软件测试基础知识（1） -- 软件评测师（十二）

1 软件测试的基本概念

1.1 软件测试概述

    （1）软件测试定义：2014年，IEEE发布了软件工程知识体系SWEBOK3.0 ，其中将软件测试定义微“是动态验证程序针对有限的测试用例集是否可产生期望的结果”。

    （2）软件测试的目的：保证软件质量

    （3）软件测试的对象：由程序、相关数据和文档三部分组成。

    （4）软件质量保证（QA）：指为了提供足够的信任表明实体能够满足质量要求，而在质量管理体系中实施并根据需要进行证实的全部有计划和有系统的活动。软件质量保证和软件测试的区别如下：

    1）软件质量保证涉及的活动要宽泛得多，作为企业级的系统性的活动更加宏观，对各种具体的质量保证措施提供知道、监督和评价，并不断改善提高质量保证的能力。

    2）保证软件质量的措施和手段有很多，测试是其中一种，当然是不可缺少的最为重要的手段，测试需要在质量保证的大目标下开展工作以满足质量保证的要求，同时测试将为质量保证提供充分的数据以帮助评价质量。软件测试更多的表现为技术性活动，而软件质量保证则是管理性活动特征更明显。

     在软件测试和软件质量保证活动中，验证与确认是两个经常使用的术语，而且还比较多的同时使用，英文中验证为Verification, 确认为Validation, 因此很多时候用V&V来代表验证与确认。两者的区别如下：

    1）验证：通过提供客观证据来证实规定需求已经得到满足。对于软件来讲，验证是检验软件是否满足需求规格说明的要求，是判断生产者是否（按需求规格）正确地构造了软件，或者说是不是“正确的做事”。验证的依据是产品要求（需求规格），是生产者自己内部要求。

    2）确认：通过提供客观证据来证实针对某一特定预期用途或应用需求已经得到满足。确认是检验软件是否有效，是否满足用户的预期用途和应用需求。确认是要判断生产者是否构造了正确的软件，或者说是不是“做了正确的事”。确认的依据是用户的应用要求，对软件生产者来讲是一种外部要求。除了测试外，确认应该有更多的活动，如评审、用户调查及意见收集等。

    （5）软件测试的原则：

    1）溯源性原则：不同阶段的测试有不同的阶段性目标，但汇集起来后的总目标是保证软件质量，者主要通过对需求的复合型验证和确认（V&V）来体现，因此测试应当溯源到原始需求，而不是仅仅只盯着眼前。

    2）工程性原则：测试不是某个阶段的活动，而是贯穿软件生产的各阶段，需要以工程化的思想和方法来组织和实施。需尽早按计划开展测试，甚至进行预防性测试，以避免测试延迟带来的巨大代价。

    3）独立性原则：应当避免开发工程师测试自己的程序，自己测试自己的程序会受到定势思维和心理因素的影响，测试质量将大打折扣，企业应设立独立的测试工程师岗位或测试部门去承担测试工作。

    4）合理性原则：对软件进行完全测试是不可能的，基于有限的时间和有限的资源，无法对软件开展穷举式的测试。

    5）不完全性原则：测试能做的是尽可能多的发现错误，但不能暴漏全部的缺陷，不能证明软件不再包含错误。

    6）相关性原则：基于大量的测试统计和分析，人们发现一个软件（模块）中被找到的缺陷越多，则这个软件（模块）中残留的缺陷也越多，或者说缺陷常常有聚集现象。

    7）可接受原则：测试的直接目标是发现软件缺陷，但更进一步的目的是修复发现的缺陷，然而修复是有代价的，因为时间或修复风险等方面的原因，以发现的缺陷不一定全部修复。在各方可以接受的前提下，可以允许某些缺陷留在软件中。

    8）风险性原则：测试虽然是为了降低或化解软件的质量风险，但必须认识到测试本身也是有风险的。所以需要在做测试设计及构造测试用例时考虑如何规避和减少风险。

    （6）软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境而规定的软件测试的原则、方法的集合，软件测试策略的确定是基于测试需求的分析以及测试风险评估的结果，定义测试的规范和要求，选择合适的测试方法，并制定测试启动、停止、完成的标准和条件。

    制定软件测试策略的过程如下：

    1）确定测试的需求。需要注意测试需求必须是可观测、可测评的。软件需求于测试需求以及测试用例不是一对一关系。测试需求可能有许多来源。

    2）评估风险并确定测试优先级。

   3）确定测试策略 。一个好的测试策略应该包括：实施的测试类型和测试目标、实施测试的阶段、技术、评估测试结果和测试是否完成的标准、对测试工作存在的影响的特殊事项等。

