在完成以上所有事项之后，现在，我们该如何有效的将我们想要的结合到我们的代码里呢？提供给用户一个或两个实现一些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。
文章来源于领测软件测试网 https://www.ltesting.net/
