APP测试规范

APP测试规范
APP测试规范

a p p客户端测试规范

APP测试流程

目录

1. 测试基本流程图 (4)

2.8回归测试

3.App测试点 (7)

3.1安全测试 (7)

3.1.1软件权限 (7)

3.1.2安装与卸载安全性 (7)

3.1.3数据安全性 (8)

3.1.4通讯安全性 (9)

3.1.5人机接口安全性 (9)

3.4.2应用的前后台切换 (14)

3.4.3免登录 (14)

3.4.4数据更新 (15)

3.4.5离线浏览(无网测试) (15)

3.4.6 App更新 (15)

3.4.7定位、照相机服务 (16)

3.4.8时间测试 (16)

3.4.9 PUSH测试 (16)

(20)

3.12接口测试 (20)

3.13 客户端数据库测试 (21)

1.测试基本流程图

2.测试要点

2.1测试资源

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

1)

2)

3)

4)

2.2

5)

6)

2.3

1)

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

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

询问产品经理。

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

据类型

2.4功能测试

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

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

3)一切功能问题以需求文档为准,若有用户体验方面的建议,必须先以邮件或口头的形

式询问产品经理。

4)

5)

6)

7)

8)

2.5

1)

2)

营人员的确认。

3)性能测试方面必须满足硬件压力条件下的测试需要(例如多线程)

4)网络响应用户体验方面的性能测试,请参考且遵守《Mobile app可用性能标准》。

2.6后台数据统计测试

1)核对“客户端相关?启动查询”项,此项数据就是经常说的“激活量”,非常重要。测

试时必须保证该项中的各数据均正确,且每次启动软件都会有相应的统计记录。

2)核对“借款查询”项,测试时必须保证各数据均正确,且每次成功借款后都会有相应

的统计记录。

3)需要注意的是,在成功借款之后,BI后台会做判断将该记录划到测试单范围,测试人

2.7

1)

2)

3)

4)

2.8

1)

2)

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

3.App测试点

3.1安全测试

3.1.1软件权限

1)扣费风险:包括发送短信、拨打电话、连接网络等(询问权限)2)

3)

4)

5)

6)

7)

8)

9)

10)

11)

1)应用程序应能正确安装到设备驱动程序上

2)能够在安装设备驱动程序上找到应用程序的相应图标(桌面图标)

3)是否包含数字签名信息(银行卡充值、提现)

4)JAD文件显示的资料内容与应用程序显示的资料内容应一致

5)安装路径应能指定

6)没有用户的允许, 应用程序不能预先设定自动启动

7)卸载是否安全, 其安装进去的文件是否全部卸载

8)卸载用户使用过程中产生的文件是否有提示

9)其修改的配置信息是否复原

10)

11)

1)

2)

3)

4)

5)

6)

7)在数据删除之前,应用程序应当通知用户或者应用程序提供一个“取消”命令的操作

8)“取消”&“后退”命令操作能够按照设计要求实现其功能

9)应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况

10)能合理地处理出现的错误(不能闪退)

11)意外情况下提示用户

3.1.4通讯安全性

1)在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序,优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能

2)当创立连接时, 应用程序能够处理因为网络连接中断, 进而告诉用户连接中断的情况

3)声音的设置不影响应用程序的功能

4)应用程序必需利用目标设备适用的全屏尺寸来显示上述内容

5)应用程序必需能够处理不可预知的用户操作, 例如错误的操作和同时按下多个键(快速多次重复查看大图和返回,容易引起崩溃)

3.2安装、卸载测试

验证 App是否能正确安装、运行、卸载

3.2.1安装

1)软件在不同操作系统(常见Android、iOS)下安装是否正常。

2)软件安装后的是否能够正常运行,安装后的文件夹及文件是否写到了指定的目录里。

3)

4)

5)

6)

7)

8)

9)

10)

1)

2)直接删除安装文件夹卸载是否有提示信息

3)测试卸载后文件是否全部删除所有的安装文件夹。

4)卸载过程中出现的意外情况的测试(如死机、断电、重启)。

5)卸载是否支持取消功能,单击取消后软件卸载的情况。

6)系统直接卸载 UI测试,是否有卸载状态进度条提示

3.3 UI测试

测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是否完美、操作是否友好等。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

1)

2)

3)

4)

1)

2)

3)

4)

5)页面的图片应有其实际意义而要求整体有序美观

6)图片质量要高且图片尺寸在设计符合要求的情况下应尽量小

7)界面整体是用的颜色不宜过多

3.3.3内容测试

1)输入框说明文字的内容与系统功能是否一致(用户名,密码,验证码等)

2)文字长度是否加以限制

3)文字内容是否表意不明

4)是否有错别字

5)信息是否为中文显示(乱码处理)

6)是否有敏感性词汇、关键词

7)

3.4

1)的用户2)

3)

3.4.1运行

1)App安装完成后的试运行,可正常打开软件。

2)App打开测试,是否有加载状态进度提示。

3)App打开速度测试,速度是否可观。

4)App页面间的切换是否流畅,逻辑是否正确

5)注册

--同表单编辑页面

--用户名密码长度

--注册提示页面

--注册后的页面跳转

6)

--登陆后,页面中登陆信息。

--页面中有注销按钮。

--登陆超时的处理

7)投标

--能否正常投标

--能够正常支付

--能否正常使用优惠券

--能否正常赠送优惠券

--已投标状态显示是否正确

3.4.2应用的前后台切换

1)

2)

3)

4)

5)

6)(有可7)

1)app有免登录功能时,需要考虑系统版本(iOS、Android)差异。

2)考虑无网络情况时能否正常进入免登录状态。

3)切换用户登录后,要校验用户登录信息及数据内容是否相应更新,确保原用户退出。

