WEB测试用例.doc

一些常用模块的测试用例
1、登录　　2、添加　　3、查询　　4、删除
1、登录
①用户名和密码都符合要求（格式上的要求）
②用户名和密码都不符合要求（格式上的要求）
③用户名符合要求，密码不符合要求（格式上的要求）
④密码符合要求，用户名不符合要求（格式上的要求）
⑤用户名或密码为空
⑥数据库中不存在的用户名，不存在的密码
⑦数据库中存在的用户名，错误的密码
⑧数据库中不存在的用户名，存在的密码
⑨输入的数据前存在空格
⑩输入正确的用户名密码
以后按[enter]是否能登陆
2、添加
①要添加的数据项均合理，在界面保存成功后，检查数据库中是否添加了相应的数据：select查询
②留出一个必填数据为空
③按照边界值等价类设计测试用例的原则设计其他输入项的测试用例：数据组合测试
④不符合要求的地方要有错误提示
⑤是否支持table键
⑥按enter是否能保存
⑦若提示不能保存，也要察看数据库里是否多了一条数据
3、删除
①删除一个数据库中存在的数据，然后查看数据库中是否删除（界面删除一条数据，查看数据库中是否删除）
②删除一个数据库中并不存在的数据，看是否有错误提示，并且数据库中没有数据被删除如何实现？

③输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。
④输入的正确数据前加空格，看是否能正确删除数据
⑤什么也不输入
⑥是否支持table键：tab键
⑦是否支持enter键
4、查询
精确查询：
①输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
②输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据
③输入格式或范围不符合要求的数据，看是否有错误提示：如日期格式：YYYY-MM-DD；范围：月份中输入13等，一般这些数据都是枚举型数据，以下拉框的形式出现
④输入数据库中不存在的数据
⑤不输入任何数据：查询结果应该为所有记录
⑥是否支持table键
⑦是否支持enter键
模糊查询：
在精确查询的基础上加上以下一点：
① 输入一些字符，看是否能查出数据库中所有的相关信息

故障模型---缺陷查找攻击的二十一招大法

1．输入非法数据
输入数据的类型、长度、边界值；还要留意错误信息本身。
基本数据类型的边界值
2．输入默认值
从选项按钮、配置面板等处去考察。
3．输入特殊字符集
根据被测软件的具体情况输入非法字符。
多了解ASCII 字符集、程序设计语言和OS中的保留字符串及其特定含义。
4．输入使缓冲区溢出的数据
在需要接受字符串的地方输入一个比最大字符串更长的字符串。
黑客常用此法来攻击系统。
5．输入产生错误的合法数据组合
在输入值之间存在依赖关系时，输入可能会出现问题的组合值。
6．产生同一个输入的各种可能输出
在同一输入对应多个输出时可用此法测试。
7．输出不符合业务规则的无效输出
列出所有的无效输出，然后逐一测试，重点查看输出结果的正确性。
8．输出属性修改后的结果
强制每个输出产生，并编辑其属性，然后再次强制产生输出。
9．屏幕刷新显示
增加、删除、移动屏幕上的对象。
10．数据结构溢出
尝试将过多的值输入数据结构，测试上溢；尝试多删除一个数据，测试下溢。
11．数据结构不符合约束
任何时候都要对数据属性的约束进行检查，特别注意修改数据时也要进行。
可通过破坏内部数据的约束来进行测试。
12．操作数与操作符不符合
对于数值计算考虑操作数和操作符之间的限定关系；对于图形计算还要考虑各种输入数据之间的组合关系。
13．递归调用自身
考虑对象的自我交互或复制。
14．计算结果溢出
一次又一次地执行计算或使用很大或很小的输入和数据进行计算，重点测试数据类型的初始值或边界值附近的值，强制数据产生上溢或下溢。
15．数据共享或关联功能计算出错
当一个以上的功能在同一时间处于运行状态，可以考虑以点带面，重点测试某一功能，对可能与这个功能相连的其他功能附带测试。
16．文件系统超载
当软件较大，运行时需要较大空间时，强制磁盘系统满容量或小于等于被测试软件运行时所需容量后，运行被测试软件或利用测试工具模拟磁盘状况。
17．介质忙或不可用
软件运行需要消耗大量内存或需要其他相关软件同时运行，可通过启动大量程序或利用测试工具模拟磁盘状况。
18．介质损坏
用实际损坏介质的方法来测试应用程序。
19．文件名不合法
输入OS不允许的文件名和应用程序不允许的文件名。
20．更改文件访问权限
修改文件访问权限或用低权限的用户访问文件。
21．文件内容受损
对于那些需要对文件格式和内容进行校验的应用程序，可通过手工损坏文件或利用测试工具模拟CRC错误。

