你了解软件测试的流程吗？

测试的过程并不是固定的，会灵活变化。它只是一种规范，也可以把它当作一种指导。app上讨论软件测试时，经常会提到：项目测试和产品测试一定是不一样的。

产品测试一定有非常完整的发版计划，有充足的的时间，有充足的资源进行协调，即使因为一些特殊的原因未能按时完成发版计划，也可以进行延期。产品测试都会尽量的去进行完成的全级别测试。

项目测试一般时间都非常紧，资源有限，发生意外的情况很多，任务时间都是被极度压缩。到目前为止汇才创智经历过大大小小几十个项目，有的时候并不能按计划时间充足地上线。所以项目测试一般会大量的精简测试过程，甚至为了按时上线做出一些牺牲，牺牲掉一些不重要的功能，来优先保证重点功能、常用功能。

一、文档评审

首先是需求文档。

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

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

将来做测试的时候，如果开发做出来的东西和需求文档里写的、画的不一样，都属于BUG！如果开发说是需求改了或者说是产品经理说的，那么抱歉，请修改需求文档！所以，严格来说，测试人员在测试时只认文档不认人。可能有人会说，那这样测试人员就没必要参加评审了，直接等文档就行。

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

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

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

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

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

然后是开发文档。

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

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

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

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

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

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

最后是测试计划。

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

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

测试计划是测试人员的工作守则和规范。但是产品的诞生过程中，免不了出现各种各样的特殊情况，所以实际的测试可能会跟测试计划有所出入。所以测试报告中需要写明与测试计划产生偏差的原因，并计算变差量，分析偏差的风险。最终的测试过程和测试结果还是以测试报告为准。

关于更多内容，可以关注“汇才创智”微信公众号。