21世紀的軟體測試

   原文來自於Testing in 21st Century，翻譯出來，供大家思考。從我個人觀點看，21世紀的測試可以簡單地概括為3句話（三段論）：

1. 全程軟體測試，測試是重中之重。
2. 全程自動化測試，測試原來可以是這樣的。
3. 全程缺陷預防，測試工作已經不是那麼重要。

————————————譯文————————————————-

    由於當前商業和IT環境的驅動，軟體測試的理念、實踐和工具正在發生一些革命性的變化。這種變化將給專業測試人員及其測試工作帶來什麼樣的影響？

 

這些驅動正在改變專業測試人員的生活

    IT操作的商業環境正在發生變化，這直接影響著商業和IT如何看待專業的測試人員。測試已經不僅僅充當門衛（Gatekeeper），而且是一個變革的倡導者，一些測試人員在足夠早的時候發現風險，從而為如何開發和部署軟體帶來更高的效率。這種變化的驅動因素來自於：

• 越來越多的普通人正在廣泛使用IT, 或IT系統
• 在激烈的市場競爭中的產品上市時間（Time-to-market）的壓力
• 商業環境的快速變化
• 軟體應用方面的規則的影響
• 長期投資回報（ROI）周期意願的降低
• 在IT方面聰明地花錢-大型項目的失敗率仍然很高
• IT系統、平台和用來構建它們的語言等類型或形式越來越多

軟體測試和SDLC（軟體開發生命週期）軟體測試不再是一個事後的想法

 

測試計劃是專案計劃中不可缺少的部分

    測試正在變得比以往複雜得多。一個典型的公司專屬應用程式系統總是要與其它內部和外部應用系統進行關鍵性的整合。大多數的應用都
有各種功能和非功能測試（從可用性、效能、可擴充性到部署、安裝）任務，這些任務需要事先為環境、測試資料收集和專業技能等進行計劃。其中一些需要花費較
長的準備時間。如果缺乏前期規劃，測試就會成為項目的瓶頸，這越來越成為大家的共識。所以，測試計劃變得越來越積極，項目一開始就策劃。

一個漸進的規劃正變得越來越必要。做什麼和什麼時候做的問題越來越多地被事先回答，而且在接近測試執行的時候，怎麼做的問題也已計劃好。

測試團隊的早期參與是強制性的

    從早期發現和修訂問題到提供可預測性、大量成本節省和高效的變化過程，IT組織正在意識到極大的好處。

   對一個專業的測試人員而言，機遇與挑戰並存。這是協作的必然要求，有多種技能的測試人員可以消除商業和技術之間的隔閡，並理解使前期測試可行的實踐方法和工具。

 有些技能是共同的：

• 良好的分析能力，以獲得客戶和業務分析專家的認可
• 能夠快速建立適應代碼多次變化的自動化的測試架構
• 不僅僅是一個自動化測試載入器的專家，而且是測試自動化的專家，能夠在必要時開發合適的工具
• 基於商業價值及其相關的技術風險的測試設計技能

可測性是一個設計標準

    早期的測試參與是一個不可替代的要求。例如，可測性已經越來越多地成為一個設計標準，以便允許早期的、有效、快速的和可維護的測試建立。測試人員與開發人員的協作是極為重要的。

在如何或何處將可測試性作為設計標準方面的一些例子，有助於測試和自動化測試，例如：

• 確保使用者介面和商業邏輯的分離，使得我們可以在適當的層次進行測試（使用者介面或業務層）。這允許測試載入器（如FIT/ FITNESSE）可以在UI設計沒有最終確定或沒有UI的情況下通過API進行測試。
• 可以更有效地使用UI對象的ID來完成UI的自動化測試
• 當外部系統不可用或仍處於開發階段的時候，構建可配置的類比系統來測試應用程式

軟體測試的新趨勢

• 從“精小”方面看測試 – 測試如何能夠消除在交付過程中的浪費。這個思想確實可以驅動在工具方面和構建一個更具協作性的測試理念方面的改變，這種測試理念可以綜合考慮利用IT項目中每個個體的能力而不僅僅是測試人員。
• 測試作為一個持續的反饋機制 – 測試正在漸漸成為一個持續的反饋機制，而不是在開發週期末尾的、已計劃的活動。在一個構建流水線中，整合到持續的事件驅動機制中的功能測試意味著測試被應用程式的變化所驅動，而不是時間表所驅動。
• 用於定義測試的更進階語言 – 這些語言可以被非IT客戶人群所理解。這使得測試可以被其他人所理解，而且允許不同的項目相關利益者或干係人（stakeholder）瞭解測試的價值。
• 在專案生命週期的早期開始自動化 –
  正在開發的工具和架構使得測試維護是一個相對簡單的任務。我們認為，由於測試代碼和開發人員的代碼類似，因此也可以從快速開發環境中的開發實踐裡獲益，如
  重構（用以在代碼中進行小的設計變更，而不影響行為。被目前的許多IDE所支援）和基於良好的物件導向編程的測試架構。
• 不僅僅是GUI驅動測試, 而且通過GUI的各個層次（包括底層）驅動測試。例如，測試和反饋一樣重要，所以不管在哪個層次進行測試，關鍵是提供正在構建的應用程式是否正確的反饋。如FIT/ FITNESSE測試架構有助於構建可重複的、可擴充的、易讀的非GU測試套件。
• 開源軟體作為商業測試載入器的可能的替代 – 商業工具供應商在自動化的測試領域並不具有絕對的優勢。一個開發人員和測試人員的大型社區正在推行開源工具的廣泛使用和開發。成功的工具和架構（如Selenium和 Fitnesse）就是開源工具在測試領域的有力證明。

新一代的專業測試人員

    測試人員不再被看做搞怪的人（monkey tester）或者是令人掃興的人（party pooper），而是在產品環境中應用程式可成功交付的干係人。

• 測試人員表現為客戶和項目干係人的代表。
• 測試人員需要展示其對業務、客戶需求的優先順序和市場實際狀況等的理解能力。
• 測試人員保護客戶和項目干係人的利益，同時支援開發人員開發出更好的軟體產品。
• 測試人員協助Team Dev避免偏離正確的軌道（局面不失控），如風險抑制、用正確的方式構建正確的東西、在開發週期早期檢測應用程式的薄弱環節或地區。
• 測試人員將逐漸地將測試和Team Dev的敵對關係轉換為協作的關係。

   
21世紀的組織需要在交付周期的早期引入測試以提供快速的反饋，構建安全而完整的自動化測試以滿足應用程式快速變更的需
求，並較早讓使用者參與以構建正確的、有價值的測試。為了實現這些，他們需要接受多技能的職業培訓，以獲得最先進的測試方法。單獨的測試人員不能帶來測試的
高效，需要增加測試人員和業務專家、測試人員和開發人員以及測試人員和終端使用者之間的協作。鼓勵使用敏捷方法、工具和技術，從而有助於隨時隨地的協作來很
好地應對變更。

參考：
  Fit/FITNESSE：

•        
http://fit.c2.com/

•        
http://www.fitnesse.org/

•        
http://gojko.net/fitnesse/fixturegallery/

•        
http://www.fitnesse.info/

 

Selenium:

• http://www.openqa.org/selenium/
• 開源測試載入器/社區(Selenium /OpenQA.org)——今非昔比
• 強大的Web開源測試載入器—Selenium
• 開源測試載入器的完整解決方案
• 技術佈道——全程軟體測試