界面设计的行业标准总结一
　GUI的整体标准包括以下四个方面：
　　1.规范性
　　2.合理性
　　3.一致性
　　4.界面定制性
　　一、GUI设计的规范
　　遵循一致的准则，确立标准并遵循，是软件界面设计中必不可必的环节。确立界面标准的好处：
　　1.便于用户操作：户使用起来能够建立起精确的心里模型，使用熟练了一个界面后，切换到另外一个界面能够很轻松的推测出各种功能
　　2.使用户感觉到统一、规范，在使用软件的过程中愉快轻松的完成操作，提高对软件的认知
　　3.降低培训、支持成本，不必花费较多的人力对客户进行逐个指导
　　二、GUI布局的合理性
　　界面的合理性是指界面是否与软件功能相融洽，界面的颜色和布局是否协调等。例如：
　　1.界面布局
　　a.屏幕不能拥挤
　　*  Mayhew在1992年的试验结果表明屏幕总体覆盖度不应该超过40％，而分组覆盖度不应该超过62％。
　　*  整个项目，采用统一的控件间距，通过调整窗体大小达到一致，即使在窗体大小不变的情况下，宁可留空部分区域，也不要破坏控件间的行间距。
　　b.控件按区域排列
　　*  一行控件纵向中对齐, 控件间距基本保持一致，行与行之间间距相同，靠窗体的控件距窗体边缘的距离应大于行间距。
　　*  当屏幕有多个编辑区域，要以视觉效果和效率来组织这些区域
　　c.有效组合
　　逻辑上相关联的控件应当加以组合以表示其关联性，反之，任何不相关的项目应当分隔开。在项目集合间用间隔对其进行分组，或者使用方框划分各自区域
　　d.窗口缩放时控件位置、布局
　　*  固定窗口大小，不允许改变尺寸
　　*  改变尺寸的窗口，在窗口尺寸发生变化时控件的位置、大小做出相应的改变
　　*  改变尺寸的窗口，在窗口改变尺寸时增加相应在的纵向、横向滚动条，以方便用户使用窗体上的控件
　　2.界面颜色搭配
　　使用恰当的颜色，可以使软件的界面看起来更加规范：
　　a.统一色调
　　针对软件类型以及用户工作环境选择恰当色调，如：安全软件，根据工业标准，可以选取黄色。绿色体现环保，蓝色表现时尚清新、紫色表现浪漫等等，淡色可以使人舒适，暗色做背景使人不觉得累等。
　　b.与操作系统统一，读取系统标准色表
　　c.遵循对比原则
　　在浅色背景上使用深色文字，深色背景上使用浅色文字，如蓝色文字以白色背景容易识别，而在红色背景则不易分辨。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色
　　d.整个界面色彩尽量少的使用类别不同的颜色
　　e.颜色方案也许会因为显示器、显卡、操作系统等原因显示出不同的色彩
　　f.针对色盲、色弱用户，可以使用特殊指示符
　　e.颜色方案也许会因为显示器、显卡、操作系统等原因显示出不同的色彩
　　f.针对色盲、色弱用户，可以使用特殊指示符
三、GUI风格的一致性
　　界面的一致性既包括使用标准的控件，也指相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。
　　1.在不同分辨率下的美观程度
　　软件界面要有一个默认的分辨率，而在其他分辨率下也可以运行，分别在800×600，1024×768，1280×768，1280×1024，1200×1600分辨率下的大字体、小字体下的界面表现。
　　2.界面布局要一致
　　如所有窗口按钮的位置和对齐方式要保持一致。
　　3.界面的外观要一致
　　如控件的大小、颜色、背景和显示信息等属性要一致，一些需要特殊处理或有特殊要求的地方除外。
　　4.界面所用颜色要一致
　　颜色的前后一致会使整个应用软件有同样的观感，反之会让用户觉得所操作的软件杂乱无章，没有规则或言。
　　5.操作方法要一致
　　如双击其中的项，触发某事件，那么双击任何其他列表框中的项，都应该有同样的事件发生。
　　6.控件风格、控件功能要专一
　　a.不错误的使用控件
　　例如使用Button样式做Table的功能，拿主菜单条显示版权信息等
　　b.一个控件只做单一功能，不复用
　　如果在特殊情况下出现复用的时候，可采用以下两种方法解决：
　　*  分组，使用双份控件
　　*  使用Table页，给用户很明显的视觉变化
　　7.标签和讯息的措词要一致
　　如在提示、菜单和帮助中产生相同的术语。
　　8.标签中文字信息的对齐方式要一致
　　如某类描述信息的标题行定为居中，那么其他类似的功能也应该与此一致。
　　9.快捷键在各个配置项上语义保持一致
　　如Tab键的习惯用法是阅读顺序从从左到右，从上到下。在定义软件快捷键时也可以将现有一些快捷键的属性作为参考，如表1-3-1（见附件）列出了常用的快捷键及其功能。
　　四、GUI界面操作可定制性
　　界面的可定制性大致可分为以下几个特性：
　　1.界面元素可定制
　　允许用户定义工具栏、状态栏是否显示，工具栏显示在界面上的位置；允许用户定义菜单的位置等。
　　2.工具栏可定制
　　不同用户对常用工具的使用是不同的，因此允许用户建立新的工具栏，选择要显示的工具栏，定制工具栏上的按钮等功能在软件系统中经常被用到
　　3.统计检索可定制
　　对于某些特殊行业的软件可以提供统计检索的可定制性，在充分了解用户需求的基础上制定大量的安全供用户选择。
GUI所包含各类元素标准的定制
　　GUI的元素大致可分为以下几个方面：
　　1. 窗口
　　2. 菜单
　　3. 图标
　　4. 控件
　　5. 鼠标
　　6. 文字
7. 联机帮助
界面设计的行业标准总结二
　　一、GUI窗口的标准
　　窗口是显示设备中的一个区域，用于观看对象、对象相关信息以及应用与对象的动作进行交互。从外观上来说，通常窗口是由标题、边框、菜单、工作区、滚动条等组成。窗口的标题栏可以进行打开、关闭、创建、缩放、移动、删除、重叠等操作
　　好的GUI窗口应该具备以下标准：
　　1.窗口控件的大小、对齐方向、颜色、背景等属性的设置和程序设计规约相一致
　　2.显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
　　3.若窗口无法显示，所有内容能够改变大小、移动和滚动
　　4.活动窗口能够反显加亮
　　5.窗口能够正确的关闭
　　6.多个窗口叠加时窗口的名称正确显示
　　7.窗口的数据能够利用鼠标、功能键、方向前头和键盘操作
　　8.当窗口被覆盖并重新调用后，窗口能够正确再生
　　9.如果使用多任务，所有的窗口能够被实时更新
　　10.窗口支持最小化和最大化或放大
　　11.窗口上的控件随着窗体的缩放而缩放
　　12.父窗体支持缩放时，子窗体也应该支持缩放
　　13. 一个窗口中按Tab键，移动聚焦按顺序移动。先从左至右，再从上到下
　　14.子窗口位置在父窗口的左上角或正中，正上方1/4处为易吸引用户注意力的位。父窗口或主窗口的中心位置应该在对角线焦点附近，如下图2-1-2所示
　　15.当多个子窗口弹出时依次向右下方偏移，并且显示出窗口标题，如下图2-1-3所示
　　16.重要的命令按钮与使用频繁的按钮放在了界面醒目的位置
　　17.与正在进行的操作无关的按钮应该加以屏蔽
　　18.按钮大小要与界面的大小和空间协调
　　19.窗口中所包含的标签左对齐排列
　　20.多窗口的切换响应时间不宜过长
二、GUI菜单的标准
　　菜单是否易用主要体现在它能否提供线索帮助用户识别，而不用强迫用户去记忆，一个好的菜单设置可以分为以下几个方面：
　　1.菜单设置符合软件的需求
　　2.菜单项的措词准确，能够表达出所要进行设置的功能
　　3.菜单项的顺序合理，具有逻辑关联的项目集中放置
　　4.图形布局一致
　　5.菜单设置在窗体标题栏的下方
　　三、GUI图标的标准
　　图标是表示实体信息简洁、抽象的符号，它还可以作为可视按钮项，当被选中激活时，可以完成指定的功能。那么图标的设计当中应该着重考虑哪些问题呢，以下提供几点可供参考：
　　1.图标的设置符合常规的表达习惯
　　2.不同的目标采用不同的图标
　　3.图标具有清晰的轮廓，轮廓清晰的图标可保证图像在不同背景色上都具有较好的效果
　　4.选择合适的尺寸来定义图标。Windows XP系统的图标有四种尺寸（以像素为单位）可作为参考： 48×48， 32×32，24×24以及16×16，图标大小的选取决定于工具栏所定义的宽度
　　5.图标的外形与实际功能相似，应尽量避免抽象。这样的图标可以使用户很轻松、容易地认识图标的作用
　　6.在图标上加以标注，用来说明图标所完成的功能
　　7.图标放置在菜单栏的下方
　　四、GUI中控件的标准
　　软件系统功能的实现与控件是密不可分的，各控件位置的摆放直接影响到软件的使用，及其美观程度。下面举例说明软件系统中最常用到的控件对其元素间距、摆放位置进行说明：
　　1.控件元素的间距
　　a.单个元素间距
　　*  输入框之间垂直间距为5px
　　*  Label文本标签和输入元素之间水平间距为8-22px
　　*  复选框、单选按钮之间垂直间距为8px
　　*  多种元素混合垂直排列时，复选框和单选按钮边上的间距无论在什么情况下都为8px
　　b.元素分组间距
　　*  窗口边框和内容区域的四周边距为11px；
　　*  父组和子组之间的四周间距为10px；
　　*  分组框边框和内部内容区域的四周边距为5px；
　　*  复选框组、单选框组的组水平间距为15px
　　2.按钮的位置，如下表2-4-1对按钮摆放位置的规则做了总结

