测试应当参与到软件的整个生命周期中，远远早于代码的编写阶段。首先需要检验的就是需求文档，为此而衍生的组织活动——需求评审。在项目的早期，消除需求中的缺陷能够大大减小开发和测试返工的代价；
1，缺陷预防是指在各种错误遗留到后续开发阶段之前，运用各种技术和过程，发现和避免这些错误；
2，可测试的对于一个需求，测试人员可以设计一个过程来执行所测试的功能，如果这个结果是可预期的，并且能够通过编程实现和人工方式加以验证，则该需求具有可测性；
测试人员需要彻底的了解产品，这不仅是需要了解软件的 “输入输出”，还要了解相应的业务背景、现实中的客户应用场景、客户的应用习惯以及产品设计的思想主题等内容，这些都是在对需求说明书的思考学习过程中了解的。除此之外，根据系统的立意主旨，考虑系统的边界，防止本该别的系统的需求放到本系统中来。
在充分了解产品主题及需求的基础上，进行测试计划、测试设计、测试过程、测试用例等设计时才会更加的出色；
越早发现需求中的缺陷，我们付出的代价也就越小：
1，质量测度标准：我们需要为每条需求建立一个质量测度标准，什么样的标准是满足需求的；
举个例子：“我们的系统必须够快”
那么系统怎么算快，不同的人有不同的理解，是响应速度在 10 秒内，还是说在 2 秒内，我们需要为够快定义一个可衡量的标准，这就需要需求的描述都精确；
2，非功能性需求
非功能性需求，并不赋予系统特殊的功能，但非功能性需求决定了技术方案的选择和存在风险区域，我们可以从以下几个方面来考虑：
（1）正确性
根据用户的需要进行检验，是否遵循一定的标准和规则？是否准确的反应了客户的需要，比如一些习惯操作等；
（2）完整性
主要是需要保证需求中不遗漏任何必须的元素。如：性能、安全性、可使用性、兼容性和可访问性等；
（3）一致性
验证产品需求有没有内部或外部的矛盾；如：需求定义了一个术语 “观察者”，但是在上下文当中，可以理解出不同的意思，没有清晰的定义，这就为后来的开发和测试带来了不便；
（4）可测性或可验证性
保证测试一条需求的可能性，同时结果是可预期的。如果一个需求是不可测试的，我们必须注明它的风险，同时应尽可能调整需求使其可测；
（5）可行性
在给定的预算、时间、技术及其他资源内可实现；
（6）必要性
每条需求是否与系统有关，按照系统的既定目标去衡量，考虑系统的边界，这条需求对系统的价值是什么？没有这条需求是否会影响系统实现其目标？
（7）优先级
我们可以将需求存在时的正面影响和负面影响各分为 5 个等级，两方面去评分，总和越高则优先级越高，如此对需求做出取舍；
（8）可追溯性
每条需求是否能够找到所有引用它的部分？对于需求的变化，我们能否找到所有受这种变化影响的部分，包含：设计、编码、测试、联机帮助等等；
需求就绪后，我们应当立即开展测试过程的设计，在测试过程的设计中，发现需求中的错误和遗漏点，明确需求中元素的定义，验证需求的可测性；
如果需求变化没有及时同步到开发、测试，则可能导致测试过程中测试与开发的冲突，
常见的原因有
（1）变更的需求没有形成文档；
（2）文档过期；
（3）开发错误理解需求；
需求变更应当经过组织的重新讨论，并评估变更带来的相关影响；
同时我们可以借助一些需求管理工具，跟踪需求的变化，同时保证需求的可追溯；
在现实过程中，可能会遇到以一个软件版本为基线，开发新的软件的情况，但原有的系统没有任何文档，例如：A 系统对接某个支付通道，现在公司打算整合所有的支付通道并形成支付服务，需要以 A 系统某个版本为基线去做新的开发。在这种情况下我们可遵循如下步骤：
（1）选用确定的基线程序版本；
我们必须选用某一个稳定的版本作为基线程序，并只把这个版本作为开发工作的起点，这样我们缺陷跟踪则更加直接，不用考虑基线程序的升级版本或修正版本；
（2）把现有程序文档化；
我们需要先梳理基线版本的业务逻辑并将其文档化。每个功能写一个段落，包括各种测试场景及预期的输出结果，并反映出系统的内部逻辑，这样我们可以在面对一个问题时确认其是否是缺陷，同时为将来的迭代版本提供参考依据；
（3）对基线程序的更新也应做好文档的更新
我们在基线程序的基础上开发新的程序的同时，原基线程序也可能在继续使用并持续迭代，对于基线程序的更新我们也应形成文档，以供后来的参考。
（4）从此实现有效的开发过程
对于新系统或原系统，从此应当遵守有效的系统开发过程，避免恶劣的软件工程发展蔓延下去；
本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明
