فرض کنید در User Story نوشته شده: «کاربر باید بتواند شماره موبایل معتبر وارد کند.» پیش از آنکه حتی یک خط کد نوشته شود، چند سؤال مهم بیپاسخ مانده است: اعداد فارسی پذیرفته میشوند؟ پیششماره کشور مجاز است؟ فاصله یا خط تیره چه؟ شماره تکراری چه رفتاری دارد؟ کشف این ابهامها با اجرای نرمافزار ممکن نیست، چون هنوز نرمافزاری وجود ندارد. اینجا تست استاتیک (Static Testing) ارزش خود را نشان میدهد.
تست استاتیک با بازبینی نیازمندی، طراحی، کد و سایر مصنوعات پروژه—بدون اجرای نرمافزار—عیبها را زودتر پیدا میکند. در این راهنما با تعریف، تفاوت تست ایستا و پویا، انواع Review، مراحل اجرای بازبینی، تحلیل استاتیک کد، ابزارها و یک مثال عملی متناسب با محصولات ایرانی آشنا میشوید.
فهرست مطالب
تست استاتیک (Static Testing) چیست؟
تست استاتیک روشی برای بررسی مصنوعات پروژه بدون اجرای کد یا نرمافزار است. این بررسی میتواند دستی، مانند بازبینی یک سند نیازمندی، یا با ابزار، مانند اجرای Linter و Static Application Security Testing، انجام شود. هدف، کشف عیب، ابهام، ناسازگاری، نقص استاندارد و ریسک در زمانی است که اصلاح آن هنوز سادهتر است.
در ادبیات رسمی ISTQB Foundation Level، دو خانواده اصلی فعالیتهای تست استاتیک عبارتاند از:
- بازبینی (Review): ارزیابی یک محصول کاری توسط انسان؛ مانند Review نیازمندی، طراحی یا کد؛
- تحلیل استاتیک (Static Analysis): ارزیابی ساختار و ویژگیهای مصنوع پروژه، معمولاً با ابزار و بدون اجرای آن.
تست استاتیک بخشی از تصویر بزرگتر تست نرمافزار است و بهتر است از نخستین مراحل چرخه توسعه آغاز شود. این رویکرد به «پیشگیری از عیب» کمک میکند، در حالی که تست پویا بیشتر رفتار عیب را هنگام اجرا آشکار میسازد.
تفاوت تست استاتیک و تست داینامیک چیست؟
| معیار | تست استاتیک (Static) | تست پویا (Dynamic) |
|---|---|---|
| اجرای نرمافزار | لازم نیست | لازم است |
| زمان شروع | از نیازمندی و طراحی | پس از وجود نسخه قابل اجرا یا جزء قابل تست |
| نمونه | Review سند، Code Review، Lint، SAST | تست واحد، API، UI، کارایی |
| عیبهای هدف | ابهام، تناقض، کد مرده، نقض استاندارد، آسیبپذیری احتمالی | رفتار اشتباه، Crash، پاسخ نادرست، کندی |
| خروجی رایج | یافته بازبینی، اصلاح سند/کد، گزارش ابزار | نتیجه Pass/Fail، لاگ اجرا، گزارش باگ |
| محدودیت | رفتار واقعی زمان اجرا را ثابت نمیکند | ممکن است علت ریشهای یا عیب سند را دیر آشکار کند |
این دو رویکرد مکمل یکدیگرند. برای مثال، ابزار تحلیل استاتیک میتواند مسیر کد غیرقابلدسترسی را گزارش کند، اما نشان نمیدهد کاربر در اینترنت ضعیف چه تجربهای دارد. در مقابل، تست پویا ممکن است پیام خطای مبهم را ببیند، اما Review زودهنگام میتوانست همان ابهام را پیش از توسعه از نیازمندی حذف کند.
چه چیزهایی را میتوان با تست استاتیک بررسی کرد؟
- Business Requirement، User Story و معیار پذیرش؛
- طرح معماری، مدل داده، قرارداد API و نمودار جریان؛
- Wireframe، Prototype و Design System؛
- کد برنامه، کد تست، اسکریپت مهاجرت و Infrastructure as Code؛
- Test Plan، Test Case، چکلیست و داده تست؛
- راهنمای کاربر، متن پیامهای خطا و مستندات عملیاتی؛
- تنظیمات، Policyهای امنیتی و فایلهای پیکربندی؛
- گزارش اختتام، Release Note و Runbook بازیابی.
بهطور کلی، هر خروجی قابلخواندن یا قابلتحلیل پروژه که معیار ارزیابی مشخصی داشته باشد، میتواند موضوع تست استاتیک باشد. این گستردگی باعث میشود تستر پیش از تحویل Build نیز بازخورد باارزش ارائه کند.
مزایا و محدودیتهای Static Testing
مزیتها
- کشف زودهنگام: ابهام نیازمندی یا نقص طراحی پیش از تکثیر در کد و تست پیدا میشود.
- کاهش دوبارهکاری: اصلاح یک جمله یا نمودار معمولاً از بازطراحی و انتشار Patch ارزانتر است.
- افزایش پوشش: مسیرهایی که اجرای آنها سخت است—مانند کد مرده یا تنظیمات خطا—قابل بررسی میشوند.
- همترازی تیم: Product، Design، Development، QA و Operations درک مشترکتری از رفتار مورد انتظار پیدا میکنند.
- بهبود قابلیت نگهداری: نقض استاندارد، پیچیدگی زیاد و تکرار زودتر شناسایی میشود.
- پشتیبانی از امنیت: الگوهای آسیبپذیر و افشای احتمالی Secretها پیش از Deploy گزارش میشوند.
- انتقال دانش: بازبینی ساختاریافته به یادگیری افراد تازهوارد و کاهش وابستگی به یک نفر کمک میکند.
محدودیتها
- رفتار واقعی سیستم در CPU، شبکه، مرورگر یا داده واقعی را نشان نمیدهد.
- کیفیت نتیجه به مهارت بازبین، معیارها و زمان اختصاصیافته وابسته است.
- ابزارها False Positive دارند و هر هشدار الزاماً باگ واقعی نیست.
- بازبینی طولانی و بدون دامنه روشن میتواند خستهکننده و کماثر شود.
- تبدیل Review به ارزیابی شخص نویسنده، همکاری و یادگیری را تضعیف میکند.
بنابراین، هدف حذف تست پویا نیست؛ هدف ساختن یک لایه دفاعی زودهنگام و ارزانتر در چرخه حیات تست نرمافزار است.
انواع بازبینی در تست استاتیک
میزان رسمیبودن Review باید با ریسک، پیچیدگی و الزامهای پروژه متناسب باشد. چهار شکل رایج عبارتاند از:
۱. بازبینی غیررسمی (Informal Review)
همکار سند یا تغییر را بررسی و بازخورد کوتاه میدهد؛ مثلاً Pair Review یا نظر روی Pull Request. فرایند سبک و سریع است، اما نقشها و معیارها ممکن است کاملاً مستند نباشند. برای تغییرات کمریسک مناسب است.
۲. مرور گامبهگام (Walkthrough)
نویسنده، مصنوع را برای گروه توضیح میدهد و بازخورد میگیرد. هدف علاوه بر کشف عیب، انتقال دانش و رسیدن به درک مشترک است. یک BA میتواند جریان سفارش را قدمبهقدم برای تیم مرور کند.
۳. بازبینی فنی (Technical Review)
افراد دارای تخصص فنی، انطباق راهحل با معیارها، معماری، استاندارد یا ریسک را ارزیابی میکنند. برای قرارداد API، طراحی دیتابیس، استراتژی اتوماسیون یا معماری امنیتی کاربرد دارد.
۴. بازرسی (Inspection)
رسمیترین نوع Review است: نقشها، فرایند، معیار ورود/خروج، چکلیست، ثبت یافته و دادههای بازبینی مشخصاند. در بخشهای حساس یا محیطهای نیازمند شواهد و انطباق، Inspection میتواند انتخاب مناسبی باشد.
مراحل اجرای یک Review مؤثر
۱. برنامهریزی
دامنه، هدف، مصنوع، نسخه، معیارها، شرکتکنندگان، زمان و روش ثبت یافتهها مشخص میشوند. سؤال کلیدی این است: «در این بازبینی دنبال چه نوع مشکلی هستیم؟»
۲. آغاز بازبینی
اطلاعات زمینه، دسترسی، اسناد مرجع، چکلیست و تعریف شدت یافتهها در اختیار بازبینها قرار میگیرد. اگر نسخه سند یا معیار پذیرش روشن نباشد، نتیجه قابلردیابی نخواهد بود.
۳. بازبینی فردی
هر بازبین مصنوع را مستقل بررسی و یافتهها را با مکان دقیق، دلیل و پیشنهاد روشن ثبت میکند. مطالعه فردی پیش از جلسه از تبدیل جلسه به خواندن گروهی خطبهخط جلوگیری میکند.
۴. ارتباط و تحلیل یافتهها
تیم یافتهها را ادغام، تکراریها را حذف و موارد اختلافی را روشن میکند. هدف حمله به نویسنده نیست؛ هدف بهبود محصول کاری است. درباره «اثر و معیار» صحبت کنید، نه سلیقه شخصی.
۵. اصلاح و گزارش
مالک مصنوع موارد پذیرفتهشده را اصلاح میکند. بسته به ریسک، بازبین یا مسئول Review اصلاح را تأیید میکند. نتیجه نهایی، موارد باز و درسآموختهها ثبت میشوند.
نقشهای رایج در Review
- Author: نویسنده یا مالک مصنوع؛
- Reviewer: فردی که عیب و ریسک را بررسی میکند؛
- Moderator/Facilitator: تسهیلگر فرایند و جلسه؛
- Scribe: ثبتکننده یافته و تصمیم؛
- Review Leader: مسئول برنامهریزی و نتیجه بازبینی؛
- Manager: فراهمکردن منابع و پیگیری بهبود فرایند.
در تیم کوچک ممکن است یک نفر چند نقش داشته باشد؛ مهم این است که مسئولیت تصمیم، ثبت و اصلاح مبهم نماند.
تحلیل استاتیک کد چیست و چه چیزی پیدا میکند؟
تحلیل استاتیک ساختار کد یا فایلهای فنی را بدون اجرای برنامه بررسی میکند. راهنمای تحلیل استاتیک کد برای تسترها این بخش را عمیقتر پوشش میدهد.
نمونه یافتههای قابلکشف
- متغیر، Import یا کد استفادهنشده؛
- نقض Coding Standard و فرمت ناسازگار؛
- پیچیدگی سایکلوماتیک بالا و تابع بیشازحد بزرگ؛
- مسیر غیرقابلدسترسی یا شرط همیشه درست/غلط؛
- مدیریت ناقص Null و خطای نوع؛
- وابستگی آسیبپذیر یا الگوی ناامن شناختهشده؛
- Secret، Token یا Password قراردادهشده در کد؛
- تکرار کد و بدهی فنی؛
- خطا در فایل پیکربندی، Dockerfile یا Infrastructure as Code.
دستههای رایج ابزار
| دسته | نمونه | کاربرد |
|---|---|---|
| Linter و Formatter | ESLint، Pylint، Ruff، Checkstyle | استاندارد، خطاهای رایج و یکدستی کد |
| تحلیل نوع | TypeScript، mypy، PHPStan | ناسازگاری نوع و Nullability |
| کیفیت کد | SonarQube، SonarCloud | Code Smell، پیچیدگی، تکرار و Quality Gate |
| SAST | Semgrep، CodeQL، ابزارهای تجاری | الگوهای آسیبپذیری امنیتی |
| وابستگی | Dependabot، npm audit، OWASP Dependency-Check | نسخهها و آسیبپذیری کتابخانهها |
| Secret Scanning | Gitleaks، TruffleHog | کلید و Secret ثبتشده در مخزن |
ابزار باید در IDE، Pre-commit یا CI/CD اجرا شود تا بازخورد سریع باشد. قوانین را مرحلهای و متناسب با پروژه فعال کنید؛ صدها هشدار قدیمی و بیاولویت باعث میشود تیم هشدارهای مهم را نیز نادیده بگیرد.
مثال عملی: بازبینی نیازمندی ثبتنام با شماره موبایل
نیازمندی اولیه: «کاربر شماره موبایل معتبر را وارد میکند و کد تأیید دریافت میکند.» این جمله برای توسعه و تست کافی نیست. در Review، تیم QA میتواند سؤالهای زیر را مطرح کند:
داده و فرمت
- فرمت پذیرفتهشده
09xxxxxxxxxاست یا+98xxxxxxxxxxنیز مجاز است؟ - اعداد فارسی و عربی به انگلیسی نرمال میشوند یا خطا میگیرند؟
- فاصله، خط تیره و کپیکردن شماره چه رفتاری دارد؟
- شماره خالی، کوتاه، بلند یا شامل حرف چه پیام مشخصی میگیرد؟
قواعد کسبوکار
- اگر شماره قبلاً ثبت شده باشد، مسیر ورود نمایش داده میشود یا خطا؟
- هر کد چند دقیقه معتبر است و چند بار میتوان درخواست مجدد داد؟
- پس از چند تلاش ناموفق، محدودیت موقت اعمال میشود؟
- آیا کد قبلی پس از درخواست مجدد باطل میشود؟
امنیت و حریم خصوصی
- پاسخ سیستم وجود یا نبود حساب را افشا میکند؟
- شماره در Log، ابزار تحلیل رفتار یا پیام خطا Mask میشود؟
- Rate Limit بر اساس شماره، IP یا هر دو اعمال میشود؟
تجربه و دسترسپذیری
- پیام خطا به فیلد مرتبط و برای صفحهخوان قابلتشخیص است؟
- کاربر میتواند شماره را اصلاح کند بدون آنکه جریان گیر کند؟
- در اینترنت ضعیف یا پاسخ دیرهنگام SMS چه وضعیتی نمایش داده میشود؟
نتیجه این Review باید معیارهای پذیرش دقیقتر، قرارداد API روشن، پیامهای خطای توافقشده و سناریوهای تست قابلردیابی باشد. این همان ارزش تست زودهنگام در مرحله تحلیل نیازمندیهای STLC است.
چکلیست بازبینی نیازمندی و کد
چکلیست Review نیازمندی
- آیا هدف و ارزش کسبوکار روشن است؟
- آیا فاعل، اقدام، شرط و خروجی مشخصاند؟
- آیا اصطلاح مبهمی مانند «سریع»، «معتبر» یا «مناسب» بدون معیار وجود دارد؟
- آیا Happy Path، خطا، لغو، Timeout و بازیابی تعریف شدهاند؟
- آیا نوع، واحد، بازه، فرمت و مرز داده روشن است؟
- آیا سطح دسترسی و حریم خصوصی پوشش داده شدهاند؟
- آیا نیازمندی با سایر اسناد تناقض ندارد؟
- آیا معیار پذیرش قابل تست و قابل اندازهگیری است؟
- آیا نیازهای فارسی مانند RTL، ارقام، تقویم و واحد پول در دامنهاند؟
چکلیست Code Review
- تغییر با نیازمندی و دامنه Pull Request همراستاست.
- نامگذاری و ساختار قابلفهماند و پیچیدگی بیدلیل وجود ندارد.
- خطا، Null، Timeout و Retry بهدرستی مدیریت میشوند.
- ورودی اعتبارسنجی و خروجی حساس Encode یا Mask میشود.
- Secret و داده شخصی در کد یا Log ثبت نشدهاند.
- تست واحد/یکپارچگی برای مسیر اصلی و خطا وجود دارد.
- تغییر سازگاری عقبرو و Migration لازم را در نظر گرفته است.
- هشدارهای ابزار تحلیل استاتیک بررسی و موارد مهم رفع شدهاند.
شاخصهای مفید برای بهبود تست استاتیک
متریک باید برای یادگیری استفاده شود، نه رتبهبندی افراد. چند شاخص کاربردی:
- تعداد و شدت عیبهای کشفشده پیش از اجرای نرمافزار؛
- زمان متوسط از ثبت یافته تا اصلاح؛
- نرخ فرار عیبهایی که میتوانستند در Review پیدا شوند؛
- درصد مصنوعات پرریسک که بازبینی شدهاند؛
- تعداد هشدارهای جدید نسبت به بدهی قدیمی ابزار؛
- نرخ پذیرش یافتهها و سهم False Positive؛
- موضوعات پرتکرار برای بهبود چکلیست یا آموزش.
صرف افزایش تعداد Comment یا هشدار، نشانه کیفیت بهتر نیست. مهم است آیا عیب مهم زودتر پیدا شده و از تکرار آن جلوگیری شده است.
بهترین شیوههای اجرای Static Testing در تیم چابک
- QA را از Refinement و طراحی وارد کنید، نه فقط پس از Ready for Test.
- Definition of Ready را به تستپذیری و وضوح معیار پذیرش متصل کنید.
- Pull Request را کوچک نگه دارید تا Review عمیق ممکن باشد.
- چکلیست را بر اساس تاریخچه باگ محصول بهروز کنید.
- Linter و تحلیل نوع را سریع اجرا کنید؛ SAST عمیقتر را در CI زمانبندی کنید.
- Quality Gate را مرحلهای فعال کنید تا تیم زیر بار هشدار بیکیفیت نرود.
- یافته را با مکان، معیار و اثر توضیح دهید؛ نظر سلیقهای را جدا کنید.
- برای بخش حساس از بازبین دامنه، امنیت یا عملیات کمک بگیرید.
- بازبینی را فضایی برای همکاری بسازید، نه ابزار سرزنش.
در تیمهای Agile، این فعالیتها بخشی از توسعه روزانهاند و با تست در اجایل و نقش QA همراستا هستند.
سوالات متداول
آیا Code Review همان تست استاتیک است؟
Code Review یکی از شکلهای تست استاتیک است، اما تمام آن نیست. بازبینی نیازمندی، طراحی، تستکیس و مستندات، همچنین تحلیل خودکار کد و تنظیمات نیز در این خانواده قرار میگیرند.
آیا تست استاتیک فقط وظیفه توسعهدهنده است؟
خیر. توسعهدهنده در Review و تحلیل کد نقش مهمی دارد؛ اما تستر، BA، طراح، متخصص امنیت و عملیات نیز بر اساس نوع مصنوع و ریسک بازخورد متفاوتی ارائه میکنند. کیفیت مسئولیت مشترک تیم است.
آیا تست استاتیک میتواند جای تست پویا را بگیرد؟
خیر. تست استاتیک رفتار واقعی زمان اجرا، کارایی، تجربه کاربر یا تعامل سرویسها را ثابت نمیکند. ترکیب تست ایستا و پویا پوشش بهتری ایجاد میکند.
از چه زمانی Static Testing را شروع کنیم؟
از نخستین مصنوع قابلبررسی؛ معمولاً ایده، نیازمندی یا User Story. هرچه بازخورد زودتر برسد، احتمال تکثیر عیب در طراحی، کد و تست کمتر است.
برای یک تیم کوچک کدام نوع Review مناسب است؟
Review غیررسمی روی سند و Pull Request، همراه با چکلیست کوتاه، نقطه شروع خوبی است. برای قابلیت پرریسک، Technical Review ساختاریافته با افراد تخصصیتر اضافه کنید.
جمعبندی
تست استاتیک یعنی کیفیت را پیش از اجرای نرمافزار بررسی کنیم. Review خوب ابهام نیازمندی، نقص طراحی و ریسک فرایند را زود آشکار میکند؛ تحلیل استاتیک نیز الگوهای مشکلدار کد و پیکربندی را با سرعت پیدا میکند. دامنه و معیار روشن، بازبینی فردی، گفتوگوی محترمانه، ثبت قابلردیابی و ترکیب نتیجه با تست پویا، این فعالیت را از یک تشریفات به ابزار واقعی کاهش ریسک تبدیل میکند.
