第1章 软件测试基础
一、填空题
1、软件生命周期
2、瀑布
3、螺旋
4、功能性、可靠性、可使用性、效率、可维护性、可移植性
5、严重、一般、次要、建议
6、单元测试
7、白盒测试
8、W
二、判断题
1、F 解析：现在比较流行的开发模型为敏捷模型。
2、F
3、F 解析：软件缺陷可存在于软件需求分析、架构设计、编程开发等各个阶段。
4、T
5、F 解析：X模型融入了探索测试。
6、F
三、单选题
1、A
2、C
3、B
4、C 解析：缺陷报告的形式，每个公司都有一套模板
5、D
6、B
四、简答题
1、软件缺陷处理流程为：提交→分配→确认→处理→复测→关闭，具体如下图所示：
- 软件缺陷处理流程
（1）提交：测试人员发现缺陷之后，将缺陷提交给测试组长。
（2）分配：测试组长接收到测试组员提交的缺陷之后，将其移交给开发人员。
（3）确认：开发人员接收到移交的缺陷之后，会与团队甚至测试人员一起商议，确定该缺陷是否是一个缺陷。
（4）拒绝：如果经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷。如果经过商议之后，确定其是一个真正的缺陷，则可以根据缺陷的严重程度或优先级等立即处理或延期处理。
（5）处理：开发人员修改缺陷。
（6）复测：开发人员修改好缺陷之后，测试人员重新进行测试（回归测试），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。
（7）关闭：测试人员进行回归测试之后，如果缺陷已经被正确修改，则将缺陷关闭，整个缺陷处理完成。
2、软件测试的基本流程为：分析测试需求→制定测试计划→设计测试用例→执行测试→编写测试报告。
（1）分析测试需求
测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。
（2）制定测试计划
测试计划是整个测试工作的导航图，但它并不是一成不变的，随着项目推进或需求变更，测试计划也会不断发生改变，因此测试计划的制定是随着项目发展不断调整、逐步完善的过程。
测试计划一般要做好以下工作安排。
- 确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。
- 制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。
- 安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。
- 安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。
（3）设计测试用例
测试用例（Test Case）指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。测试用例常用的设计方法包括等价类划分法、边界值分析法、因果图与判定表、正交实验法、逻辑覆盖法等。
（4）执行测试
测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。
测试人员需要完成所有测试用例的执行，每一个测试用例都可能会发现很多缺陷，测试人员要做好测试记录与跟踪，衡量缺陷的质量并编写缺陷报告。
当提交后的缺陷被开发人员修改之后，测试人员需要进行回归测试。如果系统对测试用例产生了缺陷免疫，测试人员则需要编写新的测试用例。
（5）编写测试报告
测试报告是一个测试活动的总结，对项目测试过程进行总结，对测试数据进行统计，对项目的测试质量进行客观的评价文档。
一份完整的测试报告必须要包含以下几个要点。
- 引言：描述测试报告编写目的、报告中出现的专业术语解释及参考资料等。
- 测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。
- 测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，通过测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动中借鉴参考。
- 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。
- 测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确是否可用的结论。
- 测试报告的数据是真实的，每一条结论的得出是有评价依据的，不能是主观臆断的。
第2章 黑盒测试
一、填空题
1、等价类
2、有效等价类、无效等价类
3、边界值法
4、恒等
5、异、或、唯一、要求
6、条件桩、条件项、动作桩、动作项
二、判断题
1、F 解析：无效等价类也可以捕获程序缺陷。
2、F 解析：此种情况可以划分三个等价类，一个有效等价类（取值范围），两个无效等价类（取值范围两边的值）。
3、F
4、T
5、T
6、T
三、选择题
1、A 解析：恒等是输入与输出之间的关系。
2、C
3、D
四、简答题
1、等价类划分原则：
（1）如果程序要求输入值是一个有限区间的值，则可以将输入数据划分为一个有效等价类和两个无效等价类，有效等价类为指定的取值区间，两个无效等价类分别为有限区间两边的值。
（2）如果程序要求输入的值是一个“必须成立”的情况，则可以将输入数据划分为一个有效等价类和一个无效等价类。
（3）如果程序要求输入数据是一组可能的值，或者要求输入值必须符合某个条件，则可以将输入数据划分一个有效等价类和一个无效等价类。
（4）如果在某一个等价类中，每个输入数据在程序中的处理方式都不相同，则应将该等价类划分成更小的等价类，并建立等价表。
2、在实际测试中，条件桩往往很多，而且每个条件桩都有真假两个条件项，有n个条件桩的决策表就会有2n条件规则，有些规则的取值对结果并无影响，这个问题就称为无关条件项，无关条件项使用“-”表示，忽略无关条件项，可以将这两条规则进行合并。合并之后的无关条件项（-）包含其他条件项取值，因此具有相同动作的规则还可进一步合并
3、正交实验设计法测试用例设计步骤。
（1）提取因子，构造因子状态表
分析软件的规格需求说明得到影响软件功能的因子，确定因子可以有哪些取值，即确定因子的状态。
（2）加权筛选，简化因子-状态表
在实际软件测试中，软件的因子及因子的状态会有很多，每个因子及其状态对软件的作用也大不相同，如果把这些因子及状态都划分到因子-状态表中，则最后生成的测试用例会相当庞大，从而影响软件测试的效率。因此需要根据因子及状态的重要程度进行加权筛选，选出重要的因子与状态，简化因子-状态表。
加权筛选就是根据因子或状态的重要程度、出现频率等因素计算因子和状态的权值，权值越大，表明因子或状态越重要，而权值越小，表明因子或状态的重要性越小。加权筛选之后，可以去掉一部分权值较小的因子或状态，使得最后生成的的测试用例集缩减到允许的范围。
（3）构建正交表，设计测试用例
正交表的表示形式为Ln（tc）来表示。
- L表示正交表。
- n为正交表的行数，正交表的每一行可以设计一个测试用例，因此行数n也表示可以设计的测试用例的数目。
- c表示正交实验的因子数目，即正交表的列数，因此正交表是一个n行c列的表。
- t称为水平数，表示每个因子能够取得的最大值，即因子有多少个状态。
第3章 白盒测试
一、填空题
1、执行语句
2、判定覆盖
3、条件覆盖
4、判定-条件
5、条件覆盖
6、探针
二、判断题
1、T
2、F 解析：目标代码插桩是往二进制程序中插入代码，二进制程序是已经经过编译、链接后的代码。
3、F
4、T
5、T 解析：使用同一种编程语言编写的程序与探针，则探针可能通用。
三、选择题
1、D
2、C 解析：条件组合覆盖考虑到了每个逻辑条件的取值的所有组合情况。
3、C 解析：源代码插桩中，桩代码会一起参与编译、链接，因此插桩法会导致代码膨胀。
四、简答题
1、请简述一下逻辑覆盖的几种方法及它们之间的区别。
（1）语句覆盖
语句覆盖是最常见的覆盖方式。语句覆盖的目的是测试程序中的代码是否被执行，它只测试代码中的执行语句，这里的执行语句不包括头文件、注释、空行等。语句覆盖在多分支的程序中，只能覆盖某一条路径，使得该路径中的每一个语句至少被执行一次，但不会考虑各种分支组合情况。
（2）判定覆盖
判定覆盖(Decision Coverage)又称为分支覆盖，其原则是设计足够多的测试用例，在测试过程中保证每个判定至少有一次为真值，有一次为假值。判定覆盖的作用是使真假分支均被执行，虽然判定覆盖比语句覆盖测试能力强，但仍然具有和语句覆盖一样的单一性。
判定覆盖语句一般是由多个逻辑条件组成，如果仅仅判断测试程序执行的最终结果而忽略每个条件的取值，必然会遗漏部分测试路径，因此，判定覆盖也属于弱覆盖。
（3）判定-条件覆盖
判定-条件覆盖(Condition/Decision Coverage)要求设计足够多的测试用例，使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次，例如，对于判定语句if(a>1 AND c<1)，该判定语句有a>1、c<1两个条件，则在设计测试用例时，要保证a>1、c<1两个条件取“真”、“假”值至少一次，同时，判定语句if(a>1 AND c<1)取“真”、“假”也至少出现一次。这就是判定-条件覆盖，它弥补了判定覆盖和条件覆盖的不足之处。
相比于条件覆盖、判定覆盖，判定-条件覆盖弥补了两者的不足之处，但是由于判定-条件覆盖没有考虑判定语句与条件判断的组合情况，其覆盖范围并没有比条件覆盖扩展，因此判定-条件覆盖在仍旧存在遗漏测试的情况。
（4）条件组合覆盖
条件组合(Multiple Condition Coverage)指的是设计足够多的测试用例，使判定语句中每个条件的所有可能至少出现一次，并且每个判定语句本身的判定结果也至少出现一次。它与判定-条件覆盖的差别是，条件组合覆盖不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。
2、请简述一下目标代码插桩的三种执行模式。
目标代码插桩具有以下三种执行模式:
（1）即时模式（Just-In-Time）：原始的二进制或可执行文件没有被修改或执行，将修改部分的二进制代码生成文件副本存储在新的内存区域中，在测试时仅执行修改部分的目标代码。
（2）解释模式（Interpretation Mode）：在解释模式中目标代码被视为数据，测试人员插入的测试代码作为目标代码指令的解释语言，每当执行一条目标代码指令，程序就会在测试代码中查找并执行相应的替代指令，测试通过替代指令的执行信息就可以获取程序的运行信息。
（3）探测模式（Probe Mode）：探测模式使用新指令覆盖旧指令进行测试，这种模式在某些体系结构（如x86）中比较好用。
第4章 性能测试
一、填空题
1、单位时间
2、每秒钟
3、负载测试
4、HTTP
5、容量测试
6、Vugen、Controller、Analysis
二、判断题
1、T
2、F 解析：吞吐量的单位并不唯一，它可以是请求数/秒、访问人数/天等。
3、T
4、T
5、T
6、F 解析：压力测试是逐步加压，峰值测试是瞬间加压。
三、单选题
1、D
2、C
3、D
4、A
5、C 解析：Jemeter使用采样器记录服务器的响应。
四、简答题
1、常用的性能测试指标。
（1）响应时间
响应时间（Response Time）是指系统对用户请求作出响应所需要的时间。这个时间是指用户从软件客户端发出请求到用户接收到返回数据的整个过程所需要的时间，包括各种中间件（如服务器、数据库等）的处理时间。
（2）吞吐量
吞吐量（Throughput）是指单位时间内系统能够完成的工作量，它衡量的是软件系统服务器的处理能力。吞吐量的度量单位可以是请求数/秒、页面数/秒、访问人数/天、处理业务数/小时等。
（3）并发用户数
并发用户数是指同一时间请求和访问的用户数量。例如对于某一软件，同时有100个用户请求登录，则其并发用户数就是100。并发用户数量越大，对系统的性能影响越大，并发用户数量较大可能会导致系统响应变慢、系统不稳定等。软件系统在设计时必须要考虑并发访问的情况，测试工程师在进行性能测试时也必须进行并发访问的测试。
（4）TPS
TPS是指系统每秒钟能够处理的事务和交易的数量，它是衡量系统处理能力的重要指标。
（5）点击率
点击率是指用户每秒向Web服务器提交的HTTP请求数，这个指标是Web应用特有的一个性能指标，通过点击率可以评估用户产生的负载量，并且可以判断系统是否稳定。点击率只是一个参考指标，帮助衡量Web服务器的性能。
（6）资源利用率
资源利用率是指软件对系统资源的使用情况，包括CPU利用率、内存利用率、磁盘利用率等，资源利用率是分析软件性能瓶颈的重要参数。
2、常见的性能测试种类。
（1）负载测试
负载测试是指逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能够承受的最大负载量。
（2）压力测试
压力测试也叫强度测试，它是指逐步给系统增加压力，测试系统的性能变化，使系统某些资源达到饱和或系统崩溃，从而确定系统所能承受的最大压力。
（3）峰值测试
性能测试中还有一种压力测试叫作峰值测试，它是指瞬间（不是逐步加压）将系统压力加载到最大，使测试软件系统在极限压力下的运行情况。
（4）配置测试
配置测试是指调整软件系统的软硬件环境，测试各种环境对系统性能的影响，从而找到系统各项资源的最优分配原则。配置测试不改变代码，只改变软硬件配置，例如安装版本更高的数据库、配置性能更好的CPU、内存等，通过更改外部配置来提高软件的性能。
（5）可靠性测试
可靠性测试是指给系统加载一定的业务压力，使其持续运行一段时间（如7*24h），测试系统在这种条件下是否能够稳定运行。由于加载有业务压力且运行时间较长，因此可靠性测试通常可以检测出系统是否有内存泄露等问题。
（6）容量测试
容量测试是指在一定的软硬件及网络环境下，测试系统所能支持的最大用户数、最大存储量等。容量测试通常与数据库、系统资源（如CPU、内存、磁盘等）有关，用于规划将来需求增长（如用户增长、业务量增加等）时，对数据库和系统资源的优化。
3、LoadRunner的组成部分及其作用。
（1）VuGen
LoadRunner是通过多个虚拟用户在系统中同时工作或访问系统的环境来进行性能测试的，虚拟用户进行的操作通常被记录在虚拟用户脚本中，而VuGen就是用于创建虚拟用户脚本的工具，因此它也称为虚拟用户脚本生成器。
在创建脚本时，VuGen会生成多个函数用于记录虚拟用户所执行的操作，并将这些函数插入到VuGen编辑器生成基本的虚拟用户脚本，这个创建脚本的过程也叫作录制脚本。
（2）Controller
Controller用于创建和控制LoadRunner场景，场景负责定义每次测试中发生的事件，包括模拟的用户数、用户执行的操作以及测试要监控的性能指标等。
（3）Analysis
Analysis是LoadRunner的数据分析工具，它可以收集性能测试中的各种数据，对其进行分析并生成图表和报告供测试人员查看。
第5章 安全测试
一、填空题
1、安全隐患
2、应用层
3、HTML代码、Javascript
二、判断题
1、T
2、T
3、T
4、F 解析：XSS攻击是盗取用户信息伪装成用户访问网站；CSRF是通过用户非法访问网站。
5、F
三、选择题
1、C
2、D
3、A
4、C
5、B
四、简答题
1、安全测试与常规测试的区别。
（1）测试目标不同
普通测试以发现BUG为目标；安全测试以发现安全隐患为目标。
（2）假设条件不同
普通测试假设导致问题的数据是用户不小心造成的，接口一般只考虑用户界面；安全测试假设导致问题的数据是攻击者处心积虑构造的，需要考虑所有可能的攻击途径。
（3）思考域不同
普通测试以系统所具有的功能为思考域；安全测试的思考域不但包括系统的功能，还有系统的机制、外部环境、应用与数据自身安全风险与安全属性等。
（4）问题发现模式不同
普通测试以违反功能定义为判断依据；安全测试以违反权限与能力的约束为判断依据。
2、安全测试基本原则。
（1）培养正确的思维方式
安全测试人员则要有创造性性思维，创造性思维能够帮助我们站在攻击者角度思考各种无法预期的情况，同时能够帮助我们猜测开发人员是如何开发的，如何绕过程序防护逻辑，以某种不安全的行为模式导致程序失效。
（2）尽量测试和经常测试
安全性缺陷和普通Bug没什么区别，越早发现修复成本越低；发人员最好能够意识到新产生的安全漏洞对正在开发的软件的影响，测试人员要转变思维方式，从攻击者角度的各个细节测试应用程序，使软件更加安全。
（3）选择正确的测试工具
很多情况下安全测试需要模拟黑客的行为对软件系统发起攻击，以确保软件系统具备稳固的防御能力。模拟黑客行为就要求安全测试人员擅长使用各种工具，如漏洞扫描工具、模拟数据流行为的前后台相关工具、数据包抓取工具等。现在市面上提供了很多安全扫描器或者应用防火墙工具可以自动完成许多日常安全任务，但是这些工具并不是万能的。作为测试人员，我们要准确了解这些工具能做什么，不能做什么是非常重要的，切不可过分夸大或者不当使用测试工具。
（4）可能情况下使用源代码
在做渗透测试时，如果使用黑盒测试方法，需要大量测试用例进行覆盖，且测试完成后仍无法确定软件是否仍然存在风险。使用白盒测试方法，借助扫描工具对源代码进行扫描，一方面可以找出潜在的风险，从内对软件进行检测，提高代码的安全性；另一方面也可以进一步提高代码的质量。
（5）测试结果文档化
测试总结的时候，明智且有效的做法是将测试行动和结果清晰准确地记录在文档中，产生一份测试报告。一份好的测试报告应该帮助开发人员准确定位软件安全漏洞，从而有效进行漏洞修补，使软件更安全可靠。
3、XSS攻击原理、过程及防范措施。
XSS是Web应用系统最常见的安全漏洞之一，它主要源于Web应用程序对用户输入检查和过滤不足。攻击者可以利用XSS漏洞把恶意代码（HTML代码或javascript脚本）注入到网站中，当有用户浏览该网站时，这些恶意代码就会被执行，从而达到攻击的目的。
通常，在XSS攻击中，攻击者会通过邮件或其他方式诱使用户点击包含恶意代码的链接，例如攻击者通过E-mail向用户发送一个包含恶意代码的网站home.com，用户点击链接后，浏览器会在用户毫不知情的情况下执行链接中包含的恶意代码，将用户与home.com交互的cookie和session等信息发送给攻击者，攻击者拿到这些数据之后，就会伪装成用户与真正的网站进行会话，从事非法活动。
对于XSS漏洞，最核心的防御措施就是对用户的输入进行检查和过滤，包括URL、查询关键字、HTTP头、POST数据等，仅接受指定长度范围、格式适当、符合预期的内容，对其他不符合预期的内容一律进行过滤。除此之外，当向HTML标签或属性中插入不可信数据时，要对这些数据进行进行相应的编码处理。将重要的cookie标记为http only，这样javascript脚本就不能访问这个cookie，避免了攻击者利用javascript脚本获取cookie。
第6章 自动化测试
一、填空题
1、项目需求变动不频繁、项目周期足够长、自动化测试脚本可重复使用
2、UI测试、接口测试、单元测试
3、录制与回放、脚本测试、数据驱动测试
4、功能函数、类（参见白盒测试章节小提示部分）
5、线性脚本、结构化脚本、共享脚本
6、Selenium IDE、Selenium Grid、Selenium RC
7、class、xpath、link text
二、判断题
1、T
2、F 解析：回归测试需要对项目进行全面测试
3、F
4、F
5、T
6、T 解析：关于持续集成可查阅DevOps相关资料进行学习
三、选择题
1、D 解析：参见本章案例讲解，可以通过Appium修改UI布局进行测试
2、A
3、C
4、C 解析：持续集成需要测试人员进行调度，参见持续集成测试框架设计图
5、C
6、D 解析：自动化测试同样需要人与人之间的沟通与协作才能做到最优化
四、简答题
1、请简述持续集成的基本过程。
参见持续集成过程流程图，持续集成需要版本控制工具、持续集成工具、持续集成环境部署、基础测试、阶段性测试。一旦持续集成环境搭建完成后测试人员通过集成工具获取项目代码，进行基本测试或执行相关的测试用例，得到最初的测试结果。
2、请简述传统持续集成框架和持续集成容器的区别。
参见持续集成框架设计流程图。在传统持续集成框架下进行测试之需要搭建代码托管平台（Git、GitLab等）或者使用本地项目，准备好测试所需要的数据以及当前项目需要的服务器、测试用例等。对于持续集成容器化进行测试需要测试人员搭建容器环境、管理容器仓库等操作，搭建环境比传统持续集成测试搭建相对复杂但提高了项目部署效率以及不同场景下测试的便捷。
3、请简述自动化测试使用的技术。
参见自动化测试常见的技术，在回答中提及测试技术使用的测试工具。自动化测试技术可分为录制与回放技术，使用录制回放工具可以将操作过程录制下来通过回放观察是否存在问题，录制工具如Loadrunner、UFT、Selenium及其衍生工具等；脚本测试可分为线性脚本、结构化脚本、共享脚本，在测试中可以使用自动化测试框架Junit、Unittest框架进行编写或者参考脚本录制回放工具生成的脚本进行测试；数据驱动测试分为关键字驱动测试、行为驱动测试，这两种测试的区别是针对数据操作对象和测试场景进行划分，工具如Loadrunner、Katalon等。
第7章 移动App测试
一、填空题
1、iOS、Android
2、安装测试、卸载测试、升级测试、弱网测试、耗电量测试（写出任意三个即可）
3、移动原生应用、移动Web应用、混合应用
二、判断题
1、F 解析：移动App不止运行在手机上，还包括平板、智能手表、穿戴设备等移动终端。
2、F
3、T
4、T
5、F 解析：Appium使用Webdriver协议驱动设备。
6、F
7、T
三、选择题
1、C
2、B
3、D
四、简答题
1、移动App及其与传统软件的区别。
移动App（移动Application，移动应用服务）是针对手机、平板等移动连接到互联网的业务或者无线网卡业务而开发的应用程序。
移动App与传统软件的区别主要有以下几点：
- 设备多样性
- 网络多样性
- 平台多样性
2、移动App的专项测试。
（1）安装测试
移动App安装渠道较多，要对每一个渠道安装进行测试；移动设备比较多，需要对各个型号的移动设备进行安装测试；移动App在安装过程中是否可以取消安装，取消安装过程是否与App概要设计描述一致；移动App安装过程出现意外情况，其处理过程是否与App概要设计描述一致；移动设备空间不足是否有相应处理措施；安装过程是否有进度条提示；安装完成，App是否能正常运行。
（2）卸载测试
卸载App时是否有提示信息；卸载过程出现意外情况，其处理过程是否与App概要设计描述一致；卸载过程是否有进度条提示；卸载完成，App相应文件的处理是否与概要设计描述一致。
（3）升级测试
升级测试需要在已经安装App的基础上进行，如果有软件更新，打开App时需要有提示信息；升级包下载过程中断处理是否与概要设计描述一致；多种升级渠道都需要进行测试；测试不同操作系统，软件升级是否都能顺利通过。
（4）交互性测试
移动设备大多具有电话、短信、蓝牙、手电筒等功能，在使用App时难免会受到干扰，例如使用App时，如果需要拨打/接听电话、启动蓝牙、相机、手电筒等，App要做好相应的处理措施，确保App不会产生功能性错误。
（5）弱网测试
移动App使用移动网络，移动网络的情况比较复杂，网络信号会受到环境的影响，容易发生网络不稳定的情况，而很多App的一些隐藏问题只有在复杂的网络环境下才会显现出来，例如正在使用的App遇到网络信号切换或变弱时，App不能响应或产生功能性错误，因此在测试时要特别对App进行弱网测试，及早发现问题。
（6）耗电量测试
移动设备电量一直是困扰用户的一个问题，同时也是移动设备发展的一个瓶颈，如果App架构设计不好，或者代码有缺陷，就可能导致电量消耗比较高，因此App耗电量测试也很重要。如果App耗电量较高，改进App在电量不足的情况下，让App释放掉一部分性能以节省电量。
3、移动App与传统软件测试的区别。
比较移动App测试与传统软件测试的不同，要从以下几个方面进行考虑。
（1）页面布局不同
对于传统软件，计算机设备屏幕比较大，可以同时显示很多信息，用户在使用时对所有信息一览无余，页面布局比较灵活，但是对于移动App，移动设备屏幕小，显示的信息有限，一般都是单列显示，在测试时需要考虑布局是否合理。此外，在测试时还要考虑到移动设备的屏幕可以旋转，旋转之后，屏幕上信息显示是否符合用户需求。
（2）使用场合不同
传统软件使用地点比较固定，网络信号也比较稳定，而移动App使用场合不固定，网络信号也不稳定，测试需要考虑弱网情况下App的使用情况。此外，还要考虑移动设备电量不足的情况下，App是否能正常使用。
（3）输入方法不同
传统软件大多使用键盘和鼠标进行输入，移动App的输入方法比较多，除了键盘和鼠标之外，还包括触屏、电容笔、语音等，移动App测试时要测试多种输入方法是否都能正常使用。
（4）操作方式不同
传统软件使用鼠标操作，点击精确，而移动App大多是触屏操作，点击时误差较大，且不支持“鼠标”悬停事件。
