Common Docker Commands

     We know that Docker is a software framework for building, running, and managing containers on servers and the cloud. Docker gives you the best of this because you can run your tests in containers or isolate them in development and deployment. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.

     In Docker, all software parts can be organized in containers. This includes the operating system, software, dependencies, environment variables, etc. Containers can be shared among different users, enabling quick installation and running of software and services. This makes Docker handy for automation testing, as the relevant container can just be downloaded and run as part of the automated test. However, Docker is also secure because it runs as an isolated process on the host machine. In this article, I would like to share the common Docker commands. The commands categorized as:

  • Lifecycle Commands.
  • Start and Stop Containers Commands.
  • Docker Image Commands.
  • Docker Container and Image Information Commands.
  • Network Commands.
Lifecycle Commands

Below we will discuss various lifecycle commands that using regularly,

To create a container without starting it:

docker create [IMAGE]

Rename an existing container:

docker rename [CONTAINER_NAME] [NEW_CONTAINER_NAME]

Run a command in a new container:

docker run [IMAGE] [COMMAND]

Remove container after it exits:

docker run –rm [IMAGE]

Start a container and keep it running:

docker run -td [IMAGE]

Start a container and creates an interactive bash shell in the container:

docker run -it [IMAGE]

Create, Start, and run a command inside the container and remove the container after executing command:

docker run -it-rm [IMAGE]

Execute command inside already running container:

docker exec -it [container]

Delete a container (if it is not running):

docker rm [CONTAINER]

Update the configuration of the container:

docker update [CONTAINER]

Start and Stop Containers Commands

Below we will discuss various start and stop containers commands,

Start container:

docker start [CONTAINER]

Stop running container:

docker stop [CONTAINER]

Restart container:

docker restart [CONTAINER]

Pause processes in a running container:

docker pause [CONTAINER]

Unpause processes in a running container:

docker unpause [CONTAINER]

Block a container until others stop:

docker wait [CONTAINER]

Kill a running container:

docker kill [CONTAINER]

Attach local standard input, output, and error streams to a running container:

docker attach [CONTAINER]

Docker Image Commands

Below we will discuss various commands that operate with Docker image,

Create an image from a Dockerfile:

docker build [URL/FILE]

Create an image from a Dockerfile with Tags:

docker build -t [URL/FILE]

Pull an image from a registry:

docker pull [IMAGE]

Push an image to a registry:

docker push [IMAGE]

Create an image from a tarball:

docker import [URL/FILE]

Create an image from a container:

docker commit [CONTAINER] [NEW_IMAGE_NAME]

Remove an image:

docker rmi [IMAGE]

Load an image from a tar archive or stdin:

docker load [TAR_FILE/STDIN_FILE]

Save an image to a tar archive:

docker save [IMAGE] > [TAR_FILE]

Docker Container and Image Information Commands

Below we will discuss various commands to deal with Container and Image information,

List running containers:

docker ps

Lists both running containers and ones that have stopped:

docker ps -a

List the logs from a running container:

docker logs [CONTAINER]

List low-level information on Docker objects:

docker inspect [OBJECT_NAME/ID]

List real-time events from a container:

docker events [CONTAINER]

Show port mapping for a container:

docker port [CONTAINER]

Show running processes in a container:

docker top [CONTAINER]

Show live resource usage statistics of container:

docker stats [CONTAINER]

Show changes to files (or directories) on a file system:

docker diff [CONTAINER]

List all images that are locally stored with the docker engine:

docker [image] ls

Show the history of an image:

docker history [IMAGE]

Network Commands

Below we will discuss various network commands to work with Docker,

List networks:

docker network ls

Remove one or more networks:

docker network rm [NETWORK]

Show information on one or more networks:

docker network inspect [NETWORK]

Connects a container to a network:

docker network connect [NETWORK] [CONTAINER]

Disconnect a container from a network:

docker network disconnect [NETWORK] [CONTAINER]

     Thanks for referring this long article. I hope all the commands are useful and helpful in your Docker management cycle and configurations.

make it perfect!