五、鼠标在GUI中的标准
　　用户会把鼠标移进、移出窗口，或当光标在窗口，或当光标在窗口中，用户按下、释放鼠标键，鼠标是否准确、灵活，对一个软件系统来说也很重要。以下几点标准可作为在软件系统中鼠标设计的参考：
　　1.在整个交互的过程中，可以识别鼠标操作
　　2.多次点击鼠标后，仍能够正确识别
　　3.鼠标有多个按钮的情况下，能够正确识别每个按钮所要完成的功能
　　4.光标、处理指示器和识别指针随操作恰当的改变
　　5.点击选中时，鼠标指针停留在选中内容上，而不会滑动
　　6.支持鼠标滑轮上下翻动操作
　　7.对于相同种类的元素采用相同的操作激活
　　8.采用动态图标形象的表示出当前的操作，如用水漏表示系统忙，用手型表示可以点击等
　　9.鼠标无规则点击时不会产生不良后果
　　10.单击鼠标右键弹出快捷菜单，取消右键后该菜单隐藏
　　11.鼠标光标样式统一，尽量使用系统标准，杜绝出现重复的情况
　　六、GUI文字的标准
　　文字在视觉上向用户传达各种信息，界面文字包括界面文字的字体和界面文字的用语两个方面，那这两方面都有哪些要求呢？以下分别阐述。
　　1.字体
　　a.使用统一字体，如规定软件系统的中文字体为“宋体”，英文及数据采用“Times New Roman”
　　b.所有控件、描述信息尽量使用大小统一的字体属性，除了特殊提示信息、加强显示等例外情况
　　2.文字表达
　　提示信息、帮助文档文字表达遵循以下准则：
　　a.口语化描述，用词客气多用您、请，不要用或少用专业术语，杜绝错别字
　　b.标点符号（断句、逗号、句号、顿号、分号）的用法要统一， 提示信息比较多的话要进行分段
　　c.警告、信息、错误 使用对应的表示方法
　　d.使用统一的语言描述，例如一个关闭功能按钮，可以描述为退出、返回、关闭，则应该统一规定
　　e.根据用户不同采用相应的词语语气语调
　　七、GUI联机帮助的标准
　　帮助文档适用于以下三种情况：
　　*  系统默认、行业标准的控件操作不需要逐一描述，只需要对特殊控件加以描述
　　*  特殊操作、特殊功能界面，在界面上加控件直接连接到对应的帮助文件中
　　*  特殊设置的详细信息，除了应该在界面上用简洁明了的语句说明外，还可以在界面上加控件直接连接到对应的帮助文件中
　　帮助文档的标准要求：
　　*  结构化，按功能模块划分
　　*  必须阐述功能通过什么方法可以在软件中实现
　　*  措词恰当、简捷、通俗易懂，明了的帮助用户解决问题
*  不在帮助文档中做广告宣传

