自动化测试技术：软件测试模型和测试过程详解

一、软件测试模型

软件测试根据不同的测试对象、测试背景可采用不同的测试模型实施测试活动，针对测试人员，下面将通过对V模型、W模型、X模型、H模型及敏捷模型的分析，加强测试工程师在实际测试工作过程中，模型的选择及应用能力。

（一）V模型

RAD（Rap Application Development，快速应用开发）模型是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。

阶段步骤

V模型大体可以划分为以下几个不同的阶段步骤：需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

缺陷及解决

缺陷：V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决：当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

V测试模型适用开发周期较短的项目。在瀑布模型流行的年代，V测试模型发挥了很重要的作用，但随着业务规模的不断扩大，研发模型的不断优化改革，V模型已渐渐被淘汰。

（二）W模型

W模型，由Evolutif公司提出，相对于V模型，W模型增加了软件开发各阶段中同步进行的验证和确认活动。

如图所示，由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型强调

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试（这里针对设计文档，一般可以划分为需求设计文档、概要设计文档、详细设计文档和代码文档）， 也就是说，测试与开发是同步进行的。

从这个角度来说，一个完整合格的测试人员对软件各方面把握程度应该比开发人员更高，一个测试人员要能胜任软件研究任何一个岗位。

W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

局限性

在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。

优点

1. 测试的活动与软件开发同步进行

2. 测试的对象不仅仅是程序，还包括需求和设计

3. 尽早发现软件缺陷可降低软件开发的成本

W模型解决了V模型开发测试活动串行的问题，但仍然存在测试活动受开发活动的影响，并不能做到真正的测试活动与开发活动分离，互不影响。通过W模型，我们可以看到，当开展单元及集成测试活动时，单元、集成测试活动的测试对象仍由研发活动提供，滞后于研发活动。因为仅在开发人员完成单元、组件代码设计后，才能实施单元、集成测试或接口测试。

（三）H模型

相对于V模型和W模型，H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

优点

1. 开发的H模型揭示了软件测试除测试执行外，还有很多工作；

2. 软件测试完全独立，贯穿整个生命周期，且与其他流程并发进行；

3. 软件测试活动可以尽早准备、尽早执行，具有很强的灵活性；

4. 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行，同时也是可以被迭代的。

缺点

1. 管理型要求高：由于模型很灵活，必须要定义清晰的规则和管理制度，否则测试过程将非常难以管理和控制；

2. 技能要求高：H模型要求能够很好的定义每个迭代的规模，不能太大也不能太小；

3. 测试就绪点分析困难：测试很多时候，你并不知道测试准备到什么时候是合适的，就绪点在哪里，就绪点的标准是什么，这就对后续的测试执行的启动带来很大困难；

4. 对于整个项目组的人员要求非常高：在很好的规范制度下，大家都能高效的工作，否则容易混乱。例如：你分了一个小的迭代，但是因为人员技能不足，使得无法有效完成，那么整个项目就会受到很大的干扰。

（四）X模型

X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。

X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执 行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。

（五）敏捷测试模型

其实软件测试中并无敏捷测试模型，为了对应敏捷开发，才提出了敏捷测试的概念。

敏捷开发的最大特点是高度迭代，周期性强，能够及时、持续地响应需求的频繁变更反馈。敏捷测试即是不断修正被测对象的质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产过程安全、及时地发布最终产品。

敏捷测试工程师在高速迭代、沟通之上的敏捷开发团队中，需要关注需求变更、产品设计、源代码设计。通常情况下，需要全程参与敏捷开发团队的团队讨论评审活动，并参与决策制定等。在独立完成测试设计、测试执行、测试分析输出的同时，关注用户、有效沟通，从而协助敏捷流程推动产品的快速开发。

在传统开发模型下，一个测试版本生成周期可能为几个月，但在敏捷模型中，可能几周一个版本，甚至几天一个测试版本，因此敏捷团队中的测试工程师在技术技能、业务理解、产品设计等方面都需要熟练，否则很难快速高效地完成测试任务，给项目带来风险。

二、软件测试过程

一个完整的流程应该是一个闭合的环，从测试需求开始到测试总结结束。

1、需求阶段

测试人员在制订测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。主要包括以下两个活动：

阅读和理解需求：测试人员首先需要对业务进行深入学习，理解需求文档中的各项功能和目标，确保对产品有一个全面的认识。

参与需求评审：在需求评审会议中，测试人员与项目经理、开发人员和需求分析师共同讨论需求文档，确保需求的准确性和完整性。评审的目的是发现并解决潜在的问题，如描述不清、逻辑冲突或功能无法实现等，同时统一团队对需求的理解。

软件测试需求上设计测试用例的依据。制定详细的软件测试需求有助于保证测试的质量和进度。软件测试需求是衡量测试覆盖率的重要指标。主要目的：1.对软件测试要解决的问题进行详细的分析，弄清要求。2.找出测试点。

软件测试需求要经过采集、分析和评审过程其步骤如下

（1）根据软件开发需求说明书逐条列出软件开发需求，并判断其是否有可测试性。

（2）对步骤1 中列出的每一条开发需求，形成可测试的描述，针对这条开发需求确定需要进行测试的范围。

（3）对步骤2中形成的每一条测试范围，根据测试标准，用以判断测试成功和失败。

