用例是的基础，是测试人员和开发团队其他成员深入了解产品开发需求的介质之一，也是产品质量的保障。因此合理设计测试用例不仅有助于掌握客户的产品真实需求，使得研发团队所有人员对需求的理解处于同一平面上，也确保产品在整个动态的研发过程中，始终符合用例的设计，实现用户最终期望的功能。
在传统开发模式中，需求分析往往占用较长时间，分析阶段由核心的开发人员和测试人员参与。在进入研发阶段后，将需求传递给其他开发和测试人员，测试人员根据需要在设计完测试用例和开发完成以后，进行各种类型的测试。这样的结果往往由于测试人员没有参与最初的需求讨论，因此对需求的理解存在一定偏差，很多用例的编写基于测试人员的假设。而且因为开发周期较长，最终交付的功能已经发生改变。
在开发模式中，测试人员和开发人员的节奏是同步的，即开发人员增量地开发功能的同时或甚至之前，测试人员也增量地设计相应的测试用例，等功能完成后马上可以对功能性测试。对于还未开始开发或者需求暂不明确的功能，不进行测试用例的深度分析。这样就能把更多的精力投入到最重要功能上去。
在中，需求一般以用户故事的形式存在，是将用户的需求用实例或者故事的方式记录到待办事项列表中（backlog）。 测试用例和用户故事之间是紧密关联的，在产品经理（PO）设计、解释完成用户故事后，测试人员根据用户故事设计测试用例。测试用例可以是对用户故事验收标准的细分，也可以把多个用户故事进行串联形成一个用例，这取决于用户故事和测试用例设计的粒度大小。由于用户故事会随着需求的细化和拆分，因此很难对用户故事和测试用例做一一对应，而且后期维护成本较高，因此需要在用户故事和测试用例中增加模块属性，来管理测试用例和用户故事之间的关联关系。而且两者应该在一个统一平台进行维护和更新。
对于非功能性的测试用例，往往并不关联具体功能模块，但是会有对应的用户故事，例如：性能需求，安全需求等，建立这类测试的测试用例的时候，可以通过建立性能模块，安全模块等并不存在的模块，和其他用例等同处理。
敏捷的其中一个非常有用的实践是测试驱动开发，这需要开发人员编写，在单元测试过程中，对于复杂逻辑的函数或者组件，也需要设计单元测试用例。这些测试用例本身不以实际文档的形式存在用例库中，往往和测试人员一起讨论并参考测试人员设计的测试用例来进行编写签入到单元测试中。因此做测试用例个数统计时，需要包括单元/组件测试测试用例数量，或者为单元测试/组件测试单独设立统计指标。同时没有特别必要和模块或者用户故事做关联。
最新内容请见作者的GitHub页：http://qaseven.github.io/