概述：边界值分析是测试设计一个稳定的部分，但是对黑盒测试人员来讲有时候边界并不是那么明显。这些不明显的边界被称作隐藏的边界。本文提供几个隐藏的边界的例子，还有一些以让隐藏边界显露来设计测试计划的要点方法。
使用边界值分析和等价类划分是测试设计的基础做法之一。该理论的含义是对于一个特定的输入，测试中更常使用的值是在这些输入范围的边界附近的值。在边界之间的一类值当用到测试时常被认为是"等价的"。
举个例子，如果你的APP有一个功能是让输入一个价格的打折值，有效的范围很可能就是0百分比到100百分比。将要测试的值就会是那些在边界附近的值，或-1百分比，0百分比，100百分比和101百分比。你很可能也会选择测试一个"正常的"20%的折扣。如果那些工作正确，你不大可能通过测试其他可能的折扣值来发现缺陷。你在寻找在边界和超过边界的正确行为。
然而，有时候有些边界并不那么显而易见。我曾经因为隐藏的边界栽过跟头，导致缺陷跑到了顾客面前。这种情形不常有，但是当其出现时，我就会听到那个有魔力的话："你没测过这个吗？"
在本篇文章中，我会详细叙述隐藏边界的几个引起因素：潜在的执行中的数据类型边界（比如，16比特数据类型到32比特数据类型）；信任边界，尤其是在一个重新设计或重构中；有特别含义的数据值和软件中有趣的边角。
数据类型边界
我测试过的一个电信管理平台有一个功能是在远程设备上配置不断变化的参数。其中一个参数有个范围是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）。
信任边界
软件架构的一个要义是定义信任区。如果一个客户请求来自信任区，接收的API接口可以认为这些请求没有恶意意图并可以略过一些输入验证。这对提高系统性能和开发者效率非常有用。
有一个项目，我们正在按照商议好的约定快速向通过Web服务的外部公司展露我们潜在的商业逻辑。这个项目称作服务启动并在大量将Web服务包装在我们已有的API请求附近。
这些API请求原来只对我们程序的内部模块提供，而且他们被设计做内部模块。结果，那些输入被认为是来自信任源。输入验证以节省编码和处理时间。
然而，对这个服务启动项目，有些API请求被暴露给了外部的请求者。"快乐路径"测试用例使用跟我们的程序一样的输入，一切都很好--直到我们开始从Web服务层面测试并对输入产生怀疑。
一个特定的字段在该API中有读和写的能力，但是逻辑上，它只应该有读的能力。该条商业逻辑基于来自数据库的数据来计算那个值。前端UI只读到了该值，但是当开发人员暴露那个API，我们能够写入那个值，将不一致的数据写入数据库。
任何时候信任边界移动或被假定了，就很有可能是有严重的缺陷。明确地与开发人员检查信任边界然后相应地设计测试计划是一个好的工作做法。
特殊数据值
很多APP对特殊数据值有特殊的行为。这些行为可能在软件说明书或者界面上不可见，但是他们可能导致缺陷。
一个系统对测试有特殊规定，使用一个唯一的由那个用户个人资料中的信用卡号和其他数据组成的组合来付款。本来是不要对测试人员和测试账号收款的。然而，你猜到了--一个有关特殊信用卡检查的缺陷导致很多顾客可以免费使用我们的服务。
这种现象并不普遍或者会有灾难性的后果，当然顾客们并不在意，但是它却将使用特殊处理过的数据来猜测该账户是测试账户的危险暴露了出来。一个更好的设计应当是明确将那些账户指定为测试账户。
... ...
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第四十九期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
