近，某信息安全公司發布了一個更新補丁，導致用戶的密鑰管理軟件無法正常工作，應該從類似的問題中學習到怎樣的教訓呢?評論家Andrew Binstock撰文強調了回歸測試的重要性!
　　有關問題的背景，Andrew做了相應的介紹：
　　在我看來，不使用一個全面的回歸測試集合是錯誤的。這種錯誤將導致正如卡巴斯基——這家消費者導向的安全軟件公司(提供反病毒，反惡意軟件)——所面臨的尷尬局面？ò退够囊豢町a品是供用戶存放安全密鑰的密鑰安全軟件。當用戶需要使用一個密鑰時，用戶通過密鑰安全軟件的密碼打開軟件，復制/粘貼要使用的密鑰。其要使用的密鑰會顯示為一組圓點。完成操作后，他們關閉安全軟件然后繼續他們的工作。通過一個簡單的列表，用戶可以添加新的密鑰。這個列表還非常明智地添加了密鑰有效期限。用戶也可以將選擇“從不設定有效期限”。
　　下面我將仔細說明。更新的結果是所以的密鑰都突然過期，而且修改有效期的按鈕失效。我并不知道卡巴斯基是怎么開發軟件的。盡管如此，我們不難從這些現象推斷出一些信息。
　　Andrew強調了測試的重要性：
　　和很多人一樣，我一直以來很欣賞“Uncle Bob”Martin的部分觀點。盡管我不贊同他的一些觀點(有時是強烈不贊同)，但我從來沒有質疑過的他一直強調的這一點：沒有測試的提交代碼方式是不正確的。我并不是在推崇Martin的大解決方案(測試驅動開發)，而是強調他基本立場的正確性。老實說，Martin即不是的、也不是第一個提出測試與提交代碼同步的重要性的人。Kent Beck、Michael Feathers等許多持續集成和DevOps的倡導者們，一直以來都持有這個觀點。但是Martin孜孜不倦的倡導這個觀點。并且正是由于他的推動努力，很多勤奮的開發人員本能地理解了寫完代碼后立即進行測試的重要性。
　　測試已經成為開發工作的重要部分。Andrew認為，以至于當開發者沒有進行測試時，人們會認為開發者又陷入了老的工作模式或者指責開發者草率行事，對自己的代碼毫不關心。直到幾年前，我們還可以說可以不用對開發者編寫的代碼進行測試，能成功地把人類送到月球上。當時，大部分人都認為自己可以不進行測試完成出色的代碼。直到，還都需要面對這個重要的問題：他們如何知道自己對代碼的修改不會影響到現存代碼的正常運行?測試的作用——作為整個代碼的傳感器和監視器——是對進行測試工作的必要性的有力的論證。
　　對于該信息安全公司的問題，Andrew分析道：
　　卡巴斯基公司肯定沒有進行回歸測試，否則它將不會遇到這個問題。這個問題發生在Windows 7的機器上——我的朋友告訴我這個問題發生在普通的Window 7家庭機上(家庭機的主要運行的程序是Office、Outlook和IE瀏覽器)。評論說很多Window 7的電腦都遇到了這個問題？紤]到Windows 7是當下流行的操作系統，卡巴斯基公司肯定沒有針對這款系統進行測試。
　　還有另外一條線索說明測試工作沒有進行或者至少進行的不充分：這款軟件里被標明“從不設定有效期限”的密鑰突然顯示為過期狀態，而且其到期日期變為1601年。
　　Andrew認為，這個日期非常麻煩。在測試中，了解程序的不變量十分有用。不變量是程序中不管程序處于什么狀態，總為真的一些東西。不變量是程序中豐富的“靜脈”，我們在回歸測試集合中要充分利用它們。在這個程序中，我們可以知道它的一個不變量是任何軟件的到期日期都不能早于軟件發布日期。打個比方，如果說卡巴斯基是在2011年7月1日第一次發布的這個軟件，那么所有用戶的密鑰的截止日期不會早于這個日期。這是一個不變量——任何密鑰的截止日期不能早于2011年7月1日。如果密鑰的截止日期早于這個日期，那說明程序有錯誤。而現在程序中出現1601年這個日期，這說明測試工作不足或設計工作很差。也是說，使用無效的日期作為使用的數據，如一個錯誤代碼。這種重用數據字段來代表一個完全陌生的數據項的做法是很可怕的。這種做法在磁盤空間和內存都很昂貴的時代非常流行。標志位的字節常常被重載來表示獨特的信號或者罕見的條件。如今在資源受限制的嵌入式系統中我們依舊可以見到這種做法，那是因為現在還沒有更好的做法來替代這種做法。不過對于桌面程序，這是一個嚴重的問題。首先，你會給正在試圖解決一些困惑問題的用戶帶來新的令人困惑。其實，你會讓不變量不穩定，F在，針對不變量的測試必須測試所有合法的異常值——一個常數的維護問題作為新的誤差值被添加到這個重載的字段。相反，錯誤常常被他們自身的領域和診斷所標明。這保證了測試的完整性，代碼的清晰、可讀性。關于后者，想想那些測試錯日期、翻譯錯日期的代碼。當你在你是用的應用程序中看到這些問題是你會怎么想?
　　我朋友現在明智的思考她是否應該更換一款安全軟件，用一款從不會鎖住她的密鑰的軟件。如果你不充分測試你的軟件(從開發者測試開始進行——開發者測試將在產品發布前早早發現問題)，你可能會遇到大麻煩！　∶艚輰＜襆isa Crispin曾經撰文強調了自動化回歸測試的重要性：敏捷團隊沒有測試自動化會成功嗎?可能吧，但是我們所知道的成功團隊都依賴自動化回歸測試。如果你花費全部時間用在手動回歸測試上，絕沒有時間用于重要的探索性測試(會發現隱藏在代碼中的危險行為)。敏捷開發利用測試來指導開發。為了編寫代碼使測試通過，你需要快速、簡單地運行測試。沒有短期反饋周期和安全的回歸測試，團隊將很快陷入技術債務，缺陷不斷增加，速度越來越慢。
　　自動化回歸測試是團隊的工作。整個團隊應該選擇每種測試適合的工具。提前考慮測試將幫助開發人員為了便于測試自動化來設計代碼。使用敏捷測試象限和測試自動化金字塔來幫助你自動化各種類型的測試。記住從簡單入手。你會驚訝地發現一些基本的自動化冒煙測試或者自動化單元測試會發生很大作用。
　　測試自動化是團隊的工作。開始時很艱苦，需要克服很大的痛苦。如果你管理開發或者測試團隊，確保在時間、培訓和激勵上提供了足夠的支持。如果你是沒有自動化測試的團隊的測試人員，開發人員瘋狂地編寫代碼以至于不會停下來考慮測試，那么你會面臨很大的挑戰。嘗試從管理層和團隊成員中獲取支持以開始小規模的自動化工作。