手机app测试要点（复制文）

 

 1、简介 

    移动应用App已经渗透到每一个人的生活、娱乐、学习、工做当中，使人激动、兴奋且具备创造性的各类App犹如雨后春笋般交付到用户手中。各种智能终端也在快速发布，而开发者对于全球移动设备的质量和性能却掌握甚少，App与设备的兼容性问题经常致使用户投诉，令开发者十分沮丧，App测试与服务质量保证矛盾十分突出。  

 

移动开发的一个重要难题，就是应用在开发过程当中，必须使用手机真实环境进行系统测试，才有可能进入商用。因为手机操做系统的不一样，以及操做系统版本之间的差别，使得真机系统测试这个过程尤为复杂，涉及终端、人员、工具、时间、管理等方面的问题。  

 

首先必须购买足够多的手机，包括不一样操做系统，不一样版本，不一样分辨率，甚至不一样厂商，目前市场上的手机平台有iOS、Android、Symbian、WP、Blackberry、Linux等（集中度较高的是iOS、Android和WP系统），平台之间存在较大差别，语言和标准彻底不一样。以Android为例，就须要面对Android 1.五、2.0、2.一、2.二、2.三、3.0、4.0七个以上的版本，约十几种不一样的分辨率，HTC、摩托、三星、LG、索爱、联想、中兴、华为…等数十个厂商。一个商业化运做的开发团队，通常至少须要几十部手机、终端，才能完成必要的适配工做。若是缺失这个真机系统测试环节，极大可能会给应用的推广和使用埋下了一个隐患，一旦出问题将直接招致用户的投诉或抛弃。  

其次在拿到不一样手机进行测试的时候，还将面临不一样手机厂商的系统版本差别问题，即使是标准统一的Android系统，手机厂商的版本也并不是彻底相同，MIUI、LePhone、MEIZU，这些Android系统已经加入了不少个性化的东西，致使Android应用必须进行单独适配。这过程当中出现的不少问题，每每没有资料可查，使开发者雪上加霜。 

终端问题以后，就是人员工资的高涨使得不少开发团队在紧张的预算下优先向产品、运营、技术倾斜，不少成规模的互联网企业一般只有几我的的小测试团队。  

另外，App的真机系统测试在全球范围内还停留在刀耕火种的纯人工状态，没有有效的工具能够利用，测试人员发现的Bug很难复现，开发人员所以也很难定位、快速修改Bug。   

接下来的问题是，为了知足用户旺盛的需求、适应激烈的市场竞争，全部的移动互联网企业都在拼命地赶工期，开发人员下班前完成的版本、至少但愿次日上班的时候可以被测试完成，这就要求测试人员连夜工做，因而咱们能够看到不少欧美的软件公司会把测试工做交给中国的外包企业进行。  

最后，终端、人员、流程等管理问题也很是突出，终端、Bug、人员要在测试、开发、产品、客服、运营等不一样的部门以前交错。  

如何进行卓有成效的App系统测试，以及协调好与之相关的计划、管理、人员、资源、终端等各个环节，一直是困扰各个App开发企业的问题。   

1.1 什么是App测试  

IEEE定义：使用人工或自动化来测试某个程序，来验证它是否知足规定的需求或者实际结果和预期结果之间的差异。 

App是基于移动互联网软件、及软硬件环境的应用软件。App测试就是要找出App中的BUG，经过各类手段和测试工具，判断App系统是否可以知足预期标准。移动App，因为增长了终端、外设和网络等多项元素，于是测试内容和项目也相应增长了。  

在App开发过程当中容易出现缺少有效沟通，功能复杂、编程错误、需求不断变动、时间压力、缺少文档的代码、App开发工具、SDK和人员的疏忽等缘由引起的错误，经过测试可以发现、找出其中的错误，解决错误，从而提升App的质量2.

 

1.2 测试方法  

 白盒测试  

依据被测App分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试。

黑盒测试  

黑盒测试（Black-Box Testing）是基于系统需求规格，在不知道系统或组件的内部结构的状况下进行的测试，把测试对象看做一个黑盒，只考虑总体特性，不考虑内部具体实现。  一般又将黑盒测试叫作：基于规格的测试（Specification-Based Testing）、输入输出测试（Input/Output Testing）、功能测试（Functional Testing）。 

人工测试   

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

自动化测试  

经过计算机模拟人的测试行为，替代人的测试活动，狭义上指测试执行由计算机来完成。

 

UT、  Unit Testing单元测试  

定义：对App的基本组成单元来进行正确性检验。集中对用源代码实现的每个程序单元 进行测试，检查各个程序模块是否正确地实现了规定的功能。  目的：检测App模块对App产品设计说明书的符合程度。  类型：白盒测试，测试范围为单元内部的数据结构，逻辑控制，异常处理。 评估标准：逻辑覆盖率。 