4)需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出,给出友好提示。

5)密码更换后,检查有数据交换时是否进行了有效身份的校验

6)支持自动登录的应用在进行数据交换时,检查系统是否能自动登录成功并且数据操作

无误。

7)检查用户主动退出登录后,下次启动app,应停留在登录界面

3.4.4数据更新

1)+自

2)

3)

4)

1)

2)

3)

4)

5)

3.4.6 App更新

1)当客户端有新版本时,有更新提示。

2)当版本为非强制升级版时,用户可以取消更新,老版本能正常使用。用户在下次启动

app时,仍能出现更新提示。

3)当版本为强制升级版时,当给出强制更新后用户没有做更新时,退出客户端。下次启

动app时,仍出现强制升级提示。

4)当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新

至新版本,并检查更新后的客户端功能是否是新版本。

5)当客户端有新版本时,在本地不删除客户端的情况下,检查资源同名文件是否能正常

更新成最新版本。(如首页图片,广告位等)

3.4.7定位、照相机服务

1)

2)

3)

4)

1)

2)

3)手机处于睡眠模式时,检查用户是否会接收到push,并唤醒。

4)当push消息是针对登录用户的时候,需要检查收到的push与用户身份是否相符. 3.5性能测试

1)极限测试:在各种边界压力情况下,如电池、存储、网速等,验证App是否能正确响

应。

--内存满时安装App

--运行App时手机断电

--运行App时断掉网络

2)响应能力测试:测试App中的各类操作是否满足用户响应时间要求。

3)

3.6

1)

2)

3)

4)

5)App运行时切换网络(2G、3G、4G、wifi)

6)App运行时浏览网络

7)App运行时使用相机、计算器等手机自带设备

8)App 调用第三方充值、提现

3.7兼容测试

1)与本地及主流App是否兼容

2)基于开发环境和生产环境的不同,检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、

WCDMA、CDMA1x、CDMA2000、HSPDA等),App的数据和运用是否正确

3)与各种设备是否兼容,安卓和IOS系统是否兼容

3.8

1)

2)

3.9

1)

2)测试与升级模块相关的模块的功能是否与需求一致

3)升级安装意外情况的测试(如死机、断电、重启)

4)升级界面的 UI测试

5)不同操作系统间的升级测试

以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性提升产品的潜在客户满意度。

1)是否有空数据界面设计,引导用户去执行操作。

2)是否滥用用户引导。

3)

4)

5)

6)

7)

8)

9)

10)

11)

12)是否有横屏模式的设计,应用一般需要支持横屏模式,即自适应设计

13)提示语是否友好

14)操作是否繁琐复杂

3.11.1手势操作测试

1)手机开锁屏对运行中的App的影响

2)运行中的App前后台切换的影响

3)多个运行中的App的切换

4)

1)

2)

3)

4)

5)

3.11.3服务器宕机或出现404、502等情况下的测试

当出现域名解析故障时,出现404、502等情况下,需要对异常进行正确的处理。

3.12接口测试

确保服务端提供的接口并转换的JSON内容正确,对分支、异常流有相应的返回值(需要提

手机APP测试流程规范

手机APP测试流程规范 、流程图 Fail 回归测试接收版本不符 App 测试版本送测规范符合 UI 测试: 核对 rp/ 效果图功能测试:核对需求文档兼容性测试、性能压力测试尽快申请到正式 环境下测试进入正式环境后台订单统计测试仍然为测试环境 Pass 用户行为统计 测试 发送上线 报告 测试周期 测试周期一般为两周( 10 个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1. 测试资源 测试任务开始前,检查各项测试资源。 1. 产品功能需求文档 2. 产品原型图 3. 产品效果图 4. 行为统计分析定义文档

5. 测试设备( ios 3." 1.3-ios 5." 0.1;Android 1. "6-Android 4."0 ;Winphone 7."1 及以上;Symbian v3/v5/Nokia Belle 等) 6. 其他(例如有秒杀专题的项目,需要规划秒杀时间表;有优惠券使用的项目,需要申请添加优惠券数据;支付宝/ 银联支付功能的项目,需要提前申请支付宝/银联账户等等) 2. 测试要点 1. 接收版本 A)接收测试版本的同时,需要查看程序填写的《App测试版本提交质量规范》,若符合则开始测试任务,若不符合规范,可拒绝测试。 B)日常接收版本时需要注意测试版本规范,如不符合,请开发人员重新修改合适的版本号后再次提交测试。 2. UI测试 A)确保手头的原型图与效果图为当前最新版本。 B)确保产品UI符合产品经理制定的原型图与效果图。 C)一切界面问题以效果图为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出

移动APP测试方案及流程

移动APP测试方案及流程 作者: 心来心去来源: 51Testing软件测试网采编 针对app的测试过程和重点关注内容,做以下梳理和总结。 1、首先是测试资源确认及准备 (1)产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全; (2)测试设备及工具的准备:IOS和andriod不同版本的真机,以及相关测试工具的准备。 2、测试用例的设计与评审 (1)根据产品需求文档、产品原型图等文档,设计客户端的一般功能测试用例; (2)测试用例评审、修改与完善,评审通过后着手进入正式测试阶段。 3、UI测试 (1)确保手头的原型图与效果图为当前最新版本,符合产品经理及用户要求; (2)测试过程中一切以效果图为准,若有用户体验方面的建议,可以先以邮件的形式与产品经理确认,确认通过后,可以正式向开发提出用户体验方面的问题; (3)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型。 4、功能测试 (1)功能测试时主要依据编写的功能测试用例进行软件功能的遍历; (2)涉及的测试主要包括基本功能测试,安装、卸载、运行测试,异常处理(包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理)测试。 5、中断测试 (1)软件运行过程中接电话、收短信、锁屏、闹铃、充电,收到通知提醒后再使用软件,软件应仍可正常运行使用; (2)软件运行时,由前台切换到后台,再切回前台后,应仍可正常运行使用。 6、兼容性及适配测试 (1)硬件的适配:不同手机厂商、硬件性能,不同屏幕大小的适配; (2)OS版本的兼容:IOS6-9;Andriod3以上等,如果用了一些新的API在老的系统上不支持会导致crash; (3)不同分辨率屏幕的适配:移动设备的分辨率多种多样,如果app没有做比较合适的处理就可能会显示不好,甚至影响功能的操作。

App功能测试的7大注意点

01 运行 1)App安装完成后的试运行,可正常打开软件。 2)App打开测试,是否有加载状态进度提示。 3)App页面间的切换是否流畅,逻辑是否正确。 4)注册 同表单编辑页面 用户名密码长度 注册后的提示页面 前台注册页面和后台的管理页面数据是否一致 注册后,在后台管理中页面提示 5)登录 使用合法的用户登录系统 系统是否允许多次非法的登录,是否有次数限制 使用已经登录的账号登录系统是否正确处理 用户名、口令(密码)错误或漏填时能否登陆 删除或修改后的用户,原用户名登陆 不输入用户口令和重复点“确定/取消”按钮,是否允许登录 登陆后,页面中登录信息 页面中有注销按钮 登录超时的处理 02 应用的前后台切换 1)App切换到后台,再回到App,检查是否停留在上一次操作界面。 2)App切换到后台,再回到App,检查功能及应用状态是否正常。 3)App切换到后台,再回到前台时,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。 4)手机锁屏解锁后进入App注意是否会崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。 5)当App使用过程中有电话进来中断后再切换到App,功能状态是否正常。6)当杀掉App进城后,再开启App,App能否正常启动。 7)出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷。 8)对于有数据交换的页面,每个页面都必须要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃。 03 免登陆 很多应用提供免登陆功能,当应用开启时自动以上一次登录的用户身份来使用App。 1)考虑无网络情况时能否正常进入免登录状态。 2)切换用户登陆后,要校验用户登录信息以及数据内容是否相应更新,确保原用户退出。

