Upgrade to Pro — share decks privately, control downloads, hide ads and more …

単体テストソムリエになろう!(WACATE参加者用)

scarletplover
December 22, 2023
360

 単体テストソムリエになろう!(WACATE参加者用)

予告なしに変更・削除されることがあります。ご承知おきください

scarletplover

December 22, 2023
Tweet

Transcript

  1. 単体テスト ▪ JSTQBより – コンポーネントテスト(ユニットテストとも呼ばれる)︓コンポー ネントを単独でテストすることに 焦点を当てる。コンポーネントテストは、 テストハーネス、またはユニットテストフレームワークのよ うな特定のサ ポートを必要とすることが多い。コンポーネントテストは、通常、開発者

    が開発環境で⾏う。 実際の現場ではプログラムごと、画⾯ごと、振る舞い単位(コンポー ネントの集合体)で⾏われることも多く、これは単体テストと多くの 現場で呼ばれているものの説明ではない (おそらくコンポーネントテスト=単体テストになってほしいという思いの表明)
  2. 単体テスト ▪ SWEBOK – ユニットテスティング︓別々にテストできるソフトウェア構成要 素を切り離し、それぞれの働き(functioning)を検証する。前後関係 (context)に依存して、これらは独⽴したサブプログラミングであったり、 密接に結合された単位から作られた、より巨⼤なコンポーネントだったり する。 ▪

    SQuBok – 単体テスト︓モジュールやクラスなどテストが実施可能な部分をテス トする。 (アーキテクチャや単体テストツールを駆使してプログラムの最⼩単位(コンポーネント)ごとに テストするのをデファクトスタンダードにしたいけど実態は) テストできる最⼩単位を切り離して検証するテスト
  3. システムテストなら。。 ▪ テスト設計 – ⽂献にテストタイプとかの説明がもっと詳しく書いてある ▪ 多くの場合、エンドツーエンドのタスクに対する機能テストや品質特性に対す る⾮ 機能テストといったシステムやプロダクト全体の振る舞いや能⼒の全般 に焦点を当てる。⼀部の⾮機能

    品質特性については、本番相当のテスト環境 において、すべて揃ったシステムでテストすることが望ま しい(例えば、使 ⽤性テスト)。サブシステムのシミュレーションを使⽤することも可能である。 シス テムテストは、システムの仕様に関連するものであり、独⽴したテスト チームによって実施されること がある(JSTQBより)。 – テスト技法に⾔及する⽂献の多くがシステムテストに類するテストを事例 としており、イメージしやすい。 ▪ ⼈事管理システム(はじめて学ぶテスト技法) ▪ Webサイトの⾒直し(マインドマップから始まるテストウェアテスト)
  4. 単体テストだと。。 ▪ 古典は「じゃあどうやってテストするのよ︕」って本が多い – ホワイトボックステストっていいますが・・・ – スタブ・ドライバ使うんです︕って書いてあるけどそれ、どうやって作るの︖ – 書いてあっても製品コードが古すぎて参考にならない。 ▪

    最近の本はいきなり「コードで書くもの︕⼿動何それおいしいんですか︖」 「ツール使え︕」って前提の本が多い – ⾃動テストをデファクトスタンダードにしたいという思想が強い。 – ⼿段に偏っていることが多い。 – 古典との連続性がなく、概念を把握しにくい。 – 最近「単体テストもブラックボックステストでかくもの(キリッ)」までものが 出てきてもはや何⾔ってるかわからない。
  5. 単体テストでの⼤事な要素 ▪ テストなので、「テスト対象=どの単位でテストするか」「ど こに着⽬してテストを作成するか︖」が⼤事 ▪ 単体テストはプログラムの中のことを確認しなくてはならないので、何 かとツールが必要。よって「どう実施するか」も重要になる。実施 ⽅法によってテスト対象や着⽬点が制約を受けることもしばしばある。 ▪ 現場によっては「単体テスト」に「統合テスト」を含んでいる場合もあ

    る。また静的テストで実装内容を確認しているかどうかによって単体テ ストのケースが変わることがある。よって「前後のテスト⼯程」を 勘案する必要がある。 ▪ プロジェクトのプログラミング⼯程は1⼈じゃないため、上記の事項に おいて「どこまで共有・ルール化しているか」でプロジェクトと しての単体テストの質が変わる。
  6. どの単位でテストするか ▪ 基本的には「モジュール」だが・・・ – クラス・関数・コンポーネント・・・ – コンパイルされたプログラムの場合もある。 ▪ 時代によって凝集性が上がり結合度が下がっている。 「モジュール」の中⾝がどんなものかは把握しておく必要がある。

    – 1960年以前︓芸術品としてのプログラム・・・プログラマ頼み – 1960年代〜︓構造化プログラミング・・・制御構造 ブロック化 – 1990年代〜︓オブジェクト指向・・・カプセル化 再利⽤ ? メイン ⼊⼒項⽬のチェッ ク 料⾦計算 印刷 メインルーチン ⼊⼒チェック 料⾦計算 印刷 メイン ⼊⼒項⽬のチェッ ク 料⾦計算 印刷 メインルーチン ⼊⼒チェック 料⾦計算 印刷 インプット ビジネス ロジック アウトプット オブザーバー 属性 操作 ビュー クラス 属性 操作 コントローラー クラス 属性 操作 モデル クラス 属性 操作 モデル クラス 属性 操作
  7. 単位の種類 ▪ モジュールにも⾊々ある – 画⾯ – DBに接続する – ビジネスロジック –

    処理の順番を管理する ▪ モジュールによって単体テストの意 味やしやすさが違う – ビジネスロジックはロジック 単位でテストできる – 画⾯はどっかで⼈間の⽬視が 必要 – DBは実際にDBに繋がないとテ ストできない部分がある。 ビジネスロジックな どは単独でテストし やすい コントローラーやDB 周り、UI周り は単体でテストしに くい
  8. どこに着⽬してテストするか ▪ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ▪ 単体テストで確認するアーキテクチャ –

    他の単位とのインターフェース(クラス間など) – 他の単位とのコミュニケーション(クラス呼び出しなど) – 状態の変化(セッション、画⾯の状態など) ▪ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序
  9. どこに着⽬してテストするか ▪ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ▪ 単体テストで確認するアーキテクチャ –

    他の単位とのインターフェース(クラス間など) – 他の単位とのコミュニケーション(クラス呼び出しなど) – 状態の変化(セッション、画⾯の状態など) ▪ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 ここにフォーカスしたテス トケースを作成するのが 原則
  10. どこに着⽬してテストするか ▪ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ▪ 単体テストで確認するアーキテクチャ –

    他の単位とのインターフェース(クラス間など) – 他の単位とのコミュニケーション(クラス呼び出しなど) – 状態の変化(セッション、画⾯の状態など) ▪ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 基本はアーキテクチャとし てのインターフェースやコ ミュニケーション、状態変 化に落ちる テストケースはアーキテク チャのインターフェースに 依拠するはず
  11. どこに着⽬してテストするか ▪ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ▪ 単体テストで確認するアーキテクチャ –

    他の単位とのインターフェース(クラス間など) – 他の単位とのコミュニケーション(クラス呼び出しなど) – 状態の変化(セッション、画⾯の状態など) ▪ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 ここはいわば実装部分。 変更が多いため、ここを起 点にテストをすると保守性 が低くなる
  12. どこに着⽬してテストするか ▪ 単体テストで確認する仕様 – ビジネスロジック – UIの⾒た⽬ ▪ 単体テストで確認するアーキテクチャ –

    他の単位とのインターフェース(クラス間など) – 他の単位とのコミュニケーション(クラス呼び出しなど) – 状態の変化(セッション、画⾯の状態など) ▪ 開発者が決める実装内容 – メソッド・変数の名前 – 処理の細かいロジック – 処理順序 ここにフォーカスしたテス トケースを作成するのが 原則
  13. 複雑さをどうテストするか ▪ 開発者が決める実装内容のみにフォーカスしたテストをして はいけないが、問題がないかの検証は必要 →単体テストまでに潰しておく必要がある ▪ 複雑さをどうテストするか – 基本は全てテストで実⾏されていない経路がないことを 確認する(カバレッジ)。

    ▪ 命令網羅︓ – すべての命令が少なくとも⼀回は実⾏されるようにテ ストを設計する。 ▪ 分岐網羅︓ – 判定条件の結果として、真になる場合と偽になる場合 がそれぞれ少なくとも⼀回は出現するようにテストを 設計する。 ▪ 条件網羅︓ – 条件判定における個々の条件について、すべての真偽 が少なくとも1回は出現するようにテストを設計する。
  14. 複雑さをどうテストするか ▪ カバレッジは確保してるけどテストが不⼗分になるパターンに注意 – 組み合わせが⼗分にテストできていない – 境界値分析ができてない if(x == true

    || y == true){ return true; //x,yのどちらかが真だったら真 //x、y両⽅のパターンのテスト 要 } if(hoge >= 1 && hoge <=10){ return true; //1以上10以下だったら真 //境界値分析が必要 }
  15. どう実施するか ▪ ⼿動か⾃動か – UI関連はどっかで⽬視が必要になる場⾯ が存在する – ⾃動については「何でテストするか」 でできることがだいぶ変わる ▪

    昔は頑張って呼び出し元プログラムを 偽造できるようにシステムを作成しな ければ⾃動テストできなかった。 ▪ 今はmockなどの技術が発達し、そこま で頑張って意識しなくても⾃動テスト できるようになった。 ▪ より⼩さいところからテストできるよ うになるのが理想。 ▪ テスト記録ツール – 単体テストツールには⾃動でついてる が⼿動でもテスト内容を記録し、カバ レッジ率を計ってくれるものが存在。 テストした いクラス 呼ばれるモ ジュール 呼ばれるモ ジュール mockで偽造する
  16. 前後のテスト⼯程について ▪ 単体の統合について – 現場では「モジュールテスト+統合テスト」を単体テストと呼んでいると ころも多い ▪ マイヤーズでは「モジュールテスト」の章にモジュールテスト + 統合テ

    ストが書かれている。 – テストの実施⽅法によってはモジュールテストがやりにくいところもある。 ▪ DB周りや画⾯では統合した上でテストをすることが推奨されるクラスも ある – ⼤事なのは「最⼩の単位」の統合をどう考えているのか ボトムアップでの 統合 トップダウンでの 統合
  17. 前後のテスト⼯程について ▪ 静的テストについて – 開発者が決める仕様については、開発者のコードレビューを実施している ことが望ましい – コードの書き⽅によって、テスト内容が変わる。 配列を結合する例 let

    ⼊⼒配列 = [“あ”,”い”,”う”,”え”,”お”]; let 結果; for(let i = 0; i <5 ;i++){ 結果=結果+⼊⼒配列[i]; //ぐるぐる回して結合 } return 結果; let ⼊⼒配列 = [“あ”,”い”,”う”,”え”,”お”]; let 結果=⼊⼒配列.join(“”);
  18. テストの内容を共有しているか ▪ 世の中には「テスト内容は開発者に任せている」「⾃動テストができる⼈だけ ⾃動テストをやっている」という現場が存在する。 ▪ テストの単位、着眼点、⼿段についてチームでどこまで平仄をとっているかは チーム次第である。 – ⾃動テストを必ずやる。コードカバレッジ100% –

    テストを⾏う単位ややる内容、粒度は決まっているが⼿段は決まっていな いetc… ▪ また決められた単体テストのルールを守っているかをどう確認しているかも チームによって違う。 – コードレビュー – テスト仕様書レビュー – エビデンス確認
  19. チームレジェンドの単体テストの例 ▪ チーム︓ クライアントサーバーシステムで画⾯側のWindowsフォームを作成。 ▪ 困りごと︓ 直感的に単体テスト(開発者テスト)で出るバグがシステムテストで出ている。 ▪ 単体テスト︓ 単体テストの単位

    画⾯ごとのテスト。ビジネスロジックも基本は画⾯ごと。 ⼿段 ⼿動。 着眼点 画⾯の⼊⼒情報と画⾯状態に着⽬してテストケースを作成。 テスト仕様書を作成してテストしている。組み合わせも考慮さ れている。 次のテスト⼯程 システムテスト 共有 上記事項については共有されており、テスト仕様書を業務SEが レビューしている。 コードのカバレッジが図られていないため、テストされてないコード上の分岐があるのでは︖ 画⾯ごとではなく、ロジックごとにテストができるようにするのが理想。 せめてテスト記録ツールを⼊れるなどして、単体テストがしやすい環境にするのが良い。 ー
  20. チーム最近の単体テストの例 ▪ チーム︓ WEBサービスのフロントエンドをREACTで組んでいる。 ▪ 困りごと︓ 直感的に単体テスト(開発者テスト)で出るバグがシステムテストで出ている。 ▪ 単体テスト︓ 単体テストの単位

    WEBのUI画⾯部品(⼊⼒フォーム部分とか)ごと、ロジック部 分(APIとの接続)は関数ごと。 ⼿段 Reactのテストフレームワークで⾃動テストをやっている。 着眼点 基本はUIのインプット情報ごとにテストケースのコードをTDD で書いている。コードカバレッジ100%。 次のテスト⼯程 次がもうシステムテスト 共有 上記事項については共有されており、コードレビューもしてい る。 統合をどこでやっているか曖昧。 単体テストについて、テストとしての観点が少なく、境界値分析がやられていなのでは︖
  21. 参考⽂献 ▪ ⽇本科学技術連盟. 「ソフトウェア品質知識体系ガイド(第3版)-SQuBOK Guide V3-」. ⽇本科学技術連盟.,2020 ▪ 新⾕勝利. (2013).

    「ソフトウェアエンジニアリング基礎知識体系ガイド - SWEBOK V3.0 -.」 ⽇本規格協会, 2013 ▪ ロバート・C・マーティン. 「クリーンアーキテクチャ ソフトウェア設計の原則とパターン」. 翔泳社, 2018. ▪ NPO法⼈ASTER. 「ASTERセミナー標準テキスト」. https://www.aster.or.jp/business/seminar_text.html, (参照 2023-12ー18) ▪ グレンフォード・J・マイヤーズ, トム・バジェット, テッド・M・トーマス, コーリー・サンドラー. 「ソフトウェア・テス トの技法」. 近代科学社, 2006. ▪ 児⽟公信. 「UMLモデリングの本質」. 翔泳社, 2011. • JSTQB. 「テスト技術者資格制度 Foundation Level シラバス 」. https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf, (Version 2023V4.0.J01) ▪ ⾠⺒敬三. 「ソフトウェアテストの歴史と近年の動向」. https://www.slideshare.net/Bugler/ss-139696080, (参照 2023-12ー18) ▪ Vladimir Khorikov,.「単体テストの考え⽅/使い⽅」(Vladimir Khorikov, 須⽥智之著) ▪ 本スライドのアイコンの著作権はLeremyにあります(www.freepik.com)