在完成以上所有事項之后，現在，我們該如何有效的將我們想要的結合到我們的代碼里呢？提供給用戶一個或兩個實現一些GUI需求的產品是不足夠的。長遠來說，為了達到最大的客戶滿意度及增強業務及時性，任何組織應該力求提供一致的GUI軟件。由開發組織提供的所有產品必須貫穿一致【注意，GUI特征的更改是從屬于用戶需求的變更】。這就要求GUI標準的文檔化，并且需要被嚴格的遵守和實施。在發貨給用戶之前產品必須根據這些標準進行驗證。
這也要求在所有的直接和產品開發相關的技術人員之間共享GUI標準工作進展。這可以通過執行組織范圍的培訓達成。讓每個人知道不僅要嚴格實施標準，而且要理解遵循這些標準的需要，這是是很重要的。
以下是一些為了標準化，可能需要關注的GUI元素（在一個客戶端/服務器產品）：
（p.s.一下為一些常見的UI名詞，不作翻譯。）
Ø Dialog Boxes – Property, Function, Process and Message Types
· Modal Dialog
· Modeless Dialog
· Search Dialog Boxes
· Other types of Dialog Boxes
Ø Message Boxes
· Information
· Warning
· Critical
Ø Menus
· Shortcut Menus
· Menu Items
Ø Controls
· Command Buttons
· Button Action
· Ellipsis Buttons
· Option Buttons
· Check Boxes
Ø Keyboard Support
· Access Key for OK / Cancel
· Function Keys as Access Keys
Ø Text / Numeric / Alphanumeric fields
· Text Boxes
· List Boxes
· Check List Boxes
· List views
· Combo Box
· Multi-Line Edit fields
Ø Visual Entities
· Cursor Movements
· Tab [Forward Tab]
· Shift + Tab [Backward Tab]
· Cursor Movement Keys
· Default Commands
· Fonts
· Capitalization
· Color
Ø Organization Specific Screens
· Logon Screen
· Splash Screen
· About Screen
· Screen Navigation
Ø Other GUI Elements
· Classic Menu
· Tab Form
· Multi-page Form
· Accumulator
· Access and Exit of all windows
我們可能還會有更多的元素增加到這個列表中，象在醫療保健應用程序或每個窗口里顯示的應用程序的名稱－“Patient Ribbon”。例如，如果我們稱一個應用程序的名稱為“Standard Salary Manager”，開發組織可能想在主應用程序框架的標題欄里都顯示這個名字。如果在這個應用程序里有一個功能叫“Employee Gross Salary”，那么和這些屏幕相關的功能之后為子窗口命名。例如，“Employee Gross Salary – New (to add a new gross salary data for a new employee)”，“Employee Gross Salary – Edit” (to modify a gross salary data for an existing employee)”或“Employee Gross Salary –View” (to read-only the gross salary data for an existing employee)”。
GUI確認測試
GUI驗證測試主要就是要求確保在編碼過程中嚴格地遵守了每個產品的開發期間需要被實現的標準。主要就是驗證是否遵守植入產品里的公司自己的GUI標準。
下圖（圖1）列舉了一個簡單，但是很有效的執行確認測試的方法。
圖1 GUI確認測試的模型
一些執行GUI確認測試的指南
· 為了手工測試和自動化（如果有的話）準備GUI測試策略，它可以適用于貫穿所有的項目
· 針對手工測試和自動化，為當前的活動設計GUI測試計劃
· 專門為此活動分配資源&全部時間用于驗證不同項目的GUI特性
· 可以為每個GUI元素準備通用的測試用例文檔，它可以適用于被測試的所有應用程序的每個窗體。
例如，如果測試人員在某個窗體里碰到一個單選按鈕，他必須參考單選按鈕測試的測試用例文檔，然后驗證是否迎合單選按鈕的所有期望結果。
· 另外一個方法是，通過準備所有標準GUI元素的checklist，然后在測試執行時將結果填在表中，無論期望的行為是否實現。在這種情況下，每個窗體的確認都會有很多的checklist需要填寫。
· 按照設計好的計劃運行/執行測試
· 手工測試是最好的方法之一，因為它節約資源并且在軟件中不時發生變更時通常是最好的，
· 如果你有GUI測試的自動化測試工具，例如Mercury Interactive (WinRunner / Astra QuickTest for Web)或Segue (SilkTest)，它們都可以使用與測試GUI的特性（假設不會太頻繁地對需求做大量的變更）
· 即使采用了自動化測試，最好都要執行手工測試以確保GUI的所有方面，包括那些不可能被自動化的地方
· 自動化測試提供給測試人員速度，可重復性，覆蓋率，可靠性，可重用性&可編程性
· 當必須在每個build里運行測試，針對數據驅動測試，回歸測試或腳本的遠端執行，使用不同瀏覽器做的同一測試，關鍵性任務頁面等，自動化測試可能是非�？尚械�，
· 自動化測試對于一次性測試，ad-hoc測試，沒有預期結果的測試等等，可能是不理想的
· 需要注意的非常重要的事情是，幾乎是很難去檢查指定的像素是由某某顏色組成，某個對象是否是多少大小。并且在Web里，如果希望腳本運行在不同的瀏覽器里，對象的大小可能不同。除非可用性對于任何一個應用程序都是非常重要的，否則自動化這樣的測試沒有任何希望。
· 一旦執行了測試，就要準備測試結果并且發送給所有有關的人。測試結果文檔可能包括所測試應用程序里的每一個窗體里已提交的bug。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
