[{"data":1,"prerenderedAt":110},["ShallowReactive",2],{"unit:shindanshi\u002Fjoho\u002Fkaihatsu\u002Ftest":3},{"unit":4,"drills":90,"related":95,"topicUnits":100},{"id":5,"exam":6,"subject":7,"subjectName":8,"topic":9,"title":10,"tier":11,"hindo":12,"kijunbi":13,"readingMinutes":14,"sources":15,"factcheck":20,"blocks":24,"pairs":38,"drills":50,"links":87},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Ftest","shindanshi","joho","経営情報システム","データベースと開発","テスト — 分解して見るか、ハンドルを回して見るか",1,"B","2026-05-01",5,[16],{"kind":17,"label":18,"url":19},"kokai","日本中小企業診断士協会連合会「令和8年度第1次試験案内」（テスト手法・テスト段階はシステム開発の標準知識。URLは試験科目・制度の確認用）","https:\u002F\u002Fwww.jf-cmca.jp\u002Fattach\u002Ftest\u002Fr08\u002Fr08_1ji_annai.pdf",{"status":21,"date":22,"scope":23},"passed","2026-07-16","独立監査（opus・2026-07-16）: 最重要検証点＝C2（条件網羅）の定義を素材の「すべての条件の真偽の組み合わせ」から標準定義（個々の条件式の真偽をそれぞれ1回以上。全組み合わせは複数条件網羅=MCC）へ修正した当否——権威ソースで「素材が誤り・修正は正当」と確認（素材誤りの上方修正11例目）。Chen記法・正規化3段階・SQL4分類（TRUNCATE=DDL含む）・WHERE\u002FHAVING・ACID・分離レベル両端・スクラム3役と5行事・テスト4段階（UAT=発注側）・境界値分析の例（100と101）・FP法5対象（IFPUG=EI\u002FEO\u002FEQ\u002FILF\u002FEIFと一致）・COCOMO（Boehm1981・3モード）を全数照合し全点正確。ドリル20\u002F20正確・比喩の承認継承忠実・請負\u002F準委任の対応はIPA「モデル取引・契約書」の通説と一致・文字混入ゼロ（483字全て標準日本語漢字）・リンク10件全実在・hindo全一致。S\u002FA\u002FB級ゼロ・C級3点（C0⊂C1⊂C2の簡略化／TCL独立の4分類系／M:Nの層——いずれも試験深度で無害・修正不要と判定）。合格可能性約88%。PASS。",{"hook":25,"question":26,"intuition":27,"rigor":30,"pitfall":33,"jitsumu":36,"payoff":37},"\n        \u003Cp>車の検査には2通りあります——\u003Cb>機械を分解して\u003C\u002Fb>部品の動きを一つずつ確かめる方法と、\u003Cb>ハンドルを回して\u003C\u002Fb>ちゃんと曲がるかを外から確かめる方法。中身を見るか、振る舞いを見るか。\u003C\u002Fp>\n        \u003Cp>ソフトウェアのテストもこの2軸です。さらに「部品→つながり→全体→お客さんの確認」という\u003Cb>段階の順序\u003C\u002Fb>が、もう1つの的になります。\u003C\u002Fp>","ホワイトボックスとブラックボックスは何が違い、テストはどんな段階で進むのでしょうか。",{"heading":28,"html":29},"中身を見るのがホワイト、振る舞いを見るのがブラックです","\n        \u003Cp>\u003Cb>ホワイトボックステスト\u003C\u002Fb>は\u003Cb>プログラムの内部構造\u003C\u002Fb>を見て、どこまで実行し尽くしたかを網羅基準で測ります——\u003Cb>C0（命令網羅）\u003C\u002Fb>＝すべての命令を1回以上実行、\u003Cb>C1（分岐網羅）\u003C\u002Fb>＝すべての分岐の真偽を1回以上通過、\u003Cb>C2（条件網羅）\u003C\u002Fb>＝判定を構成する\u003Cb>個々の条件式\u003C\u002Fb>の真偽をそれぞれ1回以上実行。番号が上がるほど基準が細かくなります。\u003C\u002Fp>\n        \u003Cp>\u003Cb>ブラックボックステスト\u003C\u002Fb>は内部を見ずに\u003Cb>入出力の振る舞い\u003C\u002Fb>で確かめます——代表値で試す\u003Cb>同値分割\u003C\u002Fb>と、バグが潜みやすい境目を突く\u003Cb>境界値分析\u003C\u002Fb>（「100以下」なら100と101を試す）が2大技法です。\u003C\u002Fp>\n        \u003Cdiv class=\"chorus\">\u003Cspan class=\"chorus-k\">テストの合言葉\u003C\u002Fspan>\u003Cspan class=\"chorus-t\">\u003Cb>単体→結合→システム→受入（ユーザー）\u003C\u002Fb>——\u003Cb>C0命令・C1分岐・C2条件\u003C\u002Fb>\u003C\u002Fspan>\u003C\u002Fdiv>",{"heading":31,"html":32},"段階は範囲が広がる順——最後の受入はユーザーの仕事です","\n        \u003Cp>テストの段階は範囲の広がる順に4つ——\u003Cb>単体テスト（UT）\u003C\u002Fb>＝部品単位（開発者が担当）→\u003Cb>結合テスト（IT）\u003C\u002Fb>＝部品どうしのつながり→\u003Cb>システムテスト（ST）\u003C\u002Fb>＝全体を本番同等の条件で→\u003Cb>受入テスト（UAT）\u003C\u002Fb>＝\u003Cb>発注したユーザー側\u003C\u002Fb>が「頼んだものか」を確認。担当の主語が最後だけ変わるのがポイントです。\u003C\u002Fp>\n        \u003Cp>修正のたびに必要なのが\u003Cb>リグレッションテスト（回帰テスト）\u003C\u002Fb>——直した箇所の周りだけでなく、\u003Cb>既存の機能が壊れていないか\u003C\u002Fb>を再確認します。「直したら別の場所が壊れた」を防ぐ保険です。\u003C\u002Fp>",{"heading":34,"html":35},"C0\u002FC1\u002FC2の定義の入れ替えと、受入テストの担当が的です","\n        \u003Cp>定番の誤り肢は\u003Cb>網羅基準の入れ替え\u003C\u002Fb>——「C1はすべての命令を1回以上実行する基準である」（それは\u003Cb>C0\u003C\u002Fb>。C1は\u003Cb>分岐\u003C\u002Fb>の網羅）。C0＝命令・C1＝分岐・C2＝条件の対応を崩さないでください。\u003C\u002Fp>\n        \u003Cp>\u003Cb>技法の帰属\u003C\u002Fb>も的——「境界値分析はホワイトボックステストの技法である」（誤り——内部を見ない\u003Cb>ブラックボックス\u003C\u002Fb>の技法）。段階では「\u003Cb>受入テストは開発者が実施する\u003C\u002Fb>」（誤り——\u003Cb>ユーザー側\u003C\u002Fb>の仕事）が定番です。\u003C\u002Fp>","\n        \u003Cp>顧問先がシステムを発注したら、\u003Cb>受入テスト（UAT）は顧問先自身の仕事\u003C\u002Fb>——ここをベンダー任せにすると「検収後に業務で使えないと発覚」という最悪の展開になります。診断士の助言は2つ——①検収前に\u003Cb>実際の業務データと業務手順で\u003C\u002Fb>試す、②「月末締め」「期初の処理」など\u003Cb>境界のタイミング\u003C\u002Fb>を必ず試す（境界値分析の実務版）。この2つだけで検収事故の大半は防げます。\u003C\u002Fp>","\n        冒頭の問いに答えます。ホワイトボックスは内部構造を網羅基準（C0命令・C1分岐・C2条件）で確かめ、ブラックボックスは入出力の振る舞いを同値分割・境界値分析で確かめます。段階は単体→結合→システム→受入の順に範囲が広がり、受入だけはユーザー側の仕事——修正後はリグレッションテストで既存機能を守ります。次は、作る前の値段の話——見積り3法へ。",[39],{"label":40,"left":41,"right":45,"hinge":49},"ホワイトボックスとブラックボックス",{"badge":42,"name":43,"note":44},"ホワイト","内部構造を見る","網羅基準C0\u002FC1\u002FC2でどこまで実行したかを測る",{"badge":46,"name":47,"note":48},"ブラック","入出力の振る舞いを見る","同値分割・境界値分析——内部は見ない","「分解して見るか、ハンドルを回して見るか」。境界値分析の帰属替えが定番の的です。",[51,62,75,82],{"type":52,"id":53,"prompt":54,"options":55,"correct":60,"explanation":61},"quiz","joho-test-q1","テストの網羅基準に関する記述として、最も適切なものはどれか。",[56,57,58,59],"C0（命令網羅）は、すべての命令を少なくとも1回実行するようにテストケースを設計する基準である。","C1（分岐網羅）は、すべての命令を少なくとも1回実行する基準である。","C2（条件網羅）は、プログラム中の分岐を一切通らないことを確認する基準である。","同値分割と境界値分析は、ホワイトボックステストの代表的な技法である。",0,"\u003Cstrong>正解：ア\u003C\u002Fstrong>　C0＝命令網羅です。\u003Cbr>イ＝命令の網羅はC0（C1は分岐の真偽を通過させる基準）、ウ＝C2は個々の条件式の真偽をそれぞれ実行する基準、エ＝同値分割・境界値分析は内部を見ないブラックボックスの技法。番号と定義の入れ替えが手口です。",{"type":63,"id":64,"prompt":65,"ask":66,"choices":67,"correctKey":69,"explanation":74},"judge","joho-test-j1","「受入テスト（UAT）は、発注したユーザー側が実際の業務の観点から確認するテストである」との記述がある。","この記述は適切か。",[68,71],{"key":69,"label":70},"ok","適切",{"key":72,"label":73},"ng","不適切","\u003Cb>適切\u003C\u002Fb>です。単体→結合→システムまでは作る側、最後の受入だけは\u003Cb>頼んだ側\u003C\u002Fb>の仕事——「頼んだものが来たか」は発注者にしか確かめられません。「受入テストは開発者が実施」が定番の誤り肢です。",{"type":63,"id":76,"prompt":77,"ask":66,"choices":78,"correctKey":69,"explanation":81},"joho-test-j2","「上限が100と定められた入力項目に対し、100と101を試すのは、境界値分析に基づくテストケース設計である」との記述がある。",[79,80],{"key":69,"label":70},{"key":72,"label":73},"\u003Cb>適切\u003C\u002Fb>です。バグは境目に潜む——有効の端（100）と無効の始まり（101）を突くのが境界値分析です。代表値を1つ選んで試すのは同値分割——2大技法の区別も的になります。",{"type":83,"id":84,"prompt":85,"answer":86},"blank","joho-test-b1","プログラムを修正した後、修正箇所以外の既存機能が壊れていないかを再確認するテストを〔?〕という。","リグレッションテスト（回帰テスト）",[88,89],"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmodel","shindanshi\u002Fjoho\u002Fkaihatsu\u002Fmitsumori",[91,92,93,94],{"unitId":5,"unitTitle":10,"topic":9,"item":51},{"unitId":5,"unitTitle":10,"topic":9,"item":62},{"unitId":5,"unitTitle":10,"topic":9,"item":75},{"unitId":5,"unitTitle":10,"topic":9,"item":82},[96,98],{"id":88,"title":97},"開発モデル — 家を建てるか、試食を重ねるか",{"id":89,"title":99},"見積り3法 — 機能で測る、行数で測る、過去に聞く",[101,104,107,108,109],{"id":102,"title":103},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fer-seikika","正規化 — 引っ越し1件で2行直すはめになる前に",{"id":105,"title":106},"shindanshi\u002Fjoho\u002Fkaihatsu\u002Fsql-acid","SQLとACID — 絞ってから集めるか、集めてから絞るか",{"id":88,"title":97},{"id":5,"title":10},{"id":89,"title":99},1784183227536]