Validate Large Number of Response Data in Postman

     We know that validation of response data from an API is very important at the prior stage of functional and also during the QA execution stage. You may need to validate the response data from API against the AUT or you may need to validate the response data from API against the database result set.

     I had a situation or scenario to validate millions of records in API response against the database table result set. It’s very difficult to achieve millions of record validation, even if we do via manual testing it will take time or getting bore after 50 or 60 record validation. We can achieve this validation by following below procedures:

Prerequisites: Make sure that the Dataset or Resultset available as CSV or JSON file. 

  1. Create Postman request.
  2. Add test case in Postman to iterate and validate the data from CSV or JSON against the response of the API. 
  3. Run the collection using Test Runner, there map the CSV or JSON file.

     I did achieve this via postman scripting and later at the time of execution using collection runner validated the response against the dumps exported from the database. I used below sample script in Postman tests,

pm.test(“Verify ID Present”, function () {
pm.expect(pm.response.text()).to.include(pm.iterationData.get(“column_name_in_the_CSV”));
console.log(“ID “+data[“column_name_in_the_csv”]+” is present”)
});

In the above test, validating the ID values from response data against the ID values that exported from database result set. Like this, we can create multiple tests to validate the response data. pm.iterationData.get(“column_name_in_the_CSV”) this method will iterate through all the data from the respective column of the CSV file and check against the API response.

     Once we create the test scripts in Postman, we can open Run Collection against your collection to get the Runner view (we discussed the execution process in the previous article). In the Runner view, we can upload the CSV file that exported from the database and starts execution. Finally, we will get the results including Passed and Failed cases. If we export the collection as JSON from Postman, we can run the collection with CSV file and generate an HTML report using newman library via command-line. The code as follows:

newman run “collection_JSON_file_path” -d “CSV_file_path” -r htmlextra

     The above command helps to run the same collection, validate the CSV data, and finally, it will generate an HTML report. You can try this way of validation instead of stretching to achieve this kind of testing situation.

make it perfect!

Automate and Validate QR Code Details

     I had a scenario to automate and validate the QR code data. There are some contact details encoded within the QR code, I have to validate the contact details against the expected result. I got a solution from Google’s zxing library and implemented those in my script and validated the QR code data. I have achieved this with help of the following two libraries from Google,

  • Google zxing – core
  • Google zxing – javase

Following are the details of dependencies that I used to achieve this scenario:

<dependency>
<groupId>com.google.zxing</groupId>
<artifactId>core</artifactId>
<version>3.4.1</version>
</dependency>


<dependency>
<groupId>com.google.zxing</groupId>
<artifactId>javase</artifactId>
<version>3.4.1</version>
</dependency>

We can use this capability in different ways. Here, I would like to share the following:

  • Validate QR code from the web application directly.
  • Validate QR code from the local system.
Validate QR code from the web application directly

     In this case, you have to get the QR code image from your application. Create an object of URL class, then pass the URL class object to store the file as an image. Once the image ready, then process it using Google zxing’s method and convert the image to a binary bitmap. Later capture the details of QR code using Google zxing’s decoding method and store it into a Result’s object. Finally, validate that decoded data against expected result using TestNG Assert. Below is the logic:

String QRCodeImage=”//img[@src=’https://assets.outlook.com/qrprod/-1603550372.png ‘] “;
String urlOfQRCode = driver.findElement(By.xpath(QRCodeImage)).getAttribute(“src”);
// Create an object of URL Class
URL url = new URL(urlOfQRCode);
// Pass the URL class object to store the file as image
BufferedImage bufferedimage = ImageIO.read(url);
// Process the image
LuminanceSource luminanceSource = new BufferedImageLuminanceSource(bufferedimage);
BinaryBitmap binaryBitmap = new BinaryBitmap(new HybridBinarizer(luminanceSource));
// To Capture details of QR code
Result result = new MultiFormatReader().decode(binaryBitmap);
Assert.assertEquals(“Expected_Result”, result.getText());

Validate QR code from the local system

     In this case, you should have the QR code image ready in your local system path. Once the QR code ready, pass the QR code object to store the file as an image. Once the image ready, then process it using Google zxing’s method and convert the image to a binary bitmap. Later capture the details of the QR code using Google zxing’s decoding method and store it into a Result’s object. Finally, validate that decoded data against expected result using TestNG Assert. Below is the logic:

