【Android测试】【随笔】与 “58同城” 测试开发交流

◆版权声明：本文出自胖喵~的博客，转载必须注明出处。

转载请注明出处：http://www.cnblogs.com/by-dream/p/5384698.html

初衷

---

　　一直都有一个这样的想法：

　　虽然在我发出这个帖子之后没有人来主动和我交流，并且有人说这样的方法论会过于死板硬套，不能适用于实际复杂的业务测试中；但是我还是决定去写这样一个系列的文章，只要能够帮助到一部分的测试，哪怕不是很多，我也愿意尝试去做。

分享者简介

---

　　侯哥，4年测试开发经验，现任58同城**部门测试开发，擅长自动化测试。

　　这里非常感谢侯哥能够无私的将自己的经验分享出来（另外下文中出现的所有观点均是分享者的观点，不代表58集团）。

　

分享内容

---

　　侯哥分享的内容主要包含两部分：

　　一、业务测试

　　首先他跟进的业务比较特殊，业务的内容的不仅限在PC、手机站点还有App端的内容。他们会对每次的新需求进行一个划分：大项目和小项目。

　　先说小项目，小项目一般指的是不超过5个开发工作日的产品，针对这样的需求变动，基本就是开发完成后，做功能验证 如果涉及到页面的修改会考虑兼容性。兼容性主要只考虑系统兼容性和分辨率兼容性，大概是有一个这样的表，然后将同时满足系统版本和分表率的真机填入表中，用真机进行测试。

　　当然就目前的情况来看，Android基本上已经不关心Android 4.0 以下的，iOS 4s以下的设备也不再关注了，除非产品强烈建议。

　　介绍下大项目：由于大项目的开发周期比较长，测试可以较为提前的介入，首先，第一部分的测试是对于产品文档的评审。产品会把详细的文档发出来，他们会通过批注的方式对文档进行评审，然后产品对有疑问的地方，进行讲解或修改。当文档确定之后，就进入到了测试的第二部分，编写测试用例。目前会编写两种测试用例，冒烟测试用例和针对需求完善的测试用例。冒烟测试用例的使用者包括开发和测试人员，而完善的测试用例使用者主要是测试人员本身。开发提测之前，需要给出冒烟测试结果，所以冒烟测试用例需要在研发提测前一天给出。第三步，就是执行测试的过程了。这个过程，可能会分成两部分，如果涉及到接口的修改，就会有对应的接口测试，如果没有，就只针对需求的功能测试。

　　二、自动化测试（Android）

　　首先我问他为什么要做自动化？他说从他对于自动化的理解，出发点主要是两个。一个是便于回归和冒烟，另外一个就是测试知识的积累。为什么要做自动化，算一道题就明白了。当你有10个测试用例的时候，你执行一次的时间是10分钟。那当用例数扩大到100个，1000个，甚至几万个的时候。我们手动执行已经成为了不可能，那自动化就成为了必然。还是那句老话，测试的职责在于保证质量， 而穷尽测试是最能够保证质量的测试办法，当然我们都知道穷尽测试是不可能的。那我们就通过大面积的自动化测试来实现多种测试输入的组合，进而替代穷尽测试。如果非要说自动化测试提高了多少效率，我觉得可以提高百分百的效率，甚至更高。当我们把所有的自动化用例执行都放在晚上，那一个测试人员一天干了两个人的活。这就是他的观点。

　　接着是他介绍了他自己写的UI自动化的框架。目前市面上很多的UI自动化框架，功能很强大，使用很便捷。为什么他还要开发一套全新的框架呢。目的就是为了解决ui自动化维护成本高的问题。维护成本高的原因，可以从两个方面考虑，一是UI变动频繁需要经常修改，二是编写自动化脚本的成本高。他们新开发的自动化框架，从三个方面解决了编写成本的问题。一是，多层封装，减少暴露给用户的接口，减少学习和编写成本。二是，模拟类自然语言，大大降低编写门槛。三是，尽量放大测试用例颗粒度。

　　针对第一点可能不少人会有这样的疑问就是减少暴露的接口是否会导致功能的缺失，他会通过配置参数的方式，扩展接口的功能。比如滑动，我们增加一个参数 输入 top 就是向上滑动。针对第二点比较好理解，就是将函数方法名称封装成我们比较好理解的语言。第三点的意思可以理解为，减少用例个，比如测试一个数是否为自然数 我们设计用例 可能是 1 2 3 0 -1 等等，那就只写一个2 就算验证了。

　　整个架构的原理就是 底层调用adb shell 上层封装不同的接口 然后通过Python提供的 unittest 组合测试集，执行测试集的结果，通过html进行展示。整个自动化测试的框架设计，基于关键字驱动，他们定义了一些关键字，比如设备号， 用例名等等，根据对应的关键字来触发脚本执行。目前自动化脚本的使用场景主要是每次迭代的版本发布前，进行一次回归测试，当然会有一些误报，但是大大减少了回归测试的人力成本。没有发现问题说明我们目前的版本较稳定，如果发现问题，那就赶快处理，修改后再次回归。