测试一年多，上线就崩溃：技术供应商纳斯达克酿出严重软件事故

编者按：本文来自微信公众号“InfoQ”（ID:infoqchina），作者：褚杏娟，策划：Tina，36氪经授权发布。

测试，你忽视不起。

经过一年多的广泛测试、四次彩排，澳大利亚交易所（ASX）的新系统在上线后还是因为出现故障而被迫关闭。这是其 2016 年因硬件故障导致休市后最为严重的一次事故。

测试一年多，测了个寂寞

11 月 16 日中午，ASX 发布声明表示当天将休市，于次日正常时间重新开放。交易所给出的关闭的原因是“局限于单个交易指令中交易多种证券（组合交易）的软件问题导致了市场数据不准确。”

ASX 此次升级的系统是由纳斯达克开发的最新一代交易系统，目前在全球广泛使用。为了保障上线后的安全运行，ASX、技术提供商纳斯达克（Nasdaq）、客户和第三方独立专家已经做了一年多的广泛测试，包括四次彩排。

然而，这么多测试都没能发现上述严重缺陷。

正是考虑到极高的复杂度，澳大利亚证交所才建议使用组合交易以降低运营风险。证交所的使用手册中提到，“股票合并指令消除了在多指令中单个指令的执行风险。因此，股票组合指令尤其适用于套利、股票转换、配对交易或任何其他希望获得净价格结果的组合。”

澳大利亚证交所承诺只需一天即可修复问题。事实也确实如此，该证交所于本周二恢复上线，并随即创下近 100 天以来的交易新高。

澳交所 CEO Dominic Stevens 为此次“给投资者、客户以及其他市场用户造成的影响而道歉。服务中断，证明我们未能达到自身设定的高标准以及其他人给予澳大利亚证交所的殷切期望。”

他还提到，“尽管进行了广泛的测试与演练，甚至有技术供应商参与其中，但澳大利亚证交所仍然需要承担责任。”该交易所决心继续实施自上而下贯彻的技术栈建设计划。

之所以决心全面升级，是因为该交易所仍在使用安腾芯片来支持核心交易类应用。时至今日，业界的核心交易应用早已被分布式分类账所取代。

Burman Invest 基金经理 Julia Lee 表示，由于证券交易所非常依赖新技术，将来可能还会再次发生重大宕机事故。

而在这次事故中蒙受损失的投资者可能很难获得赔偿。基金经理 Roger Montgomery 表示，如果股票交易未完成，投资者不可能证明自己亏本。人们无法为未发生的事情获得赔偿。

不重视测试引发的重大损失

很多公司常常因为忽视测试而自食恶果。去年，波音公司为美国宇航局（NASA）研发的载人飞船“星际客机”（CST-100Starliner）发射升空失败。尽管这次任务从隔热板到环境控制到着陆，许多项目都进展顺利，但由于一个小小的计时系统问题，导致了这次飞行任务的失败。

波音公司和美国宇航局在去年 12 月底组织了独立调查小组，并在今年 2 月中旬发出调研报告。这份报告显示，飞船和火箭助推器的时间存在偏差，而飞船的 Mission Elapsed Timer 提前轮询了火箭助推器的时间，从而进行了错误的计时并进入了错误的轨道。在发现这个问题之后，波音继续搜寻了可能存在的未被发现的其他问题。他们很快发现了第二个 Bug，该问题可能导致在将服务舱与机组成员舱分开时发射错误的推进器。

这些错误完全可以被提前“测试”出来。但在实验室测试软件的过程中，工作人员主要关心的是确保载人飞船和运载火箭两部分能够正确通信。测试小组证明了没有通信问题，但未发现载人飞船读取错误时间的问题。

调查小组检查了测试的流程，发现测试人员为了缩短测试时间走了捷径。他们将整个飞行过程分成了几个小单元分别进行测试，但最后却没有做完整的、端到端的集成测试。也就是说根本没有进行时长为 25 个小时的整体测试。最后波音公司不得不重新审核所有的一百万行代码。

而早在 1999 年，NASA 发射的火星极地着陆器在火星上坠毁。Lockheed Martin 公司于 2000 年初在丹佛进行的四项测试表明，MPL 起落架上的传感器发出了虚假信号。本应被设计成忽略这些信号的软件，最终却没有被设计成这样。这些信号被航天器解读为着陆腿所承受的压力导致下降引擎被关闭。由于一系列测试使用的传感器线路不正确，这一设计缺陷在发射前没有被发现。

当然，测试也不是万能的。2018 年 6 月 ，阿里云曾出现重大技术故障，恢复时间大概花费一小时，本次事故也被定义为 S1 级别。经过技术复盘，阿里给出的故障原因是工程师团队上线自动化运维新功能时，执行了一项变更验证操作，该操作在测试环境中未发生问题，上线后触发未知 bug。

测试不止是找 bug

很多人认为测试就是运行软件、检查功能点、找 bug、提交 bug，这严重低估了测试的重要性。

随着软件系统越来越复杂，软件迭代越来越快，软件开发潜在 bug 的可能性也会越来越高，软件测试作为软件研发流程中保障质量的最后一关，也显得越来越不可或缺。找 bug、提交 bug 只是软件测试工作中的一小段过程，测试脚本化、自动化都只是测试手段。

软件测试人员拿到需求书、需求分析书后，开始撰写测试案例、评审测试案例、执行测试、找 bug、提 bug，再做回归测试，最后项目 / 变更上线，这一套测试做得很全面，但项目 / 变更在生产上还是时不时出点问题。软件测试人员很苦恼，测试工作繁杂而又紧张，一套测试流程走下来，身体累，如果再出生产问题，心更累。

软件质量贯穿于整个软件研发周期，单凭软件测试人员，不能百分之百保证软件质量。而好的质量意味着交付更多的价值，不仅仅是没有缺陷那么简单。

软件测试人员从事测试活动是对软件产品的质量做出系统、全面、有效的反馈，开发人员依据这些反馈信息，进一步完善软件产品，进而提升软件的整体质量。有价值质量反馈体现为深入的、系统的和犀利的质量相关的见解。软件测试人员在日常开展功能测试、性能测试、安全测试等测试活动，都是为了提供有价值的反馈，如产品缺陷、设计优化和用户体验优化。

现在，很多测试人员和开发人员之间的协作在逐步增强，团队之间的界限随着时间的推移变得越来越模糊。测试人员的职责范围也在扩展，逐渐参与到流程的其他方面，团队在不同领域需要完成的任务和需要解决的挑战也在扩展。

一些测试人员需要指导开发人员进行自测，还有一些人需要在生产环境中进行质量监控，并定义流程，确保质量保证成为整个团队工作的一部分，而不仅仅是在版本发布之前发现漏洞和给漏洞打补丁。

软件测试最重要价值的是保障软件质量，只有以软件质量保障为顶级原则，测试工程师才能真正做好、做深软件测试工作。

延伸阅读：

https://xie.infoq.cn/article/60ba42a150f0b0623663b009c

https://www.theregister.com/2020/11/17/asx_outage/