（4）对步骤3所确定的质量需求，分析测试执行时需要实施的测试类型，形成专业的测试需求。

（5）建立测试需求跟踪矩阵，并输入测试需求管理系统，对测试需求实施严格有效的管理。

2、测试计划

测试工作贯穿于整个软件开发生命周期，是一项庞大而复杂的工作，需要制订一个完整且详细的测试计划作为指导。测试计划是整个测试工作的导航图，但它并不是一成不变的，随着项目推进或需求变更，测试计划也会不断发生改变，因此测试计划的制订是随着项目发展不断调整、逐步完善的过程。

测试计划一般要做好以下工作安排。

确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。

制订测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型(如功能测试、性能测试)选定测试环境和测试方法(如人工测试、自动化测试)。

安排测试资源：通过衡量测试难度、时间、工作量等因素对测试资源进行合理安排，

包括人员分配、工具配置等。

安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。

预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制订应对策略。

3、设计阶段

测试需求评审通过、测试计划、方案制定好后，便可进行测试用例编写工作了，可根据详细需求文档、Xmind思维导图、产品原型图、研发详细设计文档进行用例编写，通常按照系统功能模块划分编写范围。

测试方法设计：根据需求文档和设计文档，设计具体的测试方法，如功能测试用例、接口测试用例、性能测试场景等。

测试用例编写：基于设计的方法，编写详细的测试用例，包括正常流程和异常流程，确保覆盖所有可能的场景。测试用例需要经过组内评审和会议室评审，以保证其有效性和完整性。

测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。测试用例常用的设计方法包括等价类划分法、边界值分析法、因果图与判定表法、正交实验设计法、逻辑覆盖法等。

测试用例设计的原则

（1）一个测试用例对应一个功能点，测试用例要容易阅读。并且测试用例的数据要正确。

（2）测试用例的执行粒越小，测试用例所覆盖的边界定义就会更加清晰。测试结果对产品问题的指向性越强。

（3）测试用例间的耦合度越低越好，耦合度越低，彼此之间的干扰也就越少。

（4）测试用例要从使用者的角度去编写，尽量使步骤清晰，具有可再现性。所谓'可再性'是指不同的人按照步骤多次执行，应该得到相同的结果。

（5）测试用例要有明确的预期结果，即测试执行结果的正确性是可判断的。

（6）测试用例要有代表性，尽量将具有相似功能测试用例抽象并归类，尽量做到用尽可能少的测试用例发现尽可能多的缺陷。

（7）测试用例的设计思路是先易后难的，确保正常情况下基本功能能够实现。

（8）尽量用成熟的测试用例设计方法指导设计，设计测试用例不能只凭主观或直观想法，而要以一定的设计方法为指导。

4、执行阶段

执行测试就是按照测试用例进行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。测试执行过程看似简单，只要按照测试用例完成测试工作即可，但实则并不如此。测试用例的数目非常多，测试人员需要完成所有测试用例的执行，每一个测试用例都可能会发现很多缺陷，测试人员要做好测试记录与跟踪，衡量缺陷的质量并编写缺陷报告。

当提交后的缺陷被开发人员修改之后，测试人员需要进行回归测试。如果系统对测试用例产生了缺陷免疫，测试人员则需要编写新的测试用例。在单元测试、集成测试、系统测试、验收测试各个阶段都要进行功能测试、性能测试等，这个工作量无疑是巨大的。除此之外，测试人员还需要对文档资料，如用户手册、安装手册、使用说明等进行测试。因此不要简单地认为执行测试就是按部就班地完成任务，可以说这个阶段是测试人员最重要的工作阶段。

搭建测试环境：准备和配置必要的硬件和软件资源，确保测试环境的稳定性和与生产环境的一致性。

执行冒烟测试：对软件的主要功能进行初步测试，确保关键路径可用，作为进一步测试的前提。

执行详细测试：根据测试用例进行系统测试，包括功能测试、接口测试、性能测试等。在测试过程中，发现的bug需要记录并提交到缺陷管理系统。

缺陷跟踪和管理：与开发团队紧密合作，跟踪bug的修复情况，并进行回归测试，确保每个bug得到妥善解决。

5、评估阶段

测试报告：对测试过程进行总结，包括测试时间、环境、用例执行情况、bug发现和修复情况等。

风险评估：分析测试过程中的潜在风险，如遗留bug、性能瓶颈等，并提出相应的解决方案或建议。

测试报告是对一个测试活动的总结，对项目测试过程进行归纳，对测试数据进行统计，对项目的测试质量进行客观评价。不同公司的测试报告模板虽不相同，但测试报告的编写要点都是一样的，一般都是先对软件进行简单介绍，然后说明这份报告是对该产品的测试过程进行总结，对测试质量进行评价。

一份完整的测试报告必须包含以下几个要点。

• 测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。

• 测试内容及执行情况：描述本次测试模块的版本（当前这个版本，包含哪些需求点）、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。（报告用例情况）

• 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因，给出规避措施等建议，同时还要记录残留缺陷与未解决问题。（从多个维度分析：bug等级分布，遗留bug分析，bug类型分布。模块bug分布，bug激活次数分析）

• 测试结论与建议: 从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论（是否达到发布标准，是否可发布），并给出建议。（从测试角度，对版本存在的问题，提出建议）

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。