软件测试文档评审

软件测试文档评审

首先是需求文档

在系统开始开发之前，产品经理会根据收集到的用户意见和最终方案编写需求文档，编写完成后，要进行需求文档评审;说是评审，实际上主要是需求讲解。给开发们讲解业务知识、我们要做什么东西、为什么这么做、要做成什么样子。从这个环节开始，测试人员就应该介入进来。

因为需求文档是测试人员测试的唯一标准!

测试人员参加需求文档的评审的必要性：

1.测试人员也需要了解和学习相关的业务知识。

2.测试人员需要知道产品最终的上线目标是什么，来判断什么时候能达到交付的程度。

3.测试人员可以凭借经验对需求文档中的部分设计提出不同的意见。

4.测试人员可以凭借经验对需求文档中没有涉及到的一些异常情况和特殊场景进行讨论。

然后是开发文档

需求文档定型之后，开发经理会根据需求文档来编写开发文档。

开发文档的内容大概包括：开发模型、代码架构、代码规范、接口规范、数据库设计…

为什么测试要参加开发文档的评审?其实主要是去听测试人员需要了解系统的基本架构和实现原理，方便分析问题原因：

· 测试人员需要了解数据库表结构，对后续的测试很有必要。

· 测试人员可以提出一些规范性的要求，便于后面的测试。(比如要求前端人员尽量给所有前端组件加上id或name属性，方便自动化测试时定位元素)。

· 测试人员可以发现代码中缺少对某些异常场景的逻辑判断。

最后是测试计划

测试计划是测试人员的工作量预估，也是将来测试人工作考核绩效的重要依据。

测试计划的内容包括：测试范围是什么、分为哪些阶段、什么时间点完成什么、测试的具体内容列表(流程、功能、接口)、测试资源的成本(人/天)等等。

测试计划是测试人员的工作守则和规范。

但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。

所以测试报告中需要写明与测试计划产生偏差的原因，并计算变差量，分析偏差的风险。

最终的测试过程和测试结果还是以 测试报告 为准。