IBM-ның жүйелік тестілеу құралы: TPNS және WSim тарихы

Test automation tool developed by IBM

Teleprocessing Network Simulator (TPNS) is an IBM licensed program, first released in 1976 as a test automation tool to simulate the end user activity of network terminal(s) to a mainframe computer system, for functional testing, regression testing, system testing, capacity management, benchmarking and stress testing. In 2002, IBM re packaged TPNS and released
Workload Simulator for z/OS and S/390 (WSim) as a successor product.

Teleprocessing Network Simulator (TPNS) Version 1 Release 1 (V1R1) was introduced as Program Product 5740 XT4 in February 1976, followed by four additional releases up to V1R5 (1981). In August 1981, IBM announced TPNS Version 2 Release 1 as Program Product 5662 262, followed by three additional releases up to V2R4 (1987). In September 1998, IBM announced the TPNS Test Manager (for ) as a usability enhancement to automate the test process further in order to improve productivity through a logical flow, and to streamline TPNS based testing of IBM 3270 applications or CPI C transaction programs. In December 2001, IBM announced a Service Level 0110 Functional and Service Enhancements release. In August 2002, IBM announced Workload Simulator for z/OS and S/390 (WSim) V1.1 as Program Number 5655 I39, a re packaged successor product to TPNS, alongside the WSim Test Manager V1.1, a re packaged successor to the TPNS Test Manager. In November 2012, IBM announced a maintenance update of Workload Simulator for z/OS and S/390 (WSim) V1.1, to simplify the installation of updates to the product. In December 2015, IBM announced enhancements to Workload Simulator for z/OS and S/390 (WSim) V1.1, providing new utilities for TCP/IP data capture and script generation.

TPNS supports the simulation of a wide range of networking protocols and devices: SNA/SDLC, start stop, BSC, TWX, TTY, X.25 Packet Switching Network, Token Ring Local Area Networking, and TCP/IP servers and clients (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP clients). TCP/IP servers and clients (Telnet 3270 & 5250, Telnet Line Mode Network Virtual Terminal, FTP and simple UDP clients),

as a software development tool — for prototyping software programs during the development process.

In 1998, IBM introduced the Test Manager for TPNS V3R5 which added substantial automation features that streamline many repetitive tasks associated with planning, preparing, operating and analyzing a TPNS based simulation run, while still enabling the test programmer optionally to retain full awareness, in real time, of the events unfolding at every step and to intervene if necessary.

During the simulation, ITPENTER keeps a log (on tape or disk) of all messages exchanged between the simulated device(s) and the real application(s) under test. After the simulation has completed, the test programmer can therefore run any of three TPNS supplied log analysis utilities.

The log list utility (ITPLL) is used to list and review the logged data in detail, including operator commands, data transmitted and received, screen images, message generation tracing, and test data verification.

The response time calculator (ITPRESP) is used to calculate and print response times reports.

The log compare utility (ITPCOMP) is used to compare the 3270 screen images logged during two simulation runs of the same script(s) and report on differences between them.

The Echo program (ITPECHO) is supplied with TPNS (and WSim) as a ready made VTAM application that runs in the system under test as a target for messages sent by real or simulated 3270 display device(s). Using ITPECHO enables network connectivity and load testing to be carried out without the need to set up a copy of a production level application and its databases, thereby saving test personnel the effort of writing scripts or allocating disk space for such an application and its datasets. As its name implies, ITPECHO will return exactly the message it has just received (when sent with the 'Enter' key), but it can also return the amount of data that was requested in the previous message (when sent with the 'PF5' key), from real or simulated display device(s). The latter feature is useful for creating test conditions where the 'send' and 'receive' messages need to be of different and variable lengths. To provide the amount of data requested, ITPECHO pads its message with as many occurrences of the alphabet as necessary, or a fraction of it if the amount of data requested in less than 26 characters.

Rather than applying TPNS as a test tool, AVMON (AVailability MONitor) is a TPNS implementation designed to monitor the availability and performance of real network subsystems running in production (NetView and TSO). The TPNS supplied sample AVMON scripts monitor only NetView and TSO, but a user installation may add support for monitoring more subsystems (CICS, IMS, DB2, etc.) and any of their applications, by modifying or extending the AVMON scripts, perhaps through the use of the Interactive Data Capture script generator mentioned above to create the new script(s). During the TPNS simulation run, AVMON updates the TPNS log dataset, which can therefore be processed by the three TPNS log analysis utilities (log list, response times calculator and log compare). AVMON monitors availability by simulating a single terminal user in session with a real subsystem, periodically sending a brief probing message, and sensing when the subsystem becomes unavailable. When the simulated user detects unavailability, it sends a message to the operator console alerting the operator to the problem. AVMON also tracks the time it takes for the monitored subsystem to return a response, and reports whenever a user specified performance threshold is exceeded. By using the TPNS Response Time utility, the performance statistics of the entire monitoring run can be compiled into a single report, thus providing an installation with evidence of the end to end response times experienced by the subsystem's end users. For automated operations, AVMON may also be modified to perform operator functions when it senses that a real resource has become inoperative and therefore requires an operator intervention, such as restarting the resource for example.