179 lines
9.7 KiB
Markdown
179 lines
9.7 KiB
Markdown
|
## 1.移动app特性
|
|||
|
|
|
|||
|
|
● 设备多样性
|
|||
|
|
● 网络多样性
|
|||
|
|
● 平台多样性
|
|||
|
|
|
|||
|
|
## 2.移动app测试与传统软件测试对区别
|
|||
|
|
|
|||
|
|
● 页面布局不同
|
|||
|
|
● 使用场合不同
|
|||
|
|
● 输入方法不同
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
● 操作方式不同
|
|||
|
|
|
|||
|
|
## 3移动app测试要点及其内容
|
|||
|
|
|
|||
|
|
### 1.UI测试
|
|||
|
|
|
|||
|
|
移动App的UI测试主要测试App界面（如窗口、菜单、对话框）布局、风格是否满足客户要求，文字表述是否简洁准确、页面是否美观、操作是否友好等。
|
|||
|
|
|
|||
|
|
#### 1.界面布局
|
|||
|
|
|
|||
|
|
● 界面布局合理且友好，符合用户习惯。
|
|||
|
|
● 列表型界面有滚动条。
|
|||
|
|
● 功能入口明显，容易找见。
|
|||
|
|
|
|||
|
|
#### 2.图形测试
|
|||
|
|
|
|||
|
|
● 图片大小合适，显示清晰。
|
|||
|
|
● 页面字体与风格一致。
|
|||
|
|
● 背景颜色和字体、图片颜色搭配得当，让用户视觉体验良好。
|
|||
|
|
|
|||
|
|
#### 3.内容测试
|
|||
|
|
|
|||
|
|
● 文字表达准确，符合App功能。
|
|||
|
|
● 文字没有错别字。
|
|||
|
|
● 文字用语简洁友好。
|
|||
|
|
|
|||
|
|
### 2.功能测试
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
#### 1.切换测试
|
|||
|
|
|
|||
|
|
● 后台切换：当并行运行多个程序时，在程序之间进行切换，要确保再次切换回来时App还保持在原来的页面上。
|
|||
|
|
|
|||
|
|
● 删除进程：测试从后台直接删除进程，当再次打开App时是否符合概要设计描述，同时测试删除进程时是否将App建立的会话一起删除。
|
|||
|
|
|
|||
|
|
● 锁屏：锁屏包括手动锁屏和自动锁屏，测试锁屏之后App响应是否符合概要设计的要求，例如再次打开时App还保持原来的页面可以继续使用，当锁屏达到一定时间后就自动退出程序。
|
|||
|
|
|
|||
|
|
#### 2.推送测试
|
|||
|
|
|
|||
|
|
在使用计算机时，经常会收到推送信息，这些推送有的是系统推送，有的是软件推送。在移动端，移动App也会推送，例如支付宝推送一个红包、今日头条推送实时热点新闻等，移动App的推送功能也需要进行测试，确保App推送及时，并且用户可以及时收到推送。
|
|||
|
|
|
|||
|
|
### 3.专项测试
|
|||
|
|
|
|||
|
|
#### 1.安装测试
|
|||
|
|
|
|||
|
|
● 移动App的安装渠道比较多，如谷歌应用商店、应用宝等，甚至可以通过扫码安装，对于多渠道的安装方式，在测试时每个渠道都要进行测试，以确保通过每个渠道都能正确安装软件。对于已经安装的软件，如果再次安装，要弹出已安装或更新提示，而不是产生冲突。
|
|||
|
|
|
|||
|
|
● 移动设备比较多，例如一个品牌的手机会有不同的系列，每个系列也会有多个型号，此外，移动App所依赖的平台也比较多，在测试时要考虑App对不同手机、不同操作系统的兼容性。
|
|||
|
|
|
|||
|
|
● App在安装过程中是否可以取消安装，如果可以取消安装，确保取消安装的处理要与App概要设计描述一致，例如，如果App概要设计描述取消安装的处理过程为：取消安装进行回滚处理，将已经安装的文件全部删除；那么在实际取消安装时也必须如此处理。
|
|||
|
|
|
|||
|
|
● 如果安装过程出现意外情况，如死机、重启、电量耗尽关机等，App安装的处理是否与App概要设计一致，如中断安装，当再次开机时继续安装；启动后台进程守护安装，当再次开机时提示App安装完成。
|
|||
|
|
|
|||
|
|
● 如果移动设备空间不足，要确保有相应提示，例如，当剩下100MB空间时，要安装一个200MB的App，有的App直接提示空间不足，无法安装；有的App会先安装，待空间用尽时再提示。
|
|||
|
|
|
|||
|
|
● App安装过程要进行UI测试，例如给用户提供进度条提示。
|
|||
|
|
|
|||
|
|
● App安装完成之后，测试其是否能正常运行，安装后的文件夹及文件是否写入到了指定的目录下。
|
|||
|
|
|
|||
|
|
#### 2.卸载测试
|
|||
|
|
|
|||
|
|
● 在卸载时，有卸载提示信息。
|
|||
|
|
|
|||
|
|
● App在卸载过程中是否支持取消卸载，如果支持取消卸载，要确保取消卸载的处理与App概要设计描述一致。
|
|||
|
|
|
|||
|
|
● 卸载软件的过程中如果出现意外情况，如死机、重启、电量耗尽关机等，要有相应的处理措施，如进行回滚，当再次开机时需要重新卸载；
|
|||
|
|
|
|||
|
|
● 中断卸载，当再次开机时继续卸载；启动后台进程守护卸载，当再次开机时提示卸载完成。
|
|||
|
|
|
|||
|
|
● 卸载过程要进行UI测试，例如给用户提供进度条提示。
|
|||
|
|
|
|||
|
|
● 卸载完成之后，App相应的安装文件是否要全部删除，应当给用户一个提示信息，提示相应文件全部删除或者让用户自己选择是否删除。
|
|||
|
|
|
|||
|
|
#### 3.升级测试
|
|||
|
|
|
|||
|
|
● 如果有新版本升级，打开软件时要有相应提示。
|
|||
|
|
|
|||
|
|
● 升级包下载中断时要有相应处理措施，支持继续下载或者重新下载。
|
|||
|
|
|
|||
|
|
● App安装渠道有多种，相应的升级渠道也有多种，要对多渠道升级进行测试，确保每个渠道的升级都能顺利完成。
|
|||
|
|
|
|||
|
|
● 测试不同操作系统版本时软件升级是否都能通过。
|
|||
|
|
|
|||
|
|
#### 4.交互性测试
|
|||
|
|
|
|||
|
|
移动设备大多具有电话、短信、蓝牙、手电筒等功能，在使用App时难免会受到干扰，例如使用App时，如果需要拨打/接听电话、启动蓝牙、相机、手电筒等，App要做好相应的处理措施，确保App不会产生功能性错误。
|
|||
|
|
|
|||
|
|
#### 5.弱网测试
|
|||
|
|
|
|||
|
|
移动App使用移动网络，移动网络的情况比较复杂，网络信号会受到环境的影响，容易发生网络不稳定的情况，而很多App的一些隐藏问题只有在复杂的网络环境下才会显现出来，例如正在使用的App遇到网络信号切换或变弱时，App不能响应或产生功能性错误，因此在测试时要特别对App进行弱网测试，及早发现问题。
|
|||
|
|
|
|||
|
|
#### 6.耗电量测试
|
|||
|
|
|
|||
|
|
移动设备电量一直是困扰用户的一个问题，同时也是移动设备发展的一个瓶颈，如果App架构设计不好，或者代码有缺陷，就可能导致电量消耗比较高，因此App耗电量测试也很重要。如果App耗电量较高，改进App使其在电量不足的情况下，让App释放掉一部分性能以节省电量。
|
|||
|
|
|
|||
|
|
### 4.性能测试
|
|||
|
|
|
|||
|
|
#### 1.边界测试
|
|||
|
|
|
|||
|
|
在各种边界压力下，如电量不足、存储空间不足、网络不稳定，测试App是否能正确响应、正常运行。
|
|||
|
|
|
|||
|
|
#### 2.压力测试
|
|||
|
|
|
|||
|
|
对移动App不断施加压力，如不断增加负载、不断增大数据吞吐量等以确定App的服务瓶颈，获得App能提供的最大服务级别，确定App性能是否满足用户需求。
|
|||
|
|
|
|||
|
|
#### 3.响应能力测试
|
|||
|
|
|
|||
|
|
响应能力测试实质上也是一种压力测试，在一定条件下App是否可以正确响应，响应时间是否超过了客户需求。
|
|||
|
|
|
|||
|
|
#### 4.耗能测试
|
|||
|
|
|
|||
|
|
测试App运行时对移动设备的资源占用情况，包括内存、CPU消耗，App长期运行时耗电量、耗流量情况，验证App对资源的消耗是否满足用户需求。
|
|||
|
|
|
|||
|
|
## 4.移动app测试流程
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
● 接受测试版本：由开发人员提交给测试人员。
|
|||
|
|
● App版本测试：主要检查测试App开发阶段对应的版本是否一致。
|
|||
|
|
● UI测试：检查App界面是否与需求设计的效果一致。
|
|||
|
|
● 功能测试：核对项目需求文档，测试App功能是否满足客户需求。
|
|||
|
|
● 专项测试：对移动App进行专项测试。
|
|||
|
|
● 正式环境测试：模拟实际使用环境进行测试
|
|||
|
|
● 上线准备：测试通过后，对测试结果进行总结分析，为App上线作准备。
|
|||
|
|
|
|||
|
|
## 5.移动app测试工具
|
|||
|
|
|
|||
|
|
### 1.Appium
|
|||
|
|
|
|||
|
|
Appium是一个开源、跨平台的自动化测试框架，它使用WebDriver协议驱动Android设备、iOS设备和Windows应用程序。
|
|||
|
|
|
|||
|
|
### 2.UI Automator
|
|||
|
|
|
|||
|
|
UI Automator是Android4.1以上版本自带的一个测试框架，它既可以做UI测试也可以做功能测试。UI Automator是黑盒测试框架，测试人员不需要获取对象源码就可以使用它对App进行UI测试和功能测试。
|
|||
|
|
|
|||
|
|
### 3.Monkey
|
|||
|
|
|
|||
|
|
Monkey也是安卓官方SDK自带的自动化测试工具。它是运行在模拟器或真实设备上的程序，可以生成用户事件随机流（点击、触摸、手势以及系统级事件），Monkey测试中的所有事件都是随机的，不带任何主观性。Monkey常用于应用程序的压力测试。
|
|||
|
|
|
|||
|
|
## 6.测试工作中测试活动及其相关内容
|
|||
|
|
|
|||
|
|
### 1.需求评审
|
|||
|
|
|
|||
|
|
在整个团队拿到需求之后的第一件事是进行需求分析，看看要这个软件要实现哪些需求。需求分析的后一步就是需求评审了，这个环节需要软件测试工程师与产品需求人员、开发人员、QA人员共同进行参与，评审这些需求能不能够实现。
|
|||
|
|
|
|||
|
|
### 2.写测试计划
|
|||
|
|
|
|||
|
|
接下来在开发人员编写开发计划的同时，测试人员要写测试计划，就是哪些人要在什么时间做哪些测试工作，最后产出什么工作结果也就是提交哪些文档。
|
|||
|
|
|
|||
|
|
### 3.编写测试用例
|
|||
|
|
|
|||
|
|
测试用例就是指导测试工作进行的文档，比如要测试系统的登录功能、购买功能等，会通过测试方法和策略来设计测试用例。所以编写测试用例是软件测试工程师进行测试之外最重要的工作了。
|
|||
|
|
|
|||
|
|
### 4.用例评审
|
|||
|
|
|
|||
|
|
用例评审就是评价和审查测试方法和测试内容是否合理全面。不能只做基础的测试工作就可以，还得全面进行可能会出现各种各样错误的测试，尽可能把bug降到最低。
|
|||
|
|
|
|||
|
|
### 5.执行测试、提交bug
|
|||
|
|
|
|||
|
|
执行测试自然不必多说，就是测试工程师真刀真枪地进行测试工作，找出了bug之后会进行提交，让软件开发人员进行修改。
|
|||
|
|
|
|||
|
|
### 6.回归测试、编写测试总结报告
|
|||
|
|
|
|||
|
|
回归测试就是对开发人员改好bug的软件再次进行测试，看bug是否都已经修改好。待bug都修改好之后，测试人员要编写测试总结报告，阐述软件的质量如何，软件才可以上线发布。
|