UML软件测试 计划 设计和执行: 解空间测试常见错误及纠正方法

软件测试 计划 设计和执行

◾计划和组织软件项目中的测试

◾欣赏不同的测试方法

◾创建与包相对应的测试设计

◾为类测试创建测试工具

◾为用例测试创建功能测试用例

◾使用等价分区和边界值创建样本测试数据

◾记录执行测试用例和整理结果的步骤

◾规划运行测试（例如，性能，体积测试）

简介  质量控制（QC），通常称为测试，在任何软件开发和维护项目中都发挥着重要作用。测试的目的是检测错误。这些错误可能发生在需求，设计，模型和程序中。在为检测错误而编写的测试用例中也可能存在错误。测试的主要目的是验证软件程序的正确性。

本章讨论在软件项目中规划和组织测试。此讨论包括创建测试计划和设计，了解测试类型，创建测试数据以及执行测试。

测试项目中的需求测试需要了解正在测试的“内容”，过程规则（即“如何”测试，包括如何对数据进行分类以进行测试），创建测试用例，识别测试工具以及采购测试技能。

◾使用UML进行软件工程有效的测试工件包括测试策略（即，经过仔细考虑和记录良好的方法来测试特定的软件产品），正确记录的测试计划，测试用例（具有正面和负面情景） ，良好的测试架构，测试数据和测试的可追溯性。

详细和单元级测试包括设计和创建“测试类”，它将通过检查算法并通过已经开发的类传递精心构造的数据集来测试实际的解决方案类。设计测试类并将其纳入测试设计中的挑战是本次讨论的重要部分。

在大多数实际项目中，测试可以使用大约三分之一的分配项目时间。但是，在实践中，如果项目时间不足，测试是第一个被削减的活动。这是因为测试的可见影响不会立即感觉到，但通常在系统投入生产之后。因此，重要的是将测试作为整个开发过程的一个组成部分。

 

各种类型的测试图19.1显示了在测试计划期间要考虑的各种类型的测试。这些是：

◾单元测试 - 测试模型和系统中小单元的功能，例如用例和类。单元测试通常是代码的技术测试，它们需要编写测试工具并创建测试数据。

◾组件测试 - 测试包含多个类的整个组件或子系统的功能。

◾系统测试 - 测试整个系统的功能以及系统组件之间的相互依赖性。当项目达到此系统测试级别时，它还可以进行全面性能和负载测试。

◾集成测试 - 测试整个系统及其与已在生产中的所有其他系统和数据库的接口。集成测试受益于现有的企业体系结构，该体系结构提供有关所有现有系统及其彼此对齐的信息。

◾验收测试 - 系统用户在接受系统之前独立于开发人员进行。开发人员可以回答查询，设置测试环境并支持用户;但是他们没有证明他们的工作是合理的 - 相反，项目团队一起研究验收测试结果，以确定改进的潜力。

◾操作测试 - 在系统运行时测试系统的功能。操作要求（也称为非功能性要求或NFR并在第20章中讨论）包括性能，数量，安全性和可扩展性，仅举几例。操作测试需要尽可能复制系统实际负载的测试数据库和环境。

◾回归测试 - 在系统的任何软件包中修复错误后在整个系统上执行。回归测试可以在开发期间以及系统运行期间进行。回归测试不仅可以确保系统中新固定的部分正常工作，而且系统的现有功能也不会受到新修复的影响。自动化测试工具在确保有效且高效地执行回归测试方面发挥着重要作用。

◾安全测试 - 虽然被视为操作测试的一部分，但安全测试与图19.1中的其他测试正交。这是因为安全测试需要在软件解决方案的任何和所有测试阶段进行。从单元测试开始，解决方案的安全性需要在开发的所有其他阶段进行测试。

渗透测试，防御和攻击性黑客测试以及功能安全检查是此安全测试的一部分 - 这在本质上变得非常技术性。

向利益相关者正式报告测试结果，可以了解项目的状态，系统在生产中的可靠性，以及是否需要制定任何战略决策，特别是与系统发布相关的决策（例如延迟发布)。

 

测试策略影响因素

