OREO
koreo****@gmail*****
2009年 4月 2日 (木) 19:01:54 JST
あきぴーさん 返信ありがとうございます。 年度末でバタバタしていて、ご報告が遅れました。 こちらもxUnit系でUnitTestやっていますのでUTを登録する気はもともとありません。 TestLinkは基本Scenario Based Testなので、System Test向けですね。 とはいっても、Test実行結果の管理や、仕様書作成ということで、remoteTestLink などのツールを利用して、UT codeのXMLを をTestLinkにImportしています。 ＞しかし、テストケースは粒度に関係なく、事前条件＋テスト手順＋事後条件のフォーマットに統一できるだろうと思います。 それはそのとおりなのですが、こちらの質問の意図が伝わらなかったようですね。 今回は、どのようなSuites階層にしているのかなと思ったわけです。 Integration Test（IT）ではUserがGUIをとして何か操作を行なうことに対するTestをするわけですが、 Black Box Testとはいえ、色々なTestの分け方が考えられます。 現状、最上位SutitesはTest Level＝Unit 、Integaration、Systemになっており、 IT のフォルダの下にGUI Test、機能テストTest、非機能関連Test といったTest Typeを次のSuitesにしようかと考えました。 自社のこれまでのITでは、Test用のMatrixを作っていて、Matrixの項目をSutiesにするというのもありかなと。 ここでのMatrixは行が画面の種類で列が、画面遷移や入力・イベント、といったTest観点のカテゴライズです。 画面毎にどの観点のTestが必要かマトリックスを作っています。 このようなわけ方がいいのかなと思い、他の方の運用をお伺いしてみました。 ＞テストの目的とテストケースがほぼ1対1になるまで分 １TestCase、１Validation PointというのはTestLinkを使わなくてもそうするべきでしょうね。 このエッセンスはTestLinkだからというわけではないと考えております。 あきぴーさんは、しっかり運用されていらっしゃるようですね。 とても参考になりました。ありがとうございます。 2009/03/08 18:18 Akipii Oga <akipi****@gmail*****>: > OREOさん > > はじめまして。あきぴーと申します。 > TestLinkを半年間運用した経験から、僕の考えを書いてみます。 > > > 例えば、同値分割、Decision Tableなで入力値を決定した場合、Stepは同じだが入力値が違うといったTestCaseが考えられますが、 > > TestLink上ではどのように管理するのが好ましいのでしょうか? > > 例えば顧客情報などの個人情報を登録するようなTestCaseでは > > > > 1. 姓名を入力（姓、名をそれぞれ入力するText Boxがある） > > 2．生年月日を入力する。 > > 3．性別を入力する。（男,女,その他） > > 4．・・・ > > ・ > > ・ > > ・ > > N．登録ボタンを押してDBへ登録する。 > > > > といったときに、正常系であろうと異常系（無効な入力値での動作確認）であろうと、Stepは同じです。 > > このような場合、TestLink上ではどのようにTestCaseを管理すると管理しやすいのでしょうか？ > > （最も異常系の場合、既定結果が違うので、同じTestCaseというわけにはいかないと思います。 > > しかし、正常系では、上記の例ですと、性別では３種類の中から選ばれたものが登録されることを確認しないといけないです。） > > 僕の所では、TestLinkのテストケースは結合〜システムテストで使うため、ユースケースを > ベースとしたユーザシナリオになります。 > そのため、単体テストレベルの細かなテストは書いてません。 > ＃JUnit、単体チェックシートなどで既にテスト済みのため。 > > 管理者の観点では、テストの進捗を計測できる単位までテストケースを分割します。 > 普通、1つのユーザストーリーで複数のテストケースがあり、それぞれにテストの目的が > あります。 > テストの目的とテストケースがほぼ1対1になるまで分割すれば、テスト結果画面で > リアルタイムに進捗をモニタリングできます。 > > テスト担当者の観点では、担当のテスト内容をすぐにテストできる単位がありがたいです。 > だから、1個のテストケースが1個のテスト手順になるように、テストケースを作ります。 > 特に、テスト担当者は業務に詳しくない人もいるため、テストケースの事前条件と事後条件を > 詳細に書かないと、テストの品質が悪くなります。 > > 上記の場合、僕なら例えば下記のように書きます。 > > (TestSuite1)xx画面 > (TestSuite2)姓名の入力チェック機能が正常であることを確認する > (TestCase-ID)テスト仕様書のケースID > (TestCase-概要)xx画面の姓名に値を入力する(ex. y1, y2...)。 > (TestCase-ステップ)zzボタン押下 > (TestCase-期待値)xx画面でE1メッセージを表示する > > つまり、下記のルールで書いてます。 > > ・TestSuiteには、テストケースをグループ化するための項目を入れる > ・TestSuiteへテストの目的を書く > ・TestCase-概要にテストケースの事前条件を書く > ・TestCase-ステップにテスト手順を書く > ・TestCase-期待値に期待値を書く > > ・テストケースは、ユーザストーリーを検証する目的で分割する。 > そのため、テストスイートにWBSのようなテスト分類項目、テストの目的を入れる。 > ・テストケースの粒度は、ストーリー単位。 > 境界値条件など細かなテストは、単体テスト済みとする。 > ・テストケースの事前条件は、概要の欄に詳細に書く。 > 特に業務システムでは、テストデータやテスト前の画面の状態を詳細に書かないと > テスト担当者が理解しにくい。 > TestLinkでは事前条件の欄がないため、仕方ないので概要で代用している。 > 詳細に書く必要があれば、表形式(tableタグ)などで代用する。 > > ・テストケースのテスト手順は、ステップ欄に書く。 > ・テストケースの事後条件は、期待値の欄に書く。 > 更新後のテストデータ、更新後の画面の状態を書く。 > > テスト担当者の作業を聞くと、テスト実行画面で、アサイン＝自分、結果＝未実行で > フィルタリングしてテストしているみたいです。 > そのため、テスト担当者の観点で使いやすくするには、テスト実行画面に出るテストケース > 1個でテストの目的が完遂されるように書けばいいと思います。 > > テストケースの粒度は、単体テストか又は、結合・システムテストで使うのか、で全く > 性質が変わってきます。 > しかし、テストケースは粒度に関係なく、事前条件＋テスト手順＋事後条件のフォーマットに > 統一できるだろうと思います。 > > 以上、よろしくお願いします。 > > _______________________________________________ > Testlinkjp-users mailing list > Testl****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/testlinkjp-users > -------------- next part -------------- HTMLの添付ファイルを保管しました...ダウンロード