浅谈易用性测试及GUI常见的测试要求
对于一个需要面对用户的软件产品来说，最直观的UI和使用感受也是产品能否获得用户认可的关键一环。个人认为，在毒霸的产品传统中，从设计到开发再到测试，对产品的易用性和GUI的规范往往给予的关注较少。我在测试过程中就遇到了很多影响使用心情的非关功能方面的 BUG。希望此文可以在毒霸的易用性和GUI方面的测试中给同学们提供一些参考。
　　易用性测试
　　易用性(Useability)是交互的适应性、功能性和有效性的集中体现。
　　在《软件工程产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性；即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：
　　(1) 易理解性测试
　　(2) 易学性测试
　　(3) 易操作性测试
　　(4) 吸引性测试
　　(5) 易用的依从性测试
　　易用性测试方法有：静态测试；动态测试；动态和静态结合测试。
　　由于易用性缺陷的主观性，因此测试人员和UI设计人员经常产生不同意见。UI通常被当作创造者的作品，而测试人员说某处是错误，就可能挫伤“艺术家”。易用性是软件缺陷中的敏感问题。
　　人体工程学(ergonomics)是一门将日常使用的东西设计为易于使用和实用性强的学科。人体工程学的主要目标是达到易用性。
　　1、用户界面测试
　　用于与软件交互的方式称为用户界面或UI。
　　2、优秀UI的构成
　　软件测试员要负责测试软件的易用性，包括其用户界面。
　　记住，软件测试员不需要去设计UI，只需要把自己当作用户，然后去找出UI中的问题。
　　优秀UI具备的七个要素
　　(1) 符合标准和规范
　　重要的用户界面要符合现行标准和规范，这些标准和规范由软件易用性专家开发。它们是由大量正式测试、经验、技巧和错误得出的方便用户的规则。如果软件严格遵守这些规则，优秀UI的其他要素就自然具备。
　　(2) 直观性
　　* 用户界面是否洁净、不唐突、不拥挤？
　　* UI的组织和布局合理吗？
　　* 是否允许用户轻松地从一个功能转移到另一个功能？
　　* 下一步做什么明显吗？
　　* 任何时候都可以决定放弃或者退回、退出吗？
　　* 菜单或者窗口是否深藏不露？
　　* 有多余功能吗？软件整体抑或局部是否做得太深？
　　* 帮助系统有效吗？
(3) 一致性
　　* 用户的使用习惯性强，希望一个程序的操作方式能够带到另一个程序中。在审查软件一致性时要考虑一下术语：
　　* 快捷键和菜单选项
　　* 术语和命名
　　* 听众
　　* 诸如OK和Cancel按钮的位置
　　(4) 灵活性
　　* 灵活性表现在：用户喜欢选择不要太多，但是足以允许他们选择做什么和怎么做。
　　* 状态跳转
　　* 状态终止和跳过
　　* 数据输入和输出
　　(5) 舒适性
　　* 软件使用起来应该舒适，不能给用户工作制造障碍和困难。如何鉴别软件舒适性的一些好想法：
　　* 恰当。软件外观和感觉应该与所做的工作和使用者相符。
　　* 错误处理。程序应该在用户执行严重错误的操作之前提出警告，并且允许用户恢复由于错误操作导致丢失的数据。
　　* 性能。快不见得是好事。不少程序的错误提示信息一闪而过，无法看清。如果操作缓慢，应该让用户得到相应的信息。
　　(6) 正确性
　　* 要测试正确性，就是测试UI是否做了该做的事。
　　* 市场定位偏差：有没有多余的或者遗漏的功能，或者某些功能执行了与市场宣传材料不符的操作？
　　* 语言和拼写：程序员常常能制造出非常有趣的用户信息。
　　* 不良媒体：图标是否同样大小？是否具有相同的调色板？声音是否应该有相同的格式和采样率？
　　* 所见即所得：保证UI所说的就是实际得到的。
　　(7) 实用性
　　* 是否实用是优秀用户界面的最后一个要素。
　　* 不是指软件本身是否实用，而是指具体特性是否实用。
　　* 在审查产品说明书、准备测试或者实际测试时，想一想看到的特性对软件是否有实际价值。它们有助于用户执行软件设计的功能吗？如果认为它们没必要，就要研究一下找出它们存在于软件中的原因。
　　总之，不要让易用性测试的模糊性和主观性阻碍测试工作。易用性测试的模糊和主观是固然的，即使设计用户界面的专家也会承认有的地方是这样的
GUI常见的测试要求
　　窗口
　　* 窗口能否基于相关的输入或菜单命令适当的打开
　　* 窗口能否改变大小、移动和滚动
　　* 窗口中的数据能否用鼠标、功能键、方向箭头和键盘操作
　　* 当被覆盖的窗口重新调用后，所有相关功能是否可操作
　　* 能否使用所有窗口的相关功能，所有相关功能是否可操作
　　* 相关的下拉式菜单，工具条，滚动条，对话框，按钮，图标和其它控制有否？能否正常显示完全可用？
　　* 显示多窗口时，窗口名能否正确显示，活动窗口是否加亮
　　* 使用多用户时，所有窗口是否能实时更新
　　* 多次或不正确按鼠标是否会产生无法预测的结果
　　* 窗口的声音、颜色提示和窗口的操作顺序是否符合需求
　　* 窗口能否正确关闭
　　数据项
　　* 字母、数据能否正确显示且输入系统
　　* 图象方式数据项（如滚动条）是否正常工作
　　* 数据输入、消失是否可以理解，能否识别非法数据
　　下列式菜单和鼠标操作
　　* 菜单条显示在合适语言环境中
　　* 应用程序的菜单是否显示系统相关特性
　　* 下拉式操作是否正确，功能是否正确
　　* 菜单调色板和工具条是否能正常的工作
　　* 能否列出所有菜单功能和下拉式功能
　　* 能否通过鼠标操作所有菜单的功能，通过文本命令激活每个菜单功能
　　* 菜单功能随当前窗口操作加亮或变灰
　　* 如果要求多次点击鼠标或鼠标有多个按钮时能否正确识别
　　* 光标、处理指示器和识别指针能否随操作而适当改变
UI测试常见BUG
录入界面
　　1. 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）
　　2. 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）
　　3. 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息
　　 (1) 长度校验

