图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南：

窗口：
· 窗口是否基于相关的输入和菜单命令适当地打开？
· 窗口能否改变大小、移动和滚动？
· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
· 当被覆盖并重新调用后，窗口能否正确地再生？
· 需要时能否使用所有窗口相关的功能？
· 所有窗口相关的功能是可操作的吗？
· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示？
· 显示多个窗口时，窗口的名称是否被适当地表示？
· 活动窗口是否被适当地加亮？
· 如果使用多任务，是否所有的窗口被实时更新？
· 多次或不正确按鼠标是否会导致无法预料的副作用？
· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
· 窗口是否正确地被关闭？

下拉式菜单和鼠标操作：
· 菜单条是否显示在合适的语境中？
· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
· 下拉式操作能正确工作吗？
· 菜单、调色板和工具条是否工作正确？
· 是否适当地列出了所有的菜单功能和下拉式子功能？
· 是否可以通过鼠标访问所有的菜单功能？
· 文本字体、大小和格式是否正确？
· 是否能够用其他的文本命令激活每个菜单功能？
· 菜单功能是否随当前的窗口操作加亮或变灰？
· 菜单功能是否正确执行？
· 菜单功能的名字是否具有自解释性？
· 菜单项是否有帮助，是否语境相关？
· 在整个交互式语境中，是否可以识别鼠标操作？
· 如果要求多次点击鼠标，是否能够在语境中正确识别？
· 光标、处理指示器和识别指针是否随操作恰当地改变？

数据项：
· 字母数字数据项是否能够正确回显，并输入到系统中？
· 图形模式的数据项（如滚动条）是否正常工作？
· 是否能够识别非法数据？
· 数据输入消息是否可理解？

　　A测试用例设计

　　 测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：

　　测试用例的基本格式

　　 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。

　　 用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。

　　 测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。

　　 重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，

　　 测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。

　　 操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。

　　 预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。

　　 软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。

　B　 重用同类型项目的测试用例

　　 @@@@@如果我看得远，那是因为我站在巨人的肩上 －－牛顿。@@@@@

　　 一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。

　　 利用已有的软件 Checklist

　　 在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。

　　加强测试用例的评审

　　 测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。

　　定义测试用例的执行顺序

　　在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。

　　测试用例执行

　　测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：

　　 搭建软件测试环境，执行测试用例

　　 测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。

　　 如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。


　　 测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：

　　全方位的观察测试用例执行结果：测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

　　加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

　　及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

　　与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

　　及时更新测试用例

　　 测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。

　　 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

　　提交一份优秀的问题报告单

　　 软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。

　　 软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

　　 硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确详实的记录硬件配置情况。

　　 测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。

　　 输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。

　　 日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

　　 根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。

　　测试结果分析

　　 软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试中避免盲区。

• 1.集成测试
• 集成测试是在软件项目/产品在系统集成过程中所进行的测试，其主要目的是检查软件项目，组件之间的接口是否正确，以及每个组件功能是否按照需求规格说明书编制。
• 根据集成测试进度计划，一边将软件组件或其他软件单位组合成越来越完整的系统，一边运行该系统，以检测所组成的系统是否正确。
• 包括功能集成测试和非功能集成测试（备注：目前主要进行的是性能、压力、并发、效率测试。）。

• 2.系统测试
• 系统测试是对已经集成好的软件项目/产品系统进行彻底的测试，以验证软件系统功能和性能满足其需求规格说明书所指定的要求，检查软件的行为和输出是否正确。
• 系统测试按照系统测试进度计划进行。
• 包括功能系统测试和性能、以及非功能性系统测试（备注：目前主要进行的是性能、压力、并发、效率测试。）

• 3.冒烟测试
• 冒烟测试又称为可接收性测试，是测试部在开始大范围功能或性能测试前，对最基本功能主要流程的简单测试，验证系统是否满足接收测试的标准。满足标准测试部开始测试，否则返回程序开发部重新修订。
• 同时测试部协助查找造成该版本不能开始测试的主要原因，程序开发加以修订再送测。
• 依据《接收测试标准》

• 4.回归测试
• 回归测试根据已经关闭的缺陷再重新进行的测试。目的在于验证以前出现过，但已经修复好的缺陷不再重新出现。
• 在验证已经关闭的缺陷不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。
• 因此鼓励对所有回归测试用例实现脚本化，虽然对于目前功能自动化测试还是一个非常困难的工作

