31 testing'' may be heard interchangeably. Additionally, these terms are often |
31 testing'' may be heard interchangeably. Additionally, these terms are often |
32 misused. |
32 misused. |
33 |
33 |
34 There are also a number of different philosophical approaches to software |
34 There are also a number of different philosophical approaches to software |
35 testing. For example, some organizations advocate writing test programs |
35 testing. For example, some organizations advocate writing test programs |
36 before actually imlementing the desired software, yielding ``test-driven |
36 before actually implementing the desired software, yielding ``test-driven |
37 development.'' Some organizations advocate testing from a customer perspective |
37 development.'' Some organizations advocate testing from a customer perspective |
38 as soon as possible, following a parallel with the agile development process: |
38 as soon as possible, following a parallel with the agile development process: |
39 ``test early and test often.'' This is sometimes called ``agile testing.'' It |
39 ``test early and test often.'' This is sometimes called ``agile testing.'' It |
40 seems that there is at least one approach to testing for every development |
40 seems that there is at least one approach to testing for every development |
41 methodology. |
41 methodology. |
90 accurate MAC-level implementation of the 802.11 specification and [...] a |
90 accurate MAC-level implementation of the 802.11 specification and [...] a |
91 not-so-slow PHY-level model of the 802.11a specification.'' |
91 not-so-slow PHY-level model of the 802.11a specification.'' |
92 |
92 |
93 Once this is done, one can develop an abstract model of the target system. This |
93 Once this is done, one can develop an abstract model of the target system. This |
94 is typically an exercise in managing the tradeoffs between complexity, resource |
94 is typically an exercise in managing the tradeoffs between complexity, resource |
95 requiremens and accuracy. The process of developing an abstract model has been |
95 requirements and accuracy. The process of developing an abstract model has been |
96 called @emph{model qualification} in the literature. In the case of a TCP |
96 called @emph{model qualification} in the literature. In the case of a TCP |
97 protocol, this process results in a design for a collection of objects, |
97 protocol, this process results in a design for a collection of objects, |
98 interactions and behaviors that will fully implement RFC 793 in @command{ns-3}. |
98 interactions and behaviors that will fully implement RFC 793 in @command{ns-3}. |
99 In the case of the wireless card, this process results in a number of tradeoffs |
99 In the case of the wireless card, this process results in a number of tradeoffs |
100 to allow the physical layer to be simulated and the design of a network device |
100 to allow the physical layer to be simulated and the design of a network device |
138 The system can be also be stressed by operating close to or beyond capacity by |
138 The system can be also be stressed by operating close to or beyond capacity by |
139 generating or simulating resource exhaustion of various kinds. This genre of |
139 generating or simulating resource exhaustion of various kinds. This genre of |
140 testing is called ``stress testing.'' |
140 testing is called ``stress testing.'' |
141 |
141 |
142 The system and its components may be exposed to so-called ``clean tests'' that |
142 The system and its components may be exposed to so-called ``clean tests'' that |
143 demostrate a positive result -- that is that the system operates correctly in |
143 demonstrate a positive result -- that is that the system operates correctly in |
144 response to a large variation of expected configurations. |
144 response to a large variation of expected configurations. |
145 |
145 |
146 The system and its components may also be exposed to ``dirty tests'' which |
146 The system and its components may also be exposed to ``dirty tests'' which |
147 provide inputs outside the expected range. For example, if a module expects a |
147 provide inputs outside the expected range. For example, if a module expects a |
148 zero-terminated string representation of an integer, a dirty test might provide |
148 zero-terminated string representation of an integer, a dirty test might provide |
201 reappear, but the term has evolved to describe any kind of change that breaks |
201 reappear, but the term has evolved to describe any kind of change that breaks |
202 existing functionality. There are many kinds of regressions that may occur |
202 existing functionality. There are many kinds of regressions that may occur |
203 in practice. |
203 in practice. |
204 |
204 |
205 A @emph{local regression} is one in which a change affects the changed component |
205 A @emph{local regression} is one in which a change affects the changed component |
206 directy. For example, if a component is modified to allocate and free memory |
206 directly. For example, if a component is modified to allocate and free memory |
207 but stale pointers are used, the component itself fails. |
207 but stale pointers are used, the component itself fails. |
208 |
208 |
209 A @emph{remote regression} is one in which a change to one component breaks |
209 A @emph{remote regression} is one in which a change to one component breaks |
210 functionality in another component. This reflects violation of an implied but |
210 functionality in another component. This reflects violation of an implied but |
211 possibly unrecognized contract between components. |
211 possibly unrecognized contract between components. |