测试人员新需求跟进工作质量checklist

最新推荐文章于 2024-03-05 14:02:12 发布

longxibendi

最新推荐文章于 2024-03-05 14:02:12 发布

阅读量2.1k

点赞数

分类专栏：测试

测试专栏收录该内容

6 篇文章 0 订阅

订阅专栏

from: http://blog.163.com/li_hx/blog/static/18399141320125286922554/

此中有真意，欲辨已忘言。
讲究一致性，需求和计划一致，计划和用例一致。一致，是语义一一对应。

1 概述

为了保证测试中心新需求跟进工作的质量，避免出现因为工作检查不到位的情况而产生的质量问题，特制定本Checklist。请各部门就测试任务，检查工作质量，加强测试工作质量的提高。

填写要求：首先，需求跟进人员，要进行自查，把结果填写到表格；其次，检查人员检查，把结果也填写到表格；最终提交的文档，要有2种角色书写的内容。

通过准则：有1个不通过，则算不通过。有1次修正后验证不通过，认为最终结果是不通过。

2 Checklist

1) 新需求跟进工作检查

对每个组员或者直接下属的新需求跟进工作进行检查。可以将检查过程中发现的问题记录到备注中。

新需求名称：

新需求跟进人员：

检查项	检查结果	备注（内容多，可以另行附加纸张）
【一】需求文档检查
1. 对新需求是否提出自己的问题。问题个数：问题种类：笔误需求中前后矛盾需求丢失必须内容（是开发人员需求文档描述不仔细，测试人员无法进行详细的测试计划）需求不可测（任何一句话都要考虑如何测试，凡是与测试无关的内容不应放在需求中）需求说明不可理解需求中未考虑的点（开发人员没有想到的问题，最后可能出现bug的地方）需求描述有二义需求中没有考虑模块相关性需求中对应的性能需求描述不够清晰其他需要逐项提问，越细致约好	问题类型问题个数笔误需求中前后矛盾需求丢失必须内容需求不可测需求说明不可理解需求中未考虑的点需求描述有二义需求中没有考虑模块相关性需求中对应的性能需求描述不够清晰其他 □问题轻松回答（通过） □问题有卡壳，但不严重（通过） □全貌、重点不清晰（不通过）
【二】对需求文档的理解
1. 口头讲解对新需求的理解，可将检查结果写入备注中（从概述与细节两方面检查）需求难点需求重点需求的五处细节	□全部理解（通过） □部分理解（不通过） □很少理解（不通过）
【三】[建议]需求兼容性理解对比
1. 如果新需求兼容其他产品，检查是否查阅其他产品手册，与我们的需求做对比了解了解异同之处语法功能实现其他特性对比（优缺点对比）	□了解 □不了解 □不适用
【四】测试计划检查
1. 新需求中设计测试计划检查模块覆盖模块内功能点覆盖参数遍历参数组合（包括需求中明确的不能组合和必须组合项，都要测试）需求中提到的支持的功能需求中提到的不支持的功能异常情况的测试隐含功能（例如：应该输入正整数，需要考察输入非正整数的情况）是否考虑与其他需求相关性（需要测试计划人员讲清楚关联点在哪里，道理是什么？作为重点要讲明白）模块之间相关性根据经验补充的测试点（比如错误信息国际化）要求每条都严格检查**	□通过 □不通过 □不适用
【五】测试用例检查
1. 新需求测试用例检查 1.1与测试计划是否一致抽查5条以上测试用例，并写入本文档备注部分。 1.2期望结果是否明确 1.3测试目的是否明确 1.4测试步骤是否明确正向查: 从测试计划出发，抽取5条以上测试点，要求找出用例反向查：从测试用例出发，抽取5条以上测试用例，请讲其测试目的，与测试计划和需求的对应关系	□通过 □不通过 □不适用
【六】对用例的格式进行检查
1 检查测试用例是否使用模板（质量体系C层文件）必须遵守《XXX测试用例规范_v1.0.doc》 1.1对于sql 用例模板参见《B07-C24测试用例(SQL脚本版).txt》 1.2对于需要以word 形式写的用例，参考模板《B07-C25 测试用例(WORD版).doc》（质量体系C层文件）	□通过 □不通过 □不适用
【七】异常测试、破坏性测试用例检查
1 破坏性测试用例构造需要从系统总体方面考虑设计测试用例相关模块综合设计测试用例强调发散性思维方式	□通过 □不通过没有此方面的思考或思考不充分，视为不通过
【八】脚本自动化程度
测试脚本，是否可自动化。 1 检查不可自动化的部分原因 2 可自动化部分，不提交Daily，提交到Firefly相关位置。 3 如果自动化部分如果提交Daily，提交Daily检查单 4 手工测试用例，提交到Firefly 相关位置下。	□ 全部自动化（通过） □ 部分自动化（是否通过需要查用例不能自动化的原因） □通过 □不通过
【九】测试执行（需求跟进人员自行填写，检查人员逐一核实）
1. 新需求测试发现的bug数量请填写在总数中，然后分类填写	总数最严重严重普通不严重手工执行用例时间
【十】备份培养
1 检查备份人员对需求、用例、测试环境等的熟悉情况被检查人员姓名： 1）需求讲解： □清楚（100%以上） □部分清楚（80%-99%） □不了解（80%以下）需求的重要部分，不能有遗漏 2）测试环境： 3）测试用例执行：□清楚（100%以上） □部分清楚（80%-99%） □不了解（80%以下） 2 检查备份对于测试用例的贡献度 1）测试点补充个数 3 备份人对需求的意见反馈详细参见需求提问中的具体内容 □通过 □不通过（有一项“不了解”即不通过，其他情况，检查人据实际情况确定）
【十一】帮助手册测试
1. 新需求对应的帮助手册测试测试发现的bug数量请填写在总数中，然后分类填写请参考《联机帮助测试规范》	总数最严重严重普通不严重
【十二】工作归档（写出归档位置）
测试计划已经归档测试用例已经归档测试报告已经归档手工用例归档（列出手工用例的个数和位置，必须说明不能自动的原因和理由）	□ 通过（全部归档） □ 不通过（有遗漏即不通过）
【十三】bug格式
1 bug标题是否简洁明了通过： □简洁 □不够精炼 2 bug级别是否正确： □正确 □不正确 3 bug的测试环境（操作系统等）是否正确：□正确 □不正确 4 bug的重现步骤是否简洁： □简洁 □不够精炼 5 bug确认是否有“caseid”（检查全部bug）： □有 □没有 □不适用 6 bug状态修改[1]，是否合乎规定： □是 □否 bug检查是否通过（抽查5个，有一项不通过即视为不通过）：□通过 □不通过
【十四】bug质量
1 一级bug个数个；反映出的问题： 2 二级bug个数个；反映出的问题： 3 其他bug个数反映出的问题：描述产品质量缺陷
【十五】[建议]检查人员用时（人时）
需求跟进检查用时：测试计划检查用时：测试用例检查用时： Bug检查用时：其他检查用时：
最终结论： □ 通过 □ 不通过	检查人（签名）：	检查完成时间：年月日