القائمة
test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
内部実装を見ず、入出力仕様だけから入力空間の分割でテストケースを機械的に導くブラックボックス技法群。 test-catalog の手法カタログの一部。同値分割(Equivalence Partitioning)、境界値分析(Boundary Value Analysis)、 ドメイン分析テスト(Domain Analysis、多変数の境界on/off/in/out)、デシジョンテーブル(Decision Table、条件の組合せとアクション) を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
gitコミット運用ルール。**主目的は論理的に独立した修正を都度・適切な粒度でコミットすること**、および plan モードで実装計画を立てる際に必ずコミット計画を plan 本文に含めること。メッセージ形式は Conventional Commits。「コミットして」「コミット分けて」「コミット計画を立てて」「分けてコミット」「実装計画を立てて」「planを立てて」「実行計画を作って」「リファクタリング計画」と依頼される、`git commit`を実行する、ExitPlanMode 前に plan を提示する、複数の独立した修正をまとめるか分けるか判断する、レビューコメント対応をコミットする、rebase/squash で履歴を整える、`gh pr create`時にPRタイトルをコミット流儀に揃える等の場面で必ず参照する。変更を約30〜50行の論理単位へ分割してコミットを積む実務手順は micro-commit スキル側が担い、本スキルは粒度の判断基準・plan 段階のコミット計画・メッセージ規約を定める(併用時は本スキルの基準で分割単位を決め、micro-commit で実行する)。
テストが flaky になる要因のうち、処理どうしの協調(タイミング・順序)が定まらないものへの体系的対策。 test-catalog の手法カタログの一部。並行・競合(共有状態への同時アクセス、レース窓の検出と直列化による封じ込め)、 テスト間順序・状態漏れ(実行順シャッフルでの炙り出し、beforeEach/afterEachでの初期化・後始末)、 検出3軸と隔離(quarantine)・retry緑詐称の戒めといった flaky 対策の共通方針 を検証したい、または割り当てたいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。
自然言語の要求を EARS 記法 + 状態/ドメインモデルへ構造化し、TLA+ で設計を網羅検査し、 TLC の反例を Gherkin の受け入れ仕様に落とすまでの 3 重フィードバックループの入口(ルーター)。 ユーザーが「ループエンジニアリング」「EARS」「TLA+」「Gherkin」「設計を検証」「状態機械を検査」 「要求を形式化」と言ったとき、または並行・状態遷移・プロトコル設計の正しさを実装前に モデル検査で固めたいときに使用する。起動判断(2 問ゲート)を通った後、工程は loopeng-extract → loopeng-formalize → loopeng-modelcheck → loopeng-gherkin の各スキルへ委譲する。 設計は TLA+、実装の数学的証明は formal-verification(Lean)。
Automatically create conventional commit-style micro-commits by splitting changes into logical units of ~30-50 lines each. Use this skill whenever the user asks to commit, says "コミットして", "commit this", or when a feature, fix, or refactoring task is completed and changes need to be committed. Also trigger when the user mentions "マイクロコミット", "micro commit", "conventional commit", or asks to split changes into smaller commits. If you detect that a coding task has just been completed and there are uncommitted changes, suggest using this skill. Grain-size judgment and plan-stage commit planning are handled by the commit-flow skill; when both apply, commit-flow decides the split and this skill executes it.
期待値を1つずつ手で用意できないとき、正しいと信じられる別実装(参照実装・旧実装・別ライブラリ)と 出力を突き合わせる差分テスト(Differential Testing)を扱う。test-catalog の手法カタログの一部。 参照実装の独立性確認、入力空間の共通化、出力差ゼロの assert、浮動小数の許容誤差比較、 移行完了までの併走運用を検証したい、または割り当てたいときに使う。 通常は test-catalog スキルの索引経由で手法が選定された後にこのスキルを直接参照する。
| name | nonfunctional-perf |
| description | test-catalog の手法カタログの一部。非機能テストの測定系(性能テスト、負荷テスト、 ストレステスト、スパイクテスト、ソークテスト/耐久テスト、スケーラビリティテスト、 キャパシティテスト)を検証したいときに使う。通常は test-catalog スキルの索引経由で 手法が選定された後にこのスキルを直接参照する。 |
| disable-model-invocation | true |
非機能のうち「どれだけ速く・どれだけ捌けるか」を数値で測る観点を集める。 性能、負荷、ストレス、スパイク、ソーク(耐久)、スケーラビリティ、キャパシティの7種。 共通の型は「測定指標 + 合否しきい値(SLO/SLA)を先に決め、超えたら CI を落とす」ことだ。 しきい値の無い計測は「走らせただけ」で終わり、回帰を守らない。
品質保証系の非機能(セキュリティ、a11y、互換、信頼性、可用性、カオス、耐障害性、コントラクト、データ品質)は nonfunctional-attributes.md に分けた。
開発プロセスに組み込む戦術(BDD/ATDD/CI/カナリア)、静的テスト、その他の観点(冪等性/並行性)は process-static.md。
ISO/IEC 25010 の性能効率性に対応する。負荷の軸(時間 × 量 × 変動)を取りこぼさないために種別を分ける。
この7種は「広く薄い一覧」で足りる。深掘りが要るのは実際に手を動かす負荷テストで、以下に遂行手順と完了チェックを置く。 他種も同じ骨格(SLO を決める → 該当する負荷パターンをかける → 指標を計測 → しきい値と突合)で、負荷パターンだけが変わる。
負荷テストの本体は「先に合否ラインを決め、再現可能な負荷をかけ、指標としきい値を突合する」ことだ。順序を守らないと「走らせて数値を眺めただけ」になる。
throw で CI を落とす)。ここを実装しないと回帰が守られない。throw/失敗させる行が現にあるか。「結果を出力するだけ」で合否判定が無ければ未完(走らせただけ)。依存を増やさず Node だけで済むので autocannon をスクリプトから呼ぶ。
p99 レイテンシとエラー数を基準にして、超えたら失敗させる。
import autocannon from "autocannon";
const result = await autocannon({
url: "http://localhost:3000/api/health",
connections: 50,
duration: 10,
});
// 基準を満たさなければ CI を落とす。これが無いと「走らせただけ」で終わる
if (result.errors > 0) throw new Error(`errors: ${result.errors}`);
if (result.latency.p99 > 200) throw new Error(`p99 too high: ${result.latency.p99}ms`);
「遅い」報告を受けて直すときは、テストと同じく合否を数値で確定させてから手を動かす。
oracle-differential)。参照が高コストなら全件でなく抜き取りで比較する(オラクル自体がテストをタイムアウトさせない)。非機能は「網羅率」でなく「品質特性 × 基準値」で網羅を定義する。 網羅基準: ISO/IEC 25010 の性能効率性に関係する特性ごとに「測定指標 + 合否しきい値(SLO/SLA)」を定め、対象特性をすべて1つ以上のしきい値テストで覆ったとき網羅とみなす。 性能なら p99 とスループット、容量ならキャパシティ上限を指標にする。 網羅手順:
品質保証系(セキュリティ、a11y、信頼性、耐障害性、コントラクト、データ品質)の網羅の定義は nonfunctional-attributes.md の末尾にある。
セキュリティの検出層分け、a11y の WCAG 違反0件など、測定指標が数値レイテンシと異なる観点はそちらを参照する。