تست خودکار

تولید تست کیس با هوش مصنوعی؛ از Prompt تا Quality Gate

انتشار در تاریخ توسط محمد عسکری

فرض کنید User Story فقط می‌گوید: «کاربر مبلغ را وارد می‌کند و پرداخت موفق انجام می‌شود.» یک مدل زبانی ظرف چند ثانیه تست‌کیسی مرتب می‌سازد: مبلغ معتبر، کلیک روی پرداخت و انتظار پیام موفق. خروجی ظاهراً حرفه‌ای است؛ اما مبلغ ریال است یا تومان؟ رقم فارسی و عربی چه می‌شود؟ حداقل و حداکثر چیست؟ اگر Callback درگاه بعد از Commit دیر برسد یا دوبار تکرار شود، Oracle موفقیت کدام State است؟ مدل با یک Test Basis ناقص، خلأها را یا نادیده می‌گیرد یا با فرض‌های خوش‌ظاهر پر می‌کند.

تولید تست کیس با هوش مصنوعی زمانی مفید است که خروجی را Candidate testware بدانیم، نه Evidence. چرخهٔ قابل‌اتکا چنین است: Approved Test Basis → Grounding Pack → Prompt Contract → Candidate Tests → Traceability/Oracle Gates → Review/Execution → Evidence → Approval/Regression. سرعت تولید فقط ابتدای این زنجیره است.

در این راهنما، ورودی لازم، پرامپت آماده، قالب خروجی، روش جلوگیری از Hallucination، کنترل امنیت/حریم خصوصی، Quality Gate و معیارهای ارزیابی را می‌سازیم. سپس یک مثال واقعاً اجراشده نشان می‌دهد چرا پوشش نیازمندی، Passشدن کد و قدرت Oracle سه سنجهٔ متفاوت‌اند.

تولید تست کیس با هوش مصنوعی چیست؟

در این کاربرد، یک مدل مولد—معمولاً LLM—از Requirement، Acceptance criteria، API schema، کد، State model، تست‌های قبلی یا نمونهٔ خروجی استفاده می‌کند تا Test condition، Test case، Test data یا Test script پیشنهادی بسازد. صفحهٔ رسمی ISTQB CT‑GenAI v1.1 نیز Prompt engineering، ارزیابی خروجی، Hallucination، Bias، Privacy و Security را بخش‌های اصلی استفاده از GenAI در تست می‌داند.

تعریف عملی: AI Test Case Generation فرایند تولید و پالایش Candidate testware از منابع مشخص است؛ Candidate فقط پس از Traceability، تأیید Oracle، Review، اجرای کنترل‌شده و ثبت Evidence می‌تواند وارد Test suite معتبر شود.

این مقاله دربارهٔ استفاده از AI برای کمک به طراحی تست است. اگر خودِ محصول یک مدل ML/LLM است، مسئلهٔ Test strategy، داده، Model evaluation و Production monitoring متفاوت است و در راهنمای تست سیستم‌های AI/ML پوشش داده شده است. کاربردهای گسترده‌تر AI در فعالیت‌های QA نیز در مقالهٔ هوش مصنوعی در تست نرم‌افزار قرار دارد؛ این صفحه فقط مالک زنجیرهٔ تولید و اعتبارسنجی تست‌کیس است.

خروجی AI دقیقاً کدام Artifact است؟

Artifact حداقل محتوا آیا Evidence است؟
Test idea یک Risk یا رفتار برای بررسی خیر
Test condition موضوع/شرط قابل‌آزمون و Source خیر
Test case Precondition، Data، Action، Expected، Source/Oracle خیر؛ هنوز اجرا نشده
Test procedure ترتیب قابل‌اجرای گام‌ها و Cleanup خیر
Automated test script کد تست، Fixture، Assertion و Integration خیر؛ کد تولیدشده است
Test result Actual، Status، Build/Environment و Artifact فقط اگر اجرا معتبر باشد
Decision evidence نتیجهٔ معتبر + Scope/Unknown/Residual risk بله، برای تصمیم مشخص

تعداد زیاد Test case در پاسخ مدل، Coverage یا Quality نیست. یک تست بدون Expected result مستقل، Source requirement و وضعیت اجرای قابل‌اعتماد فقط متن بیشتری تولید کرده است.

چه زمانی AI برای تولید تست مناسب است؟

کارهای مناسب برای شروع

  • ساخت Draft از Acceptance criteria روشن و Versioned؛
  • پیشنهاد Partition، Boundary، State و Negative condition برای Review؛
  • تبدیل Test case تأییدشده به Skeleton کد یا Gherkin؛
  • یافتن Duplicate، Gap یا تناقض در Test suite موجود؛
  • ساخت دادهٔ مصنوعی درون Schema و محدودیت‌های روشن؛
  • توضیح یک تست قدیمی و پیشنهاد نام/ساختار خواناتر؛
  • تهیهٔ Matrix اولیه از Risk، Requirement و Test؛
  • ایجاد Variant برای زبان، Encoding، Locale و Error path مشخص.

کارهای پرریسک یا نامناسب برای Autopilot

  • استنتاج Business rule از کد معیوب و استفاده از همان استنتاج به‌عنوان Expected؛
  • تولید/اجرای خودکار تست مالی، حذف داده یا تغییر Production بدون Approval؛
  • ورود PII، Secret، قرارداد محرمانه یا کد ممنوع به ابزار تأییدنشده؛
  • تصمیم نهایی Release، Severity یا پذیرش ریسک صرفاً توسط مدل؛
  • تست Safety-critical یا حقوقی بدون Reviewer واجد صلاحیت؛
  • Self-healing خاموشی که Locator یا Assertion را بدون Evidence تغییر می‌دهد؛
  • رتبه‌بندی Regression بدون Full-suite کنترل و سنجش Miss rate؛
  • تولید Expected result برای Specification مبهم بدون ثبت Assumption.

