如何做好测试的文档审查？（获奖名单已公布）（2014.9.1）

lsekfe

本周的问题为“如何做好测试的文档审查？”
此话题由会员提供，如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	土土的豆豆	50元京东礼品卡	#6

IUHK

是对测试活动内的文档：测试计划、案例、报告的审查，还是对整个测试活动的文档审查呢？
感觉不同的评审活动只能在形式上保证这个动作，但我遇到过的大部分只是走个过场，有效的沟通都只是在少数2-3个人之见产生的。
而且能提出文档问题的这几个人也往往有很多其他事情处理，不是专门的QA。
做事的没时间好好审，QA只能在形式保证活动。
请楼下做的好朋友聊聊吧。

wuxia

这个测试的文档是否有限制条件呢？是否只局限于测试流程内的文档？
每个测试流程阶段的文档都不一样，所以审查的侧重点和方式都不一样，从理论上说做好测试文档审查首先应该具备责任心、耐心和细心的精神；其次运用正规检视文档、技术评审文档、走读文档的方式评审文档；然后从正确性、无歧义性、完整性、一致性、可验证性、可追踪性来确保文档的质量；最后就是和不同部门的人员沟通的问题，需要QA、开发、或者需求调研人员协助沟通。
（PS：严格运用需求规格说明书的评审方法去做就可以了，但实际工作中如楼上说的一样，很难一步一步严格按照流程执行。呵呵）

zhanghl820716

首先取决于所审查测试文档的性质。重要性，涉及范围，系统项目的大小，文档资料的类型等；
大概流程是：
提前准备工作内容：制定测试文档的审查目标；根据审查目标再制定审查计划和涉及范围，划分内容的重要性优先级；
完成这些后，再确定参与审查相关人员以及审查方式；再把自己所提前准备的相关资料每人一份做基本了解；
审查过程中：根据所制定的内容优先级，从文档不同各个方面去审查；具体文档审查从几个点网上百度就有可以拿来参考；

yinjiajia0626

我觉得需求规格说明书，测试计划和测试用例是重点审查对象，一般这三个点我一定要参与审查的，否则项目中不断变更的需求。
需求规格说明书的评审的开发召集，测试计划和测试用例都是我召集，项目经理、开发、测试都参加，召开评审会才能提高个人的审查粒度。

土土的豆豆

测试阶段对于文档的评审和其他软件开发过程阶段中产生的文档一样，理应进行评审检查。
个人建议公司若有条件或者肯投入成本的话，可以加上QA角色。这里的QA是真正意义的质量保障，不是有些小公司兼职做测试的那种。
独立的QA部门以及团队成员，对制度符合各个流程的制度、规范、体系要求等。测试作为整个软件工程中的一部分，当然适用于体系规范。文档评审是保证项目质量和节省成本的重要手段。
这里不说是必要手段，原因很多公司连基本文档都不存留，且实际会更加项目大小、进度进行成本控制。
我们讨论的是有条件进行文档规范化、合理化、质量化的情况。
测试阶段的文档通常包括：
测试需求文档
测试用例
测试方案
测试计划
测试记录
测试缺陷报告
测试结果
测试报告
……

每个文件生成产生后，应该让负责领导或部门经理签字确认，有必要最好可以同时要求需求部门和开发部门领导一起签字确认，以免后续产生缺陷bug时，开发与测试部门产生不同意见。（个人理解同样术语产生不同场景的除外）
通常评审会是一个大会议的过程，若人数少也可以就2-3人单独交流。
这里简单列举主要样式：

评审对象（即文档名称）
评审条目（详细的评审细则、项目）
评审结论
评审意见
审核/批准
评审跟踪与反馈
备注
……

各测试阶段生成的记录文件都可以按照以上章节进行操作。
关键是要有QA，或者项目组/部门至少有存放文档的配置管理系统/数据库，如使用VSS,SVN等。

这样所有操作都有章可寻，有法可依，确保文档的有效性和规范性，保障大家在软件测试过程中的安全、稳定。

个人想法~请探讨。

愚人

站在谁的角度来看？

千里

