memo.txtスマートフォン用の表示で見るmemo.txt教えていただいたこと、勉強したことのメモです。この広告は、90日以上更新していないブログに表示しています。ソフトウェアテスト全3回の、第3回。組み上げ方はテスト戦略として、どんなバグを見つけたいか、何をする期間か、どんな人がテストをするか、対象についての知識がどれくらいあるかなどによって、使い分ける。低いレベルから作り始めて、レベルを上げながらどんどん増やしていく。高いレベルから作り始める。シナリオテストを行うことが多い。トップダウン/ボトムアップトップダウン入力を受け付けるところからテストする。ボトムアップ入力位置は関係なくモジュール毎にテストする。トップダウンの方が楽そうなのにボトムアップでテストするのはすべてのモジュールがトップに向かうツリー構造であれば、トップダウンで網羅しやすいけど、それ以外の場合には漏れが発生しやすいから。組み合わせをあとから付け足す方法論。Sprint毎に、ユーザーストーリーに対して最短のパスを開発する(テストも含まれる)。実施がインクリメンタルなだけ。テストケースが減る訳じゃない。バグを予測できないものはテストではないテストはエラーを発見したら、成功。実施期間の終了によってテストを完了とする1.ある網羅基準について満たしたテストをすべて実施して完了とする○○技法の△△基準で網羅したテストを、すべて実施した。2.設定したエラー件数の発見によって完了とするそのフェーズでどんなエラーが何件あるか見積もり、その件数分エラーを発見したら完了とする。フェーズ毎にエラーの件数は違うテストレベルが上がるにつれて減るべきエラーや、テストレベルが高くないと出ないエラーがあるはず。テストケース数が高いところは、優先度が高い」と言える。3.エラー件数の発生具合によって完了とするプロダクト、プロジェクトによって適したグラフがちがうから、戦略時に決めておく。要望に応えるには検出するバグの総量は面積。自分が思っているデシジョンテーブルと、お客さんが思っているデシジョンテーブルが同じであることが重要。→確認すべき現実的なのは23にも挑戦はできるし、意味のある値をとることはできるが、完了はできない。→傾向を測ることしかできない。ソフトウェアテスト全3回予定の、第2回。基本的なツールとしてPictMasterの使い方を教えていただきました。PictMasterhttp://sourceforge.jp/projects/pictmaster/※PICTが入っていないPCの場合、まずPICTをインストールする必要があります。値の並び:水準をカンマ区切りで書く実行するとこんなファイルができる。制約表を使ってみるとりあえず使ってみるのファイルに、制約表を追加。メモ:レスザンの値は値の並びに書いてある値しか指定できなかった。シートを使ってみる結果表を使ってみるで生成された表をメインシートの右隣のシートに貼る。※結果内容があるとエラーになるので消しておく必要有り。商品価格の水準に130を追加して、実行ー。以前やったテストは確実にやって、さらに何か追加するときに使う。a.xls毎回同名のファイルを作るので、一度閉じるか別名で保存しないと次の実行はできない。ソフトウェアテスト全3回予定の、第1回。http://goyoki.hatenablog.com/entry/2012/07/11/004240こちらの資料の47ページからを見ながら教えていただきました。ぶれいすさんリフレクションとは動的(実行時)に、型の情報/メソッドの情報などを取得する。取得した情報を元に、インスタンスの生成/メソッドの呼び出し行う。動的に型の生成・書き換え/メソッドの生成・書き換え(もするらしい)。いう時に使うのでしょう文字列からオブジェクトを生成し、メソッドを呼び出す。設定ファイルにクラス名(例:Hoge)が文字列で書いてある。プログラムが設定ファイルのクラス名を読み込み、リフレクションを使ってHoge型のオブジェクトを生成する。ToStringフィールドの中身を文字列で表示するToString()を用意するとこんな感じになる。みたいなフィールドが増えると、ToString()を書き換えないといけない。}}そこで、リフレクションを使ってこんな感じに書いておく。→フィールドが増えてもToString()を書き換えなくていい。}}遅いけどな実行時に処理するので遅いので、使い方注意。f.GetValue(this)が10~100倍くらい遅い。『ユースケース駆動開発実践ガイド』に沿って教えていただきました。ユースケースモデリングガイドラインのトップ10(p58~68)システムの使い方について2段落ルールに従いなさい。アクターとユースケース図を使ってユースケースを組織化しなさい。ユースケースは叙述的に書きなさい。指示的に記述された文ユーザーは、パスワードを使った認証方式でログインできる。叙述的に書き直した文ユーザーはユーザー名とパスワードを入力して、「ログイン」ボタンをクリックする。システムはユーザー名からユーザーの情報を取り出し、パスワードをチェックする。ユーザーはシステムにログインする。イベントとその応答の流れとしてユースケースを書き、ユーザーとシステムの対話の両側を記述しなさい。GUIプロトタイプや画面モックアップを使いなさい。オブジェクトモデルの単語の使い方についてユースケースは実行時の振る舞いの仕様であるということを忘れないように。オブジェクトモデルの言葉を使ってユースケースを書きなさい。動詞」という文の構造にしたがってユースケースを書きなさい。【名詞】が【名詞】を【動詞】ドメインクラスの名前を使いなさい。(画面のような)バウンダリクラスの名前を使いなさい。関係はinvokesとprecedesを覚えておけばいいですA<<precedes>>BユースケースBの実行前に、ユースケースAが完全に実行される。ログインする<<precedes>>読者レビューを書くA<<invokes>>BユースケースBはユースケースAの実行期間中に実行される。きょんさんわかったこと品質モデルとは(確認)プロダクトをいろいろな視座から考えてみるヒントみたいなものだと思っています。→だいたいそんな感じです。ISO25000系は現在進行形で作られている品質モデルSQuaREシリーズとも呼ばれる。(ISO9126も含めた)既存の品質モデルを汲んでいる。ISO2501n以下のための品質モデルと実際的な利用のための手引きを提供する。利用時の品質モデル対象コンピュータシステム及び対象ソフトウェア製品を含む人間-コンピュータシステム全体に焦点。人間とコンピュータとの対話の成果に関係する。有効性(有効性)効率性(効率性)満足性(実用性/信用性/快感性/快適性)リスク回避性(経済リスク緩和性/健康・安全リスク緩和性/環境リスク緩和性)利用状況網羅(利用状況完全性/柔軟性)製品品質モデル対象ソフトウェア製品を含む対象コンピュータシステムに焦点。外部品質と内部品質に適用できる。間接利用者システムと直接対話をしないが,出力を受け取る人。大事なこと品質要求事項は利害関係者の観点から定義することが望ましい。