[开发测试] 软件测试

文章目录

- 软件测试_面试题

1. 软件测试都要测试什么？

2. 软件缺陷的定义？

答：
笼统的回答说是：所有不满足需求或超出需求的都是缺陷，没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷。
比较专业的回答：1.软件未实现产品说明书要求的功能 2.软件出现了产品说明书指明不应该出现的功能 3.软件实现了产品说明书未提到的功能 4.软件未实现产品说明书虽未提及但应该实现的功能。 5.软件难以理解、不易使用、运行缓慢或者（从测试的角度来看）最终用户会认为不好。

3. 软件测试的定义？

答：
1.正向测试是确认产品能够正常工作，然后去评价一个程序或系统的特性或者能力，并确定它是否能够达到预期效果，软件测试就是以此为目的的任何行为。
2. 反向测试是为了发现错误而执行一个程序或系统的过程。
3. IEEE定义的软件测试：
在规定条件下运行系统或构件的过程：观察并记录结果，并对系统或构件的某些方面给出评价。
分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性。
4. 广义的软件测试：对软件形成过程中的所有工作产品（包括程序以及文档）进而不仅仅是对程序的运行进行测试。

4. 解释一下确认和验证？

答：
确认：通过检查和提供客观证据来证实特定目的的功能或者应用是否已经实现。
验证：通过检查和提供客观证据来证实指定的需求是否满足。

5. 软件测试的目的是什么？

答：
1.以最少的人力，物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。
2.同时利用测试过程中得到的测试数据和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。
3.采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量。

6. 软件测试和软件调试区别？

答：
1.在主体，目标，方法和思路上有所不同。
2.测试是从已知条件开始，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始，结束的过程可能不可预计。
3.测试可以计划，可以预先指定测试用例和过程，工作进度可以度量；描述调试的过程或持续时间比较困难。
4.测试的对象包括软件开发过程中的文档，数据以及代码；调试的对象一般来说只是代码。

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模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

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（无效）

测试用例设计方法你会怎么用？
答：
对于选择测试数据：等价类划分法、边界值分析法
对于测试步骤设计：因果图法、判定表法、场景法、正交试验法、状态迁徙图法（功能图法）
其他测试用例设计方法：测试大纲法、探索性测试、猴子测试（随意性测试）

缺陷的严重程度和缺陷的优先级有什么关系？提交缺陷时能不能夸大或降低缺陷的严重程度或者优先级
答：
1）
缺陷的严重程度：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷的优先级：缺陷的优先级指缺陷必须被修复的紧急程度。
1.二者之间没有任何直接的关系；
2.不要认为严重的缺陷，修复优先级就高；
3.如果碰到优先级和严重程度都高的缺陷，也只是偶然；
4.比如QQ的帮助按钮，会经常有闪退的现象，严重程度很高，但是修复优先级很低。再比如企业的logo错误，不影响任何功能，但是必须优先修复。
2）不能。
即我们工作的时候不能搞特殊，私人关系等。

针对你工作中的一个bug，说说这个bug的处理过程（缺陷的生命周期中，每一个环节由谁做什么）
答：

说说测试需求、测试用例和缺陷报告的关系。
答：
测试的基本流程：获取测试需求—编写测试计划—指定测试方案—设计和开发测试用例—执行测试—提交缺陷—测试分析和评审—测试总结—准备下一版本测试。
获取测试需求是测试工作的第一步，通过需求的分析，了解和掌握测试的方向和内容，例如：
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 可以表现出系统的需求是否得到满足