テストツール

NUnitまとめ

脆弱性関連

バグトラッキングツール

テスト一般

  • テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について 2018.3
    • 『カバレッジが高ければ、品質が高い』は誤った論理であり、正しくは 『「カバレッジが高い」かつ「テストケースの品質が高い」ならば、「コードの品質が高い」』 である。
    • いくらカバレッジが高くても、 テストケースの品質が悪ければ、バグが潜在している可能性を低くすることはできない。
    • カバレッジを100%に近づければ近づけるほど、バグ検出の費用対効果は低下する。
    • クリティカルなコードではない限り、カバレッジ(C0 / C1)の目標値は 85%程度 に設定すべきである。
  • プログラマとテストエンジニアにバトル勃発!正しいバグ票の書き方とは? 2012.7.11
    • バグ修正をスムーズに進めるためには、バグレポートを書く時点で「バグ対我々」という構図を意識できているかどうかという点が最も重要です。意識するだけで文面が変わってきます。もちろん、バグレポートを読んで対応するプログラマにも同じ意識が必要です。返答においても「バグ対我々」という構図がなければ、すぐに問題のあるバグレポートに変わってしまいます。
    • 口頭では躊躇してしまうような厳しい内容を文章にして伝えるというのは、得策ではありません。バグレポートも同様です。特にバグレポートは書く人(起票する人)にとっては、電子メールよりも報告の意味が強い文書なので、口頭で指摘するよりも厳しい口調になってしまう場合が多い傾向にあります。
  • テスト駆動開発について僕は誤解していた 2012.3.6
    • 「TDD のテストは自動実行できる assert の集合に過ぎない」という誤解
    • 「TDD のテストは設計を実コードより先に決定づけるものである」という誤解
    • 「テストとプログラミングをちまちま切り替えるより、それぞれ集中してやったほうが良くね?」という誤解
    • 「どうせテスト書いたってプログラム修正したらすぐ捨てるわけだし、やっぱりテスト書くのは時間の無駄じゃね?」という誤解
    • 「テストにまで可読性を求めるとか、バカじゃね?」という誤解
  • 「品質に厳しい組織で、なぜ品質が劣化するのか?」 2011.12.20
    • それは「品質に厳しい組織」なのではなく「品質管理部門が肥大化した組織」なのではないかと.
    • 「品質管理部門」とは,高い品質のものの品質確認はできるけど,どれだけ管理部門が大きくなっても品質の低いソフトウエアが高くなることはない.そして品質管理部門が肥大化して現場を軽視する組織においては,現場の人の質が低下した分だけソフトウエアの品質も低下し,品質監視部門は低品質を確認するだけの組織に成り下がる.(経験者談)
  • 世の中のソフトウェアテストは“間違いだらけ”!? 2010.7.13
    • では、テストに対する“誤解”とは何か?――氏が最初に指摘するのは、「テストをすれば完璧なソフトウェアが作れるという“幻想”」である。
    • 大切なのは「すべてをテストすること」ではなく、「(起こり得る)リスクを理解すること」と「誰にとってのリスクか」という“ポイント”を明確化することにある。
    • すなわち、「テストとは一種のサンプリング」なのだ。だが、これをマネジメント層の人間が理解していない場合、「完璧はある」という“幻想”を抱いているがゆえに、「すべてをテストしろ」とテスト技術者らに無茶な要求をし、結果的にプロジェクトの進行を遅らせてしまう。
  • 条件網羅の種類
    • 命令網羅:命令の実行をすべてテストで最低1回は実行する
    • 判定条件網羅=分岐網羅:if文判定結果がtrueの場合、falseの場合をそれぞれ網羅
    • 条件網羅=分岐条件網羅:if文の判定で評価する式(and/orでつながった項目)がtrue/falseの値を一回は取るようにする
    • 複合条件網羅:if文の判定で評価する式(and/orでつながった項目)の true/false の組み合わせを全部試す
    • 例)
      判定条件網羅: 判定条件の真,偽を実行
       「a=0,b=1」(真)
       「a=1,b=1」(偽)
      
      条件網羅: 各条件の可能な結果を1回はとる
       「a=0,b=1」(条件1:真、条件2:偽 → 真)
       「a=1,b=0」(条件1:偽、条件2:真 → 真)
      
      複合条件網羅: 各条件の可能な結果のすべての組合せを実行
       「a=0,b=0」(条件1:真、条件2:真 → 真)
       「a=0,b=1」(条件1:真、条件2:偽 → 真)
       「a=1,b=0」(条件1:偽、条件2:真 → 真)
       「a=1,b=1」(条件1:偽、条件2:偽 → 偽)
  • NTTデータとの決闘シリーズ第二幕
    • カバレッジは、参考程度に見るのはいいけど、数値目標を立てて管理に使い始めると弊害が増える。
    • 問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。
    • ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。
  • 複雑度と単体テストの相関関係 2009.1.4
    • 複雑度の数値は、下記の意味を持つらしい。
    • 10 以下であればよい構造
    • 30 を越える場合,構造に疑問
    • 50 を越える場合,テストが不可能
    • 75 を越える場合,いかなる変更も誤修正を生む原因を作る
    • 話によると、複雑度が15以上ならばコードレビューを実施する会社もあるらしい。
    • ソフトウェア複雑度(McCabeのサイクロマチック数)
    • ≒分岐網羅(C1)のテストケース数
    • ≒単体テストケース数
  • 数兆円かけても消せない「バグ」といかにつきあうか 2008.4.14
    • 以前あるシステムが止まったとき、テレビでその原因を「たった一行の間違いで」と伝えていた。それは驚くべきことではなくむしろ当然で、ミスはむしろ一行どころか一文字あるいは1ビットということがよくあり、これらをすべて洗い出すには気の遠くなるような大変な労力が必要になる。
    • まさかの時に備えて事業継続計画(Business Continuity Plan、BCP)を整備しておくことが必須だ。BCPとはシステムが停止したときにできるだけ被害を少なくするように、また完全ではないにしてもシステムを使わないで何とかサービスやビジネスを継続するような手順のことだ。作るだけでなく常に演習をしておくことが最も重要な対策であり、これを怠ると大変な事態を招く可能性がある。
  • テスト設計の必勝テクニック 2007.10.9
    • なぜテストの直前にテスト設計をしてはいけないのか。TISの鈴木三紀夫氏(技術本部 基盤技術センター主査)は,「仕様変更が大きく関係する」と説明する。開発現場では通常,仕様書や設計書のミスが見つかり,仕様変更になることが多い。だが,見つかった時期によって,手戻り工数は大きく変わる。もしテスト工程でこうしたミスが見つかれば,テストどころではなくなり,大きな手戻りを招くことになる。
    • 鈴木氏によれば,テスト設計を実施すると「仕様書や設計書のミス」を発見しやすいという。「そもそもテスト項目を抽出できない仕様書や設計書には何らかの問題がある。テスト設計は仕様書や設計書を参照しながら進めるので,“テスト”という観点でレビューすることになる」(鈴木氏)。

