そう言えば最近、音楽聴くのにコンポとか使う人減ったよね？〜テストレベル Part2
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
久々にギターの弦を買いに行ったけど高くて泣きそう、って言うか泣けたよね、、、
エレキもアコギも両方買うタイミングだったからWパンチで出費が痛いね。
泣けたところで、コンポーネントテストのお勉強始めるよー
コンポーネントテストの目的
• リスクの軽減
• コンポーネントの機能的/非機能的振る舞いが設計および仕様通りであることの検証
• コンポーネント品質に対する信頼の積み上げ
• コンポーネントに存在する欠陥の検出
• 欠陥がより高いテストレベルまで見逃されることの防止
まずは部品レベルで仕様を満たしていて、欠陥が無いかを確認して後々の故障リスクを軽減させる目的だね。
インクリメンタル開発モデルやイテレーティブ開発モデル(アジャイルなど)と言ったプログラムを継続して更新する場合、同じテストを繰り返して変更による既存のプログラムに悪影響が出てないことを確認するので、テストを自動化して簡単に繰り返しできるようにするのが推奨されているよ。
テストベースとテスト対象
テストベース
コンポーネントテストでテストベースとして使用できる作業成果物の例:
• 詳細設計
• コード
• データモデル
• コンポーネント仕様
テスト対象
コンポーネントテストの典型的なテスト対象の例:
• コンポーネント、ユニット、またはモジュール • コードとデータ構造
• クラス
• データベースモジュール
テストベースはテストを行う元ネタのことだったね？テストベースとなる資料に書かれてるソフトウェア製品やシステムの部品であるコンポーネントの細かい処理や動作、データの取り扱い方（データモデル）と言った詳細情報を元にテスト分析、設計を行うことになるよ。
テスト対象はそのテストベースと同じ元ネタで作られた細かい部品単位と言うことになるね。
見つけておきたい典型的な欠陥と故障
コンポーネントテストの典型的な欠陥と故障の例:
• 正しくない機能(例えば、設計仕様の記述とは異なる)
• データフローの問題
• 正しくないコードとロジック
コンポーネントテストは開発担当者が行うことが多くて、検出した欠陥は、形式に沿った欠陥レポートを記載せずに見つけたらすぐに修正するのが一般的とされてるよ。
でも、開発担当者が欠陥レポートを書くと、根本原因分析やプロセス改善にとって重要な情報が多くて後々、助かるので欠陥レポート記載も推奨したいところだね。
アプローチと責務
コンポーネントテストはコードを開発した開発担当者が行うことが一般的と言う説明をしたけど、そうでない場合、少なくともテスト対象のコードにアクセスできる必要があるとされているよ。
ただし、テスト対象が（画面で操作できる）GUIのコンポーネントの場合はコードへのアクセスは不要になるね。
また、システムの他の部分と切り離したコンポーネントごとのテストを行うと言う特徴からモックオブジェクト、サービス仮想化、ハーネス、スタブ、ドライバーと呼ばれる連結処理の仮のプログラムやコード、アプリを活用したりするよ。
例えば
・データベースのテストをするのにデータ登録コンポーネントが無い場合に仮の登録画面を作る
・画面操作でAPIの処理をして次の画面で結果表示機能で画面が出来てない場合にAPIを直接実行
と言った具合に組み合わせる機能のダミーを使ったり、直接、機能を動かすイメージで覚えておいてね。
こうやって、開発担当者が欠陥の検出と修正を行った場合、欠陥コンポーネントから修正したコンポーネントのコードを差し替えてテストしながら開発を進めるんだ。
最後にテスト駆動開発という用語があるので見ておこうね。
高度にイテレーティブであるテスト駆動開発(TDD)のサイクルは、自動化されたテストケー スの開発、小規模なコードの構築と統合、コンポーネントテストの実行、問題の修正、コードのリファクタリングで構成される。このプロセスは、コンポーネントを完全に構築し、すべてのコンポーネント テストが合格となるまで継続する。テスト駆動開発は、テストファーストアプローチの一例である。テスト駆動開発はエクストリームプログラミング(XP)がオリジナルであるが、アジャイル開発の他のアプローチおよびシーケンシャルライフサイクルにも普及している。
テスト駆動開発はテストする内容をリストアップして失敗するコードを書く→テストが通るコードを書く→重複、失敗部分を除去（リファクタリング）と言う手順で行うよ。
従来の開発ではコードを書いてテストだったから順番が入れ替わっていることからテストファーストのアプローチとも呼ばれるんだ。
開発側のテストと言う位置付け
テストタイプのお話をする時に改めて説明はするけど、コードの中身やプログラムの内容を調査、解析して欠陥を探すのをホワイトボックステストと呼んでて、コンポーネントテストはホワイトボックステストと言うテストタイプで行われることが多いよ。
コードの中身、プログラミングの内容が理解できるだけの知識も必要だから基本的に開発側で担当することになるんだ。
その場合、テストの心理学で勉強した通り作った本人には確証バイアスが働くのでコンポーネントテストはご本人が担当してしまうとテスト内容が甘くなりがちなんだよね？
開発担当と打ち合わせの機会があって、ある程度の信頼関係ができていたら
「こんなテストもしておいた方がええですよー」
と抜けそうな部分や次のテストレベルで欠陥があるとテストが止まって困る部分をお伝えしておくと、コンポーネントテストの段階で有効なテストに貢献できるんだ。
次回は統合テスト（結合テスト）のお話をするからねー
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？