《BS-7925-2-1998.pdf》由会员分享，可在线阅读，更多相关《BS-7925-2-1998.pdf（58页珍藏版）》请在三一文库上搜索。
1、| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BRITISH STANDARD BS 7925-2:1998 ICS 35.080
2、 NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW Software testing Part 2: Software component testing Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 GMT+00:00 2006, Uncontrolled Copy, (c) BSI This British Standard, having been pre
3、pared under the direction of the DISC Board, was published under the authority of the Standards Board and comes into effect on 15 August 1998 BSI 1998 The following BSI references relate to the work on this standard: Committee reference IST/15 Draft for Public Comment 97/644971 DC ISBN 0 580 29556 7
4、 BS 7925-2:1998 Amendments issued since publication Amd. No.DateText affected Committees responsible for this British Standard The preparation of this British Standard was entrusted to Technical Committee IST/15, Software engineering, upon which the following bodies were represented: British Compute
5、r Society Defence Research Agency Institution of Electrical Engineers Lloyds Register of Shipping Ministry of Defence National Computing Centre Ltd. Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7925-2:199
6、8 BSI 1998i Contents Page Committees responsibleInside front cover Forewordiii Introduction1 1Scope1 2Normative reference1 3Definitions2 4Process2 5Test case design techniques3 6Test measurement techniques6 Annex A (informative) Process guidelines10 Annex B (informative) Guidelines for testing techn
7、iques and test measurement17 Annex C (informative) Test technique effectiveness48 BibliographyInside back cover Figure 1 Generic component test process2 Figure A.1 Document hierarchy10 Figure A.2 Example of component test strategy12 Figure A.3 Example of project component test plan14 Figure A.4 Exam
8、ple of component test plan14 Figure A.5 Example of test specification15 Figure A.6 Example of component test report16 Figure B.1 Input exam mark17 Figure B.2 Input coursework mark18 Figure B.3 Equivalence partitions and boundaries for total mark18 Figure B.4 Input exam mark23 Figure B.5 Input course
9、work mark23 Figure B.6 Boundary values23 Figure B.7 Equivalence partitions and boundaries24 Figure B.8 State transition diagram26 Figure B.9 STD for manage_display_changes27 Figure B.10 Cause-effect graph30 Figure B.11 Control flow graph for binsearch35 Figure C.1 Partial ordering of structural test
10、 coverage criteria49 Table B.1 Input exam mark19 Table B.2 Input coursework mark19 Table B.3 Invalid inputs20 Table B.4 Valid outputs20 Table B.5 Invalid outputs20 Table B.6 Minimized test case suite22 Table B.7 Input exam mark23 Table B.8 Input coursework mark23 Table B.9 Valid outputs24 Table B.10
11、 Additional test cases25 Table B.11 Additional test cases25 Table B.12 Possible transitions27 Table B.13 manage_display_changes component28 Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7925-2:1998 ii BSI
12、1998 Page Table B.14 Notation for state tables28 Table B.15 State table for the manage_display_changes component28 Table B.16 State table29 Table B.17 Test cases29 Table B.18 Decision table30 Table B.19 Test cases30 Table B.20 Test cases31 Table B.21 Test cases to cover mutations32 Table B.22 Test c
13、ases35 Table B.23 Occurrence of variables and their categories36 Table B.24 du-pairs and their type37 Table B.25 All-c-uses38 Table B.26 All-c-uses38 Table B.27 Test inputs39 Table B.28 Alternative test inputs39 Table B.29 Test inputs40 Table B.30 Test cases40 Table B.31 Test cases40 Table B.32 Test
14、 cases40 Table B.33 Overall set of test cases41 Table B.34 Test cases41 Table B.35 Initial test case set44 Table B.36 LCSAJs44 Table B.37 Additional tests45 Table B.38 New test sets45 Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 GMT+00:00 2006, Uncon
15、trolled Copy, (c) BSI BS 7925-2:1998 BSI 1998iii Foreword This part of BS 7925 was prepared by Technical Committee IST/15. It was developed by a working party of the British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST). A British Standard does not purport to include al
16、l the necessary provisions of a contract. Users of British Standards are responsible for their correct application. Compliance with a British Standard does not of itself confer immunity from legal obligations. Summary of pages This document comprises a front cover, an inside front cover, pages i to
17、iv, pages 1 to 50, an inside back cover and a back cover. Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 GMT+00:00 2006, Uncontrolled Copy, (c) BSI ivblank Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 G
18、MT+00:00 2006, Uncontrolled Copy, (c) BSI BSI 19981 BS 7925-2:1998 Introduction This standard specifies a process for the testing of software components and techniques for the design and measurement of that testing. It enables users to improve the quality of their software testing and thus the quali
19、ty of their software products. The standard can be used in the context of both the Inspection and testing provisions of BS EN ISO 9001 and the Software coding and testing provisions of BS ISO/IEC 12207. An important attribute of this standard is that it contains objective provisions which make it po
20、ssible to determine whether or not it has been followed in a particular case. The standard includes the concept of measuring testing as well as assessment of whether the testing meets defined targets. As there are many challenges in software testing, the standard is deliberately limited in scope to
21、cover only the lowest level of independently testable software. Because the interpretation of, and name for, this lowest level is imprecise, the term component has been chosen rather than other common terms such as unit, module, or program to avoid confusion with them (see BS 7925-1). 1 Scope This B
22、ritish Standard specifies a process for the testing of software components and techniques for the design and measurement of that testing. This standard is fully applicable to the testing of components written in procedural languages. The functional test case design techniques and test measurement te
23、chniques specified are applicable to all languages. The structural test case design techniques and test measurement techniques specified may not be applicable to non-procedural languages. This standard prescribes the generation of test cases using only valid input data values, i.e. values for which
24、the behaviour of the component under test is defined by its specification. NOTEGood practice in component testing would also include test cases that use invalid input data values as a means of testing the adequacy of the components specification. Formalization of such error guessing is excluded from
25、 this standard. This standard does not cover the following: some types of testing This standard excludes a number of areas of software testing, e.g. integration testing, system testing, user acceptance testing, statistical testing, testing of non-functional attributes such as performance, testing of
26、 real-time aspects, testing of concurrency, static analysis such as data flow or control flow analysis, reviews and inspections (even as applied to components and their tests). test completion criteria This standard does not prescribe test completion criteria as it is designed to be used in a variet
27、y of software development environments and application domains. Test completion criteria will vary according to the business risks and benefits of the application under test. selection of test case design techniques This standard does not prescribe which test case design techniques are to be used. O
28、nly appropriate techniques should be chosen and these will vary according to the software development environments and application domains. selection of test measurement techniques This standard does not prescribe which test measurement techniques are to be used. Only appropriate techniques should b
29、e chosen and these will vary according to the software development environments and application domains. implementation This standard does not prescribe how required attributes of the test process are to be achieved, for example, by manual or automated methods. fault removal This standard does not a
30、ddress fault removal. Fault removal is a separate process from fault detection. 2 Normative reference The following normative document contains provisions which, through reference in this text, constitute provisions of this British Standard. For dated references, subsequent amendments to, or revisio
31、ns of, any of these publications do not apply. For undated references, the latest edition of the publication referred to applies. BS 7925-1, Software component testing Vocabulary. Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 12:43:07 GMT+00:00 2006, Uncontrol
32、led Copy, (c) BSI 2 BSI 1998 BS 7925-2:1998 3 Definitions For the purposes of this part of BS 7925, the terms and definitions given in BS 7925-1 apply. 4 Process 4.1 General Before any component testing may begin there shall be a project component test strategy (4.2), and a project component test pl
33、an (4.3). Every component shall have a component specification which shall allow the output of the component to be determined for any sequence of inputs given an initial state and a defined environment for the component. NOTESee annex A for general guidance on the process. 4.2 Project component test
34、 strategy 4.2.1 The project component test strategy shall specify: a) the techniques to be employed in the design of test cases, and the rationale for their choice; these techniques shall be selected from those listed in clause 5; b) criteria for test completion and the rationale for their choice; t
35、hese test completion criteria shall be test coverage levels, the measurement of which shall be achieved by using test measurement techniques chosen from those listed in clause 6; c) the degree of independence from the design process required of personnel who design test cases; NOTETypical arrangemen
36、ts include the following: i) the test cases are designed by the person(s) who writes the component under test; ii) the test cases are designed by another person(s); iii) the test cases are designed by (a) person(s) from a different section; iv) the test cases are designed by (a) person(s) from a dif
37、ferent organization; v) the test cases are not chosen by a person. d) whether the component testing is performed using isolation, bottom-up or top-down approaches, or some mixture of these; e) the environment in which component tests will be executed, including a description of the hardware and soft
38、ware environment in which all component tests will be run; f) the test process that shall be used for component testing; for any given component, the specified test process shall start with component test planning and finish with verification of component test completion; each test case for a compon
39、ent shall first be specified, then executed and then recorded in the component test record. The component test is illustrated in Figure 1. NOTEThe sequence of component test specification, component test execution, and component test recording may be iterated and, on any one iteration, may be perfor
40、med for a subset of the test cases associated with a component. Later activities for one test case may occur before earlier activities for another. Figure 1 Generic component test process 4.3 Project component test planning The project component test plan shall specify the dependencies between compo
41、nent tests and their sequence. Their derivation shall include consideration of the chosen approach to component testing see 4.2.1d). NOTEDependencies may also be influenced by overall project management and work scheduling considerations. 4.4 Component test planning For each component a component te
42、st plan shall specify how the project component test strategy (4.2) and project component test plan (4.3) apply to the given component. This shall include specific identification of all exceptions to the component test strategy and all software with which the component under test will interact durin
43、g test execution, such as drivers and stubs. 4.5 Component test specification 4.5.1 For each component test cases shall be designed using the test case design techniques identified in the component test plan (4.4). Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08
44、 12:43:07 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BSI 19983 BS 7925-2:1998 4.5.2 Each test case shall be specified by defining its objective, the initial state of the component, its input, and the expected outcome. The objective shall be stated in terms of the test case design technique being use
45、d. 4.5.3 The execution of each test case shall be repeatable. 4.6 Component test execution Each test case defined in the component test specification shall be executed. 4.7 Component test recording 4.7.1 The test records for each test case shall unambiguously record the identities and versions of th
46、e component under test and the test specification. The actual outcome shall be recorded. It shall be possible, by reference to the test records, to establish whether all the specified test cases have been performed. 4.7.2 The actual outcome shall be compared against the expected outcome. Any discrep
47、ancy found shall be logged and analysed in order to establish: a) where the fault lies; and b) the earliest test activity that should be repeated in order to remove the discrepancy in the test specification or verify the removal of the fault in the component. 4.7.3 Whenever a fault is corrected by m
48、aking a change or changes to test materials or the component under test, the affected activities shall be repeated. 4.7.4 A record shall be made of the test coverage levels achieved for those measures that are specified as test completion criteria in the project component test strategy. 4.8 Verifica
49、tion of component test completion For each component the component test records shall be checked against the previously specified test completion criteria. If these criteria are not met, the earliest test activity that has to be repeated in order to meet the criteria shall be identified and the test process shall be restarted from that point. NOTEIt may be necessary to repeat the component test specification activity to design furt