测试的战略方面包括在项目中讨论测试范围，所需资源的时间和成本，从哪里获取资源以及其他高级复杂性。

在测试计划中还考虑了与不测试解决方案的某些部分相关的风险以及缺陷优先级划分的成本。尽管测试本身具有战术性，但在项目开始时需要采用战略方法来为软件解决方案提供高质量的好处。

基于UML的项目类型会影响测试计划的创建。例如，集成项目的测试计划侧重于新开发的系统和相应的遗留应用程序之间的接口。包实施项目的测试计划侧重于测试用例的准确性和相关性。

项目的规模也会影响测试方法。对于较大的项目，更大的系统测试生命周期必须考虑测试导致的返工成本和时间。

在大型项目中，一旦开发出第一个包，测试就会开始，因此，它是迭代和增量开发生命周期的一部分。另一方面，小型项目可能专注于对整个产品的一次性测试;与大型项目相比，小型项目可能只有相对较少的演练和检查。

项目的重要性在质量控制中也很重要。在完成系统的基本测试之后，可以缩小测试范围以仅关注关键

对于具有广泛法规遵从性，需要审核和外部批准的项目，可以使用基于缺陷的优先​​级排序方法。

组织软件测试组织测试功能从软件项目的早期阶段开始。测试策略定义测试类型，预期结果，测试如何完成，测试何时发生，使用的工具，角色和职责，报告和验收标准。最终批准测试结果的关键角色和责任也是测试策略的一部分。

 

图19.2显示了测试计划作为基于测试策略组织测试的关键文档。测试计划包含处于包或子系统级别的测试设计。通过考虑基于用例和基于类的测试（稍后讨论），测试设计受益。最后，测试用例处于详细的单元级别。接下来讨论测试组织的这三个方面。

 

测试计划

测试计划是一个基于测试策略的重要文档。测试计划详细说明了测试所需的资源，安排测试设计和测试用例的时间表，测试工具的采购和使用，以及记录和重新测试错误以及创建和维护测试环境的方法。

一个好的测试计划还规定了要测试的模块的预期工作量以及可用的资源。一个好的测试计划旨在在第一个包实施后立即开始测试活动。这要求在软件过程的初始迭代期间开发测试计划。在创建整体测试计划时，关注软件功能，可靠性和可用性的客户导向外部产品属性（Younessi，2002）1也很重要。

 

测试计划的时间表（可能在质量或项目计划内）还应包括完成个别测试的具体日期和负责的团队成员。基于云的测试工具提供了一个数据库，用于记录和报告软件事件，并能够对测试结果进行分析，并对与测试相关的风险进行有根据的猜测。

 

测试计划中应包含以下详细信息：

◾进行测试的目的或目的;虽然这通常很简单（提高质量和减少错误），但测试可以采取各种形式并具有各种目标（例如，确保软件包符合法规要求或测试性能以确定来自第三方的服务质量供应商）。

◾参与测试的人员和流程 - 这些是用于测试的资源，来源的地方（例如，内部，外部）以及他们的技能水平;更新人员技能以确保其符合测试需求是项目计划此部分的一部分。

◾整体验收标准 - 与整个测试过程的目标相似，验收标准也是测试计划文件中的一个战略部分。这是描述用户在什么条件下“接受”系统的声明。

◾测试设计列表 - 源自用于创建整个测试环境的过程，这些测试设计通常映射到软件模型中的软件包。测试设计包含处理测试软件解决方案的包和子系统的特定信息。

◾详细用于测试的方法和过程 - 这些是用于测试软件解决方案的活动和任务的描述。标准（如ISTQB和ISO9001）可以为测试中使用的方法和方法提供输入。

◾基于垂直 - 水平，黑白框等组合的测试方法（本章稍后将详细介绍）。

◾通过可追溯性矩阵跟踪测试到其原始要求的方法。

◾基于可用资源，开发进展情况（例如，交互，增量，并行）的测试职责和时间表将生成在整个系统开发之前准备好进行测试的模块。

◾报告错误和重新测试的方法 - 这是对如何进行重新测试和回归测试（即在错误/错误的一部分修复后对解决方案进行全面测试）的描述。为重新测试做准备是一项具有挑战性的项目管理工作，因为很难预测在软件开发练习的测试阶段会发现什么。

 

