边界测试方法研究及应用

摘    要
   目前虽然软件产业内各方对软件测试越来越关注，但软件测试化理论大部分仍然停留在纸上，人们发现很多的理论很难在实践中得到运用。所以现在人们对软件测试的研究很多都面向那些能在实际项目中得到很好实践的技术的理论研究上。
本文以软件测试中黑盒测试的一个方法“边界值测试方法研究”为题目，首先介绍了软件测试的相关理论，并着重介绍了边界测试方法的研究理论，然后根据实际的项目，学生信息管理系统的功能测试对边界值测试方法进行分析，从而得出边界值测试方法作为一个理论研究与实际运用结合得很好的软件测试方法，它为我们在其他软件测试理论的研究与实际运用提供了很好的经验。

本文来自think58 [资料来源：THINK58.com]

[资料来源：http://think58.com]

关键词：软件测试，黑盒测试，边界值测试，等价划分
2 软件测试理论介绍
2.1 概述
软件测试是软件工程的一个重要部分，从测试的类型来看，测试分为2种：黑盒测试和白盒测试。
黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。
从测试实际的前后过程来看，软件测试是由一系列的不同测试所组成，这些软件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。确认测试验证软件的功能和性能及其它的特性是否与用户的要求一致，系统测试是在实际运行环境下进行一系列的测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的。
本章中我们主要是对软件测试的黑盒测试类型的理论进行介绍。黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。黑盒测试常用的方法包括等价划分法，边界值分析法，错误推测法，因果图等方法, 在实际测试中我们将综合运用这些测试方法进行测试。最后我们将介绍关于软件测试的术语,由于正文篇幅限制我们将其放在附录Ａ中，这些术语将对我们的研究软件测试和论文写作过程中提供帮助。 [资料来源：THINK58.com]
2.2 测试理论
2.2.1 软件测试基础
（1）测试目标
Glen Myers[MYE79]在他关于测试的优秀著作中陈述了一系列可以服务于软件测试目标的规则：
● 测试是一个为了发现错误而执行程序的过程。
● 一个好的测试案例是指很可能找到迄今为止尚未发现的错误的案例。
● 一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。
上述目标隐含了一个观点上的戏剧性变化,他们和通常的观点(既一个成功的测试是指没有找到错误的测试)正好相反。我们的目标是设计这样的测试，他们能够系统的揭示不同类型的错误并且耗费最少时间和最小工作量。
如果成功构造了测试（根据上面陈述目标），则能够在软件中揭示错误。测试的第二个好处在于他证实了软件依据规约所具有的功能及其性能需求，此外，构造测试时的数据收集提供了软件可靠性以及软件整体质量的一些信息。但是，有一件事测试无法完成：测试无法说明错误和缺陷不存在，它只能表示错误和缺陷已经出现。
(2)测试原则
在设计有效的测试案例之前，软件工程师必须理解指导软件测试的基本原则。Davis[DAV95]提出了一组测试原则：
● 所有的测试都应可以追溯到客户需求。正如我们所知，软件测试的目标在于发现错误。而最严重的错误（从客户角度看）是那些导致程序无法满足需求的错误。

[版权所有：http://think58.com]

● 应该在测试工作真正开始前较长时间就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试案例定义可以在设计模型被确定后立即开始，因此，所有的测试可以在任何代码产生前就被计划和设计。
● Pareto原则可以应用于软件测试。简单而言，Pareto原则暗示着测试发现的错误中的80%很可能起源于程序模块中的20%。当然，问题在于分离这些有疑点的模块并进行彻底的测试。
● 测试应从“小规模”开始，逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
● 穷举测试是不可能的。甚至在一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑并确保使用程序设计中的所有条件是有可能的。
为了达到最有效，应该由独立的第三方来构造测试。“最有效”指发现错误的可能性最高的测试（测试的主要目标）。
(3)可测试性
在理想的情况下，软件工程师在设计计算机程序、系统或产品时因该考虑可测试性，这就使得负责测试的人能够更容易设计有效的测试案例，但是什么是“可测试性”呢？James Bach以下面的方式描述可测试性。

think58.com

[资料来源：www.THINK58.com]

软件可测试性就是一个计算机程序能够被测试的容易程度。因为测试是如此的困难，因此，需要知道做些什么才能使测试过程理顺。有时，测试员愿意去做对于测试过程有帮助的事，而一个包括可能的设计点、特性等等的检查表对他们是有用的。
肯定存在可用于在很多方面测量可测试性的度量，有时可测试性被用来表示一个特定测试集覆盖产品的充分程度。在军方还用它来表示工具被检验和修复的容易程度。这两种意义都略不同于软件可测试性。下面的检查表提供了一组导致可测试软件的特征：
可操作性:
● 系统的错误很少（错误增加测试过程中的分析和报告的开销）。
● 没有阻碍测试执行的错误。
● 产品的功能阶段演化（允许同时开发和测试）。
可观察性:
● 每个输入有唯一的输出。
● 系统状态和变量可见或在运行中可查询。
● 过去的系统状态和变量可见或在运行中可查询（如：事务日志）。
● 所有影响输出的因素都可见。
● 容易识别错误的输出。
● 通过自测机制自动检测内部错误。
● 自动报告内部错误。
● 可获取原代码。
可控制性：
● 所有可能的输出都产生与某种输入组合。
● 通过某种输入组合，所有代码都可能被执行。 [资料来源：THINK58.com]
● 测试工程师可直接控制硬件和软件的状态及变量。
● 输入和输出格式保持一致且是结构化的。
● 能够便利的对测试进行刻画，自动化和再生。
可分解性：
● 软件系统由独立模块构成。
● 能够独立测试各软件模块。
简单性：
● 功能简单性。
● 结构简单性。
● 代码简单性。
稳定性：
● 软件的变更是不经常的。
● 软件的变更是可控制的。
● 软件的变更不影响已有的测试。
● 软件失效后得到良好恢复。
易理解性：
● 设计能够被很好的理解。
● 内部，外部和共享构件之间的依赖性能够被很好的理解。
● 设计的变更被通知。
● 可随时获取技术文档。
● 技术文档组织合理。
● 技术文档明确详细。
● 技术文档保持精确性。
软件工程师可以运用James Bach提出的这些属性来开发可测试的软件配置（即程序，数据和文档）。但关于测试本身呢？Kaner ,Falk和Nguyen[KAN93]给出“好”测试的一些属性：
● 一个好的测试发现错误的可能性很高。为了达到这个目标，测试者必须理解软件并尝试设想软件如何才能失败，理想的，故障的类型被探测。

copyright think58

[资料来源：http://THINK58.com]

think58.com [资料来源：THINK58.com]

[资料来源：http://think58.com]