软件测试是软件开发过程中相对独立的一个环节，目的是审查软件的质量并确定软件的功能是否符合项目初始阶段定义的需求。1990年的IEEE/ANSI（美国电气和电子工程师协会）标准将测试定义为：“在特定条件下运行系统或组件，观察或记录结果，并对系统或组件的某些方面做出评估的过程。”(IEEE/ANSI, 1990 [Std 610.12-1990])这些“特定条件”可以理解为软件需求或设计方案。

V模型软件开发流程

我们采用一种被称为“V”模型的流程进行软件开发。V模型是一种理想的开发模型，可以有效地帮助我们理解软件开发各个阶段之间的关系。V模型是源于软件开发的瀑布模型。流程的三个主要阶段——需求分析、高层设计与详细规格说明——都有对应的验证与确认测试阶段。模块的实现测试由单元测试完成；系统设计测试由集成测试完成；最终用可操作性测试根据需求确定软件能正常工作。V模型的名称就是指这几个阶段的时间安排。从需求分析开始，一步一步地进行系统开发，直到最终的实现阶段完成。而测试就从这个阶段开始，从单元测试，按照流程进行直到可操作性测试结束。根据V模型，测试人员可以在需求分析阶段进入软件开发流程。这样便可以协同工作，并及时发现潜在的问题。这有助于降低开发风险，减少软件修正成本。

什么是测试策略？

为什么要编写测试策略？测试策略就是如何进行软件测试的计划。测试策略的目标包括：

• 取得利益相关者（比如管理部门、开发人员、测试人员、顾客和用户等）的一致性目标；
• 从开始阶段对期望值进行管理；
• 确保“开发方向正确”；
• 确定所有要进行的测试类型。

测试策略为测试提供全局分析，并确定或参考：

• 项目计划、风险和需求；
• 相关的规则、政策或指示；
• 所需过程、标准与模板；
• 支持准则；
• 利益相关者及其测试目标；
• 测试资源与评估；
• 测试层次与阶段；
• 测试环境；
• 各阶段的完成标准；
• 所需的测试文档与检查方法。

Workspace软件介绍

Sybase Workspace是第一个可以按需交付应用类型的集成开发环境（IDE）：面向服务、mobile模式、Java、组合模式（composite）、事件驱动和数据驱动。Sybase Workspace基于Eclipse开源框架，使开发人员可以更容易、更快速地开发连接各种基础设施（比如数据库、消息系统和企业应用程序）的复杂应用程序。

Sybase Workspace填补了以往需要不同厂商的开发工具才能实现开发任务交互的空白。没有其它的集成开发环境提供具有相同深度与广度的功能。

Sybase Workspace由以下六个主要组件构成：企业模型、服务框架、整合与流程安排、数据库开发、Mobile-Portal开发和Web应用程序开发。

Workspace特征分析

从测试的角度来讲，Workspace项目有以下特征：

• 大型项目需要更多的重复性测试。
• 软件结构稳定。
• 对于需要经常进行编译和单元测试的各种版本的软件的编译与发布流程相似。
• 使用大量的组件会提高集合测试过程中产生问题的可能性。

但是，如果对测试策略做以下改动，测试流程就会更加高效。

• 用自动化测试代替大量重复性手动测试。
• 根据测试框架制定单元测试集。
• 添加日常编译、自动化单元集测试和自动化脚本测试。
• 使用更有效和更有价值的分析方法对测试流程进行评估，以避免整合时的高风险。

Workspace测试工作流程

1. 确定需求与设计方案

需求与设计方案的确定将直接影响软件开发。如果软件不能满足顾客的需求，风格再好的程序也毫无价值。为避免这种情况，测试工程师应该参与到需求与设计文档的审核工作中。这些文档包括：

• 项目经理编写的需求说明，包括市场部门与客户支持部门的相关信息。
• 以需求说明为参考的功能设计要求，同样由项目经理编写。
• 由开发人员编写的以功能设计方案为参考的设计方案实现说明。

作为测试工程师，其主要任务就是检查这些文档的完整性、严格性和功能可测试性。这个过程也有助于测试工程师更早地参与项目开发。

 2. 准备测试计划和测试用例

测试计划和测试用例是基于功能设计方案进行编写的。“测试计划”定义了测试的范围、方法、资源和流程。这份计划概括了测试项目、测试质量、测试任务、任务原则和风险。大多数情况下测试计划还包括系统测试。因为单元测试和集合测试是开发人员的责任，开发计划中也可以包括这些项目。对各阶段测试工作量的评估时，可以假设每个阶段所需的时间都是前一阶段的1.1或1.5倍。比如，系统测试时间一般是编程阶段（包括单元测试与集合测试）的1.1到1.5倍。

测试计划中最重要的一个方面便是变量控制。这些变量主要来于项目计划、需求、测试软件版本和测试资源。有效地处理变量可以减少风险。 

