【问题标题】：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 +1) 2147483648 (2^31) 2147483649 (2^ 31+ 1) 4294967296 (2^32) 4294967297 (2^32+ 1)
有人知道测试所有这些案例的原因吗？我的直觉与开发人员可能使用的数据类型有关（整数、长整数、双精度...）
类似地，使用字符串：
长（255、256、257、1000、1024、2000、2048 或更多字符）
【问题讨论】：
标签：
string
testing
numbers
integer
long-integer
【解决方案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。
【解决方案2】：
这些数字是“整整”计算机数字的边界值（+1、0 和 -1），它们始终是 2 的幂。这些 2 的幂也不是随机的，而是表示整数精度的标准选择 - 8、16、32 等位宽。
【解决方案3】：
这些边界值接近最大有符号short、最大unsigned short 和int 相同。测试它们的原因是发现靠近典型数据类型边界值的错误。
例如您的代码使用带符号的short，并且您有一个测试，该测试恰好低于和高于此类类型的最大值。如果第一个测试通过而第二个测试失败，您可以很容易地判断出short 上的溢出/截断是原因。