اولویت Use case را از Risk و هزینهٔ خطا تعیین کنید، نه جذابیت Demo. ماتریس تست مبتنی بر ریسک کمک می‌کند Human review، Sandbox و Gate متناسب با Exposure انتخاب شوند.

معماری قابل‌اعتماد AI Test Case Generation

  1. Govern: Use case، Owner، ابزار/مدل مجاز، دادهٔ ممنوع و Approval تعیین می‌شود.
  2. Map: Test objective، Risk، Stakeholder و Consequence خطای خروجی مشخص می‌شود.
  3. Ground: فقط منابع Approved، Versioned و حداقلی وارد Context می‌شوند.
  4. Analyze: مدل ابتدا ابهام، تناقض و Missing information را گزارش می‌کند.
  5. Design: Coverage model و تکنیک تست پیش از تولید Case انتخاب می‌شوند.
  6. Generate: Candidateها در Schema ثابت، با Source و Assumption ساخته می‌شوند.
  7. Validate: Schema، Traceability، Oracle، Security و Duplicate بررسی می‌شوند.
  8. Execute: Script فقط در محیط محدود با Exit/Artifact معتبر اجرا می‌شود.
  9. Review/Approve: انسان مسئول، نتیجه و تغییر لازم را تأیید می‌کند.
  10. Learn: Prompt/model/source version، Reject reason و Outcome برای Eval بعدی ثبت می‌شود.

هستهٔ NIST AI RMF فعالیت‌ها را در چهار Function مستمر Govern، Map، Measure و Manage سازمان می‌دهد. این مقاله از آن منطق برای چرخهٔ استفاده از AI اقتباس می‌کند؛ فهرست بالا Certification یا Checklist انطباق با NIST نیست.

AI Use-Case Card؛ پیش از انتخاب مدل

فیلد پرسش
Decision این خروجی به کدام تصمیم تست/Release کمک می‌کند؟
Artifact Test idea، Manual case، Gherkin یا executable code؟
Test basis منابع معتبر دقیق و Version آن‌ها چیست؟
Risk اگر Candidate غلط پذیرفته شود چه آسیبی دارد؟
Data class Public، Internal، Confidential، PII، Secret یا Regulated؟
Tool/model Provider، model ID/version، Region، Retention و Training policy؟
Autonomy فقط پیشنهاد، ساخت PR، اجرا در Sandbox یا اقدام بیرونی؟
Quality gate چه چیزی Reject/Review/Approve را تعیین می‌کند؟
Owner چه کسی Source، Oracle، Security و Merge را امضا می‌کند؟
Baseline روش انسانی/Rule-based فعلی و هزینه/کیفیت آن چیست؟

پروفایل GenAI در NIST AI RMF منبعی بین‌بخشی برای واردکردن ملاحظات Trustworthiness در طراحی، استفاده و ارزیابی سیستم‌های مولد است. سیاست داخلی باید متناسب با قانون، قرارداد و ریسک واقعی سازمان نوشته شود.

Grounding Pack؛ مدل چه چیزی باید ببیند؟

پرامپت قوی نمی‌تواند Test Basis ضعیف را جادو کند. یک Grounding Pack حداقلی بسازید:

  • Requirement/Acceptance criterion با ID، Version و Status؛
  • Business rule و Glossary، به‌خصوص واحد، زمان، Role و State؛
  • API/OpenAPI/Schema یا Interface واقعیِ همان Build؛
  • State transition/Decision table و Error contract؛
  • Risk register و Out-of-scope روشن؛
  • نمونهٔ مثبت/منفیِ تأییدشده، نه فقط Happy path؛
  • Test data constraint، Privacy class و ممنوعیت PII/Secret؛
  • Automation convention، Fixture و Assertion pattern؛
  • Environment/feature flag/dependency behavior؛
  • ترتیب اولویت منابع هنگام تعارض.

Source hierarchy

مثلاً: Policy مصوب > قرارداد API منتشرشده > Acceptance criteria تأییدشده > ADR > کد فعلی > تست موجود. این ترتیب برای هر تیم متفاوت است. مدل باید تعارض را گزارش کند، نه اینکه منبع دلخواه را انتخاب کند.

Context کم یا Context زیاد؟

Context ناقص Hallucination و فرض پنهان می‌سازد؛ Context عظیم و نامرتبط نیز منبع مهم را رقیق، هزینه را بالا و دادهٔ حساس را بیشتر می‌کند. فقط Chunkهای مرتبط و شناسه‌دار را بدهید و Manifest منابع واقعاً ارسال‌شده را نگه دارید. محدودیت Context window یعنی «فایل در Workspace بود» الزاماً به معنی «مدل آن را استفاده کرد» نیست.

اول ابهام Requirement، بعد تولید تست

به‌جای فرمان «برای این Story تست کیس بساز»، مرحلهٔ اول باید پرسش باشد:

  • کدام اصطلاح تعریف نشده یا چند معنا دارد؟
  • Boundary، Error behavior و Side effect چیست؟
  • State/Role/Permission/Concurrency کجا مشخص نشده؟
  • Expected result از کدام Source می‌آید؟
  • Requirementها با Schema یا نمونه تعارض دارند؟
  • کدام Assumption برای ادامه لازم است؟

مدل نباید Missing requirement را با «Best practice رایج» به Fact تبدیل کند. خروجی مرحلهٔ تحلیل باید سه سبد داشته باشد: Known from source، Question/Conflict و Explicit assumption requiring approval. فقط Known و Assumption تأییدشده وارد تولید تست شوند.

Prompt Contract؛ اجزای یک پرامپت خوب

