选课系统测试计划.htm

初学者在软件开发中可以用到的一些文档

        / accounts</li>
      <li>worst case transaction volume / mix (see performance testing above).</li>
    </ul>
    <p>NOTES: Stress testing's goal might also be stated as identify and
    document the conditions under which the system FAILS to continue functioning
    properly.</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Technique:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>Use tests developed for Performance Testing.</li>
      <li>To test limited resources, tests should be run on single machine, RAM
        and DASD on server should be reduced (or limited).</li>
      <li>For remaining stress tests, multiple clients should be used, either
        running the same tests or complementary tests to produce the worst case
        transaction volume / mix.</li></font>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Completion Criteria:</font></td>
    <td width="66%" valign="TOP"><font size="2">All planned tests are executed
    and specified system limits are reached / exceeded without the software or
    software failing (or conditions under which system failure occurs is outside
    of the specified conditions).</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Special Considerations:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>Stressing the network may require network tools to load the network
        with messages / packets.</li>
      <li>The DASD used for the system should temporarily be reduced to restrict
        the available space for the database to grow.</li>
      <li>Synchronization of the simultaneous clients accessing of the same
        records / data accounts.</li></font>
    </ul>
  </td>
</tr>
</table>
</center></div>

<blockquote>
  <font size="2">
  <p align="left"><strong>8. <a name="_Toc445538393"></a><font face="Arial" size="2"><i><a name="_Toc447185699">Volume
  Testing</a></i></font></strong></p>
  </font>
</blockquote>
<blockquote>
  <blockquote>
    <font size="2">
    <p>Volume Testing subjects the software to large amounts of data to
    determine if limits are reached that cause the software to fail. Volume
    testing also identifies the continuous maximum load or volume the system can
    handle for a given period. For example, if the software is processing a set
    of database records to generate a report, a Volume Test would use a large
    test database and check that the software behaved normally and produced the
    correct report.</p></font>
  </blockquote>
</blockquote>
<div align="center"><center>

<table cellspacing="0" border="0" cellpadding="7" width="90%">
  <tr>
    <td width="34%" valign="TOP"><font size="2">Test Objective:</font></td>
    <td width="66%" valign="TOP"><font size="2">Verify that the application /
    system successfully functions under the following high volume scenarios:
    </font><ul><font size="2">
      <li>maximum (actual or physically capable) number of clients connected (or
        simulated) all performing the same, worst case (performance) business
        function for an extended period.</li>
      <li>maximum database size has been reached (actual or scaled) and multiple
        queries / report transactions are executed simultaneously.</li></font>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Technique:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>Use tests developed for Performance Testing.</li>
      <li>Multiple clients should be used, either running the same tests or
        complementary tests to produce the worst case transaction volume / mix
        (see stress test above) for an extended period.</li>
      <li>Maximum database size is created (actual, scaled, or filled with
        representative data) and multiple clients used to run queries / report
        transactions simultaneously for extended periods.</li></font>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Completion Criteria:</font></td>
    <td width="66%" valign="TOP"><font size="2">All planned tests have been
    executed and specified system limits are reached / exceeded without the
    software or software failing.</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Special Considerations:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>What period of time would be considered an acceptable time for high
        volume conditions (as noted above)?</li></font>
    </ul>
    </td>
  </tr>
</table>
</center></div>

<blockquote>
  <font size="2">
  <p><strong>9. <a name="_Toc314978541"></a><a name="_Toc327254070"></a><a name="_Toc327255035"></a><a name="_Toc327255104"></a><a name="_Toc327255343"></a><a name="_Toc433104452"></a><a name="_Toc447185700"></a><font face="Arial" size="2"><i>Security
  and Access Control Testing</i></font></strong></p>
  </font>
</blockquote>
<blockquote>
  <blockquote>
    <font size="2">
    <p>Security and Access Control Testing focus on two key areas of security:</p>
    <p>- Application security, including access to the Data or Business
    Functions, and<br>
    - System Security, including logging into / remote access to the system.</p>
    <p>Application security ensures that, based upon the desired security, users
    are restricted to specific functions or are limited in the data that is
    available to them. For example, everyone may be permitted to enter data and
    create new accounts, but only managers can delete them. If there is security
    at the data level, testing ensures that user &quot;type&quot; one can see
    all customer information, including financial data, however, user two only
    sees the demographic data for the same client.</p>
    <p>System security ensures that only those users granted access to the
    system are capable of accessing the applications and only through the
    appropriate gateways.</p></font>
  </blockquote>
</blockquote>
<div align="center"><center>

<table cellspacing="0" border="0" cellpadding="7" width="90%">
  <tr>
    <td width="34%" valign="TOP"><font size="2">Test Objective:</font></td>
    <td width="66%" valign="TOP"><font size="2">Function / Data Security: Verify
    that user can access only those functions / data for which their user type
    is provided permissions.
    <p>System Security: Verify that only those users with access to the system
    and application(s) are permitted to access them.</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Technique:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>Function / Data Security: Identify and list each user type and the
        functions / data each type has permissions for.</li>
      <li>Create tests for each user type and verify permission by creating
        transactions specific to each user type.</li>
      <li>Modify user type and re-run tests for same users. In each case verify
        those additional functions / data are correctly available or denied.</li>
      <li>System Access (see special considerations below)</li></font>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Completion Criteria:</font></td>
    <td width="66%" valign="TOP"><font size="2">For each known user type the
    appropriate function / data are available and all transactions function as
    expected and run in prior Application Function tests</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Special Considerations:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>Access to the system must be reviewed / discussed with the appropriate
        network or systems administrator. This testing may not be required as it
        maybe a function of network or systems administration.</li></font>
    </ul>
    </td>
  </tr>