手机App测试策略和流程

手机App测试策略和流程目录

1.引言 本文档是长春吉大正元信息技术股份有限公司东北公司手机APP测试的工作指导原则,它为手机APP测试过程中涉及到的测试方法、测试类型等制定标准做出明确的诠释和说明。 测试部门相关人员以此文档作为测试工作的依据和行为准则。 编写目的 本规范规定了东北公司手机APP测试过程中的活动和步骤。为公司测试(活动、产品)的实施和过程情况的各项检查提供依据;为度量被测试产品质量提供验证指标和验证方法。 适用范围 适用于长春吉大正元信息技术股份有限公司东北分公司测试部。 适用于:手机APP项目和产品的系统测试 针对手机APP的验证测试(外包项目)不在此范围之内,如需确保重点项目的手机APP质量度量和评价,需领导特殊审核。 2.测试过程描述 验证测试先决条件 对当前项目测试优先级进行划分: 产品大于项目优先级; 自主项目大于外包项目优先级; 重大项目(领导特批)大于客户化项目; 提前申请优先级大于变更申请优先级。(例如:监狱项目提前申请预留或者安排 测试员提前介入) 对当前测试版本质量进行评级:对于不符合测试准入原则的版本予以驳回。 验证测试三天后对提交版本进行质量预评估和评级:对第一轮发现较严重的问题进行列 举,对版本的整体情况进行评估。(详见BUG清单)对于不能度量质量的项目予以驳回 自测试。(例如:监狱移动OA项目)。 外埠公司提交测试前。应附上测试报告(功能测试报告、兼容性测试报告、性能测试报 告以及app可用性能标准结果);?公司内部提交测试前,需附上缺陷记录和修改状态表。 上述有一项不能满足或不能按时提交予以测试驳回。 总结提交测试版本的内部测试情况(测试BUG列表)。对遗留问题必须列出并记录解决 方案。对性能和稳定性指标要予以详细描述。 测试周期 测试周期可按项目的开发周期来确定测试时间,一般客户化项目手机APP测试时间为三周(即15个工作日),根据项目情况以及版本质量标准可适当缩短或延长测试时间。正式测试前先向测试部经理确认项目排期。 需提供资源 测试任务开始前,检查各项测试资源是否提交,有两项没有提交予以测试驳回。 --产品功能需求文档; --产品原型图; --产品效果图; --用户使用手册; --测试设备确认表(例如:;;及以上;Symbian v3/v5/Nokia Belle等); 轮次报告及产品上线报告

手机APP测试报告

招标手机APP测试总结报告

目录 1.测试概述 (1) 1.1. 编写目的 (1) 1.2. 测试围 (1) 2. 测试计划执行情况 (1) 2.1. 测试类型 (1) 2.2. 测试环境与配置 (2) 2.3. 测试人员 (2) 2.4. 测试问题总结 (3) 3. 测试总结 (3) 3.1.测试用例执行结果 (3) 3.2. 安全测试 (4) 3.2.1. 软件权限 (5) 3.2.2. 安装与卸载安全性 (5) 3.2.2. 数据安全性 (6) 3.2.3. 通讯安全性 (7) 3.2.4. 人机接口安全性 (7) 3.3. 安装、卸载测试 (8) 3.3.1. 安装 (8) 3.3.2. 卸载 (8) 3.4. UI测试 (9) 3.4.1. 导航测试 (9) 3.4.2. 图形测试 (9) 3.4.3. 容测试 (9) 3.5. 功能测试 (10) 3.5.1. 运行 (10) 3.5.2. 注册 (10) 3.5.3. 登录 (10) 3.5.4. 注销 (11) 3.5.5. 应用的前后台切换 (11) 3.5.6. 免登入 (11) 3.5.7. 数据更新 (12) 3.5.8. 离线浏览 (12) 3.5.9. APP更新 (12) 3.5.10. 时间测试 (13) 3.5.11. 性能测试 (13) 3.5.12. 交叉性事件测试 (13) 3.6. 兼容测试 (14) 3.7. 用户体验测试 (14) 4. 测试结果 (15)

