软件测试点--经验总结

时间 2019-11-30

原文原文链接

Web测试中关于登陆的测试

请问，你为本身写过的用例怀疑过吗？javascript

　　前两天听一个朋友说他同事写了100个用例，结果有92个是无效的，差点被公司开了，本人之前也写过很多用例，但如今突然怀疑个人用例了，以为愈来愈糊涂了，拿登录框来讲吧，我写了7个用例，但总感受很差，在网上找了篇文章，分享下，但愿对你们有帮助。html

快捷键的使用是否正常：java

1. TAB 键的使用是否正确程序员

2.上下左右键是否正确web

3.界面若是支持 ESC键看是否正常的工做sql

3.ENTER 键的使用是否正确切换时是否正常。shell

布局美感数据库

界面的布局是否符合人的审美的标准编程

具体因人而异windows

输入框的功能：

输入合法的用户名和密码能够成功进入

输入合法的用户名和不合法密码不能够进入，并给出合理的提示

输入不合法的用户名和正确密码不能够进入，并给出合理的提示

输入不合法的用户名和不正确的密码不能够进入，并给出合理的提示

不合法的用户名有：不正确的用户名，，使用了字符大于用户名的限制

正经常使用户名不容许的特殊字符空的用户名，系统（操做系统和应用系统）的保留字符

不合法的密码有：空密码（除有特殊规定的），错误的密码，字符大于密码的限制

正常密码不容许的特殊字符，系统（操做系统和应用系统）的保留字符

界面的连接：

对于界面有连接的界面，要测试界面上的全部的连接都正常或者给出合理的提示

补充

输入框是否支持复制和黏贴和移动

密码框显示的不要是具体的字符，要是一些密码的字符

验证用户名前有空格是否能够进入，通常状况能够。

验证用户名是否区分大小写。（有的软件是区分大小写的）

验证必填项为空，是否容许进入。

验证登陆的次数是否有限制。从安全角度考虑，有些安全级别高的软件会考虑这方面的限制。

搜索功能测试用例设计

对被测试点进行分解，把测试用例分解为多个测试场景

场景编号	场景描述	预期结果
场景一	页面检查	正确
场景二	默认条件搜索	查询结果正确
场景三	修改可选条件搜索	查询结果正确
场景四	修改输入条件搜索	查询结果正确
场景五	修改区间条件搜索	查询结果正确
场景六	组合可选、输入条件搜索	查询结果正确
场景七	操做后检查搜索条件及查询结果	查询结果正确
场景八	错误、空记录搜索	查询结果为空

测试步骤描述

按照已经分解的测试场景顺序，逐个描述测试场景的测试步骤

测试场景一：

步骤编号	具体描述
1	进入搜索（高级搜索）页面
2	界面共性测试
3	退出

测试场景二：

步骤编号	具体描述
1	进入搜索（高级搜索）页面
2	点击“搜索”按钮，显示查询结果列表
3	检查查询结果列表，每页显示记录条数正确、文字折行显示正确、页面布局美观
4	检查查询结果列表，列标题项、列显示内容、排序方式符合需求定义
5	检查查询结果列表，符合默认查询条件结果集
6	点击查询结果列表连接、复选框、全选框响应正确
7	退出

测试场景三：

步骤编号	具体描述
1	进入搜索（高级搜索）页面
2	逐一选择各个查询条件可选项，如：“所有”、“类别1”等，点击“搜索”，查询结果正确
3	组合各个查询条件可选项，如：价格＋产品，点击“搜索”，查询结果正确
4	退出

测试场景四：

步骤编号	具体描述
1	进入搜索（高级搜索）页面
2	逐一输入文本域条件，模糊查询值，点击“搜索”，查询结果正确
3	逐一输入文本域条件，彻底匹配值，点击“搜索”，查询结果正确
4	逐一输入文本域条件，中文值，点击“搜索”，查询结果正确
5	逐一输入文本域条件，字母大、小写值，点击“搜索”，查询结果正确
6	逐一输入文本域条件，数字类型值，点击“搜索”，查询结果正确
7	逐一输入文本域条件，全角、半角值，点击“搜索”，查询结果正确
8	组合各个文本域查询条件，点击“搜索”，查询结果正确
9	退出

翻页功能测试用例

翻页功能咱们常碰到的通常有如下几个功能：

2、总页数，当前页数

3、指定跳转页

4、指定每页显示条数

固然，有一些是少于多少页，所有以数字的形式显示，多于多少页后，才出现下一页的控件。本文暂且用以上四点来作为通用的用例来设计吧。

对于1翻页连接或按钮的测试，主要要检查的测试点有：

1、有无数据时控件的显示状况

2、在首页时，首页和上一页是否能点击

3、在尾页时，下一页和尾页是否能点击

4、在非首页和非尾页时，四个按钮功能是否正确

5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序

对于2总页数，当前页数，主要要检查的测试点有：

1、总页数是否等于总的记录数/指定每页条数

2、当前页数是否正确

对于3指定跳转页，主要要检查的测试点有：

1、是否能正常跳转到指定的页数

2、输入的跳转页数非法时的处理

对于4指定每页显示条数，主要要检查的测试点有：

1、是否有默认的指定每页显示条数

2、指定每页的条数后，列表显示的记录数，页数是否正确

3、输入的每页条数非法时的处理

分析完上面的测试点，应该能够进行用例的设计了。

step 1: 列表无记录

expect: 1、四个翻页控件变灰不可点击

2、列表有相应的无数据信息提示

3、不可指定页数

4、不可指定跳转页

5、总页数显示为0

6、当前页数显示为0

step 2: 列表的记录数<=指定的每页显示条数

expect: 1、四个翻页控件变灰不可点击

2、总页数显示为1

3、当前页数显示为1

step 3: 列表的记录数>指定的每页显示条数

expect: 1、默认在首页，当前页数为1

2、列表的数据按照指定的排序列正确排序

3、记录数与数据库相符

4、总页数＝记录数/指定的每页显示条数

step 4: 列表的记录数>指定的每页显示条数，在首页

expect: 1、首页变灰不可点击

2、上一页变灰不可点击

3、下一页可点击，从（每页指定条数＋1）条记录开始显示，当前页数+1

4、尾页可点击，显示最后页的记录

step 5: 列表的记录数>指定的每页显示条数，在中间的某页

expect: 1、首页可点击，显示1到每页指定条数的记录

3、下一页可点击，从后一页的记录

4、尾页可点击，显示最后页的记录

5、列表的数据按照指定的排序列正确排序

6、当前页数为所在页

step 6:列表的记录数>指定的每页显示条数，在尾页

expect: 1、首页可点击，显示1到每页指定条数的记录

3、下一页变灰不可点击

4、尾页变灰不可点击

5、列表的数据按照指定的排序列正确排序

