2023年6月30日发(作者：)

1.2 测试方法

1.2.1 白盒测试

依据被测 App 分析程序内部构造，并根据内部构造设计用例，来对内部控

制流程进行测试。

1.2.2 黑盒测试

黑盒测试(Black-Box Testing)是基于系统需求规格，在不知道系统或组件

的内部结构的情况下进行的测试，把测试对象看作一个黑盒，只考虑整体特性，

不 考 虑 内 部 具 体 实 现 。 通 常 又 将 黑 盒 测试 叫 做： 基 于 规 格 的 测 试

(Specification-Based Testing )、输入输出测试(Input/Output Testing )、功能测试

(Functional Testing ) 。

1.3 测试类型

1.3.1 人工测试

测试活动由人来完成，狭义上指测试执行由人工完成。

1.3.2 自动化测试

通过计算机模拟人的测试行为， 替代人的测试活动， 狭义上指测试执行由计

算机来完成。

1.4UT 、IT 、ST 测试

1.4.1Unit Testing 单元测试

定义：对 App 的基本组成单元来进行正确性检验。集中对用源代码实现的

每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

目的：检测 App 模块对 App 产品设计说明书的符合程度。

类型：白盒测试，测试范围为单元内部的数据结构，逻辑控制，异常处理。

评估标准：逻辑覆盖率。

1.4.2Integrate Testing 集成测试

定义： 测试模块或子系统组装后功能以及模块间接口是否正确， 把已测试过

的模块组装起来，主要对与设计相关的 App 体系结构的构造进行测试。

目的：在于检测 App 模块对 App 产品概要设计说明书的符合程度。

类型： 灰盒测试， 测试范围为模块之间接口与接口数据传递的关系， 以及模 块组合后的功能。

评估标准：接口覆盖率。

1.4.3System Testing 系统测试

定义： App 系统测试 (App System Testing )，是将已经确认的 App 程序、移

动终端、 外设、 网络等其他元素结合在一起， 进行信息系统的各种组装测试和确

认测试， 系统测试是针对整个产品系统进行的测试， 目的是验证系统是否满足了

需求规格的定义， 找出与需求规格不符或与之矛盾的地方， 从而提出更加完善的

方案。 App 系统测试发现问题之后要经过调试找出错误原因和位置， 然后进行改

正。

App 系统测试是基于系统整体需求说明书的黑盒类测试， 应覆盖系统所有联

合的部件。对象不仅仅包括需测试的 App 软件，还要包含 App 软件所依赖的硬

件、外设甚至包括某些数据、某些支持软件及其接口等，基于本地及不同地区、

网络等真实终端，测试、检查已实现的 App 是否满足了需求规格说明中确定了

的各种需求，以及 App 配置是否完全正确。

目的：验证最终 App 系统是否满足用户规定的需求。类型：黑盒测试，测试范围为整个系统。

1.5 卓有成效的移动 App 系统测试 The Effective System Testing of Mobile App

评估标准：测试用例对需求规格的覆盖率。

系统测试过程：

2. 移动 App 系统测试

2.1 冒烟测试(Smoke Testing)

冒烟测试(Smoke Testing) 的对象是每一个新编译的需要正式测试的 App

版本， 目的是确认软 件基本功能正常，可进行后续的正式测试工作 。 冒烟测试

的执行者是版本编译人员。

App 程序在编写开发过程中， 内部需要多个版本(Builds)，但是只有有限的

几个版本需要执行正式 测试(根据项目开发计划)， 这些需要执行的中间测试版

本，在刚刚编译出来后，开发人员需要进行基

2.2 功能测试 ( Functional Testing )

功能测试是移动 App 测试最关键的环节，根据产品的需求规格说明书和测

试需求列表，验证产品的功能实现是否符合产品需求规格；

功能测试的目标主要包括：

是否有遗漏需求；

是否正确的实现所有功能；

隐示需求在系统是否实现；

输入、输出是否正确。

移动 App 的功能测试应侧重于所有可直接追踪到用例、或业务功能和业务

规则的测试需求。 这种测试的目标是核实数据的接受、 处理和检索是否正确， 以

及业务规则的实施是否恰当。

