ユーザーマニュアル
TestLink version 1.7
Copyright 2004 - 2007 TestLink Community
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. The license is available in "GNU Free Documentation License" homepage.
---
翻訳: Testing Engineer's Forum (TEF) - ソフトウェアテスト技術者交流会 -
「TEF有志によるTestLink日本語化プロジェクト」部会
---
1 一般情報
TestLinkはWebベースのテスト管理システムです。このマニュアルは、TestLinkを使用するために必要な操作手順、用語、構成などについて説明しています。インストール時に必要となる、システム要件、インストール手順、システム構成方法などは、インストールマニュアルをご参照ください。最新のドキュメントは、TestLinkフォーラム（www.teamst.org）または、SourceForge上のプロジェクトページ（testlink.sourceforge.net）からダウンロードすることができます。
（訳注: 日本語で書かれた情報については http://www38.atwiki.jp/testlink/ または http://sourceforge.jp/projects/testlinkjp をご参照ください。）
1.1. TestLinkコンポーネントの全体構造
TestLinkの基盤となるコンポーネントは３種類あります。それは、テストプロジェクト、テスト計画、そしてユーザです。これ以外の全てのデータは、この基盤要素の関連もしくは属性となります。それではまず始めに、この文書およびソフトウエアテスト分野で使用される用語について定義します。
1.2. TestLinkで使用する用語
テストケースは、TestLink上でのテスト作業を表す最小単位であり、ステップ（アクション、シナリオとも呼ばれます）と実行結果を含んでいます。
テストスイートは、テストケースをグループ化するための単位です。これにより、テスト仕様を論理的に分割することができます。
テストスイートは、TestLinkバージョン1.6以前にコンポーネントやカテゴリと呼ばれていたものに対応します。
テスト計画は、テストケースを実行する時に作成されます。テスト計画は、ひとつまたは複数のテストプロジェクト上のテストケースから構成されます。テストケースには、製品ビルド、マイルストーン、テストの割り当て、そしてテスト結果が含まれます。
TestLinkの起動中は、必ず１つ以上のテストプロジェクトが存在しています。テストプロジェクトは、いくつものバージョンに更新されていきます。テストプロジェクトには、テストケースが登録されたテスト仕様、要件仕様、キーワードが含まれます。プロジェクトに参加するユーザには役割が設定されます。
TestLinkのユーザには、TestLinkの機能を使用して定義された役割が与えられます。詳しくはユーザ管理の章をご参照ください。図1はユーザの役割に関連する一般的な作業を表しています。
1.3. TestLinkを用いた作業の流れの例
1. 管理者がテストプロジェクト「ファーストフード」を作成し、「リーダー」権限をもったAdamと、「テスト主任」権限をもったBelaとい2. リーダーであるAdamが、ソフトウェア要件をインポートし、空のテストケースを作成します。
3. テスト担当者であるBelaが各テストケースのステップ(テストシナリオ)を記述し、テストスイートを用いてそれらを分類します。
4. Adamはキーワード「回帰」を作成し、10種類のテストケースにアサインします。
5. Adamはテスト計画「フィッシュ & チップス」とビルド「フィッシュ 0.1」を登録し、キーワード「回帰」がアサインされたテストケースを登録します。
6. AdamとBelaはテストを実行し、5ケースで成功、1ケースで失敗、4ケースでブロックというように結果を記録します。
7. 開発者が新たなビルド「フィッシュ 0.2」を作成し、Belaが以前失敗もしくはブロックしたテストケースのみを実行します。これらのテストが成功したとします。
8. チームのマネージャもテスト結果を見たいことでしょう。ログインページでアカウントを追加できることを、管理者はマネージャに説明します。マネージャがアカウントを作成すると、デフォルトで「ゲスト」権限が与えられ、テストケースと実行結果を閲覧することができます。マネージャは、ビルド「フィッシュ 0.1」で問題があったことと、最終的に全てのテストケースが成功したことを確認できるでしょう。しかしながら、「ゲスト」権限しかないマネージャは、これらのデータを変更することはできません。
2. テスト仕様
TestLinkでは、テストケースの構造をテストスイートとテストケースに分解します。このレベルはアプリケーションを通して保持されます。
2.1. テストケースの作成
テスターは少なくともテストスイートとテストケースという構造に従わなければなりません。最初にテストプロジェクトに対して、ひとつか、それ以上のテストスイートを作成します。印刷に使用可能な説明を記述することができます。テストスイートは、別のテストスイートを含むことができます。
ユーザは、テストケースをコピーしたり、移動したりすることができます。
テストケースは次に示す部分を持っています。
タイトル：短い概要もしくは略号を含めることができます。(例：TL-USER-LOGIN)
要約：簡潔に、概要のようなもの
ステップ：テストシナリオを記述します（入力操作）、事前条件や事後処理に関する情報を含めることもできます。
実行結果：確認事項や、期待結果に関して記述します。
テストケース番号はTestLinkによる自動採番で、ユーザが変更することは出来ません。
このIDは、テストプロジェクトに関わらず、テストケースが作成されるとき、システム全体でグローバルなカウンタが使用されているのを意味します。
テストケース - 有効属性
もし、複数のバージョンのテストケースが存在する場合、有効/無効を示す新しい属性があったほうが親切です。これは次のように使われます。
すべでのテストケースは、有効として作成されます。無効なテストケースのバージョンは「テスト計画へのテスト計画の追加」では、利用できません。これは、テストデザイナーにとっては便利な機能です。彼らはテストケースのバージョンを編集し、テスト計画で利用可能になった時に、完了したと判断して、ステータスを有効に変更することができます。
一度、テストケースのバージョンがテスト計画に関連付けられ、結果を持つと、無効にすることはできなくなります。
次のことに注意してください。テストプロジェクト名（この例では、toaster_x15)のそばの数字は２ですが、テストプロジェクトは３つのテストケースがあります。これは、テストケース１が無効なためカウントされていないからです。
2.2. テストケースの削除
テストケースとテストスィートはテスト計画からリーダの権限を持っている場合には削除することができます。この操作はテスト計画を最初に作成して、まだ結果が何もない場合には有効です。しかしながら、テストケースの削除はひもづくすべての実行結果を失うかもしれません。このことから、極端な警告がこの機能を使用するために推奨されています。
2.3. 要件との紐付け
テストケースは、ソフトウエア要件、システム要件とｎ対ｎで関連付けられます。この機能は、テストプロジェクトで実現されています。ユーザは、テストケースと要件をメインメニューの要件の関連付けで割り当てることができます。
3.キーワード
3.1 キーワードを使う
キーワードは、テストケースの分類において、ユーザにもうひとつのレベルを提供する為の機能です。
キーワードはテスト仕様の中で何らかの特性をもつテストケースのコレクションをサポートし、
あなたはそれを定義する為に使う事ができます。
例:
回帰テストの為のセット
検討済みのテストケース
単一プラットフォームに向けたテストケース
3.2 キーワードの作成
キーワードはmgt_modify_key権限を持つユーザのみが作成できます。
この権限は、現在リーダーのみが持っています。ひとつ、あるいはキーワードの
グループが作成されたら、ユーザーはそれをテストケースに割り当てる事ができます。
3.3. キーワードの割り当て
テストケースへのキーワード割り当ては、キーワード割り当て画面[the assign keyword screen](一括)、
あるいはテストケース管理(個々)から行われます。
3.4. キーワードによるフィルタ
ユーザがキーワードによってフィルタ可能なもの:
テスト仕様書からテストケースを探す。
テストスイートにテストケースのグループを加える。
テストスクリーンを実行する。
4. 要件に基づくテスト
4.1 イントロダクション
テスターは、システムが仕様通りに作られていることを証明するために、
要件に基づくテストを行います。
全ての要件に対して複数のテストケースが設計されます。
テスト実行が終わると、テストマネージャーは、実行結果と要件の網羅度を報告します。
この情報に基づき、顧客とステークホルダーは、システムを
次のテストフェーズに移行、もしくは稼動させてもよいかを決定します。
システムが仕様通りに作られていることを保証するために、
テストマネージャーはリスクの組み合わせと要件に基づくテストを行います。
それは、システムが仕様通りに作られていることを、顧客とステークホルダー
に見えるようにするためのものです。
要件に基づくテストの優位性：
・ リスクと要件を結びつけると、曖昧さや要件もれが明確になります。
・ システムの最重要部分へ最初に焦点をあてられるので、優先度の高いリスクを
カバーすることができます。
・ 顧客やステークホルダーと同じ言葉でコミュニケーションできます。
そのため、テストプロジェクトの状態の報告がよりわかりやすくなるので
もっとテストするか、リスクをとるか、を判断しやすくなります。
・ リスクと優先度は納期の圧力のかかったテストプロジェクトでは交渉の対象になります。
リスクとは、テストプロジェクトで何をカバーする必要があって、何を
延期できるかということです。
リスクと要件に基づいたテストは、テストプロジェクトをより管理しやすくします。
顧客やステークホルダーとのコミュニケーションが改善されます。
テストマネージャはリスクと優先度に基づいたテストを始めます。
プロセスは合理化され、その結果、高品質の結果を得られます。
4.2. 有効性
機能を有効にするのはテストプロジェクトのレベルで行います。
すなわち、管理者はそのテストプロジェクトを有効にしなければなりません。
(メインウィンドウのテストプロジェクトのリンクを編集してください)
そうしないとリンクは見えません。
これは利用者レベルを分けるためのものです。
最も一般的な役割では、要件を見ることはできても変更はできません。
詳細はユーザ管理の章を参照してください。
4.3. 要件仕様
要件はいくつかのシステム／ソフトウェア／ユーザ要件仕様に
まとめられます。
要件文書の作成：
1. メインウィンドウの要件仕様をクリックします。
要件仕様リストのウィンドウが開かれます。
2. 文書を作成するために作成ボタンを押します。
3. 題名、スコープ、最終的なテストケースの数を書き換えます。
最後のパラメータは統計のために使われます。
もし、有効な要件文書があれば、それだけで使えますが、
入力した時点で TestLink の全ての要件が有効であるとは限りません。
デフォルト値 'n/a' は、仕様の中で現在までに使われた要件の
数を意味します。
<< 検討中 begin >>
3. 題名、スコープ、最終的な要件の数を書き換えます。
最終的な要件の数は統計のために使われます。
全ての要件を登録しないうちにTestLinkを実行する場合に使うものです。
最終的な要件の数が設定されない場合には、現在登録されている要件の
数が使われます。
<< 検討中 end >>
4. データベースにデータを追加するために作成ボタンを押します。
要件仕様リストのウィンドウの表の中に新しく作成した文書の題名が
表示されます。
5. 次の作業をするために文書の題名をクリックします。
要件仕様ウィンドウが開かれます。
各々の要件仕様は自分自身の統計値と
関係するデータが含まれたレポートを持っています。
"要件仕様" ウィンドウの全ての仕様は "印刷" ボタンを使って
印刷することができます。
管理者は定義ファイルの著作権と部外秘の表示で会社を定義できます。
4.4. 要件
個々の要件は、題名、スコープ(html 形式)、状態を持っています。
題名はユニークである必要はなく、最大半角100文字までです。
スコープパラメータはHTML 形式のテキストです。
状態は、有効(VALID)かテスト不可(NOT_TESTABLE)の値を持ちます。
テスト不可(NOT_TESTABLE)の要件は測定には含まれません。
要件はCSVファイルのインポートやTestLink インターフェース経由で
手動で生成、修正、削除できます。
4.4.1. 要件のインポート
TestLink は２タイプの CSV 形式をサポートしています。
一つめのシンプルタイプは、各行に題名とスコープを含みます。
二つめの 'Doors' からエクスポートするタイプでは、ヘッダと
選択された完全なフィールドを見つけようとします。
題名をインポートしてから比較して、衝突を回避します。
二つ目のタイプでは、以下の３つの方法が選択できます。
・同じ題名の要件をインポートして更新する。
・同じ題名の要件をインポートして新しいものを作成する。
・同じ題名の要件はインポートしないようにする。
4.4.2. 要件とテストケースとの関係
テストケースはソフトウェア／システムの要件と多対多で関連づけられます。
すなわち、いくつものテストケースを一つの要件に割り当てたり、
複数の要件を一つのテストケースでカバーすることができます。
ユーザはメインウィンドウの割り当て要件リンク経由で
要件をテストケースに割り当てられます。
テスト仕様のカバレッジは、要件仕様ウィンドウの解析ボタンを
押すことで見ることができます。
4.4.3. 要件に基づく報告
「テストレポートとメトリクス」メニューに移動すると
要件に基づいた各種報告のリンクが表示されます。
現在の要件仕様の要件とテスト計画は、この報告で解析されます。
全テストケースの最新結果(テスト計画で有効な)は
個々の要件にも反映されます。
異なる結果が一つの要件に適用されるような場合は
優先順位の高い結果が適用されます。
優先順位は、上から失敗、ブロック、未実行、パスの順です。
要件カバレッジの例
要件は三件のテストケースでカバーされている。
これらの二つは現在のテストスイートに含まれている。
ビルド１では、一つはパスして、もう一つは未テストである。
現在の要件の全体の結果：未実行。
ビルド２で二つめのテストケースがテストされてパスした場合は
要件に適用される結果はパスとなる。
5. テストプロジェクト
テストプロジェクトはTestLinkの基礎です。あなたの会社のリリース版テストプロジェクトは、時間がたつにつれてそれらの特徴や機能に変更がありますが、ほとんどが同じまま残ります。
テストプロジェクトは要件ドキュメンテーション、テスト仕様書、テスト計画、そしてキーワードを含んでいます。
5.1. 新規テストプロジェクトの作成
新規テストプロジェクトの作成は"管理者"権限を必要とします。各テストプロジェクトの名前は重複しないようにする必要があります。目視によりそれらを区別するために背景色をテストプロジェクトテンプレートに割り当てることができます。
新規プロジェクトを作成するとき注意すること:
たくさんのテストケースが孤立する、またはテストケースがシステムから削除されてしまうので、システムからテストプロジェクトを消すことは推奨しません。
テスト計画はある一定の時点におけるテストプロジェクトのテストを表します。その結果、テスト計画はテストプロジェクト上のテストケースから生成されます。
TestLinkはテストプロジェクトにCSVデータのインポートをすることをサポートしています。これは後述のインポートのセクションでより詳しく説明します。
5.2. テストプロジェクトの編集と削除
テストプロジェクトの編集は"管理者"権限を必要とします。ユーザは、テストプロジェクト名、背景色、要件管理機能の有効性の変更が可能です。
特権を持つユーザは、使われなくなったテストプロジェクトを無効にさせることもできます。これにより、無効なテストプロジェクトはトップナビゲーションバー上のリストに表示されなくなります(ただし、管理者の場合、このようなテストプロジェクトは、リストに'*'のマークがついた状態で表示されます)。
ユーザはテストプロジェクトの削除も可能です。この行為は、データベースからすべての関連データをも削除します。この行為は元に戻せません。削除の代わりに無効にすることを強くお勧めします。
6. テスト計画
テスト計画は、名称、説明、選出したテストケースの収集、ビルド、テスト結果、マイルストーン、テスターの割り当て、優先度の定義を含んでいます。
6.1. 新規テスト計画の作成
テスト計画はリーダー権限を持ったユーザにより、“テスト計画作成”ページ(“テスト計画作成”リンク)から作成できます。
テスト計画はテストケース実行の基礎です。テスト計画は、特定の時点においてTestプロジェクトからインポートされたテストケースで作られます。テスト計画はリーダー権限を持ったユーザのみ作成可能です。他のテスト計画からテスト計画を作成することも可能です。これで、ユーザは必要になった時点でのテストケースからテスト計画を生成します。パッチのためのテスト計画を作成するとき、これが必要となるかもしれません。ユーザがテスト計画を見るためには、適当な権限を持たねばなりません。権限は(リーダーにより)ユーザ定義/プロジェクト権限のセクションで割り当てることができます。ユーザにプロジェクトが見られないと言われたとき、このことを思い出してください。それくらい重要なことです。
6.2. ビルド
リーダー権限を持ったユーザは、メインページの“ビルドの管理”リンクをたどることが可能です。
ビルドはソフトウェアの特定のリリースです。会社における各プロジェクトは、たぶん多くの異なったビルドで構成されています。TestLinkでは、実行はビルドとテストケースの両方で構成されます。もしプロジェクトにひとつもビルドを作成していなければ、実行画面はあなたに実行を許可しないでしょう。また、メトリクス画面は完全に空白になるでしょう。
現在、ビルドは編集できません。現存のビルドの表にある“ゴミ箱”アイコンをクリックすることでビルドを削除することができます。
6.3. テスト計画の削除
テスト計画はリーダー権限を持ったユーザにより削除できます。テスト計画を永久に削除すると、テスト計画と、テストケースやテスト結果など対応するデータのすべてとが、両方とも削除されます。これは特別なケースのためだけにとっておくべきです。 代わりに、テスト計画は同ページ上で無効にさせる(“メイン” ページの選択メニュー上に表示しないようにする)ことが可能です。
7. テスト計画に実装されているもの
7.1. 新規テストケースの追加
ステップと期待結果が含まれたテストケースが追加されます。
複数のテストプロジェクトからのデータを1つのテスト計画に追加することができます。キーワード(ナビゲーションシートで調整される)でテスト仕様書データをフィルターにかけることができます。
データがいったんテスト計画にリンクされると、それはチェック印でマークされるでしょう。既にテストケースをインポート済みであれば、再びそれをインポートしようとしても、それを無視するでしょう。
7.2. テスト計画からテストケースを削除する
"テストケースの削除"ページから、リーダー権限を持つユーザは、テスト計画からテストケースとテストスイートを削除することができます。結果が保存されていないため、初回のテスト計画作成のときには、データの削除も役に立ちます。しかしながら、テストケースを削除することは、それらに関連しているすべての結果の損失をもたらすでしょう。したがって、この機能を使用するときには、極度に用心することをお勧めします。
左側のシートのツリーで、テスト計画における現在のテストケースだけを表示します。
7.3. 優先度
TestLinkはテストケースのオーナーシップと優先度を割り当てる能力をリーダー権限を持ったユーザに与えます。一般的なリスクはテストスイートレベルで行われます。
リスクレベルは low, medium, high そして重要度は 3, 2, 1 です。ユーザは優先度 A,B,C としてリスクと重要度(L1, L2, L3, M1, H2, M3, H1, H2, H3)の組み合わせを格付けすることができます。
リスク、重要度、オーナーシップ、および優先度を割り当てるのは、すべて任意であり、メトリクス画面では優先度Bをデフォルトとするでしょう。
7.4. テスト実行の割り当て
テスト実行の割り当ては実行とメトリクス画面の両方に影響します。実行画面では、ユーザが割り当てられたことにより実行可能なテストケースをソートする機能を持っています。メインメトリクス画面には、テスト担当者が残しているテストケースを示すテーブルがあります。もしテスト担当者に割り当てられたテストケースが無ければ、デフォルトでは何もありません。
また、これらのメトリクスが有効にされるなら、テスト担当者はメインページにおいて、自分が実行したテストのメトリクスを見ることができます(インストールマニュアル参照)。
8. テストの実行
8.1. 概要
テストの実行は以下の条件が満たされると有効になります。
1.テスト仕様が作成された。
2.テスト計画が作成された。
3.テスト計画にテストケースが追加された。
4.ビルドが作成された。
5.テスト計画がテスターに割り当てられた(割り当てがされなければテスターはテスト計画のページに移動することはできません）。
メインページで要求されたテスト計画を選択して、'テストの実行'リンクをクリックします。左画面がツリー画面で表示され、テストケーススイートの設定ができます。ここではフィルタリングやビルドの定義ができます。
8.2. ナビゲーション
ナビゲーション画面は'フィルタ＆設定'とテストケーススイートが表示されたツリー型のメニューから構成されます。
8.2.1. テストケースのフィルタリング
このテーブルでは洗練されたナビゲーションを通して、テストの実行前にユーザーがテストケースをフィルタリングできます。
テスタ: テスタでテストケースをフィルタリングします。
キーワード: キーワードでテストケースをフィルタリングします。テストケースの作成・編集・削除時かあるいは”キーワードの割り当て”で複数のテストケースにキーワードを割り当てます。キーワードはテストリーダにより作成・編集・削除できます。それぞれのテスタはキーワードの割り当てができます。
結果: 結果でテストケースをフィルタリングします。「結果」はテストケースの実行時にそのビルドで何が発生したかを示します。結果は次のいづれかです。成功・失敗・ブロック・実行されてない。
8.2.2. テストビルドの定義
ビルドでテストケースをフィルタリングします。ビルドはテストの追跡をするための基本の構成になります。それぞれのテストケースは一つのビルドにつき一回実行されます。ビルドはテストリーダにより”新しいビルドの作成”ページで作成されます。
8.2.3. ツリー型メニュー
ツリー型メニューは結果により色分けされてテストケースを表示します。
色付けされたメニュー: デフォルトではツリーはドロップダウンボックスで選択されたビルドに対して、結果でソートされています。.
ビルドによる色付けされたテストケースの例
ユーザはビルド2をドロップダウンボックスから選択し、"最近"チェックボックスを有効にしていません。ビルド2からのすべてのテストケースがその状況とともに表示されます。もしテストケース1がビルド2で成功しているならば、緑で表示されます。
”最終結果”はメニューを最近のテスト結果により色付けします。
最近のテスト結果により色づけされたテストケースの例
ユーザはビルド2をドロップダウンボックスから選択し、"最近"チェックボックスを有効にしています。ビルド2からのすべてのテストケースがその最新状況とともに表示されます。もしテストケース1がビルド3で成功しているけれども、ユーザがビルド2を選択している場合には、緑で表示されます。
8.3. 実行
8.3.1. テストステータス
テスト実行は、結果（成功、失敗、ブロック）を特定のビルドのテストケースに割り振リます。'ブロック'されたテストケースは何らかの理由によりテストすることができません（例 構成の問題より機能的なテストを実行できないなど）。
8.3.2. テスト結果の挿入
テスト結果の画面は、適当なテストスイートもしくはテストケースをナビゲーション画面でクリックすることで表示されます。タイトルに現在のビルドとオーナーが表示されます。色づけされたバーはテストケースのステータスを示します。黄色はテストケースのテストシナリオを含みます。
Version1.5ではテスト仕様のテストケースが更新されたか削除されたかの表示機能はサポートされていません。
更新されたテストケース: TL1.0.4ではフラグにより表示されましたが、Version1.6ではこの機能がありません。ユーザが適切な権限を持っていれば、メインページから"テストケースの更新”ページに移動することができます。
もし変更があった（新しいバージョンであるか、削除された）場合、ユーザがテストケースを更新する必要はありません。
9. カスタムフィールド
カスタムフィールドはシステムレベルで定義をします。例）カスタムフィールドを同じフィールドＩＤで定義することはできません。カスタムフィールドを作成した後に、使用したいテストプロジェクトへ割り当てる必要があります。これはMantisモデルに基づきます
カスタムフィールドはMantis(http://www.mantisbt.org/)とdotproject(http://www.dotproject.net/)の両方のモデルの機能を使って実装されています。
表示/変更属性
デザイン時の表示:
カスタムフィールドがテストケース仕様で表示されます。
デザイン時の変更:
ユーザはテストケース仕様でカスタムフィールドの値を割り当て・変更できます。
実行時の表示:
カスタムフィールドはテストケースの実行時に表示されます。
実行時の変更:
ユーザはテストケースの実行時にカスタムフィールドの値を割り当て・変更できます。
割り当てられた値は保存されます。
例 1.
カスタムフィールド : 追加備考
型 : string
テストスイートで利用できます。編集はテストケース仕様でのみできます。
ただしテスト実行時に表示されることで役に立てます。
デザイン時の表示 = YES
デザイン時の変更 = YES
実行時の表示 = YES
実行時の変更 = NO
例 2.
カスタムフィールド : オペレーションシステム
型 : list
テストケースで利用できます。テストケースデザインでない場合には、テストケースの実行時のみ編集できます。
デザイン時の表示 = NO
デザイン時の変更 = NO
実行時の表示 = YES
実行時の変更 = NO
10. テストレポートとメトリクス
レポートとメトリクスはメインページの"結果"または"テストレポートとメトリクス"をクリックすることにより表示することができます。レポートとメトリクスは現在選択されているテスト計画を対象にしており、複数のテスト計画を対象にすることは現バージョンではできません。結果ページを表示する前にメインページで対象とするテスト計画が選択されているか確認してください。ユーザーに表示されるページは左枠と右枠のページで構成されています。
左枠のページからどのようなレポートを実行して表示するか選択することができます。
右枠のページには各レポート毎の説明と使用方法が表示されます。
左枠のページからは次の項目を設定することができます。
アクティブビルド
"アクティブビルド"の項目を設定によって影響を受けるレポートは"アクティブビルドのメトリクス"レポートのみです。このレポートは設定されたビルドを元に現在のテスト計画の状態を表示します。
レポートフォーマット
チャートを除く全てのレポートは次のいずれかの形式で表示させることができます：
1."normal" - ブラウザにレポートが表示されます
2."MS Excel" - Microsoft Excel形式でレポートがエクスポートされます
3."HEML Email" - ユーザーのメールアドレスにレポートが送信されます
現バージョンでは左枠から10種類のレポートを選択することができます。各レポートの目的や機能を以下に説明します。
10.1. アクティブビルドのメトリクス
"アクティブビルド"に設定されたビルドの詳細な結果を表示します。このレポートは選択されたビルドで実行された結果のみ表示します。
レポートは結果を次の様なテーブルで表示します：
最上位のテストスイートごとの結果
ツリーの最上位のテストスイートごとに結果を表示します。テストケース数、成功、失敗、ブロック、未実行の合計と完了したテストケースの完了率が表示されます。完了したテストケースとは成功、失敗、ブロックのいずれかの結果が設定されたテストケースを指します。テストスイートに表示されている結果にはそのテストスイート内のテストスイートの結果も含まれています。
テストスイートごとの結果
ツリーの最上位のテストスイートだけでなく、テスト計画の全てのテストスイートごとにメトリクスを表示します。
キーワードごとの結果
テスト計画のテストケースに割り当てられているキーワードごとに結果を表示します。
10.2. 一般的なテスト計画のメトリクス
このレポートはテストスイート、オーナー、キーワードごとにテスト計画の最新の状態を表示します。テスト計画の最新の状態とは、最も新しいビルドで実行されたテストケースで構成されます。例として、あるテストケースがいくつものビルドでテストされていた場合、最も新しいテスト結果が反映されます。最新のテスト結果を反映することは他の多くのレポートにも共通する概念です。最新のテスト結果は次のようにして決定されます。
1)テスト計画に反映されるビルドの優先順位はビルドの新旧によって決定します。より新しいビルドのテスト結果が古いビルドのテスト結果よりも優先されます。例として、あるテストケースのテスト結果がビルド1では"失敗"となっていたが、ビルド2では"成功"だった場合、最新のテスト結果は"成功"となります。
2)同じビルドでテストが幾度か実行された場合は、より新しいテスト結果が優先されます。例として、ビルド3がリリースされ、あるテスト担当者がビルド3のテスト結果を"成功"と設定し、後に別のテスト担当者が同じビルドのテスト結果を"失敗"と設定した場合、最新のテスト結果は"失敗"となります。
3)ビルドに対するテスト結果が"未実行"となっているテストケースは最新のテスト結果には反映されません。例として、ビルド1のテスト結果が"成功"となっておりビルド2のテスト結果が"未実行"となっていた場合、最新のテスト結果は"成功"となります。
次のようなテーブルが表示されます。
最上位のテストスイートごとの結果
最上位のテストスイートごとに結果を表示します。テストケース、成功、失敗、ブロック、未実行の合計と完了したテストケースの完了率が表示されます。完了したテストケースとは成功、失敗、ブロックのいずれかの結果が設定されたテストケースを指します。テストスイートに表示されている結果にはそのテストスイート内のテストスイートの結果も含まれています。
キーワードごとの結果
テスト計画のテストケースに割り当てられているキーワードごとに結果を表示します。
例：
|キーワード|合計|成功|失敗|ブロック|未実行|完了率 [%]|
|P3|1128|346|47|55|680|39.72|
|P2|585|372|25|31|157|73.16|
|P1|328|257|6|51|14|95.73|
オーナーごとの結果
テスト計画のテストケースに割り当てられているオーナーごとに結果を表示します。オーナーが割り当てられていないテストケースは"未割り当て"という行に反映されます。
例：
|テスト担当者|合計|成功|失敗|ブロック|未実行|完了率 [%]|
|Dominika|579|217|34|47|281|51.47|
|Mohammad|246|82|9|2|153|37.80|
|未割り当て|35|19|0|1|15|57.14|
|Ken|289|110|1|21|157|45.67|
|Mallik|430|269|5|18|138|67.91|
|Ali|227|123|28|13|63|72.25|
|Mike|24|22|0|0|2|91.67|
|Alex|272|155|1|36|80|70.59|
10.3. 全てのビルドの状態
全てのビルドのテスト結果を表示します。各ビルドごとにテストケース、成功、失敗、ブロック、未実行の合計とその割合が表示されます。テストケースを同じビルドで何度かテストしていた場合は、最も新しいテスト結果が反映されます。
10.4. メトリクスの抽出
このレポートはメトリクスの抽出条件を入力するページと抽出された結果を表示するページで構成されています。
抽出条件ページ：
抽出条件ページには4つの項目があります。各項目はデフォルトで全てのビルドとテストケースを抽出対象にするようアイテムが選択されています。抽出条件を変更することにより特定のオーナーやキーワード、テストスイート、ビルドの結果といった任意のレポートを作成することができます。
キーワード
任意のキーワードを選択することができます。デフォルトではキーワードは選択されていません。キーワードが選択されていない場合、キーワードが割り当てられているかに依存せず全てのテストケースが抽出対象になります。キーワードはテスト計画ページや、キーワード管理ページからアサインすることができます。テストケースにアサインされたキーワードは全てのテスト計画やテストケースのバージョンに反映されます。特定のキーワードについての結果を抽出したい場合はこの項目を変更してください。
オーナー
オーナーを選択することができます。デフォルトではオーナーは選択されていません。オーナーが選択されていない場合、オーナーのアサインに依存せず全てのテストケースが抽出対象になります。現バージョンではオーナーが"未割り当て"のテストケースを検索することはできません。オーナーシップは"テスト実行の割り当て"ページやテスト計画でアサインすることができます。特定のテスト担当者の進捗を確認した場合はこの項目を変更してください。
最上位のテストスイート （複数選択することができます）
最上位のテストスイートを選択することができます。デフォルトでは全てのテストスイートが選択されています。選択されたテストスイートのみ抽出対象になります。特定のテストスイートについての結果を抽出したい場合はこの項目を変更してください。
ビルド （複数選択することができます）
ビルドを選択することができます。デフォルトでは全てのビルドが選択されています。選択されたビルドによって実行されたテストケースのみメトリクスの抽出対象になります。例として、過去3つのビルドによってどのくらいのテストケースが実行されたか確認したい・・・等の場合はこの項目を変更してください。
キーワード、オーナーおよびテストスイートの選択によりテスト計画からテストケースの数が決定されます。この選択はテストスイートやテスト計画ごとのメトリクスを計算するために使われます。例として、オーナーに"Greg"、キーワードに"Priority 1"を設定し、全てのテストスイートを選択した場合はGregにアサインされたPriority 1のテストケースが抽出対象になります。レポートに表示されるテストケースの合計はこれら3つの項目により計算されます。
どのビルドを選択するかはメトリクスに表示されるテスト結果（成功、失敗、ブロック、未実行）に影響を与えます。詳細については前述されている"最新のテスト結果"の箇所を参照してください。
"クエリー送信"ボタンを押して抽出を開始し、結果を表示します。
抽出結果ページ：
抽出結果ページは次の項目を表示します：
1. レポート作成に設定された抽出条件
2. テスト計画全体の総計
3. テストスイートごとの総計（テストケース、成功、失敗、ブロック、未実行の合計）と実行結果。テストケースが複数のビルドで実行されていた場合、選択されたビルドの全ての実行結果が表示されます。しかし、テストスイートの概要は選択されたビルドの最新のテスト結果のみ表示します。
10.5. ブロック、失敗、実行不能テストケースレポート
これらのレポートは現在のブロック、失敗、実行不能テストケースの全てを表示します。
“最近のテスト結果”ロジック(全体テスト計画メトリクスに基づいて表現された)は
ブロック、失敗、実行不能と判断されたテストケースを採用しないようにします。
ブロック、失敗、実行不能テストケースレポートはユーザが統合バグトラッキングシステムを使用している場合
同類のバグを表示します
10.6. テストレポート
各々のビルドの各々のテストケースのステータスを見ます。
もしテストケースがなんども同じビルドで実行されたとすれば、
最新の実行結果を使うでしょう。このレポートの“?”は
このビルドでは実行不能テストケースを知らせます。
大きいデータセットを使用している場合はより簡単に眼を通せるようにExcelフォーマットでこのレポートを
エクスポートすることをお勧めします。
10.7. チャート
このレポートページはブラウザにFlashのプラグインが必要になります。
Flashはhttp://www.maani.usから提供されており、結果を図式的なフォーマットで表示するために使用します。
“最近のテスト結果”ロジックはあなたの閲覧できる全部で４つのチャートで使用されます。
グラフはユーザを現在のテスト計画のメトリクスを視覚化し補助するために動画で表示されます。
提供している4つとは :
1.全体のパス/失敗/ブロック/実行不能 テストケースの円グラフ
2.キーワードによる結果の棒グラフ
3.オーナーによる結果の棒グラフ
4.トップレベルスイートによる結果の棒グラフ
棒グラフの棒はユーザがパス、失敗、ブロック、実行不能ケースののおおよその数が見分けられる様に
おのおの彩色されています。
10.8. 各々のテストケースのバグ総計
このレポートは全てのバグがファイルされた全体のプロジェクトの各々のテストケースを表示します。
このレポートはバグトラッキングシステムを接続している場合にのみ使用可能です。
12 ユーザ管理
12.1 アカウントの設定
すべてのユーザはアカウント設定ウインドウ(メニューバーの中の"Personal")から、
自分自身の情報を編集する事ができます。TestLinkはadministrator権限を持つ
ユーザに対して、ユーザの作成、編集、削除を許可しますが、参照、ユーザパスワードの
変更は許可されません。もし、ユーザがパスワードを忘れた場合は、ログイン画面の
上部にあるリンクから、ユーザ名と登録したメールアドレスを入力すればそのアドレスへ
パスワードが送付されます。
11.2. 役割と権限
TestKinkには6つの異なったデフォルトパーミッションレベルが用意されています。
これらの権限は管理者がアクセスできる”the user administration”で変更できます。
パーミッションレベルは下記のとおりです:
Guest: テストケースとプロジェクトメトリクスの参照のみ行えます。
Test Executor:彼らに割り当てられたテストを実行する事のみ可能です。
Test Designer:テスト仕様書および要求全てに働きかける事ができます。
Test Analyst:テストの作成、編集、削除、およびそれらを実行する事ができます。
テスト計画の管理、テストプロジェクトの管理、マイルストーンの作成や権限の移譲は行えません。
Test Leader:これまでの全ての権限を持ち、さらにテスト計画の管理、権限の移譲、マイルストーンの作成、
キーワードの管理が行えます。
Admininstrator:これまでの全ての権限を持ち、さらにテストプロジェクトの管理が行えます。
注意: テスト計画に関連する機能は、もれなく作成済みのテス計画にアサインされる必要があります。
詳しくは、テスト計画のアサインの項をご参照ください。
11.2.1. 役割
TestLinkには規定の役割が存在します。管理者はシステムの中でデータを編集する適切な権限を付与します。それぞれのユーザに対して、これらの役割のひとつを割り当てます。下記のテーブルは、横の列にそれぞれの役割 (guest ,tester, senior tester, leader, admin)、次のカラムにそれぞれ異なる権限レベルを参照できます。これらのレベルは規定のものですが、自由に編集したり、新しい役割を定義する事もできます(熟練した管理者向け)。ユーザーテーブルは、役割の適切な権限レベルを指し示す外部キーを含んでいます。
Role|List of Rights|Permissions
Guest|mgt_view_tc, mgt_view_key, tp_metrics|データの参照のみ
Test Executor(Tester)|tp_execute,tp_metrics|テストの実行のみ
Test Analyst(Senior Tester)|tp_execute, tp_metrics, tp_create_build,mgt_view_tc, mgt_modify_tc, mgt_view_key,mgt_view_req|テストの編集,テストの実行, ビルド生成
Test Designer|tp_metrics, mgt_view_tc, mgt_modify_tc, mgt_view_key, mgt_modify_req, mgt_view_req|テストと要求の編集
Test Leader|tp_execute, tp_create_build, tp_metrics, tp_planning, tp_assign_rights, mgt_view_tc, mgt_modify_tc, mgt_view_key, mgt_modify_key, mgt_view_req, mgt_modify_req|テスト計画に関するすべての権限, テストの編集と実行
Admin|tp_execute, tp_create_build, tp_metrics, tp_planning, tp_assign_rights, mgt_view_tc, mgt_modify_tc, mgt_view_key, mgt_modify_key, mgt_view_req, mgt_modify_req, mgt_modify_product, mgt_users| 全ての事が可能. この役割だけが、ユーザとプロジェクトをメンテナンスできる
Table 1: Role description
11.2.2. 役割の定義
次のテーブルは、役割の定義に使われたキーワードのリストです。
Right|Description
mgt_view_tc|テスト仕様の参照 (data of Component, Category, and test case)|
mgt_modify_tc|テスト仕様の編集 (create,modify,delete,order, move, and copy Components, Categories, and test cases)
mgt_view_key|キーワードの参照
mgt_modify_key|キーワードの変更
mgt_modify_product|テストプロジェクトの生成、編集、削除
mgt_view_req|要求の参照
mgt_modify_req|要求の生成、編集、削除、紐付け
Table 2: Test project related Rights
Right|Description
tp_execute|テストケースを実行する権限 (テスト結果の挿入)
tp_create_build|ビルドを生成する権限
tp_metrics|メトリクスの参照
tp_planning|テストプランの生成、編集、削除、リスクとオーナーシップ、マイルストーン、テストスイートの割り当て
tp_assign_rights|プロジェクト参照権限の割り当て
Table 3: Test Plan related Rights
11.3. テスト計画の割り当て
ユーザは割り当てられたテスト計画だけを見られます。
テスト計画の権限を得る為には、リーダー権限か、管理者権限を持つユーザが彼らに"ユーザ定義/プロジェクト権限"を通して、"テスト計画管理"にて権限を与える必要があります。
システムのすべてのユーザーが、新しくつくられたテスト計画を見るための権限をデフォルトで持っているというわけではありません（彼ら自身に権限を与えることの出来るテスト計画者を除いては）
テスト計画の権限が0と言うことは、そのユーザはメイン画面にあるテスト計画ドロップダウンボックスのどんなテスト計画も見られないことを意味します。
テスト計画権限のテーブルにそれらはあります（すなわち、どのユーザがどのテスト計画を見ることが出来るかが分かります）。
このテーブルはユーザIDとプロジェクトIDが結合して作られます。
メインページには、ログインしたユーザに適切な権限があるかどうかチェックするコードが含まれます。
（そして許可されたプロジェクトを表示します。これを切ることは薦められません）
12. データのインポートとエクスポート
TestLinkはデータを共有するいくつかの方法をサポートします。
項目
ファイルフォーマット
あなたが得るもの
キーワード
CSV
XML
全てのテストプロジェクトのキーワード
テストプロジェクト
XML
全てのテストスイートとテストケース
あなたは割り当てたキーワードもまた、エクスポートするかどうか選ぶことができます。
テストスイート
XML
テストスイートの詳細、全てのテストケース、子となるテストスイートとテストケース
あなたは割り当てたキーワードをエクスポートするかどうか選ぶことができます。
テストケース
XML
2種類のエクスポートが可能です。
- 1つのテストケースだけ
- テストスイートにある全てのテストケース
あなたは割り当てたキーワードをエクスポートするかどうか選ぶことができます。
要件
CSV
CSV DOORS（※）
XML
（※）このフォーマットではインポートしかサポートしていません。
テーブル4：項目はインポート/エクスポートの両方ができます。
制限：添付ファイルはエクスポートできません。
12.1. キーワードのインポート/エクスポート
CSV形式の例 “キーワード;備考”:
Klyngon;Klyngon keyword notes
Moon rocks;Moon rocks keyword notes
XML形式の例 キーワード:
<?xml version="1.0" encoding="UTF-8"?>
<keywords>
<keyword name="Klyngon">
<notes>
<![CDATA[Klyngon keyword notes]]>
</notes>
</keyword>
<keyword name="Moon rocks">
<notes>
<![CDATA[Moon rocks keyword notes]]>
</notes>
</keyword>
</keywords>
12.2. テスト計画のインポート/エクスポート
ユーザは計画の記述、テスト仕様とキーワードを含むテスト計画をインポート、
またはエクスポートすることができます。
次の２つの説明はツリーメニュー状データと同じデータのXMLファイルです。
<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="">
<details><![CDATA[]]></details>
<testsuite name="Communications">
<details><![CDATA[<p>Communication Systems of all types</p>]]></details>
<testsuite name="Handheld devices">
<details><![CDATA[]]></details>
<testcase name="10 G shock">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
<testcase name="Gamma Ray Storm">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
</testsuite>
<testsuite name="Subspace channels">
<details><![CDATA[<p>Only basic subspace features</p>]]></details>
<testcase name="Black hole test">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
</testsuite>
</testsuite>
<testsuite name="Holodeck">
<details><![CDATA[]]></details>
<testcase name="Light settings">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
</testsuite>
<testsuite name="Propulsion Systems">
<details><![CDATA[]]></details>
<testsuite name="Main engine">
<details><![CDATA[]]></details>
<testcase name="Emergency stop">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
</testsuite>
</testsuite>
</testsuite>
12.3. テストスイートのインポート/エクスポート
キーワードを除いたテストスイートのXML出力例
<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="Handheld devices">
<details><![CDATA[]]></details>
<testcase name="10 G shock">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
<testcase name="Gamma Ray Storm">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
</testsuite>
キーワードを含むテストスイートのXML出力例
<?xml version="1.0" encoding="UTF-8"?>
<testsuite name="Handheld devices">
<details><![CDATA[]]></details>
<testcase name="10 G shock">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
<keywords>
<keyword name="Klyngon">
<notes><![CDATA[Klyngon keyword notes]]></notes>
</keyword>
</keywords>
</testcase>
<testcase name="Gamma Ray Storm">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
<keywords>
<keyword name="Klyngon">
<notes><![CDATA[Klyngon keyword notes]]></notes>
</keyword>
<keyword name="Moon rocks">
<notes><![CDATA[Moon rocks keyword notes]]></notes>
</keyword>
</keywords>
</testcase>
</testsuite>
12.4. 単独のテストケース
XMLファイルの例:
<?xml version="1.0" encoding="UTF-8"?>
<testcases>
<testcase name="Black hole test">
<summary>
<![CDATA[<p>This procedure must be done once a week, with this safety device disabled:</p>
<ol><li>X45HH</li><li>YY89-000-JI</li></ol>]]>
</summary>
<steps><![CDATA[
<p>Preset bias to 0</p>
<p>Enable <strong>long range</strong> communications control</p>
<p>Simulate black hole interference</p>]]> </steps>
<expectedresults><![CDATA[
<table width="200" cellspacing="1" cellpadding="1" border="1">
<caption>Main Results</caption>
<tbody>
<tr><td>Spin value</td><td>9.9</td></tr>
<tr><td>Opposite Angle</td><td>18 rad</td></tr>
<tr><td> </td><td> </td></tr>
</tbody>
</table>]]>
</expectedresults>
<keywords>
<keyword name="Moon rocks">
<notes><![CDATA[Moon rocks keyword notes]]></notes>
</keyword>
</keywords>
</testcase>
</testcases>
12.5. テストスイート中のすべてのテストケース
<?xml version="1.0" encoding="UTF-8"?>
<testcases>
<testcase name="10 G shock">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
<testcase name="Gamma Ray Storm">
<summary><![CDATA[]]></summary>
<steps><![CDATA[]]></steps>
<expectedresults><![CDATA[]]></expectedresults>
</testcase>
</testcases>
12.6. ソフトウェア要求仕様のインポート/エクスポート
CSVファイルは“ドキュメントID, タイトル, 詳細”が含まれます。
CSVファイルの例:
ENG-0001,Terrestrial Propulsor,
ENG-0002,Main Deflector,"<p>Main deflector bla, bla, bla.</p>"
XMLファイルの例:
<?xml version="1.0" encoding="UTF-8"?>
<requirements>
<requirement>
<docid><![CDATA[ENG-0001]]></docid>
<title><![CDATA[Terrestrial Propulsor]]></title>
<description><![CDATA[]]></description>
</requirement>
<requirement>
<docid><![CDATA[ENG-0002]]></docid>
<title><![CDATA[Main Deflector]]></title>
<description><![CDATA[<p>Maindeflector bla, bla, bla.</p>]]></description>
</requirement>
</requirements>
Revision History:
#
Description
Date
Author
0.x
Documents for TL 1.5 and update for TL 1.6
2005
M. Havlat
A. Morsing
F. Mancardi
1.0
Converted to OO2 format;
2005/03/12
M. Havlat
1.1
Minor update; FIX 372, 352
2006/02/14
M. Havlat
1.2
Updated as draft for TL 1.7
2006/11/17
M. Havl?t
1.3
Removed TL 1.6 terms
Added initial information about Custom Fields
2007/03/01
F. Mancardi
1.4
Added content and updated Franciscos “jumpstart_manual” and tl_file_format.
General style cleanup and update.
2007/09/06
M. Havl?t
最終更新：2007年11月26日 23:41
