Checklist设计编写规范及模板

一.编写CHECK LIST的目的:

1 保障所有的测试面都考虑到并被记录;【与无线相关的接口要考虑到无线;联动优势的退款要考虑到断账日前后】

2 保障TESTCASE已经覆盖所有的测试主体;

3 提高TESTCASE的REVIEW通过率。

二.CHECK LIST定义

CHECK LIST要包含从执行测试开始到发布完成后之间的所有检查内容。

TEST CASE是CHECK LIST的延伸;CHECK LIST包含 TEST CASE的目录及TEST CASE的指导。

三.CHECK LIST的依据:

1 需求 、UE设计图

2 设计文档/DEV设计方案(前端、后端、日志、DB结构:表、字段、键) 

3 系统结构 (含 外部接口)

4. 数据流

5 通用CASE 

6 经验积累、QA COMMAN SENSE

7  Code Diff, 依据变更的代码

四.CHECK LIST包括哪些内容:

^checklist模板细化问题版_2.0.xls

测试分类

必须检查项

测试模块

测试子模块

特殊测试点

是否自动化

UE/UI

 

 

 

 

 

 

参考WEB通用测试用例集

 

 

 

 

功能

 

 

 

 

 

 

对于复杂项目,必须梳理业务流程图。测试用例要求做到逻辑覆盖与边界值覆盖。

 

 

 

 

性能

 

 

 

 

 

 

项目涉及老系统的QPS是多少?新系统预估的QPS是多少?如何预估的?

 

 

 

 

 

项目对外提供接口或者页面的平均响应时间是多少?

 

 

 

 

 

修改对系统的请求量是否会有影响?预估变化是多少?要给出计算和评估方式,不能拍脑袋!

 

 

 

 

 

修改对系统的处理能力是否会有影响?对CPU和内存开销影响有多大?响应时间是否会变慢?

 

 

 

 

 

修改对公共系统是否有影响,如数据库,消息中间件。

 

 

 

 

兼容

 

 

 

 

 

 

浏览器兼容?
a、区分浏览器内核 
1、Trident内核:IE最先开发或使用的,也称IE内核,360浏览器使用的也是IE内核; 
2、Webkit内核:谷歌chrome浏览器最先开发或使用,也叫谷歌内核,枫树浏览器、太阳花使用的也是谷歌内核; 
3、Gecko内核: Netscape6开始采用的内核,后来的Mozilla FireFox (火狐浏览器) 也采用了该内核,K-Meleon浏览器也是使用这种内核; 
4、Presto内核:目前只有Opera浏览器采用该内核 
b、依据用户使用情况 
 ie 6-9, ff, chrome, 360, opera, 搜狗 
重点: 不同浏览器在渲染上还有不同,IE8及以后版本,基本都是标准模式,IE6,7的怪癖模式需要格外注意浏览器设置:

 

 

 

 

 

分辨率兼容: 常见的分辨率 1024*768 , 800*600

 

 

 

 

 

前后端兼容: 当界面有增加新的字段或数据来源,考虑旧有前端与新后端的数据兼容

 

 

 

 

 

数据兼容: 
a.旧有接口的变动,(新增字段,修改原有字段类型,长度) 
b.新旧数据兼容,比如RT升级; 数据库中是否新增字段,新数据该字段为何止,线上旧有数据该字段为何值? 
c.字段的变化关注 该字段所在数据流都进行了相应变化考虑

 

 

 

 

 

dubbo 依赖的版本升级

 

 

 

 

 

数据库兼容 
a. 查看时间段内所有数据都进行了迁移操作 
b. 查看修改到数据是否能够真确反映到老系统中 
c. 查看迁移后各字段是否正确 
d. 字段长度不一致检查 
e.特殊对象 
f. 老的数据关联,在新库中是否仍然正确关联

 

 

 

 

 

业务兼容?

 

 

 

 

 

多系统兼容,无线端兼容?

 

 

 

 

系统结构

 

 

 

 

 

 

外部系统异常,数据持久层异常(redis,memcache,db异常),是否捕捉,是否影响主流程?

 

 

 

 

 

外部系统异常,调用第三方接口返回失败,异常,超时,是否捕捉,是否影响主流程?

 

 

 

 

 

对外部系统异常必须try catch

 

 

 

 

 

上下游系统,对于系统之间的结构层次,相对或依赖要清楚,系统之间互相提供什么服务,如何提供等。

 

 

 

 

 

系统间数据流向

 

 

 

 

 

一个系统的异常对其他系统的影响,异常能否完全捕捉,数据持久层异常(redis,memcache,db异常)

 

 

 

 

 

系统超时对其他系统影响,

 

 

 

 

 

性能测试

 

 

 

 

 

系统设计的合理性,可扩展性,可移植性,健壮性,鲁棒性,稳定性 

 

 

 

 

