软件测试-期末复习2

题型分布

第一大题选择题10小题，每小题2分，共20分；

第二大题填空题，每空2分，共20分；

第三大题判断题5小题，每小题1分，共5分；

第四大题简答题5小题，每小题5分，共25分；

第五大题综合题，2小题，每题15分，共30分。

第五大题中1小题为黑盒测试题

第五大题中1小题为白盒测试题，样题可参考教材“3.1.2 实例：判断年份是否为闰年”，题目会给出一段代码，考点涉及逻辑覆盖法、基本路径法的设计过程。比如利用逻辑覆盖法从代码中找出判定条件，基本路径法需要画出控制流图、得出圈复杂度和得出所有的独立路径。

第1章 软件测试基础

要求：了解软件生命周期，了解软件开发模型，了解软件质量，掌握软件缺陷分类及管理，熟悉软件测试及其与开发的关系，掌握软件测试模型，掌握软件测试原则，掌握软件测试基本流程。重点：软件缺陷处理流程及管理/软件测试模型/软件测试原则。难点：掌握软件测试基本原则/掌握软件测试的基本流程。要点:软件测试原则、软件测试按测试阶段分类、测试模型、质量模型、软件测试基本流程

一、软件生命周期(了解)

第1阶段:问题定义。在该阶段中软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性。

第2阶段:需求分析。该阶段对软件需求进行更深人的分析，划分出软件需要实现的功能模块，并制作文档。需求分析在软件的整个生命周期中起着非常重要的作用,它直接关系到软件开发的成功率。在后期开发中需求可能会发生变化，因此，在进行需求分析时，应考虑到需求的变化，以保证整个项目顺利进行。

第3阶段:软件设计。该阶段在需求分析的基础上，对整个软件系统进行设计，例如系统框架设计、数据库设计等。

第4阶段:软件开发。该阶段在软件设计的基础上，选择一种编程语言进行开发。在开发过程中，必须要制定统一的、符合标准的程序编写规范，以保证程序的可读性、易维护性和可移植性。

第5阶段:软件测试。该阶段的目标任务是在软件开发完成后对软件进行测试，以查找软件设计与软件开发过程中存在的问题并加以修正。软件测试阶段包括单元测试、冒烟测试、集成测试、系统测试和验收测试，测试可采用黑盒测试、白盒测试或者两者结合的方法。在测试过程中，为减少测试的随意性，需要制定详细的测试计划并严格遵守，测试完成之后，要对测试结果进行分析并将测试结果以文档的形式汇总。

第6阶段:软件维护。软件完成测试并投入使用之后，面对庞大的用户群体，软件可能无法满足用户的使用需求，此时就需要对软件进行维护升级以延续软件的使用寿命,软件维护包括纠错性维护和改进性维护2 个方面。软件维护是软件生命周期中持续时间最长的阶段。

二、软件开发模型(了解)

1.瀑布模型：

当一个阶段的任务完成之后才能开始下一个阶段。软件开发的每一个阶段都要有结果产出，结果经过审核证之后作为下一个阶段的输入，下一个阶段才可以顺利进行:如果结果审核验过不通过，则需要返回修改。

优点：检查点清晰，分工明确，有利于大型软件软件开发人员的组织管理及工具的使用与研究，可以提高开发的效率。

缺点：严格按照线性执行，增加了开发风险；要求必须有产出结果，增加了开发工作量。

对于现代软件，各阶段之间的关系很少是线性，瀑布模型已经不适合现代软件开发。

2.快速原型模型

快速原型模型与瀑布模型正好相反，它在最初确定用户需求时快速构造出一个可以运行的软件原型，这个软件原型用于向用户展示待开发软件的全部或部分功能和性能，用户对该原型进行作审核评价，然后给出更具体的需求意见，这样逐步丰富、细化需求，最后开发人员与用户达成最终共识，确定用户的真正需求。确定用户的真正需求之后，开始真正的软件开发。

优点：克服了需求不明确带来的风险，适用于不能预先确定需求的软件项目。

缺点：原型设计较难；不利于开发人员对产品的扩展。

3.迭代模型

优点：适应客户需求变更；降低了开发成本和风险。

缺点：增加了集成失败风险；容易退化为“边做边改”模式，失去对整个项目的控制。

4.螺旋模型

螺旋模型包含四个象限：

● 制定计划：确定软件目标，制定实施方案，列出项目开发的限制条件。

● 风险分析：评价所制定的实施方案，识别风险并消除风险。

● 实施工程：开发产品并进行验证。

● 客户评估：客户对产品进行审核评估，提出修正建议，制定下一步计划。

优点：强调了风险分析，有助于将软件质量融入开发中；小分段构建大型软件，易于计算成本；客户参与，保证项目可控性。

缺点：构建过程太过繁琐，不适合小型项目。

5.敏捷模型：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

特点：

● 项目被拆分成多个子项目，迭代完成，每个迭代都要经过测试。

● 快速响应需求变更，在修改过程中，软件一直处于可用状态。

● 不断对产品进行细微、渐进式地改进，每次改一小部分，如果可行再逐步扩大改进范围。

● 开发未动，测试先行。

● 注重“人”的作用。

优点：及时响应客户需求变更，不断适应新的趋势。

缺点：管理相对混乱，不适合大型项目。

开发方式：Scrum、Kanban

三、软件质量概述(了解)

1.软件质量是指软件产品满足基本需求及隐式需求的程度。

2.从软件质量的定义，可将软件质量分为三个层次：

● 满足需求规定：软件产品符合开发者明确定义的目标，并且能可靠运行。

● 满足用户需求：软件产品的需求是由用户产生的，软件最终的目的就是满足用户需求，解决用户的实际问题。

● 满足用户隐式需求：软件如果满足用户隐式需求，即潜在的可能需要在将来开发的功能。将会极大的提升用户满意度，这就意味着软件质量更高。

3.ISO/IEC 9126:1991软件质量模型：由6个特性和 21个子特性组成。

含义：

(1)功能性:在指定条件下，软件产品满足用户基本需求和隐式需求的能力。

(2)可靠性:在指定条件下使用时，软件产品维持规定的性能级别的能力。

3)可使用性:在指定条件下，软件产品被使用、理解、学习的能力。

(4)效率:在指定条件下，相对于所有资源的数量，软件产品可提供适当性能的能力。

(5)可维护性:指软件产品被修改的能力，修改包括修正、优化和功能规格变更的说明。

(6)可移植性:指软件产品从一个环境迁移到另一个环境的能力。