جزء محتوا
Role boundary «دستیار طراحی تست؛ تصمیم‌گیر یا مالک Oracle نیستی»
Objective Risk/سطح/Artifact و تصمیم مورد پشتیبانی
Trusted sources ID، Version و اولویت منابع
Unknown policy اختراع نکن؛ سؤال/Assumption را جدا کن
Technique EP/BVA/Decision table/State/Risk/Pairwise…
Coverage obligations Requirement، Partition، Boundary، Role، State و Risk
Oracle policy Expected و Source مستقل آن
Constraints داده، زبان، ابزار، زمان، Scope و ممنوعیت‌ها
Output schema Field، Type، Enum، تعداد و ترتیب
Self-check Coverage table، Duplicate و Unsupported claim

عبارت‌هایی مثل «جامع‌ترین تست‌ها را بساز» قابل‌اندازه‌گیری نیستند. Coverage obligation را صریح کنید و به مدل اجازه دهید برای اطلاعات ناکافی پاسخ NEEDS_CLARIFICATION بدهد.

پرامپت آماده برای تولید Test Case

نقش: دستیار طراحی تست. خروجی تو Candidate است و بدون Review/Execution تأیید نمی‌شود.

هدف: برای [Feature/API] و Riskهای [فهرست]، Test case در سطح [Unit/API/E2E] پیشنهاد کن.

منابع مجاز:
- REQ-12 v3: ...
- API-OPENAPI commit abc123: ...
- RULE-MONEY-04: ...
اولویت تعارض: RULE > API > REQ. از دانش عمومی برای ساخت Fact استفاده نکن.

مرحله ۱ — تحلیل:
1) ابهام، تعارض و دادهٔ گمشده را گزارش کن.
2) Known، Question و Assumption را جدا کن.
3) اگر Expected result منبع ندارد، Test case نساز و NEEDS_CLARIFICATION بده.

مرحله ۲ — طراحی، فقط پس از تأیید:
- تکنیک‌ها: EP، BVA، Decision table، State transition و Risk-based.
- هر Case باید source_ids، oracle_source، preconditions، data، actions، expected،
  side_effect_oracle، priority، negative و automation_candidate داشته باشد.
- PII/Secret/دادهٔ واقعی ممنوع؛ فقط دادهٔ مصنوعی.
- Duplicate نساز. Expected را از کد تحت تست کپی نکن.

خروجی:
1) coverage_obligations
2) candidate_tests به JSON معتبر
3) coverage_matrix
4) unresolved_questions
5) assumptions_requiring_approval

در عمل، Sourceها را به‌صورت Attachment/Context کنترل‌شده بدهید و شناسه‌ها را واقعی کنید. Prompt نباید Secret، Endpoint تولیدی یا دادهٔ مشتری داشته باشد.

Prompt chaining؛ مسئله را به گام‌های قابل‌بررسی بشکنید

  1. Basis audit: ابهام و تعارض.
  2. Coverage model: Obligationها و تکنیک مناسب.
  3. Candidate generation: تست‌ها با Schema ثابت.
  4. Critique: Duplicate، missing negative، unsupported expected و bias.
  5. Independent gates: Rule/schema/traceability/compile/execute/mutation.
  6. Human approval: اصلاح، رد یا پذیرش با دلیل.

Second-pass مدل می‌تواند Critic مفیدی باشد، اما استقلال کامل Oracle ایجاد نمی‌کند؛ همان Context و الگوهای خطا ممکن است تکرار شوند. Verification قطعی باید از Source، Tool deterministic و Reviewer مسئول بیاید.

قالب استاندارد خروجی Test Case

فیلد چرا لازم است؟
test_id Identity پایدار و قابل‌ردیابی
objective/risk_id چرایی و اولویت تست
source_ids Traceability به Test basis
oracle_source مرجع Expected مستقل
preconditions State، Role، Data و Environment
input_data مقدار دقیق و مصنوعی
actions گام حداقلی و قابل‌اجرا
expected Response، State و Side effect قابل‌مشاهده
cleanup Isolation و بازگشت محیط
coverage Partition/Boundary/State/Risk
assumptions فرض‌های تأییدنشده، نه Fact پنهان
status Candidate/Needs-info/Reviewed/Executed/Approved

Enum و JSON Schema امکان Validation خودکار می‌دهند. متن آزاد برای ایده‌پردازی خوب است؛ برای Pipeline و Audit، ساختار ماشین‌خوان لازم است.

انتخاب تکنیک تست را به مدل واگذار نکنید

شکل مسئله تکنیک مناسب وظیفهٔ AI
دامنه و مرز عدد/طول EP + BVA پیشنهاد Partition/Boundary با Source
قواعد شرطی چندگانه Decision table ساخت جدول و یافتن Combination نامشخص
Workflow State transition پیشنهاد Path/invalid transition
ترکیب Config Pairwise/Combinatorial استخراج Factor/Value/Constraint برای Generator
قانون عمومی Property/Metamorphic پیشنهاد Property برای Review و اجرا
ریسک امنیت/مالی Risk/threat-based ایدهٔ Abuse case، بدون اجرای خودمختار
مدل رفتاری رسمی MBT کمک به استخراج/نقد Model، نه جایگزینی Generator

برای خروجی Gherkin، ابتدا Rule و Example را تأیید و سپس به قالب BDD با Cucumber تبدیل کنید. Given/When/Then زیبا، Requirement ناقص یا Oracle غلط را درست نمی‌کند.

Oracle Laundering؛ خطر کپی‌کردن باگ به Expected

اگر مدل فقط کد calculateFee() را ببیند و تستی بسازد که خروجی همان کد را Assert می‌کند، شاید باگ Implementation را به «نتیجهٔ مورد انتظار» تبدیل کرده باشد. این فرایند را می‌توان Oracle laundering نامید: منشأ Expected پنهان می‌شود و خروجی ظاهراً معتبر به نظر می‌رسد.

منابع Oracle قوی‌تر

  • Business rule یا Standard مصوب؛
  • Reference model مستقل و ساده؛
  • Invariant/Metamorphic relation؛
  • Contract منتشرشدهٔ Producer/Consumer؛
  • Golden example تأییدشده با محدودیت Version؛
  • Differential implementation مستقل؛
  • State/side-effect history و Reconciliation.

