按照尽早进行测试的原则，测试人员应该在需求阶段就介入，并贯穿软件开发的全过程。
就测试过程本身而言，应该包括以下几个阶段：
- 测试需求的分析和确定
- 测试计划
- 测试设计
- 测试执行
- 测试记录和缺陷跟踪
- 回归测试
- 测试总结和报告
该阶段就是一个PDCA循环，是一种质量改进模型。P（plan）代表计划，D（do）代表执行，C（check）代表检查，A（action）代表处理。
测试需求
对于需求文档，应遵照尽早测试的原则，对其进行测试。
通常，需要检查需求规格说明书的以下几个方面，来衡量需求规格说明书的质量：【检查要点】
- 正确性：对照原始需求检查规格说明书
- 必要性：不能回溯到出处的需求可能是多余的
- 优先级：乔当地划分并标识
- 明确性：不使用含糊的词汇
- 可测试性：每项需求都必须是可验证的
- 完整性：不能遗漏必要和必须的信息
- 一致性：与原始需求一致、内容前后一致
- 可修改性：良好的组织结构使需求易于修改
需求规格说明书的检查步骤：【检查步骤】
- 获取最新版本的软件需求规格说明书，同时尽量取得用户原始需求文档
- 阅读和尝试理解需求规格说明书中描述的所有需求项
- 对照需求规格说明书检查列表进行检查并记录
- 针对检查结果进行讨论、修订需求规格说明书后回到第一步，知道检查列表中所有项通过
方法一：通过需求规格说明书检查列表进行检查：【检查列表】
- 满足要求则选择是，不满足则选择不是，某项在本次检查或评审中不适用则选择NA
- 实际使用该列表项根据该项目的实际需要进行删减、修改和补充，并在说明一栏填写评估检查项是否通过的依据和说明检查项的审查目的等内容。
方法二：通过编写测试用例来检查需求
测试人员通过构建并尝试回答设计的黑盒测试主要为了测试需求的完整性、准确性以及简明性等需求问题。
在进行环境测试时，首先需要知道软件系统将来的使用环境，然后尽量模拟这些可能出现的使用环境进行测试。当尝试在需求文档中找到详细的运行环境时，可能会发现这一部分的需求不够完整，在进一步编写环境测试的用例之前，必须解决这部分需求文档的完整性问题。
举例：假设软件产品已经存在
测试用例编号：Input_001
测试优先级：中等
估计执行时间：2分钟
测试目的：验证业务单据数据的查询正确性
标题：业务单据查询
步骤：
- 打开查询界面
- 输入查询条件
- 确定并提交查询
- 查看并验证返回的信息
按照这种初步设计的测试用例对产品进行“预演”测试，测试人员会发出很多疑问，例如：可输入的查询条件包括哪些？提交查询之前是否会验证输入数据的正确性？输入数据的单位、范围有无限制？所有条件都不输入是否意味着能查询出所有业务单据？对于这些疑问，如果在需求文档中不能找到令人满意的答案，则可以认为需求文档的完整性、准确性、可测试性都存在缺陷。在进一步编写测试用例和测试之前应该解决需求文档的这些问题。
