记测试流程

测试流程

主要流程概述

说明：项目整体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个，其中P1级1个，P2级0个，P3级0个。

三、测试环境：

    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%	新增定向功能：DB数据check、算法数据产出、引擎召回  新增过滤功能：DB数据check、算法数据产出、引擎召回    算法&引擎均联调通过	pass
	影响功能	case通过率100%
	核心功能	case通过率100%
	全功能	case通过率100%
	联调功能	case通过率100%
兼容性	接口兼容	接口无bug，页面交互正常	无	不涉及
	web兼容	交互正常，样式美观，无bug
第三方依赖	调用第三方服务返回错误（数据，顺序）	服务可用，有降级或重试方案，提示友好	无	不涉及
	调用第三方服务超时	服务可用，有降级或重试方案，提示友好
	调用第三方服务不可用	服务有损可用，有容灾或降级方案，提示友好
	网络异常	服务有损可用，有容灾或降级方案，提示友好
上线步骤	上线和回滚方案	上线和回滚过程无损，用户感知小	正常上线。	pass
基础性能	吞吐量	不低于稳定环境性能	无	不涉及
	响应时间	不低于稳定环境性能
	错误率	不低于稳定环境性能

 

 

 

 PS 设计测试用例：

http://www.testclass.net/post/about_interview

 

 

重点：

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

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

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

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

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

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

比如

• 装盐的袋子不能（不是）漏

• 衣服的颜色是红的

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

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

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

​