1.2 软件异常的分类及其关系

    （1）软件缺陷：Defect, 更多时候习惯用Bug。GB/T 32422-2015《软件工程 软件异常分类指南》中将缺陷定义为“工作产品中出现的瑕疵或缺点，导致软件产品无法满足用户需求或者规格说明，需要修复或者替换”。具体来说，缺陷还有以下各种称呼。

    1）错误：较多时候是软件缺陷的静态表现，是存在于软件中的一种缺陷。

    2）故障：是软件缺陷的动态表现，是因为软件的缺陷造成软件工作时出现的问题。

    3）失效：是软件因缺陷而导致的后果。

    （2）软件缺陷的形成：需求的表达没有真实反映实际的要求，设计有瑕疵，采用的技术方案不合理，软件太过复杂，沟通有问题，软件过程不规范，文档化不充分等都可能引入缺陷。通过统计，需求分析阶段引入的缺陷比例通常超过40%，在设计阶段引入的缺陷也在30%以上，而编码产生的缺陷低于30%。相比较而言，编码缺陷最容易被发现，而需求分析和设计阶段产生的缺陷很隐蔽，被发现要困难得多。因此对需求和设计的评审有助于降低缺陷的发生率。

    （3）软件异常的分类：GB/T 32422-2015《软件工程 软件异常分类指南》中软件异常被定义为“从文档或软件操作观察到偏离以前验证过的软件产品或引用的文档的任何事件”。异常可能由失效引起，失效可能由故障引起，而故障是软件缺陷的子集。

    缺陷的优先级和严重性在不同的企业中可能因业务场景差异有不同的定义：

    1）缺陷的优先级：用于表达评估、解决和关闭缺陷的优先程度，分为5个级别。

级别	处理原则
紧急	需要立即处理
高	应在下一个可运行版本中解决
中	应在第一个交付版本中解决
低	期望在第一个交付版本中解决（在第一个交付版本后升级到优先级“中”）
无	无需在第一个交付版本中解决

    2）缺陷的严重性：只缺陷引起失效的最大影响程度，也分为5个等级。

级别	描述
阻塞	在纠正或发现合适的方法之前，测试无法进行
严重	主要操作被打乱，导致安全性受到影响
一般	主要操作受到影响但软件产品仍能继续运行
轻微	非主要操作受到影响
可忽略	操作未受到影响

1.3 软件测试过程模型

    软件测试过程模型通常是对着开发模型演变的，常见的4种软件测试过程模型如下：

    （1）V模型：软件测试的V模型对应于开发的瀑布模型。

    在V模型中，测试活动对应于瀑布模型的每个工程阶段，即：

    1）单元测试对应编码

    2）集成测试对应详细设计 

    3）系统测试对应概要设计

    4）验收测试对应需求分析

    （2）W模型：是对V模型的一个重要改进，充分体现了尽早开展测试的原则，V模型以发现缺陷为目标，而W模型则以上升为保证软件质量为目标。

    （3）H模型：进一步改善了W模型中的一些问题，把测试活动从软件开发过程中独立出来，在软件过程的任何一个时间点，只要测试条件满足即可开展测试。

     H模型比W模型更好的地方是能够兼顾测试的效率和灵活性，适合于各种规模及类型的软件项目。

    （4）敏捷测试模型：敏捷测试源于敏捷开发，敏捷测试是敏捷开发的组成部分，需要与开发流程良好融合，其特定如下：

