自动化测试框架_测试自动化框架-CSDN博客

自动化测试框架

Test Automation Framework

测试自动化框架

Before we proceed into the depth of framework design and related components, I would like to clarify some common notions related to Software Test Automation.

在深入研究框架设计和相关组件之前，我想澄清一些与软件测试自动化有关的常见概念。

It is often considered that Automation will help in identifying more bugs in the application under test (AUT), which is absolutely incorrect. It is basically useful in reducing the time involved in doing some complex tasks that the manual QA guy would usually take longer time to perform and may be prone to human errors.

通常认为，自动化将有助于识别被测应用程序（AUT）中的更多错误，这是绝对不正确的。从根本上讲，这对于减少执行复杂的任务所花费的时间非常有用，而手动QA人员通常会花费较长的时间来执行这些操作，并且可能会出现人为错误。

So does this mean that I would be eliminating the use of Manual QA in my team? The answer is a big NO. The manual QA team is there to understand the complex business functionalities and other minute details that may not have been covered in automation; they are the ones who know the business functions inside out. Overall the Software QA team functions well only if the Manual and Automation teams are in sync and both mutually add value to the final output – Deliver a good quality software product.

那么这是否意味着我将在团队中不再使用人工质量检查？答案是否定的。手动的质量检查团队可以了解自动化中可能未涵盖的复杂业务功能和其他详细信息；他们是完全了解业务功能的人。总体而言，只有在手动和自动化团队保持同步并且双方共同为最终输出增加价值的前提下，软件质量检查团队才能正常运作–提供高质量的软件产品。

Now coming back to our main topic of automation frameworks, I will quickly list down the commonly known frameworks going by the bookish concepts -

现在回到自动化框架的主要主题，我将快速列出书本概念所遵循的众所周知的框架-

• Modular

•模块化

• Data Driven

•数据驱动

• Keywork Driven

•按键驱动

• Hybrid Test Automation

•混合测试自动化

Here is a quick description of each of these types and in the coming sections we will discuss more on the Hybrid framework as gives you the liberty to tweak the framework as per your requirements.

这是对每种类型的简要说明，在接下来的部分中，我们将进一步讨论Hybrid框架，因为您可以根据自己的需求自由调整框架。

Modular framework

模块化框架

Most basic of all frameworks, the test scripts can be created as small, independent scripts that can be modules/functions of the AUT. Then each module can be integrated to form larger test for the overall application test suite. This helps in achieving modularity and maintainability of the scripts.

在所有框架中，最基本的是，可以将测试脚本创建为小型，独立的脚本，这些脚本可以作为AUT的模块/功能。然后，可以集成每个模块，以形成整个应用程序测试套件的更大测试。这有助于实现脚本的模块化和可维护性。

Data Driven

数据驱动

As the name suggests, this type of framework depends on some data to drive the test scripts. Therefore, the data (input and output) can be in the form of files or DB Tables. The scripts can be designed such that the data is read from input files, the functionality to tested is triggered and then based on the outcome of the test the result is again stored as files/tables.

顾名思义，这种类型的框架取决于一些数据来驱动测试脚本。因此，数据（输入和输出）可以采用文件或DB表的形式。可以设计脚本，以便从输入文件中读取数据，触发要测试的功能，然后根据测试结果将结果再次存储为文件/表。

Keyword Driven

关键字驱动

These are basically generated from the manual test cases by picking up the keywords from the test cases. The functionality is entered in the form of a table that lists down the events to be performed and then executed.

这些基本上是通过从测试用例中挑选关键字从手动测试用例生成的。以表格的形式输入该功能，该表格列出了要执行然后执行的事件。

Hybrid Test Automation

混合测试自动化

All of the above framework approaches have their own pros and cons. To overcome these and make the best use of their advantages – the Hybrid automation framework is designed.

上述所有框架方法都各有利弊。为了克服这些问题并充分利用它们的优势–设计了混合自动化框架。

I will be discussing the Hybrid automation framework based on my personal experiences with a wide range of applications and test automation tools.

我将基于我的个人经验以及各种应用程序和测试自动化工具来讨论混合自动化框架。

Refer the snapshot of the Automation Framework architecture:

请参阅自动化框架体系结构的快照：

Automation Test Suite自动化测试套件

This will comprise of the features/functionalities that will be covered in your test suite. The objective of the framework is to develop a test suite that will have maximum coverage of tests and ability to add new test cases easily and with less script maintenance. Test cases for automation scripting would be selected on priority depending on the significance of test case and frequency of execution of the test case.

这将包括测试套件中涵盖的功能部件/功能。该框架的目标是开发一个测试套件，该套件将最大程度地覆盖测试，并能够轻松地添加新的测试用例，并减少脚本维护。根据测试用例的重要性和测试用例的执行频率，将根据优先级选择用于自动化脚本的测试用例。

Sanity Tests健全性测试 Installation Tests安装测试 Components:组件：

The automation framework should be easily maintainable as well as portable. Although, it will be dependent on the automation test tool the architecture should be formed such that the components are modular and flexible to modify.

自动化框架应该易于维护并且可移植。虽然，这将取决于自动化测试工具，但应将体系结构形成为使组件模块化并易于修改。

Function Library and Reusable events函数库和可重用事件 Objects Repository对象存储库 Modules and Test Scripts模块和测试脚本 Supported Controls:支持的控件：

Depending on the AUT and the test automation tool you choose for your automation process, you will need to identify what all controls are required. For example, for a Windows-based application you will need a tool that identifies Win Controls, whereas for a website you might need web controls, Java controls, Flash controls or any other as per the web page design.

根据您为自动化过程选择的AUT和测试自动化工具，您将需要确定所需的所有控件。例如，对于基于Windows的应用程序，您将需要一个用于标识Win Controls的工具，而对于网站，您可能需要根据网页设计而需要Web控件，Java控件，Flash控件或任何其他控件。

Logging and Reporting:记录和报告：

This is the most important and critical part of the automation framework design. So far, we have developed scripts to automate your feature testing using all the possible components; now comes the time to store the result of automation and report the same to the appropriate QA authorities.

这是自动化框架设计中最重要和最关键的部分。到目前为止，我们已经开发了脚本来使用所有可能的组件自动执行功能测试。现在是时候存储自动化结果并将其报告给相应的质量检查部门了。

The manual QA team will be highly dependent on the output from the automation run as they might need to verify the failed items/bugs that will be raised during the automation testing process. The following are some useful components to be considered for logging and reporting:

手动的质量检查小组将高度依赖自动化运行的输出，因为他们可能需要验证自动化测试过程中将引发的失败项目/错误。以下是一些用于日志记录和报告的有用组件：

Exception Handling异常处理 Call stack reporting调用堆栈报告 Excel based reports基于Excel的报告 Database logging数据库日志记录 Email notifications电子邮件通知

There is a lots more to add to framework designing and approaches to development of these frameworks. I have tried to put the best of my experience in words to help the QA community build robust frameworks and ensure good quality software products.

框架设计和这些框架的开发方法还有很多其他要添加的内容。我试图用我的经验总结，以帮助质量保证社区建立可靠的框架并确保高质量的软件产品。

Do send me your feedback on this article.

请将您对本文的反馈意见发送给我。