۲۴۰ Check کارکردی از ۲۴۰ Check سبز است. پنج آیتم چکلیست «Performance، Security، Reliability، Usability و Scalability» هم تیک خورده و میانگین Latency برابر ۲۸۰ms است. آیا محصول از نظر کیفیت آماده است؟ نه لزوماً. هنوز نمیدانیم این عدد برای کدام Stakeholder، Workflow، بار، Percentile، Environment، Build، بازهی مشاهده و Oracle است؛ Tail latency، خطای کسبوکاری، شرایط Degraded و Trade-offها نیز پنهاناند.
این راهنما «تست غیرعملکردی» را از فهرست ابزار و نوع تست به یک زنجیرهی تصمیم تبدیل میکند: Stakeholder Concern → Quality Attribute Scenario → NFR Contract → Measurement Contract → Evidence Profile → Result → Trade-off/Exception → Decision/Correction. خروجی، یک ادعای کیفیت محدود و قابلردیابی است؛ نه تضمین موفقیت محصول.
پاسخ کوتاه: تست غیرعملکردی چیست؟
تست غیرعملکردی یا Non-Functional Testing مجموعهای از فعالیتهای ارزیابی است که دربارهی ویژگیهای کیفی محصول، سیستم یا تجربه در Context مشخص Evidence میسازد. سؤال فقط «چقدر خوب؟» نیست؛ باید بپرسیم برای چه کسی، کدام Artifact، در پاسخ به چه Stimulus، تحت چه شرایطی، چه Response قابلاندازهگیری و با چه محدودیتی؟
| عبارت مبهم | پرسش قابلبررسی |
|---|---|
| سیستم سریع باشد | کدام Journey، تحت چه Workload، در کدام Percentile و Measurement point؟ |
| امن باشد | کدام Asset/Threat/Control، در چه Scope و با کدام Test method؟ |
| پایدار باشد | در برابر کدام Fault، برای چه Window، با چه Recovery و Data integrity؟ |
| کاربرپسند باشد | کدام Segment/Task/Context، با چه Success/Error/Effort measure؟ |
| مقیاسپذیر باشد | با تغییر کدام Load/Resource، کدام Service level و هزینه حفظ شود؟ |
مالکیت این مقاله و مرز با راهنماهای تخصصی
راهنمای عمومی تست غیرکارکردی تعریف، انواع و فرایند کلی را مالک است. تست Performance Workload/Latency/Throughput/Saturation، تست امنیت Threat/Control/RoE، معیارهای کاربردپذیری Task/SUS/Study design و برنامه دسترسپذیری Policy/WCAG/Evidence را پوشش میدهند. مالکیت این صفحه، قرارداد مشترکی است که هر Quality Attribute را از Concern به Scenario، Measure و Evidence تبدیل میکند.
| نیاز خواننده | مقصد | خروجی |
|---|---|---|
| انواع NFR چیست؟ | مقاله ۵۸۹ | نقشهی انواع و مراحل |
| Load/Stress را چگونه اجرا کنم؟ | مقاله ۶۴۴ | Performance test plan |
| Security/Usability/A11y تخصصی | ۶۶۵/۷۷۴/۱۸۲۳ | Protocol حوزهای |
| NFR چگونه قابلتصمیم شود؟ | همین مقاله | Scenario/Measure/Evidence/Trade-off contract |
Functional و Non-functional مرز آهنی ندارند
تقسیم سادهی «چه کاری» و «چقدر خوب» برای آموزش اولیه مفید است، اما در عمل میشکند. قفلکردن حساب پس از چند تلاش، حفظ یک Effect در Callback تکراری، ارائهی متن جایگزین و رد دسترسی بدون مجوز هم رفتار قابلمشاهده دارند و هم به Security، Reliability یا Accessibility مربوطاند. یک Test میتواند هم Functional correctness و هم Quality Attribute را بسنجد.
- نام NFR بهتنهایی Level، Technique یا Automation method را تعیین نمیکند.
- Performance بدون Correctness میتواند پاسخ اشتباه را خیلی سریع تحویل دهد.
- Security فقط یک «نوع تست غیرعملکردی» در انتهای کار نیست؛ Requirementهای رفتاری دارد.
- Usability و Accessibility را با Response time جایگزین نکنید.
- Maintainability/Testability ممکن است با Analysis، Review و Instrumentation هم Evidence بگیرند.
Quality Attribute، NFR، Metric، SLO و Test یکسان نیستند
| مفهوم | نقش | نمونهی محدود |
|---|---|---|
| Quality Attribute | دسته یا خاصیت کیفیت | Reliability |
| Stakeholder Concern | نگرانی زمینهمند | Callback تکراری اثر مالی دوم نسازد |
| NFR/Quality Scenario | رفتار و Measure مورد انتظار در Context | در Peak+Dependency degraded، Effect تکراری صفر |
| Metric/Measure | عملیاتیسازی مشاهده | duplicate-effect ratio |
| Target/Threshold | مرز تصمیم برای Scenario | نسبت صفر در Population تعریفشده |
| SLO/Operational objective | هدف سرویس در Window عملیاتی | با Policy و Budget مستقل |
| Test/Evaluation | روش ساخت Evidence | Workload + fault + invariant oracle |
مدل کیفیت، فهرست خرید یا گواهی انطباق نیست
صفحهی عمومی ISO/IEC 25010:2023 میگوید مدل Product Quality شامل ۹ Characteristic و Subcharacteristicهایشان است و میتواند برای Specification، Measurement و Evaluation استفاده شود. این صفحه، متن کامل استاندارد را در اختیار نمیگذارد؛ استفاده از نام Categoryها بهتنهایی اثبات پیادهسازی کامل استاندارد یا انطباق نیست. نسخهی ۲۰۱۱ نیز Withdrawn شده است، پس نسخهی مرجع را Pin کنید.
مدل کیفیت کمک میکند Blind spotها را بپرسیم، اما همهی Characteristicها برای هر Release وزن برابر ندارند. Domain، Product goal، User segment، Risk، Architecture و تعهدها تعیین میکنند کدام Scenario محرک تصمیم است.
از Stakeholder و Context of Use شروع کنید
«کاربر» یک Persona واحد نیست. مشتری با اینترنت ناپایدار، اپراتور پشتیبانی، کاربر Screen Reader، تیم عملیات، توسعهدهندهی نگهدارنده، خریدار سازمانی و Risk owner Concernهای متفاوتی دارند. Threshold بدون Stakeholder و Decision need ممکن است عددی دقیق اما بیمعنا باشد.
StakeholderConcern {
stakeholderId, segment, jobToBeDone,
qualityConcern, harmIfMissed, decisionNeed,
authority, contextOfUse,
accessibilityNeed, locale, timezone,
assumptions, unknowns, evidenceRef
}
Quality Attribute Scenario شش جزء پایه دارد
SEI در قالب Quality Attribute Scenario شش جزء را جدا میکند: Source of stimulus، Stimulus، Environment، Artifact، Response و Response measure؛ مرجع اولیه: گزارش فنی SEI درباره Quality Attribute Scenarios. این مقاله Stakeholder، Basis، Priority، Scope، Version، Evidence و Governance را برای استفادهی تستی به آن اضافه میکند؛ این افزودهها را استاندارد SEI معرفی نمیکنیم.
| جزء | پرسش | نمونهی خیالی |
|---|---|---|
| Source | چه کسی/چیزی رویداد را ایجاد میکند؟ | PSP Stub |
| Stimulus | چه وضعیت/رویدادی رخ میدهد؟ | Callback تکراری و دیررس |
| Environment | در چه حالت عملیاتی؟ | Peak مصنوعی + Dependency degraded |
| Artifact | کدام بخش تحریک میشود؟ | Checkout callback handler |
| Response | سیستم چه واکنشی نشان دهد؟ | Deduplicate، Reconcile و Feedback محدود |
| Response Measure | چگونه پاسخ سنجیده شود؟ | p95 و duplicate-effect ratio با Guardrail |
قالب NFR قابلکپی
QualityScenario {
scenarioId, qualityModel/version,
stakeholderConcernId, characteristic/subcharacteristic,
source, stimulus, environment, artifact,
response, responseMeasure,
scope, exclusions, preconditions,
operatingMode, degradedMode, frequency,
priority, rationale, basisRef,
ownerCapability, version, digest
}
یک جملهی Given/When/Then میتواند View مفیدی باشد، اما Contract اصلی را به متن آزاد تقلیل ندهید. شناسه، Version و Digest لازماند تا Result بعدی دقیقاً به همان Scenario متصل شود.
Operating condition و Degraded mode را صریح کنید
Threshold بدون Condition اعتبار کمی دارد. Normal، Peak، Ramp، Maintenance، Partial dependency failure، Cache cold، Failover، Retry storm، low bandwidth یا assistive technology Contextهای متفاوتاند. «دنیای واقعی» یک Environment تعریفشده نیست؛ Profile قابل بازسازی لازم است.
| Condition | Fieldهای لازم | Claim limit |
|---|---|---|
| Normal | Workload mix، rate، data state | Peak/Failure را پوشش نمیدهد |
| Peak | Arrival model، duration، ramp، contention | Growth آینده را ثابت نمیکند |
| Degraded dependency | Fault، timeout، retry، recovery | همهی Dependency failures را نمایندگی نمیکند |
| Cold state | Cache/connection/JIT state | Steady state را نتیجه نمیدهد |
| Accessible workflow | AT/browser/input/context | همهی کاربران یا معیارها را پوشش نمیدهد |
Threshold را Tester یا AI از خود اختراع نکند
منبع Threshold میتواند تعهد، Policy، Research معتبر، User need، Hazard/Risk analysis، Baseline مقایسهپذیر، ظرفیت Dependency یا Experiment کسبوکار باشد. هر عدد باید Source، Authority، Assumption، تاریخ اعتبار و Revisit trigger داشته باشد. «زیر دو ثانیه چون Best Practice است» Requirement کافی نیست.
| نوع مرز | کاربرد | نباید با آن اشتباه شود |
|---|---|---|
| Baseline | آنچه قبلاً اندازهگیری شده | هدف مطلوب |
| Target | مقدار مطلوب | حد پذیرش/Block |
| Threshold | مرز Verdict برای Scenario | Guarantee آینده |
| Guardrail | جلوگیری از بهبود یک Metric با آسیب دیگر | Metric فرعی تزئینی |
| Budget | سهم تخصیصیافته در زنجیره | Result کل سیستم |
| SLO | هدف عملیاتی در Window/Population | Test threshold بدون Mapping |
Measurement Contract؛ نام Metric کافی نیست
Latency، Availability، Error rate یا Task success بدون تعریف عملیاتی قابل مقایسه نیستند. نقطهی شروع/پایان، Population، Sample frame، Unit، Aggregation، Window، Clock، Missing data، Warmup، Outlier، Collector و Uncertainty را ثبت کنید. Average میتواند Tail را پنهان کند؛ Percentile نیز بدون Sample و Window قابل تفسیر نیست.
MeasurementContract {
measureId, construct, operationalDefinition, unit,
population, sampleFrame, aggregation, percentile,
target, threshold, guardrails,
observationWindow, warmup, measurementPoint, clock,
collector, collectorVersion, calibration,
missingDataRule, outlierRule, uncertainty,
oracleId, version, digest
}
Population، Sample و Denominator را Pin کنید
«۹۹٪ موفقیت» بدون Denominator معلوم نیست دربارهی Request، Journey، User، Session یا Minute صحبت میکند. Retry موفق میتواند Failure اولیه را پنهان کند؛ Timeout client ممکن است در Server success ثبت شود. Exclusion و Invalid attempt را پیش از مشاهدهی نتیجه تعریف کنید، نه برای سبزکردن Dashboard.
| Field | نمونه | دام |
|---|---|---|
| Population | تمام Attemptهای معتبر Checkout در Run | فقط Responseهای دریافتشده |
| Numerator | Attemptهای Oracle-correct | HTTP 2xx بدون Business correctness |
| Denominator | Started attempts طبق Manifest | حذف Timeout/Abort |
| Invalid rule | Harness failure با Evidence | هر نتیجهی نامطلوب |
| Retry semantics | Original + retry chain | فقط آخرین Attempt |
Workload Profile را از «کاربر همزمان» فراتر ببرید
عدد Concurrent user بدون مدل Arrival، Think time، Journey mix، Session، Payload، Cache، Data cardinality، Ramp و Duration مبهم است. ۵۰۰۰ کاربر برای یک محصول ممکن است زیاد، کم یا بیمعنا باشد. در Performance تخصصی، Workload Model و Open/Closed model را دقیقتر دنبال کنید.
WorkloadProfile {
profileId, source, validityWindow,
arrivalModel, journeyMix, rate/concurrency,
thinkTime, payloadDistribution, dataCardinality,
ramp, steadyWindow, duration,
retryPolicy, cacheState, geography/network,
assumptions, exclusions, digest
}
Correctness Oracle را در تست NFR حفظ کنید
Load generator ممکن است پاسخ ۲۰۰ و Latency خوب ببیند، درحالیکه Ledger effect تکراری، داده گم یا پاسخ stale است. NFR Result باید Oracle کارکردی/دامنهای را کنار Measure کیفیت اجرا کند. برای طراحی منبع Expected و Verdict، راهنمای Test Oracle را ببینید.
- Latency را فقط برای پاسخهای Oracle-valid یا با تفکیک Result class گزارش کنید.
- Error rate فنی را از Business failure جدا کنید.
- Timeout client، completion server و side effect را به یک Attempt chain وصل کنید.
- Guardrailهای Integrity، Security و Accessibility را کنار Metric هدف نگه دارید.
- Fast failure را Success performance حساب نکنید.
Evidence Profile از فهرست Test Type بهتر است
نوشتن «Load + Security + Usability test» نمیگوید چه Claimی باید بررسی شود. Evidence Profile با Question و Counterclaim شروع میکند، سپس Method، Level، Workload، Environment، Data، Dependency، Instrumentation، Attempt plan، Stop condition و Artifactهای مورد انتظار را مشخص میکند.
EvidenceProfile {
evidenceProfileId, scenarioId,
question, counterclaim,
method, level,
workloadProfileId, environmentProfileId,
dataProfileId, dependencyProfileId,
instrumentationProfileId,
attemptPlan, stopConditions, safetyBoundary,
expectedArtifacts, manifestSchema,
retention, access, redaction,
limitations, digest
}
Evidence را در چند Level تخصیص دهید
همهی Attributeها در یک End-to-End Test بزرگ سنجیده نمیشوند. Static analysis، Component benchmark، Contract test، fault injection، System/load test، usability study، accessibility review و operational exercise Evidenceهای مکمل میسازند. Level را براساس Object/Boundary/Question انتخاب کنید، نه نام NFR؛ چارچوب تخصیص در راهنمای Test Level Allocation آمده است.
| Question | Evidence زودهنگام | Evidence نمایندهتر | Gap محتمل |
|---|---|---|---|
| Latency handler | Component benchmark | System workload | Network/DB contention |
| Recovery | State-machine/Component fault | Dependency outage exercise | Operational procedure |
| Accessibility | Lint/component review | AT × Browser + complete process | Content/user context |
| Security | Review/SAST/unit control | DAST/manual scenario | Threat/identity/environment |
| Maintainability | Static/architecture evidence | Timed change exercise | Team/tool familiarity |
Environment Fidelity را Claimمحور تعریف کنید
Production-like یک وضعیت دودویی نیست. Compute، Network، Dependency، Data distribution، Scale، Config، Identity، Clock و Observability Fidelity جدا دارند. کمبود Fidelity Result را خودکار بیارزش نمیکند؛ باید Limitation، Bias direction احتمالی و Compensation را بنویسید.
| بُعد | Profile | Evidence محدودکننده |
|---|---|---|
| Scale | نسبت به Target و Bottleneck | Capacity extrapolation uncertainty |
| Dependency | Real/Stub/Replay/Fault model | Contract و Failure-mode gap |
| Data | Distribution/Cardinality/State | Production data لازم نیست |
| Network | Latency/loss/DNS/TLS/path | Localhost نتیجهی WAN نیست |
| Observability | Sampling/schema/collector overhead | Measurement effect |
Stop condition و Safety Boundary قبل از اجرا
Stress، fault injection و Security test میتوانند داده، سرویس یا افراد را آسیب بزنند. Scope، نرخ، محیط مجاز، Kill switch، Owner، Monitoring، abort threshold، cleanup، legal/policy approval و Incident path را پیشاپیش تعریف کنید. «نقطه شکست واقعی» را در Production بدون Authority و Guardrail دنبال نکنید.
Quality Attributeها با هم تعامل و تعارض دارند
Cache ممکن است Latency را بهتر و Freshness را بدتر کند؛ Encryption میتواند Security را تقویت و هزینه/Latency را تغییر دهد؛ Audit logging میتواند Traceability را بالا ببرد و Privacy/Performance را تحت فشار بگذارد؛ Retry میتواند Availability ظاهری را بهتر و Duplicate effect را بیشتر کند. هدف Maxکردن همهی Attributeها نیست؛ تصمیم Trade-off با Guardrail و Authority لازم است.
QualityTradeoff {
tradeoffId, scenarioIds[], attributeA, attributeB,
decisionQuestion, optionSet,
benefitHypothesis, costHypothesis, riskHypothesis,
experimentId, guardrails,
authority, rationale, evidenceRefs,
expiry, revisitTrigger, digest
}
یک Scenario سبز، کل Characteristic را سبز نمیکند
قبولی یک Journey در یک Window فقط همان Population/Build/Environment/Method را پوشش میدهد. Characteristicهایی مثل Reliability یا Security مجموعهی بزرگی از Concernها هستند. Coverage model باید Scenario population، Risk، Attribute interaction، شرایط عملیاتی، Platform/Segment و Evidence gap را نشان دهد؛ Dashboard «Performance: سبز» بیشازحد خلاصه است.
Result Contract و واژگان Verdict
NFRResult {
resultId, scenarioId, buildId,
runIds[], attemptCount, validAttemptCount,
observedMeasure, threshold, guardrailObserved,
verdict: PASS | FAIL | INCONCLUSIVE | INVALID | NOT_RUN,
confidenceRationale, unknowns, limitations,
evidenceManifestId, exceptions, residualRisk,
supersedes, digest
}
Unknown مساوی Pass نیست. INVALID دربارهی اعتبار Run است، نه کیفیت Product. INCONCLUSIVE یعنی Evidence برای Verdict کافی نیست. NOT_RUN را از Not applicable جدا کنید. PASS نیز Claim محدودی دربارهی Scenario میدهد، نه Quality یا Release.
Exception، Residual Risk و Release Decision
Failشدن NFR خودکار Release را Block نمیکند مگر Policy از پیش چنین Gateای تعریف کرده باشد؛ سبزشدن همهی Resultهای موجود نیز خودکار Approval نیست. Missing scenario، Evidence gap، Exception، Benefit، Dependency و Residual risk باید به Authority مناسب برسند. چارچوب تصمیم را در کیفیت بهاندازه کافی خوب و Release Decision ببینید.
| Record | مالک/Authority | حد ادعا |
|---|---|---|
| Test Result | Evidence owner | Scenario/Run |
| Exception | Policy-defined authority | Scope + expiry + condition |
| Residual Risk | Risk owner | شناختهشده و زماندار |
| Release recommendation | Capability تعریفشده | پیشنهاد، نه تصمیم |
| Release decision | Decision authority | بر پایه Evidence/Benefit/Risk |
Change Trigger و Freshness برای NFR
Workload، User segment، Dependency، Architecture، Runtime، Data distribution، Collector، Threshold source یا Policy که تغییر کند، Result قبلی ممکن است stale شود. هر Scenario/Measure/Evidence Profile باید Change trigger و Validity window داشته باشد. بازاجرای کور همهی Testها تنها راه نیست؛ Impact assessment لازم است.
Correction و Traceability نتیجه
اگر بعداً Collector خطا داشت، Percentile اشتباه محاسبه شد یا Sample ناقص بود، Result را بیصدا ویرایش نکنید. Correction باید Result قبلی را Supersede، دلیل و Evidence تازه را ثبت و تصمیمها/داشبوردهای متاثر را پیدا کند.
NFRCorrection {
correctionId, supersededResultId,
trigger, reason, affectedFields,
correctedMeasure, newEvidenceManifestId,
affectedDecisionQuery, ownerCapability,
publishedAt, priorDigest, newDigest
}
آزمایشگاه فارسی: Checkout خیالی و تعامل کیفیتها
این Lab کاملاً ساختگی و جدا از هر شرکت، بانک، PSP، کاربر، پرداخت یا سامانهی واقعی است. شبکه یا Production واقعی ندارد و توصیهی بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی یا انطباق ایران نیست. Objectهای خیالی شامل Order، PaymentAttempt، PSP Stub، Callback Event، Ledger Entry، Reconciliation Job و Notification هستند.
| Concern | Stimulus/Environment | Response/Measure | Guardrail |
|---|---|---|---|
| Latency + Reliability | Callback تکراری/دیررس در Peak+degraded stub | p95≤450ms و duplicate effect=۰ | Error≤۱% و Ledger effect گم نشود |
| Usability | وضعیت Pending برای Segment خیالی | Feedback قابلفهم در Task protocol | Accessibility path حفظ شود |
| Localization | ارقام فارسی/عربی/لاتین و RTL/LTR | Parse/render مطابق Oracle | Canonical value تغییر نکند |
| Time | UTC instant و View تهران | ترتیب Event حفظ شود | Jalali فقط Presentation |
مبالغ کاملاً خیالی با Currency canonical برابر IRR و نمای تومانِ صریحاً برچسبخوردهاند. Tenant/Order/Attempt/Event/Ledger/Run/Build/Evidence شناسههای جدا دارند. هیچ نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی وجود ندارد؛ Unicode با NFC و زمان با UTC instant + Asia/Tehran view کنترل میشود.
Fixture: ۲۴۰ Check سبز در برابر ۱۸۵ Finding
Fixture مستقل و بدون Dependency بیرونی `SYN-NFR-QUALITY-SCENARIO-EVIDENCE-۰۱` با Node.js اجرا شد. Dashboard سطحی ۲۴۰/۲۴۰ Functional Check، پنج از پنج NFR checklist و Average latency برابر ۲۸۰ms را دید و `QUALITY_PASS` اعلام کرد. ممیزی ۱۸۶قاعدهای، همان ورودی را با دقیقاً ۱۸۵ Finding به HOLD برد.
| گروه | تعداد قاعده | نمونهی الزام |
|---|---|---|
| Identity | 16 | Model/NFR set/Build/Environment/Data |
| Stakeholder | 14 | Concern/Context/Harm/Decision |
| Scenario | 20 | Source/Stimulus/Environment/Artifact/Response/Measure |
| Measure | 22 | Population/Percentile/Window/Clock/Uncertainty |
| Evidence Profile | 20 | Question/Counterclaim/Profiles/Stop/Safety |
| Trade-off | 16 | Options/Hypotheses/Guardrails/Authority |
| Result | 18 | Runs/Attempts/Measure/Verdict/Limit |
| Governance | 18 | Owner/Exception/Risk/Correction |
| Forbidden + Relations | 42 | مطلقگویی و اتصال بین Contractها |
نسخهی اصلاحشده `NFR-PROFILE-SYN-۳۰` را به Build/Data/Environment ثابت وصل کرد، Stakeholder خیالی را مشخص ساخت، Scenario تکرار Callback را در Peak+Degraded نوشت، p95 و Duplicate-effect ratio را با Population/Window/Oracle/Guardrail تعریف کرد، Evidence Profile و Trade-off سرعت در برابر Reliability/Auditability را ثبت کرد و سه Run معتبر را به Result متصل ساخت. خروجی `READY_FOR_NFR_EVIDENCE_REVIEW` با صفر Finding بود؛ نه اثبات Truth، کفایت Threshold، پوشش کامل Attribute، ایمنی، انطباق، کیفیت Product یا Release.
ابزار را بعد از سؤال انتخاب کنید
| نیاز Evidence | قابلیت ابزار | خطر انتخاب لوگومحور |
|---|---|---|
| Workload قابلبازسازی | Arrival/mix/data/manifest | VU زیاد بدون مدل |
| Tail measurement | Histogram/percentile/raw refs | Average-only dashboard |
| Correctness | Domain oracle/invariant | HTTP status-only |
| Fault/Recovery | Safe injection/timeline/reset | Failure بدون کنترل |
| Human quality | Protocol/segment/task/evidence | Automation score جای مطالعه |
| Traceability | Profile/Scenario/Run/Result IDs | Screenshot و PDF جداافتاده |
Automation و CI برای NFR
Checkهای ارزان و تکرارپذیر را در Feedback lane مناسب قرار دهید؛ Experimentهای پرهزینه، مخرب یا آماری را با Cadence و Environment جدا اجرا کنید. Threshold noise، Baseline drift، shared-environment contention و Collector change میتوانند Flaky gate بسازند. هر Run باید Manifest، Exit semantics و Artifact identity داشته باشد.
AI چه کمکی میکند و کجا متوقف میشود؟
AI میتواند Concernها را خوشهبندی، Scenario/Counterclaim پیشنهاد، Log/Metric را خلاصه، Missing field را پیدا یا Experiment draft تولید کند. AI نباید Threshold بیمنبع بسازد، داده/شاهد جعل کند، Secret/PII دریافت کند، Outlier نامطلوب را حذف کند، انطباق اعلام کند یا Exception/Residual risk/Release را بپذیرد. Model/prompt/input/version و Human decision را قابلردیابی نگه دارید.
معیارهای برنامه NFR و Countermetricها
| Metric | کاربرد | Countermetric |
|---|---|---|
| Scenario readiness | درصد Scenarioهای دارای Contract | Stakeholder/attribute blind spots |
| Evidence freshness | سن Result معتبر | بازاجرای پرهزینه/بیریسک |
| Invalid run rate | سلامت Harness/Environment | نتایج نامطلوب Misclassified |
| Unknown age | پیری ابهامها | Unknownهای prematurely closed |
| Exception expiry | انقضای بدهی پذیرفته | Reopen/escape rate |
| Decision latency | زمان Evidence تا تصمیم | Evidence sufficiency/correction |
| Attribute interaction coverage | Trade-offهای بررسیشده | پیچیدگی و هزینهی تست |
۳۴ Anti-pattern تست غیرعملکردی
- Functional pass را Product quality دانستن.
- NFR را فقط «چقدر خوب» تعریفکردن.
- همهی NFRها را Performance دانستن.
- Security را فقط یک Test type انتهایی دانستن.
- یک Threshold برای همهی کاربران.
- Average latency بهجای Distribution.
- Concurrent user بدون Workload model.
- Production-like را Production-equivalent دانستن.
- Production data را الزامی دانستن.
- Tool result را اثبات Attribute دانستن.
- ۵۰۰۰ User را خودکار واقعبینانه دانستن.
- ۴۸ ساعت را اثبات Reliability دانستن.
- Stress test را ظرفیت حقیقی نهایی دانستن.
- Zero finding را اثبات Security دانستن.
- SUS را اثبات Accessibility دانستن.
- Automation را پوشش کامل NFR دانستن.
- Shift-left را تضمین کاهش هزینه دانستن.
- Early test را تضمین پیشگیری از Failure دانستن.
- NFR testing را تضمین موفقیت کسبوکار دانستن.
- نبود NFR test را علت قطعی شکست کسبوکار دانستن.
- Attributeها را مستقل دانستن.
- Maxکردن همزمان همهی Attributeها.
- یک Scenario سبز را سبزی Characteristic دانستن.
- یک Scenario قرمز را خرابی Architecture دانستن.
- نام ISO category را اثبات Compliance دانستن.
- Checklist completion را Readiness دانستن.
- Telemetry را خودکار Test evidence دانستن.
- کپی آزاد Telemetry تولید.
- Threshold ساختن با AI.
- Risk acceptance با AI.
- هر Failure را Block خودکار دانستن.
- همهسبز را Release approval دانستن.
- Unknown را Pass دانستن.
- نبود Measurement را نبود Risk دانستن.
چکلیست ۳۲نقطهای NFR Owner
| حوزه | کنترل |
|---|---|
| Context | Goal/Risk/Stakeholder/Segment/Job/Concern/Harm/Decision روشن است؟ |
| Model | Quality model و نسخه فقط Taxonomy است، نه Compliance claim؟ |
| Scenario | Source/Stimulus/Environment/Artifact/Response/Measure کامل است؟ |
| Scope | Operating/Degraded mode، Preconditions، Exclusions و Frequency ثبت است؟ |
| Threshold | Source/Authority/Assumption/Validity/Revisit دارد؟ |
| Measure | Definition/Unit/Population/Sample/Aggregation/Window/Clock روشن است؟ |
| Validity | Warmup/Missing/Outlier/Calibration/Uncertainty تعریف شده؟ |
| Oracle | Correctness و Guardrail کنار Metric هدفاند؟ |
| Profiles | Workload/Environment/Data/Dependency/Instrumentation versioned هستند؟ |
| Execution | Attempt/Stop/Safety/Reset/Manifest مشخص است؟ |
| Trade-off | Option/Hypothesis/Guardrail/Evidence/Authority/Expiry دارد؟ |
| Result | Scenario/Build/Runs/Verdict/Unknown/Limit/Evidence متصلاند؟ |
| Decision | Exception/Residual risk/Release authority جدا هستند؟ |
| Freshness | Change trigger/Correction/Affected-decision query وجود دارد؟ |
Pilot سیروزه NFR
| بازه | کار | خروجی/Guardrail |
|---|---|---|
| روز ۱–۵ | یک Goal/Risk و سه Stakeholder Concern | بدون Catalogue بیمرز |
| روز ۶–۱۰ | سه Quality Scenario و Threshold source | Unknown و Exclusion صریح |
| روز ۱۱–۱۵ | Measurement/Evidence Profile | Population/Oracle/Safety |
| روز ۱۶–۲۰ | سه Run و Result Contract | Manifest + valid attempts |
| روز ۲۱–۲۵ | یک Trade-off/Exception/Correction drill | Authority + expiry |
| روز ۲۶–۳۰ | بازبینی Metric و Scale/Adapt/Stop | Countermetric + claim limits |
قالب نهایی NFR Evidence Packet
NFR Evidence Packet 1) Goal/Risk + Stakeholder Concern + Decision need 2) Quality model/version + Scenario ID/version 3) Source/Stimulus/Environment/Artifact/Response/Measure 4) Measurement Contract + threshold source + guardrails 5) Workload/Environment/Data/Dependency/Instrumentation Profiles 6) Evidence question + counterclaim + method/level/attempt plan 7) Build/Run/Attempt identities + Evidence Manifest 8) Result/Verdict + uncertainty/unknowns/limitations 9) Trade-off/Exception/Residual Risk + Authority/expiry 10) Claim limit + Change triggers + Correction path
جمعبندی
تست غیرعملکردی با خرید ابزار یا تیکزدن چند Category بالغ نمیشود. از Concern یک Stakeholder در Context واقعی شروع کنید، آن را به Quality Scenario قابلنسخهبندی تبدیل کنید، Measure و Threshold را عملیاتی و منبعدار بنویسید، Correctness/Guardrail را حفظ کنید، Evidence را میان Levelها تخصیص دهید و Result را به Build/Run/Manifest محدود کنید. Trade-off، Unknown، Exception و Correction بخش خود کیفیتاند؛ حذف آنها فقط Dashboard را سبزتر میکند.
سؤالات متداول
تفاوت تست عملکردی و غیرعملکردی چیست؟
Functional testing معمولاً رفتار/قاعدهی مورد انتظار را بررسی میکند و Non-functional testing برای Quality Attribute در Context Evidence میسازد؛ اما مرز مطلق نیست. یک تست Callback میتواند هم Correctness اثر و هم Latency/Reliability را همزمان بسنجد.
چگونه NFR قابلآزمایش بنویسیم؟
Stakeholder/Concern را به Source، Stimulus، Environment، Artifact، Response و Response Measure تبدیل کنید؛ سپس Scope، Population، Threshold source، Guardrail، Profileهای اجرا، Oracle، Evidence و Claim limit را نسخهدار اضافه کنید.
آیا تست غیرعملکردی همان Performance Testing است؟
خیر. Performance یکی از حوزههای کیفیت است. Security، Reliability، Compatibility، Usability/Interaction، Accessibility، Maintainability و دیگر Concernها روش و Measureهای متفاوت دارند. حتی دستهبندی باید با مدل و نسخهی انتخابشده Pin شود.
بهترین زمان شروع تست غیرعملکردی چه زمانی است؟
Concern و Scenario را هنگام کشف Goal/Risk شروع کنید؛ Evidence مناسب را در طول چرخه و در Levelهای مختلف بسازید. این به معنای اجرای همهی تستهای پرهزینه در روز اول نیست. زمان، Fidelity و Cadence باید براساس سؤال، Risk و Feedback budget انتخاب شود.
قبولی همهی NFRها یعنی محصول آمادهی انتشار است؟
نه. Resultها فقط Scenarioهای اجراشده را در Build/Environment/Window مشخص پوشش میدهند. Coverage gap، Unknown، Freshness، Functional evidence، Benefit، Dependency، Exception و Residual risk نیز در Release Decision دخیلاند و Authority آن باید از قبل تعریف شود.