6、当前页数为最后一页的页数

step 7:输入每页显示条数为正整数

expect: 1、每页显示条数更新成指定的条数

2、超过指定的条数的记录分页显示

3、总页数更新成列表的记录数/每页显示条数

step 8:输入每页显示条数为0

expect: 1、提示“每页显示条数必须为大于1的整数”

2、提示后每页显示条数恢复为上次生效的条数

step 9:输入每页显示条数为负数

expect: 1、提示每页显示条数必须为大于1的整数

2、提示后每页显示条数恢复为上次生效的条数

step 10:输入每页显示条数长度超过数据库指定的长度<<<maxlen>>>

expect: 1、提示每页显示条数不能超过<<<maxlen>>>位

2、提示后每页显示条数恢复为上次生效的条数

step 11:输入每页显示条数为字符串，如中文翻页数

expect: 1、提示每页显示条数必须为大于1的整数

2、提示后每页显示条数恢复为上次生效的条数

step 12:输入每页显示条数为特殊字符，如％

expect: 1、提示每页显示条数必须为大于1的整数

2、提示后每页显示条数恢复为上次生效的条数

step 13:输入每页显示条数为html字符串，如<br>

expect: 1、提示每页显示条数必须为大于1的整数

2、提示后每页显示条数恢复为上次生效的条数

step 14:输入跳转的页数为存在的页数

expect: 1、正确跳转到指定的页数

step 15:输入跳转的页数不存在或非法值

expect: 1、跳转的页数值置为1，显示第一页的数据

以上的用例是将总页数，当前页数都揉进了翻页控件的测试用例中了

输入框的测试

最近在测试Web的输入框的时候，总是不知道从何处下手，去网上搜罗了一些资料，固然网上对输入框的测试资料少之又少，因此我做了一个简单的总结，总的状况有一下几个方面：

1.验证输入与输出的是否信息一致；

2.输入框以前的标题是否正确；

3.对特殊字符的处理，尤为是输入信息须要发送到数据库的。特殊字符包括：'（单引号）、"（双引号）、[]（中括号）、（）（小括号）、{}（大括号）、；（分号）、<>（大于小于号）……

4.对输入框输入超过限制的字符的处理，通常非特殊的没有做出限制的在255byte左右；

5.输入框自己的大小、长度；

6.不一样内码的字符的输入；

7.对空格、TAB字符的处理机制；

8.字符自己显示的颜色；

9.密码输入窗口转换成星号或其它符号；

10.密码输入框对其中的信息进行加密，防止采用破解星号的方法破解；

11.按下ctrl和alt键对输入框的影响；

12.对于新增、修改、注册时用的输入框，有限制的，应该输入时做出提示，指出不容许的或者标出容许的；

13.对于有约束条件要求的输入框应当在条件知足时输入框的状态发生相应的改变，好比选了湖南就应该列出湖南下面的市，或者选了某些条件以后，一些输入框会关闭或转为只读状态；

14.输入类型；根据前面的栏位标题判断该输入框应该输入哪些内容算是合理的。例如，是否容许输入数字或字母，不容许输入其余字符等。

15.输入长度；数据库字段有长度定义，当输入过长时，提交数据是否会出错。

16.输入状态；当处于某种状态下，输入框是否处于可写或非可写状态。例如，系统自动给予的编号等栏位做为惟一标识，当再次处于编辑状态下，输入框栏位应处于不可写状态，若是可写对其编辑的话，可能会形成数据重复引发冲突等。

暂时，就能想这么多，看你们谁还有观点，互相学习下！

17.若是是会进行数据库操做的输入框，还能够考虑输入SQL中的一些特殊符号如单引号等，有时会有意想不到的错误出现

18.输入类型输入长度是否容许复制粘贴为空的状况空格的考虑半角全角测试对于密码输入框要考虑显示的内容是* 输入错误时的提示信息及提示信息是否准确

19.能够先了解你要测试的输入框在软件系统的某个功能中所扮演的角色，而后了解其具体的输入条件，在将输入条件按照有效等价类，无效等价类，边界值等方法进行测试用例的设计。

20.关键字有大小写混合的状况；

21.关键字中含有一个或多个空格的状况，包括前空格，中间空格（多个关键字），和后空格；

22.关键字中是否支持通配符的状况（视功能而定）；

23.关键字的长度分别为9、10、11个字符时的状况；

24.关键字是valid，可是没有匹配搜索结果的状况；

25.输入html的标签会出现哪些问题？输入&lt；html&gt；会出现什么问题呢？（这条是我本身发现的，在网上也没找到相似的东东，呵呵，你们凑合着看吧）

安全测试方面：

给出一些特别的关键字，好比 or 1=1，这样的关键字若是不被处理就直接用到数据库查询中去，后果可想而知。

Web测试的经常使用的检查点

1，页面链接检查每个链接是否都有对应的页面，而且页面之间切换正确。

2，相关性检查删除/增长一项是否会对其余项产生影响，若是产生影响，这些影响是否都正确。

3，检查按扭的功能是否正确如update，cancel，delete，save等功能是否正确。

4，字符串长度检查输入超过需求说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错。

5，字符类型检查在应该输入指定类型的内容的地方输入其余类型的内容（如在应该输入整形的地方输入其余字符类型），看系统是否检查字符类型，是否报错。

6，标点符号检查输入内容包括各类标点符号，特别是空格，各类引号，回车健，看系统是否处理正确。

7，中文字符处理在能够输入中文的系统输入中文（简体或繁体），看是否会出现乱码或出错。

8，检查带出信息的完整性在查看信息和update信息时，查看所填写的信息是否所有带出，带出信息和添加的是否一致。

9，信息重复检查在一些须要命名，且名字应该惟一的信息输入重复的名字或id，看系统有没有处理，是否报错，重名包括是否区分大小写，以及在输入内容的先后输入空格，系统是否做出正确处理。

10，检查删除功能在一些能够一次删除多个信息的地方，不选择任何信息，按‘delete’，看系统如何处理，是否报错，而后选择一个或多个信息，进行删除，看是否作正确处理。

11，检查添加和修改的一致，检查添加和修改信息的要求是否一致，例如添加要求必添的项，修改也应该必填，添加规定的整形的项，修改也必须为整形。

12，检查修改重名，修改时把不能重名的项改成已存在的内容看是否会处理，同时，也要注意，会不会报和本身重名的错。

13，重复提交表单一条已经成功提交的记录，back后再提交，看系统会如何处理。

14，检查屡次使用back健的状况在有back的地方，back，回到原来的页面，再back，重复几回，看是否会报错。

15，search检查在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确，若是能够输入多个search条件，能够同时添加合理和不合理的条件，看系统处理是否正确。

16，输入信息位置注意在光标停留的地方输入信息时，光标和所输入信息是否会跳到别的地方。

