检查表checklist使用

上一篇 / 下一篇  2014-05-10 10:07:04 / 个人分类:测试好文章收集

检查表checklist很常见,各行各业都有,但是作为电信运营支撑系统这样大的软件系统的实施和开发,却。。。。。

检查项目并不是一成不变的,也不是随便想几个就可以的,否则会成为摆设。一定得要有过程管理思想并深刻体会到其中的关键点进行监控。每个团队、每个时期都是动态变化的,checklist是一种动态的工具。除了过程,可以使用在其他方面,例如:各种评审。
checklist可以让工作标准化,但是快速发展的团队和高效工作似乎不需要标准化?错,这要看checklist的内容是什么。总会有需要checklist的地方并且能起到真正的作用。

测试用例检查表

是否每个用例测试一种单独的情况
用例是否有测试数据
用例是否有预期结果
是否明确描述了测试数据的异常值、正常值、边界值
预期结果是否可以再现
测试用例是否分级展现
是否有数据恢复脚本
是否有优先级
是否是可用状态(ready)
每个用例是否覆盖了测试需求
是否有设计时间(用例完成设计的时间)
是否被评审过


测试场景检查表
场景是否由用例组成的
场景是否有优先级
是否每个场景中的用例已经run
是否被评审过

测试需求检查表
涉及到数据库连接是否明确了连接个数和方式
是否每个测试需求相对独立
测试需求之间不应该存在因果关系
测试需求中不应该存在模糊描述(大量、很多、长时间等等)
测试需求的来源是否可靠(不会被随意改动)
测试需求描述是否清晰无歧义
是否被评审过
是否设定了优先级
测试需求是否包含了业务需求
是否把复杂的业务需求分解了
是否每个测试需求都有明确的输入输出,便于测试

defect检查表
是否描述清晰:出现问题的环境简要描述
是否描述清晰:出现问题的操作过程描述
是否描述清晰:问题现象描述清楚
是否提出了自己的分析
是否指定了解决人
是否跟踪了每一个自己的bug
是否有未关闭的bug
是否提出bug之前检查了没有人已经提出来过(不重复)
是否每个defect描述一个独立的问题
是否及时修改了defect状态
是否填写了应该填写的字段
不能带有主观的对程序的评价
bug描述中不能带有疑问句
是否填写了优先级
是否填写了严重程度

测试计划检查表
是否符合项目里程碑时间要求
是否安排好了执行时间计划
是否安排好了执行人计划
计划安排是否粒度到天(周)
是否有测试人员培训计划
第一、 描述了项目的目的
第二、 描述了项目的开发周期
第四、 描述了测试案例的设计周期
第五、 描述测试案例的执行周期
第六、 描述了测试过程中用到的工具或者技术
第七、 描述了测试过程中用到的资源情况
每一部分测试计划时间安排是否有冲突
是否有测试过程检查机制
测试过程检查是否涉及到其他组
是否取得了相关组的认可
是否经过了有项目经理参加的评审
是否有测试执行日报告机制
是否有风险分析以及规避方法
是否有测试环境描述
是否有测试人员协作机制
是否有测试人员考核点描述并且可行
是否有其他组协作机制描述


测试环境更新检查表
是否是在确认了版本无误的情况下更新的
是否有配置文件更新
是否可执行程序权限正确
是否记录了编译错误并报告
更新后是否做了冒烟测试
更新后是否记录了更新过程
如果更新步骤或内容有变化是否同步更新了作业指导文档
更新问题是否提交到CVS
更新问题是否通知到相关人员
是否记录了本次更新经验(版本更新日志)


测试方案检查表
是否描述了测试方法
是否描述了测试参与人员
是否描述了测试环境
是否描述了人员协作办法
是否相关人员已经通知到
是否描述了测试内容
测试内容时候细化到模块
是否描述了测试时间安排
是否描述了测试人员培训安排
是否描写了测试说明章节
是否进行了换位思考(别人能读得懂吗)
是否有备份方案
是否经过评审


准备测试评审检查表
是否提前给开发组和项目经理以及相关人员发送了评审材料
是否预定了会议室和预约了合理的时间
是否准备了与会材料和工具(投影机等)
是否主讲者已经演练了一下
是否最好了被推翻重来的准备
是否做好了听取改进意见的准备
是否做好了改变原有思路的准备
是否做好了大家都没有意见的准备
是否做好了需要二次评审的准备
是否做好了由于各种原因评审会失败的准备
是否检查过了被评审材料


压力测试检查表
是否已经清楚了实际业务的压力情况
是否已经预估了业务发展趋势和量化了增长速度
是否预估了产品的生命周期
是否预估了产品生命周期内业务量可能的峰值
是否统计了业务峰值时间段以及峰值业务量
是否已经明确了生产系统的主机分布

TAG:

 

评分:0

我来说两句

Open Toolbar