一直以来大家讨论很多自动化开发语言，讨论很多性能测试工具，讨论很多自动化测试工具。但是却对所有测试活动最重要的输入——测试用例，讨论甚少。为什么？也许是因为测试用例的质量如何评估没有好的标准，或是写测试用例的工具很简单，就是一个文本编辑器，随便抓个人都可以写测试用例。或是有的测试经理自己都对测试用例的质量没有更多地去思考，没有去不断加强修炼。一心只迎合项目经理的进度要求，用测试用例数量来向项目经理邀功。误认为：测试用例数量越多，测试做的工作就越好。这种情况就属于前人云“有数量无质量，还是等于零”。直接导致后续的测试活动质量低下，甚至导致所有的测试决策都建立在了错误的数据基础之上，产品失败的风险加大。这时可能会有朋友说：“测试用例写的差，我们的产品不一样可以发布，一样在市场上运行和销售。” 针对这种情况，我的分析是：如果我们没有正确的有技术含量的测试，只依靠人力资源的数量和时间投入，经过一系列的加班，苦干，进度延长，还是可以推出一款勉强满足质量要求的产品。但是，如果我们有高质量的测试用例，或许我们就可以使用更少的人，更少的时间就达到了满足质量要求的产品。高质量的测试用例就类似一台推土机，低质量的测试用例就类似一把铲子。虽然我们可以靠人海战术，加班奋斗来铲完所有泥土，但是我们也可以用推土机用更少的人更快的搬完所有泥土。选择哪一种？大家心中有自己的答案。我的观点是：有人才，有条件做到高质量测试用例的公司，应该尽可能在提高测试用例质量上投时间投资源从技术上来改进。如果没有人才，没有条件做到高质量测试用例的公司，只有一个办法了，那就是用人海战术和奋斗来愚公移山了。只是后一种情况，对测试从业者是一种悲哀，也给了外行看不起测试的一些借口。
如何设计好的测试用例，在网上有着各种理论和标准，并且大家也有自己的一些认识和感受。在这里，我只补充一些以前可能网友们没看到的新观点。不知大家注意没有，本篇文章，一直只说测试用例质量，没有说一个测试用例的质量。那是因为，我认为测试用例的质量，其实全称应该是测试用例库的质量。测试用例库的质量才决定测试活动质量和测试活动的效率。
测试用例库的质量最基本的要素有2个：1、测试用例集架构的质量；2、单个测试用例的质量。
1、测试用例集架构的质量：是指你的测试用例库中的测试用例集是否包含了所有的质量属性所需要的测试用例，例如：是否有专项的可靠性测试用例，性能测试用例，压力测试用例，兼容性测试用例，可移植性测试用例，可维护性测试用例，可用性测试用例，安全性测试用例等。
2、单个测试用例的质量：网上有很多建议了，我就不列举了。补充一些常见测试用例缺陷概率高的问题——测试用例理解二义性，测试用例描述前后不一致，测试用例不具有可实现性，测试用例易用性差，测试用例的测试结果不唯一。（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自架构师Jack的51Testing软件测试博客：http://www.51testing.com/?293557
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
