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 执行

--》发布