1.4 软件测试类型 

    （1）按工程阶段划分的测试：如果按软件开发的瀑布模型，测试活动可以分为几个主要的阶段，包括单元测试、集成测试、系统测试、确认测试和验收测试。

    1）单元测试：是最小单位的测试活动，也称为模块测试。单元测试是封闭在单元内部的测试，关注一个单元是否正确地实现了规定的功能、逻辑是否正确、输入输出是否正确，从而寻找模块内部存在的各种错误，单元测试使用的方法包括白盒测试、黑盒测试以及灰盒测试。在单元测试中进行的测试工作需要在以下五个方面对所测模块进行检查：

    ①模块接口测试：在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确的输入和输出，就谈不上进行其他的测试。

    ②局部数据结构测试：局部数据结构是最常见的错误来源，如不正确或不一致的数据类型说明、使用尚未赋值或尚未初始化的变量、错误的初始值或错误的默认值、变量名拼写错误或书写错误、不一致的数据类型等等。

    ③路径测试：应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试，可以发现大量的路径错误。常见的不正确计算有：

    a. 运算的优先次序不正确或误解了运算的优先次序。

    b. 运算的方式错，即运算的对象彼此在类型上不相容。

    c. 算法错。

    d. 初始化不正确。

    e. 运算精度不构。如计算的结果用int和float是不一样的。

    f. 表达式的符号表示不正确。如“=” 和 “==”是比较容易混淆的符号。

 ④错误处理测试：比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：

    a. 出错的描述难以理解。

    b. 出错的描述不足以对错误定位，不足以确定出错的原因。

    c. 显示的错误与实际错误不符。

    d. 对错误条件的处理不正确。

    e. 在对错误进行处理之前，错误条件已经引起系统的干预等。

    ⑤边界测试：在边界上出现错误是常见的，例如在一段程序内有一个n次循环，当到达第n次重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。

    2）集成测试：是在软件的单元测试完成并修复了所发现的错误后，进行模块的集成时开展的测试。集成测试的主要任务是发现单元之间的接口可能存在的问题，如接口参数不匹配、接口数据丢失、数据误差积累引起错误等，目标是验证各个模块组装起来之后是否满足软件的设计文件要求。模块组装成为系统的方式有以下两种：

    ①一次性组装方式：是一种非增殖式组装方式，也称为整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。

    ②增值式组装方式：又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。

    3）系统测试：目标是确认软件的应用系统能否如预期工作并满足应用的需求。系统测试对应的对象是应用系统，除软件外可能还包括硬件、网络及数据，并且需要在一个比较真实的环境下进行。

    4）确认测试：也称为有效性测试，主要由软件的开发方组织。该测试可以对需求规格的局部开展分项确认，也可以针对需求规格全集开展完全的确认，以验证软件的有效性。

    5）验收测试：由用户方组织，在生产环境下进行。实施验收测试的可以是用户自己，也可以是开发方，也可以委托第三方机构开展。

    （2）按是否执行代码划分的测试可分为如下两种：

    1）静态测试：不运行软件，只做检查和审核，测试的对象包括需求文档、设计文档、产品规格说明书以及代码等。对各类文档的测试主要通过评审的方式进行，对代码的静态测试采用代码走查和代码审查方式。

    2）动态测试：需要执行代码，是通过运行软件开展的测试。关注语句、分支、路径、调用等程序结构的覆盖。

    （3）按测试实施主体划分的测试可以分为如下三种：

    1）开发方测试：开发方作为软件的供方，测试应该涵盖软件生成及交付的各个阶段，以满足用户需求为最终目的。

    2）用户方测试：实施难度远高于开发方测试，用户方只能开展验收测试，基于对自己真实需求的认识，用户方测试能够更好地确认软件是否符合自身的需求。

    3）第三方测试：向社会提供专业的软件测试服务，对检验软件产品质量、保护软件用户方权益具有重要意义。主要开展软件的确认测试、验收测试和符合性测试。

    （4）按是否关联代码划分的测试可以分为如下三种：

    1）白盒测试：也称为结构化测试、逻辑驱动测试或基于代码的测试，是指测试人员开展测试时完全清楚被测试程序的内部结构、语句及工作过程。

    2）黑盒测试：也称为基于规格说明的测试，通过软件的外部表现行为进行测试的方法，他不关心程序的内部结构和如何实现，只关心程序的输入和输出。

    3）灰盒测试：即关注黑盒测试方法中的输入输出，也在一定程度上关注程序的内部情况，是两种测试方法的一定融合，较多地应用于软件的集成测试中。

    （5）按软件质量特性划分的测试可以分为8种：

    1）功能性测试：是在制定条件下使用的，测试软件提供满足明确和隐含要求的功能的程度，包括软件功能的完备性、正确性和合适性。

    2）性能效率测试：是在指定条件下使用时，测试软件的性能及效率满足需求的程度，包括时间特性、资源利用性、容量等。

    3）兼容性测试：是在共享相同的硬件或软件环境的条件下，测试软件能够与其他软件交换信息和/或执行其所需的功能的程度，包括软件的共存性和互操作性。

    4）易用性测试：是在指定的使用环境中，测试软件在有效性、效率和满意度特性方面为了指定的目标可为指定用户使用的程度，包括软件的可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性、易访问性等。

    5）可靠性测试：是测试软件在指定条件下指定时间内执行指定功能的程度，包括软件的成熟性、可用性、容错性、易恢复性。

    6）信息安全性测试：是测试软件保护信息和数据的程度，包括保密性、完整性、抗抵赖性、可核查性、真实性。

    7）维护性测试：是测试软件能够被预期的维护人员修改的有效性和效率的程度，包括软件的模块化、可重用性、易分析性、易修改性、易测试性。

    8）可移植性测试：是测试软件能够从一种硬件、软件或其他运行（或使用)环境迁移到另一种环境的有效性和效率的程度，包括软件的适应性、易安装性、易替换性。

    （6）符合性测试：是按符合性评价划分的测试，是要通过测试去判定软件是否符合事先已经明确的文件性要求和约束，如标准、规范、技术指标、招投标文件、合同等。符合性测试可以由上述的用户方、开发方的独立测试部门或第三方测试机构进行，为获得客观公正的符合性测试结论，最好由具备资质的第三方测试机构开展。

    （7）回归测试：只要软件发生了变化，就应该进行回归测试。如果这种变动是对缺陷的修复，回归测试首先要验证缺陷是否确实被正确修复了，然后测试因此次缺陷修复而可能影响到的功能是否依然正确。如果软件的变动是增加了新的功能，回归测试除了验证新功能的正确性之外同样要测试可能受到影响的其他功能。即使变动是删减了软件中原来的某些功能，依然要通过回归测试来检查是否影响到保留的功能。