这6个特性及其子特性是软件质量标准的核心，软件测试工作就是根据这6个特性和21个子特性去测试、评价一款软件的。

4.影响软件质量的因素：

●  需求模糊：在软件开发之前，确定用户需求是一项非常重要的工作，它是后面软件设计与软件开发的基础,也是最后软件验收的标准。但是用户需求是不可视的，往往也说不清楚，导致产品设计、开发人员与用户之间存在一定的理解误差。开发人员对用户的真正需求不明确，导致开发出的产品与实际需求不符，这势必会影响软件的质量。除此之外，在开发过程中用户往往会多次变更需求，导致开发人员频繁地修改代码，同时会导致软件设计存在不能调和的误差，最终影响软件的质量。

●  软件开发缺乏规范性文件指导：现代软件开发中，大多数团队都将精力放在开发成本和开发周期上，而不太重视团队成员的工作规范导致团队成员开发“随意性”比较大，这也会影响软件质量，导致后期维护困难。而且一旦最后软件出现质量问题，也很难定责。

●  软件开发人员问题：软件是由开发人员开发出来的,因此开发人员的技术水平对产品质量的影响非常大。除了个人技术水平限制外，还包括人员流动的影响。新成员可能会接着上一任的产品继续开发下去，两个人的思维意识、技术水平等会有所不同，导致软件开发前后不一致，进而影响软件质量。

●  缺乏软件质量控制管理：在软件开发行业，并没有一个量化的指标去衡量一款软件的质量,软件开发的管理人员往往更易管控软件的开发成本和进度，毕竟这是显而易见的，并且是可以度量的。但软件质量则不同，软件质量无法用具体的量化指标去度量，因此很少有人关心软件最终的质量。

四、软件缺陷

1.软件缺陷产生的原因：

●  需求不明确

●  软件结构复杂

●  开发人员水平有限

●  项目期限短

●  使用新技术

2.软件缺陷的分类(掌握)

3.软件缺陷的处理流程：每个公司的软件缺陷处理流程不尽相同，但是它们遵循的最基本流程是一样的，都要经过提交、分配、确认、处理、复测、关闭等环节。

● 提交：测试人员发现缺陷后，将缺陷提交给测试组长。

● 分配：测试组长接收到测试组员提交的缺陷之后，将其移交给开发人员。

● 确认：开发人员收到移交的缺陷后，与团队及测试人员商议，确定该缺陷是否是缺陷。

● 拒绝：如经过商议之后，缺陷不是一个真正的缺陷则拒绝处理，关闭缺陷。如果经过商议之后，确定其是一个真正的缺陷，则根据缺陷的严重程度或优先级等立即处理或延期处理。

● 复测：开发人员修改好缺陷之后，测试人员重新进行测试（复测），检测缺陷是否确实已经修改。如果未被正确修改，则重新提交缺陷。

● 关闭：测试人员重新测试后，如缺陷已被正确修改，则将缺陷关闭，整个缺陷处理完成。

4.常见的软件缺陷管理工具：禅道、JIRA、Bugzilla

五、软件测试

1.软件测试的目的

●  对于软件开发来说，软件测试通过找到的问题缺陷帮助开发人员找到开发过程中存在的问题，包括软件开发的模式、工具、技术等方面存在的问题与不足，预防下次缺陷的产生。

●  对于软件测试来说，使用最少的人力、物力、时间等找到软件中隐藏的缺陷，保证软件的质量，也为以后软件测试积累丰富的经验。

●  对于客户需求来说，软件测试能够检验软件是否符合客户需求，对软件质量进行评估和度量，为客户评审软件提供有力的依据。

2.软件测试的分类

（1）按照测试阶段分类

●  单元测试：验证软件单元是否符合软件需求与设计，开发人员自测。

●  冒烟测试：软件构建版本建立后，对系统的基本功能进行简单的测试，这种测试重点验证的是程序的主要功能，而不会对具体功能进行深入测试。

●  集成测试：冒烟测试之后，将已经测试过的软件单元组合在一起测试它们之间的接口，用于验证软件是否满足设计需求。

●  系统测试：将经过测试的软件在实际环境中运行，并与其他系统的成分（如数据库、硬件和操作人员等）组合在一起进行测试。

●  验收测试：主要是对软件产品说明进行验证，逐行逐字的按照说明书的描述对软件产品进行测试，确保其符合客户的各项要求。

（2）按照测试技术分类

 ● 黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

●白盒测试：测试人员了解软件程序的逻辑结构、路径与运行过程，在测试时，按照程序的执行路径得出结果。白盒测试就是把软件（程序）当作一个透明的盒子，测试人员清楚的知道从输入到输出的每一步过程。

总结：相对于黑盒测试来说，白盒测试对测试人员的要求会更高一点，它要求测试人员具有一定的编程能力，而且要熟悉各种脚本语言。但是在软件公司里，黑盒测试与白盒测试并不是界限分明的，在测试一款软件时往往是黑盒测试与白盒测试相结合对软件进行完整全面的测试。

3.按照软件质量特性分类

●  功能测试：测试软件的功能是否满足客户的需求，包括准确性、易用性、适合性、互操作性等。

●  性能测试：测试软件的性能是否满足客户的需求，性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。

4.按照自动化程度分类

●  手工测试：测试人员一条一条的执行代码完成测试工作。费时费力且很验证保证测试效果。

●  自动化测试：借助脚本、自动化测试工具等完成相应的测试工作，它也需要人工的参与，但是它可以将要执行的测试代码或流程写成脚本，执行脚本完成整个测试工作。

5.按照测试项目分类

●  界面类测试：验证软件界面是否符合客户需求。

●  安全性测试：试软件在没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理，是否能保证软件与数据的安全。

●  文档测试：以需求分析、软件设计、用户手册、安装手册为主，主要验证文档说明与实际软件之间是否存在差异。

6.其他分类

●  α测试：软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题，整个测试过程是可控的。

●  β测试：软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录，然后反馈给开发人员进行修复。

●  回归测试：对修改后的程序重新进行测试确认原有的缺陷已经消除并且没有引入新的缺陷，这个重新测试的过程就叫作回归测试。

●  随机测试：没有测试用例、检查列表、脚本或指令的测试，它主要是根据测试人员的经验对软件进行功能和性能抽查。

六、软件测试与软件开发

1.关系(熟悉)

2.软件测试在项目各个阶段的作用如下：

●  项目规划阶段：负责从单元测试到系统测试的整个测试阶段的监控。

●  需求分析阶段：确定测试需求分析，即确定在项目中需要测试什么，同时制定系统测试计划。

