Web性能测试案例分析

一、架构设计阶段的性能测试

案例重点关注如下三个方面：

如何根据项目需要来设计与开发测试程序。

测试工具在性能测试中的作用与地位。


针对数据库本神进行性能测试的地位。
二、项目背景

三、性能测试策略、目标、范围、环境

四、性能测试分析与设计

(1)系统架构组对数据库提测试出了如下要求：
测试数据库对复杂SQL语句的支持，尤其是一些长SQL语句的支持。
测试数据库对二进制等格式类型存储的支持。

测试系统在数据量较大时的多用户并发查询的响应时间--查询响应时间为Web服务器对数据库响应时间，不包含应用系统响应时间。

(2)根据上面的测试要求的分析，设计出如下性能测试方案：

测试体系采用B/S架构方式，对数据库的查询操作封存在Servlet中，Servlet运行于tomcat5.0上，前端采用JSP页面调用Servlet并输出执行结果(数据库执行查询的时间)和查询结果(数据库返回的查询结果)。

利用原型系统后台数据库的数据作为测试数据，保证测试结果更加真实。

测试采用的查询语句用原型系统的业务语句，保证测试兼顾实际应用。


通过测试工具LoadRunner来创建虚拟用户，实现用户并发查询。.
通过测试结果来综合分析各家数据库的性能。

五、性能测试实施

测试脚本的开发与修改

数据库系统调优前的测试
数据库系统调优后的测试
六、测试结果分析TestAge
各家国产数据库调优前的测试结果及分析


数据库调优策略TestAge
各家国产数据库调优后的测试结果及分析
稳定性测试场景分析
测试结果TestAge
七、案例点评

体现了模型剪裁与具体化原则

节约了一定的开发成本TestAge
仅仅有测试工具是不够的：很多人认为有了性能测试工具，就可以完成性能测试任务，根本不需要自己去开发脚本。实际上，性能测试最重要的是设计与规划，如何去执行测试用例，则是相对容易的事情。执行测试用例主要通过测试工具，但有时还要靠自己开发的脚本来辅助测试，案例中的测试项目就是很好的证明。
调优不能解决一切问题：性能测试的基本思路“测试--发现问题--调优--再测试”的反复过程。因此，解决性能问题应该从设计阶段着手。
转自：http://www.cnblogs.com/junzhongxu/

白盒测试工具大全

白盒工具--NuMega DevPartner Studio
　　这是一组白盒测试工具，主要是用于代码开发阶段，检查应用的可靠性和稳定性。它提供了先进的错误检查和调试解决方案，充分地改善生产力和开发团队的软件开发质量。NuMega产品线是一个全面的SmartDebugging工具包，自动地检查企业级或Internet级用多语言创建的组件和应用中出现的软件错误和性能问题，并能很快地给予解决。

　　NuMega DecPartner Studio满足在软件开发过程中每一个开发人员的需求，无论我们是使用一种或多种语言，NuMega产品都能够帮助我们提高生产力。它的产品主要有自动地错误检测、性能分析、代码覆盖分析等功能，分别用于捕获、定位错误，抽取代码执行频度，以及抽取代码覆盖率等数据，产品包括：
　　程序员在开发过程中可能会经常遇到这样的问题：调试时语法没有问题，代码也没有错误，但应用程序运行就是不正常甚至死机，其实这有可能是由于逻辑错误引起的内存溢出或资源泄露等问题，这些错误一般是不容易被检测出来的。而这类错误就是BoundsChecker错误检测范围之一。
通过对被测应用程序的操作，BoundsChecker提供清晰的、详细的程序错误分析，自动查明静态的堆栈错误及内存/资源泄露，并能够迅速的定位出错的源代码，即使在没有源代码的情况下也可检查第三方组件的错误。
　　BoundsChecker错误检测范围主要包括：
1)．指针和泄露错误
　　接口泄露
内存泄露
　　资源泄露
　未分配的指针错误
2)．内存错误
动态存储溢出