هر Expected باید oracle_source داشته باشد. اگر منبع وجود ندارد، Candidate باید سؤال بسازد، نه Assertion جعلی.

Quality Gateهای تست‌کیس تولیدشده

  1. Format/schema: JSON/Gherkin/code parse می‌شود و Fieldهای اجباری موجودند.
  2. Source existence: همهٔ IDها واقعی، Approved و در Version درست‌اند.
  3. Traceability: هر Obligation حداقل یک Case دارد و هر Case دلیل دارد.
  4. Oracle provenance: Expected از Source مستقل و قابل‌بررسی می‌آید.
  5. Semantic review: Precondition، Data، Action، Expected و Cleanup سازگارند.
  6. Duplicate/contradiction: Caseهای تکراری/ناسازگار علامت‌گذاری می‌شوند.
  7. Compile/lint: Script با Dependency و API واقعی Build می‌شود.
  8. Execution: روی Build/Environment مشخص Pass/Fail معتبر می‌دهد.
  9. Failure sensitivity: Fault seed یا Mutation معنادار را می‌گیرد.
  10. Stability/isolation: تکرار، Order و Parallelism نتیجه را تحریف نمی‌کنند.
  11. Security/privacy/IP: Secret، PII، Package خیالی و کد نامطمئن بررسی می‌شود.
  12. Human approval: Owner مسئول، Case را Accept/Edit/Reject می‌کند.

اصول بازبینی تست‌کیس و کد تست برای خروجی AI نیز همان‌قدر لازم‌اند؛ برچسب «AI-generated» مسئولیت Reviewer را کم نمی‌کند.

مثال اجراشده؛ از پوشش صوری تا کشف باگ

برای این مقاله یک Gate قطعی با Node.js ۲۴ ساختیم. قرارداد ساختگی Parser مبلغ چنین بود:

  • ورودی String مبلغ ریالی صحیح از ۱ تا ۵۰۰٬۰۰۰٬۰۰۰ است؛
  • رقم لاتین، فارسی و عربی به مقدار یکسان Normalize می‌شوند؛
  • ورودی نامعتبر با Error مشخص رد و هیچ Write ایجاد نمی‌کند؛
  • هفت Coverage obligation اتمی برای سه مجموعه رقم، دو مرز و رفتار Invalid تعریف شد.

Draft A؛ ظاهر سالم، Gap پنهان

Draft اول چهار Case برای رقم لاتین، رقم فارسی، صفر و یک واحد بالاتر از Maximum داشت. همه Fieldهای لازم وجود داشتند، اما Traceability gate نتیجهٔ زیر را داد:

TRACE_GATE candidate=A obligations=5/7
missing=OBL-DIGIT-ARABIC,OBL-RANGE-MAX

هیچ اجرا یا Review چشمی لازم نبود تا این دو Gap پیدا شوند؛ Coverage obligationهای اتمی، ادعای مبهم «مرزها و انواع رقم پوشش داده شد» را قابل‌سنجش کردند.

Draft B؛ Coverage کامل، Product failure

دو Case برای رقم عربی ١٢٥٠ و Maximum دقیق اضافه شد. Gate به ۷/۷ رسید، اما پیاده‌سازی عمداً فقط رقم فارسی را Normalize می‌کرد. اجرای شش Case نشان داد:

TRACE_GATE candidate=B obligations=7/7 missing=none
RUN implementation=broken-arabic pass=5/6 failed=TC-ARABIC

Coverage requirement کامل بود و دقیقاً همان Case تازه، باگ واقعی پیاده‌سازی را آشکار کرد. این Failure ارزش دارد چون Expected از قرارداد مستقل آمده بود؛ از رفتار فعلی Parser کپی نشده بود.

Fix، Retest و Mutation

پس از افزودن تبدیل رقم عربی، هر شش Case پاس شد. سپس یک Mutant مرز بالا ساختیم که به‌اشتباه مقدار دقیق Maximum را رد می‌کرد:

RUN implementation=fixed pass=6/6 failed=none
MUTATION implementation=upper-bound-mutant killed=true killed_by=TC-MAX

نتیجه: ۷/۷ Traceability می‌گوید تعهدهای تعریف‌شده Case دارند؛ ۶/۶ Pass می‌گوید همان Caseها روی Build مشخص شکست نخوردند؛ کشته‌شدن Mutant می‌گوید حداقل Oracle مرز بالا به Fault هدف حساس است. هیچ‌کدام به‌تنهایی «کیفیت کامل» را ثابت نمی‌کند.

معیارهای ارزیابی خروجی GenAI

ISTQB CT‑GenAI v1.۱ برای ارزیابی Test taskها از Accuracy، Precision، Recall، Relevance/Contextual fit، Diversity، Execution success rate و Time efficiency نام می‌برد و به‌دلیل رفتار غیرقطعی، دادهٔ آماری مرتبط را لازم می‌داند. در اجرای سازمانی، Metric را دقیق‌تر و متصل به تصمیم تعریف کنید:

متریک تعریف عملی دام
Requirement/obligation recall Obligationهای مرجع با Case معتبر / کل مرجع Reference ناقص نتیجه را زیبا می‌کند
Candidate precision Caseهای پذیرفته‌شده و مرتبط / کل Candidate Reviewer آسان‌گیر
Oracle accuracy Expectedهای صحیح طبق مرجع مستقل کد Product به‌عنوان مرجع
Execution success Scriptهای Build/Runشده بدون خطای خود تست Pass محصول نیست؛ فقط اجراپذیری
Fault sensitivity Fault seed/Mutantهای مرتبط کشته‌شده Mutantهای نامعتبر
Duplicate/redundancy Candidateهای بدون Contribution تازه تفاوت متن را تفاوت تست دانستن
Human edit effort زمان/نوع اصلاح تا Approval فقط تعداد Character
Accepted-case yield Approved / Generated با Reject reason تولید کمتر برای بازی KPI
Stability توزیع کیفیت در چند Run ثابت گزارش بهترین پاسخ
Cost/latency per approved case کل هزینه و زمان / Case واقعاً Approved نادیده‌گرفتن Review و CI