●  概要设计与详细设计阶段：制定单元测试计划和集成测试计划。

●  编码阶段：开发相应的测试代码和测试脚本。

●  测试阶段：实施测试并提交相应的测试报告。

3.常见的软件测试模型（掌握）

（1）V模型

优点：将复杂的测试工作分成了目标明确的小阶段完成，具有阶段性、顺序性和依赖性，它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。

缺点：只能在编码之后才能开始测试，早期的需求分析等前期工作没有涵盖其中，因此它不能发现需求分析等早期的错误，这为后期的系统测试、验收测试埋下了隐患。

（2）W模型

优点：测试范围不仅包括程序，还包括需求分析、软件设计等前期工作，这样有利于尽早全面的发现问题。

缺点：它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动，无法支持迭代、自发性等需要变更调整的项目。

（3）H模型;将测试活动完全独立了出来，形成一个完全独立的流程，这个流程将测试准备活动和测试执行活动清晰的体现出来。测试流程和其他工作流程是并发执行的，只要某一个工作流程的条件成熟就可以开始进行测试。

（4）X模型；程序分成多个片段反复迭代测试，然后将多个片段集成再进行迭代测试。

优点：对单独程序片段进行的相互分离的编码和测试，保证了测试效果。增加了探索测试，可以帮助测试人员发现计划之外的软件错误。

缺点：频繁的集成会增加测试成本；探索测试对测试人员要求更高。

4.软件测试原则（掌握）

（1）测试应基于客户需求

所有的测试工作都应该建立在满足客户需求的基础上，从客户角度来看，最严重的错误就是软件无法满足要求。有时候，软件产品的测试结果非常完美，但却不是客户最终想要的产品，那么软件产品的开发就是失败的，而测试工作也是没有任何意义的。因此测试应依照客户的需求配置环境并且按照客户的使用习惯进行测试并评价结果。

（2）测试要尽早进行

软件的错误存在于软件生命周期的各个阶段，因此应该尽早开展测试工作，把软件测试贯穿到软件生命周期的各个阶段中，这样测试人员能够尽早地发现和预防错误，降低错误修复的成本。尽早的开展测试工作有利于帮助测试人员了解软件产品的需求和设计，从而预测测试的难度和风险，制定出完善的计划和方案，提高测试的效率。

（3）穷尽测试是不可能的

由于时间和资源的限制，进行完全（各种输入和输出的全部组合）的测试是不可能的，测试人员可以根据测试的风险和优先级等确定测试的关注点，从而控制测试的工作量，在测试成本、风险和收益之间求得平衡。

（4）遵循GoodEnough原则

GoodEnough原则是指测试的投入与产出要适当权衡，形成充分的质量评估过程，这个过程建立在测试花费的代价之上。测试不充分无法保证软件产品的质量，但测试投入过多会造成资源的浪费。随着测试资源投入的增加，测试的产出也是增加的，但当投入达到一定的比例后，测试的效果就不会明显增强了。因此在测试时要根据实际要求和产品质量考虑测试的投入，最好使测试投入与产出达到一个GoodEnough状态。

（5）测试缺陷要符合“二八”定理

一般情况下，软件80%的缺陷会集中在20%的模块中，缺陷并不是平均分布的。因此在测试时，要抓住主要矛盾，如果发现某些模块比其他模块具有更多的缺陷，则要投入更多的人力、精力重点测试这些模块以提高测试效率。

（6）避免缺陷免疫

测试用例被反复使用，发现缺陷的能力就会越来越差；测试人员对软件越熟悉越会忽略一些看起来比较小的问题，发现缺陷的能力也越差，这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉，形成了思维定势。

七、软件测试基本流程（掌握）

（1）分析测试需求

测试人员在制定测试计划之前需要先对软件需求进行分析，以便对要开发的软件产品有一个清晰的认识，从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据，作为测试计划的基本依据，为后续的测试打好基础。此外，分析测试需求也是对软件需求进行测试，以发现软件需求中不合理的地方。被确定的测试需求必须是可核实的，测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流，以澄清某些混淆，确保测试人员与客户尽早地对项目达成共识。

（2）制定测试计划

测试计划一般要做好以下工作安排。

● 确定测试范围：明确哪些对象是需要测试的，哪些对象不是需要测试的。

● 制定测试策略：测试策略是测试计划中最重要的部分，它将要测试的内容划分出不同的优先级，并确定测试重点。根据测试模块的特点和测试类型（如功能测试、性能测试）选定测试环境和测试方法（如人工测试、自动化测试）。

● 安排测试资源：通过对测试难度、时间、工作量等因素对测试资源合理安排，包括人员分配、工具配置等。

● 安排测试进度：根据软件开发计划、产品的整体计划来安排测试工作的进度，同时还要考虑各部分工作的变化。在安排工作进度时，最好在各项测试工作之间预留一个缓冲时间以应对计划变更。

● 预估测试风险：罗列出测试工作过程中可能会出现的不确定因素，并制定应对策略。

（3）设计测试用例

测试用例（Test Case）指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。不同的公司会有不同的测试用例模板，虽然它们在风格和样式上有所不同，但本质上是一样的，都包括了测试用例的基本要素。测试用例编写的原则是尽量以最少的测试用例达到最大测试覆盖率。

（4）执行测试

测试执行就是按照测试用例执行测试的过程，这是测试人员最主要的活动阶段。在执行测试时要根据测试用例的优先级进行。在执行测试过程中，测试人员要密切跟踪测试过程，记录缺陷、形成报告等，这一阶段是测试人员最重要的工作阶段。

（5）编写测试报告

一份完整的测试报告必须要包含以下几个要点。

● 引言：测试报告编写目的、报告中出现的专业术语解释及参考资料等。

● 测试概要：介绍项目背景、测试时间、测试地点及测试人员等信息。

● 测试内容及执行情况：描述本次测试模块的版本、测试类型，使用的测试用例设计方法及测试通过覆盖率，依据测试的通过情况提供对测试执行过程的评估结论，并给出测试执行活动的改进建议，以供后续测试执行活动借鉴参考。

● 缺陷统计与分析：统计本次测试所发现的缺陷数目、类型等，分析缺陷产生的原因给出规避措施等建议，同时还要记录残留缺陷与未解决问题。

● 测试结论与建议：从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价，给出具体明确的结论。

测试报告的数据是真实的，每一条结论的得出都要有评价依据，不能是主观臆断的。

例题：书P22-23

第2章 黑盒测试