17，上传和下载文件检查上传和下载文件的功能是否实现，上传是否能打开。对上传文件的格式有什么规定，系统是否有解释信息，并检查系统是否可以作到。

18，必填项检查应该填写的项没有填写的时候系统是否都作了处理，对必填项是否提示信息，如在必填项前面加*.

19，快捷键检查是否支持经常使用快捷，如Ctrl+C，Ctrl+V，BackSpace等，对一些不容许的输入信息的字段，如选人，选日期对快捷方式是否作了限制。

20，回车检查在输入结束后直接按回车键，看系统如何处理，是否会报错。

性能测试

2.1.链接速度测试用户链接到Web 应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户能够等较长的时间，但若是仅仅访问一个页面就不会这样。若是Web 系统响应时间太长（例如超过5 秒钟），用户就会因没有耐心等待而离开。

另外，有些页面有超时的限制，若是响应速度太慢，用户可能还没来得及浏览内容，就须要从新登录了。并且，链接速度太慢，还可能引发数据丢失，使用户得不到真实的页面。

2.2.负载测试负载测试是为了测量Web 系统在某一负载级别上的性能，以保证Web 系统在需求范围内能正常工做。负载级别能够是某个时刻同时访问Web 系统的用户数量，也能够是在线数据处理的数量。例如：Web 应用系统能容许多少个用户同时在线？若是超过了这个数量，会出现什么现象？Web 应用系统可否处理大量用户对同一个页面的请求？

用户及权限管理功能常规测试方法

1) 赋予一我的员相应的权限后，在界面上看此人员是否具备此权限，并以此人员身份登录，验证权限设置是否正确（可否超出所给予的权限）；

2) 删除或修改已经登录系统并正在进行操做的人员的权限，程序可否正确处理；

3) 从新注册系统变动登录身份后再登陆，看程序是否能正确执行，具备权限是否正确；

4) 在有工做组或角色管理的状况下，删除包含用户的工做组或角色，程序可否正确处理；

5) 不一样权限用户登陆同一个系统，权限范围是否正确；

6) 覆盖系统全部权限设定；

7) 可否添加信息为空的用户(其中包括空用户名及空口令、空用户名非空口令、非空用户名及空口令) ；

8) 可否添加长用户名及长口令，若是容许，新用户可否正确登陆；

9) 系统是否容许删除系统管理员这一特殊用户或修改系统管理员口令，删除或修改后系统的实际状况；

10) 登陆用户可否修改本身的权限；

11) 添加用户（有标识或编号）:标识相同，用户名不一样；标识相同，用户名相同；标识不一样，用户名相同；标识不一样，用户名不一样；

12) 登陆用户可否修改本人（或其余人）的信息，删除本人（或其余人）；

13) 修改用户的信息（包括权限，口令，基本信息等），对其余模块的影响；

14) 修改用户信息：修改后的用户信息和已经存在的用户信息相同；修改后的用户信息和已经存在的用户信息不一样；

15) 不给用户受权，是否容许登陆；

15) 改某些设置时，是否会影响具备上级权限及相同权限人员的设置；

16) 系统管理员修改了某些数据，以其余人员身份登陆时数据是否改变；

17) 用户可否同时属于多个组，各个组的权限可否交叉；删除后从新添加的用户是否具备之前的权限；更改用户各项属性（包括权限）看对权限是否有影响。

WEB测试之兼容性测试

1. 软件兼容性测试

兼容性测试是指待测试项目在特定的硬件平台上，不一样的应用软件之间，不一样的操做系统平台上，在不一样的网络等环境中能正常的运行的测试。

兼容性测试的目的：待测试项目在不一样的操做系统平台上正常运行，包括待测试项目能在同一操做系统平台的不一样版本上正常运行；待测试项目能与相关的其余软件或系统的“和平共处”；待测试项目能在指定的硬件环境中正常运行；待测试项目能在不一样的网络环境中正常运行。

兼容性测试没法作到彻底的质量保证，但对于一个项目来说，兼容性测试是必不可少的一个步骤。

2. Web兼容性测试的主要类型

Web兼容性测试主要是针对不一样的操做系统平台，浏览器，以及分辨率进行的测试。

2.1. 操做系统兼容性测试

常见的操做系统有Windows，Unix，Linux等，对于普通用户来说，最经常使用的是Windows操做系统。Windows操做系统包括Windows XP，windows 2003，vista，Win2000/NT，Windows9x等等。用户使用操做系统的类型，直接决定了咱们操做系统平台兼容性测试的操做系统平台数量，进行操做系统平台的兼容性测试的主要目的就是保证咱们的待测试项目在该操做系统平台下能正常运行。

对于一些特殊项目（好比定制项目），能够指定某一类型的操做系统版本，这些都应该在需求规格说明书中指明，针对这些指明的操做系统版本必须进行兼容性测试。

大部分的其余项目，是不指定操做系统版本的，针对这样的项目，咱们应当针对当前的主流操做系统版本进行兼容性测试，在确保主流操做系统版本兼容性测试的前提下在对非主流操做系统版本进行测试，尽可能保证项目的操做系统版本的兼容性测试的完整性。

2.2. 浏览器兼容性测试

浏览器是Web系统中对核心的组成构件，来自不一样厂家的浏览器对Javascrīpt、 ActiveX或不一样的HTML规格有不一样的支持，即便是同一厂家的浏览器，也存在不一样的版本的问题。不一样的浏览器对安全性和JAVA的设置也不同。

目前最为经常使用的浏览器为：IE 6.0 IE 7.0.但因为操做习惯的问题，还有至关一部分用户喜欢使用腾讯的TT，以及firefox浏览器，这些浏览器一样也存在各个版本的问题。这个对于Web系统来说是一个至关大的挑战。

对于一些特殊项目（好比定制项目），能够指定某一类型的浏览器（包括版本），这些都必须在需求规格说明书中指明。针对这些指明的浏览器必须进行兼容性测试。但大部分的项目，是不能指定浏览器的，针对这样的项目，那么咱们必须针对当前的主流浏览器（含版本），在确保主流浏览器的兼容性测试经过的前提下，再对非主流浏览器（含版本）进行测试，尽可能保证项目的浏览器的兼容性测试的完整性。

2.3. 分辨率兼容性测试

分辨率的测试是为了页面版式在不一样的分辨率模式下能正常显示，字体符合要求而进行的测试。

用户使用什么模式的分辨率，对于咱们来说是未知的。一般状况下，在咱们的需求规格说明书中会建议某些分辨率。对于测试来说，必须针对需求规格说明书中建议的分辨率进行专门的测试。如今常见的分辨率是1024×768，800×600。对于需求规格说明书中规定的分辨率，测试必须保证测试经过，但对于其余分辨率，原则上也应该尽可能保证，但因为这个在需求规格说明书中没有加以约束，因此在必定程度上，开发每每会拒绝进行调整。对于需求规格说明书中没有规定分辨率的项目，测试应该在完成主流分辨率的兼容性测试的前提下，尽量进行一些非主流分辨率的兼容性测试，在必定程度上保证大部分。