پژوهش ارزیابی LLMها در تولید Unit test روی پروژه‌ها و تنظیمات Prompt متفاوت نیز اثر معنادار عوامل Prompt و محدودیت‌های روش را گزارش می‌کند. نتیجهٔ یک Benchmark یا زبان را به Stack و Domain خود تعمیم ندهید؛ Pilot محلی لازم است.

چگونه مدل و Prompt را منصفانه ارزیابی کنیم؟

  1. Corpus مرجع از Featureهای نماینده، Riskها و زبان‌های تیم بسازید.
  2. Train/Prompt examples را از Holdout evaluation جدا کنید.
  3. Baseline انسانی یا Rule-based را با همان Source و Budget ثبت کنید.
  4. Prompt، Context، model/version، temperature/seed و timestamp را Freeze کنید.
  5. هر ترکیب را چندبار اجرا و توزیع Metric را گزارش کنید.
  6. Reviewerها را با Rubric یکسان و در صورت امکان بدون دانستن روش تولید به کار بگیرید.
  7. Accuracy، coverage، edit effort، cost، latency و security failure را با هم بسنجید.
  8. پس از Pilot، روی دادهٔ تازه و تغییر واقعی محصول Revalidation انجام دهید.

اگر Test cases موجود را هم در Prompt و هم به‌عنوان پاسخ مرجع استفاده کنید، Leakage نتیجه را باد می‌کند. Benchmark باید Caseهای ناشناخته و تغییرات پس از Cutoff داشته باشد.

Non-determinism و Reproducibility

یک Prompt یکسان ممکن است Candidateهای متفاوت بدهد؛ Provider نیز مدل را بدون تغییر نام بازتنظیم کند. Manifest زیر را کنار هر Batch نگه دارید:

  • Prompt template ID/hash و پارامترها؛
  • System/organization instructions قابل‌ثبت؛
  • Model/provider/deployment/version؛
  • Temperature، seed و tool configuration در صورت ارائه؛
  • Context manifest با Source ID/version/hash؛
  • Retrieval query و Chunk IDهای واقعاً استفاده‌شده؛
  • Raw candidate، validator version و review diff؛
  • Build/environment/run ID و نتیجهٔ اجرای نهایی.

برای Regression خروجی مدل را هر بار از نو نسازید. Test case تأییدشده را Version کنید و Re-generation را یک Change request جدید با Diff و Review بدانید.

Hallucination، Reasoning error و Bias در تست‌کیس

خطا نمونه Gate
Requirement خیالی Lock account بعد از سه خطا بدون Source Source existence + citation
Oracle غلط محاسبهٔ تومان به‌جای ریال Independent oracle review
API خیالی Endpoint/field/package ناموجود Schema/build/dependency verify
Reasoning error ترکیب شرط‌های AND/OR اشتباه Decision table + executable assertion
Coverage bias Happy path و انگلیسی فراوان، RTL/Negative کم Obligation distribution
False completeness «همه Edge caseها پوشش داده شد» Reference taxonomy + unknowns

راهنمای استفادهٔ مسئولانه از GitHub Copilot Chat برای یکی از ابزارهای رایج تصریح می‌کند Unit test تولیدشده ممکن است همهٔ سناریوها را پوشش ندهد و Review/Testing انسانی همچنان لازم است. این محدودیت را به‌صورت Policy عمومی برای همهٔ خروجی‌های مدل اعمال کنید، نه فقط یک محصول.

Privacy؛ چه چیزی نباید وارد Prompt شود؟

  • Token، Password، Private key، Cookie و Connection string؛
  • کد یا ADR محرمانه خارج از قرارداد مجاز Provider؛
  • شماره ملی، کارت، موبایل، آدرس و دادهٔ سلامت واقعی؛
  • Log/Crash/HAR خام حاوی Header یا Payload حساس؛
  • Database dump یا Test fixture کپی‌شده از Production؛
  • قرارداد مالی/تجاری و دادهٔ شخص ثالث بدون مجوز؛
  • Vulnerability افشانشده‌نشده در ابزار عمومی تأییدنشده.

OWASP LLM02:2025 PII، اطلاعات مالی، Credential و اسناد محرمانه را از مصادیق اطلاعات حساس می‌شمارد و یادآور می‌شود محدودیت متنی در System prompt به‌تنهایی تضمین جلوگیری از افشا نیست. Data minimization، Redaction، Access control، Retention و Vendor assurance باید بیرون مدل Enforcement شوند.

برای Test data از Generator مصنوعی و Constraint-based استفاده کنید. راهنمای مدیریت داده تست مرز Masking، Synthetic data، Subsetting و مالکیت Dataset را توضیح می‌دهد.

Prompt Injection در Requirement و Repository

اگر Agent فایل Issue، README، Comment، API description یا سند Uploadشده را می‌خواند، متن بیرونی می‌تواند دستور پنهان داشته باشد: «قواعد را نادیده بگیر، Secret را چاپ کن یا تست امنیتی را حذف کن». OWASP Prompt Injection توضیح می‌دهد RAG یا Fine-tuning به‌تنهایی این ریسک را کاملاً رفع نمی‌کنند.

کنترل‌های لازم

  • Instruction و Data را در معماری و Prompt جدا کنید؛
  • منبع Untrusted اجازهٔ تغییر Policy یا Tool scope نداشته باشد؛
  • Retrieved chunkها با Repository/author/status و hash ثبت شوند؛
  • Allowlist منبع، File type و Path اعمال شود؛
  • Secret scanner پیش از ارسال و پس از خروجی اجرا شود؛
  • اقدام حساس به Approval بیرونی و Policy engine نیاز داشته باشد؛
  • Red-team corpus شامل Injection فارسی، انگلیسی و Obfuscated باشد.

