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