意図的にバグを作り、それを検出するテストを自動生成する

「あえてあり得そうなバグを作る」 → 「そのバグを見つけるテストを作る」 → 「コードをバグに強くする」

gpt-4o.icon

従来のテスト生成

カバレッジは向上する

バグが見つかるとは限らない

ACHのアプローチ

1. エンジニアが関心のあるバグの種類を記述（例：「個人データが誤ってログに記録されるバグを見つけたい」）

2. LLMがその記述を元に、現実的に発生しそうなバグ（変異）をコード内に作成（例：ログ出力処理にミスを導入）

3. そのバグを検出するためのテストを自動生成（例：「ログに個人データが含まれていないことを確認するテストを作成」）

主な特徴:

単にカバレッジを増やすだけでなく、実際に問題になりそうなバグ にピンポイントでテストを作成できる。

結果として、プライバシー保護やセキュリティなど特定の分野の回帰バグ を未然に防ぐことができる。

テスト記述を自然言語で指示 でき、LLMが適切なバグとテストを自動作成。

Metaの主要プラットフォーム（Facebook、Instagram、Messenger、WhatsApp）で実証済み。

kadoyau.icon

「LLMがそのバグを確実に見つけるテストを自動生成」した後にバグを当然消すと思うんだけど、その際にこのテストは壊れないの？

GPT-4o.icon

ACHで生成されたテストは、バグ（変異）を削除しても壊れない ように設計されている。

なぜ壊れないのか？

1. バグ（変異）がない状態を「正解」としてテストを作る

ACHは「バグありのコード」と「バグなしのコード」の両方を知っている。

「バグがなければこのテストは通る」「バグがあればテストは失敗する」 という基準でテストを作成する。

2. 変異（バグ）を削除しても、テストは正常なコードを守る働きをする

変異体を削除した後でも、テストは「今後、同じバグが発生しないか？」をチェックする役割を果たす。

つまり、テストが壊れるのではなく、「バグがない状態を保証するテスト」として機能する。

どんなバグが作られるか事前にはわからないため、特定のコードに依存しないテストを作る必要がある。

例えば、「個人情報が誤ってログに出る」バグなら：

NG: 「特定の関数に print(user_data) があるか」をチェック → 変異の形が変わると通用しない

OK: 「ログの出力結果に個人情報が含まれていないことを検証する」

これなら、バグの具体的な形がどう変わっても、最終的な振る舞いを基準にチェックできる。

期待する状態をテストする

例えば、

「ログに email や phone_number が出力されないこと」

「認証なしで管理者ページにアクセスできないこと」