要求：掌握等价类划分测试用例设计法，掌握边界值分析法测试用例设计法，掌握因果图与决策表法，了解正交实验设计法，掌握场景法，了解状态迁移图法。重点：掌握等价类划分法/掌握边界值分析法。难点：掌握因果图与决策表法/掌握正交实验设计法。要点:等价类划分法设计测试用例、边界值分析法、决策表概念、因果图法概念、因果图每种关系的含义、场景法概念、黑盒测试测试方法选择策略、理解测试用例特征

1.测试用例：指的是一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。是可以被独立执行的一个过程，是一个最小的测试实体，不能再被分解。测试用例将软件测试的行为活动做了一个科学化的组织归纳，以便能够把软件测试的行为转化为可管理的模式。同时，测试用例也是将测试具体量化的方法之一；对于不同类别的软件，测试用例也是不同的。对于一个测试过程来说，测试用例起到了很重要的作用，它构成了设计和制定测试过程的基础。而从某种角度来说，测试的“深度”与测试用例的数量成比例，判断测试是否完全的一个主要评测方法是基于需求的覆盖。

作用：

● 有效性：在测试时，不可能进行穷尽测试，从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试，可有效地节约时间和资源、提高测试效率。

● 避免测试的盲目性：在开始实施测试之前设计好测试用例，可以避免测试的盲目性，并使得软件测试的实施重点突出、目的明确。

● 可维护性：在软件版本更新后只需修正少部分的测试用例便可开展测试工作，降低工作强度，缩短项目周期。

可复用性：功能模块的通用化和复用化使软件易于开发，而良好的测试用例具有重复使用的性能，使得测试过程事半功倍，并随着测试用例的不断精化，使得测试效率也不断提高。

● 可评估性：测试用例的通过率是检验程序代码质量的标准，也就是说，程序代码质量的量化标准应该用测试用例的通过率和测试出软件缺陷的数目来进行评估。

● 可管理性：测试用例是测试人员在测试过程中的重要参考依据，也可以作为检验测试进度、测试工作量及测试人员工作效率的参考因素，可便于对测试工作进行有效的管理。

基本准则：

● 测试用例的代表性： 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。

● 测试用例的简洁性：步骤足够详细、准确和清晰；测试用例避免冗长和复杂，这样的用例可读性差、不利于测试人员理解和操作。简洁的测试用例可以让测试过程目的明确，让测试结果具有唯一性。

● 测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。

● 测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。

2.黑盒测试：把软件（程序）当作一个有输入与输出的黑匣子，它把程序当作一个输入域到输出域的映射，只要输入的数据能输出预期的结果即可，不必关心程序内部是怎么样实现的。

主要用于发现以下情况：

●是否有不正确或遗漏了的功能

●在接口上，能否正确地接受输入数据，能否产生正确地输出信息

●访问外部信息是否有错

●性能上是否满足要求

●界面是否错误，是否不美观

●初始化或终止错误

优点：

●黑盒测试与软件的具体实现方式无关，因此软件实现方式如果发生了变更、修改但功能测试不变的话，仍可以使用原来的测试用例。

●在进行软件开发的同时，也可以进行软件黑盒测试用例的设计，这样可以节省一部分时间成本，减少总开发时间

一、 等价类划分法：一个程序可以有多个输入，等价类划分就是将这些输入数据按照输入需求进行分类，将它们划分为若干个子集，这些子集即为等价类，在每个等价类中选择有代表性的数据设计测试用例。等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，它们具有等价特性，即每一类的代表性数据在测试中的作用都等价于这一类中的其它数据。这样，对于表征该类的数据输入将能代表整个子集合的输入。因此，可以合理的假定：测试某等价类的代表值就是等效于对于这一类其它值的测试。

二、边界值分析法

1.边界值的选取有两种方式：

● 选取5个值：最小值、略大于最小值、正常值、略小于最大值、最大值。

● 选取7个值：略小于最小值、最小值、略大于最小值、正常值、略小于最大值、最大值、略大于最大值。

三、因果图与决策表

●  恒等：在恒等关系中，要求程序有一个输入和一个输出，输出与输入保持一致。若c1为1，则e1也为1，若c1为0，则e1也为0。

●  非：非使用符号“~”表示，在这种关系中，要求程序有一个输入和一个输出，输出是输入的取反。若c1为1，则e1为0，若c1为0，则e1为1。

●  或：或使用符号“∨”表示，或关系可以有任意个输入，只要这些输入中有一个为1，则输出为1，否则输出为0。

●  与：与使用符号“∧”表示，与关系也可以有任意个输入，但只有这些输入全部为1，输出才能为1，否则输出为0。

这些依赖关系在软件测试中称为“约束”，约束的类别可分为四种：E（Exclusive，异）、I（at least one，或）、O（one and only one，唯一）、R（Requires，要求），在因果图中，用特定的符号表明这些约束关系。

●   E（异）：a和b中最多只能有一个为1，即a和b不能同时为1。

●   I（或）：a、b和c中至少有一个必须是1，即a、b、c不能同时为0。

●   O（唯一）：a和b有且仅有一人为1。

●   R（要求）：a和b必须保持一致，即a为1时，b也必须为1，a为0时，b也必须为0。

1.使用因果图法的优点：

（1）考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。

（2）能够帮助测试人员按照一定的步骤，高效率的开发测试用例。

（3）因果图法是将自然语言规格说明转化成形式语言规格说明的一种严格的方法，可以指出规格说明存在的不完整性和二义性。

2.决策表也称为判定表，其实质就是一种逻辑表。在程序设计发展初期，判定表就已经被当作程序开发的辅助工具了，帮助开发人员整理开发模式和流程，因为它可以把复杂的逻辑关系和多种条件组合的情况表达的既具体又明确，利用决策表可以设计出完整的测试用例集合。

决策表通常由4个部分组成：

●  条件桩：列出问题的所有条件，除了某些问题对条件的先后次序有要求之外，通常决策表中所列条件的先后次序都无关紧要。

●  条件项：条件项就是条件桩的所有可能取值。

●  动作桩：动作桩就是问题可能采取的操作，这些操作一般没有先后次序之分。

●  动作项：指出在条件项的各组取值情况下应采取的动作。

四、正交实验设计法：指从大量的实验点中挑选出适量的、有代表性的点，依据Glois理论导出“正交表”，从而合理的安排实验的一种实验设计方法。

正交实验设计法包含三个关键因素，具体如下所示。

●  指标：判断实验结果优劣的标准。

●  因子：因子也称为因素，是指所有影响实验指标的条件。

●  因子的状态：因子的状态也叫因子的水平，它指的是因子变量的取值。