Web测试-sql注入

Web安全性测试—SQL注入

由于要对网站安全性进行测试，因此，学习了一些sql注入的知识。

在网上看一些sql注入的东东，因而想到了对网站的输入框进行一些测试，原本是想在输入框中输入<script>alter("abc")<script>,可是输入框有字符限制，只好输入<script>,结果网站出大问题了，呵呵，终于又出现了个bug。

另外一个就是在URL最后随意输入一些字符或数字，结果，新闻模块那出现了问题，暴露了网站的一些信息，又一个bug，高兴下……

下面把今天看到的有关SQL注入方面的知识整理以下：

SQL注入是一种攻击方式，在这种攻击方式中，恶意代码被插入到字符串中，而后将该字符串传递到SQL Server的实例以进行分析和执行。任何构成SQL语句的过程都应进行注入漏洞检查，由于SQL Server将执行其接收到的全部语法有效的查询。一个有经验的、坚决的攻击者甚至能够操做参数化数据。

SQL注入的主要形式包括直接将代码插入到与SQL命令串联在一块儿并使其得以执行的用户输入变量。一种间接的攻击会将恶意代码注入要在表中存储或做为元数据存储的字符串。在存储的字符串随后串连到一个动态SQL命令中时，将执行该恶意代码。

注入过程的工做方式是提早终止文本字符串，而后追加一个新的命令。因为插入的命令可能在执行前追加其余字符串，所以攻击者将用注释标记“--”来终止注入的字符串。执行时，此后的文本将被忽略。

如下脚本显示了一个简单的SQL注入。此脚本经过串联硬编码字符串和用户输入的字符串而生成一个SQL查询：

var Shipcity;

ShipCity = Request.form. ("ShipCity");

var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

用户将被提示输入一个市县名称。若是用户输入Redmond，则查询将由与下面内容类似的脚本组成：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

可是，假定用户输入如下内容：

Redmond'; drop table OrdersTable--

此时，脚本将组成如下查询：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分号(;)表示一个查询的结束和另外一个查询的开始。双连字符(--)指示当前行余下的部分是一个注释，应该忽略。若是修改后的代码语法正确，则服务器将执行该代码。SQL Server处理该语句时，SQL Server将首先选择OrdersTable中的全部记录（其中ShipCity为Redmond）。而后，SQL Server将删除OrdersTable。

只要注入的SQL代码语法正确，便没法采用编程方式来检测篡改。所以，必须验证全部用户输入，并仔细检查在您所用的服务器中执行构造SQL命令的代码。本主题中的如下各部分说明了编写代码的最佳作法。

验证全部输入:

始终经过测试类型、长度、格式和范围来验证用户输入。实现对恶意输入的预防时，请注意应用程序的体系结构和部署方案。请注意，设计为在安全环境中运行的程序可能会被复制到不安全的环境中。如下建议应被视为最佳作法：

若是一个用户在须要邮政编码的位置无心中或恶意地输入了一个10 MB的MPEG文件，应用程序会作出什么反应？

若是在文本字段中嵌入了一个DROP TABLE语句，应用程序会作出什么反应？

测试输入的大小和数据类型，强制执行适当的限制。这有助于防止有意形成的缓冲区溢出。

输入字符在Transact-SQL中的含义

; 查询分隔符。

' 字符数据字符串分隔符。

-- 注释分隔符。

/* ... */ 注释分隔符。服务器不对/*和*/之间的注释进行处理。

xp_ 用于目录扩展存储过程的名称的开头，如xp_cmdshell。

Web测试中书写用例时要考虑的检查点

一般书写Test Case时须要考虑的检查点.

对于屏幕显示来讲包括：

检查显示的布局；

检查域和按钮的顺序；

检查域的尺寸；

检查字体的大小和风格；

检查文本的含义；

检查拼写错误；

检查屏蔽域；

检查只读域；

检查图片；

检查按钮的状态；

检查按钮的尺寸；

检查按钮的图标和名字；

检查是否有重复的图标；

检查指针是否在第一个可输入域；

检查TAB键的次序；

对于域来讲包括：

检查可编辑性；

检查域间的移动；

检查分界条件；

检查有效分界符；

检查无效分界符；

检查连续多个有效分界符；

检查仅一个分界符输入；

检查多余空格的截取；

检查只读域和屏蔽域在TAB时的状态；

对于数字域来讲包括：

检查正数值；

检查负数值；

检查零值；

检查小数点；

检查特殊字符加数字；

检查字母加数字；

检查ASCII值；

检查重复值；

检查空值；

对于字符域来讲包括：

检查仅有字母；

检查仅有数字；

检查字母数字；

检查容许的特殊字符；

检查禁止的特殊字符；

检查包含特殊字符的字母数字；

检查ASCII值；

对于字母域来讲包括：

检查字母；

检查数字值；

检查字母数字值；

检查特殊字符；

检查ASCII值；

对于时间域来讲包括：

检查字符?和/；

检查其余特殊字符；

检查字母数字值；

检查正确的格式；

检查错误的格式；

检查错误的日期数字；

检查正确的日期数字；

检查日历表；

手机电子邮件测试用例

序号	测试项目		测试方法		测试标准
1	电子邮件设置	IP地址设置	默认的为010.000.000.172，本身设置必须设置为010.000.000.172		若是须要手动设置必须设置成010.000.000.172
		拨号设置(GSM)\		默认为17266，手动设置必须设置成17266	手动设置必须设置成17266
		节点设置(GPRS)		必须设置为cmwap	必须设置为cmwap
		用户名设置		若是设置，必须设置为WAP	若是设置必须设置为WAP
		用户密码设置		若是用户名作了设置，此项必须设置为wap	若是用户名作了设置，此项必须设置为wap
		上网数据模式设置(GPRS/GSM)		选择GPRS或GSM方式	若是有这两项可选择，必须可以使用。
		端口类型选择		能够选择安全和不安全。	通常选择不安全
2	用户设置	账户设置		将用户的邮箱地址、接收邮件服务器（POP3）、发送邮件服务器（SMTP）、邮箱账户名以及密码设置完成	可以成功设置
		下载设置		设置好各个限制项目：如单个信件下载最大字节、所有信件下载最大字节等等	可以成功设置