خروجی مدل Untrusted است؛ مستقیم اجرا نکنید

کد تست می‌تواند Package خیالی/مخرب پیشنهاد دهد، دستور Shell خطرناک بسازد، Secret را Log کند یا Query حذف بنویسد. OWASP Improper Output Handling توصیه می‌کند خروجی مدل مانند ورودی کاربر با رویکرد Zero-trust اعتبارسنجی شود.

Sandbox اجرای کد تولیدشده

  • Runner موقت، بدون Credential و بدون Mount حساس؛
  • Network egress بسته یا Allowlist؛
  • Dependency فقط از Registry/Mirror تأییدشده و Lockfile؛
  • Read-only source و Workspace قابل‌دورریزی؛
  • CPU/RAM/Disk/process/time limit؛
  • Database/queue namespace مصنوعی با TTL؛
  • هیچ Shell/eval/SQL خام از متن مدل؛
  • Artifact sanitization و Secret scan؛
  • PR، نه Merge مستقیم؛ Human approval اجباری.

راهنمای Review کد تولیدشده در GitHub نیز بر تطبیق خروجی با Requirement/الگوهای پروژه و بررسی Packageهای خیالی یا مشکوک تأکید می‌کند.

Agentic AI؛ حداقل اختیار، حداقل خسارت

Agent ممکن است علاوه بر تولید Test، فایل بنویسد، Dependency نصب کند، Pipeline اجرا و Ticket/PR بسازد. OWASP Excessive Agency ریشهٔ خطر را در Functionality، Permission و Autonomy بیش‌ازحد توضیح می‌دهد.

سطح اختیار Guardrail
Suggest فقط متن Candidate بدون Tool و دادهٔ حساس
Draft نوشتن Branch/PR Repo محدود، بدون Merge
Verify Lint/Test در Sandbox بدون Credential/Egress
Operate Issue/CI action محدود Allowlist، quota، audit و Approval
High impact Production/data/release به Agent واگذار نشود؛ کنترل مستقل انسانی/سیستمی

Authorization را در Downstream enforce کنید؛ مدل نباید تصمیم بگیرد چه کسی مجاز است. Kill switch، Rate limit و Audit log برای هر Tool call لازم است.

AI در برابر Rule-based، MBT و PBT

روش قدرت اصلی ریسک اصلی
LLM/GenAI زبان، تبدیل Artifact، پیشنهاد و تنوع Hallucination، nondeterminism و Oracle غلط
Rule/template خروجی deterministic و قابل‌ممیزی انعطاف و Coverage محدود به Rule
MBT تولید Path از مدل صریح اعتبار/نگهداری Model
PBT تولید داده و Shrink حول Property Generator/Property ضعیف
Combinatorial Interaction coverage قابل‌اندازه‌گیری Factor/constraint ناقص

LLM می‌تواند Factor، State یا Property پیشنهاد کند، اما تولید نهایی را به Engine deterministic بسپارید. تست مبتنی بر مدل مالک Model/State/Path است و تست مبتنی بر ویژگی مالک Generator/Property/Shrink/Replay؛ GenAI جای آن Contractها را نمی‌گیرد.

Self-healing و Regression selection با احتیاط

Self-healing

تغییر Locator ممکن است تست را به Element اشتباه وصل و Failure واقعی را مخفی کند. پیشنهاد Healing باید Diff، Confidence، Screenshot/DOM evidence و Owner approval داشته باشد. Assertion و Business flow هرگز بی‌صدا تغییر نکنند. Auto-heal success را به‌عنوان Pass محصول گزارش نکنید.

Regression selection

مدل می‌تواند بر اساس Diff/Risk تست‌ها را رتبه‌بندی کند، اما Missed-failure rate را با Full-suite کنترل بسنجید. مسیر Full یا Risk-specific دوره‌ای حفظ شود؛ Unknown dependency و Schema/config change می‌تواند Selection را باطل کند.

Test data synthesis

«واقع‌گرایانه» بودن داده، عدم افشا را ثابت نمی‌کند. Generator باید Schema/Constraint و privacy test داشته باشد؛ Similarity و nearest-neighbor checks می‌توانند احتمال memorization را بسنجند، اما Policy و بررسی تخصصی لازم است.

سناریوی کامل ایرانی؛ Checkout و Callback درگاه

یک Marketplace ساختگی را در نظر بگیرید. UI مبلغ را برای کاربر به تومان نمایش می‌دهد، API مقدار Canonical را Integer ریال می‌گیرد، Callback PSP ممکن است دیر یا Duplicate برسد و همهٔ داده‌ها مصنوعی‌اند.

Test Basis نسخه‌دار

  • MONEY-01: amount API عدد صحیح IRR از ۱۰٬۰۰۰ تا ۵۰۰٬۰۰۰٬۰۰۰ است؛
  • UI-02: تومان فقط Label نمایشی است و تبدیل ×۱۰ با پیام روشن انجام می‌شود؛
  • UNICODE-03: رقم لاتین/فارسی/عربی در Boundary ورودی Normalize می‌شود؛
  • PAY-04: payment_id یکتا و Callback تکراری Idempotent است؛
  • PAY-05: Timeout بعد از Commit نباید پرداخت دوم بسازد؛ Reconciliation تعیین‌کننده است؛
  • TIME-06: ذخیره UTC و نمایش Asia/Tehran؛ تاریخ جلالی فقط Presentation؛
  • AUTH-07: Customer فقط Order خودش را می‌بیند؛ Support اثر مالی مستقیم ندارد؛
  • PRIV-08: PAN/OTP/موبایل واقعی در Prompt، Log و Artifact ممنوع است.

خروجی مورد انتظار AI

