测试策略模式_软件测试面试必备.docx

编号：时间：2021年x月x日书山有路勤为径学海无涯苦作舟页码：_软件测试面试必备第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名称“记录、重构、回放”是AdamGeras提出来的。顺序从最新记录测试中提取一组“动作组件”或“动词”然后通过测试用例来调用这些“动作组件”(而不是使用详细的内联代码)。大多数商业捕获/回放工具提供将字面值转换为参数的方法主要的测试用例可以将这些参数传递到“动作组件”。屏幕改变时只需再记录“动作组件”所有测试用例自动使用新的“动作组件”定义继续运行。这种策略在效能上与使用测试实用程序方法与单元测试中的SUT交互相同。它允许使用重构的记录测试组件作为脚本测试中的高级语言。像MercuryInteractive的BPT2BPT是“业务进程测试(BusinessProcessTesting)”的缩写。这样的工具以自顶向下的方法将这一范式用于脚本测试。开发完高级脚本并指定了测试步骤所需的组件之后更多的技术人员就可以记录或手动编码单个组件。18.1.3实现方式说明使用记录测试策略时有两种基本选择：可以获得第三方工具它记录与应用程序交互时发生的通信；可以将“记录与回放”机制内置于应用程序。1.变体：外部测试记录在商业上有许多测试记录工具可用每种工具都有自身的优缺点。最好的选择取决于应用程序用户接口的性质、预算、要验证的功能性的复杂性以及其他可能的因素。如果要使用测试来驱动开发就需要挑选使用测试记录文件格式的工具这种格式可以手动编辑且易于理解。需要手动编写内容如果使用“记录与回放”工具来执行测试这种情况也还是脚本测试的示例。2.变体：内置测试记录也可以将记录测试性能内置于SUT。在那种情况下可以用相当高的级别定义测试脚本“语言”级别足够高就可以在构建系统之前手动编写测试。实际上有报告说MicrosoftExcel电子数据表的VBA宏性能是Excel自动化测试机制的开端。18.1.4示例：内置测试记录从表面上看提供记录测试的代码样本没有意义因为这种模式处理生成测试的方法而不是表示它的方法。回放测试时实际上就是数据驱动测试。同样通常不重构到记录测试因为它经常是项目尝试的