回复 6# 土土的豆豆


    你的楼下就是QA，哈哈

土土的豆豆

回复 7# 愚人

果然精辟~

土土的豆豆

回复 8# 千里

恩恩 了解鸟~~
可惜大大简明扼要就几个字……

千里

回复 10# 土土的豆豆


    人家跟你走的路线不一样，人家走极简主义路线。

sd107880

大家说的都够细的，就我测试军品经验而言，一个是是否符合审查体系“GJB438B-2009”，其次就是被测软件，尤其是《用户手册》中有很多截图，那么就会看是否与被测软件的界面一致！

liujs

我想问下测试过程中的各种风险以及对应的预防/规避措施？

mandy.wang

审查过程：

1.审查前的准备

1)确定需要审查的对象

2)确定进行审查的时机

3)确定参与审查人员

4)明确审查的资料

5)确定审查结束标准

6)至少提前一天发出审查通知，将需要审查的资料以邮件的形式发送给审查会议相关人员，并注明详审时间、地点及参与人员等

7)在邮件中提醒审查会议相关人员至少简读一遍审查内容，并记录相关的疑问，以便在审查会议上提出

8)会议主持者(一般为审查资料的作者)应在会议前整理相关疑问，以便在会议上提出

2.审查

1)召开审查会议。与会者在作者讲解完审查资料之后给出意见和建议，同时进行详细的审查记录

2)依据审查记录修改审查资料并通用邮件与相关人员沟通

3)相关人员回归审查修改后的审查资料

测试过程中的文档包括：测试计划、测试用例、测试报告，主要的审查对象是测试用例，测试用例的审查内容主要包括如下内容：

1)是否使用了正确的模板？

2)是否覆盖了需求规格说明，包括内在需求和外在和非功能需求？（与软件测试需求相对应）

3)是否对需求变更的部分进行对应的调整和增加？

4)软件测试用例是应有正确的名称和编号

5)软件测试用例应标注有执行优先级

6)测试用例是否正确填写了测试对应的需求，测试步骤，预期结果，优先级，作者姓名，创建日期等？

7)测试用例是否包含测试数据，测试数据的生成是否正确？

8)是否包含了负面测试用例？

9)是否使用了等价类划分和边界值分析的测试方法？

10)测试步骤是否被阐述清楚？

11)预期结果是否表达正确？

12)每个步骤都应给出相应的测试结果

13)给出一个预期结果的验证步骤不要太多

14)预期结果中不要使用模糊的语言，是确定的，唯一的

15)操作步骤和期望结果应完整、一致、清晰

16)每个软件测试用例的操作步骤不要太多（一般<=15）

hotivy

抛个砖，谈谈我工作中涉及的两种类型——从数量和质量上审查。

“数量”审查，一般是QA的审查。在项目前期制定好“过程剪裁”后，QA需要定时检查测试文档的提交情况。包括文档种类，文档数量，格式等方面。至于检查文档内容的准确性，有些为难QA了。见过懂业务、技术的QA检查文档，那绝对是项目人员的噩梦啊， 哈哈，不过也是极少见的。

再一个“质量”检查，就是项目组对测试文档的审查了。这里我给分为“管理类”和“设计类”两种。
“管理类”一般是测试计划、测试需求分析，测试总结之类的。这种文档主要由项目管理层和项目骨干进行评审，不同文档的注重面不一样，与项目计划、需求分析之类的文档雷同，可以具体问题具体分析。

“设计类”就是测试构想，测试设计，执行方案，bug周期管理等。这些跟一线员工更加息息相关，多由设计人员、开发人员、测试人员共同参与评审。我觉得这种评审效率要高。文档格式、内容不用教条的与xxx体系一样，符合公司情况、项目情况就好，可以今后不断完善。
再一个就是“变更”的审查，需求、设计等的变更，要注意在测试文档的体现，这往往是容易遗漏地方，后期对于变更部分的审查也很重要，这部分审查往往体现在“设计类”文档上。

另一方，建议所有文档组内先自评，别错字连篇的就递交项目组。

海里的幸福

真幸运

海里的幸福

日出而作，日落而写作。