UNIX Command Dictionaries

The UNIX manual is mostly on line and the UNIX `man’ command is used to display parts of the manual. Typing

man [command] (CR)
will yield information in an almost readable format during a IBM Telnet session. The problem is that you have both UNIX and CMS paging the output. You respond to the UNIX paging prompt `:’ with a `(CR)’ return for a new page, `d (CR)’ for a short new page, u (CR)’ for a short page up (back), or `q (CR)’ to quit. For the CMS paging prompt `holding’, respond with the designated `Clear-key’. If you are using IBM Telnet, then `man [command]‘ usually produces poor output for the head of the display. The version `man -blou [command] (CR)’ should remove underscoring and other backspacing for printing at UIC, but does not work completely. For a quick overview of a command try the `-q’ quick option:

man -q command] (CR)
Alternatively,

man [command] > [file] (CR)
is useful for redirecting the output to a file that can later be transfer back to CMS for printing (e.g. by `printdoc’). The UNIX no paging `-r’ option does not work in a CMS session, so the CMS user has to press both the `Return-key’ for a new UNIX `man’ page or the `Clear-key’ for a new CMS page depending on the odd UNIX prompt or the CMS “HOLDING” prompt, respectively.

This abridged UNIX dictionary is only intended to be a short enough list to get you started without being bewildered by the enormous UNIX manuals, but with enough commands to be able to do something useful. For more information use the `man’ command or refer to some of the UNIX texts. UNIX is a trademark of Bell Laboratories.

The format is

[command] [generic operand] : [Definition.]

along with a carriage return `(CR)’ for each command. DO NOT FORGET that almost all UNIX commands must be in lower case. Do not attempt to learn all of this at once, but read some of it and try it out at an actual computer session.

Introduction of System Testing

System testing is testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of Black box testing, and as such, should require no knowledge of the inner design of the code or logic.

As a rule, System testing takes, as its input, all of the “integrated” software components that have successfully passed Integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of Integration testing is to detect any inconsistencies between the software units that are integrated together (called assemblages) or between any of the assemblages and the hardware. System testing is a more limiting type of testing; it seeks to detect defects both within the “inter-assemblages” and also within the system as a whole.

Types of system tests

The following examples are different types of testing that should be considered during System testing:

• Functional testing
• User interface testing
• Usability testing
• Compatibility testing
• Model based testing
• Error exit testing
• User help testing
• Security testing
• Capacity testing
• Performance testing
• Sanity testing
• Regression testing
• Reliability testing
• Recovery testing
• Installation testing
• Maintenance testing
• Accessibility testing

What is Test Scripts

A test script is a short program written in a programming language used to test part of the functionality of a software system. Any test that is written as a short program is regarded as an automated test. Test scripts written as a short program can either be written using a special automated functional GUI test tool or in a well-known programming language (such as C++, Tcl, Expect, Java, Perl, Python, or more recently, Ruby).

Introduction of Regression Testing

Regression testing is any type of software testing which seeks to uncover regression bugs.

Regression bugs occur mainly for the following two reasons:
• Whenever some bugs are fixed there is a probability that while fixing those bugs some more bugs
have appeared in some other modules of the application.
• Adding additional modules to the application or modifying the system can also cause bugs in the
application.

Introduction of User Acceptance Testing

The user acceptance testing is usually a black box type of testing. In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing.
However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment.

The steps taken for User Acceptance Testing typically involve one or more of the following:

1) User Acceptance Test (UAT) Planning
2) Designing UA Test Cases
3) Selecting a Team that would execute the (UAT) Test Cases
4) Executing Test Cases
5) Documenting the Defects found during UAT
6) Resolving the issues/Bug Fixing
7) Sign Off

User Acceptance Testing is of Two types:

• Alpha Testing: Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. Alpha Testing is carried out within the organization and not at the client’s side.

• Beta Testing: Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.