</table>
</center></div>

<blockquote>
  <p>
  <font size="2"><strong>10. <a name="_Toc417790800"></a><a name="_Toc433104453"></a><a name="_Toc447185701"></a></strong></font><font face="Arial" size="2"><i><strong>Failover
  / Recovery Testing</strong></i></font></p>
  
</blockquote>
<blockquote>
  <blockquote>
    <font size="2">
    <p><a name="_Toc327254071"></a><a name="_Toc327255036"></a><a name="_Toc327255105"></a><a name="_Toc327255344"></a><a name="_Toc433104454"></a>Failover
    / Recovery testing ensures that an application or entire system can
    successfully failover and recover from a variety of hardware, software, or
    network malfunctions with undue loss of data or data integrity.</p>
    <p>Failover testing ensures that, for those systems that must be kept
    running, when a failover condition occurs, the alternate or backup systems
    properly &quot;take over&quot; for the failed system without loss of data or
    transactions.</p>
    <p>Recovery testing is an antagonistic test process in which the application
    or system is exposed to extreme conditions (or simulated conditions) such as
    device I/O failures or invalid database pointers / keys. Recovery processes
    are invoked and the application / system is monitored and / or inspected to
    verify proper application / system / and data recovery has been achieved.</p></font>
  </blockquote>
</blockquote>
<div align="center"><center>

<table cellspacing="0" border="0" cellpadding="7" width="90%">
  <tr>
    <td width="34%" valign="TOP"><font size="2">Test Objective:</font></td>
    <td width="66%" valign="TOP"><font size="2">Verify that recovery processes
    (manual or automated) properly restore the database, applications, and
    system to a desired, known, state. The following types of conditions are to
    be included in the testing:
    </font><ul><font size="2">
      <li>Power interruption to the client</li>
      <li>Power interruption to the server</li>
      <li>Communication interruption via network server(s)</li>
      <li>Interruption, communication, or power loss to DASD and or DASD
        controller(s)</li>
      <li>Incomplete cycles (data filter processes interrupted, data
        synchronization processes interrupted).</li>
      <li>Invalid database pointer / keys</li>
      <li>Invalid / corrupted data element in database</li></font>
    </ul>
    </td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Technique:</font></td>
    <td width="66%" valign="TOP"><font size="2">Tests created for Application
    Function and Business Cycle testing should be used to create a series of
    transactions. Once the desired starting test point is reached, the following
    actions should be performed (or simulated) individually:
    <ul>
      <li>Power interruption to the client: power the PC down</li>
      <li>Power interruption to the server: simulate or initiate power down
        procedures for the server</li>
      <li>Interruption via network servers: simulate or initiate communication
        loss with the network (physically disconnect communication wires or
        power down network server(s) / routers).</li>
      <li>Interruption, communication, or power loss to DASD and or DASD
        controller(s): simulate or physically eliminate communication with one
        or more DASD controllers or devices.</li>
    </ul>
    <p>Once the above conditions / simulated conditions are achieved, additional
    transactions should executed and upon reaching this second test point state,
    recovery procedures should be invoked.</p>
    <p>Testing for incomplete cycles utilizes the same technique as described
    above except that the database processes themselves should be aborted or
    prematurely terminated.</p>
    <p>Testing for the following conditions requires that a known database state
    be achieved. Several database fields, pointers and keys should be corrupted
    manually and directly within the database (via database tools). Additional
    transactions should be executed using the tests from Application Function
    and Business Cycle Testing and full cycles executed.</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Completion Criteria:</font></td>
    <td width="66%" valign="TOP"><font size="2">In all cases above, the
    application, database, and system should, upon completion of recovery
    procedures, return to a known, desirable state. This state includes data
    corruption limited to the known corrupted fields, pointers / keys, and
    reports indicating the processes or transactions that were not completed due
    to interruptions.</font></td>
  </tr>
  <tr>
    <td width="34%" valign="TOP"><font size="2">Special Considerations:</font></td>
    <td width="66%" valign="TOP">
    <ul>
      <font size="2">
      <li>Recovery testing is highly intrusive. Procedures to disconnect cabling
        (simulating power or communication loss) may not be desirable or
        feasible. Alternative methods, such as diagnostic software tools may be
        required.</li>
      <li>Resources from the Systems (or Computer Operations), Database, and
        Networking groups are required.</li>
      <li>These tests should be run after hours or on an isolated machine(s).</li></font>
    </ul>
    </td>
  </tr>
</table>
</center></div>

<blockquote>
  <p><i><strong><font face="Arial" size="2">11. <a name="_Toc447185702">Configuration
  Testing</a></font></strong></i></p>
  
</blockquote>
<blockquote>
  <blockquote>
    <font size="2">