12.3 Testing and Maintenance 测试与维护简答

Exposing faults and debugging

• Dry run/trace table：manually execute statements and record variable values。
• Walkthrough：step through code/algorithm, often with others, checking logic and values。
• Breakpoint：stops execution at a chosen line/state。
• Single stepping：executes one statement at a time。
• Watch/report window：monitors variables as they change。
• Temporary output statements/logging：show control flow and intermediate values。

Explain method + evidence of fault：unexpected variable value or unexpected path identifies where behaviour diverges。

Error types

Testing methods

• White-box：tests internal paths/branches with knowledge of code。
• Black-box：tests inputs against expected outputs without referring to internal code。
• Dry run/walkthrough：manual examination of logic and values。
• Integration：tests modules as they are combined and their interfaces/interactions。
• Stub：dummy replacement for an unavailable/faulty called module；returns known result so caller/integration can be tested。
• Alpha：in-house/developer testing before external release。
• Beta：small group of potential/real users test in real-world conditions and provide feedback before full release。
• Acceptance：customer checks the system against agreed requirements。

Test strategy and test plan

Strategy gives the overall approach、stages、responsibilities、methods、environment and success criteria。Test plan records specific cases：

• Test number/purpose。
• Input/test data and type。
• Expected result。
• Actual result。
• Pass/fail and corrective action/date where appropriate。

Expected result must be decided before the test, otherwise an incorrect result may be accepted accidentally。

Test data

• Normal：valid, typical value inside allowed range。
• Boundary/extreme：valid values at limits, and often values immediately around limits to expose off-by-one faults。
• Abnormal/invalid：outside allowed range or wrong format/type where applicable；should be rejected safely。

For valid inclusive range 24 to 37, strong tests include：24 TRUE、37 TRUE、23 FALSE、38 FALSE，再加 typical 30 TRUE。

Maintenance

Corrective

Fixes faults/bugs found after release because the program does not behave as expected。

Adaptive

Changes software to work with changed environment or requirements：new hardware/OS/technology、library changes、legislation or business requirements。

Perfective

Improves performance、usability or functionality even though the existing system works；responds to enhancement requests。

Mark-scheme pattern

This is adaptive maintenance because the program is changed to work with new hardware. Adaptive maintenance may also be required after a change in legislation or user requirements.

Exam checklist

• Debugging feature 是否同时说明如何暴露 fault？
• Syntax/logic/run-time 是否按发生方式区分？
• Testing method 是否与 stage/knowledge of code/customer context 匹配？
• Stub 是否说明 dummy module + known result？
• Beta 是否写 small user group、real use、feedback？
• Test plan 是否有 expected 与 actual result？
• Boundary 是否覆盖 minimum/maximum 及邻近 invalid values？
• Maintenance 是否按 bug/environment/improvement 区分？

---

本页不包含纠错代码或功能修改代码；这些将在代码与 debugging 专项中完成。