→脆弱性関連
→CI/CD
サブトピック†
カバレッジ†
- テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について 2018.3
- 『カバレッジが高ければ、品質が高い』は誤った論理であり、正しくは 『「カバレッジが高い」かつ「テストケースの品質が高い」ならば、「コードの品質が高い」』 である。
- いくらカバレッジが高くても、 テストケースの品質が悪ければ、バグが潜在している可能性を低くすることはできない。
- カバレッジを100%に近づければ近づけるほど、バグ検出の費用対効果は低下する。
- クリティカルなコードではない限り、カバレッジ(C0 / C1)の目標値は 85%程度 に設定すべきである。
テスト手法†
- 結合テストと総合テスト
- ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます
- ファズ・テスト
- 入力データの一部をランダムに書き換え、どのようなエラーが起きるかチェックする技法
E2E(End to End)テスト†
カオスエンジニアリング†
テスト計画書に書く項目の例†
- テスト計画書とは、テスト工程の要件定義を行い、明確にすることで品質を確保するための文書である。顧客向けと内部向けに分けて書くこともある。顧客向けは品質確保をどのように行うかに重点が置かれ、内部向けは手順や方法、統一ルールの明示などに重点が置かれる傾向がある
- 工程の定義
- 「対象プログラムが設計書仕様通りの動作をすることを確認する」など
- 処理概要
- テスト観点
- テストの方法・進め方
- 品質指標値
- 確認目標件数
- 障害摘出目標件数 (キロステップあたり何件、とか)
- 成果物
- テスト仕様書
- テスト完了したプログラム
- 障害管理台帳
- エビデンス
- UnitTest結果
- ログファイル、トレースダンプなど
- カバレッジレポート
- レビュー記録表
- テスト計画実績対比表
- 品質計画実績報告書
- テスト完了基準
- テスト項目全件消化
- 障害がすべて対策済みであること
- レビュー指摘がすべて対応済であること
- 体制
- スケジュール
- 進捗管理方法
- テスト品質の管理方法
品質管理一般†
- エンジニアなら知っておきたい障害報告&再発防止策の考え方 2018
- 障害報告は始末書や反省文ではない
- 「起きた現象」の内容ではなくて、「原因やバグが発生しているモジュール名」などを書いてしまいがち
- 3段階くらいに再発防止策を検討
- 直接原因 : その不具合が発生した直接的原因
- 間接原因 : その不具合に至るまでの間接的な原因
- 本当の理由: なぜ、このようなパターンの障害が発生したか
品質評価報告書の項目例†
- 品質評価の対象範囲
- テスト観点
- どういう観点でテスト項目を立てたか。
- また、なぜその観点でテストが十分と言えるのか、という根拠づけを説明する
- 品質データ
- テスト件数目標/実績
- テスト密度(キロステップ辺り件数など)とその達成度
- 障害摘出目標/実績
- 障害密度実績/達成度(目標密度/実績密度)
- バグの分析
- バグの内容
- 障害の傾向(障害の種類、水平展開の数、摘出すべき工程etc.)
- 実施したテストの弱点分析。プログラムのどういう部分でバグが多く出ているか、どういう種類のバグが多く出ているか。
- 品質強化策
- 実施経緯。どういう弱点があったのでそれを補うためにこう言う方策を取った、など
- 品質強化策の詳細内容
- 残作業、次工程への引継事項
- テスト環境の制約上確認できなかったテスト項目、本番環境との相違点など
コードレビュー†
→コーディング規約については言語・開発環境へ
- ソフトウェアレビューが成功する進行役の6条件 2010.4.14
- レビューアがエラー発見に集中できているか
- レビューアがエラー発見の手掛かりを得られているか
- 遠慮して発言していないレビューアがいないか
- 適切なエラー指摘がなされているか
- 進行のペース(時間配分)は適切か
- 作成者は指摘を受け入れているか
静的解析/コードメトリック/コードメトリクス†