功能测试基于黑盒技术，通过图形用户界面 (GUI) 与应用程序进行交互，

并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

2.3 用户界面 测试 ( GUI Testing )

用户界面 (GUI) 测试用于核实用户与 App 之间的交互，包括用户友好性，

人性化测试。

一个好的 App 要有一个极佳的分辨率， 而在其他分辨率下也都能可以运

行 。GUI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应

的访问或浏览功能。 另外， GUI 测试还可确保 GUI 中的对象按照预期的方式

运行，并符合公司或行业的标准。

GUI 测试主要测试在不同分辨率下，测试用户界面 (如菜单、对话框、窗口

和其它可视控件)布局、风格是否满足客户要求， 文字是否正确， 页面是否美观，

文字，图片组合是否完美，操作是否友好等。

GUI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应

的访问或浏览功能。 确保用户界面符合公司或行业的标准， 包括用户友好性、 人

性化、易操作性测试。

2.4 用户 体验 易用 性测试 ( UE Testing )

用户体验易用性测试主要是检测用户在理解和使用系统方面到底有多好， 是

否存在障碍或难以理解的部分。

用户体验易用性的测试方法， 一般是通过用户访谈， 或邀请内测、 小范围公

测等方式进行， 通过不同实验组的运营结果来判断是否存在易用性缺陷。 但由于

缺乏有效的测试工具， 必须要大量的测试样本才能获得比较真实的测试数据， 投

入资源较多，测试周期较长。

2.5 安全性 、 访问控制测试 ( Security Testing )

安全性和访问控制测试侧重于安全性的两个关键方面：

1) 应用程序级别的安全性，包括对数据或业务功能的访问。

应用程序级别的安全性可确保： 在预期的安全性情况下， 主角只能访问特定

的功能或

用例， 或者只能访问有限的数据 。例如， 可能会允许所有人输入数据， 创建

新账户，但只

有管理员才能删除这些数据或账户。 如果具有数据级别的安全性， 测试就可

确保“用户类

型一” 能够看到所有客户消息(包括财务数据) ， 而“用户二”只能看见

同一客户的统计

数据。

2) 系统级别的安全性，包括对系统的登录或远程访问。

系统级别的安全性可确保只有具备系统访问权限的用户才能访问应用程序，

而且只能

通过相应的网关来访问。

2.6 性能测试 ( Performance Testing )

性能测试用来测试 App 在真实环境中的运行性能，以及与硬件、网络资源

的匹配度，最终度量系统相对于预定义目标的差距。

性能测试测试主要通过以下几项测试完成。

2.6.1 负载测试 ( Load Testing )

负载测试是在一定的软硬件及网络环境下， 通过模拟不同的用户， 执行一种

或多种业务， 观察系统在不同负载下的性能表现。 在这种测试中， 将使测试对象

承担不同的工作量， 以评测和评估测试对象在不同工作量条件下的性能行为， 以

及持续正常运行的能力。

负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正

常运行。

此外， 负载测试还要评估性能特征， 例如， 响应时间、事务处理速率和其他

与时间相关的方面。

2.6.2 强度测试 ( Stress Testing )

强度测试是一种性能测试， 实施和执行此类测试的目的是找出因资源不足或

资源争用而导致的错误。 如果内存或磁盘空间不足， 测试对象就可能会表现出一

些在正常条件下并不明显的缺陷。 而其他缺陷则可能由于争用共享资源 (如数据

库锁或网络带宽) 而造成的。 强度测试还可用于确定测试对象能够处理的最大工

作量。

2.6.3 稳定性测试 ( St ability Testing )

稳定性测试评价系统在一定负荷情况下， 长时间的运行情况。 在一定的软硬

件及网络环境中， 通过模拟大量的用户执行多种业务处理大量数据， 使系统在极

限环境下长时间运行，目的在于寻找系统的失效点。

2.6.4 基准测试

基准测试的目的主要是进行与已知系统的比较，包括 App 之前的版本、参

照版本、竞品等。

2.6.5 竞品测试

竞品测试是判断 App 竞争使用各种资源(数据纪录，内存等)的情况。

2.6.6 故障转移和恢复测试 ( Recovery Testing )

