由《再论移动无线应用专项》(https://testerhome.com/topics/3765) 引出，谈谈我对于测试工作的理念。

总体而言，我的专项测试理念：服务于目标需求，有选择的展开，先落地流程，逐步扩大战果并监控衰减，持续集成。保持工具及测试策略的项目复用性和设备兼容性。

基于我在设备端对系统的性能相关专项测试实践，在我的意识里专项大类分两部分：

1、验证设定结果的必测专项

首先不得不说，不同规模的公司和测试团队，能投入专项的时间和人力是有限的；根据人力和时间的总投入，建立起基本的测试固定流程保证产品基本的用户体验，专项只是其中的子集。

比如设备端测试：运营商入库有必测专项，场测也有专项需求，设备功耗续航是基本保障，wifi 及网络专项也是重要考量，性能测试专项，应用集成测试等等

比较而言移动无线应用的专项就少一些了，主要看涉及的产品要保证哪些验证点？

我能想到的验证点：功能，性能，兼容，容错，中断，后台接口，稳定性，交互体验，视觉效果，音视频质量与触发，使用场景测试，文本及多语言本地化验证，安全性测试，竞品对比。

面临的保障点过多，测试资源有限，自然就是有选择的取舍，有策略的覆盖测试。必测专项就是其中的子集。

当前的互联网思维，产品新功能到用户手中的节奏要求快，往往带着功能问题也是要推给用户尽快使用占据市场的。
在这大前提下，专项测试的效率及产出比就很重要，否则效率低就是大量铺人力并行进行测试。

往往测试周期内白天都投入了人力测试之中，整个测试流程中手工验证占据着大量的人时，人工部分的测试依靠的是测试策略缩减投入；研发设备充足前提下可以并行自动化测试，而下班时间也是可以充分利用投入自动化测试。

讨论专项首先要挑明的应该是适用性和优缺点，提出问题并给出自己项目的答案：

1、此专项验证了哪些问题？
2、此专项对于用户体验改善起到了什么帮助？
3、此专项需要投入多少资源完成测试？
4、此专项如果实施，用什么回归节奏来进行？
5、实施此专线是否有完整策略和自动化方案提高效率？
诸如此类自问自答，根据自身项目特点，有选择的进行必要性专项测试。

2、根据实际产出价值进行的扩展性专项

这里要重点谈论的就是有效利用充足设备并行自动化测试，及充分利用下班时间进行自动化测试及自动化数据收集了。毕竟只有充分自动化才能带来效率的提升。效率提升才带来了可观的产出比，才变成大家都愿意投入的测试专项。

再来谈专项技术，服务于两点，验证及数据采集。

1、验证类：

（1）稳定性压力测试

固定 case 自动化压力脚本，monkey，开关机压力，长时间播放压力，MTBF 专项等等。都是通过持续测试时间在反应用户使用的可靠性。

我自己所实践的稳定性压力测试，方针就是充分利用下班时间及手工需求之外的测试设备完成测试
具体讲如：shell 管理 monkey 测试，开关机压力脚本，接打电话的 MO/MT 压力测试脚本方案，自动化系统升降级压力测试，信号源切换压力测试脚本都是此类专项测试，脚本方案交付项目组各自实施。

（2）多项目的共性专项组：音视频触发，中断测试，文本多语言本地化测试。

由于音视频，音效是必要的组成部分。除了验证触发，还有音量，音质，画质。多语言本地化又需要共用文本组人员，对于此类测试需要更专业的验证人员来服务多项目的验证工作，此类测试由于多项目的共性原因，往往会被提出来成为专项测试组，一对多的服务于多项目。

2、数据类：

（1）测试策略

阶段性扩展测试覆盖用例及覆盖范围，逐步扩展测试内容。先落地流程在逐步扩大战果，监控衰减。
我所实践的性能测试及我自己建立的用例得分评价方案就是此思路在逐步做事情。

（2）数据收集与评价分析

采集数据类型：cpu，内存，响应时间，电量功耗，流量，用户数据上报。

我所做的监控类方案设计，MCM（cpu 内存监控），BTM（电量监控）、sim 卡信号强度监控、脚本分析升级包 system 分区变化（避免超分区上线导致版本编译失败，提前预警）。这些都是建立收集数据的脚本方案，并设计了数据可视化结果服务于数据分析。