测试用例也提供了对测试任务、测试模式、方法、技术和策略的描述。内容涉及测试目标、测试环境、数据输入、测试步骤、预期结果和测试脚本。作为软件测试的关键，测试用例将引导集合测试、系统测试和回归测试的实行。此外，测试用例还可以用来度量测试结果，分析软件缺陷并提高软件质量。为完善测试用例设计，必须抛弃一些关于测试用例的错误观点。测试用例并不是为了检测“异常”缺陷。作为测试的基础，测试用例必须完全覆盖测试需求，也不能以个例为参考。测试用例的详细程度应该考虑到测试人员对软件的熟悉程度，既不能太简单也不能过于详细。测试人员必须明白测试用例是“活的”，它们必须在整个测试过程中及时更新。如果没有根据需求和设计方案同步更新，测试用例将失效。 

因此，任何测试用例都应该添加明显的验证方法。这对测试人员判断输出与预期结果的一致性是必要的。 

同样，项目经理和开发人员也需要对测试计划和测试用例进行审核。这样整个团队才能对项目有个统一的了解。

 3. 测试实现

主要测试流程是根据测试计划执行测试用例程序。这包括编写自动化测试脚本并反复执行这些脚本，也包括执行手工测试用例程序。测试顺序是本着从简单到复杂、从简单功能测试到整体功能测试、从表面bug到深层bug的原则进行的。随着项目开发和测试流程的发展，产品的功能和质量也将提高。因此必须反复执行测试用例以避免质量回归，特别是自动化测试每次进行？连编时。测试人员的另一个任务是维护测试用例。如果根据最初说明文档设计的测试方案中存在问题，或者当前的测试用例没有覆盖顾客反映的一些bug，就应该添加新的测试用例。

自动化测试

为完善Workspace环境下的测试，我们使用IBM RFT（IBM的功能测试工具，Rational Functional Tester）实现自动化测试。

如图3所示，自动化测试过程可以分为两个阶段：

1. 准备脚本

• 开始录制：打开RFT并精确地录制测试用例的相关操作。
• 增强脚本功能：插入验证点、测试参数和If/Else或Loop控制语句提高回归测试自动化性能。
• 调试脚本：调试并验证脚本。

 2. 回归测试

• 执行脚本：通过自动化测试工具，执行脚本并验证软件。
• 结果分析：检查日志文件的执行结果，分析软件的问题并报告。

自动化工具的使用提高了测试的效率，并可使测试人员将更多的注意力放在开发新测试模型和提高测试用例覆盖率上。此外，自动化测试还提供了测试资源的数字化管理方式，这些测试资源还可以在功能测试与回归测试中实现重用。

软件问题报告（SPR）

软件问题报告（SPR）是一份由质量保证工程师（QA）填写的、关于测试中发现的软件问题的正式报告。这种文档有统一的格式。软件问题报告应该包含对软件的问题的描述，帮助开发人员修正并追踪问题。高质量的软件问题报告涉及以下信息：问题ID、主题、详细描述、产品或项目、产品版本、功能或模块、原因、严重性、优先度、附加信息、状态、请求人、请求日期、负责人、解决方案，以及解决方案的版本。

一份软件问题报告从创建到关闭的生命周期内有五个状态：创建、打开、等待验证、解决和关闭。图4显示了各状态之间的转变过程。软件开发过程中的任何一个阶段，不管什么时候发现问题，都应该创建一份软件问题报告并设置为New状态。经质量保证工程师验证并确定是bug后，状态转为打开（Open）。另一方面，如果摄影师保证工程师无法验证问题或确定为bug，状态就转为关闭（Close）。

当开发人员收到软件问题报告时，他应当先尝试报告的重新生成。如果无法做到，他应当建议质量保证工程师验证并关闭报告。否则开发人员应该修正bug，报告修正信息，并将软件问题报告的状态置为等待验证（WaitToVeryfy），以供质量保证工程师进行验证。当质量保证部门确定修正已经解决bug，软件问题报告的状态便转为关闭（Close）。如果他们认为没有解决bug，状态便转为打开（Open）。根据状态表，可以跟踪到每一份软件问题报告并确定其得到解决。

测试评估方法

 1. 测试用例优先级分析

如果没有足够时间执行硬指标测试任务，则需要有可以分析测试用例优先级的方法，以保证首先执行最重要的测试用例。为此，我们需要定义每个测试用例的优先级。

我们定义“功能优先级”和“内容优先级”，然后将这两项相乘得到各测试用例的最终优先级。 
功能优先级：

• 3 重要功能；
• 2 一般功能；
• 1 很少用到的功能；

 内容优先级：

• 3 一般内容；
• 2 重要的异常功能；
• 1 不重要的异常功能；

