轻量级自动化框架探索

为什么80%的码农都做不了架构师？>>>   

轻量级自动化框架解析

如果公司要进行scrum，那么自动化测试就是scrum的基石，因为scrum的迭代整度很快，如果每一次的迭代都需要手工的进行测试，那是来不及的，这时如果自动化能够帮忙解决一部分，将会给测试人员节约大量的时间，而自动化测试也是需要成本来维护，自动化测试稳定，维护成本低的关键在于测试框架的好坏，本文谈一谈自己搭建的一个框架从而梳理一下各个模块之间的关系。

Introduction

我司是一个网络安全公司，并不是人们说的互联网，而是一家网络设备厂商，因此IP转发在我们产品中占据很大的部分，又因为我们是一家安全公司，因此我们产品覆盖了OSI的L2~L7，应用非常广泛，早先网络厂商的用户界面都是以CLI为主，犹其以cisco最为有名，华为，中兴其次，但在互联网的大环境中，越来越多的产品的用户界面都做成GUI，因此我在设计自动化测试时选择了从WEB入手，进行GUI自动化测试，伴随着RestFUL API完善后会转入接口测试，我司自动化测试的基本准则是开源，低价，轻量，快速，稳定，这使得我选择自动化框架有了一个依据：

1. OS： ubuntu 兼顾图形与CLI，虽然我更喜欢无界面管理，但是GUI部分还是ubuntu做的更好一点
2. GUI ：GUI测试选择了市需上最通用的selenium作为工具模拟人工点击页面，由于价格和开源的原因放弃QTP
3. Function： 功能部分的测试原本属于接口测试，但由于我们产品的独特性，我们可以用测试仪表来模拟客户端和服务器端之间的通信从而完成功能方面的测试，可以选择的有思博伦的avalaunch， IXIA等仪表厂商，但这些仪表都是百万级别的价格，因此我选择了cisco 的开源发包软件TRex, 虽然在界面上稍逊一点，但在完成功能方面的测试，以及跟自动化测试框架的结合来看，完全能够胜任。
4. Language： 在测试领域， java有着非常大的优势， 因为有Junit等库的支持，但java被oracle收购后，下坡路明显，另一个强势的语言是python，其在各个领域都有着非常强大的库， 在测试框架中有pyunit, pytest, noise三大库，我选择pytest作为自动化测试的框架，是因为它比pyunit更简洁和高效，并能够兼容另两种测试框架，而且具有很强的扩展性。
5. CI：持续交付选择jenkins，一方面是因为其开源，另一方面也是因为通用性好，扩展性好，插件丰富
6. Container:   docker,不要问我为什么，我只追逐前沿而已
7. Version Control：Git 不解释

UI与功能的集成

UI用selenium可以实现，而TRex是一款可以发L4~L7层的发包软件，在UI完成界面的配置后，进行发包的功能测试，两者都是开源软件，TRex有完美的python接口，可以对每一个功能，如HTTP, HTTP&DNS, SIP, RSTP一些业务流量进行模拟，通过网络设备的接口模拟Client与Server之间的通信，当数据经过防火墙时，防火墙会对数据根据zone的区域进行控制，随后可以根据log模块来验证此次测试的成功与失败，目前selenium与TRex是根据os.popen来实现，感觉还是非常生硬，后面可以优化，但完整的smoke已然不成问题。

pytest 与 selenium的集成

selenium作为具体测试的手段，而pytest作为测试的框架，主要是用来形成测试套件以及生成测试报告，pytest的灵活在于它不仅可以对套件进行完整性测试，而且可以对单个测试用例进行测试，这个功能在调试时非常棒，以及它可以对测试输入参数进行更改，这样就做到了一个用例，多个输入，而不是一个用例，一个值，优化了测试的代码，最后它的fixture功能，可以完美的替代unittest中的setup, teardown，使得一次测试的初始化和测试收尾工作都能自动执行，它的pytest-html插件可以生成测试报告

pytest 与 jenkins的集成

持续集成是为了让不断有代码签入到主版本时都能进行测试，而不至于分支代码偏离主代码太远，以至于到最后集成不到一起，持续集成每日构建，这样可以更早的发现错误，并且对自己的版本更加有信心，只要jenkins不报错，你就放心你签入的代码没有问题，既使有问题，也不会是太大的问题，因为pytest-html可以生成一个html的测试报告，而Jenkins也有一个publish html的插件，因此两者集成起来通过jenkins来跑pytest,并最终把pytest生成的report在jenkins里面展现出来

总结

自动化测试流程

1. Jenkins 每日从git那取版本出来，进行一系列的测试，输出测试报告
2. 每日研究 feature, 设计case, 并在分支上进行 case automation
3. 单元测试新引入的 feature， push 到 git中
4. 对失败的用例进行修改，分析和维护

转载于:https://my.oschina.net/hding/blog/1058099