可追溯性矩阵

 

可追溯性矩阵被视为测试计划的一部分。然而，这个矩阵非常重要，可以成为它自己的独立文件。 treacability矩阵由质量经理和用户共同拥有。但是，对于较小的项目，此矩阵可以是前面提到的测试计划的一部分。

顾名思义，可追溯性矩阵将测试用例跟踪到正在测试的相应需求的来源 - 主要是用例。可追溯性矩阵揭示了一个需求是否可以追溯到测试用例。如果没有，则测试用例不足或者某些要求未得到满足。建模工具通常提供可跟踪性工具，可用于报告此活动。可追溯性是一项持续的活动，从第一次迭代测试用例创建开始。

 

 

设计的软件工程用例和类在软件建模中主要有不同的焦点 - 用例关注问题空间中的需求和解决方案空间中的设计类。此外，用例和类之间的关系是多对多的，如图19.3所示。这两个关键软件建模元素的测试设计需要考虑上述因素以及测试设计中用例和类测试之间的潜在重叠。

 

类，特别是在解决方案领域，由解决方案设计人员拥有。问题空间中的用例更接近用户和业务分析师。由于这种划分，属于用户和业务分析师的验收测试用例侧重于测试用例质量，而技术测试用例包括编写测试工具。测试工具是一组类，仅用于通过自动传递测试数据和执行功能来测试主类。测试工具通过测试数据处理和处理能力来测试系统中的所有类。

 

测试设计还关注系统的单独可执行部分 - 例如，诸如包之类的子系统。这一焦点导致了一种测试方法和一组特定于特定包的测试用例。例如，患者包的测试设计验证并验证创建和管理患者详细信息的所有方面，而数据库包的测试设计包含验证和验证医院管理系统（HMS）数据库的性能和安全性方面的测试用例。

 

 

与每个包相对应的测试设计还考虑了要测试的类的数量及其相应的复杂性。对于每个类，有许多测试用例测试不同的功能。

测试设计进一步整合了额外的测试用例，这些测试用例涉及测试整个组件或包，而不是针对各个类。例如，测试设计中的一组测试用例测试Date类，另一组测试用例可以测试Account类。但是，一个好的测试设计可以确保有额外的测试用例来测试两个类的工作以及它们一起提供给调用类的结果。

Class 1 Class 2 Class 3 Class 4 Class 5使用案例1使用案例2使用案例3使用案例4技术测试用例测试一个类的所有操作;因此，它导致对许多用例的一些功能的测试。此技术测试不同于验收测试，其中测试单元是用例而非类。

图19.3基于用例和基于类的测试设计。

测试方法

 

测试方法是测试策略的一部分。测试方法有助于确定要设计的测试类型，为测试创建的数据类型以及进行测试所需人员的技能。

项目的类型和大小以及被测试类的重要性对于使测试人员能够开发出合理的测试方法起着重要作用。这里讨论的测试方法并不是彼此独有的。大多数测试设计都包含了此处讨论的每种测试方法的某些方面。在创建测试设计时牢记测试方法使它们更加详尽和准确。

 

图19.4突出显示了不同的测试方法。这些方法涉及：

◾测试黑盒与白盒测试的可见性

◾自动化测试 - 进行手动测试与使用自动测试工具

◾切片测试 - 垂直（功能）或水平（技术）

◾数据等价分区和边界值的分区

 

下面将进一步详细讨论这些方法。

测试的可见性 - 黑盒与白盒测试黑盒白盒测试涉及被测元素的开放性或封闭性。

黑盒测试仅涉及系统的输入和输出，而白盒测试则用于详细检查软件的功能和过程中的逻辑。白盒方法非常适合验证类设计的内部细节;黑盒测试用于用例的验收测试。

测试手册与自动手册或自动化测试的自动化基于测试中使用的人员和工具。在手动测试中，测试人员在物理上执行测试用例并手动检查结果。相反，在水平手动白框[可见性] [分区] [自动化]边界值等效分区黑盒自动[切片]测试方法垂直图19.4测试方法。

 

