软件测试_面试题

持续更新…

---

[软件测试工程师经典面试题](https://blog.csdn.net/qq_41625341/article/details/82941787)

---

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次，第三次输入正确
4. 密码输错3次，冻结银行卡
5. 选择存款服务
6. 选择转账服务
7. 选择修改密码服务
8. 取款机没有纸币了
9. 取款机没有信号了
10. 等…

场景设计：
场景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.系统间的相互逻辑依赖关系；

性能测试_面试题

1.什么是性能测试，性能测试分类

答：
1.
中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。
笼统地来说，性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各种性能指标进行测试。
2.性能测试分类
1）基准测试：先测一轮作为后面测试或者后面版本测试的基准（一般地，会把第一版第一轮的测试数据作为基准；不同版本做基准，需要进行评估，不能跨度太大）。
2）一般性能测试：验证软件在正常情况和系统条件下能够满足性能指标（基于用户行为情况和用户分布等信息，对系统是否能够达到预期服务能力进行验证）。
3）并发测试：测试多个用户同时访问同一应用，同一个模块或者数据记录时是否存在死锁或者其他问题，所以几乎所有的性能测试都会涉及到一些并发测试（通常并发操作都会加锁，死锁其实就是资源的争用）。
4）负载测试：确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。验证系统在一定压力下延长系统运行时间，直到系统性能出现“拐点”(跨过拐点，系统出现不稳定的情况，比如性能的下降)。
5）压力测试：验证系统在已经处于极限负载下或者某指标已经处于饱和状态下系统性能的表现（系统濒临崩溃，寻找系统极限值的过程），来获得系统能够提供的最大服务级别。
6）疲劳强度测试：对系统进行加压（可以是并发量，也可以是时间），测试系统出现疲劳时候的点（系统逐渐变慢的临界点。如果是时间，一般跑24h以上）。
7）稳定性测试：验证系统在连续运行的情况下，查看系统的各项性能指标——MTBF（错误发生的平均时间间隔），是否长时间运行会出现内存泄露等问题（一般跑72h以上）。
8）容量测试：预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
9）大数据量测试：主要针对对数据库有特殊要求的系统进行的测试，验证系统在使用大批量数据对系统产生压力或影响的情况下系统各种指标是否正常。9.1）实时大数据量：模拟用户工作时的实时大数据量，主要目的是测试用户较多或者某些业务产生较大数据量时，系统能否稳定地运行。9.2）极限状态下的测试：主要是测试系统使用一段时间即系统累积一定量的数据时，能否正常地运行业务。9.3）前面两种的结合：测试系统已经累积较大数据量时，一些实时产生较大数据量的模块能否稳定地工作。
10）配置测试：验证系统在不同的软件或硬件配置的情况下，找出系统各项资源的最优分配。
11）恢复性测试（也称作可维护性测试，失效恢复测试）：当软件运行故障时的恢复能力。失效恢复测试一般是对具有负载均衡的系统或者是具有备份的系统进行的，主要是为了测试当系统局部发生故障时，是否会对全局产生较大的影响，产生的影响是否在可以接受的范围内，以及用户是否能够继续使用系统（还要关注失效后，系统还能支持多少用户并发操作，以及出现这种情况，可以采用哪些应急方案来快速解决问题。具有主从备份的系统一般要做失效恢复性测试。如主库发生故障，从库自动切换为主库，主库恢复后，是保持两个主库，还是恢复一主一从等等）。
12）现网性能测试：在真实的环境下做性能测试（为了得出最真实的数据，这种类型的测试要注意一些问题对网络性能的影响，比如占用过多的带宽，影响其他业务，垃圾数据的清理等。一般做性能测试是在内网的环境下进行，·比如服务器系统相关的各种配置的测试，基本都是在局域网做，但没有办法评估网络环境的带宽等限制问题，在局域网测试可能没有问题，真实环境下就不一定，可能就会因为带宽网络的限制问题，导致用户无法访问系统，无法满足需求）。

2.在产品开发周期中，性能测试的开展阶段

答：
一般地，在产品开发周期中：
1.先做性能规划，功能测试通过之后，再做性能测试；
2.在技术选型的阶段做性能测试。

3.功能测试流程和性能测试流程对比

答：
1.功能测试流程：需求分析–测试计划–用例编写–测试执行–输出报告。
2.性能测试流程：需求分析–方案设计–测试计划–脚本编写–环境搭建–数据准备–测试执行–收集监控数据–分析调优–输出报告。

4.性能测试的需求分析需要考虑哪些东西？

答：
性能测试的重点与难点：需求分析、诊断和调优。
需求分析需要考虑：
1）产品规格：产品经理告知要做什么样的功能；
2）用户模型：用户常用功能，使用时间段，使用用户量等；
3）系统数据：基础数据和业务数据（因为性能测试需要大量的数据，如果数据量较少，那么与数据相关的 性能问题，就很难反应实际问题。造数据的原则：宁多勿少）；
4）系统架构：系统架构可以说是为软件系统提供一个结构、行为和属性的高级抽象过程（比如：浏览器–>web服务器（nginx）–>应用服务器（tomcat）–>缓存（redis）–>数据库（mysql））；
5）运维日志：进一步确认真实用户的数据和行为（一般系统在线上运行一段时间都会存有运维日志，从运维日志的角度，进一步了解用户数据和行为）；
6）市场计划：帮助我们考虑系统性能扩展性（比如双十一，一些需要大并发的场景）。
7）项目管理计划：帮助我们明确测试点的优先级（有些哪些需要测试，测试的时间安排等）。
8）产出需求分析文档。

5.性能测试相关术语、性能测试指标

答：
1）虚拟用户（Virtual User，简称vu）：在测试环境中，Loadrunner和一些性能测试工具在物理计算机上使用Vuser来“虚拟”实际用户的操作行为。
2）并发：强调“大量用户”的“同时性”操作，该操作要求对服务器（不是客户端）产生压力。
3）并发用户数：指的是在某一时刻同时进行了对服务器产生影响的操作的用户数量（并发用户数<在线用户数<系统用户数）。
4）响应时间：如果从用户的角度来说，响应的时间为：从请求发出到看到响应结果。这个响应时间的影响因素有很多，比如：用户的带宽，运营商，服务器，服务器的数据处理，返回的运营商，用户电脑的处理速度等。
5）请求响应时间：服务器收到用户请求到把响应内容发送出去的这段时间。
6）事务响应时间：处理请求对应事务的时间。
7）响应时间=网络传输请求的时间（浏览器到服务器）+服务器处理（一层或多层）时间（比如：nginx-tomcat-redis-mysql）+网络传输响应的时间（服务器到浏览器）+页面前端解析渲染时间。
8）思考时间：模拟真实用户操作而停顿的时间间隔。
9）TPS（Transaction Per Second，每秒事务数）：指每秒钟系统（服务器）能够处理的事务数量（评判系统的处理能力）；TPS=并发用户数/响应时间。
10）吞吐量：在单次业务中，客户端和服务器进行的数据交互总量，受服务器性能和网络性能的影响。吞吐量是衡量网络性能的实际指标，而带宽是理论指标。
11）吞吐率：吞吐量除以传输时间，衡量服务器性能和网络性能的重要指标之一，一般可以用“请求数/秒、页面数/秒、字节数/秒”等单位衡量（“字节数/秒”最常用）。
12）性能计数器：性能计数器是一系列用于描述各类型服务器或者操作系统性能的指标，在进行资源监控和系统瓶颈分析中起着重要的作用。

6.解释一下“理发店”模型和拐点模型

答：

1.“理发店”模型

假设

• 理发店共有理发师3名（系统资源，服务器）；
• 每位理发师理一个人的头发需要1h（处理时间）；
• 顾客到理发店理发，所能容忍的时间是（等待时间+剪发时间）3h（响应时间），即等待时间最多2h；
• 响应时间（等待时间+剪发时间）超过3h，顾客可能就会直接走人（不再请求或重新请求）。

---

场景

• 场景1：当理发店有2名顾客时，有2名理发师进行理发服务，这2名顾客均花费1h（存在资源浪费）。
  • 服务完2名顾客离开，需要1h；
  • 存在资源浪费（有一名理发师空闲）。
• 场景2：当理发店有3名顾客时，有3名理发师进行理发服务，这3名顾客均花费1h。
  • 服务完3名顾客离开，需要1h；
  • 3名顾客为最佳并发用户数（资源得到了充分利用）。
• 场景3：当理发店有4名顾客时，有3名理发师进行理发服务，剩余1名顾客需要等待1h才能够进行理发。
  • 服务完4名顾客离开，需要2h。
  • 超过3名顾客，其中3个人需1h，一人需2h（等待1h+理发1h），这说明没有绝对的并发。
• 场景4：当理发店有7名顾客时，有3名理发师进行理发服务，剩余3名顾客需要等待1h、1名顾客需要等待2h才能理发。
  • 服务完7名顾客离开，需要3h。
• 场景5：当理发店有9名顾客时，有3名理发师进行理发服务，剩余3名顾客需要等待1h、3名顾客需要等待2h才能理发。
  • 服务完9名顾客离开，需要3h。
  • 响应时间3h为最大忍耐限度，响应时间最低要求；
  • 9名顾客为最大并发用户数（最大边界值），超过会出现顾客离开的情况。
• 场景6：当理发店有10名顾客时，有3名理发师进行理发服务，剩余3名顾客需要等待1h、3名顾客需要等待2h才能理发、1名顾客需要等待3h。
  • 1名顾客超过忍受时间极限，离开理发店，放弃理发；
  • 为保证用户的正常访问，超过最大并发用户数，系统可提醒拒绝访问或超时。

2.拐点模型

• 响应时间
  • 随压力增大，响应时间基本保持不变，曲线趋于平稳，图像几乎呈平滑的直线（0 ~ 最佳并发用户数）；
  • 超过最佳并发用户数，随着压力增大，曲线呈上升趋势，响应时间开始明显增加（最佳并发用户数 ~ 最大并发用户数）；
  • 超过最大并发用户数，随着压力增大，曲线上升趋势变得陡峭，响应时间成倍增长（最大并发用户数 ~ ∞）。
• 吞吐量
  • 随压力增大，吞吐量逐渐增大，曲线呈上升趋势（0 ~ 最佳并发用户数）；
  • 超过最佳并发用户数，吞吐量继续增大，直到到达最大吞吐量（曲线最高点，此时服务器处理能力达到瓶颈），然后吞吐量开始下降（最佳并发用户数 ~ 最大并发用户数）；
  • 超过最大并发用户数，随着压力增大，曲线呈断崖式下降，服务器濒临崩溃。
• 资源利用率
  • 随压力增大，资源利用率逐渐增大，曲线呈上升趋势（0 ~ 最佳并发用户数）；
  • 超过最佳并发用户数，随着压力增大，曲线趋于平稳，图像几乎呈平滑的直线，资源利用率达到饱和状态（ 最佳并发用户数 ~ ∞）。

模型与用户联系

• 系统的负载=最佳并发用户数
  • 系统的整体效率最高，没有资源浪费，用户不需要等待。
• 最佳并发用户数<系统负载<最大并发用户数
  • 系统可以继续正常工作，但由于用户的等待时间延长，满意度开始下降。
• 系统负载>最大并发用户数
  • 导致有些用户无法忍受等待时间而放弃访问;
  • 随着并发人数的继续增加，系统展现疲态，工作效率降低，响应时长成倍增加。

综上，对于一个系统：

• 系统平均负载<系统最佳并发用户数
  • 因为如果[系统平均负载>最佳并发用户数]，长此以往，系统风评下降。
  • 扩展：在做系统的可靠性或稳定性测试的时候，要保持[系统平均负载≤最佳并发用户数]。
• 系统需要承受的峰值负载<系统最大并发用户数
• 系统对用户请求的响应速度，就决定着用户对系统性能的评价。
• “好的性能”意味着更大的最佳并发用户数和最大并发用户数。

性能瓶颈的测试方法

答：

性能测试的准入准出条件

答：

实际工作中性能测试的流程

答：

前端性能测试的概念、工具、诊断与分析

答：

事务特性和隔离级别，如果不考虑事务的隔离性可能会带来什么后果？

答：
1.事务的特性：原子性，一致性，持久性，隔离性。
1）原子性（Atomicity）：原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生（一组操作不能分开）；
2）一致性（Consistency）：事务前后数据的完整性必须保持一致；
3）持久性（Durability）：持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响；
4）隔离性（Isolation）：指多个用户并发操作数据库时，一个用户的事务不能被其他用户的事务所干扰，多个并发事务之间数据要相互隔离（事务之间互不干扰）。
2.事务的隔离级别：一级-读未提交（read uncommitted）、二级-读已提交（read committed）、三级-可重复读（repeatable read）、四级-串行化（serializable）。

级别	名字	隔离级别	脏读	不可重复读	幻读	数据库默认隔离级别
1	读未提交	read uncommitted	是	是	是
2	读已提交	read committed	否	是	是	Oracle
3	可重复读	repeatable read	否	否	是	MySQL
4	串行化	serializable	否	否	否

3.不考虑事务隔离级可能带来的后果：比如并发操作，多个用户同时访问同一个数据，可能会引发并发访问的问题。

并发访问的问题	含义
脏读	一个事务读取到了另一个事务中尚未提交的数据。
不可重复读	一个事务中两次读取的数据内容不一致，要求的时一个事务中多次读取时数据是一致的（事务update时引发的问题）。
幻读	一个事务中两次读取的数据的数量不一致，要求在一个事务多次读取的数据的数量是一致的（事务insert或delete时引发的问题）。

功能测试和非功能测试

…零碎知识点

软件测试-面试题（基础+性能）相关推荐

1. 软件测试面试八股文——基础篇

   大家好 今天给大家分享软件测试面试题基础篇,看看大家能答对几题 1.软件测试方法有哪些分类?各自有什么特点?设计测试用例的主要方法有哪些? 白盒: 测试人员利用程序内部的逻辑结构及相关信息,设计或选择 ...

2. 2021秋季“金九银十”跳槽必备：软件测试面试题（附带答案）

   软件测试面试题(带答案) 1. 请自我介绍一下(需简单清楚地表述自己的基本情况,在这过程中要展现出自信,对工作有激情,上进,好学) 面试官您好,我叫###,今年26岁,来自江西九江,就读专业是电子商务 ...

3. 万人总结的软件测试面试简历及软件测试面试题

   一.前言:浅谈面试 面试是我们进入一个公司的门槛,通过了面试才能进入公司,你的面试结果和你的薪资是息息相关的.那如何才能顺利的通过面试,得到公司的认可呢?面试软件测试要注意哪些问题呢?下面和笔者一起来 ...

4. 史上最全的软件测试面试题

   你们以前测试的流程是怎样的 <答:测试计划-测试用例设计-测试执行-测试分析报告> 为什么选择测试这行 <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,甚 ...

5. 最全软件测试面试题(经典)

   最全软件测试面试题 在当今竞争激烈的软件测试职场中,想要获取一份满意的offer,就要在面试前做足充分准备,不断挖掘用人单位岗位需求,才能做到"知己知彼,百战不殆." 避免面试过程 ...

6. 2022金九银十最全的软件测试面试题，能不能找到合适工作就看它了

   闲话少述,直接上正题 PS:前面是目录题目,后面是完整解题思路跟答案 目录 一.面试基础题 简述测试流程: 什么是软件测试?软件测试的目的与原则 问:软件生存周期及其模型是什么? 什么是软件质量? 自 ...

7. 2022最新200道软件测试面试题

   2022最新200道软件测试面试题 一.自我介绍 二.项目 三.测试基础 四,接口自动化测试 四,数据库方面 五.python自动化:代码熟悉程度 六,测试用例 一.自我介绍 二.项目 一般都是问最近 ...

8. 软件测试面试题大盘点，了解了这些你还怕啥，啥都不怕，面试官说就你了。

   知己知彼才能百战不怠,每一次面试也是一场仗,这仗打的漂亮不漂亮和你面试回答有很大的关联,这几天一菲私下整理了很多软件测试面试题,今天就给大家梳理一下,不要太感动! 1.你的测试职业发展是什么? 测试经 ...

9. 128道软件测试面试题，总结目前互联网公司最常问的面试题

   以下是软件测试相关的面试题及答案,欢迎大家参考! 1.你的测试职业发展是什么? 测试经验越多,测试能力越高.所以我的职业发展是需要时间积累的,一步步向着高级测试工程师奔去.而且我也有初步的职业规划,前 ...

10. 2021软件测试面试题汇总【备战金九银十】内容较长建议收藏

    一.面试基础题 简述测试流程: 1.阅读相关技术文档(如产品PRD.UI设计.产品流程图等). 2.参加需求评审会议. 3.根据最终确定的需求文档编写测试计划. 4.编写测试用例(等价类划分法.边界值 ...

最新文章

1. easyui 去掉按钮 虚线框
2. 前端开发中Cookie那些事儿
3. [HNOI2016]最小公倍数
4. jatoolsprinter web打印控件直接打印不弹出
5. JBuilder中光标错位的解决办法
6. #.NET分别以GET和POST方式抓取远程页面
7. Base64编码 - Java加密与安全
8. EtherCAT有哪些主流开源代码？它们的优点是什么？
9. 利用数据库来填充UltraWebTree
10. 数据分析实战之自如房租分析
11. 离散数学习题2.6：王教授是哪里人？
12. 计算机网络 校园网规划,校园网络规划与设计方案
13. python获取扫描枪数据线_扫描枪常见接口数据线的连接方法
14. Java项目：ssm在线答题系统
15. 计算机辅助翻译实训心得,计算机辅助翻译实训报告格式.doc
16. GROMACS Tutorial 3-Umbrella Sampling
17. Android ShapeableImageView使用详解，告别shape、三方库
18. 区块链如何加快智慧城市建设？
19. 华大单片机移植RTThread操作系统
20. hosts文件修改之后立刻刷新

热门文章

1. 程序员在线写诗《寒江雪》
2. JNCIS-SP学习指南卷1 第一章：协议无关的路由
3. Altium Designer 18 生成网络表
4. 关于ADL的查找顺序
5. java页面置换_页面置换算法java
6. 国际服登陆显示服务器维护中,国际服显示服务器在维护中怎么办 教你一招解决服务器维护中什么意思...
7. uni-App打包ios后白屏
8. bzoj4816[SDOI2017]数字表格
9. kubeadm部署1.11.1的k8s集群
10. 2023-2028中国稻谷行业市场 国稻种芯：未来趋势预测报告