System Test Plan for Prototype II

v0.1

by Scott Senkeresty

The system test for DNM Prototype II will consist of the following things:

These tests should insure that the prototype meets 100% of the functionality specified in the Requirements for Prototype II. It will also insure that the system has acceptable levels of performance and quality. A full system test would include other areas, such as Stress and Environmental Testing.

Functionality Tests

The function of the following tests is to prove that the prototype provides 100% correct functionality as specified in the prototype II requirements document.

  1. User Interface Module

    Test Case: Enter valid login name and password at the login prompt
    login: sroliver
    password: ********
    Expected Result : Main menu displayed

    Test Case: Enter invalid login name and any password at the login prompt
    login: xxxxxxxx
    password: ********
    Expected Result: Invalid Login error and prompts the user to acknowledge with Return

    Test Case: Enter valid login name and incorrect password at the login prompt
    login: sroliver
    password: foobar
    Expected Result: Invalid login error and prompts the user to acknowledge with Return


    Test Case: Execute Discover Nodes
    > 1 Return
    Expected Result: Displays the node names and prompts the user to press Return.

    Test Case: Enter Return after the node names are displayed
    > Return
    Expected Results: Exit to the DNM main menu

    Test Case: Execute Link Utilization
    > 2 Return
    Expected Results: Link utilization is displayed. See section 2 for link utilization verification.

    Test Case: Lock the DNM Priviledged User Interface
    > 3 Return
    Expected Results: The Main menu and command inputs are no longer active. The DNM should re-display the password prompt. See test cases 1-3

    Test Case: Exit the DNM
    > 4 Return
    Expected Results: Exit the DNM and return to unix command prompt

    Test Case: Enter an invalid menu item.
    > a Return
    Expected Results: Redisplay the DNM main menu

  2. Protocol and Statistics Modules (including Data Collection / SNMP)

    Note: Requirements v1.0 and Design v1.1 are inconsistant in terms of the Statisics gathering capabilites These tests assume that only Link Utilization can be gathered, as specified in the design document.

    Test Case: Collect Link Utilization between 2 machines on Cobra Cluster.
    Expected Results: The UI should display a value for the link utilization for the specified machines. To determine the "correctness" of the value returned, the Lan Analyser or HP Internet Advisor should be used to measure the Link Utilization and the values compared. DNM should return a value with a value agreeing within 5% of the value measured with the network tools.

    To test the Protocol Module a configuration file must be coded. This file will be available in the ~coram account for the PPC to read. This file will designate the name or IP address of the node to monitor, the frequency of the monitoring, and what statistics to gather from the given machine. The expected results will be based on the configuration file. The exact values will be determined after the config file is admitted.

    Multiple Configuration Files are to be tested :

  3. Node Discovery Module

    Test Case: Discover all nodes on the Cobra Cluster.
    Expected Results: The UI should display every node on the Cobra Cluster. The output should be: 
    	129.65.98.1     cobra.csc.calpoly.edu
	129.65.98.2     python.csc.calpoly.edu
	129.65.98.3     adder.csc.calpoly.edu
	129.65.98.4     boa.csc.calpoly.edu
	129.65.98.5     anaconda.csc.calpoly.edu
	129.65.98.6     mamba.csc.calpoly.edu
	129.65.98.7     krait.csc.calpoly.edu
	129.65.98.8     hognose.csc.calpoly.edu
	129.65.98.9     rattler.csc.calpoly.edu
	129.65.98.10    garter.csc.calpoly.edu
	129.65.98.11    moccasin.csc.calpoly.edu
	129.65.98.100   phoenix.csc.calpoly.edu
    The output may be sorted in other orders, but must include all and only these nodes.

  4. Distribution Control Module

    According to the design v1.1, no distribution takes place.

  5. Security Module

    Security will not be tested in Prototype II; it is being pushed off until prototype III. Testing methods are still under investigation.

    Currently two ideas are presented for testing security.

    1. Use the Internet Advisor.
      Sample Test Case: Request Link Utilization Information, and using the Internet Advisor, store the packets that pass between the Priviledged User Interface and the Client.
      Expected Results: The data stored in the packets should be "encryted". Method of determining this is still unknown

    2. Write a dummy client.
      Sample Test Case: Select a "special" menu selection that will cause the Priviledged User Interfact to send a packet to a special testing client.
      Expected Results The client code could then decrypt the message and be sure the results are exactly what was sent; and that it was "encrypted" method of detecting encryption still unknown

Performance Tests*

We use the term performance loosely, to include a broad range of measurable aspects of the system. Included in Performance Testing is:

Software Quality Attribute Tests *

An important part of the requirements for any system are the quality considerations. It is quite possible that certain quality considerations will be un-important, but they should at least be thought about, and a conscious decision made. Quality should never "just happen".

The following list of quality attribues is incomplete but a good place to start. Only a select few of these attributes will be tested for prototype II (the ones with the links).

Attribute Definition Requirements
Adaptability the ability for the system to adapt to changes in the environment.
Availability the amount or percent of time which the system is usable. The system will be available 100% of the time.
Cohesiveness the degree to which the functions in the system perform single specific duties. There will be no global variables.
Configurability the degree to which the system can be configured to perform in a different manner. All configurable options will be placed in one configuration file.
Consistency the degree to which the interfaces (user and module) are consistant. All function names will adhere to the guidelines outline in the coding standards AND prototype II design document.
Correctness the extent to which the software satisfies its specification. The code will be 100% correct.
Installability the ease in which the system can be installed. The DNM and its process components can be installed on any machine on the Cobra cluster.
Localizability the ease in which the system can be changed to use a different language. None.
Maintainability the ease with which a software system can be modified to correct faults. The cyclomatic complexity of all function will be less than or equal to 10.
Modifiability the effort required to modify or add new features to the system.
Portability the ability of the system to run on multiple platforms without code changes. All RPC and Thread calls will use DCE versions of these calls.
Readability the ease in which the code or documentation may be read and understood. Every function will have a plain English description of its purpose
Reliability the degree to which the system will not fail. The mean time between failures will be greater than 200 hours.
Reusability the degree to which existing work (code, design, etc) may be used to solve similiar problems in the future. SNMP functionality will be recoded only where 100% unavoidable.
Serviceability the ease in which a system may be maintained in the field after installation. None.
Security the degree to which system is "secure". All process components will accept requests only from the priviledged node. All such requests will be encryped.
Testability the ease in which the system may be verified as correct and matching the specification. Every requirement will be 100% testable, meaning a test can be ran against the requirement, and there will be no question as to whether or not it passed.
Traceability the degree to which decisions (and/or faults) maybe traced back to previous stages in the life-cycle. Every function will include a comment in its prototype, stating which requirement number the function addresses.
Understandability the ease in which a system (its code, design, documentation, etc) may be comprehended. Every function will have a plain english description of its purpose and assumptions.
Usability the degree to which a system is benificial. The priviledged user interface component can be executed on any Cobra machine.

* These requirements are stated here for the first time. As a test designer, you must have something to test. I am taking the authority to state these as testable requirements; though, they are not clearly stated elsewhere in the specification or requirements documents.

Maintainability Test

To help increase the likelihood of maintainable code, the DNM will measure the Cyclomatic Complexity of all functions. Every function must have a Cyclomatic Complexity of less than or equal to 10.

Security Test

Security is a very serious issue for a network manager. To this end, all communication between process components must be encrypted. It must be impossible for a process component to accept a request from any process other than the privileged user interface (or its surragates).

The testing strategy for this is still under investigation. It will not be tested until Prototype III.

Author : Scott Senkeresty