20230616_产品团队共创（关于产品质量保障）

文档目的旨在促进开发内部自测，测试及时总结质量，上线后引导团队及时总结。

一、To测试

1. 需求评审后：
   测试输出用例，安排测试用例评审，和产品，开发达成功能验证一致，会后及时更新用例；
2. 产品每轮提测：
   在每轮测试都要严格覆盖全测试面，保证在一轮中发现尽可能多的问题；
   每轮及时输出bug，bug需要登记规范，指到具体的前端，后端，指定相应的bug级别（级别需要和开发一起定下），每轮及时记录情况和总结；
3. 版本上线后：
   输出产品总体测试报告，（版本不理想的情况下？）拉开发开会一起复盘一下如何促进，之后怎么落实到之后工作；

二、To开发

1. 每个提测版本小模块的开发人员需要做好自测，有关联的模块则需要互测；
2. 每个提测版本指定开发负责人，对每轮产品提测时质量进行测试把控，提测前希望由负责人抽取bug进行验证（从产品全局的角度保障模块质量），有时间情况下可以全部覆盖下；
3. 督促负责产品的开发们，把已知技术实现难度大，导致的未实现问题，一些需要开发提供案例的功能等等，都登记到提测单中，也包含自测情况文档的上传，注意:每轮都要写提测单这个东西，内容按照每轮自行记录；
4. 模块交叉过流程（从同职能开发的角度保障模块质量）：有两个后端（前端）开发，那么互相交叉验证下相互的主体流程；
5. 不同职能交叉验证（从不同职能开发的角度保障模块质量）：前端关注后端，后端关注前端，优化自己只做自己模块的现象；

三、To产品

1. 尽早介入测试，在测试最终测试结束后，对产品最终实现进行验收；

四、一些讨论点，及关于报告

提测标准

• 功能全部开发完成，或提前两天告知无法完成的原因，方便测试调整对应的用例
• 开发接口、界面的自测、功能负责人的联调测试、产品负责人的集成测试都要认真完成并通过，产品经理对出口的版本负责，保证提测版本的质量
• 产品负责人将测试点（一般小的版本会控制在30条以内）全部验证通过；且提测单附上测试通过的文档

bug等级

• 严重： 系统无法使用或者崩溃；主流程（核心、常用、重要功能）无法使用；数据完整性受到重大威胁（比如会批量修改、删除数据）
• 一般： 系统一般功能无法使用或无法正常使用；数据完整性受到威胁（比如会修改、删除数据，数据原子性被破坏，通常原子性被破坏会升级到核心功能无法使用）
• 轻微： 系统一般、低频功能在特殊情况下会被影响；用户体验、交互、界面不友好等

版本质量等级

• 差： 测试过程中发现了大量严重的缺陷和问题，系统的功能无法满足基本要求
  • 超过三个核心功能或者流程无法正常工作（明显没有自测行为）
  • 较多功能无法正常工作（比如超过当前提测版本10%的功能点）
  • 一个版本内超过10个严重bug
  • 一个版本提交次数超过五轮（不包括五轮），可以统计推测试环境次数或者提供部署包次数
  • 根据开发提供的文档、步骤配置系统多次后，系统仍崩溃、报错
  • 上线后用户反馈较多严重的bug，或者存在较多不友好的交互与优化
• 一般： 测试过程中基本没有严重的缺陷和问题，系统的功能满足基本要求
  • 核心功能基本没有问题
  • 只有少部分功能无法正常工作或存在优化
  • 只有少量严重bug（4~10个）
  • 版本控制在五轮以内（包括五轮）
  • 上线后用户基本没有反馈严重bug，或者bug隐藏较深，或者反馈较少的优化
• 好： 测试过程中没有严重的缺陷和问题，系统功能满足要求
  • 核心功能全部没有问题
  • 几乎没有功能无法正常工作，只有少部分需要优化
  • 基本没有严重bug（3个以内）
  • 版本控制在四轮以内（包括四轮）
  • 上线后用户没有反馈bug，界面与体验获得点赞

版本质量为一般与差的情况，测试报告需要重点体现，并且测试、开发、产品负责人等需要进行复盘原因，提出改进方案并实施

测试报告需要输出的内容

1. 提测总体质量的总结：延期的原因，版本质量等级的定义，参与的测试人员，开发人员，版本为期时间，进行几轮，每轮的时间；
2. bug级别分布（按每轮，最终版本再体现一个总体指标）：高，中，低；
3. bug人员分布（按每轮，最终版本再体现一个总体指标）：xxx高几个，中几个，低几个；
4. 测试面自评：业务了解不够导致用例缺漏？需求变动？自身测试疏漏，下次如何改进等等；
5. 客观评价参与的开发质量：重点写下导致延期原因或者问题多的；

五 附测试报告模板

1.版本总体质量等级：好

本次定级影响原因主要为：基本没有严重bug（3个以内）

2. 版本关键时间节点

需求对接时间（指的是负责人开始了解产品的时间，比如XXX）：2023-05-08
用例评审时间：无
原定提测时间：2023-05-10
实际提测时间：2023-05-08
实际上线时间：2023-05-12

注意：可能是提测延迟的根本原因，提测前(时)插入的需求改动:

3.测试参与人

测试人员：XXX，XXX
开发人员：XXX，XXX

4.测试周期

• 历时4个工作日(5月8日~5月11日)，进行了3轮测试。
• 一轮：05.08~05.09
• 二轮：05.10~05.11
• 三轮：05.11~05.11

5.BUG级别分布：（已去除优化，设计如此，不解决类别）

• 总分布：BUG总数15个，严重：2个，一般：5个 轻微：8个

轮数	bug个数	严重	一般	轻微
一轮	7	1	2	4
二轮	4	0	2	2
三轮	4	1	1	2

一个图表体现分布

6.BUG人员分布

• 按开发解决人员分布:

解决人	总BUG数	严重	一般	轻微
XXX	8	0	3	5
XXX	3	0	0	3
XXX	1	1	0	0
XXX	3	1	2	0

一个图表体现分布

• 按测试创建人分布：

创建人	总BUG数	严重	一般	轻微
XXX	12	1	4	7
XXX	3	1	1	1

一个图表体现分布

7.总体质量分析

7.1 TO 测试 测试面自评

bug分布情况总结：

较好：
1、主体功能可以把控，轮数把控合理，能够及时发现模块交互问题，提出不合理的交互和模块优化；

改进：
1、提测前准备好测试点，给开发提供自测点，应该可以减少严重问题的出现；

7.2 TO 开发 客观评价参与的开发质量

一般：
1、模块细节的交互自测的不够深入（比如···）；
2、功能性的必要测试点没有覆盖到（比如···）；
改进：
1、提测涉及的模块必要功能要覆盖全面，除此之外可以花点时间感受下交互的问题；