2 测试技术的分类

    测试技术分为4类：基于规格说明的测试技术、基于结构的测试技术、基于经验的测试技术、自动化测试技术。

    （1）基于规格说明的测试技术其实就是黑盒测试，包括10种方法：等价类划分法、分类树法、边界值法、语法测试、组合测试、判定表测试、因果图法、状态转移测试、场景测试、随机测试。

    （2）基于结构的测试技术其实就是白盒测试，包括静态测试技术和动态测试技术。动态测试通过运行软件来发现错误或验证程序是否符合预期要求。静态测试则不运行软件，制作检查和审核，测试的对象包括需求文档、设计文档、产品规格说明书以及代码等。

    （3）基于经验的测试技术包括错误猜测法、探索性测试、基于检查表的测试。

    （4）自动化测试技术的内容包括：自动化测试技术的发展、自动化测试的分类、自动化测试的优缺点、自动化测试的实践策略。

2.1 基于经验的测试技术

    基于经验的测试一般是测试人员基于以往的项目经验、特定的系统和软件知识或应用领域知识开展，能够发现应用系统化的测试方法不易发现的隐含特征的问题，其效果与测试人员的经验和技能有直接关系，但具有一定的随机性，往往难以评估其覆盖率。通常有如下3种技术：

    （1）错误猜测法：又称为错误推测法，是基于测试人员对以往项目测试中曾经发现的缺陷、故障或失效数据，在导致软件错误原因分析的基础上设计测试用例，用于预测错误、缺陷和失效发生的技术。错误猜测法中有关估算错误数量的方法主要有2种：

    1）Seeding模型估算法：排错前，将软件中含有的未知错误数据记为N，在此基础上，人为向程序中再添加个错误。经过t个月的排错工作后，检查排错的清单，将排错类型分为两类：一类为程序中原有的错误，数量记为n，另一类则是由排错人员人工插入的错误，数量为。预估该软件中错误总数。

    Hyman在Seeding模型估算错误的基础上对其进行改进：设置A、B两组测试人员相互独立地对某个软件进行测试，记A组人员和B组人员测得的错误数分别为i 和j 个，两组测试人员共同测出的错误数为k，软件错误数的估算值N与这三个量的关系如下：N=(i*j)/k。

    2）Shooman模型估算法：这时一种通过估算错误产生的频度来保证软件的可靠性的方法。估算错误产生的频度主要体现为估算平均失效等待实践（MTTF）。因此Shooman模型估算MTTF的公式为：。其中，K为经验常数;是程序长度（机器指令条数或简单汇编语句条数）；是测试之前程序中的原有故障总数，t是测试（包括排错）的时间；是在0-t期间内检出并排除的故障总数。

    （2）探索性测试：探索性测试主要分为自由式探索性测试、基于场景的探索性测试、、基于策略的探索性测试、基于反馈的探索性测试和基于会话的探索性测试。探索性测试有2种方法：

    1）局部探索式测试法：可以辅助测试人员针对测试过程中出现的细节问题做出即时的决定。测试人员可以将测试经验、专业知识以及在操作环境中构建和运行软件的知识结合在一起，在没有更多的信息的前提下运行测试用例，动态地做出正确的局部决定。

    2）全局探索式测试法：可以辅助测试人员在实际开始测试之前建立一个全局目标，确定对软件进行探索式测试的整体方向，以更系统化的方法来组织测试，从而尽量覆盖软件的复杂程度及其特。

    3）探索性测试的优势如下：

    ①在测试设计不充分的情况下，探索式测试可以基于之前类似的测和结果进行测试。

    ②在早期需求模糊或系统不稳定时，探索性测试可以不受限制地在短时间内对产品质量进行反馈。

    ③当发现缺陷时，探索性测试可以快速向开发人员提供针对缺陷的严重程度、涉及范围和变化的反馈。

    ④探索性测试可以作为脚本测试的一个重要补充，以检测出脚本测试不能检测到的缺陷。

    4）探索性测试的局限性如下：

    ①无法对测试对象进行全面性的测试，测试结果一般不易度量，不能确保发现最重要的软件缺陷。

    ②脚本测试可以在需求收集阶段编制测试用例，根据用例的执行来发现缺陷，而探索性测试去烧易防缺陷的能力。

     ③对于已经确定了测试类型和执行顺序的测试来说，直接编写测试脚本并执行比进行探索性测试更有意义。

    ④依赖测试人员的领域知识和测试技术，探索性测试不容易协调及调整，导致测试效率低下，缺乏条理。

    （3）基于检查表的测试：通过设计相应的检查点，并按照检查点进行测试验证的一种测试方法。分类主要有以下两种：

    1）基于代码检查表的测试：基于代码检查表进行代码审查的测试主要为了检查代码和设计的一致性，代码对标准的遵循、可读性，代码逻辑表达的正确性，代码结构的合理性等方面。

    2）基于文档检查表的测试：基于文档检查表的测试进行文档审查主要涉及文档的可用性、文档内容及文档标识和标示等方面。

