文档
测试流程 测试计划，测试用例，测试报告
测试有文档测试,单元测试,集成测试,系统测试,压力测试,性能测试,安装测试,界面测试,兼容性测试,回归测试.人员:测试人员,代码管理人员,文案人员.
. 页面连接检查：每个连接是否都有对应的页面，而且页面之间切换正确。能够使用一些工具，如LinkBotPro、File-AIDCS、HTML Link Validater、Xenu等工具。LinkBotPro不支持中文，中文字符显示为乱码；HTML Link Validater只能测试以Html或者htm结尾的网页连接；Xenu无需安装，支持asp、do、jsp等结尾的网页，xenu测试连接包括内部连接和外部连接，在使用的时候应该注意，同时可以生成html格式的测试报告。若是系统用QTP进行，也能够使用QTP的页面检查点检查、自动化检查
2. 相关性检查：
Ø 功能相关性：删除/增长一项会不会对其余项产生影响，若是产生影响，这些影响是否都正确，常见的状况是，增长某个数据记录之后，若是该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。
Ø 数据相关性：下来列表默认值检查，下来列表值检查，若是某个列表的数据项依赖于其余模块中的数据，一样须要检查，好比，某个数据若是被禁用了，可能在引用该数据项的列表中不可见。
3. 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出如今重置按钮上，表现为功能失效。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是不是正确的，有时候会出现，需求规定的字符串长度过短而没法输入业务数据。
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其余类型的内容(如在应该输入整型的地方输入其余字符类型),看系统是否检查字符类型。
6. 标点符号检查: 输入内容包括各类标点符号,特别是空格,各类引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格看成一个字符，而在查询的时候空格被屏蔽，致使没法查询到添加的内容。
7．特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出如今% ‘ \ 这几个特殊字符
8. 中文字符处理: 在能够输入中、英文的系统输入中文,看会否出现乱码或出错。
9. 检查信息的完整性: 在查看信息和更新信息时,查看所填写的信息是否是所有更新,更新信息和添加信息是否一致。要注意检查的时候每一个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的状况。
10. 信息重复: 在一些须要命名,且名字应该惟一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的先后输入空格,系统是否做出正确处理。
11. 检查删除功能:在一些能够一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;而后选择一个和多个信息,进行删除,看是否正确处理。若是有多页，翻页选，看系统是否都正确删除，而且要注意，删除的时候是否有提示，让用户可以更正错误，不误删除。
12. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
13. 检查修改重名:修改时把不能重名的项改成已存在的内容,看会否处理,报错.同时,也要注意,会不会报和本身重名的错.
14. 重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否作了处理。对于WEB系统来讲，能够经过浏览器返回键或者系统提供的返回功能。
15. 检查屡次使用返回键的状况: 在有返回键的地方,返回到原来页面,重复屡次，看会否出错。
16. 搜索检查: 有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.若是能够输入多个搜索条件,能够同时添加合理和不合理的条件,看系统处理是否正确，搜索的时候一样要注意特殊字符，某些系统会在输入特殊字符的时候，将系统中全部的信息都搜索到。
17. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
18. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否可以作到。下载文件可否打开或者保存，下载的文件是否有格式要求，如须要特殊工具才能够打开等。上传文件测试同时应该测试，若是将不能上传的文件后缀名修改成能够上传文件的后缀名，看是否可以上传成功，而且，上传文件后，从新修改，看上传的文件是否存在。
19. 必填项检查：应该填写的项没有填写时系统是否都作了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
20. 快捷键检查：是否支持经常使用快捷键，如Ctrl+C、 Ctrl+V、 Backspace等，对一些不容许输入信息的字段，如选人，选日期对快捷方式是否也作了限制。
21. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方颇有可能会出现错误。
22．刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。
23．回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于须要用户验证的系统，在退出登陆后，使用回退键，看系统处理如何；屡次使用回退键，屡次使用前进键，看系统如何处理。
24．直接URL连接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于须要用户验证的系统更为重要。若是系统安全性设计的很差，直接输入各功能页面的URL地址，颇有可能会正常打开页面。
25．空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。
26．输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。
27．密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来讲，此种方式彻底能够起到加密的做用，但同时，会形成一些问题，即大于128的Ascii对应的字符在解密时没法解析，尝试使用“uvwxyz”等一些码值较大的字符做为密码，同时，密码尽量的长，如17位密码等，形成加密后的密码出现没法解析的字符。
28．用户检查：任何一个系统，都有各种不一样的用户，一样具备一个或多个管理员用户，检查各个管理员之间是否能够相互管理，编辑、删除管理员用户。同时，对于通常用户，尝试删除，并重建同名的用户，检查该用户其余信息是否重现。一样，提供注销功能的系统，此用户再次注册时，是否做为一个新的用户。并且还要检查该用户的有效日期，过了有效日期的用户是不能登陆系统的。容易出现错误的状况是，可能有用户管理权限的非超级管理员，可以修改超级管理员的权限。
29．系统数据检查：这是功能测试最重要的，若是系统数据计算不正确，那么功能测试确定是通不过的。数据检查根据不一样的系统，方法不一样。对于业务管理平台，数据随业务过程、状态的变化保持正确，不能由于某个过程出现垃圾数据，也不能由于某个过程而丢失数据。
30．系统可恢复性检查：以各类方式把系统搞瘫，测试系统是否可正常迅速恢复。
31．确认提示检查：系统中的更新、删除操做，是否提示用户确认更新或删除，操做是否能够回退（便是否能够选择取消操做），提示信息是否准确。事前或过后提示，对于Update或Delete操做，要求进行事前提示。
32．数据注入检查：数据注入主要是对数据库的注入，经过输入一些特殊的字符，如“’”，“/”，“-”等或字符组合，完成对SQL语句的破坏，形成系统查询、插入、删除操做的SQL由于这些字符而改变原来的意图。如select * from table where id = ‘ ’ and name = ‘ ’，经过在id输入框中输入“12’-”，会形成查询语句把name条件注释掉，而只查询id=12的记录。一样，对于update和delete的操做，可能会形成误删除数据。固然还有其它一些SQL注入方法，具体能够参考《SQL应用高级SQL注入.doc》，不少程序都是基于页面对输入字符进行控制的，能够尝试跳过界面直接向数据库中插入数据，好比用Jmeter，来完成数据注入检查。
33．刷新检查：web系统中的WebForm控件实时刷新功能，在系统应用中有利有弊，给系统的性能带来较大的影响。测试过程当中检测刷新功能对系统或应用形成的影响（白屏），检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响（如每次刷新都链接数据库查询等）。
34．事务检查：对于事务性操做，断开网络或关闭程序来中断操做，事务是否回滚。
35．时间日期检查：时间、日期验证是每一个系统都必须的，如2006-2-2九、2006-6-31等错误日期，同时，对于管理、财务类系统，每一年的1月与前一年的12月（同理，每一年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如2006年2月28日、2006-2-2八、20060228等。日期检查还要检查日期范围是否符合实际的业务，对于不符合时间业务的日期，系统是否会有提示或者有限制
36．多浏览器验证：愈来愈多的各种浏览器的出现，用户访问Web程序再也不单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。
37．安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各类方案是否都能正常安装）、安装过程当中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。
38．文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。
39．测试数据检查：事实告诉咱们，测试数据比代码更有多是错的，所以，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。
40．请让个人机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在个人机器上是可以经过的。这就说明了其中存在着和环境相关的BUG。“是否全部的一切都受到了版本控制工具的管理？”、“本机的开发环境和服务器的环境是否同样？”、“这里是否存在一个真正的BUG，只不过是在其余的机器里偶然出现？”。全部的测试必须在全部系统要求的机器上运行经过，不然的话，代码就可能存在问题。
41．Ajax技术的应用：Ajax有不少优势，但也有不少缺点，若是利用优势、避免缺点，是咱们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验，用户体验的效果直接关系到是否使用Ajax技术。“会作，并不意味着应该作、必须作”，这就是对Ajax技术的很重要的注解。
42．Ajax技术的应用：Ajax采用异步调用的机制实现页面的部分刷新功能，异步调用存在异常中断的可能，尝试各类方法异常中断异步的数据调用，查看是否出现问题。在这里遇到的一个问题就是对日期控件的操做，已经若是页面数据较多的时候的刷新。
43．脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也愈来愈受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，所以在Web系统中，可能会出现脚本错误。同时，脚本错误形成的后果可大、可小
2. 相关性检查：
Ø 功能相关性：删除/增长一项会不会对其余项产生影响，若是产生影响，这些影响是否都正确，常见的状况是，增长某个数据记录之后，若是该数据记录某个字段内容较长，可能会在查询的时候让数据列表变形。
Ø 数据相关性：下来列表默认值检查，下来列表值检查，若是某个列表的数据项依赖于其余模块中的数据，一样须要检查，好比，某个数据若是被禁用了，可能在引用该数据项的列表中不可见。
3. 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。常见的错误会出如今重置按钮上，表现为功能失效。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度。还要检查需求规定的字符串长度是不是正确的，有时候会出现，需求规定的字符串长度过短而没法输入业务数据。
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其余类型的内容(如在应该输入整型的地方输入其余字符类型),看系统是否检查字符类型。
6. 标点符号检查: 输入内容包括各类标点符号,特别是空格,各类引号,回车键。看系统处理是否正确。常见的错误是系统对空格的处理，可能添加的时候，将空格看成一个字符，而在查询的时候空格被屏蔽，致使没法查询到添加的内容。
7．特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。常见的错误是出如今% ‘ \ 这几个特殊字符
8. 中文字符处理: 在能够输入中、英文的系统输入中文,看会否出现乱码或出错。
9. 检查信息的完整性: 在查看信息和更新信息时,查看所填写的信息是否是所有更新,更新信息和添加信息是否一致。要注意检查的时候每一个字段都应该检查，有时候，会出现部分字段更新了而个别字段没有更新的状况。
10. 信息重复: 在一些须要命名,且名字应该惟一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的先后输入空格,系统是否做出正确处理。
11. 检查删除功能:在一些能够一次删除多个信息的地方,不选择任何信息,按“delete”,看系统如何处理,会否出错;而后选择一个和多个信息,进行删除,看是否正确处理。若是有多页，翻页选，看系统是否都正确删除，而且要注意，删除的时候是否有提示，让用户可以更正错误，不误删除。
12. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
13. 检查修改重名:修改时把不能重名的项改成已存在的内容,看会否处理,报错.同时,也要注意,会不会报和本身重名的错.
14. 重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否作了处理。对于WEB系统来讲，能够经过浏览器返回键或者系统提供的返回功能。
15. 检查屡次使用返回键的状况: 在有返回键的地方,返回到原来页面,重复屡次，看会否出错。
16. 搜索检查: 有搜索功能的地方输入系统存在和不存在的内容,看搜索结果是否正确.若是能够输入多个搜索条件,能够同时添加合理和不合理的条件,看系统处理是否正确，搜索的时候一样要注意特殊字符，某些系统会在输入特殊字符的时候，将系统中全部的信息都搜索到。
17. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方。
18. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否可以作到。下载文件可否打开或者保存，下载的文件是否有格式要求，如须要特殊工具才能够打开等。上传文件测试同时应该测试，若是将不能上传的文件后缀名修改成能够上传文件的后缀名，看是否可以上传成功，而且，上传文件后，从新修改，看上传的文件是否存在。
19. 必填项检查：应该填写的项没有填写时系统是否都作了处理，对必填项是否有提示信息，如在必填项前加“*”；对必填项提示返回后，焦点是否会自动定位到必填项。
20. 快捷键检查：是否支持经常使用快捷键，如Ctrl+C、 Ctrl+V、 Backspace等，对一些不容许输入信息的字段，如选人，选日期对快捷方式是否也作了限制。
21. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。这个地方颇有可能会出现错误。
22．刷新键检查：在Web系统中，使用浏览器的刷新键，看系统处理如何，会否报错。
23．回退键检查：在Web系统中，使用浏览器的回退键，看系统处理如何，会否报错。对于须要用户验证的系统，在退出登陆后，使用回退键，看系统处理如何；屡次使用回退键，屡次使用前进键，看系统如何处理。
24．直接URL连接检查：在Web系统中，直接输入各功能页面的URL地址，看系统如何处理，对于须要用户验证的系统更为重要。若是系统安全性设计的很差，直接输入各功能页面的URL地址，颇有可能会正常打开页面。
25．空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。如对于要求输入整型、符点型变量的项中，输入空格，既不是空值，又不是标准输入。
26．输入法半角全角检查：在输入信息项中，输入半角或全角的信息，查看系统如何处理。如对于要求输入符点型数据的项中，输入全角的小数点（“。”或“．”，如４．５）；输入全角的空格等。
27．密码检查：一些系统的加密方法采用对字符Ascii码移位的方式，处理密码加密相对较为简单，且安全性较高，对于局域网系统来讲，此种方式彻底能够起到加密的做用，但同时，会形成一些问题，即大于128的Ascii对应的字符在解密时没法解析，尝试使用“uvwxyz”等一些码值较大的字符做为密码，同时，密码尽量的长，如17位密码等，形成加密后的密码出现没法解析的字符。
28．用户检查：任何一个系统，都有各种不一样的用户，一样具备一个或多个管理员用户，检查各个管理员之间是否能够相互管理，编辑、删除管理员用户。同时，对于通常用户，尝试删除，并重建同名的用户，检查该用户其余信息是否重现。一样，提供注销功能的系统，此用户再次注册时，是否做为一个新的用户。并且还要检查该用户的有效日期，过了有效日期的用户是不能登陆系统的。容易出现错误的状况是，可能有用户管理权限的非超级管理员，可以修改超级管理员的权限。
29．系统数据检查：这是功能测试最重要的，若是系统数据计算不正确，那么功能测试确定是通不过的。数据检查根据不一样的系统，方法不一样。对于业务管理平台，数据随业务过程、状态的变化保持正确，不能由于某个过程出现垃圾数据，也不能由于某个过程而丢失数据。
30．系统可恢复性检查：以各类方式把系统搞瘫，测试系统是否可正常迅速恢复。
31．确认提示检查：系统中的更新、删除操做，是否提示用户确认更新或删除，操做是否能够回退（便是否能够选择取消操做），提示信息是否准确。事前或过后提示，对于Update或Delete操做，要求进行事前提示。
32．数据注入检查：数据注入主要是对数据库的注入，经过输入一些特殊的字符，如“’”，“/”，“-”等或字符组合，完成对SQL语句的破坏，形成系统查询、插入、删除操做的SQL由于这些字符而改变原来的意图。如select * from table where id = ‘ ’ and name = ‘ ’，经过在id输入框中输入“12’-”，会形成查询语句把name条件注释掉，而只查询id=12的记录。一样，对于update和delete的操做，可能会形成误删除数据。固然还有其它一些SQL注入方法，具体能够参考《SQL应用高级SQL注入.doc》，不少程序都是基于页面对输入字符进行控制的，能够尝试跳过界面直接向数据库中插入数据，好比用Jmeter，来完成数据注入检查。
33．刷新检查：web系统中的WebForm控件实时刷新功能，在系统应用中有利有弊，给系统的性能带来较大的影响。测试过程当中检测刷新功能对系统或应用形成的影响（白屏），检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响（如每次刷新都链接数据库查询等）。
34．事务检查：对于事务性操做，断开网络或关闭程序来中断操做，事务是否回滚。
35．时间日期检查：时间、日期验证是每一个系统都必须的，如2006-2-2九、2006-6-31等错误日期，同时，对于管理、财务类系统，每一年的1月与前一年的12月（同理，每一年的第1季度与前一年的第4季度）。另外，对于日期、时间格式的验证，如2006年2月28日、2006-2-2八、20060228等。日期检查还要检查日期范围是否符合实际的业务，对于不符合时间业务的日期，系统是否会有提示或者有限制
36．多浏览器验证：愈来愈多的各种浏览器的出现，用户访问Web程序再也不单单依赖于Microsoft Internet Explorer，而是有了更多的选择：Maxthon、Firefox、Tencent Traveler等，考虑使用多种浏览器访问系统，验证效果。
37．安装测试：对于C/S架构的系统，安装程序的测试是一个重要方面，安装程序自动化程度、安装选项和设置（验证各类方案是否都能正常安装）、安装过程当中断测试、安装顺序测试（分布式系统）、修复安装及卸载测试。
38．文档测试：主要是对用户使用手册、产品手册进行测试，校验是否描述正确、完整，是否与当前系统版本对照，是否易理解，是否二义性等。
39．测试数据检查：事实告诉咱们，测试数据比代码更有多是错的，所以，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。
40．请让个人机器来运行：在某些项目中，出现一个病态的问题：系统没有问题呀，它在个人机器上是可以经过的。这就说明了其中存在着和环境相关的BUG。“是否全部的一切都受到了版本控制工具的管理？”、“本机的开发环境和服务器的环境是否同样？”、“这里是否存在一个真正的BUG，只不过是在其余的机器里偶然出现？”。全部的测试必须在全部系统要求的机器上运行经过，不然的话，代码就可能存在问题。
41．Ajax技术的应用：Ajax有不少优势，但也有不少缺点，若是利用优势、避免缺点，是咱们对新的Web2.0应用的一个挑战。而Ajax的应用最直接的问题就是用户体验，用户体验的效果直接关系到是否使用Ajax技术。“会作，并不意味着应该作、必须作”，这就是对Ajax技术的很重要的注解。
42．Ajax技术的应用：Ajax采用异步调用的机制实现页面的部分刷新功能，异步调用存在异常中断的可能，尝试各类方法异常中断异步的数据调用，查看是否出现问题。在这里遇到的一个问题就是对日期控件的操做，已经若是页面数据较多的时候的刷新。
43．脚本错误：随着Ajax、IFrame等异步调用技术的发展，Javascrīpt技术也愈来愈受到开发人员的重视，但Javascrīpt存在调试困难、各浏览器存在可能不兼容等问题，所以在Web系统中，可能会出现脚本错误。同时，脚本错误形成的后果可大、可小
安全性测试：
Web应用系统的安全性测试区域主要有：
（1）如今的Web应用系统基本采用先注册，后登录的方式。所以，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，能够试多少次的限制，是否能够不登录而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是相当重要的。须要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本经常构成安全漏洞，这些漏洞又经常被黑客利用。因此，还要测试没有通过受权，就不能在服务器端放置和编辑脚本的问题。
导航测试： 导航描述了用户在一个页面内操做的方式，在不一样的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不一样的链接页面之间。经过考虑下列问题，能够决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可经过主页存取？Web系统是否须要站点地图、搜索引擎或其余的导航帮助？
在一个页面上放太多的信息每每起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有知足本身须要的信息，若是没有，就会很快地离开。不多有用户愿意花时间去熟悉Web应用系统的结构，所以，Web应用系统导航帮助要尽量地准确。
导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
总体界面测试 ：
总体界面是指整个Web应用系统的页面结构设计，是给用户的一个总体感。例如：当用户浏览Web应用系统时是否感到温馨，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对总体界面的测试过程，实际上是一个对最终用户进行调查的过程。通常Web应用系统采起在主页上作一个调查问卷的形式，来获得最终用户的反馈信息。
对全部的可用性测试来讲，都须要有外部人员（与Web应用系统开发没有联系或联系不多的人员）的参与，最好是最终用户的参与。
4、客户端兼容性测试
一、平台测试
市场上有不少不一样的操做系统类型，最多见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪种操做系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操做系统下能正常运行，但在另外的操做系统下可能会运行失败。
所以，在Web系统发布以前，须要在各类操做系统下对Web系统进行兼容性测试
二、浏览器测试
浏览器是Web客户端最核心的构件，来自不一样厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不一样的HTML规格有不一样的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不一样的浏览器中也有不一样的显示，甚至根本不显示。不一样的浏览器对安全性和Java的设置也不同。
测试浏览器兼容性的一个方法是建立一个兼容性矩阵。在这个矩阵中，测试不一样厂商、不一样版本的浏览器对某些构件和设置的适应性。
图形测试 ：
在Web应用系统中，适当的图片和动画既能起到广告宣传的做用，又能起到美化页面的功能。一个Web应用系统的图形能够包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一块儿，以避免浪费传输时间。Web应用系统的图片尺寸要尽可能地小，而且要能清楚地说明某件事情，通常都连接到某个具体的页面。
（2）验证全部页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，通常采用JPG或GIF压缩。
三、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的仍是误传的。例如，在商品价格列表中，错误的价格可能引发财政问题甚至致使法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试一般使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口，也就是通常Web站点中的所谓"相关文章列表"。
在Web工程过程当中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工做。基于Web的系统测试与传统的软件测试不一样，它不但须要检查和验证 是否按照设计的要求运行，并且还要测试系统在不一样用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而， Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。所以，咱们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将 web 测试分为 6 个部分：
1. 功能测试
2. 性能测试（包括负载/压力测试）
3. 用户界面测试
4. 兼容性测试
5. 安全测试
6. 接口测试
本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深刻说明。
1 功能测试
1.1 连接测试
连接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。连接测试可 分为三个方面。首先，测试全部连接是否按指示的那样确实连接到了该连接的页面；其次，测试所连接的页面是否存在；最后，保证Web应用系统上没有孤立的页 面，所谓孤立页面是指没有连接指向该页面，只有知道正确的URL地址才能访问。
连接测试能够自动进行，如今已经有许多工具能够采用。连接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的全部页面开发完成以后进行连接测试。
采起措施：采用自动检测网站连接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）
1.2 表单测试
当用户经过表单提交信息的时候，都但愿表单能正常工做。
若是使用表单来进行在线注册，要确保提交按钮能正常工做，当注册完成后应返回注册成功的消息。若是使用表单收集配送 信息，应确保程序可以正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，须要验证服务器能正确保存这些数据，并且后台运行的程序能正确解 释和使用这些信息。
当用户使用表单进行用户注册、登录、信息提交等操做时，咱们必须测试提交操做的完整性，以校验提交给服务器的信息的 正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。若是使用了默认值，还要检验默认值的正确性。若是表单只能接受指 定的某些值，则也要进行测试。例如：只能接受某些字符，测试时能够跳过这些字符，看系统是否会报错。
1.3 数据校验
若是系根据业务规则须要对用户输入进行校验，须要保证这些校验功能正常工做。例如，省份的字段能够用一个有效列表进行校验。在这种状况下，须要验证列表完整并且程序正确调用了该列表(例如在列表中添加一个测试值，肯定系统可以接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采起措施：第一个完整的版本采用手动检查，同时造成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。
1.4 cookies测试
Cookies一般用来存储用户信息和用户在某应用系统的操做，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来建立动态和自定义页面或者存储登录等信息。
若是Web应用系统使用了Cookies，就必须检查Cookies是否能正常工做。测试的内容可包括Cookies是否起做用，是否按预约的时间进行 保存，刷新对Cookies有什么影响等。若是在 cookies 中保存了注册信息，请确认该 cookie可以正常工做并且已对这些信息已经加密。若是使用 cookie 来统计次数，须要验证次数累计正确。
采起措施：
1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
能够选择采用的软件
IECookiesView v1.50
Cookies Manager v1.1
1.5 数据库测试
在Web应用技术中，数据库起着重要的做用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最经常使用的数据库类型是关系型数据库，能够使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，通常状况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是因为用户提交的表单信息不正确而形成的，而输出错误主要是因为网络速度或程序设计问题等引发的，针对这两种状况，可分别进行测试。
采起措施：暂时没有更好的测试方法
考虑结合到1.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员须要对应用程序特定的功能需求进行验证。尝试用户可能进行的全部操做：下订单、更改订单、取消订单、核对订单状态、在货物发送以前更改送货信息、在线支付等等。这是用户之因此使用网站的缘由，必定要确认网站能像广告宣传的那样神奇。
采起措施：深入理解需求说明文档
1.7 设计语言测试
Web设计语言版本的差别能够引发客户端或服务器端严重的问题，例如使用哪一种版本的HTML等。当在分布式环境中开 发时，开发人员都不在一块儿，这个问题就显得尤其重要。除了HTML的版本问题外，不一样的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
2 性能测试
2.1 链接速度测试
用户链接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户能够等较长的时间，但若是仅仅访问一个页面就不会这样。若是Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，若是响应速度太慢，用户可能还没来得及浏览内容，就须要从新登录了。并且，链接速度太慢，还可能引发数据丢失，使用户得不到真实的页面。
2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工做。负载级别能够是某 个时刻同时访问Web系统的用户数量，也能够是在线数据处理的数量。例如：Web应用系统能容许多少个用户同时在线？若是超过了这个数量，会出现什么现 象？Web应用系统可否处理大量用户对同一个页面的请求？
2.3 压力测试
负载测试应该安排在Web系统发布之后，在实际的网络环境中进行测试。由于一个企业内部员工，特别是项目组人员老是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，因此，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么状况下会崩溃。黑客经常提供错误的数据负载，直到Web应用系统崩溃，接着当系统从新启动时得到存取权。
压力测试的区域包括表单、登录和其余信息传输页面等。
负载/压力测试应该关注什么
测试须要验证系统可否在同一时间响应大量的用户，在用户传送大量数据的时候可否响应，系统可否长时间运行。可访问性 对用户来讲是极其重要的。若是用户获得“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不只要使用户可以正常访问站点，在不少状况下，可能会有 黑客试图经过发送大量数据包来攻击服务器。出于安全的缘由，测试人员应该知道当系统过载时，须要采起哪些措施，而不是简单地提高系统性能。
瞬间访问高峰
若是您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内可以响应上百万的请求。负载测试工具可以模拟 X 个用户同时访问测试站点。
每一个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，可是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(固然每一个孩子都有本身的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
若是站点用于处理鲜花订单，那么至少但愿它在母亲节前的一周内能持续运行。若是站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能须要使用自动测试工具来完成这种类型的测试，由于很难经过手工完成这些测试。你能够想象组织100 我的同时点击某个站点。可是同时组织 100000 我的呢。一般，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。并且，测试工具安装完成以后，再次使用的时候，只要点击几下。
采起措施：采用测试工具WAS、ACT协助进行测试
3 用户界面测试
3.1 导航测试
导航描述了用户在一个页面内操做的方式，在不一样的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不一样的连 接页面之间。经过考虑下列问题，能够决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可经过主页存取？Web系统是否须要站 点地图、搜索引擎或其余的导航帮助？
在一个页面上放太多的信息每每起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应 用系统，看是否有知足本身须要的信息，若是没有，就会很快地离开。不多有用户愿意花时间去熟悉Web应用系统的结构，所以，Web应用系统导航帮助要尽可 能地准确。
导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2 图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的做用，又能起到美化页面的功能。一个Web应用系统的图形能够包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一块儿，以避免浪费传输时间。Web应用系统的图片尺寸要尽可能地小，而且要能清楚地说明某件事情，通常都连接到某个具体的页面。
（2）验证全部页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，通常采用JPG或GIF压缩，最好能使图片的大小减少到 30k 如下
（5）最后，须要验证的是文字回绕是否正确。若是说明文字指向右边的图片，应该确保该图片出如今右边。不要由于使用图片而使窗口和段落排列古怪或者出现孤行。
一般来讲，使用少量或尽可能不使用背景是个不错的选择。若是您想用背景，那么最好使用单色的，和导航条一块儿放在页面的左边。另外，图案和图片可能会转移用户的注意力。
3.3内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的仍是误传的。例如，在商品价格列表中，错误的价格可能引发财政问题甚至致使法律纠纷； 信息的准确性是指是否有语法或拼写错误。这种测试一般使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口，也就是通常Web站点中的所谓"相关文 章列表"。
对于开发人员来讲，可能先有功能而后才对这个功能进行描述。你们坐在一块儿讨论一些新的功能，而后开始开发，在开发的 时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。所以测试人员和公关部门一块儿检查内 容的文字表达是否恰当。不然，公司可能陷入麻烦之中，也可能引发法律方面的问题。测试人员应确保站点看起来更专业些。过度地使用粗体字、大字体和下划线可 能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不但愿看到一篇处处是黑体字的文章，因此相信您也但愿 本身的站点能更专业一些。最后，须要肯定是否列出了相关站点的连接。不少站点但愿用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。可是若是用户 没法点击这些地址，他们可能会以为很迷惑。
3.4 表格测试
须要验证表格是否设置正确。用户是否须要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有由于某一格的内容太多，而将整行的内容拉长?
3.5 总体界面测试
总体界面是指整个Web应用系统的页面结构设计，是给用户的一个总体感。例如：当用户浏览Web应用系统时是否感到温馨，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对总体界面的测试过程，实际上是一个对最终用户进行调查的过程。通常Web应用系统采起在主页上作一个调查问卷的形式，来获得最终用户的反馈信息。
对全部的用户界面测试来讲，都须要有外部人员（与Web应用系统开发没有联系或联系不多的人员）的参与，最好是最终用户的参与。
4 兼容性测试
4.1 平台测试
市场上有不少不一样的操做系统类型，最多见的有Windows、Unix、Macintosh、Linux等。Web 应用系统的最终用户究竟使用哪种操做系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操做系统下能正常运行，但在另外 的操做系统下可能会运行失败。
所以，在Web系统发布以前，须要在各类操做系统下对Web系统进行兼容性测试。
4.2 浏览器测试
浏览器是Web客户端最核心的构件，来自不一样厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不一样的HTML规格有不一样的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不一样的浏览器中也有 不一样的显示，甚至根本不显示。不一样的浏览器对安全性和Java的设置也不同。
测试浏览器兼容性的一个方法是建立一个兼容性矩阵。在这个矩阵中，测试不一样厂商、不一样版本的浏览器对某些构件和设置的适应性。
4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否过小以致于没法浏览? 或者是太大? 文本和图片是否对齐?
4.4 Modem/链接速率
是否有这种状况，用户使用 28.8 modem下载一个页面须要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，须要确认图片不会太大。
4.5 打印机
用户可能会将网页打印下来。所以网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有很多用户喜欢阅读而不是 盯着屏幕，所以须要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不同。测试人员至少须要验证订单确认页面打印是 正常的。
4.6 组合测试
最后须要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，可是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却没法使用 Lynx 来浏览。若是是内部使用的 web 站点，测试可能会轻松一些。若是公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。若是全部的人都使用 T1 专线，可能不须要测试下载施加。(但须要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。可是，理想的状况是，系统能在全部机器上运行，这样就不会 限制未来的发展和变更。
采起措施：根据实际状况，采起等价划分的方法，列出兼容性矩阵
5 安全测试
即便站点不接受信用卡支付，安全问题也是很是重要的。Web 站点收集的用户资料只能在公司内部使用。若是用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每一个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的全部内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"… com/objects/images"。而后在浏览器地址栏中手工输入该路径，发现该站点全部图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有不少资料，其中引发我注意的是已过时页面。该公司每月都要更改产品价格，而且保存过时页面。我翻看了一下这些记录，就能够 估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。若是某个客户在谈判以前查看了这些信息，他们在谈判桌上确定处于上风。
5.2 SSL
不少站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是由于浏览器出现了警告消息，并且在地址栏中的 HTTP 变成 HTTPS。若是开发部门使用了SSL，测试人员须要肯定是否有相应的替代页面(适用于3.0 如下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有链接时间限制？超过限制时间后出现什么情 况？
5.3 登陆
有些站点须要用户进行登陆，以验证他们的身份。这样对用户是方便的，他们不须要每次都输入我的资料。你须要验证系统 阻止非法的用户名/口令登陆，而可以经过有效登陆。用户登陆是否有次数限制? 是否限制从某些 IP 地址登陆? 若是容许登陆失败的次数为3，你在第三次登陆的时候输入正确的用户名和口令，能经过验证吗? 口令选择有规则限制吗? 是否能够不登录而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。
5.4 日志文件
在后台，要注意验证服务器日志工做正常。日志是否记全部的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不一样。有些脚本容许访问根目录。其余只容许访问邮件服务器，可是经验 丰富的黑客能够将服务器用户名和口令发送给他们本身。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要须要测试没有通过受权，就不能在服务器端放置 和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
6 接口测试
在不少状况下，web 站点不是孤立。Web 站点可能会与外部服务器通信，请求数据、验证数据或提交订单。
6.1服务器接口
第一个须要测试的接口是浏览器与服务器的接口。测试人员提交事务，而后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还能够查询数据库，确认事务数据已正确保存。
这种测试能够归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减小欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。若是商店只使用 Visa 卡和 Mastercard 卡， 能够尝试使用 Discover 卡的数据。(简单的客户端脚本可以在提交事务以前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 表明Discover。)一般，测试人员须要确认软件可以处理外部服务器返回的全部可能的消息。
这种状况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。一般咱们试图确认系统可以处理全部错误，但却没法预期系统全部可能的错 误。尝试在处理过程当中中断事务，看看会发生什么状况？订单是否完成？尝试中断用户到服务器的网络链接。尝试中断 web 服务器到信用卡验证服务器的链接。在这些状况下，系统可否正确处理这些错误？是否已对信用卡进行收费？若是用户本身中断事务处理，在订单已保存而用户没有 返回网站确认的时候，须要由客户表明致电用户进行订单确认。
采起措施：在理解需求的基础上，充分发挥想象力，尽可能比较全面的列出各类异常状况。
7 结论
不管你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来讲都是更具挑战性的工做。用户对 web 页面质量有很高的指望。在不少状况下，就像业务功能同样，页面用于维护和发展公共关系，因此第一印象很是重要。
Web应用系统的安全性测试区域主要有：
（1）如今的Web应用系统基本采用先注册，后登录的方式。所以，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，能够试多少次的限制，是否能够不登录而直接浏览某个页面等。
（2）Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。
（3）为了保证Web应用系统的安全性，日志文件是相当重要的。须要测试相关信息是否写进了日志文件、是否可追踪。
（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
（5）服务器端的脚本经常构成安全漏洞，这些漏洞又经常被黑客利用。因此，还要测试没有通过受权，就不能在服务器端放置和编辑脚本的问题。
导航测试： 导航描述了用户在一个页面内操做的方式，在不一样的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不一样的链接页面之间。经过考虑下列问题，能够决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可经过主页存取？Web系统是否须要站点地图、搜索引擎或其余的导航帮助？
在一个页面上放太多的信息每每起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有知足本身须要的信息，若是没有，就会很快地离开。不多有用户愿意花时间去熟悉Web应用系统的结构，所以，Web应用系统导航帮助要尽量地准确。
导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
总体界面测试 ：
总体界面是指整个Web应用系统的页面结构设计，是给用户的一个总体感。例如：当用户浏览Web应用系统时是否感到温馨，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对总体界面的测试过程，实际上是一个对最终用户进行调查的过程。通常Web应用系统采起在主页上作一个调查问卷的形式，来获得最终用户的反馈信息。
对全部的可用性测试来讲，都须要有外部人员（与Web应用系统开发没有联系或联系不多的人员）的参与，最好是最终用户的参与。
4、客户端兼容性测试
一、平台测试
市场上有不少不一样的操做系统类型，最多见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪种操做系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操做系统下能正常运行，但在另外的操做系统下可能会运行失败。
所以，在Web系统发布以前，须要在各类操做系统下对Web系统进行兼容性测试
二、浏览器测试
浏览器是Web客户端最核心的构件，来自不一样厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不一样的HTML规格有不一样的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不一样的浏览器中也有不一样的显示，甚至根本不显示。不一样的浏览器对安全性和Java的设置也不同。
测试浏览器兼容性的一个方法是建立一个兼容性矩阵。在这个矩阵中，测试不一样厂商、不一样版本的浏览器对某些构件和设置的适应性。
图形测试 ：
在Web应用系统中，适当的图片和动画既能起到广告宣传的做用，又能起到美化页面的功能。一个Web应用系统的图形能够包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一块儿，以避免浪费传输时间。Web应用系统的图片尺寸要尽可能地小，而且要能清楚地说明某件事情，通常都连接到某个具体的页面。
（2）验证全部页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，通常采用JPG或GIF压缩。
三、内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的仍是误传的。例如，在商品价格列表中，错误的价格可能引发财政问题甚至致使法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试一般使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口，也就是通常Web站点中的所谓"相关文章列表"。
在Web工程过程当中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工做。基于Web的系统测试与传统的软件测试不一样，它不但须要检查和验证 是否按照设计的要求运行，并且还要测试系统在不一样用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而， Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。所以，咱们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。
本文将 web 测试分为 6 个部分：
1. 功能测试
2. 性能测试（包括负载/压力测试）
3. 用户界面测试
4. 兼容性测试
5. 安全测试
6. 接口测试
本文的目的是覆盖 web 测试的各个方面，未就某一主题进行深刻说明。
1 功能测试
1.1 连接测试
连接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。连接测试可 分为三个方面。首先，测试全部连接是否按指示的那样确实连接到了该连接的页面；其次，测试所连接的页面是否存在；最后，保证Web应用系统上没有孤立的页 面，所谓孤立页面是指没有连接指向该页面，只有知道正确的URL地址才能访问。
连接测试能够自动进行，如今已经有许多工具能够采用。连接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的全部页面开发完成以后进行连接测试。
采起措施：采用自动检测网站连接的软件来进行。
推荐软件：
Xenu Link Sleuth 免费 绿色免安装软件
HTML Link Validator 共享（30天试用）
1.2 表单测试
当用户经过表单提交信息的时候，都但愿表单能正常工做。
若是使用表单来进行在线注册，要确保提交按钮能正常工做，当注册完成后应返回注册成功的消息。若是使用表单收集配送 信息，应确保程序可以正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，须要验证服务器能正确保存这些数据，并且后台运行的程序能正确解 释和使用这些信息。
当用户使用表单进行用户注册、登录、信息提交等操做时，咱们必须测试提交操做的完整性，以校验提交给服务器的信息的 正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。若是使用了默认值，还要检验默认值的正确性。若是表单只能接受指 定的某些值，则也要进行测试。例如：只能接受某些字符，测试时能够跳过这些字符，看系统是否会报错。
1.3 数据校验
若是系根据业务规则须要对用户输入进行校验，须要保证这些校验功能正常工做。例如，省份的字段能够用一个有效列表进行校验。在这种状况下，须要验证列表完整并且程序正确调用了该列表(例如在列表中添加一个测试值，肯定系统可以接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采起措施：第一个完整的版本采用手动检查，同时造成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。
1.4 cookies测试
Cookies一般用来存储用户信息和用户在某应用系统的操做，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来建立动态和自定义页面或者存储登录等信息。
若是Web应用系统使用了Cookies，就必须检查Cookies是否能正常工做。测试的内容可包括Cookies是否起做用，是否按预约的时间进行 保存，刷新对Cookies有什么影响等。若是在 cookies 中保存了注册信息，请确认该 cookie可以正常工做并且已对这些信息已经加密。若是使用 cookie 来统计次数，须要验证次数累计正确。
采起措施：
1 采用黑盒测试：采用上面提到的方法进行测试
2 采用查看cookies的软件进行（初步的想法）
能够选择采用的软件
IECookiesView v1.50
Cookies Manager v1.1
1.5 数据库测试
在Web应用技术中，数据库起着重要的做用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最经常使用的数据库类型是关系型数据库，能够使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，通常状况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是因为用户提交的表单信息不正确而形成的，而输出错误主要是因为网络速度或程序设计问题等引发的，针对这两种状况，可分别进行测试。
采起措施：暂时没有更好的测试方法
考虑结合到1.2和1.3的测试中
1.6 应用程序特定的功能需求
最重要的是，测试人员须要对应用程序特定的功能需求进行验证。尝试用户可能进行的全部操做：下订单、更改订单、取消订单、核对订单状态、在货物发送以前更改送货信息、在线支付等等。这是用户之因此使用网站的缘由，必定要确认网站能像广告宣传的那样神奇。
采起措施：深入理解需求说明文档
1.7 设计语言测试
Web设计语言版本的差别能够引发客户端或服务器端严重的问题，例如使用哪一种版本的HTML等。当在分布式环境中开 发时，开发人员都不在一块儿，这个问题就显得尤其重要。除了HTML的版本问题外，不一样的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。
2 性能测试
2.1 链接速度测试
用户链接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户能够等较长的时间，但若是仅仅访问一个页面就不会这样。若是Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，若是响应速度太慢，用户可能还没来得及浏览内容，就须要从新登录了。并且，链接速度太慢，还可能引发数据丢失，使用户得不到真实的页面。
2.2 负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工做。负载级别能够是某 个时刻同时访问Web系统的用户数量，也能够是在线数据处理的数量。例如：Web应用系统能容许多少个用户同时在线？若是超过了这个数量，会出现什么现 象？Web应用系统可否处理大量用户对同一个页面的请求？
2.3 压力测试
负载测试应该安排在Web系统发布之后，在实际的网络环境中进行测试。由于一个企业内部员工，特别是项目组人员老是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，因此，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么状况下会崩溃。黑客经常提供错误的数据负载，直到Web应用系统崩溃，接着当系统从新启动时得到存取权。
压力测试的区域包括表单、登录和其余信息传输页面等。
负载/压力测试应该关注什么
测试须要验证系统可否在同一时间响应大量的用户，在用户传送大量数据的时候可否响应，系统可否长时间运行。可访问性 对用户来讲是极其重要的。若是用户获得“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不只要使用户可以正常访问站点，在不少状况下，可能会有 黑客试图经过发送大量数据包来攻击服务器。出于安全的缘由，测试人员应该知道当系统过载时，须要采起哪些措施，而不是简单地提高系统性能。
瞬间访问高峰
若是您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内可以响应上百万的请求。负载测试工具可以模拟 X 个用户同时访问测试站点。
每一个用户传送大量数据
网上书店的多数用户可能只订购 1-5 书，可是大学书店可能会订购 5000 本有关心理学介绍的课本? 或者一个祖母为她的 50 个儿孙购买圣诞礼物(固然每一个孩子都有本身的邮件地址) 系统能处理单个用户的大量数据吗?
长时间的使用
若是站点用于处理鲜花订单，那么至少但愿它在母亲节前的一周内能持续运行。若是站点提供基于 web 的 email 服务，那么点最好能持续运行几个月，甚至几年。可能须要使用自动测试工具来完成这种类型的测试，由于很难经过手工完成这些测试。你能够想象组织100 我的同时点击某个站点。可是同时组织 100000 我的呢。一般，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。并且，测试工具安装完成以后，再次使用的时候，只要点击几下。
采起措施：采用测试工具WAS、ACT协助进行测试
3 用户界面测试
3.1 导航测试
导航描述了用户在一个页面内操做的方式，在不一样的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不一样的连 接页面之间。经过考虑下列问题，能够决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可经过主页存取？Web系统是否须要站 点地图、搜索引擎或其余的导航帮助？
在一个页面上放太多的信息每每起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应 用系统，看是否有知足本身须要的信息，若是没有，就会很快地离开。不多有用户愿意花时间去熟悉Web应用系统的结构，所以，Web应用系统导航帮助要尽可 能地准确。
导航的另外一个重要方面是Web应用系统的页面结构、导航、菜单、链接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
3.2 图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的做用，又能起到美化页面的功能。一个Web应用系统的图形能够包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一块儿，以避免浪费传输时间。Web应用系统的图片尺寸要尽可能地小，而且要能清楚地说明某件事情，通常都连接到某个具体的页面。
（2）验证全部页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，通常采用JPG或GIF压缩，最好能使图片的大小减少到 30k 如下
（5）最后，须要验证的是文字回绕是否正确。若是说明文字指向右边的图片，应该确保该图片出如今右边。不要由于使用图片而使窗口和段落排列古怪或者出现孤行。
一般来讲，使用少量或尽可能不使用背景是个不错的选择。若是您想用背景，那么最好使用单色的，和导航条一块儿放在页面的左边。另外，图案和图片可能会转移用户的注意力。
3.3内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的仍是误传的。例如，在商品价格列表中，错误的价格可能引发财政问题甚至致使法律纠纷； 信息的准确性是指是否有语法或拼写错误。这种测试一般使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面能够找到与当前浏览信息相关的信息列表或入口，也就是通常Web站点中的所谓"相关文 章列表"。
对于开发人员来讲，可能先有功能而后才对这个功能进行描述。你们坐在一块儿讨论一些新的功能，而后开始开发，在开发的 时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。所以测试人员和公关部门一块儿检查内 容的文字表达是否恰当。不然，公司可能陷入麻烦之中，也可能引发法律方面的问题。测试人员应确保站点看起来更专业些。过度地使用粗体字、大字体和下划线可 能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不但愿看到一篇处处是黑体字的文章，因此相信您也但愿 本身的站点能更专业一些。最后，须要肯定是否列出了相关站点的连接。不少站点但愿用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。可是若是用户 没法点击这些地址，他们可能会以为很迷惑。
3.4 表格测试
须要验证表格是否设置正确。用户是否须要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有由于某一格的内容太多，而将整行的内容拉长?
3.5 总体界面测试
总体界面是指整个Web应用系统的页面结构设计，是给用户的一个总体感。例如：当用户浏览Web应用系统时是否感到温馨，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对总体界面的测试过程，实际上是一个对最终用户进行调查的过程。通常Web应用系统采起在主页上作一个调查问卷的形式，来获得最终用户的反馈信息。
对全部的用户界面测试来讲，都须要有外部人员（与Web应用系统开发没有联系或联系不多的人员）的参与，最好是最终用户的参与。
4 兼容性测试
4.1 平台测试
市场上有不少不一样的操做系统类型，最多见的有Windows、Unix、Macintosh、Linux等。Web 应用系统的最终用户究竟使用哪种操做系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操做系统下能正常运行，但在另外 的操做系统下可能会运行失败。
所以，在Web系统发布以前，须要在各类操做系统下对Web系统进行兼容性测试。
4.2 浏览器测试
浏览器是Web客户端最核心的构件，来自不一样厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不一样的HTML规格有不一样的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不一样的浏览器中也有 不一样的显示，甚至根本不显示。不一样的浏览器对安全性和Java的设置也不同。
测试浏览器兼容性的一个方法是建立一个兼容性矩阵。在这个矩阵中，测试不一样厂商、不一样版本的浏览器对某些构件和设置的适应性。
4.3 分辨率测试
页面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否显示正常? 字体是否过小以致于没法浏览? 或者是太大? 文本和图片是否对齐?
4.4 Modem/链接速率
是否有这种状况，用户使用 28.8 modem下载一个页面须要 10 分钟，但测试人员在测试的时候使用的是 T1 专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，须要确认图片不会太大。
4.5 打印机
用户可能会将网页打印下来。所以网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有很多用户喜欢阅读而不是 盯着屏幕，所以须要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不同。测试人员至少须要验证订单确认页面打印是 正常的。
4.6 组合测试
最后须要进行组合测试。600x800 的分辨率在 MAC 机上可能不错，可是在 IBM 兼容机上却很难看。在 IBM 机器上使用 Netscape 能正常显示，但却没法使用 Lynx 来浏览。若是是内部使用的 web 站点，测试可能会轻松一些。若是公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。若是全部的人都使用 T1 专线，可能不须要测试下载施加。(但须要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。可是，理想的状况是，系统能在全部机器上运行，这样就不会 限制未来的发展和变更。
采起措施：根据实际状况，采起等价划分的方法，列出兼容性矩阵
5 安全测试
即便站点不接受信用卡支付，安全问题也是很是重要的。Web 站点收集的用户资料只能在公司内部使用。若是用户信息被黑客泄露，客户在进行交易时，就不会有安全感。
5.1 目录设置
Web 安全的第一步就是正确设置目录。每一个目录下应该有 index.html 或 main.html 页面，这样就不会显示该目录下的全部内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找到该图片所在的路径"… com/objects/images"。而后在浏览器地址栏中手工输入该路径，发现该站点全部图片的列表。这可能没什么关系。我进入下一级目录 "…com/objects" ，点击 jackpot。在该目录下有不少资料，其中引发我注意的是已过时页面。该公司每月都要更改产品价格，而且保存过时页面。我翻看了一下这些记录，就能够 估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。若是某个客户在谈判以前查看了这些信息，他们在谈判桌上确定处于上风。
5.2 SSL
不少站点使用 SSL 进行安全传送。你知道你进入一个 SSL 站点是由于浏览器出现了警告消息，并且在地址栏中的 HTTP 变成 HTTPS。若是开发部门使用了SSL，测试人员须要肯定是否有相应的替代页面(适用于3.0 如下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有链接时间限制？超过限制时间后出现什么情 况？
5.3 登陆
有些站点须要用户进行登陆，以验证他们的身份。这样对用户是方便的，他们不须要每次都输入我的资料。你须要验证系统 阻止非法的用户名/口令登陆，而可以经过有效登陆。用户登陆是否有次数限制? 是否限制从某些 IP 地址登陆? 若是容许登陆失败的次数为3，你在第三次登陆的时候输入正确的用户名和口令，能经过验证吗? 口令选择有规则限制吗? 是否能够不登录而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登录后在必定时间内（例如15分钟）没有点击任何页面，是否须要从新登录才能正常使用。
5.4 日志文件
在后台，要注意验证服务器日志工做正常。日志是否记全部的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP 地址吗? 记录用户名吗?
5.5 脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不一样。有些脚本容许访问根目录。其余只容许访问邮件服务器，可是经验 丰富的黑客能够将服务器用户名和口令发送给他们本身。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要须要测试没有通过受权，就不能在服务器端放置 和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。
6 接口测试
在不少状况下，web 站点不是孤立。Web 站点可能会与外部服务器通信，请求数据、验证数据或提交订单。
6.1服务器接口
第一个须要测试的接口是浏览器与服务器的接口。测试人员提交事务，而后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还能够查询数据库，确认事务数据已正确保存。
这种测试能够归到功能测试中的表单测试和数据校验测试中
6.2 外部接口
有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减小欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。若是商店只使用 Visa 卡和 Mastercard 卡， 能够尝试使用 Discover 卡的数据。(简单的客户端脚本可以在提交事务以前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 表明Discover。)一般，测试人员须要确认软件可以处理外部服务器返回的全部可能的消息。
这种状况在远程抄表中可能会体现到
6.3 错误处理
最容易被测试人员忽略的地方是接口错误处理。一般咱们试图确认系统可以处理全部错误，但却没法预期系统全部可能的错 误。尝试在处理过程当中中断事务，看看会发生什么状况？订单是否完成？尝试中断用户到服务器的网络链接。尝试中断 web 服务器到信用卡验证服务器的链接。在这些状况下，系统可否正确处理这些错误？是否已对信用卡进行收费？若是用户本身中断事务处理，在订单已保存而用户没有 返回网站确认的时候，须要由客户表明致电用户进行订单确认。
采起措施：在理解需求的基础上，充分发挥想象力，尽可能比较全面的列出各类异常状况。
7 结论
不管你在测试 internet、intranet 或者是 extranet 应用程序，web 测试相对于非 web 测试来讲都是更具挑战性的工做。用户对 web 页面质量有很高的指望。在不少状况下，就像业务功能同样，页面用于维护和发展公共关系，因此第一印象很是重要。
测试方法
测试方法
1． 划分等价类
把全部可能的数据输入划分为若干部分，而后从每一部分选择少数具备表明性的数据做为测试用例。
（1）有效等价类
合理，有意义的输入数据构成的集合，检验程序是否实现规格说明预先规定的功能和性能。
（2）无效等价类
不合理，无心义的输入数据构成的集合，检验程序的容错能力。
2． 边界值分析
大量的错误发生在输入或输出的边界上，而不是某个范围的内部。
3． 语句覆盖
设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次，语句覆盖是最弱的逻辑覆盖在准则。
4． 断定覆盖
设计若干测试用例，运行被测程序，使得程序中每一个判断的取真分支和取假分支至少经历一次，即判断的真假值都能知足。
5． 条件覆盖
设计若干测试用例，运行被测程序，要使判断中的每一个条件的可能取值至少知足一次。
6． 路径覆盖
覆盖全部可能的路径。
7． 断定-条件覆盖
使得每一个条件的全部可能至少出现一次，而且至少每一个判断自己的判断结果出现一次。
8． 功能测试的经常使用方法
（1） 页面连接检查，每个连接是否有对应的界面
（2） 相关性检查，删除/增长一项会不会对其余项产生影响，若是产生影响，是否正确
（3） 检查按钮功能是否正确
（4） 字符串长度检查，输入超出需求所说明的字符串长度的内容，看系统是否检查，会不会出错。
（5） 字符类型检查
（6） 标点符号检查
（7） 中文字符处理 ，乱码或出错
（8） 检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是否是所有带出,带出信息和添加的是否一致。
（9） 信息重复，在一些须要命名，且名字惟一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的先后输入空格，看系统是否处理。
（10） 检查删除功能 ，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理
选择一个或多个时又如何处理
（11） 检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
（12） 检查修改重名，修改时把补能重名的项改成已存在的内容，看会否处理，报错，同时看会否报和本身重名的错。
（13） 重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理。
（14） 检查屡次处理back键的状况
（15） Search检查:在有search功能的地方输入系统存在和不存在的内容，看结果是否正确；
若是能够输入多个search条件，同时能够添加合理和不合理的条件，看系统是否处理正确。
（16） 输入信息的位置，输入信息时，光标的位置
（17） 上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息。
（18） 必填项检查，必填项是否有提示信息
（19） 快捷键检查，是否支持经常使用快捷键检查
（20） 回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。
9． 界面测试的经常使用方法
界面测试要遵循的规则：
一．易用性，按钮名称通俗易懂，望文知意。
（1）完成相同或相近功能的按钮，要用Frame框起来，经常使用按钮要有快捷键
（2）完成同一功能或任务的元素要集中放置，减小鼠标的移动距离
（3）按功能将界面划分区域块，并要有功能说明和标题
（4）界面要支持键盘自动浏览按钮功能，Tab，回车键等
（5）界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
（6）同一界面上的控件数最好不要超过10个，多于10个时能够考虑使用分页界面显示。
（7）分页界面要支持在页面间的快捷切换，经常使用组合快捷键Ctrl+Tab
（8）默认按钮要支持Enter及选操做，即按Enter后自动执行默认按钮对应操做。
（9）可写控件检测到非法输入后应给出说明并能自动得到焦点
（10）Tab键的顺序与控件排列顺序要一直，目前流行整体从上到下，同时行间从左到右的方式。
（11）复选框和选项框按选择概率的高底而前后排列。
（12）复选框和选项框要有默认选项，并支持Tab选择。
（13）选项数相同时多用选项框而不用下拉列表框。
（14）界面空间较小时使用下拉框而不用选项框。
（15）选项数叫少时使用选项框，相反使用下拉列表框。
（16）专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
二．规范性，一般界面设计都按Windows界面的规范来设计
（1）经常使用菜单要有命令快捷方式
（2）完成相同或相近功能的菜单用横线隔开放在同一位置。
（3）菜单前的图标能直观的表明要完成的操做。
（4）菜单深度通常要求最多控制在三层之内
（5）工具栏要求能够根据用户的要求本身选择定制。
（6）相同或相近功能的工具栏放在一块儿。
（7）工具栏中的每个按钮要有及时提示信息。
（8）一条工具栏的长度最长不能超出屏幕宽度。
（9）工具栏的图标能直观的表明要完成的操做。
（10）系统经常使用的工具栏设置默认放置位置
（11）工具栏太多时能够考虑使用工具箱。
（12）工具箱要具备可增减性，由用户本身根据需求定制。
（13）工具箱的默认总宽度不要超过屏幕宽度的1/5。
（14）状态条要能显示用户切实须要的信息，经常使用的有：目前的操做、系统状态、用户位置、用户信息、提示信息、错误信息等，若是某一操做须要的时间较长，还应该显示进度条和进程提示。
（15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
（16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
（17）菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感
（18）菜单和状态条中一般使用5号字体。工具条通常比菜单要宽，但不要宽的太多，不然看起来很不协调。
（19）右键快捷菜单采用与菜单相同的准则。
三．独特性
（1） 安装界面上应有单位介绍或产品介绍，并有本身的图标。
（2） 主界面，最好是大多数界面上要有公司图标。
（3） 登陆界面上要有本产品的标志，同时包含公司图标。
（4） 帮助菜单的“关于”中应有版权和产品信息
（5） 公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大致一致。
四．安全性
（1）最重要的是排除可能会使应用非正常停止的错误。
（2）应当注意尽量避免用户无心录入无效的数据
（3）采用相关控件限制用户输入值的种类。
（4）当用户做出选择的可能性只有两个时,能够采用单选框。
（5）当选择的可能再多一些时,能够采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
（6）当选项特别多时，能够采用列表框，下拉式列表框。
（7）在一个应用系统中,开发者应当避免用户做出未经受权或没有意义的操做
（8）对可能引发致命错误或系统出错的输入字符或动做要加限制或屏蔽。
（9）对可能发生严重后果的操做要有补救措施。经过补救措施用户能够回到原来的正确状态。
（10）对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
（11）对错误操做最好支持可逆性处理，如取消系列操做。
（12）在输入有效性字符以前应该阻止用户进行只有输入以后才可进行的操做。
（13）对可能形成等待时间较长的操做应该提供取消功能。
（14）特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。
（15）与系统采用的保留字符冲突的要加以限制。
（16）在读入用户所输入的信息时，根据须要选择是否去掉先后空格。
（17）有些读入数据库的字段不支持中间有空格，但用户切实须要输入中间空格，这时要在程序中加以处理。
1． 划分等价类
把全部可能的数据输入划分为若干部分，而后从每一部分选择少数具备表明性的数据做为测试用例。
（1）有效等价类
合理，有意义的输入数据构成的集合，检验程序是否实现规格说明预先规定的功能和性能。
（2）无效等价类
不合理，无心义的输入数据构成的集合，检验程序的容错能力。
2． 边界值分析
大量的错误发生在输入或输出的边界上，而不是某个范围的内部。
3． 语句覆盖
设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次，语句覆盖是最弱的逻辑覆盖在准则。
4． 断定覆盖
设计若干测试用例，运行被测程序，使得程序中每一个判断的取真分支和取假分支至少经历一次，即判断的真假值都能知足。
5． 条件覆盖
设计若干测试用例，运行被测程序，要使判断中的每一个条件的可能取值至少知足一次。
6． 路径覆盖
覆盖全部可能的路径。
7． 断定-条件覆盖
使得每一个条件的全部可能至少出现一次，而且至少每一个判断自己的判断结果出现一次。
8． 功能测试的经常使用方法
（1） 页面连接检查，每个连接是否有对应的界面
（2） 相关性检查，删除/增长一项会不会对其余项产生影响，若是产生影响，是否正确
（3） 检查按钮功能是否正确
（4） 字符串长度检查，输入超出需求所说明的字符串长度的内容，看系统是否检查，会不会出错。
（5） 字符类型检查
（6） 标点符号检查
（7） 中文字符处理 ，乱码或出错
（8） 检查带出信息的完整性，在查看信息和update信息时,查看所填写的信息是否是所有带出,带出信息和添加的是否一致。
（9） 信息重复，在一些须要命名，且名字惟一的信息输入重复的名字或ID，看系统有没有处理，重名包括是否区分大小写，以及在输入内容的先后输入空格，看系统是否处理。
（10） 检查删除功能 ，在一些可删除多个的地方，不选任何内容按删除按钮看系统如何处理
选择一个或多个时又如何处理
（11） 检查添加修改是否一致，检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
（12） 检查修改重名，修改时把补能重名的项改成已存在的内容，看会否处理，报错，同时看会否报和本身重名的错。
（13） 重复提交表单，一条已成功提交的记录，back后在提交，看系统是否进行处理。
（14） 检查屡次处理back键的状况
（15） Search检查:在有search功能的地方输入系统存在和不存在的内容，看结果是否正确；
若是能够输入多个search条件，同时能够添加合理和不合理的条件，看系统是否处理正确。
（16） 输入信息的位置，输入信息时，光标的位置
（17） 上传和下载文件的检查，上传下载的功能是否实现，上传文件是否能打开，上传文件的格式规定，系统是否有解释信息。
（18） 必填项检查，必填项是否有提示信息
（19） 快捷键检查，是否支持经常使用快捷键检查
（20） 回车键检查，在输入结束后直接按回车键，看系统处理如何，会否报错。
9． 界面测试的经常使用方法
界面测试要遵循的规则：
一．易用性，按钮名称通俗易懂，望文知意。
（1）完成相同或相近功能的按钮，要用Frame框起来，经常使用按钮要有快捷键
（2）完成同一功能或任务的元素要集中放置，减小鼠标的移动距离
（3）按功能将界面划分区域块，并要有功能说明和标题
（4）界面要支持键盘自动浏览按钮功能，Tab，回车键等
（5）界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
（6）同一界面上的控件数最好不要超过10个，多于10个时能够考虑使用分页界面显示。
（7）分页界面要支持在页面间的快捷切换，经常使用组合快捷键Ctrl+Tab
（8）默认按钮要支持Enter及选操做，即按Enter后自动执行默认按钮对应操做。
（9）可写控件检测到非法输入后应给出说明并能自动得到焦点
（10）Tab键的顺序与控件排列顺序要一直，目前流行整体从上到下，同时行间从左到右的方式。
（11）复选框和选项框按选择概率的高底而前后排列。
（12）复选框和选项框要有默认选项，并支持Tab选择。
（13）选项数相同时多用选项框而不用下拉列表框。
（14）界面空间较小时使用下拉框而不用选项框。
（15）选项数叫少时使用选项框，相反使用下拉列表框。
（16）专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
二．规范性，一般界面设计都按Windows界面的规范来设计
（1）经常使用菜单要有命令快捷方式
（2）完成相同或相近功能的菜单用横线隔开放在同一位置。
（3）菜单前的图标能直观的表明要完成的操做。
（4）菜单深度通常要求最多控制在三层之内
（5）工具栏要求能够根据用户的要求本身选择定制。
（6）相同或相近功能的工具栏放在一块儿。
（7）工具栏中的每个按钮要有及时提示信息。
（8）一条工具栏的长度最长不能超出屏幕宽度。
（9）工具栏的图标能直观的表明要完成的操做。
（10）系统经常使用的工具栏设置默认放置位置
（11）工具栏太多时能够考虑使用工具箱。
（12）工具箱要具备可增减性，由用户本身根据需求定制。
（13）工具箱的默认总宽度不要超过屏幕宽度的1/5。
（14）状态条要能显示用户切实须要的信息，经常使用的有：目前的操做、系统状态、用户位置、用户信息、提示信息、错误信息等，若是某一操做须要的时间较长，还应该显示进度条和进程提示。
（15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
（16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
（17）菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感
（18）菜单和状态条中一般使用5号字体。工具条通常比菜单要宽，但不要宽的太多，不然看起来很不协调。
（19）右键快捷菜单采用与菜单相同的准则。
三．独特性
（1） 安装界面上应有单位介绍或产品介绍，并有本身的图标。
（2） 主界面，最好是大多数界面上要有公司图标。
（3） 登陆界面上要有本产品的标志，同时包含公司图标。
（4） 帮助菜单的“关于”中应有版权和产品信息
（5） 公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大致一致。
四．安全性
（1）最重要的是排除可能会使应用非正常停止的错误。
（2）应当注意尽量避免用户无心录入无效的数据
（3）采用相关控件限制用户输入值的种类。
（4）当用户做出选择的可能性只有两个时,能够采用单选框。
（5）当选择的可能再多一些时,能够采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
（6）当选项特别多时，能够采用列表框，下拉式列表框。
（7）在一个应用系统中,开发者应当避免用户做出未经受权或没有意义的操做
（8）对可能引发致命错误或系统出错的输入字符或动做要加限制或屏蔽。
（9）对可能发生严重后果的操做要有补救措施。经过补救措施用户能够回到原来的正确状态。
（10）对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
（11）对错误操做最好支持可逆性处理，如取消系列操做。
（12）在输入有效性字符以前应该阻止用户进行只有输入以后才可进行的操做。
（13）对可能形成等待时间较长的操做应该提供取消功能。
（14）特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。
（15）与系统采用的保留字符冲突的要加以限制。
（16）在读入用户所输入的信息时，根据须要选择是否去掉先后空格。
（17）有些读入数据库的字段不支持中间有空格，但用户切实须要输入中间空格，这时要在程序中加以处理。