前幾天看到一個很有趣的微博（見圖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年。”——這聽起來好耳熟啊：“我們的軟體無法實現這樣的功能，所以請取消這個需求”……
本文由@柴阿峰 投稿於伯樂線上，如果您也願意分享一份自己的原創/譯文，可以 從這裡開始哦~
【如需轉載，請標註並保留原文連結、譯文連結和譯者等資訊，謝謝合作！】