无效的句柄被锁定
句柄没有被锁定
内存分配冲突
栈空间溢出
静态存储溢出
API和OLE错误
API函数返回失败
API函数未执行
无效的变量（包括指针变量、字符串变量等）
OLE接口方法的变量无效
OLE接口方法失败
线程调用库函数错误
BoundsChecker支持的语言和主机平台:
C++, Delphi
Windows NT, Windows95/98
　　在开发过程中，对一个应用程序通过手工测试，总会有一部分代码功能没有被检测到，或者说逐个检测每一个函数的调用是相当费时间的；未被检测的代码我们不能保证它的可靠性，以后程序的失败可能往往就是由这部分未检测的代码造成的。现在我们可以用TrueCoverage来帮助我们解决这些问题，我们在测试程序时，每完成一次应用话路，TrueCoverage就能够列出在这次对话中所有函数被调用次数、所占比率等，并可以直接定位到源代码，当然我们也可以合并多个应用话路来进行检测。所以说TrueCoverage能通过衡量和跟踪代码执行及代码稳定性，帮助开发团队节省时间和改善代码可靠性。
TrueCoverage支持的语言和主机平台
C++, JAVA, Visual Basic
Windows NT, Windows95/98
3. TrueTime
代码运行缓慢是开发过程中一个重要问题。一个应用程序运行速度较慢，程序员不容易找到到底是在哪里出现了问题，如果不能解决应用程序的性能将降低并极大的影响应用程序的质量，于是查找和修改性能瓶颈是调整整个代码性能的关键。如何快速的查找性能瓶颈呢？TrueTime的出现就使这个问题变得很容易了。当我们在测试程序时，每完成一次应用话路，TrueTime都能提供这次对话中函数的调用时间，提供详细的应用程序和组件性能的分析，并自动定位到运行缓慢的代码。这样就能帮助程序员尽快地调整应用程序的性能。
TrueTime支持的语言和主机平台
C++, JAVA, Visual Basic
Windows NT, Windows95/98

SmartCheck
作为一名Visual Basic的开发人员，在开发的过程中经常会遇到许多问题难以解决，包括象隐藏的run-time错误、Windows API函数在Visual Basic中正确使用的问题、一些组件的错误等等，它们很难被定位到具体的代码中，令开发人员花费大量时间去寻找并解决。SmartCheck就是能很快地查找到这些问题的一个自动化的工具，它是对于Visual Basic来说最好的run-time调试工具，它检测所有的Windows API函数调用、内存分配以及其它一些重要的程序错误。SmartCheck检错的种类包括泄露、接口方法失败、存储错误、程序和函数失败和Visual Basic的Runtime错误等，它能够将检测到的错误快速地定位到源代码。使用SmartCheck将会极大地提高VB开发人员的工作效率。
SmartCheck 支持的语言和主机平台:TestAge
Visual Basic
Windows NT, Windows95/98
FailSafe是用于Visual Basic开发的一个自动错误处理和恢复系统。VB开发人员经常能够遇到程序执行时意外地终止，但是对于为什麽出现错误只提供了简短的、模糊的出错信息，使开发人员不能方便地发现错误的根源。如果使用了FailSafe，它将插入额外的代码对你的程序进行插装，当程序执行时，FailSafe通过这些插装的代码捕获、记录执行时程序和系统的重要信息，直接指出错误发生时程序和系统的状态，这些丰富的信息使开发人员能够快速且正确的解决问题。
FailSafe 支持的语言和主机平台:
Visual Basic
Windows NT, Windows95/
对于Visual Basic开发人员来说，CodeReview是最好的自动源代码分析工具，它对应用程序的组件、逻辑、Windows和Vb自身潜在的数百个问题进行严格地源代码检查。CodeReview分析的类型包括Y2K问题，逻辑错误，应用程序性能和可用性问题，Windows API调用和标准一致性问题等。CodeReview可以检测整个的VB工程或指定的模块，并能定制检错的种类；对检测的结果有详细的说明，提供帮助和推荐解决方案，而且能够直接的链接到源代码。
CodeReview系统还提供了两个子模块，一个是Metrics：通过对VB工程（vbp）的执行，计算出代码的长度、复杂度、理解度、语言的使用等级、出错的可能性等数据；另一个是Namer：它调用一个VB工程，自动并规则地对其中的对象重新命名，并备份原来没有规则命名的工程文件，使开发人员对程序能够有条理地管理。
可以这麽说：CodeReview是Visual Basic开发人员必不可少的顾问。
CodeReview 支持的语言和主机平台:
Visual Basic
Windows NT, Windows95/98

