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. 回归测试

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

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

 

原文转自：http://www.ltesting.net