每一个新开发的软件都避免不了测试,这里总结了一些Android系统的移动端APP测试的一些测试流程,希望可以给大家一些帮助。

1.
UI 测试

App主要核ui与实际设计的效果图是否一致;交互方面的问题建议,可以先与产品经理确认,确认通过后,才开始让开发实施更改或优化。

2.APP功能测试

根据软件说明或用户需求验证App的各个功能实现,实际测试过程一般都是根据功能测试用例来执行。测试覆盖率基本上都是有测试用例主导,也就是说在功能测试部分,是检验测试用例是否有效以及完整的,也就导致另外一个问题,测试用例怎么写的问题,将另外一篇文章来单独阐述测试用例的编写方法。

3.
中断测试

模拟用户真实使用App是会遇到的中断情况进行测试。

4.
兼容性测试

版本迭代的新旧版本的在功能,逻辑层面的兼容测试,同一个App
在不同系统版本运行,以及不同机型之间的适配测试。兼容测试:接口的兼容性测试能够保证大部分的功能完善;App在不同系统版本上保证运行。适配性:
屏幕,系统版本等。该部分通过第三方的云平台进行。

5.
性能测试

可测试的方面:

①安装和启动时间;

②CPU的占用;

③内存的占用;

④流量的耗用;

⑤电量的耗用;

⑥后端,测试App中的各类操作是否满足用户响应时间要求,主要是测试点在网速方面。

⑦后端,有网络并发。

6.
稳定性测试,压力测试

①在各种边界压力情况下(如电池、存储、网速等),验证App是否能正确响应。

②反复/长期操作下,系统资源是否占用异常;Android
可是使用adb命令。

③压力测试主要集中在后端,前端的压力测试目前测的较少。

7.安全测试

App安全测试大概划分为以下几类:

①从数据的本地存储到数据的传输、处理以及远程访问等各个环节,基于相应的安全标准/行业标准评估App的安全特性;

②借鉴在Web
App和网络安全测试的一些成功经验在智能终端App测试中进行裁减或适配;

③检测App的用户授权级别,数据泄漏,非法授权访问等;

④对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测,以期发现潜在的安全问题;

⑤基于各种通信协议或相应的行业安全标准检视App是否满足相应的要求。

8.用户体验测试

这个简单的说就是站在用户的角度上进行使用App,学习成本低,易上手等,可以进行用户盲测,根据用户反馈的意见进行修改。测试人员可以通过与其他竞争品进行对比,
或者根据较大厂商App的交互习惯进行比较。

9.
回归测试

主要有以下几方面进行测试:

①根据产品说明书或者功能文档进行功能确认。


重新将主要优先级较高的测试用例执行一遍。

③重新验证bug。

10.
线上测试

线上测试是产品上线之后一定要完成的,这部分可以根据场景化进行回归测试,其中网络环境要全部覆盖一遍。

这个东西好像我记得在我的移动APP测试经验里有写到。记得不是那么清楚了,正好今天有人问,我就整理一下贴出来给大家看看吧。

移动测试问题免费咨询

/ 1 /
软件权限
1)扣费风险:包括发送短信、拨打电话、连接网络等
2)隐私泄露风险:包括访问手机信息、访问联系人信息等
3)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
4)限制/允许使用手机功能接入互联网
5)限制/允许使用手机发送接受信息功能
6)限制/允许应用程序来注册自动启动应用程序
7)限制或使用本地连接
8)限制/允许使用手机拍照或录音
9)限制/允许使用手机读取用户数据
10)限制/允许使用手机写入用户数据
11)检测App的用户授权级别、数据泄漏、非法授权访问等

首先看看下面这个图

一、 测试周期

/ 2 /
安装与卸载安全性
1)应用程序应能正确安装到设备驱动程序上
2)能够在安装设备驱动程序上找到应用程序的相应图标
3)是否包含数字签名信息
4)JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
5)JAD文件显示的资料内容与应用程序显示的资料内容应一致
6)安装路径应能指定
7)没有用户的允许,应用程序不能预先设定自动启动
8)卸载是否安全,其安装进去的文件是否全部卸载
9)卸载用户使用过程中产生的文件是否有提示
10)其修改的配置信息是否复原
11)卸载是否影响其他软件的功能
12)卸载应该移除所有的文件

图片 1

测试周期一般为两周,根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管或产品经理确认项目排期。

 

二、测试资源

我想这幅图应该能够很明确的展示APP测试的流程了。然后需要说明的是执行测试那一段。因为用的xmind,字数太多图看起来就太小了,所以在这里说一下每个阶段对应的东西。

测试任务开始前,检查各项测试资源。

UI测试

产品功能需求文档

检查UI图片,icon,文字,布局等UI元素与效果图是否一致。一般UI方面不会存在特别严重的问题,作为建议提给产品就好了。

产品原型图

功能测试

产品效果图

检验功能是否符合需求,涉及到UI层,接口,数据,服务端,代码逻辑等。功能方面的缺陷一般被定义为严重缺陷,必须修复。如果在时间欠缺的情况下,可通过会议与产品,开发,运营,项目负责人多方商议后,确定在不影响本版本的情况下延期处理。

行为统计分析定义文档

健壮性测试

测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上;Symbian
v3/v5/Nokia Belle等)

检验产品在出现异常时的处理机制。同时需要检验出现这些异常场景,或者是比较极限的情况的时候会否出现crash、anr的情况。一般只要有处理就不会出现问题。需要注意一些极限和异常场景,还有中断和弱网的测试。

其他(例如有秒杀专题的项目,需要规划秒杀时间表;有优惠券使用的项目,需要申请添加优惠券数据;支付宝/银联支付功能的项目,需要提前申请支付宝/银联账户等等)

