Skip to content
Solved Assignments

Software Test Plan for Secret Simulation: Abstract Data Type (ADT) Functionality Evaluation

This document outlines a software test plan focusing on evaluating the functionality of Abstract Data Types in a secret simulation.

Preview 6 of 18 pages

See the first 6 pages exactly as they appear in the document.

  1. Page 1
    Read page 1 as text

    Software Test Plan for Secret Simulation: Abstract Data Type (ADT) Functionality Evaluation Software Test Plan for ToDo List Programming Assignment X Monday, July 6, 2015 Prepared By Domicia Herring dnh@uah.edu Prepared For Dr. Rick Coleman, Instructor CS 221, Data Structures in C++ Computer Science Department University of Alabama in Huntsville Based on the provided Software Test Plan for the Secret Simulation system, explain how the test procedures ensure the effectiveness and robustness of the system in terms of functionality, reliability, and performance. In your response, analyze the testing strategies mentioned, such as integration testing, regression testing, and system testing, and discuss how each approach contributes to the identification of potential issues in the software. Word Count Requirement: 400 - 500 words.

  2. Page 2
  3. Page 3
    Read page 3 as text

    Table of Contents 1.0 System Overview............................1 2.0 Referenced Documents.......................1 3.0 Test Procedures............................1 Appendices A. Test Plan Forms............................8

  4. Page 4
    Read page 4 as text

    Software Test Plan Secret Simulation 1.0 System Overview A secret government agency has need of a special Abstract Data Type (ADT) for use in a Basically Secret Simulation (BSS). The ADT may be thought of abstractly as three queues (3Qs). The 3Qs each can hold the same type of data structure. Commands at regular time intervals (CARTI) will be sent to this portion of the BSS. Command one (C1) will be to dynamically create a data structure (DCDS), place into the data structure information to be supplied (TBS), and enqueue it into the first queue (Queue A). Command two and three (C2 and C3) will be to dequeue a structure from Queue A and immediately enqueue it into Queue B (C2) or Queue C (C3). Command four and five (C4 and C5) will be to dequeue and destroy a structure from either Queue B (C4) or Queue C (C5). Details of this functionality are given in section 2.0. As usual should you or any of your programming team divulge even the smallest bit of information about this BSS we will have to shoot you. 2.0 Referenced Documents  Programming Assignment X Statement of Work.  Dale, Nell and Teague, David, C++ Plus Data Structures 2nd ed. 2001.  “Programming Assignment 2 Hints ” web page , http://cs.uah.edu/~rcoleman/CS221/ProgAssign/cs221Prog2Hints.html  Softw are Design Document for the Secret Simulation program. 3.0 Test Procedures The following tests will be performed on the software before its release.

  5. Page 5
    Read page 5 as text

    Table f 1 f defines f the f scope f of f the f Defence f Integration f and f System f Test f effort. IST f Testing f for f Defence … IS … IS F NOT … Positive f and f negative f functionality Load, f capacity, f and f volume Reliability f and f stability Error f handling f and f recovery Competitive f inferiority f comparison Operations f and f maintenance Usability Data f quality Performance Localization Compatibility Security f and f privacy Installation f and f migration Documentation Interfaces Distributed f (outsource f usability f and f localization f testing) Black - box/behavioral f testing 3.x f regression f testing 3.1 f regression f testing f (across f increments) Date f and f time f handling Standards f and f regulatory f compliance Code f coverage f verification Set - use f pair f or f data f flow f verification Database f table f overflow f error f handling User f interface f offensiveness User f interface f performance f under f maximum f load OfficeArrow f integration Migration f and f media f load f fine - tuning Legacy f browsers, f client, f or f server f compatibility OS f login f identity f override Legacy f (pre f 3.0) f migration Unit f or f component f testing f (except f supporting f development f team) White - box/structural f testing Table f 1 : f IST f for f Defence f IS/IS f NOT f (Scope)

  6. Page 6
    Read page 6 as text

    Definitions Table f 2 f defines f some f test f terms f and f other f terms f found f in f this f document. Term Meaning Black f Box f Testing Testing f based f on f the f purposes f a f program f serves; f i.e., f behavioral f testing. Bug Some f aspect f of f the f system f under f test f that f causes f it f to f fail f to f meet f reasonable f expectations. f “Reasonable” f is f defined f by f iterative f consensus f if f it f is f not f obvious. f Build A f collection f of f software f objects f of f known f revision f levels f compiled f into f one f or f more f software f executables f for f installation f on f the f system f under f test. Test f Release Confirmation f Test A f selected f set f of f tests f designed f to f find f ways f in f which f a f bug f fix f failed f to f address f the f reported f problem f fully. Entry f Criteria The f parameters f that f determine f whether f one f is f ready f and f able f to f enter, f continue, f or f exit f a f particular f test f phase. f Continuation f Criteria Exit f Criteria Integration f Test A f set f of f tests f designed f to f find f bugs f in f the f interfaces f (control f and f data f flows) f between f tested f components f of f the f system. Quality f Risk The f possibility f of f a f specific f system f failure f mode, f either f localized, f caused f by f subsystem f interactions, f or f a f repercussion f effect f of f a f remote f system f failure, f that f adversely f affects f the f system’s f user. Reference f Platform A f “known f correct” f system f against f which f one f can f compare f the f results f and f behaviors f of f the f system f under f test. f Server f Cluster A f set f of f servers f configured f to f perform f a f particular f role f in f terms f of f development, f testing, f or f production. Regression f Test A f set f of f tests f run f to f find f new f failures, f or f regressions, f that f changes f have f caused f in f component, f interface, f or f system f functionality. Smoke f Test A f limited f set f of f regression f tests f designed f to f determine, f though f a f random f sample f of f critical f functions, f whether f a f given f build f is f ready f for f testing.

12 more pages in the full document

Unlock it once and it stays in your library, ready to chat with or turn into flashcards.

Unlock the full document
See all

Study this document with CramX

Once it is in your library, every tool can work from it.