Objectives: Introduction Over View of System Analysis and Design
Download 0.94 Mb. View original pdf
|
- Navigate this page:
- 3. Performance Time Testing
| 2. Storage Testing Analysts specify a capacity for the system when it is designed and constructed. Capacities are measured in terms of the number of records that a disk will handle or a file can contain. These capacities are linked to disk space and the size of indices, record keys, and soon. But they too must be tested. If the documentation fora new system to be run on a microcomputer claims that a disk file can store up to 10,000 records, each 393 bytes long, the claim must be verified before implementation. Storage testing often requires entering data until the capacity is reached. Comparing the actual and claimed capacities will verify the accuracy of the documentation on the one hand and allow a judgement about actual capacity at the same time. Many, many systems are never tested in this way. Users find out too late that claims made during installation are not true there is not enough storage capacity for transactions and master file records. 3. Performance Time Testing When analysts are developing a design, their concerns are more on reports, inputs, files, and processing sequences than on performance time, although this changes with experience. During simple unit and integration testing, relatively small sets of data are used to find errors or cause failures. Therefore, users frequently find out how slow or fast the response time of the system is only after it has been installed and loaded up with data. That maybe too late. Systems are rarely too fast for users. Performance time testing is conducted prior to implementation to determine how long it takes to receive a response to an inquiry, make a backup copy of a file, or send a transmission and receive a response. It also includes test runs to time indexing or resorting of large files of the size the system will have during atypical run or to prepare a report. A system that runs well with only a handful of test transactions maybe unacceptably slow when full loaded. And the time to know about this is prior to implementation, when adjustments can be more easily made. Once files are fully loaded and the user is relying on the system for daily activities, it is difficult to pull it back and being large- scale changes. The user needs the system and the analyst will not want to risk the loss of live data. Download 0.94 Mb. Share with your friends:
|