JCheck对于Java开发人员来说是一个功能强大的图形化的线程和事件分析工具，它提供了一个生动的图形化的方法来表现程序的线程的状态信息以及和Windows线程、同步对象、线程组等的交互作用信息，使开发人员能够直观地分析Java Applet或Application：通过这些形象化的图形显示，可以确定runtime错误，对执行和逻辑错误进行分析，立刻发现线程问题如死锁、活锁、资源缺乏和系统失败，诊断线程同步和时间选择问题，分析程序执行流程；而后JCheck对于那些错误可以定位和显示详细的信息并能定位到源代码。Jcheck极大地减少了程序的调试时间，改善了软件开发生产力。TestAge 中国软件测试时代WB"j#Hd
　　JCheck 支持的语言和主机平台：
Microsoft Visual J++
Windows NT, Windows95/98
转自：http://www.cnblogs.com/junzhongxu/

谈:面向对象的软件测试与传统测试的比较[3]

关键字：软件测试与传统测试类是否实现了要求的功能
　　5、 面向对象的单元测试
　　传统的单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。
　当考虑面向对象软件时，单元的概念发生了变化。封装驱动了类和对象的定义，这意味着每个类和类的实例(对象)包装了属性(数据)和操纵这些数据的操作。而不是个体的模块。最小的可测试单位是封装的类或对象，类包含一组不同的操作，并且某特殊操作可能作为一组不同类的一部分存在，因此，单元测试的意义发生了较大变化。我们不再孤立地测试单个操作，而是将操作作为类的一部分。
　　6、 面向对象的集成测试
　　传统的集成测试，有两种方式通过集成完成的功能模块进行测。（一）自顶向下集成：自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。（二）自底向上集成：自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试。
　　因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没有意义，此外，一次集成一个操作到类中(传统的增量集成方法)经常是不可能的，这是由于“构成类的成分的直接和间接的交互”。对OO软件的集成测试有两种不同策略，第一种称为基于线程的测试，集成对回应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。第二种称为基于使用的测试，通过测试那些几乎不使用服务器类的类(称为独立类)而开始构造系统，在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试。这个依赖类层次的测试序列一直持续到构造完整个系统。
　　7、 面向对象的系统测试

　　通过单元测试和集成测试，仅能保证软件开发的功能得以实现。但不能确认在实际运行时，它是否满足用户的需要。为此，对完成开发的软件必须经过规范的系统测试。系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件，也应有相应的模拟手段。系统测试时，应该参考OOA分析的结果，对应描述的对象、属性和各种服务，检测软件是否能够完全"再现"问题空间。系统测试不仅是检测软件的整体行为表现，从另一个侧面看，也是对软件开发设计的再确认。

　　面向对象测试的整体目标——以最小的工作量发现最多的错误——和传统软件测试的目标是一致的，但是OO测试的策略和战术有很大不同。测试的视角扩大到包括复审分析和设计模型，此外，测试的焦点从过程构件(模块)移向了类。
软件测试与传统测试不论是传统的测试方法还是面向对象的测试方法，我们都应该遵循下列的原则：

　　1.应当把“尽早和不断地测试”作为开发者的座右铭。

　　2.程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。

　　3.设计测试用例时，应该考虑到合法的输入和不合法的输入，以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。

　　4.一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。

　　5.对测试错误结果一定要有一个确认的过程。一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。
　　6.制定严格的测试计划，并把测试时间安排得尽量宽松，不要希望在极短的时间内完成一个高水平的测试。


　　7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见。

　　8.妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。
转自：http://www.cnblogs.com/junzhongxu/

谈:面向对象的软件测试与传统测试的比较[2]

关键字：软件测试与传统测试对认定的对象的测试

对认定的结构的测试
　　对认定的主题的测试
　　对定义的属性和实例关联的测试
对定义的服务和消息关联的测试
　　3、 面向对象设计的测试
　　通常的结构化的设计方法，用的"是面向作业的设计方法，它把系统分解以后，提出一组作业，这些作业是以过程实现系统的基础构造，把问题域的分析转化为求解域的设计，分析的结果是设计阶段的输入"。而面向对象设计（OOD）采用"造型的观点"，以OOA为基础归纳出类，并建立类结构或进一步构造成类库，实现分析结果对问题空间的抽象。由此可见，OOD不是在OOA上的另一思维方式的大动干戈，而是OOA的进一步细化和更高层的抽象。所以，OOD与OOA 的界限通常是难以严格区分的。OOD确定类和类结构不仅是满足当前需求分析的要求，更重要的是通过重新组合或加以适当的补充，能方便实现功能的重用和扩增，以不断适应用户的要求。因此，对OOD的测试，应从如下三方面考虑：

