1. 测试行业的生存挑战：

XP Scrum CI CD DevOps的流行加大了测试压力
原有质量保证体系从理论到技术思想已经全面落伍，缺乏工程化体系建设
互联网发展快，导致测试工程师跟不上发展速度
现有的知识体系缺乏完整的梳理和总结，导致新人学习困难且不成体系
网络和培训结构充斥着过时、落伍的知识体系
研发工程师也在进入质量保证和测试领域，研发主导就更不会招聘技术落后的测试工程师
部分测试服务公司鼓吹独立测试团队无存在的必要

2 .移动互联网服务架构

用户通过客户端/小程序/H5发起各种各样的网络请求发送给服务端。API网关通过分流实现流量均衡到达后段的服务集群
BI：大数据分析

3. 项目实施的关键过程

需求：项目团队对需求进行沟通、评审
设计：开发人员制定设计方案，并进行评审
研发：开发人员实现需求，并通过单元测试、代码审计、冒烟测试（手工+自动化）交付给测试人员
测试：服务端测试（接口测试、性能测试、安全测试）、客户端测试（UI验收、功能测试、性能测试、兼容性测试、安全测试）完成，交付产品
敏捷：需求->研发->测试。偏需求管理的实践
持续集成：研发->测试，自动化构建，自动化测试，不断进行迭代
DevOps+持续交付：研发->测试->交付。
质量监控：交付->测试。测试可以通过对线上产品已有数据的收集，实现质量监控
业务监控：交付->研发。研发用来监控一些业务的成功率及业务的基础数据，偏自身业务
运营统计：交付->需求。交付反馈到产品经历，如友盟，SDK

4. 质量保证工作实施的三大阶段

4.1 研发阶段的质量保证

4.1.1 研发工程师的交付物

设计文档：需求文档、设计文档、接口文档
代码：Java、python
数据：SQL Mysql PG索引文件
可部署的产品：构建的二进制包、联调环境

4.1.2 研发阶段常见的质量保证手段

研发阶段的质量保证手段能够对阶段性的工作产出进行有效的评估度量，从而能更早的发现问题，有效的提升产品质量

4.1.2.1 代码评审（code review）

定义：
*    指对计算机源码系统化的审查、常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。
价值点：
*    代码规划约束，培养良好的代码习惯和追求
*    深入了解业务，实现知识和规划的传承
*    沟通设计思路并改进，互相评审防止代码烂设计进入
行业观点和落地：
*    行业经验普遍认为代码评审是最有效的质量保证手段
*    借助标准的代码管理工具即可，比如gitlab的pr机制
*    整个过程测试工程师参与度低

4.1.2.2 代码审计

定义：
*    是一种以发现程序错误、安全漏洞和违反程序规范为目标的源代码分析。是防御性编范式的一部分。该范式的目标是在程序发布前减少错误。
综合性的代码分析平台：
*    sonar支持自定义规则，较多的公司使用，推荐
*    360火线
IDE辅助功能：
*    Xcode，Android studio
*    阿里巴巴Java开发手册，IDE插件支持
独立的静态分析工具：
*    findbugs
*    pmd
*    androidlint
*    scan-build
静态分析技术分类：
*    lint系列：通过分析语法树和源代码分析代码规范
*    字节码检查：findbugs为代表：通过分析编译器给出的调用链和二进制字节码的调用链寻找逻辑缺陷
静态代码的在线规则库：
*    自定义规则
    *    sonar https://docs.sonarqube.org/display/DEV/Adding+Coding+Rules
    *    pmd https://pmd.github.io/pmd-5.5.5/customizing/howtowritearule.html
*    在线规则库
    *    360火线 http://magic.360.cn/
    *    FindBugs的规则库：http://findbugs.sourceforge.net/bugDescriptions.html
代码审计关注的质量指标：
*    代码坏味道
    *    代码规范
    *    技术债评估
*    bug和漏洞
*    代码重复度
*    单测与集成
    *    测试用例数量
    *    覆盖率

4.1.2.3 单元测试

定义：
*    是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法。
价值：
*    最底层的质量保护网
*    用于验证修改的影响范围
责任：
*    单元测试是研发同学的责任和义务
*    建立持续集成快速返回的机制
*    单测可测性是决定单测成败的关紧啊
*    覆盖度评估很关键
几乎所有的开源项目都有单测用例

4.1.2.3 自动化冒烟

debug版本的冒烟：
*    自动打debug包
*    基于debug包的自动化专项测试
    *    monkey健壮性测试
    *    自动化遍历+专项测试
        *    LeakCanary自动检测内存泄漏
        *    Bugly等检测崩溃
        *    BlockCanary检测卡顿
test版本的冒烟
*    少量的自动化冒烟用例
*    自动遍历+功能探索

4.1.2.4 研发自测

研发自测：
*    防止低质量的产品进入下游浪费成本
*    保证高质量交付有助于缩短项目工期
*    自查和自测试是负责人的态度，也是优秀的研发工程师的习惯
产品自测：
*    评估产品流程和UI设计是否符合预期
自测行为的监督与推动参照后面的监控体系

单元测试与review

4.2 测试阶段的质量保证

4.2.1 app交付策略</4>

内部交付
*    Jenkins自动打包
*    提供内部网站下载入口，供整个项目团队手工验证
公测：
*    使用fir.im bugly testflight服务
正式发布
*    打包渠道包推送到各市场
*    上传到app store

4.2.2 建立测试准入机制

建立合适的自动打包机制
*    自动对研发、测试分支进行打包
*    自动对相关分支进行测试
*    对研发分支进行自动化冒烟，确保研发分支无重大问题
*    对测试分支建立完善的测试
*    打回 or 测试
建立合适的版本管理机制
*    版本号的使用规范 三位+四位
*    根据版本号和commit id定位代码

特性分支->研发分支->测试分支->tag_第一轮-->tag_第二轮-->tag_第三轮->发布分支

常见后段发布机制

代码编译和发布包构建
*    后端打包mvn
*    移动端打包gradle cocospod
*    二进制部署打包 rpm docker
环境构建
*    docker等容器技术
*    jendins等自动构建和部署平台
测试推送
*    后段升级自动触发接口测试

特性分支->研发分支->sep分支->rc分支->prod分支

基本的测试checklist和手段

业务测试
回归测试
专项测试
质量监控

合理的测试安排

回归与新功能测试每次都要执行
专项测试可以每个大版本可测试一次

业务测试

价值
*    保证当前版本需求实现的正确
*    保证产品业务长期的功能正确
*    保证交互和产品体验
验证方式
*    目前人工测试审查为主
*    自动化验证辅助

4.3 发布后的质量监控

转载于:https://www.cnblogs.com/csj2018/p/11526846.html