面试提问整理

1. 请描述一下你们公司的测试流程需求澄清会议测试计划、方案及其评审测试用例及其评审测试执行、缺陷跟踪测试结束出报告2. 测试计划是谁编写的组长/测试经理3. 测试计划主要内容有哪些项目概述、测试范围、人员分配、测试策略、进度、风险4. 测试计划评审人需要哪些项目经理和测试组全体5. 什么叫里程碑就是项目或版本过程中的各个时间或任务节点，比如版本发布、需求定稿等等6. 什么是版本计划针对一个升级版本做的计划，内容包括版本范围、进度安排、人员分配、风险等7. 测试计划的编写依据有哪些需求规格设明书、项目计划可能参考到的还有需求分析表、概要设计8. 项目进度和测试计划不一致怎么处理根据实际情况修改计划9. 编写测试计划大概需要多次时间1-3天（一周内随便说吧）10. 你们公司是什么阶段介入软件测试的从需求分析开始，测试人员就介入了，开发和测试人员同时进行需求分析。从SE写出新需求的概要设计开始，开发和测试同时对FRS和概要设计进行需求澄清会议，然后开发人员写详细设计，测试人员写测试方案，开发人员编码，测试人员写用例，开发人员提交版本，测试人员进行测试。11. 你们公司开发和测试人员比例是多少3：112. 你们有独立的测试部门吗？有/没有，我们都在同一个项目中，项目经理管理我们，我们只有一个测试组长。13. 开发和测试出现了意见冲突怎么解决沟通，沟通解决不了的可以将问题升级。14. 测试需求分析是谁做的除新员工外的全体测试人员，新员工也参与，但不会分配任务和对需求分析负责。15. 需求阶段需要出哪些文档测试需求分析表、概要设计、测试计划等16. 测试的依据是什么需求，归根结底就是需求。17. 什么是隐形需求就是需求中没有明确要求，但是按照约定俗成的规则或日常习惯必须满足的需求。就好像问：你有XXX的电话号码吗？18. 项目中碰到需求的问题，能够直接和客户沟通吗？能，我在项目组中是对外接口人，我可以直接和客户方的代表开会进行沟通。/不能，我们需要将问题整理到一起，由测试经理和项目经理作为接口人和客户进行沟通。/不能，我们的需求是产品线提的，关于需求问题，我们直接找产品线。19. 需求过程中不确定的需求怎么解决项目组内讨论解决，如果还是得不到解决，需要找用户确认20. 需求文档是谁编写的客户/产品线21. 怎么进行需求测试会议讨论评审22. 什么是测试点，测试点包含哪些内容就是针对功能细分的点，我们写的测试点类似于测试用例的标题，是说什么功能的什么情况。23. 什么是测试方案，什么是测试策略方案是指导我们要怎么测的问题，里边的主要内容是测试点。策略是指导我们都要测什么方面，比如要进行功能测试，性能测试，兼容性测试等等，并指出需要依赖什么工具等。24. 测试方案是谁编写的分给谁谁写，自己写自己负责的部分，一般除了新员工都会写。25. 测试方案包含哪些内容业务功能的描述，对需求、功能的理解，业务流程图、业务表、测试点等等。26. 测试方案编写的输入条件是什么需求规格说明书、测试需求分析表27. 请描述一下测试用例需要参考的文档绝大部分都是参考测试方案，很少量是参考需求文档或其他文档。28. 测试用例设计方法有哪些？等价类、边界值、场景法、因果图、判定表、错误推测法29. 测试用例内容有哪些ID、标题、优先级、前置条件、操作步骤、预期结果等30. 什么是好的测试用例我觉得不冗余不遗漏的测试用例就是好用例，我也看过理论方面的书，书上说能够发现至今没有发现的缺陷的用例就是好用例，不过我们在设计用例的时候根本不知道我们设计的用例执行结果是什么。31. 测试用例的颗粒度划分颗粒度大小就是用例的粗细程度，每个项目组的尺度应该有所不同吧。32. 测试用例为什么需要有优先级，有哪一些优先级因为在不同阶段执行的用例数目是不同的，用例对应的功能的重要程度也是不同的，我们用的是高中低三级33. 你们以前一天能够编写多少测试用例30条左右吧，没怎么统计过，大概是这个数34. 你们项目一共有多少条测试用例500-2000，具体项目具体分析，和项目大小、颗粒度大小都有关系。35. 高、中、低先级的测试用例的比例占多少都差不多只是中的会多于其他两个，差不多3/4/3的比例吧。36. 测试用例需要哪些人来评审我们测用例评审是测试组内评审的，因为我们的方案是全体项目组成员（PM、SE、开发和测试）来评审的，并且方案里的测试点写到了测试用例标题的程度，所以我们拿已经全员评审过的测试点来写用例只不过是一个体力活，所以我们的用例评审就不用太多人员来参与了。我们是项目组全体来评审的，毕竟测试是保证软件质量的最后一个环节，测试用例是测试执行的依据，所以测试用例十分重要，项目组非常重视用例的评审，希望把漏测的可能降到最低，所以我们的用例是项目组全体会议评审的。37. 一个项目需要写多少测试用例怎么估算这个在需求分析之后根据测试点来评估的，我们的测试点写的很细，所以测试用例的数目几乎等于测试点的数目38. 测试用例是谁写的测试人员39. 不能发现bug的测试用例不是好的测试用例吗？我不这样认为，我觉得在执行之前，每个用例都可能发现缺陷，好的测试用例是一套完整的不冗余、不遗漏的测试用例，是能够被其他测试人员执行的测试用例。不能因为是否找到BUG来说用例是否好。40. 为什么要进行交叉测试执行因为自己执行自己设计的用例，会按照设计用例的思路来执行用例，可能会忽略一些偶然或异常的情况，交叉执行可能会发现新的BUG。当然如果用例已经写的很细，颗粒度很小，输入输出写的很全面，交叉执行的效果都会差不多，因为无论谁来执行，结果都是一样的。41. 测试环境是谁搭建的我们老大/CMO/测试人员42. 你们测试版本是在哪里去获取的开发搞定之后提交到SVN上，我们去SVN上取43. 什么叫预测试，预测试是怎么进行的，预测试一般为多长时间预测试就是开放刚刚开发完成，测试环境刚搭建起来，这时我们要对系统的各种功能能不能跑通，业务流程能不能完成进行测试，就是“冒烟测试”，这就是转测试，我们转测试大概需要一天的时间。44. 测试准入条件是什么预测试功能无阻塞45. 测试环境搭建需要和需求配置一样的硬件条件吗不一定，功能测试环境是不关注硬件条件的，如果测试性能的话，就要关注这个了。（其实我不知道什么是需求配置）46. 测试环境会不会在虚拟机上搭建可能会吧，我们的测试环境都搭建在物理主机上了。47. 测试环境搭建一般会有安装说明书吗会48. 预测试无法通过怎么处理开发连夜改，如果改不好推迟测试开始时间49. 每天能够执行多少条测试用例20来条吧50. 执行用例之后用例会有哪些状态通过、不通过、阻塞51. 对于无效的用例怎么处理，哪些情况会导致用例无效删，需求变更、设计重复、或者对需求理解有偏差都可能造成用例无效。52. Bug的生命周期以及Bug在每个阶段的的状态测试人员提交BUG 新建测试经理确认BUG 打开项目经理/开发经理确认，分配给开发 打开开发确认，修改 已修改测试回归通过 关闭开发确认非错 非错/rejected测试确认非错 关闭开发确认不改 不改开发确认遗留 delay/延迟/遗留测试人员回归不通过或确认是BUG reopen/重新打开53. 测试人员在Bug或者需求上存在争议解决过程是怎么样的？沟通、讨论，找用户确认，不成就升级54. 项目中出现争议，测试经理和开发经理无法抉择怎么处理没有遇到过，具体问题具体分析，都是一个团队的，没有解决不了的问题55. 你们公司用什么缺陷管理工具，谁维护缺陷管理工具BUGFREE BUGZILLA BUGBASE QC 56. 系统测试缺陷产生的主要原因有哪些需求理解错误、设计不完善、程序错误、UI错误、兼容性、性能、安全性等57. Bug级别怎么来定义，一般有几级我们用的是四级，1-致命，2-严重，3-一般，4-轻微/建议58. 说出你映像最深刻的Bug略，我在课堂说过一个userid和customerid重复的问题。59. 哪一些Bug需要关闭回归通过的，确认非错的，无效的60. 测试什么时候可以结束软件通过验收测试；用例覆盖率、测试执行率、测试通过率、遗留问题等方面达到质量指标；问题都已修复，执行用例无法发现新问题。61. 性能测试在什么时候测试功能稳定之后，具体的时间就是没有其他干扰性能环境的时间。比如一共四轮测试的第三轮。62. 自动化测试在什么时候测试回归63. 兼容性测试在什么时候测试功能稳定之后64. 资料测试包括哪些，谁来测试，资料测试在什么时候测试测试方案、测试用例、版本说明书、安装说明书等等文档的评审。方案、用例的评审就是在其完成之后，版本说明书、安装说明书在版本发布之前。65. 资料是谁写的CMO，我们写的。66. 资料测试需要设计测试用例吗？无67. 测试一般分几轮，大致的时间段是怎么样的我们新项目一般测4、5轮甚至更多，我们的版本测试一般都是3轮。新项目中第一、二轮都差不多一个月，3轮可能有半个多月，第4轮大概只有几天。版本中第一轮可能有一周，第二轮差不多3、4天，第三轮可能只有1、2天。68. 无法执行的测试用例怎么处理分析原因，如果是冗余的就删除，如果是被阻塞的就保留69. 测试提交的bug怎么处理确认、修改70. Bug修改后由谁来回归提BUG的测试人员71. 回归不通过的Bug是什么状态打开72. 你写过测试总结吗？你说的测试总结是更像测试报告还是业务总结呢？我写过业务总结，就是在进行了这部分业务的测试之后，总结一下这个业务的细节和测试需要关注的点。73. 测试报告是谁编写的测试经理/组长74. 测试报告时谁评审的PM、测试主管、部门主管、部门经理等75. 测试报告里面包含哪些内容测试过程中的数据如用例覆盖率、执行率、通过率等，遗留BUG的分析，风险，质量评估结果等76. 验收测试是谁做的用户77. sit，ut，uat是什么 SIT就是System Integreation Testing 系统集成测试UT就是 Unit Testing 单元测试UAT 就是User acceptance Testing 用户接收测试/验收测试78. 什么是用户手册指导用户使用的说明书79. 验收测试不通过测试需要做什么改BUG80. Bug怎么进行回溯分析漏测的BUG是什么原因产生的，如果是容易发现的，并且测试用例中有涉及，要追究相应测试人员的责任，如果是偶发性，隐藏比较深，也要进行记录，在日后的测试中加以注意。总之，如果是能力范围内，能够找到却没有找到的BUG就要追究相关测试人员的第一责任，如果非能力范围内的，要引以为戒，吸取教训，积累经验。81. 你们项目的缺陷密度是多少BUG数/代码量82. 验收的缺陷密度是多少不知道83. 验收不通过，谁承担责任一般来说，测试人员承担第一责任84. 有Bug的版本能否发布可能会发布，看BUG是啥BUG，有多大影响，修改需要多少成本，还是那句话，具体问题具体分析。85. 阿尔法测试盒贝塔测试区别是公司内部员工模拟用户进行测试。测试是用户进行非正式验收测试。86. 你们项目总共发现了多少Bug项目的话200-400版本的话20-6087. 一个项目10个月，你能大致划分一下每个阶段嘛？确定需求可能需要2、3个月，之后要做近一个月的需求分析，开发设计、编码，测试人员的测试设计可能也需要3个月左右，而测试执行大概需要4个来月。88. Bug在项目中不能正常收敛，原因有哪些？需求不断变更是很可能的原因，或者是开发人员水平较低，修复一个BUG引发出若干其他BUG。89. 在测试阶段能够发现大概多少比例的Bug很多吧，应该有80%以上，如果版本很稳定可能会更高。90. 解释一下为什么越早发现Bug，修复成本越小因为越早发现BUG，就会在错误的道路上走的越短，及时修正后，避免了在错误的道路上越走越远的情况。91. 什么是28原则8成BUG在2成的模块。92. 你是怎么安排你的工作时间的我还是以任务为导向或者说以结果为导向的，每天我都有自己的目标，今天打算完成多少工作，会做到今日事今日毕，如果完成的比较早，可能会帮助其他同事或加强自己学习和提高，如果在下班的时候还差一点完成不了，我宁可加班完成，也不愿意将任务拖到第二天。当然如果遇到我个人无法解决的问题，造成了我任务完成不了，我会尽快反馈、协调解决问题，尽量保证当天可以完成，或调整我的工作计划。93. 你对出差有什么看法全球不限时不限地点94. 项目是否发现Bug越多，质量越好NO！发现的越多，藏的也越多95. 上线前晚上发现严重Bug，第二天之前来不及修复，该项目能否上线不能UT = unit testing 单元测试IT = integration testing 集成测试ST = system testing 系统测试UAT= User acceptance testing 用户接受测试(俗称:验收测试)经过了近2年的努力，多数研发团队都用上了技术质量部自主研发的Bug管理工具Kelude_Issues，告别了商业工具和其他的开源工具。这个过程中Bug跟踪流程也发生了比较多的变化，下图是现在Kelude_Issues的Bug跟踪流程图：这个流程还是有着比较多的“淘宝特色”，我想可能很多用惯了其他Bug管理产品的同仁，看着这个图会感觉不太习惯，觉得状态比较多，箭头也多，有点绕。在经典的Bug跟踪流程里面，对于“状态”概念的定义，是比较清楚的，一般来说这些状态会比较常见，当然由于工具的不同，所用的英文单词也会有些差别，这个不用纠结，领会精神。New：新创建的BugOpen：经过了PM的确认，确实是个BugAssigned：已经分配给开发工程师进行解决Resolved：开发工程师解决了，等待测试工程师验证（注意是解决，不是fix）Closed：通过了验证，关闭这里最容易引起混淆的概念，就是“Resolved”被解决过了。最常见的解决方式，就是Fixed，被修复了；有时因为一些原因，暂时无法修复，只能Later，其实Later也是一种解决方式，常见的解决方式有以下几个：Fixed：被修复了Later：暂时不修复，后面的版本再修复Wont Fix：不修复了，其实是一种Later的特例，无限期LaterInvalid：根本不是Bug，往往由于对需求的误解Duplicate：重复的，相同的Bug已经被提交过一次了Not Reproducible：无法重现，在淘宝叫做Works for Me严格来说，这一组“解决方式”，是属于同一层面的，它们都需要由测试或者PM来验证，如果验证不通过，那就回到Open状态，验证通过就Close。而在淘宝Bug流程中，这些“解决方式”都被设置成了“状态”，其实也挺好，更加直观。但是这里有一个很要命的问题，就是那