ソフトウェア結合テストに関して説明したものはどれか。
平成22年度 春期 ITパスポート試験 問34
This question's explanation and your answers so far.
問 34
Incorrectア
Combining with systems that perform related business processing and confirming that they operate normally is work that goes beyond the developed software itself and looks at whether the whole, including the surrounding existing systems, functions as a business operation. That corresponds to system testing (overall testing) or operational testing, which come after integration testing. What integration testing looks at is strictly the joints between programs inside the software being developed, not the hookup with separate external systems or the confirmation that the entire business operation runs. Its scope of verification is one level too wide, so it is not a description of integration testing.
Incorrectイ
White-box testing that covers all statements and branch conditions focuses on the internal structure and processing paths of a program and designs test cases so that coverage criteria such as statement coverage and branch coverage are met. That is a description of unit testing, which verifies the inside of one module at a time. Integration testing takes it as a premise that each module already works correctly and looks at their combination and their interfaces, so this description of covering the internal logic points to the earlier phase and is wrong.
Incorrectウ
A programmer using verification tools and checklists to confirm that a program was created according to coding standards refers to static testing (code review, static analysis), which inspects the source code itself without executing the program, and which looks at conformance to coding standards such as naming rules, indentation and forbidden constructs. Integration testing is dynamic testing that actually runs the program and checks its behavior, so the two differ both in the means of checking and in what is checked, which makes this wrong.
- エ
正解 The correct answer is エ. Software integration testing (also called combination testing or an integration test) is the phase in which the individual modules and programs that have passed unit testing are combined and run, and it is confirmed that their joints mesh correctly. What is checked here is the interfaces between programs: whether the number, order, data type, unit and value range of the arguments exchanged between the calling side and the called side, the passing of return values and error codes, and the layout of data passed through shared files or databases are all consistent with the design. Even when each module works exactly as specified on its own, a mismatch such as one side passing a value in centimeters while the other receives it in meters cannot be found by unit testing; it comes to the surface only once the parts are combined. Therefore エ, which says that it confirms that the interfaces between programs are consistent, is the correct description of integration testing. Note that there are two ways to proceed with the combining: top-down testing, which connects modules starting from the upper levels and substitutes stubs for the lower-level modules that do not exist yet, and bottom-up testing, which connects modules from the lower levels and substitutes drivers for the upper levels.
- The test phases widen their scope of verification step by step, in the order unit testing → integration testing → system testing → operational testing. The purpose of integration testing is to confirm that when the modules and programs that have passed unit testing are connected, their interfaces (the number, type and unit of arguments, the return values, the layout of the data passed) are consistent. It is the phase that flushes out mismatches that do not appear when the parts run on their own and emerge only once they are combined.
- Telling apart the phases and techniques that are easy to confuse: white-box testing such as statement coverage and branch coverage looks inside a module and is unit testing; checking conformance to coding standards with tools and checklists is static testing (code review), which does not involve running the program; combining with other business systems to see whether the business operation runs is system testing or operational testing. Only integration testing takes the joints between programs as its target.