软件测试规范

第一部分    应用程序测试
第一章界面测试
    界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
1.1易用性测试
按钮名称应该易懂，用词准确，摒弃模棱两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
1) 常用的按钮要有键盘快捷方式。 
2) 界面应按功能划分出区域，要有功能说明或标题。
3) 界面及按钮的风格应尽量统一。
4) 界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5) 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。 
6) 有输入的界面进入时焦点应停留在第一个EDIT上。
7) 界面上的控件摆放的数目是否过多。一般最好不要超过10个，多于10个应建议使用分页界面显示。
8) 同一界面的功能数量是否过多。一般最好不要多于10个，过多导致使用不便。
9) 分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl + Tab
10) 默认按钮要支持Enter及选择操作，即按Enter后自动执行默认按钮对应操作。
11) 可写控件检测到非法输入后应给出说明并能自动获得焦点。
12) Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
13) 复选框和选项框中的内容应尽量按选择几率的高低而先后排列。
14) 复选框和选项框通常要有默认选项。
15) 选项数相同时多用选项框而不用下拉列表框。
16) 界面空间较小时使用下拉框而不用选项框。
17) 选项数较少时使用选项框，相反使用下拉列表框。
18) 专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
1.2 规范性
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具箱、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具箱。
1) 常用菜单要有命令快捷方式。
2) 完成相同或相近功能的菜单用横线隔开放在同一位置。
3) 菜单前的图标能直观的代表要完成的操作。
4) 菜单深度一般要求最多控制在三层以内。
5) 菜单的说明要跟弹出的窗体一致。
6) 大型软件一般工具栏要求可以根据用户的要求自己选择定制。
7) 相同或相近功能的工具按钮放在一起。
8) 工具栏中的每一个按钮要有及时提示信息。
9) 一条工具栏的长度最长不能超出屏幕宽度。
10) 工具栏太多时可以考虑使用工具箱。
11) 工具箱要具有可增减性，由用户自己根据需求定制。
12) 工具箱的默认总宽度不要超过屏幕宽度的1/5。
13) 状态条要能显示用户切实需要的信息，常用的有：
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
14) 状态条的高度以放置五号字为宜，滚动条的宽度比状态条的略窄。
15) 菜单和工具条要有清楚的界限；菜单要求凸出显示，这样在移走工具条时仍有立体感。
16) 右键快捷菜单采用与菜单相同的准则，且右键快捷菜单在对话框中不应出现。

17）菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。

18）系统常用的工具栏设置默认放置位置。

19）工具栏的图标能直观的代表要完成的操作。

1.3 帮助功能
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。

帮助设施细则：
1) 帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的组先时期的说明，让人困惑)。

2) 打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。

3) 操作时要提供及时调用系统帮助的功能。常用F1。

4) 在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。

5) 最好提供目前流行的联机帮助格式或HTML帮助格式。

6) 用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。

7) 如果没有提供书面的帮助文档的话，最好有打印帮助的功能。

8) 在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

9) 在帮助中应提供留言管理功能，让用户可以方便进行沟通。

 

