欢迎您光临本站,如有问题请及时联系我们。

DevOps实践(1)面向服务的全自动化测试体系

  一.功能

  依托于robotframework

  根据代码注释,自动生成测试库

  自动搜索测试用例或指定测试用例文件运行

  commit触发测试和周期性定时(按天/小时)测试

  测试报表统计(区分环境)

  企业微信通知测试结果

  在此之前,大家要去复习两个重要的概念,一个是【测试金字塔】模型,


  DevOps


  另一个是【基于关键字和数据驱动的测试】,


  二.自动化测试架构

  自动化测试


  在这一套自动化测试架构中,代码注释起到了核心的作用,背后就是标准化的要求,代码注释的格式如下:


  代码


  基于代码的comment,能完成如下能力的输出:


  1、Document。我们要自动生成api接口说明文档,可以依赖此方法生成。


  2、自动化生成服务测试用例。自动根据关键字构造自动化测试的方法和用例。


  三.根据代码注释,自动生成测试库

  指定项目的根目录,会自动将测试库写入到test/library/[项目名].py


  如下代码


  注意,如果post/put请求发送的是一个list数据,这里param请写struct类型。如


  @paramstructdata


  然后测试数据构造data=[{“a”:1}],框架将会发送[{“a”:1}]作为httpbody


  会自动扫描并生成robotframework的测试库


  测试库


  使用者,只需要撰写测试数据即可(数据驱动测试)


  数据


  四.自动搜索测试用例或指定测试用例文件运行


  自动搜索测试用例

  根据我们的部署规范,工具会自动搜索/usr/local/easyops目录下的项目,符合如下要求:

  a.文件夹必须是全小写的

  b.文件夹下有test/case目录

  指定测试用例文件

  可指定测试用例的文件/目录测试

  五.commit触发测试和周期性定时(按天/小时)测试

  工具会自动监听commit,触发测试

  也可指定每1h或每1d测试

  测试


  自动触发流水线执行全流程的验证,开发、测试和发布亦是如此。


  六.测试报表统计

  我们提出3个评价指标:

  成功率:成功的用例个数/总的测试用例个数

  覆盖率:(keyword总数-未测试的keyword个数)/keyword总数

  测试用例指数:测试keyword的测试数据个数的平均。最小是1(每个接口都只有1个测试数据),希望能达到3~5


  测试的结果数据会自动解析并存储到influxdb,利用grafana来展示

  grafana3.区分环境。我们有162、163、164等开发环境,所有数据都会区分显示


  此时的环境管理非常重要,过去的痛苦之处是如何快速创建和有效管理环境。由于我们的研发模式采用的是gitworkflow模式,所以能产生大量的特性分支,一个特性势必对应一个环境。因此会产生大量的开发环境、集成测试和回归测试环境,必须能够保证我们服务测试用例和环境能一一对应,且无需人工接入,这一点就大大降低了测试维护的代价和成本。


  七.企业微信通知测试结果

  项目的测试成功率小于100%,将会发送到企业微信


  八.总结

  一个完善的自动测试体系背后,是有很多经验值得分享的:


  1、研发参与测试。我们说的参与测试不是参与测试本身,而是参与测试体系的搭建。研发和测试为了共同的目标,稍作改变,而不是完全依赖后续环境,自动化测试体系构建成本就可以大大降低。


  2、标准化。研发坚持标准化的代码习惯,基于标准化,传递能力给自动化测试过程,效率和质量都能得到保障。


  3、质量意识前置。我们不把“质量当成测试组的职责”,而是把这部分的能力前置到研发阶段,共同构建质量保障壁垒。


  4、自动化。我们在开发自动化测试体系的同时,把其能力和平台流水线能力对接起来,让执行和接入成本大大降低。


  5、数据化度量。即使建立了完善的测试体系,如果没有很好的度量,效果依然不会很好,度量最好的方式——看板。


  6、闭环。有问题就立即要去解决,让测试发现的问题闭环起来。


来源:本文由E8运维原创撰写,欢迎分享本文,转载请保留出处和链接!