　　对认定的类的测试
对构造的类层次结构的测试
对类库的支持的测试

4、 面向对象编程的测试
　　典型的面向对象程序具有继承、封装和多态的新特性，这使得传统的测试策略必须有所改变。封装是对数据的隐藏，外界只能通过被提供的操作来访问或修改数据，这样降低了数据被任意修改和读写的可能性，降低了传统程序中对数据非法操作的测试。继承是面向对象程序的重要特点，继承使得代码的重用率提高，同时也使错误传播的概率提高。多态使得面向对象程序对外呈现出强大的处理能力，但同时却使得程序内"同一"函数的行为复杂化，测试时不得不考虑不同类型具体执行的代码和产生的行为。

面向对象程序是把功能的实现分布在类中。能正确实现功能的类，通过消息传递来协同实现设计要求的功能。因此，在面向对象编程（OOP）阶段，忽略类功能实现的细则，将测试的目光集中在类功能的实现和相应的面向对象程序风格，主要体现为以下两个方面。


　　数据成员是否满足数据封装的要求
转自：http://www.cnblogs.com/junzhongxu/

谈:面向对象的软件测试与传统测试的比较[1]

关键字：软件测试与传统测试 软件危机是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失控。

软件的质量不仅是体现在程序的正确性上，它和编码以前所做的需求分析，软件设计也密切相关。这时，对错误的纠正往往不能通过可能会诱发更多错误的简单的修修补补，而必须追溯到软件开发的最初阶段。因此，为了保证软件的质量，我们应该着眼于整个软件生存期，特别是着眼于编码以前的各开发阶段的工作。于是，软件测试的概念和实施范围必须扩充，应该包括在整个开发各阶段的复查、评估和检测。由此，广义的软件测试实际是由确认、验证、测试三个方面组成。


　　在整个软件生存期，确认、验证、测试分别有其侧重的阶段。确认主要体现在计划阶段、需求分析阶段、也会出现在测试阶段；验证主要体现在设计阶段和编码阶段；测试主要体现在编码阶段和测试阶段。事实上，确认、验证、测试是相辅相成的。确认无疑会产生验证和测试的标准，而验证和测试通常又会帮助完成一些确认，特别是在系统测试阶段。


　　传统的测试计算机软件的策略是从“小型测试”开始，逐步走向“大型测试”。即我们从单元测试开始，然后逐步进入集成测试，最后是有效性和系统测试。在传统应用中，单元测试集中在最小的可编译程序单位——子程序(如，模块、子例程、进程)，一旦这些单元均被独立测试后，它被集成在程序结构中，这时要进行一系列的回归测试以发现由于模块的接口所带来的错误和新单元加入所导致的副作用，最后，系统被作为一个整体测试以保证发现在需求中的错误。


　面向对象程序的结构不再是传统的功能模块结构，作为一个整体，原有集成测试所要求的逐步将开发的模块搭建在一起进行测试的方法已成为不可能。而且，面向对象软件抛弃了传统的开发模式，对每个开发阶段都有不同以往的要求和结果,已经不可能用功能细化的观点来检测面向对象分析和设计的结果。因此，传统的测试模型对面向对象软件已经不再适用。
　　1、 面向对象测试模型

面向对象的开发模型突破了传统的瀑布模型，将开发分为面向对象分析（OOA），面向对象设计（OOD），和面向对象编程（OOP）三个阶段。针对这种开发模型，结合传统的测试步骤的划分，我们把面向对象的软件测试分为：面向对象分析的测试，面向对象设计的测试，面向对象编程的测试，面向对象单元测试，面向对象集成测试，面向对象系统测试。

2、 面向对象分析的测试
传统的面向过程分析是一个功能分解的过程，是把一个系统看成可以分解的功能的集合。这种传统的功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程，以过程的抽象来对待系统的需要。而面向对象分析（OOA）是"把E-R图和语义网络模型，即信息造型中的概念，与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法"，最后通常是得到问题空间的图表的形式描述。OOA直接映射问题空间，全面的将问题空间中实现功能的现实抽象化。将问题空间中的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和操作表示实例的特性和行为。对一个系统而言，与传统分析方法产生的结果相反，行为是相对稳定的，结构是相对不稳定的，这更充分反映了现实的特性。OOA的结果是为后面阶段类的选定和实现，类层次结构的组织和实现提供平台。因此，对OOA的测试，应从以下方面考虑：
转自：http://www.cnblogs.com/junzhongxu/