1.4 合理性
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
1) 父窗体或主窗体的中心位置应该在对角线焦点附近。即采取屏幕居中。
2) 子窗体位置应该在主窗体的左上角或正中。
3) 多个子窗体弹出时应该依次向右下方偏移，以显示出窗体标题为宜。
4) 重要的命令按钮与使用较频繁的按钮要放在界面上较注目的位置。
5) 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
6) 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。并且将按钮的缺省焦点置在“取消”按钮上。
7) 非法的输入或操作应有足够的提示说明。
8) 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
9) 提示、警告、或错误说明应该清楚、明了、恰当。
10) 对于需要执行长时间的操作，必须使用状态条，让用户了解进展情况，避免使用户误解为死机。
11) 大多数下拉框（ComboBox），应该不允许用户输入，如果需要输入，应在设计文档中指出。
12) 当下拉框（ComboBox）允许用户不选择任何选项时，不应显示一个空的选项，应使用文字描述，如“请选择…”等。
13) 对于文本框（TextBox）一般需要根据其对应的数据库字段的类型以及长度来限制用户允许输入的字符和长度，测试时要注意输入框中的数值的最大数和最小数，以及默认值、空白值或空格时的情况。
14) 对于ListView以Report形式（ViewStyle属性=vsReport）显示数据，一般要求实现列排序，如果由于特殊原因不能实现列排序，应该禁止用户点击列。
15) 对于日期输入框是否接受正确的日期输入；是否拒绝错误的日期输入；日期输入框在日期输入后是否按既定的日期格式显示日期。
16) 对于单选组内是否有且只有一个单选钮可选；如果单选组内无单选钮可选，这种情况是否允许存在。
17) 复选框组内是否允许多个复选框（包括全部可选）可选；如果复选框组内无复选框可选，这种情况是否允许存在；文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理。
18) 密码输入框是否按掩码的方式显示。
19) 对于有增加、修改或删除等有变动操作的页面，要随操作及时刷新。
20) 对于数据录入界面，重点考虑如何提高用户的录入速度。例如界面中有“身份证号”和“出生日期”，当用户输入了一个合法的身份证号后，系统应该自动根据身份证号将出生日期提取出来并填入“出生日期”控件中。
21) 系统的提示框样式应统一，即使用标准的Windows提示框，其中包括标题、图标、提示语和功能按钮。图标使用要规范，要根据提示信息的性质选择不同的图标，而且除非严重的错误，一般不使用“X”图标，以免使用户产生畏惧心理。    
22) 如果系统中需要经常录入一些重复数据，应考虑将其提取出来，让用户进行一次配置，然后系统自动根据配置完成该信息的录入。例如：系统有登记企业信息的功能，其中企业信息包括该企业所在的省、市、区，由于该系统安装到某个市级单位后，所登记企业的所在省、市都是确定的，让用户每次登记时都重复选择省、市将给用户带来很大的不便。应该由用户在系统初始化时设置好缺省的省、市，在企业登记时只要选择该企业所在的区即可，这样就提高了用户的登记效率。
23) 对于输入型控件禁止为其指定输入法。
24) 窗体显示后，缺省的焦点应该设在最合理的控件上，方便用户操作。
25) 输入型控件一般不允许只输入空格或可存入输入值两端的空格。

1.5 美观与协调性
界面大小应该适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
1) 长宽接近黄金点比例（宽高比为4:3），切忌长宽比例失调。
2) 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3) 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置，要与界面的大小和空间要协调。
4) 避免空旷的界面上放置很大的按钮。
5) 放置完控件后界面不应有很大的空缺位置。
6) 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。建议使用宋体9号字。
7) 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
8) 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
9) 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
10) 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
11) 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。对于窗体中包含ListView、TreeView、DBGrid、StringGrid等控件，必须支持最大化，使用户能够尽量多的获得信息。当处于“往下还原”状态时，默认窗体应居中。
12) 如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
13) 除主窗体外，其他窗体大部分都要支持敲“Esc”键退出的功能，除非设计文档中特殊指明。

14) 对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。

15) 通常父窗体支持缩放时，子窗体没有必要缩放。

1.6 菜单位置
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2): 常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3): 下拉菜单要根据菜单选项的含义进行分组，并且按照一定的规则进行排列，用横线隔开。
4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，次要的放在后边。
6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7): 菜单深度一般要求最多控制在三层以内。
8): 对常用的菜单要有快捷命令方式，组合原则见8。
9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
10): 菜单前的图标不宜太大，与字高保持一直最好。
11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12): 主菜单数目不应太多，最好为单排布置。

13):菜单条是否显示在合适的语境中？

14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

15):下拉式操作能正确工作吗？

16):菜单、调色板和工具条是否工作正确？

17):是否适当地列出了所有的菜单功能和下拉式子功能？

18):是否可能通过鼠标访问所有的菜单功能？

19):相同功能按钮的图标和文字是否一致？

20):是否能够用其它的文本命令激活每个菜单功能？

21):菜单功能是否随当前的窗口操作加亮或变灰？

22):菜单功能是否正确执行？

23):菜单功能的名字是否具有自解释性？

24):菜单项是否有帮助，是否语境相关？

25):在整个交互式语境中，是否可以识别鼠标操作？