测试用例优先级＝功能优先级*内容优先级；

 2. 测试覆盖率

测试覆盖度是对测试完整性的评估，可以通过对测试需求和测试用例或执行代码的覆盖计算获得。根据覆盖率指数我们可以回答下面的问题：“测试的完整性程度怎样？”

• 基于需求的测试覆盖率

基于需求的测试覆盖率应该经过多次计算，特别是如果要用其作为测试周期重要阶段的覆盖标志（比如计划、实现、执行和取得的测试覆盖度）。

测试覆盖率＝T(p,I,x,s)/RfT;

“T”指测试过程或测试用例中描述的测试的数量（包括planned, implemented, executed或succeeded）。“RfT”指测试需求的总和。

• 基于内容的测试覆盖率

基于内容的测试覆盖率是用来评估执行代码数量的，对应剩余代码的数量。代码覆盖度应该建立在控制流（语句、分支或路径）或数据流上。可以用以下公式计算：

测试覆盖率＝Ie/TIic；

“Ie”是指用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数量。“TIic”是代码中项目总和。 

比如，要计算语句覆盖以度量是否每条可执行语句都得到执行，参数“Ie”就指已经执行的代码语句数量，“TIic”就是软件中所有代码语句的数量。两个参数的比值即为测试语句覆盖率。在黑盒测试中，我们可以用IBM RPC工具迅速得到这个结果。

3. 对软件问题报告信息的分析

在整个软件测试过程中，我们可以得到许多关于软件问题报告和修正程序的信息。通过分析这些信息，我们可以提取出更有价值的信息，跟上工作进度并制定决策。

• 根据级别或类型对问题进行分类

通过分类得到的关于问题的信息的统计数据可以从整体上反映出问题的表现状态。这些数据可以告诉我们哪个才是众多问题的解决关键。

• 新问题的时间分布

通过分析新问题和研究新问题的分布状态是很有用的。如果分布曲线显示最近稳定性渐趋平稳，就表明软件稳定性在逐渐提高；如果临近开发最终期限时曲线仍有较大的波动，就需要考虑延缓发布时间，并花更多时间寻找原因。

• 修正率

这可以反映开发人员的修正效率；也可以用来作为性能评估指数，开发人员在执行单元测试时也必须更加认真。

• 测试延迟曲线

图5显示的是测试延迟曲线。其中蓝色曲线表示程序交付日期，红色曲线表示测试完成日期。两条曲线之间的间隔即为“测试”与“程序交付”之间的时间延迟。间隔越大，测试效率越低。在这张图中，第五次和第六次测试延迟时间较其它更长。

• 修正延迟曲线

图6显示的是修正延迟曲线。其中红色曲线代表问题提交的日期，蓝色曲线代表修正完成的日期。这两条曲线之间的间隔显示了“修正”与“问题提交”之间的延迟状态。如果间隔变大，则表明修正时间变长，修正效率变低。在这张图中，有三个阶段的延迟比较大。

测试工作流程监控

为提高开发人员与测试人员的协作性，取得一致的软件质量评估标准，可以在管理过程使用过程监控方法。这表示可以让第三方团队进行工作监控，第三方可以是软件测试部门主管，或者软件质量保证部门（SQA)的某位工作人员或主管。根据项目的不同阶段，我们将监控方法按时间分为三个部分：测试开始阶段、测试实现阶段和测试结束阶段。

1. 测试开始阶段

• 测试工作有特定的工作范围吗？
• 需要测试的软件有特定的环境指数吗？
• 测试工作有特定的阶段划分吗（比如单元、集成、系统和接受等）？各个阶段有特定的交付条件吗？
• 公司确定了顾客的接受程度与范围吗？软件安装与维护有没有特定的成功或失败标准？

2. 测试实现阶段

• 缺陷管理工作流程是否标准？是否可以在提交和关闭前进行缺陷再检查？
• 配置管理工作是否标准？是否可以完全追踪到测试过程中的所有相关版本？测试版本的更新频率是否满足实际需求？
• 是否能够及时获得关键测试所需的资源？如果不能，有可接受的计划完成延迟的工作吗？
• 测试策略、测试计划和测试用例能通过审核吗？里面的问题都得到解决了吗？
• 所有的测试文档已经根据实际情况更新了吗？严格执行过了吗？
• 根据初始测试安排制定的后面的测试计划有没有什么遗漏的地方？
• 测试过程是否符合公司计划安排？

3. 测试结束阶段

• 测试覆盖中的缺陷趋势曲线走向平稳吗？不同模型的趋势曲线是否一致？
• 有没有正式的文档判定产品是否可以交付给顾客？
• 最后有没有正式的评估会议要举行？顾客会参加会议吗？是不是所有遗留的问题都有确切的解决方案？是否每个问题都有解决与跟踪的原理？
• 软件是否符合初期建立的交付条件？