软件工程 系统测试概述

文章目录

  • 概述
    • 测试过程
  • 软件测试策略
    • 单元测试
      • 测试内容
      • 测试方法
    • 集成测试
    • 确认测试
      • α测试与β测试
    • 系统测试

概述

系统测试是为了发现错误而执行程序的过程,成功的测试是发现了至今尚未发现的错误。测试的目的就是希望能以最少的人力和时间发现潜在的各种错误和缺陷。

系统测试应包含软件测试、硬件测试和网络测试,但后面更多的是软件测试。系统测试是保证系统质量和可靠性的关键,是对系统开发过程中的系统分析、设计、实施的最后复查,根据测试的概念和目的,在进行系统测试时赢遵循以下基本原则:

  1. 应尽早并不断地进行测试,测试不是在系统开发完之后才进行的。开发的各个阶段都有可能出现错误,因此测试应贯穿在开发的各个阶段。
  2. 测试工作应避免由原开发人员或小组承担,因为开发人员往往不愿否认自己的工作,另一方面开发人员很容易按照自己编程的思路来制定测试,具有局限性。
  3. 在设计测试方案时,不仅要确定输入数据,而且要根据系统功能来给出预期的输出结果。
  4. 在设计测试用例时,不仅要设计有效、合理的输入条件,也要包含不合理、失效的输入条件。
  5. 在测试程序时,不仅要检验程序是否做了该做的事情,还要关注程序是否做了不该做的事情。
  6. 严格按照测试计划进行,避免测试随意性。
  7. 妥善保存测试计划、测试用例,作为软件文档的组成部分。
  8. 测试例子都是精心设计出来的,可以为重新测试或追加测试提供基础。

测试过程

一个规范化的测试过程通常包含如下基本活动:

  1. 制定测试计划

    充分考虑项目的开发时间和进度及其他客观因素来制定测试,使测试是可行的。计划内容主要有测试项目、进度安排、测试环境等内容。

  2. 编制测试大纲

    大纲是测试活动的依据,它明确的规定了测试中针对系统的每一项功能或者特性所需完成的基本测试项目和测试标准。

  3. 根据测试大纲设计生成测试用例,产生测试设计文档

    其中主要的是文档,它主要的内容有被测的项目、输入数据、测试过程和预期输出。

  4. 实施测试

    测试的实施由一系列的测试周期组成,每个测试周期中测试人员都会依据测试大纲和测试用例对软件进行完整的测试。

  5. 生成测试报告

    测试完成后需要形成对应的报告,用以对测试进行说明,列出测试得出的结论,指出其中的错误和缺陷。另外还可以提出建议等。

软件测试策略

测试策略指的是周密性的测试计划,一个测试策略必须包含测试计划、测试用例设计、测试执行及结果收集和评估。软件测试的策略应该具有足够的灵活性,以便促成测试方法的指定,同时又必须足够严格,能对项目进行准确的追踪。

有效的测试一般分为4步进行,下面简单介绍一下。

单元测试

又称为模块测试,在模块编写完成后且成功编译后就可以进行,单元测试主要侧重于模块中的逻辑和数据结构,一般使用白盒测试法,单元测试可以对多个模块同时进行。

测试内容

主要测试模块的5个特征:

  1. 模块接口——接口保障的是数据的流出流入

    • 输入参数与形式参数在个数、属性、单位上是否一致
    • 模块内调用其他模块时,给出的参数是否一致
    • 调用标准函数时,参数是否正确
    • 全局变量在各模块的定义是否一致
    • 输入是否仅改变了形式参数
    • 开关语句是否正确
    • 规定的I/O格式是否正确
    • 文件、内存等是否被正确的关闭、清理
  2. 数据结构——局部的数据结构错误是比较常见的错误

    • 变量说明是否准确
    • 是否存在使用未初始化变量
    • 变量默认值是否正确
    • 变量名是否存在拼写错误
  3. 执行路径——路径测试是一种基本任务,确保覆盖核心路径

    由于实际中难以对每一条路径都穷举测试,因此需要进行的设计测试用例以发现计算及控制流方面的错误。

    • 算术优先次序是否正确,精度是否足够,运算对象的类型是否合适,算法是否准确
    • 逻辑运算符次序是否正确,循环终止是否正确,是否存在死循环,分支循环时出口是否正确
  4. 出错处理——好的设计应该能预测出错并提供合理的处理方法

  5. 边界条件——边界错误是编程中最常见的错误

测试方法

由于模块都不是独立运行的程序,各模块之间存在调用与被调用的关系,因此在对每个模块进行测试时,需要开发两种模块:

  1. 驱动模块,相当于主程序,它负责接收测试用例,并送至测试模块,回报输出结果。
  2. 桩模块,用来替代被测模块所调用的其他子模块,实现一个完全可控的测试。

通过驱动模块和桩模块将被测模块隔离,能完全控制各种情况的发生,从而更准确的测试模块的行为。

提高模块的内聚度可以有效的简化单元测试,如果一个模块只实现一个功能,那测试方案和数据的设计难度都会降低,而且更容易捕捉模块发生的错误。

集成测试

所谓集成测试就是将模块那系统设计说明要求,组合成一个整体进行测试。因为即使各个模块都通过了单元测试,仍然有可能在集成后出现问题。集成测试是构造软件体系结构的系统化技术,主要是为了发现与接口相关的错误。

