测试用例个数代表什么？

　　Jams Bach在《软件测试经验与教训》一书中打了个形象的比喻来说明测试用例的个数并不代表什么：

　　如果拿出公司的所有箱子堆起来，并不会知道箱子所装东西的价值。如果公司有37个箱子，总重量是384磅，这能从什么方面说明公司的未来吗？不能。但是这些箱子所装的东西可能和公司的未来是密切相关的。因此要想知道价值所在，唯一的办法就是打开箱子，查看所装的东西。

　　其实测试用例就像箱子，只是统计箱子个数而不管里面的实际内容的话是没有什么意义的。因此，仅仅统计测试用例的测试通过率也说明不了任何问题。90%的通过率到底是好还是坏呢？如果不了解里面的测试内容的话，谁也不能回答这个问题。

　　同样地，统计执行得测试用例与计划执行得测试用例的比例也说明不了任何问题。因为也许最难执行的测试用例被推到了最后，或者最后的10%的测试用例需要50%的时间来完成，又或者计划要执行的那些测试用例其实远远不足以覆盖测试的需求，也没有覆盖重要的风险。

　　因此，衡量一个项目的测试设计是否到位，是否完善，并不能单从所设计的测试用例个数来衡量，还要真正看到测试用例里面的内容。要想让测试用例的个数代表点什么的话，我们必须进行测试用例的评审。

测试用例的评审

　　测试用例设计出来了，质量如何，如何提高测试用例设计的质量？就像软件产品需要通过各种手段来保证质量一样，测试用例的质量保证也需要综合使用各种手段和方法。

　　测试用例的检查可以有多种方式，但是最敏捷的应当属临时的同行评审。我认为同行评审，尤其是临时的同行评审，应该演变成类似软件开发中的“结对编程”一样的方式。从而体现敏捷的“个体和交互比过程和工具更有价值”，要强调测试用例设计者之间的思想碰撞，通过讨论、协作来完成测试用例的设计，原因很简单，测试用例的目的是尽可能全面地覆盖需求，而测试人员总会存在某方面的思维缺陷，一个人的思维总是存在局限性。因此需要一起设计测试用例，善用“集体智慧”、“群众的智慧”。

　　测试用例的评审要点需要至少包括以下几个方面：

• 测试用例对需求覆盖的完整性。
• 测试用例的有效性。
• 测试用例的清晰性。
• 测试用例的可理解性。
• 测试用例的可维护性。

　　除了同行评审，还应该尽量引入用户参与到测试用例的设计中来，让他们参与评审，从而体现敏捷的“顾客的协作比合同谈判更有价值”这一原则。这里顾客的含义比较广泛，关键在于你怎样定义测试，如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场人员或领域专家）；如果测试是指对开发提供帮助和支持，那么顾客显然就是程序员了。

　　邀请程序员参与测试用例的评审，就好比临战前的“演练”，测试人员是“剑”，开发人员是“盾”，如果开发人员能回答测试人员基于测试用例提出的所有问题，那么OK，测试人员要好好考虑是否应该增强自己的测试用例了，另外，开发人员回去可能也会好好考虑如何增强自己的程序在处理可能出现的异常和错误方面的代码，真可谓“一举两得”！
　　当然，在这种开发人员参与的测试用例评审中，也是一个暴露两方对于同一需求的不同理解的机会，通过评审和交流，能尽早达成共识，避免造成在测试执行和BUG修改阶段产生的“误会”。

小结

　　鼓吹测试用例无用论的测试人员可能并没有真正理解测试用例的意义，没有意识到测试之前进行“战略部署”的重要性，同时也很可能误解了敏捷测试、探索性测试的方法，把自由、随意当成了敏捷，把随机的、即兴的测试当成了探索性测试。

　　测试用例可粗可细，可建立完善的测试用例库，也可仅仅用一个Excel表来记录，但是一定要对测试进行“设计”，在与软件BUG进行的持续“战斗”中，一定要体现出测试人员的“智慧”来，相信“胸有成竹，则战无不胜”。