【研發經驗談】子產品間建鍊失敗問題的分析及解決

很長時間以來，我每天花在地鐵上的時間都在一個小時以上。閑來無事，我就在手機上下載下傳了多看閱讀，并且購買了很多電子書。最近，我閱讀了《異類》，頗有感觸。作者在書中提出了一個“一萬小時”的定律，也就是說，當一個人花在某件事情上的時間超過一萬個小時之後，就會發生質的改變，就會做到比絕大多數人好。我們耳熟能詳的一些天才，像蓋茨、喬伊等等，雖然天賦很高，但自身也很勤奮，花了比常人多得多的時間在自己所喜歡的事業上。也就說是，是“一萬小時”定律讓他們與衆不同。

量變引起質變的規律也适用于軟體開發領域，本文中提到的問題，即是一例。

問題描述

在某項目進行了長期的自動測試工作之後，我們組建了如下的系統架構：

最近，在進行自動測試的過程中，我們發現測試用例的執行總是失敗的。更具體地說，就是消息觸發腳本無法調用發消息工具，兩者之間無法建鍊。

原因分析

本測試系統已搭建了長達兩年，已經累積了上千個測試用例。之前從未遇到過此類消息觸發腳本無法調用發消息工具的問題。那麼，究竟是什麼原因引起的呢？

我們首先檢查了自動測試環境，發現一切正常。之後，我們修改了自動測試的調用腳本，變成了手動觸發。也就是說，當發消息工具成功啟動之後，我們再點選消息觸發腳本，發現鍊路能夠正常建立，且消息發送正常。那麼，為什麼自動測試的時候就不能正常建鍊呢？

我們再回過頭來分析了一下自動測試的整個流程。當自動測試啟動之後，消息觸發腳本和發消息工具幾乎是同時開始運作的，而發消息工具運作起來之後，要先讀取配置檔案中的測試用例，然後綁定IP和端口号，完成之後再等待和消息觸發腳本建鍊。前期的測試用例比較少，所有當消息觸發腳本監測與發消息工具的鍊路的時候，後者已經成功讀取了配置檔案，并綁定了IP和端口号。這樣，後續的流程就能夠正常執行。

但是，随着測試用例的累積，當消息觸發腳本開始監測與發消息工具的鍊路的時候，後者還在讀取配置檔案，并未綁定IP和端口号。這樣，消息觸發腳本發現鍊路還不具備，是以執行就失敗了。這也就是我們看到的現象。之是以手動能夠執行成功，是因為我們點選消息觸發腳本的時候，發消息工具早就完成了讀配置和綁定IP與端口号的操作(手動操作要比自動操作慢很多)，就不存在建鍊不成功的問題了。

問題解決

根據以上分析，我們隻需要給發消息工具足夠的時間，讓消息觸發腳本晚點與發消息工具建鍊就可以了。

我們在消息觸發腳本中添加了如下語句：

ping 127.0.0.1 -n 30

當消息觸發腳本執行了30次ping操作之後，發消息工具早就做好了準備工作，于是建鍊成功，後續流程順利執行。

總結

本文中提到的建鍊失敗問題的解決辦法雖然簡單，但該問題卻提醒了我們，在兩個子產品需要進行消息互動的時候，發送消息的子產品一定要等到接收消息的子產品“準備好”之後，再發送消息過去。也就說是，軟體子產品的初始化需要時間，在設計軟體的時候，我們一定要将各個子產品的初始化時間考慮進去。