Programmer's ROM - The Computer Language Library

home *** CD-ROM | disk | FTP | other *** search

/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / spell / spell2.tst < prev

Wrap

Text File | 1988-05-03 | 124.6 KB | 7,150 lines

:::::::::: speller_tst.dis :::::::::: TESTONE.DCT TESTTWO.DCT TESTTHREE.DCT USERON.DCT USERTW.DCT TESTFILEONE.TXT TESTFILETWO.TXT TEST1.TXT TEST3.TXT TEST4.TXT --USER4:[REA.NOSC]TEST.MEM speltest.doc -- -- The following outlines the output from the test matrix. -- TEST1_1.DCT TEST1_2.DCT TEST2_1.DCT --TESTS 2_2 THRU 2_5 (No output other than interactive) TEST2_6.DCT TEST2_7.DCT TEST2_8.DCT TEST2_9.DCT TEST2_10.DCT TEST3_1.DCT TEST4_1.DCT TEST4_2.DCT TEST4_3.DCT TEST4_4.DCT TEST4_5.DCT TEST4_6.DCT TEST4_7.DCT TEST4_8.DCT TEST4_9.DCT TEST4_10.DCT TEST4_11.DCT TEST4_12.DCT TEST4_13.DCT TEST5_1.DCT TEST5_2.DCT TEST5_3.DCT --TEST6 Interactive --TEST7 Interactive --TEST8 Interactive --TEST9 Interactive --TEST10 Interactive --TEST11 Interactive TEST12_1.TXT TEST13_1.TXT TEST14_1.DCT TEST14_2.DCT TEST15_1.DCT TEST15_2.DCT TEST15_3.DCT TEST16_1.DCT TEST17_1.DCT TEST17_2.DCT TEST18_1.DCT TEST18_2.DCT TEST18_3.DCT TEST19_1.DCT TEST20_1.DCT TEST20_2.DCT TEST21_1.DCT -- --Tests labeled as interactive must be verified by the output to the --terminal. No output test files have been included for these tests. -- --BATCH TESTS -- --For the most part these tests are the same as their interactive --counterparts. There may be some slight differences in the output --caused by a different input dictionary being used. -- TESTB1_1.DCT --TEST 1_2 NOT APPLICABLE --TEST SERIES 2 NOT APPLICABLE TESTB3_1.DCT TESTB3_2.DCT TESTB4_1.DCT TESTB4_2.DCT TESTB4_3.DCT TESTB4_4.DCT TESTB4_5.DCT TESTB4_6.DCT TESTB4_7.DCT TESTB4_8.DCT TESTB4_9.DCT TESTB4_10.DCT TESTB4_11.DCT TESTB4_12.DCT TESTB4_13.DCT TESTB5_1.DCT TESTB5_2.DCT TESTB5_3.DCT --TEST 6 INTERACTIVE --TEST 7 INTERACTIVE --TEST 8 INTERACTIVE --TEST 9 INTERACTIVE --TEST 10 INTERACTIVE --TEST 11 INTERACTIVE --TEST 12 INTERACTIVE --TEST 13 INTERACTIVE TESTB14_1.DCT TESTB14_2.DCT TESTB15_1.DCT TESTB15_2.DCT TESTB15_3.DCT TESTB16_1.DCT TESTB17_1.DCT TESTB17_2.DCT TESTB18_1.DCT TESTB18_2.DCT TESTB18_3.DCT TESTB19_1.DCT --TEST 20 NOT APPLICABLE TESTB21_1.DCT :::::::::: TESTONE.DCT :::::::::: Whether introduce type for arrays OMORROW very on abstract each If are of array complete its right we use :::::::::: TESTTWO.DCT :::::::::: name particular depends WORK much abstract situation we thinking :::::::::: TESTTHREE.DCT :::::::::: This will be third dictionary :::::::::: USERON.DCT :::::::::: this maybe job listing wordspell end ask why would upyors nome nots knots name nepo nape nate nats nazs nabs nass noss noes :::::::::: USERTW.DCT :::::::::: second dictionarylist mostanythinggoes PHILLIP Phillipe telephone telegraph telegraphy telephoney DAY coaxial serial ribbon parallel misspelled lexicon graphically sketch drafting longing logging afterwards maybeso :::::::::: TESTFILEONE.TXT :::::::::: Whether we introduce name particular type for arrays very on depends much abstract each If are of array situation thinking array complete its use. This will be a third dictionary. :::::::::: TESTFILETWO.TXT :::::::::: Whether we introduce name particular type for arrays very on depends much abstract each If are of array situation thinking array complete its use. This will be a third dictionary. DCS Ada and other acronyms added to the file AFW NSA :::::::::: TEST1.TXT :::::::::: Whether we introduce a type name for a particular arrays depends very much on the abstract view of each situation. If we are thinking of the array as a complete object in its own rigt then we should use a type name. If on the other hand we are thinking of the array as merely an indexable conglomer This line is for DCS, ACSL ATB and other Ada words. ate not related as a whole to other arrays then it should probably be of an anonymous type. Arays lik OMORROW n WORK_DAY f te las setion re ood exmples of arrays which are of the anonymous rigt category. To be forced to introduct a tpe ame fr sch arays woud intoduce unecessary clter nd a possbly false sense of abstraction. On the other hand if we are manipulating lots of arrays of reals of length 6 hen thre is a comon unerlying abstrac tye ad so it shold be naed. The model for array types intorduced so far is still not satis factory. It does not allow us to represent an abstract view that embraces th ommonality between arrays which has have different bounds but are otherwise of the same type. In particular it would not allow the writing of subprograms rigt which could take an array of arbitrary bounds as an actual parameter. This is generally recognised as a major difficulty with Pascal. So the concept of an unconstrained array typ e is introduced in which the constraints for the indexes are not given. Consider :::::::::: TEST3.TXT :::::::::: An important point to notice is that an array type or subtype must give all the bounds or none at all. It would be perfectly legal to introduct an alternative name for matrix by creating it with no bounds. We could not have a type or subtype that just gave the bounds for one dimension but not the other. :::::::::: TEST4.TXT :::::::::: An impoetant point to notce is that an array type or suctype must give all the boonds or none at all. It would be perfectly legal to introduct an elternative name for matrix by creating it with no bounfs. We could not have a type or subtype that just gave the boueds for one diminsion but not the other. :::::::::: speltest.doc :::::::::: ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| Program Design Specification for an Interactive Spelling Corrector in Ada Prepared for: ||||||||||||||||||||||||| ||||||||||||||||||||||||| Advanced Computer Systems Lab |||||||| |||| |||||||| Texas Instruments |||||||| ||| |||||||| |||||||| | || |||||||| |||||||| || | |||||||| |||||||| |||| |||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| |||||||| |||||||| |||||||| ||||| |||||||| |||||||| ||||| |||||||| |||||||| ||||| |||||||| |||||||| |||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| |||||||| |||||||| |||||||| ||||||||||||||| |||||||| |||||||| ||||||||||||||| |||||||| |||||||| |||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| Equipment Group - ACSL |||||||| |||||||| P.O. Box 801, M.S. 8007 |||||||| ||||||||||||||| McKinney, Texas 75069 |||||||| ||||||||||||||| 14 March 1985 |||||||| ||||||||||||||| |||||||| |||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| TEXAS INSTRUMENTS INCORPORATED ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| ||||||||||||||||||||||||| CHAPTER 1 INTRODUCTION 1.1 PURPOSE This Computer Program Test Procedures document describes the acceptance test procedures for the Ada Spelling Corrector computer program. This research and development is being done for the Naval Ocean Systems Center (NOSC) under contract N66001-84-R0030. Within this document, the Ada Spelling Corrector is referred to as the Spelling Corrector. This acceptance test procedures document has been prepared in accordance with the Navy Data Item Description for a Computer Program Test Procedures document [NAV78]. 1.2 SCOPE This document describes the procedures for testing the Spelling Corrector after it is developed. The test procedures defined in this document will show compliance with the requirements of the Proposal to Design and Implement a Spelling Corrector in Ada [TI84]. 1.3 SUMMARY The objective of this document is to explain the test procedures that are necessary for acceptance testing of the Spelling Corrector. Acceptance testing will demonstrate that the requirements of the Proposal to Design and Implement a Spelling Corrector in Ada [TI84] have been satisfied. A list of the requirements that must be verified is provided in the Requirements Cross Reference Matrix in Appendix B. CHAPTER 2 APPLICABLE DOCUMENTS [BEI84] Beizer, Boris, Software System Testing and Quality Assurance, Van Nostrand Reinhold Co., New York, 1984. [BRU82] Bruce, Phillip and Sam M. Pederson, The Software Development Project, John Wiley and Sons, Inc., New York, 1982. [EVA84] Evans, Michael W., Productive Software Test Management, John Wiley and Sons, Inc., New York, 1984. [MYE79] Myers, Glenford J., The Art of Software Testing, John Wiley and Sons, Inc., New York, 1979. [NAV78] Navy, "Data Item Description, Computer Program Test Procedures", Navy DI-T2144, 29 November 1978. [TI84 ] Texas Instruments, "Proposal to Design and Implement an Ada Style Standards Checking Tool," Lewisville, Tx, January 1984. CHAPTER 3 TESTING REQUIREMENTS 3.1 GENERAL Acceptance testing of the Spelling Corrector must verify the requirements in the proposal [TI84] for the Spelling Corrector. A summary of the requirements from the proposal document is provided in Appendix B in the Requirements Cross Reference Matrix. Verifying that the requirements have been satisfied is a process involving three main steps. A description of each step is given below. 1. Develop Test Specifications - The first step is to develop test specifications based on the requirements. The test specifications outline the testing criteria that is necessary to show that the Spelling Corrector satisfies its original objectives. Appendix A contains the test specifications for the Spelling Corrector. 2. Create Test Data - The second step is to create test data to satisfy the test specifications. The test data is a library of Ada source programs, user and system dictionaries, and input files used to implement the testing criteria in the test specifications. The Ada source programs, user and system dictionaries, and input files are used as input to the Spelling Corrector. There are various expected output files generated by the Spelling Corrector, depending on the options used to run it and the mode (batch or interactive) in which it is being run. The output may be a new dictionary, the input file with any number of words marked as possible spelling errors, a simple list of the words from the input file which might be misspelled, the listing of a dictionary which was already in existence at the start of the program's run, or a set of user prompts. 3. Analyze Results - The third step is to conduct testing and analyze the results. The Spelling Corrector is executed with the test data, input files, and dictionaries that were created in step 2. The results are analyzed and the appropriate matrices are updated. TESTING REQUIREMENTS Page 3-2 Some of the ideas from Myers [MYE79] were used to facilitate the development of the test specifications. Specifically, the facility test category defined by Myers was used to help define the test specifications. Myers' definition for facility testing is provided below. Facility Facility testing is the determination of whether each facility or function is actually implemented. The procedure is to scan the requirements sentence by sentence and when the sentence specifies a "what" (e.g., "syntax should be consistent ...", "user should be able to specify a range of locations ..."), determine if the program satisfies the "what". 3.2 SPELLING CORRECTOR ACCEPTANCE/PREOPERATING PROCEDURES The following paragraphs explain the necessary preparations and procedures for acceptance testing of the Spelling Corrector. 3.3 EQUIPMENT PREPARATION In order to complete acceptance testing, the Spelling Corrector must be available on a Data General MV 10,000 running under AOS/VS. 3.4 DIGITAL PROCESSOR PREPARATION In order to complete acceptance testing, the ROLM/Data General Ada Development Environment (ADE) must be available. 3.5 TESTING PROCEDURE The procedure for acceptance testing is to fulfill all the test specifications in Appendix A. This can be accomplished by completing the second and third steps from Section 3.1. As noted in step 2, input files for the Spelling Corrector (Ada source programs, system and user dictionaries, and input files) must be created to satisfy all of the test specifications in Appendix A. In addition, the expected output files for the Spelling Corrector (new dictionaries, word lists, altered input files, etc.) must be created based on the input files. Then, when the Spelling Corrector tool is ready to undergo acceptance testing, step 3 is started. Thus, the input files and dictionaries are executed with the tool. The output files that are generated are compared with the expected output files, which have already been established as correct. The file names for the test data library and the corresponding test specifications that are satisfied need to be documented in the Test Data Matrix in Appendix C. Finally, the results of testing are analyzed and the Test Specification Matrix in Appendix B is updated. TESTING REQUIREMENTS Page 3-3 NOTE One Ada source program and corresponding Style Parameter file may be used to satisfy a number of test specifications in Appendix A. In other words, it is not necessary to create a separate set of input files for each test specification in Appendix A. CHAPTER 4 TEST MANAGEMENT The Spelling Corrector development team is responsible for management of the testing described in this document. The Spelling Corrector development team responsibilities are to: o create test data according to the test specifications in Appendix A, and record the test data information in the Test Data Matrix in Appendix B, o conduct the test procedures described in the Testing Requirements section, o maintain the Test Specifications Matrix in Appendix B, and o write an internal test report. CHAPTER 5 PERSONNEL REQUIREMENTS The software development team for the Spelling Corrector is the only personnel required to complete the acceptance testing described in this document. CHAPTER 6 HARDWARE REQUIREMENTS The acceptance testing described in this document shall be conducted on a Data General MV 10,000 running under AOS/VS. CHAPTER 7 SOFTWARE REQUIREMENTS The acceptance testing described in this document requires the ROLM/Data General Ada Development Environment (ADE). CHAPTER 8 TESTING SCHEDULE The acceptance testing described in this document will take 1-2 weeks to complete, at most. CHAPTER 9 QUALITY ASSURANCE ACSL personnel will be responsible for the following Quality Assurance and Configuration Management tasks: o verifying that the test data satisfies the test specifications, o verifying that the documentation of each test is complete, and o maintaining configuration control of all software undergoing test. APPENDIX A TEST SPECIFICATIONS This appendix contains the test specifications for the Spelling Corrector. Each test specification includes a list of the requirements that are satsified, a description of the test, assumptions for the test, and a test synopsis. The test synopsis describes the input and expected results for the test. The test categories that are used for each test specification are also provided in the synopsis. A description of the various test categories is provided in the Testing Requirements section. A.1 TEST SERIES 1 A.1.1 Requirements Met By Test 1. The user will be able to enable an auxiliary dictionary search. (BOTH) Proposal Section: 2.3.1 A.1.2 Description Of Test Basically, this test checks for the capability to use a certain type of file for a given purpose. Words from several dictionaries should appear in the file being checked, because using words from only the auxiliary dictionary being used for this test would not guarentee that that particular auxiliary dictionary is enabled. See Requirement Number 16, which requires that if no dictionary is enabled, then all words in the input file will be marked as possible errors. A.1.3 Assumptions The MASTER and ACRONYM dictionaries are disabled. A.1.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. TEST SPECIFICATIONS Page A-2 INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 With auxiliary Only words not in Facility dictionary disabled, auxiliary give the order to dictionary should enable it; search an be marked as mis- input file with mis- spelled spelled words from that auxiliary dictionary and other dictionaries 2 With auxiliary Same as above, Facility dictionary search no error message enabled, give the should result from command to enable it; enabling a perform the same dictionary which is search as in Part 1 already enabled TEST SPECIFICATIONS Page A-3 A.2 TEST SERIES 2 A.2.1 Requirements Met By Test 2. The program will be able to merge two or more user-specified dictionaries, provided that those dictionaries exist before the attempted merge operation. See also Requirement 20, which is related. (INTERACTIVE) Proposal Section: 2.3.1 A.2.2 Description Of Test This series of tests consists of supplying the program with the types of dictionaries indicated under the INPUT DATA column, below, giving the command to merge them, and checking for the results described in EXPECTED OUTPUT, also below. A "valid" dictionary is one which exists at the time that the command is given; likewise, an "invalid" dictionary is one which does not exist at the time that the command is given. A.2.3 Assumptions A.2.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Two valid dictionaries Dictionaries Facility should be merged, and no error messages should result 2 One valid and Merger should not Facility one invalid be attempted, and dictionary, an error message in that order should be given for the invalid dictionary name 3 One invalid and Same result as Facility one valid Test # 2, just dictionary, above in that order TEST SPECIFICATIONS Page A-4 4 One invalid Merger should not Facility dictionary or one be attempted, and valid dictionary error messages should be given for insufficient number of arguments and/or invalid dictionary name 5 No arguments at all Merger should not Facility be attempted 6 Three dictionaries, Merger should be Facility two valid and one done on the two invalid, in that order valid dictionaries, and an error message should be output for the invalid dictionary 7 Three dictionaries, Same as # 6, Facility one valid, one above invalid, and one valid, in that order 8 Three dictionaries, Same as # 6, Facility one invalid, two above valid, in that order 9 Three or more valid Merger should be done Facility dictionaries. on all three diction- aries. 10 Two valid dictionaries One valid dictionary Facility defined as the union of the two input dic- tionaries. TEST SPECIFICATIONS Page A-5 A.3 TEST SERIES 3 A.3.1 Requirements Met By Test 3. The program will be able to list the contents of a user-specified dictionary, provided that that dictionary exists when the program is given the command to perform that listing. (BOTH) Proposal Section: 2.3.1 A.3.2 Description Of Test This test consists of giving the LIST DICTIONARY command, with the data as shown in the INPUT DATA section, below. A "valid" dictionary is one which exists at the time that the command is given; likewise, an "invalid" dictionary is one which does not exist at the time that the command is given. A.3.3 Assumptions A.3.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 A valid dictionary The dictionary's Facility contents should be listed 2 An invalid dictionary No listing should Facility be attempted, and an error message should be given for an invalid argument TEST SPECIFICATIONS Page A-6 A.4 TEST SERIES 4 A.4.1 Requirements Met By Test 4. The program will be able to search either the MASTER and ACRONYM dictionaries, both dictionaries, or neither dictionary. (BOTH) Proposal Section: 2.3.1 A.4.2 Description Of Test This testing series involves commanding the search of various combinations of enabled dictionaries, as specified in the INPUT DATA section below. The input file should contain some words from both the MASTER and ACRONYM dictionaries, as well as some words that are not in those dictionaries. A.4.3 Assumptions A.4.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Enable search on Only words from Facility MASTER and ACRONYM, the MASTER then command dictionary should disablement of MASTER be flagged, and there and perform search should be no undesirable side effects 2 Enable MASTER and Only words from Facility ACRONYM, then disable the ACRONYM ACRONYM and perform dictionary search should be flagged, and there should be no undesirable side effects 3 Enable search on All words should be Facility MASTER and ACRONYM, flagged, since no then disable both dictionary was enabled, and perform search and there should be no undesirable side effects 4 Disable MASTER and Same as above, plus no Facility ACRONYM dictionary undesirable side searches, then command effects arising from TEST SPECIFICATIONS Page A-7 disablement of MASTER the redundant command dictionary and perform search 5 Disable MASTER and Same as # 4, above Facility ACRONYM dictionary searches, then command disablement of ACRONYM dictionary and perform search 6 Disable MASTER and Same as # 4, above Facility ACRONYM dictionary searches, then command disablement of ACRONYM and MASTER dictionaries and perform search 7 Enable MASTER search, Same as # 3, above Facility then command disablement of MASTER search 8 Enable MASTER search, Only words not from the Facility then command MASTER dictionary disablement of ACRONYM should be flagged, and search and perform there should be no search undesirable side effects 9 Enable MASTER search, All words should be Facility then disable ACRONYM flagged, and there and MASTER searches should be no and perform search undesirable side effects 10 Enable ACRONYM search, Only ACRONYM words Facility attempt MASTER should not be flagged disablement, and perform search 11 Enable ACRONYM search, All words should be Facility disable ACRONYM flagged search, perform search 12 Enable ACRONYM search, All words should be Facility disable ACRONYM and flagged MASTER searches, perform search 13 Enable MASTER and Words from the MASTER Facility ACRONYM searches, and ACRONYM perform search dictionaries should not be flagged TEST SPECIFICATIONS Page A-8 A.5 TEST SERIES 5 A.5.1 Requirements Met By Test 5. The program will check the words in the specifed input file against all of the enabled dictionaries in the order: MASTER dictionary first, then ACRONYM dictionary, then user dictionaries. (BOTH) Proposal Section: 2.3.2 A.5.2 Description Of Test Three runs of the test text will be needed. Each run will be performed with various combinations of the dictionaries enabled. An input file with misspelled words will be needed. The misspelled words will have to be unique to each of the three dictionaries, i.e., the correct spelling for each misspelled word should be found in only one of the test dictionaries. A.5.3 Assumptions A.5.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 File of misspelled List of misspelled Facility words described in words not contained in Description of Test the MASTER dictionary 2 File of misspelled List of misspelled Facility words as in # 1, words not contained in above. the MASTER or ACRONYM dictionaries 3 File of misspelled List of misspelled Facility words as in # 1 & 2, words not contained in all three dictionaries TEST SPECIFICATIONS Page A-9 A.6 TEST SERIES 6 A.6.1 Requirements Met By Test 6. The program will indicate each word suspected of being misspelled by displaying the line in which that word occurs, with a pointer to that word. In addition, the program will prompt the user for further actions. (INTERACTIVE) Proposal Section: 2.3.2 A.6.2 Description Of Test The test file should contain several lines on which misspellings occur. There should be at least three lines with all words misspelled, one line with the first word being the only misspelling on the entire line, one line with the last word being the only misspelling on the entire line, and two lines where a word which is not normally hyphenated if it is on only one line is split between two lines. A.6.3 Assumptions A.6.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Test input file as All words which are Facility described in misspelled should be Description of Test marked, including the section above. word split between two lines. Also, each time a line with a misspelled word is displayed, the prompt for further action should also be displayed. See also Requirement # 7, below TEST SPECIFICATIONS Page A-10 A.7 TEST SERIES 7 A.7.1 Requirements Met By Test 7. The program will offer the user three options accompanying the prompt for the further actions, and those options will be: 1. The user may request a list of possible correct spellings for the word suspected of being misspelled. 2. The user may leave the word unchanged. 3. The user may enter the correct spelling for the word suspected of being misspelled. (INTERACTIVE) Proposal Section 2.3.2 A.7.2 Description Of Test This requirement is basically an extension of the previous requirement, and no separate testing runs are needed. Only the additional checking described in the Test Synopsis section below should be required. Note that this particular requirement specifies only that the options described will be displayed, not necessarily that they will work. The proper functioning of the three options is covered by the requirements immediately following this one. A.7.3 Assumptions A.7.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Same as for An indication of the Facility Requirement Number 6 offering of the three options specified in the requirement TEST SPECIFICATIONS Page A-11 A.8 TEST SERIES 8 A.8.1 Requirements Met By Test 8. When the user requests a list of possible correct spellings, as described in option # 1 of Requirement # 7 above, the program will perform an incremental search of all enabled dictionaries. (INTERACTIVE) Proposal Section 2.3.2 A.8.2 Description Of Test Run the program with various combinations of enablement and disablement of the system and two made-up private dictionaries. The input file should have words which do not appear in any of the dictionaries involved in the test series, as well as words which do appear in those dictionaries. A.8.3 Assumptions A.8.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Enable MASTER only and Only the words from Facility run the MASTER dictionary should be listed 2 Enable ACRONYM only Only the words from Facility and run the ACRONYM dictionary should be listed 3 Enable MASTER and Only the words from Facility ACRONYM and run the MASTER and ACRONYM dictionaries should be listed 4 Enable MASTER, Only the words from Facility ACRONYM, a private the MASTER, ACRONYM, dictionary, and run and enabled private dictionary should be listed 5 Enable all Only the words from Facility dictionaries and run the MASTER, ACRONYM, and enabled private dictionaries should be listed TEST SPECIFICATIONS Page A-12 6 Enable MASTER and one Only the words from Facility private dictionary and the MASTER and enabled run private dictionaries should be listed 7 Enable MASTER and both Only the words from Facility private dictionaries the MASTER and enabled and run private dictionaries should be listed 8 Enable ACRONYM and one Only the words from Facility private dictionary and the ACRONYM and run enabled private dictionaries should be listed 9 Enable ACRONYM and Only the words from Facility both private the ACRONYM and dictionaries and run enabled private dictionaries should be listed. TEST SPECIFICATIONS Page A-13 A.9 TEST SERIES 9 A.9.1 Requirements Met By Test 9. When the user requests a list of possible correct spellings the program will locate all dictionary entries containing the prefix as an initial substring. (INTERACTIVE) Proposal Section 2.3.2 A.9.2 Description Of Test Run the same test series as for Requirement Number 8, but for this series, provide prefix strings for the misspellings. A.9.3 Assumptions A.9.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Enable MASTER only and Only the words from Facility run the MASTER dictionary should be listed 2 Enable ACRONYM only Only the words from Facility and run the ACRONYM dictionary should be listed 3 Enable MASTER and Only the words from Facility ACRONYM and run the MASTER and ACRONYM dictionaries should be listed 4 Enable MASTER, Only the words from Facility ACRONYM, a private the MASTER, ACRONYM, dictionary, and run and enabled private dictionary should be listed 5 Enable all Only the words from Facility dictionaries and run the MASTER, ACRONYM, and enabled private dictionaries should be listed 6 Enable MASTER and one Only the words from Facility private dictionary and the MASTER and enabled run private dictionaries TEST SPECIFICATIONS Page A-14 should be listed 7 Enable MASTER and both Only the words from Facility private dictionaries the MASTER and enabled and run private dictionaries should be listed 8 Enable ACRONYM and one Only the words from Facility private dictionary and the ACRONYM and run enabled private dictionaries should be listed 9 Enable ACRONYM and Only the words from Facility both private the ACRONYM and dictionaries and run enabled private dictionaries should be listed. TEST SPECIFICATIONS Page A-15 A.10 TEST SERIES 10 A.10.1 Requirements Met By Test 10. When the requested search of the dictionaries (see Specification 9) is completed, the program will display an alphabetized, sequentiallly-numbered list of all discovered possible correct spellings. (INTERACTIVE) Proposal Section 2.3.2 A.10.2 Description Of Test This test is, in effect a continuation of the testing for Requirement Number 9, immediately preceding. Merely inspect the output lists to ascertain that they are alphabetized and sequentially numbered. This testing is "Facility" testing. A.10.3 Assumptions A.10.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== See the Test Synopsis for Requirement Number 9, inspecting the output list for alphabetic order and sequential numbering TEST SPECIFICATIONS Page A-16 A.11 TEST SERIES 11 A.11.1 Requirements Met By Test 11. When the requested search of the dictionaries is completed, in addition to displaying the list specified immediately above, the program will allow the user to choose one of the following options: 1. The user may select one of the alternatives from the displayed list 2. Directly enter the correct spelling of the word. 3. The user may leave the word unchanged and continue. (INTERACTIVE) Proposal Section 2.3.2 A.11.2 Description Of Test This test is, in effect a continuation of the testing for Requirement Numbers 9 and 10, immediately preceding. Merely inspect the screen after the completion of each search to make certain that the three options specified are offered. This testing is "Facility" testing. Note that this particular requirement specifies only that the options described will be displayed, not necessarily that they will work. The proper functioning of the three options is covered by the requirements immediately following this one. A.11.3 Assumptions A.11.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== See the Test Synopsis for Requirement Number 9, inspecting the screen for a display of the three options TEST SPECIFICATIONS Page A-17 A.12 TEST SERIES 12 A.12.1 Requirements Met By Test 12. If the user chooses to leave the word suspected of being misspelled unchanged, as in option # 3 of Requirement 11, the program will not change the current spelling of the word under consideration. (INTERACTIVE) Proposal Section 2.3.2 A.12.2 Description Of Test This test series will require two identical files, one an input file and the other a comparison file. The input file is the one which should be run, and the comparison file is used to detect any changes which might have occurred in the input file. These files should have the same misspelled word as the first and last word on the first line of the file, the first and last word on a line somewhere in the middle of the file, and the first and last word on the last line of the file. When the option to change each misspelling is offered, the tester should indicate that the word should be left unchanged. There should be no change in the input file after that choice. A comparison utility, such as the UNIX operating system's "diff" would expedite this testing, by comparing the input file after each choice with the comparison file. A.12.3 Assumptions A.12.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 An input file, as No change in the input Facility described in the file should occur Description of Test section. The program should be run on that entire file, and the no-change option selected for each misspelling TEST SPECIFICATIONS Page A-18 A.13 TEST SERIES 13 A.13.1 Requirements Met By Test 13. If the user chooses to change the spelling of the word suspected of being misspelled, as in option # 1 or option # 2 of Requirement 11, each occurrence of the same suspected misspelling will be changed to the choice made by the user. (INTERACTIVE) Proposal Section 2.3.2 A.13.2 Description Of Test The program should be run on a file with the same word misspelled several different ways, e.g., "diferent", "differant", "defferent", etc. Each misspelling should occur several times in the input file, preferably in different positions on a line of text. The input file should be examined after every change is made, to insure that only the exact same misspellings as the misspelling which was displayed are the ones which are changed. Using the preceding example, if the misspelling being changed is "diferent", then only the occurrences of "diferent" being examined and those elsewhere in the file should be changed. The "differant", "defferent", and other variant misspellings should be left unchanged. A.13.3 Assumptions A.13.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 File as described in Only the exact same Facility Description of Test misspelling as the section, above misspelling under consideration should be changed. See the Description of Test section above for an example. TEST SPECIFICATIONS Page A-19 A.14 TEST SERIES 14 A.14.1 Requirements Met By Test 14. If the MASTER and ACRONYM dictionaries are both disabled, only the user's enabled private dictionaries will be searched. (BOTH) Proposal Section 2.3.3.1 A.14.2 Description Of Test There should be two private dictionaries available. The input file should contain misspelled words from the MASTER and ACRONYM dictionaries, as well as from two private dictionaries, After the program is run, the processed input file should be examined to see which words are marked as errors. A.14.3 Assumptions A.14.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Disable MASTER and Only words from the Facility ACRONYM dictionaries, enabled private if they are not dictionaries should not already disabled. be marked as errors Enable more than one private dictionary and run the program 2 Disable one of the Only words from the Facility private dictionaries private dictionary and run the program which is still enabled should not be marked as errors TEST SPECIFICATIONS Page A-20 A.15 TEST SERIES 15 A.15.1 Requirements Met By Test 15. If the MASTER dictionary is disabled and the ACRONYM dictionary is enabled, the ACRONYM dictionary and any enabled private dictionaries will be searched. (BOTH) Proposal Section 2.3.3.2 A.15.2 Description Of Test The ACRONYM dictionary should be enabled and the MASTER dictionary disabled. The same file as that used to test Requirement Number 14 may be used. The processed input file should be examined to see which words were marked as errors. A.15.3 Assumptions A.15.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Make sure that the The marked words Facility ACRONYM dictionary is should be words not enabled and the MASTER from the ACRONYM and dictionary disabled, enabled private and enable two private dictionaries dictionaries. Run the program 2 Disable one of the The marked words Facility private dictionaries should not be words and run the program from the ACRONYM dictionary and the private dictionary which is still enabled 3 Disable the private The marked words Facility dictionary which is should not be words still enabled and run from the ACRONYM dictionary. TEST SPECIFICATIONS Page A-21 A.16 TEST SERIES 16 A.16.1 Requirements Met By Test 16. If no dictionary is enabled, the program will label all words as suspected of being misspelled. (BOTH) Proposal Section 2.3.3.2 A.16.2 Description Of Test Disable all dictionaries and run the program. A.16.3 Assumptions A.16.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Disable all All words should be Facility dictionaries, both marked as possible system and private misspellings and run the program TEST SPECIFICATIONS Page A-22 A.17 TEST SERIES 17 A.17.1 Requirements Met By Test 17. If the user disables all dictionaries, specifies the output file option, and runs the program on an error-free file, the program will produce a file that can be used as a private dictionary. (BOTH) Proposal Section 2.3.3.2 A.17.2 Description Of Test Same basic procedure as Requirement Number 16, immediately above, with the difference that the output file option is specified. The object to examine will be a newly-created file which should subsequently be usable as a private dictionary. The first input file should contain no misspellings. The second input file should contain the same words as the first input file, but the words should be misspelled. This test has two parts, and the second part depends on the first part. In the first one, the ability of the program to create a file from the no-existing-dictionaries-enabled output-file-option-specified condition is checked. The second part checks to see if the file thus created is usable as a private dictionary. A.17.3 Assumptions A.17.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Ensure that all A new file containing Facility dictionaries are all of the input disabled, and run the file's words should program with the be present after the "output file" option. program has run 2 Enable the file which The errors in the Facility resulted from the input file should be above run as a private flagged dictionary. Run the program again with the input file containing the errors TEST SPECIFICATIONS Page A-23 A.18 TEST SERIES 18 A.18.1 Requirements Met By Test 18. If the MASTER dictionary is enabled and the ACRONYM dictionary is disabled, the MASTER dictionary and any enabled private dictionaries will be searched. (BOTH) Proposal Section 2.3.3.3 A.18.2 Description Of Test Enable the MASTER dictionary and disable the ACRONYM dictionary. Run with zero, one, and two or more private dictionaries enabled. A.18.3 Assumptions A.18.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Enable the MASTER Only words not Facility dictionary and disable contained in the the ACRONYM dictionary MASTER dictionary and all private should be marked as dictionaries and run possible misspellings. 2 Enable one of the Only words not from Facility private dictionaries the MASTER and en- and run again abled private dictionaries should be marked as possible misspellings 3 Enable another Only words not from Facility private dictionary the MASTER and en- and run again abled private dictionaries should be marked as possible misspellings TEST SPECIFICATIONS Page A-24 A.19 TEST SERIES 19 A.19.1 Requirements Met By Test 19. If the user specifies the LIST DICTIONARY option, the program will compact the contents of the dictionary given by the user as the input file and write the result to another file. (BOTH) Proposal Section 2.3.3.4 A.19.2 Description Of Test Give the program a user dictionary, a filename to write the results to, specify the LIST DICTIONARY option, and run the program. A.19.3 Assumptions A.19.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Run the program on a A new file which is Facility user dictionary, a compacted version of specifying the list the input file and dictionary option and with the given output giving the name of the filename desired output file TEST SPECIFICATIONS Page A-25 A.20 TEST SERIES 20 A.20.1 Requirements Met By Test 20. If the user specifies the MERGE DICTIONARY option, the program will merge the input files together and, thereafter, use the resultant file as an auxiliary dictionary. (INTERACTIVE) Proposal Section 2.3.3.5 A.20.2 Description Of Test Run the program with two user dictionaries, specifying the "merge dictionary" option, and supplying an output filename for the program to write to. The output file should be usable as a private dictionary. The test will necessarily have two parts. In the first part, the object is to see if the program will merge two dictionaries, and in the second, to see if the resulting output file is usable as a user dictionary. The second part of the test will require an input textfile to be checked, and that file should contain words from both of the original user dictionaries. A.20.3 Assumptions A.20.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Run the program with A file with the Facility the "merge dictionary" specified output option on two user filename dictionaries, and specify an output filename 2 Run the program to A list of words from Facility check the spelling the input file which on an input textfile might be misspelled TEST SPECIFICATIONS Page A-26 A.21 TEST SERIES 21 A.21.1 Requirements Met By Test 21. The program will generate an output file containing all of the words in the input file which are suspected of being misspelled. (BOTH) Proposal Section 2.3.3.7 A.21.2 Description Of Test Run the program on a file containing misspelled words, instructing it to generate the described list. For this test, supply a filename for the list to be written to. A.21.3 Assumptions A.21.4 Test Synopsis The following table summarizes the test data, expected outputs, and test categories addressed by the associated test data. INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES ===== ========== =============== ========== 1 Run the program on a A file with the name Facility file containing supplied by the misspelled words, tester which contains and give a filename the misspelled words for the list which the in the input file program should create APPENDIX B CROSS REFERENCE MATRIX This appendix contains three cross reference matrices that show the relationship between the test specifications in Appendix A, the requirements from the proposal for the Spelling Corrector [TI84], and the test data files developed to satisfy the test specifications. The Test Specifications Matrix lists the test specifications and shows which requirements are satisified with each test specification. In addition, the Test Specifications Matrix contains two columns for check off and comments to fill in as the test specifications are fulfilled. The second matrix, the Requirements Cross Reference Matrix, provides a quick reference of how each requirement is satisfied. The acceptance requirements are listed along with the test specifications that satisfy each requirement. In addition, the specific section from the Proposal to Design and Implement an Ada Spelling Standards Checking Too [TI84] where the requirement is described is listed. The third matrix, the Test Data Matrix, shows the relationship between the test data and the test specifications in Appendix A. The file names included in the test data library that are developed by the Spelling Corrector development team will be listed along with the test specifications that they satisfy. CROSS REFERENCE MATRIX Page B-2 B.1 TEST SPECIFICATIONS MATRIX ------------------------------------------------------------------ | TEST SPEC | REQUIREMENTS | CHECK | COMMENTS | |============|================|=======|==========================| | A.1 | 1 |3-17-85| Testfileone.txt | | | | | Testone.dct, Testtwo.dct | | | | | Testthree.dct | |------------|----------------|-------|--------------------------| | A.2 | 2 |3-17-85| Testone.dct, Testtwo.dct | | | | | Useron.dct, Usertw.dct | |------------|----------------|-------|--------------------------| | A.3 | 3 |3-17-85| Testone.dct, Testtwo.dct | |------------|----------------|-------|--------------------------| | A.4 | 4 |3-17-85| Testone.dct, Testtwo.dct | | | | | Testfileone.txt | | | | | Testfiletwo.txt | |------------|----------------|-------|--------------------------| | A.5 | 5 |3-17-85| Testone.dct, Testtwo.dct | | | | | Testthree.dct | |------------|----------------|-------|--------------------------| | A.6 | 6 |3-17-85| Test1.txt | |------------|----------------|-------|--------------------------| | A.7 | 7 |3-18-85| Speller_master.dct | |------------|----------------|-------|--------------------------| | A.8 | 8 |3-18-85| Test1.txt, Useron.dct | | | | | Usertw.dct | | | | | Speller_master.dct | | | | | Speller_acronym.dct | | | | | | |------------|----------------|-------|--------------------------| | A.9 | 9 |3-18-85| Same as 8 | |------------|----------------|-------|--------------------------| | A.10 | 10 |3-18-85| Same as 8 | |------------|----------------|-------|--------------------------| | A.11 | 11 |3-18-85| Same as 8 | |------------|----------------|-------|--------------------------| | A.12 | 12 |3-18-85| Test1.txt | | | | | Speller_acronym.dct | | | | | Speller_master.dct | |------------|----------------|-------|--------------------------| | A.13 | 13 |3-18-85| Test1.txt | |------------|----------------|-------|--------------------------| | A.14 | 14 |3-18-85| Testone.dct, Testtwo.dct | | | | | Testthree.dct | | | | | Speller_master.dct | | | | | Speller_acronym.dct | |------------|----------------|-------|--------------------------| | A.15 | 15 |3-18-85| Same as 14 with | | | | | Testfiletwo.txt | |------------|----------------|-------|--------------------------| CROSS REFERENCE MATRIX Page B-3 | A.16 | 16 |3-18-85| Testfileone.txt | |------------|----------------|-------|--------------------------| | A.17 | 17 |3-18-85| Test3.txt, Test4.txt | |------------|----------------|-------|--------------------------| | A.18 | 18 |3-18-85| Speller_master.dct | | | | | Speller_acronym.dct | | | | | Useron.dct, Usertw.dct | | | | | Test1.txt, Testone.dct | | | | | Testtwo.dct | |------------|----------------|-------|--------------------------| | A.19 | 19 |3-18-85| Usertw.dct | |------------|----------------|-------|--------------------------| | A.20 | 20 |3-18-85| Useron.dct, Usertw.dct | |------------|----------------|-------|--------------------------| | A.21 | 21 |3-18-85| Test1.txt | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |----------------------------------------------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | |------------|----------------|-------|--------------------------| | | | | | CROSS REFERENCE MATRIX Page B-4 |----------------------------------------------------------------| CROSS REFERENCE MATRIX Page B-5 B.2 REQUIREMENTS CROSS REFERENCE MATRIX The acceptance test requirements that were used to develop the test specifications in Appendix A are listed below. Specific sections from the Proposal to Design and Implement an Ada Style Standards Checking Tool [TI84] are referenced with each requirement. The proposal sections represent the section numbers in the proposal document where the requirement is described. REQUIREMENT PROPOSAL SECTION =========== ================ 1. The user will be able to enable an 2.3.1 auxiliary dictionary search. (BOTH) 2. The program will be able to merge 2.3.1 two or more user-specified dictionaries, provided that those dictionaries exist before the attempted merge operation. See also Requirements 21 and 22, which are related. (BOTH) 3. The program will be able to list 2.3.1 the contents of a user-specified dictionary, provided that that dictionary exists when the program is given the command to perform that listing. (BOTH) 4. The program will be able to search 2.3.1 either the MASTER and ACRONYM dictionaries, both dictionaries, or neither dictionary. (BOTH) 5. The program will check the words in 2.3.2 the specifed input file against all of the enabled dictionaries in the order: MASTER dictionary first, then ACRONYM dictionary, then user dictionaries. (BOTH) 6. The program will indicate each word 2.3.2 suspected of being misspelled by displaying the line in which that word occurs, with a pointer to that word. In addition, the program will prompt the user for further actions. (INTERACTIVE) 7. The program will offer the user 2.3.2 three options accompanying CROSS REFERENCE MATRIX Page B-6 the prompt for the further actions, and those options will be: 1. The user may request a list of possible correct spellings for the word suspected of being misspelled. 2. The user may leave the word unchanged. 3. The user may enter the correct spelling for the word suspected of being misspelled. (INTERACTIVE) 8. When the user requests a list of 2.3.2 possible correct spellings, as described in option # 1 of Requirement # 7 above, the program will perform an incremental search of all enabled dictionaries. (INTERACTIVE) 9. When the user requests a list of 2.3.2 possible correct spellings and/or provides a correct prefix of the word suspected of being misspelled, the program will locate all dictionary entries containing that prefix as an initial substring. (INTERACTIVE) 10. When the requested search of 2.3.2 the dictionaries (see Specification 9) is completed, the program will display an alphabetized, sequentiallly-numbered list of all discovered possible correct spellings. (INTERACTIVE) 11. When the requested search of the 2.3.2 dictionaries is completed, in addition to displaying the list specified immediately above, the program will re-prompt the user for the correct spelling of the word suspected of being misspelled and will present the user with three options: 1. The user may select one of the alternatives from the displayed list 2. The user may enter another spelling CROSS REFERENCE MATRIX Page B-7 which is not on the displayed list. 3. The user may leave the word unchanged. (INTERACTIVE) 12. If the user chooses to leave the 2.3.2 word suspected of being misspelled unchanged, as in option # 3 of Requirement 11, the program will not change the current spelling of the word under consideration. (INTERACTIVE) 13. If the user chooses to change the 2.3.2 spelling of the word suspected of being misspelled, as in option # 1 or option # 2 of Requirement 11, each occurrence of the same suspected misspelling will be changed to the choice made by the user. (INTERACTIVE) 14. If the MASTER and ACRONYM dictionaries 2.3.3.1 are both disabled, only the user's enabled private dictionaries will be searched. (BOTH) 15. If the MASTER dictionary is disabled 2.3.3.2 and the ACRONYM dictionary is enabled, the ACRONYM dictionary and any enabled private dictionaries will be searched. (BOTH) 16. If no dictionary is enabled, 2.3.3.2 the program will label all words as suspected of being misspelled. (BOTH) 17. If the user disables all dictionaries, 2.3.3.2 specifies the output file option, and runs the program on an error-free file, the program will produce a file that can be used as a private dictionary. (BOTH) 18. If the MASTER dictionary is enabled 2.3.3.3 and the ACRONYM dictionary is disabled, the MASTER dictionary and any enabled private dictionaries will be searched. (BOTH) 19. If the user specifies the 2.3.3.4 LIST DICTIONARY option, the program will compact the contents of the dictionary CROSS REFERENCE MATRIX Page B-8 given by the user as the input file and write the result to another file. (BOTH) 20. If the user specifies the 2.3.3.5 MERGE DICTIONARY option, the program will merge the input files together and, thereafter, use the resultant file as an auxiliary dictionary. See Requirements 2, above, and 22, below, related. (BOTH) 21. The program will generate an output file 2.3.3.7 containing all of the words in the input file which are suspected of being misspelled. (BOTH) CROSS REFERENCE MATRIX Page B-9 B.3 TEST DATA MATRIX The expression "TESTS" in the matrix below refers to the Test Series number which identifies the series of tests designed to check for compliance with the requirement with which the Test Series number is matched. REQUIREMENTS TESTS ============ ===== 1. The user will be able to enable an 1 auxiliary dictionary search. (BOTH) 2. The program will be able to merge 2 two or more user-specified dictionaries, provided that those dictionaries exist before the attempted merge operation. See also Requirements 21 and 22, which are related. (BOTH) 3. The program will be able to list 3 the contents of a user-specified dictionary, provided that that dictionary exists when the program is given the command to perform that listing. (BOTH) 4. The program will be able to search 4 either the MASTER and ACRONYM dictionaries, both dictionaries, or neither dictionary. (BOTH) 5. The program will check the words in 5 the specifed input file against all of the enabled dictionaries in the order: MASTER dictionary first, then ACRONYM dictionary, then user dictionaries. (BOTH) 6. The program will indicate each word 6 suspected of being misspelled by displaying the line in which that word occurs, with a pointer to that word. In addition, the program will prompt the user for further actions. (INTERACTIVE) 7. The program will offer the user 7 three options accompanying the prompt for the further actions, and those options will be: CROSS REFERENCE MATRIX Page B-10 1. The user may request a list of possible correct spellings for the word suspected of being misspelled. 2. The user may leave the word unchanged. 3. The user may enter the correct spelling for the word suspected of being misspelled. (INTERACTIVE) 8. When the user requests a list of 8 possible correct spellings, as described in option # 1 of Requirement # 7 above, the program will perform an incremental search of all enabled dictionaries. (INTERACTIVE) 9. When the user requests a list of 9 possible correct spellings and/or provides a correct prefix of the word suspected of being misspelled, the program will locate all dictionary entries containing that prefix as an initial substring. (INTERACTIVE) 10. When the requested search of 10 the dictionaries (see Specification 9) is completed, the program will display an alphabetized, sequentiallly-numbered list of all discovered possible correct spellings. (INTERACTIVE) 11. When the requested search of the 11 dictionaries is completed, in addition to displaying the list specified immediately above, the program will re-prompt the user for the correct spelling of the word suspected of being misspelled and will present the user with three options: 1. The user may select one of the alternatives from the displayed list 2. The user may enter another spelling which is not on the displayed list. CROSS REFERENCE MATRIX Page B-11 3. The user may leave the word unchanged. (INTERACTIVE) 12. If the user chooses to leave the 12 word suspected of being misspelled unchanged, as in option # 3 of Requirement 11, the program will not change the current spelling of the word under consideration. (INTERACTIVE) 13. If the user chooses to change the 13 spelling of the word suspected of being misspelled, as in option # 1 or option # 2 of Requirement 11, each occurrence of the same suspected misspelling will be changed to the choice made by the user. (INTERACTIVE) 14. If the MASTER and ACRONYM dictionaries 14 are both disabled, only the user's enabled private dictionaries will be searched. (BOTH) 15. If the MASTER dictionary is disabled 15 and the ACRONYM dictionary is enabled, the ACRONYM dictionary and any enabled private dictionaries will be searched. (BOTH) 16. If no dictionary is enabled, 16 the program will label all words as suspected of being misspelled. (BOTH) 17. If the user disables all dictionaries, 17 specifies the output file option, and runs the program on an error-free file, the program will produce a file that can be used as a private dictionary. (BOTH) 18. If the MASTER dictionary is enabled 18 and the ACRONYM dictionary is disabled, the MASTER dictionary and any enabled private dictionaries will be searched. (BOTH) 19. If the user specifies the 19 LIST DICTIONARY option, the program will compact the contents of the dictionary given by the user as the input file and write the result to another file. (BOTH) 20. If the user specifies the 20 MERGE DICTIONARY option, the program will CROSS REFERENCE MATRIX Page B-12 merge the input files together and, thereafter, use the resultant file as an auxiliary dictionary. See Requirements 2, above, and 22, below, related. (BOTH) 21. The program will generate an output file 21 containing all of the words in the input file which are suspected of being misspelled. (BOTH) :::::::::: TEST1_1.DCT :::::::::: This be depends dictionary. much name particular situation thinking third will :::::::::: TEST1_2.DCT :::::::::: This be depends dictionary. much name particular situation thinking third will :::::::::: TEST2_1.DCT :::::::::: If OMORROW WORK Whether abstract are array arrays complete depends each for introduce its much name of on particular right situation thinking type use very we :::::::::: TEST2_6.DCT :::::::::: If OMORROW WORK Whether abstract are array arrays complete depends each for introduce its much name of on particular right situation thinking type use very we :::::::::: TEST2_7.DCT :::::::::: If OMORROW WORK Whether abstract are array arrays complete depends each for introduce its much name of on particular right situation thinking type use very we :::::::::: TEST2_8.DCT :::::::::: If OMORROW WORK Whether abstract are array arrays complete depends each for introduce its much name of on particular right situation thinking type use very we :::::::::: TEST2_9.DCT :::::::::: If OMORROW WORK Whether abstract are array arrays ask complete depends each end for introduce its job knots listing maybe much nabs name nape nass nate nats nazs nepo noes nome noss nots of on particular right situation thinking this type upyors use very we why wordspell would :::::::::: TEST2_10.DCT :::::::::: If OMORROW WORK Whether abstract are array arrays complete depends each for introduce its much name of on particular right situation thinking type use very we :::::::::: TEST3_1.DCT :::::::::: Whether introduce type for arrays OMORROW very on abstract each If are of array complete its right we use :::::::::: TEST4_1.DCT :::::::::: If This Whether abstract are array arrays be complete depends dictionary. each for introduce its much name of on particular situation thinking third type use. very we will :::::::::: TEST4_2.DCT :::::::::: AFW Ada DCS NSA :::::::::: TEST4_3.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_4.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_5.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_6.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_7.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_8.DCT :::::::::: AFW Ada DCS NSA :::::::::: TEST4_9.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_10.DCT :::::::::: AFW If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_11.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_12.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST4_13.DCT :::::::::: AFW NSA :::::::::: TEST5_1.DCT :::::::::: AFW Ada DCS NSA :::::::::: TEST5_2.DCT :::::::::: AFW NSA :::::::::: TEST5_3.DCT :::::::::: AFW NSA :::::::::: TEST12_1.TXT :::::::::: Whether we introduce a type name for a particular arrays depends very much on the abstract view of each situation. If we are thinking of the array as a complete object in its own rigt then we should use a type name. If on the other hand we are thinking of the array as merely an indexable conglomer This line is for DCS, ACSL ATB and other Ada words. ate not related as a whole to other arrays then it should probably be of an anonymous type. Arays lik OMORROW n WORK_DAY f te las setion re ood exmples of arrays which are of the anonymous rigt category. To be forced to introduct a tpe ame fr sch arays woud intoduce unecessary clter nd a possbly false sense of abstraction. On the other hand if we are manipulating lots of arrays of reals of length 6 hen thre is a comon unerlying abstrac tye ad so it shold be naed. The model for array types intorduced so far is still not satis factory. It does not allow us to represent an abstract view that embraces th ommonality between arrays which has have different bounds but are otherwise of the same type. In particular it would not allow the writing of subprograms rigt which could take an array of arbitrary bounds as an actual parameter. This is generally recognised as a major difficulty with Pascal. So the concept of an unconstrained array type is introduced in which the constraints for the indexes are not given. Consider :::::::::: TEST13_1.TXT :::::::::: Whether we introduce a type name for a particular arrays depends very much on the abstract view of each situation. If we are thinking of the array as a complete object in its own right then we should use a type name. If on the other hand we are thinking of the array as merely an indexable conglomer This line is for DCS, ACSL ATB and other Ada words. ate not related as a whole to other arrays then it should probably be of an anonymous type. Arays lik OMORROW n WORK_DAY f te las setion re ood exmples of arrays which are of the anonymous right category. To be forced to introduct a tpe ame fr sch arays woud intoduce unecessary clter nd a possbly false sense of abstraction. On the other hand if we are manipulating lots of arrays of reals of length 6 hen thre is a comon unerlying abstrac tye ad so it shold be naed. The model for array types intorduced so far is still not satis factory. It does not allow us to represent an abstract view that embraces th ommonality between arrays which has have different bounds but are otherwise of the same type. In particular it would not allow the writing of subprograms right which could take an array of arbitrary bounds as an actual parameter. This is generally recognised as a major difficulty with Pascal. So the concept of an unconstrained array type is introduced in which the constraints for the indexes are not given. Consider :::::::::: TEST14_1.DCT :::::::::: ACSL ATB Ada Arays Consider DCS In It Pascal. So The To WORK abstrac abstraction. actual ad allow ame an and anonymous arays arbitrary as ate between bounds but category. clter comon concept conglomer constraints could depends different difficulty does embraces exmples f factory. false far forced fr generally given. hand has have hen in indexable indexes intoduce intorduced introduced introduct is it las length lik line lots major manipulating merely model much n naed. nd not object ommonality ood other otherwise own parameter. particular possbly probably re reals recognised related represent rigt same satis sch sense setion shold should situation. so still subprograms take te th that the then thinking thre to tpe tye types unconstrained unecessary unerlying us view which whole with words. woud writing :::::::::: TEST14_2.DCT :::::::::: ACSL ATB Ada Arays Consider DCS In It Pascal. So The To WORK abstrac abstraction. actual ad allow ame an and anonymous arays arbitrary as ate be between bounds but category. clter comon concept conglomer constraints could depends different difficulty does embraces exmples f factory. false far forced fr generally given. hand has have hen in indexable indexes intoduce intorduced introduced introduct is it las length lik line lots major manipulating merely model much n naed. nd not object ommonality ood other otherwise own parameter. particular possbly probably re reals recognised related represent rigt same satis sch sense setion shold should situation. so still subprograms take te th that the then thinking thre to tpe tye types unconstrained unecessary unerlying us view which whole with words. woud writing :::::::::: TEST15_1.DCT :::::::::: AFW NSA This acronyms added and be dictionary. file other the third to will :::::::::: TEST15_2.DCT :::::::::: AFW NSA This acronyms added and be depends dictionary. file much name other particular situation the thinking third to will :::::::::: TEST15_3.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TEST16_1.DCT :::::::::: If This Whether abstract are array arrays be complete depends dictionary. each for introduce its much name of on particular situation thinking third type use. very we will :::::::::: TEST17_1.DCT :::::::::: An It We all all. alternative an array at be bounds bounds. but by could creating dimension for gave give have important introduct is it just legal matrix must name no none not notice one or other. perfectly point subtype that the to type with would :::::::::: TEST17_2.DCT :::::::::: boonds boueds bounfs. diminsion elternative impoetant notce suctype :::::::::: TEST18_1.DCT :::::::::: ACSL ATB Ada Arays DAY DCS OMORROW WORK abstrac ame arays clter comon conglomer exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye unecessary unerlying woud :::::::::: TEST18_2.DCT :::::::::: ACSL ATB Ada Arays DAY DCS WORK abstrac ame arays clter comon conglomer exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye unecessary unerlying woud :::::::::: TEST18_3.DCT :::::::::: ACSL ATB Ada Arays DAY DCS abstrac ame arays clter comon conglomer exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye unecessary unerlying woud :::::::::: TEST19_1.DCT :::::::::: second dictionarylist mostanythinggoes PHILLIP Phillipe telephone telegraph telegraphy telephoney DAY coaxial serial ribbon parallel misspelled lexicon graphically sketch drafting longing logging afterwards maybeso :::::::::: TEST20_1.DCT :::::::::: DAY PHILLIP Phillipe afterwards ask coaxial dictionarylist drafting end graphically job knots lexicon listing logging longing maybe maybeso misspelled mostanythinggoes nabs name nape nass nate nats nazs nepo noes nome noss nots parallel ribbon second serial sketch telegraph telegraphy telephone telephoney this upyors why wordspell would :::::::::: TEST20_2.DCT :::::::::: If Whether abstract are array arrays be complete depends dictionary. each for introduce its much of on particular situation thinking third type use. very we will :::::::::: TEST21_1.DCT :::::::::: ACSL Arays abstrac ame arays clter comon conglomer exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye unecessary unerlying woud :::::::::: TESTB1_1.DCT :::::::::: This be depends dictionary. much name particular situation thinking third will :::::::::: TESTB3_1.DCT :::::::::: If OMORROW Whether abstract are array arrays complete each for introduce its of on right type use very we :::::::::: TESTB3_2.DCT :::::::::: Document <<INVALID.DCT>> is invalid. This operation is terminated. :::::::::: TESTB4_1.DCT :::::::::: If This Whether abstract are array arrays be complete depends dictionary. each for introduce its much name of on particular situation thinking third type use. very we will :::::::::: TESTB4_2.DCT :::::::::: AFW Ada DCS NSA :::::::::: TESTB4_3.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_4.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_5.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_6.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_7.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_8.DCT :::::::::: AFW Ada DCS NSA :::::::::: TESTB4_9.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_10.DCT :::::::::: AFW If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_11.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_12.DCT :::::::::: AFW Ada DCS If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB4_13.DCT :::::::::: AFW NSA :::::::::: TESTB5_1.DCT :::::::::: AFW Ada DCS NSA :::::::::: TESTB5_2.DCT :::::::::: AFW NSA :::::::::: TESTB5_3.DCT :::::::::: AFW NSA :::::::::: TESTB14_1.DCT :::::::::: ACSL ATB Ada Arays Consider DAY DCS In It Pascal. So The To WORK abstrac abstraction. actual ad allow ame an and anonymous arays arbitrary as ate between bounds but category. clter comon concept conglomer constraints could depends different difficulty does e embraces exmples f factory. false far forced fr generally given. hand has have hen in indexable indexes intoduce intorduced introduced introduct is it las length lik line lots major manipulating merely model much n naed. name name. nd not object ommonality ood other otherwise own parameter. particular possbly probably re reals recognised related represent rigt same satis sch sense setion shold should situation. so still subprograms take te th that the then thinking thre to tpe tye typ types unconstrained unecessary unerlying us view which whole with words. woud would writing :::::::::: TESTB14_2.DCT :::::::::: ACSL ATB Ada Arays Consider DAY DCS If In It OMORROW On Pascal. So The To WORK Whether abstrac abstract abstraction. actual ad allow ame an and anonymous arays arbitrary are array arrays as ate between bounds but category. clter comon complete concept conglomer constraints could depends different difficulty does e each embraces exmples f factory. false far for forced fr generally given. hand has have hen if in indexable indexes intoduce intorduced introduce introduced introduct is it its las length lik line lots major manipulating merely model much n naed. name name. nd not object of ommonality on ood other otherwise own parameter. particular possbly probably re reals recognised related represent rigt same satis sch sense setion shold should situation. so still subprograms take te th that the then thinking thre to tpe tye typ type type. types unconstrained unecessary unerlying us use very view we which whole with words. woud would writing :::::::::: TESTB15_1.DCT :::::::::: AFW NSA acronyms added and depends file much name other particular situation the thinking to :::::::::: TESTB15_2.DCT :::::::::: AFW NSA This acronyms added and be depends dictionary. file much name other particular situation the thinking third to will :::::::::: TESTB15_3.DCT :::::::::: AFW If NSA This Whether abstract acronyms added and are array arrays be complete depends dictionary. each file for introduce its much name of on other particular situation the thinking third to type use. very we will :::::::::: TESTB16_1.DCT :::::::::: If This Whether abstract are array arrays be complete depends dictionary. each for introduce its much name of on particular situation thinking third type use. very we will :::::::::: TESTB17_1.DCT :::::::::: An It We all all. alternative an array at be bounds bounds. but by could creating dimension for gave give have important introduct is it just legal matrix must name no none not notice one or other. perfectly point subtype that the to type with would :::::::::: TESTB17_2.DCT :::::::::: boonds boueds bounfs. diminsion elternative impoetant notce suctype :::::::::: TESTB18_1.DCT :::::::::: ACSL ATB Ada Arays DAY DCS OMORROW WORK abstrac ame arays clter comon conglomer e exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye typ unecessary unerlying woud :::::::::: TESTB18_2.DCT :::::::::: ACSL ATB Ada Arays DAY DCS WORK abstrac ame arays clter comon conglomer e exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye typ unecessary unerlying woud :::::::::: TESTB18_3.DCT :::::::::: ACSL ATB Ada Arays DAY DCS abstrac ame arays clter comon conglomer e exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye typ unecessary unerlying woud :::::::::: TESTB19_1.DCT :::::::::: DAY PHILLIP Phillipe afterwards coaxial dictionarylist drafting graphically lexicon logging longing maybeso misspelled mostanythinggoes parallel ribbon second serial sketch telegraph telegraphy telephone telephoney :::::::::: TESTB21_1.DCT :::::::::: ACSL Arays DAY OMORROW WORK abstrac ame arays clter comon conglomer e exmples f fr intoduce intorduced introduct las lik n naed. nd ommonality ood possbly recognised rigt satis sch setion shold te th thre tpe tye typ unecessary unerlying woud