软件测试-面试题
软件测试_面试题
持续更新…
[软件测试工程师经典面试题](https://blog.csdn.net/qq_41625341/article/details/82941787)
文章目录
-
- 软件测试_面试题
-
- 1. 软件测试都要测试什么？
- 2. 软件缺陷的定义？
- 3. 软件测试的定义？
- 4. 解释一下确认和验证？
- 5. 软件测试的目的是什么？
- 6. 软件测试和软件调试区别？
- 7. 软件测试的对象是谁？(跟1.问题类似)
- 8. 描述一下软件的生命周期及其产出物？
- 9. 你认为软件研发人员在软件生命周期中什么阶段就应该介入呢？
- 10. 瀑布模型有什么优缺点呢？重点说说缺点。
- 11.简单说一下螺旋模型，并说说螺旋模型的特征 。
- 12. 说说迭代模型和它的优点？
- 13. 解释一下增量模型，并说说它的缺点是什么？
- 14. 解释一下快速原型模型流程。
- 15. 总结一下软件开发模型有哪些？
- 16. 说说软件测试的流程，并说说软件开发和软件测试流程在哪里是交集？
- 17. 说说V模型，并谈谈它的缺点。
- 18. 谈谈W模型，并解释一下它与V模型不同之处，最后说说W模型的优缺点。
- 19. 简单的说说H模型和X模型。
- 20. 简单的说说软件测试工作岗位的独立性。
- 21. 简单的说说软件测试过程理念
- 22.解释一下单元测试和集成测试
- 23.简单的说说验收测试的α，β，γ测试。
- 24.简单说说静态测试和动态测试。
- 25.简单的说说回归测试，冒烟测试，随机测试，猴子测试。
- 26.简单说说手工测试和自动化测试。
- 27.简单说说黑盒测试，白盒测试，灰盒测试。
- 28.说说软件测试原则？
- 29.什么是测试用例？如果软件按照测试用例运行达不到预期的结果怎么办？如果开发人员说缺陷修复了，你接下来要怎么做？
- 30.如果让你设计一个测试用例，那么你觉得这个测试用例应该包含哪些东西？
- 31.设置测试用例有用吗，有必要耗时间编写吗？（设置测试用例的作用）
- 32.在时间不够用的情况下，还要进行详细的测试用例设计吗？测试用例需要经常更新吗？
- 33.测试数据的选取可以用哪些方法？
- 34.简单说说等价类的划分步骤，并分析如果让你来划分等价类，比如用户名的规则是：设置后不可更改，中英文均可，最长14个英文或7个汉字，这样的案例你要怎么划分？
- 35.简单说说测试用例模板，并简单解释一下每一项的注意点。
- 36.在以下案例中，请使用边界值分析法，进行测试数据的取值。
- 37.多边形判断小程序（等价类和边界值综合）如何去设置测试用例？
- 38.测试用例设计方法你会怎么用？
- 39.说说因果图法和它的局限性
- 40.说说因果图中原因和结果之间的关系、约束条件（原因约束，结果约束）
- 41.饮料自动售货机案例（使用因果图法）
- 42.说说判定表法（判定表驱动法）
- 43.说说判定表的使用条件和应用场景
- 44.订购单检查案例（使用判定驱动法）
- 45.杂志的阅读指南判定表，对该判定进行优化
- 46.讲讲场景法，并说出场景法的基本原理和基本流、备选流
- 47.ATM机的取款流程案例（场景法）
- 48.说说正交实验法
- 49.工业生产案例（正交实验法）
- 50.说说功能图法（状态迁徙图），并说出功能图法的目标和使用场景
- 51.QQ登录界面案例（功能图法）
- 52.简单说说测试大纲法、探索测试法、猴子测试法（随意性测试）
- 53.猴子测试法的缺点
- 54.用例测试方法如何选择？
- 55.说说缺陷的属性
- 56.说说缺陷的类型
- 57.说说缺陷的严重程度
- 58.说说缺陷的修复等级
- 59.说说缺陷的状态
- 60.说说缺陷的起源
- 61.说说缺陷的来源
- 62.说说缺陷的根源
- 63.说说缺陷的起源、来源、根源的关注度
- 64.缺陷的严重程度和缺陷的优先级有什么关系？提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级
- 65.讲讲缺陷的生命周期
- 66.针对你工作中的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）
- 67.说说缺陷识别的依据
- 68.说说缺陷报告的编写目的、编写准则和预期读者
- 69.说说缺陷报告模板中有哪些内容
- 70.<缺陷描述>的准则
- 71.说说测试需求、测试用例和缺陷报告的关系。
- 72.白盒测试中常见的覆盖。
- 73.如果给你一个水杯，你会怎么对它做测试？（经典）
- 74.简单的说说禅道使用的大致流程
- 75.什么是接口测试？接口测试的范围。
1. 软件测试都要测试什么？
答：程序、数据、文档都要测试。
2. 软件缺陷的定义？
答：
笼统的回答说是：所有不满足需求或超出需求的都是缺陷，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。
比较专业的回答：1.软件未实现产品说明书要求的功能 2.软件出现了产品说明书指明不应该出现的功能 3.软件实现了产品说明书未提到的功能 4.软件未实现产品说明书虽未提及但应该实现的功能。 5.软件难以理解、不易使用、运行缓慢或者（从测试的角度来看）最终用户会认为不好。
3. 软件测试的定义？
答：
1.正向测试是确认产品能够正常工作，然后去评价一个程序或系统的特性或者能力，并确定它是否能够达到预期效果，软件测试就是以此为目的的任何行为。
2. 反向测试是为了发现错误而执行一个程序或系统的过程。
3. IEEE定义的软件测试：
在规定条件下运行系统或构件的过程：观察并记录结果，并对系统或构件的某些方面给出评价。
分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性。
4. 广义的软件测试：对软件形成过程中的所有工作产品（包括程序以及文档）进而不仅仅是对程序的运行进行测试。
4. 解释一下确认和验证？
答：
确认：通过检查和提供客观证据来证实特定目的的功能或者应用是否已经实现。
验证：通过检查和提供客观证据来证实指定的需求是否满足。
5. 软件测试的目的是什么？
答：
1.以最少的人力，物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。
2.同时利用测试过程中得到的测试数据和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。
3.采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量。
6. 软件测试和软件调试区别？
答：
1.在主体，目标，方法和思路上有所不同。
2.测试是从已知条件开始，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始，结束的过程可能不可预计。
3.测试可以计划，可以预先指定测试用例和过程，工作进度可以度量；描述调试的过程或持续时间比较困难。
4.测试的对象包括软件开发过程中的文档，数据以及代码；调试的对象一般来说只是代码。
| 测试 | 调试 | |
|---|---|---|
| 主体 | 测试人员 | 开发人员 |
| 目标 | 找bug | 将错误修改正确 |
| 方法 | 等价类、边界值 | 程序和逻辑算法 |
| 思路 | 反向思维占据主流 | 正向思维占据主流 |
7. 软件测试的对象是谁？(跟1.问题类似)
答：测试的对象包括软件开发过程中的文档，数据以及代码。
8. 描述一下软件的生命周期及其产出物？
答：需求分析，产生需求规格说明书；概要设计，产生架构文档；详细设计，产生详细设计文档；编码，产生源代码；测试，产生测试文档；最后软件产品验收。
9. 你认为软件研发人员在软件生命周期中什么阶段就应该介入呢？
答：测试人员应该参与到整个软件的生命周期中，即从需求阶段就应该参与。
10. 瀑布模型有什么优缺点呢？重点说说缺点。
答：
缺点：
1.强调时间顺序的严格执行，前阶段不完成，后阶段也无法开始，即缺乏灵活性。
2.将测试放在了编码之后，没有体现测试贯穿软件生命周期的原则，即测试人员在需求的时候就要参与进去（避免需求的问题一直延续到代码完成才得以暴露）。
3.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
4.线性开发，用户等到整个过程的末期才能见到开发成果，从而增加了开发风险。
5.瀑布模型不适应用户需求的变化。
优点：
1.为项目提供了按阶段划分的检查点。
2.当前一阶段完成后，只需要关注后续阶段。
11.简单说一下螺旋模型，并说说螺旋模型的特征 。
答：
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。
特征：
1.引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减少损失。
2.螺旋模型更适合大型的昂贵的系统级的软件应用。
12. 说说迭代模型和它的优点？
答：
迭代包括产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必须的所有其他元素，强调开发的深入。在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析，设计，实施和测试工作流程。
优点：
1.降低了在一个增量上的开支风险。
2.降低了产品无法按照既定进度进入市场的风险。
3.加快了整个开发工作的进度。
4.迭代过程这种模式使适应需求的变化会容易些。
13. 解释一下增量模型，并说说它的缺点是什么？
答：
把软件分割成若干独立的模块，分批次的完成和交付。
缺点：最明显的缺点就是如果打破原有的软件结构和框架，可能会带来一定的风险。
14. 解释一下快速原型模型流程。
答：产品经理制作完原型，给客户讲解、演示原型，客户觉得不行，产品经理改进原型，客户满意，原型交给开发人员依照原型开发产品。
15. 总结一下软件开发模型有哪些？
答：瀑布模型、螺旋模型、迭代模型、敏捷开发模型、增量模型、快速原型模型等。
16. 说说软件测试的流程，并说说软件开发和软件测试流程在哪里是交集？
答：
1.获取软件测试需求、编写软件测试计划、制定软件测试方案、开发与设计测试用例、执行测试、提交缺陷报告、测试分析与评审、提交测试总结、准备下一版本测试。
2.在软件测试流程中，执行测试这一项是交集。
17. 说说V模型，并谈谈它的缺点。
答：
V模型是一种软件测试的过程模型，它揭示了开发过程与测试过程中各阶段的对应关系;V模型的工作流程是线性的：用户需求、需求分析与系统、概要设计、详细设计、编码，单元测试对应详细设计、集成测试对应概要设计、系统测试对应需求分析与系统、验收测试对应用户需求。
缺点：
1.V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析、系统设计的验证；
2.需求分析的满足情况一直到后期的验收测试才被验证；
3.没有提现出“尽早地和不断地进行软件测试”的原则。
总结来说就是，V模型没有体现测试贯穿软件生命周期的原则，测试介入的时间太晚，它是在编码后才进行测试，这种模型是不科学的，它会导致很多问题在最后的测试环节才被发现。
18. 谈谈W模型，并解释一下它与V模型不同之处，最后说说W模型的优缺点。
答：
W模型由两个V字形模型组成，分别代表测试与开发过程，明确表示出了测试与开发的并行关系。
用户需求阶段对应验收测试设计
需求分析与系统设计阶段对应确认与系统测试设计
概要设计阶段对应集成测试设计
详细设计阶段对应单元测试设计
编码阶段对应单元测试
代码集成阶段对应集成测试
项目实施阶段对应确认测试与系统测试
项目交付阶段对应验收测试
优点：
1.测试活动与软件开发同步进行
2.测试的对象不仅仅是程序，还包括需求和设计
3.尽早发现软件缺陷可降低软件开发的成本
局限性：
在W模型中，需求，设计，编码等活动被视为串行的，这样就无法支持灵活的迭代。
19. 简单的说说H模型和X模型。
答：
H模型：
H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。它具有以下特点：H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到了准备就绪点，测试执行活动就可以开展，并且不同的测试活动可以按照某个次序先后进行，也可以反复进行。
X模型：
X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终成为可执行的程序。X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
H模型：
X模型：
20. 简单的说说软件测试工作岗位的独立性。
答：
可以这么说，工作岗位上的独立性：专门的测试外包公司岗位>企业内部独立于研发部门的测试>研发团队的测试岗位>开发人员自己测试
21. 简单的说说软件测试过程理念
答：
1.尽早测试
测试人员早期参与软件项目；尽早的开展测试执行工作。
2.全面测试
对软件的所有产品进行全面的测试；软件开发及测试人员（有时包括用户）全面的参与测试工作中。
3.全过程测试
测试人员要充分关注开发过程；测试人员要对测试的全过程进行全程的跟踪。
4.独立的、迭代的测试
测试活动是独立的；测试活动应该是循环往复、不断的进行。
22.解释一下单元测试和集成测试
答：
如果把软件测试按照开发阶段划分，可以划分为单元测试和集成测试;
1.单元测试
单元测试又称为模块测试，是针对软件设计的最小单元——程序模块进行正确性验证的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
2.集成测试
集成测试又称组装测试，通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
3.确认测试
确认测试也叫有效性测试，是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质。
4.系统测试
系统测试是在真实的系统运行的环境下，检查完整的程序系统是否和系统（包括硬件、外设、网络和系统软件、支持平台）正确配置、连接、并最终满足用户的所有需求。
5.验收测试
是软件产品检验的最后一个环节，按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
23.简单的说说验收测试的α，β，γ测试。
答：
验收测试一般由供求双方进行，有三种验收测试的主体。
1.α测试：软件的开发商自己进行的交付前的测试。
2.β测试：软件的需求方自己进行的测试。
3.γ测试：第三方的软件测试（需求方自己不测试，可能交给第三方的软件测试外包公司进行测试）。
24.简单说说静态测试和动态测试。
答：
如果把软件测试按照代码是否运行划分，可以分为静态测试和动态测试。
1.静态测试
指不实际运行被测试对象，而只是静态地检查程序代码，界面或文档中可能存在错误的过程；代码测试：主要测试代码是否符合相应的标准和规范；界面测试：主要测试软件的实际界面与需求中的说明是否相符文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求。
2.动态测试
指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程，所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。
25.简单的说说回归测试，冒烟测试，随机测试，猴子测试。
答：
1.回归测试
是指对软件的新版本测试时，重复执行之前某一个重要版本的测试用例。目的：1.验证之前版本产生的所有缺陷是否被完全修复；2.确认修复这些缺陷没有引发新的缺陷。
2.冒烟测试（确认测试）
是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，也叫可测性测试。（是正向的测试）
3.随机测试（类似探索性测试）
是指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
4.猴子测试
把自己当成不懂产品的笨蛋或小动物，随便乱点，没有任何的主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。
26.简单说说手工测试和自动化测试。
答：
如果把软件测试按照测试主体来划分的话，可以分成手工测试和自动化测试。
1.手工测试
手动地测试功能。
2.自动化测试
利用工具软件，或者编写代码的方式，去测试被测的软件系统。
27.简单说说黑盒测试，白盒测试，灰盒测试。
答：
如果把软件测试按照测试技术来划分的话，可以分成黑盒测试，白盒测试和灰盒测试。
1.黑盒测试：
黑盒测试又称功能测试，是把测试对象看成一个黑盒子，通过软件的外部表现来发现其缺陷和错误，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
2.白盒测试：
白盒测试又称结构测试，把程序看成装在一个透明的盒子里，通过对程序内部结构的分析、检测来寻找问题。白盒测试是检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。
手动地测试功能。
3.灰盒测试：
介于白盒测试和黑盒测试之间。灰盒测试关注输出对于输入的正确性，同时也关注程序的内部表现，但这种关注不像白盒测试那样详细，完整，只是通过一些表征性的现象，时间，标志等来判断程序内部的运行状况。有些地方也把灰盒测试叫做接口测试。
28.说说软件测试原则？
答：
1.所有测试的标准都是建立在用户需求之上。
2.软件测试必须基于“质量第一”的想法去开展各项工作，当时间和质量冲突时，时间要服从质量。
3.事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结果，对产品的质量进行分析和评估。
4.软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。
5.穷举测试是不可能的。
6.第三方进行测试会更客观，更有效。
7.软件测试计划是做好软件测试工作的前提。
8.测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。
9.对发现错误较多的程序段，应进行更深入的测试，一般来说，一段程序中已经发现的错误越多，其中存在的错误概率也就越大。
10.重视文档，妥善保存一切测试过程（测试计划、测试用例、测试报告等）。
11.应该把“尽早和不断地测试”作为测试人员的座右铭。
12.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。
13.测试应从“小规模”开始，逐步转向“大规模”。
14.不可将测试用例置之度外，排除随意性。
15.必须彻底检查每一个测试结果。
16.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。
17.对测试错误结果一定要有一个确认的过程。
29.什么是测试用例？如果软件按照测试用例运行达不到预期的结果怎么办？如果开发人员说缺陷修复了，你接下来要怎么做？
答：
1.测试用例：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所预期结果。
2.如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件测试人员已经测出了该软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内。
3.软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成。（回归测试）
30.如果让你设计一个测试用例，那么你觉得这个测试用例应该包含哪些东西？
答：
1.用例编号：编号规则：TestCase_项目名称_模块名称_功能名称_0001；
2.测试项：测试用例的目的；
3.依赖用例：一般在功能流程上，下游功能测试用例依赖于上游功能测试用例；
4.测试步骤：软件的操作步骤；
5.测试数据：单独整合的测试数据；
6.预期结果：一般与测试目的密切相关；
7.测试结果：在测试用例执行完成后添加；
8.测试人；
9.备注：为了测试用例正常执行而做的特殊准备。
31.设置测试用例有用吗，有必要耗时间编写吗？（设置测试用例的作用）
答：
1.有效性：测试用例是软件测试人员的测试过程中重要参考依据；
2.可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率；
3.易组织性：即使是小的项目，也可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用；
4.可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证；
5.可管理性：测试用例也可以作为测试人员进度、工作量以及跟踪/管理测试人员的工作效率的标准。
32.在时间不够用的情况下，还要进行详细的测试用例设计吗？测试用例需要经常更新吗？
答：
在详细测试用例与有效测试时间中找到平衡点；
必须更新，尤其是发现过缺陷的测试用例（“杀虫剂效应”：一个发现过缺陷的测试用例，就相当于杀虫剂，“虫子”可能产生抗药性，必须换一种“杀虫剂”（新的测试用例，与之前的测试用例中数据类型保持一致）进行重新清杀）。
33.测试数据的选取可以用哪些方法？
答：
等价类划分法和边界值分析法
1.等价类划分法：等价类划分，指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，以此发现更多的软件缺陷，统计好数据后由此对软件进行改进升级。
2.边界值分析法：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
34.简单说说等价类的划分步骤，并分析如果让你来划分等价类，比如用户名的规则是：设置后不可更改，中英文均可，最长14个英文或7个汉字，这样的案例你要怎么划分？
答：
1.首先，我们要划分出等价类和列出等价类表
a. 有效等价类
b. 无效等价类
2. 确定测试用例
a. 为每个等价类规定一个唯一的编号；
b. 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例覆盖；
c. 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。
首先根据用户规则，可以分析出该规则的隐含条件：用户名的设置不能重复，不能为空；
可以这样划分：
根据中英均可这个信息：
有效等价类：中文、英文
无效等价类：数字，特殊字符
最长14个英文或7个汉字：
有效等价：14个英文/7个汉字
无效等价类：英文超过14/中文超过7
用户名的设置不能重复
有效等价：使用未注册的用户名进行注册
无效等价类：使用已注册的用户名进行注册
用户名的不能为空
有效等价：填写用户名进行注册
有效等价：不填写用户名进行注册
35.简单说说测试用例模板，并简单解释一下每一项的注意点。
答：
一般测试用例模板中包含：测试用例编号，测试项，依赖用例，测试步骤，输入数据，预期结果，测试结果，测试人，备注。
1.测试用例可以测试：功能（Function）、界面（UI）、性能（Performance）、安全（Security）、接口（Interface）等；
2.测试项：可以不写目的产生的结果，但测试项必须有明确的目的，不能模棱两可，最后不知道到底测试什么；某些常识性的不要附加上去，避免写的太长；测试项一般只写一个测试目的，不要一次测试多个点；一个无效等价类的测试数据（反向的），只要违反一个需求（比如非法的身份证号）；
3.依赖用例：一定是下游的测试用例依赖上游的测试用例；如果本身就是按照顺序做的测试用例，可以不写依赖用例，如果跨过了一定的过程或步骤，这时一定要写依赖用例；依赖用例也可以跨模块；
4.测试步骤：表明操作的对象和方式、数据；
5.测试数据：没有使用测试数据可不写；如果要求输入不为空，不输入就不写（需要在测试项中标注某一个内容为空）； 如果要对空格进行测试，建议不要将空格这个字符放在数据的最前面或者最后面；
6.测试结果不执行就不填；
7.用例中不用说明是正向测试还是反向测试。
36.在以下案例中，请使用边界值分析法，进行测试数据的取值。
答：
1.文本框需要输入6~18位字符，要怎样取值进行测试？
边界值：6个字符，18个字符
次边界值：7个字符，17个字符，5个字符（无效），19个字符（无效）
2.已知x的取值范围，6≤x≤12，请问在测试中要怎样取值进行测试？
边界值：6，12
次边界：7，11，5（无效），13（无效）
3.已知x的取值范围，6＜x＜12，请问在测试中要怎样取值进行测试？
边界值：7，11
次边界：6（无效），8，10，12（无效）
4.已知文本框的输入字符个数要求是不大于150字，要怎样取值进行测试？
隐含信息：0≤x≤150
边界值：空，150个字符
次边界：1，149，151（无效）
37.多边形判断小程序（等价类和边界值综合）如何去设置测试用例？
题目：输入多边形的各个边长，注意是整数，该程序可以判断三角形，四边形，五边形；
答：
三角形判断
（1）构成三角形 （2）构成直角三角形 （3）构成等腰三角形 （4）构成等边三角形 （5）构成钝角三角形 （6）构成锐角三角形
四边形判断
（1）平行四边形 （2）正方形 （3）长方形
五边形判断‘
这里只列出了判断三角形测试用例
38.测试用例设计方法你会怎么用？
答：
对于选择测试数据：等价类划分法、边界值分析法
对于测试步骤设计：因果图法、判定表法、场景法、正交试验法、状态迁徙图法（功能图法）
其他测试用例设计方法：测试大纲法、探索性测试、猴子测试（随意性测试）
39.说说因果图法和它的局限性
答：
因果图法是一种适合于描述对于多种输入条件组合的测试方法；根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法；它适合于检查程序输入条件涉及的各种组合情况。
局限性：
当原因和结果很多的时候，他们之间的关系连线就会很多，导致因果图的可读性变差，因此用作局部的小功能分析（即原因和结果不是很多的时候）
40.说说因果图中原因和结果之间的关系、约束条件（原因约束，结果约束）
答：
原因和结果之间的关系：恒定、非、或、与。
原因约束：互斥、包含、唯一、要求；
结果约束：屏蔽。
41.饮料自动售货机案例（使用因果图法）
题目：有一个饮料自动售货机（处理单价为5角钱）的控制处理软件，它的软件规格说明如下:
若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来;
若投入1元钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来，并同时退回5角钱的硬币。
答：
首先分析有哪些原因、结果—然后分析原因、结果的约束：
这个示例里没有强调投币和选饮料的先后性，所以“要求”约束可以不用画。
列出所有的原因和结果的列表，设计初步的测试用例步骤：
设计测试用例：
42.说说判定表法（判定表驱动法）
答：
判定表(Decision table)是另一种表达逻辑判断的工具。与结构化语言和判断树相比，判断表的优点是能把所有条件组合充分地表达出来；其缺点是判定表的建立过程较烦杂，且表达方式不如前两种简便。判定表在用于知识表达中，有许多其他方式所达不到的作用。
是分析和表达多逻辑条件下执行不同操作情况的工具。它由以下几部分组成：
1.条件桩（Condition Stub）:列出了问题的所有条件（原因），通常认为列出的条件的次序无关紧要；
2.动作桩（Action Stub）：列出的问题规定可能采取的动作（结果），这些操作的排列顺序没有约束；
3.条件项（Condition Entry）：列出针对它左列的条件的取值，在所有可能情况下的真假值；
4.动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
43.说说判定表的使用条件和应用场景
答：
所有的条件桩在表中的位置和顺序互相不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。（这点与因果图不同，因果图中的原因和结果是有各自约束的）
1.规格说明以判定表的形式给出，或很容易转换成判定表；
2.条件的排列顺序不影响执行哪些操作；
3.规则的排列顺序不影响执行哪些操作；
4.当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
5.如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。
应用场合：
主要适用于多条件的内容组合与结果分析，一般判定表法的应用比因果图更广，但因果图法和判定表法类似，因果图法和判定表法经常会结合在一起使用。
44.订购单检查案例（使用判定驱动法）
题目：如果金额超过500元，由未过期，则发出批准单和提货单；
如果金额超过500元，由未过期，则发出批准单和提货单；
如果金额超过500元，但过期了，则不发批准单；
如果金额不超过500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。
答：
首先分析条件和动作：
| 条件1 | 条件2 | 动作 |
|---|---|---|
| 金额>500 | 未过期 | 发出批准单、提货单 |
| 金额>500 | 过期 | 发提货单 |
| 金额≤500 | 未过期 | 发出提货单、提货单 |
| 金额≤500 | 过期 | 发出提货单、提货单、通知单 |
然后进行判定表优化：
观察判定表可以发现，不管金额的高低，只要过期，就会发送批准单和提货单（在测试时间不充足的情况下，可以选两者中的一个情况下进行测试）—当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
所以优化后，条件项就减少成为3个。
最后将判定表中的每一列也（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果。
45.杂志的阅读指南判定表，对该判定进行优化
题目：
该判定表为一个杂志的阅读指南判定，指导读者能够良性阅读。
读完表格后，请对表格内容进行优化，将重复的内容去掉，并且说明原因，为什么能合并。
答：
在时间充足的情况下，就把所有可能的条件组成测试一遍，时间不充足的情况下，要想进行全面的覆盖，只能采用科学的方法进行优化。
46.讲讲场景法，并说出场景法的基本原理和基本流、备选流
答：
通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。
基本原理：
现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
基本流：软件功能按照正确的事件流实现的一条正确的流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）
备选流：除了基本流之外的各支流，包含多种不同的情况。采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）
47.ATM机的取款流程案例（场景法）
答：
简单的分析：
详细：
基本流：插卡—输入—选择取款服务—选择取款金额—等待出钞—退卡
备选流：
- 卡片不是银行卡
- 卡片不是银联卡
- 密码输错1-2次，第三次输入正确
- 密码输错3次，冻结银行卡
- 选择存款服务
- 选择转账服务
- 选择修改密码服务
- 取款机没有纸币了
- 取款机没有信号了
- 等…
场景设计：
场景1：基本流
场景2：基本流 备选流1
场景3：基本流 备选流4
场景4：基本流 备选流2 备选流3
…
设计测试用例步骤（每一个场景都是一个测试用例）：
以场景4为例：
假定ATM只能识别银联卡
1.插卡—用万事达卡，ATM不识别
2.换卡—银联卡
3.输入密码-第一次输入错误
4.输入密码—第二次输入密码
5.输入密码—第三次输入密码正确
6.选择取款服务
6.选择取款金额
8.等待出钞
9.退卡
为用例的步骤设计测试数据…
48.说说正交实验法
答：
正交试验法就是利用排列整齐的表—正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最好的效果。这种试验设计方法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。
49.工业生产案例（正交实验法）
题目：
有一个工业产品，其生产工艺受到操作方式、温度、洗涤时间三个因素的影响，并且每个因素都有三种可能的取值，具体如下所示，请设计试验组合。
| 因素 | 操作方式 | 温度(℃) | 洗涤时间(min) |
|---|---|---|---|
| Ⅰ | 60 | 15 | |
| Ⅱ | 80 | 20 | |
| Ⅲ | 100 | 25 |
答：
如果完全排列组合：3*3*3=27
使用小工具完成正交实验的设计：正交设计助手
以上面的案例为例使用该工具：
文件→新建工程→右键“未定义工程”→修改工程
实验→新建实验→设计向导（实验说明）
设计向导（选择正交表）：这个案例是3水平3因素，我们选择3水平4因素的正交表（L9_3_4），这里是选择最贴切的正交表，如果因素个数选小了，就无法覆盖所有可能的测试用例。
设计向导（因素和水平）→填写数据后→点击确定
完成后的正交表设计：
至于推导的过程，这个可以不要求清楚。
观察以上设计的正交表：
每一列中，同一个数字出现的次数相等（这里是出现了3次）
任意两列中，同一个数字对出现的次数相等（这里是出现了1次）
50.说说功能图法（状态迁徙图），并说出功能图法的目标和使用场景
答：
功能图方法是用功能图形象的描述程序的功能说明，并机械的生成功能图的测试用例。功能图由状态迁移图和逻辑功能模型构成。
目标：
设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁徙图路径的覆盖。
使用场景：
软件的状态会根据某些内容、条件、操作的变化而变化。（比如Tim的隐身、在线、离线、忙碌等状态）
51.QQ登录界面案例（功能图法）
题目：这里以老版的QQ登陆界面为例，说明功能的变迁：
答：
1）首先识别出可以进行的操作：
IP1:输入账号
IP2:输入密码
IP3:点击登录
IP4:点击关闭按钮
2）定义QQ登录界面为 “空闲” 状态；
3）给“空闲”状态加操作，就产生了新的状态；
4）在新状态的基础上加操作，得到了一个新的状态 “QQ号，密码已输入”；
5）在新状态的基础上加操作，得到得到了一个新的状态 “QQ登录后的界面”，但这个状态和“空闲”状态发生了“隔断”，因此可以将其视为空闲状态的结束，而结束整个分析过程；
6）将状态变化过程列表化，准备设计测试用例；
| 状态名/序号 | A | B | C | D | … |
|---|---|---|---|---|---|
| 空闲 | 1 | 1 | 1 | 1 | |
| QQ号已输入 | 2 | 2 | |||
| 密码已输入 | 2 | ||||
| QQ号、密码已输入 | 3 | ||||
| QQ登录后的界面 | 4 | ||||
| 退出 | 2 | 3 | 3 |
每列的含义：
A列：从QQ登陆界面，直接点击登录按钮，QQ登录退出；
B列：…
C列：…
D列：从QQ登陆界面，先输入QQ号（状态变为 “QQ号已输入”）；在输入密码（状态变为QQ号，密码已输入），点击登录，状态变为“QQ登录后的界面”；
…
x列：…
好的测试用例，越简单越好，做到：大道至简，大巧若拙。
6）写出测试用例…
52.简单说说测试大纲法、探索测试法、猴子测试法（随意性测试）
答：
测试大纲法：是一种着眼于需求的方法，为列出各种测试条件，将需求转换为大纲的形式，就类似于思维导图（树形结构）。
探索测试法：基于经验和和直觉，是计划内测试用例设计的补充，探索性测试执行前也需要设计测试用例。
猴子测试法（随意性测试）：一种没有书面测试用例，记录期望结果、检查列表、脚本或指令的测试（无意识的测试）。
53.猴子测试法的缺点
答：
1）测试往往不太真实；
2）不能达到一定的覆盖率；
3）许多测试都是冗余的；
4）需要使用同样的随机数才能重建测试，即想要重复的操作及其困难。
54.用例测试方法如何选择？
答：
1）首先进行等价类划分
2）在任何情况下都必须使用边界值分析法
3）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
4）对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳的效果
5）状态迁徙图也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据
6）对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
7）可以用错误推测法（探索性测试）追加一些测试用例
8）对照程序逻辑，检查已设计出的测试用例看的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例
55.说说缺陷的属性
答：
1）缺陷类型（type）：缺陷类型是根据缺陷的自然属性划分的缺陷种类。
2）缺陷严重程度（Severity）：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
3）缺陷优先级（Priority）：缺陷的优先级指缺陷必须被修复的紧急程度。
4）缺陷状态（Status）：缺陷的状态指缺陷通过一个跟踪修复过程的进展情况。
5）缺陷起源（Origin）：缺陷的起源指缺陷引起的故障第一次被检测到的阶段。
6）缺陷来源（Source）：缺陷的来源指缺陷的起因。
7）缺陷根源（Root Cause）：缺陷的根源指发生错误的根本因素。
56.说说缺陷的类型
答：
1）功能（Function）：影响了各种系统功能、逻辑的缺陷。
2）用户界面（UI）：影响里用户界面、人机交互特性、包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷。
3）文档（Documentation）：影响发布和维护、包括注释、用户手册、设计文档。
4）软件包（Package）：由于软件配置库、变更管理或版本控制引起的错误。
5）性能（Performance）：不满足系统可测量的属性值、如执行时间、事务处理速率等。
6）系统/模块接口（Interface）：与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突。
57.说说缺陷的严重程度
答：
1）致命（Fatal） ：系统任何一个主要功能完全缺失，用户数据收到破坏，系统崩溃、悬挂、死机、或者危及人身安全。
2）严重（Critical）：系统的主要功能部分丧失，数据不能保存，系统次要功能完全丧失，系统所提供的功能或服务受到明显的影响。
3）一般（Major）：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题。
4）较小（Minor）：操作者不方便或遇到麻烦，但它并不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 。
58.说说缺陷的修复等级
答：
1）立即解决（P1级）：缺陷导致系统几乎不能使用或测试不能继续，需立即修复（一般几个消失内，比如四个小时）。
2）高优先级（P2级）：缺陷严重，影响测试，需要有限考虑（一般一天内）。
3）正常排队（P3级） ：缺陷需要正常排队等待修复（在新版本发布之前）。
4）低优先级（P4级）：缺陷可以在开发人员有时间的时候被纠正（有些缺陷甚至跨越几年都没有修复）。
59.说说缺陷的状态
答：
1）激活/打开： 问题还没有解决，存在于源代码中，确认“提交的缺陷”，等待处理，如新报的缺陷。
2）已修复/修复 ：已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但还没有被测试人员验证 。
3）关闭/非激活：测试人员验证后，确认缺陷不存在之后的状态 。
4）重新打开： 测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复。
5）推迟：这个软件缺陷可以在下一个版本中解决。
6）保留： 由于技术原因或第三方软件的缺陷，开发人员不能修复的缺陷。
7）不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷复现的步骤 。
8）需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。
9）重复：这个软件缺陷已经被其他软件测试人员发现。
10）不是缺陷 ：这个问题不是软件缺陷。
11）需要修改软件规格说明书：由于软件规格说明书对软件设计的要求，必须要修改软件规格说明书。
扩展：
1.激活/打开（新建）。由开发人员进行标注。
2.确认。确认新提交的缺陷是一个真实有效的缺陷。一般由测试主管、或者质量保证（OA）、由产品经理进行确认。经确认后，有效的缺陷会指派给相关人员进行处理。
3.已修复/修正。在缺陷被修复后，一般由开发人员进行
4.关闭/非激活。缺陷被修复完成后，经测试人员的验证后，没有问题。
5.重新打开。经测试人员验证后，发现缺陷并没有被修复成功，需要开发人员重新打开进行再次处理和修复
6.推迟。缺陷现在不修复，推迟到下一个版本或者阶段。测试要跟开发或者其他相关管理人员进行确认（推迟的这个状态要去确认）
7.保留。缺陷暂时修复不了。一般由开发人员去设定，测试人员进行确认。
8.不能重现。一般闪退、崩溃类型的缺陷具有类似的特征，或者由于操作系统的差异、浏览器缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要再三的确认bug。
9.需要更多信息。作为测试人员，提交bug的时候，要尽可能的把所有相关文件一起提交。（比如测试用的图片、视频）
10.重复。测试中，一定要避免这种情况出现。尤其在软件的某一个功能频繁被多个模块（由不同的测试人员测试）调用的情况下。
11.不是缺陷。注意不要出现这种情况。
12.需要修改软件规格说明书。缺陷不是技术原因造成的，而是由于需求不明确或者设计不明确造成的。
60.说说缺陷的起源
答：
1）需求：在需求阶段发现的缺陷。
2）架构：在系统架构设计阶段发现的缺陷。
3）设计：在程序设计阶段发现的缺陷。
4）编码：在编码阶段发现的缺陷。
5）测试：在测试阶段发现的缺陷。
6）用户：在用户使用阶段发现的缺陷。
61.说说缺陷的来源
答：
1）需求说明书：需求说明书的错误或不清楚引起的问题。
2）设计文档：设计文档描述不准确和需求说明书不一致的问题。
3）系统集成接口：系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷。
4）数据流（库）：由于数据字典、数据库中的错误引起的缺陷。
5）程序代码：是由编码中的问题引起的缺陷。
62.说说缺陷的根源
答：
1）测试策略：错误的测试范围，误解了测试目标，超越测试能力等。
2）过程、工具和方法：无效的需求收集过程，过时的风险管理过程，不适用的项目。
3）管理方法，没有估算规程，无效的变更控制过程等。
4）团队/人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气或动机不纯。
5）硬件：硬件配置不对，或者处理器导致算法精度丢失，内存溢出。
6）软件：软件设置不对，操作系统错误导致无法释放资源，工具软件错误、编译器错误、千年虫等问题。
7）工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。
63.说说缺陷的起源、来源、根源的关注度
答：
缺陷的起源、来源、根源，一般关注较多的是缺陷的来源（直接原因），在测试总结的时候，关注的缺陷的根源。
64.缺陷的严重程度和缺陷的优先级有什么关系？提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级
答：
1）
缺陷的严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷的优先级：缺陷的优先级指缺陷必须被修复的紧急程度。
1.二者之间没有任何直接的关系；
2.不要认为严重的缺陷，修复优先级就高；
3.如果碰到优先级和严重程度都高的缺陷，也只是偶然；
4.比如QQ的帮助按钮，会经常有闪退的现象，严重程度很高，但是修复优先级很低。再比如企业的logo错误，不影响任何功能，但是必须优先修复。
2）不能。
即我们工作的时候不能搞特殊，私人关系等。
65.讲讲缺陷的生命周期
答：
首先是发现缺陷，提交缺陷，确认缺陷，分配缺陷，修复缺陷，验证缺陷，如果缺陷仍存在问题就继续提交缺陷，直到缺陷被修复好，最后关闭缺陷。
66.针对你工作中的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）
答：
1）发现缺陷、提交缺陷：测试人员；
2）确认缺陷：一般由测试主管或者质量保证（OA）、产品经理进行确认；
3）分配缺陷：经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配，分配的对象可能是开发、也可能是UI，也可能是产品经理；
4）修复缺陷：开发人员；
5）验证缺陷：测试人员去验证缺陷有没有修复；
6）关闭缺陷：只能是测试人员进行，否则出了问题，测试人员一律不背锅。
67.说说缺陷识别的依据
答：
客观的依据：需求文档，设计文档，产品原型，测试用例；
主观的依据：同行业的类似成熟的软件，和开发人员沟通，跟有经验的测试人员沟通，参照同行业隐形需求进行识别。
68.说说缺陷报告的编写目的、编写准则和预期读者
答：
编写目的：
1）易于搜索软件测试报告的缺陷；
2）报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确；
3）软件开发人员希望获得缺陷的本质特征和复现步骤；
4）市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。
编写准则：
准确、清晰、简洁、完整、一致。
预期读者：
开发人员、质量管理人员、市场人员、运维人员…等很多人都会阅读缺陷报告，所以缺陷报告一定要用语直白、清晰、明了。
69.说说缺陷报告模板中有哪些内容
答：
1.缺陷编号：Bug_项目名称_模块名称_功能名称_000x
2.所属模块：一级模块名称/二级模块名称/三级模块名称（有利于修改的人员快速定位缺陷位置）
3.优先级：缺陷的修复紧急程度 P1>P2>P3>P4
4.严重程度：S1>S2>S3>S4
5.缺陷概述：一般用一句话来描述缺陷的基本情况（时间、地点、人物、事件）
6.缺陷描述：将缺陷的复现步骤、实际结果和预期结果列出来
7.提交人：是谁提交的就写谁的名字
8.备注：一般写产生该缺陷的特殊情况；如果没有特殊情况，将bug的截图作为备注信息
70.<缺陷描述>的准则
答：
1）单一准确
2）可以再现（大部分的缺陷可以再现，但类似于偶尔出现的闪退、崩溃这种缺陷，就无需做到）
3）完整统一
4）短小简练
5）特定条件
6）补充完善
7）不做评价（不对缺陷出现的严重程度和缺陷表现出来的效果进行主观臆断，不要调侃）
71.说说测试需求、测试用例和缺陷报告的关系。
答：
测试的基本流程：获取测试需求—编写测试计划—指定测试方案—设计和开发测试用例—执行测试—提交缺陷—测试分析和评审—测试总结—准备下一版本测试。
获取测试需求是测试工作的第一步，通过需求的分析，了解和掌握测试的方向和内容，例如：
1.分析出系统的模块和组织结构
2.分析出软件的基本功能和运行流程（业务分析，包括会有哪些角色要用）
3.识别出软件的主次功能
获取测试需求的过程中，测试人员就要有相应的分析成果，一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。
设定测试中的需求正向、反向和优先级
当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计，也就是每一个需求都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常重要，使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算说明。
如果需求覆盖度<100%，那一定说明测试的覆盖度不够。
测试中，最能体现测试人员的工作量的指标就是缺陷的数量和用例的数量。
1.设计的测试用例的总数 TC
2.执行的测试用例的总数 EC
3.未执行的测试用例的总数 NEC
4.执行通过的测试用例的总数 SC
5.执行失败的测试用例总数 FC
6.提交的缺陷的总数 BC
以上六个数据，他们要符合如下的数量关系：
1）TC≥EC
2）TC=EC+NEC
3）EC=SC+FC
4）BC≥FC（不可能边边角角都设计了测试用例，即可能在测试用例之外的存在缺陷，你可能运用了你的经验和直觉发现了设计之外的缺陷）
5）SC/EC 可以表现出系统的质量是否合格
6）EC/TC 可以表现出系统的需求是否得到满足
72.白盒测试中常见的覆盖。
答：
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖。
73.如果给你一个水杯，你会怎么对它做测试？（经典）
答：
如何对水杯进行测试？这位博主总结的好，看他的~
74.简单的说说禅道使用的大致流程
答：
禅道是一个软件项目管理工具，它的思想是基于SCRUM和极限编程。进入禅道，管理员要添加人员比如产品经理，项目经理，测试主管，测试人员，开发人员等。产品经理可以创建产品，添加需求；项目经理要创建项目（迭代），关联产品，设置项目团队，然后项目要关联需求，确定了项目的需求后，要对每个需求进行划分任务，然后可以将任务进行指派；研发团队可以查看指派给自己的任务，并完成任务；测试人员基于需求编写测试用例；任务完成后，研发团队可以创建版本，关联需求，将该版本提交，作为待测试版本；测试团队拿到测试版本后，关联测试用例，将测试用例指派给测试人员进行测试，测试人员执行测试用例，将失败的用例转bug并提交；研发团队要针对提交的bug进行修复并提交；测试人员要验证bug是否修复，如果修复了，就关闭bug，否则重新激活bug；在迭代到一个稳定，可执行的版本后，产品经理可对该版本进行发布工作。
75.什么是接口测试？接口测试的范围。
答：
1.接口测试是测试系统内部各个组件间接口，以及系统和外部系统之间的交互点；
2.测试的主要内容：1.检查数据的交换，2.传递和控制管理过程，3.系统间的相互逻辑依赖关系；
功能测试和非功能测试
…零碎知识点