自动化测试工具用于验证软件。自动化测试可以帮助进行回归测试 - 其中系统的所有部分都经过测试（即使它们没有改变），以确保系统某个部分的更改不会在其他部分中产生错误。

切片测试 - 垂直（功能）或水平（技术）垂直或水平测试表示系统的行为与技术切片以进行测试。

系统的垂直划分意味着将其从应用程序的角度划分为子系统，并将这些划分结合到测试设计中。例如，分为患者，咨询和工作人员的医院应用程序仅针对这些包进行测试。

测试的水平切片 基于其基础设施而不是其功能。例如，用于测试HMS的水平切片意味着首先测试整个系统仅用于数据，然后测试业务对象以及跨所有包和程序的GUI切割。

数据等效分区和边界值的划分 等价划分和边界值表示如何对测试数据进行抽样测试（Meyers，1979）.2等价划分适用于构成数据实体的任何变量。将所有可用数据划分为相等的分区，然后选择来自每个分区的样本以创建用于测试的样本数据集。等价分区的边缘是边界值。因此，基于边界值的测试数据由来自分区边缘的数据组成。

 

测试架构图19.5显示了测试HMS时使用的测试类的技术架构。

 

该图显示了全面测试架构的一小部分，并突出了精心设计的测试架构（几乎就像设计系统本身的一部分一样）。图19.5中的所有类都被定型为<< tester >>，将它们分类为负责测试的类。

图19.5显示了HMSbaseTester类，它是一个抽象类。该类将包含测试所需的常用功能。它们是createTestObject（），runTest（）和updateTestResults（）。这些操作由较低级别的操作重载。

第二级类也适用于系统中每个类的构造型，它们是BoundaryTester，EntityTester和TableTester。这些类被赋予了测试这些特定类的类的通用函数。例如，BoundaryTester具有处理显示表单，填充数据以及验证表单上的字段的功能。 EntityTester类具有实体类所需的最常用函数，例如get（）和set（）函数，而从EntityTester派生的类具有自己的特定函数来测试实际实体类的业务逻辑; TableTester处理在实际系统中测试数据库类所需的常用函数，因此可能包含与加载数据库相关的函数，然后检查CRUD功能（创建 - 读取 - 更新 - 删除功能，在第13章中讨论）以及检查数据完整性。但是，这三个类位于测试体系结构的中间层。

软件测试

319图19.5还显示了CustSubsystemTesterandScheduleSubsystemTester类。这些是超类，它们代表需要针对相应的患者和计划包进行测试的基本功能。为每个包创建了这样的超类，并赋予该包的通用测试功能。

测试设计解决方案空间中的测试设计测试设计是基于对子系统或组件级别的系统的理解而创建的。封装为测试设计提供了一个起点。测试设计提供了所需功能的广泛覆盖，而不是系统中每个单元的低级测试用例。封装图以及MOPS中的用例文档所产生的测试设计确保了接近测试的模块化。用户也可以参与这些测试设计，然后可以用于进行验收测试。

测试设计格式测试设计的典型格式包含以下内容：

◾名称 - 这标识了所考虑的测试设计，可以存储为文档。理想情况下，该名称应反映测试设计的性质。它可能是TestPatient中以“Test”为前缀的包的名称。

HMS的常见测试功能将由真实测试人员重载。

<< tester >> << tester >> << tester >> << tester >> << tester >> << tester >> << tester >> loadTestData（）loadTestData（）BoundaryTester EntityTester TableTester PatientFormsTest一个可选的额外图层测试架构？是层相当于基测试仪类HMS PatientSubsystemTester ScheduleSubsystemTester loadTestData（每包）createTestObject（）loadTestData（）displayTestForm（）loadTestData（）HMSbaseTester createTestObject（）的runTest（）updateTestResult（）图19.5的可能的测试体系结构HMS 。

 

◾模块 - 指示由测试设计指定的目标系统中的子系统，封装或任何其他模块的详细信息。它包含要测试的软件包类型的简要说明，软件包所需的准备工作（例如，创建测试数据或获取域专家的服务），以及所需的各种类型的测试用例。

 