品質管理一般

品質評価報告書の項目例

  • 品質評価の対象範囲
  • テスト観点
    • どういう観点でテスト項目を立てたか。
    • また、なぜその観点でテストが十分と言えるのか、という根拠づけを説明する
  • 品質データ
    • テスト件数目標/実績
    • テスト密度(キロステップ辺り件数など)とその達成度
    • 障害摘出目標/実績
    • 障害密度実績/達成度(目標密度/実績密度)
  • バグの分析
    • バグの内容
    • 障害の傾向(障害の種類、水平展開の数、摘出すべき工程etc.)
    • 実施したテストの弱点分析。プログラムのどういう部分でバグが多く出ているか、どういう種類のバグが多く出ているか。
  • 品質強化策
    • 実施経緯。どういう弱点があったのでそれを補うためにこう言う方策を取った、など
    • 品質強化策の詳細内容
  • 残作業、次工程への引継事項
    • テスト環境の制約上確認できなかったテスト項目、本番環境との相違点など

テスト手法

  • 結合テストと総合テスト
    • ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます
  • ファズ・テスト
    • 入力データの一部をランダムに書き換え、どのようなエラーが起きるかチェックする技法

テスト計画書に書く項目の例

  • テスト計画書とは、テスト工程の要件定義を行い、明確にすることで品質を確保するための文書である。顧客向けと内部向けに分けて書くこともある。顧客向けは品質確保をどのように行うかに重点が置かれ、内部向けは手順や方法、統一ルールの明示などに重点が置かれる傾向がある

項目

  • 記載範囲
    • テスト対象の範囲を示す。構成図で色をつけるなど
  • 工程の定義
    • 「対象プログラムが設計書仕様通りの動作をすることを確認する」など
  • 処理概要
  • テスト観点
  • テストの方法・進め方
    • 故障管理、仕様変更管理のやり方
  • 品質指標値
    • 確認目標件数
    • 障害摘出目標件数 (キロステップあたり何件、とか)
  • 成果物
    • テスト仕様書
    • テスト完了したプログラム
    • 障害管理台帳
    • エビデンス
    • UnitTest結果
    • ログファイル、トレースダンプなど
    • カバレッジレポート
    • レビュー記録表
    • テスト計画実績対比表
    • 品質計画実績報告書
  • テスト完了基準
    • テスト項目全件消化
    • 障害がすべて対策済みであること
    • レビュー指摘がすべて対応済であること
  • 体制
  • スケジュール
  • 進捗管理方法
  • テスト品質の管理方法

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-04-12 (月) 23:40:25 (29d)