您现在的位置是：首页 >技术杂谈 >2023年最牛最规范的软件测试的标准操作流程，（大厂内部测试流程规范文档）网站首页技术杂谈

前言：

软件测试作为软件开发过程中不可或缺的环节，其标准化操作流程对于企业的产品质量和竞争力具有至关重要的作用。然而，在实际工作中，由于各个企业的文化背景、组织形式、产品类型等因素的不同，标准化的测试流程也存在差异，这给软件测试人员在不同企业间的工作转换带来了一定的难度。本篇文章提供了全网最牛最规范的软件测试标准操作流程，其中包括多家大厂内部测试流程规范文档的汇总和整理。这些流程规范文档涵盖了软件测试领域的各个方面，从测试计划到用例编写再到缺陷管理和版本迭代等不同阶段，都提供了详尽清晰的操作指南和工具支持。读者可以根据自身所处的企业或项目特点进行选择和参考，并结合自身经验和能力，打造出适合自己公司的标准化测试流程。

 

软件测试操作流程

1、制定测试计划

首先要明确的一点是，测试计划任务一般是由管理层完成，旨在对整个项目做统筹规划、资源配备等。一般来讲，软件测试计划设计有五大板块，分别是目标设计、总体概述（项目背景和项目范围）、测试计划（测试资源需求、组织形式、测试对象、需求跟踪、测试通过/失败标准、测试挂起/恢复条件、测试风险及防范、测试任务安排）、应交付的测试工作产品以及资源分配。

2、测试需求分析

然后我们要清楚的是，我们做需求分析，文档的来源是哪里，一份标准的需求文档到底包含哪些内容，我们该如何分析。标准需求文档需要包含的内容信息有，版本信息、文档说明、背景/产品简介、产品结构、详细功能说明、非功能需求、项目规划、附录。做需求分析的时候，切忌用主观感受解释为什么要做这个需求，这类解释是苍白无力的，有时间不如去做个用户访谈，只有全局了解用户需求，才能做出为人所用的产品。

3、测试用例设计与编写

按照软件测试的策略划分，有黑白灰盒测试，不同的测试策略我们使用的设计方法也不同。比如，黑盒测试侧重于功能层面的正确性和完善度，本质上对最终的输出和展现的测试，常用方法如等价类、边界值、判定表等。白盒测试着重于代码的测试，测试设计方法就侧重于代码层面，比如代码检查法、逻辑覆盖法等。

4、测试用例评审

用例评审旨在将测试人员编写好的测试用例进行评估审核，由团队共同参与协作完成的事，其中包括测试团队、测试领导、产品方，甚至开发团队。通过用例评审，校验出用例的合理性、有效性、可实施性、是否遗漏或冗余等。只有用例评审通过后，才能展开后续的测试活动。

看完了软件测试的标准操作流程，想必大家对于软件测试这一岗位的工作内容，也有了更加充分的了解。当然，想要真正掌握软件测试的相关技能，还需要大家更加深入的仔细学习才行。另外，只有自己亲身去实践软件测试的这些操作流程，我们才能更好的的理解并掌握软件测试技能。

前言：测试的过程并不是固定的，要灵活的变化

其实测试的过程并不是固定的，它只是一种规范，也可以把它当作一种指导。但是真实的产品测试和项目测试中，一定是要灵活运用的，甚至是在不断的根据实际情况变化。我在其他平台、app上讨论软件测试时，经常提到：项目测试和 产品测试一定是不一样的。

产品测试一定有非常完整的发版计划，有充足的的时间，有充足的资源进行协调，即使因为一些特殊的原因未能按时完成发版计划，也可以进行延期。所以产品测试都会尽量的去进行完成的全级别测试。

项目测试一般时间都非常紧，资源有限，发生意外的情况很多，任务时间都是被极度压缩。到目前为止我经历过大大小小几十个项目，没有一个是能按计划时间充足的上线。所以项目测试一般会大量的精简测试过程，甚至为了按时上线做出一些牺牲，牺牲掉一些不重要的功能，来优先保证 重点功能、常用功能。

　一、文档评审

首先是需求文档