1.测试概述 1.1.编写目的 本测试报告为招标手机APP的测试报告,目的在于总结测试阶段的测试情况以及分析测试结果,描述系统是否符合用户需求,是否已达到用户预期的功能目标,并对测试质量进行分析。 测试报告参考文档提供给用户、测试人员、开发人员、项目管理者、其他管理人员和需要阅读本报告的高层经理阅读。 1.2.测试围 测试主要根据用户需求说明书和软件需求规格说明书以及相应的文档进行系统测试,包括功能测试、性能测试、安全性和访问控制测试、用户界面测试以及兼容性测试等,而单元测试和集成测试由开发人员来执行。 主要功能包括:用户登录、我的项目、推荐项目订阅、行业资讯、我的收藏、意见反馈、我的CA锁。 2.测试计划执行情况 2.1.测试类型

手机app测试用例

手机app 测试用例 目录 目录 (1) 1. 用户登录 (3) 1.1用户登录流程 (3) 1.1.1游客登录 (3) 1.1.2微信登录 (3) 1.1.3正常账号登录 (4) 1.2接口要素检验 (4) 2. 用户注册 (5) 2.1用户注册流程 (5) 2.1.1正常注册 (5) 2.2接口要素检验 (5) 3. 个人中心 (6) 3.1正常用户个人中心 (6) 3.1.1推广收益 (6) 3.1.2昵称修改 (7) 3.1.3修改头像 (7) 3.2游客与微信用户个人中心 (7) 3.2.1推广收益 (7) 3.2.2一键转正 (8) 3.2.3昵称修改 (8) 3.2.4修改头像 (8) 3.3接口要素检验 (8) 4. 安全中心 (10) 4.1正常用户安全中心 (10) 4.1.1修改密码 (10) 4.1.2密保问题 (10) 4.1.3绑定手机 (11) 4.1.4实名认证 (11) 4.2游客与微信用户安全中心 (11) 4.2.1绑定手机 (11) 4.2.2实名认证 (12) 4.3接口要素检验 (12) 5. 设置 (13) 5.1功能设置 (13)

5.1.1背景音乐 (13) 5.1.2音效音乐 (14) 5.1.3音量控制 (14) 5.1.4退出app (14) 5.1.5账号切换 (14) 5.2app规则 (15) 5.3意见反馈 (15) 5.3.1发送反馈意见 (15) 5.4客服服务 (15) 5.5关于手机 (16) 5.5.1检查更新 (16) 5.5.2服务协议与隐私说明 (16) 6. 常用功能栏 (16) 6.1银行 (17) 6.1.1开通银行 (17) 6.1.2登录银行 (17) 6.1.3存款 (17) 6.1.4取款 (17) 6.2背包 (18) 6.3好友 (18) 6.3.1我的好友 (18) 6.3.2临时好友 (19) 6.3.3查找好友 (20) 6.4活动 (20) 6.4.1系统信息 (20) 6.4.2活动中心 (20) 6.5充值 (21) 6.5.1微信支付 (21) 6.5.2支付宝支付 (21) 6.5.3银联支付 (21) 6.6商城 (22) 6.6.1道具商城 (22) 6.6.2礼品商城 (22) 6.6.3兑换记录 (23) 6.7福利 (23) 6.7.1会员特权 (23) 6.7.2破产补助 (23) 6.7.3每日签到 (23) 6.7.4首冲奖励 (24) 6.7.5每日抽奖 (24) 6.8更多 (24) 6.8.1兑换码 (24) 6.8.2分享 (24) 6.9接口要素检验 (25)

App测试基本流程

APP测试基本流程 一、流程图 仍然为测试环境

二、测试周期 测试周期一般为两周(10个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 三、测试资源 测试任务开始前,检查各项测试资源。 1.产品功能需求文档 2.产品原型图 3.产品效果图 4.行为统计分析定义文档 5.测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上; Symbian v3/v5/Nokia Belle等) 6.其他(例如有秒杀专题的项目,需要规划秒杀时间表;有优惠券使用的 项目,需要申请添加优惠券数据;支付宝/银联支付功能的项目,需要提 前申请支付宝/银联账户等等) 四、测试要点 1.接收版本 A)接收测试版本的同时,需要查看程序填写的《App测试版本提交质量规范》,若符合则开始测试任务,若不符合规范,可拒绝测试。 B)日常接收版本时需要注意测试版本规范,如不符合,请开发人员重新修改合适的版本号后再次提交测试。 2.UI测试 A)确保手头的原型图与效果图为当前最新版本。 B)确保产品UI符合产品经理制定的原型图与效果图。 C)一切界面问题以效果图为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型 3.功能测试 A)确保手头的功能需求文档为当前最新版本。 B)确保所有的软件功能都已实现且逻辑正常。 C)一切功能问题以需求文档为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现,必须得到产品经理的确认,而不是单单只听开发人员的技术解释。 E)PMS上所有的“外部原因”问题,都需要尽早地督促开发人员与客户服务端人员联系协调解决。 F)P MS上所有的“设计如此”、“延期处理”问题,都需要和产品经理确认后再进行验证。

测试手机APP流程规范标准

