[B! テスト] takashi001のブックマーク

結合テストと総合テスト

ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます（図1）。テスト計画プロセスでは、テスト全体の指針や概要をまとめます。テストの目的、対象範囲、実施方法、テスト体制、テスト環境、スケジュール、合格基準など、テスト全般に関わる方針を「テスト計画書」にまとめ、ユーザを含むプロジェクトメンバー全員で方向性を共有します。テスト設計プロセスでは、策定されたテスト計画に基づいて、実際のテスト作業内容を設計します。テストのシナリオやテスト内容、確認すべき項目などを「テスト仕様書」に具体的に定義します。テスト実施者は、このテスト仕様書に基づいてテストを実施します。障害を発見した際は、障害番号を採番し、障害管理票に記載して残管理します。これらの障害が片づいて、テストが正常に行われた場合は「テスト報告書」で報告します。弊社

takashi001 2013/02/22

リンク

システム開発プロジェクト管理者の道具箱

開始条件要件定義の目的要件定義の担当者要件定義の方法要件定義の基になる資料要件の種類要件定義の確認要件定義書の項目要件定義書作成時の注意点要件定義の変更管理成果物終了条件

takashi001 2013/02/22

リンク

機能をモレなくテストするテンプレート

単体テスト仕様書兼報告書の使い方図2は「DUNGEON」のテンプレートの「単体テスト仕様書兼報告書」です。単体テスト仕様書兼報告書のフォーマットは、こちら（http://www.thinkit.co.jp/images/article/140/3/14031.zip）からダウンロードできます（14031.zip/42.7 KB）。当テンプレートの工夫点を挙げてみます。 1点目は前節で述べた詳細設計書との連携部分です。詳細設計書と別ファイルであるということは、同一ファイルの場合に比べて、作成時の工数増、テスト項目の漏れが発生するリスク増というデメリットがあります。しかし、詳細設計書から転記しやすいフォーマットにすることでそのデメリットを解消しているのです。構成として、詳細設計書の章立てごとにシートを分けています。なぜならチェックする内容ごとにシートのフォーマットが異なるからです。極力リ

takashi001 2013/02/22

テスト

リンク

結合テスト仕様書兼報告書のテンプレート

結合テストの範囲テストフェーズの続きとして、今回は「結合テスト」に焦点を当てます。一口に結合テストといっても、SIerによっては実施範囲が異なると思いますので、まずは本連載で想定している範囲を明確にしておきたいと思います。この実施範囲の差は何を「結合」するかという単位の違いによるものです。最小単位のプログラムを複数結合してテストするのか、それとも画面間の結合なのか、または業務手順の結合なのかということです。もちろんこの違いは、開発手法やシステム構成、開発言語、プロジェクト管理手法など、さまざまな要因によって決まるものですし、また、その単位でしかテストしないわけではなく、どこに重きを置くかの差でもありますので、一概にどれが正解とは言い切れません。今回紹介する「DUNGEON」テンプレートは、ウォーターフォールでの業務システム構築が守備範囲です。したがって本連載で説明する結合テストは、業

takashi001 2013/02/22

テスト

リンク

動的解析/単体テスト

近年のソフトウェア品質への要求の高まりから、ユニット単位での品質向上を目的とした「単体テスト」の実施が強く求められています。単体テストを行うことで、開発の早い段階で不具合の検出が可能になり、後工程での手戻りや修正コストが低減できるメリットがあります。しかし、「テストの実施工数が増える」という新たな課題も生まれます。 C/C++testでは、単体テスト時の課題であったテストケース作成のためのコーディング作業を大幅に削減できます。 C/C++testのテストケースエディターは、GUI操作のみで「テストケース」の作成や「スタブ」の生成、スタブの振る舞いの設定ができます。スタブコールバックフレームワークが実装されており、スタブ機能のフレームワークや、テストケースエディターのスタブ設定が、スタブごとの管理ができます。スタブAPIの独自記法の習得が不要となり、さらに複数のテストケースを共有できます。