测试工具产生的记录/回放工具的缺陷及维护
发表时间：2023-09-15 17:03:15
文章来源：炫佑科技
浏览次数：180
菏泽炫佑科技
测试工具产生的记录/回放工具的缺陷及维护
大多是软件的功能测试功能（也称为录制/回放工具），例如机器人和机器人。录制/播放工具的缺陷使我们在测试中过分依赖它。
缺陷：
录制/回放工具记录用户与应用程序交互时的击键和鼠标移动。击键和鼠标移动都记录为脚本，然后可以在测试执行期间“播放”。虽然这种方法对特定情况有益，但录制/回放功能仅为其全部功能的 1/10 左右。生成**条记录后，必须修改录制/回放脚本。对功能测试的修改主要集中在通过GUI验证的测试上，也称为黑盒测试。仅通过录制/回放直接创建脚本有一些严重的限制和缺点。
1. 硬编码数值。录制/回放工具根据用户的交互生成脚本，其中还包含从用户界面输入或接收的任何数据。在脚本中“硬编码”值可能会导致以后维护的问题。如果用户界面或应用程序的其他方面发生更改，则硬编码的数值可能会导致脚本非法。例如，在记录期间生成脚本时，输入值、窗口坐标、窗口标题和其他值也可以记录在生成的脚本代码中。如果这些值中的任何一个在应用程序中发生更改，则测试执行期间的这些固定值将成为罪魁祸首：测试脚本与应用程序的交互是错误的，或者完全失败。另一个可能有问题的硬编码数值是日期戳。如果测试工程师在测试期间记录了当前日期，则几天后再次运行脚本将导致失败，因为脚本包含不再与当前日期匹配的硬编码值。
2. 非模块化、不可维护的脚本。测试工具生成的录制/回放脚本通常不是模块化的，并且很难维护。例如，许多测试过程可能会引用 WEB 应用程序中的特殊 URL，如果在脚本中使用硬编码 URL，则此 URL 的更改将导致大量脚本失效。在模块化开发方法中，只有一个函数被引用或包装在 URL 周围。然后，引用它的脚本将调用此函数，以便只需在一个位置更改对 URL 的任何更改。
3. 缺乏可重用性标准。测试 过程 开发 面临 的 * 重要 问题 之一 是 可 重 用 性。如果测试创建专门的标准，明确要求开发可重用的自动化测试过程，则可以大大提高测试组的生产力。如果将用户界面部分的测试打包成模块化、可重用的脚本文件供其他脚本调用，则在用户界面不断变化时，脚本的维护工作量大大减少。
创建可重用库时，*好将数据读取、写入和确认、导航、逻辑和错误检查等功能分组到单独的脚本文件中。自动化测试开发的指南应该大量借鉴有效软件开发的原则。现在是遵循*接近测试工具生成的脚本的开发语言的开发语言指南的好时机。例如，如果工具生成的脚本与 C 类似，那么它应该遵循 C 开发标准;如果该工具生成的脚本类似于 BASIC 语言，则应遵循 BASIC 语言开发标准。
在自动化测试开发中，仅使用录制/回放方法生成的测试脚本难以维护和重用，这是一个显而易见的事实。虽然在少数情况下可以使用粗略的脚本，但在大多数情况下，如果录制后不修改脚本，测试工程师会在测试执行过程中由于被测试应用程序的变化而重复记录脚本。使用录制/回放工具的潜在好处必然会被不断重建测试脚本的挫败感所抵消。这可能会导致测试人员产生强烈的挫败感，并且会对自动化测试工具不满意。
为了避免未处理的记录/回放脚本引起的问题，应建立可重用测试脚本的开发策略。未处理的录制/回放脚本并不表示有效的自动测试。
解决方案：自己开发测试工具
为了消除自动化测试工具的限制，对核心组件进行更深入的测试，可以自行开发测试工具。此类自定义测试工具通常使用健壮的编程语言编写，例如独立C++或Java程序，并且自定义测试工具通常比自动化测试工具生成的脚本运行得更快，更灵活，因为这些脚本受到测试工具的特定环境的限制。
让我们以适合使用自定义测试工具的测试任务为例，假设应用程序的目的是根据用户提供的信息进行计算，并生成有关计算结果的报告。计算过程可能很复杂，并且可能对各种输入参数的不同组合敏感。可能有数百万种潜在的变化可以产生不同的结果，因此对计算过程进行彻底的测试可以保证计算的正确性。
手动开发和验证大量计算测试用例是浪费时间。在大多数情况下，通过接口执行大量测试用例也非常慢。这里更有效的方法是开发自己的测试工具，该工具直接针对应用程序的代码（通常直接针对用户界面层下的核心组件）执行测试用例。
使用自制测试工具的另一种方法是将新组件与旧组件或系统进行比较。这两个系统通常使用不同的数据存储格式和通过不同技术实现的不同用户界面。此时测试工具产生的记录/回放工具的缺陷及维护，为了在两个系统上运行相同的测试用例并生成比较报告，自动化测试工具需要一种特殊的机制来复制自动化测试脚本。在*坏的情况下，单个测试工具不能同时与两个系统兼容，在这种情况下，必须使用两个不同的自动化测试工具开发两组测试脚本。更好的选择是生成一个定制的自动化测试工具，将两个系统之间的差异封装到单独的模块中，以便我们可以设计适用于两个系统的测试。自制的自动化测试工具可以使用旧系统产生的测试结果作为基线，通过比较两组结果并输出它们之间的差异来自动验证新系统产生的结果。
实现此目的的一种方法是使用自制适配器模式。自制测试线束适配器是一个模块自动化软件开发，用于转换或调整每个被测试的系统，使其与自制测试工具兼容，以便自制测试工具可以通过适配器在系统中执行预定义的测试用例，并以可以自动相互比较的标准格式存储结果。对于每个开发的适配器，适配器必须能够直接与系统交互并针对系统执行测试用例。使用自制测试工具测试两个系统需要不同的适配器，并独立调用自制测试工具两次，每个系统一次。将保留并比较两个调用的结果。该图描述了一个自定义测试工具，该工具针对旧系统和新系统执行测试用例。
通过为每个系统使用不同的适配器，可以将同一测试用例用于多个系统。旧系统的适配器生成一组基线结果，用于将结果与新系统进行比较。
为了完成其任务，自制测试工具适配器首先获取一组测试用例，然后按顺序执行它们，从而绕过用户界面直接测试每个系统的逻辑。绕过用户界面可优化性能并*大化测试用例的吞吐量。它还具有更大的稳定性。如果自制测试工具依赖于用户界面，那么对用户界面的任何更改（在开发生命周期中经常被修改多次）都可能导致自制测试工具识别泄漏中的缺陷。检查这样的结果会浪费大量宝贵的时间。
每个测试用例的执行结果以相同的格式存储在一个或多个结果文件中。无论要测试的系统如何。保存结果文件以与后续测试生成的结果进行比较。可以使用自定义生成的结果工具进行比较，该工具根据某些规则读取和评估结果文件，并输出发现的任何错误或差异。如果我们格式化结果，那么它们也可以通过标准的“文件差异”工具进行比较。与所有测试类型一样，自制测试工具
使用的测试用例可能非常复杂，特别是当自制测试工具测试的组件用于数学或科学计算时，并且大多数测试都可以用自定义测试工具覆盖。