26):如果要求多次点击鼠标，是否能够在语境正确识别？

27):如果鼠标有多个按钮，是否能够在语境中正确识别？

28):光标、处理指示器和识别指针是否随操作恰当地改变？   

1.7 独特性
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的潜移默化的广告效用。
1) 安装界面上应有单位介绍或产品介绍，并有自己的图标。
2) 主界面，最好是大多数界面上要有公司图标。
3) 登录界面上要有本产品的标志，同时包含公司图标。
4) 帮助菜单的“关于”中应有版权和产品信息。
5) 公司的系列产品要保持一致的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

1.8 快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些，在西文Windows及其应用软件中快捷键的使用大多是一致的。 
菜单中：
1) 面向事务的组合有: 
组合键 Ctrl-D Ctrl-F Ctrl –H Ctrl-ICtrl-N Ctrl-S Ctrl-O
功能删除寻找替换插入新记录保存打开
2) 编辑:
组合键 Ctrl-A Ctrl-C Ctrl-V Ctrl-XCtrl-Z Ctrl-Y
功能全选拷贝粘贴剪切撤消操作恢复操作
3) 文件操作:
组合键 Ctrl-P Ctrl-W
功能打印关闭
4) 系统菜单
组合键 Alt-F Alt-E Alt-T Alt－W Alt－H
功能文件编辑工具窗口帮助
5) MS Windows保留键:
组合键 Ctrl-Esc Ctrl-F4 Alt-F4 Alt-TabEnter Esc Shift-F1
功能任务列表关闭窗口结束应用下一应用缺省按钮/确认操作取消按钮/取消操作上下文相关帮助
6) 按钮中：(可以根据系统需要而调节，以下只是常用的组合。)
组合键 Alt-Y Alt-C Alt-N Alt-D Alt-QAlt-A Alt-E Alt-B Alt-R Alt-W
功能确定取消否删除退出添加编辑浏览读写
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。

 

1.9:安全性考虑：
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
安全性细则：
1)：最重要的是排除可能会使应用非正常中止的错误。
2)：应当注意尽可能避免用户无意录入无效的数据。
3)：采用相关控件限制用户输入值的种类。
4)：当用户作出选择的可能性只有两个时,可以采用单选框。 
5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6)：当选项特别多时，可以采用列表框，下拉式列表框。
7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11)：对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!
,.。?/还有空格。
15)：与系统采用的保留字符冲突的要加以限制。
16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
补充下几点应特别注意： 

统一的外观；

引用对象前的有效性检验；

使用正确的数据窗口列名；

使用适当的GUI 控件来使得用户输入有效；

需要时对数据窗口的列作保护；    //如设置TabOrder=0等

提交前对数据窗口列作约束检验；

避免用户进入危险地带；

对用户不经意的操作作出提示。

1.10:多窗口的应用与系统资源：
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其它窗口来显示该窗口。
2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
3)：关闭所有窗体，系统退出后要释放所占的所有系统资源，除非是需要后台运行的系统。
4)：尽量防止对系统的独占使用。

5)：窗口能否基于相关的输入或菜单命令适当地打开？

6)：窗口能否改变大小、移动和滚动？

7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？

8)：当被覆盖并重调用后，窗口能否正确地再生？

9)：需要时能否使用所有窗口相关的功能？

10)：所有窗口相关的功能是可操作的吗？

11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其它控制可为窗口可用，并适当地显示？

12)：显示多个窗口时，窗口的名称是否被适当地表示？

13)：活动窗口是否被适当地加亮？

14)：如果使用多任务，是否所有的窗口被实时更新？

15)：多次或不正确按鼠标是否会导致无法预料的副作用？

16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？

17)：窗口是否正确地关闭？

 

1.11其他

表单Check List

 

–         在数字框中是否能输入文本？

–         是否允许通配符？

–         是否可以为空？

–         输入长度限制是否合理?

>         例如：身份证框限制为15字符，不合理

–         复选框和单选按钮的默认值是否正确?

–         是否只有一个单选框能被选中?

–         复选框是否出发了预期的事件

 

页面 Check List

 

–         当页面出现较长列表时，是否有滚动条？

–         调整控件或框架的大小，是否对页面造成非预期的影响？

