This document lists demo assets that the field has found useful as part of a core demo or tailored demo.
Most of these test scripts are not considered part of the "core" demo assets which means you will not find them delivered as part of the devops.dockerapp or the devops images. Test scripts that are shown on this page that are part of the core scripts delivered in the Devops image are noted with '(c)'. For example:
uftdev-gherkin (c)
Instructions on How to add a test script to devops container can be found below. Alternatively, you could just clone or fork the repository into the file system of NimbusClient or NimbusServer.
Instruction and expectations for those developing new test scripts can be found below:
Expectations for those developing new scripts
Almost all scripts are available on github, from the admpresales account. However, there are a few scripts that are availalble from other github accounts.
R&D runs a suite of scripts nightly, as a part of their devops implementation. They are all LeanFT scripts, and are available here: R&D LeanFT Scripts. These scripts are, in general, longer and more involved than those in the admpresales account, since they are trully used in a production environment, (as opposed to the scripts in admpresales, that are more demo focused). One way that this is apparent if you look at the details, is that these assets ONLY use objects in Application Models, so the Application Models are much more extensive than the ones in admpresales.
The details of the contents is contained in the project README.md.
| Script Name (now) | Name (pre 2020) | Note |
|---|---|---|
| uftdev-aos-for-340-training | N/A | There is a level 340 training on UFT Dev. This repository has completed tests that are shown in the training video |
| uftdev-aos-for-340-complex-AM | N/A | This test is used as a resource for the UFT Developer level 340 training. It is a solution for the Complex AM workflow, where the AM is created first, then steps are added. |
| uftdev-aos-web-gherkin (c) |
leanft-gherkin | IntelliJ - maven project which uses UFT Developer and gherkins features and files and cucumber for execution. This one actually executes a test against AOS |
| octane-gherkin (c) |
octane-gherkin | Very similar to UFT Developer_Gherkins with the exception that the Gherkin step definitions are left empty so it runs faster. The intent here is to use when focusing on Octane demos only and UFT Developer is not a focus. |
| uftdev-aos-web-se | aos-web-lft4se | Maven project demonstrating using UFT Developer for Selenium in a simple project. This was created using the Selenium OIC. |
| uftdev-se | simple-lft-selenium | Simple script demonstrating Selenium and UFT Developer used together. With webdriver launching and UFT Developer attaching to browser and using the Verify and Reporter classes |
| oscillating | oscillating | This script was used as part of a training session to demonstrate how areas of the Octane Pipeline Analysis screen gets populated based on how scripts run, pass, fail, etc. |
| uftdev-aos-mobile-ios | Mobile AOS Test - iOS | UFT Developer tests against AOS on an iOS device |
| testng-example | testng-example | Simple TestNG tests using UFT Developer Reports to demonstrate how to run TestNG in parallel and pass arguments to a test |
| Script Name (now) | Name (pre 2020) | Note |
|---|---|---|
| uftone-gui-aos-order-purchase | uft-gui-aos-order-purchase | Demonstrates the shopping business process against AOS. The script logs into AOS; shops and completes the purchase (looping from a local data tabe) ; logs out |
| uftone-flight-api-with-gui-verification | flight-api-with-gui-verification | Demonstrates using API test interacting (calling) GUI test. This script is great for showing customer the value of using API testing with their regression suites. Much of regression testing is setting up specific data scenarios so users can perform the actual test they need. Using API for the setup can drastically reduce the overall execution time. |
| uftone-flight-gui-comprehensive | comprehensive-uft-test-flightgui | UFTOne script demonstrating several capabilites of UFT (courtesy Ron Sercely) |
| uftone-aos-web-create-account | uft-gui-create-aos-account | This UFTOne script creates a new account in AOS |
| uftone-using-an-Excel-sheet-with-more-than-256-columns | UFT-using-an-Excel-sheet-with-more-than-256-columns | Prior to v15, The datatable in a UFT test was limited to 256 columns. This test shows how to open Excel files with up to 16,384 columns. Note that starting with v15, 16,364 columns are supported. However, this script shows how a tester can take detailed control of readying/wriging to Excel spreadsheets, which goes well beyond what is available using the UFTOne GUI interface into parameters. |
| Script Name | Note |
|---|---|
| TruClient Native Mobile | This is a simple TruClient mobile script for iOS. Works against the AOS app |
| vugen-correlation-examples | This repository contains two VuGen scripts, which contain correlations of increasing complexity. It also contains a PowerPoint presentation which explains correlation in general, and what is in these scripts in particular. |
| Script Name | Note |
|---|---|
| uft-gui-alm-load-qcp-files | This utility script was written to enable TE to easily load multiple .qcp files into ALM from the administration web page. |
A Successful Git Branching Model
If you can connect to https://www.github.com from your devops container, then from a terminal window on NimbusServer with the devops container up, run the following command:
docker exec devops bash -c "su -s /bin/bash -c 'git clone --mirror https://github.com/admpresales/aos-web-lft4se.git /gitrepo/aos-web-lft4se' apache"
If your container can not connect to the internet, then use these from your command window:
git clone --mirror https://github.com/admpresales/aos-web-lft4se.git aos-web-lft4se
docker cp aos-web-lft4se devops:/gitrepo
docker exec devops bash -c 'chown -R apache:apache /gitrepo/aos-web-lft4se'
You would of course replace the url and name to the git project you wish to use in the above steps
Note: if you create a new test script that think should be added to the admpresales account, the instructions for transfering are here:
How to transfer a github repository
All projects must have a useful README.md. Help on how to create the README.md using the github markdown language can be found:
If you are going to be writing a lot of Markdown, or writing something "fancy", you might want to install MarkdownPad, Markdown Monster, or one of the many other tools available on the internet. These tools allow you to develop Markdown on your desktop where you see the "code" and results side by side. They also support creating tables, which can be quite painful if you do not use one of these tools. You can get MarkdownPad here:
Markdown editor for your desktop
To make it work on Windows 10 however, you will also need to install awesomium sdk:
awesomium sdk
| Field Name | Required(Y/N | Other Comments |
|---|---|---|
| Script Name | Y | Should be same as name of repository, except can use Camel-Case |
| Description | Y | Should be same as github repository description string |
| Table of Contents | N | This is a TOC for the README, in case the README is long |
| Usage | Y | How to use including prerequisites and dependencies |
| Send Feedback | Y | Email(s) |
Scripts should be named: <technology-type-target-short_description>
Examples:
uft-gui-aos-create_new_account
vugen-truclient-aos_sanity
Note: For UFT Developer scripts, the format is:
<technology-IDE-type-target-short_description>
This is important especially for scripts developed with Visual Studio.
If the technology supports it, there should be at least one checkpoint.
If the technology supports it, there should a parameterized value(s).
Test scripts should be verified within both NimbusClient and NimbusServer, on all installed browsers
Only maven projects should be used.
UFT Developer version should be set to use the latest version of UFT Developer by modifying the default pom.xml file. Specifically, in properties create a uftdev.version tag, with a value of RELEASE.
<properties>
<uftdev.version>RELEASE</uftdev.version>
</properties>
Then in each uftdev , replace the hard coded version with ${uftdev.version}, as shown here:
<dependency>
<groupId>com.hp.lft</groupId>
<artifactId>sdk</artifactId>
<version>${uftdev.version}</version>
</dependency>
Web scripts should always be recorded with Internet Explorer so that the active screen is present.
Test script replay should be against the 3 browsers installed on NimbusClient, i.e, IE, Chrome, Firefox.
RonK or Michal?