在系统开始开发之前，产品经理会根据收集到的用户意见和最终方案编写需求文档，编写完成后，要进行需求文档评审；说是评审，实际上主要是需求讲解。给开发们讲解业务知识、我们要做什么东西、为什么这么做、要做成什么样子。从这个环节开始，测试人员就应该介入进来。

因为需求文档是测试人员测试的唯一标准！

将来做测试的时候，如果开发做出来的东西和需求文档里写的、画的不一样，都属于BUG！如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！所以，严格来说，测试人员在测试时只认文档不认人。可能有人会说，那这样测试人员就没必要参加评审了，直接等文档就行。

测试人员参加需求文档的评审的必要性：

1.测试人员也需要了解和学习相关的业务知识。

2.测试人员需要知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。

3.测试人员可以凭借经验对需求文档中的部分设计提出不同的意见。

4.测试人员可以凭借经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。

然后是开发文档

需求文档定型之后，开发经理会根据需求文档来编写开发文档。

开发文档的内容大概包括：开发模型、代码架构、代码规范、接口规范、数据库设计…

为什么测试要参加开发文档的评审？其实主要是去听测试人员需要了解系统的基本架构和实现原理，方便分析问题原因：

· 测试人员需要了解数据库表结构，对后续的测试很有必要。

· 测试人员可以提出一些规范性的要求，便于后面的测试。（比如要求前端人员尽量给所有前端组件加上id或name属性，方便自动化测试时定位元素）。

· 测试人员可以发现代码中缺少对某些异常场景的逻辑判断。

最后是测试计划

测试计划是测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。

测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表（流程、功能、接口）、测试资源的成本（人/天）等等。

测试计划是测试人员的工作守则和规范。

但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。

所以测试报告中需要写明与测试计划产生偏差的原因，并计算变差量，分析偏差的风险。

最终的测试过程和测试结果还是以 测试报告 为准。

二、单元测试（又称组件测试 component testing）

单元测试其实在平时比较少做，并不是因为它不重要，因为单元测试就是代码级别的测试。组件测试（也称为单元或模块测试）关注在可单独测试的组件。组件测试的目标包括：

1.降低风险

2.验证组件的功能和 非功能行为是否符合设计和规定

3.建立对组件质量的信心

4.发现组件中的缺陷

5.防止缺陷遗漏到更高的测试级别

简单的举个例子，现在开发做了一个新增的方法。

单元测试就是要写一个测试类或测试方法，调用开发的新增方法（新增肯定还要传值），并且在调用过程中模拟一些异常情况或者传输错误的值。所以单元测试一般由开发人员来完成，测试人员也可以去做，但是首先测试人员需要有一定的编码能力并搭建开发环境，其次测试人员需要去理解和分析开发的相关代码，甚至是要了解和学习相关架构。

现在成熟的开发框架已经自带的很多测试的组件和工具，以Springboot为例，可以直接导入测试依赖包。

<dependency>
　　    <groupId>org.springframework.boot</groupId>
　　    <artifactId>spring-boot-starter-test</artifactId>
　　    <scope>test</scope>
　　</dependency>

 

@RunWith(SpringRunner.class)
　　@SpringBootTest
　　public class TestImpl2Test {
　　@Autowired
　　@Qualifier(“testImpl2”)
　　ITestServer iTestServer;
　　@Test
　　public void test(){
　　iTestServer.showClassName();
　　}
　　}

综上所述，由开发人员来进行单元测试，要更加便捷和高效，更节约成本，几乎是举手之劳。而且能培养开发自测的良好习惯，关注代码质量的重要性。

三、敏捷测试(Agile testing)（可选）

在开发人员进行开发的这个阶段，测试人员无法对产品直接进行测试，工作任务较轻可以安排测试人员进行测试用例的编写。

对于一些紧急的项目，可以引进敏捷测试。敏捷测试是最近几年比较流行的测试方法，也拥有了众多的拥护者。还引出了一个测试思想——测试驱动开发（TDD ）这个概念有时间我单拎出来写。

敏捷测试的最大特点是高频率的快速迭代，几乎是一天一个迭代版本，甚至是一天多个版本。

敏捷测试是遵循敏捷宣言的一种测试实践：

1.强调从客户的角度，即从使用系统的用户角度，来测试系统。

