测试设计中隐藏的边界有哪些？

概述：边界值分析是测试设计一个稳定的部分，但是对黑盒测试人员来讲有时候边界并不是那么明显。这些不明显的边界被称作隐藏的边界。本文提供几个隐藏的边界的例子，还有一些以让隐藏边界显露来设计测试计划的要点方法。

使用边界值分析和等价类划分是测试设计的基础做法之一。该理论的含义是对于一个特定的输入，测试中更常使用的值是在这些输入范围的边界附近的值。在边界之间的一类值当用到测试时常被认为是“等价的”。

举个例子，如果你的APP有一个功能是让输入一个价格的打折值，有效的范围很可能就是0百分比到100百分比。将要测试的值就会是那些在边界附近的值，或-1百分比，0百分比，100百分比和101百分比。你很可能也会选择测试一个“正常的”20%的折扣。如果那些工作正确，你不大可能通过测试其他可能的折扣值来发现缺陷。你在寻找在边界和超过边界的正确行为。

然而，有时候有些边界并不那么显而易见。我曾经因为隐藏的边界栽过跟头，导致缺陷跑到了顾客面前。这种情形不常有，但是当其出现时，我就会听到那个有魔力的话：“你没测过这个吗？”

在本篇文章中，我会详细叙述隐藏边界的几个引起因素：潜在的执行中的数据类型边界（比如，16比特数据类型到32比特数据类型）；信任边界，尤其是在一个重新设计或重构中；有特别含义的数据值和软件中有趣的边角。

Data-Type Boundaries数据类型边界

我测试过的一个电信管理平台有一个功能是在远程设备上配置不断变化的参数。其中一个参数有个范围是1到1024000。前端UI将这个参数储存在一个32位的整型数种并正确地处理了输入的验证和系统的行为，或者说期望的边界值（0，1，1024000和1024001）和几个会被顾客使用的正常值。我们并没有穷举式地测试每个值，因为在边界值之间的值被视作彼此都是等价的。

但是，在该管理平台和远程设备之间的通信网络有个协议将数据类型限制在16比特位。通信模块将32位的值撕成2个16比特的值并分开将他们传输。这是缺陷所在的地方。

当顾客将那个参数设置成65536，它就被通信模块设置成0。代码本应该将发送两个值作为该参数，65535和1。65535是16比特所能代表的最大数值。撕开该值的代码有一位的偏差；它尝试将65536放进那个16比特的值中。

65535和65536之间的边界在UI端部那么明显。它在软件说明书或测试计划中并没出现。只有参与做该设置理解整个系统的人这个边界才显而易见。

现在，当我看到一个要输入较大数值的数字型输入，我就会测试可能会出现的数据代表（256，65535和429467295）。

Trust Boundaries信任边界

软件架构的一个要义是定义信任区。如果一个客户请求来自信任区，接收的API接口可以认为这些请求没有恶意意图并可以略过一些输入验证。这对提高系统性能和开发者效率非常有用。

有一个项目，我们正在按照商议好的约定快速向通过 Web 服务的外部公司展露我们潜在的商业逻辑。这个项目称作服务启动并在大量将 Web 服务包装在我们已有的API请求附近。

这些API请求原来只对我们程序的内部模块提供，而且他们被设计做内部模块。结果，那些输入被认为是来自信任源。输入验证以节省编码和处理时间。

然而，对这个服务启动项目，有些 API 请求被暴露给了外部的请求者。“快乐路径”测试用例使用跟我们的程序一样的输入，一切都很好--直到我们开始从Web服务层面测试并对输入产生怀疑。

一个特定的字段在该 API 中有读和写的能力，但是逻辑上，它只应该有读的能力。该条商业逻辑基于来自数据库的数据来计算那个值。前端UI只读到了该值，但是当开发人员暴露那个API，我们能够写入那个值，将不一致的数据写入数据库。

任何时候信任边界移动或被假定了，就很有可能是有严重的缺陷。明确地与开发人员检查信任边界然后相应地设计测试计划是一个好的工作做法。

Special Data Values特殊数据值

很多APP对特殊数据值有特殊的行为。这些行为可能在软件说明书或者界面上不可见，但是他们可能导致缺陷。

一个系统对测试有特殊规定，使用一个唯一的由那个用户个人资料中的信用卡号和其他数据组成的组合来付款。本来是不要对测试人员和测试账号收款的。然而，你猜到了--一个有关特殊信用卡检查的缺陷导致很多顾客可以免费使用我们的服务。

这种现象并不普遍或者会有灾难性的后果，当然顾客们并不在意，但是它却将使用特殊处理过的数据来猜测该账户是测试账户的危险暴露了出来。一个更好的设计应当是明确将那些账户指定为测试账户。

Easter Eggs复活节彩蛋【软件中有趣的边角】

一个复活节彩蛋是建到一个APP里的有些特殊的功能--也许是一些有趣的事，像迷你游戏或有团队名称的信用卷。软件中的首个复活节彩蛋是在阿他瑞2600游戏毛线。如果游戏玩家拿起一个特定的不可见的物体，他们将进入一个秘密房间看到来自游戏创造者留的信息。这个房间不会在任何文档或测试中出现，因为没有人知道它。

复活节彩蛋很有趣，但是他们可能暴露系统的脆弱性，尤其是没有测试彻底的情况下。我见过的一个缺陷彩蛋是一个在特别的天里将我们在app上的正常品牌替换掉的特殊的标志。举个例子，在一个如独立日这样的节日里，该logo可能变化颜色有炮竹图像。尤其是除了那段时间它不工作，而用户看到的是一个404的错误。图像崩溃了，我们在发布之前没有那个特定的节日日期。

对隐藏边界可以做什么

基于隐藏边界的特性，他们难以发现，尤其是在黑盒测试里。随机地搜索隐藏边界是困难的而且有很少的成功可能。

但是，不是一切都迷失了。这里有一些可以处理隐藏边界的方法。

• ​参加设计评审，寻找数据类型的不匹配情形和任何数据转换的情形。询问有关转换的事情然后合适滴设计测试。

• ​对数字数据输入，测试由潜在的数据类型定义的潜在边界。

• ​学习代码包，寻找任何可能是复活节彩蛋的文件或资源。

• ​问开发人员可能存在的边界和任何复活节彩蛋。

隐藏边界的潜在存在给黑盒测试同行们充足的理由去测试程序中有些潜在的架构和执行。希望本篇文章启发你去探索你的程序并暴露出一些潜在的问题。

【整整200集】超超超详细的Python接口自动化测试进阶教程合集，真实模拟企业项目实战