利用正交实验法设计测试用例的步骤：

● 提取因子，构造因子状态表

● 加权筛选，简化因子状态表

● 构建正交表，设计测试用例

五、场景法

场景法也叫流程图法.是指通过模拟用户操作软件时的场景来对系统的功能或业务流程进行测试。场景法通常用于测试多个功能之间的组合使用情况，以及用于集成测试、系统测试和验收测试阶段。根据用户操作流程的正确性来划分时,场景法将用户的操作流程分为基本流和备选流。

六、状态迁移图：是黑盒测试的一种方法，状态迁移图用来描述系统或对象的状态，以及导致系统或对象状态发生改变的事件。状态迁移图法是通过分析被测系统的状态，以及这些状态之间的转换条件和路径来设计测试用例的一种方法，它主要用于验证在给定的条件内,系统对象是否能够发生状态的改变，以及是否存在不可能达到的状态或非法的状态等。在状态迁移图中，由一个状态、事件所确定的下一个状态可能会有多个，实际迁移到哪一个状态，由触发条件决定。

第3章 白盒测试

要求：掌握基本路径法、掌握语句覆盖法、掌握判定覆盖法、掌握条件覆盖法、掌握判定条件覆盖法、掌握条件组合覆盖法，了解目标代码插桩法、熟悉源代码插桩法。

重点：掌握逻辑覆盖测试中的语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、源代码插桩。难点：掌握逻辑覆盖法之间的区别、了解目标代码插桩和源代码插桩。要点:程序插桩法概念，各逻辑覆盖法覆盖度比较，基本路径法设计测试用例、语句覆盖、判定覆盖、条件覆盖和判定-条件覆盖法设计测试用例。

一、逻辑覆盖法

● 语句覆盖；又称行覆盖、段覆盖、基本块覆盖，它是最常见的覆盖方式。目的是测试程序中的代码是否被执行，它只测试代码中的执行语句，这里的执行语句不包括头文件、注释、空行等。在多分支的程序中，只能覆盖某一条路径，使得该路径中的每一个语句至少被执行一次，但不会考虑各种分支组合情况。语句覆盖无需详细考虑每个判断表达式，可以直观地从源程序中有效测试执行语句是否全部被覆盖，由于程序在设计时，语句之间存在许多内部逻辑关系，而语句覆盖不能发现其中存在的缺陷，因此语句覆盖并不能满足白盒测试的测试所有逻辑语句的基本需求

● 判定覆盖：判定覆盖(Decision Coverage)又称为分支覆盖，其原则是设计足够多的测试用例，在测试过程中保证每个判定至少有一次为真值，有一次为假值。作用是使真假分支均被执行，虽然判定覆盖比语句覆盖测试能力强，但仍然具有和语句覆盖一样的单一性。

上述4个测试用例覆盖了acd、abd、ace、abe四条路径，使得每个判定语句的取值都满足了各有一次“真”与“假”。相比于语句覆盖，判定覆盖的覆盖范围更广泛。判定覆盖虽然保证了每个判定至少有一次为真值，有一次为假值。判定覆盖语句一般是由多个逻辑条件组成，如果仅仅判断测试程序执行的最终结果而忽略每个条件的取值，必然会遗漏部分测试路径，因此，判定覆盖也属于弱覆盖。

● 条件覆盖：设计足够多的测试用例，使判定语句中的每个逻辑条件取真值与取假值至少出现一次。

从条件覆盖的测试用例可知，使用3个测试用例就达到了使每个逻辑条件取真值与取假值都至少出现了一次，但从测试用例的执行路径来看，条件分支覆盖的状态下仍旧不能满足判定覆盖，即没有覆盖acd路径。

相比于语句覆盖与判定覆盖，条件覆盖达到了逻辑条件的最大覆盖率，但却不能保证判定覆盖，仍旧不能满足白盒测试覆盖所有分支的需求。

● 判定-条件覆盖：要求设计足够多的测试用例，使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次。

在判定-条件覆盖中，3个测试用例满足了所有条件可能取值至少出现一次，以及所有判定语句可能结果也至少出现一次的要求。

相比于条件覆盖、判定覆盖，判定-条件覆盖弥补了两者的不足之处，但是由于判定-条件覆盖没有考虑判定语句与条件判断的组合情况，其覆盖范围并没有比条件覆盖扩展，判定-条件覆盖也没有覆盖acd路径，因此判定-条件覆盖在仍旧存在遗漏测试的情况。

● 条件组合覆盖：条件组合(Multiple Condition Coverage)指的是设计足够多的测试用例，使判定语句中每个条件的所有可能至少出现一次，并且每个判定语句本身的判定结果也至少出现一次，它与判定-条件覆盖的差别是，条件组合覆盖不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。与判定-条件覆盖相比，条件组合覆盖包括了所有判定-条件覆盖，因此它的覆盖范围更广。但是当程序中条件比较多时，条件组合的数量会呈指数型增长，组合情况非常多，要设计的测试用例也会增加，这样反而会使测试效率降低。

总结：

语句覆盖测试用例中，使程序中每个可执行语句至少被执行一次；对多分支的逻辑无法全面反映。

判定覆盖保证每个判定至少有一次为真值，有一次为假值；判定覆盖语句一般是由多个逻辑条件组成，忽略了每个条件的取值。

条件覆盖使判定语句中的每个逻辑条件取真值与取假值至少出现一次；相比于语句覆盖与判定覆盖，条件覆盖达到了逻辑条件的最大覆盖率，但却不能保证判定覆盖。

判定-条件覆盖使得判定语句中所有条件的可能取值至少出现一次，同时，所有判定语句的可能结果也至少出现一次；判定-条件覆盖在仍旧存在遗漏测试的情况。

条件组合覆盖使判定语句中每个条件的所有可能至少出现一次，并且每个判定语句本身的判定结果也至少出现一次；但是当程序中条件比较多时，条件组合非常多，要设计的测试用例也会增加，这样反而会使测试效率降低。

二、插桩法：程序插桩法是一种被广泛使用的软件测试技术,简单来说,程插桩法就是往被测试程序中插入测试代以达到测试目的的方法，插人的测试代码被称为探针。根据测试代码插入的时间不同可以将程序插桩法分为目标代码插桩和源代码插桩。

相比于目标代码插桩，源代码插桩实现复杂程度低。源代码插桩是源代码级别的测试技术，探针代码程序具有较好的通用性，使用同一种编程语言编写的程序可以使用一个探针代码程序来完成测试。

