自动化框架开发语言的选择和开发者的技术背景
发表时间：2023-10-27 10:05:06
文章来源：炫佑科技
浏览次数：185
菏泽炫佑科技
自动化框架开发语言的选择和开发者的技术背景
在决定选择哪种类型的自动化框架之后，接下来需要决定的是：应该选择哪种编程语言？ 编程语言的选择与开发人员的技术背景有很大关系。 通常，他们会选择自己熟悉的编程语言，但这通常是一个限制。 另一方面，它也受到SUT的影响。 一般来说，很少会选择C和C++作为自动化框架开发语言。 虽然这两种语言的执行效率较高，但开发效率较低。 我们项目的自动化框架是用Java语言编写的，关键字也是用Java实现的。 选择Java作为关键字实现是因为SUT——即服务器提供的API是Java或C++。 所以自然选择了Java。 至于自动化框架开发语言的选择，其实还有其他的选择，比如脚本语言和Perl。 脚本语言，或者说Perl，作为超高级开发语言，具有解释型和执行型的特点，在开发效率上可能会更高。
下面是关键字的选择实现。 关键字相当于手动执行测试用例的一个步骤。 例如，在当前项目中，关键字是修改产品的配置选项，也可以是发送带有特定附件的电子邮件。 就我们的产品而言，操作数据库有三种方式，分别是DIIOP、Web和本地调用。 一开始我选择了DIIOP，实现起来比较简单。 后来发现这样实现的自动化脚本，包含十几个关键字脚本，执行时间大概是35s – 40s。 Web 的执行时间要高效得多。 自动化脚本的执行时间可以缩短近10秒，但其实现需要分为服务器端Web发布和客户端调用。 这样一来，测试环境的部署也更加复杂。 讲这个主要是想告诉我们，一开始就需要评估这些，选择合适的方案，不然中途的变化影响会很大。
自动化框架，说白了就是对流程的封装。 那么自动化框架应该包括哪些流程呢？ 我们来看看下面的两帧图像。
**张图解释了一套自动化测试是由自动化框架、自动化脚本和关键字组成的。 第二张图描述了自动化框架的流程：根据配置选择要执行的测试用例，解析自动化执行脚本，将自动化执行脚本发送到自动化执行引擎，生成Log文件，*后生成。
这个简单的自动化框架与Robot框架相比，还有哪些地方可以改进呢？ **个是基于 Test Suit 的设置和测试。 自动化脚本的组成如下：清理并初始化测试环境（例如建立测试脚本所需的一些数据库），执行自动化脚本，生成执行结果，*后清除环境。 这些步骤也在我们的自动化脚本中实现，但是如果我们想在执行一批测试用例之前做一些操作并在执行后清除它们，我们使用它们的方式就是将批次中这些自动化脚本的名称放在被执行。 在测试脚本之前，我们的脚本按字母顺序排序以确保安全。 应该有更好的办法。 其次，自动化脚本中有关键字 Fail。 我还需要执行以下关键字吗？ 我们的框架会继续执行，但是Robot是可配置的，并且是通过. 你可以努力学习。
如何安排和预估自动化框架和关键词的开发周期？ 项目自动化测试框架和自动化脚本开发也分为两部分。 **次迭代期间，完成了自动化框架的主要流程自动化软件开发，完成了主要关键词，构建了SMOKE部分的自动化脚本。 在第二次迭代中，我们进一步完善了自动化框架，然后添加了关键字并完成了一些自动化脚本。 一开始我对估计也不太确定，因为有些关键词的实施可能比较困难，这时候就需要及时同步风险。 第二阶段，预估触底反弹。
如何协同开发？ 自然地，添加版本控制。 现在的自动化框架使用的版本控制是Git，相当流行！ 如果多人协作开发并提交代码，那肯定会发生。 我们的方法如下。 除了分支之外，大家在本地建立一个开发分支。 每次代码提交前，先将Git上的*新代码转移到分支上，然后将本地开发分支与分支合并，合并*终代码。
自动化脚本是如何命名的？ 我们的自动化脚本都是从手动测试用例中挑选出来的。 我们希望自动化脚本和手动脚本之间有关联，但同时只要看到自动化脚本的Title，就可以知道自动化。 脚本的大致测试意图。 我们这样做，e+ID，这个ID就是手动测试用例的ID。
如何控制粒度？ 该关键字相当于手动执行步骤。 这是我们的做法。 首先，我们手动执行测试用例，提取通用步骤，并实现关键字。 但如果关键词的粒度太细的话，关键词的数量会比较多，但是如果粗的话，关键词参数的形式就会比较复杂，这就需要构建自动化脚本的同事们学习了。 这个粒度需要把握好。 同时，对于自动化的关键字参数，需要使用详细的注释和格式示例。
如何在自动化脚本中维护变量？ 通常，自动化脚本中一些与执行环境相关的参数会以变量的形式被提取出来并存储在配置文件中。 这样，在部署自动化测试环境时，只需要修改这些环境相关的配置文件即可。 就是这样。 但随着自动化测试用例数量的增加，这个配置文件会变得臃肿。
如何判断自动化脚本的运行结果？ 自动化测试脚本和手动执行测试用例一样，也有预期结果和实际结果的比较。 如果两者不一致，则认为自动化脚本失败。 我们一开始所做的是将预期结果作为参数传递给关键字。 该关键字会在后台对比实际结果，不一致则失败。 一开始以为没有问题，后来发现因为环境因素，一些预期的结果会发生变化。 这时候我们就得修改自动化脚本了。 后来的做法是这样的：首先转储一个预期的结果并将其存储在本地。 执行自动化脚本时，转储实际结果，然后比较两者。 这避免了自动执行脚本的频繁更改。
执行结果的容错性？ 如何保证执行结果可靠？ 在自动化关键字的实现过程中会加入一些容错机制。 举一个简单的例子，发送一封带有特征附件的电子邮件就命中了一个策略。 此时，日志数据库中就会生成一条记录。 在实施自动关键词时，您可能会遇到这样的情况。 当你检查日志数据库时，很可能日志记录还没有生成。 如果这个时候直接判断自动化框架开发语言的选择和开发者的技术背景，自然会失败。 我们如何提高容错能力？ 一个很简单的方法就是加一定的延时，比如循环检查多少次，每次延时一秒。 这就带来了另一个问题，执行时间会延长。
立即获得 RD 帮助。 在实现DLP功能时，我发现重新加载程序的配置会很耗时。 如果无法重新加载自动脚本，则发送电子邮件将不会符合您的配置策略。 这时候就需要寻求RD的帮助了。 他们在后台提供密钥。 当使用该键并重新加载完成后，程序会打印出提示信息。 这个时候我们的自动化脚本只需要检查这些提示信息是否已经生成就可以判断是否完成然后发送邮件。
自动化测试开发和维护过程中*大的成本是什么？ 我认为一方面是测试数据的维护。 另一方面，由于产品功能的变化而引入的自动化脚本的修改也会产生成本。
自动化测试的应用场景？ 项目*大的价值是什么？ 就我们的项目而言，主要就是把手动测试用例变成自动化测试用例，也就是所谓的黑盒和功能自动化实现。 我们*初定位的时候，也希望回归测试自动化，缩短回归测试时间，提高回归测试效率，保证代码优化和新引入的代码不会影响老功能。 自动化测试不能发现手动测试无法发现的问题。 理想的状态是这样的，自动化测试和CI系统是集成的。 当新版本发布时，自动化框架可以自动安装新版本，执行自动化脚本，并在完成后通过电子邮件发布执行结果。
有什么办法可以推进关键词的实施吗？ 不要等到功能稳定，而是开始自动化。 我在Junit中看到过mock的概念，但是不知道具体怎么做。 我会在下一阶段学习它！
现在看来，一套自动化测试的开发还涉及到：项目需求分析、高层设计、框架开发、自动化脚本实现、各种规则制定、多方位协作等等，所以自动化测试开发需要被视为一个项目。 做吧！
2023年*详细自动化测试框架，从入门到精通的全栈测试开发技术教程
