如何治疗app功能测试中的头疼脑热？（一）

 

在移动互联网蓬勃发展的今天，移动APP测试工作现状，已经是家家有本难念的经。不管公司大小，不管测试什么样的app，重复性最多，测试工作量最大的功能测试，都让测试者苦不堪言。这个系列文章，将逐一解构一些问题。

笔者经常看到各种稀奇古怪的APP，相信读者近两年也很纳闷，各类APP如雨后春笋般冒出，大部分app给人的感觉是“很难用”。为什么？就是其软件质量不过关，用户使用过程碰到各种异常导致用户弃用该APP。

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

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

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

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

本文先解决第一个问题：

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

毫无疑问，很多测试接口人或者测试者都遇到过这种情况，开发人员完成功能开发就丢给测试人员，你问他自测过吗，他的回答是肯定的。而往往测试人员一验证就发现冒烟不能通过，再打回重新修改，一来二往，时间浪费了，测试人员不胜其烦的为开发做了验证工作。到最后项目时间变得很紧张，因为在国内测试主要是后期工作，这时间压力就落到测试者头上。测试不完整导致的黑锅也是测试人员背了。

TestBird自助功能测试平台，基于云手机的基础建设，将功能测试搬到线上，开发再也不能找借口说：没手机了！而无论怎样，你先给我自测，测没测过，咱们一目了然！

该平台将用户做功能测试的全过程清晰记录下来，并以执行用例的方式呈现，测试成功与否，测试问题截图日志全部都自动保存。对中小公司来讲无疑是一个全新的利器！