程序插桩测试方法有效的提高了代码测试覆盖率，但是插桩测试方法会带来代码膨胀、执行效率低下和HeisenBugs，在一般情况下插桩后的代码膨胀率在20%~40%，甚至膨胀率达到100%导致插桩测试失败。

三、基本路径法：是一种将程序的流程图转化为程序控制流图，并在程序控制流图的基础上，分析被测程序控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。使用基本路径法设计的测试用例需要确保被测程序中的每条可执行语句至少被执行一次。

计算程序圈复杂度的方法有3种，具体如下。

使用公式计算:V(G)=E-N+2，其中 V(G)表示程序的圈复杂度,E表示控制流图中边的数量，N表示控制流图中节点的数量。使用公式计算:V(G)=P+1，P表示控制流图中判定节点的数量。在控制流图中，当一个节点分出2条或多条指向其他节点的边时，这个节点就是一个判定节点。程序的圈复杂度等于控制流图中的区域数量。

四、黑盒测试和白盒测试比较

1.黑盒测试过程中不用考虑内部逻辑结构，仅仅需要验证软件外部功能是否符合用户实际需求。黑盒测试可发现以下缺陷：

●  外部逻辑功能缺陷，如界面显示信息错误等

●  兼容性错误，如系统版本支持、运行环境等。

●  性能问题，如运行速度、响应时间等。

白盒测试与黑盒测试不同，白盒测试可以设计测试用例尽可能覆盖程序中分支语句，分析程序内部结构。白盒测试常用于以下几种情况:

●  源程序中含有多个分支，在设计测试用例时要尽可能覆盖所有分支，提高测试覆盖率。

●  内存泄漏检查迅速，黑盒测试只能在程序长时间运行中发现内存泄漏问题，而白盒测试能立即发现内存泄露问题。

                                                                      第4章 接口测试

要求：了解接口测试，熟悉HTTP，掌握使用Postman发送请求的方式，掌握Postman的基本使用方法。重点：接口测试的概念、HTTP。难点：了解Postman的基本使用方法。要点:

HTTP,Pstman的基本使用，接口测试的流程

一、实现接口测试的方式

1.通过工具实现接口测试

2.通过代码实现接口测试：在工作中，测试人员需要按照公司制定的流程开展接口测试。通常，接口测试的流程包括分析接口测试需求、解析与评市接口文档、编写接口测试计划、设计与评市接口测试用例、搭建接口测试环境、编写接口测试脚本、执行接口测试用例、管理与跟踪接口缺陷、整理测试报告。

二、HTTP：超文本传输协议。HITP 是客户端和服务器之间的通信协议它主要由请求和响应组成。

1.统一资源定位符(Unifom Resouree Locator，URL)也称网页地址。

2.URL 的语法格式。

3.HTTP 请求是指客户端向服务器发送的请求消息,HTTP请求主要由请求行、请求头和请求体组成。

4.HTTP响应是指服务器向客户端发送的响应消息。HTTP响应主要由状态行、响应头和响应体组成。

Ixx:表示指示信息。

2xx:表示请求成功。

3xx:表示请求重定向。

4xx:表示客户端错误。

5xx:表示服务器错误。

5.Postman 参数化

(1)CSVCSV是一种常用的文件格式，在CSV文件中主要以纯文本形式存储数据，数据之间以逗号分隔，格式简但是不能存储元组、列表、字典和布尔类型的数据。

(2)JSON 也是一种常用的文件格式，JSON 文件中的数据由键值对组成，能够存储元组、列表、字典等类型的数据。

第五章性能测试

要求：掌握性能测试概念、指标及分类，掌握JMeter各组件的使用。重点：掌握性能测试的指标、种类、掌握JMeter各组件的使用。难点：掌握JMeter各组件的使用。要点:性能测试指标包括哪些及各个指标的概念、性能测试分类及概念、JMeter各组件的使用。

一、性能测试

1.定义：通过性能测试工具模拟正常、峰值及异常负载状态下对系统的各项性能指标进行测试的活动。性能测试能够验证软件系统是否达到了用户期望的性能需求，同时也可以发现系统中可能存在的性能瓶颈及缺陷，从而优化系统的性能。

2.目的：

●  验证系统性能是否满足预期的性能需求，包括系统的执行效率、稳定性、可靠性、安全性等。

●  分析软件系统在各种负载水平下的运行状态，提高性能和效率。

●  识别系统缺陷，寻找系统中可能存在的性能问题，定位系统瓶颈并解决问题。

●  系统调优，探测系统设计与资源之间的最佳平衡，改善并优化系统的性能。

3.性能测试指标

● 响应时间

响应时间（Response Time）指系统对用户请求作出响应所需要的时间。

这个时间是指用户从软件客户端发出请求到用户接收到返回数据的整个过程所需要的时间，包括各种中间件（如服务器、数据库等）的处理时间。响应时间越短，表明软件的响应速度越快，性能越好。但是响应时间需要与用户的具体需求相结合。

● 吞吐量：指单位时间内系统能够完成的工作量，它衡量的是软件系统服务器的处理能力。

●并发用户数：指同一时间请求和访问的用户数量。并发用户数量越大，对系统的性能影响越大，并发用户数量较大可能会导致系统响应变慢、系统不稳定等。

● TPS：系统每秒钟能够处理的事务和交易的数量，它是衡量系统处理能力的重要指标。

●点击率：指用户每秒向Web服务器提交的HTTP请求数，这个指标是Web应用特有的一个性能指标，通过点击率可以评估用户产生的负载量，并且可以判断系统是否稳定。点击率只是一个参考指标，帮助衡量Web服务器的性能。

●资源利用率：软件对系统资源的使用情况，包括CPU利用率、内存利用率、磁盘利用率等，资源利用率是分析软件性能瓶颈的重要参数。

● 错误率：系统在负载情况下，失败交易的概率。错误率=（失败交易数/交易总数）*100%

不同系统对错误率的要求不同，但一般不超出千分之五。稳定性较好的系统，其错误率应该由超时引起，即为超时率。请求成功率=请求成功数/总请求数

4.性能测试种类

●基准测试：从狭义上讲，基准测试是指单用户测试，即测试环境确定后，使用单个用户对业务模型中的重要业务做多次单独的测试，观察并记录各项性能指标的变化。例如，同一个用户登录10 次软件以测试登录所需时间最后得出 10次登录平均所需时间为3秒，这就是一次基准测试。

●负载测试是指逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统性能指标的情况下，系统所能够承受的最大负载量。

