测试流程

 

主要流程概述

说明:项目整体owner作为项目经理

          QA这边的owner建议由改动比较大的或者提出需求方作为owner

 

1、需求评审

  •     产品对项目内容进行讲解,并说明prd中的内容;
  •     测试人员主要是对需求的理解提出疑问,以便才能根据需求写用例;
  •     开发人员根据需求功能点进行排期,然后将开计划转交给测试人员;
  •     测试负责人根据测试用例数目以及功能点评估测试时间;
  •     项目的开发与测试计划及时钉钉给相关人员。

2、编写测试用例

  •    阅读项目prd,与钻展测试负责人即本次项目的owner明确项目的需求和主要功能点;
  •    编写测试用例。

3、测试用例评审

            重点大项目: 建议可以先在小组内进行评审

  •  对于XX项目的重点功能进行修改时进行;
  •   在测试用例完成后,上传Bug管理平台
  • 以邮件形式将用例发送给组内人员,以便他们事先了解用例对哪些功能进行验证以及验证的细节;
  •  对用例进行评审,补充遗漏的测试功能点。

4、提测

  •  开发对测试相关人员在管理平台上备注
  •  测试人员需要明确开发完成的内容,如果与prd不符,需要及时与产品沟通确认;
  •  与开发明确项目是否影响其他功能,如果有需要进行相应的回归测试;
  •  部署测试环境,准备开始测试

5、测试

  •   根据测试用例进行测试;
  •   发现问题后,记录到Bug 平台,并设置提醒进行高效跟进
  •   BUG修改后,进行验证;
  •   对于前端项目,线下测试完成后,需要部署预发环境进行测试,需要修改domain的配置

 

6、测试日报&报告

         重点项目需要测试日报体现,日常项目钉钉同步进度

  •  冒烟测试打回:在平台上记上
  • 测试日报邮件内容:

a)    题目:【测试进度】-【XX】- 日期;

b)   测试进度;

c)    测试内容;

d)    存在的BUG;

e)    需要明确的问题。

7、线上回测

  •  项目上线后,一定要第一时间回测;
  •  接口层上线,观察是否有errorlog

8、项目资料积累

  •  项目测试完,资料的积累


测试日报模板

Hi all:

【项目名称】- 2019.04.09-测试日报-XX

 

一、测试进度:

     测试排期:xx侧:2019-3-4~2019-3-12(第一轮测试进度90%,见具体);

                     引擎侧:2019-3-5~2019-3-8(测试进度:50%);

                     算法侧:已开完完成,等待联调

      重点关注:暂无(如果有,要描述关注啥,谁关注)

     

     BP侧第一轮测试进度:90 %,case执行如下:

 
 

测试轮次

待执行case

阻塞case

已执行case

第一轮(100)

40

10

50

第二轮

 

 

 

 
 
 

case的统计,目前需要将case导入aone中,统计成本需要考虑

 

 

二、项目bug以及风险

 

风险:1、项目周期长,主要耗时在,定向中心-bug修复;

          2、定向中心-reopen-bug较多,bug修复后引发更严重的bug。

               以上两个原因导致项目上线时间有风险。

 

bug列表:xxxxxxxx  @​XX,请关注

 
 

Active

Resolved

Closed

Total

1(P1)

0

17(3P2+14P)

18
 
 
 

 

三、测试内容:

 

  1. 新增定向功能:DB数据check、算法数据产出、引擎召回  100%
  2. 新增过滤功能:DB数据check、算法数据产出、引擎召回    80%
  3. 联调测试:  10%

 

四:测试环境

    140.205.173.181 i.cnblogs.com.com

    indexbp1:daily/0.0.316;indexbp2:daily/0.0.22


 


测试报告

【定向二期】本次提测已经完成100%

 

 

一、测试结果:测试通过


       遗留问题:暂无,如果有,描述问题+解决时间+跟进人

 

二、提测质量:

提测质量: 提测次数2次;

测试质量: bug总数:1个,其中P11个,P20个,P30个。

 

三、测试环境:

    140.205.173.181 i.cnblogs.com.com

    indexbp1:daily/0.0.316;indexbp2:daily/0.0.22

 

四:代码分支

    cnblogs:26bd7fdc151ce688fc7444e3e1013a3f50dd69fd

 

五:测试时间

 

测试开始时间2019-3-4   测试结束时间:2019-3-12

测试所用时间:5天

非测试消耗时间:2天(等待bug修复)
测试执行轮次:2

 

五:测试内容

 
 

检查项

子项

指标

测试内容

测试结果

备注

基础功能

新功能

case通过率100%

  1. 新增定向功能:DB数据check、算法数据产出、引擎召回 
  2. 新增过滤功能:DB数据check、算法数据产出、引擎召回   
  3. 算法&引擎均联调通过

pass

 

影响功能

case通过率100%

核心功能

case通过率100%

全功能

case通过率100%

联调功能

     case通过率100%

兼容性

接口兼容

接口无bug,页面交互正常

不涉及

 

web兼容

交互正常,样式美观,无bug

第三方依赖

调用第三方服务返回错误(数据,顺序)

服务可用,有降级或重试方案,提示友好

不涉及

 

调用第三方服务超时

服务可用,有降级或重试方案,提示友好

调用第三方服务不可用

服务有损可用,有容灾或降级方案,提示友好

网络异常

服务有损可用,有容灾或降级方案,提示友好

上线步骤

上线和回滚方案

上线和回滚过程无损,用户感知小

正常上线。

pass

 

基础性能

吞吐量

不低于稳定环境性能

不涉及

 

响应时间

不低于稳定环境性能

错误率

不低于稳定环境性能

 
 

 

 PS 设计测试用例:

 
 
重点:

有的候选人是这么回答的。

假如是一袋盐,那么要看看装盐的袋子是不是会漏?

这时候我一般会反问,那应该是要漏还是不要漏?很多候选人这时候会愣住,可能完全意识不到我为什么会这么问。

我这么问是因为我有个怪癖,那就是我希望测试用例都是可以执行的。可以执行的意思是,你要告诉我你究竟是希望袋子漏还是不漏。如果你希望袋子是不漏的,那么袋子漏的时候测试用例就是不通过的,反之也成立。如果你告诉我看看袋子漏不漏,那么因为我是很笨的,我不知道如何去执行这个用例,因为我不知道袋子究竟是需要漏呢还是不能漏。

与之类似的,在测试衣服的时候,有的候选人会回答要看衣服的尺码是不是合适。那么我会反问,对于L号,衣服多长是合适,多长又是不合适呢?这是因为合适不合适是没有执行标准的,对于一个身高不高的人——比如1米49家穷人丑的我——来说,L号是不合适的,太长了。而对于身材匀称的其他人来说,L应该是合适的。所以合不合适没法量化,加上又有模棱两可的是不是这样的词语推波助澜,这种用例执行起来是相当困难的。

所以写用例,要想可执行,首先的第一条原则是,不要包含一些似是而非的词语,比如是不是,要不要,有没有之类的。换句话说,就是用例里大概率要么包含是,要么包含不是这样的词。

比如

  • 装盐的袋子不能(不是)漏

  • 衣服的颜色是红的

  • 衣服的材料是80%的棉,20%的涤纶

像这样的是或者不是的句型,我们可以称之为断言。

上面是最基本的用例设计,主要考察的是思维的全面程度,以及设计用例的最基本要求——可以执行,没有歧义。另外我还喜欢根据候选人的经历去问一些稍微有技术深度的问题。

 

版权声明:本文为gxunique原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/gxunique/p/11238233.html