先说说现在这个科室的用例发展历程吧！

　　我初来时，界面测试用例以及有关控件的基本常性用例与功能测试用例、业务逻辑测试用例杂合在一起，用例数量极其庞大，一个小小的系统至少上千的数量，用例开发时间很长，而执行测试时为了提高覆盖率，每轮测试时所有用例都要做，测试时间相当长，当然那时项目少，还勉强可以。

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

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

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

　　这种策略，在我刚进用例设计小组时曾提出过建议，只不过当时科室老一辈的强烈抗议和阻制了它，找的藉口和理由，现在觉得挺靠谱的。还好，近科室老一辈的都跳走了，现在用例设计剩我一个人了，各个Leader都是同年，比较支持我的做法，在近项目上实现这种方式，发现并没有传说中的那么困难和麻烦，在用例设计的时间减少了不少，并且在执行中也还相当可行。

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