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. 日报所含内容：
   • 对当前测试版本质量进行分级
   • 严重阻塞进度的问题提出，提示开发同学优先修改
   • 对版本整体测试进度进行评估
3. 产品上线前，测试发送测试报告

2 APP测试点

2.1 安装

1. 软件在不同操作系统（Palm OS、Symbian、Linux、Android、iOS、Black Berry OS 6.0、Windows Phone 7）下安装是否正常
2. 软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里
3. 软件安装各个选项的组合是否符合概要设计说明
4. 软件安装向导的UI测试
5. 软件安装过程是否可以取消，点击取消后，写入的文件是否如概要设计说明处理
6. 软件安装过程中意外情况的处理是否符合需求（如死机，重启，断电）
7. 安装空间不足时是否有相应提示
8. 安装后没有生成多余的目录结构和文件
9. 对于需要通过网络验证之类的安装，在断网情况下尝试一下
10. 还需要对安装手册进行测试，依照安装手册是否能顺利安装

2.2 卸载

1. 直接删除安装文件夹卸载程序是否有提示信息
2. 测试系统直接卸载程序是否有提示信息。
3. 测试卸载后文件是否全部删除所有的安装文件夹
4. 卸载过程中出现的意外情况的测试（如死机、断电、重启）
5. 卸载是否支持取消功能，单击取消后软件卸载的情况
6. 系统直接卸载UI测试，是否有卸载状态进度条提示

2.3 安全性

2.3.1 通讯安全

1. 在软件运行中，如有来电，SMS，EMS，MMS，蓝牙等通讯或充电是，是否能暂定程序，优先处理通讯，并在处理完毕后恢复软件，继续执行
2. 创立连接时，应用程序因网络连接中断，是否可以告诉用户连接中断的情况
3. 可以处理通讯延时和中断
4. HTTP、HTTPS覆盖测试
   • APP和后台服务一般是通过http交互，验证http环境下是否正常
   • 外网免费网络中一般都要输入密码，通过SSL认证来访问网络，需要对是使用HTTP Client的library异常做捕获处理
5. 应用程序关闭，或网络断开不再使用时，应该及时关闭

2.3.2人机接口安全

1. 返回桌面应用程序保持可用
2. 指令顺序有先后
3. 本机非网络控制和通知控制，其他设置对应用程序不造成影响

2.3.3 数据安全性

1. 密码等敏感数据不会保存在设备中，同时密码不会被解码
2. 输入密码讲不以明文展示
3. 支付相关的密码一律不被储存在欲输入位置上
4. 若应用程序可进行备份操作，备份数据应进行加密操作，恢复数据应考虑恢复过程中的异常，通讯中断等
5. 在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作
6. 应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况
7. 在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的任何内容
8. 不能再安全警告前，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户
9. 如果数据库中重要的数据正要被重写, 应及时告知用

2.4 功能测试

根据软件说明或用户需求验证App的各个功能实现

• 采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准，若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或准则。
• 根据被测功能点的特性列丼出相应类型的测试用例对其进行覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖
• 在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误

2.4.1 程序运行

1. 安装后可正常打开
2. 注册
   • 用户密码长度
   • 注册后提示
   • 注册成功数据是否前后一致
3. 登录
   • 登录是否互斥
   • 是否可进行异地登录
   • 是否允许非法登录
   • 使用已在线账号登录，登录系统是否处理正常
   • 使用禁用账号登录系统，系统处理是否正常处理
   • 登录账号密码数据错误登录是否成功
   • 登录超时如何处理
4. 注销
   • 注销后用户再次登录是否成功
   • 注销后，数据是否已经删除（物理删除，或逻辑删除）

2.4.2 程序切换

1. APP切换到后台，再回到app，检查是否停留在上一次操作界面
2. APP切换到后台，再回到app，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样
3. app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
4. 手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
5. 当App使用过程中有电话进来中断后再切换到app，功能状态是否正常
6. 当杀掉app进程后，再开启app，app能否正常启动
7. 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷
8. 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃

2.4.3 保留TOKEN（免登）

2.4.4 APP更新

1. 当客户端有新版本时，有更新提示
2. 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示
3. 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示
4. 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新

2.4.5 离线加载

很多应用都可以加载数据到本地，给用户提供在离线情况下可以浏览

2.4.6 消息推送

