ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

自动化测试框架设计原则

2021-10-30 14:35:53  阅读:167  来源: 互联网

标签:版本控制 测试报告 框架 代码 测试用例 测试 自动化


自动化测试框架设计原则

1、代码规范

测试框架随着业务推进,必然会涉及代码的二次开发,所以代码编写应符合通用规范,代码命名符合业界标准,并且代码层次清晰。特别在大型项目、多人协作型项目中,如果代码没有良好的规范,那么整个框架的代码会风格混杂、晦涩难懂,后续维护会很困难,最终成为没人敢动的“祖传代码”。

2、模块清晰明确

模块化是将测试框架从逻辑上分为几个不同的模块,如下列的模块化分层的测试框架所示,使用者可以根据实际情况自行裁剪。

 

 模块化的好处是可重用,并且便于替换修改。
以上图为例,假设测试报告模块以前用的是 Allure,现在想替换成更加贴切自身业务的自研测试报告,我们仅需将报告模块替换掉就可以了。
但如果测试框架没有做模块化划分,测试报告是耦合在框架代码里的,那么就会导致无法切换测试报告,或者切换代价过大的问题,改动起来就会比较痛苦。

3、通用性强

通用于不同的操作系统,比如,测试框架不仅适用在 Windows 操作系统上,还要适用在 MacOS、Linux 系统上,越通用,测试框架的受众就会越多。能解决同一类通用问题,比如,测试框架有个底层方法是用来操作弹出框的,那么无论是 Alert 框、确认框,还是一个允许用户输入的交互框,测试框架应该都能识别并操作。

 4、可维护、可扩展

1、可维护性

测试框架要做到容易维护,就一定要代码规范,模块清晰,除此之外整个测试框架代码风格还应该统一、易读、易懂。总之,要做到框架出问题时能容易定位并修改;更要做到,即使多人合作这个框架,这个框架代码要看起来是出自同一人之手。

   2、可扩展性

  可扩展性指当需求变化时框架容易扩展。如果测试框架不能扩展,就无法解决业务发展带来的新问题,也就意味着测试框架的寿命会很短。

5、错误处理机制,高效解决

在测试运行中,难免由于种种原因运行错误,这时测试框架就必须具备处理错误的能力。错误处理机制一般分为停止运行和错误恢复两种。

6、系统日志清晰,方便调试

除了错误处理机制外,系统的操作日志也能帮你快速排查问题根源,所以平时的日志一定要清晰详细,最好具备上下文,这样才能根据日志进行有效调试,快速定位错误发生的原因。

 7、支持测试环境切换

一个产品从开发到上线,会经历几个测试环境的测试,比如 dev 环境, 集成测试环境,预生产环境,生成环境等。所以测试框架要能做到,一套脚本多环境运行,支持环境切换,并且能根据环境进行自动化的配置(包括系统配置、测试数据配置等)。

8、 支持外部数据驱动

根据外部输入数据,动态生成测试用例,并在测试报告中单独展示。测试框架会把这些只有数据不同,步骤和操作都相同的测试用例,在运行中解析成一个个不同的独立测试用例,并在测试运行结束后,全部逐一展示到测试报告里。
根据外部输入数据,动态切换运行用例。测试目的不同,其需要采用的测试用例也会不同,所以自动化测试框架会给各个测试用例打上标签,再根据需要,自动选择具备特定标签的测试用例进行运行。

9、支持顺序、并发、远程运行

当你的测试用例有上千条,甚至上万条时,顺序测试会花费大量的时间。为了快速得到测试结果,测试框架应该支持顺序、并发、远程执行,这样能够缩短测试用例的整体执行时间。

 10、报告完备详尽

测试报告是 QA 工作中的重要一环,通常在一个项目结束或者一个 sprint 结束时发出。
虽然,在实际工作中,我们经常听到大家抱怨说测试报告太烦琐了,又不产生什么直接价值,但完备详尽的测试报告,不仅可以述说 QA 到底做了哪些工作,还可以看出整个项目的生命周期运行得平稳与否,软件的质量如何。

11、解决当前没有解决的问题

“不要重复造轮子”是工具创造的首要原则。从功能角度看,框架得到认可,要么是解决了当前无法解决的问题,要么是解决方案比当下的更好。
例如,Selenium/WebDriver 最开始为人所知是因为它开源、可跨平台;后来 Selenium/WebDriver 的替代者 Cypress 为人所知,是因为它还具备运行在浏览器之内,且自备 Mock 的能力。
所以,你的框架能不能被认可,就在于它是否具有独特的功能特性,这是与其他框架区别开来的标签,也是弥补市场空白的撒手锏。

12、版本控制,回溯复盘

什么是版本控制?其实就是将代码纳入版本控制系统(如 Git)的管理之下。那么为什么测试框架要做版本控制呢?
有了版本控制,你的不同版本的测试代码就能以不同分支的形式出现,否则,你只能一次保持一个版本的代码,非常不方便。
有了版本控制,不仅协作开发、版本切换变得非常容易,使用者也可以通过查看版本之间的变化来理解框架的发展脉络。

13、持续集成,全局出发

前面的原则是从测试本身角度出发的,而“持续集成”是从整个公司业务出发,需要你与整个开发团队合作完成,同时这是你晋级“资深”的体现。
测试框架应该能方便地集成至公司的持续集成系统,并且通过持续集成系统触发测试。

 

 

-------- THE END --------

 

标签:版本控制,测试报告,框架,代码,测试用例,测试,自动化
来源: https://www.cnblogs.com/txu2k8/p/15484933.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有