• 5.a测试
• α测试规定是企业内部项目/产品在企业内部试用的过程。
• 根据项目/产品情况，企业高层管理者确定项目/产品是否需要开展α测试。
• α测试可以从软件项目/产品编码结束之时开始，或在项目/产品系统测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠性之后再开始。
• α测试由产品经理主持，产品运维部搭建项目/产品运营环境，产品经理协助收集新需求，测试组长协助验证产品缺陷

• 6.β测试
• β测试是由企业的外部用户在实际运营环境下进行的使用。这些用户是与企业签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意反馈有关信息给企业。
• β测试由产品经理主持，产品运维部搭建项目/产品运营环境，产品经理协助收集新需求，测试组长协助验证产品缺陷。
• 只有当α测试达到一定的可靠程度时，才开始β测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。

• 7.功能测试
• 验证软件功能能否正常按照它的功能需求规格说明书和UI进行工作。
• 包括满足明确的或者隐含的功能，检验运行软件时的期望行为是否符合原需求规格

• 8.性能测试
• 在软件工程中，性能测试属于效率测试的一部分。
• 按照需求规格说明书中性能测试需求，验证软件的性能水平是否能够满足需求点。

      9.可维护性测试

      检测软件是否允许或方便的进行修正、改进或更改的能力。

      10.可移植性测试

      检测软件是否可从某一环境转移到另一环境（系统体系结构、硬件或软件环境）的能力。

      11.用户文档测试

• 完整性：用户文档应包含产品使用所需信息。
• 正确性：用户文档中所有信息应是正确的，不能有歧义和错误的表达。
• 一致性：用户文档自身内容或相互之间以及与产品描述之间都不应相互矛盾。每个术语的含义宜处处保持一致。
• 易理解性：用户文档对于正常执行其工作任务的一般用户是易理解的。
• 易浏览性：用户文档宜易于浏览，以使相互关系明确

• 12.用户界面测试
• 分析软件用户界面的设计是否合乎用户期望或要求。
• 常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息（菜单和在线帮助）等方面的测试。

      13.白盒测试

• 通过程序的源代码进行测试，而不使用用户界面。
• 这种类型的测试需要从代码语法和代码规范发现内部代码在算法、溢出、路径、条件等等中的缺陷或者错误，进而加以修正。

     14.黑盒测试

• 通过使用整个软件或某个软件界面严格地执行测试,而不关心程序源代码。
• 测试人员通过输入数据（正确数据、错误数据）看输出的结果，从而了解软件怎样工作。

• 15.灰盒测试
• 灰盒测试就像黑盒测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某个软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。
• 测试人员可以有的放矢地进行某种确定条件的功能测试。

• 16.有效用例
• 有效用例(Valid case)或者叫合法输入用例。
• 是已知软件程序能正确地处理的测试用例。

• 17.无效用例
• 无效用例（Invalid case）或者出错用例(error case)：描述在不合法输入时程序的反应。
• 也就是程序在不合法输入时可以得到正确的预期处理结果。

• 18.等价类划分测试
• 等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。
• 等价类的划分有两种不同的情况：
  ①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。

     　②无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。

• 在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

• 19.边界值测试
• 边界值测试，是对等价类测试方法的补充。这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值或稍低于其边界值的一些特定情况。
• 使用边界值方法设计测试用例，首先应确定边界情况。应当选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。

• 20.国际化测试
• 验证软件程序在不同国家或区域的平台上也能够如预期运行，支持使用当地常用的日期，字体，文字表示，特殊格式等。
• 例如：数商的多语言版本，繁体、英文、日文、法语、阿拉伯语、德语等

• 21.本地化测试
• 本地化测试要验证所有已计划要发布的不同语言版本软件，是否能被正确地翻译成当地语言。
• 这类测试一般包括验证菜单，对话框，出错信息，帮助内容等所有用户界面上的文字都能够显示正确翻译好的当地文字。

• 22.探索性测试
• 探索性测试：使操作流程复杂或者非正当操作流程的情况下进行破坏性测试。
• 即：目前所谓的测试工程师在遍历测试用例后，进行的发挥性测试。

      23.偶发性测试

       在测试过程中按照一定的操作步骤发现的Bug，但是不是每次都能复现。这样的Bug称为偶发Bug