对外部系统影响,服务提供者与服务消费者

 

 

 

 

 

 

对上游系统影响:修改老接口

 

 

 

 

 

是否修改原有接口的数据结构与返回数据的格式?

 

 

 

 

 

都有哪些外部系统(上游系统)调用了改修的接口?

 

 

 

 

 

是否需要做回归测试?回归测试用例有哪些?

 

 

 

 

 

对下游系统影响:调用第三方接口,调用数据库。

 

 

 

 

 

是否新增调用第三方接口(包含下游系统,数据库,消息中间件)?

 

 

 

 

 

对新增调用三方接口(包含下游系统,数据库,消息中间件)的压力有多少大,多少QPS?

 

 

 

 

 

接口调用方是否有缓存?自己是否需要做缓存?

 

 

 

 

监控

 

 

 

 

 

 

项目上线后是否响应监控?监控是否加告警?

 

 

 

 

 

项目发布后应该查看哪些监控?

 

 

 

 

 

监控点:成功率监控、失败率监控、数量的监控、响应时间、异常监控、数据库同步、对外接口的监控、定时任务的运行状态 
1、成功率监控:比如booking页面展示成功率、出票成功率、支付回调、pnr校验成功率、价格校验成功率、舱位校验、短信/邮件发送成功率监控 
2、 失败率监控:同上 相对失败率而言,接口请求成功率、订单恢复成功的次数、PID的失败率 
3、数量的监控:主站的访问量、Booking量、生单量、支付量、状态机扭转订单状态的次数、请求各个支付方式(支付宝)的数量、支付回调成功的次数、Q税总数以及Q税成功次数 
4、响应时间:Booking跳转时间、SS重搜的时间、AV搜索的时间、政策搜索时间 
5、异常监控:对空指针、404、5XX的监控(一般通过log4j日志监控) 
6、数据库同步:数据库同步的延时时间、成功、失败、 
7、接口监控:例如运价直连的接口响应时间 
8、定时任务的运行状态:清单的定时任务、清楚PNR、发送国际预约的邮件是否执行了 
注:几个监控点一般都需要结合使用,例如Q税 要记录Q税的总数及成功次数、Q税的成功的时间,结合起来才好定位问题。 
以上仍然不完全,欢迎直接在该页面补充

 

 

 

 

日志

 

 

 

 

 

 

关键业务流程和异常流程是否有日志记录?

 

 

 

 

 

上线后能否通过日志进行验证?

 

 

 

 

 

是否对BETA环境的日志进行校验?

 

 

 

 

 

使用日志工具类打印日志?slf4j+logback

 

 

 

 

 

日志添加的位置是否合适?
a.日志是否加在合适的地方,不能影响业务主流程
b.捕获的异常信息必须要打印出
c.接口的入参返回
d.与外部系统传出和读入的数据

 

 

 

 

 

日志添加的格式?
a:日志的格式有打印日志的时间、级别、线程、日志名称、消息
b:级别:
ERROR:发生了严重的错误,必须马上处理。这种级别的错误是任何系统都无法容忍的。比如:空指针异常,数据库不可用,关键路径的用例无法继续执行。  
WARN:还会继续执行后面的流程,但应该引起重视。其实在这里我希望有两种级别:一个是存在解决方案的明显的问题(比如,"当前数据不可用,使用缓存数 据"),另一个是潜在的问题和建议(比如“程序运行在开发模式下”或者“管理控制台的密码不够安全”)。应用程序可以容忍这些信息,不过它们应该被检查及 修复。  
INFO: 把用户行为(user-driven)和系统的特定行为(例如计划任务…)
DEBUG:开发人员关注的事。后面我会讲到什么样的东西应该记录到这个级别。  
TRACE:更为详尽的信息,只是开发阶段使用。在产品上线之后的一小段时间内你可能还需要关注下这些信息,不过这些日志记录只是临时性的,最终应该关 掉。DEBUG和TRACE的区别很难区分,不过如果你加了一行日志,在开发测试完后又删了它的话,这条日志就应该是TRACE级别的。

 

 

 

 

 

内容:不能包括密码、账户敏感信息,清晰易读,易于解析理解,比如下面三条更希望看到哪条日志?
log.debug("Message processed");
log.debug(message.getJMSMessageID());
log.debug("Message with id '{}' processed",message.getJMSMessageID());

 

 

 

 

 

避免空指针异常
log.debug("Processing request with id: {}", request.getId());
Request如果是null,这条语句就有问题啦!

 

 

 

 

第三方依赖

 

 

 

 

 

 

是否引用了第三方的jar包?本次升级是否依赖第三方jar更改?

 

 

 

 

 

