我们部门从2002年开始开始测试用例的编写任务，但直至2004年，测试用例对实际的测试工作并没有带来明显的效果，反而造成工作量上的增加和资源浪费。因为，一直以来，已经编写好的测试用例并没有认真地执行和维护。这不是测试用例本身的问题，而是测试管理者的失误！
为什么我们一直以来都对测试用例表现出不好的态度呢？分析原因，有四：
1.首先是资源投入的问题。测试团队的人数不够，将直接引发工作量问题。而测试用例又是一件要求非常细致的工作。
2.开发测试用例所需要的技术知识。测试用例的设计离不开技术（虽然在有些情况下可以不需要），但当前的测试团队并没有好的技术基础（如编程经验，设计经验等）。另外，与开发组和产品需求规划组的交流也不顺畅。导致测试用例的设计很片面，且太过于主观（纯粹靠设计人员的经验）。
3.对测试用例的理解过于单薄。为什么这么说呢？由于QC是一件非常复杂的工作，事情多且杂乱（特别是在开发流程不规范的组织中），测试主管们很容易掉进“为了设计而设计”的陷井。测试用例的编写过程和质量，并不是“测试用例工作”的全部，测试用例的执行、维护才是这项工作的重点。
4.测试主管们对测试用例的期望值过高。测试用例编写出来了，也执行了。但它毕竟是一份文档，是死的，我们需要活用它。也就是说，测试用例还需要一个相配套的使用策略。比如，对某个软件版本的的测试，根据实际的项目情况（如测试时限，人员及其水平，目标软件的品质等）对测试用例库进行筛选和打包，这样才能较好地实现测试用例的效果。
