Testing and maintenance
| English | Chinese | Pinyin |
|---|---|---|
| syntax error | 语法错误 | yǔ fǎ cuò wù |
| run-time error | 运行时错误 | yùn xíng shí cuò wù |
| logic error | 逻辑错误 | luó jí cuò wù |
| dry run | 手工跟踪 | shǒu gōng gēn zōng |
| white-box | 白盒 | bái hé |
| black-box | 黑盒 | hēi hé |
| stub | 桩 | zhuāng |
| boundary | 边界 | biān jiè |
| regression test | 回归测试 | huí guī cè shì |
Hunting down the bugs
- Finding errors — and keeping software working after release — is most of its lifetime cost.
- We classify errors, choose testing methods, and pick good test data.
- Then we maintain and safely amend the program.
Software process lab
Classify development examples by the stage or tool they belong to.
Types of error
- Syntax error 语法错误 — breaks the language's grammar (missing bracket); caught at translation, so the program won't run.
- Run-time error 运行时错误 — happens while running (divide by zero, file not found); the program crashes — fix by adding checks.
- Logic error 逻辑错误 — the program runs but gives wrong results (off-by-one, wrong operator); the hardest to find — only careful testing reveals it.
Three kinds of error: syntax (won't run), run-time (crashes) and logic (runs but is wrong)
Match each kind of error to how it shows up.
Syntax = caught at translation; logic = wrong output; run-time = crash while running.
Testing methods
- Dry run 手工跟踪 — trace the code on paper, recording each variable's value.
- White-box 白盒 — designed from the code's internal structure (cover every statement/branch).
- Black-box 黑盒 — designed from the specification only (inputs → expected outputs).
- Alpha (in-house) then beta (limited real users); acceptance testing by the customer. A stub 桩 stands in for a module not yet written.
A state-transition diagram for a door lock with code 259
Designing test cases from the specification only (inputs and expected outputs), ignoring the code inside, is called ______-box testing.
Black-box tests from the spec; white-box uses the code's internal structure to cover statements and branches.
Choosing test data
- Normal — typical valid values (marks 0–100:
50,75). - Abnormal — values that should be rejected (
-10,200,"abc"). - Boundary 边界 — the edges, where off-by-one bugs hide (
0,100, and just outside:-1,101).
Good test data covers normal, abnormal and boundary values — the edges catch off-by-one bugs
For a field that accepts marks 0–100, which are the boundary test values?
Boundary data sits at the edges of the valid range (and just outside) — where off-by-one errors hide.
Maintenance and amending
- Perfective — improve features/performance even though it works; adaptive — keep it working in a changing environment (new OS/law); corrective — fix bugs found in use.
- To amend a program: read the code, make the change small, update all callers, then regression test 回归测试 (check you broke nothing) and document it.
- Error types: syntax errors, run-time errors and logic errors. Test methods include walkthrough and integration testing; test data includes extreme values (the largest/smallest accepted).
Three kinds of maintenance: perfective, adaptive and corrective
Corrective maintenance fixes faults, perfective maintenance improves features, and adaptive maintenance keeps the software working in a changed environment.
Three maintenance types: corrective (fix bugs), perfective (enhance), adaptive (new OS/hardware/rules).
After changing a program, regression testing checks that:
Regression testing re-runs old tests to confirm existing behaviour still works after a change.
You've got it
- syntax (won't run) · run-time (crashes) · logic (runs, wrong output — hardest)
- black-box = from the spec; white-box = from the code; alpha/beta/acceptance stages
- test data: normal, abnormal, boundary (edges catch off-by-one)
- maintenance: perfective / adaptive / corrective; always regression test after a change