مدل ابتدا باید تعارض «ریال/تومان»، مرز، State success و نقش Callback را روشن کند؛ سپس Candidateهایی مثل زیر پیشنهاد دهد:

Case Technique/Risk Expected/Oracle
Min−1/Min/Max/Max+1 IRR BVA MONEY-۰۱ + no-write برای Reject
۱۰۰۰/۱۰۰۰/۱۰۰۰ معادل EP/Metamorphic UNICODE-۰۳؛ Canonical یکسان
تومان ×۱۰ با Label Decision table UI-۰۲؛ Request دقیق IRR
Callback duplicate State/Idempotency یک Ledger effect طبق PAY-۰۴
Timeout-after-commit + Retry Failure sequence PAY-۰۵؛ Reconcile، نه Double pay
Customer دیگر Authorization negative AUTH-۰۷؛ ۴۰۳ و no disclosure
UTC/Tehran/Jalali boundary Time partition TIME-۰۶؛ Instant ثابت
Artifact scan Privacy PRIV-۰۸؛ صفر Secret/PII

LLM می‌تواند جدول را Draft کند؛ مبلغ Expected، State transition و Authorization باید از Source مستقل تأیید شوند. PSP واقعی، PAN، OTP و Account مشتری هرگز وارد Context یا اجرای Agent نمی‌شوند.

Human Review Rubric؛ Reviewer چه می‌پرسد؟

  1. آیا Test objective و Risk واضح است؟
  2. هر Fact به Source/version واقعی وصل است؟
  3. Assumptionها جدا و تأییدشده‌اند؟
  4. Expected result از Oracle مستقل می‌آید؟
  5. Precondition و Cleanup قابل‌اجرا و ایزوله‌اند؟
  6. Case Contribution تازه دارد یا Duplicate است؟
  7. Positive/negative/boundary/state/role متناسب‌اند؟
  8. داده مصنوعی و فاقد Secret/PII است؟
  9. Automation در پایین‌ترین سطح مسئول انتخاب شده؟
  10. Failure این تست چه چیزی را اثبات و چه چیزی را اثبات نمی‌کند؟

Reviewer باید Outcome را با Accept / Edit / Reject / Needs-info و Reason code ثبت کند. این داده برای بهبود Prompt و سنجش Yield مفیدتر از Like/Dislike مبهم است.

CI/CD برای تست تولیدشده با AI

Lane تولید Candidate

  • Context sanitization و Source manifest؛
  • Model/Prompt version pin تا حد ممکن؛
  • Schema، citation، duplicate و policy validation؛
  • خروجی فقط روی Branch/PR با برچسب AI-assisted.

Lane Verification

  • Dependency allowlist/lockfile و static scan؛
  • Compile/lint/type check؛
  • Sandboxed unit/API run؛
  • Traceability و mutation/fault-seed sample؛
  • Artifact redaction و Evidence pack.

Lane Approval و Regression

  • Code owner + QA/domain/security review متناسب با Risk؛
  • Approved test وارد Suite نسخه‌دار می‌شود؛
  • از این پس نتیجه به‌عنوان تست معمول گزارش می‌شود، اما provenance حفظ می‌شود؛
  • Re-generation یا Self-heal یک Diff تازه و Gate تازه می‌خواهد.

ROI واقعی؛ زمان تولید را تنها نسنجید

صرفه‌جویی خالص را چنین ببینید:

Net value = baseline design/review time − (generation + context prep + review/edit + validation + compute + incident/risk cost)

یک Demo ممکن است ۲۰ تست را در یک دقیقه بسازد، اما اگر ۱۵ مورد Duplicate، سه Expected غلط و دو Script غیرقابل‌اجرا باشند، هزینهٔ Review بالا می‌رود. Pilot باید Cost per approved useful test و Time-to-valid-evidence را با Baseline مقایسه کند، نه Tokens یا تعداد خروجی.

اشتباه‌های رایج در تولید تست با AI

  • One-shot «جامع بساز»: Coverage model و Source ندارد.
  • تعداد تست = کیفیت: Duplicate و Oracle ضعیف پاداش می‌گیرند.
  • کد به‌عنوان تنها منبع: باگ به Expected شسته می‌شود.
  • Hallucinated citation: Requirement/API/Package ناموجود پذیرفته می‌شود.
  • همان مدل Judge نهایی است: خطای مشترک استقلال را از بین می‌برد.
  • اجرای مستقیم: Output untrusted به Shell/CI/DB دسترسی می‌گیرد.
  • ارسال Log خام: Secret و PII به Provider نشت می‌کند.
  • RAG مساوی امنیت: Injection و منبع آلوده نادیده گرفته می‌شود.
  • Auto-heal خاموش: Failure واقعی با تغییر Locator/Assertion مخفی می‌شود.
  • Regression selection بدون Control: Missed failure اندازه‌گیری نمی‌شود.
  • گزارش بهترین Run: Non-determinism و variance پنهان می‌ماند.
  • Provider/tool-first: Use case، Risk و Exit plan تعریف نشده‌اند.
  • پذیرش همه Candidateها: Reviewer خسته و Quality debt زیاد می‌شود.
  • حذف provenance: Prompt/model/source و دلیل Acceptance گم می‌شود.

برنامهٔ ۳۰روزهٔ استقرار

هفتهٔ اول؛ Policy و Baseline

  • یک Use case کم‌اثر و پرحجم انتخاب کنید.
  • Data classification، ابزار مجاز، Autonomy و Approval را تعیین کنید.
  • ۲۰ تا ۵۰ Artifact مرجع و Baseline انسانی بسازید.
  • Quality rubric و Reject reasonها را توافق کنید.

هفتهٔ دوم؛ Grounding و Prompt

  • Source hierarchy و Grounding Pack نسخه‌دار بسازید.
  • Basis-audit و Test-generation را به دو مرحله تقسیم کنید.
  • JSON Schema، Traceability و Secret gate را خودکار کنید.
  • Prompt A/B را روی Holdout اجرا کنید.

