自动化测试
2017-04-24 19:17:23 0 举报AI智能生成
自动化分析，前人经验，自己总结，感谢！！
作者其他创作
大纲/内容
自动化分析
自动化技术栈
Android
ADB命令
获取当前窗口activity
adb shell dumpsys activity | findstr \"mFocusedActivity\"
Android系统知识
AccessibilityService(无障碍服务)
当用户无法全面与界面进行交互时，他可以帮助用户完成一些操作
Monkey
STF
Appium
IOS
Junit
Maven
管理层面的问题
公司的过程管理流程
为什么设计这样的流程
优点和缺点
针对不同产品的不同阶段，管理流程改如何处理
优化机制
开发语言
技术选型
开发效率
第三方库
稳定性
扩展性
项目组织
语法
Python
弱类型
解释性
函数式编程
面向对象编程
多重继承
Java
子主题
测试生态
单元测试框架
report框架
自动化测试框架
夜里测试框架
运营商
自动化
设计
业务的拆解
框架的选型
代码的设计
设计模式
工具选择
学习成本
是否要对测试包进行修改
签名
是否与被测APP同进程，还是另起进程
是否同时支持ios和Android
UI自动化
如何设计自动化来支持和解决业务问题
冒烟用例选择-核心场景
可重用性
测试代码重用
主要是公共过程的提取
测试脚本模板重用
是指抽取脚本通用部分，形成公共模板，便于后期快速开发脚本，如果能通过脚本直接生成这些公共部分更好
受前一个用例运行的影响，程序状态不正确导致测试脚本运行错误
比如前一个异常退出，session还有结束，可能导致后面用例建立session失败
脚本包含多个用例，如果用例查找空间失败，则会抛出异常，导致脚本退出，
页面不稳定的情况
需求总是变化的情况
case增长带来性能问题
团队内达成共识
要点记录
appium
定位
最好用id定位，id的变化可能比较小，xpath也可能因为dom结构发生变化而变化，文本变化可能性更大
API自动化
思想
分层测试，持续集成
如何分层
抽象类
数据库查询工具类
主要封装针对数据查询方法的分类
MySQL
redis
hbase
静态参数存储类
存储请求所需参数
接口路径
请求参数
测试账号
请求类
封装向后台发送接口请求的方法
包括其他的通用请求方法
测试类
按照针对业务、针对用户的接口进行分类
分层设计
通用模块设计
业务调用封装
数据
用例
自动遍历测试
工具
monkey
appcrawler
uicrawler
遍历过的页面会重复遍历，会造成一些页面点击次数特别高，但是有的页面点击次数还很好，而且有的页面无法遍历到
有时会卡在一个页面出不去
点击过的元素会再次点击，导致重复进入同一个activity
maxim
配置
策略配置
uiautomatordfs
深度遍历算法
uiautomatormix
直接使用底层accessibiltyserver获取界面接口 解析各控件，随机选取一个控件执行touch操作同时与原生monkey混合比例使用，比例大小可配置 --pct-uiautomatormix n
uiautomatortroy
控件选择策略按max.xpath.selector配置的高低优先级来进行深度遍历
保留原始monkey
运行时长
--running-minutes 3
--act-whitelist-file /sdcard/awl.strings
定义白名单activity，一定会遍历到的activity
--act-blacklist-file
指定黑名单，不进行遍历的activity
随机输入
需要提前安装adbkeyboard
也可以自定义输入内容
max.strings
自动遍历测试面临的问题
如何探索到所有的可操作的控件，访问到所有需要被测的activity？
如何提高遍历效率，避免控件过多的重复操作？
页面重复访问
控件重复操作
如何屏蔽掉我们不想要的操作？
如何限定在我们想要的测试范围？
如何解决登录问题？
如何评估测试效果？
如何帮助后续复现问题
截图
录屏
持续集成
核心理念
实践方式
核心
分支模型
环境管理
遇到的问题
好的自动化测试框架应该具备什么样的性质
效率
编写
关键字驱动
数据驱动
如何使用参数化
将需要循环或遍历的参数参数化
如果在产品需求文档、设计文档等已经明确了运行过程或参数，则完全可以将数据保留在测试用例内
那些状态或者数据是变的部分，那些是不变的部分
不变的部分就可以写在测试用例里
不要使用数据去描述复杂的操作，尽量保持数据是简单的参数值描述，而不是一个复杂的行为，这样会让数据驱动变成关键字驱动
如何存放数据
存放位置
单独的路径里，与测试用例的结构目录相同
与用例同级目录，通过扩展名来区分数据还是用例
存放结构
执行
分布式
应该是只有当业务逻辑发生变更时采取维护测试用例，减少其他情况发生时的维护用例
易用性
尽可能的让测试人员只专注于测试场景的设计
简单的接口调用封装
灵活的参数设置
header
公共参数
数据库调用
redis调用
环境切换的问题
不同设备机器上执行的问题
闭环
研发
监控
反馈
针对产品的问题
根据业务和技术架构设计测试策略
内部分层
各个模块的流转图
测试策略
大致的定义是：测什么和怎么测
不知道该如何深入，工作开始缺乏挑战性和成就感
如何做
测试的对象和范围是什么
测试的目标是什么
测试的重点和难点是什么
测试的深度和广度是什么
如何安排测试活动，即先测什么再测试什么
如何评价测试效果
0 条评论
回复 删除
下一页
