最近转到一家公司，对质量经理的职责有了更广泛的定义，即同时负责需求的设计。在这种情况下，引入TDD（测试驱动开发）这种开发模式。在TDD下，如果我们再按照系统测试用例的编写方式去设计用例，将出现大量的遗漏。我们在进行测试用例的设计时，需要进行一些针对性的步骤设计以及必要的冗余用例设计。
要体现出表操作
开发时，功能开发与涉及到列表、数据显示与查询页面无法同时完成。所以功能涉及到的表操作，我们几乎没法通过页面查询来判断。此时，功能实现中涉及到的数据库表操作应该在用例步骤中体现出来。否则开发人员在对数据库表结构不是非常熟悉的情况下，会导致一些该做的表操作并没有执行。
要覆盖到所有流程分支
在由多个子系统组成的系统中，如果我们仅仅针对于场景做系统测试用例，会导致一些流程分支覆盖不完全。区别于场景设计，此时应根据具体可能出现的情况分别针对性设计用例。而不应按黑盒的基本概念，不关心里面的内部逻辑来设计用例。同时，我们需要在用例中体现出内部的通信处理方式，比如同步和异步通信处理。
边界设计，需要给出具体的边界判断方式，而不仅仅是测试数据
在黑盒测试用例设计时，我们设计用例往往只给出了测试数据，这些数据可能就是根据边界判断方程式得出的（如A-B
当需求发生变更时，测试用例要及时更新
当需求发生变更时，应及时对测试用例做更新。同时要把更新的用例以某种项目的方式标识出来，并确保将其通知到对应开发人员。
可能情况下，设计单元测试用例
如果要让程序员更加受益于TDD开发模式。那我们可能引入单元测试用例的设计。这样，程序员不会去关注具体的业务逻辑，只要根据单元测试用例，把对应的功能一一实现就OK了。这个仅仅是作者本人的猜想，还没尝试过这样的方法。
总之，TDD模式开发，测试用例设计应区别于以往的黑盒用例设计。要尽可能的去覆盖流程分支，从而避免遗漏。