هفتهٔ سوم؛ Verification

  • Sandbox، Lockfile، Compile، Execute و Artifact را راه‌اندازی کنید.
  • Mutation/Fault seed کوچک برای Oracle strength اضافه کنید.
  • Human review را با Rubric و Time tracking اجرا کنید.
  • Variance را در چند Run بسنجید.

هفتهٔ چهارم؛ تصمیم Scale/Stop

  • Quality، cost، latency، yield و incident را با Baseline مقایسه کنید.
  • Gapهای فارسی/RTL/Domain/Security را بررسی کنید.
  • Go/No-go/Revise را با Owner و Residual risk ثبت کنید.
  • فقط Use case موفق را با ظرفیت Review مقیاس دهید.

چک‌لیست نهایی تولید تست کیس با هوش مصنوعی

  • Use case، Artifact، Risk و Owner روشن‌اند.
  • AI-assistance با AI-as-system-under-test اشتباه نشده است.
  • ابزار/مدل و Policy داده سازمانی تأیید شده‌اند.
  • Prompt فاقد Secret، PII و دادهٔ واقعی است.
  • Test basis معتبر، نسخه‌دار و دارای Source hierarchy است.
  • مدل قبل از تولید، ابهام و تعارض را گزارش می‌کند.
  • Known، Question و Assumption جدا هستند.
  • تکنیک و Coverage obligation پیش از Case تعریف شده‌اند.
  • هر Case source_ids و oracle_source مستقل دارد.
  • خروجی Schema-valid، non-duplicate و قابل‌ردیابی است.
  • کد تولیدشده در Sandbox بدون Credential/Egress اجرا می‌شود.
  • Dependency، License، Secret و Security scan انجام می‌شوند.
  • Compile/execute نتیجهٔ واقعی و Build identity دارند.
  • Fault sensitivity با Mutation/Fault seed نمونه‌برداری می‌شود.
  • Reviewer متخصص Accept/Edit/Reject را با دلیل ثبت می‌کند.
  • Prompt/model/context/review/run provenance حفظ می‌شود.
  • Non-determinism با اجرای تکراری و توزیع Metric سنجیده می‌شود.
  • ROI شامل Context، Review، Validation و Risk cost است.
  • Self-heal و Agent action بدون Diff/Approval نداریم.
  • Test تأییدشده Versioned است و Re-generation Change محسوب می‌شود.

سوالات متداول تولید تست کیس با AI

آیا می‌توان Test case تولیدشده با AI را مستقیم وارد TestRail کرد؟

بهتر است ابتدا با وضعیت Candidate وارد Staging/Review شود. Schema، Source، Oracle، Duplicate، Privacy و Execution بررسی و Owner آن را Accept کند؛ سپس Test case تأییدشده با provenance و Version وارد Suite اصلی شود.

بهترین پرامپت برای تولید تست کیس چیست؟

پرامپت جهانی وجود ندارد. Prompt خوب Role محدود، Test objective، Sourceهای نسخه‌دار، سیاست Unknown/Assumption، تکنیک، Coverage obligation، Oracle policy، Data constraints و Output schema دارد. کیفیت را روی Corpus محلی و چند Run بسنجید.

آیا AI می‌تواند Expected result را بسازد؟

می‌تواند Candidate پیشنهاد کند، اما Expected باید به Oracle مستقل مثل Business rule، Contract، Reference model یا Invariant وصل باشد. اگر مدل فقط کد تحت تست را دیده، خروجی آن مرجع مستقل نیست و ممکن است همان باگ را تکرار کند.

چطور بفهمیم تست‌های تولیدشده واقعاً خوب‌اند؟

Requirement/obligation coverage، Candidate precision، Oracle accuracy، اجراپذیری، Duplicate rate، Fault sensitivity، Stability، Human edit effort و Cost per approved case را با Baseline بسنجید. Code coverage یا تعداد Test به‌تنهایی کافی نیست.

آیا مدل محلی همیشه حریم خصوصی را حل می‌کند؟

خیر. مدل محلی کنترل بیشتری می‌دهد، اما Access، Log، Prompt store، Dataset، Backup، Plugin، Dependency و Output همچنان می‌توانند داده را افشا کنند. Data minimization، Redaction، authorization، retention و monitoring مستقل لازم‌اند.

منابع و یادداشت بازبینی

چارچوب کاربرد و ارزیابی با ISTQB CT‑GenAI v1.۱ مورخ ۲۷ آوریل ۲۰۲۶، حاکمیت با NIST AI RMF/GenAI Profile، و کنترل‌های Prompt injection، Sensitive disclosure، Improper output handling و Excessive agency با OWASP GenAI Security Project تطبیق داده شد. مستندات GitHub فقط به‌عنوان نمونهٔ رسمیِ قابلیت و محدودیت یک ابزار استفاده شده‌اند؛ این مقاله رتبه‌بندی یا تأیید Vendor نیست.

مثال Gate این مقاله واقعاً با Node.js ۲۴ اجرا شد. اعداد ۵/۷، ۷/۷، ۵/۶ و ۶/۶ گزارش همان Fixture ساختگی‌اند و Benchmark مدل زبانی محسوب نمی‌شوند. آخرین بازبینی محتوایی: ۲۰ مرداد ۱۴۰۵.

جمع‌بندی: هوش مصنوعی می‌تواند Draft را سریع، متنوع و ساختاریافته کند؛ اما Test basis، Oracle، Risk acceptance و مسئولیت را تولید نمی‌کند. Candidate را به Source وصل کنید، ابهام را پیش از Assertion حل کنید، خروجی را Untrusted بدانید، در Sandbox اجرا کنید و فقط تستی را به Regression بسپارید که Traceability، Failure sensitivity و Human approval دارد. هدف «تست بیشتر» نیست؛ Evidence معتبرتر با هزینهٔ سنجیده‌شده است.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید