软件测试知识


1. 软件测试概述

1.1 软件测试的定义

(1) 1983年,IEEE给软件测试的定义:

使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

(2) 1990年,IEEE再次给出软件测试的定义:

①在特定的条件下运行系统或构件,观察或记录结果,对系统的某个方面做出评价;

②分析某个软件项以发现现存的和要求的条件之差别并评价此软件项的特性。

以上的定义都有一定的片面性。不能只对系统程序进行测试,找出系统程序中的错误,而对分析、设计等过程发生的错误视而不见。软件产品由文档、数据和程序组成,那么软件测试就是对软件开发过程中形成的文档、数据以及程序进行相关的测试。

1.2 软件的缺陷等级划分

软件缺陷的等级可以用严重性和优先级来描述:

严重性:衡量缺陷对客户满意度影响的满意程度,分为

  1. 致命错误,可能导致本模块以及其他相关的模块异常,死机等问题;
    常见的有严重花屏、内存泄漏、用户数据丢失或破坏、系统崩溃/死机/冻结、模块无法启动或异常退出、严重的数值计算错误、功能设计与需求严重不符、其它导致无法测试的错误, 如服务器500错误。
  2. 严重错误,问题局限在本模块,导致模块功能失常或异常退出;
    常见的有:功能未实现,功能错误、系统刷新错误、数据通讯错误、轻微的数值计算错误、影响功能及界面的错误字或拼写错误。
  3. 一般错误,模块功能部分失效;
    常见的有:操作界面错误,边界条件错误,提示信息错误,长时间操作无进度提示,系统未优化,兼容性问题。
  4. 建议模块,有问题提出人对测试模块的改进建议。
    优先级:缺陷被修复的紧急程度;
  5. 立即解决(P1级) :缺陷导致系统功能几乎不能使用或者测试不能继续,需立即修复;
  6. 高优先级(P2级) :缺陷严重,影响测试,需优先考虑;
  7. 正常排队(P3级) :缺陷需要正常排队等待修复;
  8. 低优先级(P4级) :缺陷可以在有时间的时候被纠正。

2. 软件测试的目的

  1. 对于软件开发。软件测试通过找到问题缺陷帮助开发人员找到开发过程中存在的问题,包括软件开发的模式、工具、技术等方面存在的问题和不足,预防下次缺陷的产生。
  2. 对于软件测试来说。使用最少的人力、物力、时间等找到软件中隐藏的缺陷,保证软件饿质量,也为以后软件测试积累丰富经验。
  3. 对于客户需求来说,软件测试能够检验软件是否符合客户要求,对软件质量进行评估和度量,为了客户评审软件提供有力的依据。

3. 软件测试的分类

3.1 按测试阶段分类

  • 单元测试。验收软件单元是否符合软件需求与设计,开发人员自测。

    • 通常情况下是白盒的,对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试,及早的发现和解决不易显现的错误。
    • 单元测试的策略:逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、数据流分析。
  • 集成测试。将已经测试过的软件单元组合在一起测试它们之间的接口,用于验证软件是否满足设计需求。

    • 自顶向下集成:模块集成的顺序是首先集成主模块,然后按照控制层次结构向下进行集成,隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。
    • 自底向上集成:从原子模块开始来进行构造和测试,因为模块是自底向上集成的,进行时要求所有隶属于某个给顶层次的模块总是存在的,也不再有使用稳定测试桩的必要。
  • 系统测试。将软件在实际环境中运行,并与其他系统的成分(如数据库、硬件等) 组合在一起进行测试。

    • 检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的“先知者问题”。是黑盒的。测试重点是整个系统的运行以及与其他软件的兼容性。
    • 系统测试包括:功能测试,性能测试,可靠性测试,安全性测试
  • 验收测试。主要对软件产品说明进行验证,按照说明书的描述对软件产品进行测试,确保符合客户的各项要求。

    • 它的测试数据通常是系统测试的测试数据的子集。验收测试包括正式验收测试,非正式验收测试:Alpha测试(α测试)和Beta(β测试)测试。

3.2 按测试技术分类

  • 黑盒测试。也称功能测试数据驱动测试。把软件(程序) 当作一个有输入与输出的黑匣子,它把程序当作一个输入域到输出域的映射,只要输入的数据能输出预期的结果即可,不必关心程序内部是怎么样实现的。
* 常用的黑盒测试方法有:等价类划分法、边界值分析法、因果图法、场景法、正交实验设计法、判定表驱动分析法、错误推测法、功能图分析法。
* “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试,只有把所有可能的输入都作为测试情况使用,才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个,因此不仅要测试所有合法的输入,而且还要对那些不合法但是可能的输入进行测试。
  • 白盒测试。又称逻辑驱动测试结构测试。测试人员了解软件程序的逻辑结构、路径与运行过程,在测试时,按照程序的执行路径得出结果。白盒测试就是把软件(程序) 当作一个透明的盒子,测试人员清楚的知道从输入到输出的每一步过程。
* 常用白盒测试方法: 
    * 静态测试:不用运行程序的测试,包括代码检查、静态结构分析、代码质量度量、文档测试等等,它可以由人工进行,也可以借助软件工具(Fxcop) 自动进行。 
    * 动态测试:需要执行代码,通过运行程序找到问题,包括功能确认与接口测试、覆盖率分析、性能分析、内存分析等。
* 白盒测试中的逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。六种覆盖标准发现错误的能力呈由弱到强的变化:

1.语句覆盖每条语句至少执行一次。

2.判定覆盖每个判定的每个分支至少执行一次。

3.条件覆盖每个判定的每个条件应取到各种可能的值。

4.判定/条件覆盖同时满足判定覆盖条件覆盖。

5.条件组合覆盖每个判定中各条件的每一种组合至少出现一次。

6.路径覆盖使程序中每一条可能的路径至少执行一次。

3.3 按照软件质量特性分类

  • 功能测试。测试软件的功能是否满足客户的需求,包括准确性、易用性、适合性、互操作性等。
  • 性能测试。测试软件的性能是否满足客户的需求,性能测试包括负载测试、压力测试、兼容性测试、可移植性测试和健壮性测试等。

3.4 按照自动化程度分类

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

    • 手工测试优点
      1、测试人员具有经验和对错误的猜测能力。
      2、测试人员具有审美能力和心理体验。
      3、测试人员具有是非判断和逻辑推理能力。
    • 手工测试缺点
      1、重复的手工回归测试,代价昂贵、容易出错。
      2、依赖于软件测试人员的能力。
  • 自动化测试。借助脚本、自动化测试工具等完成相应的测试工作,它也需要人工的参与,但是它可以将要执行的测试代码或流程写成脚本,执行脚本完成整个测试工作。

    • 自动化测试的优点
      1、对程序的回归测试更方便。这可能是自动化测试最主要的任务,特别是在程序修改比较频繁时,效果是非常明显的。由于回归测试的动作和用例是完全设计好的,测试期望的结果也是完全可以预料的,将回归测试自动运行,可以极大提高测试效率,缩短回归测试时间。

      2、可以运行更多更繁琐的测试。是可以在较少的时间内运行更多的测试

      3、可以执行一些手工测试困难或不可能进行的测试。比如,对于大量用户的测试,不可能同时让足够多的测试人员同时进行测试,但是却可以通过自动化测试模拟同时有许多用户,从而达到测试的目的

      4、更好地利用资源。将繁琐的任务自动化,可以提高准确性和测试人员的积极性,将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试,仅适合于手工测试,将可自动测试的测试自动化后,可以让测试人员专注于手工测试部分,提高手工测试的效率。

      5、测试具有一致性和可重复性。由于测试是自动执行的,每次测试的结果和执行的内容的一致性是可以得到保障的,从而达到测试的可重复的效果。

      6、测试的复用性。由于自动测试通常采用脚本技术,这样就有可能只需要做少量的甚至不做修改,实现在不同的测试过程中使用相同的用例。

      7、增加软件信任度。由于测试是自动执行的,所以不存在执行过程中的疏忽和错误,完全取决于测试的设计质量。一旦软件通过了强有力的自动测试后,软件的信任度自然会增加。

    • 自动化测试的缺点

​ 1、不能取代手工测试

​ 2、手工测试比自动测试发现的缺陷更多

​ 3、对测试质量的依赖性极大

​ 4、测试自动化不能提高有效性

​ 5、测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱,所以维护会受到限制,从而制约软件的开发。

​ 6、工具本身并无想像力

3.5 按照测试项目分类

  • 界面类测试。验证软件界面是否符合客户需求。
  • 安全性测试:软件遭受到没有授权的内部或外部用户的攻击或恶意破坏时如何进行处理,是否能保证软件与数据的安全。
  • 文档测试。以需求分析、软件设计、用户手册、安装手册为主,主要验证文档说明与实际软件之间是否存在差异。

3.6 其他分类

  • α测试

    • 软件上线之前进行的版本测试。由开发人员和测试人员或者用户协助进行测试。测试人员记录使用过程中出现的错误与问题,整个测试过程是可控的。
    • Alpha测试发现的错误,可以在测试现场立刻反馈给开发人员,由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始,或在模块(子系统)测试完成后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。
  • β测试

    • 软件上线之后进行的版本测试。由用户在使用过程中发现错误与问题并进行记录,然后反馈给开发人员进行修复。
    • Beta测试着重于产品的支持性,包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后,才能开始Beta测试。由于Beta测试的主要目标是测试可支持性,所以Beta测试应该尽可能由主持产品发行的人员来管理。
  • 回归测试。对修改后的程序重新进行测试,确认原有的缺陷已经消除并且没有引入新的缺陷,这个重新测试的过程就叫作回归测试。
  • 随机测试。没有测试用例、检查列表、脚本或指令的测试,它主要是根据测试人员的经验对软件进行功能和性能抽查。

4. 软件测试在项目各个阶段的作用

  • 项目规划阶段:负责从单元测试到系统测试的整个测试阶段的监控。
  • 需求分析阶段:确定测试需求分析,即确定在项目中需要测试什么,同时制定系统测试计划。
  • 概要设计与详细设计阶段:制定单元测试计划和集成测试计划。
  • 编码阶段:编写相应的测试代码和测试脚本。
  • 测试阶段:执行测试并提交相应的测试报告。

5. 常见的软件测试模型

5.1 V模型

  • 优点:将复杂的测试工作分成了目标明确的小阶段完成,具有阶段性、顺序性和依赖性,它既包含了对于源代码的底层测试也包含了对于软件需求的高层测试。
  • 缺点:只能在编码之后才能开始测试,早期的需求分析等前期工作没有涵盖其中,因此它不能发现需求分析等早期的错误,这为后期的系统测试、验收测试埋下了隐患。
    V模型流程图如下:

5.2 W模型

  • 优点:测试范围不仅包括程序,还包括需求分析、软件设计等前期工作,这样有利于尽早全面的发现问题。
  • 缺点:它将软件开发过程分成需求、设计、编码、集成等一系列的串行活动,无法支持迭代、自发性等需要变更调整的项目。
    W模型流程图如下:

5.3 H模型

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

  • 优点:

    • 开发的H模型揭示了软件测试除测试执行外,还有很多工作;
    • 软件测试完全独立,贯穿整个生命周期,且与其他流程并发进行;
    • 软件测试活动可以尽早准备、尽早执行,具有很强的灵活性;
    • 软件测试可以根据被测物的不同而分层次、分阶段、分次序的执行,同时也是可以被迭代的。
  • 缺点:

    • 管理型要求高:由于模型很灵活,必须要定义清晰的规则和管理制度,否则测试过程将非常难以管理和控制;
    • 技能要求高:H模型要求能够很好的定义每个迭代的规模,不能太大也不能太小;
    • 测试就绪点分析困难:测试很多的时候,你并不知道测试准备到什么时候是合适的,就绪点在哪里,就绪点的标准是什么,这就对后续的测试执行的启动带来很大困难;
    • 对于整个项目组的人员要求非常高:在很好的规范制度下,大家都能高效的工作,否则容易混乱。例如:你分了一个小的迭代,但是因为人员技能不足,使得无法有效完成,那么整个项目就会受到很大的干扰。
      H模型流程图如下:

5.4 X模型

设计原理:X模型的设计原理是将程序分成多个片段反复迭代测试,然后将多个片段集成再进行迭代测试。

  • 优点:对单独程序片段进行的相互分离的编码和测试,保证了测试效果。增加了探索测试,可以帮助测试人员发现计划之外的软件错误。
  • 缺点:频繁的集成会增加测试成本;探索测试对测试人员要求更高。
    X模型流程图如下:

v模型适用于中小企业,w模型适用于中大型企业(因为人员要求高) ,h模型人员要求非常高,很少有公司使用;结合W模型与H模型进行工作,软件各方面的测试内容是以W模型为准,而测试周期、测试计划和进度是以H模型为指导。X模型更多是作为最终测试、熟练性测试的模板,例如,对一个业务的测试已经有2年时间,则可以使用X模型进行模块化的、探索性的方向测试。

6. 软件测试的原则

(1) 测试应基于客户需求

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

(2) 测试要尽早进行和不断进行

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

(3) 穷举测试是不可能的

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

(4) 遵循GoodEnough原则

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

(5) 测试缺陷要符合“二八”定理

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

(6) 避免缺陷免疫

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

7. 软件测试的流程

不同类型的软件产品测试的方式和重点不一样,测试流程也会不一样。同样类型的软件产品,不同的公司所制定的测试流程也会不一样。虽然不同软件的详细测试步骤不同,但它们所遵循的最基本的测试流程是一样的。

(1) 分析测试需求

测试人员在制定测试计划之前需要先对软件需求进行分析,以便对要开发的软件产品有一个清晰的认识,从而明确测试对象及测试工作的范围和测试重点。在分析需求时还可以获取一些测试数据,作为测试计划的基本依据,为后续的测试打好基础。

此外,分析测试需求也是对软件需求进行测试,以发现软件需求中不合理的地方。

序号检查项检查结果说明

被确定的测试需求必须是可核实的,测试需求必须有一个可观察、可评测的结果。无法核实的需求就不是测试需求。测试需求分析还要与客户进行交流,以澄清某些混淆,确保测试人员与客户尽早地对项目达成共识。

(2) 制定测试计划

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

  • 确定测试范围:明确哪些对象是需要测试的,哪些对象不是需要测试的。
  • 制定测试策略:测试策略是测试计划中最重要的部分,它将要测试的内容划分出不同的优先级,并确定测试重点。根据测试模块的特点和测试类型(如功能测试、性能测试) 选定测试环境和测试方法(如人工测试、自动化测试) 。
  • 安排测试资源:通过对测试难度、时间、工作量等因素对测试资源合理安排,包括人员分配、工具配置等。
  • 安排测试进度:根据软件开发计划、产品的整体计划来安排测试工作的进度,同时还要考虑各部分工作的变化。在安排工作进度时,最好在各项测试工作之间预留一个缓冲时间以应对计划变更。
  • 预估测试风险:罗列出测试工作过程中可能会出现的不确定因素,并制定应对策略。
    (3) 设计测试用例

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

(4) 执行测试

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

(5) 编写测试报告

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

  • 引言:测试报告编写目的、报告中出现的专业术语解释及参考资料等。
  • 测试概要:介绍项目背景、测试时间、测试地点及测试人员等信息。
  • 测试内容及执行情况:描述本次测试模块的版本、测试类型,使用的测试用例设计方法及测试通过覆盖率,依据测试的通过情况提供对测试执行过程的评估结论,并给出测试执行活动的改进建议,以供后续测试执行活动借鉴参考。
  • 缺陷统计与分析:统计本次测试所发现的缺陷数目、类型等,分析缺陷产生的原因给出规避措施等建议,同时还要记录残留缺陷与未解决问题。
  • 测试结论与建议:从需求符合度、功能正确性、性能指标等多个维度对版本质量进行总体评价,给出具体明确的结论。
总结:测试报告的数据是真实的,每一条结论的得出都要有评价依据,不能是主观臆断的。

8. 参考资料

2021最网最全软件测试基础知识【建议收藏】 - 知乎 (zhihu.com)
软件测试知识点汇总_孤帆扁舟去的博客-CSDN博客


For you, a thousand times over!