我们大家一起来说说B/S版软件的测试

榕儿

做了挺长时间的测试，但总觉得进步很小。今突发其想，一个人的力量有限，想与各位探讨。我们大家一起想想B/S版软件测试时有些什么要注意的，需要从哪些方面进行测试。

[[i] Last edited by 榕儿 on 2004-11-19 at 14:37 [/i]]

fengfan928

基于Web的系统测试方法
基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。
　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。
　　随着Internet和Intranet/Extranet的快速增长，Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上，电子商务迅速增长，早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在，是因为它能提供支持所有类型内容连接的信息发布，容易为最终用户存取。
　　Yogesh Deshpande和Steve Hansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科，提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则，用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前，对于web工程的研究主要是在国外开展的，国内还刚刚起步。
　 在基于Web的系统开发中，如果缺乏严格的过程，我们在开发、发布、实施和维护Web的过程中，可能就会碰到一些严重的问题，失败的可能性很大。而且，随着基于Web的系统变得越来越复杂，一个项目的失败将可能导致很多问题。当这种情况发生时，我们对Web和Internet的信心可能会无法挽救地动摇，从而引起Web危机。并且，Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。
　　在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

　　一般软件的发布周期以月或以年计算，而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

　　一、功能测试

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　2、表单测试

　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　3、Cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

　　4、设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或Perl等也要进行验证。

　　5、数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

　　二、性能测试

　　1、连接速度测试

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

　　另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

　　2、负载测试

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

　　3、压力测试

　　负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

　　进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

　　压力测试的区域包括表单、登陆和其他信息传输页面等。

　　三、可用性测试

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　（2）验证所有页面字体的风格是否一致。

　　（3）背景颜色应该与字体颜色和前景颜色相搭配。

　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

　　4、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？

对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

　　四、客户端兼容性测试

　　1、平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　2、浏览器测试

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、javascript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。


　　五、安全性测试

　　Web应用系统的安全性测试区域主要有：

　　（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

　　（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

　　（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

　　六、总结

　　本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

基于Web的系统测试与传统的软件测试既有相同之处，也有不同的地方，对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

qoorange

3q!可以现学现用！

wangna2002na

真棒，顶一个，呵呵。

peter525

楼主真的不错,讲得太好了,受益匪浅.

yiyi820106

受益匪浅

特别关注

很好，谢谢！

133126595

顶 谢谢~~~~~~~

fairyox

6楼的文章确实强，不过好象从哪里看到过 。
我倒想说一说自己的想法。
对于B/S结构都有一个共同的特点，就是用户、身份、角色和权限的问题。
我对这四个概念我也是思考了很久，根据我想的东西说一下：
首先看下面几个例子：
用户→身份→角色→权限
把这些概念赋予一个部队的某个班
张三→士兵→炮兵→打炮
李四→士兵→炮兵→装蛋（装弹）
王五→班长→炮兵→指挥打炮、装弹、打炮
赵六→士兵→伙房师傅→给炮兵做饭
以上的例子是存在于某个炮兵班的系统当中，每个用户都有自己的身份和角色，身份和角色决定了他的权限。
用户：进入到系统当中操作的所有人，或者说是虚拟的人。在系统中我们假设每个人只有一个用户名和密码，那么我们每个人在系统中都是一个单独的用户。当然有的时候有一个人有很多用户名和密码，那么他可能在系统中扮演多个身份和角色，不过在他以某个用户名进入系统后我们仍然认为他是一个独立的人。就像一个人既可以是教师又可以是奥运志愿者一样，在社会上身份和角色和可以做的事，但是在某个特定的环境中他的身份角色是唯一的。
身份：指在大环境下的具有某个或某些特定功能的群体。所谓大环境就是在整个系统中对一个用户的定义，这里主要是具有最高权限的系统管理员、管理员和非管理员，有时候管理员可能还分很多种。身份在大环境中一般来说是相对稳定的。这种身份最典型的就是论坛中，每个版都有自己的斑竹，可以是一个也可以是多个，整个论坛还有权限最高的管理员，其他的用户则为非管理员。以上例子中，在这个炮兵班的身份主要是班长和士兵，即简单的系统管理员和非管理员，如果是排就有普通管理员这个身份存在了。
角色：只在小环境中或特定环境中一个用户或多个用户指定的身份类型。这个是动态的，也可以说是经常变动的。像演戏一样，演员是一个用户的身份，但是角色却是随着戏的不同经常发生着变化的。在B/S结构系统中经常会存在VIP用户，注册用户，高级用户，普通用户，游客等的角色，他们做能做的东西其实都是非关系管理类的。那么我们说以上的称呼就是他们的角色，在论坛中这种情况更加的典型。很多网站积分达到多少或者交了多少多少的钱就会被系统允许做什么什么样的操作，其实就是在做角色的改变。以上例子中炮兵就可以分为（我不懂，瞎说的）装弹员，点火员，擦跑员，运炮车司机等。他们在一次打炮的操作中所做的工作是完全不一样的，只有一个是确定的，他们只能在某一环节中起到作用，却不能从全局进行操控。
权限：所谓权限就是权力和限制，说白了就是你能在系统中做哪些操作。每个系统都是若干功能，也可以说成是有若干个权限，每种操作无论是针对系统的还是系统中某个部分的都会根据身份和角色不同赋予某一个或某一些用户。所以权限一般不会被一个用户所拥有，在以上的例子中可以看到，不只一个角色可以打炮，也不只一个角色可以装弹，所以权限有的时候是可以交叉使用的。