通常,集成测试有两种方式: 非增量集成增量集成 。前者就是分别测试各模块,再组合起来进行整体测试;而后者则是不断的往整体中添加模块来运行测试;非增量的好处在于可以与单元测试并行测试,但容易产生混乱,可能出现难以定位错误的问题。后者由于逐步扩大,因此更容易定位错误,且能更好的对接口进行充分的测试,并应用系统化的测试方法。下面简单介绍一些增量集成的方法:

  1. 自顶向下

    模块的集成顺序由主控模块开始,沿着控制层逐渐往下,以深度优先或广度优先的方法将从属模块集成至系统中测试。简单的来说流程如下:

    • 将主控模块作为测试驱动模块,用桩模块替换所有从属模块。
    • 根据深度优先或广度优先的原则,每次用一个实际模块替换一个桩模块。
    • 每替换进来一个实际模块均执行一遍测试集。
    • 完成后接着用另一个实际模块替换另一个桩模块,以此类推,直至整个系统继承完毕。
    • 在这个过程中,可以执行回归测试。
  2. 自底向上

    这个与自顶向下方法是逆向的,它是从最底层构件开始集成。但略有不同的是,自底向上的方法按完成特定功能的簇为单位,在其之上放置驱动模块来实现的。最后再将各个簇集成即可。

    相对于自顶向下来说,需要编写的测试代码更少,每个簇只需要一个驱动模块,而不是每个模块都需要对应的桩模块。

  3. 回归测试

    每次集成一个新模块时,系统都发生了变更,这些变更可能导致原本正常的功能产生错误。因此回归测试就是再次执行已经执行过的测试集,以确保变更没有产生预期之外的副作用。

    回归测试有助于保证不出现无意识行为导致额外的错误,主要包含3种类型的测试用例:

    • 可以测试软件整体功能并具有代表性的测试用例
    • 可能会受变更影响的部分的测试用例
    • 着重测试发生变更的模块的测试用例

    随着集成的进行,如果总是重新测试所有已经执行过的测试集,则回归测试集最终可能变得非常庞大,这是不现实的,因此回归测试的测试用例应当只着重于核心功能的测试。

  4. 冒烟测试

    这是一种非常常见的测试方法,来自于电子工程领域,指的是当电路发生变更后,直接上电,如果短路冒烟了则证明改动出现了问题。可见这是一种测试耗时短的测试方式。

    基本方式就是每天都构建整个软件产品并进行冒烟测试,期望尽早发现问题。

确认测试

当集成测试完成后就可以进行确认测试了,确认测试主要集中于用户可见和可识别的系统输出,即是软件系统的整体行为。

通过针对软件需求或规格说明来制定测试用例,确保软件系统的行为与需求或规格说明吻合。另外一方面,确认测试也要关注软件系统的配置评审工作,即检查软件、文档、数据是否齐全有序。

α测试与β测试

软件作为一种产品,由多个用户使用,但想让所有用户都进行正式的测试是不切实际的,因此多数软件开发者都使用 α , β \alpha , \beta α,β测试来查找似乎只有最终用户才能发现的错误。

α \alpha α测试是由有代表性的最终用户在开发者的场所进行,软件在一般的环境下使用,开发者全程观看,并记录错误和使用问题。

β \beta β(beta)测试是在一个或多个最终用户的场所中进行,这种测试开发者通常不在现场,由最终用户记录测试过程中的所有问题并定期向开发者报告。这也是现在很多软件都经历过的测试方式。

β \beta β测试的一个变体称为客户验收测试,由客户执行一系列特定的测试,试图在正式验收前发现错误。验收测试的表现可能是非常正式的,有时候甚至会测试数个星期。

系统测试

系统测试是将已经确认的软件与计算机硬件、网络、外部设备等其他因素结合在一起进行的测试,这是一种贴近实际使用环境的测试。目的是发现系统整体是否与用户需求不符。

  1. 恢复测试

    多数计算机系统必须有能力在发生错误后的一定时间内恢复运行,有些系统甚至要要求高容错能力,即处理错误不能使整个系统都停止运行。

    恢复测试就是一种系统测试,通过各种方式强制让系统出现故障,并验证是否能从故障中恢复,并在约定时间内恢复运行,并且不造成任何损害。如果系统具备自我恢复的能力,则需要重新验证数据是否正确。如果是由人工干预的恢复,则要对恢复平均耗时进行评估。

  2. 安全性测试

    在这种测试中,测试人员模拟非法入侵者,采取不同的方法尝试突破系统,安全性测试的准则是确认进行非法入侵所要花费的代价是否大于系统被攻破后泄露信息的价值。

  3. 压力测试

    以非正常的数量、频率或容量等方式执行,使系统在大幅超出设计指标的情况运行以观察结果。本质上来说,压力测试也是要试图破坏软件系统以观察系统的行为。

    另外有个变体称为敏感性测试,即在有效数据界限之内的一小部分可能会引起极端情况,甚至是产生错误。敏感性测试就是试图在有效的数据界限之中找到会引发系统不稳定的数据组合。

  4. 性能测试

    在很多系统中,仅能提供所需功能但不符合性能要求是不能接受的,性能测试就是注重于测试运行的性能。性能测试也可以在任一开发过程中进行,如单元测试中进行以测试模块性能。但通常而言,只有当整个系统完全集成后的性能测试才能确定软件系统的真实性能。

    性能测试常常与压力测试一同进行,而且需要硬件和软件作为工具。以严格的方式监控处理器、内存等各种资源的利用量。通过这样的方式,测试人员就可以发现什么情况下会导致效率降低甚至故障。

  5. 部署测试

    也称为配置测试,是将软件在将要运行的每一种环境中执行的测试。另外还要检查面向客户的所有安装程序和文档。

你可能感兴趣的:(软件工程)