–         当用户选中了页面中的一个复选框，之后回退一个页面，再前进一个页面，复选框是否还处于选中状态？

–         如果浏览器调整大小，页面是否还能完全显示？

–         刷新后界面是否正常显示？

–         控件在特定情况下是否被设置成disable状态？

 

导航 Check List

 

–         导航是否直观

–         Web系统的主要部分是否可通过主页存取

–         Web系统是否有站点地图、搜索引擎或其它的导航帮助

 

对于屏幕显示来说包括：
检查显示的布局；
检查域和按钮的顺序；
检查域的尺寸；
检查字体的大小和风格；
检查文本的含义；
检查拼写错误；
检查屏蔽域；
检查只读域；
检查图片；
检查按钮的状态；
检查按钮的尺寸；
检查按钮的图标和名字；
检查是否有重复的图标；
检查指针是否在第一个可输入域；
检查TAB键的次序；

对于域来说包括：
检查可编辑性；
检查域间的移动；
检查分界条件；
检查有效分界符；
检查无效分界符；
检查连续多个有效分界符；
检查仅一个分界符输入；
检查多余空格的截取；
检查只读域和屏蔽域在TAB时的状态；

对于数字域来说包括：
检查正数值；
检查负数值；
检查零值；
检查小数点；
检查特殊字符加数字；
检查字母加数字；
检查ASCII值；
检查重复值；
检查空值；

对于字符域来说包括：
检查仅有字母；
检查仅有数字；
检查字母数字；
检查允许的特殊字符；
检查禁止的特殊字符；
检查包含特殊字符的字母数字；
检查ASCII值；

对于字母域来说包括：
检查字母；
检查数字值；
检查字母数字值；
检查特殊字符；
检查ASCII值；

对于时间域来说包括：
检查字符?和/；
检查其它特殊字符；
检查字母数字值；
检查正确的格式；
检查错误的格式；
检查错误的日期数字；
检查正确的日期数字；
检查日历表；

对于错误信息和警告信息来说：
检查错误信息和警告信息的含义；
检查错误信息和警告信息的一致性；
检查确定位置的错误信息；
检查错误信息后的光标位置；
检查所有异常对应的错误信息；
检查错误信息的格式；

对于普通的检查来说：
检查文本域和字符域输入是否左对齐；
检查数字域输入是否右对齐；
检查标签的切换；
检查重复的名字；
检查可删除的表格；
检查表格的多选；
检查过滤器的逻辑性；
检查多个过滤器的逻辑性；
检查重复的序列号；
检查显示切换；
检查快捷键；
检查工具栏提示；
检查日期域是否居中；
检查选择项的高显；
检查选择符；
检查显示窗口的风格统一性；

对于按键的功能包括：
New button：
检查包含next和cancel按键的子窗口的显示；
检查子窗口显示的内容；
Add button：
检查包含save和cancel按键的子窗口的显示；
Edit button：
检查在未选择项目情况下点击后的警告信息；
检查包update和cancel按键的子窗口的显示；
检查选择的项目是否显示在制定的位置；
Copy button：
检查在未选择项目情况下点击后的警告信息；
检查点击后的确认信息；
检查插入后的复制数据；
Delete button：
检查在未选择项目情况下点击后的警告信息；
检查点击后的确认信息；
检查删除后的数据；
Run button：
检测运行时的参数窗口；
检查执行结果；
检查未选择项目情况下点击后的警告信息；
Back button：
检查是否回到上一屏幕；
Next button：
检查是否显示下一屏幕；
Finish button：
检查数据是否进入数据库；
检查完成屏幕的显示；
Cancel button：
检查确认信息；
检查是否有其它键执行同样功能；
检测是否能能够正确处理；

