從錯誤補丁看回歸測試的重要性

第第頁從錯誤補丁看回歸測試的重要性從錯誤補丁看回歸測試的重要性

發(fā)表于：2023-11-25來源：InfoQ：崔康點擊數(shù)：標簽：回歸測試

最近，某著名信息安全公司發(fā)布了一個更新補丁，導致用戶的密鑰管理軟件無法正常工作，應該從類似的問題中學習到怎樣的教訓呢?評論家AndrewBinstock撰文強調了回歸測試的重要性!

最近，某著名信息（安全）公司發(fā)布了一個更新補丁，導致用戶的密鑰管理軟件無法正常工作，應該從類似的問題中學習到怎樣的教訓呢?評論家AndrewBinstock撰文強調了（回歸）（測試）的重要性!

有關問題的背景，Andrew做了相應的介紹：

在我看來，不使用一個全面的回歸測試集合是錯誤的。這種錯誤將導致正如卡巴斯基這家消費者導向的安全軟件公司(提供反病毒，反惡意軟件)所面臨的尷尬局面?？ò退够囊豢町a品是供用戶存放安全密鑰的密鑰安全軟件。當用戶需要使用一個密鑰時，用戶通過密鑰安全軟件的密碼打開軟件，復制/粘貼要使用的密鑰。其要使用的密鑰會顯示為一組圓點。完成操作后，他們關閉安全軟件然后繼續(xù)他們的工作。通過一個簡單的列表，用戶就可以添加新的密鑰。這個列表還非常明智地添加了密鑰有效期限。用戶也可以將選擇"從不設定有效期限'。

下面我將仔細說明。更新的結果是所以的密鑰都突然過期，而且修改有效期的按鈕失效。我并不知道卡巴斯基是怎么（開發(fā)）軟件的。盡管如此，我們不難從這些現(xiàn)象推斷出一些信息。

Andrew強調了測試的重要性：

和很多人一樣，我一直以來很欣賞"UncleBob'Martin的部分觀點。盡管我不贊同他的一些觀點(有時是強烈不贊同)，但我從來沒有質疑過的他一直強調的這一點：沒有測試的提交代碼方式是不正確的。我并不是在推崇Martin的大解決方案(測試驅動開發(fā))，而是強調他基本立場的正確性。老實說，Martin即不是唯一的、也不是第一個提出測試與提交代碼同步的重要性的人。KentBeck、MichaelFeathers等許多持續(xù)集成和DevOps的倡導者們，一直以來都持有這個觀點。但是Martin孜孜不倦的倡導這個觀點。并且正是由于他的推動努力，很多勤奮的開發(fā)人員今天本能地理解了寫完代碼后立即進行測試的重要性。

測試已經成為開發(fā)工作的重要部分。Andrew認為，以至于當開發(fā)者沒有進行測試時，人們會認為開發(fā)者又陷入了老的工作模式或者指責開發(fā)者草率行事，對自己的代碼毫不關心。直到幾年前，我們還可以說可以不用對開發(fā)者編寫的代碼進行測試，就能成功地把人類送到月球上。當時，大部分人都認為自己可以不進行測試就完成出色的代碼。直到今天，還都需要面對這個重要的問題：他們如何知道自己對代碼的修改不會影響到現(xiàn)存代碼的正常運行?測試的作用作為整個代碼的傳感器和監(jiān)視器是對進行測試工作的必要性的最有力的論證。

對于該信息安全公司的問題，Andrew分析道：

卡巴斯基公司肯定沒有進行回歸測試，否則它將不會遇到這個問題。這個問題發(fā)生在（Windows）7的機器上我的朋友告訴我這個問題發(fā)生在普通的Window7家庭機上(家庭機的主要運行的程序是Office、Outlook和IE瀏覽器)。評論說很多Window7的電腦都遇到了這個問題?？紤]到（Windows）7是當下最流行的操作系統(tǒng)，卡巴斯基公司肯定沒有針對這款系統(tǒng)進行測試。

還有另外一條線索說明測試工作沒有進行或者至少進行的不充分：這款軟件里被標明"從不設定有效期限'的密鑰突然顯示為過期狀態(tài)，而且其到期日期變?yōu)?601年。

Andrew認為，這個日期非常麻煩。在測試中，了解程序的不變量十分有用。不變量是程序中不管程序處于什么狀態(tài)，總為真的一些東西。不變量是程序中豐富的"靜脈'，我們在回歸測試集合中要充分利用它們。在這個程序中，我們可以知道它的一個不變量是任何軟件的到期日期都不能早于軟件發(fā)布日期。打個比方，如果說卡巴斯基是在2023年7月1日第一次發(fā)布的這個軟件，那么所有用戶的密鑰的截止日期就不會早于這個日期。這就是一個不變量任何密鑰的截止日期不能早于2023年7月1日。如果密鑰的截止日期早于這個日期，那就說明程序有錯誤。而現(xiàn)在程序中出現(xiàn)1601年這個日期，這說明測試工作不足或設計工作很差。也就是說,使用無效的日期作為使用的數(shù)據(jù)，如一個錯誤代碼。這種重用數(shù)據(jù)字段來代表一個完全陌生的數(shù)據(jù)項的做法是很可怕的。這種做法在磁盤空間和內存都很昂貴的時代非常流行。標志位的字節(jié)常常被重載來表示獨特的信號或者罕見的條件。如今在資源受限制的嵌入式系統(tǒng)中我們依舊可以見到這種做法，那是因為現(xiàn)在還沒有更好的做法來替代這種做法。不過對于桌面程序，這是一個嚴重的問題。首先，你會給正在試圖解決一些困惑問題的用戶帶來新的令人困惑。其實，你會讓不變量不穩(wěn)定?，F(xiàn)在，針對不變量的測試必須測試所有合法的異常值一個常數(shù)的維護問題作為新的誤差值被添加到這個重載的字段。相反，錯誤常常被他們自身的領域和診斷所標明。這保證了測試的完整性，代碼的清晰、可讀性。關于后者，想想那些測試錯日期、翻譯錯日期的代碼。當你在你是用的應用程序中看到這些問題是你會怎么想?

我朋友現(xiàn)在明智的思考她是否應該更換一款安全軟件，用一款從不會鎖住她的密鑰的軟件。如果你不充分測試你的軟件(從開發(fā)者測試開始進行開發(fā)者測試將在產品發(fā)布前早早發(fā)現(xiàn)問題)，你可能會遇到大麻煩。

資深敏捷專家LisaCrispin曾經撰文強調了（自動化）回歸測試的重要性：敏捷團隊沒有測試（自動化）會成功嗎?可能吧，但是我們所知道的成功團隊都依賴自動化回歸測試。如果你花費全部時間用在手動回歸測試上，絕沒有時間用于重要的探索性測試(會發(fā)現(xiàn)隱藏在代碼中的危險行為)。敏捷開發(fā)利用測試來指導開發(fā)。為了編寫代碼使測試通過，你需要快速、簡單地運行測試。沒有短期反饋周期和安全的回歸測試，團隊將很快陷入技術債務，（缺陷）不斷增加，速度越來越慢。

自動化回歸測試是團隊的工作。整個團隊應該選擇每種測試適合的工具。提前考慮測試將幫助開發(fā)人員為了便于測試自動化來設計代碼。使用（敏捷測試）象限和測試自動化金字塔來幫助你自動化各種類型的測試。記住從簡單入手。你會驚訝地發(fā)現(xiàn)一些基本的自動化冒煙測試或者自動化（單元測試）會發(fā)生很大作用。

測試自動化是團隊的工作。開始時很艱苦，需要克服很