1、安装卸载
用例编号 | 测试内容 | 操作步骤 | 预期结果 | 测试次数 | 测试结果 | 备注 |
安装 | ||||||
1 | 通过第三方软件协助安装是否正常 | 第三方软件搜索app,安装 | 目标:支持360、豌豆荚、应用宝等主流辅助工具 | 1 | Pass | |
2 | 在不同操作系统下安装是否正常 | 1、使用测试手机安装 | 可以安装,并正常使用 | 1 | Failed | |
3 | 安装过程中断网,安装是否能完成 | 安装过程中断网 | 不会出现异常 | 1 | Failed | |
4 | 安装后的文件夹及文件是否写到了指定的目录里 | 安装,(使用手机助手)查看安装后文件 | 文件存放在制定目录 | 1 | NT | |
5 | 软件安装过程是否可以取消,点击取消后,写入的文件是否如概要设计说明处理 | 安装过程中取消 | 按照说明书处理,例如文件可以取消,已安装文件被删除 | 1 | NT | |
6 | 软件安装过程中断电 | 安装过程中断电 | 软件重新安装无异常 | 1 | Pass | |
7 | 软件安装过程中重启 | 安装过程中重启 | 软件重新安装无异常 | 1 | Pass | |
8 | 软件安装过程中死机 | 软件重新安装无异常 | 1 | |||
9 | 安装空间不足时是否有相应提示 | 在空间不足的手机上安装 | 给出正确提示 | 1 | ||
10 | 安装后没有生成多余的目录结构和文件 | 安装,(使用手机助手)查看安装后文件 | 结构目录正常 | 1 | ||
卸载 | ||||||
11 | 可以通过第三方软件协助卸载 | 1、使用测试手机卸载 | 可以卸载 | 1 | ||
12 | 卸载是否有提示信息,是否支持取消 | 到手机应用管理中心卸载,或其他卸载方式 | 卸载支持取消功能 | 1 | ||
13 | 测试卸载后文件是否全部删除所有的安装文件夹 | 卸载,(使用手机助手)查看安装后文件 | 工具 | 1 | ||
14 | 软件卸载过程中断电 | 卸载过程中断电 | 重新卸载无异常 | 1 | ||
15 | 软件卸载过程中重启 | 卸载过程中重启 | 重新卸载无异常 | 1 | ||
16 | 软件卸载过程中死机 | 重新卸载无异常 | 1 | |||
17 | 卸载后是否可以重装 | 卸载后重装 | 可以重装 | 1 |
2、功能用例
用例编号 | 测试内容 | 操作步骤 | 预期结果 | 测试次数 | 测试结果 | 备注 |
启动 | ||||||
1 | App打开时,是否有加载动画或加载状态进度提示 | 启动APP | 有加载动画或加载状态进度提示(以需求为准) | 1 | ||
2 | App打开速度是否可观 | 统计APP启动速度 | 启动时间在可接受范围内 | 1 | ||
前后台切换 | ||||||
3 | APP切换到后台,再回到APP,是否停留在上一次操作界面 | APP切换到后台,再回到APP | 停留在上一次操作界面 | 1 | ||
4 | APP切换到后台,再回到APP,功能及应用状态是否正常 | APP切换到后台,再回到APP | 功能及应用状态正常。 | 1 | ||
5 | 手机锁屏解屏后进入APP是否会崩溃,功能状态是否正常 | 锁屏,然后解锁后再次打开APP | 功能及应用状态正常。 | 1 | ||
6 | 当App使用过程中有电话进来中断后再切换到APP,功能状态是否正常 | 1 | ||||
7 | 当杀掉APP进程后,再开启APP,APP能否正常启动 | 1 | ||||
8 | 出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷 | 1 | ||||
9 | 对于有数据交换的页面,每个页面都必需要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃 | 1 | ||||
免登录:很多应用提供免登录功能,当应用开启时自动以上一次登录的用户身份来使用app. | ||||||
10 | 无网络情况时能否正常进入免登录状态。 | 断开网络,启动APP | 正常进入免登录状态 | 1 | ||
11 | 切换用户登录后,用户登录信息及数据内容是否更新 | 切换用户 | 原用户完全退出,信息更新 | 1 | ||
数据更新:根据应用的业务规则,以及数据更新量的情况,来确定最优的数据更新方案 | ||||||
12 | 需要确定哪些地方需要提供手动刷新,哪些地方需要自动刷新,哪些地方需要手动+自动刷新。 | 1 | ||||
13 | 确定哪些地方从后台切换回前台时需要进行数据更新。 | 1 | ||||
14 | 根据业务、速度及流量的合理分配,确定哪些内容需要实时更新,哪些需要定时更新 | 1 | ||||
15 | 确定数据展示部分的处理逻辑,是每次从服务端请求,还是有缓存到本地,这样才能有针对性的进行相应测试 | 1 | ||||
16 | 检查有数据交换的地方,均有相应的异常处理 | 1 | ||||
离线浏览:很多应用会支持离线浏览,即在本地客户端会缓存一部分数据供用户查看 | ||||||
17 | 在无网络情况可以浏览本地数据 | 1 | ||||
18 | 退出APP再开启APP时能正常浏览 | 1 | ||||
19 | 切换到后台再切回前台可以正常浏览 | 1 | ||||
20 | 锁屏后再解屏回到应用前台可以正常浏览 | 1 | ||||
21 | 在对服务端的数据有更新时会给予离线的相应提示 | 1 | ||||
定位、照相机服务:测试定位、照相机服务时,需要采用真机进行测试 | ||||||
22 | 有用到相机、定位服务时,需要注意系统版本差异 | 1 | ||||
23 | 有用到定位服务、照相机服务的地方,需要进行前后台的切换测试,检查应用是否正常 | 1 | ||||
24 | 当定位服务没有开启时,使用定位服务,会友好性弹出是否允许设置定位提示。当确定允许开启定位时,能自动跳转到定位设置中开启定位服务 | 1 | ||||
时间测试 | ||||||
25 | 检查文字的发布时间、评论时间是否合理 | 客户端自行设置手机的时区、时间 | 文字的发布时间、评论时间合理(由服务器转换) | 1 | ||
PUSH测试:测试push时,需要采用真机进行测试 | ||||||
26 | 检查push消息是否按照指定的业务规则发送 | 1 | ||||
27 | 检查不接受推送消息时,检查用户不会再接收到push | 在APP中设置不接收推送,检查是否还会受到推送消息 | 用户不会再接收到push | 1 | ||
28 | 免打扰测试 | 设置免打扰时间段,检查推送信息的时间 | 在免打扰时间段内,用户接收不到PUSH。 | 1 | ||
29 | 推送消息是否准确 | 对特定用户推送消息 | 检查特定是否是否准确接收,且非目标用户未接收消息 | 1 | ||
注册 | ||||||
30 | 注册时,用户名和密码长度是否有限制,格式是否有要求 | 注册页面,验证用户名和密码的格式和长度 | 用户名和密码皆有合理限制,并在输入错误时给出提示 | 1 | ||
31 | 注册已存在的用户时,处理是否合理 | 用已存在的用户名进行注册 | 焦点移开输入框或者提交时给出提示,无法保存 | 1 | ||
32 | 注册成功后是否给出提示或登录到提示页面 | 注册成功后,观察系统处理方式 | 给出提示或登录到提示页面 | 1 | ||
33 | 后台管理页面是否可以查询到注册用户数据,数据是否跟注册时一致 | 登录成功后,在管理后台查询用户信息 | 否可以查询到注册用户数据,且数据跟注册一致 | 1 | ||
登录 | ||||||
34 | 合法用户可以登录系统 | 用前台注册的用户或后台添加的用户进行登录 | 可以正常登录 | 1 | ||
35 | 系统是否允许多次非法的登录,是否有次数限制。 | 用正确的账号和错误的密码多次登录 | 每次登录都有剩余登录尝试次数,用完后账号锁定 | 1 | ||
36 | 使用禁用的账号登录系统是否正确处理 | 后台将某账号锁定,然后尝试登录 | 无法登录,且给出的提示信息清晰、安全 | 1 | ||
37 | 使用已经登录的账号登录系统是否正确处理 | 用同一账号在两台手机登录 | 第二次登录时给出提示,强行登录后,第一次登录的账号下线 | 1 | ||
38 | 使用后台已删除的用户登录 | 后台将某账号删除,然后尝试登录 | 无法登录,且给出的提示信息清晰、安全 | 1 | ||
39 | 使用错误的用户名或密码登录时,处理是否合理 | 用错误的账号或或密码登录 | 无法登录,且给出的提示信息清晰、安全 | 1 | ||
40 | 登录后,页面中的登录信息是否准确,登录后展示页面是否合理 | 用正确的账号登录,检查登录后信息和页面 | 登录信息准确,展示页面合理 | 1 | ||
41 | 登录超时的处理 | 登录过程中断开网络 | 给出提示 | 1 | ||
42 | 使用第三方账号登录 | 使用第三方账号登录 | 可以正常登录 | 1 | ||
43 | 在第三方账号上取消授权后无法自动登录 | 在第三方账号上取消授权 | 无法自动登录,需要重新授权 | 1 | ||
修改(忘记)密码 | ||||||
44 | 在登录页面有忘记密码的链接 | 1 | ||||
45 | 可以找回密码 | 1 | ||||
46 | 新旧密码都正确无误时可以修改密码 | 1 | ||||
47 | 修改密码页面,新密码不对时无法修改,且给出提示 | 1 | ||||
48 | 新不密码不符合规则时无法修改 | 1 | ||||
49 | 新密码和确认密码不符合时无法修改,且给出提示 | 1 | ||||
注销 | ||||||
50 | 可以注销,且注销后跳转的页面合理 | 1 | ||||
51 | 注销后,无法查看要求登录的数据 | 1 | ||||
计量单位 | ||||||
52 | 计量单位之间是否可以切换,若可以,切换是否方便 | 1 | ||||
53 | 单位切换后,报表模块是否能展示正确的数据和图表 | 1 |
3、用户体验测试
用例编号 | 测试内容 | 操作步骤 | 预期结果 | 测试次数 | 测试结果 | 备注 |
通用 | ||||||
1 | 空数据界面是否有用户操作的引导。 | 1 | ||||
2 | 是否滥用用户引导。 | 1 | ||||
3 | 是否有不可点击的效果 | 如:某按钮此时处于不可用状态,那么一定要灰掉,或者拿掉按钮,否则会给用户误导 | 1 | |||
4 | 交互流程分支是否太多 | 1 | ||||
5 | 相关的选项是否离得很远 | 1 | ||||
6 | 一次是否载入太多的数据 | 1 | ||||
7 | 界面中按钮可点击范围是否适中 | 1 | ||||
8 | 标签页是否跟内容有从属关系 | 当切换标签的时候,内容跟着切换 | 1 | |||
9 | 操作应该有主次从属关系 | 1 | ||||
10 | 是否有横屏模式的设计 | 应用一般需要支持横屏模式,即自适应设计 | 1 | |||
11 | 系统是否是否定义Back的逻辑,是否在不应该返回的时候返回了? | 涉及软硬件交互时,Back键应具体定义 | 1 | |||
12 | 用户不耐心而且多次敲按键会发生什么? | 1 | ||||
13 | 输入错误的数据会发生什么? | 1 | ||||
14 | 系统操作是否简单、易理解?是否有引导性? | 1 | ||||
15 | App页面间的切换是否流畅,逻辑是否正确 | 切换APP页面 | 检查是否流程,切换是否符合逻辑 | 1 | ||
导航相关 | ||||||
16 | 导航方式是否合理?(菜单不能太深,是否符合逻辑?) | 1 | ||||
17 | 是否有让用户产生担忧数据安全的设计和操作? | 1 | ||||
18 | 会要求打开相关服务吗(如GPS、Wi-Fi)?如果用户打开会怎样?没打开又会怎样? | 1 | ||||
19 | 将用户重新引向哪儿?去网页?还是从网页到App?这会导致问题出现吗? | 1 | ||||
出错提醒和消息 | ||||||
20 | 出错提醒的UI设计可以接受吗? | 1 | ||||
21 | 错误信息内容可以理解吗? | 1 | ||||
22 | 错误信息是否保持一致? | 1 | ||||
23 | 这些错误信息有帮助吗? | 1 | ||||
24 | 错误信息内容是否合适? | 1 | ||||
25 | 这些错误是否符合惯例和标准? | 1 | ||||
26 | 这些错误信息本身是否安全? | 1 | ||||
27 | 运行记录和崩溃是否能被用户和开发者获得? | 1 | ||||
28 | 是否所有的错误都被测试过? | 1 | ||||
29 | 用户处理完错误信息后,将处于什么状态? | 1 | ||||
30 | 是否在用户应该接受错误信息时,却没有错误信息弹出? | 1 | ||||
31 | 后台消息能即使推送到移动端吗? | 1 | ||||
32 | 如果因网络或其他原因出错,提示框中是否有重试或者不重试的选择按钮? | 1 | ||||
其他异常 | ||||||
33 | 系统会因为长时间运行而慢慢停止,然后崩溃吗? | 1 | ||||
34 | 开启时会发生什么? | 1 | ||||
35 | 任务完成中会发生什么? | 1 | ||||
36 | 是否可能丢失未保存的操作? | 1 | ||||
37 | 你可以忽视通知提醒吗?忽视后会发生什么? | 1 | ||||
38 | 你可以对通知提醒做出响应吗?响应后会发生什么 | 1 | ||||
39 | 当登录过期或超时会发生什么? | 1 | ||||
40 | 多次快速点击时,这个同样适用于Apple | 1 |
4、交叉事件测试
用例编号 | 测试内容 | 操作步骤 | 预期结果 | 测试次数 | 测试结果 | 备注 |
1 | 多个App同时运行是否影响正常功能 | 运行多个APP | 运行正常(注意内存不足的情况) | 1 | ||
2 | App运行时前/后台切换是否影响正常功能 | 具体参考功能sheet中的“前后台切换” | 无影响 | 1 | ||
3 | 冲突测试 | App运行时拨打/接听电话 | 无影响 | 1 | ||
4 | 冲突测试 | App运行时发送/接收信息 | 无影响 | 1 | ||
5 | 冲突测试 | App运行时发送/收取邮件 | 无影响 | 1 | ||
6 | 冲突测试 | App运行时切换网络(2G、3G、wifi) | 无影响 | 1 | ||
1 | 冲突测试 | App运行时浏览网络 | 无影响 | 1 | ||
2 | 冲突测试 | App运行时使用蓝牙传送/接收数据 | 无影响 | 1 | ||
3 | 冲突测试 | App运行时使用相机、计算器等手机自带设备 | 无影响 | 1 | ||
4 | 多个运行中的App的切换 | 多个运行中的App的切换 | 正常 | 1 | ||
5 | App运行时关机 | App运行时关机 | 正常 | 1 | ||
6 | App运行时重启系统 | App运行时重启系统 | 正常 | 1 | ||
7 | App运行时充电 | App运行时充电 | 正常 | 1 | ||
8 | App运行时kill掉进程再打开 | App运行时kill掉进程再打开 | 正常 | 1 | ||
9 | App运行时受到语音留言 | 1 | ||||
10 | App运行时,电话打进来 | 1 | ||||
11 | App运行时收到信息 | 1 | ||||
12 | App运行时,受到提醒通知 | 1 |
5、硬件测试
用例编号 | 测试内容 | 操作步骤 | 预期结果 | 测试次数 | 测试结果 | 备注 |
手势操作:不同的用户有不同的操作习惯,所以产品的操作行为和工作流程也很重要。 | ||||||
1 | 手势操作是否根设计相符,页面切换是否流畅 | 用手势操作APP | 流畅、准确 | 1 | ||
网络环境:2G、3G、wifi。目前2G的网络相对于比较慢,测试时尤其要注意此块的测试。 | ||||||
2 | 无网络时,执行需要网络的操作,给予友好提示,确保程序不出现crash。 | 程序运行过程中断开网络 | 继续操作,观察是否给出友好提示或出现异常 | 1 | ||
3 | WIFI/2G/3G/4G情况下数据显示 | 1 | ||||
4 | 2G和wifi切换情况下的处理 | 1、从wifi切换到2G | 正常 | 1 | ||
5 | 3G和wifi切换情况下的处理 | 1、从wifi切换到3G | 正常 | 1 | ||
6 | 4G和wifi切换情况下的处理 | 1、从wifi切换到4G | 正常 | 1 | ||
7 | 不同wifi切换时的处理 | 从某wifi切换到另一个wifi | 正常 | 1 | ||
8 | 在网络信号不好时,检查功能状态是否正常 | 远离路由,操作APP | 确保不因提交数据失败而造成crash | 1 | ||
9 | 在网络信号不好时,检查数据是否会一直处于提交中的状态,有无超时限制。 | 远离路由,操作APP中某个提交操作 | 如遇数据交换失败时要给予提示 | 1 | ||
10 | 在网络信号不好时,执行操作后,在回调没有完成的情况下,退出本页面或者执行其他操作的情况,有无异常情况。 | 远离路由,操作APP。例如用第三方账号登录,出现授权成功时推出该页面或点击页面其他按钮 | 无异常 | 1 | 该问题容易导致程序出现crash | |
服务器异常:如服务器宕机或出现404、502等情况下的测试 | ||||||
11 | 服务器异常 | 服务器更改DNS | APP给出友好提示,片刻后操作无异常 | 1 | 如:当出现域名解析故障时,你对后台API的请求很可能就会出现404错误,抛出异常这时需要对异常进行正确的处理,否则可能会导致程序不能正常工作。 | |
12 | 服务器异常 | 服务器更改域名、端口 | APP给出友好提示,片刻后操作无异常 | 1 | ||
13 | 服务器异常 | 断开服务器网络,片刻后再次连接 | APP给出友好提示,片刻后操作无异常 | 1 | ||
14 | 服务器异常 | 将服务器关机 | APP给出友好提示 | 1 |
6、更新升级测试
用例编号 | 测试内容 | 操作步骤 | 测试结果 | 测试次数 | 测试结果 | 备注 |
更新 | ||||||
1 | 测试升级后的功能是否与需求说明一样 | 1、更新后检查升级的功能,与需求说明对比: | 与需求一致 | 1 | ||
2 | 当客户端有新版本时,有更新提示 | 1 | ||||
1 | 当版本为非强制升级版时,用户可以取消更新,老版本能正常使用。用户在下次启动APP时,仍能出现更新提示 | 1 | ||||
2 | 当版本为强制升级版时,当给出强制更新后用户没有做更新时,退出客户端。下次启动APP时,仍出现强制升级提示 | 1 | ||||
3 | 当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新 | 不卸载客户端的情况下更新,更新后检查功能和资源同名文件 | 可以正常更新到新版本,功能正常,且同名文件更新到最新版本 | 1 | ||
4 | 在线升级时数字签名验证是否通过,升级是否成功 | 有版本更新时点击【在线升级】 | 可以正确升级,升级后正常使用 | 1 | ||
5 | 在线跨版本升级 | 在某一版本上点击【在线升级】 | 可以正确升级,升级后正常使用 | 1 | ||
6 | 通过第三方软件协助升级是否正常 | 1 | ||||
7 | 在不同操作系统下升级是否正常 | 1 | Pass | |||
8 | 升级过程中断网,升级是否能完成 | 可以完成 | 1 | |||
9 | 升级后的文件夹及文件是否写到了指定的目录里 | 是 | 1 | |||
10 | 软件升级过程是否可以取消,点击取消后,写入的文件是否如概要设计说明处理 | 是 | 1 | |||
11 | 软件升级过程中断电 | 重新升级无异常 | 1 | |||
12 | 软件升级过程中重启 | 重新升级无异常 | 1 | |||
13 | 软件升级过程中死机 | 重新升级无异常 | 1 | |||
14 | 升级空间不足时是否有相应提示 | 有 | 1 | |||
15 | 升级后没有生成多余的目录结构和文件 | 1 |
7、客户的数据库设计测试
用例编号 | 测试类别 | 操作步骤 | 预期结果 | 测试次数 | 测试结果 | 备注 |
1 | 一般的增、删、改、查测试 | 1 | ||||
2 | 当表不存在时是否能自动创建,当数据库表被删除后能否再自建,数据是否还能自动从服务端中获取回来并保存 | 1 | ||||
3 | 当业务需要从客户端取数据时,检查客户端数据存在时,app数据是否能自动从客户端数据中取出,还是仍然会从服务器端获取?检查客户端数据不存在时,app数据能否自动从服务器端获取到并保存到客户端 | 1 | ||||
4 | 在业务需要从服务端取回数据保存到客户端的时候,客户端能否将数据保存到本地 | 1 | ||||
5 | 当业务对数据进行了修改、删除后,客户端和服务端是否会有相应的更新 | 1 |
8、日志抓取分析
用例编号 | 测试类别 | 测试内容 | 详细 | 测试次数 | 测试结果 | 备注 |
1 | 功能测试 | 手机助手连接手机进行操作 | 1 | |||
2 | 功能测试 | 记录手机的Error Log | 1、下载安装:alogcat.apk | 1 | ||
3 | 功能测试 | 手机数据信息 | 使用360手机助手等工具进行管理与查看手机的目录结构和数据存储位置将非常方便 | 1 |