郑州微网站建设,公司名字注册查询,中国纪检监察报怎么订阅,设计类专业哪个最好自动化测试技术笔记(二)#xff1a;准备工作的切入点
上篇整理的技术笔记#xff0c;聊了自动化测试的前期调研工作如何开展#xff0c;最后一部分也提到了工作的优先级区分。
这篇文章#xff0c;接上篇文章的内容#xff0c;来聊聊自动化测试前期的准备工作#xff0…自动化测试技术笔记(二)准备工作的切入点
上篇整理的技术笔记聊了自动化测试的前期调研工作如何开展最后一部分也提到了工作的优先级区分。
这篇文章接上篇文章的内容来聊聊自动化测试前期的准备工作需要考虑哪些方面。 测试环境选择和搭建
自动化测试运行环境不外乎测试环境(SIT)、验收环境(UAT)、灰度环境(PRE)和生产环境(PROD)。
在不同的环境运行的目的、效果、优势和不足也各不相同下面是不同环境的区分对比结果。 环境名称 优势 不足 测试环境(SIT) 节省环境资源代码版本比较新可及时验证复用性强 服务不稳定测试数据容易混淆测试结果准确性不高需要人工二次校验 验收环境(UAT) 服务相对稳定环境复用性强代码版本相对较新 测试数据容易混淆 灰度环境(PRE) 环境稳定服务齐全可以更好的进行业务流程的自动化测试 测试数据容易混淆需要单独的维护和管理测试数据 生产环境(PROD) 环境稳定服务齐全主要用来做线上主流程巡检防资损 需要单独维护测试数据和账号且需要配置白名单过滤防止污染生产数据
不同环境对自动化测试开展的便利性和制约性不同建议根据自动化测试的成熟度、要解决的问题来选择不同的环境。
当然如果选择搭建单独的自动化测试环境就要考虑环境资源申请、域名、代码仓库权限、维护成本等因素。
还有个很容易忽视的点就是服务器操作系统类型和版本举个我当时遇到的例子
要做web的UI自动化测试工具选择了selenium我们常用的浏览器是chrome用户使用环境是windows自动化测试要求快速无感执行
就需要考虑Linux环境下基于chrome浏览器的case执行(chromium)还要考虑Linux操作系统对chrome的适配问题centos和uhuntu以及centos的版本选择6.5还是7.2甚至还要考虑浏览器驱动的适配问题。 测试框架选型和设计
近几年成熟稳定的开源自动化测试工具和框架可选择的比较多了但具体问题具体分析测试框架的选型和设计同样是很重要的事情。在选择测试框架或者工具时一般需要考虑如下几方面
自动化测试类型UI/API/UNITUI自动化要考虑web和移动端的区别单元测试要考虑被测系统的开发语言框架自身的生态框架支持的编程语言、社区活跃度、文档是否齐全、业内落地案例、测试同学自身的技术栈框架的学习成本不能只考虑选择个人熟悉的还要考虑后续的多人协同团队其他同学的学习上手难度框架的维护成本后期case多了或业务场景变更后case的维护成本以及框架本身是否提供了更好的封装模块测试脚本和数据管理
测试脚本和测试数据管理需要结合自动化测试的执行环境一起来看。
一般来说测试脚本为了便于统一管理和多人协作维护现在都是采用Gitgitlab的方式做好版本管理和分支规范即可。
而测试数据的管理相对来说比较复杂可选的方式也不同。下面是常见的几种测试数据管理方式对比 测试数据管理方式 优势 不足 Excel参数文件形式 数据维护方便简单快捷 不利于多人协作数据量大了之后数据维护更新成本高 配置文件形式 适合热点数据/通用信息管理如账号密码等 无法适用于复杂场景和大规模的数据管理 数据库统一管理 便于数据隔离统一管理 一般是配合单独的自动化环境一起维护 测试范围和校验粒度
标题所述的两点其实是同一种问题。
测试范围的筛选需要结合投入的资源项目紧急程度来综合评估一般测试范围的覆盖优先级可以遵循这个顺序核心业务——高频业务——问题较多的业务。
覆盖率的考量可以遵循这个顺序核心场景——核心业务流程——异常场景如此覆盖后再考虑逆向流程。
测试用例的粒度可以参照功能测试用例的区分从 P0 冒烟case到 P1 再到 P2以此类推。
当然如果遇到比较复杂和亢长的流程可以考虑拆分为多个测试用例在同一个任务里按上下游关系去执行。
粒度的设定和拆分在不同阶段有不同的划分。刚开始落地时可以由粗到细先实现再考虑不断优化。 持续集成和测试报告
自动化测试如果无法做到持续集成快速验证那就不能称之为自动化。
要做到将自动化测试我个人认为有如下几个标识来判断
执行的频次和效率比如1天可以执行100个功能case那自动化最起码要在10分钟甚至1分钟内完成执行结果自动校验功能测试可以人工来判断测试是否通过自动化测试的通过率成功率需要达到一定的成功率(比如90%以上)且失败的case可以重试验证或者失败的结果和日志及时通知给相关人员无人值守自动运行这点其实很多方法可以实现比如定时任务条件触发。当然做到这点还算不上自动化必须考虑到如果出现重大问题还需要及时的发现和告警通知是否融入交付流水线交付流水线即我们今天常说的CICD或者devops流水线常见的场景有服务打包编译后的自动化单元测试服务自动发布后的接口自动化和UI自动化测试以及服务上线前和上线后的自动化冒烟和回归测试甚至还可以加入线上的日常自动化巡检。外部调用和多人协作
以电商业务为例支付需要调用三方短信通知需要调用短信服务商发货物流需要调用三方但实际工作中三方提供的环境往往不满足我们的测试需要这个时候就需要一定的手段来解决这个问题。常见的手段如下
挡板mock最常用的手段流量染色影子库实现成本较大技术复杂性较高和三方协商一致后配置专门的白名单或者渠道很难协商
至于多人协作问题其实涉及很多方面比如
测试数据专人统一维护还是按需维护提供专门的工具或者流程规范约束测试用例和测试脚本的维护各管各的还是提供统一的规范demo专人检查或者定时review测试范围的边界如何界定重合部分如何区分职责以上就是自动化测试落地前的准备工作内容来源于我之前做自动化测试工作时的一些笔记内容稍加提炼和修改。
下一篇我会聊聊自动化测试落地方案以及落地过程中常见的问题以及解决思路。 总结 现阶段很多人都在说软件测试太内卷了工作太难找了竞争太激烈了。那么如何在这样的现状下使得自己更具有竞争力呢笔者认为大家需要迅速学习软件测试的硬技能提升自己的业务能力早日摆脱初中级测试的Title虽然测试人员众多但是高级的软件测试人员还是很稀缺有很多人挂着高级测试的头衔却还在干着初中级测试的活。在掌握这些硬技能的同时软技能的培养同样重要沟通能力、自主学习能力越来越被企业看重。 如果不想被这个时代淘汰就要做好持续学习的准备。下方给大家准备了全套的软件测试自动化测试全套教程。
【需要的可以点击下方官方推广小卡片扫码备注000免费领取】
