就在两小时前，WiFi 管家刚刚发布了 3.0 版本。做完最后一个专项汇报，坐在屏幕前揉了揉肩膀松了口气。一种特别的情绪突然蔓延开来。
算一算时间，已经陪它走过了第三个年头。作为这个产品的测试第一人，心底涌起的情感催促着我，是时候总结一些东西，一来作为点滴回忆记录，二来作为经验总结沉淀。
本次总结，借用一纸芳华诉说流年——既描述过去，也展望未来。
内容包括以下几点：
WiFi 管家前世今生
WiFi 测试雄关漫道
总结&展望
WiFi 管家萌芽于手机管家 5.0 版本里的模块【WiFi 管理】，入口在快捷中心。
（1）测试投入重心变化
测试同学从最初保证业务测试的完成，经过这三个阶段发展的不同需求，也发生了一些职能变化。从 “如何测得更全” 到 “如何测试更准” 再到 “如何测得又快又准”，后面 “测试策略” 篇幅会细讲面对这样的职能要求，我们是如何开展测试的。
（1）研发流程变化：细化关键流程和成员职责
图—孕育期、引入期研发流程图
图—发展期研发流程
从研发流程的变化可以看得到，由于业务的调整，在孕育期和引入期均是按手管原先制定的 FT 流程来走，而随着项目组人员的扩充，把原先流程拆解更细化，对应的角色分工也更明确。
（2）测试流程变化：以需求为粒度贯穿全程
WiFi 管家孕育期：需求与提测未有工具可关联，直接根据需求文档，按计划在 rdm 打包，转提测任务，再输出测试报告，闭环一个测试周期。
WiFi 管家引入期到发展期：利用 Tapd 管理需求，从一个需求的创建到正式环境测试完成为一个测试周期，在故事墙可以很清晰看到每个节点每个需求的状态和生命周期。
（3）角色职责变化：从模糊到清晰
这份 Checklist 是从无到有，从引入期到发展期诞生的，各角色分工 Checklist 图清晰定义了整个项目过程，包括测试同学在内的各角色接入的时机与对应要做的事情。
（1）测试方法变化：由手工到多样化
（2）测试分析发展：从 0 到 1，探索无穷
由测试方法的发展可以得知，测试分析是在引入期才开始出现的，通过测试分析让我们的测试更精准高效。
（3）用例管理：由加法到减法
WiFi 管家 1.0 的到来，用例的移植成了很大的挑战：
1）用例量庞大：以笔者的用例为例子，每个版本都有一份该版本的用例以及一份总用例，总用例文件分散，用例数多（总用例数接近 2000），无整体清晰视图；
2）可读性差：由于测试人员分工的不断调整，同个模块的用例的维护是经由几轮不同编写风格的迭代，甚至有些用例格式不统一（既有 excel 又有 mm 图）；
3）用例优先级不明确：用例优先级是凭经验拍脑袋定的，同时历经几个版本未对旧用例的优先级做调整，导致测试执行时间冗长且部分用例已不是核心内容。
为了解决这些问题，在 WiFi 管家 2.0 版本引入了 ACC 测试建模 + 大数据相结合的思想，完成了一次华丽的用例删减，也大大提高了效率。
（4）自动化/专项情况：由整体到场景
从最初的纯手工，到接入长板（整体性能）自动化测试，再到基于场景的自动化测试，在专项测试方面一直在探索无穷的进步的可能性。
（1）测试计划制定：从粗糙到精细
测试计划是测试过程的整体设计。测试计划最初是相对粗糙的，只考虑了功能测试。慢慢地，测试计划包括对测试范围、测试风险进行分析，对测试用例、工作量、人力和时间等进行估算。
制定测试计划步骤如下：
下图是测试计划的例子：
（2）测试进度： Tapd 缺陷报告每日同步 + 需求粒度测试进度记录
测试进度同步经历由人肉到自动化、从粗到细的过程。
（3）测试风险把控： 抽象方法论
测试风险，就是在软件测试过程已经出现或潜在的问题，造成测试的结果不准确或进度延后于预期。
如何识别和把控测试风险？经过近几年的抽象和总结，可以用下表来概括：
（4）测试规范： 从无序到有序
由于 WiFi 测试同学的增加，关于用例、执行、需求变更把控、缺陷提交，都急需一套规范来保证。从 1 人的无序状态，到当下的有序，摸索接近一年时间。
陪伴是最长期的告白。WiFi 测试路漫漫，在此鸣谢团队的每一位成员，感谢大家一路陪伴，一起分担，一起成长。
问题：你的团队这几年测试路遇到了什么困难呢？又是如何解决的呢?
关注微信公众号腾讯移动品质中心 TMQ，获取更多测试干货！