◾依赖性 - 指示此测试设计所依赖的其他测试设计。这在创建测试周期时很有用，或者可以根据测试周期创建测试设计本身。例如，TestPatient测试设计的依赖关系是TestConsultation，理想情况下，在测试整个系统的用户代码和密码之后，应该测试客户端的创建和维护。

 

◾测试用例列表 - 这是构成测试设计的测试用例列表。属于此测试设计的所有测试用例都与简短的单行描述一起列出。测试用例可以根据测试设计的需要进行编号和分组（例如，所有接口测试用例可以在测试设计文档中分组，与所有数据库访问测试用例分开）。

 

测试设计专注于解决方案领域的包装。一旦实现，包（或子系统）被认为是系统的单独可执行部分。这要求测试设计考虑测试包的方法，所需的数据类型，包与其他包的依赖性以及包的操作要求。这导致列出并理解包中每个构造型的类的数量。测试设计还可能导致在每个包中创建单独的测试包或在系统中创建单独的测试包。

组件的测试设计由于组件是包中的可执行代码单元，因此测试设计也用于单个组件。此外，测试设计包含组件内各个类的测试用例。因此，必须测试组件内的组件和类之间的依赖性，并且需要将其合并到测试设计中。此外，有时两个或多个类之间的操作也可能彼此依赖（通常通过序列图指定），需要仔细创建处理此依赖关系的测试用例。

测试整个组件需要额外的测试用例 - 而不是单个类。例如，测试设计中的一组测试用例可以测试Date类，另一组测试用例可以测试Schedule类。良好的测试设计可确保第三组测试用例根据Date类中输入的有效和无效数据测试计划的工作情况。

因此，较早的测试用例被认为是类的单元测试，而后面描述的测试用例是基于系统中某些功能的测试用例，该功能超出了类的单独操作，即调度程序接受有效日期和一定范围。这种相互依赖性的概念在测试设计中得到了扩展，包括相互依赖的多种类型的组件，组件和包。

测试设计中的可重用性测试体系结构和设计中的可重用性意味着基类增强了测试设计人员提供一套良好的测试类的能力，这些测试类不仅可以确保全面有效的测试，还可以确保创建测试设计和执行的效率。测试用例。

 

测试设计有助于测试设计人员从过去的项目中学习，并逐步增加他们的测试用例。在软件项目的初始迭代中使用的测试线束和测试用例可以重复用于测试以后的迭代。

注意重用有助于从现有测试台创建测试数据。最后，在测试结果的整理中使用的测试类也有助于重用，因此应该结合到测试架构和设计中。

但是，在考虑重用测试时，重要的是要注意将要重用的类（第15章中讨论的“重用”）需要进行全面测试，不仅要考虑它们当前的功能，还需要通过潜在的重用进行彻底的重用。后续项目中的继承和关联将使用它们（“with reuse”）。

除了详细测试可重用的类之外​​，还必须为这些类的用户（使用者）提供扩展测试类以创建自己的测试类的机会。因此，对于可重用的类库，还应提供一套适合重用的测试类。

解决方案空间中的测试用例测试用例构成了测试工作的基础，特别是在解决方案空间中。编写好的测试用例与编写好的用例一样重要。因此，重新讨论第5章是很重要的，其中讨论了编写好的用例。有人提到好的用例是良好测试用例的起点。这是因为验收测试用例要求测试人员逐步完成用例。

编写测试用例以进行类和组件的技术测试。这些测试用例是基于一小段测试代码的技术测试的基本单元。测试用例还测试正在开发的软件的基本单元。因此，测试用例将记录为进行一类测试所采取的步骤。

测试用例格式记录测试用例的格式取决于测试的内容。例如，测试GUI的测试用例的测试格式与测试数据库的测试用例不同。以下是可以扩展并用于设计的通用测试用例格式：

◾标识 - 用于标识测试用例的名称和编号

◾目的 - 测试的原因（例如，验证业务逻辑或检查屏幕上字段的有效性）。这个目的可能决定了测试者类的类型。

 

◾先决条件 - 可以在执行测试之前必需的元素。这些先决条件与特定测试用例有关。模块的整个测试设计的先决条件单独记录。

 