第二章功能测试
在测试前，首先要根据《需求分析报告》全面了解用户需求并透彻理解。测试时要注意以下几点：
A、测试时要分清主次，即先测试主要功能，后测试次要功能。要选找出系统的功能主干，让数据依次流经功能主干，测试功能实现的是否正确。只要功能主干有问题，这个系统就是失败的。
B、功能主干用正常正确后，我们还要考虑测试其异常处理功能。
C、功能主干测试正确后，再进行分支功能的测试。
E、要对程序的功能进行方便性测试，将不够满意的地方，都应当成系统缺陷向项目负责人或系统开发者指出。
F、检查系统需求和设计说明书中要求的功能是否在系统中都被实现、性能是否达到指标。
G、数据之间的逻辑关系是否正确。
H、要有预览和打印功能。对于企业端软件，打印不能只针对一种打印机，要用多种打印机进行测试。

 

第三章环境测试
配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。在实际测试中，软件环境又可分为主测试环境和辅测试环境。主测试环境是测试软件功能、安全可靠性、性能、易用性等大多数指标的主要环境。一般来说，配置主测试环境可遵循下列原则：
1.符合软件运行的最低要求。测试环境首先要保证能支撑软件正常运行。
2.选用比较普及的操作系统和软件平台。一般都要在win98、win2000、2000server、windows xp下进行测试，除非软件的设计文档上有特殊要求。
3．要保证系统至少在时下流行的两种以上的浏览器上测试通过。如IE5、IE5.5、IE6、NS7等。
4.营造相对简单、独立的测试环境。除了操作系统，测试机上只安装软件运行和测试必需的软件，以避免不相关的软件影响测试实施。
5.无毒的环境。利用有效的正版杀毒软件检测软件环境，保证测试环境中没有病毒。并检测软件与时下流行的两种杀毒软件没有充突。
6．分辨率环境。要在不同的分辨率下进行测试，保证软件的每个页面的显示都正常。对于在Win2000下编制的程序，应在Win9X环境下检查界面上的字体和控件是否失真。
7．网络环境。要看网络连接是否正常；是否需要局域网和互联网等。
　　辅测试环境常常用来满足不同的测试需求或特殊测试项目：
　　兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其安装卸载和主要功能进行验证。
　　模拟真实环境测试：有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。
横向对比测试：利用辅测试环境“克隆”出完全一致的测试环境，从而保证各个被测软件平等对比。

第四章压力测试
压力测试用来检查程序对异常情况的抵抗能力。当关于容量的信息不确定的时候，需要确定是否分配了足够的磁盘空间，通讯的容量是否足够，测试系统过载的情况。压力测试总是迫使系统在异常的资源配置下运行。

例如，

①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；
②定量地增长数据输入率，检查输入子功能的反映能力；
③运行需要最大存储空间（或其他资源）的测试用例；
④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例；
⑤多用户、超过系统设定的用户同时使用系统；
⑥以比预期更快的速度与系统进行交互；
⑦让系统长时间运行等等。

第五章恢复测试
恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。

第六章性能测试
性能测试主要是对响应时间、事务处理速率、数据显示速度、计算速度、网络传输速度、数据库查询响应时间、扫描时间、扫描识别率等和其他与时间相关的需求进行评测和评估。性能评测的目标是核实性能需求是否都已满足。实施和执行性能评测的目的是将测试对象的性能行为当作条件（例如工作量或硬件配置）的一种函数来进行评测和微调。
对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。
另外，还需要注意程序对系统消耗资源的测试，如CPU负载、内存、显存、硬盘资源消耗情况。

第七章安全测试
　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。

例如，
①想方设法截取或破译口令；
②专门定做软件破坏系统的保护机制；
③故意导致系统失败，企图趁恢复之机非法进入；
④试图通过浏览非保密数据，推导所需信；
⑤权限控制是否合理、正确等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。

第八章安装测试
A、在一台与用户的运行环境基本一致，没有安装过开发工具（如BCB、DELPHI、VB或VC）和没有安装过特殊字体的计算机上，依据产品《使用手册》/《安装手册》中的安装说明部分进行安装，要求无论是自动安装和手工配置都能够依据向导正确实施安装，安装退出后，软件能正确启运、运行。
B、产品安装界面上的提示要正确，对安装起指导作用，版权说明文件与该程序相符。
C、安装时，对默安装路径、用户自己指定的路径都要求能进行正确安装。
D、用户自已指定路径时，如为已存在路径能够进行安装，如为不存在的路径，应能创建该路径并进行安装。
E、程序安装完成后，在开始－程序菜单中要生成中文的快捷方式或程序组，本公司的软件产品，要生成“伍陆柒捌＊＊软件”程序组，在其下生成中文的快捷方式。
F、卸载测试，如果系统提供自动卸载工具，那卸载后，检查是否把所有文件都全部删除，注册表中的有关注册信息是否也被删除。
G、安装完成在简单的使用后在执行卸载操作，看是否能执行成功。
H、先安装客户端，在安装服务端，看是否会出现问题。
I、考察安装该系统是否对其他的应用程序造成影响。