关于手机APP 测试流程规范 1、流程图 仍然为测试环境

测试周期 测试周期一般为两周(10个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.1测试资源 测试任务开始前,检查各项测试资源。 1.产品功能需求文档 2.产品原型图 3.产品效果图 4.行为统计分析定义文档 5.测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上; Symbian v3/v5/Nokia Belle等) 6.其他(例如有秒杀专题的项目,需要规划秒杀时间表;有优惠券使用的 项目,需要申请添加优惠券数据;支付宝/银联支付功能的项目,需要提前申请支付宝/银联账户等等) 1.2测试要点 1.接收版本 A)接收测试版本的同时,需要查看程序填写的《App测试版本提交质量规范》,若符合则开始测试任务,若不符合规范,可拒绝测试。 B)日常接收版本时需要注意测试版本规范,如不符合,请开发人员重新修改合适的版本号后再次提交测试。 2.UI测试 A)确保手头的原型图与效果图为当前最新版本。 B)确保产品UI符合产品经理制定的原型图与效果图。 C)一切界面问题以效果图为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型 3.功能测试 A)确保手头的功能需求文档为当前最新版本。 B)确保所有的软件功能都已实现且逻辑正常。 C)一切功能问题以需求文档为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现,必须得到产品经理的确认,而不是单单只听开发人员的技术解 释。 E)P MS上所有的“外部原因”问题,都需要尽早地督促开发人员与客

APP测试理论,方法,流程

1.APP测试基本流程 1.1流程图 仍然为测试环境

1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.3测试资源 测试任务开始前,检查各项测试资源。 --产品功能需求文档; --产品原型图; --产品效果图; --行为统计分析定义文档; --测试设备; --其他。 2. 黑盒测试 黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。 黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。很明显,如果外部特性本身设计有问题或规格说明的规定有误,用黑盒测试方法是发现不了的 2.1目的 黑盒测试法注重于测试软件的功能需求,主要试图发现下列几类错误。 功能不正确或遗漏; 界面错误; 输入和输出错误; 数据库访问错误; 性能错误; 初始化和终止错误等。 2.2测试方法

等价类划分的办法是把程序的输入域划分成若干部分(子集),然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的,常用的黑盒测试用例设计方法。 划分等价类 1) 划分等价类:等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类。 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。 无效等价类:与有效等价类的定义恰巧相反。 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。 划分等价类 2)划分等价类的方法:下面给出六条确定等价类的原则。 ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。 ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类. ③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。 ④在规定了输入数据的一组值(假定n个),并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。 ⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。 ⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。 3)设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

APP测试注意点

一,输入键盘 1,键盘的弹出,收起是否流畅。 2,键盘弹起有没有遮挡住输入框、按钮或者其他应该显示的界面。 3,键盘的回车,下一步,操作响应是否可以跳转到下一个输入框。 如:页面上有多个输入框,在第一个输入框,点击键盘下一步。手机光标到下一个输入框中。4,切换页面,键盘是否会自动收起 如:在页面中输入键盘弹起,直接点击返回键。在另一个页面,键盘应该收起 5,数字键盘 如:只能输入数字页面,弹起数字键盘,体验会更好。 二,特殊字符显示 XML支持的特殊字符转实体 (>、<、&、'、")这些字符会被解析成对应的(>、≪、&、&apes;、") 测试时在需要关注这些特殊字符在显示的时候是不是正常显示。 三,账号相关 1,登录A账号,设置相关信息,保存。在另一台手机上登录A账号查看信息,是否是最新的。 如:用户更换了头像,在另一台手机登录看头像是否更新 2,一台手机登录A账号,另一台手机也登录A账号(有的程序可以多台终端同时登录)如:一台手机进行删除操作,另一台手机再操作删除。查看异常处理是否合理 3,不同多台终端同时登录,登录一个终端的时候,另一个终端的账号是否会退出。 包括不同终端,像安卓,IOS,IPAD,PC等。 四,手机操作 1,手机锁屏,前后台切换 1) app切换到后台,再回到app时,检查是否停留在上一次操作界面,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。 2) 当杀掉app进程后,再开启app,app能否正常启动。 3) 出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在。 4) 对于有数据交换的页面,每个页面都必需要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃。 2,频繁进行同一操作 如:一直进行刷新操作; 3,频繁进行不同操作切换 如:在多个不同tab间来回切换;一直操作点击,返回。 4,单击,双击,快速多次点击,长按,左右滑动 对于只能单击的按钮,试试双击,快速多次点击,长按是否会有异常 对于长按的区域,双击,单击滑动等操作,查看是否会有异常 不要仅限于按钮设定的功能操作。 5,强制关闭进程(杀进程) 杀掉进程,再重新启动程序,是否可以正常启动,界面功能操作是否正常。

App测试流程及测试点(个人整理版)

1 APP测试基本流程 1.1流程图 仍然为测试环境 15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。

1.3测试资源 测试任务开始前,检查各项测试资源。 --产品功能需求文档; --产品原型图; --产品效果图; --行为统计分析定义文档; --测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上;Symbian v3/v5/Nokia Belle等); --其他。 1.4日报及产品上线报告 1)测试人员每天需对所测项目发送测试日报。 2)测试日报所包含的内容为: --对当前测试版本质量进行分级; --对较严重的问题进行例举,提示开发人员优先修改; --对版本的整体情况进行评估。 3)产品上线前,测试人员发送产品上线报告。 4)上线报告所包含的内容为: ---对当前版本质量进行分级; ---附上测试报告(功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果); --总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。 2 App测试点 2.1安全测试 2.1.1软件权限 1)扣费风险:包括发送短信、拨打电话、连接网络等 2)隐私泄露风险:包括访问手机信息、访问联系人信息等 3)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测 4)限制/允许使用手机功能接入互联网 5)限制/允许使用手机发送接受信息功能 6)限制/允许应用程序来注册自动启动应用程序 7)限制或使用本地连接