◾输入 - 输入系统的数据，由有效和无效的测试数据组成。

 

◾行动 - 测试人员进行测试所需的活动或步骤。对于技术测试用例，可能不需要详细操作，因为这些操作是测试工具的一部分。

 

◾预期输出 - 确定测试是成功还是失败。

 

◾实际输出 - 或占位符，用于在测试用例执行时记录结果。

 

◾例如，执行测试的测试人员的管理细节。

 

在成功测试中，创建良好的测试数据样本非常重要。每个测试用例和测试设计都应该能够从广泛的数据中提取，以创建样本测试数据。每个测试设计还应该能够将实际输出与预期输出相匹配，尤其是在自动测试中。

测试数据是一个输入文件，包含由有效和无效输入组成的大量数据记录。表19.1提供了这两个重要数据类别的示例。

这些是Patient类的输入数据，测试其“Patient Medicare Insurance Number” - 一个六位INTEGER字段。有效输入确保类能够接受并处理它要接受的输入。无效输入测试类拒绝不接受的输入的能力。

这两组数据输入到输入文件中，相应的一组预期结果输入另一个文件中。然后可以将实际输出与该预期结果文件进行匹配，以确保验证测试结果。测试工具使用这种方法不仅可以进行常规测试，还可以进行回归测试，这需要进行大量不需要人工干预的常规测试。

屏蔽和混合测试数据对于某些测试，数据泄漏和隐私等问题值得关注。谁可以测试以及他们可以测试什么是重要的。因此，在执行测试之前，需要屏蔽帐号，名称和其他标识源等详细信息。例如，信用卡号1234 1234 1234 1234将被屏蔽为xxxx xxxx xxxx xx34。同样，只提供护照号码的最后一位数字。与掩蔽相关的是数据的混合。这合并了数据和替换，例如真实姓名和假名。屏蔽和混合的代码本身已经过测试，以确保结果正确并且不会导致错误的测试结果。

医院管理系统的验收测试用例以下部分包含HMS的验收测试用例。这些测试用例归用户和业务分析师所有。它们基于相应的用例（在第5章中讨论）。

解决方案空间中基于类的测试用例方法本节讨论解决方案空间中的测试用例。这里的重点是设计级别的技术测试。因此，所有技术测试用例及其相应的测试工具都侧重于测试作为测试单元的类（与上一节中讨论的验收测试中的用例相对）。但是，由于用例和类之间的多对多关系，类的每个测试用例还测试了许多用例的一些功能。基于类的测试对用例的影响如图19.3所示。

测试工具在面向对象的设计中，其他类会为其提供的功能调用类。

此调用由其他类调用该类的操作或方法。类不是自己执行，而是由其他类调用。因此，要启动系统，需要一个起始类。

此起始类取决于操作环境（例如，在Java中，此起点是Java虚拟机中的类加载器，或由语言提供的JVM）。

每次使用JVM并测试整个系统可能既不实际也不必要。

另一方面，可能有必要以最小的级别测试类，因为它是由程序员编写的。在系统的最小单元进行的常规和增量测试要求在类本身中编码一些测试方法。

通过编写测试类来专门调用正在测试的类及其所有操作来实现此要求。这样的测试类称为测试工具。例如，在Java环境中，为了测试Patient类，首先在Patient中创建一个main（）函数。

 

通常，Java应用程序只需要一个类，其主要方法是起点输入操作预期输出实际输出患者登录：P2003付款类型：现金/支票患者登录并显示帐单。在检查细节后，患者将选择支付类型的现金/支票。 （例如PayPal）客户打印的账单作为要结算的发票。

发票编号200303支付金额：$ 3333.00日期：22/11/2004支付方式：现金患者登录：123432患者尝试登录但由于登录不正确而失败。

提示说登录错误。

显示消息：登录无效。

请再试一次。

 

但是，在“起始类”之外的类中使用main方法允许测试代码驻留在类中，因此类可以独立于其他类进行“单元”测试。