适配

二、测试要点

检验产品的兼容性,不同的硬件设备,分辨率,操作系统,屏幕尺寸,手机型号等。安卓这一块儿是不太好做的,国内的定制系统太多了,一般方法都是针对主流机型进行测试。

接收版本

稳定性测试

本人觉得,这个过程可以直接略过。非专业测试着,不喜勿拍。

这里通常使用的是monkey进行测试。之前我也是对monkey不屑一顾,后来经过前辈指点也是发现了它的强大之处。目前也属于正在学习的阶段。主要手段还是通过伪随机事件流,进行大量的点击,滑动等操作,主要是用来检测产品中隐藏的crash、anr的缺陷。

UI测试

性能测试

A)  确保手头的原型图与效果图为当前最新版本。

客户端性能:主要监测,客户端运行时设备的CPU,GPU,流量,耗电量,响应时间等数据。进行数据分析,针对客户端对产品进行优化,从而提升产品的竞争力。这里是可以检查出内存泄漏的哦。在深入的发掘可以分析客户端的性能瓶颈,甚至定位出影响客户端性能的代码。这一块儿作为APP的专项测试,实际上可以做的东西有很多,也值得大家去发掘去做。只是国内大部分中小型的公司还没有重视起来,都还属于走过场的形式,笔者也没有特别深入的去做,也就不讲了。

B)  确保产品UI符合产品经理制定的原型图与效果图。

服务端性能:主要监测,I/O,吞吐量,并发,压力,负载等数据。针对测试结果进行分析,寻找性能瓶颈,完成对性能的优化。主要目的是检查服务端的稳定性,能否达到预期目标,完成预期任务。这一块儿笔者还没有接触就不深谈了哈。

C) 
一切界面问题以效果图为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。

回归测试

D)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型。

回归测试,主要是针对开发修复的缺陷进行测试。评估改动的影响范围,有目标有针对性的进行测试。其实还需要对老版本的功能、数据等进行回归。不得不说黑盒就是麻烦,每一次改动,无论巨细,无论影响范围都必须要做这个。

功能测试

上线测试

A)  确保手头的功能需求文档为当前最新版本。

在发布上线之后,要在生产环境上进行最后一轮的系统测试。笔者一般是把前面所有做过的东西全部在做一次。

B)  确保所有的软件功能都已实现且逻辑正常。

 

C) 
一切功能问题以需求文档为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。个人建议,用户体验方面的建议,优先级放在修复bug之后。

嗯…这个是根据传统的瀑布式模型整理的东西。

D)若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现,必须得到产品经理的确认,而不是单单只听开发人员的技术解释。此处确认最好以邮件形式存在。

博客持续更新…东西也比较杂,毕竟咱也只是个小测试想到哪写到哪。只希望对大家有所帮助。

E)所有的“外部原因”问题,都需要尽早地督促开发人员与客户服务端人员联系协调解决。并在之后的测试报告中予以体现。

F)所有的“设计如此”、“延期处理”问题,都需要和产品经理确认后再进行验证。并在之后的测试报告中予以体现。

G)测试下单时,注册的测试账号必须符合公司规范;收货地址必须包含“测试”关键字,最好每次下单的名称中含有日期,以便查询;在正式环境中下单后必须取消该订单等。

兼容测试/性能测试

A)  确保软件在所有兼容机型上都能正常使用(ios一般需要兼容7或者6,
 ios5可以不用考虑,用户使用率已经低于5%以下)

B) 
对于低端性能兼容机上独有的问题(例如ios5以下、Android1.6以下),若在技术上难以修改或者由于排期的原因无法在短时间内改进,必须在测试日报中注明,并得到技术平台主管、产品经理以及运营人员的确认,最好以邮件的形式得到确认)

C) 
性能测试方面必须满足硬件压力条件下的测试需要(例如多线程,用户常用的app都要后台运行的环境中测试。)

D)网络响应用户体验方面的性能测试,需要保证在wifi、3g、2g网络下的切换效果。比如wifi切换到2g,网络响应的速度以及切换界面。

后台订单统计测试

A) 
核对“客户端相关启动查询”项,此项数据就是经常说的“激活量”,非常重要。测试时必须保证该项中的各数据均正确,且每次启动软件都会有相应的统计记录。

B) 
核对“订单查询”项,测试时必须保证各数据均正确,且每次成功下单后都会有相应的统计记录。

C) 
需要注意的是,在成功下单之后,后台会做判断将该订单划到测试订单范围,测试人员必须到“订单查询(测试)”模块中核对订单统计记录信息。

用户行为统计测试

A)确保手头的行为统计分析定义文档为最新版本,且与开发人员手中的文档一致。

B)确保产品经理在文档中所定义的页面在该产品中都是存在的。

C)尽可能真实地模拟用户行为。

D)核对统计日志,确保各项操作所对应的页面ID以及操作ID都是正确的。

回归测试

A)软件最终上线前,需对产品进行回归测试,测试内容包含之前所有的测试项目

B)回归测试不再对细节进行测试,而是类似于对产品进行验收,从客户正常使用的角度对产品进行再一轮的整体测试。

C)只有在回归测试通过之后,才对产品进行提交。

三、测试日报及产品上线报告

测试人员每天需对所测项目发送测试日报。

测试日报所包含的内容为:

A)对当前测试版本质量进行分级。

B)对较严重的问题进行例举,提示开发人员优先修改。

C)对版本的整体情况进行评估。

产品上线前,测试人员发送产品上线报告

点击移动测试问题免费专家咨询

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图