测试策略模式_软件测试面试必备VIP专享VIP免费

_软件测试面试必备第18章测试策略模式18.1记录测试(也称为记录与回放测试、机器人用户测试、捕获/回放测试)如何准备软件的自动化测试？通过记录与应用程序的交互并使用测试工具回放它们来自动化测试。图18-1记录测试示意图自动化测试有几个目的。在回归测试软件更改之后，它们可以用于这些软件。它们有助于归档软件的行为。在写软件之前，它们可以指定其行为。如何准备自动化测试脚本，对可以将它们用于什么目的、它们对SUT中的变更有多健壮以及准备它们需要多少技能与努力等产生影响。记录测试使得能够在构建SUT之后、改变它之前迅速创建回归测试。18.1.1运行原理我们使用一种工具，它会监控我们与SUT的交互。这种工具记录大多数SUT对我们的通信以及我们对SUT的响应。录音会话完成之后，可以将它保存在文件里以便稍后回放。准备运行测试时，可以从工具的“回放”部分开始，并让它指向录音会话。它启动SUT，并给它提供响应SUT输出的记录输入。在录音会话内，它也可以比较SUT的输出及其响应。错误匹配可能导致测试失败。有些记录测试工具允许调整录音会话内SUT表现与回放过程中SUT表现之间比较的敏感性。大多数记录测试工具通过用户界面与SUT交互。18.1.2使用时机如果应用程序正在运行，但不希望对它进行太多变更，就可以使用记录测试进行回归测试。现有应用程序需要重构(预计修改功能性)而没有可用的脚本测试用作回归测试时，也可以使用记录测试。通常，生成一组记录测试比准备具有相同功能性的脚本测试更快。在理论上，任何知道如何运行应用程序的人都可以完成测试记录，几乎不需要专业技术。实际上，许多商业工具都值得深入学习。同时，需要一些专业技术来添加“检查点”，以便调整回放工具的敏感性，或者调整测试脚本(如果记录工具记录了错误信息)。大多数记录测试工具通过用户界面与SUT交互。如果SUT的用户界面不断发展，这种方法特别容易让它们变得脆弱(接口敏感性，参见“脆弱测试”)。甚至是小的变更(例如改变按钮或字段的内部名称)也足以让回放工具产生错误。这些工具也倾向于在低级别详细记录信息，这样会让测试难以理解(参见“模糊测试”)。因此，如果对SUT的变更中止了这些工具，也很难手动修复它们。所以，如果SUT不断发展，就要准备有规律地再记录测试。如果要使用作为文档的测试或者要使用这些测试驱动新的开发，就应该考虑使用脚本测试。使用商业记录测试工具难以实现这些目标，因为大多数工具不允许定义用于测试记录的高级语言。将记录测试性能构建到应用程序本身之中或者使用重构的记录测试可以解决这个问题。变体：重构的记录测试这两种策略的混合是，使用“记录、重构、回放”1顺序从最新记录测试中提取一组“动作组件”或“动词”，然后通过测试用例来调用这些“动作组件”(而不是使用详细的内联代码)。大多数商业捕获/回放工具提供将字面值转换为参数的方法，主要的测试用例可以将这些参数传递到“动作组件”。屏幕改变时，只需再记录“动作组件”，所有测试用例自动使用新的“动作组件”定义继续运行。这种策略在效能上与使用测试实用程序方法与单元测试中的SUT交互相同。它允许使用重构的记录测试组件作为脚本测试中的高级语言。像MercuryInteractive的BPT2这样的工具以自顶向下的方法将这一范式用于脚本测试。开发完高级脚本并指定了测试步骤所需的组件之后，更多的技术人员就可以记录或手动编码单个组件。18.1.3实现方式说明使用记录测试策略时，有两种基本选择：可以获得第三方工具，它记录与应用程序交互时发生的通信；可以将“记录与回放”机制内置于应用程序。11名称“记录、重构、回放”是AdamGeras提出来的。22BPT是“业务进程测试(BusinessProcessTesting)”的缩写。1.变体：外部测试记录在商业上有许多测试记录工具可用，每种工具都有自身的优缺点。最好的选择取决于应用程序用户接口的性质、预算、要验证的功能性的复杂性以及其他可能的因素。如果要使用测试来驱动开发，就需要挑选使用测试记录文件格式的工具，这种格式可以手动编辑且易于理解。需要手动编写内容，如果使用“记录与回放”工具来执行测试，这种情况也还是脚本测试的示例。2.变体...