2.重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

3.建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

这种高频率的迭代测试，可以极大地提升产品成型的速度，bug能在最短时间内被处理。

这种测试非常考验测试人员的抗压、责任心、领导力和沟通协调能力。

但是敏捷测试也有很多的缺点，在这里我只谈自己的感受，如果有不对的地方可以留言和我讨论：

测试人员工作压力大，休息时间少，几乎没有喘息的时间。

不同版本的bug管理比较混乱，验证起来需要梳理清楚，最好是借助专业的管理工具。

bug反复性高，可能在短时间内甚至不会出现bug逐步下降的正常趋势，而是产生较大的波动。

开发无法按照bug等级来确定工作优先级，因为可能在改一个中等bug，突然来了严重bug，也得等上一个bug改完的。

需求改动频繁，可能昨天做的功能或者做一半的功能突然就舍弃掉了。所以我们正常的测试中一般不会去做敏捷测试，但是有些公司比较推崇。

四、集成测试（integration testing）、系统测试（system testing）

集成测试的重点就是测试各模块的接口，也就是组件或系统之间的交互。

集成测试侧重于集成测试的目标包括：

1.减少风险

2.验证接口的功能和非功能行为是否符合设计和规定

3.建立对接口质量的信心

4.发现缺陷（ 可能存在于接口本身，也可能存在于组件或系统内部

5.防止缺陷遗漏到更高的测试级别

与组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更

也不会破坏已有的接口、组件或系统 。

系统测试侧重于整个系统或产品的行为和能力，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。

系统测试的目标包括：

1.减少风险。

2.验证系统的功能和非功能行为是否按照设计和指定的要求进行验证系统的功能和非功能行为是否按照设计和指定的要求进行。

3.确认已完成系统成且系统按预期工作确认已完成系统成且系统按预期工作。

4.建立对整个系统质量的信心建立对整个系统质量的信心。

5.发现缺陷发现缺陷。

6.防止缺陷遗漏到更高的测试级别或生产防止缺陷遗漏到更高的测试级别或生产。一般情况下，系统测试的测试环境应该与集成测试的相同。

我为什么把集成测试和系统测试放在一起，因为我们在做测试的时候，经常是集成测试和系统测试同时进行。

集成测试意味着开发已经完成所有模块的开发，并且对产品有了一定的信心。

所以我们通常是直接进行集成和系统测试，也就是全用例、全流程、全功能、全接口的测试。测试环境由测试人员进行搭建，尽量与生产环境一致。

测试期间测试环境不允许开发人员访问，直到一轮测试结束。

一轮结束后会将测试环境包括数据库移交给开发，用来复现相关问题，并查找问题原因。开发提交新一轮测试后，测试人员重新搭建环境进行测试。

五、验收测试（acceptance testing）

验收测试通常侧重于整个系统或产品的行为和功能。

验收测试通常是由客户、业务用户、产品负责人 或系统操作员负责，也可能涉及其他利益相关方 。

验收测试的目标包括：

1.建立对整个系统质量的信心

2.确认系统 是否完整 且系统将按预期工作

3.验证系统的功能和非功能行为 符合规范

六、其他（确认测试、回归测试）

确认测试：修复缺陷后， 应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例 。为了覆盖修复缺陷所 需 的变化， 也可以使用新的测试来测试软件。至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤。

确认测试的目的是确认是否已成功修复原来的缺陷。

回归测试：部分代码所做的变更， 无论是修复代码，还是其他类型的更改，都可能会意外地 影响到除更改代码外的其他部分代码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。变更也可能包括环境的变化 ，例如操作系统或数据库管理系统的新版本。这种意外的副作用被称为回归。

回归测试的目的是运行测试来检测这些意外的副作用。

如果对你有帮助的话，点个赞收个藏，给作者一个鼓励，也方便你下次能够快速查找，感谢。

如果你想获取该文章配套的视频视频教程以及练手的接口。请狠狠点击下方链接，

并把所需的资料的文章链接发给我即可领取

如果你想获取简历模板+面试技术宝典+求职视频+上千份测试真题，也请狠狠点击下方链接，

并把所需的资料的文章链接发给我即可领取