3	编写新邮件			选择输入法编写文本，并选择插入的附件（格式为txt/gif/jpg/bmp等）	全部的输入法都能实现，插入附件功能必须实现
4	发送邮件			编辑好邮件后，输入对方的电子邮件，按确认键进行发送	邮件可以成功发送并要有保存提示或自动进入已发信箱（若是此功能已经设定）
5	删除邮件			在邮件列表中，选择某条邮件，按选项菜单，选择删除项，再按确认键。	可以删除所选邮件
6	回复邮件			在邮件列表中选择某条邮件，在选项中选择回复，而后进行编辑，确认后发送。	可以实现邮件的回复操做。
7	转发邮件			在收件箱中选择某条邮件，在选项中选择转发，而后进行编辑，并输入第三方的邮箱地址或者从地址簿中选择号码，按确认键进行发送。	可以实现邮件的转发。

记事本与日历的测试用例

序号	测试项目		测试方法	断定标准
1	记事本测试	新建	在记事本中新建一个文本文档。	必须可以正常新建一个文档。
		编辑	对新建文档或者已有的文档进行编辑。	必须可以编辑文档，编辑时必须可以正确输入汉字、英文、数字、字母、标点符号等。


		保存	保存已经编辑的文档。	编辑完成后必须可以保存已编辑的内容。

		删除	删除已经保存的文档。	必须可以删除已经保存的文档，删除前必须有确认信息，删除成功与否必须有相应的提示。


2	日程表测试	新建	在记事本中新建一个日程安排。	必须可以正常新建一个日程。
		编辑	对新建文档或者已有的日程进行编辑。	必须可以编辑文档，编辑时必须可以正确输入汉字、英文、数字、字母、标点符号等。


		保存	保存已经编辑的日程。	编辑完成后必须可以保存已编辑的内容。

		删除	删除已经保存的日程。	必须可以删除已经保存的文档，删除前必须有确认信息，删除成功与否必须有相应的提示。


		日程提示设定	设定提示时间、提示模式。	必须可以设定日程提示的时间和提醒模式，设定完成后必须可以准时提醒。


		时间、日期设定	设定当前时间、日期。	必须可以设定当前的时间和日期，必须保证日程表里的万年历时间准确无误，至少保证日程表中每一年的每月（阳历与农历）的第一天与最后一天的正确性，另外对应的星期也必须准确。特别须要关注闰年。

Web测试总结
让web站点崩溃最多见的七大缘由

磁盘已满

致使系统没法正常运行的最可能的缘由是磁盘已满。一个好的网络管理员会密切关注磁盘的使用状况，隔必定的时间，就须要将磁盘上的一些负载转存到备份存储介质中（例如磁带）。

日志文件会很快用光全部的磁盘空间。Web服务器的日志文件、SQL*Net的日志文件、JDBC日志文件，以及应用程序服务器日志文件均与内存泄漏有同等的危害。能够采起措施将日志文件保存在与操做系统不一样的文件系统中。日志文件系统空间已满时Web服务器也会被挂起，但机器自身被挂起的概率已大大减低。

C指针错误

用C或C++编写的程序，如Web服务器API模块，有可能致使系统的崩溃，由于只要间接引用指针（即，访问指向的内存）中出现一个错误，就会致使操做系统终止全部程序。另外，使用了糟糕的C指针的Java模拟量（analog）将访问一个空的对象引用。Java中的空引用一般不会致使马上退出JVM，可是前提是程序员可以使用异常处理方法恰当地处理错误。在这方面，Java无需过多的关注，但使用 Java对可靠性进行额外的度量则会对性能产生一些负面影响。

内存泄漏

C/C++程序还可能产生另外一个指针问题：丢失对已分配内存的引用。当内存是在子程序中被分配时，一般会出现这种问题，其结果是程序从子程序中返回时不会释放内存。如此一来，对已分配的内存的引用就会丢失，只要操做系统还在运行中，则进程就会一直使用该内存。这样的结果是，曾占用更多的内存的程序会下降系统性能，直到机器彻底中止工做，才会彻底清空内存。

解决方案之一是使用代码分析工具（如Purify）对代码进行仔细分析，以找出可能出现的泄漏问题。但这种方法没法找到由其余缘由引发的库中的泄漏，由于库的源代码是不可用的。另外一种方法是每隔一段时间，就清除并重启进程。Apache的Web服务器就会因这个缘由建立和清除子进程。

虽然Java自己并没有指针，但总的说来，与C程序相比， Java程序使用内存的状况更加糟糕。在Java中，对象被频繁建立，而直到全部到对象的引用都消失时，垃圾回收程序才会释放内存。即便运行了垃圾回收程序，也只会将内存还给虚拟机VM，而不是还给操做系统。结果是：Java程序会用光给它们的全部堆，从不释放。因为要保存实时（Just In Time，JIT）编译器产生的代码，Java程序的大小有时可能会膨胀为最大堆的数倍之巨。

还有一个问题，状况与此相似。从链接池分配一个数据库链接，而没法将已分配的链接还回给链接池。一些链接池有活动计时器，在维持一段时间的静止状态以后，计时器会释放掉数据库链接，但这不足以缓解糟糕的代码快速泄漏数据库链接所形成的资源浪费。

进程缺少文件描述符

若是已为一台Web服务器或其余关键进程分配了文件描述符，但它却须要更多的文件描述符，则服务器或进程会被挂起或报错，直至获得了所需的文件描述符为止。文件描述符用来保持对开放文件和开放套接字的跟踪记录，开放文件和开放套接字是Web服务器很关键的组成部分，其任务是将文件复制到网络链接。默认时，大多数shell有64个文件描述符，这意味着每一个从shell启动的进程能够同时打开64个文件和网络链接。大多数shell都有一个内嵌的 ulimit命令能够增长文件描述符的数目。

线程死锁

由多线程带来的性能改善是以可靠性为代价的，主要是由于这样有可能产生线程死锁。线程死锁时，第一个线程等待第二个线程释放资源，而同时第二个线程又在等待第一个线程释放资源。咱们来想像这样一种情形：在人行道上两我的迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方没法经过，又同时向另外一侧迈出一步，这样仍是没法经过。双方都以一样的迈步方式堵住了对方的去路。假设这种状况一直持续下去，这样就不难理解为什么会发生死锁现象了。

解决死锁没有简单的方法，这是由于使线程产生这种问题是很具体的状况，并且每每有很高的负载。大多数软件测试产生不了足够多的负载，因此不可能暴露全部的线程错误。在每一种使用线程的语言中都存在线程死锁问题。因为使用Java进行线程编程比使用C容易，因此 Java程序员中使用线程的人数更多，线程死锁也就愈来愈广泛了。能够在Java代码中增长同步关键字的使用，这样能够减小死锁，但这样作也会影响性能。若是负载太重，数据库内部也有可能发生死锁。

若是程序使用了永久锁，好比锁文件，并且程序结束时没有解除锁状态，则其余进程可能没法使用这种类型的锁，既不能上锁，也不能解除锁。这会进一步致使系统不能正常工做。这时必须手动地解锁。

