最新测试设计中隐藏的边界有哪些？，大佬手把手教你如何仿写出大厂的APP

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化的资料的朋友，可以戳这里获取

但是，在该管理平台和远程设备之间的通信网络有个协议将数据类型限制在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的错误。图像崩溃了，我们在发布之前没有那个特定的节日日期。

对隐藏边界可以做什么

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

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

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**