web测评图

⑴ Web测试的主要内容和测试方法有哪些

测试分类：

1、界面测试

1）给用户的整体感：舒适感；凭感觉能找到想要找的信息；设计风格是否一致

2）各控件的功能

2、功能测试

1）删除/增加某一项：是否对其他项造成影响，这些影响是否都正确

2）列表默认值检查

3）检查按钮功能是否正确：新建、编辑、删除、关闭、返回、保存、导入、上一页、下一页、页面跳转、重置（常见错误）

4）字符串长度检查：超出长度

5）字符类型检查

6）标点符号检查：空格、各种引号、Enter键

7）特殊字符：常见%、“、”

8）中文字符：是否乱码

9）检查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息与添加信息是否一致

10）信息重复：需唯一信息处，比如重复的名字或ID、重名是否区分大小写、加空格

11）检查删除功能：不选择任何信息，按Delete，看如何处理；选择一个或多个进行删除；多页选、翻页选删除；删除是否有提示

12）检查添加和修改是否一致：添加必填项，修改也该必填；添加为什么类型，修改也该什么类型

13）检查修改重名：修改时把不能重名的项改为已存在的内容

14）重复提交表单：一条已经成功提交的记录，返回后再提交

15）检查多次使用返回键：返回到原来页面，重复多次

16）搜索检查：存在或不存在内容，看搜索结果是否正确；多个搜索条件，同时输入合理和不合理条件；特殊字符

17）输入信息的位置

18）上传下载文件检查：功能是否实现，

上传：上传文件是否能打开、格式要求、系统是否有解释信息、将不能上传的文件格式修改后缀为可上传的文件格式；

下载：下载是否能打开、保存、格式要求

19）必填项检查：必填项未填写；是否有提示，如加*；对必填项提示返回后，焦点是否自动定位到必填项

20）快捷键检查：是否支持快捷键Ctrl+C、Ctrl+V、backspace；对不允许做输入的字段（如：下拉选项），对快捷方式是否也做了限制

21）Enter键检查：输入结束后按Enter键，系统如何处理

22）刷新键检查：按浏览器刷新键如何处理

23）回退键检查：按浏览器回退键如何处理

24）空格检查：输入项输入一个或多个空格

25）输入法半角全角检查：比如，浮点型，输入全角小数点“。”或“. ”，如4. 5；全角空格

26）密码检查：输入加密方式的极限字符；密码尽可能长

27）用户检查：不同种类管理员用户的不同权限，是否可以互相删除、管理、编辑；一般用户的权限；注销功能，老用户注销再注册，是否为新用户

28）系统数据检查：数据随业务过程、状态的变化保持正确，不能因为某个过程出现垃圾数据，也不能因为某个过程而丢失数据。

29）系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可以迅速恢复

30）确认提示检查：系统更新、删除操作：是否有提示、取消操作；提示是否准确；事前、事后提示

31）数据注入检查：对数据库注入，特殊字符，对SQL语句进行破坏

32）时间日期检查：时间、日期、时间验证：日期范围是否符合实际业务；对于不符合实际业务的日期是否有限制

33）多浏览器验证

3、性能测试

1）压力测试：实际破坏一个Web应用系统，测试系统的反应，测试系统的限制和故障恢复能力

2）负载测试：在某一负载级别上的性能，包括某个时刻同时访问Web的用户数量、在线数据处理的数量

3）强度测试：测试对象在性能行为异常或极端条件下（如资源减少或用户过多）的可接受性，以此验证系统软硬件水平

4）数据库容量测试：通过存储过程往数据库表中插入一定数量的数据，看是否能及时显示

5）预期指标的性能测试：在需求分析和设计阶段会提出一些性能指标，对于预先确定的性能要求要首先进行测试

6）独立业务性能测试：对核心业务模块做用户并发测试，包括同一时刻进行完全一样的操作、同一时刻使用完全一样的功能

7）组合业务性能测试：模拟多用户的不同操作，最接近实际用户使用情况，按用户实际的实际使用人数比例来模拟各个模块的组合并发情况

8）疲劳强度性能测试：系统稳定运行情况下，以一定负载压力来长时间运行系统的测试

9）网络性能测试：准确展示带宽、延迟、负载、端口的变化是如何影响用户的相应时间的

10）大数据量性能测试：实时大数据量，模拟用户工作时的实时大数据量；极限状态下的测试，系统使用一段时间，积累一段数据量时能否正常运行，以及对前面两种进行结合

