Automated Testing Tool

Overview

During my employment with Mercury Security Products, I was tasked with helping to establish the foundation of an automated testing suite for current and upcoming access-control products. Working together with other software developers, we iterated upon previously built internal software to allow easy scripting and execution of a variety of required testing scenarios.

The software was built in C# with the Windows Presentation Foundation (WPF), utilizing an internal DLL to allow communications between a host computer and a Mercury Security device with networking capabilities. I assisted in creating a graphically-based controller for loading, running, pausing, and stopping scripts, as well as assisted in establishing a language for internal users to create scripts for tests.

Note: This page discusses tools and software that are not public facing, therefore some details are intentionally left vague.

An LP4502, one of the devices that would make use of the automated testing framework.

Developing a Language

The first iteration of an internal testing tool took the form of a CLI program with scripts written in XML. It would perform all tasks synchronously, which unfortunately proved to be too limited in capability for what the QA team needed to run tests. Our DevOps Engineer, however, realized that we could migrate this tool into a more commonly used software by developers and QA testers alike, establishing a queue for processing commands and expected responses in the process.

The software already had the capability to load and process "scripts" in the form of .txt and .ini files. These files would contain a series of commands that Mercury devices would read and execute upon receiving, including various commands for configuration or simulating access-control related functions. Utilizing these scripts allowed a for more seamless integration into the workflow, building off a language everyone was already familiar with.

Building the tools

Once the foundation was built for the testing queue and scripting language, I was tasked with constructing the visual components for controlling and monitoring the testing process. Reserving some unused space in the testing software, I set up a progress bar, standard control buttons (play, pause, stop), and a text field that displayed the name of the script being executed for clarity. All of these components made use of what was available within the WPF framework, as the software had already been built upon it. Constructing these components required close collaboration with our DevOps engineer, as he constructed the testing queue simultaneously.

Jenkins Integration

Upon completing the first working pass of the testing queue, we needed to ensure that the testing software could execute scripts in a "headless" manner, so that scripts could be run by our internal Jenkins server that I had established. Working together with the QA team allowed us to begin creating a suite of nightly automated tests on a dedicated set of devices that would make use of our new scripting language and testing tools, with Jenkins reporting results to appropriate parties.

Page updated

Google Sites

Report abuse