ok   四个概念终于说完了（感觉都是废话）  很明显了  我们的系统由这些元素组成  那么他们是怎么工作的呢？  流程

做测试的人都知道测试有流程，bug处理有流程，其实每个系统都有自己的操作流程。对于上面的例子，我认为简单流程应该如下：
把炮的各个部分装上运炮车→将运炮车开到目的地→卸炮→组装大炮→调试→校对→装弹→准备→开炮→收炮→卸炮→将炮零件装上车→将运炮车开回营地→保养炮和炮车→收入仓库
其实中间有很多步骤是要加如判断的，如果判断否回到前面的某个步骤重新开始。

很明显了，我不想解释例子中某个身份或者角色在这个流程中的某个环节用了什么权限发挥了什么样的作用大家也应该都很清楚明了了。

个人认为做B/S测试主功能测试的时候路线应该是这样的：
1.测试每个权限是否正确。
2.多个权限在一起时是否发生功能性错误。
3.测试权限赋予角色后是否正确
4.角色所具备的权限是否正确，是否有缺少或存在不该有的权限。
5.在特定身份的情况下角色所具有的权限会发生什么样的改变。
6.当发生角色交叉，就是一个身份可以扮演多个角色的时候发生权限交叉会不会有错误。
7.在流程中测试权限的功能是否有问题（这里一定保证覆盖流程的所有分支）。
8.当流程发生中断的处理。

当然这种测试有时也会出现问题，就是在B/S结构中有时候会有在任何情况都可以做的操作。比如查看，查询，排序类的操作，所以这一类操作要单独进行测试。

我是测试新人，刚刚培训结束，以上都是自己想出来的，从来没在大项目是实践过，如果有错误请指出，谢谢哥哥姐姐们的支持。

zhulei2612022

不错不错

fjl6187

收了,多谢

lovry

我是按软件流程来测试的~
别的偶也不知道哈~
新手哈~

zhangc999

它边缘数据

owenyuan

强

末落者

that's very good!

zlxly

我是个刚入行的新人只能授教了,我会好好学的.

77582

内容很全面,收藏了

jijunjun2007

哪位大侠做过web 性能测试啊?特别是负载和安全方面的?还请指教!

jxjx1003

功能上,页面上,安全性上,性能上~~~~~

maihua258

这么多，我看了都不记得了呵呵！好象有点深奥哦

storm

学习了，谢谢

longhui5513

我学到不少东西，谢谢啦：）