web性能测试研究.doc

摘 要软件开发和使用的历史已经留给了使用者很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使软件开发者们必须添加一个相应的流程，并在此流程中采取强有力的检测措施来检测未发现的隐藏的软件缺陷，也就是软件测试。随着计算机软件的规模越来越大，软件测试成为了软件质量保障的关键环节，软件测试自动化也成为了软件测试领域所无法逾越的发展阶段。软件测试的核心是测试思维，你的思维能深入到什么程度，测试就能做到什么程度，本次课题旨在训练我们的测试思维，同时通过本次的课题实例掌握测试流程与技巧，为我们成为真正的测试人员打下坚实的基础。本文将使用网上飞机订票系统进行测试，通过设计测试方案，对程序进行系统的单元测试，收集测试数据，对测试数据进行分析等手段，最终生成相关资料及最终测试报告，详细介绍及探讨软件测试技术在Web中的研究和实现。 本论文的展开将通过以下三个部分： 第一部分：软件测试以及性能测试技术的相关介绍，市场上主流测试管理工具的对比分析。 第二部分：本论文相关项目的案例分析和测试规划，网上飞机订票系统测试的测试思路和测试方案设计 第三部分：网上飞机订票系统性能外部测试的具体测试细则关键字：黑盒测试，白盒测试，测试管理，测试桩，测试点。Software testing technology in the Web in the Research and ImplementationAbstractSoftware development and use of history has left many users due to software defects caused by the enormous financial and material resources, experiences and lessons of loss. These lessons to force software developers have to add a corresponding processes, and in this process to take strong measures to detection of detection did not find the hidden software defects, that is, software testing. Software testing is to test the core of thinking, thinking you can go to what extent, will be able to test to what extent, the subject of this test designed to train our thinking, at the same time the subject of this example of the testing process and techniques to master in order to become a real test of our staff and lay a solid foundation. With the increasing scale of software, software testing software quality assurance has become a key link in the software test automation has become the field of software testing stage of development can not be crossedThis article will use the online booking system for testing aircraft, through the design of test programs, procedures and systems for unit testing, test data collection, analysis of test data and other means, and ultimately to generate relevant information and final test reports, and to explore the details of software testing technology in the Web research and to achieve. In this paper, the launch will be the adoption of the following three parts: Part I: Software testing and performance testing of the related technology, the mainstream of the market test of the comparative analysis of management tools. Part II: In this paper, the text of the case studies related to project planning and testing, on-line booking system to test the aircrafts test program design and testing of ideas Part III: Online booking system performance aircraft external test specific test rulesKeywords: black-box testing, white-box testing, test management, test piles, test points目 录1引 言61.1 选题背景61.2 本文的目标和主要工作71.3 测试环境的搭建82 软件测试分类92.1按测试策略分类92.1.1 白盒测试92.1.2 代码测试112.1.3 接口测试122.1.4 白盒测试的六种覆盖方法132.1.5 主流白盒测试工具172.1.6 黑盒测试182.1.7 ALAC(Act-like-a-customer)测试182.1.8 测试管理工具182.2按测试阶段分类192.2.1 单元测试192.2.2 集成测试212.2.3 系统测试和验收测试222.3其他常见测试方法232.3.1 功能测试232.3.2 性能测试232.3.3 界面测试242.3.4 负载测试242.3.5 强度测试252.3.6 数据库容量测试253 性能测试研究263.1 软件测试概述263.1.1 性能测试263.1.2 测试工具273.2 主流性能测试工具比较273.2.1 Microsoft Web Application Stress Tool(WAS)283.2.2 Open System Testing Architecture(OpenSTA)283.2.3 QALoad293.2.4 IBM Rational TeamTest（Teamtest）293.2.5 WebLoad303.2.6 LoadRunner304 项目分析与规划测试334.1 网上飞机订票系统 2.3版项目分析344.1.1 背景概述344.1.2 功能概述344.1.3 系统组件与配置354.1.4 分析使用模型及任务分布364.2 定义负载测试目标364.3 测试思路与测试方案设计374.3.1 设计压力应用思路374.3.2 测试方案设计394.3.3 性能测试用例40 网上飞机订票系统性能测试实例的实现425.1 创建用户脚本425.2 完善测试脚本445.2.1 事务设置445.2.2 用参数化取代常量值455.2.3 集合点465.2.4 脚本检验475.3 方案执行485.3.1 场景创建485.3.2 加压计划495.3.3 多IP地址505.4 运行结果处理分析505.4.1 Throughput515.4.2 Transaction Response Time525.4.3 分解界面535.4.4 针对测试用例的图表分析55总结58致谢59参考文献59附录601引 言信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成为人们共同关注的焦点。不论软件的生产者还是软件的使用者，均生存在竞争的环境中，软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的顺利完成，当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉下降，继而冲击股票市场。在一些关键应用 (如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等)中使用质量有问题的软件，还可能造成灾难性的后果。软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失控。有错是软件的属性，而且是无法改变的，因为软件是由人来完成的，所有由人做的工作都不会是完美无缺的。问题在于我们如何去避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能低的程度。1.1 选题背景软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保障的关键步骤。其定义可简略概括为：使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。随着软件规模的不断扩大，软件质量问题已成为制约计算机发展的主要因素之一。作为保证软件质量和可靠性的手段，软件测试起着不可替代的作用。随着电力信息化的发展和技术的进步，电力信息化软件的架构也由 C/S 结构发展到了现在的 B/S 架构，如今电力信息化软件的主流正是通过 Internet 访问，基于 Web的应用程序。与以往的软件相比，基于 Web 的信息化软件有着不同于以往软件的特点u 集中 包括数据库集中，信息系统管理集中，业务管理集约化。u 大分布 按照地域广泛分布，这与“集中”的特点是对立统一的。u 大量 包括数据量大，业务量大。正是由于以上的特点，基于 Web 的信息化软件相比传统软件，带来了非常大的优越性，但同时也带来了很多挑战，这是因为基于 Web 的信息系统的大分布，决定了Web 服务器要同时接受大量的数据请求。这样一旦 Web 服务器瘫痪即将造成巨大的损失。这就对 Web 系统的性能提出了要求，要求产品在出厂前必须接受严格的性能测试。有鉴于此，本课题将基于 Web 的性能测试作为主要研究方向，本文将以 “网上飞机订票系统 2.3版”作为对象，以美国 Mercury 公司生产的 LoadRunner软件为工具进行外部性能压力测试，对软件测试，尤其是自动化测试进行完善，系统的概括和实践。1.2 本课题国内外研究现状及发展趋势1.3 本文的目标和主要工作本文将通过基于 LoadRunner 的“网上飞机订票系统 2.3版”性能外部测试对自动化测试实例的设计与实现进行深入研究，并在此基础上对软件性能测试的流程作出整理和归纳，其研究方法和探讨可以为该方向的研究者及学习者提供参考，亦可为其他同类研究的评价提供借鉴，并且对将来自动化测试的的培训及入门具有指导作用。本论的主要工作有：1.以 LoadRunner 为工具对“网上飞机订票系统 2.3版”进行性能测试。2.对市场上主流的性能测试工具进行对比。3.对性能测试的流程进行整理归纳。4.通过对网上飞机订票系统2.3版的性能测试，学习并掌握基于 LoadRunner 的测试技术。5.分析所得测试数据并最终生成相关文档。2 软件测试分类软件测试的分类可以从以下几个方面来分：首先按测试策略可以分为静态测试、动态测试、黑盒测试、白盒测试、手工测试、自动测试；按测试阶段分类有可以分为单元测试、集成测试、确认测试、系统测试以及验收测试；还有其他的一些常见测试方法，例如：功能测试、性能测试、压力测试，负载测试等。2.1按测试策略分类2.1.1 白盒测试由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的，因此我们要进行白盒测试。白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的,你清楚盒子内部的东西以及里面是如何运作的。白盒的测试用例需要做到：(1)保证一个模块中的所有独立路径至少被使用一次(2)检查内部数据结构以确保其有效性白盒测试的目的：通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。白盒测试的实施步骤：测试计划阶段：根据需求说明书，制定测试进度测试设计阶段：依据程序设计说明书，按照一定规范化的方法进行软件结构划分和设计测试用例。测试执行阶段：输入测试用例，得到测试结果。测试总结阶段：对比测试的结果和代码的预期结果，分析错误原因，找到并解决错误。白盒测试的方法：总体上分为静态方法和动态方法两大类静态分析是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。动态分析的主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后 ,对软件系统行为的分析。动态分析包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支测试白盒测试的优缺点优点：迫使测试人员去仔细思考软件的实现;可以检测代码中的每条分支和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底;最优化。缺点：昂贵;无法检测代码中遗漏的路径和数据敏感性错误;不验证规格的正确性。总的来说，白盒测试是一种被广泛使用的逻辑测试方法，是由程序内部逻辑驱动的一种单元测试方法。只有对程序内部十分了解才能进行适度有效的白盒测试。但是贯穿在程序内部的逻辑存在着不确定性和无穷性，尤其对于大规模复杂软件。因此我们不能穷举所有的逻辑路径，即使穷举也未必会带来好运（穷举不能查出程序逻辑规则错误，不能查出数据相关错误，不能查出程序遗漏的路径）。那么正确使用白盒测试，就要先从代码分析入手，根据不同的代码逻辑规则、语句执行情况，选用适合的覆盖方法。任何一个高效的测试用例，都是针对具体测试场景的。逻辑测试不是片面的测试正确的结果或是测试错误的结果，而是尽可能全面地覆盖每一个逻辑路径。2.1.2 代码测试 静态测试执行代码静态测试应注意以下方面：同一程序内的代码书写是否为同一风格；代码布局是否合理、美观；程序中函数、子程序块分界是否明显；注释是否符合既定格式；注释是否正确反映代码的功能；变量定义是否正确（长度、类型、存储类型）；子程序（函数和方法）接受的参数类型、大小、次序是否和调用模块相匹配合；函数的返回值类型是否正确；程序中是否引用了未初始化变量；数组和字符串的下标是否为整数；数组和字符串的下标是否在范围内（不“越界”）；进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”；是否在应该使用常量的地方使用了变量（例：数组范围查询）；是否为变量赋予不同类型的值；赋值是否符合数据类型的转换规则；变量的命名是否相似；是否存在声明过，但从未引用或者只引用过一次的变量；在特定模块中所有的变量是否都显式声明过；是否可以理解为该变量具有更高的共享级别；是否为引用的指针分配内存；数据结构在函数和子程序中的引用是否明确定义了其结构；计算中是否使用了不同数据类型的变量；计算中是否使用了不同的数据类型相同但长度不同的变量；赋值的目的变量是否小于赋值表达式的值；数值计算是否会出现溢出（向上）的情况；数值计算是否会出现溢出（向下）的情况；除数是否可能为零；某些计算是否会丢失计算精度；变量的值是否超过有意义的值；计算式的求值的顺序是否容易让人感到混乱；比较是否正确；是否存在分数和浮点数的比较；精度问题是否会影响比较；每一个逻辑表达式是否都得到了正确表达；逻辑表达式的操作数是否均为逻辑值；程序中的 BeginEnd 和 DoWhile 等语句中，End 是否对应；程序、模块、子程序和循环是否能够终止；是否存在永不执行的循环；是否存在多循环一次或少循环一次的情况；循环变量是否在循环内被错误地修改；多分支选择中，索引变量是否能超过可能的分支数；该情况是否能够得到正确处理；全局变量定义和用法在各个模块中是否一致；是否修改了只作为输入用的参数；常量是否被作为形式参数进行传递。 动态测试执行代码动态测试应注意以下方面：测试数据是否具有一定的代表性；测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）；是否可能从客户那边得到测试数据；不可从客户那边得到测试数据的情况下，所用的测试数据是否具有实际的意义（客户业务上的）；是否每一组测试数据都得到了执行；每一组测试数据的测试结果是否与预期结果一致；文件的属性是否正确；打开文件语句是否正确；输入/输出语句是否与格式说明书所记述的一致；缓冲区大小与记录长度是否匹配；使用文件前是否已打开了文件；文件结束条件是否存在；产生输入/输出错误时，系统是否进行检测并处理；输出信息中是否存在文字书写错误和语法错误；数字输入框是否接受数字输入；数字是否按既定格式显示；数字输入框是否拒绝字符串和“非法”数字的输入；组合框是否的能够进行下拉选择；组合框是否能够进行下拉多项选择；对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择；列表框是否能够进行选择；多项列表框是否能够进行多数据项选择；日期输入框是否jieshou接受正确的日期输入；日期输入框是否拒绝错误的日期输入；日期输入框在日期输入后是否按既定的日期格式显示日期；单选组内是否有且只有一个单选钮可选；如果单选组内无单选钮可选，这种情况是否允许存在；复选框组内是否允许多个复选框（包括全部可选）可选；如果复选框组内无复选框可选，这种情况是否允许存在；文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理；文本框中数据格式（大小、对齐方向、颜色、背景）是否符合规范；密码输入框是否按掩码的方式显示；控件是否存在默认输入值，若存在，默认值是否得到显示和提交；Cancel 之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理；Submit 之类的按钮按下后，数据是否得到提交或按既定规约处理；异常信息表述是否正确；软件是否按预期方式处理错误；文件或外设不存在的情况下是否存在相应的错误处理；软件是否严格的遵循外设的读写格式；产生的文件和数据表的格式是否正确；产生的文件和数据表的计算结果是否正确；打印的报表是否符合既定的格式；错误日志的表述是否正确；错误日志的格式是否正确。2.1.3 接口测试定义通用的命令接口结构，用文本文件记录接口相关结构信息，通过对该文本文件进行逐行的语法解析，将文件中的描述转化为统一结构的链表，验证来自外层的数据是否正确，以及根据提示用户输入的信息验证发送到其它层的数据是否正确。这种通用接口测试方法，解决了接口测试时重复编写类似功能代码的问题，提供了一种新的描述不同命令结构的思路。通过使用文件形式，不用修改程序就可以实现对新的接口命令的测试，使测试程序得到极大的精简，并且易于扩展和移植到不同项目中。详细步骤：（1）测试程序要测试的已经具体实现的类。（2）一个抽象的测试类，声明要验证的功能的测试方法。在具体的测试程序实现中继承这个测试类，并修改相应的实现方法。（3）每一个具体实现中都运行该测试程序，但在每个实现中都只验证“接口范围内”的行为。（4）在程序内，找到创建（接口）对象的代码，将该代码改成具体的、已经实现的类的创建方法，但记住将该对象声明为接口的对象，而不是具体实现的类的对象。重复这一过程，直至测试程序中没有已经实现的类的对象。（5）要在测试中调用的抽象方法。（6）只涉及接口和一些抽象的测试方法，将测试程序移入抽象的测试类。（7）这一过程直至所有的测试都移入抽象的测试类。（8）前面的全部过程，直至除了验证具体实现的特有的方法的测试程序外，所有的测试代码都已完成。2.1.4 白盒测试的六种覆盖方法首先为了下文的举例描述方便，这里先给出一张程序流程图。（本文以 2005 年软件设计师考试的一道考试题目为例，图中红色字母代表程序执行路径）。图2.1 程序流程图（1）语句覆盖主要特点：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。用例设计：（如果此时将 A 路径上的语句 1-T 去掉，那么用例如表 2.1）表2.1 语句覆盖用例XY路径15050OBDE29070OBCE优点：可以很直观地从源代码得到测试用例，无须细分每条判定表达式。缺点：由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。在本例中去掉了语句 1T 去掉，那么就少了一条测试路径。在 if 结构中若源代码没有给出 else 后面的执行分支，那么语句覆盖测试就不会考虑这种情况。但是我们不能排除这种以外的分支不会被执行，而往往这种错误会经常出现。再如，在 Do-While 结构中，语句覆盖执行其中某一个条件分支。那么显然，语句覆盖对于多分支的逻辑运算是无法全面反映的，它只在乎运行一次，而不考虑其他情况。（2）判定覆盖主要特点：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。用例设计(如表 2.2)：表2.2 判定覆盖用例设计XY路径19090OAE25050OBDE39070OBCE优点：判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。缺点：往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含 AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。（3）条件覆盖主要特点：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。用例设计(如表 2.3)表 2.3 条件覆盖用例设计XY路径19070OBC240OBD优点：显然条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。缺点：要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。（4）判定/条件覆盖主要特点：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。用例设计(如表 2.4)：表 2.4判定/条件覆盖用例设计XY路径19090OAE25050OBDE39070OBCE47090OBCE优点：判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。缺点：判定/条件覆盖准则的缺点是未考虑条件的组合情况。（5）组合覆盖主要特点：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。用例设计(如表 2.5)：表 2.5 组合覆盖用例设计XY路径19090OAE29070OBCE39030OBDE47090OBCE53090OBDE67070OBDE75050OBDE优点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。缺点：线性地增加了测试用例的数量。（6）路径覆盖主要特点：设计足够的测试用例，覆盖程序中所有可能的路径。用例设计(如表 2.6)：XY路径19090OAE25050OBDE39070OBCE47090OBCE优点：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广。缺点：由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，如：If（!A）B+； Fc3Q 0If（!A）D-；这两个语句实际只包括了 2 条执行路径，即 A 为真或假时候对 B 和 D 的处理，真或假不可能都存在，而路径覆盖测试则认为是包含了真与假的 4 条执行路径。这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。2.1.5 主流白盒测试工具 Parasoft 白盒测试工具集（1）工具名：Jtest 支持语言环境：Java 简介：代码分析和动态类、组件测试。（2）工具名：Jcontract 支持语言环境：Java 简介：实时性能监控以及分析优化。（3）工具名：C+ Test 支持语言环境：C,C+ 简介：代码分析和动态测试。（4）工具名：CodeWizard 支持语言环境：C,C+ 简介：代码静态分析。（5）工具名：Insure+支持语言环境：C,C+简介：实时性能监控以及分析优化。（6）工具名：.test 支持语言环境：.Net 简介：代码分析和动态测试。 Compuware 白盒测试工具集（1）工具名：BoundsChecker支持语言环境：C+,Delphi简介：API 和 OLE 错误检查、指针和泄露错误检查、内存错误检查。（2）工具名：TrueTime 支持语言环境：C+,Java,Visual Basic简介：代码运行效率检查、组件性能的分析。（3）工具名：FailSafe支持语言环境：Visual Basic简介：自动错误处理和恢复系统。（4）工具名：Jcheck 支持语言环境：MS Visual J+简介：图形化的纯种和事件分析工具。（5）工具名：TrueCoverage支持语言环境：C+,Java,Visual Basic简介：函数调用次数、所占比率统计以及稳定性跟踪。（6）工具名：SmartCheck支持语言环境：Visual Basic简介：函数调用次数、所占比率统计以及稳定性跟踪。（7）工具名：CodeReview支持语言环境：Visual Basic简介：自动源代码分析工具。2.1.6 黑盒测试 黑盒测试是指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。 黑盒测试也可以借助一些工具，如WinRunner，QuickTestPro，Rational Robot等。2.1.7 ALAC(Act-like-a-customer)测试 ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对哪些客户最容易遇到的错误。2.1.8 测试管理工具随着软件测试的地位逐步提高，测试管理的重要性逐步显现，测试工具的应用已经成为了普遍的趋势。目前用于测试的工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。总的来说，测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候，我们也应该看到，在测试过程中，并不是所有的测试工具都适合我们使用，同时，有了测试工具、会使用测试工具并不等于测试工具真正能在测试中发挥作用。2.2按测试阶段分类2.2.1 单元测试单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。因为单元测试需要知道内部程序设计和编码的细节知识，一般应由程序员而非测试员来完成，往往需要开发测试驱动模块和桩模块来辅助完成单元测试。因此应用系统有一个设计很好的体系结构就显得尤为重要。单元测试的通过标准是什么： (1)程序通过所有单元测试的用例 (2)语句的覆盖率达到100% (3)分支覆盖率达到85% 如何进行单元测试:单元测试主要用白盒测试方法，一般我们先静态地检查代码是否符合规范，然后动态地运行代码，检查其它实际运行结果。当然检查程序的运行结果是否正确是一个最基本的要求，我们还要检查很多项，比如程序的非法数据的容错处理，程序的边界值处理等。 桩模块：是指模拟被测模块所调用的模块。 驱动模块：是指模拟被测模块的上级模块。 桩模和驱动模块例子： include void main(void) int a=1,b=2,c; c=fun1(a,b); int fun1(int x, int y) return X + Y; 主函数main调用fun1,fun1实现了计算两个参数之和功能，假设这两个函数是由两个程序员各自开发的，他们之间的开发开度不一样。如果没有main函数，如何测试fun1函数，这时，我们需要模拟构一个新的main函数，它可以不包含main函数中需要的所有内容和细工，但至少要能够调用fun1,并且能够打印调用之后的结果，我们就把这个模拟的函数称为fun1的驱动模块。如果没有fun1函数，这时，我们需要模拟构建一个新的fun1函数，它可以不包含fun1函数中需要的所有内容和细节，但至少能够被main函数调用，并有一个返回值，我们把这个模拟的函数就称为fun1的桩模块。 单元测试优点它是一种验证行为。程序中的每一项功能都是测试来验证它的正确性。它为以后的开发提供支缓。就算是开发后期，我们也可以轻松的增加功能或更改程序结构，而不用担心这个过程中会破坏重要的东西。而且它为代码的重构提供了保障。这样，我们就可以更自由的对程序进行改进。它是一种设计行为。编写单元测试将使我们从调用者观察、思考。特别是先写测试（test-first），迫使我们把程序设计成易于调用和可测试的，即迫使我们解除软件中的耦合。 它是一种编写文档的行为。单元测试是一种无价的文档，它是展示函数或类如何使用的最佳文档。这份文档是可编译、可运行的，并且它保持最新，永远与代码同步。 它具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地的快速运行测试。 单元测试范畴如果要给单元测试定义一个明确的范畴，指出哪些功能是属于单元测试，这似乎很难。但下面讨论的四个问题，基本上可以说明单元测试的范畴，单元测试所要做的工作。 它的行为和我期望的一致吗？这是单元测试最根本的目的，我们就是用单元测试的代码来证明它所做的就是我们所期望的。它的行为一直和我期望的一致吗？编写单元测试，如果只测试代码的一条正确路径，让它正确走一遍，并不算是真正的完成。软件开发是一个项复杂的工程，在测试某段代码的行为是否和你的期望一致时，你需要确认：在任何情况下，这段代码是否都和你的期望一致；譬如参数很可疑、硬盘没有剩余空间、缓冲区溢出、网络掉线的时候。我可以依赖单元测试吗？不能依赖的代码是没有多大用处的。既然单元测试是用来保证代码的正确性，那么单元测试也一定要值得依赖。单元测试说明我的意图了吗？ 单元测试能够帮我们充分了解代码的用法，从效果上而言，单元测试就像是能执行的文档，说明了在你用各种条件调用代码时，你所能期望这段代码完成的功能。 2.2.2 集成测试集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求）如根据结构图组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。集成测试方法集成测试应该考虑以下问题：1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2、各个子功能组合起来，能否达到预期要求的父功能；3、一个模块的功能是否会对另一个模块的功能产生不利的影响；4、全局数据结构是否有问题；5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。对子系统，集成测试也叫部件测试。任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。集成测试的实施集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：1、是采用何种系统组装方法来进行组装测试；2、组装测试过程中连接各个模块的顺序；3、模块代码编制和测试进度是否与组装测试的顺序一致4、测试过程中是否需要专门的硬件设备；解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应测试应安排在这些设备能够投入使用之时，并需要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。集成测试完成标准怎样判定集成测试过程完成了, 可按以下几个方面检查:1、成功地执行了测试计划中规定的所有集成测试；2、修正了所发现的错误；3、测试结果通过了专门小组的评审。集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。在完成预定的组装测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见2.2.3 系统测试和验收测试系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。验收测试又分a(阿发)测试和B(贝搭)测试:Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试由用户、测试人员、开发人员等共同参与的内部测试，Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。2.3其他常见测试方法2.3.1 功能测试功能测试指测试软件各个功能模块是否正确，逻辑是否正确。是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。一般分为逻辑功能测试、易用性测试、安装测试、兼容性测试等。对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。 比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误2.3.2 性能测试软件的性能包括很多方面，主要有时间性能和空间性能两种。时间性能主要是指软件的一个具体事务的响应时间（respond time）比如登录163邮箱，输入用户名和密码，点“登录”按钮，从你点击按钮的那一刻起，到最终登录后的页面反馈给你，这一时间间隔为3秒，我们则称 163邮箱在这一次登录事务中的响应时间为3秒。一般我们多次登录，来记录不同的响应时间，最后取平均值，这样的数据才有参考价值。（一般一个电子商务网站来说，一个普遍接受响就时间标准为2(2秒给用户以响就是非常有吸引力的)/5(5秒以内被认为是比较不错的)/10(用户忍受上限)）；空间性能：主要指软件运行时所消耗的系统资源，比如安装软件之前，我们经常看到某软件安装的最低要求。性能测试一般分为：(1)一般性能测试：指让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测式。(2)稳妥定性测试：也叫可靠性测试，指连续运行被测系统，检查系统运行的稳定程度。(3)负载测试：通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。压力测试：通常是指持续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。2.3.3 界面测试UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等 用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关 比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。2.3.4 负载测试负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？2.3.5 强度测试强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错