软件工程讲义_第12章 软件测试策略解析

《软件工程讲义_第12章 软件测试策略解析》由会员分享，可在线阅读，更多相关《软件工程讲义_第12章 软件测试策略解析（87页珍藏版）》请在金锄头文库上搜索。

1、现代软件工程 第12章 软件测试策略 主要内容 v软件测试的策略性方法 v策略问题 v传统软件的测试策略 v面向对象软件的测试策略 v确认测试 v系统测试 v调试技巧 v小结 软件测试策略 v软件测试的目的是为了发现软件设计和 实现过程中的疏忽所造成的错误。但是， 如何进行测试？是否应该制定正式的测试 计划？是应该将整个程序作为一个整体来 测试，还是应该只测试其中的一部分？当 向一个大型系统加入新的构件时，是否需 要重新测试已经测过的部分？什么时候需 要客户介入测试工作？当制定测试策略时 ，就需要回答上述及其他一些问题。 软件测试策略 v测试所花费的工作量经常比其他任何软 件工程活动都多。若测

2、试是无计划地进行 ，既浪费时间，又浪费不必要的劳动。甚 至更糟的是，错误会依然存在。因此，为 测试软件建立系统化的测试策略是合情合 理的。 软件测试策略 v 测试从“小规模”开始，进展到“大规模” 。这意味着，早期的测试关注单个构件或 相关的一小组构件，利用测试发现构件中 的数据和处理逻辑错误。当单个的构件被 测试完后，需要将构件集成直到建成整个 系统。这时，执行一系列的高阶测试以发 现在满足顾客需求方面的错误。随着错误 的发现，必须利用调试过程进行诊断和纠 正。 软件测试策略 v测试规格说明是将软件测试团队的测试 具体作法文档化。这主要包括制定描述整 体策略的计划、定义特定测试步骤的规程 以

3、及规定将要进行的测试。 v通过在测试进行之前评审测试规格说明 ，可以评估测试用例以及测试任务的完整 性。有效的测试计划和规程将导致软件的 有规则地构造，并且能够发现构造过程中 各个阶段引入的错误。 软件测试策略 v软件测试策略将软件测试用例的设计方 法集成到一系列经周密计划的步骤中去， 从而使软件构造成功地完成。测试策略提 供以下方面的路径图：描述将要进行的测 试步骤，这些步骤计划和执行的时机，需 要多少工作量、时间和资源。因此，任何 测试策略都必须包含测试计划、测试用例 设计、测试执行以及测试结果数据的收集 与评估。 软件测试的策略性方法 v测试是可以事先计划并可以系统地进行 的一系列活动。

4、因此，应该为软件过程定 义软件测试模板，即将特定的测试用例设 计技术和测试方法放在一系列的测试步骤 中去。 v为完成有效的测试，软件团队应该进行 有效的、正式的技术评审。通过评审，许 多错误可以在测试开始之前排除。 v测试开始于构件层，然后向外“延伸”到 整个基于计算机系统的集成。 软件测试的策略性方法 v不同的测试技术适用于不同的时间点。 v测试由软件开发人员和（对大型项目而言）独立的测 试组执行。 v测试和调试是不同的活动，但任何测试策略中都必须 包括调试。 v软件测试策略必须提供用来验证小段源代码是否正确 实现的必要的低级测试，以及用来确认系统的主要功能 是否满足用户需求的高级测试。软件

5、测试策略必须为专 业人员提供工作指南，同时，为管理者提供一系列的里 程碑。由于测试策略的步骤是在软件完成的最后期限的 压力已逐步呈现的时候才开始进行的，因此，测试的进 度必须是可测量的，应该让问题尽可能早地暴露。 验证与确认 v软件测试是通常所讲的更为广泛的主题 验证与确认的一部分。验证是指确保软件正 确地实现某一特定功能的一系列活动。确认 则指的是确保开发的软件可追溯到用户需求 的另外一系列活动。BOE81用另一种方式 说明了这两者的区别： 验证：我们在正确地构造产品吗？ 确认：我们在构造正确的产品吗？ v验证和确认包含了广泛的SQA活动，其中 包括正式技术评审、质量和配置审核、性能 监控、

