测试报告

测试报告编写的目的：告诉大家本次迭代能不能上线，上线的理由是什么，不能上线的理由是什么？

 

本次迭代所有BUG必须要解决嘛？

1、每个迭代的BUG不一定所有要解决的

2、不能解决的的情况：

     A、很难解决，需要很长时间

     B、可以解决也可以不解决，不是紧急的

3、针对必须要解决但是又影响范围很大，这个时候作为测试的操作行为：

      A、你需要把实际情况反馈给测试负责人

      B、由来你主持会议（会议参与人，产品经理，开发，开发负责人，测试，测试负责人，pm，pmo）

 

 

测试报告的要素：

1、测试概述：版本，测试时间，测试参与人，备注

2、新功能测试结果：本次迭代新功能测试的结果(只有一个结果就是通过/pass)

3、系统已有功能测试结果

4、系统核心流程测试结果

5、缺陷分析（总共有多少个BUG，解决了多少个，解决率是多少，未解决多少个）

6、测试风险分析

7、测试结果

 

 

特别强调下：在流程中，开发与测试的工作是同时进行的

 

 

 

产品经理发出需求评审的会议邀请

测试需要干的事：

1、熟悉新的需求业务逻辑

2、在熟悉的基础上思考对之前逻辑是否有很大的影响，如果有，需要记录下来，同时需要思考这个思考这个对现在使用的用户的影响以及解决的方案，这些问题都需要汇总

 

产品需求设计评审

需求评审期间需要做的事：

1、熟悉业务要求

2、针对有疑问的业务逻辑出来，产品经理会进行解答

3、针对本次调整影响已使用的用户，解决的方案是什么，也是需要提出来

4、在PRD的评审阶段，测试至少要做到把需求点的95%吃透

 

评审技术方案

1、再梳理清楚需求的基础上理清开发的设计方案

2、主要需要核对的是开发技术内部的实现以及逻辑是否与产品的保持一致

 

编写测试计划

  考虑要素：

1、整体成本的考虑（人力和时间）

2、包含了测试需要测试改功能使用到的技术点

3、依赖方的管理以及风险管理

 

编写测试方案

 测试方案：

1、测试思路

2、具体使用到的技术

3、考虑到的测试范围和测试点

 

开发转测后先进行冒烟测试

冒烟测试：

正常流程的测试

为了提升开发转测的质量，建议测试编写开冒烟测试用例后，把冒烟测试用例给开发，由开发自己进行check后再转测给测试

 

开发这边转测经常冒烟测试不通过？你这边有什么改进的方式和方法

把冒烟测试用例转发给开发 ，让开发自己先进行冒烟测试，测试没有问题了 ，再转测给测试，测试再进行冒烟测试

 

提交BUG以及验证BUG

1、发现BUG

2、提交BUG

3、开发修改BUG

4、开发吧问题修复后反馈给测试

5、测试验证如果通过，就关闭，如果没有通过，继续反馈给开发

 

提交BUG需要注意的点：

1、很清晰的测试步骤

2、需要尽可能地带错误日志信息、截图

 

测试通过后编写测试报告

  包含内容：

1、本次更新功能点的测试结果

2、系统已有共功能的测试结果

3、总BUG数、以及不同级别的BUG

4、遗留问题的描述以及解决方案