有关测试用例的感慨

M4iF:y_QZ|-I0先说说现在这个科室的用例发展历程吧!51Testing软件测试网'`3d5e @IGSd}u

#ud-G K+^;G9b0我初来时，界面测试用例以及有关控件的基本常性用例与功能测试用例、业务逻辑测试用例杂合在一起，用例数量极其庞大，一个小小的系统至少上千的数量，用例开发时间很长，而执行测试时为了提高覆盖率，每轮测试时所有用例都要做，测试时间相当长，当然那时项目少，还勉强可以。51Testing软件测试网 j
O h'~G })x

后来，项目多了起来，发现这些用例能发现的Bug率相当低，测试人员在测试的时候甚至根本不看这些用例，甚至有些时候，跑着跑着火就起来了，老大搞了一个设计用例组，专门来解决这个问题。讨论了很久，就搞了一个基本用例检查表出来，让我们在设计用例过程中遇到界面测试以及有关控件的就套用。这样一来，用例数量看上去少了很多，但实际数量并没有减少。不过还是有好处的，在用例开发时间上，却实减少了很多51Testing软件测试网 TvV ZJ+u

_0cwgW(|8s}x0当检查表在用例中大量拓展时，项目Leader反应，有些测试人员基础差的看不懂，有些测试人员在执行时根本不打开检查表就进行了测试，而且这样把检查表套用在用例中，没有减少执行的时间，效率并没有得到提升

基于以上现象，这几次的用例设计，我把界面测试用例与控件测试等用例单独放入一个模块，采用 界面测试、控件测试、键盘测试用例+功能、业务流程测试用例的方式来设计用例，期望通过策略来减少在界面测试、控件测试、键盘测试用例上花费的时间，增加功能、业务用例执行的时间，把主要精力投放到这一块。51Testing软件测试网/w@0p
h'V7@

^@e"f^'t/~TVL0这种策略，在我刚进用例设计小组时就曾提出过建议，只不过当时科室老一辈的领导人强烈抗议和阻制了它，找的藉口和理由，现在觉得挺靠谱的。还好，最近科室老一辈的都跳走了，现在用例设计就剩我一个人了，各个Leader都是同年，比较支持我的做法，在最近项目上实现这种方式，发现并没有传说中的那么困难和麻烦，在用例设计的时间减少了不少，并且在执行中也还相当可行。51Testing软件测试网bE&fb{.J(K

本来期望用例架构，采用界面、控件、键盘等基础性用例+功能测试用例+业务逻辑用例分开来设计，但从我提出这种概念之后，各个Leader也并不是很支持。另外，其它用例设计人员也不知道该如何下手，也不太同意。哎，看来我又得做尝试了！51Testing软件测试网y~PvQJ THu

qwen 2010-5-12