#author("2023-01-31T14:55:16+09:00","default:irrp","irrp")
→テストツール
→NUnitまとめ
→脆弱性関連
→インシデント管理ツール
→[[CI/CD]]
#contents
*テスト一般 [#ze640392]
-[[フロントエンドにおける「単体テストの考え方/使い方」>https://zenn.dev/akfm/articles/frontend-unit-testing]] 2023.1
-[[なぜ我々はユニットテストが書けないのか？｜SHIFT Group 技術ブログ｜note>https://note.com/shift_tech/n/ne17f3fab6a05]] 2022.7
--メンタルの問題、コストの問題、知識の問題
-[[テストコードにはテストの意図を込めよう #vstat - Speaker Deck>https://speakerdeck.com/nihonbuson/tesutokodonihatesutofalseyi-tu-woip-meyou]] 2022.7
-[[世界中のITエンジニアが悩まされている原因不明でテストが失敗する「フレイキーテスト」問題。対策の最新動向をJenkins作者の川口氏が解説（前編）。DevOps Days Tokyo 2022 − Publickey>https://www.publickey1.jp/blog/22/itjenkinsdevops_days_tokyo_2022.html]] 2022.6
-[[現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ>https://t-wada.hatenablog.jp/entry/design-for-testability]] 2019.10
-[[プログラマとテストエンジニアにバトル勃発！正しいバグ票の書き方とは？>http://thinkit.co.jp/story/2012/07/11/3614?page=0,0]] 2012.7.11
--バグ修正をスムーズに進めるためには、バグレポートを書く時点で「バグ対我々」という構図を意識できているかどうかという点が最も重要です。意識するだけで文面が変わってきます。もちろん、バグレポートを読んで対応するプログラマにも同じ意識が必要です。返答においても「バグ対我々」という構図がなければ、すぐに問題のあるバグレポートに変わってしまいます。
--口頭では躊躇してしまうような厳しい内容を文章にして伝えるというのは、得策ではありません。バグレポートも同様です。特にバグレポートは書く人（起票する人）にとっては、電子メールよりも報告の意味が強い文書なので、口頭で指摘するよりも厳しい口調になってしまう場合が多い傾向にあります。
-[[テスト駆動開発について僕は誤解していた>http://d.hatena.ne.jp/kura-replace/20120306/1331040054]] 2012.3.6
--「TDD のテストは自動実行できる assert の集合に過ぎない」という誤解
--「TDD のテストは設計を実コードより先に決定づけるものである」という誤解
--「テストとプログラミングをちまちま切り替えるより、それぞれ集中してやったほうが良くね？」という誤解
--「どうせテスト書いたってプログラム修正したらすぐ捨てるわけだし、やっぱりテスト書くのは時間の無駄じゃね？」という誤解
--「テストにまで可読性を求めるとか、バカじゃね？」という誤解
-[[マイクロソフトの責任者が語る「われわれはどのようにソフトウェアをテストしているか？」>http://www.publickey1.jp/blog/12/_jasst12_tokyo.html]] 2012.1.30
-[[負荷テストのデータ、読めてますか？>http://www.atmarkit.co.jp/fnetwork/rensai/perform02/01.html]] 2012.1.6
--パーセンタイル値とか
-[[単体テストを中心としたテストレベルの話>http://togetter.com/li/236005?f=tgtn]] 2011.1.3
-[[「品質に厳しい組織で、なぜ品質が劣化するのか？」>http://d.hatena.ne.jp/JavaBlack/20111220/p3]] 2011.12.20
--それは「品質に厳しい組織」なのではなく「品質管理部門が肥大化した組織」なのではないかと．
--「品質管理部門」とは，高い品質のものの品質確認はできるけど，どれだけ管理部門が大きくなっても品質の低いソフトウエアが高くなることはない．そして品質管理部門が肥大化して現場を軽視する組織においては，現場の人の質が低下した分だけソフトウエアの品質も低下し，品質監視部門は低品質を確認するだけの組織に成り下がる．（経験者談）
-[[テスト戦略、設計、手法、技法などなどのリンクをまとめてみた>http://d.hatena.ne.jp/kyon_mm/20110505/1304586126]] 2011.5.5
-http://www.swtest.jp/wiki/index.php
-[[世の中のソフトウェアテストは“間違いだらけ”!?>http://www.atmarkit.co.jp/im/cits/serial/bookguide/02/01.html]] 2010.7.13
--では、テストに対する“誤解”とは何か？――氏が最初に指摘するのは、「テストをすれば完璧なソフトウェアが作れるという“幻想”」である。
--大切なのは「すべてをテストすること」ではなく、「（起こり得る）リスクを理解すること」と「誰にとってのリスクか」という“ポイント”を明確化することにある。
--すなわち、「テストとは一種のサンプリング」なのだ。だが、これをマネジメント層の人間が理解していない場合、「完璧はある」という“幻想”を抱いているがゆえに、「すべてをテストしろ」とテスト技術者らに無茶な要求をし、結果的にプロジェクトの進行を遅らせてしまう。
-[[条件網羅の種類>http://oshiete.goo.ne.jp/qa/963125.html]]
--命令網羅：命令の実行をすべてテストで最低１回は実行する
--判定条件網羅＝分岐網羅：if文判定結果がtrueの場合、falseの場合をそれぞれ網羅
--条件網羅＝分岐条件網羅：if文の判定で評価する式(and/orでつながった項目)がtrue/falseの値を一回は取るようにする
--複合条件網羅：if文の判定で評価する式(and/orでつながった項目)の true/false の組み合わせを全部試す
--例）
判定条件網羅： 判定条件の真，偽を実行
「a=0，b=1」（真）
「a=1，b=1」（偽）
条件網羅： 各条件の可能な結果を１回はとる
「a=0，b=1」（条件１：真、条件２：偽 → 真）
「a=1，b=0」（条件１：偽、条件２：真 → 真）
複合条件網羅： 各条件の可能な結果のすべての組合せを実行
「a=0，b=0」（条件１：真、条件２：真 → 真）
「a=0，b=1」（条件１：真、条件２：偽 → 真）
「a=1，b=0」（条件１：偽、条件２：真 → 真）
「a=1，b=1」（条件１：偽、条件２：偽 → 偽）
-[[ソフトウェア開発の「パンドラの箱」を開けないために>http://monoist.atmarkit.co.jp/fembedded/articles/kumikomi/18/kumikomi18.html]] 2010.4.17
--ソフトウェアの開発では、摘出したバグを修正しない方がよい場合も少なくありません。特に、出荷日が目前に迫ったタイミングでは、そのままバグを放置した方が望ましいこともあるのです。
-[[勝ちにいく！ソフトウェアテスト>http://itpro.nikkeibp.co.jp/article/COLUMN/20070920/282540/?ST=system]]
-[[テスト消化曲線とバグ発生曲線の７パターン診断>http://monoist.atmarkit.co.jp/fembedded/articles/kumikomi/16/kumikomi16.html]] 2010.2.18
-[[メトリクスでソフトウェア品質を見える化する>http://forza.cocolog-nifty.com/blog/2009/12/post-2b99.html]] 2009.12.15
-[[開発するのに30分、テストするのに10万年〜野戦病院モードのソフトウェア開発プロジェクト：その4〜>http://monoist.atmarkit.co.jp/fembedded/articles/kumikomi/13/kumikomi13.html]]
-[[開発工程とテスト― 単体／統合／受入／システム／回帰テスト>http://codezine.jp/article/detail/4566]] 2009.11.26
-[[単体テスト計画書>http://codezine.jp/article/detail/4154]]
-[[NTTデータとの決闘シリーズ第二幕>http://d.hatena.ne.jp/higayasuo/20080828/1219901392]]
--カバレッジは、参考程度に見るのはいいけど、数値目標を立てて管理に使い始めると弊害が増える。
--問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。
--ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。
-[[できるテスターの七つの習慣>http://labs.unoh.net/2009/03/post_133.html]] 2009.3.28
-[[複雑度と単体テストの相関関係>http://forza.cocolog-nifty.com/blog/2009/01/post-ca39.html]] 2009.1.4
--複雑度の数値は、下記の意味を持つらしい。
--10 以下であればよい構造
--30 を越える場合，構造に疑問
--50 を越える場合，テストが不可能
--75 を越える場合，いかなる変更も誤修正を生む原因を作る
--話によると、複雑度が15以上ならばコードレビューを実施する会社もあるらしい。
--ソフトウェア複雑度(McCabeのサイクロマチック数)
--≒分岐網羅(C1)のテストケース数
--≒単体テストケース数
-[[テストできるコードの書き方>http://www.hyuki.com/yukiwiki/wiki.cgi?WritingTestableCode]]
-[[数兆円かけても消せない「バグ」といかにつきあうか>http://it.nikkei.co.jp/business/news/index.aspx?n=MMIT2z000011042008]] 2008.4.14
--以前あるシステムが止まったとき、テレビでその原因を「たった一行の間違いで」と伝えていた。それは驚くべきことではなくむしろ当然で、ミスはむしろ一行どころか一文字あるいは１ビットということがよくあり、これらをすべて洗い出すには気の遠くなるような大変な労力が必要になる。
--まさかの時に備えて事業継続計画（Business Continuity Plan、ＢＣＰ）を整備しておくことが必須だ。ＢＣＰとはシステムが停止したときにできるだけ被害を少なくするように、また完全ではないにしてもシステムを使わないで何とかサービスやビジネスを継続するような手順のことだ。作るだけでなく常に演習をしておくことが最も重要な対策であり、これを怠ると大変な事態を招く可能性がある。
-[[テスト設計の必勝テクニック>http://itpro.nikkeibp.co.jp/article/COLUMN/20070920/282541/?P=2&ST=system]] 2007.10.9
--なぜテストの直前にテスト設計をしてはいけないのか。TISの鈴木三紀夫氏（技術本部 基盤技術センター主査）は，「仕様変更が大きく関係する」と説明する。開発現場では通常，仕様書や設計書のミスが見つかり，仕様変更になることが多い。だが，見つかった時期によって，手戻り工数は大きく変わる。もしテスト工程でこうしたミスが見つかれば，テストどころではなくなり，大きな手戻りを招くことになる。
--鈴木氏によれば，テスト設計を実施すると「仕様書や設計書のミス」を発見しやすいという。「そもそもテスト項目を抽出できない仕様書や設計書には何らかの問題がある。テスト設計は仕様書や設計書を参照しながら進めるので，“テスト”という観点でレビューすることになる」（鈴木氏）。
-[[Web開発におけるテスト関連ドキュメントの作成・運用>http://enterprisezine.jp/article/detail/31?p=1]] 2007.7.30
-[[ソフトウェアの欠陥はなぜなくらならいか>http://labaq.com/archives/50914149.html]]
*カバレッジ [#e8d18d14]
-[["テストカバレッジ強制ギプス" 導入 - Qiita>https://qiita.com/nrnrk/items/41d6d900c9688b9b4de2]] 2021.12
-[[テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について>https://qiita.com/bremen/items/d02eb38e790b93f44728]] 2018.3
--『カバレッジが高ければ、品質が高い』は誤った論理であり、正しくは 『「カバレッジが高い」かつ「テストケースの品質が高い」ならば、「コードの品質が高い」』 である。
--いくらカバレッジが高くても、 テストケースの品質が悪ければ、バグが潜在している可能性を低くすることはできない。
--カバレッジを100%に近づければ近づけるほど、バグ検出の費用対効果は低下する。
--クリティカルなコードではない限り、カバレッジ（C0 / C1）の目標値は 85%程度 に設定すべきである。
*テスト手法 [#w93a9680]
-[[【入門】フロントエンドのテスト手法まとめ - Qiita>https://qiita.com/SMAC/items/7cf6b24bed318dab5715]] 2022.7
--Static Test
--Unit Test
--Integration Test
--End to End Test
-[[現場で使うためのオールペア法、直交法の基本>http://www.atmarkit.co.jp/ait/articles/1506/11/news013.html]] 2015.6.11
-[[結合テストと総合テスト>http://www.thinkit.co.jp/free/project/4/7/1.html]]
--ソフトウェアの開発におけるテスト作業は、「テスト計画」「テスト設計」「テスト実施」「テスト管理」という4つのプロセスで構成されます
-[[ファズ・テスト>http://www-06.ibm.com/jp/developerworks/java/library/j-fuzztest.shtml]]
--入力データの一部をランダムに書き換え、どのようなエラーが起きるかチェックする技法
** E2E(End to End)テスト [#j90a9fd8]
-[[E2Eテスト(インテグレーションテスト)の利点と不利点 - Qiita>https://qiita.com/NAKKA-K/items/58d6b8476a3717179bda]] 2022.5
-[[E2EテストにAutifyを使っている理由、そしてE2Eテストで大事にしていること - Kaizen Platform 開発者ブログ>https://developer.kaizenplatform.com/entry/ban/2021-04-25/]] 2022.4
**カオスエンジニアリング [#s38d0a01]
-[[WindowsにGremlinをインストールして攻撃を実行してみる | DevelopersIO>https://dev.classmethod.jp/articles/how-to-install-and-run-gremlin-on-windows/]] 2021.11
-[[Gremlinのシナリオを使ってTLS/SSL証明書の有効期限をテストしてみる。 | DevelopersIO>https://dev.classmethod.jp/articles/test-tls-certificate-expiration-by-gremlin/]] 2021.11
-[[Chaos Engineering on Frontend ~フロントエンドにカオス性を注入して信頼性を向上させよう~ - Qiita>https://qiita.com/G-awa/items/9dc13c2db99cc85705bf]] 2021.11
-[[カオスエンジニアリングと聞いてカオスになった人必見 - Qiita>https://qiita.com/naokiiiii/items/de20997a70922c01f754]] 2018
--カオスエンジニアリングとは、全世界に動画配信サービスを提供するNetflixが導入したことで注目されるようになった手法で、「本番稼働中のサービスにあえて擬似的な障害を起こすことで、実際の障害にもちゃんと耐えられるようにしよう」という取り組みです。
*テスト計画書に書く項目の例 [#xf80eb7d]
-テスト計画書とは、テスト工程の要件定義を行い、明確にすることで品質を確保するための文書である。顧客向けと内部向けに分けて書くこともある。顧客向けは品質確保をどのように行うかに重点が置かれ、内部向けは手順や方法、統一ルールの明示などに重点が置かれる傾向がある
**項目 [#ja97b2e4]
-記載範囲
--テスト対象の範囲を示す。構成図で色をつけるなど
-工程の定義
--「対象プログラムが設計書仕様通りの動作をすることを確認する」など
-処理概要
-テスト観点
-テストの方法・進め方
--故障管理、仕様変更管理のやり方
-品質指標値
--確認目標件数
--障害摘出目標件数 （キロステップあたり何件、とか）
-成果物
--テスト仕様書
--テスト完了したプログラム
--障害管理台帳
--エビデンス
--UnitTest結果
--ログファイル、トレースダンプなど
--カバレッジレポート
--レビュー記録表
--テスト計画実績対比表
--品質計画実績報告書
-テスト完了基準
--テスト項目全件消化
--障害がすべて対策済みであること
--レビュー指摘がすべて対応済であること
-体制
-スケジュール
-進捗管理方法
-テスト品質の管理方法
*品質管理一般 [#n0b8e3d8]
-[[試験工程管理の概論 – サイゼントの技術ブログ>https://cyzennt.co.jp/blog/2022/12/19/%e8%a9%a6%e9%a8%93%e5%b7%a5%e7%a8%8b%e7%ae%a1%e7%90%86%e3%81%ae%e6%a6%82%e8%ab%96/]] 2022.12
-[[質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition - Speaker Deck>https://speakerdeck.com/twada/quality-and-speed-2022-spring-edition]] 2022.9
--品質と開発スピードはトレードオフではない、という話
-[[変更管理、その正体と対策：意外と知らない構成管理の正体（3） - ITmedia エンタープライズ>https://www.itmedia.co.jp/im/articles/0411/19/news108.html]] 2004
-[[エンジニアなら知っておきたい障害報告&再発防止策の考え方>https://qiita.com/hirokidaichi/items/f9f4549c88aaf8b38bda]] 2018
--障害報告は始末書や反省文ではない
--「起きた現象」の内容ではなくて、「原因やバグが発生しているモジュール名」などを書いてしまいがち
--3段階くらいに再発防止策を検討
---直接原因 ： その不具合が発生した直接的原因
---間接原因 ： その不具合に至るまでの間接的な原因
---本当の理由： なぜ、このようなパターンの障害が発生したか
-[[ソフトウェア品質最前線>http://techon.nikkeibp.co.jp/embedded/2006mook/]]
-[[品質表展開（QFD）とは>http://www.i-juse.co.jp/statistics/product/func/process/qfd.html]]
-[[<論文>情報システム開発における品質管理の一考察 : テスト工程におけるソフト品質向上手法の改善>http://ci.nii.ac.jp/naid/110000040949]]
-[[表面の現象で対策を打ってはいけない>http://itpro.nikkeibp.co.jp/article/COLUMN/20080702/310037/]] 2008.7.25
-[[ソフトウェア品質最前線:http://techon.nikkeibp.co.jp/embedded/2006mook/]]
**品質評価報告書の項目例 [#qa480090]
-品質評価の対象範囲
-テスト観点
--どういう観点でテスト項目を立てたか。
--また、なぜその観点でテストが十分と言えるのか、という根拠づけを説明する
-品質データ
--テスト件数目標／実績
--テスト密度（キロステップ辺り件数など）とその達成度
--障害摘出目標／実績
--障害密度実績／達成度（目標密度／実績密度）
-バグの分析
--バグの内容
--障害の傾向（障害の種類、水平展開の数、摘出すべき工程etc.)
--実施したテストの弱点分析。プログラムのどういう部分でバグが多く出ているか、どういう種類のバグが多く出ているか。
-品質強化策
--実施経緯。どういう弱点があったのでそれを補うためにこう言う方策を取った、など
--品質強化策の詳細内容
-残作業、次工程への引継事項
--テスト環境の制約上確認できなかったテスト項目、本番環境との相違点など
*コードレビュー [#l9ef11db]
→コーディング規約については言語・開発環境へ
-[[「読みやすいコードのガイドライン―持続可能なソフトウェア開発のために」を読んだ！ - mochikoAsTechのdig日記>https://mochikoastech.hatenablog.com/entry/2022/11/27/212739]] 2022.11
-[[コードレビューについて>http://blog.livedoor.jp/lalha/archives/50495777.html]] 2014
-[[コードレビュー 開発者ガイド | eng-practices>https://shuuji3.xyz/eng-practices/review/]] 2019
--Google's Engineering Practices Documentation Japanese Translation
--[[コードレビューの方法 | eng-practices>https://shuuji3.xyz/eng-practices/review/reviewer/]] レビュアー向けドキュメント
--[[CL の作者がコードレビューを乗り切るためのガイド | eng-practices>https://shuuji3.xyz/eng-practices/review/developer/]] レビュイー向けドキュメント
-[[コードレビューしませんか？メリット・デメリットを解説 - Qiita>https://qiita.com/ushi_osushi/items/91498bd4cad88d7cd1c0]] 2022.3
-[[コードレビューで嫌われる人の特徴7選 - Qiita>https://qiita.com/emjo1804/items/48f6e78237a04684ab38]] 2022.3
-[[レビューで大量の指摘をして大きな手戻りを発生させた原因はレビューアの私にあった>https://qiita.com/kojimadev/items/e12784e6764f1b60e73c]] 2021.4
-[[コードレビューについて>http://d.hatena.ne.jp/camlspotter/20120814/1344919762]] 2012.8.14
-[[ソフトウェアレビューが成功する進行役の6条件>http://www.atmarkit.co.jp/im/carc/serial/review/04/01.html]] 2010.4.14
--レビューアがエラー発見に集中できているか
--レビューアがエラー発見の手掛かりを得られているか
--遠慮して発言していないレビューアがいないか
--適切なエラー指摘がなされているか
--進行のペース（時間配分）は適切か
--作成者は指摘を受け入れているか
* 静的解析/コードメトリック／コードメトリクス [#g87b8132]
-[[McCabe を使って Python コードの複雑度をチェックしよう！ - サーバーワークスエンジニアブログ>https://blog.serverworks.co.jp/python-mccabe]] 2022.9
-[[コードメトリクスを計測・可視化する - ペパボテックブログ>https://tech.pepabo.com/2022/04/25/code-metrics-dashboard/]] 2022.4
-[[コード メトリック - サイクロマティック複雑度 - Visual Studio (Windows) | Microsoft Docs>https://docs.microsoft.com/ja-jp/visualstudio/code-quality/code-metrics-cyclomatic-complexity?view=vs-2019]] 2019
--循環複雑度
-[[【AWS Black Belt Online Seminar】Amazon CodeGuru - YouTube>https://www.youtube.com/watch?v=OF-NfrcgR-o]] 2021
-[[Amazon CodeGuruを用いて悪しきコードを撲滅したい - Qiita>https://qiita.com/yym_06/items/b32df05136b9c8bd9be8]] 2021.10
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