第九章文档测试
      将文档同程序相比较，看是否有不相符的情况。检查文档的截图是否跟程序一致，检查文档是否有错字或不符合语法规范的地方。
 

A、程序的帮助文档要说明准确、通俗易懂，不用专业术语，且操作步骤要符合程序的要求。
B、要图文并茂，易于理解。
C、从程序抓取的图片中，数据要有代表意义，而不是一些乱七八糟的字母、数字的组合。有意义的数据也能对用户的操作起着指导作用。
总之，对文档要进行完整性校验、正确性校验、一致性校验、易理解性校验、易浏览性校验、版本统一性校验。

第十章回归测试
当程序修改后，为了确保功能的正确性，需要重新测试应用程序中没有改变的部分。
在时间和条件允许的情况下，要测试修改相关的整个模块甚至整个程序。

第二部分    WEB程序的测试
一、按测试类型分类
字段编辑测试。字段编辑检查要查看格式编排、边界以及计算错误。如果日期需要限制在特定的时间范围内，该软件是否允许输入该时间范围外的日期？是否要求数字字段只包含数字？如果输入了字母会出现什么情况？如果包含计算，计算执行是否正确？字段输入框对请求的输入来说，是否足够大？如果有下拉框，其值否正确？ 
流控制和状态测试。在用户填写完表单中的字段并按下按钮后，逻辑是否会到达期望的进程？下一次显示同一页面时，其中的值是否正确？有时页面第一次显示了正确的值，而以后不再显示；或者情况相反。 
配置测试。在可行的情况下，会用尽可能多的“受支持服务器”和客户程序配置对应用程序进行测试。 
负载测试。在将页面或 Web 应用程序作为整体进行测试之前，应首先在组件级别进行负载和性能测试，以确保应用程序的每一部分能够在适当的指标下运行。这种隔离测试使测试小组能够更迅速地发现使用特定技术的问题。如果一个执行数据库查询功能的小脚本太慢，进行组件级别的测试比进行整个页面或应用程序测试更容易发现它。 
回归测试。开发部门修复了代码中的错误后，我们会重新进行测试，以检查错误是否被修复并确保所做的修复不会引起其它问题。

二、按窗体位置分类：

左侧导航窗格：
是否能够在左侧的导航窗格中来回移动，该窗格显示是否正确？
是否能够在大于屏幕的区域内滚动？
是否能够选择不同的新闻组，文章列表是否显示在右上窗格中？
是否能够调整左侧导航窗格以及右上和右下窗格的大小？

右上窗格：
右上窗格是否正确地显示文章，是否保持了每篇文章的连载状况？
是否可以遍历连载文章？
读过一篇文章后，它是否被标记为红色？
如果文章列表大于一个页面，是否能够遍历右上窗格中的各个页面？

右下窗格：
是否可以选择一篇文章并显示在该页面的右下窗格中？
是否能够发布新消息，回复组，回复个人或转发文章？
在回复个人或转发消息时，默认的邮件客户程序是否启动并显示新消息？ 
是否能够伴随文章发送附件？
是否可以查看附件？

工具栏：
验证工具栏适合其所在的页面并能够根据浏览器窗口调整大小。
验证本地菜单能够正常运行。
验证本地菜单中的链接。
验证全局菜单能够正常运行。
验证全局菜单中的链接。
验证工具栏上的所有图形。
验证工具栏框架大小不可调整。

界面测试
站点地图和导航条
确认你测试的站点是否有地图。有些网络高手可以直接去自己要去的地方，而不必点击一大堆页面。另外新用户在网站中可能会迷失方向。站点地图和/或导航条可以引导用户进行浏览。需要验证站点地图是否正确。确认地图上的链接是否确实存。地图有没有包括站点上的所有链接。是否每个页面都有导航条? 导航条是否一致? 每个页面的链接是否正常? 导航条是否直观?

