前幾天看到一個很有趣的微博（見圖1：）當然這事兒對發博的人肯定沒有趣，又查了一下閏秒的概念：

原來我們的時間計算有兩種方式，一種是類似于古人看太陽位置或者用日冕的“天文法”，獲得的時間稱之為世界史；一種是利用原子振蕩周期計算的“原子法”，我們生活中用的時間都是***種，而計算機系統則大量使用第二種。在大部分場合這倆時間完全一致，但是由于現在地球越轉越慢（或許歲數也大了 Orz），所以還是有微小的誤差，為了平衡這種誤差，由國際計量局統一規定在年底或年中（也可能在季末）對協調世界時增加或減少1秒的調整。2012年7 月1日我們就見證了一個閏秒（北京時間為7:59:60）。

圖1

合著閏秒是計時領域的一種調整，但是這個調整卻給全世界IT系統帶來了麻煩，除了微博中提到的芬蘭航空管理系統，許多使用Linux系統服務器也發生了問題，這是因為，Linux內核2.6.29之前版本存在bug，在進行閏秒調整時可能會引起系統時鐘服務ntpd進程死鎖。許多使用Linux服務器的著名網站都遇到了問題（不過看報道，都是國外網站，國內網站似乎很平靜，難道我們的網站都是用Windows Server？）

類似的案例，在我國還有一個事件，由于出租車計價器芯片沒有2月29日，廣州的上千輛出粗車在這天趴窩。

與時間有關的最經典的bug當然還是“千年蟲”了，由于采用了兩位紀年用于節省存儲空間，全世界的軟件在2000年1月1日都可能會宕機（系統無法識別00代表2000還是1900），在那個互聯網還不發達，操作系統不能偷偷在后臺打補丁的年代，各大軟件公司都在四處郵寄補丁光盤，并在惴惴不安中渡過了新年。

從這些案例我想到的是測試設計的問題：如何優化我們的時間相關數據設計？

首先，時間數據的等價類劃分應該更加細致，除了一個有效時間和一個無效時間，還應該有閏年、閏月、閏秒數據。由于時間是廣泛相關數據，縱使被測軟件可以正確處理，被測軟件相關的其他軟件（操作系統，數據庫，Java虛擬機等）也有可能會出問題（例如Linux內核的那個bug），所以這種廣泛測試是必要的。這種測試可以作為一個單獨的檢驗用例或者探索測試執行。

其次，時間的廣義邊界值測試。大部分測試者都知道測試輸入框的顯性邊界值，但是很少有人去測試時間這個隱形邊界值。時間可能不是我們手動輸入的，但是它還是每時每刻在做為隱形輸入在影響著我們的系統。而當時間處于交界點（跨年，跨天，或者某個時刻）時，問題就會發生。例如我在過去測試中遇到每天早上 8點整某個信息管道就會丟失數據。

再擴展一點就是，我做測試時，經常揪住省份這個選擇框不放，別看這是最簡單的錄入信息（提問，中國有多少個省級單位？如果不知道的話，自己去 baidu吧），要么少了，要么多了，要么名字不對，有相當的機會發現問題。新浪微博不也出過“湖北省省會是哪里”回答武漢，系統提示“您的回答有誤”……這種烏龍事件嗎。

時間，省份這都是非常簡單的輸入，但是這都只是看似簡單而已，內里還是有很多門道，因為他們涉及到其他領域的知識：政治、人文，地理，歷史等等。

所以，測試（尤其是黑盒測試，手工測試）絕對是一個入門容易，做好難的職位，單單是時間這么常見的數據，就有很多潛在知識，從設計和分析上都需要注意，更何況復雜的業務系統，或者專業軟件。所以終歸測試是離不開人的因素的，測試時要“動腦子”，要不斷提高理解，要不斷的學習，而不是只對著用例文檔一行行的做機器人：這種機器人工程師，早晚會被機器人測試腳本取代。而那些真正動腦子的工程師，才擁有未來。

ps：寫完這篇文章的時候，看到一篇報道說“美國政府表示閏秒的推行不是好事，他們指出，因為這個閏秒將會導致很多計算機系統運行困難。目前，國際電信聯盟（ITU）已經接受美國提出的取消閏秒的提案。不過關于這個提案的討論活動預計要推遲到2015年。”——這聽起來好耳熟啊：“我們的軟件無法實現這樣的功能，所以請取消這個需求”……

原文鏈接：http://blog.jobbole.com/23256/