Checklist设计编写规范及模板
一.编写CHECK LIST的目的:1 保障所有的测试面都考虑到并被记录;【与无线相关的接口要考虑到无线;联动优势的退款要考虑到断账日前后】2 保障TESTCASE已经覆盖所有的测试主体;3 提高TESTCASE的REVIEW通过率。二.CHECK LIST定义CHECK LIST要包含从执行测试开始到发布完成后之间的所有检查内容。TEST CASE是CHECK LIST的...
一.编写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包括哪些内容:
测试分类 | 必须检查项 | 测试模块 | 测试子模块 | 特殊测试点 | 是否自动化 |
UE/UI | |||||
参考WEB通用测试用例集 | |||||
功能 | |||||
对于复杂项目,必须梳理业务流程图。测试用例要求做到逻辑覆盖与边界值覆盖。 | |||||
性能 | |||||
项目涉及老系统的QPS是多少?新系统预估的QPS是多少?如何预估的? | |||||
项目对外提供接口或者页面的平均响应时间是多少? | |||||
修改对系统的请求量是否会有影响?预估变化是多少?要给出计算和评估方式,不能拍脑袋! | |||||
修改对系统的处理能力是否会有影响?对CPU和内存开销影响有多大?响应时间是否会变慢? | |||||
修改对公共系统是否有影响,如数据库,消息中间件。 | |||||
兼容 | |||||
浏览器兼容? | |||||
分辨率兼容: 常见的分辨率 1024*768 , 800*600 | |||||
前后端兼容: 当界面有增加新的字段或数据来源,考虑旧有前端与新后端的数据兼容 | |||||
数据兼容: | |||||
dubbo 依赖的版本升级 | |||||
数据库兼容 | |||||
业务兼容? | |||||
多系统兼容,无线端兼容? | |||||
系统结构 | |||||
外部系统异常,数据持久层异常(redis,memcache,db异常),是否捕捉,是否影响主流程? | |||||
外部系统异常,调用第三方接口返回失败,异常,超时,是否捕捉,是否影响主流程? | |||||
对外部系统异常必须try catch | |||||
上下游系统,对于系统之间的结构层次,相对或依赖要清楚,系统之间互相提供什么服务,如何提供等。 | |||||
系统间数据流向 | |||||
一个系统的异常对其他系统的影响,异常能否完全捕捉,数据持久层异常(redis,memcache,db异常) | |||||
系统超时对其他系统影响, | |||||
性能测试 | |||||
系统设计的合理性,可扩展性,可移植性,健壮性,鲁棒性,稳定性 | |||||
对外部系统影响,服务提供者与服务消费者 | |||||
对上游系统影响:修改老接口 | |||||
是否修改原有接口的数据结构与返回数据的格式? | |||||
都有哪些外部系统(上游系统)调用了改修的接口? | |||||
是否需要做回归测试?回归测试用例有哪些? | |||||
对下游系统影响:调用第三方接口,调用数据库。 | |||||
是否新增调用第三方接口(包含下游系统,数据库,消息中间件)? | |||||
对新增调用三方接口(包含下游系统,数据库,消息中间件)的压力有多少大,多少QPS? | |||||
接口调用方是否有缓存?自己是否需要做缓存? | |||||
监控 | |||||
项目上线后是否响应监控?监控是否加告警? | |||||
项目发布后应该查看哪些监控? | |||||
监控点:成功率监控、失败率监控、数量的监控、响应时间、异常监控、数据库同步、对外接口的监控、定时任务的运行状态 | |||||
日志 | |||||
关键业务流程和异常流程是否有日志记录? | |||||
上线后能否通过日志进行验证? | |||||
是否对BETA环境的日志进行校验? | |||||
使用日志工具类打印日志?slf4j+logback | |||||
日志添加的位置是否合适? | |||||
日志添加的格式? | |||||
内容:不能包括密码、账户敏感信息,清晰易读,易于解析理解,比如下面三条更希望看到哪条日志? | |||||
避免空指针异常 | |||||
第三方依赖 | |||||
是否引用了第三方的jar包?本次升级是否依赖第三方jar更改? | |||||
依赖第三方接口:(http、dubbo) | |||||
服务对于依赖外部系统的服务,确认好发布回滚步骤 | |||||
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 执行
--》发布
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)