软件测试基础----测试策略、手段、方法

测试策略

单元测试

单元测试是对已实现的软件的最小单元进行测试,以保证构成软件的各个单元的质量。

在单元测试活动中,强调被测试对象的独立性。通过单元测试,希望达到下列一些目标:

• 单元体现了其特定的功能，如果需要，返回正确的值。
• 单元的运行能够覆盖预先设定好的各种逻辑。
• 在单元工作过程中,其内部数据能够保持完整性,包括全局变量的处理、内部数据的形式、内容及相巨关系等不发生错误。
• 可以接受正确数据,也能处理非法数据,在数据边界条件上,单元也能够正确工作。
• 该单元的算法合理，性能良好。

单元的质量是整个软件质量的基础,所以充分的单元测试是非常必要的。

通过单元测试可以更早地发现缺陷,缩短开发周期、降低软件成本。 多数缺陷在单元测试中很容易被发现,但如果没有进行单元测试,那么这些缺陷在后期测试时就会隐藏得很深而难以发现最终导致测试周期延长、开发成本急剧增加。

单元测试方案是根据详细设计文档来编制的。

集成测试

1. 集成测试的模式：

• 非渐增式测试模式:
  先分别测试每个模块,再把所有模式按设计要求放在一起结合成所要的程序,也常被称为大棒模式。
• 渐增式模式:
  把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试完以后再把下一个应该测试的模块结合进来测试。

业界普遍采用渐增式测试模式,也就是持续集成的策略。 使用持续集成,绝大多数模块之间的接口缺陷,在其引入的第一天可能就会被发现。软件开发中各个模块可能不是同时完成的,测试人员可以尽可能早地集成已完成的模块,有利于尽早发现缺陷, 避免像大棒模式那样一下子涌现大量的缺陷。

2. 自顶向下集成测试：

自顶向下集成法是从主控模块开始,沿着软件的控制层次向下移动,逐渐把各个模块结合起来。在自顶向下组装过程中,可以使用深度优先策略或宽度优先策略。

自顶向下集方法示意图：↓↓↓↓↓

深度优先: M1→M2→M5→ M8→M6→M3→S7→S4
宽度优先: M1→M2→M3-S4→M5→M6→S7→M8

自顶向下集成测试法能够在测试阶段的早期验证系统的主要功能逻辑，越重要的控制模块，越能优先得到测试。
但软件中使用频繁的基础函数一般处在模块结构图的底层，由于这些模块集成的时间比较晚，因此这些基础函数中的错误也会发现的比较晚。另外，该方法需要编写大量的桩程序，因此在具体实施时可能会遇到比较大的阻力。

3.自底向上集成测试

自底向上集成测试是指从底层模块(即软件模块结构图中最低层的模块)开始,逐步向上不断集成模块进行测试的方法。

自底向上集成方法示意图：↓↓↓↓↓

自底向上集成测试一般不需要创建桩程序，但需要创建驱动程序。

自底向上集成测试能够在最早时间完成对基础函数的测试，其他模块可以更早地调用这些基础函数，有利于提高开发效率，缩短开发周期。但控制能力强、影响面越广的上层模块,其测试时间会靠后，若在测试后期才发现这些模块有问题，则修改这些缺陷就会很困难，或者修改的影响面很广，从而存在很大的风险。

4. 混合策略

在实际测试过程中,一般会将自顶向下集成测试和自底向上集成测试有机地结合起来，形成混合测试策略来完成软件系统的集成测试,这种混合测试策略可以发挥自顶向下集成测试和自底向上集成测试的优点,避免其缺点,从而有效地提高测试效率。

三明治集成方法示意图：↓↓↓↓↓

改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得更彻底。↓↓↓↓↓

确认测试

确认测试又称有效性测试,是在模拟的环境下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书中列出的需求,即验证软件的功能是否与用户的要求一致。

软件的功能要求在软件需求规格说明书中已经明确规定,即需求规格说明书包含的用户需求信息就是软件确认测试的基础。

有效性测试和软件配置审查是确认测试需要完成的两项工作，这两项工作在验收测试之前就已完成。

系统测试

系统测试是验证软件产品是否符合这些质量特性要求的测试。系统测试包括性能测试、安全测试和兼容性测试等。

• 系统测试是公司内部进行的测试

验收测试

验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动,它是技术测试的最后一个阶段,也称为交付测试。

验收测试是交付用户前的最后一个测试阶段；
验收测试是以用户为主的测试

