测试与发布流程

测试与发布流程

做测试已经9年了，之前要么大公司已经有现有流程，要么就是小公司人少，大家都是默认流程往前推进。

现在这个职位，完全0-1，才有了这个第一次------整理测试和发布流程。

tips：预发环境因为很多公司没有（目前我在的公司也没有：）），所以流程图用浅色标注。

1. 目的

1.1. 结合公司的项目情况制定合理的软件测试流程，提高测试效率和产品质量。

1.2. 制定合理有效的软件发布流程，指导产品发布活动，有效控制产品发布过程，有效控制追踪产品版本。

2. 角色与职责

2.1. 运维人员：

2.1.1. 负责上架产品发布

2.1.2. 跟踪现场需要调测的异常包状态

2.2. 产品经理：

2.2.1. 产品需求设计

2.2.2. 审核产品发布并提出发布请求

2.3. 开发人员：

2.3.1. 实现和修改完善产品

2.3.2. 协助测试人员进行验收测试

2.4. 测试人员

2.4.1. 产品测试和bug追踪

2.4.2. 提出产品发布审核请求

3. 定义

3.1.1. 软件版本正式发布：通过软件测试人员测试验证并符合发布标准的软件版本发布过程,参考附件一流程。

3.1.2. 软件版本异常发布:通过软件测试人员测试验证,但测试结果不符合发布标准的软件版本发布过程,可采取软件版本异常发布流程。比如：客户使用现场缺陷修复或现场测试等紧急情况。参考附件二流程。

4. 测试与发布流程说明

详细请看上方流程图

5. 测试与发布流程

5.1. 需求评审

5.1.1. 参与人员：产品，设计，开发，测试

5.1.2. 目标：明确相关人员的职责，评估设计，开发，测试周期，制定项目计划

5.1.3. 评审期间，产品给出产品需求文档，设计从视觉、交互角度给出文档，开发人员从技术角度来分析实现方案，实现难易程度。测试人员从用户角度来给出产品逻辑上是否存在不合理的建议。

5.2. 测试计划（可选）

5.2.1. 参与人员：测试，产品

5.2.2. 目标：根据项目计划及开发人员工期安排，制定测试计划

5.2.3. 测试计划内容：测试范围与主要内容，时间要求和人员安排，测试分类与测试方法，测试环境，测试数据准备

5.3. 测试用例编写

5.3.1. 参与人员：测试

5.3.2. 目标：根据产品需求，设计足够覆盖率的测试用例

5.3.3. 工具：Excel

5.3.4. 用例文档管理：Confluence 附件

5.4. 测试用例评审

5.4.1. 参与人员：产品，开发，测试

5.4.2. 目标： 确认测试用例的准确和覆盖率，避免功能点遗漏，提供smoke test case给开发人员。

5.4.3. 评审方式：根据项目大小或项目时间，选择通过邮件发送评审，或者开评审会。

5.5. 开发人员自测

5.5.1. 参与人员：开发

5.5.2. 目标：自测通过后提交测试版本给测试人员。

5.5.3. 自测通过：需求文档的功能点全部实现，测试人员提供的smoke test通过

5.5.4. 自测失败：继续开发流程

5.6. 开发人员提测

5.6.1. 参与人员：开发

5.6.2. 目标：待测功能交付

5.6.3. 提交测试准备：新增模块在功能上是否达到设计要求（有哪些需求更改项），提供接口文档（接口测试），并且对可能影响的其他模块进行说明

5.7. 测试环境发布

5.7.1. 参与人员：开发人员

5.7.2. 目标：交付测试人员可测试环境

5.7.3. 发布要求：自测通过，开发负责人审核通过，并正式提出测试需求

5.8. 测试人员执行测试用例

5.8.1. 参与人员：测试

5.8.2. 目标：在计划的时间内，100%执行测试用例，尽可能多的发现bug

5.8.3. 测试数据的准备和测试工具的选择

5.8.4. 提供测试结论，测试通过提出产品上架发布请求，并对遗留问题进行说明

5.9. 缺陷管理

5.9.1. 参与人员：开发，测试

5.9.2. 目标：找出软件缺陷并及时修复

5.9.3. 缺陷管理流程

5.10. 产品上线评审

5.10.1. 参与人员：产品，开发，测试

5.10.2. 目标：产品经理对需求进行最后确认，测试人员针对测试环境的测试结果进行说明并且评估产品上线风险

5.10.3. 需求变更：任何需求变更需要提出需求变更请求，并由相关负责人审批？

5.11. 预发布环境发布

5.11.1. 参与人员：运维

5.11.2. 目标：发布预发布环境，提供稳定的测试环境

5.11.3. 发布要求：critical bug数量为0，high priority bug数量为0，medium priority bug数量不大于2，low priority bug数量不做约束

5.12. 预发布环境测试

5.12.1. 参与人员：测试

5.12.2. 测试范围：新需求全部功能点，和全部回归测试（根据实际情况可调整回归测试范围，比如仅测试会影响新功能点的测试用例。

5.13. 产品上线请求

5.13.1. 参与人员：测试

5.13.2. 目标：提出发布请求，并对测试环境的测试结果进行报告和说明

5.13.3. 发布要求：critical bug数量为0，high priority bug数量为0，medium priority bug数量不大于2，low priority bug数量不做约束。

5.14. 生产环境发布

5.14.1. 参与人员：运维

5.14.2. 目标：发布生产环境

5.15. 生产环境测试

5.15.1. 参与人员：测试