上一课显示了Patient类的所有功能将如何进行测试。创建测试工具，发送测试消息，以及可选地自动记录结果，如图19.6中的序列图所示。如图所示，测试线束确保测试类的每个操作。但是，测试工具应该集中精力彻底测试其实现可能随时间变化的功能，以允许功能的可扩展性，从而实现系统的可扩展性。这是因为函数的可变性很可能在系统中产生错误而不是标准函数。

验证测试用例一旦以指定的格式设计和创建测试用例，就必须验证测试用例是否正确。如果计算和其他输出没有改变，可以根据现有系统的结果对它们进行交叉检查，或者可以根据样本手动输出和系统专家用户执行的其他计算来验证输出。

研讨会中测试用例的演练对于验证测试用例和测试工具是否正确也非常有用。

示例代码19.1 class Patient {// private：int PatientID;字符串名称;地址;日期出生日期; // operations // public：<< business >> getPatientName（）：BOOL; getSerialNumber（）：BOOL; changeAddress（）：BOOL; << maths >> calculateAge（）：AGE; - << database >> saveDetails（Sno，Details）：Void; - // test operations static void main（String args []）aPatient = New Patient; aPatient.getPatientName（）; aPatient.getSerialNumber（）; aPatient.changeAddress（）; aPatient.calculateAge（）; aPatient.saveDetails（）;软件测试

◾329运行（NFR）测试运行测试是技术测试中的一项单独的专用活动。如前所述，操作测试的设计，编写和执行与类的测试用例非常相似。

操作测试需要单独的方法和设计。因此，整个操作测试分别放在测试包中。第20章讨论的操作（非功能）规范提供了这些测试成功或失败的标准。

一些操作测试一些操作测试包括以下内容：

◾性能测试 - 在各种条件下测试系统的性能。测试工具是测试组件或系统响应时间的有用辅助工具。但是，应在不同的负载条件下计算响应时间。在系统上以最小负载测试响应可能会给出测试成功的错误印象。

 

◾卷测试 - 系统在运行条件下处理特定交易量的能力。卷测试的示例包括系统在其数据库中插入/更新大量数据的能力以及在系统操作期间将数据保存在其实体对象中的能力。

JVM：PatientSubsystemTester createTestObject createPatient（）aPatient：Patient runTest（）getPatientName（）getSerialNumber（）changeAddress（）calculateAge（）saveDetails（）collat​​eResults（）updateResults（）HMStestResult结果类负责存储测试结果测试工具对象测试Patient类的所有操作

 

图19.6描述测试工具行为的序列图。

with UML软件工程

◾安全测试 - 系统通过适当的身份验证和其他安全机制允许或阻止数据的能力。虽然登录和密码是系统功能的常规部分，但安全测试涉及测试可能已在系统中使用的特定安全类和第三方安全组件。

 

◾可扩展性测试 - 系统在可能使用系统的其他功能时处理越来越多的负载的能力。 例如，如果系统今天可以处理500个Patient对象的实例，它可以在一年的时间内容纳50,000个Patient对象的实例吗？ 可扩展性测试的另一个例子是测试系统存储越来越多的数据和越来越多的系统用户的能力。

 

 

 

常见错误	纠正错误	实例
在没有测试“安全带”的情况下测试技术类	编写测试工具以对应技术类。	参见示例代码19.1和关于测试线束的讨论。
忘记测试组件	确保测试设计包括除了类之外的组件测试。	请参阅前面关于测试设计的讨论。
不计划进行运营测试	在测试计划开始时包括操作（NFR）测试。 一旦开发出第一个模块（包），就开始进行操作测试。	请参阅本章中有关操作（NFR）测试的讨论。
不基于用例的验收测试	验收测试由用户在接受系统之前执行。 由于需求是在用例中指定的，因此验收测试必须基于用例。	请参阅本章中HMS验收测试案例。
创建的测试数据不足	确保提供涵盖主要要求的广泛测试数据。	通过从等价分区和边界值中抽样，查看测试数据创建章节中的讨论。
假设所有测试都是手动或自动化的	实际测试是手动和自动测试的平衡。	有关测试方法，请参见图19.4。
不了解正面和负面测试之间的区别	积极测试是班级接受“好”数据的地方; 而负面测试是指班级拒绝“坏”数据的地方	重新讨论有效和无效数据以进行测试。