一旦将资产保留到团队中所有 SOAtest 用户都能访问的资源库中，我们建议根据不同团队成员的角色定义工作流程。

开发人员

除了单元测试框架（如 JUnit 和 NUnit），开发人员还需要一个功能测试框架，这样他们就能根据一组基本测试对系统的功能进行阶段性测试。实际上，敏捷开发模式和 TDD（测试驱动开发）方法通常都需要采用这种做法。

开发人员的测试工作可以而且理应超越开发团队范围。由于开发人员最熟悉被测系统技术方面的内容，因此早已做好充分准备，能够通过提供功能测试的初始构件要素来启动测试流程。例如，这可能包括定义以下构建块：

• 对 WSDL、WADL、OpenAPI/Swagger 或 RAML 定义中的 web 服务进行初始测试，使用的是服务有望正确处理的基本参数值。
• Web 站点的主要用例流程。
• 在 SOAtest DB 工具中使用的最初配置的数据库连接设置（包括示例查询）。
• 工作的 JMS/JNDI 设置。

此类初始测试工件使开发人员能够向 QA 人员提供有关如何测试系统的实时和可实行的说明，从而取代并改进通常使用的“静态”说明（如带有 XML 消息示例的 Word 文档或带有说明的维基信息）。

因此，Parasoft 建议开发人员最好与 QA 人员一样能够访问测试项目，从而为 QA 人员提供测试工件，使其能够在此基础上进行构建。这样，QA 人员就能专注于系统的业务需求：最终用户体验，而不是连接设置、URL、消息示例等技术问题。通常情况下，开发人员所做的测试可能非常基础，涵盖主要的积极路径用例。他们往往会建立起一些构建要素，至少在基本层面表明系统是否有效。

质量保证

在推荐的工作流程中，质量保证团队的成员利用开发人员创建的测试示例更新他们的工作空间，并在此基础上围绕系统设计各种用例场景，以发现不生效的部分。这可能包括：

• 使用数据源扩展测试用例，以提高测试覆盖率。
• 设计负面场景（错误条件测试用例）。
• 创建用例场景测试，以验证系统是否符合所有已定义的最终用户需求。
• 设计可跨越多个应用程序的端到端业务流程测试。
• 定义测试成功标准和验证断言。

QA 人员创建的测试应提交到共享资源库，以便开发人员也能执行。这样，开发人员就可以使用测试用例来重现系统中的问题，调试问题，在对代码进行修改后立即对修改进行验证，而不必等待 QA 人员在下一个版本重新运行测试。

安全测试

虽然许多企业倾向于将这一关键实践作为生命周期后期的审查工作，但包括 Parasoft 在内的大多数安全专家都建议将安全审查集成到开发生命周期的各个阶段。Parasoft 解决方案框架遵循便是这一理念。 

Parasoft SOAtest 使用安全相关验证（包括静态分析和渗透测试）来增强现有的功能测试案例。承担安全验证责任的工程师（可能是开发人员、QA 人员或专门的团队）可以在功能测试的基础上配置安全性渗透测试。这也是为什么需要共享测试工件的另一个原因，也是为什么在共享工作空间进行协作十分明智的原因。

完整内容，请参阅安全测试。

负载和性能测试

一些公司拥有集中的负载和性能团队，可以访问适合运行实际负载测试的硬件和预发布环境。其他公司则让项目团队开展这项活动。或者有的公司会同时采用以上两种方案，但在规模、生命周期阶段和测试频率层面有所不同。在所有这些情况下（无论谁设计了负载测试，也无论谁在多大程度上运行了负载测试），访问功能测试项目都十分有益，因为性能测试就是为了在负载条件下运行现有功能测试而设计的。性能测试工程师的任务包括：

• 检索开发人员和测试人员添加到资源库的项目（.tst）文件。
• 使用现有的单元测试和功能测试来定义负载测试方案。
• 定义 QoS（预期服务质量）指标，根据 SLA 验证服务，使用监控器帮助识别瓶颈。
• 将负载测试方案提交到共享资源库。

完整内容，请参阅Load Test。