测试目的
软件测试的目的
软件测试目的
软件测试原则
测试原则
测试类型
按照测试内容划分，
测试类型一般有逻辑测试、功能测试、性能测试、接口测试、人机交互界面测试、强度测试、余量测试、安全性测试、恢复性测试、边界测试、数据处理测试、安装性测试、容量测试等。
（1）逻辑测试。
逻辑测试是测试程序逻辑结构的合理性、实现的正确性。逻辑测试由测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。逻辑测试根据不同的软件级别一般需进行语句覆盖、分支覆盖、条件覆盖、条件组合覆盖、路径覆盖、MC/DC覆盖等。
（2）功能测试。
功能测试是对软件需求规格说明或设计文档中的功能需求逐项进行的测试，以验证其功能是否满足要求。功能测试一般需进行：用正常值的等价类输入数据值测试；用非正常值的等价类输入数据值测试；进行每个功能的合法边界值和非法边界值输入的测试；用一系列真实的数据类型和数据值运行，测试超负荷、饱和及其他“最坏情况”的结果；在配置项测试时对配置项控制流程的正确性、合理性等进行验证。
（3）性能测试。
性能测试是对软件需求规格说明或设计文档中的性能需求逐项进行的测试，以验证其性能是否满足要求。性能测试一般需进行：测试在获得定量结果时程序计算的精确性（处理精度）；测试其时间特性和实际完成功能的时间（响应时间）；测试为完成功能所处理的数据量；测试程序运行所占用的空间；测试其负荷潜力；测试配置项各部分的协调性；在系统测试时测试软件性能和硬件性能的集成；在系统测试时测试系统对并发事物和并发用户访问的处理能力。
（4）接口测试。
接口测试是对软件需求规格说明或设计文档中的接口需求逐项进行的测试。接口测试一般需进行：测试所有外部接口，检查接口信息的格式及内容；对每一个外部输入／输出接口必须做正常和异常情况的测试；测试硬件提供的接口是否便于使用；测试系统特性（如数据特性、错误特性、速度特性）对软件功能、性能特性的影响；对所有的内部接口的功能、性能进行测试。
（5）人机交互界面测试。
人机交互界面测试是对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的要求。人机交互界面测试一般需进行：测试操作和显示界面及界面风格与软件需求规格说明中要求的一致性和符合性；以非常规操作、误操作、快速操作来检验人机界面的健壮性；测试对错误命令或非法数据输入的检测能力与提示情况；测试对错误操作流程的检测与提示；对照用户手册或操作手册逐条进行操作和观察。
（6）强度测试。
强度测试是强制软件运行在不正常到发生故障的情况下（设计的极限状态到超出极限），检验软件可以运行到何种程度的测试。强度测试一般需：提供最大处理的信息量；提供数据能力的饱和实验指标；提供最大存储范围（如常驻内存、缓冲、表格区、临时信息区）；在能力降级时进行测试；在人为错误（如寄存器数据跳变、错误的接口）状态下进行软件反应的测试；通过启动软件过载安全装置（如临界点警报、过载溢出功能、停止输入、取消低速设备等）生成必要条件，进行计算过载的饱和测试；需进行持续一段规定的时间，而且连续不能中断的测试。
（7）余量测试。
余量测试是对软件是否达到需求规格说明中要求的余量的测试。若无明确要求时，一般至少留有20%的余量。根据测试要求，余量测试一般需提供：全部存储量的余量；输入／输出及通道的吞吐能力余量；功能处理时间的余量。
（8）安全性测试。
安全性测试是检验软件中已存在的安全性、安全保密性措施是否有效的测试。测试应尽可能在符合实际使用的条件下进行。安全性测试一般需进行：对安全性关键的软件部件，必须单独测试安全性需求；在测试中全面检验防止危险状态措施的有效性和每个危险状态下的反应；对设计中用于提高安全性的结构、算法、容错、冗余及中断处理等方案，必须进行针对性测试；对软件处于标准配置下其处理和保护能力的测试；应进行对异常条件下系统／软件的处理和保护能力的测试（以表明不会因为可能的单个或多个输入错误而导致不安全状态）；对输入故障模式的测试；必须包含边界、界外及边界结合部的测试；对“0”、穿越“0”以及从两个方向趋近“0”的输入值的测试；必须包括在最坏情况配置下的最小输入和最大输入数据率的测试；对安全性关键的操作错误的测试；对具有防止非法进入软件并保护软件的数据完整性能力的测试；对双工切换、多机替换的正确性和连续性的测试；对重要数据的抗非法访问能力的测试。
（9）恢复性测试。
恢复性测试是对有恢复或重置功能的软件的每一类导致恢复或重置的情况逐一进行的测试，以验证其恢复或重置功能。恢复性测试是要证实在克服硬件故障后，系统能否正常地继续进行工作，且不对系统造成任何损害。恢复性测试一般需进行：探测错误功能的测试；能否切换或自动启动备用硬件的测试；在故障发生时能否保护正在运行的作业和系统状态的测试；在系统恢复后，能否从最后记录下来的无错误状态开始继续执行作业的测试。
（10）边界测试。
边界测试是对软件处在边界或端点情况下运行状态的测试。边界测试一般需进行：软件的输入域或输出域的边界或端点的测试；状态转换的边界或端点的测试；功能界限的边界或端点的测试；性能界限的边界或端点的测试；容量界限的边界或端点的测试。
（11）数据处理测试。
数据处理测试是对完成专门数据处理功能所进行的测试。数据处理测试一般需进行：数据采集功能的测试；数据融合功能的测试；数据转换功能的测试；剔除坏数据功能的测试；数据解释功能的测试。
（12）安装性测试。
安装性测试是对安装过程是否符合安装规程的测试，以发现安装过程中的错误。安装性测试一般需进行：不同配置下的安装和卸载测试；安装规程的正确性测试。
（13）容量测试。
容量测试是检验软件的能力最高能达到什么程度的测试。容量测试一般应测试到在正常情况下软件所具备的最高能力，如：响应时间或并发处理个数等能力。
根据软件开发阶段和测试对象，
一般可分为单元测试、部件测试（也称为集成测试或组装测试）、配置项测试和系统测试。
单元测试
单元测试的对象是软件单元。软件单元测试的目的是检查每个软件单元能否正确地实现设计说明中的功能、性能、接口和其他设计约束等要求，发现单元内可能存在的各种错误。一般由软件的供方组织并实施软件单元测试，也可委托第三方进行软件单元测试。软件单元测试可根据软件单元的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。单元测试一般应符合以下的技术要求：
（1）在对软件单元进行动态测试之前，应对软件单元的源代码进行静态测试。
（2）应建立测试软件单元的环境，如桩模块和驱动模块，其测试环境应通过评审。
（3）对软件设计文档规定的软件单元的功能、性能、接口等应逐项进行测试。
（4）软件单元的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
（5）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
（6）语句覆盖率要达到100%。
（7）分支覆盖率要达到100%。
（8）对输出数据及其格式进行测试。
软件单元测试一般应采用静态测试方法和动态测试方法。通常静态测试先于动态测试。软件单元测试完成后形成的文档有：软件单元测试计划；软件单元测试说明；软件单元测试报告；软件单元测试记录；软件单元测试问题报告。
部件测试
部件测试的对象包括软件部件的组装过程和组装得到的软件部件，软件部件由软件单元组成。软件部件测试的目的是检验软件单元和软件部件之间的接口关系，并验证软件部件是否符合设计要求。软件部件测试一般由软件供方组织并实施，测试人员与开发人员应相对独立；也可委托第三方进行软件部件测试。软件部件测试可根据软件部件的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。部件测试一般应符合以下技术要求：
（1）应对构成软件部件的每个软件单元的单元测试情况进行检查。
（2）若对软件部件进行必要的静态测试，应先于动态测试。
（3）组装过程是动态进行的，因此应标明组装策略。
（4）应建立部件测试环境，如桩模块和驱动模块，其测试环境应通过评审。
（5）应逐项测试软件设计文档规定的软件部件的功能、性能等特性。
（6）软件部件的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例覆盖。
（7）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
（8）应测试软件单元和软件部件之间的所有调用，达到要求的测试覆盖率。
（9）应测试软件部件的输出数据及其格式。
（10）应测试软件部件之间、软件部件和硬件之间的所有接口。
（11）应测试运行条件（如数据结构、输入／输出通道容量、内存空间、调用频度等）在边界状态下，进而在人为设定的状态下，软件部件的功能和性能。
（12）应按设计文档要求，对软件部件的功能、性能进行强度测试。
（13）对安全性关键的软件部件，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
（14）发现是否有多余的软件单元。
软件部件测试一般应采用静态测试方法和动态测试方法。静态测试方法常采用静态分析、代码审查等方法，动态测试方法常采用白盒测试方法和黑盒测试方法。通常，静态测试先于动态测试。
在由软件单元和软件部件组装成新的软件部件时，应根据软件单元和软件部件的特点选择便于测试的组装策略。按测试过程中，组合软件单元的方式，有两种不同的组装策略，即一次性组装策略和增值式组装策略。
一次性组装策略是一种非增值集成方式，首先完成全部软件单元测试，然后再把所有的软件单元集成在一起进行测试，最终得到要求的软件系统。一次性组装策略的优点是工作量相对较小，缺点是定位错误比较困难。
增值式组装策略也称为递增集成法，即依次将软件单元增加到已测试完成的软件部件中，将已测试的软件部件组装为更大的软件部件，在组装的过程中边增加边测试，以便发现组装过程中的问题。最后增值逐步组装为要求的软件系统。根据组装的过程又可分为自顶向下组装、自底向上组装、“三明治”组装、定向冒险组装、功能定向组装等策略。
软件部件测试完成后形成的文档包括：软件部件测试计划；软件部件测试说明；软件部件测试报告；软件部件测试记录；软件部件测试问题报告。
配置项测试
配置项测试的对象是计算机软件配置项（CSCI，以下简称配置项），软件配置项是为独立的配置管理而设计的并且能满足最终用户功能的一组软件。软件配置项测试的目的是检验软件配置项与软件需求规格说明的致一性。配置项测试可根据软件配置项的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。配置项测试一般应符合以下技术要求：
（1）必要时，在高层控制流图中作结构覆盖测试。
（2）应逐项测试软件需求规格说明规定的配置项的功能、性能等特性。
（3）配置项的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
（4）测试用例的输入应至少包括有效等价类值、无效等价值和边界数据值。
（5）应测试配置项的输出及其格式。
（6）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。
（7）应测试运行条件在边界状态和异常状态下，或在人为设定的状态下，配置项的功能和性能。
（8）应按软件需求规格说明的要求，测试配置项的安全性和数据的安全保密性。
（9）应测试配置项的所有外部输入、输出接口（包括和硬件之间的接口）。
（10）应测试配置项的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。
（11）应按软件需求规格说明的要求，对配置项的功能、性能进行强度测试。
（12）应测试设计中用于提高配置项的安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。
（13）对安全性关键的配置项，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
（14）对有恢复或重置功能需求的配置项，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。
（15）对不同的实际问题应外加相应的专门测试。
应保证软件配置项测试工作的独立性。软件配置项测试一般由软件的供方组织，由独立于软件开发的组织实施。软件配置项测试一般应采用黑盒测试方法。
软件配置项测试完成后形成的文档有：软件配置项测试计划；软件配置项测试说明；软件配置项测试报告；软件配置项测试记录；软件配置项测试问题报告。
系统测试
系统测试的对象是完整的、集成的计算机系统（CS），重点是新开发的配置项的集合。系统测试的目的是在真实系统工作环境下检验完整的软件配置项能否和系统正确连接，并满足系统／子系统设计文档和软件开发任务书规定的要求。可根据软件系统的重要性、安全性关键等级等对如下技术要求内容进行剪裁，但必须说明理由。系统测试一般应符合以下技术要求：
（1）应按系统／子系统设计说明的规定，逐项测试系统的功能、性能等特性。
（2）系统的每个特性应至少被一个正常测试用例和一个被认可的异常测试用例所覆盖。
（3）测试用例的输入应至少包括有效等价类值、无效等价类值和边界数据值。
（4）应测试系统的输出及其格式。
（5）应测试配置项之间及配置项与硬件之间的所有接口。
（6）应在边界状态、异常状态或在人为设定的状态的运行条件下，测试系统的功能和性能。
（7）应测试系统的安全性和数据访问的安全保密性。
（8）应测试系统的全部存储量、输入／输出通道的吞吐能力和处理时间的余量。
（9）应按系统或子系统设计文档的要求，对系统的功能、性能进行强度测试。
（10）应测试人机交互界面提供的操作和显示界面，包括用非常规操作、误操作、快速操作测试界面的可靠性。
（11）应测试设计中用于提高系统安全性和可靠性的方案，如结构、算法、容错、冗余、中断处理等。
（12）对安全性关键的系统，应对其进行安全性分析，明确每一个危险状态和导致危险的可能原因，并对此进行针对性的测试。
（13）对有恢复或重置功能需求的系统，应测试其恢复或重置功能和平均恢复时间，并且对每一类导致恢复或重置的情况进行测试。
（14）对软件系统的安装性进行测试。
（15）对不同的实际问题应外加相应的专项测试。
系统测试一般由软件的需方组织，由独立于软件开发的组织实施。系统测试一般应采用黑盒测试方法。
系统测试完成后形成的文档包括：系统测试计划；系统测试说明；系统测试报告；系统测试记录；系统测试问题报告。
软件测试过程
开发过程的质量决定了软件的质量，同样地，测试过程的质量决定了软件测试的质量和有效性。软件测试过程的管理是保证测试过程质量、控制测试风险的重要活动。软件测试和软件开发一样，都遵循软件工程的原理，有它自己的生命周期。软件的测试过程一般分成测试计划、测试设计与开发、测试实施、测试评审与测试结论等阶段。对每个阶段的任务、输入和输出都有明确的规定，以便对整个测试过程进行质量控制和配置管理。
软件测试过程是一种抽象的、遵循GB/T 18905（ISO 14598.5）《评价者用的过程（Process for Evaluator）》中定义软件评价过程的模型，是国际上共同遵守的软件评测过程标准，是软件测试过程管理的精髓。标准定义了分析各类软件产品的评测需求，规定、设计、实施、评审以及对评测做出结论所需的各种活动。本章介绍的主要内容，可作为软件测试过程工作内容与管理的基本原则。为符合GB/T 18905基本原理，仍保留“评价过程”的标准用语。
测试过程
软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。
软件测试过程
测试需求分析
根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：
（1）确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别（单元测试、部件测试、配置项测试、系统测试）、测试类型相匹配。
（2）确定每个测试项的优先级。
（3）确定每个测试项的测试充分性要求。
（4）根据被测软件的重要性、测试目标和约束条件，确定每个测试项应覆盖的范围及范围所要求的覆盖程度。
（5）确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。
（6）确定测试项与软件需求规格说明或设计文档的追踪关系。
将测试需求分析结果按所确定的文档要求，形成测试需求规格说明或写入测试计划。
应对测试需求规格说明或测试需求分析结果进行评审，评审内容如下：
（1）测试级别和测试对象所确定的测试类型及其测试要求是否恰当。
（2）每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求。
（3）测试类型和测试项是否充分。
（4）测试项是否包括了终止要求。
（5）文档是否符合规定的要求。
测试策划
根据软件需求规格说明或设计文档等进行测试策划，策划一般包括：
（1）确定测试策略，如部件或配置项测试策略。
（2）确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。
（3）确定要受控制的测试工作产品，列出清单。
（4）确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。
（5）进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。
（6）确定测试任务的结束条件。
（7）确定被测软件的评价准则和方法。
（8）确定测试活动的进度。应根据测试资源和测试项，确定进度。
应将测试策划结果，按所确定的文档要求形成测试计划。
测试设计和实现
应根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：
（1）按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有接口和要测试的接口。
（2）说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。
（3）设计测试用例。
（4）确定测试用例的执行顺序。
（5）准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等。
（6）准备并获取测试资源，如测试环境所必须的软、硬件资源等。
（7）必要时，编写测试执行需要的程序，如开发部件测试的驱动模块和桩模块以及测试支持软件等。
（8）建立和校核测试环境，记录校核结果，说明测试环境的偏差。
应将测试设计与实现的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：
（1）测试名称和项目标识。
（2）测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项的标识（编号）。
（3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法。
（4）测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）等的初始化要求。
（5）测试用例的输入。每个测试用例输入的描述中应包括的内容：
①每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。
②测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）。
③测试输入是真实的还是模拟的。
④测试输入的时间顺序或事件顺序。
（6）测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果。
（7）测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如：
①实际测试结果所需的精确度。
②允许的实际测试结果与期望结果之间差异的上、下限。
③时间的最大或最小间隔。
④事件数目的最大或最小值。
⑤实际测试结果不确定时，重新测试的条件。
⑥与产生测试结果有关的出错处理。
⑦其他有关准则。
（8）实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：
①每一步所需的测试操作动作、测试程序输入或设备操作等。
②每一步期望的测试结果。
③每一步的评估准则。
④导致被测程序执行终止伴随的动作或指示信息。
⑤需要时，获取和分析中间结果的方法。
（9）测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响。
（10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件。
（11）确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。
（12）测试说明应经过评审，得到相关人员的认同，测试说明评审内容如下：
①测试说明是否完整、正确和规范。
②测试设计是否完整和合理。
③测试用例是否可行和充分。
测试执行
应按照测试计划和测试说明的内容和要求执行测试，主要完成下列工作：
如实填写测试记录，当结果有量值要求时，应准确记录实际的量值。
（1）测试记录应受到严格管理，并规范格式，至少包括测试用例标识、测试结果和发现的缺陷。
（2）应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。
（3）当测试用例不通过时，应根据不同的缺陷类型，采取相应的措施：
①对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中，并实施相应的变更。
②对被测软件的缺陷应记录到软件问题报告中。
③软件问题报告的格式应规范。
（4）当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关记录，分析测试工作是否充分，是否需要进行补充测试：
①当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。
②当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。
测试总结
应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等，对测试工作和被测软件进行分析和评价，主要完成下列工作：
（1）对测试工作进行分析和评价，分析和评价内容应包括：
①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。
②在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由。
③确定无法解决的软件测试事件并说明不能解决的理由。
（2）对被测软件进行分析和评价，分析和评价内容应包括：
①总结测试中所反映的被测软件与软件需求（或软件设计）之间的差异。
②可能时，根据差异评价被测软件的设计与实现，提出改进的建议。
③当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。
（3）分析测评项目中的数据和文档，以供以后的测试使用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：好的用例设计、好的需求规格说明等。
（4）应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。
测试总结评审应在测试报告编制工作完成后进行，以确定是否达到测试目的，给出评审结论。评审的具体内容和要求包括：
（1）审查测试文档与记录内容的完整性、正确性和规范性。
（2）审查测试活动的独立性和有效性。
（3）审查测试环境是否符合测试要求。
（4）审查软件测试报告与软件测试原始记录和问题报告的一致性。
（5）审查实际测试过程与测试计划和测试说明的一致性。
（6）审查测试说明评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。
（7）审查测试结果的真实性和正确性。
软件测试对象
根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，这就称为“确认测试”。将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。
由于软件分析、设计与开发各阶段是互相衔接的，前一阶段工作中发生的问题如未及时解决，很自然要影响到下一阶段。从源程序的测试中找到的程序错误不一定都是在程序编写过程中产生的。如果简单地把程序中的错误全都归罪于程序员，未免冤枉了他们。据美国一家公司的统计表明，在查找出的软件错误中，属于需求分析和软件设计的错误约占64%，属于程序编写的错误仅占36%。这都说明，对程序编写而言，它的许多错误是“先天的”。事实上，到程序的测试为止，软件开发工作已经经历了许多环节，每个环节都可能发生问题。
为了把握各个环节的正确性，人们需要进行各种验证和确认（verification&validation）工作。
验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。
确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。
验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。
测试计划（负载测试）
制定一个全面的测试计划是负载测试成功的关键。定义明确的测试计划将确保制定的方案能完成负载测试目标。这部分内容描述负载测试计划过程，包括分析应用程序、定义测试目标、计划方案实施、检查测试目标。在任何类型的系统测试中，制定完善的测试计划是成功完成测试的基础。负载压力测试计划有助于：
①构建能够精确地模拟工作环境的测试方案。负载测试指在典型的工作条件下测试应用程序，并检测系统的性能、可靠性和容量等。
②了解测试需要的资源。应用程序测试需要硬件、软件和人力资源。开始测试之前，应了解哪些资源可用并确定如何有效地使用这些资源。
③以可度量的指标定义测试成功条件。明确的测试目标和标准有助于确保测试成功。仅定义模糊的目标（如检测重负载情况下的服务器响应时间）是不够的。明确的成功条件应类似于“50个客户能够同时查看他们的账户余额，并且服务器响应时间不超过1分钟”。
下面详细论述负载压力测试计划过程的4个步骤。
分析应用程序
负载测试计划的第一步是分析应用程序。应该对硬件和软件组件、系统配置以及典型的使用模型有一个透彻的了解。应用程序分析可以确保使用的测试环境能够在测试中精确地反映应用程序的环境和配置。
确定系统组件
绘制一份应用程序结构示意图。如果可能，从现有文档中提取一份示意图。如果要测试的应用程序是一个较大的网络系统的一部分，应该确定要测试的系统组件。确保该示意图包括了所有的系统组件，例如客户机、网络、中间件和服务器等。
如下图所示说明了一个由许多Web用户访问的联机银行系统。各Web用户连接到同一数据库以转移现金和支票余额。客户使用不同的浏览器，通过Web方式连接到数据库服务器。
联机银行系统应用布署
描述系统配置
增加更多详细信息以完善示意图。描述各系统组件的配置。应当掌握以下信息：
. 连接到系统的用户数；
. 应用程序客户端计算机的配置情况（硬件、内存、操作系统、软件、开发工具等）；
. 使用的数据库和Web服务器的类型（硬件、数据库类型、操作系统、文件服务器等）；
. 服务器与应用程序客户端之间的通信方式；
. 前端客户端与后端服务器之间的中间件配置和应用程序服务器；
. 可能影响响应时间的其他网络组件（调制解调器等）；
. 通信设备的吞吐量以及每个设备可以处理的并发用户数。
例如，在如上图所示的示意图中，多个应用程序客户端在访问系统。客户端的配置如下表所示。
客户端配置内容
分析使用模型
定义系统的典型使用方式，并确定需要重点测试的功能。考虑哪些用户使用系统、每种类型用户的数量，以及每个用户的典型任务。此外，还应考虑任何可能影响系统响应时间的后台负载。
例如，假设每天上午有200名员工登录记账系统，并且该办公室网络有固定的后台负载：50名用户执行各种字处理和打印任务。可以创建一个200个虚拟用户登录访问记账数据库的方案，并检测服务器的响应时间。要了解后台负载对响应时间的影响，可以在运行方案的网络中再模拟员工执行字处理和打印活动的负载。
任务分布
除定义常规用户任务外，还应该查看这些任务的分布情况。例如，假设银行用户使用一个中央数据库为跨越多个州和时区的客户提供服务。250个应用程序客户端分布在两个不同的时区，全都连接到同一个Web服务器中。其中150个在芝加哥，另外100个在底特律。每个客户端从上午9点开始工作，但由于处于不同的时区，因此在任何特定时间内都不会有超过150个的用户同时登录。可以分析任务分布，以确定数据库活动峰值期的发生时间，以及负载峰值期间的典型活动。
定义测试目标
开始测试之前，应精确地定义想要实现的目标。
以可度量的指标制定目标
确定了负载测试的一般性目标后，应该以可度量指标制定更具针对性的目标。为了提供评估基准，应精确地确定、区分可接受和不可接受测试结果的标准。
例如：
. 一般性目标产品评估：选择Web服务器的硬件。
. 明确目标产品评估：在一台HP服务器和一台NEC服务器上运行同一个包含300个虚拟用户的组。当300个用户同时浏览Web应用程序页面时，确定哪一种硬件提供更短的响应时间。
. 测试目标
①度量最终用户的响应时间，完成一个业务流程需要多长时间；
②定义最优的硬件配置，哪一种硬件配置可以提供最佳性能；
③检查可靠性，系统无错误或无故障运行的时间长度或难度；
④查看硬件或软件升级对性能或可靠性有何影响；
⑤评估新产品，应选择哪些服务器硬件或软件；
⑥度量系统容量，在没有显著性能下降的前提下，系统能够处理多大的负载；
⑦确定瓶颈，哪些因素会延长响应时间。
确定测试的时间
负载测试应贯穿于产品的整个生命周期。如下表说明了在产品生命周期的各个阶段有哪些类型的测试与之相关。
产品生命周期与测试类型
计划方案实施
下一步是确定如何实现测试目标。
定义性能度量的范围
可以度量应用程序中不同点的响应时间。根据测试目标确定在哪里运行Vuser（虚拟用户）以及运行哪些Vuser。
. 度量端到端的响应时间。
可以在前端运行GUI Vuser（图形用户界面用户）或RTE Vuser（终端用户）来度量典型用户的响应时间。GUI Vuser可以将输入提交给客户端应用程序并从该应用程序接收输出，以模拟实际用户；RTE Vuser则向基于字符的应用程序提交输入，并从该应用程序接收输出，以模拟实际用户。
可以在前端运行GUI或RTE Vuser来度量跨越整个网络（包括终端仿真器或GUI前端、网络和服务器）的响应时间。如下图所示为端到端的响应时间。
端到端的响应时间
. 度量网络和服务器响应时间。
可以通过在客户机运行Vuser（非GUI或RTE Vuser）来度量网络和服务器的响应时间（不包括GUI前端的响应时间）。Vuser模拟客户端对服务器的进程调用，但不包括用户界面部分。在客户机运行大量Vuser时，可以度量负载对网络和服务器响应时间的影响。如下图所示为网络和服务器的响应时间。
网络和服务器的响应时间
. 度量GUI响应时间。
可以通过减去前两个度量值，来确定客户端应用程序界面对响应时间的影响。GUI响应时间=端到端响应时间-网络和服务器响应时间。如下图所示为GUI响应时间。
GUI响应时间
. 度量服务器响应时间。
可以度量服务器响应请求（不跨越整个网络）所花费的时间。通过在与服务器直接相连的计算机上运行Vuser，可以度量服务器性能。如下图所示为服务器响应时间。
服务器响应时间
. 度量中间件到服务器的响应时间。
如果可以访问中间件及其API，便可以度量服务器到中间件的响应时间。可以使用中间件API创建Vuser，来度量中间件到服务器的性能。如下图所示为中间件到服务器响应时间。
定义Vuser活动
根据对Vuser类型的分析以及它们的典型任务和测试目标来创建Vuser脚本。由于Vuser模拟典型最终用户的操作，因此Vuser脚本应包括典型的最终用户任务。例如，要模拟联机银行客户端，应该创建一个执行典型银行任务的Vuser脚本。需要浏览经常访问的页面，以转移现金或支票余额。
中间件到服务器响应时间
根据测试目标确定要衡量的任务，并定义这些任务的事务。这些事务度量服务器响应Vuser提交的任务所花费的时间（端到端时间）。例如，要查看提供账户余额查询的银行Web服务器的响应时间，则应在Vuser脚本中为该任务定义一个事务。
此外，可以通过在脚本中使用集合点来模拟峰值期活动。集合点指示多个Vuser在同一时刻执行任务。例如，可以定义一个集合点，以模拟70个用户同时更新账户信息的情况。
选择Vuser
确定用于测试的硬件配置之前，应该先确定需要的Vuser的数量和类型。要确定运行多少个Vuser和哪些类型的Vuser，请综合考虑测试目标来查看典型的使用模型。以下是一些一般性规则：
. 使用一个或几个GUI用户来模拟每一种类型的典型用户连接；
. 使用RTE Vuser来模拟终端用户；
. 运行多个非GUI或非RTE Vuser来生成每个用户类型的其余负载。
例如，假设有五种类型的用户，每种用户执行一个不同的业务流程，如下表所示。
Vuser的数量和类型
选择测试硬件和软件
硬件和软件应该具有强大的性能和足够快的运行速度，以模拟所需数量的虚拟用户。
在确定计算机的数量和正确的配置时，请考虑以下事项。
. 建议在一台单独的计算机上运行测试工具主控台。
. 在一台Windows计算机只能运行一个GUI Vuser；而在一台UNIX计算机上则可以运行几个GUI Vuser。
. GUI Vuser测试计算机的配置应该尽量与实际用户的计算机配置相同。
关于每个测试组件的硬件要求，请参考下表一和下表二。要获得最佳性能，应满足表中所列要求。
测试机硬件与软件要求（Windows配置要求）
注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
有关最新的安装要求，请访问
测试机硬件与软件要求（UNIX配置要求）
注意：对于一个要运行许多事务的长方案，结果文件需要几个MB的磁盘空间。负载生成器计算机还需要几个MB的磁盘空间来存储临时文件（如果没有NFS）。有关运行时文件存储的详细信息，请参阅第10章“配置方案”。
检查测试目标
测试计划应该基于明确定义的测试目标。下面概述了常规的测试目标。
①度量最终用户响应时间。
②定义最优的硬件配置。
③检查可靠性。
④查看硬件或软件升级。
⑤评估新产品。
⑥确定瓶颈。
⑦度量系统容量。
度量最终用户响应时间
查看用户执行业务流程以及从服务器得到响应所花费的时间。例如，假设想要检测：系统在正常的负载情况下运行时，最终用户能否在20秒内得到所有请求的响应。如下图显示了一个银行应用程序的负载和响应时间度量之间的关系。
负载和响应时间度量关系
定义最优的硬件配置
检测各项系统配置（内存、CPU速度、缓存、适配器、调制解调器）对性能的影响。了解系统体系结构并测试了应用程序响应时间后，可以度量不同系统配置下的应用程序响应时间，从而确定哪一种设置能够提供理想的性能级别。
例如，可以设置三种不同的服务器配置，并针对各个配置运行相同的测试，以确定性能上的差异。
. 配置1：200MHz、64MB RAM。
. 配置2：200MHz、128MB RAM。
. 配置3：266MHz、128MB RAM。
检查可靠性
确定系统在连续的高工作负载下的稳定性级别。可以创建系统负载：强制系统在短时间内处理大量任务，来模拟系统在数周或数月的时间内通常会遇到的活动类型。
查看硬件或软件升级
执行回归测试，以便对新旧版本的硬件或软件进行比较。可以查看软件或硬件升级对响应时间（基准）和可靠性的影响。应用程序回归测试需要查看新版本的效率和可靠性是否与旧版本相同。
评估新产品
可以运行测试，以评估单个产品和子系统在产品生命周期中的计划阶段和设计阶段的表现。例如，可以根据评估测试来选择服务器的硬件或数据库套件。
确定瓶颈
可以运行测试以确定系统的瓶颈，并确定哪些因素导致性能下降，例如，文件锁定、资源争用和网络过载。使用负载压力测试工具，以及网络和计算机监视工具以生成负载，并度量系统中不同点的性能。如下图所示为系统不同点的性能。
系统不同点的性能
度量系统容量
度量系统容量，并确定系统在不降低性能的前提下能提供多少额外容量。要查看容量，可以查看现有系统中性能与负载间的关系，并确定出现响应时间显著延长的位置。该处通常称为响应时间曲线的“拐点”。确定了当前容量后，便可以确定是否需要增加资源以支持额外的用户。如下图所示为响应时间与负载关系。
响应时间与负载关系
2780
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