●压力测试也叫强度测试，它是指逐步给系统增加压力，测试系统的性能变化，使系统某些资源达到饱和或系统崩溃的边缘，从而确定系统所能承受的最大压力。压力测试可以暴露那些只有在高负载条件下才会出现的 bug，例如同步问题、内存泄漏等。

●并发测试：指通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其他性能问题。并发测试一般没有标准，只是测试并发时会不会出现意外情况，几乎所有的性能测试都会涉及到一些并发测试，例如多个用户同时访问某一条件数据，多个用户同时在更新数据，那么数据库可能就会出现访问错误、写入错误等异常情况。并发测试对时间的要求比较苛刻，通常并发用户的模拟都是借助于工具，采用多线程或多进程方式来模拟多个虚拟用户的并发性操作。在后续介绍LoadRunner工具时，有一个集合点的概念，它就是用来模拟并发的，可以在VuGen中设置集合点，在Controller中设置其对应的策略来模拟用例设计的场景。

●配置测试：指调整软件系统的软硬件环境，测试各种环境对系统性能的影响，从而找到系统各项资源的最优分配原则。

配置测试不改变代码，只改变软硬件配置，例如安装版本更高的数据库、配置性能更好的CPU、内存等，通过更改外部配置来提高软件的性能。

●稳定性测试：也叫可靠性测试，系统在强负载情况下，持续，持续运行一段时间（如7*24h），测试系统在这种条件下是否能够稳定运行。

●容量测试：在一定的软硬件及网络环境下，测试系统所能支持的最大用户数、最大存储量等。通常与数据库、系统资源（如CPU、内存、磁盘等）有关，用于规划将来需求增长（如用户增长、业务量增加等）时，对数据库和系统资源的优化。

5.压力测试与负载测试区别：

负载测试的目的是在满足性能指标要求的前提下,测试系统能够承受的最大负载,而压力测试的目的则是测试使系统性能达到极限的状态。例如软件系统正常的响应时间为2秒通过负载测试确定用户访问量超过1万人时响应时间变慢。对于压力测试，则继续增加用户访问量，观察系统的性能变化，当用户访问量增加到2万人时系统响应时间为3秒，当用户访问量增加到3万人时响应时间为4秒，当用户访问量增加到4万人时，系统崩溃无法响应。由此确定系统能承受的最大访问量为4万人。

二、JMeter：由Apache开发维护一款开源免费的性能测试工具，Jmeter以Java作为底层支撑环境，它最初是为测试Web应用程序而设计的，但后来随着发展逐步扩展到了其他领域。现在Jmeter可用于静态资源和动态资源的测试，例如，它可用于模拟服务器、服务器组、网络或对象上的重负载以测试其强度、分析不同负载类型下的整体性能。

1.核心组件

● 取样器（Sampler）：是Jmeter的主要执行组件，它用于向服务器发送一个请求，并记录响应信息，包括成功/失败、响应时间、数据大小等。Jmeter支持多种不同的采样器，可根据设置不同的参数向服务器发送不同类型的请求（HTTP、FTP、TCP等）。

● 监听器（Listener）：监听测试结果，还具备查看、保存和读取测试结果的功能。

● 配置元件（Config Element）：设置默认属性和变量等数据，供采样器获取所需配置信息

● 断言（Assertions）：检查测试得到的数据是否符合预期结果。包括json断言、响应断言

● 前置处理器（Per Processors）：在实际请求发出前，对即将发出的请求特殊处理。例如，HTTP URL重写修饰符可实现URL重写，当发送的请求中有SessionID信息时，可通过前置处理器填充发出请求的实际SessionID。

● 后置处理器（Post Processors）：一般放在采样器之后，用来处理服务器的返回结果。

● 逻辑控制器（Logic Controller）：确定采样器的执行顺序。

● 定时器（Timer）：在操作之间设置等待时间。

第六章web自动化测试

要求： 掌握自动化测试的概念，自动化测试需要满足的条件与自动化测试的优缺点；掌握自动化测试实施策略，掌握自动化测试技术，掌握自动化测试工具，掌握教材中自动化测试案例，掌握Selenium元素定位方法、常用的操作方法，掌握自动化测试框架的使用，能够使用unittest和pytest框架进行自动化测试。重点：掌握自动化测试需要满足的条件与自动化测试的优缺点；自动化测试实施策略、自动化测试技术。难点：掌握Selenium元素定位方法、常用的操作方法，掌握自动化测试框架的使用，能够使用unittest和pytest框架进行自动化测试。要点:自动化测试的常见技术、自动化测试实施策略、自动化测试需要满足的条件与自动化测试的优缺点、Selenium元素定位方法和常见的操作方法。

一、简介

1.定义：把以人为驱动的测试行为转化为机器执行的过程。实际上自动化测试往往通过一些测试工具或框架，编写自动化测试脚本，来模拟手工测试过程。

2.引入自动化测试需要满足以下条件：

●  项目需求变动不频繁

●  项目进度压力不大，时间不紧迫

●  多种浏览器或平台上可重复运行相同的测试脚本

金字塔要求自动化测试从三个不同级别进行，最底部的单元测试占据了自动化测试的最大百分比，其次是接口测试和UI测试。将自动化测试重点工作放在单元测试和接口测试阶段有助于加快项目整体开发进度，减少后期开发和测试的成本。

（1）单元测试：要求在开发中对每个功能模块（函数、类方法）进行测试，如检测其中某一项功能是否按预期要求正常运行，单元测试中通常采用白盒测试，主要对代码内部逻辑结构进行测试。

（2）接口测试：要求对数据传输、数据库性能等进行测试，从而保证数据传输以及处理的完整性。接口功能的完整运作对整个项目功能扩展、升级与维护有着重要的作用，接口测试通常使用黑盒测试和白盒测试相结合的方式进行。

（3）UI测试：以用户体验为主，软件的所有功能都是通过这一层展示给用户，因此UI测试的工作也很重要。由于UI界面以最终的用户体验为主，因此在UI测试中并不是100%的使用自动化测试，其中需要人工操作来确定UI界面的易用程度。

3.自动化测试的优势和劣势

优势:

（1）提高回归测试的效率

回归测试是指开发人员修改了项目中原来的代码后，为了确保项目能够正常运行、没有引人新的错误,测试人员需要重新对项目进行测试。

(2)提高测试人员的利用率

在部署好测试环境后，自动化测试可以在无人看守的状态下进行，并对测试结果进行分析。测试人员可以将时间和精力投人其他测试工作中，从而减少测试人员的工作量，提高测试人员的利川率。

(3)提高测试的精确度