6、仿真、可行性研究、文档评审、数据 库评审、算法分析、开发测试、易用性测试 、合格性测试以及安装测试。 验证与确认 v测试确实为软件质量的评估提供最后的防线。 在软件工程的整个过程中，质量体现在软件之中 。在测试过程中，方法和工具的正确运用、有效 的正式技术评审、稳固的管理与测量，都有助于 得到让人认可的质量。 vMIL77将软件测试和质量保证联系在一起， 他认为：“无论是大规模系统还是小规模系统， 程序测试的根本动机都是使用经济且能有效应用 的方法来认可软件质量。” 软件测试的组织 v对每个软件项目而言，在测试开始时总 会在不同人员之间存在认识上的差异。这 时要求开发软件的人员对该软件进行测试

7、 。 v从心理学的观点来看，软件分析和设计 是建设性的任务。以开发者的观点来看， 测试可以认为是破坏性的。因此，开发者 精心地设计和执行测试，试图证明其程序 的正确性，而不是注意发现错误。遗憾的 是，错误是存在的，而且，如果软件工程 师没有找到错误，用户也会发现。 软件测试的组织 v人们可能会产生误解:(1)软件开发人员根本不 应该做测试；(2)应当让那些无情地爱挑毛病的 陌生人做软件测试；(3)测试人员仅在测试步骤 即将开始时参与项目。这些想法都是不正确的。 v软件开发人员总是要负责程序的个别单元的测 试，确保每个单元完成其功能或显示出被设计的 行为。在多数情况下，开发者也进行集成测试。 集

8、成测试是其中一个测试步骤，它将给出整个软 件体系结构的构造。只有在软件体系结构完成后 ，独立的测试组才开始介入。 软件测试的组织 v独立测试组ITG的作用是为了避免开发人员进行测试 所引发的固有问题。独立测试可以消除可能存在的认识 差异。 v然而，软件开发人员并不是将程序交给独立测试组就 可以一走了之。在整个软件项目中，开发人员和测试组 密切配合以确保测试严格地进行。在测试进行的过程中 ，必须随时可以找到开发人员，以便及时修改发现的错 误。 v从分析与设计开始到计划和制定测试规程，ITG参与 整个项目过程。从这种意义上讲，ITG是大型软件开发 项目组的一部分。然而，在多数情况下，ITG直接对软

9、 件质量保证组织负责，由此获得一定程度的独立性。若 ITG是软件工程组织的一部分，则这种独立性是不可能 获得的。 传统软件体系结构的测试策略 v软件过程可以看作图12-1所示的螺旋。开始时系 统工程定义软件的角色，从而引出软件需求分析， 在需求分析中建立软件的信息域、功能、行为、性 能、约束和确认标准。沿着螺旋向内，经过设计阶 段，最后到达编码阶段。为开发计算机软件，沿着 流线螺旋前进，每走一圈都会降低软件的抽象层次 。 传统软件体系结构的测试策略 图12-1 测试策略 传统软件体系结构的测试策略 v软件测试策略也可以放在螺旋模型中来考虑。单 元测试起始于螺旋的旋涡中心，侧重于以源代码形 式实

10、现的每个单元（即构件）。沿着螺旋向外，就 是集成测试，这时的测试重点在于软件体系结构的 设计和构造。沿着螺旋向外再走一圈，就是确认测 试，在这个阶段，依据已经建立的软件，对需求进 行确认。最后到达系统测试阶段，将软件与系统的 其他成分作为一个整体来测试。为了测试计算机软 件，沿着流线向螺旋前进，每转一圈都拓宽了测试 范围。 传统软件体系结构的测试策略 v以过程的观点考虑整个测试过程，软件 工程环境中的测试实际上就是按顺序实现 四个步骤，如图12-2所示。 图12-2 软件测试步骤 传统软件体系结构的测试策略 v最初，测试侧重于单个构件，确保它完全作为一个单 元来起作用，因此称之为单元测试。单元

11、测试充分利用 测试技术，检查构件中每个控制结构的特定路径以确保 完全覆盖，并最大可能地发现错误。接下来，组装或集 成各个构件以形成完整的软件包。集成测试处理并并验 证与程序构造相关的问题。在集成过程中，普遍使用关 注输入和输出的测试用例设计技术。在软件集成完成之 后，要执行一系列的高阶测试，必须评估确认准则。确 认测试为软件满足所有的功能、行为和性能需求提供最 后的保证。 v最后高阶测试这一步已经超出软件工程的边界，进入 更为广泛的计算机系统工程的范围。软件一旦确认，就 必须与其他系统成分结合在一起。系统测试验证所有的 成分能合适地结合在一起，且能满足整个系统的功能/性 能需求。 面向对象软件

