Automated Software Testing Overview _ Software Testing

The actual situation of automated software testing

The term automated Software testing (automated Software testing,ast) draws many different meanings from members of the software development and testing community. For some, this term may be the meaning of test-driven development or unit testing, but for others it may mean using capture/recording/playback tools for automated software testing. The term may also mean using scripting languages such as Perl, Python, and Ruby to customize development test scripts. For others, automated software testing may involve only performance testing and stress testing, or full attention to functional or security testing. In this book, the AST refers to all of these meanings.

It is important to define the AST explicitly before further detail, as well as the meaning and understanding of the term to agree with the reader. We will define the AST based on past work and experience, which is also what it really means. In addition, this chapter discusses what is needed for a successful AST job, as well as some AST methods. Here we will discuss how to streamline some of the recommendations for automated test work, and also discuss the application of the AST throughout the software test lifecycle.

1.1 Automated Test definition

The definition of automated software testing includes all testing phases, which are cross-platform-compatible and process-independent. In general, various tests, such as functionality, performance, concurrency, and stress tests, that are currently part of a manual test program can be automated. This question is often asked: "What is the difference between manual and automated testing?" The answer is as follows:

Automated testing can make it difficult to do manual testing and improve the productivity of manual tests.

Automated testing is also software development.

Automated testing is not about replacing the analytical skills, test strategy knowledge, and understanding of test techniques required by manual testers. The experience of manual testers will be a blueprint for the AST.

Automated testing cannot be completely separated from manual testing. In contrast, automated testing and manual testing are complementary.

While it is possible to develop software to convert all of today's manual software tests to automated tests, our experience has shown that most manual tests must be modified to accommodate automation. Manual testing techniques, practices, and knowledge are intertwined with the AST, so they are also discussed in this book to support AST technology. Whether automation can produce a reasonable ROI (return on investment, ROI) is another issue that needs to be evaluated. Experience has shown that even though all tests can be automated, not all tests are worth automating. When deciding whether to automate, we need to consider the various guidelines. How to determine which tests should be automated will be explored further in chapter 6th. To keep ROI in mind, our high-level definition of AST is:

The goal is to improve the efficiency and effectiveness of the Software testing lifecycle (Software testing lifecycle,stl), throughout the implementation of the entire STL application and software technologies.

An AST is an automated effort that spans the entire STL and focuses on automated integration testing and system testing. The overall goal of the AST is to design, develop, and deliver automated tests and to improve test efficiency through repetitive testing. If implemented successfully, it can significantly reduce the cost, time, and resources associated with traditional testing and evaluation methods, processes, and procedures for software-intensive systems.

1.2 Methods of automated testing

When the AST is implemented effectively, it is not a complete capture and playback of the graphical user interface (GUI) (but many people understand it) and is not limited to testing at a particular stage, nor is it intended specifically for any particular vendor, and it adapts to AUT (application Under test , a specific architecture or language used by the application being tested.

The AST described in this book is process-independent, technology-independent, and environment-independent. By following the implementation recommendations described in this book, the AST can be implemented, whether using a waterfall model, a test-driven development model, scrum, or any other type of software development model, and whether it is a scenario for testing Web applications or service-oriented architectures, whether your application is running on Linux, On a Mac or on Windows, it has nothing to do with the environment, the OS, or the platform.

If you implement the AST effectively, you can support the application of the following environment:

Run on multiple computers.

Use a different programming language.

Run on different types of operating systems or platforms.

Regardless of whether there is a GUI (for example, a test for the message interface, no GUI).

Run any network protocols, such as TCP/IP, DDS protocol, and so on.

The following points should be borne in mind when developing an automated test framework. It should:

Support for integration of multiple business test tools, whether open source, self-developed, or from different vendors (even the latest and better available products on the market).

Supports testing without having to install the framework on the same computer as SUT.

It also supports new applications and legacy applications that are being developed.

Support for the entire test lifecycle (but not for the AST, you need to apply throughout the test lifecycle).

Support for distributed testing across multiple computers and in various systems engineering environments.

If applicable, it supports the reuse of the AST framework and components between multiple programs.

The implementation of the AST requires a small development lifecycle, including test requirements, design and build of automated frameworks, implementation/validation of automated tests, and execution. If done correctly, the AST produces reusable and extensible frameworks and components. Best practices in software development should be applied and adhered to.

While some programs and AUT have similar test automation needs and many commonalities, other programs require a unique, personalized AST implementation. The automated testing framework for effective implementation can accommodate these unique requirements.

Figure 1-1 shows an example that has been implemented using the automated framework approach that we have described. Here, we demonstrate cross-platform compatibility by running tests on Linux and Windows platforms. In addition, we have shown the integration of tools as part of an automated framework. In this example, we used the testplant eggplant and Vncrobot as test tools. We also used the Software test automation framework/software Test Automation engine (STAF/STAX) and successfully integrated the AST framework into our automated testing framework. Staf/stax is an open source, cross-platform, multilingual, thought-designed around reusable components called services, such as process invocation, resource management, logging, and monitoring. Staf eliminates the tedious and tedious construction of an automated infrastructure from scratch. The STAF Framework provides the foundation for building high-level scenarios and provides a plug-in way to support a wide range of platforms and languages. Staf/stax has proven to be very useful, and we have successfully integrated it into our own automation framework.

......

This article is reproduced from the 51Testing Software test Network, view the full text: http://www.51testing.com/html/06/n-235806.html