我正在致力于在组织中建立自动化测试实践和测试套件。一位同行告诉我，我们“应该使用框架”。对我来说，框架是任何一组代码和/或其他工具，可以帮助你创建一些东西。
我的同行似乎在暗示存在行业标准的自动化测试框架。
我以前在设计测试系统时看到过以下模式：
我的对手包括“模块化”作为其中之一。由于我在软件工程方面的背景，我听到“模块化”这个词并想到模块化编程（与面向对象、面向方面或过程编程相反）......一种组织代码的方式，而不是一种方法或框架类型在其本身。
我已经看过“模块化自动化”的维基百科定义，它看起来与编程范式相同。
我错过了什么？我可以阅读什么来与我的对手在同一页面上？是我还是他什么都不懂？我有十多年的软件工程经验，而我的同行从事 QA 的时间也差不多。他无法站点参考。我已经在谷歌上搜索了 6 个小时，试图了解这个“模块化框架”，但找不到技术示例，仅是标准编程范式（例如将代码组织成模块）。
事实证明，自动化测试的主要行业标准设计是：
此外，还使用了“混合”方法。这些方法使用了以上设计中的一种以上。
在网络上的许多地方（包括维基百科）“模块化驱动”测试用例设计被错误地称为上面列出的自动化测试用例设计策略之一。这个错误术语（“模块化驱动”）的定义似乎更多地与编码的组织方面有关，而不是 One 驱动自动化测试的方式。“模块化驱动”自动化测试是用词不当（或完全错误的术语）。换句话说，不存在这样的事情。术语“模块化”描述了正在使用的编程范例。
测试的模块化方面在于其组织，将代码存储在模块中，而不是其他编程范式，如 OOP 或过程等。
我听说过模块化自动化，也称为基于组件的测试用例设计。惠普是这个领域的重要参与者。他们提出了一种称为业务流程测试的产品。
它包括：
•可重用的业务组件
•业务组件转换为业务流程测试
业务组件是在业务流程中执行特定任务的可重用单元。（例如 - 添加到购物车）业务流程测试是由业务组件组成的场景（例如 - 下订单）
在 HP 的质量中心，业务组件模块使您能够创建和管理可重用的业务组件。
然后测试计划模块使您能够将组件拖放到业务流程测试中，并调试组件。