IT、 Integrate Testing集成测试  

定义：测试模块或子系统组装后功能以及模块间接口是否正确，把已测试过的模块组装起来，主要对与设计相关的App体系结构的构造进行测试。  目的：在于检测App模块对App产品概要设计说明书的符合程度。  类型：灰盒测试，测试范围为模块之间接口与接口数据传递的关系，以及模块组合后的功能。  评估标准：接口覆盖率。

ST  、System Testing系统测试  

定义：App系统测试（App System Testing），是将已经确认的App程序、移动终端、外设、网络等其余元素结合在一块儿，进行信息系统的各类组装测试和确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否知足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。App系统测试发现问题以后要通过调试找出错误缘由和位置，而后进行改正。  

App系统测试是基于系统总体需求说明书的黑盒类测试，应覆盖系统全部联合的部件。对象不只仅包括需测试的App软件，还要包含App软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等，基于本地及不一样地区、网络等真实终端，测试、检查已实现的App是否知足了需求规格说明中肯定了的各类需求，以及App配置是否彻底、正确。 

目的：验证最终App系统是否知足用户规定的需求。 

类型：黑盒测试，测试范围为整个系统。

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

系统测试过程：

 

2.  移动App的系统测试    

目前主流的iOS、Android和WP等OS系统以及各平台，都相应地提供了不一样程度的单元、集成测试工具，能够在模拟器、沙箱环境下进行白盒、灰盒测试、调试。  

但App存在着大量的软硬件交互，而这些都须要经过真实的终端经过黑盒测试方法进行系统测试，须要将通过集成测试的软件，做为移动终端的一个部分，与系统中其余部分结合起来，在实际运行环境下对移动终端系统进行一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行，验证最终软件系统是否知足用户规定的需求。  

然而，因为OS版本、硬件异常迅猛的发展速度，平台始终没有有效地提供符合App黑盒系统测试的工具与方法，大量的移动App测试还停留在纯人工状态，效率十分低下。终端、版本的碎片化，更加重了这一问题的严重性。  

本身开发、或借助第三方工具、平台，进行自动化的移动互联网App系统黑盒测试，是提高效率和测试质量的有效方法。  

移动互联网是极快速发展的新兴产业，没有成功经验可循，只有市场和用户才是检验你产品是否好坏的终极标准。借助传统软件测试方法和规律，能够有效地提高App的程序质量和用户体验。 

 

冒烟测试（Smoke Testing）

冒烟测试（Smoke Testing）的对象是每个新编译的须要正式测试的App版本，目的是确认软件基本功能正常，可进行后续的正式测试工做。冒烟测试的执行者是版本编译人员。     

App程序在编写开发过程当中，内部须要多个版本(Builds)，可是只有有限的几个版本须要执行正式测试（根据项目开发计划），这些须要执行的中间测试版本。在刚刚编译出来后，开发人员须要进行基本性能确认测试，验证App是否能正确安装、卸载，以及操做过程和操做先后对系统资源的使用状况，针对终端硬件及ROM版本的各维度，与App安装、卸载不适配状况、隐患缘由分析报告，最终确认是否能够正确安装/卸载，主要功能是否实现，是否存在严重死机、意外崩溃等Bug。  

若是经过了该测试，则能够根据正式测试文档进行正式测试。不然，就须要从新编译版本，再次执行版本可接收确认测试，直到成功。  

若是发现问题，就要有效地发现致使问题出现的缘由，例如在Android App测试中，某些终端、有时会出现应用程序错误须要强行关闭的提示，但又找不到重现这个问题的步骤，这个是App的问题仍是系统的问题呢，应该怎么判断呢？这一般须要有Log日志才能够判断，Andriod App出现Crash的状况，通常有两方面的缘由，若是Log日志中出现System_server，则为系统问题；若是Log中出现Shutdown VM，表明应用程序的问题；还有一种状况是出现Died，这个是进程死掉致使，包含系统主动杀死的状况。

 

【Testin Tips】  当一个单元、或程序总体开发编译完成，开发人员、或测试人员能够在PC上选取被测的App，经过iTestin链接的原型测试终端，自动进行快速的冒烟测试，以验证App安装、启动、基本操做运行、卸载等是否正常，测试报告包括各测试项是否成功、特征截图、Log日志、CPU/内存等参数等。

 

功能测试（Functional Testing）  

功能测试是移动App测试最关键的环节，根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品需求规格；  

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

（1）是否有遗漏需求；    

（2）是否正确的实现全部功能；  

