测试与需求的关系

时间: 2017-04-12    来源: 楚凡科技

•  Testing without stated requirements 没有特定需求下的测试：测试以需求为基础，测试满足需求是我们理想中的目标，然而实际中，测试员的工作不仅仅是测试系统是否满足需求，更重要一点就是确认产品的需求，也就是测试人员将进一步确认需求是否合理正确。  因为，往往由于需求的不完整性和不清晰性，所以测试不能仅仅是一个确认过程，同时还是探索需求和确认需求的过程。因此，测试不仅可以没有特定需求，而且在需求不确定的情况下特别有用。因此说：测试不是一种机械的过程。通过测试和开发的合作会产生巨大的价值。同时，在项目中，测试应该和需求同时开始，这样方便有经验的测试员通过他们对未定需求的理解来评价产品需求，一个好的测试员会对特定需求的差距始终保持警惕，并且解决这些差距到一定的程度：可以有效控制特定情况下的风险。
•   Satisfying stated requirements 满足特定需求：如果每一个特定的需求项都是产品的真实声明，然后我们把产品质量定义为这一前提的延伸。那么软件产品必须满足它的特定需求这一观点是成立的。上面的观点前提是我们有非常清晰和完整的需求集合，否则，你将被锁定在一个很窄的质量范围内。  如果提前借入测试，我们则可以通过正向从需求入手加上反向从测试入手去同时确认需求。
•  Tracing test cases to requirements 把测试用例跟踪到需求：需求如果要发挥作用，则测试与需求之间应该有所关联。谈到可追踪性，通常摘要为： 为每个需求项ID，列举关联的测试用例的ID；为每个测试ID，列举关联的需求ID。测试的完整性被大概地通过“对于每个需求项，至少有一个测试用例关联”来估计，前提是我们的需求非常明确，对产品的表达准确无误，这是一个很理想的观点。如果可追踪性的目的是用于证明测试策略已经验证了产品的需求，那么我们应该能解释我们的测试与需求之间的关系，重要的是需求和测试是如何关联的，并且随着产品风险越高越重要。明确的需求在很多领域其实是存在的，因此在这些领域需求到测试用例跟踪是非常有必要的。
•  Stating requirements in testable terms 在可测性方面衡量需求：需求有意义是非常重要的。这个观点强调除非我们能够度量是否成功，否则我们永远不能知道我们是否完成测试。事实上，尝试通过简化需求说明甚至更高一级结构化表达需求，也就是我们将自然语言描述的需求转换为更加严谨和专业化的需求项，从而增强需求的可测性，减少测试人员的理解偏差。