关于自动化测试方案选择的一些思考

关于自动化测试方案选择的一些思考

之前博主的大部分自动化测试经验在后台网关的协议和业务逻辑的测试上，以前公司的web application的功能也比较单一，电信的BOSS系统主要只是个数据展示，没有太多的交互功能。最近在做一个页面交互比较多，功能点多，渲染也比较炫的web application自动化测试方案。和后台的自动化测试经历是个不同的体念。有几点思考和大家分享和探讨一下。

---

用成熟框架还是自己开发

---

在后台的测试上，因为各个公司后台的业务差别很大，毫无疑问会用自己开发的的框架。但在web 自动化测试上，很多人会选择robot framework（QTP 应该现在没有人考虑了吧）。 使用robot framework 在处理复杂的判断时候,做二次开发和各个步骤之间传递变量还是很麻烦。 所以我采用的是折中的方案，吸收robot framework 好的模块，直接copy robot framework中的模块或者代码到自己框架里面。形成自己公司内部的框架，这样需要再一步定制化的时候非常方便，case成功率能大大提高。同时也可以定义自己的keyword 驱动

选择keyword driver还是data driver

---

其实对于会写python代码的人来说，使用keyword方式去配置、调试那些函数，输入参数，直接在data driver里面修改代码效率上也差不多。因为python代码好写啊，效率高。但选择基于keyword driver还是data driver方案还是要基于团队成员的技术水平去。

如果目前团队里面会写代码的人员足够能支撑目前自动化的case， 使用data driver的方案是比较好的选择，毕竟data driver 的方案在初期的开发工作量会比较小。

如果技术团队里面只有小部分人会写代码，大部分人不会，这种情况下采用keyword driver会是比较有效的方案。让会写代码的测试人员做好框架，可以让其他人根据keyword 框架的文档添加更多的测试用例。这样能把整个团队资源有效的利用起来。

在实际工作中可以两种方案有效的结合，既可以满足老板们的时间要求，也可以让不会写代码的团队成员帮忙配置起来部分测试用例

测试用例的组织

---

在web的手工测试里面，我们的原则是基本一个三级页面一个测试用例 ，然后在此测试用例里面列出所有功能点，测试点。但在自动化测试中，一个测试用例里面实现太多测试点，检查点，太容易因为测试代码的问题，或者时延的问题导致测试失败，这种引起的挫败感太强了。会严重挫伤别人对这个测试工具的信心。基于这种情形，我们还是需要对手工测试用例做一定的改进去适应自动化测试的需求。我们目前的方案是基本是一个测试用例里面检查2-3个功能点，超过3个的，拆分出来另外一个case.