軟件質量挑戰和實踐建議

        Aya Elgebeely 討論了四種關鍵的質量保證實踐在軟件開發中的重要性。

        簡介

        軟件開發和工程被視為非常年輕的職業；但是，它們得到了廣泛應用，并且正以比以往更快的速度增長。在許多國家，軟件行業目前通常被視為經濟增長的主要支柱之一。軟件公司常常面臨著提供高質量軟件的許多困難挑戰，而他們也在竭盡所能地讓客戶滿意。

        軟件質量不可或缺

        隨著軟件變成日常生活中不可或缺的一部分，對軟件的需求也明顯增長。相應地，高軟件質量目前被視為是 “必須具備的” 而不是 “應該具備的”。讓質量保證團隊從一開始就參與到項目規劃和執行中，這一點至關重要。然而，仍然有一些公司認為軟件質量只不過是測試人員在開發生命周期結 束時執行的一項任務。

        值得注意的是，軟件市場充斥著各種選擇，有眾多免費、開源的軟件存在。除此之外，客戶和最終用戶對他們購買的軟件的質量越來越看重。具有糟糕性 能或低質量用戶體驗的應用程序或企業系統將被淘汰，其他產品很容易取代它們的位置。現在，以前所未有的認真態度關注其產品的質量已成為軟件公司的使命。

        自始至終都要考慮軟件質量

        對于將軟件 QA 濃縮到所有開發任務完成后的測試階段的方法，它們的問題在于：會給團隊帶來巨大成本并將整個項目置于高風險之中。在測試階段，開發人員竭盡全力確保他們的 代碼具有極少的缺陷。然后測試人員努力揭示軟件中每個可能的缺陷，而經理和客戶希望他們擁有適合向市場發布的軟件。

        問題在于：為什么許多軟件公司會堅持促使開發團隊滿足嚴格的最后期限，完成盡可能多的功能，卻毫不關心代碼質量有多差，因而忽視了注入代碼內的大量缺陷，犯下架構錯誤，以及忽略文檔？

        倉促的開發可能會為團隊節省片刻的時間，但是，如果有一些重大開發問題沒有從一開始就考慮到，最終可能導致需要投入更多的時間。結果是浪費了大 量團隊資源來修復和重新設計代碼，而不是將這些資源投入到更有用的事情上。軟件團隊人員內心里對整個始末一目了然，但面對著嘮叨的客戶、嚴格的銷售團隊， 以及一些自我感覺編寫了無缺陷的軟件的開發人員，軟件團隊確實很難將 QA 撇在一邊而只顧著完成代碼。

        軟件工程標準和它們的使用

        值得一提的是，公司既不需要一定要遵守某種軟件開發標準，也不需要有嚴格的流程。典型的軟件開發生命周期 (SLDC) 有著各種不同的標準，比如 IEEE、ISO - 12207 或 CMMI。這些標準的目標是確保最終產品符合市場需求，達到最終用戶的滿意度。

        事實上，每天都會許多軟件應用程序、移動應用程序，甚至是完整的企業系統銷售給各種不同的客戶，這些應用程序可能并未使用任何標準來開發。但 是，人們還是在購買它們。忽略標準與糟糕的軟件質量和對最終產品的更少需求沒有直接的關系（只要該軟件不是對生命至關重要的軟件，比如美國境內需要 FDA 批準和應遵守某種標準的醫療軟件）。問題不是遵守標準。真正的問題在于忽略或減弱軟件質量的重要性。

        本文既不是說要遵守 SDLC 標準，也不是要擁有一個極好的開發和測試流程。首先，重要的是認識到質量是任何軟件的一個重要組成部分。公司不一定需要高度專業的 QA 團隊和實踐，但至少必須接受這種文化本身和擁有相關的實踐。

        貫穿軟件開發生命周期的軟件質量實踐

        這一節提供的實踐將對軟件質量會產生積極影響，不會給開發團隊創造太多負擔或麻煩。在開發和測試實踐中值得考慮它們。

        需求審核

        難道您不認為，浪費資源來交付錯誤的功能確實很可怕？在開始每個新開發階段之前審核軟件需求，這樣做能夠最大限度地減少缺陷并滿足客戶的需求。 在實現之前審核需求，這樣做有助于考慮潛在的變化，克服在項目的整個壽命中可能發生的誤解。團隊必須與客戶一起反復檢查所有應實現的業務領域細節。需求審 核也可以使用原型和領域模型來完成。當開發團隊在開始實際實現之前完成這個小任務時，他們的項目或開發迭代會獲得良好的開局。通過確保在實現之前所有利益 相關者都達成共識，并且每位團隊成員都意見一致，客戶和管理人員可確信開發人員將在開發周期結束時交付正確的成果。

        代碼審核和演練

        聽起來像很簡單，但代碼審核是軟件開發中最有效的實踐之一。它對減少缺陷數量（在錯誤進入軟件之前在窗口中發現它）以及增強代碼和軟件設計的質量具有直接影響。這消除了在未來的版本中執行重大的代碼重構和清理的需求。

        依據項目需求和實現細節，團隊可能認同簡單的編碼和設計原則。團隊成員應共同遵守這些原則，而且只要開發一項新功能，一個或多個團隊成員（除了作者）應審核新代碼，并搜索所有編碼或設計錯誤。

        這種做法可在許多方面為團隊帶來幫助，包括提高代碼質量和設計，最大限度地減少缺陷，并預防它們。另外，它還使得整個團隊能夠深入了解彼此的工 作，輕松移交工作，并提高團隊對不同軟件組件和功能的認知。團隊協作驗證和證明代碼的質量和設計的實現方法。它們從同事那里獲得直接反饋。這么做可謂一舉 兩得：代碼質量增加了，團隊的認知和項目責任也增加了。

        基于會議的測試

        基于會議的測試（James Bach 發明的一種方法）表示將測試負載分解為會議，每個會議有一個任務（一種希望從測試會議獲得的明確規定的結果）。每個會議有一個既定的時間范圍（從 20 到 40 分鐘），測試人員在執行測試會議期間不應中斷。

        這就像將測試人員放在一個測試房間一段時間，讓測試人員專注于查找特定軟件特性或功能的缺陷。在會議期間，測試由一組測試案例引導執行，測試人 員也可以執行探索性測試。因此，基于會議的測試是正式測試方法與測試創新的一種組合，因為它提供了測試人員房間來進行探索和獲得直覺思維，留出了時間和自 由空間來發現不常見的缺陷，或者通過折騰軟件來進一步了解它。

        會議期間，測試人員應將軟件的行為記錄在案，獲取快照，以及寫下軟件在特定輸入和設置下的行為。會議結束時，將與團隊領導或技術經理討論會議腳本。從他們的討論中，他們找出所認為的正常行為和不正常行為，然后基于討論創建缺陷報告。

        圖 1 簡短描述了基于會議的測試。對于軟件中的任何新更改，計劃不同的測試會議，每個會議都有一個指定的目標和任務。測試會議期間，測試人員使用測試案例和/或執行探索性測試。測試會議結束時，會報告在會議期間找到的缺陷。

        圖 1. 基于會議的測試工作流

        基于風險的測試

        因為在開發流程中進行了一些更改（主要的或次要的更改），開發團隊通常擁有同一個軟件的許多常用版本。一種重要的 QA 實踐是在每個主要版本之后徹底測試軟件。另一方面，在每個版本中都對整個軟件運行全面的回歸測試既耗時又很難實現。但是，僅測試更改的功能或笨拙地刪減測 試案例套件是不安全的。一段代碼可能解決了一個缺陷，但也可能破壞了代碼中的其他內容。

        基于風險的測試方法采用了折中方式。它的基本理念是按降序對軟件功能和失敗模式排序，從最重要或風險最高到值得擁有的功能和簡單的風險（一個類 似工具是 FMEA：失敗模式和影響分析）。如果測試人員在嚴格的時間限制下測試某個新版本時手頭有這個列表，他就可以集中精力確保新引入的更改不會破壞其他任何內 容。然后就可以輕松地確保更改不會破壞軟件中的任何最重要的功能，因而不會發生任何最嚴重的風險。

        結束語

        每家公司都希望在充滿競爭的 IT 市場中飛得更高，而且在努力創造人們喜歡的優秀軟件。不幸的是，有時來自客戶或不耐煩的管理層的壓力可能導致團隊繞開軟件質量實踐，最終實現一個低于預期的產品。糟糕的軟件質量只有在它發生故障時才會被注意到。

        本文中討論的實踐和方法貫穿整個開發生命周期。它們涵蓋需求分析、設計和開發，以及測試階段。而且它們表明缺陷預防比在項目結束時再解決問題要簡單得多，在項目結束時，更改帶來的技術人情債和成本將會很高。

        本文突出了軟件質量角色和重要性，以確證忽略軟件質量可能嚴重影響公司實現其業務目標。另外，本文還為讀者介紹了一些更簡單、更高效的實踐，它們不但為團隊節省了時間、金錢和精力，還提升了產品的質量。