// Pass the QR code object to store the file as image
BufferedImage bufferedimage = ImageIO.read(new File(“your_QR_code_image_path”));
// Process the image
LuminanceSource luminanceSource = new BufferedImageLuminanceSource(bufferedimage);
BinaryBitmap binaryBitmap = new BinaryBitmap(new HybridBinarizer(luminanceSource));
// To Capture details of QR code
Result result = new MultiFormatReader().decode(binaryBitmap);
Assert.assertEquals(“Expected_Result”, result.getText());

     Try to use the above logic in your code if you have any situation to validate the QR code details during automation execution.

make it perfect!

Progressive Web Application Testing

     Progressive Web Application (PWA) technology is exploding in the IT market due to its relative simplicity in development combined with the fast user interaction it offers. But testing PWA requires a different approach, even while the testing methods remain the same. In this article, I would like to share about PWA, why testing PWA is different, features of PWA applications, automation tools to test PWA applications and best practices.

What is Progressive Web Application (PWA)?

     A web application that combines the functionality of native apps with scalability and reach of web pages. Business that want to get fresh content and features to their users without the overhead of native applications. End users who want a fast, seamless, personalized experience; they are using Progressive Web Applications. PWA works in the following fashion:

  • Always Update:
    • Integrate new features immediately.
    • Work on any device or technology.
  • Looks Like an App:
    • They get their own shortcut.
    • Desktop icon.
    • No browser tab.
  • The Tech:
    • Service Workers
    • Cache API
    • Indexed DB
    • Fetch API
    • HTTPS
  • Direct to Customer:
    • Doesn’t have to go through an App Store.
    • Never has to be updated.
    • Always Personalized.
Why testing Progressive Web Application (PWA) is different?

     Just like any other web applications, it is imperative to test the PWAs as well. However, testing a PWA is much different from testing traditional web applications. In traditional web applications, one would test for the features provided by the application. Newer types of testing include checks to see if they render appropriately on various mobile devices and to ensure that the behavior is predictable and consistent but now with progressive web applications, the methodology in performing cross browser testing is much different. Let’s look into the process of testing a progressive web app,

Testing for reliability

     PWA reliability depends on the ability to serve pages over https. Using a tool such as Lighthouse will allow you to ensure all the web pages are served over https. Lighthouse can be used for more than just testing the reliability of the website.

Manual testing for native-like behavior

     This type of testing requires manual testing on various different browsers and devices. One of the primary behavior is the capability to add the PWA to the home screen like any other apps. With the web app being added to the home screen, it should start to behave like an app and not like a website. This includes the way it launches, and its ability to have some content even when there is no network connection.

Software-based testing for native-like behaviour

     Manual testing is recommended for the most common browsers on some of the most common devices. However, since it’s impossible to test on all browsers and all devices, you can use the tool Lighthouse to evaluate some of the native-like features. Lighthouse will also test the loading capabilities of all the web pages in offline mode. For example, the presence of offline functionality and loading of pages for offline mode can be tested using Lighthouse. The software examines these features by looking for the metadata that lets browsers know what to do when the PWA is launched in offline mode.

Making the best use of URLs

     A progressive web application as we have seen can look and behave like an app. However, one must remember that it’s still a website. For this reason, all pages must have a URL which is shareable on social media. All pages having URLs also ensures that the search engine crawlers index the entire website correctly. There might be some content which might have very similar URLs. Such cases often occur in a PWA and add a canonical tag in the head of the page.

Cross browser testing

     PWA heavily relies on the features of modern browsers as we have seen earlier. This makes it extremely important to ensure that the site loads and behaves as expected on all the different types of browsers such as Firefox, Chrome, Safari, etc. Some of the older browsers such as internet explorer 8.0 and earlier will not support PWAs. It is thus crucial to check how it behaves when loaded on such older browsers.

     Cross browser testing has been prevalent for a long time. However, its prominence has significantly grown due to the lack of standards and uniformity in browsers and devices across the world. Considering the heavy dependency of PWA on modern browsers, cross browser testing of PWA apps holds a major importance in today’s mobile first world.

