1、功能测试

对于网站的功能测试而言，每一个独立的功能模块需要单独的测试用例的设计导出，主要依据为《需求分析》，对于应用程序模块需要设计者提供基本路径测试法的测试用例。
具有测试用例后可以采用OpenSTA(Open System Testing Architecture)进行自动化测试

 

2、性能测试

网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做的不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立网站的性能测试的一整套的测试方案将是至关重要的。
网站的性能测试主要从两个方面进行：负荷测试(Load)和压力测试(Stress),负荷测试指的是进行一些边界数据的测试，压力测试更像是恶意测试，压力测试倾向应该是致使整个系统崩溃。
性能测试可以采用相应的工具进行自动化测试，我们目前采用如下工具
ab -----Apache 的测试工具
OpenSTA—开发系统测试架构

 

3、安全性测试

目前网络安全问题日益重要，特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试，我们拟定采用工具来测定，工具如下
SAINT------- Security Administrator's Integrated Network Tool
此工具能够测出网站系统的相应的安全问题，并且能够给出安全漏洞的解决方案，不过是一些较为常见的漏洞解决方案。

 

4、稳定性测试

网站的稳定性测试是指网站的运行中整个系统是否运行正常，目前没有更好的测试方案，主要采用将测试服务器长时间运转进行测试。

 

5、浏览器兼容性测试

通过白盒测试或者黑盒测试导出的测试用例，采用相应的工具进行测试，可以采用OpenSTA进行测试，此测试工具可以采用不同的浏览器进行测试。

 

6、可用性/易用性测试

可用性/易用性方面目前我们只能采用手工测试的方法进行评判，而且缺乏一个很好的评判基准进行，此一方面需要大家共同讨论。

 

7、链接测试 超级链接对于网站用户而言意味着能不能流畅的使用整个网站提供的服务，因而链接将作为一个独立的项目进行测试。目前我们已经有了一个测试工具
Xenu------主要测试链接的正确性的工具
可惜的是对于动态生成的页面的测试会出现一些错误。

 

8、代码合法性测试

代码合法性测试主要包括2个部分：程序代码合法性检查与显示代码合法性检查
¨ 程序代码合法性检查
程序代码合法性检查主要标准为《intergrp小组编程规范》，目前采用由SCM管理员进行规范的检查，未来期望能够有相应的工具进行测试。
¨ 显示代码合法性检查
显示代码的合法性检查，主要分为Html、Javascrīpt、Css代码检查，目前采用
HTML代码检查------采用CSE HTML Validator进行测试
Javascrīpt、Css也可以在网上下载相应的测试工具。

基于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、javascrīpt、 ActiveX、VBscrīpt或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，、javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

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

　　五、安全性测试

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

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

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

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

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

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

　　六、总结

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

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

  昨天晚上又是3点睡觉，周末形成习惯就不知不觉的玩到很晚，好几次痛下决心要早点睡觉就是没有做到。

早上睡到了12点才起床，吃了饭不知不觉的又坐到电脑旁边对着电脑发呆，好了，不说了学习去了！！！！

   马上就要毕业，工作一直没有落实。前两天参加了两家公司的面试，很让我难过,对于我这样对测试充满了热情，但是又没有工作经验的来说很容易碰壁呀！

   回头想想自己到底失败在哪里？不光是自己没有经验，自己的基础也是太差了点儿！不过我会努力的，我一定能找到一份自己喜欢测试工作！

 

QTP，全称为Quick Test Professional，它与WinRunner同为MI公司开发的功能强大的功能测试工具。从时间上来看，WinRunner在1995年便已经推出，远早于QTP，而QTP直到2002年才正式推出。从MI公司提供的一些官方资料来看，虽然他们宣称暂时不准备淘汰WinRunner，但他们的宣传资料上又明确表示，QTP已经具备了WinRunner中几乎所有的特性，同时具备了一些独有的特性，并且总体来说，使用更简单、更易扩展和维护，推荐新用户使用QTP，并建议已使用WinRunner的老客户逐渐实现转换。由此看来，MI公司实际上已经有使用QTP逐步取代WinRunner的计划。更重要的是，QTP对J2EE，.NET架构的应用程序支持得比WinRunner要好（从我实际的试用过程中，也感到确实是如此），因此我认为，从我们公司的实际情况出发，针对产品综合部今后将逐步开展自动化测试的计划，QTP应该是一个比较好的选择。
不论是WinnRunner还是QTP，它们都是功能十分强大的测试工具，加上目前国内关于测试工具的培训和文档资料，实在是少之又少，因此要完全了解和掌握它们，绝不是一朝一夕的事情。在这里我只能就目前对它们的理解程度粗略地介绍一下二者的两点主要不同之处。
1、使用的脚本语言不同。WinRunner使用的是TSL语言，这是MI公司独有的语言，有特殊性，因此在学习上会有一定难度，不过好在它与C 语言比较类似，如果测试人员有一定的C语言编程基础，会相对容易一些。而QTP使用的则是微软的VBscrīpt语言，比较通用，而且也相对简单易学。从语言上的比较上来看，我个人觉得在编程能力上，WinRunner更胜一筹，因为它拥有相当丰富的C语言函数库，而相对而言，QTP则更大众化，它面向的是没有太多技术背景和编程经验的测试人员。
2、QTP8.0具有的一大特性：关键字驱动测试（keyword-driven testing）。它的具体操作方法我将有另外的文档详细说明，这里只是简单介绍一下。通过“关键字驱动测试”，测试人员不需要“录制”测试脚本，而可以改成“设计”测试脚本。即：先将应用程序的GUI对象添加到QTP的对象仓库（Object Repository）中，然后针对每一个需要操作到的对象设计每个测试步骤。我个人感觉，这的确是一个很酷的特性，它使我们可以不必实际去操作应用程序，就可以编写出测试脚本，这样做既节省了时间，而且还有一个更大的好处就是可以在应用程序还没有设计完成，或者由于出错无法正常执行的时候仍然可以编写我们的测试脚本。应用程序只需要有使用界面（UI），而不必实际运行，测试人员就可以开始建立测试脚本，为我们实施自动化测试赢得更充足的时间。而在 WinRunner中，虽然也可以采用先学习对象，然后编写代码的方式来完成测试脚本，但这样做要求测试人员对TSL语言比较熟悉才做得到，远不如QTP 来得简单。在实际的操作中我还发现，有些时候采用录制的方法无法捕获对应用程序的操作，此时改用关键字驱动测试却可以收到不错的效果。
3、相对WinRunner，QTP还具有很多优点，例如“数据表整合”，“Active Screen”，“point and click”，更容易参数化等等，但对于这几点我还没有深入的做过比较，如果今后我对此有了更多的体会和了解，我将再作整理。