5.15.2. 测试范围：主要的新功能点和产品主流程

5.16. 发布结束

6. 异常发布流程

6.1. 生产环境缺陷提出

6.1.1. 发生时间：产品上线之后

6.1.2. 发生环境：生产环境提出产品缺陷

6.2. 缺陷评审

6.2.1. 参与人员：产品，开发，测试

6.2.2. 目的：评审缺陷的严重和紧急程度，决定是否需要开启异常发布流程

6.2.3. 缺陷等级评审：critical bug 必须修复，high priority bug 和medium priority bug征求产品和研发意见，low priority bug不走异常发布流程。

6.3. 发布请求

6.3.1. 参与人员：测试

6.3.2. 目标：提出发布请求，并对测试环境的测试结果进行报告和说明

6.4. 生产环境发布

6.4.1. 参与人员：运维

6.4.2. 目标：发布生产环境

6.5. 生产环境测试

6.5.1. 参与人员：测试

6.5.2. 测试范围：主要的新功能点和产品主流程

6.6. 发布结束

软件测试的方法一共有几种

1、从是否关心内部结构来看

（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。

（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。

（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。

2、从是否执行代码看

（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。

(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。

3、从开发过程级别看

（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。

(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。

（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

在系统测试中，对于具体的测试类型有：

（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。

（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。

（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。

（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。

（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。

（6）余量测试：对软件是否达到规格说明中要求的余量的测试。

（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，

（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）

（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。

（10）边界测试：对软件处在边界或端点情况下运行状态的测试。

（11）数据处理测试：对完成专门数据处理功能所进行的测试。

（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。

（13）容量测试：检验软件的能力最高能达到什么程度的测试。

（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。

（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。

（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。

（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。

（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。

4、从执行过程是否需要人工干预来看

（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输 入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。

（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）

5、从测试实施组织看

（1）开发测试：开发人员进行的测试

（2）用户测试：用户方进行的测试

（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性

6、从测试所处的环境看

（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试

（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告

扩展资料

软件测试的内容：

1 得到需求、功能设计、内部设计说书和其他必要的文档

2 得到预算和进度要求

3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )

4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制

5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试

6 确定对测试环境的要求 ( 硬件、软件、通信等 )

7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等

8 确定对测试的输入数据的要求

9 分配任务和任务负责人，以及所需的劳动力

10 设立大致的时间表、期限、和里程碑

11 确定输入环境的类别、边界值分析、错误类别

12 准备测试计划文件和对计划进行必要的回顾

13 准备白盒测试案例

14 对测试案例进行必要的回顾 / 调查 / 计划

15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据

16 得到并安装软件版本

17 进行测试

18 评估和报告结果

19 跟踪问题 / 错误，并解决它

20 如果有必要，重新进行测试

21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具

参考资料：百度百科-软件测试

软件测试「版本发布、发版质量、质量应急预案」流程（泳道图）

经常有同学问：

“ 如何确保发版质量 ？ ” ，

“ 版本上线后经常有各种问题怎么办 ？” ，

“ 团队配合也不错，也经常加班，为什么版本老是延期 ？ ”

“ 团队想规范流程，重新制定一份质量流程规范，怎么弄 ？ ”

。

还有很多各类问题，

基于此，老徐给各位提供一份，老徐实践多年，可行的《「版本发布、发版质量、质量应急预案」测试流程（泳道图）》。

比如，

1）团队名，老徐用 isTester 替代了。

2）一些角色名、部门名，直接用的 IT

3）这份文档，是可以拿来直接用的（当然，最好根据自己团队的实际情况，去做一些调整；完全100%照搬，难落地）

4）这是一个全的流程，涉及到「外包供应商的角色」，如果你们是完全自有团队，可把「IT & 供应商」合并。

流程图，

见链接 https://www.processon.com/view/link/611e6acd7d9c0834aa5f0903

注：这是在线脑图，图片太大，在线更清晰。

关于这份流程图，补充几个点：

2、还是一样的观点， 带着大脑去学习 ；任何内容，都不可照搬，参考这份，根据你公司的实际情况，做一些调整，基本上就可以直接用了。

IDO老徐

2021.08.19

End ，就这样。

注：这篇文章，期望能帮到每一位测试工程师、测试 Leader、技术 Leader ；文章自己收藏（转发给身边的测试 / 开发工程师们）**

什么软件发布的时候需要做知识产权登记测试？哪里去测试？

软件产品登记测试是指检测机构按照委托方提供的测试功能点，对其指定的软件产品进行功能性的检测和验证，确保这些功能都得以实现并能正常运行。
同时，软件产品登记测试的报告也是申请软件产品登记所必须的条件，对于审查方来说第三方检测机构出具的测试报告是具有较高的参考价值。
根据2009年3月颁布的中华人民共和国工业和信息化部令第9号《软件产品管理办法》的规定，软件产品实行登记和备案制度（第二章第七条），同时经登记和备案的国产软件产品可享受国务院办法的《鼓励软件产业和集成电路产业发展的若干政策》中规定的有关鼓励政策。
依据9号令第八条第（五）款和第十条第（五）款的规定，国产软件或进口软件在申请登记备案时必须提交软件检测机构出具的检测证明材料。

以上关于测试与发布流程的内容就介绍到这里，人生之路是漫长而多彩的，就像在地平线上的茫茫大海上航行一样。有时它会风平浪静；但有时它会惊涛骇浪，行驶艰难。但只要我们心中的灯塔继续存在，我们就可以继续沿着自己的路线航行。