一，前言
1，软件测试为什么变得更困难：
因为大量的编程语言，操作系统以及硬件平台的涌现
2，某些方面而言，软件测试变得容易：
因为大量的软件及操作系统比以往更加复杂，内部提供了很多已充分测试过的例程供应用程序集成，无需程序员从头设计
3，所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。
------------------------------------------------------------------------------------------------------------------------------
二，软件测试的心理学和经济学
2.1软件测试的心理学
人类行为总是倾向于具有高度目标性，确立一个正确的目标有着重要的影响。
1.我们每当要测试一个程序时，应当想到要为程序增加一些价值。而通过测试来增加程序的价值是指提高程序的可靠性或质量，提高可靠性是指找出并最终修改程序的错误。
2.定义：测试是为发现错误而执行程序的过程
3，成功的测试用例：
1）测试时发现了错误，就将这次合理设计并得到有效执行的测试成为成功
2）如果本次测试可以最终确定再无其他可查出的错误，也称为成功
不成功的测试：仅指未能适当的对程序进行检查（如同效等价类）
4，软件测试更适宜被视为试图发现程序中错误（假设其存在）的破坏性的过程。软件做了其应该做的，未做其不应该做的。
2.2软件测试的经济学
1. 黑盒测试又被称为数据驱动的测试或输入/输出驱动的测试。穷举测试用例不可能实现。
2.测试投入的目标在于通过有限的测试用例，最大限度地提高发现问题的数量，以取得好的测试效果。
3.白盒测试又称为逻辑驱动的测试。穷举路径测试也不可能实现
4.穷举路径测试也并非是完全的测试。第一，即使穷举，也不能保证程序符合其设计规范，比如编写升序排序却写成降序。第二，程序可能会因为缺少某些路径而存在问题。第三，穷举路径测试可能不会暴露数据敏感错误。
2.3软件测试的原则
1.测试用例中一个必须部分是对预期输出或结果的定义。
测试用例包含两个部分：1）对程序输入数据的描述；2）对程序在上述输入数据下的正确输出结果的精确描述。
2.程序员应当避免测试自己编写的程序。
3.编写软件的组织部应当测试自己的编写的软件。
4.应当彻底检查每个测试的结果。
5.测试用例的编写不仅应当根据有效和预期的输入情况，而且也应当根据无效和未预料到的输入情况。
6.检查程序是否“未做其应该做的”仅是测试的一般，测试的另一半是检查程序是否“做了不应该做的”。
7.应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。
对程序的更改容易导致程序先前可以执行的部分发生故障，而这种故障是不容易被发现的，保留测试用例用作回归测试。
8.计划测试工作时不应默许假定不会发现错误。
9.程序某部分存在更多错误的可能性与该部分已发现错误的数量成正比。
10.软件测试是一项极富创造性，极具智力挑战的工作。
------------------------------------------------------------------------------------------------------------------------------
三，代码检查，走查与评审
代码检查，走查以及可用性测试是三种主要的人工测试方法
3.1 代码检查与走查
1.代码检查和走查都需要人们组成一个小组来阅读或者直观检查特定的程序，进行头脑风暴，目标是找出错误，但不是改正错误。换句话说是测试而不是调试。
2.代码走查的另一个优点是一旦发现错误通常就能在代码中对其进行精确定位，这就降低了调试的成本。
3.代码检查和走查通常会有效的查出30%-70%的逻辑设计和编码错误，和基于计算机的测试是互补的。
3.2 代码检查
1.通常四个人：协调人员（非编码人员），编码人员，测试专家等。
2.代码检查要将注意力集中在发现错误上，而不是纠正错误。
3.对事不对人
4.代码检查可以提升编程人员的编码技术；可以提早发现程序中脆弱部分，提醒测试注意
5.代码检查错误列表：
数据引用错误、：如引用未赋值；引用越界；引用生命周期失效
数据声明错误、：变量未明确声明；变量未明确定义数据类型，长度等；
运算错误、：运算过程中是否溢出；运算结果是否不精确（如10*0.1很少会等于1.0）；操作符顺序是否正确；
比较错误、：运算符表达是否正确；是否有不同长度或不同数据类型比较
控制流错误、： 循环是否可与正确终止；循环是否越界；
接口错误、：形参与实参是否匹配；是否改变了形参；全局变量在模块间是否一致；
输入/输出错误、：文件使用后是否关闭；缓存大小与文件大小是否匹配；是否处理了I/O异常；
其他检查：是否对输入的合法性进行了检查；交叉引用列表中是否存在未引用过的变量；是否遗漏了某个功能；
3.3 代码走查
跟代码检查相似，但规程稍微不同，错误检查技术也不一样。
走查小组建议包括：一个经验丰富的程序员，一个程序设计语言专家，一个程序员新手（可以给出新颖不带偏见的观点），最终维护程序的人员，一位来自其他不同项目的人员，一位来自该软件编程小组的程序员。
由测试人员带一些书面的测试用例（程序或模块具有代表性的输入集及预期的输出集），在会议中进行推演，即把测试数据沿程序的逻辑结果走一遍，当然这些测试用例必须结构简单，数量较少
3.4 桌面检查
在提交测试前由程序员阅读自己程序的过程（也可以两个程序员交叉阅读）
一个人阅读程序，对照错误检查表检查程序，对程序推演测试数据。
3.5 同行评审
让程序员对自身的编程技术进行自我评价。
------------------------------------------------------------------------------------------------------------------------------
四，测试用例的设计
由于成本和时间的约束，软件测试最关心的问题是：在所有可能的测试用例中，哪个子集最有可能发现最多的错误？
我们推荐的步骤是先使用黑盒测试方法来设计测试用例，然后视情况需要使用白盒测试方法来设计补充的测试用例
4.1 白盒测试
白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。
逻辑覆盖测试：
1.语句覆盖：程序中的每条语句至少被执行一次。一般不用
2.判定（分支）覆盖：使得每一个判断都至少有一个为真和为假的输出结果。
3.条件覆盖：确保将一个判断中的每个条件的所有可能的结果至少执行一次。
4.判定/条件覆盖：将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。
5.多重条件覆盖：将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。
4.2 黑盒测试
黑盒测试（数据驱动或者输入/输出驱动的测试）基于程序规格说明书，黑盒测试的目标是找出程序不符合规格说明书的地方
1.等价类划分：确定等价类->生成测试用例。等价类划分是一个启发式的过程，需要根据实际情况进行划分，但一般情况下要划分为两个不同的组：有效等价类（对程序有效输入）和无效等价类（不正确的输入值）。(可以参考一些等价类划分的指导原则）
2.边界值分析：考虑边界值分析会获得更高的测试回报率。
1）与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试
2）边界值分析不仅要考虑输入空间的边界值，还要考虑输出空间的的边界值。（参考一些通用指南和规则）
3.因果图分析：因果图有助于用一个系统的方法选择出高效的测试用例集，还可以指出规格说明的不完整和不明确之处。是根据条件的组合生成测试用例的系统性的方法，将规格说明转换为一个布尔逻辑网络。
确定规格说明中的因果关系，因指一个明确的输入条件或输入条件的等价类，果指一个输出条件或系统转换（输入对程序或系统状态的延续影响）
4.错误猜测：利用直觉和经验猜测出错的可能类型，然后编写测试用例还暴露这些错误。
4.3 测试策略
1.如果规格说明里面包含条件组合的情况，应首先使用因果分析方法
2.在任何情况下都应该使用边界值分析方法，对输入和输出边界都要进行测试
3.应该为输入和输出确定有效和无效等价类，必要的情况下对上面的测试用例进行补充
4.使用错误猜测技术增加更多的测试用例
5.针对上述的测试用例集检查程序的逻辑结构，应考虑使用逻辑覆盖准则
------------------------------------------------------------------------------------------------------------------------------
五，模块（单元）测试
模块测试中测试用例的设计过程：使用一种或多种白盒测试方法分析模块的逻辑，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。它是大规模的白盒测试。
5.1 增量测试
非增量测试：单独测试每个模块，每个模块都要写驱动模块和桩模块（唯一好处：模块测试开始时间更早）
增量测试：先将下一个要测试的模块组装到前面已经测试过的模块集合中去； 如A被B调用，自底向上，先测试A，再测试B，要写两个驱动模块
1. 驱动模块：用来将测试用例驱动或传输到被测模块中。
2.桩模块：测试上层模块时用来模拟下层模块的的模块。
3.自顶向下测试：点：必须开发桩模 块，创建测试环境可能很难，甚至无法执行...
4.自底向上测试：缺点：必须开发驱动模块，直到最后一个模块添加进去，程序才形成一个整体。
5.2 工具
单元测试有很多测试用具，最出名的就是xUnit，这本书没讲。
------------------------------------------------------------------------------------------------------------------------------
六.更高级别的测试
当程序无法实现其最终用户要求的合理功能时，就发生了一个错误。
软件开发过程：最终用户-->需求（验收测试）-->目标（系统测试）-->外部规格说明书（功能测试）-->系统设计（集成测试）-->程序结果设计-->模块接口规格说明（模块测试）-->代码
根据软件开发的过程，对应的测试是模块测试、集成测试、功能测试、系统测试、验收测试和安装测试。
如：需求规格说明定义了为什么要开发程序
目标定义了程序要做什么，以及要做的怎样
外部规格说明定义了程序对用户的准确表现
与后续阶段相关的文档越来越详细的规定了程序是如何建立起来的
----------
模块测试的目的是发现程序模块与其接口规格说明之间的不一致
功能测试的目的是为了证明程序未能符合其外部规格说明
系统测试的目的是为了证明软件产品与其初始目标不一致
集成测试在进行增量模块测试时已经做了
6.1 功能测试
1.功能测试是一个试图发现程序与其外部规格说明之间存在不一致的过程。外部规格说明是一份从最终用户角度对程序行为的精确描述。
2.功能测试通常是一项黑盒操作，等价类划分，边界值分析，因果图分析和错误猜测很适合功能测试。
6.2 系统测试
系统测试目的：将系统或程序与其初始目标进行比较，也就是说比较程序、程序目标和用户文档之间的不一致性。
（将程序与其目标进行比较，是系统测试的核心目的，但是没有说明使用什么样的测试用例设计方法。因为目标文档阐述了程序应该做什么，做到什么程度，却没有说明程序功能如何表现）
1. 能力测试：逐条语句地检查目标文档，判断程序是否满足。（利用好问题清单）
2.容量测试：使程序经受大容量数据的检验。目的是为了证明程序不能处理目标文档中规定的数据容量。（考虑到该测试需要耗费大量的资源，所以不可进行过多的容量测试， 但每个程序至少应该进行几次容量测试）
3.强度测试：使程序承受高负载或强度的检验，所谓高强度是指在很短的时间间隔内达到的数据或操作的数量峰值。（有些也叫做压力测试）
4.可用性测试：又叫用户体验测试，通过发动最终用户在真是环境下对应用程序进行测试。
5.安全性测试：设计测试用例来突破程序安全检查的过程。
6.性能测试：测试软件在特定负载和配置环境下程序的响应时间和吞吐率不满足要求。
7.存储测试：设计测试用例来证明软件的存储目标（内存或辅助存储）没有达到。
8.配置测试：测试软件在不同配置环境下（操作系统，浏览器等）程序不同的反应。
9.兼容性/转换测试：测试软件在不同版本或者环境下的反应，评估新版本是否能兼容老的版本
10.安装测试：发现软件在安装过程中出现的各种问题，在不同平台上安装。
11.可靠性测试：可靠性测试是为了提高软件的可靠性，如果软件的目标中包含了对可靠性的特别描述，就必须设计专门的可靠性测试。如评估程序是否达到规格说明中的运行时长和平均故障间隔时间要求
12.可恢复性测试：证明系统的恢复机制不能够正确发挥作用。恢复机制是当系统发生故障时，如何从程序错误、硬件失效和数据错误中恢复过来。
13.服务/可维护性测试：测试软件的服务和可维护性目标。如评估系统是否拥有良好的数据处理和日志机制，以备技术支持和调试之需
14.文档测试：检车用户文档的正确性，主要方法是根据文档来确定系统测试用例的形式，用户文档作为审查的对象。
15.过程测试：对已规定的人工过程（如系统操作员、数据库管理员或最终用户的操作过程进行测试），如上线流程测试，切换过程测试
16.系统测试的执行：不能由程序员来进行测试；不能由该程序开发的机构来执行测试。执行系统测试的人思考问题的方式必须与最终用户相同，必须充分了解最终用户的态度和应用环境以及程序的使用方式。
6.3验收测试
将程序与其最初的需求及最终用户当前的需要进行比较的过程。通常由程序的客户或最终用户来进行，但明智的开发者会引导客户在开发过程和产品发布之前进行用户测试。
6.4测试的计划与控制
一个良好的测试计划应该包括：目标、结束准则、进度、责任、测试用例库及标准、工具、计算机时间、硬件配置、集成、跟踪步骤、调试步骤、回归测试。（即测试计划+测试方案）
6.5测试结束准则
1.(不是最佳)
模块测试的结束准则:(1)满足多重条件覆盖准则，(2)对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。
功能测试的结束准则：(1)因果图分析，(2)边界值分析，(3)错误猜测，产生的所有测试用例最终都是不成功的。
2.(也许是最有价值的准则)以确切的数量来描述结束测试的条件。（预测程序中错误的总数量）
3.(涉及到许多判断和直觉)在测试过程中记录每个单位时间内发现的错误的数量，通过检查统计曲线的形状，常常可以决定究竟是继续该阶段的测试还是结束它并来时下一测试阶段。（发现的错误数下降至0）
最佳的可能是三种的组合。
------------------------------------------------------------------------------------------------------------------------------
七.可用性（用户体验）测试
7.1可用性测试的基本要素
1.是否考虑到最终用户的理解力、教育背景以及环境压力。
2.程序的输出是否有意义、没有侮辱性的词语以及是否含糊不清？
3.错误诊断的提示信息是否清晰易懂还是需要计算机博士才可读懂？
4.用户界面上是否保持与概念一致、内部的连贯性、语法的一致性？是否符合约定的使用习惯/语义和句法规律、格式、样式以及缩写习惯？
5.需要高精确性和准确度的软件系统是否提供足够有效的输入验证？（如银行系统需要输入密码）
6.系统是不是包含了太多选项或者包含的一些选项不会被使用，是不是符合人的思维和逻辑？（精简选项）
7.对于来自用户的输入，系统是否能够及时做出反应？（如果不及时，需要告知用户等待）比如鼠标点击会不会表现出被按压/弹起的状态。
8.程序的操作是否很容易上手？（操作层级不要过深，有效的操作提示）
9.软件的设计是否有助于用户准确输入？（哪些操作用户可避免出错，哪些操作会系统异常）
10.用户的操作可以轻松重复吗吗？（软件具有可学习性）
11.用户是否确定能够在众多的功能和菜单中来回切换而不发生意外？用户会不会推荐给其他用户？
12.软件的功能实现是否达到了设计的规格要求？
可用性测试基本上属于黑盒测试的范畴。用户可用性测试应该从功能缺陷到不符合人机工程学的设计失误来揭示软件设计存在的问题
7.2可用性测试流程
1.测试用户的选择：需要同一组用户完成多个测试以及不同组用户完成多个测试。有经验的测试专家以及外行人，合理性选择。有时候局外人或许可以给出不一样的见解。
2.需要多少用户进行测试：并不是越多越好，是情况而定，主要原则就是用最少的成本达到最高的测试回报。（3-5人）
3.数据采集方法：录制测试过程并使用“发声思考”可以很好的记录可用性测试数据以及用户对软件的使用感受。“眼球追踪”技术很复杂但却很有用，可以使用在武器导航，机器人控制，车辆控制以及其他队速读和响应有特别要求的系统。
4.可用性调查问卷：可以学学问卷调查设计技巧，一个原则：尽量不要让用户做过主观的回答，减少用户输入。主要采取三个形式：是否问题/真假问题/某种程度的同意反对；测试量大，参与用户多的大型可用性测试，使用统计分析软件往往能发现人工方法不容易发现的趋势
5.何时收工：没有一定的原则，根据经验来看，对测试结果进行仔细分析和总结。
最后可用性测试结果和数据要转变为开发人员能够读懂的修改意见，修改后给原测试者，确认是否实现了改进意图，这可能是一个需要反复验证迭代的过程
------------------------------------------------------------------------------------------------------------------------------
八，调试
调试是执行一次成功的测试之后所要进行的工作。（成功的测试是指证明程序没有完成预期的功能）
调试步骤：1）定位错误 2）修改错误
8.1 调试方法
1.蛮力法调试：
1）利用内存信息输出来调试
2）根据一般的“在程序中插入打印语句”建议来调试、
3）使用自动化的调试工具（断点debug）。
蛮力法调试忽略了思考的过程，效率比较低下。
因此建议只在两种情况下使用：1）其他方法都失败了 2）作为思考过程的补充
2.归纳法调试：从细节转到全局，从线索出发，寻找线索之间的联系。步骤如下：确定相关数据->组织数据->研究数据间联系->做出假设->证明假设>解决问题
3.演绎法调试：从一些普遍的理论或前提出发，使用排除和精炼的过程，达到一个结论。步骤如下：列举出所有可能的原因或假设->利用数据排除可能的原因->提炼剩下的假设->证明剩下的假设->修复问题。其中有一个循环的过程。
4.回溯法调试：沿着程序的逻辑结构回溯不正确的结果，直到找出程序逻辑出错的位置。
5.测试法调试：当发现了某个被怀疑的错误的症状之后，我们需要编写与原先有所变化的测试用例，尽量确定错误的位置。
8.2 调试的原则
1.定位错误的原则：动脑筋/遇到僵局留到稍后解决/遇到问题把问题描述给其他人听/仅将调试工具作为第二种手段/避免能使用实验法-仅将其作为最后的手段
2.修改错误的技术：存在一个缺陷的地方有可能还存在其他缺陷；/应纠正错误本身而非其症状；/正确纠正错误的可能性并非100%；/随着程序规模的增加正确修改错误的可能性反而降低；/应该意识到纠正错误会引入新错误的可能性（回归测试的重要性）/修改错误的过程也是临时回到设计阶段的过程（如修改错误也需要进行代码检查等）/应修改源代码而不是目标代码。
3，错误分析：错误出现在什么地方？/ 谁制造了这个错误？/代码哪些做的不正确？ /如何避免该错误出现？/为什么错误没有早些发现？ /该如何更早的发下错误？（设计更多成功的测试用例）
------------------------------------------------------------------------------------------------------------------------------
九，敏捷开发模式下的测试
9.1 敏捷开发的特征：依赖客户参与；测试驱动；紧凑的迭代开发周期
敏捷开发方法列要：
方法 描述
敏捷建模： 不是一种建模方法，而是一组建模以及文档化软件系统的原则和惯例，用以支撑其他
诸如极限编程和Scrum等敏捷方法
敏捷统一过程： 为敏捷量身定做的统一软件过程的精简版
动态系统开发方法：基于快速软件开发方法，依赖于客户的持续参与，使用迭代式和增量式的开发
模式，目标是软件能够在预算之内及时交付
核心统一过程： 有的放矢，只选择统一软件过程中那些适合当前项目的实践(如用例驱动和团队编程），
不管是否需要，核心统一过程通常使用所有实践
极限编程： 另一种迭代式和增量式的开发模式，非常强调并依赖单元测试和验收测试，
也许是最著名的敏捷方法
功能驱动开发： 使用工业界的最佳实践，以客户提供的功能需求为驱动，频繁发布小版本，
使用领域对象建模，以及组件功能团队
开放统一过程： 这种敏捷方法实现了标准的统一过程，采纳该方法的软件组能够做到快速开发其产品
Scrum： 一种迭代式和增量式的项目管理方法，支持多个敏捷开发模式
进度跟踪： 适用于所有的敏捷方法，用来度量敏捷开发的速度以及进度
9.2 敏捷测试
敏捷测试时协调测试的一种形式，它要求每一个人都参与到测试计划的设计，实现以及执行中去
快速软件开发需要更及时的反馈，敏捷测试依赖于自动化测试；尽管有些问题需要探索性的手工测试，但是人们更青睐于自动化测试
敏捷开发测试中，测试者不能仅仅把问题找出来并交给开发人员修复，他们的任务是通过持续的测试反馈推动项目前行，帮助开发者修复bug，改变需求设计以及其他的一般性质量提升
9.3 极限编程（XP）与测试
XP开发方法的目的是：短时间内开发高质量的程序
XP模型除了需要客户参与之外，还高度依赖模块的单元和验收测试；事实上，测试在XP中的地位非常重要，所以需要首先创建单元（模块）测试和验收测试，然后才能创建代码库，这种形式的测试称为极限测试
9.3.1 极限编程基础
XP的关注点：
1）实现简单的设计
2）开发人员与客户的沟通协作
3）不断的测试代码库
4）重构以使用规格说明的变更
5）寻求用户的反馈
XP的实践：
1）计划与需求分析：程序员估算开发时间，客户根据估算时间选择更有价值的功能
2）小规模，递增的发布
3）系统隐喻，按标准编码：建立命名规则和程序流程，按标准编码
4）简要设计：实现最简单的设计，使代码通过单元测试
5）连续测试：在编写模块之前就生成单元测试用例。模块只有在通过单元测试之后才算完成。此外，程序只有在通过了所有的单元测试和验收测试完成才算结束
6）重构：清理和调整代码库。单宜安测试有助于确保此过程中不破坏程序的功能。应在任何重构之后重新执行所有的单元测试
7）结对编程：两个程序员协同工作，在同一台机器上开发代码库。这样可以对代码进行实时检查，极大的提高缺陷的发现率和纠正率
8）代码的集体所有权
9）持续集成：经过单元测试的代码集成到代码库
10）客户在现场
极限测试：使用黑盒测试的方法编写测试用例，针对模块去编写单元测试用例验证模块的功能性
------------------------------------------------------------------------------------------------------------------------------
十，互联网应用测试
10.1 web服务的基本结构
表示层：提供GUI（图形用户接口）
业务层：模拟业务流程，功能包括事务处理，用户身份鉴定，数据确认，程序日志等
数据层：存储供应用系统使用的或从最终用户收集来的数据
10.2 测试的挑战
1）用户群庞大且五花八门
2）业务环境，考虑业务场景
3）用户地点
4）安全性
5）测试环境
表示层，业务层和数据层测试的例子：
表示层：不同浏览器测试；检查图像以确保分辨率和大小正确；检查交互性操作的用户友好度和体验一致性；检查行业特定术语与风格使用
业务层：确保提出的响应时间，吞吐率等性能指标得到了满足；验证事务正确完成；确保失败事务回滚正确；确保正确采集数据
数据层：确保数据库操作满足性能要求；验证数据存储适当且正确；验证可使用当前备份来恢复；测试故障处理和冗余功能；测试数据加密和安全性；测试后端数据输入与管理功能的可用性和准确性
10.3 测试的策略
测试内容： 可用性/人机界面；性能；业务规则；事务准确性；数据的有效性与完整性；系统可靠性；网络结构
表示层的测试
1）内容测试：包括整体审美，字体，色彩，拼写，内容准确性和默认值
2）web站点结构：包含无效的连接或图片
3）用户环境：包含web浏览器版本和操作系统配置
如果应用高度依赖客户端的脚本处理，用户环境测试就变得更加复杂。每一个浏览器都有不同的脚本引擎或虚拟机在客户计算机上运行脚本和代码。如果使用了以下任意一项，就应特别关注浏览器的兼容性问题：ActiveX控件,HTML5,JavaScript,Adobe Flash,VBS cript,PHP,Java applets
业务层测试：
1）性能：测试目的在于检查应用系统是否满足书面的性能规格说明（通常定义为响应时间和吞吐率）
2）数据有效性：测试的目的在于发现从客户那里采集到的数据中的错误
3）事务：测试的目的在于发现事务处理过程中的错误
数据层测试：
1）响应实践：应量化结构化查询语言SQL语句的消耗时间
2）数据完整性：验证数据存储适当且正确
3）容错性和可恢复性：最大化MTBF，最小化MTTR（出错间隔时间长，恢复时间短），有故障处理机制
------------------------------------------------------------------------------------------------------------------------------
十一，移动应用测试
11.1 移动环境下测试设计需要考虑的因素
1）连接：设备硬件配置，网络速度，网络延时，偏远地区网络可用性，服务可靠性
2）设备多样性：需要测试的众多浏览器，针对不同语言的运行库版本
3）设备的各种限制：有限的处理器和内存资源，小型屏幕尺寸，多操作系统，对多任务应用的支持能力，数据缓存大小
4）输入设备：触摸屏，触摸笔，鼠标，按键，滚球
5）安装和维护：安装和卸载，打补丁包，升级
11.2 测试面临的挑战
11.2.1 移动设备多样性
操作系统，浏览器，应用程序运行时环境，屏幕分辨率，人机交互界面和接口，人体工程学设计，屏幕尺寸这些因素的复杂多样性造成了设备多样性
在模拟器上知识模拟仿真，不是真实的设备。例如按钮和输入框的颜色和形状在模拟器上通过了验收测试，但是在真机上却失败了，失败的原因是真机和基于PC的模拟器具有不同的色深和屏幕分辨率
因此在需求收集过程中，就需要挑选出可以作为程序的目标支持机型，用它来测试
11.2.2 运营商网络基础设施
设备是否能够连上不同运营商，不同国家地区的网络，弱网环境
11.2.3 脚本编程
创建和执行自动化测试脚本
11.2.4 可用性测试
需要测试更多的移动设备平台
11.3 测试方法
移动应用测试分类：
1）安装/卸载
2）网络基础设施：应用程序在网络丢失的情况下正确响应；应用程序能够正确响应网络恢复的情况；应用程序能够在网络差的情况下正确响应
3）来电和短信处理
4）内存不足
5）按键：按键事件与产品规格书一致
6）退出：能正常退出
7）充电
8）电量：低电量下运行；应用程序耗电情况；
9）硬件资源：是否过度占用CPU，内存等资源
真机测试
优点：
1）能够测试应用程序真实的性能和响应
2）检查应用运行在不同真实设备上的UI一致性问题
3）测试在真实的运营商网络下工作的响应情况
4）发现在设备上才能重现的bug
缺点：
1）价格昂贵
2）不能安装辅助测试的统计和诊断工具
3）无法通过自动化脚本安装和测试
4）测试网络不稳定
模拟器测试
优点：
1）高性价比
2）易于管理，可以支持不同设备
3）支持自动化测试脚本
缺点：
1）不能发现设备相关的bug
2）不能代表真实的性能情况
总结：
试着从选取目标支持机型开始，准备你的测试计划。
接下来，理解运营商网络基础架构，在将数据发送到手机之前，有没有经过编码转换，加密，压缩以及其他形式的修改
从经济的角度，可以先使用模拟器进行测试，在最后阶段才会使用真机测试
手工测试用例也要像对待代码一样，使用版本控制来管理你的手工测试用例，进行备份和控制变更，定期审查，提出无效的脚本