（3）隐示需求在系统是否实现；  

（4）输入、输出是否正确。  

移动App的功能测试应侧重于全部可直接追踪到用例、或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。  

功能测试基于黑盒技术，经过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。  

【Testin Tips】  经过iTestin Suite链接的本地终端，测试人员能够很是方便地按照测试用例、在终端上进行操做，全部的操做过程、轨迹都会被自动记录为脚本，全部操做目标、特征点的屏幕截图、Log日志、CPU/内存/网络和其余系统资源参数也都会被详细的记录下来，最后造成测试报告。  当功能测试要求涉及到不一样地区、不一样网络的时候，能够发布任务到mTestin社区，要求特定地区、特定网络的测试者按照功能测试用例要求进行测试，而后经过报告汇总测试结果

2.3    用户界面测试（GUI Testing）  

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

GUI测试主要测试在不一样分辨率下，测试用户界面(如菜单、对话框、窗口和其它可视控件)布局、风格是否知足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操做是否友好等。  

GUI测试的目标是确保用户界面会经过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准，包括用户友好性、人性化、易操做性测试。  

【Testin Tips】  经过iTestin Suite完成冒烟测试和功能测试，全部特征点的截图均可以快速反馈UI是否正常。 同时，为了更好地测试普通用户对UI的反馈，能够进行用户UI测试，找一组人(1组12人，军队一个班的建制)，试用你的原型UI，记录他们的操做轨迹，固然包括严重的Bug：  1） 邀请外部用户在现场经过iTestin Suite链接的终端进行操做。  2） 发布测试任务到mTestin社区，要求n组用户按照UI测试要求，经过用户本身的终端 链接到iTestin进行操做，将完成的任务提交到mTestin社区。  经过此类测试，能够有效地发现不一样用户操做UI上的行为轨迹差别，以判断UI是否存在设计不恰当、或许要改进的地方。   

2.4     用户体验可用性测试（UE Testing）  

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

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

【Testin Tips】  参考GUI测试方法，为了更好地测试普通用户对App UE的反馈，能够进行用户可用性测试，找n组测试者（1组12人——军队一个班的建制，UE测试建议选取最大12组测试者、144人），试用App的原型UE可用性，记录测试者的操做轨迹，固然包括严重的Bug。  1） 邀请外部用户在现场经过iTestin Suite链接的终端进行操做。  2） 发布测试任务到mTestin社区，要求n组用户按照可用性测试要求，经过用户本身的终 端链接到iTestin进行操做，将完成的任务提交到mTestin社区。  经过此类测试，能够有效地发现不一样用户操做App UE行为轨迹差别，以判断App的UE是否存在设计不恰当、或许要改进的地方。    

2.5    安全性、访问控制测试（Security Testing）  

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

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

应用程序级别的安全性可确保：在预期的安全性状况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会容许全部人输入数据，建立新帐户，但只有管理员才能删除这些数据或帐户。若是具备数据级别的安全性，测试就可确保“用户类型一” 可以看到全部客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。  

2) 系统级别的安全性，包括对系统的登陆或远程访问。  系统级别的安全性可确保只有具有系统访问权限的用户才能访问应用程序，并且只能经过相应的网关来访问。

2.6    性能测试（Performance Testing）  

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

2.6.1  负载测试（Load Testing）  

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

【Testin Tips】  性能测试能够经过iTestin录制脚本，在本地的原型终端上单机进行，也能够在iTestin组成的企业私有云、或Testin终端云上发起任务。  

2.6.2  强度测试（Stress Testing）  

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

 

【Testin Tips】  强度测试能够根据测试要求，经过iTestin录制脚本，本地、或经过企业私有云、甚至Testin公有云的终端，很是方便、有效地设定屡次执行的次数，自动进行测试，例如选99件商品、加999个好友、上传9999张照片、支付99999次等等。   

2.6.3  稳定性测试（Stability Testing）  

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

【Testin Tips】  稳定性测试能够根据App的产品特征，很是方便地录制脚本，经过本地、私有云、公有云和mTestin群测，快速、有效地完成测试。

 

 

2.6.4 基准测试  

 

基准测试的目的主要是进行与已知系统的比较，包括App以前的版本、参照版本、竞品等。 

【Testin Tips】  根据基准测试要求，能够经过iTestin在本地经过同类脚本的执行，能够有效地判断不一样App基准测试的结果。  

2.6.5  竞争测试  

竞争测试是判断App竞争使用各类资源（数据纪录，内存等）的状况。  

【Testin Tips】  经过iTestin Suite进行App测试时，全部相关的CPU、内存、网络等资源数据都会被记录下来，用于竞争测试分析。   