12、体系结构的测试策略 v面向对象系统的测试为软件工程师提出 了不同的挑战。测试的定义必须拓宽以包 括运用于分析和设计模型中的错误发现技 术。当建立面向对象表示时，必须评估其 完整性和一致性。单元测试已失去其部分 意义，而且集成策略也发生了很大变化。 总而言之，测试策略和测试战术都必须考 虑面向对象软件的特有特征。 面向对象软件体系结构的测试策略 v面向对象软件测试的总体策略在思想上与用于 传统体系结构的策略是一致的，但测试方法是不 同的。从“小型测试”开始，逐步走向“大型测试” 。然而，当进行“小型测试”时，重点由单个模块 测试变换为包含属性和操作且隐含着通信与协作 的类的测试。随着将类集成为一

13、个面向对象体系 结构，运行一系列的集成测试以发现由于类间的 通信与协作产生的错误以及新类的加入而引起的 副作用。最后，作为一个整体来测试系统，以确 保发现需求中的错误。 测试完成的标准 v每当讨论软件测试时，就会引出一个标 准问题：测试什么时候才算做完？怎么知 道我们已做了足够的测试？ v对上述问题的一个答复是：你永远也不 能完成测试，这个担子只会从你（软件工 程师）身上转移到你的客户身上。客户/ 用户每次运行计算机程序时，程序就在经 受测试。 v另一个答复是：当你的时间或资金不够 时，测试就完成了。 测试完成的标准 v尽管少数实践者会对这些答复产生异议，但是 软件工程师需要更严格的标准以确定

14、什么时候已 经做完充足的测试。MUS89提出了一个基于 统计标准的答复：“不，我们不能绝对地认为软 件从不失败，但相对于一个理论上正确的、经过 实践验证的统计模型而言，如果在按照概率方法 定义的环境中，1000个CPU小时内无故障运行 的概率大于0.995，那么我们就有95%的信心 说已经进行了足够的测试“。利用统计建模和软 件可靠性理论，可以建立以执行时间为函数的软 件故障模型。 策略问题 v如果想实现一个成功的软件测试策略， 必须解决下述问题： v早在开始测试之前，就要以量化的方式 规定产品需求。尽管测试的主要目的是查 找错误，但是一个好的测试策略也能评估 其他质量特性，如可移植性、可维护

15、性和 易用性。这些都应该以可测量的方式加以 规定，从而保证测试结果的无歧义性。 策略问题 v显式地陈述测试目标：测试的特定目标应该用可测量 的术语进行陈述。例如，测试的有效性、测试的覆盖率 、故障出现的平均时间、发现和修正缺陷的成本、剩余 缺陷的密度或出现频率、每次回归测试的工作时间，这 些都应当在测试计划中清晰地描述。 v了解软件的用户并为每类用户建立用户轮廓。为每类 用户描述交互场景的用例，侧重于测试产品的实际使用 ，可以减少整个测试的工作量。 v建立强调”快速周期测试“的测试计划。GIL95建议 软件工程团队“对客户有用的功能增量和(或)质量改进， 学会以快速周期进行测试。“。从这些快速

16、周期测试中得 到的反馈可用于控制质量的等级和相应的测试策略。 策略问题 v建立能够测试自身的“健壮”软件。软件 应该利用防错技术进行设计。也就是说， 软件应该能够诊断某类错误。另外，软件 设计应该包括自动化测试和回归测试。 v测试之前，利用有效的正式技术评审作 为过滤器。在发现错误方面，正式技术评 审与测试一样有效。因此评审可以减少生 产高质量软件所需的测试工作量。 策略问题 v实施正式技术评审以评估测试策略和测 试用例本身。正式技术评审能够发现测试 方法中的不一致、遗漏和明显的错误。这 节省了时间，也提高了产品质量。 v为测试过程建立一种持续的改进方法。 测试策略应该是可以测量的。测试过程中 收集的度量数据应当作为软件测试的统计 过程控制方法的一部分。 传统软件的测试策略 v许多策略可用于测试软件。其中一个极端是， 软件团队等到系统完全建成后对整个系统执行测 试以期望发现错误。这种方法尽管比较受欢迎， 但效果不好；可能给出的是包含许多缺陷的软件 ，致使