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 模块对 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) 应用程序级别的安全性，包括对数据或业务功能的访问。
应用程序级别的安全性可确保：  在预期的安全性情况下，  主角只能访问特定 的功能或
用例， 或者只能访问有限的数据 。例如，  可能会允许所有人输入数据，  创建 新账户，但只
有管理员才能删除这些数据或账户。  如果具有数据级别的安全性，  测试就可 确保“用户类
型一” 能够看到所有客户消息(包括财务数据)    ，  而“用户二”只能看见 同一客户的统计
数据。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。