[例題]単機能テストを設計する

1. [例題]テニスのスコアボード
2. [例題]分析する　- 3色ボールペン版
3. [例題]分析する　- マインドマップ版

仕様分析からテスト設計へ。まずは、単機能テストの設計をしてみる。
・・・
・・・
ふと、単機能テストを検索してみると、けっこう「単機能テスト＝単体テスト、コンポーネントテスト」という記述があったりする。単なる用語の使い方の違い、という考え方もあるけれど、僕の認識では、単機能テストと単体テストは違うテストと思う。単体テストの目的は、「関数・メソッドといった”システムの一部”が正しく実装されているか」であり、やり方によっては組み合わせテストも含まれるし、主にホワイトボックステスト（あるいはグレーボックステスト）で設計されることが多い。一方、単機能テストの目的は「機能が単独で正しい動作をするかどうか」であり、組み合わせテストを含まず、実行結果が注目されるテスト。ブラックボックス的。

# 当然、後者の意味で「単体テスト」と表現する場合もありました。

などと思いをめぐらしながら、例題の単機能テストへ。

1. 電源ボタン

仕様をみてみると、

電源の切り替えができるかどうかが単機能テストであろう。


2. リセットボタン

仕様より、

電源ONの状態で、画面がリセットされるかどうかが単機能テスト。


3. ポイント（上）ボタン

ポイントボタンは仕様がやや複雑であるが、ここではもっとも基本的な動作である、電源ONの状態で、上のプレイヤーのPOINTSが追加されるかどうかを単機能テストとする。GAMESおよびSETSへの反映パターンはここでは考慮しない。という方針。


4. ポイント（下）ボタン

ポイント（上）ボタンと同様。

こんな感じ。このスコアボードはボタンが4つしかなく、減点機能がないため、これらのテストケースの実施順序は最終的に変更する予定。