通过人工干预手段使系统发生软、 硬件异常， 通过验证系统异常前后的功能

和运行状态， 达到检验系统容错， 排错和恢复的能力。 可确保测试对象能成功完

成故障转移， 并能从导致意外数据损失或数据完整性破坏的各种硬件 、App 或

网络故障中恢复。

故障转移测试可确保对于必须持续运行的系统， 一旦发生故障， 备用系统就

将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。

恢复测试是一种对抗性的测试过程。 在这种测试中， 将把应用程序或系统置

于极端的条件下 (或者是模拟的极端条件下) ， 以产生故障 (例如设备输入/

输出 (I/O) 故障或无效的数据库指针和关健字) 。然后调用恢复进程并监测和

检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。

2.7 兼容性测试( Compatibility Testing )

兼容适配性测试(配置测试) ，是核实测试对象在不同的 App 、硬件配置

中的运行情况， 测试系统在各种软硬件配置， 不同的参数配置下系统具有的功能

和性能。

在大多数环境中，不同终端、屏幕、 OS 版本、网络连接的规格都会有所不

同， 而这些因素都可能运行许多不同的配置环境组合， 从而占用不同的资源 (如

CPU 、内存、浏览器版本、 OS 版本等) 。

目标： 验证全部配置的可操作性、有效性， 特别需要对最大配置， 最小配置

和特殊配置进行测试。

操作系统版本的兼容性：测试 App 在不同操作系统版本下是否能够正

确显示与运行；

硬件兼容性：测试与硬件密切相关的 App 产品与其他硬件产品的兼容

性，是否可以正确使用；

浏览器兼容性：测试 App 在不同产商的浏览器下是否能够正确显示与

运行。

2.8 分辨率 测试

测试在不同分辨率下，界面是否匹配。

2.9 网络测试

在网络环境下和其他设备对接， 进行系统功能， 性能与指标方面的测试， 保

证设备对接正常。

2.10 本地化测试

本地化测试是指为各个地方开发产品的测试， 如英文版、 中文版等等， 包

括程序是否能够正常运行， 界面是否符合当地习俗， 快捷键是否正常起作用等等，

特别测试在 A 语言环境下运行 B 语言 App (比如在英文环境下运行中文版

App)是否正常。

2.11 文字测试

测试文字是否拼写正确， 是否易懂， 不存在二义性， 没有语法错误； 文字与

内容是否有出入等等，包括图片文字。

2.12 发布测试

主要在 App 发布前对说明书、广告稿等进行测试。2.12.1 说明书测试

主要为语言检查、功能检查、图片检查。

语言检查：检查说明书语言是否正确，用词是否易于理解；

功能检查：功能是否描述完全，或者描述了并没有的功能等；

图片检查：检查图片是否正确。

2.12.2 宣传材料测试

主要测试产品中附带的宣传材料中的语言、描述功能、图片等。

2.12.3 帮助文件测试

帮助文件是否正确，易懂，是否人性化。

2.12.4 回归测试

回归测试是修改了旧代码后， 重新进行测试以确认修改没有引入新的错误或

导致其他代码产生错误的测试， 为测试中重要的环节， 是 App 发布、 维护阶段，

对缺陷进行修复后的测试。

目的是验证缺陷已经得到修复，检测是否引入新的缺陷。

测试流程：

1)在测试策略制定阶段，制定回归测试策略；

2)确定需要回归测试的版本；

3)测试版本发布后，按照回归测试策略来执行回归测试；

4)回归测试通过，关闭缺陷跟踪单；

5) 回归测试不通过， 缺陷跟踪单返回给开发人员， 开发人员重新修改 Bug。

再次提交给测试人员回归测试

测试策略：

1)完全重复测试：重新执行前期设计的用例，来确认问题修改的正确性和

修改的扩散局部影响性；

2)选择性重复测试：

a) 覆盖修改法： 针对被修改的部分， 选取或重新构造测试用例验证没有错

误再次发生的选择方法；

b) 周边影响法：该方法包括覆盖修改法，还要分析修改后对扩散的影响；

c) 指标达成法： 先确定一个达成的指标， 基于这种要求选择一个最小的测

试用例集合。