BS系统测试简介
bs架构文档 (2)
B/S架构测试就是WEB网站测试,主要有功能测试,性能测试,兼容性性测试另外还有一些根据情况来定,我说的是主要的,在功能方面测试的主要是链接测试,表单测试,COOKING测试,设计语言测试,还有数据库方面的测试,有没有业务方面的测试要根据情况来定了;在性能方面测试主要关注的是连接速度测试,负载测试,压力测试,连接速度测试就是测试网站的响应时间;负载测试就是在有大用户量同时在测试的网站上长期的操作,查看网站是否能正常运行,资源利用率是不是有很高;压力测试就是用户以一定数量对网站进行访问时,查看网站的运行情况,服务器(WEB服务器和数据库服务器)的运行情况,性能测试我主要的用的工具Loadrunner.在接口方面的测试主要测试的是系统是否兼容,浏览器的兼容性,还有分辨率和一些外围设备的兼容(如:打印机) 其他测试自己依情况来定了摘要：软件测试是确保软件质量的重要手段。
对于不同的软件系统，其测试手段和方法也不尽相同，基于Ｂ/Ｓ结构的软件系统是当前应用比较广泛的应用系统，对这类型的软件系统测试与传统的软件系统测试既有区别又有联系，也对软件测试提出了新的挑战。
从功能、性能、可用性、客户端兼容性、安全性等方面系统地讨论了基于Ｂ/Ｓ结构的软件系统测试方法，及其与传统软件测试的异同。
关键词：Ｂ/Ｓ结构；系统测试；性能测试；功能测试中图分类号：TP311.5 文献标识码：Ａ当今随着网络技术的不断发展，Ｉｎｔｅｒｎｅｔ在各个领域的广泛引用，越来越多的人开始关注应用于网络中的软件系统的质量。
要确保软件的质量，一方面在于软件设计是否合理和软件的编码过程是否认真准确，另一方面要看后期软件的系统测试是否全面，是否充分。
尤其是应用于网络中的软件系统，很多缺陷是在平时编码过程中很难找到的，必须通过系统的全面的测试才能发现。
由此可见，软件测试为确保软件产品的高质量，起到了举足轻重的作用。
另外对于不同环境下运行的软件其测试方法也有所不同，本文主要是对基于Ｂ/Ｓ结构下的软件系统测试的方法进行论述。
BS架构体系安全渗透测试基础
BS架构体系安全渗透测试基础首先，BS架构体系安全渗透测试需要对系统进行全面的漏洞扫描和安全评估。
系统可能存在的漏洞包括SQL注入、跨站脚本攻击（XSS）、跨站请求伪造（CSRF）等。
通过安全渗透测试，可以发现这些潜在的安全隐患，并提供相应的安全加固建议。
其次，BS架构体系安全渗透测试需要对系统的身份认证和授权机制进行测试。
这包括对用户登录、权限验证等功能的安全性评估。
通过模拟黑客攻击、测试密码强度等手段，可以验证系统的身份认证和授权机制的安全性，发现可能存在的漏洞和弱点。
此外，BS架构体系安全渗透测试还需要对系统的数据加密和传输安全性进行测试。
这包括对数据传输过程中可能存在的数据泄露、窃取等安全隐患进行评估。
通过对系统的加密算法、SSL证书等进行检查，可以帮助发现系统在数据传输过程中的安全弱点。
最后，BS架构体系安全渗透测试需要对系统的安全日志和监控功能进行测试。
这包括对系统的异常行为检测、安全事件响应等功能进行评估。
通过模拟恶意攻击、测试系统的异常响应能力等手段，可以验证系统的安全日志和监控功能的有效性，发现可能存在的安全隐患。
总之，BS架构体系安全渗透测试是保障系统安全的重要环节。
通过对系统的漏洞扫描、身份认证和授权测试、数据加密和传输测试、安全日志和监控测试等方面的综合评估，可以发现系统的安全隐患，并提供相应的安全加固建议，从而保障系统的安全稳定运行。
BS架构体系安全渗透测试是一项综合而复杂的任务，需要全面的技术知识和丰富的实战经验。
在进行安全渗透测试时，渗透测试人员需要具备深入理解网络安全、数据库安全、Web安全、应用程序安全、操作系统安全等领域的知识，同时还需要了解黑客攻击的常见手段和方式，从而能够更有效地进行安全渗透测试和风险评估。
在进行BS架构体系安全渗透测试时，首先需要对目标系统进行全面的信息搜集。
这包括对目标网站、服务器、数据库、操作系统等各个方面的信息进行收集，包括IP地址、域名信息、Web应用程序相关信息、开放端口、系统架构等。
BS测试相关内容
【B/S三层结构：界面层测试＋中间层测试＋数据层测试】界面层测试(客户端测试)：1、功能测试【基础】⑴按照软件规格说明书中对用户界面上每一个组成部分进行单个基本功能测试，包括它们的状态、默认值等⑵按软件的规格说明书中对软件各商业功能的描述进行测试。
这一测试需要通过一系列操作才能完成⑶应侧重于所有可直接追踪到业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当ⅰ、表单测试【主要测客户端脚本】测试表单的要点，从以下三个方面测试：1、表单操作是否能正常进行(重填、提交、保存)2、表单提交信息是否完整、正确3、表单上控件的测试注意的其他问题：1、确保表单操作不丢失或增加数据精度(根据web应用系统要求)2、对表单输入进行边界值检查3、使用Tab键确保字段按正确的顺序移动4、对表单中必填项目应有显著标记5、确保表单对关联的字段进行合法性检查，如城市和省份对应6、测试脚本、外加控件对表单操作的影响7、对格式填写要求严格的栏目需要给出填写样例8、表单内容提交后是否真正提到数据库中，要再次查询一下(最好到数据库端确认)ⅱ、链接测试1、所有链接是否按指示链接到该链接页面2、所有链接的页面是否存在3、保证Web应用系统上没有孤立的页面【死链、错链、孤立页面】【可适当借助于工具测试->Xenu：主要测有无死链】可能出现的问题：1、单击链接无反应2、未链接到正确页面3、链接页面不存在(自定义错误提示信息页面)(系统提示信息页面)4、有孤立页面存在【前提：不是管理员特定的管理页面】链接测试要点：1、注意链接本身应言简意赅，具有可读性2、定期检查外部链接3、设计友好的提示信息页面，告之用户请求页面不存在4、通过脚本语言、Applet(富客户端)等技术实现链接的正确性5、对动态链接的测试(使用同一种技术生成，故测一个链接没问题即可)ⅲ、设计语言测试测试要点：1、HTML标准差异Html4.0Html4.012、Applet、JavaScript、VBScript、ActiveX等当JDK1.4的少量方法被使用，而安装JDK1.3的JVM时，部分功能无法使用ⅳ、Cookie测试1、Cookie预设作用时间缺陷Response.Cookies("Password").Expires="July 31,2000"2、cookie加密否3、禁用Cookie影响尝试各种cookie级别设置时Web系统能否正常访问或能否正常实现各种功能如购物车，比如说当禁用cookie等级为“高”时，看能否进入各个页面或能否结帐【一个做的比较完善的系统应该采用两种技术，正常情况下用cookie技术实现各页面之间共享数据，但假如客户端禁用cookie时，网站应考虑到这种情况(当然要根据具体情况而定)，看是否要结合使用URL重写技术，实现各页面之间数据共享】【补充】Cookie:不是一项单独技术，应用于浏览器中，目的就是加快用户上网速度，简化上网过程；只是文本。
BS架构测试方法
BS架构测试方法BS架构，即浏览器-服务器架构，是一种常用的软件架构模式，其中客户端的浏览器通过网络与服务器交互，从服务器获得所需的数据和功能。
BS架构具有灵活性、安全性和跨平台等优点，已经成为现代软件开发的主流架构之一在BS架构下，测试是确保系统稳定性和质量的重要环节。
下面介绍几种常用的BS架构测试方法。
首先，功能测试是最基本和常见的测试方法之一、在BS架构下，系统的核心功能多数由服务器提供。
因此，需要测试服务器的各项功能是否正常运行。
功能测试可以分为单元测试和集成测试。
单元测试是对服务器功能的逐个单独测试，而集成测试则是对功能之间的协作测试。
其次，性能测试也是BS架构测试的重要组成部分。
性能测试旨在评估系统在不同负载和用户访问量下的性能表现。
在进行性能测试时，可以使用负载测试工具模拟多用户同时访问系统，以测试系统在高负载情况下的响应时间、吞吐量和并发能力等指标。
此外，安全测试也是BS架构测试不可或缺的一环。
由于BS架构中客户端与服务器之间通过网络通信，因此系统的安全性尤为重要。
安全测试可以包括网络扫描、漏洞扫描、黑盒测试和白盒测试等。
网络扫描用于检测系统中存在的漏洞和弱点，而漏洞扫描则是针对已知的安全漏洞进行测试。
黑盒测试是在没有系统源代码和内部信息的情况下，模拟攻击者行为进行测试，而白盒测试则是在了解系统内部结构和源代码的基础上进行测试。
此外，兼容性测试也是BS架构测试的重要环节。
由于浏览器存在不同的版本和不同的操作系统，系统需要在不同的环境下保持一致的功能和用户体验。
兼容性测试旨在确保系统在不同浏览器和操作系统下的兼容性。
测试人员可以使用不同的浏览器和操作系统进行测试，并检查系统在各种环境下的兼容性是否正常。
最后，可靠性测试也是BS架构测试的一项重要任务。
可靠性测试旨在评估系统在长时间运行和高负载情况下的稳定性和可靠性。
测试人员可以通过模拟用户的实际使用行为和访问模式，并观察系统是否能够稳定运行和及时响应。
BS性能测试规范
BS性能测试规范1. 引言性能测试是软件开发中的一个重要环节，它可以评估系统在负载情况下的响应速度、吞吐量、稳定性等性能指标。
对于基于浏览器和服务器的应用程序（BS应用程序），性能测试是至关重要的，因为这类应用程序通常需要处理大量的并发请求。
本文档旨在定义BS性能测试的规范，以确保测试的准确性和可重复性。
在进行性能测试前，请确保已经了解了基本的性能测试概念和方法。
2. 测试环境准备在进行性能测试前，需要准备符合实际生产环境的测试环境，包括服务器、网络、数据库等。
以下是一些测试环境准备的注意事项：•服务器：使用与生产环境相似的硬件配置和操作系统版本进行测试。
•网络：应保证测试网络的稳定性和可靠性，避免因网络故障而影响测试结果。
•数据库：测试前应确保数据库中已经存在足够的数据，以模拟真实的负载情况。
•监控工具：可以使用性能监控工具来监测系统的性能指标，如CPU利用率、内存占用、网络吞吐量等。
3. 性能测试指标性能测试需要关注以下指标来评估BS应用程序的性能：•响应时间：系统对用户请求的响应时间，通常使用平均响应时间来评估。
•吞吐量：系统在单位时间内处理的请求数量，通常使用每秒事务数（Transactions Per Second，TPS）来评估。
•并发用户数：系统能够同时处理的并发用户数量。
•错误率：系统在负载情况下产生的错误请求比例。
在进行性能测试时，应根据具体的应用场景和业务需求选择适当的性能指标进行评估。
4. 测试场景设计测试场景是性能测试的核心内容之一，需要根据实际的使用情况和业务流程来设计。
以下是一些测试场景设计的建议：•正常场景：模拟正常的用户行为，测试应用程序在正常负载下的性能表现。
•峰值场景：加大负载，测试应用程序在峰值负载下的性能表现。
•异常场景：模拟异常情况，如网络中断、服务器故障等，测试应用程序的容错能力和恢复能力。
测试场景应具有可重复性，以便进行多次测试，比较性能指标的变化。
BS系统测试(数据库性能指标)
这个等待事件的时间过长，可能是因为commit太频繁或者lgwr进程一次写日志的时间太长（可能是因为一次log io size太大），可调整_log_io_size，结合log_buffer,使得(_log_io_size*db_block_size)*n = log_buffer，这样可避免和增大log_buffer引起冲突，或者可以将日志文件存放在高速磁盘上
该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。
如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。
%
内存排序率
(In-memory Sort %)
指排序操作在内存中进行的比率。当查询需要排序的时候，数据库会话首先选择在内存中进行排序，当内存大小不足的时候，将使用临时表空间进行磁盘排序，但磁盘排序效率和内存排序效率相差好几个数量级。
该指标的值应接近100%，如果指标的值较低，则表示出现了大量排序时的磁盘I/O操作，可考虑加大sort_area_size参数的值。
厘秒
(enqueue(cs))
enqueue是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle的latch机制不是FIFO。Enqueue等待通常指的是ST enqueue、HW enqueue、TX4 enqueue和TM enqueue。
BS测试与CS测试之区别
C/S系统的测试方法
• • • • • • • • • • • • • • • • C/S（Client/Server）可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server 端来实现，降低了系统的通讯开销。这种结构与B/S最显著的区别是需要安装客户端，通过客 户端程序来访问应用系统，因此C/S客户端测试是重点，并且与B/S结构有所不同。 C/S客户端测试的重点有： （1）客户端安装测试 安装的自动化程度 安装选项和设置得测试 安装过程的中断测试 多环境安装测试 安装的正确性测试 修复安装测试 卸载安装测试 （2）客户端升级测试 与变更相关的测试 变更内容的测试 与变更相关的测试 （3）客户端功能测试 基本功能测试
B/S系统的测试方法
• 表单测试 • 当用户给Web应用系统管理员提交信息时， 就需要使用表单操作，例如用户注册、登陆、 信息提交等。在这种情况下，我们必须测试提 交操作的完整性，以校验提交给服务器的信息 的正确性。例如：用户填写的出生日期与职业 是否恰当，填写的所属省份与所在城市是否匹 配等。如果使用了默认值，还要检验默认值的 正确性。如果表单只能接受指定的某些值，则 也要进行测试。例如：只能接受某些字符，测 试时可以跳过这些字符，看系统是否会报错。
C/S模式分析—优点
C/S 模式的优点 ● 由于客户端实现与服务器的直接相连，没 有中间环节，因此响应速度快。 ● 操作界面漂亮、形式多样，可以充分满足 客户自身的个性化要求。 ● C/S结构的管理信息系统具有较强的事务处 理能力，能实现复杂的业务流程。
C/S模式分析—缺点
C/S模式的缺点 ● 需要专门的客户端安装程序，分布功能弱， 针对点多面广且不具备网络条件的用户群体， 不能够实现快速部署安装和配置。 ● 兼容性差，对于不同的开发工具，具有较 大的局限性。若采用不同工具，需要重新改 写程序。 ● 开发成本较高，需要具有一定专业水准的 技术人员才能完成。
软件测试方法——BS的测试
软件测试方法:功能测试软件测试方法:功能测试功能测试工具链接测试链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。
链接测试可分为三个方面。
首先，测试所有链接是否按指示的那样确实链接到了该链接的页面;其次，测试所链接的页面是否存在;最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。
链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。
采取措施：采用自动检测网站链接的软件来进行。
推荐软件：Xenu Link Sleuth 免费绿色免安装软件HTML Link V alidator 共享(30天试用)表单测试当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。
如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。
要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。
当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。
例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。
如果使用了默认值，还要检验默认值的正确性。
如果表单只能接受指定的某些值，则也要进行测试。
例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。
数据校验如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。
例如，省份的字段可以用一个有效列表进行校验。
在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
先列举一下性能指标：
1、通用指标（指Web应用服务器、数据库服务器必需测试项）: * ProcessorTime: 指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重； * Physicsdisk Time : 物理磁盘读写时间情况；
2、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 ：尝试链接数；
3、数据库服务器指标： * User 0 Connections ：用户连接数，也就是数据库的连接数量； * Number of deadlocks：数据库死锁； * Butter Cache hit ：数据库Cache的命中情况；上面的指标只是一些通用的指标,起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。
对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。
对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。
对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持）的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧，呵呵。
在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阈值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阈值的与一些通
用参数有问题的子系统进行深入分析。
比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。
这个我们要对子系统进行详细测试，由于B/S 结构下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等；二、应用程序本身。
通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。
对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。
最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行测试，这样才有更高的可信度。
上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。
下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种，一、性能达不到目标；二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；三、服务器稳定性的问题，比如内存泄漏……。
要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET 下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的Purify与Quantify,主要是他对.net 与
java ,C++都有支持，而且分析效果特别专业，我们先了解一下 Rational Purify, Rational Purify 能自动找出Visual C/C++ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。
在查找典型的Visual C/C++ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。
我们先说性能优化与异常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时
间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。
在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。
但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大，比如什么，SqlCmd.ExecuteNoQuery等等数据库执行函数,这时你就需要分析数据库，呵呵。
数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。
在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。
同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要Precise，它可以观测某一个较长时间内的SQL语句的执行情况。
数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。
内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C++ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。
C++的内存错误就比较多了，主要常见的有: 1、 Array Bounds Read (ABR) ：数组越界读 2、 Array Bounds Write (ABW)：数组越界写 3、 Beyond stack Read (BSR)：堆栈越界读
4、 Free Memory Read(FMR)：空闲内存读
5、Invalid pointer Read(IPR)：非法指针阅读
6、Null Pointer Read(NPR)：空指针阅读
7、 Uninitialized Memory Read(UMR)：未初始化内存读写
8、 Memory Leak：内存泄漏 Loadrunner无疑是一个强大有力的压力测试工具。
它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。
一般压力测试步骤： 1、分析并抽取系统的典型业务 2、录制脚本，设置相关参数，例如：加压顺序、加压方法等； 3、设置监控参数，如果是服务器，则选择监控服务器端的指标； 4、运行脚本，收集图表 5、多运行几次，最后汇总各次测试结果； 6、分析结果，找出系统瓶颈 7、出台调优方案，确=决定是硬件问题还是软件问题。