自动化测试框架的选用

一、自动化测试

       众所周知，软件测试按照不同的分类方式，可以划分成多种。如果按照是否执行手工划分，可划分为手工测试、自动化测试。自动化测试进一步细分的话，从软件开发周期的角度可分为：单元自动化测试、接口自动化测试、UI自动化测试（web自动化、移动端自动化）；从测试目的的角度可划分为：功能自动化测试、性能自动化测试、安全自动化测试。

二、预期收益

维护自动化会花费一定量的时间及人力成本，预期换来的收益效果是什么？

1.冒烟准入：自动化测试结果，作为准入冒烟case的参照标准，以确保老业务功能的畅通

2.全量回归：协助上线前的全量回归，提高测试效率，节约手工测试时间、人力成本

3.生产回归：线上环境全功能回归，监控线上功能畅通

4.额外收益：测试环境执行自动化测试，检测排查测试环境的问题

三、自动化适用领域

切记：不是所有的系统都适合做自动化测试！！！

如果不能做自动化测试的系统，没必要硬上，毕竟强扭的瓜不甜，否则有可能竹篮打水一场空~

什么样的系统适合自动化测试呢？且看下图所示：

项目中，接口测试的ROI（产出投入比）要比UI测试高，因为接口层相比于UI层的稳定性高、可复用性好、存在周期长。

四、现有框架

1.无需写代码的自动化框架

• JMeter + Ant+ Jenkins

3.需写代码的自动化框架

• python版：requests + unittest
• java版：httpclient + testng

4.其他框架：

• pytest版接口自动化测试框架
• Robot framework接口、ui自动化测试框架
• web端ui自动化测试框架
• app端ui自动化测试框架
• 性能自动化测试框架

五、框架对比

RF框架：

• 属于半懂代码，懂接口的结构体就易上手的测试框架，测试人员使用成本低
• 关键字驱动测试，扩展性高
• 功能完善，支持跨平台
• 有界面，交互体验好
• 可生成测试报告及清晰的Log报告
• 用例编写类似填写Excel表格的易上手，但操作起来并不够友好
• 尤业务层系统的接口自动化测试，参数设置过多，业务逻辑复杂，响应结果校验偏多，设置编写会存在诸多的填写工作量

TestNG框架：

• 需懂代码的测试框架，对于测试人员要求高一些
• 涵盖单元测试、功能测试、集成测试等，覆盖面广
• 基于Annotation（注解）机制，测试方法更灵活
• 支持多线程，效率高
• 自动生成html、xml格式的测试报告
• 可以测试依赖性，又可以任意顺序运行测试用例

六、框架选择

       公司项目采用的微服务架构体系，后端方向主要由java代码实现，对于搞起自动化方面，测试团队结合自身状况及项目业务状况，对于框架选择做了如下考量：

1. 业务版本迭代快，导致UI层面稳定性差、变化快、可复用场景不多，暂不考虑UI自动化测试
2. 业务系统主要对外输出接口，考虑到整体测试人员的能力水平以及易于上手、易用性方面，进行接口自动化测试优选RF框架
3. 中台系统逻辑较为复杂、场景较多，为了提高测试颗粒度，进行单元自动化测试优选testNG框架