在如何或何處將可測試性作為設計標準方面的一些例子，有助于測試和自動化測試，例如：
● 確保用戶界面和商業邏輯的分離，使得我們可以在適當的層次進行測試（用戶界面或業務層）。這允許測試工具（如FIT/ FITNESSE）可以在UI設計沒有最終確定或沒有UI的情況下通過API進行測試。
● 可以更有效地使用UI對象的ID來完成UI的自動化測試
● 當外部系統不可用或仍處于開發階段的時候，構建可配置的模擬系統來測試應用程序
軟件測試的新趨勢
● 從“精小”方面看測試 – 測試如何能夠消除在交付過程中的浪費。這個思想確實可以驅動在工具方面和構建一個更具協作性的測試理念方面的改變，這種測試理念可以綜合考慮利用IT項目中每個個體的能力而不僅僅是測試人員。
● 測試作為一個持續的反饋機制 – 測試正在漸漸成為一個持續的反饋機制，而不是在開發周期末尾的、已計劃的活動。在一個構建流水線中，集成到持續的事件驅動機制中的功能測試意味著測試被應用程序的變化所驅動，而不是時間表所驅動。
● 用于定義測試的更高級語言 – 這些語言可以被非IT客戶人群所理解。這使得測試可以被其他人所理解，而且允許不同的項目相關利益者或干系人（stakeholder）了解測試的價值。
● 在項目生命周期的早期開始自動化 – 正在開發的工具和框架使得測試維護是一個相對簡單的任務。我們認為，由于測試代碼和開發人員的代碼類似，因此也可以從快速開發環境中的開發實踐里獲益，如重構（用以在代碼中進行小的設計變更，而不影響行為。被目前的許多IDE所支持）和基于良好的面向對象編程的測試框架。
● 不僅僅是GUI驅動測試, 而且通過GUI的各個層次（包括底層）驅動測試。例如，測試和反饋一樣重要，所以不管在哪個層次進行測試，關鍵是提供正在構建的應用程序是否正確的反饋。如FIT/ FITNESSE測試框架有助于構建可重復的、可擴展的、易讀的非GU測試套件。
● 開源軟件作為商業測試工具的可能的替代 – 商業工具提供商在自動測試領域并不具有絕對的優勢。一個開發人員和測試人員的大型社區正在推行開源工具的廣泛使用和開發。成功的工具和框架（如Selenium和 Fitnesse）就是開源工具在測試領域的有力證明。
新一代的專業測試人員
● 測試人員不再被看做搞怪的人（monkey tester）或者是令人掃興的人（party pooper），而是在產品環境中應用程序可成功交付的干系人。
● 測試人員表現為客戶和項目干系人的代表。
● 測試人員需要展示其對業務、客戶需求的優先級和市場實際狀況等的理解能力。
● 測試人員保護客戶和項目干系人的利益，同時支持開發人員開發出更好的軟件產品。
● 測試人員幫助開發團隊避免偏離正確的軌道（局面不失控），如風險抑制、用正確的方式構建正確的東西、在開發周期早期檢測應用程序的薄弱環節或區域。
● 測試人員將逐漸地將測試和開發團隊的敵對關系轉換為協作的關系。
21世紀的組織需要在交付周期的早期引入測試以提供快速的反饋，構建安全而完整的自動化測試以滿足應用程序快速變更的需求，并較早讓用戶參與以構建正確的、有價值的測試。為了實現這些，他們需要接受多技能的職業培訓，以獲得最先進的測試方法。單獨的測試人員不能帶來測試的高效，需要增加測試人員和業務專家、測試人員和開發人員以及測試人員和最終用戶之間的協作。鼓勵使用敏捷方法、工具和技術，從而有助于隨時隨地的協作來很好地應對變更。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
