一旦资产持续化到团队的所有 SOAtest 用户可以访问的资源库中，我们建议您根据不同团队成员的角色来定义工作流。

开发人员

除了像 Junit 和 Nunit 这样的单元测试框架外，开发人员还需要功能测试框架，以便可以根据一组基本测试对系统的功能进行分级。事实上，在敏捷开发模型和 TDD（Test Driven Development，测试驱动开发）方法中，经常需要这样的实践。

开发人员的测试工作可以而且应该在开发团队之外使用。由于开发人员最熟悉测试系统的技术方面，所以他们准备好通过提供功能测试的初始构建块来启动测试进程。例如，这可能包括定义构建块，如：

• 来自 WSDL, WADL, OpenAPI/Swagger, 或 RAML 定义的 web 服务的初始测试—使用服务期望正确处理的基本参数值。
• 主要用例流经 Web 站点。
• 初始配置的数据库连接设置，带有示例查询，用于 SOAtest DB 工具中。
• 使用 JMS/JNDI 设置。

这样的初始测试构件允许开发人员向 QA 提供关于如何测试系统的一个实时并可执行的说明，替换和改进常用的“static”说明（比如，带示例 XML 消息的 Word 文档或带有说明的 wikis）。

因此，Parasoft 通常会推荐开发人员对与 QA 相同的测试项目进行访问，以将 QA 和他们可以构建的测试构件结合起来。这使 QA 能够专注于系统的业务需求：终端用户体验而不是像连接设置、URL、示例消息等之类的技术问题。通常情况下，开发人员生成的测试可以非常基础，并涵盖主要的正向路径用例。他们倾向于建立构建块，该构建块指明系统是否运行，至少在基本级别上是这样。

质量保证

在推荐的工作流中，QA 团队成员使用开发人员创建的示例测试来更新工作空间，以及使用该基础围绕系统来设计各种用例场景，以便发现什么不起作用。这可能包括：

• 使用数据源延伸测试用例，以便增加测试覆盖率。
• 设计负向场景（比如，错误条件测试用例）。
• 创建用例场景测试，以验证该系统是否符合所有定义的终端用户需求。
• 设计可以跨多个应用程序的端到端业务流程测试。
• 定义测试成功准则和验证断言。

应该将 QA 创建的测试提交到共享资源库，以便开发人员也可以执行其操作。这使开发人员在不需等待 QA 重新运行测试的情况下，可以使用测试用例重现系统中的问题、调试问题并及时对他们在代码中所做的更改进行验证...

安全测试

即使很多组织倾向于将这个关键的实践留到生命周期的后期作为审计实践，大多数安全专家（包括 Parasoft）仍建议应该将安全作为开发生命周期中的内部流程来处理。Parasoft 解决方案框架遵循此哲学。 

Parasoft SOAtest 使用了与安全性相关联的验证（包括静态分析和渗透测试）扩展现有功能测试。假设安全性验证任务的工程师们（可能是开发人员、QA 或单独的一个团队）可以在功能测试顶部配置安全渗透测试。关于为什么需要共享访问测试构件以及为什么在共享工作空间上进行合作是非常实用，这便是另一个原因。

有关全部细节，请查阅 Security Testing。

负载和性能测试

有些组织拥有集中的负载和性能组，这些组可以访问适合运行真实负载测试的硬件和阶段环境。有些组织拥有执行该活动的项目组。或者，可能两者都拥有，只是在规模、生命周期阶段和测试频率上有所不同。在所有这些实例中（不管谁设计负载测试，谁在多大程度上运行它们），访问功能测试项目是非常有益的，因为性能测试旨在运行负载下的现有功能测试。性能测试工程师的任务包括：

• 检索开发人员和测试人员添加到资源库的项目（.tst）文件。
• 使用现有单元和功能测试定义负载测试场景。
• 定义 QoS（Expected Quality of Service，预期的质量服务） 度量，以根据 SLAs 验证服务并帮助使用监视器识别瓶颈。
• 提交负载测试场景到共享资源库中。

有关全部细节，请参考 Load Test。