服务器超载

Netscape Web服务器的每一个链接都使用一个线程。Netscape Enterprise Web服务器会在线程用完后挂起，而不为已存在的链接提供任何服务。若是有一种负载分布机制能够检测到服务器没有响应，则该服务器上的负载就能够分布到其它的 Web服务器上，这可能会导致这些服务器一个接一个地用光全部的线程。这样一来，整个服务器组都会被挂起。操做系统级别可能还在不断地接收新的链接，而应用程序（Web服务器）却没法为这些链接提供服务。用户能够在浏览器状态行上看到connected（已链接）的提示消息，但这之后什么也不会发生。

解决问题的一种方法是将obj.conf参数RqThrottle的值设置为线程数目之下的某个数值，这样若是越过 RqThrottle的值，就不会接收新的链接。那些不能链接的服务器将会中止工做，而链接上的服务器的响应速度则会变慢，但至少已链接的服务器不会被挂起。这时，文件描述符至少应当被设置为与线程的数目相同的数值，不然，文件描述符将成为一个瓶颈。

数据库中的临时表不够用

许多数据库的临时表（cursor）数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的全部临时表。这时，其余的查询就须要列队等候，直到有临时表被释放时才能再继续运行。

这是一个不容易被程序员发觉的问题，但会在负载测试时显露出来。但可能对于数据库管理员（DataBase Administrator，DBA）来讲，这个问题十分明显。

此外，还存在一些其余问题：设置的表空间不够用、序号限制过低，这些都会致使表溢出错误。这些问题代表了一个好的DBA对用于生产的数据库设置和性能进行按期检查的重要性。并且，大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。

另外，还有许多因素也极有可能致使Web站点没法工做。如：相关性、子网流量超载、糟糕的设备驱动程序、硬件故障、包括错误文件的通配符、无心间锁住了关键的表。

Web应用程序是否存在跨站点脚本漏洞

到目前为止，对于跨站点脚本攻击具备很大的威胁这一点你们并没有异议。若是您很精通 XSS 而且只想看看有什么好的测试方法可供借鉴，那么请直接跳到本文的测试部分。若是您对此一无所知，请按顺序认真阅读！若是某个怀有恶意的人（攻击者）能够强迫某个不知情的用户（受害者）运行攻击者选择的客户端脚本，那么便会发生跨站点脚本攻击。“跨站点脚本”这个词应该属于用词不当的状况，由于它不只与脚本有关，并且它甚至不必定是跨站点的。因此，它就是一个在发现这种攻击时起的一个名字，而且一直沿用至今。从如今开始，咱们将使用它常见的缩写名称“XSS”。

XSS 攻击的过程涉及如下三方：

• 攻击者

• 受害者

• 存在漏洞的网站（攻击者能够使用它对受害者采起行动）

在这三方之中，只有受害者会实际运行攻击者的代码。网站仅仅是发起攻击的一个载体，通常不会受到影响。能够用多种方式发起 XSS 攻击。例如，攻击者可经过电子邮件、IM 或其余途径向受害者发送一个通过经心构造的恶意 URL。当受害者在 Web 浏览器中打开该 URL 的时侯，网站会显示一个页面并在受害者的计算机上执行脚本。

XSS 漏洞是什么样的呢？

做为一名 Web 开发人员或测试人员，您确定知道 Web 应用程序的技术基础是由 HTTP 和 HTML 组成的。HTTP 协议是 HTML 的传输机制，可以使用代码设计 Web 页面布局和生成页面。

若是 Web 应用程序接受用户经过 HTTP 请求（如 GET 或 POST）提交的输入信息，而后使用输出 HTML 代码在某些地方显示这些信息，即可能存在 XSS 漏洞。下面是一个最简单的例子：

1. Web 请求以下所示：

GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

2. 在发出请求后，服务器返回的 HTML 内容包括：

<h1>Section Title</h1>

能够看到，传递给“title”查询字符串参数的用户输入可能被保存在一个字符串变量中而且由 Web 应用程序插入到 <h1> 标记中。经过提供输入内容，攻击者能够控制 HTML。

3. 如今，若是站点没有在服务器端对用户输入加以过滤（由于老是能够绕过客户端控件），那么恶意用户即可以使用许多手段对此漏洞加以滥用：

攻击者能够经过摆脱 <h1> 标记来注入代码：

http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title</h1><script>alert(‘XSS%20attack’)</script>

这个请求的 HTML 输出将为：

<h1>Section Title</h1><script>alert(‘XSS attack’)</script>

即使是这个最简单的例子，攻击者也能够利用此链接完成数不清的事情。让咱们看看会有哪些潜在的威胁，而后讨论一些更高级的测试方法。

XSS 攻击的威胁有多么严重？

因为可以在生成的 Web 页面中注入代码，能想到的威胁有多么严重，就能够有多么严重的威胁。攻击者能够使用 XSS 漏洞窃取 Cookie，劫持账户，执行 ActiveX，执行 Flash 内容，强迫您下载软件，或者是对硬盘和数据采起操做。

只要您点击了某些 URL，这一切便有可能发生。天天之中，在阅读来自留言板或新闻组的受信任的电子邮件的时侯，您会多少次地单击其中的 URL？

网络钓鱼攻击一般利用 XSS 漏洞来装扮成合法站点。能够看到不少这样的状况，好比您的银行给你发来了一封电子邮件，向您告知对您的账户进行了一些修改并诱使您点击某些超连接。若是仔细观察这些 URL，它们实际上可能利用了银行网站中存在的漏洞，它们的形式相似于http://mybank.com/somepage?redirect=<script>alert(‘XSS’)</script>，这里利用了“redirect”参数来执行攻击。

若是您足够狡猾的话，能够将管理员定为攻击目标，您能够发送一封具备以下主题的邮件：“求救！这个网站地址老是出现错误！”在管理员打开该 URL 后，即可以执行许多恶意操做，例如窃取他（或她）的凭证。

好了，如今咱们已经理解了它的危害性 -- 危害用户，危害管理员，给公司带来坏的公共形象。如今，让咱们看看本文的重点 -- 测试您的网站是否存在这些问题。

测试 XSS 漏洞

多年以来，我一直是一名全职的安全顾问，已经作过无数次的这种测试了。我将好的测试计划归结为两个字：完全。对于你我来讲，查找这些漏洞与可以有机会在 Bugtraq 或 Vulnwatch 上吹嘘一番没有任何关系；它只与如何出色完成负责的工做有关。若是这意味着对应用程序中全部的单个查询字符串参数、cookie 值以及 POST 数据值进行检查，那么这只能代表咱们的工做还不算太艰巨。

