纵观海外软件测试行业，从2001年起头，测试人员及测试主管经常研究测试用例的编写方法。以为编写了测试用例就可以做好测试责任。其实不然。测试用例只是用来抵达测试掩饰和进行测试阅历积累的一种手段。
我们部门从2002年起头起头测试用例的编写责任，但直至2004年，测试用例对实际的测试责任并没有带来明显的效果，反而造成责任量上的增加和资源糟践。由于，一直以来，已经编写好的测试用例并没有细心地执行和掩护。这不是测试用例本身的问题，而是测试管理者的失误!
为什么我们一直以来都对测试用例表现出不好的态度呢?
分析原因，有四：
1。首先是资源投入的问题。测试团队的人数不够，将直接引发责任量问题。而测试用例又是一件要求非常细致的责任。
2。开发测试用例所需要的技术知识。测试用例的设计离不开技术(只管在有些状态下可以不需要)，但以后的测试团队并没有好的技术基础(如编程阅历，设计阅历等)。另外，与开发组和产品需求规划组的替换也不顺畅。导致测试用例的设计很片面，且太过于主观(纯粹靠设计人员的阅历)。
3。对测试用例的理解过于软弱。为什么这么说呢?由于QC是一件非常复杂的责任，事情多且杂乱(特别是在开发流程不规范的组织中)，测试主管们很随便掉进“为了设计而设计”的陷井。测试用例的编写过程和质量，并不是“测试用例责任”的全部，测试用例的执行、掩护才是这项责任的重点。
4。测试主管们对测试用例的期望值过高。测试用例编写出来了，也执行了。但它究竟是一份文档，是死的，我们需要活用它。也就是说，测试用例还需要一个相配套的应用策略。比喻，对某个软件版本的的测试，根据实际的项目状态(如测试时限，人员及其水平，主旨软件的品质等)对测试用例库进行筛选和打包，这样才能较好地实现测试用例的效果。
文章来源于领测软件测试网 https://www.ltesting.net/