在人工测试的过程中，测试人员在测试过程中会出现每次测试的操作步骤不一样的问题，这样会导致测认结果不准确。为了减少人工测试中人为的错误或误差，我们可以使用自动化测试。

(4)提高测试的便捷性

如果需要对项目进行负载测试或压力测试，则需要大最用户同时访问并操作该项目。此种类型的测试需要拟大量用户的参与，人工测试很难实现大量用户同时访问并操作项目，此时可以通过自动化测试来实现，从而达到对项目进行负载测试与压力测试的目的，提高测试的便捷性。

劣势:

(1)不能提高测试的有效性

自动化测试的脚本由代码编写而成，在测试过程中，脚本可能会出现异常或逻辑错误等情况，此时将无法提高测试的有效性。自动化测试工具本身也是一个产品，当它在不同的操作系统或平台上运行时也可能会出现缺陷例如，能在 Windows 操作系统上运行的脚本不一定能在 Lnux 操作系统上运行,能在谷歌浏览器上运行的脚本不-定能在火狐或其他浏览器上运行。当自动化测试过程中出现脚本运行异常时，则不能提高测试的有效性。

(2)发现的缺陷比人工测试少且不容易发现新的缺陷

自动化测试通常在人工测试之后开展，常用于回归测试。由于自动化测试使用的工具是没有思维的，无法进行主观判断，所以自动化测试只能用于发现新版本的软件是否有旧版本的软件的缺陷，不易发现软件的新缺陷，并且发现的缺陷数量通常比人工测试的要少。自动化测试常用于缺陷预防而不是发现更多新缺陷。

总结：通过分析自动化测试的优缺点可知，自动化测试无法完全取代人工测试，自动化测试和人工测试都有各自的优缺点。在实际项目的测试过程中，自动化测试和人工测试是相辅相成的，将两者有效结合才能保证软件产品的高质量。

4.常见技术：

（1）录制与回放

录制是指先由测试人员对桌面应用程序或者 Web 页面的某一项功能完成一遍需要测试的流程，然后通过自动化测试工具记录测试流程中客户端与服务器之间的通信过程，以及用户与应用程序交互时的操作行为，自动生成个脚本。在测试执行期间可以回放测试的流程，通过回放能够査看录制过程中存在的错误和不足，例如图片刷新缓慢、URL 无法访问等。

（2）脚本测试

脚本是测试计算机程序执行的指令集合。脚本可以用JavaScript、Python、Java 等语言编写，如果要使用录制生成的脚本，则需要修改后再使用，这样可以减少测试人员编写脚本的工作量。常见的脚本技术有以下3种。

● 脚本技术

线性脚本是指通过录制人工执行测试用例得到的脚本，包括鼠标单击事件、页面选择、数据输入等操作。线性脚木可以完整地进行回放。

● 结构化脚本

结构化脚本类似于结构化程序设计，具有多种逻辑结构，例如顺序、分支、循环等，并且它还具有函数调用功能。结构化脚本可以灵活地用于测试各种复杂功能。

● 共享脚本

在自动化测试中，一个脚本可以调用其他脚本进行测试，这些被调用的脚本就是共享脚本。共享脚本可以使脚本被多个测试用例共享。

（3）数据驱动技术

数据驱动是指从数据文件中读取输人数据并将数据以参数的形式输人脚本测试,不同的测试用例使用不同类型的数据文件。数据驱动技术实现了数据和脚本分离，相较于录制与回放测试技术，数据驱动技术极大地提高了脚本利用率和可维护性，但是界面变化较大的项目不适合使用数据驱动技术。常见的数据驱动技术有以下2种

● 关键字驱动：数据驱动的改进，它将数据与脚本分离、界面元素与内部对象分离、测试过程与实现细节分离关键字驱动的测试逻辑为按照关键字进行分解得到数据文件，常用的关键字主要包括被操作对象、操作和值。

● 行为驱动

行为驱动是指根据不同的测试场景设计不同的测试用例，它需要开发人员、测试人员、产品业务分析人员等协作完成。行为驱动测试是基于当前项目的业务需求、数据处理、中间层进行的协作测试，它注重的是测试软件的内部运作变化，从而解决单元测试中的细节问题。

二、Selenium

1.定义：当前针对Web系统的最受欢迎的开源免费的自动化工具，它提供了一系列函数支持Web自动化测试，这些函数非常灵活，它们能够通过多种方式定位UI元素，并将预期结果和实际表现进行比较。

2.元素定位方法：单个元素的定位方法。

3.元素常用操作方法

三、自动化测试框架

第7章APP测试

要求：了解移动App测试基础知识,掌握移动App测试要点,掌握移动App测试流程,熟悉常见的移动App测试工具。重点：掌握Appium测试工具的使用、掌握测试脚本的编写、掌握移动App测试环境搭建。难点：自动化测试工具的使用、测试脚本编写要点:理解移动APP的特性及其与传统软件测试的区别， 移动App测试要点，Appium的测试对象、Appium的基本使用。

一、简介

1.App测试与传统软件测试的区别

●  页面布局不同：对于PC 端软件，计算机设备屏幕比较大，可以同时显示很多信息，用户可以快速看到屏幕上显示的所有信息，页面布局比较灵活。但是对于App，移动设备屏幕小，显示的信息有限，在测试时需要考虑布局是否合理。此外，在测试时还需要考虑移动设备是横屏的还是竖屏的，以及当移动设备在横屏和竖屏之间切换时，屏幕上信息显示是否符合用户需求。

●  使用场合不同：PC 端软件的使用地点比较固定，网络信号相对也比较稳定;而App的使用地点不固定，网络信号相对也不稳定，测试时需要考虑网络信号较差的情况下App的使用情况。此外，还要考虑在移动设备电量不足的情况下 App 是否能正常使用。

●  输入方法不同：PC 端软件大多使用键盘和鼠标进行输入，App 在移动设备上使用时，输入方法比较多，例如触屏、电容笔、语音等。App 测试时需要测试多种输入方法是否都能正常使用。

●  操作方式不同：PC 端软件使用鼠标可以精确操作，而App在移动设备上使用时大多是触屏操作，点击时误差较大，且不支持鼠标指针悬停事件。

二、测试要点

1.UI测试：导航测试、图像测试、内容测试

2.功能测试：注册、登录、运行、切换、推送、更新

3.专项测试：安装测试、 卸载测试、升级测试、 交互性测试、 弱网测试、耗电量测试

4.性能测试：边界测试、压力测试、响应能力测试、耗能测试

5.兼容测试

三、Appium手势操作：轻敲操作、按下操作、抬起操作、等待操作、长按操作、移动操作、滑动操作。