[wordpress搬家]Android Testing — 应该被测试到的内容

[2013.10.10]

最近某一个项目原型已经搭建完成，需要进入测试环节，想想android的测试有很多可以抽象出来的用例，这里罗列一下，只是个人的一些经验总结，我会不断完善的，欢迎使劲拍砖。

代码走查
#编码规范(包、窥孔优化、工程结构、架构、Log细节、冗余代码）
#代码逻辑/状态机(无效逻辑剪枝、状态机优化、底层代码临界化)
#sql/io读写归并z

单元测试
#对于Service/Dao/Util/Android Dao层的事务测试

功能测试
#对应于App的feature，从使用角度入手进行测试
#UI相关测试(activity stack, 无冗余，工作堆栈互相无干扰； 增删改查后对应页面数据刷新，无错误)
#服务测试（杀死服务，重启后服务启动状态）

QA
#Binary混淆是否能够被反向工程
#安装包大小、图片资源的控制
#App发布
#升级策略
#电量测试
#CPU使用率
#网络流量
#Scalability测试(用户数量、数据数量最大值)
#性能测试(UI响应时间、)
#UI/UX等
#冒烟测试/Sanity Test
两种侧重不太一样，冒烟测试主要是最最基本的功能能够用就Ok
Sanity Test更像是一个小的迭代测试集合，选出一部分用例，在每个迭代时跑一边，覆盖绝大部分功能，让程序的正确度到一个较高的水平。
后者需要尽可能的自动化和高效。
#灾难测试（不同状态下杀死进程，高cpu/高流量/高负载(内存）下程序是否能够被杀死或者正确保存状态）
g

同时设计测试用例的时候永远要考虑的问题
#测试手动化 vs 测试自动化的
-有些测试只能手动测试，但这样的例子是不可迭代测试，或者花费很多人工
-有些用例能够进行自动化测试，但是框架太难搭建，也需要很多人工
-有些测试不用自动化你就会死，比如Scalability之类的测试
能够比较容易进行自动化测试的用例还是要设计成自动化的，Android工程支持xUnit测试，而且Java对应的JUnit已经广为人知，这点是其得天独厚的优势。理论上来讲单元测试都要自动化，功能测试能自动化的都要自动化，对于很难自动化的就需要进行精确度与人工的权衡了。

#真机测试 vs 虚拟机测试
手机有很多，真机最好能够覆盖所有主流机型，这需要对Android的Rom很熟悉，哪些Rom来自哪些开源构建等，在Android的版本树上作剪枝，钱花在刀刃上(如果能有个大方的老板最好……)。
但是虚拟机测试也是必须的，市面上上百种rom不可能都买个手机，即使都买过来也不太可能每个rom版本都测一遍，这就需要哪些所谓的云测试平台，如TestIn等，上面泡泡脚本，测测是否崩溃，没坏处。