依赖第三方接口:(http、dubbo) 
a.校验接口参数 
b.校验接口返回 
c.异常测试9(涉及到接口超时、404、500测试等) 
d.接口性能测试、接口监控(重要的接口应该添加监控) 
e.接口是否有白名单限制(境内、境外、内网、外网均可以访问) 
f.新增应用注册TC 
g.配置文件profile文件齐备,重点看prod 
h.上线之前一定要确认连接的配置是否是线上的 
i.升级时要分批次发,原则是保证业务不中断

 

 

 

 

 

服务对于依赖外部系统的服务,确认好发布回滚步骤

 

 

 

 

 

jar包核对api版本号(确认是否需要升级)

 

 

 

 

发布流程 

 

 

 

 

 

 

复杂项目必须提前定义发布流程,要求拉着QA leader,开发leader一起确认。

 

 

 

 

 

系统的业务峰值时间段是什么?是随时发布?还是业务低谷发布?

 

 

 

 

 

是否有api版本升级,dubbo版本升级,如果有列清楚互相依赖服务的发布顺序以及发布批次? 

 

 

 

 

 

跨团队合作项目,组织一起对发布步骤以及回滚步骤 

 

 

 

 

 

发布步骤和回滚都要核对 

 

 

 

 

 

检查配置文件是否有修改,相应的核对线上配置是否修改正确 

 

 

 

 

 

机器少的服务先发部分机器观察 

 

 

 

 

 

通知相关人员QA,DEV,以及产品,和各业务线leader 

 

 

 

 

 

提醒产品发发布前周知邮件,验证完毕后提醒产品发发布完成邮件 

 

 

 

 

 

如果有sql语句,ng,机器等需要提前review以及申请,避免造成发布delay 

 

 

 

 

 

发布时注意观看jekons发布log以及监控 

 

 

 

 

 

相关wiki:http://wiki.corp..com/pages/viewpage.action?pageId=70095694

 

 

 

 

冲突测试(多线程并发)

 

 

 

 

 

 

是否涉及数据库操作的多线程并发?

 

 

 

 

 

多线程是否需要加锁进行处理?多个线程之间不能相互影响?线程用完之后要关闭?

 

 

 

 

 

局部变量和全局变量重名产生的冲突? 

 

 

 

 

 

A对变量C进行了修改,B函数不知道A的修改,以为引用的还是变量C而产生的冲突  
多线程?  

 

 

 

 

数据

 

 

 

 

 

 

是否涉及数据备份?

 

 

 

 

 

是否需要对老数据进行清理和处理?

 

 

 

 

 

传入数据经过什么逻辑变成了什么数据,最终输出的结果是否符合预期,要结合diff code和业务测试两方面来看,因为可能业务感觉没有问题,但内部处理可能有的环节处理的不对

 

 

 

 

 

TTS代理商库新增了一张表和原有的表新增加一个字段,有什么需要考虑的地方呢,字段是否都需要,是否该数据需要存储在数据库,而不是利用memcache或是radis之类的。

 

 

 

 

 

pg等的统计数据是否正确,开发出来的统计数据结果是否全面

 

 

 

 

 

是json还是xml还是别的什么格式的数据,当数据为空时,key是否显示,是显示成“username”:”” 这样子,还是直接这个key都没有了

 

 

 

 

 

要注意代码中的对象用的类型和数据库中存储的类型是否一致,例如mysql中是int unsigned,那么java中应该用什么?bigint又对应java的什么类型呢?

 

 

 

 

 

数据传输的编码,是否有压缩,是get还是post,接口一次请求或返回数据的报文大小

 

 

 

 

 

是否有缓存,缓存机制是什么,是否有必要做缓存,缓存的数据有没有过期时间,过期时间是否合理,缓存用的是radis还是memcache或者别的什么

 

 

 

 

 

并发读,并发写,数据的同步,延迟的考虑,数据同步的diff情况,连接数等

 

 

 

 

安全

 

 

 

 

 

 

SQL注入?

 

 

 

 

 

XSS? 

 

 

 

 

 

URL跳转--攻击者用来进行钓鱼攻击用户?

 

 

 

 

 

业务逻辑安全? 

 

 

 

 

 

文件上传下载?

 

 

 

 

 

越权访问?

 

 

 

 

 

信息泄露及其它?

 

 

 

 

 

服务器安全配置?

 

 

 

 

 

相关wiki:http://wiki.corp..com/pages/viewpage.action?pageId=70094668

 

 

 

 

五.CHECK LIST的编写程度:

1 特殊冲突情况;

2 需求中涉及的功能,但非公共意识的部分(如密码在传输过程中的加密)

3 需求中未涉及到的隐含需求

4 切忌将checklist写得像test case 一样

六. CheckList 在项目流程中的发生环节:

--》PRD & Final Review

--》开发的设计& Review

--》CheckList & Review   –----------------》 QA来完成

--》Test Case & Review

--》Test Case 执行

--》发布

 

你可能感兴趣的:(QA)