8)限制/允许使用手机拍照或录音 9)限制/允许使用手机读取用户数据 10) 限制/允许使用手机写人用户数据 11) 检测App的用户授权级别、数据泄漏、非法授权访问等 2.1.2安装与卸载安全性 1)应用程序应能正确安装到设备驱动程序上 2)能够在安装设备驱动程序上找到应用程序的相应图标 3)是否包含数字签名信息 4)JAD文件和JAR包中包含的所有托管属性及其值必需是正确的 5)JAD文件显示的资料内容与应用程序显示的资料内容应一致 6)安装路径应能指定 7)没有用户的允许, 应用程序不能预先设定自动启动 8)卸载是否安全, 其安装进去的文件是否全部卸载 9)卸载用户使用过程中产生的文件是否有提示 10)其修改的配置信息是否复原 11)卸载是否影响其他软件的功能 12)卸载应该移除所有的文件 2.1.3数据安全性 1)当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码 2)输人的密码将不以明文形式进行显示 3)密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上 4)不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之间 5)当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据写到其它单独的文件或者临时文件中。以6)防止应用程序异常终止而又没有侧除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。 7)当将敏感数据输人到应用程序时, 其不会被储存在设备中 8)备份应该加密, 恢复数据应考虑恢复过程的异常通讯中断等, 数据恢复后再使用前应该经过校验 9)应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告 10)应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告, 更不能在安全警告显示前,,利用显示误导信息欺骗用户,应用程序不应该模拟进行安全警告误导用户11)在数据删除之前,应用程序应当通知用户或者应用程序提供一个“取消”命令的操作12)“取消”命令操作能够按照设计要求实现其功能 13)应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况 14)当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误的提示信息15)在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任何内容Μ

手机APP测试流程规范模板

手机APP测试流程规范 一、流程图 仍然为测试环境

测试周期 测试周期一般为两周(10个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.测试资源 测试任务开始前,检查各项测试资源。 1.产品功能需求文档 2.产品原型图 3.产品效果图 4.行为统计分析定义文档 5.测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上; Symbian v3/v5/Nokia Belle等) 6.其他(例如有秒杀专题的项目,需要规划秒杀时间表;有优惠券使用的 项目,需要申请添加优惠券数据;支付宝/银联支付功能的项目,需要提前申请支付宝/银联账户等等) 2.测试要点 1.接收版本 A)接收测试版本的同时,需要查看程序填写的《App测试版本提交质量规范》,若符合则开始测试任务,若不符合规范,可拒绝测试。 B)日常接收版本时需要注意测试版本规范,如不符合,请开发人员重新修改合适的版本号后再次提交测试。 2.UI测试 A)确保手头的原型图与效果图为当前最新版本。 B)确保产品UI符合产品经理制定的原型图与效果图。 C)一切界面问题以效果图为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型 3.功能测试 A)确保手头的功能需求文档为当前最新版本。 B)确保所有的软件功能都已实现且逻辑正常。 C)一切功能问题以需求文档为准,若有用户体验方面的建议,必须先以邮件或口头的形式询问产品经理。 D)若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现,必须得到产品经理的确认,而不是单单只听开发人员的技术解 释。 E)P MS上所有的“外部原因”问题,都需要尽早地督促开发人员与客户服务端人员联系协调解决。 F)P MS上所有的“设计如此”、“延期处理”问题,都需要和产品经理

移动互联网App测试流程及测试点(个人整理版)

1APP 测试基本流程 1.1流程图不符 符合 仍然为测试环境 进入正式环境 Fail Pass 接收版本 App 测试版本 送测规范 UI 测试:核对 rp/效果图 功能测试:核 对需求文档 兼容性测试、 性能压力测试 尽快申请到正 式环境下测试 后台订单统计测试用户行为统计 测试发送上线 报告 回 归 测 试

1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目排期。 1.3测试资源 测试任务开始前,检查各项测试资源。 --产品功能需求文档; --产品原型图; --产品效果图; --行为统计分析定义文档; --测试设备(ios3.1.3-ios5.0.1;Android1.6-Android4.0;Winphone7.1及以上;Symbian v3/v5/Nokia Belle等); --其他。 1.4日报及产品上线报告 1)测试人员每天需对所测项目发送测试日报。 2)测试日报所包含的内容为: --对当前测试版本质量进行分级; --对较严重的问题进行例举,提示开发人员优先修改; --对版本的整体情况进行评估。 3)产品上线前,测试人员发送产品上线报告。 4)上线报告所包含的内容为: ---对当前版本质量进行分级; ---附上测试报告(功能测试报告、兼容性测试报告、性能测试报告以及app可用性能标准结果); --总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案。 2App测试点 2.1安全测试 2.1.1软件权限 1)扣费风险:包括发送短信、拨打电话、连接网络等

手机APP产品测试用例实例与模版

中国电信XXX项目 功能测试用例 撰稿人:XX XXX信息网络有限责任公司 2013年X月XX日

