6.1 テストツールの考慮事項
テストツールって何?
-
テストに直接利用できるツール
- xUnit等
-
テストベース、テストウェア等を上手く取り扱うツール
- テストプロセスのマネジメント支援
- 成果物の構成管理
- 欠陥マネジメント
-
テスト実行のモニタリングとレポートのためのツール
- CPU,mem,I/O,network等の監視
-
分析と評価に利用できるツール
- アプリケーションのファイル仕様状況監視等
-
テストに役立つあらゆるツール
- Excel
6.1.1 テストツールの分類
テストツール導入の目的
-
手動で行うと大量のリソースを必要とする反復作業を自動化することによって、テスト活動の効率を改善する
- 例: リグレッションテスト
-
テストプロセス全体を通して、手動で行うテスト活動を支援することによって、テスト活動の効率を改善する
- 例: 日々のテスト実績の集計、欠陥の記録・分析
- テストの一貫性や欠陥の再現性を高めることで、テスト活動の品質を改善する
-
手動では実行できない活動を自動化する
- 例: 大規模な性能テスト
- 例えば、大量のデータの比較を自動化、または動作のシミュレーションをすることにより、テストの新制度を向上させる
さまざまな分類軸
- 目的
- 価格
-
ライセンスモデル
- 有料
- オーブンソース
- 使用している技術
プローブ効果
テストツールがテストの実行結果に影響を及ぼすこと
例: 性能テストツールによって実行される余分な命令のせいで応答時間が実際と変わってしまう
【所感】マルチスレッドの世界で顕著だと1社目で聞いた…
開発担当者向けのツール
例: 静的解析ツール、xUnit等
コンポーネントテストやコンポーネント統合テスト時に使用されるツール等
テストとテストウェアのマネジメントの支援ツール
テストマネジメントツールとアプリケーションライフサイクルマネジメントツール(ALM)
要件からテストケースまでのトレーサビリティを確保
例: TestLink
要件マネジメントツール
関連する別の要件やテストへのトレーサビリティ確保
例: TestLink
欠陥マネジメントツール
例: Redmine, Bugzilla
構成管理ツール
ソースコード同様、テストウェアもバージョンコントロールして構成管理する必要がある
例: Git
継続的インテグレーションツール(開発)
例: Jenkins
静的テストの支援ツール
レビューツール
例: ReviewBoard, GitHubとかGitLabとかについてるやつも
例: Redmine, Trac等でレビュー実施結果記録、指摘事項共有
静的解析ツール(開発)
【補】PHPのPHPStan等
テスト設計とテスト実装の支援ツール
テスト設計ツール
組み合わせテストケースの自動生成
例: PictMaster
https://ja.osdn.net/projects/pictmaster/
モデルベースドテストツール
状態遷移モデル等からテストケース自動生成
例: GraphWalker
https://pragmatic-qa.com/state-transition-testing-with-graphwalker/
テストデータ準備ツール
参考書の例なし
【補】Laravelのfactoryなんかが近いかな
テスト駆動開発(TDD)ツール(開発)
例: xUnit
受け入れテスト駆動開発(ATDD)ツールや振る舞い駆動開発(BDD)ツール
例: RSpec
【補】PHPのBehatとかも
テスト実行と結果記録の支援ツール
テスト実行ツール
例えば、リグレッションテストの実行
例: Selenium
要件カバレッジツール、コードカバレッジツール
要件カバレッジ
前述の要件マネジメントツールを用いる
コードカバレッジ
例: JavaだとOpenCloverとか使うらしい
【補】PHPだとpcovとかxdebugとか
テストハーネス(開発)
ドライバ/スタブのこと
ユニットテストフレームワークツール
xUnit
テスト実行の仕組みも提供するから「ライブラリ」ではなく「フレームワーク」という位置づけらしい
性能計測と動的解析の支援ツール
性能テストツール
例えばtoCのサービスでシステム要件として同時接続数やtps等が定義される場合にテストが必要
例: Apache JMeter
モニタリングツール
厳密にはテストツールではないが、「メモリリークが起きていないか」といった観点でテストするときに使用する
静的解析ツール(開発)
スレッドエラーの検出等で使用する
例: Valgrind
特定のテストに対する支援ツール
-
データ品質の評価
- 本番環境のデータをマスキングしてテストに用いる場合などに
- 例えば、ちゃんと検索できるか?等
-
データの変換とマイグレーション
- システム更改の場合などに
- 使用性テスト
- アクセシビリティテスト
- ローカライゼーションテスト
-
セキュリティテスト
- 例: Nessus
- 移植性テスト
6.1.2 テスト自動化の利点とリスク
テスト実行を支援するツールを使う潜在的な利点
-
時間の節約
- 反復する手動作業の削減
- レビュー前に実装中に欠陥検出
- 一貫性や再実行性が向上する
- 評価の客観性が向上する
-
テストに関する情報へのアクセスの容易性が向上する
- 統計をとったりグラフ化したりするのが容易
テストを支援するツールを使う潜在的なリスク
- テストツールの効果を過大に期待する
-
時間、コスト、工数の過小評価
- テストツールを初めて導入するコスト
- 大きな効果を継続的に上げるために必要なコスト
- ツールの入出力のテスト資産をメンテナンスするために必要なコスト
-
ツールに過剰な依存をする
- 手動テストはなくならない
-
ツール内にあるテスト資産のバージョンコントロールを怠る
- アプリのどのバージョンと紐づくのか把握できなくなる
-
複数のツールの運用が適切になされない
- 相互運用性の問題が無視されがち
-
ツールベンダーに潜むリスクを想定しない
- 撤退したり売ったりするかも
-
ツール自体に潜むリスクを想定しない
- OSSプロジェクトが止まるかも
-
ツールに対する当事者意識が明確ではない
- 担当者は誰?
6.1.3 テスト実行ツールとテストマネジメントツールの特別な考慮事項
テスト実行ツール
テストスクリプトの作成やテストデータの作成に想定以上のコストがかかりがち
どうする?
テストをキャプチャ
手動テストの担当者の操作をそのまま記録
たいていそのままは使用せず、後述のアプローチで修正して完成させる
データ駆動方式
テストデータをスプレッドシート等で準備し、汎用にテストスクリプトに入力
例: ユーザーID/PWをスプレッドシートで入力して様々な権限のユーザでテスト
【所感】xUnitのdataProviderが近い
キーワード駆動方式
「画面のボタンを押す」「テキストボックスへ入力を行う」等をキーワード(アクションワード)化し、スプレッドシート等で準備し、汎用のテストスクリプトに入力
テストスクリプトに関する詳細な知識がなくてもテストケースを作成できる
【所感】BDDに近い
テストマネジメントツール
-
レポートを組織独自フォーマットに整形
- 【所感】XSLTとかでできそう
- ALMとの連携
等が必要になることがある