How we overcame iron obstacles in test automation
In the early stages of implementing the DevOps practices in the ESF program, difficulties arose. For example, building a pipeline of some projects required automation of end-to-end scenarios using plastic cards and digital signatures, while the use of hardware, a POS terminal and a Touch Memory tablet imposes significant restrictions on the automation of checks. What restrictions faced and how they were solved, read under the cut.
When testing the UI, the tester manually performs the steps of test cases that use various external devices. Automation was hampered by interaction with external devices:
- in the course of making adjustments to customer data, confirmation of an authorized employee by a “tablet” (TM) is required;
- when identifying a client by the card, it is required to insert the card into the POS terminal.
')
As an automation option, it was proposed to robotize the process of interaction with devices. However, robotization was not as accessible. The robot was a mechanized grip on a platform of 3 m², which could take a card, insert it into the POS terminal and enter a PIN. A particular obstacle to use was the low accuracy of hand movements: if the card did not fall into the terminal receiver, then the force of a mechanical hand could break it. In addition, hand management was launched from a server that was not in the corporate network segment.
The next option decided to explore the mechanisms of interaction of equipment and programs. When analyzing these mechanisms, it turned out that communication with external USB-devices goes through registered ActiveX-libraries.
Analyzing possible ways of implementation, in one of the html and js files we encountered the following construction:
Here you can clearly see how an ActiveX object is created and its methods are called. As an experiment, several methods were called with the following vbs-script:
Got the result:
No errors!
It turns out that if we write our ActiveX object and produce the necessary data, the program will “think” that it communicates with the hardware.
The idea is as follows: we save the data that we get from the real library into the setup file, create a fake ActiveX object with the same name as the real one, and we will take the response data from the setup file.
In Visual Studio, we wrote a COM library with the name “Signature.Processor”, as in the example above, where we implemented methods that return previously obtained values ​​from the test file.
This implementation worked perfectly with the automated system (AS), which only checks the number of the EDS TM carrier, consisting of 8 hexadecimal numbers (JGetTmNumber) and the signature identifier (JIdUser). However, the new versions of the modules “learned” to verify the signature on the transmitted hash, which is required to be signed in the present.
This cryptographic signature functionality cannot be implemented by counting once the hash and its signature, since when the hash changes, the signature must also inevitably change. The function of automated signing has an EDS server. However, to use it, you need applications for physical access over the local network from each client, setting up administrators directly on the server to open access, and you still need to load the private key into a free slot. Access to all possible machines where, possibly, an automated EDS will be used, cannot be requested. To circumvent this security constraint, we have identified a separate server through which the interaction between the workstations with the tests and the server will take place.
The next problem is that when working with a signature through the FPSU-IP software and hardware complex, the EDS server does not have the ability to work with the TM, since when querying the number of the “tablet” from the FPSU itself, an empty value is returned. Since the FPSU-IP uses the concept of a key (the slot number into which the EDS private key is loaded) for working with EDS, our solution should emulate the number of the “tablet”. For example, all the letters “D” and at the end of the slot number with EDS.
As a result, we got the following solution:
So we have a flexible testing tool that emulates physical interaction with equipment.
At the same time practiced in Microsoft C #.
A similar situation exists with POS-terminals for bank cards. All interaction is carried out through the ActiveX-component, through which various functions of the terminal are called. Only without pitfalls.
As a result, we have the opportunity to automate scenarios on a large number of test data, up to emulation of a card with an incorrect number or expired. This allowed the release of POS-terminals in the process of auto-testing.
What is important, we received additional “buns” - we managed to solve problems not related to automation, which made testers very happy:
We hope this short post was useful for you. As always, we are happy to chat and answer your questions in the comments.
When testing the UI, the tester manually performs the steps of test cases that use various external devices. Automation was hampered by interaction with external devices:
- in the course of making adjustments to customer data, confirmation of an authorized employee by a “tablet” (TM) is required;
- when identifying a client by the card, it is required to insert the card into the POS terminal.
')
As an automation option, it was proposed to robotize the process of interaction with devices. However, robotization was not as accessible. The robot was a mechanized grip on a platform of 3 m², which could take a card, insert it into the POS terminal and enter a PIN. A particular obstacle to use was the low accuracy of hand movements: if the card did not fall into the terminal receiver, then the force of a mechanical hand could break it. In addition, hand management was launched from a server that was not in the corporate network segment.
The next option decided to explore the mechanisms of interaction of equipment and programs. When analyzing these mechanisms, it turned out that communication with external USB-devices goes through registered ActiveX-libraries.
Analyzing possible ways of implementation, in one of the html and js files we encountered the following construction:
try { var signProcessor = new ActiveXObject("Signature.Processor"); if (typeof signProcessor.DWriteSettings != "undefined" && typeof signProcessor.DSignInitialize != "undefined" && typeof signProcessor.JSignErrorMessage != "undefined" && typeof signProcessor.JIdUser != "undefined" && typeof signProcessor.JGetTmNumber != "undefined" && typeof signProcessor.DSignUnInitialize != "undefined") { return true; } else { return false; } } catch (e) { return false; } Here you can clearly see how an ActiveX object is created and its methods are called. As an experiment, several methods were called with the following vbs-script:
' — c:\Windows\SysWOW64\wscript.exe "C:\term\sign.vbs" Set MyServ = CreateObject("Signature.Processor") MyServ.DWriteSettings MyServ.DSignInitialize s = "TM=" & MyServ.JGetTmNumber() & vbCrLf s = s &"JIdUser=" & MyServ.JIdUser() & vbCrLf wscript.stdout.writeline s setMyServ=nothing Got the result:
Windows (Microsoft ) 5.8 (Microsoft Corp.), 1996-2001. . TM=06000000000000d0 JIdUser=SBTT0001u No errors!
It turns out that if we write our ActiveX object and produce the necessary data, the program will “think” that it communicates with the hardware.
The idea is as follows: we save the data that we get from the real library into the setup file, create a fake ActiveX object with the same name as the real one, and we will take the response data from the setup file.
In Visual Studio, we wrote a COM library with the name “Signature.Processor”, as in the example above, where we implemented methods that return previously obtained values ​​from the test file.
This implementation worked perfectly with the automated system (AS), which only checks the number of the EDS TM carrier, consisting of 8 hexadecimal numbers (JGetTmNumber) and the signature identifier (JIdUser). However, the new versions of the modules “learned” to verify the signature on the transmitted hash, which is required to be signed in the present.
This cryptographic signature functionality cannot be implemented by counting once the hash and its signature, since when the hash changes, the signature must also inevitably change. The function of automated signing has an EDS server. However, to use it, you need applications for physical access over the local network from each client, setting up administrators directly on the server to open access, and you still need to load the private key into a free slot. Access to all possible machines where, possibly, an automated EDS will be used, cannot be requested. To circumvent this security constraint, we have identified a separate server through which the interaction between the workstations with the tests and the server will take place.
The next problem is that when working with a signature through the FPSU-IP software and hardware complex, the EDS server does not have the ability to work with the TM, since when querying the number of the “tablet” from the FPSU itself, an empty value is returned. Since the FPSU-IP uses the concept of a key (the slot number into which the EDS private key is loaded) for working with EDS, our solution should emulate the number of the “tablet”. For example, all the letters “D” and at the end of the slot number with EDS.
As a result, we got the following solution:
So we have a flexible testing tool that emulates physical interaction with equipment.
At the same time practiced in Microsoft C #.
A similar situation exists with POS-terminals for bank cards. All interaction is carried out through the ActiveX-component, through which various functions of the terminal are called. Only without pitfalls.
As a result, we have the opportunity to automate scenarios on a large number of test data, up to emulation of a card with an incorrect number or expired. This allowed the release of POS-terminals in the process of auto-testing.
What is important, we received additional “buns” - we managed to solve problems not related to automation, which made testers very happy:
- reduction of time during manual testing due to the exclusion of manual manipulations with maps after creating a dedicated test bench and setting up the DevOps pipeline-pipe;
- reducing the time from filing an application for making cards from two weeks to several days. Subsequently, the script for preparing test cards for the “small circle” was implemented;
- eliminating the need for transportation and delivery of test cards - reduced labor costs and consumption of materials for embossing test cards;
- when a new tester was promptly brought out, for example, an outsourcing, the need to equip a workstation with a POS terminal and a TM reader was no longer necessary. This greatly accelerated immersion in the project!
We hope this short post was useful for you. As always, we are happy to chat and answer your questions in the comments.
Source: https://habr.com/ru/post/345066/
All Articles