目录 1.概述 ---------------------------------------------------------------------------------------------------- 错误!未定义书签。 编写目的--------------------------------------------------------------------------------------------- 错误!未定义书签。 读者对象--------------------------------------------------------------------------------------------- 错误!未定义书签。 参考资料--------------------------------------------------------------------------------------------- 错误!未定义书签。测试用例 ------------------------------------------------------------------------------------------------ 错误!未定义书签。 登陆/注册 ------------------------------------------------------------------------------------------- 错误!未定义书签。 文件上传--------------------------------------------------------------------------------------------- 错误!未定义书签。 文件收藏--------------------------------------------------------------------------------------------- 错误!未定义书签。 文件删除/还原------------------------------------------------------------------------------------- 错误!未定义书签。 文件重命名 ----------------------------------------------------------------------------------------- 错误!未定义书签。 文件移动--------------------------------------------------------------------------------------------- 错误!未定义书签。 文件分享--------------------------------------------------------------------------------------------- 错误!未定义书签。 图片浏览--------------------------------------------------------------------------------------------- 错误!未定义书签。 相册备份--------------------------------------------------------------------------------------------- 错误!未定义书签。 私密空间--------------------------------------------------------------------------------------------- 错误!未定义书签。 设置 --------------------------------------------------------------------------------------------------- 错误!未定义书签。 客户端安装/升级 --------------------------------------------------------------------------------- 错误!未定义书签。

App常用测试方法总结

APP常用测试方法总结 一、安全测试 1.软件权限 1)扣费风险:包括短信、拨打电话、连接网络等。 2)隐私泄露风险:包括访问手机信息、访问联系人信息等。 3)对App的输入有效性校验、认证、授权、数据加密等方面进行检测 4)限制/允许使用手机功能接入互联网 5)限制/允许使用手机发送接收信息功能 6)限制或使用本地连接 7)限制/允许使用手机拍照或录音 8)限制/允许使用手机读取用户数据 9)限制/允许使用手机写入用户数据 10)限制/允许应用程序来注册自动启动应用程序 2.安装与卸载安全性 1)应用程序应能正确安装到设备驱动程序上 2)能够在安装设备驱动程序上找到应用程序的相应图标 3)安装路径应能指定 4)没有用户的允许,应用程序不能预先设定自动启动 5)卸载是否安全,其安装进去的文件是否全部卸载 6)卸载用户使用过程中产生的文件是否有提示 7)其修改的配置信息是否复原 8)卸载是否影响其他软件的功能 9)卸载应该移除所有的文件 3.数据安全性 1)当将密码或其它的敏感数据输入到应用程序时,其不会被存储在设备中,同时密码也不会被解码。 2)输入的密码将不以明文形式进行显示。 3)密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。4)不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。5)当应用程序处理信用卡明细或其它的敏感数据时,不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件,文件可能遭受入侵者的袭击,然后读取这些数据信息。 6)党建敏感数据输入到应用程序时,其不会被存储在设备中。 7)应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告

app测试详细流程

App测试流程及测试点 1 APP测试基本流程 1.1预估测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两周(即10个工作日,一人份工作量),根据项目情况以及版本质量可适当缩短或延长测试时间。正式测试前先向主管确认项目整体排期。 与其他项目强耦合适量增加3-5个工作日,弱耦合增加1-2工作日 1.2测试资源 测试任务开始之前,准备测试资源 1.产品文档 2.原型图 3.效果图即设计交互稿 4.行为统计分析定义文档 5.测试设备(测试机,平板,系统iOS、Android,不同分辨率) 6.测试人员 7.其他 1.3分析测试内容 ?这里就说的通俗一点 ?比如A要去吃饭,那么他怎么吃饭,用什么吃饭,吃什么饭,吃多少合适。 ?怎么吃:项目业务流 ?用什么吃:项目前期准备测试事宜 ?吃什么饭:明确测试目的,项目背景 ?吃多少合适:合格点,吃完饭了是不是得确认他是不是吃饱了? 1.4设计测试计划、测试用例

古人云:凡事预则立,不预则废。也就是强调预先计划的重要性和必要性 ?测试计划 ?测试范围明确测什么?比如:产品的具体业务需求有哪些?产品是web端的还是移动端的,还是两者都有? ?测试策略明确怎么测。对不同业务需求,具体要有哪些测试类型、测试场景、测试方法。 ?资源安排包括测试人员的安排,测试环境是怎样的,测试工具的选择等。 ?进度安排在明确测试范围、方法和人员之后,我们要考虑什么时候开始测试,预计要测试多久?以便和开发计划、上线计划衔接。 ?发布标准发布标准是测试完成和产品上线需要满足的条件,以便项目内所有角色都有一致认可的目标。怎样才算是测完了?达到怎样的标准才可以上线? ?风险预防最后,我们需要对整个测试过程中可能存在的风险,以及当这些风险发生时的应对措施提前进行一些考虑和准备,并在测试计划中体现出来。 ?测试用例就不多说了,测试工程师的基本功 1.5用例评审 一千个眼里就有一千个哈姆雷特,所以用例评审很重要,这是一个查漏补缺的过程,不光用例层面的补充,也在某种程度上对其他同事也是一种回顾&梳理其他同事的堵塞点 1.3测试报告 1.测试人员对每天测试项目发送测试报告(若无要求,则不需要发送日报) 2.日报所含内容: ?对当前测试版本质量进行分级 ?严重阻塞进度的问题提出,提示开发同学优先修改

移动APP测试解决方案及流程.docx

