就在两小时前,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,获取更多测试干货!