Black-box testing (ブラックボックステスト) is a test technique that ignores the program's internal structure and checks, against the external specification (外部仕様), whether each input produces the correct output.
Group (spec: orders of 1 to 50 items are accepted)
Range
Example values
Expected result
Valid
1–50
25
Accepted
Invalid (too few)
0 or less
0
Returns an error
Invalid (too many)
51 or more
80
Returns an error
Range edges and their neighbors
Edge of each range
0, 1, 50, 51
1 and 50 accepted; 0 and 51 return errors
Because testers build the cases from the specification alone, someone other than the person who wrote the code can design them. A typical method, equivalence partitioning (同値分割), splits the inputs into groups that each lead to the same result and picks a representative value from each group. Boundary value analysis (境界値分析), which focuses on the edges of each range and the values right beside them, can also be built from the specification alone.
AnalogyIt is like testing a calculator by pressing keys and seeing whether the displayed answer is right, without ever opening the case.
How to rememberA black box is painted black so you cannot see inside; all you can watch is what goes in and what comes out.
Exam points
ExamBlack-box testing (ブラックボックステスト) does not look at the internal structure; it checks that inputs map to the right outputs according to the specification.
ExamEquivalence partitioning (同値分割), one way to build cases, divides the inputs, valid and invalid alike, into groups that give the same result and takes at least one value from each group.
Mix-upDesigning cases so that every statement or every branch gets executed is the approach of white-box testing (ホワイトボックステスト), which looks at the internal structure. White-box testing is used mainly in unit testing (単体テスト).
Integration testing (統合テスト) combines programs or components that have passed unit testing and checks whether their interfaces (インタフェース: the agreed rules for passing data and making calls) mesh correctly.
Unit testing
Integration testing
System testing
Operational testing
Operational testing: users check that the system works in their actual business flow.
4 / 4
Also called 結合テスト in Japanese (literally a joining test), it checks the seams, because components that each work correctly on their own can still fail where they connect if the format or order of the values they pass does not match. Testing generally moves from unit testing (単体テスト) of each component, to integration testing, to system testing (システムテスト), where developers check the whole system against the requirements, and finally to operational testing (運用テスト), where users confirm it works for their business. Mapped to the development phases, integration testing verifies the output of internal design (内部設計), the phase that decides the system's internal structure.
AnalogyIt is like mounting an engine and a gearbox that have each passed inspection onto the car body, then checking that pressing the accelerator really turns the wheels.
How to remember結合 literally means "tie and join": what you inspect is not each part but the knot between them.
Exam points
ExamIntegration testing (統合テスト) connects programs that have finished unit testing (単体テスト) and checks that data passes as the interface (インタフェース) rules specify, so the programs work together.
ExamPaired with the development phases, unit testing matches programming (プログラミング), integration testing matches internal design (内部設計), system testing (システムテスト) matches external design (外部設計), and operational testing (運用テスト) matches requirements definition (要件定義).
Mix-upMeasuring the performance of the whole system belongs to the next stage, system testing, while integration testing targets the seams between components. Checking internal paths exhaustively belongs to the stage before it, unit testing.
Performance testing (性能テスト) measures, with figures such as response time (応答時間) and throughput (スループット: the number of items handled in a set time), whether the system can process work at the required speed and volume.
How fast and how much the system can process is one of the non-functional requirements (非機能要件), the conditions other than functions, such as performance and reliability, and this test checks whether their target values are met. Because the measured values depend on the equipment, the test runs in an environment whose hardware and software are close to production. It only means something for the whole system once the components are connected, so developers carry it out mainly at the system testing (システムテスト) stage.
AnalogyIt is like timing a store's new checkout register with a stopwatch: how many seconds one customer's payment takes, and how many customers it can serve in an hour.
Exam points
ExamWhether performance requirements such as response time (応答時間) and throughput (スループット) reach their targets is checked by developers mainly in system testing (システムテスト).
Mix-upChecking whether the results match the specification is functional (functionality) testing; performance testing (性能テスト) is a separate thing that measures speed and volume.
Load testing (負荷テスト) raises simultaneous access or data volume up to the expected maximum and beyond, to see whether the system keeps running and where its processing limit lies.
Normal volume
Expected maximum
Beyond the maximum
Limit point
Record the point where processing can no longer keep up as the limit.
4 / 4
It is a kind of performance testing (性能テスト) that raises the number of accesses and the data volume step by step, watching how responses slow down and where processing can no longer keep up. It may also check whether the system returns errors without corrupting data once the limit is passed, and whether it gets back to its original speed when the load drops.
AnalogyIt is like a bridge load test: you add weights a little at a time and note the weight at which the deck suddenly starts to sag much more.
Exam points
Mix-upLoad testing (負荷テスト) goes beyond measuring whether targets are met under set conditions: it pushes volume past the maximum to find the limit and how the system behaves near it, which gives it a different aim from ordinary performance testing (性能テスト).
Performance testing vs. Load testing
Aspect
Performance testing
Load testing
Key differenceAim
Measures whether the required speed and volume are met
Finds how the system behaves and where its limit lies as volume grows
Volume applied
The volume in the conditions set for the required level
Regression testing (回帰テスト) reruns tests that have already passed after a program is fixed or changed, to check whether features that used to work have been broken by the change.
Fix the program
Check the fix
Rerun passed cases
No impact on existing features
If the results match earlier runs, conclude that the fix has not broken anything else.
4 / 4
It also goes by the katakana name regression testing (リグレッションテスト), and its aim is to catch defects that a fix introduces into existing features (degradation, デグレード, a slide backward in quality). Fixing one spot can affect other processing that shares the same component, so the surrounding features are rerun as well, not just the fixed part. Because the same tests are repeated after every change, regression testing pairs well with test automation.
AnalogyIt is like repairing the kitchen pipe and then turning on every tap in the house to make sure the bath and the washbasin still run.
How to rememberRegression means "going backward": you check that quality has not slipped back while you thought you were fixing things.
Exam points
ExamAfter fixing a program that has finished testing, add the cases that check the fix to the full set of previously passed cases and run the whole set again.
ExamRerunning only the case that found the defect is not enough; you also check whether the fix has affected other features.
ExamTests of changes made to a running system, regression tests (回帰テスト) among them, take place in a separate test environment configured the same as production, so that production is not affected.
Black-box testing builds cases from the specification alone; equivalence partitioning splits the inputs into groups and picks a representative value from each.
Testing proceeds through the unit, integration, system, and operational stages, and integration testing checks the seams between programs.
Performance testing is a non-functional test that measures in figures whether response time and throughput reach their targets, mainly during system testing.
Load testing is a kind of performance testing that pushes volume past the maximum to find the limit.
Regression testing rechecks that a fix or change has not broken existing features.