2.2 自动化测试

    自动化测试是把人为驱动的测试行为转化为机器执行的一种过程。也就是模拟手工测试步骤，通过执行由程序语言编制的测试脚本，自动地完成软件的测试设计、单元测试、功能测试、性能测试等全部工作，包括测试活动的自动化和测试过程管理的自动化。

    （1）自动化测试的分类:从测试目的角度可分为功能自动化测试与非功能自动化测试，非功能自动化测试主要包括性能自动化测试和信息安全自动化测试。

    功能自动化测试的目标是：①软件功能验证；②提高测试效率

    性能自动化测试的目标是：①软件性能验证；②完成人工无法完成的测试任务。

    信息安全自动化测试的目标是：①漏洞检测，信息安全验证；②完成人工无法完成的测试任务和提高测试效率。

    （2）自动化测试的优点如下图:

    （3）自动化测试的缺点如下图：

    （4）自动化测试的局限性：自动化测试可以提高测试效率，能够完成手工测试不能完成的工作，但自动化测试在实际应用中也存在局限性，并不能完全替代手工测试。在下面的领域中自动化测试会有一定的局限性，如下图：

    （5）对自动化测试不正确的认知如下图：

    （6）自动化测试的实践策略：自动化测试投入得越早，层次越低，投入产出比越高。

    1）单元层：单元测试是最有价值的测试。应使用相应的单元测试框架来规范地实施单元测试，如Java的Junit、TestNg， Python的Unittest、Pytest等，几乎所有的主流编程语言都会有其对应的单元测试框架。

    2）服务和接口层：集成、接口自动化测试，它的价值中等。单元测试关注代码的实现逻辑，集成、接口测试关注的是一个函数、类所提供的接口是否可靠，接口自动化测试能覆盖大多数主要的接口是比较合理的。

    3）用户界面层：用户界面自动化测试的价值最小。在实际生成过程中，它不易实现，维护成本很高，所以适当的界面自动化测试可以有，但是没必要100%都自动化。用户界面层自动化测试工具非常多，如QTP、Robot、Framework、Selenium等。

    （7）适合使用自动化测试工具的项目和环境如下图所示：

    （8）开展自动化测试的必要条件：

    （9）基于模型的测试技术：软件测试设计的初始步骤就是在理解被测试的系统和功能的基础上，用一定的模型结构来描述被测试的系统的功能和质量属性，然后根据测试模型获取要覆盖的测试覆盖项。在获取具体明确的测试覆盖项后，可设计测试步骤来完成测试用例的设计。

    1）基于模型的测试技术的常见工具：微软的Spec Explorer、Graph Walker、Stoat、MBT On Cloud等。

    2）基于模型的测试技术的优点如下：

    3）基于模型的测试技术的缺点如下：

    （10）基于搜索的测试技术：该技术包括各种元启发式技术，其核心思想是把测试数据生成问题转化为搜索问题，即从软件允许的输入域中搜索所需的值以满足测试要求。代表工具为Sapienz。基于搜索的测试技术的优缺点如下图所示：

    （11）自动化测试工具的选择：目前市场上的自动化测试工具非常多，常见的自动化工具有：

    1）UFT：早期称为QTP，是一种企业级的自动化测试工具，提供了强大易用的录制回放功能。支持B/S与C/S两种架构的软件测试，是目前主流的自动化测试工具。

    2）Robot Framework：基于Python，可扩展的关键字驱动的测试自动化框架，提供了一套特定的语法，并且有丰富的测试库。

    3）Selenium:是一款用于Web应用程序测试的工具，支持多平台、多浏览器、多语言去实现自动化测试。

    4）Appium：是一个C/S结构的开源测试自动化框架，支持IOS平台和Android平台上的原生应用、Web应用和混合应用。它使用WebDriver协议驱动IOS、Android和移动Web应用程序。

    （12）自动化测试语言的选择：以下为机构主流的语言及其优劣势：

    1）Python: 优点是语法简单，开发效率高，语言的扩展性好，具有可移植性和可嵌入性。缺点是执行效率比较慢，线程不能利用多CPU。

    2）Java: 优点是纯面向对象的编程语言；跨平台执行，具有很好的可移植性；提供了很多内置的类库；提供了对Web应用开发的支持；具有较好的安全性和健壮性。缺点是：解释型语言，运行效率极低，不支持底层操作。

    3）Go:优点是主要用于云计算和服务设计；跨平台编译，编译很快；支持语言级别的并发性；丰富的标准库；简单易学；可直接编译成机器码，不依赖其他库。缺点是缺少框架；错误处理不构好，软件包管理不够完善。

    （13）自动化测试输出结果的收集和分析如下图所示：

    1）持续集成工具：Jenkins。

    2）持续集成（CI）的好处：快速发现错误；防止分支大幅偏离主干。

    3）持续集成的目的：让产品快速迭代，同时还能保持高质量。

    4）一个完整的持续集成系统必须包括一个自动构建过程，包括自动编译、分发、部署和测试等。 

