为啥要测试这些数字 (2^16, 2^31 ....)

Posted 2023-02-25

【中文标题】为啥要测试这些数字 (2^16, 2^31 ....)

【英文标题】：Why test for these numbers (2^16, 2^31 ....)为什么要测试这些数字 (2^16, 2^31 ....)

【发布时间】：2012-08-10 23:32:28

【问题描述】：

通过Elisabeth Hendrickson's test heuristics cheatsheet，我看到以下建议：

数字 : 32768 (2^15) 32769 (2^15+ 1) 65536 (2^16) 65537 (2^16 [phone] (2^31) 2147483649 (2^ 31+ 1) 4294967296 (2^32) 4294967297 (2^32+ 1)

有人知道测试所有这些案例的原因吗？我的直觉与开发人员可能使用的数据类型有关（整数、长整数、双精度...）

类似地，使用字符串：

长（255、256、257、1000、1024、2000、2048 或更多字符）

【问题讨论】：

+1 获取有趣的备忘​​单！

【参考方案1】：

这些代表边界

整数

2^15 位于有符号 16 位整数的范围内 2^16 在无符号 16 位整数的范围内 2^31 位于有符号 32 位整数的边界 2^32 在无符号 32 位整数的范围内

测试接近公共边界的值测试是否正确处理了溢出（各种整数类型的算术溢出，或可能溢出缓冲区的长字符串的缓冲区溢出）。

字符串

255/256 处于可以用 8 位表示的数字的范围内 1024 位于可以用 10 位表示的数字的范围内 2048 位于可以用 11 位表示的数字的范围内

我怀疑诸如 255、256、1000、1024、2000、2048 之类的建议是基于经验/观察，一些开发人员可能会分配一个他们认为“无论如何都足够大”的固定大小的缓冲区并失败检查输入。这种态度导致buffer overflow attacks。

【讨论】：

2000 可能针对 URL 长度攻击。见Boutell。还有Dixon.

【参考方案2】：

这些数字是“整整”计算机数字的边界值（+1、0 和 -1），它们始终是 2 的幂。这些 2 的幂也不是随机的，而是表示整数精度的标准选择 - 8、16、32 等位宽。

【参考方案3】：

这些边界值接近最大有符号short、最大unsigned short 和int 相同。测试它们的原因是发现靠近典型数据类型边界值的错误。

例如您的代码使用带符号的short，并且您有一个测试，该测试恰好低于和高于此类类型的最大值。如果第一个测试通过而第二个测试失败，您可以很容易地判断出short 上的溢出/截断是原因。