移动APP测试方案及流程 针对app的测试过程和重点关注内容,做以下梳理和总结。 1、首先是测试资源确认及准备 (1)产品需求文档、产品原型图、接口说明文档以及设计说明文档等应齐全; (2)测试设备及工具的准备:IOS和andriod不同版本的真机,以及相关测试工具的准备。 2、测试用例的设计与评审 (1)根据产品需求文档、产品原型图等文档,设计客户端的一般功能测试用例; (2)测试用例评审、修改与完善,评审通过后着手进入正式测试阶段。 3、UI测试 (1)确保手头的原型图与效果图为当前最新版本,符合产品经理及用户要求; (2)测试过程中一切以效果图为准,若有用户体验方面的建议,可以先以邮件的形式与产品经理确认,确认通过后,可以正式向开发提出用户体验方面的问题; (3)由于测试环境中的数据为模拟数据,测试时必须预先考虑到正式环境中可能出现的数据类型。 4、功能测试 (1)功能测试时主要依据编写的功能测试用例进行软件功能的遍历; (2)涉及的测试主要包括基本功能测试,安装、卸载、运行测试,异常处理(包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理)测试。 5、中断测试 (1)软件运行过程中接电话、收短信、锁屏、闹铃、充电,收到通知提醒后再使用软件,软件应仍可正常运行使用; (2)软件运行时,由前台切换到后台,再切回前台后,应仍可正常运行使用。 6、兼容性及适配测试 (1)硬件的适配:不同手机厂商、硬件性能,不同屏幕大小的适配; (2)OS版本的兼容:IOS6-9;Andriod3以上等,如果用了一些新的API在老的系统上不支持会导致crash; (3)不同分辨率屏幕的适配:移动设备的分辨率多种多样,如果app没有做比较合适的处理就可能会显示不好,甚至影响功能的操作。

手机应用软件测试经验总结

手机应用软件测试经验总结 随着科技的进步,手机款型可谓日新月异,功能也越来越丰富。相应的,越来越多的手机应用软件也伴随着手机功能的多样化应运而生。面对种类众多的手机应用软件,该如何进行测试,测试时又需要重点关注什么呢?本文档结合本人在产品手机项目测试过程中的经验,浅谈下手机应用软件测试相关知识。 对于产品的手机项目(应用软件),主要是进行系统测试。而针对手机应用软件的系统测试,我们通常从如下几个角度开展:功能模块测试,交叉事件测试,压力测试,容量测试,兼容性测试,易用性/用户体验测试等。 1、功能模块测试:首先应分析功能模块的功能项,测试每个功能项是否能够实现对应的功能。一般根据测试用例(Test Case)或软件本身的流程就可以完成基本功能测试(相对简单,故障也较容易发现、解决)。 2、交叉事件测试:又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或闹铃触发,应用软件运行过程中插拔充电器等。执行干扰的冲突事件不能导致应用软件异常、手机死机或花屏等严重问题。另外,还需要注意各交叉事件的优先级别,检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级较低的事件吊死。 交叉事件测试非常重要,一般能发现应用软件中一些潜在的问题。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题(这个主要针对手机应用软件支持语言自适应功能),这一点通常会被测试人员忽略。 4、压力测试:又叫边界值容错测试或极限负载测试。即测试过程中,已经达到某一软件功能的最大容量、边界值或最大的承载极限,仍然对其进行相关操作。例如连续进行短信的接收和发送,超过收件箱和SIM卡所能存储的最大条数,仍然进行短消息的接收或发送,以此来检测软件在超常态条件下的表现,进而评估用户能否接受。

手机app测试经验总结

手机上a p p测试总结 / / 上的app分为基于HTML5的app(类似于pc上的b/S应用)和本地app(类似于 C/S结构)。 所以上我们也可以充分吸收的b/s和c/s测试经验。但是不同于pc上的应用测试,手机上的测试有其独特性 测试前的思考:我们这个产品主要是做什么的为什么我要做这个产品市场上有那 些同类型的产品 测试前的准备:1.使用同类型的产品,不仅仅是使用,应该是测试同类型的产品。2.熟悉我们产品的spec文档,积极和pm交流。3,写,没有时间至少要有一个checklist。 1.功能 a.基本功能,主要指app是否完成了设计的所有功能。分清模块,写一份checklist,避免漏测。考虑横竖屏切换,不过很多app现在只支持竖屏。 b.系统交互:电话短信干扰,低电量提醒,push提醒,usb数据线插拔提醒,充电提醒等, 2.性能:稳定性,兼用型(android碎片化是个难题,bug也多,ios相对bug少),app运行的内存消耗和cpu消耗,app后台长时间运行的耗流量,耗电量。 推荐testin这个第三方平台,对android兼用性测试比较有帮助。 3.易用性:面是否吸引人、容易理解。界面整洁、简单。无错别字。点击范围确 定等。这部分测试中,如果测试认为有不合理的地方通常会提交需求bug。 4.外场:网络切换,网络信号强,弱下的app运行情况。

对自动化的一些看法: 目前我们可以接触到手机方面的自动化工具:robotium,monkey,monkeyrunner,androidjunit。但是由于ui变化快,往往不方便维护。前三个不需要源码支持,但是功能有限,androidjunit很强大,对代码能力要求高,同时需要源码支持。app的开发周期一般都很短,ui变化大,用自动化要考虑投入成本,大多数的公司估计都不适用。不过测接口之类的通过自动化是个不错的选择。 转,说得多有道理的。 1.移动开发节奏很快,版本快速迭代,如何让测试起来? Monkey:我建议放弃完全得 Case。全部用feature list或者测试思维导图或者功能点划分表来进行引导得测试。主要目的不会漏掉功能点以及防止regression 得bug。其次要敏捷必须要有自动化得支持。关于这点就是根据不同得app进行定义了。首先UT无论如何就要做起来。其次是api和regression test得自动化要做起来。当然CI也一定要搭建的。 2.移动应用测试,如何更全面的保证产品质量如何让用户参与到测试中来?Monkey:更全面得保证产品质量。如果要说到全面,那么必须就是功能,压力,性能,安全,用户体验面面具到了。其实还是和我第一个问题说得一样。将app 结合os得特性分层进行逐个得测试或者自动化测试。关于让用户参与到测试中来的话。我建议可以将不同的用户集合起来,qq或者weixin保持联系。然后android 可以定期发布内测版本,ios可以发布testflight版本。 3.用户反馈问题建议非常多,如何做好有效管理、分析和反馈?

相关文档
最新文档