显然，一次完整的安全性检查所涉及的内容一般远远超出寻找 XSS 漏洞那样简单；它须要创建总体的威胁模型，测试溢出漏洞、信息泄漏、错误处理、SQL 注入、身份验证和受权错误。好在执行这样完全的工做时，各个领域之间都存在重叠。好比，在测试 XSS 漏洞时，常常会同时找出错误处理或信息泄漏问题。

我假设您属于某个负责对 Web 应用程序进行开发和测试的小组。在这个幸运的位置上，您能够混合使用黑盒和白盒方法。每种方法都有它本身的优势，结合使用时甚至能相互提供支持。

1. 按顺序准备您的工具包

测试工做也能够是自动化的，可是咱们在这里只讨论手动操做。手动测试的必备工具包括：

• Paros proxy (http://www.parosproxy.org)，用于截获 HTTP 通讯数据

• Fiddler (http://www.fiddlertool.com/fiddler)，用于截获 HTTP 通讯数据

• Burp proxy (http://www.portswigger.net/proxy/)

• TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)，用于修改 GET 和 POST

咱们以上至少列出了三种 Web 代理软件。也能够寻找其余不一样的相似产品，由于每种产品都有它本身的独到之处。下面，您须要在 Web 浏览器发出 HTTP 请求以前截获这些请求，并修改它们以注入 XSS 测试代码。上面全部这些工具均可以完成这项任务，某些工具还会显示返回的 HTML 源代码（若是您选择了截获服务器响应）。

截获客户端发出的 GET 和 POST 请求很是重要。这样能够绕过全部的客户端 javascript. 输入验证代码。我在这里要提醒全部 Web 开发人员 -- 客户端安全控制是靠不住的。应该老是在服务器端执行有效性验证。

2. 肯定站点及其功能 -- 与开发人员和 PM 交流

绘制一些简单的数据流图表，对站点上的页面及其功能进行描述。此时，能够安排一些与开发人员和项目经理的会议来创建威胁模型。在会议上尽量对应用程序进行深刻探讨。站点公开了 Web 服务吗？是否有身份验证表单？有留言板吗？有用户设置页面吗？确保列出了全部这些页面。

3. 找出并列出全部由用户提供输入的点

对站点地图进行进一步细化。我一般会为此建立一个电子表格。对于每一个页面，列出全部查询字符串参数、cookie 值、自定义 HTTP 标头、POST 数据值和以其余形式传递的用户输入。不要忘记搜索 Web 服务和相似的 SOAP 请求，并找出全部容许用户输入的字段。

分别列出每一个输入参数，由于下面须要独立测试每一个参数。这多是最重要的一个步骤！若是阅读下面的电子表格，您会看到我已经在示例站点中找出了一大堆这样的东西。如 forwardURL 和 lang 这样的查询字符串。如 name、password、msgBody、msgTitle 和这样的 POST 数据，甚至某些 Cookie 值。全部这些都是咱们感兴趣的重要测试内容。

4. 认真思考并列出测试用例

使用已经获得的电子表格并列出各类用来测试 XSS 漏洞的方法。咱们稍候将讨论各类方法，可是如今先让咱们看看个人电子表格的屏幕截图，请注意，我列出了页面上容许的每一个值以及每一个值的全部测试类型。这种记录测试的方法仅是我本身的习惯，您能够使用本身的方法。我喜欢记录全部东西，以便我能知道已经作了哪些工做和哪些工做没有作。

5. 开始测试并注意输出结果

在查找漏洞的过程当中，最重要的部分并非您是否找到了漏洞。而是您是否真正知道究竟发生了哪些事情。对于 XSS，只需检查 HTML 输出并看看您输入的内容在什么地方。它在一个 HREF 标记中吗？是否在 IFRAME. 标记中？它在 CLSID 标记中吗？在 IMG SRC 中吗？某些 Flash 内容的 PARAM NAME 是怎样的？

我会检查全部这些状况，若是您对所输入内容的目的十分了解，能够调整您的测试来找出问题。这意味着您可能须要添加一个额外的封闭括号“>”来让某个标记变得完整，或者添加一个双引号来关闭标记内的一个元素。或者，您可能须要使用 URL 或 HTML 来编码您的字符，例如将双引号变为 %22 或 "。

嗯，并不那么容易，这个站点看来防范比较严密。如今该怎么办呢？

那么，也许您的简单测试用例 <script>alert(‘hi’)</script> 并不能产生指望中的警告对话框。仔细想一想这个问题并在可能的状况下与开发人员进行交流。也许他们对输入中的尖括号、单引号或圆括号进行了过滤。也许他们会过滤“script”这个词。从新研究为什么输入会产生这样的输出，并理解每一个值（查询字符串、cookie、POST 数据）的做用。“pageId=10”这样的查询字符串值可能对输出没有影响，所以不值得花费时间测试它。有时，最好试着注入单个字符（例如尖括号、双引号标记或者圆括号），看看应用程序是否过滤这些字符。而后，即可以知道您面对的过滤级别究竟如何。接着，能够调整测试方法，对这些字符进行编码并重试，或者寻找其余注入办法。

改变测试用例

我恐怕没法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面很是重要。若是它们不能产生输出，那么不要在它们上面浪费时间。若是能够，请进行研究，由于您须要根据输出对测试进行相应的修改。我使用了各类变化形式来找出能接受和显示脚本代码的参数。由于这涉及太多内容，所以在这里没法一一进行讨论，可是请务必注意如下几种状况：

1. >"'><script>alert(‘XSS')</script>

2. >%22%27><img%20src%3d%22javascript.:alert(%27XSS%27)%22>

3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>

4. AK%22%20style%3D%22background:url(javascript.:alert(%27XSS%27))%22%20OS%22

5. %22%2Balert(%27XSS%27)%2B%22

6. <table background="javascript.:alert(([code])"></table>

7. <object type=text/html data="javascript.:alert(([code]);"></object>

8. <body nload="javascript.:alert(([code])"></body>

有许多变化形式能够尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展现的，常见的变化形式常常是在脚本代码前面加上 “>””，以尝试封闭网站可能在输出中生成的标记。还能够对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，由于尖括号“<>”一般会在输入时被过滤和从输出中删除，因此还必须尝试不须要尖括号的 XSS，例如 ”&{alert('XSS')};”

持久和动态

找出一个成功的 XSS 颇费周折，由于在开始时 XSS 攻击可能并非那么显而易见的。随便举一个例子，若是向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会当即看到脚本代码被执行。可是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其做为脚本代码执行。这种状况被称做持久性 XSS 攻击，若是包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行，便会发生此种攻击。

而与此相对的是动态 XSS 攻击，这种攻击会当即执行并只发生一次。好比，若是某个连接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击连接后会当即显示输出。

总结

XSS 测试一般只是整个 Web 应用程序安全性审查工做的一小部分，可是在执行测试时必须细致和完全。在多年的工做中，我一直强调使用电子表格或其余方式来记录站点的全部页面，以及每一个页面接受的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。与此同等重要的是，理解输入以及它在输出的 HTML 页面上的呈现方式。若是您知道了应用程序处理输入的方式，就会很是迅速地完成许多工做。不要浪费时间测试那些不会做为输出显示的输入。与开发人员和 PM 进行交流，并在开始测试前创建完善的威胁模型。

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性能测试术语

在软件系统日益复杂的今天，性能已经成为软件质量的重要衡量标准之一，这一点尤为体如今和WEB相关的系统上。接下来介绍一些WEB性能测试中的术语，这些术语都是WEB性能测试中出现频繁的比较高的词汇，只有掌握这些基础的性能知识才能够进一步开展测试工做。这些术语主要有并发用户，并发用户数量，请求响应时间，事务响应时间，吞吐量，吞吐率，TPS，点击率，资源利用率等。

并发用户：并发通常分为2种状况。一种是严格意义上的并发，即全部的用户在同一时刻作同一件事情或者操做，这种操做通常指作同一类型的业务。好比在信用卡审批业务中，必定数目的拥护在同一时刻对已经完成的审批业务进行提交；还有一种特例，即全部用户进行彻底同样的操做，例如在信用卡审批业务中，全部的用户能够一块儿申请业务，或者修改同一条记录。

另一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操做，可是这些请求或者操做能够是相同的，也能够是不一样的。对整个系统而言，仍然是有不少用户同时对系统进行操做，所以也属于并发的范畴。

能够看出，后一种并发是包含前一种并发的。并且后一种并发更接近用户的实际使用状况，所以对于大多数的系统，只有数量不多的用户进行“严格意义上的并发”。对于WEB性能测试而言，这2种并发状况通常都须要进行测试，一般作法是先进行严格意义上的并发测试。严格意义上的用户并发通常发生在使用比较频繁的模块中，尽管发生的几率不是很大，可是一旦发生性能问题，后果极可能是致命的。严格意义上的并发测试每每和功能测试关联起来，由于并发功能遇到异常一般都是程序问题，这种测试也是健壮性和稳定性测试的一部分。

用户并发数量：关于用户并发的数量，有2种常见的错误观点。一种错误观点是把并发用户数量理解为使用系统的所有用户的数量，理由是这些用户可能同时使用系统；还有一种比较接近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不必定会和其余用户发生并发，例如正在浏览网页的用户，对服务器没有任何影响，可是，在线用户数量是计算并发用户数量的主要依据之一。

请求响应时间：指的是客户端发出请求到获得响应的整个过程的时间。在某些工具中，请求响应时间一般会被成为"TLLB"，即"Time to last byte",意思是从发起一个请求开始，到客户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位通常为"秒"或者"毫秒".

事务响应时间:事务可能由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念，是为了向用户说明业务响应时间而提出的.例如:跨行取款事务的响应时间就是由一系列的请求组成的.事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数.

吞吐量:指的是在一次性能测试过程当中网络上传输的数据量的总和.吞吐量/传输时间,就是吞吐率.

TPS:每秒钟系统可以处理的交易或者事务的数量.它是衡量系统处理能力的重要指标.

点击率:每秒钟用户向WEB服务器提交的HTTP请求数.这个指标是WEB应用特有的一个指标:WEB应用是"请求-响应"模式,用户发出一次申请,服务器就要处理一次,因此点击是WEB应用可以处理的交易的最小单位.若是把每次点击定义为一个交易,点击率和TPS就是一个概念.容易看出,点击率越大,对服务器的压力越大.点击率只是一个性能参考指标,重要的是分析点击时产生的影响。须要注意的是,这里的点击并不是指鼠标的一次单击操做,由于在一次单击操做中,客户端可能向服务器发出多个HTTP请求.

资源利用率:指的是对不一样的系统资源的使用程度,例如服务器的CPU利用率,磁盘利用率等.资源利用率是分析系统性能指标进而改善性能的主要依据,所以是WEB性能测试工做的重点.

资源利用率主要针对WEB服务器,操做系统,数据库服务器,网络等,是测试和分析瓶颈的主要参考.在WEB性能测试中,更根据须要采集相应的参数进行分析.

Web安全测试入门

测试工做总结
Web应用系统易出问题的缘由和测试要点

web应用系统是目前最多见的应用系统之一，例如电子商务网站，就是一种典型的web应用系统，关于测试要点，我认为能够有如下几点：

当咱们在进行web应用系统的测试时，咱们能够作这样一个假设：若是咱们是某个电子商务网站的用户，咱们会对这个网站有哪些指望呢？

1,有足够的性能，不要在并发用户不少的时候响应速度很慢；

2,有足够好的兼容性，当咱们使用IE之外的浏览器的时候，网站仍旧可以正常使用；

3,有足够的安全性。至少咱们不但愿本身的用户名和密码被别人轻易得到；

4,连接的正确性。当咱们点击购买一本图书时，咱们不但愿出现的是是张CD的页面；

因而总结起来无外乎，性能，兼容性，安全性，正确性，我认为这是咱们测试人员应该关注的要点。

这几方面容易出问题的缘由，我想可能跟如下几点有关吧。

1,网站用户的数量可能在某个时间段迅速增长，其增长的速度和用户的总数可能会超过当初设计的极限；

2,用户使用环境的复杂性，系统就有WINDOWS,LINUX和其余系统，浏览器又有IE ,FIREFOX ,NETSCAPE,OPERA等等；而有的用户显示器可能还仅仅支持800*600等等情况的复杂性；

3,网络的人为攻击，病毒泛滥等

4,在一个web页面存在大量的链接，且这些连接是在不断更新，不免会出现错误；

因为这些问题的存在，在编写测试计划和测试用例，搭建测试环境和执行测试时，我认为，应该基于web应用系统的测试时的特征，有针对性地进行测试工做。

另外，对于web应用系统来讲，还能够分为服务器端测试和客户端测试两部分，毕竟web是由服务器端和客户端组成的。

我想，在服务器端，重点进行的应该是性能测试，负载测试和安全测试吧？！

在客户端，则要在兼容性测试上作好工夫。

其实对于web，最广泛的性能测试应该是负载测试，经过负载测试，测试人员就能够知道系统如何完成预期的或者超过预期的行为。例如：某个电子商务网站设计时，考虑能同时在线的用户为5000人。那测试员就须要知道当同时在线5000人时，系统的响应情况，也要知道，若是在某个时间段同时在线用户超过系统设计值，假设达到了10000人，系统的响应状况。若是同时在线5000人时，系统响应速度很慢，以致于不多有用户有足够的耐心来等待完成，那么我想这个web系统将不会被用户接受。