Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

API Testing Guide An automated approach to API testing transformation. From Mon

API Testing Guide An automated approach to API testing transformation. From Monolith to Microservice The consumerization of IT has changed the way we write applications today. Instead of building a single, monolithic system that is installed on a server in a back office or call center, modern applications are scattered within mobile devices and web browsers so users can gain access to services at anytime from anywhere. And modern applications are no longer self-contained; they are composed of multiple service components that are tied together at runtime. Therefore, the end-user experience is not powered by the elegant UIs we all use, but by APIs that facilitate interactions between code modules, applications and back-end IT systems. Because of this, the way we test must change. Quality assurance (QA) and development teams must expand their capacity to test each layer of the application, as well as the end-to-end business transactions. Modern applications then require comprehensive API testing in addition to traditional UI testing. But API testing presents many challenges for testers. It requires a new approach—one that is automated wherever possible and inherently data-driven. 2 When testing APIs, testers are faced with numerous discrete units of work. Some of these APIs may have been created by a third party, while the possible ordering and combinations of different versions of APIs can cause the number of combinations that need to be tested to skyrocket to an impossible number. The ability to identify these combinations and then reduce them to a realistic number without compromising quality requires testers to adopt a new model-based approach and invest in automation technologies. Related Reading Article from Professional Tester Magazine— Meeting the Challenge of API Testing 2 The Challenges of API Testing 3 Your inclination may be to extend the same principals of UI testing to APIs—have developers build a UI in front of each API and put your “eyes on the glass,” using manual testing to input spreadsheets of data and watch the response. This approach, however, is not ideal, takes too long and will not scale. These challenges are exacerbated for several reasons: Use case proliferation Traditional UI testing is concerned only with the functionality of the overall application. A tester exercises an input and interprets the output against expected outcomes. But API testing is a different animal. Because APIs are the central hub of logic and the gateway to data for many applications, use cases are near-limitless. As a result, the number of required tests quickly surpasses the capabilities of the development and technical testers responsible for test case design. Asynchronous and synchronous processes Modern applications are complex and one API may link together several microservices and other APIs. As a result, a single call on an API may trigger any number of parallel and serial actions. For example, one service may look up a customer’s shipping address, while a second service looks up the price of an item. A third service then takes the output to calculate the tax based on the location of the purchaser and the cost of the item. This example assumes the application is calling one API. In reality, modern applications have APIs that get data from other APIs, that then rely on others. The complexity of an API can therefore grow exponentially as it is combined with other API calls. And this complexity only multiples as testers must also factor in the calling order of APIs in test case design. Consequently, the testing of APIs needs to be handled in both atomic, standalone units of work and in orchestration. 3 The Challenges of API Testing, Continued 4 Access to dependent systems APIs pull data from multiple APIs, microservices and back-end systems. The resulting architecture can look like the roots of a tree spreading out deep and wide. And it’s unreasonable to think you will have access to every environment on this tree. Certain dependencies may still be under development, while third-party systems and mainframes may be too costly to test or their window and scope of access too limited. The simulation of unavailable resources is then key to avoiding testing bottlenecks. But the traditional way of building custom mocks and stubs is proving too problematic. For instance, stubs and mocks are usually written by developers, occasionally shared with QAs and very rarely shared with other development teams due to interoperability problems. What’s more, they cannot simulate race conditions for exhaustive performance and load testing. API versioning Versioning is a further cause of growing complexity in API testing. Most systems have a degree of deprecation, so an API must be able to handle an old version calling new versions, or a combination thereof. The API must recognize missing values and assign some kind of default to allow the old version to work. What’s more, it might be the case that some versions can be called by some versions but not others, and the numerous possible combinations must therefore be tested. Case in point: In the following diagram, there are 127 API combinations which need to be tested. However, when the versioning is overlaid, there are 10,287 possible combinations which need to be tested, and it is not likely that manual scripting will cover a sufficient proportion of these. True False MV3 MV1 MV2 CV1 CV2 CV3 OV3 OV2 OV1 IV3 IV2 IV1 MV3 MV1 MV2 CV1 CV2 CV3 OV3 OV2 OV1 IV3 IV2 IV1 Valid Versions Start Customer API Versions Order API Versions Item API Versions Valid Combinations Master API Versions {Clone1} Master API Versions Customer API Versions {Clone1} Order API Versions {Clone1} Item API Versions {Clone1} Invalid Combinations 4 A Model for API Testing Transformation To overcome these challenges, you need to adopt a modern approach and set of tools that will enable you to automate API tests and incorporate them into a continuous delivery cycle. Generate API tests automatically and in multiple ways Edit and extend API tests without writing code Use one test and one tool across all layers and systems Run unlimited tests with service virtualization “High-volume test automation requires test models, test-data generators and automatic oracles. Modelling, simulation, analytics, visualization and tool-supported decision making will become important capabilities of test architects and testing teams. Testers will have to learn how to create better test models and how to use them with more technical modelling and simulation tools.”1 —Paul Gerrard, Gerrard Consulting >> >> >> >> Related Reading • How Will the Internet of Things Affect Testers? • Industry Analyst Report: Gartner Market Guide for API Testing and Service Virtualization 5 6 Generate API Tests Automatically and in Multiple Ways In a perfect world, you could automatically derive all of the test cases you need to ensure adequate coverage, and then generate relevant test scripts while automatically provisioning the appropriate sets of data to run against those tests. Thanks to advances in testing technology, this ideal is not far off. But some degree of manual intervention is going to be required. Therefore, the question is: How do you minimize this requirement? • Start by implementing a system to formally capture and manage all API requirements and change requests. • Obtain the appropriate tools to auto-generate test cases and associated test scripts from these requirements and in multiple ways. For example, from contracts (Swagger), samples (individual messages) or observations from real API data. • Store test cases in a library for reuse. It’s important to tie all test cases back to their requirements. Only then will testers have the context they need to understand what the API is doing and where the transaction is occurring in the overall workflow. • Leverage test data management technology to pull and mask existing data from multiple back-end systems and, when needed, extract missing data synthetically for maximum test coverage. of all testing is still manual.2 70% Edit and Extend API Tests Without Writing Code Automated tests created with scripts are dependent on the system under test. Should APIs change, as they are known to do, automated tests may no longer work with future versions of the API, thus requiring additional scripting. In the end, this process may lead to large, unmanageable sets of code that are prone to defects. At the same time, modern applications are complicated and tests need to be validated across multiple application layers. This requires a much higher degree of test orchestration. But with the right test automation tools and testing framework, you can edit and extend API tests without modifying a single line of code. • Look for an API testing solution that allows for modularity to facilitate reusability from release to release. Configuration (environment, IPs, logins/passwords) should be stored separate from data, which should also be separate from invocation method (protocols such as web services, MQ, JMS, TIBCO, SQL, etc). Being able to change one of these areas separate from the other two will allow you to reuse the tests and adjust to the rapidly changing API landscape. • Choose an API testing solution with Selenium-based web UI testing and a native visual editor. uploads/Litterature/ api-testing-guide.pdf