APP端用例编写规则.docxVIP

在我们的测试工作中，对于某个 APP 的测试其实有很多东西都是类似的可以抽象 出来的，所以针对 APP的测试过程和重点关注内容，做以下梳理和总结。 一、 首先是测试资源确认及准备 1.1 产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全； 1.2 测试设备及工具的准备：IOS和andriod不同版本的真机，以及相关测试工具的准备。 二、 测试用例的设计与评审 （1）根据产品需求文档、产品原型图等文档，设计客户端的一般功能测试用例； （ 2）测试用例评审、修改与完善，评审通过后着手进入正式测试阶段。 三、 UI 测试 （1） 确保手头的原型图与效果图为当前最新版本，符合产品经理及用户要求； （2） 测试过程中一切以效果图为准，若有用户体验方面的建议，可以先以邮件的形式 与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题； （3） 由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现 的数据类型。 四、 功能测试 （1） 功能测试时主要依据编写的功能测试用例进行软件功能的遍历； （2） 涉及的测试主要包括基本功能测试， 安装、卸载、运行测试，异常处理（包括网 络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。 五、 中断测试（切换后台） （ 1）软件运行过程中接电话、收短信、锁屏、闹铃、充电，收到通知提醒后再使用软 件，软件应仍可正常运行使用； （ 2）软件运行时，由前台切换到后台，再切回前台后，应仍可正常运行使用。 （ios 切后台软件停止运行 安卓会在后台运行） 六、 兼容性及适配测试 （1）硬件的适配：不同手机厂商、硬件性能，不同屏幕大小的适配； （2） OS版本的兼容：IOS6-9; Andriod3以上等，如果用了一些新的 API在老的系统上 不支持会导致 crash； （3） 不同分辨率屏幕的适配：移动设备的分辨率多种多样，如果 APP没有做比较合适 的处理就可能会显示不好，甚至影响功能的操作。 （ 4）兼容性测试必须在一定数量的真机上进行，由于真机类型过多，尤其 Android 在 做兼容性测试时，可以选取典型的几种运用较多的真机，进行兼容性测试; （ 5）另外可以借助开源测试 testin 云测，进行更多机型的兼容性测试， testin 云测提供 基本的运行情况和一些截图，以及简单的测试报告，有助于扩大测试的范围。 七、 性能测试 （ 1）客户端性能测试重点关注：安装卸载时间、启动时间、页面加载时间、主要功能 占用的CPU内存、流量、耗电量等，以及与同类产品相比较是否有优势； 2)其中页面加载时间可以利用 Android 调试工具 DDMS 获取到，在 DDMS 里面搜索 Displayed 关键字就可以看到页面加载时间； 运行过程中主要功能占用的 CPU内存、流量等可以借助开源工具 emmagee (适 用于 Android )获取到； ( 4)至于服务器端的性能，主要利用接口对服务器施加压力，重点关注响应时间、吞 吐量、并发数、事物通过率等，可以视同工具 loadrunner 、 jmeter 进行测试。 八、稳定性测试 8.1 安卓APP的稳定性常常使用 monkey命令进行测试，通过随机事件流模拟人的操作， 对 检查程序的内存溢出、空指针有很大的作用。 8.2 Monkey主要用来检测系统 ANR及Crash等问题 九、测试分析及测试报告输出 以上各项测试结束后，应该形成完整的分析及报告文档 (包括buglist、性能及稳定性结 果分析，版本上线风险分析等内容) ，输出给各项相关人员。 十、移动端测试用例的实践经验 每种测试方法其实都有一个最佳测试时间， 如在版本测试阶段， 我们应当要先做基本功 能测试， 边界分析测试和中断，交互功能测试， 快速发现 bug 提单给开发去快速修复，保证 主体功能可以尽快得到保证， 而不是一开始就先纠结与性能， 压力和兼容测试。 一方面这类 测试往往所消耗的时间会很长， 降低了发现 bug 的速度， 另一方面先做这部分测试后， 再去 发现主体功能的bug，那么在开发人员动了大量代码之后，还是要再执行一遍性能，压力和 兼容测试的相关用例，不仅劳命伤财，效果还事倍功半。 所以在实际项目测试中， 当前我们的项目将测试内容分为功能测试， 兼容性测试， 性能 测试，稳定性测试四项，分别在不同的测试阶段进行(具体排期在测试计划时确定) ： ( 1)功能测试 —— 版本测试阶段 ( 2)兼容性测试 —— 回归测试阶段前期 ( 3)性能测试 —— 回归测试阶段，版本功能稳定后执行 ( 4)稳定性测试 —— 贯穿整个测试阶段，每晚执行 monkey 因此我们的功能用例更多的会使用 『基本功能测试』 ，『边界分析测试』 『中断功能测试』 『