前几天知识星球有同学问了一个关于自动化测试的技术问题,然后沿着这个问题大家拓展性聊了很多,有技术实践也有方法论,最后聊到测试分层和自动化测试方案的抽象设计,出现了一些歧义。 鉴于一两句也无法表述清楚我个人对自动化测试的理解,索性写篇文章,聊聊我对于自动化测试的理解,以及为什么要开展分层的思考。 在规定时间内有效的完成需求范围内的测试覆盖和验证,也是软件测试的核心之一。 自动化测试方法的提出和各种自动化工具的不断涌现,本身就是软件工程理念和技术实践不断完善和改进的必然结果。 为了保障自动化测试的执行效率,降低失败后的排查根因耗时,才有了自动化测试的分层理念和实践,即测试同学很熟悉的三层模型。 自动化测试用例的设计方法 当然,单纯的测试分层并没有彻底解决问题,还需要在设计测试用例时,考虑到最小场景。即:测试用例只需要关注自己最直接的预期结果,它的下游依赖或者调用,用对应的测试用例去覆盖即可。
软件测试是保障软件质量的重要步骤,而自动化测试是提高测试效率和准确性的关键。然而,软件的复杂性常常需要我们进行多种不同类型的测试。这就引出了一种称为“分层自动化测试”的概念。 本文将详细解释分层自动化测试的含义,并探讨如何将其应用于软件开发。 分层自动化测试的概念 分层自动化测试(Layered Automated Testing)是一种策略,它将测试任务划分为不同的层次,每个层次专注于测试应用程序的特定方面。 如何应用分层自动化测试 在实际的软件开发过程中,我们应当遵循以下原则来应用分层自动化测试: 越底层的测试越频繁:基于金字塔模型,越底层的测试(如单元测试)应该更加频繁,因为它们的执行速度快,发现问题的成本低 通过有效的应用分层自动化测试,我们可以提高测试的效率,降低测试成本,提高软件的质量和稳定性。
这篇文章,结合自己的经验,聊聊关于自动化测试的分层和落地实践场景以及前置条件。 自动化测试的分层模型 自动化测试的分层模型,测试同学都应该很熟悉了,按照分层测试理念,自动化测试的投入产出应该是一个金字塔模型。越是向下,投入/产出比就越高,但开展的难易程度/成本和技术要求就越高。 因此,根据业务场景选择合适的自动化测试方式,就很重要。 自动化测试分层的落地前置条件 先聊聊不同的自动化测试各自的特点,再来列举它们的适用场景和前置条件。 是否分层,哪种测试手段投入多少资源,更多的是取决于面临什么问题,这些问题对质量的影响程度大小,然后才是根据具体的情况选择合适的测试手段去解决问题。 聊聊自动化测试的度量指标 自动化测试如何区分用例集合 自动化测试如何管理测试数据 自动化测试如何解决日志问题 从零到一落地接口自动化测试 学习自动化测试必读技术书单 如何设计一个自动化测试平台 自动化测试如何创造业务价值
什么是分层测试? 分层测试是通过对质量问题分类、分层来保证整体系统质量的测试体系。 分层测试实现代码、服务、界面分层测试的整体架构目标,逐层建设完善自动化测试能力,逐步做到在保证质量的前提下提升需求交付效率。 可以这么说,当你遇到对一个系统进行整体保障,不知道怎么入手的时候,进行分层测试是一个良好的解决思路。 分层测试的优点 层次分明:各层测试目标清晰,能形成效果叠加,增强质量防护能力。 白盒测试:加强了对代码实现逻辑的理解,提升整体代码质量和设计质量。 原则 稳定性:稳定性是自动化用例的生命线。 有效断言:用例无断言,就是耍无赖。 测试下沉:要小不要大,自动化用例尽量下沉,用接口用例覆盖。 三早:早测试,早发现,早修复。 聚焦业务: 尽量专注于业务场景,确保每个测试都有价值。
本文以笔者当前使用的自动化测试项目为例,浅谈分层设计的思路,不涉及到具体的代码细节和某个框架的实现原理,重点关注在分层前后的使用对比,可能会以一些伪代码为例来说明举例。 接口测试三要素: 参数构造 发起请求,获取响应 校验结果一、原始状态当我们的用例没有进行分层设计的时候,只能算是一个“苗条式”的脚本。 二、进化历程 因此我们依照着痛点,以最开始的原始状态为例,对用例进行分层改造,来看看进化后的状态。 用下图先来看分层的目标: [图片] 我们希望将常用的测试场景步骤封装至service层中,供用例场景调用,增加复用性,也可以理解为测试用例的前置处理; 但是这里还是有一点小问题,就是service层的东西太多太杂 这时体现在用例中的表现就如下层testcase层所示. 3、testcase 层 我们想要的是一个清晰明了,“一劳永逸”的自动化测试用例,就像我们的手工测试用例一样,我们的前置条件可以复用,我们入参可以任意修改
# 背景 纯属个人总结,总结下目前接触到测试方法/体系 # 个人总结 从开发架构上来分层 目前接触到项目,基本上都是如下图的架构模式(MVC),每一层都衍生出对应的测试 ? 对应的测试: ? 看看市场上的测试岗位,大多数都是围绕这这些来设定的:功能测试,自动化测试,测试开发,性能测试,服务端测试 个人最近几年都是服务端测试,基本上也是在接口层,但目前偏重数据层,也明白了数据的重要性,业务的根源在数据 ,从数据上可以反应业务的健康度 不要被表象中的自动化,性能所迷惑,觉得做测试往上走就是搞自动化,性能,这样太局限了; 有这么一种情况值得思考:即使你自动化搞的非常牛逼,性能也是吊炸天,然而业务没了怎么办 即使你是工具组的测试开发,没有业务团队接入也是扯淡。因此测试的本质的业务的质量,而不是为了测试而测试 自动化是为了提高效率,是为了保证的解决业务的稳定性,性能是为了保证业务的体感 从流程上来分层 ? ,保证核心业务无误;接口可用性监控;第三方接口拨测监控...保证线上无重大问题; 数据层:大盘数据的监控(阈值,波动值),数据分析衡量业务健康度; 监控体系是保证线上的无重大故障,或者提前感知问题; 自动化是测试效率的提升
引言 ---- 自动化测试一直是测试领域桂冠上的明珠,几乎所有的测试团队都有建立团队的自动化。测试团队的自动化建设也被认为是团队提效的必经之路,但搭建和使用自动化路但路却并非一帆风顺。 现在为了腾讯视频增值团队的分层测试,了解了一些内部和外部的自动化框架,他山之石可以攻玉,这里列出来和大家一起学习。 自动化的认识 ---- 为什么要建设自动化? 主要当前QA工作中存在众多的痛点。 分层自动化的理念 在理解分层自动化之前,我们先看自动化测试金字塔。 自动化测试的目的是降本提效,既然如此,肯定要考量建设自动化的收益率。 UI自动化测试 ---- 很多测试团队都会建设UI自动化测试,初衷大体是因为UI自动化集成度高,覆盖前端的代码,验证完整链路的系统稳定性。
正好赶上公司的SOA服务化进程,测试这边也开始配合的做自动化方面的转变,从原来的黑盒系统级自动化测试向分层自动化测试转变。 2. 分层自动化测试 在谈分层测试之前,先回顾几个概念: 单元测试: 对软件中的最小可测试单元进行检查和验证。具体的说就是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。 其中Unit代表单元测试,Service代表服务集成测试,UI代表页面级的系统测试。分层的自动化测试倡导产品的不同层次都需要自动化测试,这个金字塔也正表示不同层次需要投入的精力和工作量。 下面我会逐层介绍有赞的分层自动化实践。 2.1 Unit-单元测试 在系统拆分之前,有赞只有一个庞大的巨无霸系统,单元测试极度缺失。 总结 本文主要从整体上介绍了在有赞SOA化的进程中,测试推行的分层自动化实践,以及后续的发展方向,同时简单介绍了相关的测试框架结构。下面再从整体回顾一下我们的分层自动化的要点: ?
零距离对话腾讯测试专家,获取更多测试经验。 TMQ沙龙活动第四十五期 特邀腾讯高级测试工程师——杨春喜测试分析&分层自动化测试实践。 本次分享的内容是——应用宝测试团队在EP自动化方面的实践:测试分析+分层自动化测试模式。希望通过此次分享,和大家交流心得体会,能够给大家在EP方向团队级别的实践提供一些思路。 分享嘉宾 ? 杨春喜:腾讯高级测试工程师。目前主要负责应用宝测试团队的管理工作和应用宝测试团队EP实践:测试分析+分层自动化测试模式团队的应用和拓展及相关工具能力搭建规划。 分享主题 测试分析+分层自动化测试模式的效果 与传统测试模式的差别 测试分析+分层自动化测试具体方案介绍 测试分析+分层自动化测试模式运作的机制 分享时间 9月11日(星期二) 晚上20:00~21:
本文以笔者当前使用的自动化测试项目为例,浅谈分层设计的思路,不涉及到具体的代码细节和某个框架的实现原理,重点关注在分层前后的使用对比,可能会以一些伪代码为例来说明举例。 接口测试三要素: 参数构造 发起请求,获取响应 校验结果 一、原始状态 当我们的用例没有进行分层设计的时候,只能算是一个“苗条式”的脚本。 二、进化历程 因此我们依照着痛点,以最开始的原始状态为例,对用例进行分层改造,来看看进化后的状态。 用下图先来看分层的目标: image1041×1128 64.6 KB 我们希望将常用的测试场景步骤封装至service层中,供用例场景调用,增加复用性,也可以理解为测试用例的前置处理; 但是这里还是有一点小问题 这时体现在用例中的表现就如下层testcase层所示. 3、testcase 层 我们想要的是一个清晰明了,“一劳永逸”的自动化测试用例,就像我们的手工测试用例一样,我们的前置条件可以复用,我们入参可以任意修改
image.png 大家周末好,我是测试君 下面分享一篇关于自动化测试框架开发的文章 写在前面 我们刚开始做自动化测试,可能写的代码都是基于原生写的代码,看起来特别不美观,而且感觉特别生硬。 来看下面一段代码: image.png 具体表现如下: driver对象在测试类中显示 定位元素的value值在测试类中显示 定位元素的方式在测试类中显示 线程方式硬等待sleep几秒 代码一报错,还要去测试类里面找是哪段代码报错 ,当代吗行数好多时,不好定位 好多测试脚本组装批量执行后,报错后,定位问题,很吃力 有命中的小伙伴嘛,有的话,请在文末下方留言,其他现象就不一一列举了。 1、从个人方面来说: 逼格高,让别人感觉你好厉害,技术强 面试是加分项,会写框架,可以作为谈资硬性指标 一个组内,要是妹纸多,你可以秀技能,吸引妹纸也说不定呢 2、从实际方面来说: 好的测试框架,可以稳定性 ,健壮性强,可降低代码维护成本 方便定位问题,失败定位问题会比较方便 可以提升测试效率,编写脚本成本,拿来就用,直接点方法就行 如何编写框架 下面我们将进入大家都比较关注的话题了,这里我只分享思路哈,跟上步伐
分层测试系列文章 https://www.cnblogs.com/yuxiuyan/tag/分层测试/ 1. 什么是集成测试 集成测试是在模块接口的基础上,将所有涉及模块按照设计要求(比如根据架构图)组装成子系统,对系统接口进行正确性校验的测试技术。 集成测试的优点 减少连通性问题:集成测试通过对子系统或系统的全面分析,大大降低了出现严重系统级连通性问题的可能性。 完善测试体系:单模块/接口测试无法发现的问题,在集成测试阶段可以发现。 集成测试的挑战 测试复杂性: 集成测试意味着测试两个或多个集成系统以确保系统正常工作。不仅要测试集成链路,还要进行考虑环境的详尽测试,以确保集成系统正常工作。 5.3 记录测试日志 集成测试的范围很广,因为它跨越应用程序中的多个模块。与单元测试不同,在集成测试中没有简单的方法来分析故障的根源。 因此,记录测试结果是发现问题的唯一方法。
写在前面 我们刚开始做自动化测试,可能写的代码都是基于原生写的代码,看起来特别不美观,而且感觉特别生硬。 来看下面一段代码: ? 具体表现如下: driver对象在测试类中显示 定位元素的value值在测试类中显示 定位元素的方式在测试类中显示 线程方式硬等待sleep几秒 代码一报错,还要去测试类里面找是哪段代码报错,当代吗行数好多时 ,不好定位 好多测试脚本组装批量执行后,报错后,定位问题,很吃力 有命中的小伙伴嘛,有的话,请在文末下方留言,其他现象就不一一列举了。 ,健壮性强,可降低代码维护成本 方便定位问题,失败定位问题会比较方便 可以提升测试效率,编写脚本成本,拿来就用,直接点方法就行 如何编写框架 下面我们将进入大家都比较关注的话题了,这里我只分享思路哈 7、测试类如下 ? 8、运行效果 ? 看上去是不是很nice呢,还不动手试试!!
测试分析+分层自动化测试模式的效果 与传统测试模式的差别 测试分析+分层自动化测试具体方案介绍 测试分析+分层自动化测试模式运作的机制 问答环节 ? 1、hook是什么? 2、只是做手机测试,对于各模块(每个APK)适用这种分层自动化测试吗? 答:我们会对每个模块进行测试分析+分层自动化测试。只有活动类的需求或者纯属UI交互改动类的需求不采用这种模式。 3、请问分层自动化测试的入门书籍和进阶书籍有哪些可以推荐的吗? 答:TMQ介绍精准分析的文章和自动化的文章,书籍方面比如:《腾讯Android自动化测试实战》和《不测的秘密:精准测试之路》。 4、手动BUG能有多少实现分层自动化测试用例? 答:分层自动化测试的bug在终端类型产品中我们目前做的的比例是20%-40%左右,分层自动化率在30%-40%。 5、是如何提高用例稳定性百分比的? 答:我们是基于对业务实现架构和具体分层方案理解的基础上,基于测试分析(需求分析+代码分析)进行分层测试策略的验证,ui的交互和动画部分采用手工验证,基于终端逻辑层和终端UI展现逻辑,以及后台的测试写成分层自动化脚本
分层测试系列文章 https://www.cnblogs.com/yuxiuyan/tag/分层测试/ 1. 什么是UI测试 UI测试是通过测试产品的视觉元素来验证产品功能和性能的测试技术。 注意:当分层测试的其他层次不完备的时候,最好不要考虑使用UI测试,在业务实践来看,准确率很难达标,严重影响开发人员对测试人员信心。 2. 2.2 基于录制回放的测试 录制和回放 UI 测试使用自动化软件,通常需要有限的编码技能或不需要编码技能即可实施。 采用无代码方案:为了消除重复更改测试代码的麻烦,开发人员和 QA 团队应该采用无代码自动化解决方案。 进行团队自动化教育:组织的编码文化会显着影响团队在软件开发周期中如何有效地管理测试挑战。 由于整个组织都需要特定的代码审查或更改标准,因此他们还可以专注于对团队进行最佳自动化测试实践的教育。
目录:导读 一、什么是PO模式 二、什么是自动化测试框架 三、非PO模式和PO模式优缺点对比 四、如何从0到1搭建PO模型 五、自动化测试框架和PO的关系 六、总结 ---- 一、什么是PO模式 全称: page object model 简称:POM/PO PO模式最核心的思想是分层,实现松耦合! 二、什么是自动化测试框架 说到自动化框架,我相信很多人应该都听过这个词,但是不知其到底是个什么东西,为什么要用自动化框架。有很多人堆自动化框架都是懵懵懂懂,就跟谈恋爱一样,朦胧美! 一个好的自动化测试框架是可以让不那么懂技术的人也可以写自动化测试脚本的, 一个好的自动化测试框架可以减少自动化测试中脚本管理和维护当中的人力物力和财力。 其实自动化框架的一个最大的意义在于可重用性。 五、自动化测试框架和PO的关系 自动化框架=po+各种封装(日志处理封装,全局配置文件的封装,数据库连接的封装,excel操作封装,数据驱动封装等) 其实想要胜任UI自动化测试岗位还需要掌握以下内容:
分层测试系列文章 https://www.cnblogs.com/yuxiuyan/tag/分层测试/ 1. 什么是接口测试 接口测试是通过测试模块接口来检测模块整体逻辑是否符合预期的测试方法。 2.1 单模块接口测试 接口测试代码与被测试的接口同源,在测试代码中将依赖的外部服务mock掉,数据库不mock,测试代码与被测试代码在同一个进程。 2.2 子系统接口测试 接口测试代码与被测试的接口同源,测试代码与被测试代码在不同进程。 3. 减少时间成本:接口功能比较单一,能够比较好的进行测试覆盖,也相对容易实现自动化持续集成,可以减少人工回归成本与时间,缩短测试周期。 依赖测试分析: 接口测试效果对测试分析的依赖性极大。 5. 接口测试设计最佳实践 接口测试的用例设计和单元测试有相似之处,都需要用到边界值法、等价类法等基本测试方法。
(如果,你扩展到从源码编译到字节码,机器码,到CPU指令集,到OS硬件驱动,到半导体电路的话) 单元测试中“盒子”比较小,就是一个或者若干个方法;接口测试的“盒子”就会扩大到应用级别;集成测试的“盒子 自动化测试 机器可以帮助我们完成几乎任何的单一形态的、重复性的、非智能的测试方面,这样我们才能够将时间和精力集中在多形态的、可变的、智能的测试方面。 自动化测试分层 ? 分层 自动化测试框架 自动化测试框架的出现,根本原因是为了复用代码,提高自动化测试的效率。同时一个设计良好的测试框架,也能通过开放给用户的接口,指导用户编写出风格统一,便于维护扩展的测试代码。 衡量一个自动化框架的品质,就看它在多大程度上起到上面两个作用。 Bug的定位和解决考验的不仅是测试人员的技术深度,更是知识的广度,所以这一点也是判断一个测试工程师能力水平的重要方面。 另外,对于一些流程上面的问题,考验的又是测试工程师的沟通、协调能力。
单元测试的挑战 时间成本:编写单元测试会增加开发人员工作量,单元测试跟生产代码是一样的,并不会因为是用来测试的就有所不同,开发人员同样要面对测试代码的编写,维护等工作,要将单元测试代码写好非常考验开发人员编码能力和测试代码设计能力 单元测试原则 1. 写出合适的测试名称 编写测试时要考虑的基本事项是选择测试名称。这非常重要,因为好的测试名称可以提高程序员和将来可能使用该代码的其他人的代码的可读性。 可以在单元测试中应用标准命名约定。 2. 创建简单的测试 保持测试代码尽可能简单是维护代码的关键。单元测试代码也可能有错误,尤其是在高度复杂的情况下。测试不需要很花哨。 最小化测试依赖 当测试不依赖于其他软件部分时,它们的稳定性是最好的。外部因素也不应该影响测试的结果。 6. 测试自动化 尽管可以手动进行单元测试,但当前的做法鼓励使用自动化单元测试方法。 单元测试是DevOps 自动化工具执行的一项基本功能,可简化编码过程。
本文介绍自动化测试框架编写 (记得收藏,转发哦) 大家周末好,我是测试君 下面分享一篇关于自动化测试框架开发的文章 写在前面 我们刚开始做自动化测试,可能写的代码都是基于原生写的代码,看起来特别不美观, 具体表现如下: driver对象在测试类中显示 定位元素的value值在测试类中显示 定位元素的方式在测试类中显示 线程方式硬等待sleep几秒 代码一报错,还要去测试类里面找是哪段代码报错,当代吗行数好多时 ,不好定位 好多测试脚本组装批量执行后,报错后,定位问题,很吃力 有命中的小伙伴嘛,有的话,请在文末下方留言,其他现象就不一一列举了。 ,健壮性强,可降低代码维护成本 方便定位问题,失败定位问题会比较方便 可以提升测试效率,编写脚本成本,拿来就用,直接点方法就行 如何编写框架 下面我们将进入大家都比较关注的话题了,这里我只分享思路哈 7、测试类如下 ? 8、运行效果 ? 看上去是不是很nice呢,还不动手试试!!