身为测试人“我“不再背锅，完整一套软件测试流程汇总...

news2024/11/18 6:16:02

目录：导读

- 前言
- 一、Python编程入门到精通
- 二、接口自动化项目实战
- 三、Web自动化项目实战
- 四、App自动化项目实战
- 五、一线大厂简历
- 六、测试开发DevOps体系
- 七、常用自动化测试工具
- 八、JMeter性能测试
- 九、总结（尾部小惊喜）

前言

关于测试流程，100家公司可能有100套测试流程，但是基本上都是大同小异，完全可以将测试流程形成一套可复用的SOP。

测试流程

需求分析

产品经理根据用户需求，梳理出需求文档，文档内容包括用户背景、用户需求、产品方案、需求原型、UI设计图（UI设计师填写）、技术方案（开发经理填写）、接口文档（开发人员填写）等信息。

我们需要提前阅读相关文档，深刻理解需求，对于有疑问的点提前进行标注，以便于在之后的需求评审会议上抛出疑问点。

阅读需求文档的时候，除了关注功能要求之外，还需要关注用户背景，站在用户的角度思考问题，以判断需求是否真正符合用户需求，避免交付到用户手上时发现不是用户想要的效果，还需要关注数据类型、接口定义、性能要求、安全性等，根据具体业务进行评估即可，同时还需要考虑一些隐性需求。

需求评审

产品经理给到需求文档后，会召集一个需求评审会议，参加评审的一般有产品经理、开发人员、测试leader或对应需求的测试人员。

在需求评审时不仅要了解需求，还要评估需求的质量，分析需求的完整性以及合理性，及时发现需求和设计中的问题，抛出疑问给产品经理，并得到相应的解决。

思考需求中的测试点、测试场景等，便于之后测试用例的设计和编写。

测试计划

需求评审完成之后，大家都没什么问题了，测试Leader会给出测试计划，测试计划主要叙述了预定的测试活动范围（哪些模块）、测试人员、测试资源（软件、硬件）、进度安排（预计提测时间、测试用例所需工作日、一轮测试所需时间、二轮测试所需时间、预计测试完成时间）以及风险时间（提测质量低或其他因素引起测试时间增加）等。

测试用例设计

测试人员根据需求文档和原型图等进行测试用例的设计和编写，用例格式有很多种，比如：Excel、XMind、Testlink等。有的要求完整的测试用例，有的只需要列出测试点即可，根据公司实际要求进行即可。

测试用例评审

测试用例编写完成之后，会进行用例的评审，主要是检查里面有没有什么问题，或者跟需求文档有误的点，以及是否有未考虑到的测试点。

整个到这个阶段，开发人员也差不多开发完成了。

开发自测

让开发加强单元测试，测试人员通过提供测试用例或自动化测试脚本的方式给开发，让开发在设计时考虑更全面，同时方便开发自测，有助于提高产品质量，避免在收到提测包时冒烟测试主流程都没通过，导致测试效率低下。

提测

开发自测完成后正式提测，由开发人员将代码推到相应的Git分支。

测试环境部署

测试环境部署可能是运维人员、开发人员、或测试人员。

操作系统一般是Linux或Windows；用到的一些容器技术。
例如：Docker、Kubernetes；数据库可能是MySQL、SqlServer、Oracle、人大金仓数据库、达梦数据库、神通数据库、Redis缓存等，其中可能还有用到一些中间件，例如：Web中间件Nginx、消息队列MQ、Kafka等。

不过现在很多公司都有一套持续集成和持续部署平台，只需开发人员将代码提交到相应的分支，就能触发其自动部署更新。

冒烟测试

测试环境部署完成之后，需要先进行冒烟测试。

冒烟测试就是针对每次版本或每次需求变更之后，在正式测试之前，对产品或系统的一次简单验证性测试。

验证产品或系统的基本功能、主流程是否正常。可以将冒烟测试理解为是在执行正式测试之前的“预测试”，目的是确认软件的基本功能正常，可以进行后续的测试工作。

如果这个版本的冒烟测试都没通过，后面就不用继续测试了，直接打回给开发人员，待冒烟能通过后再提测。

需关注的点：
系统的基本功能可以正常使用，避免新功能导致系统原本功能无法使用
本次迭代需求的主流程可以跑通。

前面开发自测是目的也是为了更快地通过冒烟测试，有了开发自测，提测的质量会大大提高，原本可能需要花费一天时间冒烟的功能很快就能通过。

执行测试

按照之前编写的测试用例进行测试，测试过程中可能会发现之前遗漏的场景，这时需要补充完善测试点。还可能发现一些实际效果与产品原型不一致的地方，这时就需要跟开发、产品等人员进行沟通。

提交Bug并跟踪

测试过程中发现软件的缺陷，提交到相应的缺陷管理平台并指派给对应的开发人员，例如：Jira、禅道等。