問37
頻出度★★★
ホワイトボックステストのテストケース作成に関する記述のうち，適切なものはどれか。
平成25年度 春期 ITパスポート試験 問37
マネジメント系システム開発技術 › システム開発技術
This question's explanation and your answers so far.
解説
問 37
Incorrectア
Deliberately giving character data to an item whose input condition is numeric is a test that feeds in a value the specification says the item does not accept (an invalid equivalence class) and checks from the outside whether the input check works correctly. This is a technique called equivalence partitioning or error guessing; it does not refer to the internal structure of the program at all, and it creates test cases only from the specification of inputs and outputs. Therefore it is test case creation for black-box testing, and it is wrong as an explanation of white-box testing.
Incorrectイ
Expressing the correspondence between input data and output data as a graph and turning its valid combinations into test cases is a description of cause-effect graphing (a technique that draws the relationship between causes and effects as a diagram and expands it into a decision table to derive the combinations). What it focuses on is only the relationship between inputs and outputs in the specification; it does not concern itself with what branches the program is implemented with. So this too is classified as black-box testing and does not amount to test case creation for white-box testing.
Incorrectウ
Setting an upper limit and a lower limit for the input of a person's weight and testing with them is boundary value analysis (limit value analysis), which creates test cases by focusing on the edges of the range of valid values. It is an effective technique for finding defects where the processing goes wrong just before or after a boundary, but its basis is the specification of the range of values that may be entered, not the control structure inside the program. Therefore this too is a black-box testing technique, and it is wrong as an explanation of white-box testing.
- エ
正解 The correct answer is エ. White-box testing is testing that looks inside the program (the logical structure and control flow of the source code) and checks whether the internal processing works as intended. As the name — a box whose inside is visible — suggests, test cases are designed not only from the specification document but also from the actual branch and loop structures of the program. The guideline for that design is the coverage criterion (coverage). Typical criteria are statement coverage, which executes every statement at least once, and branch coverage (decision coverage), which goes through both the true path and the false path of a decision such as an if statement at least once. Option エ, “Create test cases so that all branch paths of the program are executed at least once”, is exactly branch coverage: it goes into the internal structure and brings to light the paths that have not been executed, so it is appropriate as test case creation for white-box testing. The aim of this coverage is to keep bugs from hiding in paths that have never been tested.
ここがポイント
- White-box testing designs test cases based on the internal structure of the program (its logic and control flow), and it is used a great deal in unit testing. Its coverage criteria include statement coverage, which executes every statement at least once, and branch coverage (decision coverage), which goes through both the true branch and the false branch of a decision at least once; how much has been exercised is measured as coverage.
- Black-box testing does not look at the internal structure and designs test cases only from the external specification (the relationship between inputs and outputs); typical techniques are equivalence partitioning, boundary value analysis (limit value analysis), and cause-effect graphing. Sorting out and remembering which of the two kinds of testing each technique name belongs to is the key to answering this type of question.
用語