一直在想，如何把自动测试做的更简单，更流程化，更傻瓜，实现通过自动测试节省成本的目标。

先分析一下当前自动测试的问题。

问题一，录制和编写脚本的效率低下。

这个问题的根源在于，很多自动测试工具的同步点设置，特别是自动设置是很差的，缺少了一些“智能”。举个例子，我们来click一个button，正常都是正确的；如果在脚本执行过程中，上一个动作出发了UAT的一个响应，如果这个响应没有结束，这时候click是无效的。那么，我们自动测试工具好自己来判定：什么时候来发送“click”操作！这是一个原因。

还有一个原因，一个组件不规范，录制不成功，需要做特殊的处理。因此，需要程序员编写一个“封装函数”，所有的人都来调用这个封装函数来完成功能。这时候，脚本不是录制出来的，而是需要我们来编写。如果测试工程师没有编码能力，那么无法提升效率了。
还有一个原因，界面有控制逻辑。一个操作的录制，发现很多组件被disable了，根本无法录制下来，因此一个功能界面需要多个测试脚本，这无形中增加了编写测试脚本的工作量。

后一个原因，错误处理。当测试脚本执行错误，我们需要一个错误处理程序。菜鸟程序员会把错误处理写的到处都是，比脚本还多，后不可收拾。因此，我们需要来标准化的处理错误。

问题二，如何测试面向业务流程的用例。

目前的测试工具是“愚蠢”的。它告诉我们：用function封装一个action，然后函数调用。这是一个傻瓜的办法，糟透了。这是后，应该有一个标准的方法，来进行BPT的处理，让每个脚本尽可能简单。

这个的答案，是自动测试框架。当然，自动测试框架是一个概念，但是没有人真正定义过它：

1）能够通过配置的方式配置测试脚本；
2）支持测试脚本库的管理；
3）能够识别与脚本相关的参数化；
4）能够管理测试数据；
5）能够管理测试脚本顺序执行；
6）能够管理在自动测试执行中的数据传递；
7）能够帮助自动测试执行准备数据；
8）能够调度脚本执行；
9）能够捕获、处理脚本中出现的错误；
10）能够记录自动执行的过程；
11）能够预约执行。

问题三，有自动化测试用例设计方法

这个下一次再谈。

 

版权声明：本文为泽众软件wonder原创作品，未经明确书面许可，任何人或单位不得将其镜像、转载、复制，否则将追究法律责任。