1. 在不禁用通知的情况下，push消息是可以直接推送到手机且可以在通知栏查看
2. 在push消息推送到手机的情况下，可以点击消息进入唤醒且进入APP
3. 当push消息是针对用户进行推送的时候，需核实push消息与用户身份是否相符
4. push消息是否是按照业务规则进行推送
5. 用户设置免打扰时间内，用户是接收不到push消息的
6. 测试push时，需真机测试

2.5 UI测试

用户界面 (GUI) 测试用于核实用户与App之间的交互，包括用户友好性，人性化测试。  一个好的App要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。GUI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，GUI 测试还可确保 GUI 中的对象按照预期的方式运行，并符合公司或行业的标准

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

2.6 性能测试

性能测试用来测试App在真实环境中的运行性能，以及与硬件、网络资源的匹配度，最终度量系统相对于预定义目标的差距，通过极限测试方法，发现系统在极限或恶劣的环境中自我保护能力，主要验证系统的可靠性。 性能测试测试主要通过以下几项测试完成

2.6.1 负载测试

负载测试是在一定的软硬件及网络环境下，通过模拟不同的用户，执行一种或多种业务，观察系统在不同负载下的性能表现。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。 此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。

2.6.2 强度测试

强度测试是一种性能测试，实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

2.6.3 稳定性测试

稳定性测试评价系统在一定负荷情况下，长时间的运行情况。在一定的软硬件及网络环境中，通过模拟大量的用户执行多种业务处理大量数据，使系统在极限环境下长时间运行，目的在于寻找系统的失效点。

2.7 兼容测试

兼容适配性测试（配置测试），是核实测试对象在不同的App、硬件配置中的运行情况，测试系统在各种软硬件配置，不同的参数配置下系统具有的功能和性能。  

在大多数环境中，不同终端、屏幕、OS版本、网络连接的规格都会有所不同，而这些因素都可能运行许多不同的配置环境组合，从而占用不同的资源（如CPU、内存、浏览器版本、OS版本等）。  

1. 新老版本兼容
2. 设备兼容
3. 设备系统兼容
4. 分辨率兼容
5. 浏览器兼容

2.8 接口测试

服务端一般会提供JSON格式的数据给客户端，所以我们在服务端需要进行接口测试，确保服务端提供的接口并转换的JSON内容正确，对分支、异常流有相应的返回值。此块测试可以采用itest框架进行测试。最方便的是采用httpclient进行接口测试。
一般来讲，APP做接口测试不是特别适合

2.9 用户体验可用性测试

用户体验可用性测试主要是检测用户在理解和使用系统方面到底有多好，是否存在障碍或难以理解的部分。  

用户体验可用性的测试方法，一般是通过用户访谈，或邀请内测、小范围公测等方式进行，通过不同实验组的运营结果来判断是否存在可用性缺陷。但由于缺乏有效的测试工具，必须要大量的测试样本才能获得比较真实的测试数据，投入资源较多，测试周期较长。

2.10 网络测试

手机的网络目前主要分为2G、3G、4G、wifi。

• 无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash。 
• 内网测试时，要注意选择到外网操作时的异常情况处理。 
• 在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash。 
• 在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示。 
• 在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash

2.9 回归测试

回归测试是以上所有测试完成后的一个最为重要的环节，是App发布、维护阶段，对缺陷进行修复后的测试
目的是验证缺陷已经得到修复，检测是否引入新的缺陷

2.9.1 回归测试流程

1. 在测试策略制定阶段，制定回归测试策略
2. 确定需要回归测试的版本； 
3. 测试版本发布后，按照回归测试策略来执行回归测试； 
4. 回归测试通过，关闭缺陷跟踪单； 
5. 回归测试不通过，缺陷跟踪单返回给开发人员，开发人员重新修改BUG。再次提交给测试人员回归测试 

2.9.2 回归测试策略

1. 完全重复测试：重新执行前期设计的用例，来确认问题修改的真确性和修改的扩散局部影响性；
2. 选择性重复测试： 
3. 覆盖修改法：针对被修改的部分，选取或重新构造测试用例验证没有错误再次发 生的选择方法
4. 周边影响法：该方法包括覆盖修改法，还要分析修改后对扩散的影响； 
5. 指标达成法：先确定一个达成的指标，基于这种要求选择一个最小的测试用例集合