在网易这一年来测试团队转型升级实践
有人喜欢创造世界，他们做了开发者；有的人喜欢开发者，他们做了测试员。什么是软件测试？软件测试就是一场本该在用户面前发生的灾难提前在自己面前发生了，这会让他们生出一种救世主的感觉，拯救了用户，也就拯救者这个软件，避免了他们被卸载的命运。
在外游荡一年回到网易，进到平台交友事业部，专注于移动互联网 APP 研发测试领域，在将近一年来的时间里，经历了开发、测试团队的转型，下面跟大家讲述讲述带领测试团队从挖掘痛点的转型之路，希望能给各位一点帮助。
测试团队现状
这个部门人员朝气蓬勃，个人认为更像一个创业型的公司，初期技术资源都投入到产品功能需求开发中，对于产品质量稍作妥协，不需要太严格的过程控制和质量把控，相比开发资源而言，测试的投入资源不是那么急需。
随着用户量的上升，各种类型的移动设备问题错综复杂，用户对产品的质量有要求，部门老大对质量越来越重视，狠抓这块，从 2017 年 Q4、2018 年 Q1 分别招入两批测试人员，整个技术团队对于质量把控的诉求越来越强烈了，到后来整个测试团队跟随开发团队的规模壮大而壮大起来了。
测试技能现状
所有产品线的测试手段都是以手工测试为主，自动化辅助手段较少，回归测试成本高，Android、iOS 独占测试人员忙于业务的功能性需求的黑盒测试，非功能性需求无法满足。
Android、iOS 与后端 Server 进行数据交互的 API 规范定义是一致的，早期无相关测试人员参与，导致发现 API 问题较晚，推迟到客户端功能开发完成阶段才进行检验，同时也造成后端 API 回归成本高；
功能测试以及 API 相关测试在研发测试过程走一轮、预发布环境第二轮、生产环境走第三轮，深度依赖于手工测试，发现问题滞后，相比需求、研发阶段修复的成本来说，发现的阶段越晚修复成本越高，最终可能导致带着严重问题上线运营。
测试流程现状
交付式测试，开发人员把相关功能任务设置为 done 之后交付给测试人员，测试人员未全程参与从需求源头开始跟进（及时了解需求背景和细节，消除需求含混性，及早开展测试用例编写工作），从而研发过程中客户端功能、后端 API 的可测试性（一个完整的功能是可以分多个功能小点提测，最终完整再提测一次）无法提高，测试人员也无法及早进行冒烟测试；
无测试人员专属的持续集成构建环境，Android、iOS 打包依赖开发，测试人员存在时间等待上的开销成本一直存在未能降低。
测试三轮验证：测试环境验证第一次、预发布验证第二次、生产验证第三次，为什么做三轮，这三轮的评估依据是什么？
整个测试过程，只有测试人员参与，产品、客户端开发同学的协助如何提升融入进来呢？
测试任务评估没有依据
针对需求的相关测试任务，出牌评估工时，没有评估依据，直接拍脑袋进行，体现在：这个需求需要测试哪些方面？涉及客户端 Android、iOS 哪些特性？有哪些兼容性需要测试？只有把所有相关点列出来，评估完整的时间，再进行合理的取舍，让质量维度维持在一个可接受的平衡点，而不是一味追求最高质量，往往很多时候，利用现有资源做最平衡的质量优化，可接受的容忍度。
所谓平衡点的简单例子：
字体样式的问题，并非致命的，可以权衡接受跟着上线；
客户端列表过长溢出，没有边界判断机制，这就是致命的，必须修复上线；
客户端数据出错了，后端还可以通过快速发布来解决，并不影响客户端的上线；
生产力改进实践
生产力改进实践环节，是围绕几个大方面开展的：
敏捷开发
建立 Scrum 流程框架（版本开发流程），以此为基础的版本开发模式，各个角色紧密配合的 PDCA 循环：高度合作，善于计划和总结、拥抱变化、高度可视化。
自研的燃尽图进度跟踪工具
过去 Jira 任务管理系统自带燃尽图不能根据团队特点，展示实际进度和体现反馈风险所在，导致错过反馈进度问题的最佳时间，因此根据团队特性，自研能够反馈实际进度的燃尽图，让项目进度透明化，技术、视觉、交互、产品都参与到风险识别和反馈中来。
带来的效益：
1.使用新版燃尽图之后，每日晨会分析历史进度问题有依据，能够明显看出风险所在
2.产品人员主动关注燃尽图趋势变化，及时调整有问题的任务，提高研发交付的时效
3.每日工时可以看到研发、测试人员的个人进度，及时沟通遇到的困难，推进解决
负责客户端的测试人员承担产品职责单一，技术要求多层次
最初测试人力资源不足，为了提高更大的复用率，要求每位测试人员负责客户端 Android、iOS 的两端的测试工作，编写一份基础用例，根据每端特性在测试过程中再改变策略，落地实施的第一个季度就暴露出问题：
同时兼顾一个产品多个功能的测试任务，对于客户端开发同学而言，他们是并行工作的，而测试同学需要在不同功能的 Android、iOS 两端来回切换，导致效率低；
同样问题也存在兼顾多个产品的测试任务，有些产品是同时进行的，需要在多个产品的任务中切换，导致对两个产品都不熟悉；
测试设备占用时间严重，在进行 Android、iOS 轮换切换的场景中，一人独占相关设备；
改进：单一职责，专职专责，原则上不再进行跨项目的版本任务，也不在版本中负责一个功能的 Android、iOS 相关测试任务（除了运营的相关活动项目可以兼顾 Android、iOS 测试），主攻 Android、iOS 单一方向的功能测试、自动化测试，说的高大上一点好像成了全栈测试工程师。
实施半年之后，收益颇深，各自负责 Android、iOS 的测试同学结对编写测试用例，抽取共性部分，运行时附加个性化的系统特性，并行测试效率提高，设备占用率降低。
自研的 API 管理和测试平台
过去后端的 API 规范是通过 word 文档进行管理，版本变更是需要手动通知相应人员，而且每个人编写的格式不统一，容易造成冲突，解决上有时间开销，另外修改跟踪反馈上的成本很高，开源项目中也没有能够适合交友团队模式的工具，因此投入开发 API 管理和测试平台。
考虑到客户端与后端交互是通过 API 进行，将 API 平台化管理带来效益：
使用平台化管理清晰呈现 MobileAPI 接口分布图，有效减轻了后端同学管理接口规范的工作 ;
方便客户端同学快速查阅和版本对比 ;
API 修改历史记录对比，修改后第一时间系统自动通知相关人员 ;
在接口定义完之后，可直接生成 API Mock，节约手工写 mock 接口的时间，客户端同学可以直接开始开发工作，与后端开发并行 ;
功能点包括以下三个方面：
API 统一规范
支持在线管理接口规范文档：接口规范管理功能有很多特性，包括自动生成 change log，自动生成技术审查的规范文档，review 通知，接口版本管理，支持任意历史版本的对比，方便追踪每个版本的变化。
后端同学只需要专注于接口定义，大大节约了文档维护的时间，更早投入开发工作。
API 模拟调试
平台支持从接口规范文档直接生成 API Mock，在后端接口开发完成之前，前端、客户端的同学利用 Mock Server 摆脱后端接口的依赖，直接开始开发工作，与后端开发并行。
API 自动化测试
平台支持从接口规范文档直接生成 API 测试用例，测试人员集中参与关键场景编写，执行用例之后自动生成测试报告咯，测试同学可以在后端开发的同时，写好测试用例，在开发完成后做冒烟测试，以及回归测试，提升测试效率。
图 -API 自动化测试报告
持续集成与静态代码分析
过去代码构建在开发人员本地进行，每次提交在解决冲突上时间开销大，每个环节发现的问题滞后，无法自动化集成、按需构建，以及代码的质量没有数据参考。
团队需要引入有效的自动化构建平台，以及静态代码分析平台，用以指导日常开发过程的质量改进，将代码问题的反馈机制自动化，构建数据可视化。
持续集成
为了让产品可以快速迭代，同时还能保持高质量。技术团队对各产品的各端都建立了持续构建平台：在代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。保证持续地发现、反馈和解决问题。
静态代码分析
为了保证代码质量，从代码层级降低线上出错的可能性，技术团队引入了静态代码分析技术：在不执行计算机程序的条件下，对源代码进行分析，找出代码的设计缺陷，例如代码规范、内存泄露，以及体现总体质量：代码覆盖度、技术债务的趋势图，通知技术改进，拦截在上线之前，这些数据都成为 QA 统计的数据来源。
客户端手工覆盖度数据收集工具
过去执行完测试用例之后，无法考量哪些代码覆盖了，哪些没有覆盖，测试用例写的好不好，为了解决这些困境，在客户端 Android、iOS 植入手工测试覆盖度工具，收集代码覆盖度展示，目的是找出测试过程中未被覆盖的代码，指导测试人员调整测试策略，开展探索式测试。
图 - 客户户端 UI 手工测试报告
下图是执行美聊 2.8 版本 iOS 相关用例后的统计结果，可以根据结果调整测试策略，例如：如果改动了登录模块，目前用例覆盖度比较低，那是需要加强特殊场景测试，还是其他方面呢？这个需要团队 review 下做出决定。
图 - 美聊 2.8-iOS 手工覆盖率
利用 BugTags 工具的问题反馈
过去发现线上问题无有效收集数据的手段，用户反馈之后，需要相关人员跟进沟通，询问环境、设备等诸多问题，整个过程繁琐，人力投入开销大，引入 BugTags 是为了简化 Bug 提交过程，记录重现场景相关信息，将客户端的大量复杂操作最大限度简化。通过白名单机制，美聊可以让用户打开 Bugtags 摇一摇问题，提交用户的相关环境、设备信息，进一步推进排查问题的效率。
如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以810119819，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。
BugBash 质量活动
传统的产品走查，产品、视觉、交付、运营只对自己负责的功能部分有了解和检查，缺乏一个需求方的整体走查。当有人发现一些功能间互相关联的问题时，已经比较晚，修复成本高。引入 Bug Bash（所谓 Bug 大扫除的活动），在项目开发阶段的末期，专门划出一个专门的时间段（通常 1 天），打破以往非技术人员未参与的做法，在这期间所有参与项目的人员（技术、产品、交互），集中全部精力，运用各方面的知识来搜寻项目的 Bug，做到及早发现问题。
会后将问题汇总，用以推动开发改进功能。
图 -Bugbash 记录
QA 数据收集
在 Sprint 总结会上为了让项目成员能更加清楚了解整个 Sprint 的质量、进度问题，从 Q4 开始对每个 Sprint 都做了数据收集和展示。通过收集每个迭代版本的工时、bug 数据，在总结会上向全体人员（技术、产品、视觉、交互、运营）呈现当前版本总体质量多维度数据，指导工作的改进方向。
· 按照阶段的 bug 分布展示
按照组件的 bug 分布展示
Android Monkey 崩溃性测试
持续集成环境每日代码 daily build 之后，夜间在测试专属服务器进行长达几个小时的 Android Monkey 崩溃性测试
兼容性质量风险控制转移
目前交友测试团队现有的 Android 测试机型不足，为了解决 Android 碎片化，特别是兼容性问题，借助公司内部的易测平台来控制质量风险。
重点关注基础兼容性：安装、启动、monkey 随机、卸载。
团队人才建设
17 年初的测试团队规模太小了，业务测试需求不足以满足，人员技能集中在黑盒测试，没有移动 UI 自动化测试、后端 Server API 自动化测试、测试平台开发的相关经验，并且全员对于 Android、iOS 代码不了解，白盒测试无实践经验，也会导致排查问题不够深入了解原理。
从 17 年 Q2 开始制定团队建设技术，那么整个测试团队的关注点是什么，如何聚焦，根据技术总体需求、产品需求来落实测试需求呢？
根据团队特性，测试、开发划分了边界，只有从这些方面出发，才能更好要求组员的技能形成阶梯化，以及在招聘要求是按照此需求来落地，市场上大有可为之人，如何切实际为之更重要，下面从几个方面来谈谈。
测试团队关注点
Martin Fowler 在博客中解释了TestPyramid，如下图所示：
如果对软件测试、接口测试、自动化测试、性能测试、LR脚本开发、面试经验交流。感兴趣可以810119819，群内会有不定期的发放免费的资料链接，这些资料都是从各个技术网站搜集、整理出来的，如果你有好的学习资料可以私聊发我，我会注明出处之后分享给大家。
单元测试是第一道测试关卡，也是一个陷阱，测试人员如果投入到此环节上，将是一种资源耗尽型的质量活动。比业务熟悉程度，测试人员没有开发人员高深，比写单元测试的效率，测试人员没有开发人员高效，这里交友测试团队也跳坑了，历经一个季度跳入、跳出，理想的状态下是：开发的框架很松耦合，例如使用了 MVP/MVVM 开发模式，实际情况是这些技术债务在逐步偿还，熟悉代码的开发人员进行单元测试都有阻碍，测试人员谈何容易，简单点来说不务正业，投入产出比低。
真正要从业务需求的痛点出发挖掘适合团队的方向：测试层次的关注点是最清晰的一条分水岭隔离开发代码级别的：单元测试、集成测试，测试人员真正的关注点是：以手工测试为主，自动化为辅的发展阶段，同时围绕整个研发测试过程的质量反馈，包括：需求阶段、开发阶段、发布阶段、运营阶段。
理清整个需求之后，就是团队成员角色转型：
分为三种：
基本职能：手工测试工程师，进阶职能的：自动化测试工程师，再高级一点，测试开发工程师，其实也可以称为全栈，名字不是最重要，也不会设立这种 title，只是要明确把活给细分出来。
最后，根据需求，也把产品测试人员分布明细理顺了：
按照此规划来落地招聘需求，避免因人设岗，而是实实在在的产品需求、技术需求来决定人才所向。
测试团队文化建设
由于篇幅有限，简单来说形成学习分享的技术氛围，让测试人员定期组织技术分享，这些技术主要是可以用于生产落地以及对新技术的调研成果展示均可，另外有一些虚拟组设置，例如：自动化测试组、平台开发组，用于把兴趣相同的组员融合到一起，投入到合适的方向上。
以上是本人在网易交友事业部一年以来对测试团队转型带来的分享，在合适的阶段对测试资源做合理的投入是有必要的，发展初期的困难适当取舍产品质量，换来更多功能亮点吸引用户，占领市场，站稳脚步，发展中期，确保用户的活跃、稳定，是需要靠产品质量取胜的，产品功能并不在于多花俏，有新意、简单化、易传播这几个点可以适当考虑，其实到了中后期，技术很多处于还债阶段，之前设计的系统业务模块解耦、微服务化，提高可测试性都非常重要，而测试人员往往对于技术还债的重构要更加留意，一不小心就掉进坑里，久久不能自拔，同时最后牺牲最宝贵的就是测试质量，这是需要取舍的，别以为质量就是高高在上，测试团队的利益应当与开发、产品团队的保持一致，这才是发展的硬道理。