Features of Progressive Web Applications
  • Responsiveness and browser compatibility: The progressive web design strategy is to provide basic functionality and content to everyone regardless of browsers and connection quality. So PWA is compatible with all browsers, screen size, and other device specifications.
  • Offline support: PWA support offline and low-quality network both.
  • Push notifications: Push notifications play important role in customer engagement if used wisely. Like Native mobile app the PWA supports push notification feature.
  • Regular updates: Like any other app, PWA can also self-update.
  • A native application like interface: These apps mimic interactions and navigation’s of native apps.
  • Discoverability: PWA applications are shared through URLs so which can be easily found. A user has to visit on the site and add that to the home screen.
Important points to keep in mind while testing PWA
  • Validate PWA manifest: A manifest file is a must for PWA. A tester should look for following in the file:
    • It has a name or short_name property.
    • It has start_url property.
    • Web App Manifest has an icon property must include a 192px and a 512px sized icons.
    • Display property should be set to standalone, full screen and minimal-UI.
  • Validate service worker: Service worker registered with a fetch event handler.
  • The website should be served fully via HTTPS: Safety is the major concern in the world of PWA and tester should always make sure that site is served via HTTPS. To test this, you can use Lighthouse tool.
  • Web pages are responsive: Make sure that your web application shows responsive behavior across all mobile and desktop devices.
  • Offline loading: All of the web pages or at least some critical pages should work offline. As a tester, you need to make sure that your web app responds with a 200 when it is offline. You can use Lighthouse or WireMock tool for testing this.
  • Metadata for ‘Add to Homescreen’: You need to test if the web app provides a metadata for ‘Add to Homescreen’. You can use Lighthouse to test for metadata for ‘Add to Homescreen’.
  • Page rendering and transitions: Transitions should be smooth and should not be snappy even on slow networks. This should be done manually on a slow network. A tester should check the responses. When a user clicks on any button, the page should render immediately without any delay.
  • Each page must have a URL: Every page on your web app must have a URL and all the URLs must be unique. The URLs can also be opened directly in new browsers.
  • Push Notifications: We should test the push notification keeping in mind that they are not overly aggressive. Also, they should be asking for permissions to the user.
  • Functionality: This is the most essential part of any testing. Functional testing covers the aspects of the application with respect to the functionality defined in the requirement document. We can do it both manually and through automation.
Automation tools to test PWA

     PWA’s are like any other mobile app. Here we are discussing high-level about following tools:

  • CloudQA.
  • Appium.
  • Lighthouse.
CloudQA

     CloudQA comes with codeless test automation tools through which a user can record the functional test cases and execute them. It also comes with the capabilities to add assertions, manage test case execution and reporting. It is a powerful tool for codeless automation, so a tester without having any coding knowledge can easily use it and automate the test cases. It support the automation for PWA applications. A user can save the set of functional test cases and later execute them at the time of regression. There are options to get the test execution report, create and manage test suites and execute test suite and get the report.

     This is good enough to start with for manual testers because it does not require much of the coding knowledge and quite interactive and easy to use. Also, it does not compromise with capabilities one can add with automation.

Appium

     Appium is suited quite well for testing PWAs. You will find that, when running on a device, there is not a whole lot that makes a PWA special, it is just a web page running in a special web browser (called a ‘context’ in the Appium world) that is wrapped by the native app.  Appium is just a connector between your test scripts and your device that runs the app so the details will depend on what test script technology you choose. The only thing that is different when using Appium/Devices is that the first step of the test needs to ‘switch contexts’ so that the automated script commands are sent to the ‘in-app browser’ that the PWA is running in.