11）服务器性能测试：在进行用户并发性能测试、疲劳强度、大数据量性能测试时，完成对服务器性能的监控，并进行评估

12）一些特殊的测试：配置测试、内存泄漏的一些特殊测试

4、可用性测试(接口测试）

1）整体界面测试

2）多媒体测试

3）导航测试

5、客户端兼容性

平台测试：windows；unix；macintosh；linux

浏览器测试：不同厂商的浏览器对Java、Javascript、ActiveX、plug-ins或不同的HTML的规格

不同的支持；框架和层次结构在不同浏览器也不同的显示

6、安全性

安全性测试要求：

1）能够对密码试探工具进行防范

2）能够防范对Cookie攻击的常用手段

3）敏感数据保证不用明文传输

4）能防范通过文件名猜测和查看html文件内容获取重要信息

5）能保证在网站收到工具后在给定时间内恢复，重要数据丢失不超过1小时

web的性能测试工具：

随着Web2.0技术的迅速发展，许多公司都开发了一些基于Web的网站服务，通常在设计开发Web应用系统的时候很难模拟出大量用户同时访问系统的实际情况。

因此，当Web网站遇到访问高峰时，容易发生服务器响应速度变慢甚至服务中断。

为了避免这种情况，需要一种能够真实模拟大量用户访问Web应用系统的性能测试工具进行压力测试，来测试静态HTML页面的响应时间，甚至测试动态网页（包括ASP、PHP、JSP等）的响应时间，为服务器的性能优化和调整提供数据依据。

1、企业级自动化测试工具WinRunner

MercuryInteractive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。

2、工业标准级负载测试工具Loadrunner

LoadRunner是一种预测系统行为和性能的负载测试工具

3、全球测试管理系统testdirector

TestDirector是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。

4、功能测试工具RationalRobot

IBMRationalRobot是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。

它集成在测试人员的桌面IBMRationalTestManager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。

这种测试和管理的双重功能是自动化测试的理想开始。

5、单元测试工具xUnit系列

目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。

该测试框架的第一个和最杰出的应用就是由ErichGamma（《设计模式》的作者）和KentBeck（XP（ExtremeProgramming）的创始人）提供的开放源代码的JUnit.

6、功能测试工具SilkTest

BorlandSilkTest2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。

这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。

7、性能测试工具WAS

是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。

透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

8、自动化白盒测试工具Jtest

Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。

parasoft同时出品的还有C++test，是一款C/C++白盒测试工具。

9、功能和性能测试的工具JMeter

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。

10、性能测试和分析工具WEBLOAD

webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试；webload通过模拟真实用户的操作，生成压力负载来测试web的性能。

(1)web测评图扩展阅读：

漏洞测试

企业网站做的越来越复杂、功能越来越强。不过这些都不是凭空而来的，是通过代码堆积起来的。如果这个代码只供企业内部使用，那么不会带来多大的安全隐患。

但是如果放在互联网上使用的话，则这些为实现特定功能的代码就有可能成为攻击者的目标。

天眼举一个简单的例子。在网页中可以嵌入SQL代码。而攻击者就可以利用这些SQL代码来发动攻击，来获取管理员的密码等等破坏性的动作。

有时候访问某些网站还需要有某些特定的控件。用户在安装这些控件时，其实就有可能在安装一个木马（这可能访问者与被访问者都没有意识到）。

为此在为网站某个特定功能编写代码时，就要主动出击。从编码的设计到编写、到测试，都需要认识到是否存在着安全的漏洞。

天眼在日常过程中，在这方面对于员工提出了很高的要求。各个员工必须对自己所开发的功能负责。

已知的病毒、木马不能够在所开发的插件中有机可乘。通过这层层把关，就可以提高代码编写的安全性。

⑵ web测试有哪些方面

第一，分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于LOAD测试的相同测略需同时考虑稳定性测试的需求。
第一，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。
第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。
第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。
第五，确定采用的测试工具。
第六，进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。
第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。
第八，完成性能测试评估报告。
在进行性能测试的时候，我们需要知道一些有效的性能指标，下面我们来列出一些主要的性能指标：
一是，通用指标（指Web应用服务器、数据库服务器必需测试项）：
*ProcessorTime：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；
*Memory Available Mbyte：可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
*Physicsdisk Time ：物理磁盘读写时间情况。
二是，Web服务器指标：
*Avg Rps：平均每秒钟响应次数＝总请求时间/秒数；
*Avg time to last byte per terstion（mstes）：平均每秒业务角本的迭代次数；*Successful Rounds：成功的请求；
*Failed Rounds：失败的请求；
*Successful Hits：成功的点击次数；
*Failed Hits：失败的点击次数；
*Hits Per Second：每秒点击次数；
*Successful Hits Per Second：每秒成功的点击次数；
*Failed Hits Per Second：每秒失败的点击次数；
*Attempted Connections：尝试链接数。
三是，数据库服务器指标：
*User 0 Connections ：用户连接数，也就是数据库的连接数量；
*Number of deadlocks：数据库死锁；
*Butter Cache hit：数据库Cache的命中情况）。

可用性测试：1导航测试（Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。）2图形测试3内容测试3整体界面测试4客户端兼容性测试（1平台测试2浏览器测试）5安全性测试（测试重点：（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。 ）

⑶ WEB测试应该注意哪些地方，怎样才能做好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的系统测试不但需要检查和验证是否按照设计的要求运行，而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。

⑷ 如何使用LoadRunner进行Web性能测试

1、明确压力点，根据压力点设计多少种场景组合
2、把文档（包括多少种场景组合、场景与场景组合条件的对应表）写好
3、如果监测UNIX机器，在被监测的机器需要安装监测Unix的进程
4、让开发人员帮助我们准备测试数据或他们写相关的文档我们来准备数据
5、让开发人员做一个恢复数据的脚本，以便于我们每次测试的时候都能够有一个相同的环境
6、针对每一个模块包括四个子文件夹：如模块A下包括“脚本”“场景”“结果”“图表” 四个子文件夹，每个子文件夹储存对应的文件，如下表所示
其中：结果名“1场景”是在场景中的“Results Setting”中设置的，具体的设置见“建立场景”部分，这里也可以有另外一种方法：在打开模板设置，如下：
选中“Automatically save the session as:”并且在“%ResultDir%”后面填写你想保存的文件名，当你打开某个lrr文件时，系统自动在当前目录中生成一个文件保存分析图表，如下图所示：
生成测试脚本
1、 把登陆部分放到“vuser_init”部分,把需要测试的内容部分放到“Action”部分执行；但是如果是模拟多个用户登陆系统，则要把登陆部分放到Action部分来实现
2、 录制脚本后，想查询某个函数的原型，按“F1”键
3、 确认脚本中哪些参数是需要进行参数化的（最好能可以和开发人员一起确认）
4、 在脚本参数化时把函数web_submit_data()中的ITEMDATA后面的数据参数化，因为这些数据是传递给服务器的，当然也可以把一个函数中的所有相同变量都替换掉
5、 脚本中无用的部分用“/*”“*/”“//”注释掉，但最好不要删除
6、 调试脚本遵循以下原则：
确认在VU里SUSI（单用户单循环次数single user & single iteration）
确认在VU里SUMI（单用户多循环次数single user & multi iteration）
确认在controller中MUSI（多用户单循环次数multi user & single iteration）
确认在controller中MUMI（多用户多循环次数 multi user & multi iteration）
7、 事务的名称取的有意义便于事务之间的区分，把所有的事务名都记录在一起，便于在测试结果概要中区分它们，这要写成一个表：某次测试有哪些模块，每个模块中有哪些事务(见对应的“关系表”)
8、 在 “Parameter List”中可以选择参数类型“Random Number”，使某一个参数取设定的范围内的随机值
建立场景
1、 把场景名称编号，并制定出一份场景名称和场景条件组合的对应表。比如，场景m对应于“某一模块_xx个vu _分z台machine”(见“关系表”中的例子)
2、 根据上面的对应表把场景设置好，需要设置的要素如下：总体多少个用户、分多少个组、每个组有多少个用户、分几台机器运行、每个脚本迭代多少次、是否回放think time时间、检查Parameter List中每个参数设置是否正确、参数从表中取值间隔是否正确、是否选中“Initialize all Vusers before Run”
3、 测试结果应该保存为“m场景0，m场景1,…”
4、 把虚拟用户分散到几台机器上和在一台机器上面都要进行测试，因为有可以效果不同
5、 场景中如果有需要改动的地方，必须新建一个场景(建议使用“另存为”，然后再修改结果文件名，再选择相应的脚本)，并把场景按顺序编号，先维护好场景与场景组合条件的对应表，以便以后的查找，并且在结果 “Results Setting”中设置的结果名与场景名相同。建议在“Results Setting”中选中“Automatically create a results directory for each scenario executeon”让它每次自动累加，不建议选中“Automatically overwrite existing results directory without prompting for confirmation”，因为我们不要覆盖掉以前的测试结果，把它保存下来以便有个根据。
6、 需要注意的地方：当在“Parameter List”中的“Select next row”选中“Unique”时，如果再在“Edit Schele\Schele by Scenario\Duration”中选中第二项“Run for XX after the ramp up has been completed”时系统就会报错，提示“Unique”类型不相符。
7、 在“Run-time Setting”设置中，“General”中的“Pacing”非常有用，可以设置每次迭代之间相隔多少时间，也可以是随机的取值
8、 建议：把“Parameter List”和“Run-time Setting”中的所有设置都搞熟悉，这样便于以后对脚本和场景进行设置
9、 设计“Parameter List”时的小技巧：即在“Allocate X values for each Vuser”时，尽量 把它的间隔在数据容许的范围内取大些，这样可以做从一次迭代到最大值迭代，而且对脚本没有什么影响
10、当一个脚本中有多个事务，在事务前面增加集合点时需要一点技巧。或者我们把脚本复制几个，或者我这样做：测试前面的事务的压力时，把后面的事务前的集合点设置为不激活状态；在测试后面的事务的压力时，把前面的事务的集合点设置为不激活状态，另外最好不选中Initialize all Vusers before Run，具体参见Controller中的“Scenario/Rendezvous”，及用户手册(按F1)
11、把持续时间从最后60秒改为整个场景的时间，右键单击某个图，选择“Configue”，修改Graph Time即可
12、每次从一个场景修改后保存为另一个场景时别忘记把结果保存文件名修改相对应的文件名。在设置结果保存文件名时有一个技巧：如果你打开这个窗口时，点击确定则系统会
默认以“4场景2”为基点向后加“4场景20”“4场景21”等等，但是如果你把结果文件名后面的数据去掉，改为“4场景”，点击确定后，系统会自动搜索是以“4场景”开头的文件名，并在它的后面继续增加，比如把它改为“4场景”时，下次结果保存在“4场景3”中。而且他在搜索的时候搜索以“4场景”开头的文件名，从0开始，有的话就不取代而跳过，没有的话就取代。
运行场景
1、 运行场景前需要注意的事项：每个组的虚拟用户数、迭代次数、think time、参数化时的取值间隔、执行恢复数据的脚本、确认虚拟机的LoadRunner Agent Service打开
2、 如果监测Unix，运行场景前需要启动监测Unix进程，启动的命令“rpc.rstatd”、查看这个进程是否启动的命令“rpcinfo –p”
3、 运行前使Generator机器处理Ready状态
4、 确认被监测的机器已经连接上去，并且添加自己所需要的计数器
5、 运行之前一定要确认系统中压力点的数据量是多少
6、 确认以上都正确时再运行测试场景

监视场景
打开 “Passed Transactions”或“Failed Transactions”，可以随时观察到事务的运行状态
分析测试结果
1、 打开Analysis后，把经过数据处理的结果图表保存到“图表”文件夹，并且文件名和场景名、结果名相同，这样便于以后的查阅。也可以省去每次进行数据处理的时间。
2、 可以通过点击界面上的 “View Run Time Setting”可以看到此场景运行时的一些场景设置
3、 在关联图表时可以自动调节每个元素的比例，点击右键，选择 即可
4、 每次测试结束后确认所做的操作是正确的，确认正确后再分析结果
5、 在结果文件夹中为每个场景建立一个文档，把每次运行时的情况记录下来以便于写测试报告，尤其运行错误的原因记录下来，并把开发人员所做的修改也记录下来以便知道开发人员做了些什么修改
6、 在分析运行结果时可以把几个结果合在一起进行比较，打开如下“Cross with Result…”

⑸ Web测试的主要内容和测试方法有哪些

1功能测试 2 1.1链接测试 2 1.2表单测试 2 1.3数据校验 3 1.4 cookies测试 3
1功能测试 2
1.1链接测试 2
1.2表单测试 2
1.3数据校验 3
1.4 cookies测试 3
1.5数据库测试 3
1.6应用程序特定的功能需求 4
1.7设计语言测试 4
2性能测试 4
2.1连接速度测试 4
2.2负载测试 4
2.3压力测试 5
3用户界面测试 6
3.1导航测试 6
3.2图形测试 6
3.3内容测试 7
3.4表格测试 7
3.5整体界面测试 7
4兼容性测试 8
4.1平台测试 8
4.2浏览器测试 8
4.3分辨率测试 8
4.4 Modem/连接速率 9
4.5打印机 9
4.6组合测试 9
5安全测试 9
5.1目录设置 9
5.2登录 10
5.3日志文件 10
5.4脚本语言 10
6接口测试 10
6.1服务器接口 10
6.2外部接口 11
6.3错误处理 11
7结论 11
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术

⑹ WEB标准的标准测试

页面校验地址 http://validator.w3.org/
CSS文档校验 http://jigsaw.w3.org/css-validator/
XHTML 1.0 标准规格 : The Extensible HyperText Markup Language
W3C标准测试网址 http://validator.w3.org/
测试时一定要有文件类别宣告还有指定文件编码
<meta http-equiv=Content-Type content=text/html; charset=gb2312 />
才能顺利进行测试动作，开始打造一个标准的网站！ 1.XHTML 1.0文件类别宣告的正确写法 (不可小写)
过度标准（外语全称：Transitional）
公共标识符 称为：“-//W3C//DTD XHTML 1.0 Transitional//EN”。
<!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
>
框架标准（外语全称：Frameset）
公共标识符 称为：“-//W3C//DTD XHTML 1.0 Frameset//EN”。
<!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Frameset//EN
>
严格标准（外语全称：Strict） 包含以上须注意的问题,还有其他更严格的标准
公共标识符 称为：“-//W3C//DTD XHTML 1.0 Strict//EN”。
<!DOCTYPE html
PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
>
2.头文件问题
所有的网页头文件都一律都改为标准形式，写法如下： <head><metahttp-equiv=content-typecontent=text/html;charset=gb2312/><metahttp-equiv=content-languagecontent=zh-cn/><metaname=keywordscontent=.../><metaname=descriptioncontent=.../><title>...</title></head>3.不允许使用target=_blank
在HTML4.01可以使用target=_blank,但XHTML1.0是不被允许的.
我使用了一个HTML4.0的新属性：rel，这个属性用来说明链接和包含此链接页面的关系，以及链接打开的目标。
原来这样写的代码： 打开一个新窗口
现在要写成这样：打开一个新窗口
这是符合strict标准的方法。当然还必须配合一个javascript才有效。
javascript完整的代码JS如下： function外部链接()//万国码unicodejavascript{if(!document.getElementsByTagName)return;varanchors=document.getElementsByTagName(a);for(vari=0;i<anchors.length;i++){varanchor=anchors;if(anchor.getAttribute(href)&&anchor.getAttribute(rel)==external)anchor.target=_blank;}}window.onload=外部链接;你可以把它保存成一个.js文件(比如外部链接.js)，然后通过外部联接方法调用：
<script type=text/javascript src=外部链接.js></script>
4.XHTML 1.0要求所有的标签必须关闭
所有没有成对的空标签必须以 />结尾
和这就是成对
错误
<hr>
正确
<hr />
错误 <input type=text name=name>
正确 <input type=text name=name />
错误 <meta ...>
正确 <meta ... />
错误 <link rel=stylesheet type=text/css href=style.css>
正确 <link rel=stylesheet type=text/css href=style.css />
错误 <img src=bg.gif border=0 alt=说明文字>
正确 <img src=bg.gif border=0 alt=说明文字 />
5.所有标签元素名称都使用小写
错误 <HTML> <TITLE> <HEAD> <BODY>
正确 <html> <title> <head> <body>
错误 <IMG SRC=BG.GIF BORDER=0 ALT=说明文字>
正确 <img src=bg.gif border=0 alt=说明文字 />
错误 <UL><LI></LI></UL>
正确 <ul><li></li></ul>
以上只是举例,是所有标签元素名称都必须是小写
6.同一个id选择器不可重复使用
一个网页中id=xx同一个选择器不能重复使用,若需要重复请用class=xx
7.标签必须是一对
[font][/font]
8.正确的标签顺序
错误文字
正确文字
9.JavaScript写法
Javascript我们通常会写为
错误 <script language=javascript>
W3C标准必须为程式指定类型type=text/javascript,所以要写为
正确 <script type=text/javascript>
或者 <script language=javascript type=text/javascript>
载入外部.js独立档案的写法
正确 <script type=text/javascript src=script.js></script>
10.绝对不可省略双引号或单引号
错误 style=font-size:9pt
正确 style=font-size:9pt
错误 <img src=bg.gif width=140 height=30 alt=text />
正确 <img src=bg.gif width=140 height=30 alt=text />
错误 text
正确 text
11.图片标签加上文字说明alt=说明
错误 <img src=bg.gif height=50 border=0 />
正确 <img src=bg.gif height=50 border=0 alt=说明文字 />
12.背景音乐不允许使用 bgsound 标签
我只好用JavaScript解决这个问题。javascript完整的代码如下：
<!-- Begin
var MSIE=navigator.userAgent.indexOf(MSIE);
var NETS=navigator.userAgent.indexOf(Netscape);
var OPER=navigator.userAgent.indexOf(Opera);
if((MSIE>-1) || (OPER>-1)) {
document.write(<BGSOUND SRC=背景音乐地址 LOOP=INFINITE>);
} else {
document.write(<EMBED SRC=背景音乐地址 AUTOSTART=TRUE );
document.write(HIDDEN=true VOLUME=100 LOOP=TRUE>);
}
// end -->
你可以把它保存成一个.js文件(比如bjmusic.js)，然后通过外部联接方法调用：
<script type=text/javascript src=bjmusic.js></script>
13. 标签的争议
<embed>是Netscape的私有标签,W3C 从HTML3.2 HTML 4.01 到 XHTML 1.0 中都没有这个标签,所以使用的页面是不能通过标准测试。
W3C推荐使用 <object> 标签,用<object>插入flash影片的代码可以写为:
<object type=application/x-shockwave-flash data=index.swf width=400 height=200>
</object>
但这样的写法可能IE5/IE6 Win浏览器版本会出现问题。
标签因为广大的受到运用,不再标准范围引起很大的争议，想要解决这个问题，只能等IE浏览器对<object>有更好的支持或者W3C愿意收录标签。
14. 不允许使用框架标签<IFRAME>
这次又要用JavaScript解决问题了。javascript完整的代码如下：
function ifr(url,w,h){document.write('<iframe id=ifr name=ifr width='+w+' height='+h+' border=0 frameborder=0 scrolling=no src='+url+'></iframe>');}
把它保存成一个.js文件(比如ifr.js)，然后通过外部联接方法调用：
<script type=text/javascript src=ifr.js></script>
在你需要插入框架的地方写以下代码即可：
<script type=text/javascript>ifr('需插入的网页地址','567','485');</script>
函数ifr()使用说明：ifr('这里写地址','这里写宽度','这里写长度',)
15.google广告问题
google广告的代码是不符合W3C标准的，我只好又把它转成JS调用，但GOOGLE政策里是写着不允许修改代码的，
关于这点我正在写信给GOOGLE询问中，应该很快会有答案。
我的JS文件(google.js)代码如下：
document.writeln(<script type= ext/javascript><!--);
document.writeln(google_ad_client = pub-0538745384335317;);
document.writeln(google_ad_width = 125;);
document.writeln(google_ad_height = 125;);
document.writeln(google_ad_format = 125x125_as;);
document.writeln(google_ad_type = ext_image;);
document.writeln(//2007-06-29: www.ybj86.cn);
document.writeln(google_ad_channel = 4751988107;);
document.writeln(google_color_border = 1a1a1a;);
document.writeln(google_color_bg = 1a1a1a;);
document.writeln(google_color_link = d0eb6a;);
document.writeln(google_color_text = ffffff;);
document.writeln(google_color_url = 8ad459;);
document.writeln(google_ui_features = c:6;);
document.writeln(//-->);
document.writeln(</script>);
document.writeln(<script type= ext/javascript);
document.writeln( src=http://pagead2.googlesyndication.com/pagead/show_ads.js>);
document.writeln(</script>)
各位朋友可以按照自己的情况修改，网上也有把HTML代码转为JS代码的地方。
最后在需要挂广告的地方放入代码 <script type=text/javascript src=google.js></script>
其他需注意的地方：
16.注解文字不可包含--符号
错误 <!-- OEC--SPACE -->
正确 <!-- OECSPACE -->
17.正确使用CSS样式表
一定要放在<head></head>之间
<link rel=stylesheet type=text/css href=style.css />
<style type=text/css>
<!--
body{font-size:9pt;}
-->
</style>
错误 <style>
正确 <style type=text/css>
18.使用表格常犯的错误
我们在做表格通常会指定宽与高,例如: 内容 这样做是没有办法通过,W3C建议使用CSS来控制标签元素的高度
.table{
height:55px;
} TEXT 但是若使用太多表格,在CSS一一指定不同高,也不是好方法
其实很简单将高度height属性指定在储存格就可以了通过测试 TEXT 但这不是w3c希望的标准,建议能够使用div代替不必要的table
19.非标签一部分的符号以编码表示
表单内包含以下符号也必须用编码表示
< 以 &lt; 表示
> 以 &gt; 表示
& 以 &amp; 表示
程式中的连结 & 也要改用 &amp;
错误 <a href=foo.cgi?chapter=1&ion=2>
正确 <a href=foo.cgi?chapter=1&amp;ion=2>
20.所有属性都必须有值
XHTML1.0规定所有属性都必须有值,若没有就必须重复属性作为值
错误 <input type=radio value=v1 checked name=s1 />
正确 <input type=radio value=v1 checked=checked name=s1 />
错误 <option selected>S1</option>
正确 <option selected=selected>S1</option>
错误
正确

⑺ Web应用的测试内容都包括哪些方面

1、通用指标

指Web应用服务器、数据库服务器必需测试项，包括：处理器时间：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和。可用内存数：如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重。物理磁盘读写时间。

2、Web服务器指标

平均每秒响应次数为总请求时间与秒数之比。平均每秒业务脚本的迭代次数。成功的请求和失败的请求。成功的点击次数和失败的点击次数。每秒点击次数、每秒成功的点击次数和每秒失败的点击次数。尝试连接数。

3、数据库服务器指标

用户连接数，也就是数据库的连接数量。数据库死锁量。数据库缓存的命中情况。

(7)web测评图扩展阅读

对被测的Web应用程序进行需求分析，即对所做的测试作一个简要的介绍，包括描述测试的目标和范围，所测试的目标要实现一个什么样的功能，总结基本文档、主要活动。

写出测试策略和方法，这里包括测试开始的条件、测试的类型、测试开始的标准以及所测试的功能、测试通过或失败的标准、结束测试的条件、测试过程中遇到什么样的情况终止和怎么处理后恢复等。

一个Web应用程序由完成特定任务的各种Web组件（web components)构成的并通过Web将服务展示给外界。在实际应用中，Web应用程序由多个Servlet、JSP页面、HTML文件以及图像文件等组成。所有这些组件相互协调为用户提供一组完整的服务。

⑻ 如何进行WEB安全性测试

安全性测试
产品满足需求提及的安全能力
n 应用程序级别的安全性，包括对数据或业务功能的访问，应
用程序级别的安全性可确保：在预期的安全性情况下，主角
只能访问特定的功能或用例，或者只能访问有限的数据。例
如，可能会允许所有人输入数据，创建新账户，但只有管理
员才能删除这些数据或账户。如果具有数据级别的安全性，
测试就可确保“用户类型一” 能够看到所有客户消息（包括
财务数据），而“用户二”只能看见同一客户的统计数据。
n 系统级别的安全性，包括对系统的登录或远程访问。
系统级别的安全性可确保只有具备系统访问权限的用户才能
访问应用程序，而且只能通过相应的网关来访问。
安全性测试应用
防SQL漏洞扫描
– Appscan
n防XSS、防钓鱼
– RatProxy、Taint、Netsparker
nget、post -> 防止关键信息显式提交
– get：显式提交
– post：隐式提交
ncookie、session
– Cookie欺骗

⑼ web测试用例设计从哪些方面入手

常用的测试用例方法:
等价类：有效等价类和无效等价类。
边界值：[1,10]正整数范围为（0,1,2, 9,10,11），浮点数的话为最接近的范围点。
因果图：根据条件组合生成判定表。
正交实验设计方法：抽取有代表性的元素数据来进行测试。
错误推测法：容易发生错误的地方进行有针对性地测试。
随机测试：像一个普通用户随意地点击操作去进行测试。
需求转化法：通过正常操作、异常操作、特殊规约、用户提示、数据一致性等要点转化需求为成高粒度测试点。
对象属性分析法：文件属性：大小、路径、文件名、文件编码、文件内容、文件内容、
文件读写、文件共享。
全路径覆盖： 通过对每个业务数据流每个路径进行测试。
场景法： 场景通常包括 正常场景、异常场景、备选场景、组合场景。

⑽ 如何进行Web服务的性能测试

贴一篇我们内部的文章：
随着浏览器功能的不断完善，用户量不断的攀升，涉及到web服务的功能在不断的增加，对于我们测试来说，我们不仅要保证服务端功能的正确性，也要验证服务端程序的性能是否符合要求。那么性能测试都要做些什么呢？我们该怎样进行性能测试呢？
性能测试一般会围绕以下这些问题而进行：
1. 什么情况下需要做性能测试？
2. 什么时候做性能测试？
3. 做性能测试需要准备哪些内容？
4. 什么样的性能指标是符合要求的？
5. 性能测试需要收集的数据有哪些？
6. 怎样收集这些数据？
7. 如何分析收集到的数据？
8. 如何给出性能测试报告？
性能测试的执行过程及要做的事儿主要包含以下内容：
1. 测试评估阶段
在这个阶段，我们要评估被测的产品是否要进行性能测试，并且对目前的服务器环境进行粗估，服务的性能是否满足条件。
首先要明确只要涉及到准备上线的服务端产品，就需要进行性能测试。其次如果产品需求中明确提到了性能指标，那也必须要做性能测试。
测试人员在进行性能测试前，需要根据当前的收集到的各种信息，预先做性能的评估，收集的内容主要包括带宽、请求包大小、并发用户数和当前web服务的带宽等
2. 测试准备阶段
在这个阶段，我们要了解以下内容：
a. 服务器的架构是什么样的，例如：web服务器是什么？是如何配置的？数据库用的是什么？服务用的是什么语言编写的？；
b. 服务端功能的内部逻辑实现；
c. 服务端与数据库是如何交互的，例如：数据库的表结构是什么样的？服务端功能是怎样操作数据库的？
d. 服务端与客户端之间是如何进行交互的，即接口定义；
通过收集以上信息，测试人员整理出服务器端各模块之间的交互图，客户端与服务端之间的交互图以及服务端内部功能逻辑实现的流程图。
e. 该服务上线后的用户量预估是多少，如果无法评估出用户量，那么可以通过设计测试执行的场景得出这个值；
f. 上线要部署到多少台机器上，每台机器的负载均衡是如何设计的，每台机器的配置什么样的，网络环境是什么样的。
g. 了解测试环境与线上环境的不同，例如网络环境、硬件配置等
h. 制定测试执行的策略，是需要验证需求中的指标能否达到，还是评估系统的最大处理能力。
i. 沟通上线的指标
通过收集以上信息，确定性能测试用例该如何设计，如何设计性能测试用例执行的场景，以及上线指标的评估。
3. 测试设计阶段
根据测试人员通过之前整理的交互图和流程图，设计相应的性能测试用例。性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数量测试，网络性能测试，服务器性能测试，具体编写的测试用例要更具实际情况进行裁减。
用例编写的步骤大致分为：
a. 通过脚本模拟单一用户是如何使用这个web服务的。这里模拟的可以是用户使用web服务的某一个动作或某几个动作，某一个功能或几个功能，也可以是使用web服务的整个过程。
b. 根据客户端的实际情况和服务器端的策略，通过将脚本中可变的数据进行参数化，来模拟多个用户的操作。
c. 验证参数化后脚本功能的正确性。
d. 添加检查点
e. 设计脚本执行的策略，如每个功能的执行次数，各个功能的执行顺序等
4. 测试执行阶段
根据客户端的产品行为设计web服务的测试执行场景及测试执行的过程，即测试执行期间发生的事儿。通过监控程序收集web服务的性能数据和web服务所在系统的性能数据。
在测试执行过程中，还要不断的关注以下内容：
a. web服务的连接速度如何？
b. 每秒的点击数如何？
c. Web服务能允许多少个用户同时在线？
d. 如果超过了这个数量，会出现什么现象？
e. Web服务能否处理大量用户对同一个页面的请求？
f. 如果web服务崩溃，是否会自动恢复？
g. 系统能否同一时间响应大量用户的请求？
h. 打压机的系统负载状态。
5. 测试分析阶段
将收集到的数据制成图表，查看各指标的性能变化曲线，结合之前确定的上线指标，对各项数据进行分析，已确定是否继续对web服务进行测试，结果是否达到了期望值。
6. 测试验证阶段
在开发针对发现的性能问题进行修复后，要再执行性能测试的用例对问题进行验证。这里需要关注的是开发在解决问题的同时可能无意中修改了某些功能，所以在验证性能的同时，也要关注原有功能是否受到了影响。

想看原文或者有测试其他相关的问题可以关注下 搜狗测试 微信公众号，我们上面有不少关于性能测试分享~