　　 (2) 数字、字母、日期等等的校验
　　 (3) 范围的校验
　　4. 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示
　　5. 下拉框不选值的时候应该提供默认值
　　6. 相同字段的录入方式应该统一（录入方式有以下几种：手动输入 、点选 、下拉选择、参照）
　　7. 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）
　　8. 日期参照应该既能输入，又能从文本框选择
界面格式
　　1. 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性
　　2. 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性
　　3. 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致
　　4. 不同界面显示相同字段的一致性（如列表界面和编辑界面）
　　5. 界面按钮显示要求（查询、新增、删除顺序）
　　6. 列表的顺序排列应该统一（按照某些特定条件排序）
　　7. 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定
　　8. 所有弹出窗口居中显示或者最大化显示
　　9. 信息列表中如果某个字段显示过长用“…”或者分行显示
　　10. 人员、时间的缺省值一般取当前登录人员和时间
　　11. 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”
功能问题
　　1. 按钮功能的实现（如返回按钮能否返回）
　　2. 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示
　　3. 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）
　　4. 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮（即空白选项）、还需要有一个‘全部’选项。
　　5. 没有选择记录点击删除/修改按钮要提示“请先选择记录”
　　6. 选择记录后点击删除按钮要提示“确实要删除吗？”
　　7. 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容（当存在关联的数据时，此记录应该不能删除，必须将其关联的记录先删除，才能再回到此界面将此记录删除）
　　8. 界面只读的时候（查询、统计、导入）等，应该不能编辑。
查询问题
1. 查询条件缺少一些可以查询的字段（在查询条件中应当将可以进行查询的字段都列举出来并支持该字段的查询），
查询条件分为：可输入和枚举型（点选、框选、下拉框选择、日期选择：‘年月日分开选择’或‘弹出日期选择界面’）等两大类。
　　2. 有些查询条件需要支持模糊查询：关键字查询即部分匹配
3. 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）：
即查询条件的过滤功能
（比如第一个下拉框选择选择‘浙江省’，则第二个下拉框自动过滤出属于浙江的地区名称如‘绍兴市、宁波市、杭州市…等’；选择其中一个，则在第三个下拉框中出现该地区包括的县级城市名称）
　　4. 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一
5. 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）
不同模块相同字段显示的字段名称应该完全统一。
　　6. 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么。
7. 对于范围的查询采用全闭的形式。

