在上年的时候，我曾经把测试用例比喻成盾，而把测试比喻成剑。（http://www.testingreflections.com/node/view/3041），我仍然相信测试用例的创建会有两个用途或目的：
1） 测试用例被认为是要交付给顾客的产品的一部分。测试用例在这里充当了提高可信度的作用。典型的是UAT（可接受）级别。
2） 测试用例只作为内部使用。典型的是系统级别的测试。在这里测试效率是目的。在代码尚未完成时，我们基于设计编写测试用例，以便一旦代码准备好了，我们就可以很快地测试产品。
在转向敏捷开发的过程中，第二条失去了它的价值。我在我们公司和其他公司都看到了这样的事情。看起来要变成以下的方式：
a） 测试用例被内部使用，但是目的是可信度，而不是效率。也意味着测试用例会在测试执行过程中被不断修改和重写。
b） 探索性测试会取而代之，不写测试用例
我不回进一步去探讨a）的方式，因为很明显这种是很不可靠的测试管理 – 你不能使管理层相信这是低效的利用资源的方式。也有一些时候，测试用例被创建只是用于报告测试进度。比如说，我们有80%的测试用例编写了，而其中70%通过测试。我已经在抨击这种方式，并且还会继续抨击它。因为这是典型的用缺陷数字来衡量质量，用测试用例个数来衡量测试进度的错误方法。
上面两种方式是否正确依赖于我们是否需要可重用的测试用例。我相信回归测试用例的编写和自动化测试脚本的编写有很多共同点。甚至可以说它们有3个级别：
1、 纯探索性测试
2、 执行编写好的测试用例
3、 执行自动化测试脚本
从上到下，设计所需的时间要不断增加，但是测试执行的时间不断减少，因为自动化测试可能仅会验证你在脚本里写好要验证的东西，那就意味着你要预测什么缺陷会出现。而在手工测试过程中，你可能看到间接的证据表明存在某些缺陷。测试用例越详细，测试人员已经测试的时间就会越多（现在会执行得更快了），能找到那些间接验证的问题的可能性越低。
讲了这么多理论，现在来点实践性的东西。我在新项目是按下面的方式做的：
首先，我会找出所有在第一个版本中界面自动化失效的地方。这可能会与那些只发布一次的项目不一样，但是我在那些方面没有什么经验。当然单元测试像JUnit执行指定的API函数也会很有用，能被开发人员很好地创建，但是测试人员有时候也应该帮助一下他们。
接下来，在测试执行周期中，我不会写任何测试用例。我只会在版本发布后更新测试计划，详细地写出被测试功能特性的列表，以及对应有哪些功能特性不生效、对应的缺陷ID。在版本发布后，我创建详细的测试用例文档描述怎样调用每个功能特性，输入什么数据等等。看起来像是文档，但是有着不同的目标和用途：目的是让回归测试执行更快速进行。例如，我把数据附加上去，从而减少准备数据的时间；我细化一些琐碎的测试用例，测试人员（新手除外）会添加错误处理的一些细节。
我尝试使用测试白板（Testing Dashboard）去替换正式的包含测试用例执行/通过/失败/未执行等信息的测试报告。有时候，我只是通过非正式的所谓我的感觉之类的东西来沟通进度，而这其实是PM（项目经理）想要知道的，而不是测试用例的数字。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
