按钮位置：OK按钮总是在上方或者左方,而Cancel按钮总是在下方或右方。 等价键：Cancel按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter保持一致。
测试按钮能否正常的实现功能，常用按钮的功能为： OK（确定）接受输入的数据或显示的响应信息，关掉窗口
Cancel（取消）不接受输入的信息，关掉窗口。取消时最好给予提示，尤其时有大量输入的窗口。
Close（关闭）：结束当前的任务，让程序继续进行；关掉数据窗口 Help（帮助）：调出程序的帮助信息 Save（保存）：保存数据，停留在当前窗口。如过保存耗时长的话，最好显示类似沙漏，进度条之类的提示。注意验证能否重复保存。如在IE中由于网速慢而导致的重复保存。
Add（新增）：新增记录。新增的记录必须排在首页首行。提交失败后必须保留用户已输入的内容，以便再次提交。提交时需对主要标识字段进行重复值、空值（空格）判断。
Update/Edit（编辑）：修改/编辑记录。如界面存在复选按钮，勾选多条记录进行修改时，需给予只能对一条记录进行修改，默认为第一条的提示信息。修改时加载的内容都为该记录的实际内容，而不再为默认值。修改完成后必须回到原记录所在位置，且刷新显示修改后的值。提交失败后必须保留用户已修改的内容，以便再次提交。在查询条件下修改返回后如不满足查询条件则不显示，反之满足当前的查询条件则需显示新增的记录。需对主要标识字段进行重复值、空值（空格）判断。
Delete（删除）：删除记录。在删除之前必须有确认删除的提示信息。删除成功后刷新不显示被删除的记录。删除成功后返回到原记录所在页面；而当原记录所在页不存在时，则返回上一页。当被删除的记录与其它记录存在关联时，应给予不允许删除及更明细提示等信息。针对大批量的删除应提供全选复选框，方便用户删除。
Search（查询）：查询记录。每次查询应显示返回的结果数。每次查询应定位到首页。保留前一次的查询条件。当查询条件较多时，需配以重置按钮。当未查询到任何记录时，需给予未查找到相关记录的提示信息。除用户明确要求不需要外，需提供模糊查询及组合查询功能。当查询返回的结果大于默认的一页大小时，最好采用分页或者根据系统默认或用户定义的一页显示的记录数量来分页。如有多页，需要提供首页，下一页，上一页，尾页和跳至功能。每页的记录不能重复，但也可以根据用户需要显示上一页的最后一条数据。
Reset（重置）：重置。应回到打开窗口时的最初状态。多次点击是否还能正常显示。 Return（返回）：返回。如果一个窗口或页面不能通过菜单，工具栏到达，而是必须通过前一个窗口完成才到达，应提供返回按钮或导航条让用户可以返回。
如果点击按钮后还需要用户的进一步的操作，按钮的名称应加上省略号。如Browse。。。 OK/Cancel/Apply/Help键的排放最好遵从Windows的标准排放。
按钮最好都给予浮动提示，特别是图片按钮，可以避免由于网络太慢而导致的太长时间不能往下操作。
GUI测试之对话框、消息框篇
对话框/消息框的缺省
一般来说重要的或复杂操作成功后应该给予提示，根据系统的特性选择弹出信息框或文字显示。需要后续操作的操作在成功后应给予提示。
非法的输入或操作应给出足够的提示说明。
对可能造成数据无法恢复的操作应该给予确认信息，给用户放弃选择的机会。如删除操作。
提示信息不宜太长，宽度不能超过当前窗口的1/2；当超过此比例时，请视具体情况进行换行。有多行提示信息的，请选择对齐方式（一般为左对齐）。
静态文本标签一般采用左对齐，这样显得更有条理且易于浏览。 静态文本标签一般置于相关控件的左边，有时选项过多过长时放在上面。
复杂或带有专业性的操作或输入最好在输入项下面给予提示。
通用对话框控件，如Open?，Save As?，Color?，Fonts?，Print?，Page SetUp?等调用系统的对话框只需要是否调用正确，能否实现正常功能就可以了，里面的具体功能可以不用测试。
消息框中的图标必须根据需要选择正确的使用，一般来说 X 表示有很重要的问题需要提醒用户；? 增亮没有危险的问题； ! 强调警告用户必须知道的事情； i 一般信息，可以使乏味的信息变得有趣。
正在进行的操作提示框应使用省略号，如“删除中。。。”。 对话框标题文本中不要出现省略号。如选择\打印选项...\命令结果而显示的对话框的标题应该为\打印\，而不是“打印。。。”。但是，表示命令正在执行过程中菜单对话框（如\连接到Internet...\对话框）是一种例外情况。
对于耗时的操作都应给出类似等待光标、进度表或其他的可视反馈。用户可以取消长时间的操作。如果可以取消未完成的操作，那么将按钮标记为\取消\，否则将按钮标记为\停止\。
测试用例设计--因果图方法
一. 方法简介
1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
2.因果图法产生的背景：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
3.因果图介绍
1) 4种符号分别表示了规格说明中向4种因果关系。
2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。
3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。
4. 因果图概念 1) 关系
① 恒等：若ci是1，则ei也是1；否则ei为0。
② 非：若ci是1，则ei是0；否则ei是1。
③ 或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。 ④ 与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。 2) 约束
输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。
A.输入条件的约束有以下4类： ① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。 ② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。 ③ O约束（唯一）；a和b必须有一个，且仅有1个为1。 ④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。 B.输出条件约束类型
输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。 5. 采用因果图法设计测试用例的步骤：
1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。
3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
4) 把因果图转换为判定表。
5) 把判定表的每一列拿出来作为依据,设计测试用例。
网站测试的主要方面
1功能测试
对于网站的测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求规格说明书》及《详细设计说明书》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。
● 链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：
1）测试所有链接是否按指示的那样确实链接到了该链接的页面； 2）测试所链接的页面是否存在；
3）保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
Xenu------主要测试链接的正确性的工具
可惜的是对于动态生成的页面的测试会出现一些错误。 ●表单测试
当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
B/S结构实现的功能可能主要的就在这里，提交数据，处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能，编写可重复使用的脚本代码，可以在测试、回归测试时运行以便减轻测试人员工作量。
我们对UM子系统中各个功能模块中的各项功能进行逐一的测试，主要测试方法为：边界值测试、等价类测试，以及异常类测试。测试中要保证每种类型都有2个以上的典型数值的输入，以确保测试输入的全面性。
●Cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作而且对这些信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
●设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
●数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。
2性能测试
网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。
网站的性能测试主要从三个方面进行：连接速度测试、负荷测试（Load）和压力测试（Stress）.连接速度测试指的是打开网页的响应速度测试。负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。
●连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就
需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
●负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
●压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
压力测试的区域包括表单、登陆和其他信息传输页面等。 采用的测试工具：
性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具 ab -----Apache 的测试工具 OpenSTA—开发系统测试架构 3 接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
●服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
●外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。（简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。）通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
●错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
4 可用性测试
可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。
●导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对