输入数据的设计方法和测试用例设计方法
测试用例的设计是测试设计的重要内容，关于测试用例的设计方法，当前不少出版的测试书和发表的测试文章，不少存在着表述错误，主要是把测试用例中的输入数据的设计方法与测试用例的设计方法混为一谈，对测试初学者和测试用例设计人员产生误导。
这种错误的主要表现举例如下：
测试用例的设计方法包括：
(1)等价类划分法
(2)边界值法
(3)功能图与判定表法
(4)错误推测法
(5)用户场景法
(6)......
其实，测试用例中输入数据的设计方法只是测试用例设计方法的一个子集，上面列出的集中方法都是确定黑盒测试用例的输入测试数据的一般方法，而不是测试用例的设计方法。
除了确定输入数据之外，测试用例的设计还包括如何确定测试用例的设计策略，如何组织设计用例，如何从测试需求等文档创建完整的测试用例。
对测试执行人员来说，测试用例的表示内容包括以下几个方面：
(1)测试用例的测试目标
(2)测试用例的被测功能点描述
(3)测试用例的测试运行环境
(4)测试用例的执行方法(包括测试步骤，输入测试数据或测试脚本)
(5)测试期望的结果
(6)执行测试的实际结果
(7)其他辅助说明
从以上几点，我们可以看到输入测试数据只是设计测试用例的一个步骤，而不是全部。
测试用例的设计是一项复杂的测试工作，测试用例的设计方法需要考虑测试的目标，被测试软件的特性，测试者人力资源的技术和能力，测试组织形式，测试进度、测试成本等多个方面。
网站测试清单
通用
◇ 所有测试是否运行在干净系统上？
◇ 系统是否正常运行？
◇ 是否显示正确输出？
◇ 系统是否能提供所需功能？
◇ 普通用户是否能轻松地操作该系统？
◇ 是否易学易用？
◇ 系统是否会为客户提供服务？如响应的、有帮助的、正确的服务？
◇ 是否可以简单辨别系统的正确性与可靠性？
◇ 是否能轻易地修复或修改系统？
◇ 当系统需要提交或修复时，开发人员是否可以在限期内完成？
◇ 新版本中未经修改的功能是否能与老版本保持一致？
◇ 系统是否能使硬件、网络及人力资源得到有效利用？
◇ 系统是否能匹配相关的技术水平？
◇ 系统是否能匹配适当调整的需求
◇是否可以有效验证系统的工作方式是适当的？
◇ 本系统内一些组成部分是否可以被其他的系统再利用？
◇ 不同用户不同平台上安装系统是否同样快捷便利？
◇ 系统是否设置有未来更新的路径？
◇ 是否可以方便地获取信息？
◇ 网站是否能被搜索？
可用性、界面及导航
◇ 系统为一个用户、十个用户或一千个用户服务时，是否同样工作正常？
◇ 是否可以快速登陆主页？
◇ 网站的操作方法是否清晰地展示给用户？
◇ 如果按操作方法进行操作是否可以得到预期结果？
◇ 是否所有新用户都理解网站内的所有术语？
◇ 是否所有窗体都有导航栏？
◇ 导航栏的位置是否始终保持一致？
◇ 是否导航栏仅作用于使用中的文本？
◇ 用户是否可以在不用鼠标的情况下使用导航栏功能？
◇ 视力障碍者是否可以使用网站？红绿色盲，少于 20/20
◇ 网站标志是否风格一致？
◇ 每个单独页面内是否包含主页链接？
◇ 每个页面的排版是否统一？
◇ 每个页面的管理风格是否一致？
◇ 网站内图表的使用是否协调？
◇ 快速下载的图表是否质量优化？
◇所有图片是为页面添彩，还是浪费网速？
◇ 是否使用了图表的最佳尺寸？
◇ 图表/图片周围的文字布局是否合理？
◇ 是否对所有的参考网站或电子邮件地址都设置了超链接？
◇ 超链接颜色设置是否标准？
◇ 网站在 1024x 768、600x800 等像素下是否显示正常？
◇ 字体是否太小（切忌并非每个人都能获得相同的视图效果）？
◇ 字体是否太大？
◇ 所有文本是否排列适当？
◇ 所有图标是否排列适当？
◇ 图片是否能被完整打印？
◇ 网站内是否有站内地图？
◇ 站内地图的每个超链接是否有对应的目标链接页？
◇ 站内地图是否包含了网站内所有的超链接？
◇ 每个页面的超链接是否正常工作？
◇ 内容是合法正确的（非单元测试期间开发者设置的填充内容）
◇ 页面背景（颜色）是否会分散注意力？
◇ 返回按钮是否正常工作？不会打开一个新的浏览器窗口，或重定向其他站点。
◇ 返回上页或转至新页面时，是否会导致本页面内容丢失？
◇ 从主页开始是否可以通过 3 次或更少的点击数到达目标页面？
◇ 图表或表格中的内容是否完整？是否正确列出？是否能确定所选文本处于图表或表格的正确区域内？
◇ 页面上的链接是否和先前一致？有没有新出来的或消失的链接？
有没有链接失败的情况？
◇ 点击链接是否能到达正确的目标页面？
◇ 目标页面是否存在？
◇ 站主的联系信息是否能从网站中获得（姓名、电话、电子邮件地址、邮寄地址、传真号）？
◇ 如果用户需要为某个页面作标签，该页面的名称是否易懂？
◇ 如果用户有获取历史页面纪录的权限，那网站地址是否会出现在 History 列表中？
◇ 网站页面的状态栏是否真实反映出页面登陆的进度、信息等？
表格
◇ 表格是否过长，经常需要通过拖动滚动条才能看到表格右边的栏目？
◇ 表格是否能正确打印？
◇ 表格内的列宽和行高是否合适？
◇ 会不会因为某个输入而使行高变化异常？
框架
◇ 是否会出现浏览器不支持的框架？
◇ 框架是否能自动准确地调整大小？用户是否可以操控框架的尺寸？
◇ 滚动条是否会适时出现？
◇ 框架页面上是否有明确的数据供书签或收藏夹识别？
◇ 搜索引擎是否可以找到框架中的内容？
◇ 框架边框是否美观？
◇ 框架内更新是否会出现问题？
数据认证
◇ 网站内面向用户的数据描述是否清楚？
◇ 隐私制度是否制定清楚？用户能否看到该制度？
◇ 保存的数据是否准确？
◇ 工作站是否对数据进行认证？
◇ 服务器是否对数据进行认证？
◇ 是否可以确保用户在工作站录入的信息可以被服务器正确接收？
◇ 在不同的时间段是否可以避免录入相同的信息（订单表等）？
◇ 是否为每个用户分配有唯一标识符，用于录入表格数据，保证表格对象的唯一性？
◇ 要求用户录入的信息是否是进程所必需的？例如：要求用户录入生日信息是用于其订单编号？或是仅仅为了多获得一些用户信息？
◇ 数字录入区域是否可以录入文字？
◇ 搜索中能否使用通配符？
◇ 是否可以在域内录入空格和空值？
◇ 是否可以录入长串？
◇ 域内是否可以录入文本最大的数量？
◇ 复选框和控件按钮的初值是否设置正确？
◇ 一个组内的控件按钮是每次只能选中一个？
◇ 复选框是否会触发预期事件？
◇在表格域内用户是否不能输入 HTML 代码？
◇智能错误处理是否会引发数据认证？ IE.如生日域的需求格式为 MM/DD/YYYY，则用户输入出声年份为 1857 是不匹配的。
外部界面
◇ 系统界面是否与相关的外部系统相匹配？
◇ 界面是否通过验证？
◇ 是否所有的支持的浏览器都经过测试？
◇ 一旦外部应用程序不可用或服务器连接失败，是否所有与外部界面相关的错误环境都经过测试？
◇ 代理缓存是否经过测试？
◇ 是否所有可能从网站内部安装的应用程序都经过测试？
内部界面
◇ 网站是否支持无下载功能的用户使用？
◇ 网站是否设置有防火墙？
◇ 网站是否可以灵活使用卸载插件？
◇ 网站处于不同模式或运行速度的情况下可能需要使用插件，网站是否支持？
◇ 是否所有的插件可以协同工作？
◇ 是否所有平台都支持，且能打开链接文件（如 Solaris 操作系统是否可以打开 Microsoft Word 文件）？
◇ 是否所有浏览器都支持这些插件？
◇ 一旦 Java 不可用，是否网站就不可用？
◇ 是否所有的插件都能正常启动？
◇ 如果下载时遇到错误，是否会有错误处理？
◇ 网站功能中是否有使用"非标准"硬件（如话筒线缆调制解调器等）的功能存在？
◇ 是否可以下载注册的 ActiveX 控件？
◇ 是否可以下载未注册的 ActiveX 控件？
◇ 是否可以初始化并编译未被认定为安全的 ActiveX 控件？
◇ 是否可以运行 ActiveX 控件和插件？
◇ 是否可以编译被认定为安全可编译的 ActiveX 控件？
◇ 反馈结果是否需要 cookie？
◇ 如果用户不支持 cookie，反馈结果是否正常？
◇ 反馈结果是否允许使用每个对话 cookie？
◇ 反馈结果是否需要文件下载？
◇ 如果用户不要下载文件，网站是否仍可以使用？
◇ 反馈结果是否需要使用特定字体？
◇ 反馈结