内容
测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。

颜色/背景
由于 web 日益流行，很多人把它看作图形设计作品。不幸的是，有些开发人员对新的背景颜色更感兴趣，以至于忽略了这种背景颜色是否易于浏览。典型的站点是在紫色图片的背景上显示黄色的文本(如果你没有见过这样的站点，请浏览一下 GeoCities 或 AOL 上的个人主页，有不少这样的)。这种页面显得"非常高贵"，但是看起来很费劲。通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。

图片
无论作为屏幕的聚焦点或作为指引的小图标，一张图片都胜过千言万语。有时，告诉用户一个东西的最好办法就是将它展示给用户。但是，带宽对客户端或服务器来说都是非常宝贵的，所以要注意节约使用内存。是否所有的图片对所在的页面都是有价值的，或者它们只是浪费带宽? 使用其它的文件格式(.GIF, .JPG) 是否能使图片的大小减小到 30k 以下? 通常来说，不要将大图片放在首页上，因为这样可能会使用户放弃下载首页。如果用户可以很快看到首页，他可能会浏览站点，否则可能放弃。

表格
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长?

回绕
最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。

功能测试
链接
链接是使用户从一个页面浏览到另一个页面的重要手段。对于每个链接，需要验证两件事情：一是该链接将用户带到它所说明的地方，另外就是被链接页面是存在的。这句话听起来有些问题，但是有很多多站点的内部链接都是空的。这实在是无法忍受。

表单
当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。

Cookies
很多用户喜欢甜食，但是开发人员喜欢 web cookie (小甜饼)。如果系统使用了cookie，测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。  

应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。

接口测试
在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。

服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。

外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡，可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。  

错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。

兼容性测试
需要验证应用程序可以在用户使用的机器上运行。如果您用户是全球范围的，需要测试各种操作系统、浏览器、视频设置和 modem 速度。最后，还要尝试各种设置的组合。

操作系统
你的站点能否在 MAC 和IBM 兼容系统上浏览? 有些字体在某个系统上可能不存在，因此需要确认选择了备用字体。如果用户使用两种操作系统，请确认站点未使用只能在其中一种操作系统上运行的插件。

浏览器
站点能否使用 Netscape、Internet Explorer 或Lynx 进行浏览? 有些 HTML 命令或脚本只能在某些特定的浏览器上运行。请确认有图片的替代文字，因为可能会有用户使用文本浏览器。如果您使用 SSL 安全特性，则只需对 3.0 以上版本的浏览器进行验证，但是对于老版本的用户应该有相关的消息提示。

视频设置
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?

Modem/连接速率
是否有这种情况，用户使用 28.8 modem下载一个页面需要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。

打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。

组合测试
最后需要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，但是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却无法使用 Lynx 来浏览。如果是内部使用的 web 站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用 T1 专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。

负载/压力测试
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。

瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟 X 个用户同时访问测试站点。

每个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，但是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗?

长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100 个人同时点击某个站点。但是同时组织 100000 个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。

安全性测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web 站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。

目录设置
Web 安全的第一步就是正确设置目录。每个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"…com/objects/images"。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。

SSL
很多站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是因为浏览器出现了警告消息，而且在地址栏中的 HTTP 变成 HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0 以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？

登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些 IP 地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗?  

日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图?是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?

脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。

结论
无论你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来说都是更具挑战性的工作。用户对 web 页面质量有很高的期望。在很多情况下，就像业务功能一样，页面用于维护和发展公共关系，所以第一印象非常重要。

第三部分    数据库程序的测试
如果要向SQL数据库中保存时间，时间的年份必须大于等于1753年，如果小于1753年，修改数据库时会出错。
测试数据库程序时，除了要测试每个数据库操作是否正确外，要着重测试数据库共享问题，即多人同时执行同一功能，这样就会同时对同一数据表进行操作，测试程序是否正常。
测试数据库程序时，还要测试数据库操作的速度，如果数据库操作缓慢，应通知程序员进行优化。