Lighthouse

     Lighthouse is a tool provided by Google that tests app for PWA features. This is open source tool and it tests app against the PWA guidelines such as:

  • Tests the application offline or flaky network.
  • It is served from a secure origin i.e. https.
  • It is relatively fast.
  • Uses certain accessibility best practices.

     Lighthouse is available as a chrome extension and a command line tool. Running Lighthouse as chrome extension- Lighthouse can be downloaded from Chrome Web Store. Once installed it will add a shortcut to the taskbar. Then, run lighthouse on your application and choose Generate Report with the app open in the browser page. Here I have generated the report against one PWA application Starbucks (https://app.starbucks.com/). Got following reports:

     Running Lighthouse from command Line. Lighthouse is available as a Node module, which can be installed and run from command line. To install run this command:

npm install -g lighthouse

You can check Lighthouse flags and options with the following command:

lighthouse –help

     I have executed the lighthouse from command line for Starbucks application. I have executed below command in command-line:

lighthouse https://app.starbucks.com/ –view

     This will generate all the status in command-line and also you can see the application open in the browser. Once execution complete the browser will close and the report will generate in form of HTML and it open in another browser automatically. The command-line view looks like below and HTML report looks same as above one which we executed using chrome lighthouse extension,

     Progressive Web Application (PWA) technology is exploding in the IT market due to its relative simplicity in development combined with the fast user interaction it offers. PWA heavily relies on the features of modern browsers as we have seen earlier. This makes it extremely important to ensure that the site loads and behaves as expected on all the different types of browsers. This article helps the manual and automation engineers to learn PWA application, its features, and key points while testing PWA and the testing tools for PWA.

make it perfect!

Execute JMeter Scripts Behind the VPN

     One of my colleague had some issue while running the JMeter scripts behind the VPN or proxy. I proposed four solutions. I would like to share those four solutions here, two of them within the JMeter UI itself, another one we can do along with launching JMeter, and the final one is a static configuration within the system.properties file that available within JMeter/bin. We will discuss below more on different solutions.

Solution 1: Configure the Proxy Server into each HTTP Request

     In the HTTP Request, we can find out the Proxy Server section at the Advanced tab of the HTTP Request element. There we can add the proxy server name or IP address, port number, username, and password. In some cases, username and password are optional. Below is the screenshot details,

Solution 2: Configure the Proxy Server into HTTP Request Defaults

     Suppose if we have 50 or more HTTP Requests, then it will be difficult to configure the Proxy Server details in each HTTPT Request that we discussed in Solution 1. And also, in future your proxy settings changed, we may have to change those 50 and more requests. So the idea is to configure the Proxy Server into HTTP Request Defaults. In this case, we will not input anything into the HTTP Requests, just open HTTP Request Defaults, find out the Proxy Server at the Advanced tab, and configure the details. You can add HTTP Request Defaults under Test Plan and at the Thread Group level like a global declaration. Below is the screenshot details,

Solution 3: Launch JMeter from the command line with the following parameters

-H
[proxy server hostname or IP address]
-P
[proxy server port]
-N
[nonproxy hosts] (e.g. *.apache.org|localhost)
-u
[username for proxy authentication – if required]
-a
[password for proxy authentication – if required]

Following are some examples in the Windows system:

jmeter -H [proxyAddress] -P [portNumber]

Or you can use the IP instead of the Server name
jmeter -H [IPAddress] -P [portNumber]

If your Proxy Server required a username and password, use the command below
jmeter -H [proxyAddress] -P [portNumber] -u [username] -a [password]

If a non-proxy host list is provided, use this command
jmeter -H [proxyAddress] -P [portNumber] -u [username] -a [password] -N [proxyAddress]

In he above method, no need to worry about the proxy server configuration at the JMeter UI level.

Solution 4: Setup the proxy properties into the system properties file

     Open the system.properties in edit mode, this file is located under \apache-jmeter-5.1.1\bin directory (I am using JMeter 5.1.1). Add the following properties to the end of the file,

http.proxyHost
http.proxyPort
https.proxyHost
https.proxyPort

For example:

http.proxyHost=localhost
http.proxyPort=8887
https.proxyHost=localhost
https.proxyPort=8887

Suppose if a non-proxy host list is provided, then JMeter sets the following system properties:

http.nonProxyHosts
https.nonProxyHosts

     We can use one of the above solutions to run the JMeter script behind the VPN or proxy. We can ignore the first method if you have more HTTP Requests to execute. In some situations, we may need to work on the scripts without VPN or proxy, in that case, we can go ahead with solution 2 (need to disable HTTP Request Defaults component) or solution 3.

     Please try to utilize any of the above solution if you have a situation of running JMeter scripts behind the VPN or proxy.

make it perfect!