automation testing的case不应该太长

原因有三点：

1. 一个case太大，在前面部分的failure导致后面的部分没有执行到，降低了整个test suite的覆盖率。
2. 一个case太大，会让人花更多精力查找failure原因。
3. 一个case太大，常常有许多额外的setting动作。而如果case之间类似的setting很多，将会导致一个bug就让许多case被fail, 让人花很多时检查每个case失败的原因，其实都花在同一个bug上。而且当然地，会降低整个test suite的覆盖率。

所以case应该尽量小，且互相之间尽量少重复的动作，作为整体的test suite覆盖率要尽量高。

 

实际操作中，automate testting怎样协助减轻manual testing 的工作呢？如果直接按照manual test case 或者bug report来写 automation test case, 会有许多不必要的setting动作（在我的工作环境中，test case 和bug report都有相当详细的操作步骤）。我觉得可不可以用上一层的test plan呢？ 只要说这个 automation suite已经覆盖到了test plan的这部分，就不用再manual testing了。也就是说test plan有automation suite 和 manual testing suite两种测试方式。其实我觉得有了test plan已经足够， 太详细的test case对于熟练或者有经验的测试员反而是累赘。

 

一个构想：

用一组脚本创建基本状态。这些基本状态提供了进一步测试所需要的状态。在建立这些基本状态的同时也就相当于进行了基本功能的测试。而把特定的测试内容留给了脚本。问题是这一组脚本是怎么被调用呢？放在另外的文件里作为测试用例？作为测试框架的一部分？ 

如果这个建立基本状态的脚本失败，失败信息会log到这个建立基态的脚本。case可以选择其他的方法绕过这个失败。

 

额，讨厌要用几行代码反复做类似的工作。

 

automation框架应该完成的几桩事情：

底层：能够支持client-agent模式，能够得到所有被测控件的焦点，模拟鼠标和键盘操作。

         提供能完成一定任务的控件类。模拟鼠标的移动等。提示agent的运行。

中层：当控件的id或者字符串标示符改变时，不需要更改大量测试用例。所以必须有一层封装。

上层：同时提供一系列的方法或者模块或者类来完成常见的操作。方便测试脚本的编写。