一、工具介绍

    LoadRunner是一种预测系统行为和性能的工业标准级负载测试工具，能优化系统性能。它的测试对象是整个企业的系统，通过模拟实际用户的操作行为和实行实时性能监测，帮助用户能尽快查找和发现问题。

   LoadRunner通过模拟一个多用户并行工作环境来对应用程序进行负载测试，当应用程序在负载下运行时，LoadRunner会准确地度量、监控并分析系统的性能和功能。

 

二、LoadRunner特点

1.         创建真实的负载

    用LoadRunner的Controller,能快速组织起多用户的测试方案，并提供一个互动的环境，在其中既能建立持续且循环的负载，又能管理和驱动负载测试方案。同时，可以利用日程计划服务来定义用户什么时候访问系统以产生负载。这样，就能使测试过程自动化。

2.         实时监测器

   LoadRunner内含的实时监测器，在负载测试过程的任何时候，都可以观察到应用系统的运行性能。这些性能检测器实时显示交易性能数据（如响应时间）和其他系统组件包括Application Server, Web Server ，网路设备和数据库的实时性能。

3.         分析结果定位问题

    测试完毕，LoadRunner收集汇总所有的测试数据，并提供高级的分析和报告工具，以便迅速查找性能问题并追溯原由。通过分析，能很快的查找到出错的位置和原因并做出相应的调整。

 

三、测试步骤和流程

LoadRunner基本测试过程由以下四个步骤组成：

1.         步骤一：创建脚本

• 通过录制应用程序中典型最终用户执行的操作来生成虚拟用户（Vuser），将该用户的操作录制到自动虚拟用户脚本中，以便作为负载测试的基础。

2.         步骤二：设计场景

3.         步骤三：运行场景

• 运行用来模拟真实用户执行操作的脚本，并可以通过让多个虚拟用户（Vuser)同时执行这些操作来在系统中创建负载。

4.         步骤四：分析结果

• 提供包含深入的性能分析信息的图和报告。使用这些图和报告，可以标识应用程序中的瓶颈，并确定需要对系统进行哪些更改来提高系统性能。

如何评价性能的优劣？

    对于最终用户(End-User)来说，评价系统的性能好坏只有一个字——“快”。最终用户并不需要关心系统当前的状态——即使系统这时正在处理着成千上万的请求，对于用户来说，由他所发出的这个请求是他唯一需要关心的，系统对用户请求的响应速度决定了用户对系统性能的评价。 

    而对于系统的运营商和开发商来说，期望的是能够让尽可能多的用户在任意时刻都拥有最好的体验，这就要确保系统能够在同一时间内处理更多的用户请求。系统的负载（并发用户数）与吞吐量（每秒事务数）、响应时间以及资源利用率（包括软硬件资源）之间存在着一个“此消彼长”的关系。因此，从系统的运营商和开发商的角度来看，所谓的“性能”是一个整体的概念，是系统的负载与吞吐量、可接受的响应时间以及资源利用率之间的平衡。

    换句话说，“好的性能”意味着更大的最佳并发用户数和最大并发用户数。

 

四、知识点

1.         插入集合点

      插入集合点是为了衡量在加重负载的情况下服务器的性能情况。在测试计划中，可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据，从而达到测试计划中的需求。

2.         参数化输入

    如果用户在录制脚本过程中，填写提交了一些数据，比如要增加数据库记录。这些操作都被记录到了脚本中。当多个虚拟用户运行脚本时，都会提交相同的记录，这样不符合实际的运行情况，而且有可能引起冲突。为了更加真实的模拟实际环境，需要各种各样的输入。