迁移文章槽神也说自动化测试有效性( 二 ) _测试脚本

总之，我们对自动化测试有什么样的期望，就应该有什么样的目标和要求；设定了什么层次的测试目标，就应该有什么样的使用效果。如果告诉你自动化测试可以朝着任意品种的狗狗去培养，目标就是看家护院，你非要以哈士奇食量大喂不起为由非要选小泰迪，那能有什么办法呢？如果自动化测试分析设计不严谨，而已覆盖的脚本也没有严格编写，而或脚本严格编写却并未善加利用，那么自动化测试自然就是一个彻底的谎言了。
我们可以期望用自动化测试来暴露所有的问题供使用者抉择，而非用来精确定位每一个问题。即便我们不期望自动化测试发现所有的BUG，但是我们必须要用发现每一个BUG的标准去分析设计和利用我们的自动化测试用例。
方法之一：善用手动测试用例库
如果有完整或近乎完整的手动测试用例库，在做自动化测试的时候用它来甄别自动化测试范围、做自动化测试需求分析和设计是非常棒的，可达事半功倍之效。因为除了SLA签订的关键功能清单，我们可以分析测试用例库中最近X个月、Y个版本中被执行的测试用例的频率和比例等等数字，从而很容易得出最有价值做自动化测试的范围，而如有其他因素也可以加入综合评估。这时候，关联或映射手动测试用例和自动化测试脚本可以很容易地衡量自动化测试的覆盖率等相关指标。
除此之外，手动测试用例之于自动化测试开发的意义还在于一种特定模式下的自动化测试开发：测试人员按照一种特定的规约编写产品或项目的手动测试用例，随后用一种模型化的转换规则去生成自动化测试脚本，继而再去修改和优化。这种模式的好处是，自动化测试脚本的开发者不需要懂业务知识，只需要按照业务测试人员编写的详尽的测试用例去实施。而不足之处却也十分明显，由于思维方式上的差异，编写测试脚本过程中的沟通成本不会太低，而且对建模水平要求很高。
方法之二：搭建适应性强的框架
开源测试工具，我们组先后用过 RC、、WatiJ这几种工具模式，框架采用JUnit和，测试调度和CI使用管理。做起来最大的感受就是，像这种工具，它本质上是为互联网而生；如果要用于我们的企业ERP应用的自动化测试，如果没有做一系列适应性的API和组件封装，测试脚本开发对于大部分同事来说都是件头疼的事情。
经过摸索，我们结合PAFA（）架构的前端页面特征做了对象识别、页面加载和处理缓冲、运行监听、数据处理、断言和运行容错、报告、日志以及第三方组件（如、Cmd等）兼容的封装操作。这种封装属于Bot-Style，适用于我们基于业务操作驱动的自动化测试用例编写，能够大大地降低我们测试脚本开发的技术成本。虽然它们看起来运行起来效率并不是十分高，但是对于被测应用的响应速度来说已经是数十倍的效率胜出了。至于使用Page 还是Bot-Style，还请大师们不要吐我的槽，这没什么可争论的，因为这只是面向前端业务操作的页面测试，二者的表现毫无优劣之分，完全在于队员的测试脚本编写风格偏好。

文章插图
附图1：测试中的样例

文章插图
附图2：测试中的样例
我们正在从瀑布开发模式下逐渐开展持续集成和敏捷转型，不难预见，达到一定成熟度之后我们大部分团队会使用ATDD或BDD模式。这种快速开发的基于前端的自动化验证测试虽然在验证测试中所占的比例会越来越小，但它们将依然有用武之地，同时对当下的系统前端的回归测试也可以完全支持。

迁移文章 槽神也说自动化测试有效性( 二 )

迁移文章槽神也说自动化测试有效性( 二 )