2.7 故障转移和恢复测试（Recovery Testing）  

经过人工干预手段使系统发生软、硬件异常，经过验证系统异常先后的功能和运行状态，达到检验系统容错，排错和恢复的能力。可确保测试对象能成功完成故障转移，并能从致使意外数据损失或数据完整性破坏的各类硬件、App或网络故障中恢复。   

故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以免丢失任何数据或事务。  恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。而后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已获得了正确的恢复。  

【Testin Tips】  在不涉及电源终端或开关机等状态下的故障转移和恢复测试，能够经过iTestin对测试App及终端在测试过程当中的各项参数进行记录，帮助分析、判断测试结果。   

 

2.8 兼容适配性测试（配置测试Configuration Testing） 

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

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

目标：验证所有配置的可操做性、有效性，特别须要对最大配置，最小配置和特殊配置进行测试。   

● 操做系统版本的兼容性：测试App在不一样操做系统版本下是否可以正确显示与运行；   

● 硬件兼容性：测试与硬件密切相关的App产品与其余硬件产品的兼容性，是否能够正 确使用；   

● 浏览器兼容性：测试App在不一样产商的浏览器下是否可以正确显示与运行。 

 

2.9 分辨率测试  

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

【Testin Tips】  分辨率测试能够上传App到Testin平台，选取不一样分辨率的终端，自动进行。  

2.10   网络测试  

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

【Testin Tips】  能够按照网络要求，将测试任务发布到mTestin社区，测试者经过符合要求网络的测试终端完成测试任务，并上报测试结果到mTestin

2.11   本地化测试  

是指为各个地方开发产品的测试，如英文版、中文版等等，包括程序是否可以正常运行，界面是否符合当地习俗，快捷键是否正常起做用等等，特别测试在A语言环境下运行B语言App（好比在英文环境下运行中文版App）是否正常。  

【Testin Tips】  能够按照本地化语言要求，将测试任务发布到mTestin社区，测试者经过符合要求语言要求的测试终端完成测试任务，并上报测试结果到mTestin。  

2.12   文字测试  

测试文字是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否由出入等等，包括图片文字。  

【Testin Tips】  能够按照文字测试的要求，将测试任务发布到mTestin社区，选取合格的测试者分A/B组进行测试，测试者经过符合要求素质要求的测试终端完成测试任务，并上报测试结果到mTestin。  

此类发布到mTestin的App测试，存在明显的“杀虫剂现象”，即因为测试人员的思路不尽相同，每一个人测试的侧重点不一样，因为都按照测试用例进行测试，可是测试用例通常仅描述系统的一些基本测试项，不会将全部的测试用例方方面面都写到，有时还须要测试人员的经验和素质。因此A测试某个产品用了七个工做日，第一天到第四天报出许多bug，但从第五天开始几乎报不出啥 bug了。七天后换了B，B一会儿又测试出一堆bug，不能说A的水平差，只能说该App已经对A产生了抗药性，这就是测试学中的杀虫剂现象。因此在测试中每次轮流测试最好安排不一样的测试人员进行不一样模块测试工做，以免杀虫剂现象产生。  

2.13   发布测试  

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

【Testin Tips】  发布测试能够由App产品、客服团队内部测试，或发布测试任务到mTestin进行测试。

2.13.1 说明书测试 

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

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

功能检查：功能是否描述彻底，或者描述了并无的功能等；  图片检查：检查图片是否正确。

 2.13.2  宣传材料测试 

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

 2.13.3  帮助文件测试 

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

2.15回归测试 

回归测试是以上全部测试完成后的一个最为重要的环节，是App发布、维护阶段，对缺陷进行修复后的测试。 

目的是验证缺陷已经获得修复，检测是否引入新的缺陷； 流程：  

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

2）肯定须要回归测试的版本；  

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

4）回归测试经过，关闭缺陷跟踪单；  

5）回归测试不经过，缺陷跟踪单返回给开发人员，开发人员从新修改BUG。再次提交给测试人员回归测试 

测试策略：  

1）彻底重复测试：从新执行前期设计的用例，来确认问题修改的真确性和修改的扩散局部影响性；  

2）选择性重复测试：  

a) 覆盖修改法：针对被修改的部分，选取或从新构造测试用例验证没有错误再次发 生的选择方法；  

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

c) 指标达成法：先肯定一个达成的指标，基于这种要求选择一个最小的测试用例集 合。 

【Testin Tips】  因为回归测试是各项系统测试的重复，因此经过Testin所提供的各类测试工具与方法仍然是适合的，以前测试录制的脚本能够继续使用。根据回归测试的终端、能够分解任务执行。 

10 / 20