引入自动化测试的情况
1、回归测试,重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费;
2、此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具;
3、采用自动化测试工具有利于测试报告文档的生成和版本的连贯性;
4、自动化工具能够确定测试用例的覆盖路径,确定测试用例集对程序逻辑流程和控制流程的覆盖;
5、项目周期长,系统版本不断,并且需求不会频繁变更;
6、系统的测试对象基本可以正常识别,以及对无法识别的控件能否提供一个解决方案;
7、系统中不存在大量的不可识别第三方控件;
8、需要反复测试,如可靠性测试、回归测试等需要进行上千次的系统测试。
自动化测试技术是目前行业中特别主流的测试技术之一。目前企业中应用自动化测试技术最为主流的方式是基于框架的形态来实现的。
很多人都是以线性代码的形态来编写自动化,这是一种学习过程中必经的阶段,但是不满足于企业的实际需求。
1.框架不是一成不变的东西。不同的公司框架都会有或多或少的不同。
2.一定是结合主流技术来实现的独立化的框架。
3.一定是应用到面向对象思维,应用到实际设计模式等常态化的技术来实现的。
4.都是基于整个技术团队来进行使用的。相当于是在团队内部实现了所谓的测试工具的开发。
1.编程语言:Python
2.核心模块:Selenium、Appium、Requests
3.设计模式:
关键字驱动
几乎所有的测试框架/平台都是基于关键字驱动为底层逻辑来实现的。
页面对象模型
俗称的POM,针对UI自动化层级实现的独有设计模式,也是目前市场认知中最佳的设计模式。
测试数据
excel:基于excel文件,管理所有的测试数据。甚至管理测试用例。相较于其他的数据驱动而言,excel是入门门槛最低的形式。
yaml、py、json:相对于excel而言,有着更为简单直接的维护方式,但是,上手的难度太高。
配置管理:日志管理,浏览器配置、邮件配置、环境配置。
测试用例:excel、UnitTest、Pytest。
测试报告:自定义模板、HTMLTESTRUNNER、Allure。
持续集成
代码管理:git、svn。
jenkins:自动部署、定时任务、构建任务。
技术能力
设计能力:结合实际情况进行合理化设计。
基于经验去进行传授,不能够只是学习最基本的编码的东西。
1.通用性:能够在各种各样的系统和平台都能够使用。
2.易维护性:能够把我们的数据、用例、框架的实现进行独立的维护,能够在实现完善的过程,快速的定义到维护的点,而不对框架的其他功能造成影响。
3.定时处理:能够在指定的时间执行。
4.持续集成:当被测程序和测试代码有更新能够自动执行。
5.调试:可调试行强。
6.测试结果:测试报告、测试数据的统计分析。
可以把自动化测试框架主体分为两部分,一个是内部框架,一个是外部框架,内部框架就是我们自己实现的测试框架代码,外部框架就是抛开我们实现的核心代码,要达到自动化测试框架设计原的一些内容时用到的一些第三方工具。
内部框架
也就是分层框架,目的在于更好的优化和管理测试用例,更便捷的进行数据、元素、脚本的维护和更快速的创建新脚本。
1、通用的外部框架实现逻辑
maven或者tox-自动编译,执行TestNG或junit,集成邮件发送等。
TestNG或Junit、pytest,调用webdriver或者发送请求的方法,执行自动化测试用例,规范自动化测试脚本。
selenium脚本或者接口用例脚本。
reportNG或者allure报告优化模板。
main自动以html邮件通知或者Jenkins发送邮件。
2、内部框架
层架框架-也就是代码结构优化,根据具体的业务和需求可以大致分为以下几层,有时并不需要下面所有的层次,选取合适自己业务测试的就行。
TestCase层:执行的用例脚本
Task层:公共业务分装,是其他的项目不需要的,只和当前项目相关,比如公共登陆、搜索等业务
utils层:与业务无关的方法,比如数据驱动-也就进行数据文件的读写、浏览器操作、元素定位方法等进行封装
page层或po层:页面层,页面层主要维护某一个页面的所有元素,对页面的操作、对元素的操作以及和其他页面的交互,业务其实就是一个元素到另一个元素或者一个页面到另一个页面,这就和task层有点重复一般有一个就可以了。
element层:公共元素或者组件的维护,或者自定义组件封装
data层:数据存储。
properties层:配置文件、全局变量。
当你打算放弃梦想时,告诉自己,再多撑一天一个星期一个月,再多撑一年吧。你会发现,拒绝退场的结果令人惊讶。
奋斗是这么个过程,当时不觉累,事后不会悔。走一段再回头,会发现一个更强的自己,宛如新生。
梦想是注定孤独的旅行,路上少不了质疑和嘲笑,但那又怎样,哪怕遍体鳞伤也要活的漂亮。