你真的会比较版本号吗？我因为“3.9.0 > 3.11.0”翻了车

✍️ 前言：一个不起眼的 bug，背后的大坑

在一次测试任务中，我需要验证某段逻辑是否在不同版本范围内正确生效。逻辑中涉及版本号对比，我最初随手用了几个测试数据，比如 3.1.0、3.2.0、3.5.2，对比结果都符合预期，测试自然也通过了。

直到某一天我用上了 3.9.0 和 3.11.0，结果却让我一脸问号：系统竟然认为 3.9.0 > 3.11.0？

找开发一查，果然，代码中做版本比较的方式出了问题。他们直接把版本号当成字符串来比较，导致在“9”和“11”之间，字符串认为 "9" > "11"，从而出现了错误判断。

🚨 问题复现：版本号字符串比较的坑

很多人觉得版本号像字符串一样写着，直接 if version1 > version2 不就行了吗？

来看看以下 Python 例子：

print("3.9.0" > "3.11.0")  # True ❌

这是 错误的比较方式。因为字符串是按字符顺序逐位比较的：

  • 第一位都一样（3）
  • 第二位 “9” 和 “1”，因为字符串中 “9” > “1”，比较就停止了，返回 True

这根本不是真正意义上的版本号比较。

✅ 正确做法：逐位数字对比

版本号的正确比较方式是将它按 . 分割后，逐段转成整数进行对比。
例如，3.9.0 应该变成 [3, 9, 0]，3.11.0 变成 [3, 11, 0]，再逐位比较。

以 Python 为例：

def compare_versions(v1, v2):
    parts1 = list(map(int, v1.split(".")))
    parts2 = list(map(int, v2.split(".")))
    return parts1 > parts2

print(compare_versions("3.9.0", "3.11.0"))  # False ✅

其他语言也有类似的方法，甚至很多主流语言已经提供了内建或库级支持，比如：

  • Python：packaging.version.parse 或 distutils.version.LooseVersion
  • Java：ComparableVersion（Apache Maven）、自定义 Version 类
  • JavaScript：可使用 semver 库
  • Go：github.com/hashicorp/go-version

🧪 作为测试人员，这些细节不能忽视

这次经历给了我几个很重要的启发，尤其是在测试场景中：

1. 测试数据不能只覆盖个位版本

用 3.1.0、3.2.0 是远远不够的，必须包含：

  • 跨位数（如 3.9.0 vs 3.10.0、3.11.0）
  • 不同 patch 位数（如 3.9.0 vs 3.9.1）
  • 相同主版本不同子版本组合

2. 需主动核查开发的版本比较逻辑

如果你发现逻辑里存在版本判断，不要默认它是对的！建议直接问开发是按什么规则比的？字符串？数字？有没有用库？

3. 建议团队引入标准版本比较库

如果语言本身没有明确的处理方案，建议团队统一引入类似 semver、LooseVersion 这样的工具，避免重复踩坑。

4. 边界值要测足够

不只是 3.9.0 和 3.11.0，你还可以设计一些特殊情况，比如：

  • 不同长度（3.9 vs 3.9.0.0）
  • 补零（3.09.0 vs 3.9.0）
  • 带前缀（如 v3.9.0）

💡 总结

版本号不是字符串，它是结构化的数字！

如果你直接用字符串比较版本号，很可能在版本升级到两位数时踩坑。我们习惯性地从左到右读字符串，但机器在进行字符串比较时可能完全不是你想象的那样。

所以，不管你是开发还是测试，这种“看似简单”的细节问题，往往最容易被忽略，也最容易在上线后酿成 bug。

🧩 延伸阅读 / 推荐工具

🔚 结语

这次版本号比较翻车的经历让我意识到，细节决定质量，越基础的逻辑越不能掉以轻心。

如果你也遇到过类似问题，欢迎一起交流经验；如果你还没踩坑，那希望这篇文章能帮你绕过这个小陷阱～