移动测试体系
移动测试体系
推荐书籍：
《移动app性能评测与优化》腾讯出品
《App研发录》包建强
《移动App测试实战》
目的：好的技术推动测试行业发展。
前言
移动互联网公司的简化架构
质量目标
质量目标-更好
需求的正确性：
参与需求评审，明确需求，细化测试用例设计
测试中与产品经理协作
实现的正确性：
业务功能实现
专项测试，性能，稳定性，安全
新老版本兼容性
质量目标-更快
项目测试流程保证
持续集成+自动化+工具定制
质量监控与快速反馈
挑战
多段测试：android IOS web hybrid
诸多专项：新老版本兼容 多设备兼容 性能 安全等
专项测试技术难度大
技术生态不完善
测试方法陈旧
低质量的交付、单侧不充分、业务逻辑实现多端不一致
迭代快时间和人力资源紧张
内容大纲
研发阶段的质量保证
测试阶段的测试流程
发布后的质量监控
一、研发阶段的质量保证
【代码提测之前】
1.静态分析---测试
2.单元测试---研发执行落地，测试 提供一个机制（jenkins）。测试分层：70%
3.代码review（代码评审）----研发 测试工程师能力要求，发现问题效果好，问题的50%。
4.自测---研发，多了解，不要被开发忽悠。
5.自动化冒烟测试---测试
一、静态分析--测试
综合性的代码分析平台
Sonar支持自定义规则，较多的公司使用---就可以检查下面的质量指标。支持自定义规则。手机截图
Xcode和android studio（IDE）的自带集成工具。
独立的静态分析工具—功能：扫描代码里面的各种隐患
Findbugs
Pmd
Androidlint
Scan-build
静态分析关注的质量指标
技术债
代码规范
代码问题---主要原因。不严谨 编码解码 会有误报，要找出关键规则
代码重复度---越低越好，一段代码copy多次，风险有问题后只fix一处，其他处没改。
圈复杂度---代码分支结构，内部多层if else嵌套 可能路径多 单元测试无法全部覆盖，风险
单测的覆盖率---已覆盖，未覆盖，发现测试不充分地方，补充测试。
静态代码的在线规则库
自定义规则
https://docs.sonarqube.org/display/DEV/Adding+Coding+Rules
https://pmd.github.io/pmd-5.5.5/customizing/howtowritearule.html
在线规则库
360火线 http://magic.360.cn/
FindBugs的规则库：http://findbugs.sourceforge.net/bugDescriptions.html
研究规则，代码隐患，对以后分析问题有帮助。
静态分析工具报告
Jenkins集成的报告，扫描研发工程师每天提交的代码，当代码增加后，可以看得出来bug趋势。测试人员关注新增的严重的bug，找出隐患。手机截图
二、单元测试--研发，测试搭jenkins
单测研发主做，测试人员把流程搭建起来，进行快速反馈，通过jenkins每天跑单测用例。
单测的可测性是单测成败的关键。
合理的使用mock方法。
建立良好的反馈机制
jenkins 跟进【流程】测试人员把单元测试、静态分析都集成到jenkins中。用例管理。
不要跳过测试执行---Dskip.test = true
三、代码评审---最有效的质量保证手段
防止烂代码、烂设计进入
培养良好的代码习惯，知识和规范的传承
借助标准的代码管理工具即可，比如gitlab的pr机制。
四、自测----测试左移
研发自测
自查和自测试是负责的态度
保证质量交付有助于缩短项目工期
产品自测
自动出包给产品
评估产品流程和UI设计是否符合预期
五、自动化冒烟测试---测试，保证提测的包不会存在低级问题
自动打debug包
自动化的冒烟测试手段
前端项目--- case维护成本低
Monkey健壮性测试
自动遍历+LeakCanary自动检测内存泄漏
基本的崩溃检测
基本的冒烟测试用例
后端项目---接口测试
二、测试阶段的测试流程
测试准入
自动对测试分支进行打包
自动对测试分支进行测试
打tag表示一个正式的提测版本
移动端交付测试略
内部交付
内部测试用
自动打包jenkins
内部下载入口
公测
更快的手段测试包：fir.im bugly服务，测试团队关注包的下载地址，一旦有新版本就测试。
正式发布
打包渠道包推送到各市场
上传到app store
内部App发布
手机截图
后端发布
基于docker体系，省去了测试运维之苦
内部编译和部署系统Rolling
根据分支半自动部署环境
后端升级自动触发接口测试
测试体系
一、客户端
1.手工测试为主（每版本执行 成本大）
测试组
内测+公测：员工，产品达人，粉丝
灰度测试：应用市场No返回新版本Yes。比例控制 逻辑灰度:地域/年龄 逐步灰度
手工测试依然是主角
业务需求，交互，产品体验（工具+文档+人力）
2.自动化测试
(1)UI自动化测试
(2)接口自动化测试：测试分层20%
(3)自动遍历测试
(1)UI自动化测试
Android自动化测试-----手机截图
Appium > Robotium > UI Automator
Appium：跨平台IOS、android
IOS自动化测试----手机截图
Xcode8.0
Appium>KIF(XCTest)---能力要求
UI不足：
复用率低：UI、流程变更。勿在浮沙筑高台。------能力：配置Object模型
稳定性不足：-----能力：框架封装，避开80%干扰。失败重试，使case稳定
容易被干扰
执行慢 并发只能解决部分问题。
技术生态不完善
合理的UI自动化：
侧重于主流程的回归测试
控制规模
降低编写用例的成本
自动遍历+自动生成测试用例。
(2)接口自动化测试：测试分层20%
(3)自动遍历测试----配合UI自动化、monkey，三者配合。
定义：通过不断遍历app中页面和路径尝试发现问题的方法
优点：比UI自动化维护成本低、比Monkey更具可控性。（Monkey广泛应用于云测平台）。
价值：
·验证UI的可用----浏览，兼容性
基本功能
兼容性
·自动化性能测试：结合OneApm，NewRelic界面切换速度、后端接口响应（代理技术也可以发现后端问题）。
·内存泄漏：借助LeakCanary(手工测试中，自动提醒发现内存泄漏)和MLeaksFinder（IOS）。
·稳定性问题：长时间浏览，卡顿，崩溃问题。
·崩溃的分析与统计：Flurry Bugly Fabric SDK级，多了解集成，学会如何从Bugly上去找某一个用户的crash，取top10发给研发。分析平台数据的质量价值，堆栈信息。
·UI Diff验证新老版本的功能差异
百度：smartMonkey，在云测平台。
腾讯：newMonkey，未开源。
思寒开发的工具：appcrawler工具
·支持遍历控制，支持monkey，支持android和IOS，支持native和hybrid，支持微信和微信webview。
·自动遍历的报告：手机截图*3
·不足：验证码，短信验证搞不定，写数据，等交互的交给手动。
3.专项测试（间或版本执行）
(1)App端性能测试
·冷启动+热启动：响应时间
·界面切换和交互体验：FPS（流畅度）
·接口性能
·流量
·电量
·内存和CPU占用---后果，流畅度、crash、卡顿。
性能分析自动化相关技术
Adb：android instrument:IOS
录屏：逐帧分析加载过程
H5：remote debug协议、ChromeF12工具。
内存问题检测：
问题：---crash，，卡顿
测试手段：
开启LargeHeap
Android Studio的Monitor监控各种资源使用情况+MAT+LeakCanary
IOS+instruments套件（多指标监控）
优秀实践：自动遍历+ LeakCanary----全面发现内存问题
公司内部Log分析、数据收集等平台，定位一些问题。
(2)H5性能
手机截图—google
Webpagetest平台
多浏览器、多地域、可访问性、访问速度
Hybrid的性能分析
微信webview的性能分析----了解H5的渲染机制。
H5性能关注指标
统计指标：
首字节时间
传输时间
白屏时间
首屏时间
策略（结合绿书p69）
数据压缩，，大数据不压缩，提bug
Cache策略，关键资源大资源要做cache，不做提bug。
(3)弱网测试---电梯、地铁
弱网模拟：
树莓派（废弃）
代理工具：Fiddler、Charles、Burpsuite
IOS开发者工具
重要场景：
支持超时 网速 异常模拟，看app的反应！
可以篡改数据验证健壮性，比如字段类型和null类型（异常处理）
(4)安全测试---能力
端安全
包的破解，反编译和重新打包
包的关键api被hook篡改
服务器安全
接口业务安全，提交数据合法性
数据安全，数据泄露和撞库风险---暴力拆解
通用做法
加强通用防护手段、请安全咨询团队
Zap WVS等工具的自动化扫描
(5)兼容性测试
质量问题
某些设备的安装失败、crash
某些设备的功能不可用
某些设备的UI错乱
影响因素
OS的版本间差异--Android4.0开始关注，IOS8.0开始关注
Rom定制差异
硬件差：GPU（游戏公司） CPU 内存 屏幕尺寸
商业服务方案
Testin---monkey，安装卸载
MQC---阿里巴巴
MTC---百度
优测---腾讯
私有部署方案
OpenSTF 定制
手机截图测试研发一起用，几十台手机，远程的交互，速度快，支持自动化adb开放出来，远程测试。
Appium grid方案
二、接口测试----合理分层测试（Unit>>Service>>UI）
1.接口性能
接口测试的范围和层次
手机截图
质量维度
功能，保持新老版本的兼容--API
性能，单次请求的响应跟总体的qps相关
变更检测 字段缺失，字段的类型变更
异常和健壮性测试
质量体系
构建接口层的快速稳定的质量保证体系
构建接口监控体系---保证服务器接口对老版本用户的兼容。
接口测试流程
接口的范围---哪些接口要测试，top10访问。
接口分析---输入输出
接口测试框架---擅长的框架
测试用例维护----写代码
持续集成----jenkins
质量监控
接口测试框架
Rest-assured优秀的接口测试开源方案---集大成者！！Python，java,ruby都可以调。
Jmeter，性能测试工具，改进也可测接口。支持单测管理，实践较少。
Gatling，性能测试工具，同上，与单测结合没有
SOAPUI，接口测试工具，商业付费，方案臃肿，开源不积极
PostMan,接口测试工具，手工测试，node.js开发的，不能构建接口测试体系，有问题。
Swagger，javaAPI管理整体解决方案
Capybara-json，ruby开发，类似七牛的接口测试方案
定制化，定制化方案，基于各种语言自身的xUnit+httpclient封装。
录制和自动生成测试用例---到StuQ接口测试去找
推荐的接口测试落地手段
选择优雅的接口测试框架
录制+生成测试用例
基于har或者tcpdump的数据源
直接生成接口测试框架代码模板
基于Fiddler、Charles所提供的hal数据，直接生成接口测试的测试用例。
数据驱动，excel yaml，维护简单。文件读取，提高效率，自动拼装测试数据。
新老版本之间的接口对比分析
结构对比---一个接口字段减少了，字段类型变更，会影响客户端。老版本出错。
重构时的数据对比---检查服务端的返回数据不要发生变化。
推荐开源的Rest-assured手机截图
简约的接口测试DSL，get post请求的参数，清晰的API
支持xml json的结构化解析
支持xpath jsonpath gpath等多种解析方式
对spring的支持,mock？？
Diff方案---能力，没讲
Gor导流压测+Twitter的Diffy
局限
只支持get请求
涉及资源太多 早期没有推起来
接口测试框架Diff功能
三、发布后的质量监控
内测质量分析与监控
OneAPM---SDK级别，监控平台，手工测试时帮我抓出app性能数据，定位性能问题 Bugly---监测崩溃SDK级别。
NewRelic性能测试工具、SDK级别。
整体测试流程
持续交付流程
自动化打包
UI自动化测试
半自动部署
接口自动化
项目测试流程
2-4周迭代
测试用例+测试报告
不懂代开发的测试工程师生存空间越来越小。
测试工程师首先是一个工程师，作为一个工程师如果你不懂一门开发语言，其实你称不上是一个工程师。人和电脑是通过开发语言进行沟通的，想说话一样。如果你不懂开发语言，你就不能指导计算机帮你去做事。
手动+UI自动化+第三方工具+脚本。
大量工具的使用：批量的测试数据的生成，分析等。
学Python，学java，不要学Robot Framework局限。
开发模式
1.App是一个空壳，里面内嵌的webview，直接浏览在线网站。没有本地的东西，想浏览器一样。Url是远程。
2.把所需要的资源放到本地解析，不做任何网络请求，直接访问本地的html，渲染出来。Url是本地。
3.H5去做开发，但是输出给用户仍然是原生的控件，自动化框架可以解析。
4.原生。