验收测试按照项目任务书或合同、供需双方约定的验收依据文档对整个系统进行测试与评审,验收测试决定用户是否接收系统。
验收测试结束后,根据验收通过准则分析验收测试语梁,微测试评价及是否通过验收。
验收测试是按照任务书或合同中供需双方约定的验收依据进行测试，决定是否可以将软件交付给用户。
验收测试通常会有以下四种情况：

• 测试项目通过。
• 测试项目没有通过,并且不存在变通方法,需要做很大的修改。
• 测试项目没有通过,但存在变通方法,在维护后期或下一个版本改进。
• 测试项目无法评估或者无法给出完整的评估。此时必须给出原因。如果是因为该测试项目没有说清楚,应该修改测试计划。

回归测试

在一个系统的生命周期内往往要多次进行，一旦系统经过修改就需要进行回归测试。

回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
这里，修改的正确性有两重含义：

• 一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；
• 二是不影响软件的其他功能的正确性。

“仅测试修改部分”这种回归测试方法的测试范围是只进行部分修改的项目，所以成本低，但风险相应较高、系统靠性低。

回归测试是测试人员非常头疼的一件事情，时间紧迫是回归测试的一大难题，不可能对每一个小的改动都做FullRegression的测试。所以可以使用“基于风险的测试方法”。
也需要在测试的适当阶段引入新的测试人员来补充测试，让新加入的测试人员来带新的灵感。另外推荐在适当的项目中，使用自动化测试工具来进行回归测试

测试手段

手工测试

手工测试有其不可替代的地方,因为人具有很强的判断能力,而工具没有。

手工测试不可替代的地方至少包括以下几点：

• 测试用例的设计：测试人员的经验和对错误的判断能力是工具不可替代的。
• 界面和用户体验测试：人类的审美观和心理体验是工具不可模拟的。
• 正确性检查：人们对是非的判断、逻辑推理能力是工具不具备的。

自动化测试

自动化测试通过编写测试代码来代替手工的重复性测试工作,对经常需要多次回归的测试用例进行代码0685化，可以提高测试效率、解放人力。为了使线上环境更加稳定，可以将软件的核心功能与业务脚本化,进行线上巡检,使线上生产环境更加稳定。

UI自动化测试

UI ( User Interface ,用户界面,亦称使用者界面)是指对软件的人机交互、操作逻辑、界面美观的整体设计是系统和用户之间进行交互和信息交换的媒介,它实现信息的内部形式与人类可以接受形式之间的转换。UI层的自动化测试工具非常多,比较主流的是QTP.Robot Framework, Watir、 Selenium等,其中Selenium是目前比较常用的UI自动化测试工具。

接口自动化测试

接口自动化容易实现,维护成本低,有着更高的投入产出比,是每个公司开展自动化测试的首选,目前接口自动化测试在企业中的应用越来越广泛。

单元自动化测试

单元自动化测试可以使用单元自动化测试工具或框架来实现,不同的语言其单元测试框架也不同，几乎所有的主流语言都有其对应的自动化测试工具或框架,如Java的Junit, testNG, C#的NUnit , Python的unittest、 Pytest等。
不过单元自动化测试对测试工程师的编码能力要求较高,大部分公司在这个层级都无法很好地推行自动化测试。

测试方法

黑盒测试

黑盒测试通过软件的外部表现来发现缺陷和错误。
黑盒测试方法把测试对象看成一个黑盒子,完全不考虑程序内部结构和处理过程,仅针对程序是否能适当地接收输入数据、是否能产生正确的输出信息等进行测试。

软件测试基础----黑盒测试

白盒测试

通过对程序内部结构的分析与检测来寻找软件问题的方法称为白盒测试，又称结构测试。
白盒测试可以把程序看成是一个装在透明的白盒子里的代码,测试人员清楚地了解程序的内部结构和处理过程,通过检查程序的内部结构及逻辑路径是否正确、检查软件内部动作是否符合软件设计说明书的规定来发现程序中的缺陷

软件测试基础----白盒测试

灰盒测试

灰盒测试是介于白盒测试与黑盒测试之间的测试。
灰盒测试关注输出对于输入的正确性,同时也关注程序内部表现,但这种关注不像白盒测试那样详细和完整,只是通过一些表面的现象、事件和标志来判断程序内部的运行状态。因此,可以这样定义灰盒测试,灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例、执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。