如今，随着移动互联网的浪潮越翻越涌，移动APP测试工作的现状已经成了那本“家家难念“的经。不管公司大小，不管测试哪种类型的APP，让广泛测试者苦不堪言的就属重复性最多，测试工作量最大的功能测试。而这个系列文章将逐一解构一些问题。

笔者通过对目前大型的安卓市场和APPstore进行调查，其实我们可以发现每天都不乏有有创意的，能够针对市场需求的APP上线，但不管当时这些APP是不是排在榜单前列，过不了多久，它们便在应用市场中销声匿迹，变成所谓的“僵尸”应用。

面对这些如雨后春笋般冒出的APP，若是你使用过的话，其实就可以发现一个常见的问题—APP本身不错，但用户使用过中程碰到了各种异常，面对这样的情况，一般用户都会选择删除，继而选择其他更适合的APP。

大公司：有多名测试专家，有庞大的测试用例库，测试工作分工明确，做功能测试的人员通常固定，新员工能力建设主要通过执行用例。功能测试人员耗费了大量时间在与开发的沟通博弈上。

中型公司：有一个看得过去的测试团队，测试用例和测试平台管理通常有待完善，而测试人员流动性对其测试能力的建设和传递提出了很大考验。通常一个人负责多项测试工作，时间耗费最多而对能力提升最小的手工功能测试则让测试者崩溃。

小型公司：只有一两个测试人员甚至没有，快速的研发进程都让研发团队应接不暇，更多的就忽略了全面的功能测试，更不用说测试体系建立。

而对中小型公司来说，版本迭代没有严格的流程，通常版本提交测试后，发现很多问题导致冒烟不能通过，反反复复。

本文先解决第一个问题：

怎样提高中小型公司测试执行的规范性，让测试驱动开发进行自测？

毫无疑问，很多测试接口人或者测试者都遇到过这种情况，开发人员完成功能开发就丢给测试人员，你问他自测过吗，他的回答是肯定的。

而往往测试人员一验证就发现冒烟不能通过，再打回重新修改，一来二往，时间浪费了，测试人员不胜其烦地为开发做了验证工作。

你再问开发“你到底有没有自己好好做一轮功能测试？”

开发回复你“哦，我这边没有手机了~”

到最后项目时间变得很紧张，因为在国内测试主要是后期工作，这时间压力就落到测试者头上。测试不完整导致的大黑锅便自然落在了测试人员身上。

我们基于云手机把功能测试搬到线上，这样避免了双方责任推诿，通过工具详细记录测试过程，并以执行用例的方式呈现。测试成功与否，测试问题截图日志全部都自动保存。

测试结果可以直观看到，省去了一来二去的相互推诿，不管是开发还是测试，工作效率都会更高。

驱动开发去自测，APP开发的流程会更加自然而规范