2.3 基于软件质量特性的测试

    软件质量模型的发展如下图所示：

    （1）使用质量模型（GB/T 25000.10-2016）：使用质量主要从用户的角度进行考虑，根据使用软件的结果而不是软件自身的属性来进行测试，即用户使用产品或系统满足其需求的程度。其模型如下表所示：

使用质量模型
特殊	子特性	说明
有效性	有效性	指用户实现指定目标的准确性（出错频率）和完备性（期望功能的完整性程度）。
效率	效率	指用户实现目标的准确性和完备性时相关的资源消耗。
满意度	有用性、可信性、愉悦性、舒适性	指产品或系统在指定的使用周境中，用户的要求被满足的程度。
抗风险	经济风险缓解性、健康和安全风险缓解性、环境风险缓解性	指产品或系统在经济现状、人的生命、健康或环境方面缓解潜在风险的程度。
周境覆盖	周境完备性、灵活性	指在指定的使用周境中，产品或系统在有效性、效率、抗风险和满意度等特性方面能被使用的程度。

    （2）系统/软件产品质量模型（ GB/T 25000.10-2016）：与从用户角度触发的使用质量不同，软件产品质量更多的是考虑软件产品或系统本身的质量特性。其模型如下：

产品质量模型
特性	子特性
功能性	功能完备性、功能正确性、功能适合性、功能性的依从性
性能效率	时间特性、资源利用性、容量、性能效率的依从性
兼容性	共存性、互操作性、兼容性的依从性
易用性	可辨识性、易学性、易操作性、用户差错防御性、用户界面舒适性、易访问性、易用性的依从性
可靠性	成熟性、可用性、容错性、易恢复性、可靠性的依从性
信息安全性	保密性、完整性、抗抵赖性、可核查性、真实性、信息安全性的依从性
维护性	模块化、可重用性、易分析性、易修改性、易测试性、维护性的依从性
可移植性	适应性、易安装性、易替换性、可移植性的依从性

    1）功能性：功能性用于评估软件产品在指定条件下使用时，提供满足明确和隐含要求的功能的能力。功能性测试即包括单个功能点测试，还包括业务流程测试和主要场景测试。在功能测试中一般使用等价类划分法、边界值法、因果图法、判定表法、场景法等方法设计测试用例。用例包括正常用例和异常用例，最后对设计好的用例逐项进行测试，检查产品是否达到用户要求的功能。

    2）性能效率：性能效率测试用于评估在指定条件下使用的资源数量的性能。进行性能效率测试的目的包括获得系统的性能表现情况、发现并验证和修改系统影响性能的缺陷、为系统性能优化提供数据参考。包括时间特性测试、资源利用性测试、容量测试。性能效率测试类型有：基准测试、并发测试、压力测试、负载测试、稳定性测试、极限测试、场景测试、吞吐量测试。 

    3）兼容性：兼容性测试用于评估在共享形态的硬件或软件环境的条件下，产品、系统或组件能够与其他产品、系统或组件交换信息或执行其所需的功能的程度。主要包括共存性测试、互操作性测试。

    4）易用性：易用性的测试包含六个子特性：可辨识性测试（描述的完整性、演示覆盖率、产品标识可辨识、入口点的自描述性）、易学性测试（帮助系统和文档的完整性、自动填充默认输入字段、差错信息易理解性、用户界面的自解释性）、易操作性测试（操作一致性、消息的明确性、功能的易定制性）、用户差错防御性测试（抵御误操作、用户输入差错纠正）、用户界面舒适性测试（文字和颜色等一致、前景和背景色搭配合理、布局协调、窗口比例适当）、易访问性（特殊群体的易访问性、支持的语种的充分性）。

    5）可靠性：可靠性测试包括成熟性测试（系统、产品或组件在正常运行时满足可靠性要求的程度）、可用性测试（系统、产品或组件需要使用时能够进行操作和访问的程度）、容错性测试（当存在硬件或软件故障时，系统、产品或软件的运行符合预取的程度）和易恢复性测试（发生中断或失效时，产品或系统能够恢复直接受影响的数据并重建期望的系统状态的程度）。

    6）信息安全性：信息安全性测试包括保密性测试（只有在被授权时才能被访问的程度）、完整性测试（阻止未授权访问、篡改计算机程序或数据的程度）、抵赖性测试（活动或事件发生后可以被证实且不可被否认的程度）、可核查性测试（实体的活动可以被唯一地追溯到该实体的程度）、真实性测试（对象或资源的身份标识能够被证实符合其声明的程度）。

    7）维护性：维护性测试包括模块化测试（有多个独立组件组成的系统或计算机程序，其中一个组件的变更对其他组件的影响大小的程度）、可重用性测试（资产能够被用于多个系统或其他资产建设的程度）、易分析性测试（预期的变更，对产品或系统的影响、诊断产品的缺陷或失效原因、识别待修改部分的有效性和效率的程度）、易修改性测试（产品或系统可以被有效地、有效率地修改，且不会引入缺陷或降低现有产品质量的程度）、易测试性测试（能够为系统、产品或组件建立测试准则，并通过测试执行来确定测试准则被满足的有效性和效率的程度）。

    8）可移植性：可移植性测试包括适应性测试（产品或系统能够有效地、有效率地适应不同的或演变的硬件、软件或者其他运行（或使用）环境的程度）、易安装性测试（在指定环境下，产品或系统能够成功地安装和/或卸载的有效性和效率的程度）、易替换性测试（在相同的环境下，产品能够替换另一个相同用途的指定软件产品的程度）。  

    依从性测试用于评估产品或系统遵循与功能性、性能效率、易用性、可靠性、信息安全性、维护性、兼容性、可移植性等八个质量特性有关的标准、约定和法规以及类似规定的程度。

    标准符合性测试是测量产品的功能和性能指标，与相关国家标准或行业标准所规定的功能和性能等指标之间符合程度的测试活动。它区别于一般的测试，标准符合性测试的测试依据和测试规程一定是国家标准或行业标准，而不是实验室自定义的或其他的有关文件。