«روی سیستم من رخ نمیدهد» نتیجهٔ بررسی نیست. باگی که فقط هنگام Retry شبکه، فشار حافظه، رقابت دو Worker یا ترکیب یک Feature flag و دادهٔ قدیمی دیده میشود، ممکن است در ده اجرای بعدی ناپدید شود و هفتهٔ بعد به کاربر دیگری آسیب بزند. ناتوانی موقت در بازتولید، مشاهدهٔ اولیه را باطل نمیکند؛ فقط سطح شواهد و گام بعدی را تغییر میدهد.
این راهنما برای بازتولید باگهای متناوب (Intermittent) و مدیریت وضعیت Cannot Reproduce است: چه شواهدی را در اولین وقوع حفظ کنیم، چگونه عوامل را محدود کنیم، Trace و Log را به هم وصل کنیم، چند بار تکرار کنیم، امنیت فایلهای تشخیصی را حفظ کنیم و وقتی هنوز بازتولید نشد چه تصمیمی بگیریم. برای قالب عمومیِ گزارشهای قابلبازتولید، مقالهٔ گزارش باگ حرفهای مالک Intent اصلی است.
باگ متناوب و Cannot Reproduce یعنی چه؟
باگ متناوب شکستی است که تحت ظاهراً یکسان، فقط در بعضی اجراها ظاهر میشود؛ اما معمولاً یک یا چند شرط پنهان واقعاً یکسان نیست: زمانبندی، State، نسخه، شبکه، ترتیب Event، بار، Cache یا منابع.
Cannot Reproduce (CNR) بهتر است وضعیت موقت تحقیق باشد، نه حکم «باگ وجود ندارد». این وضعیت میگوید با اطلاعات و شرایط فعلی نتوانستهایم Failure signature را دوباره مشاهده کنیم. ممکن است:
- گام یا پیششرطی جا افتاده باشد؛
- محیط/Build/Flag متفاوت باشد؛
- شکست به Race یا احتمال وابسته باشد؛
- داده پس از وقوع تغییر کرده باشد؛
- مشکل در Dependency یا شبکهٔ بیرونی رخ داده باشد؛
- Telemetry کافی برای تأیید نداشته باشیم؛
- Defect اصلاح یا مسیرش غیرفعال شده باشد؛
- Failure مربوط به Testware یا محیط، نه محصول، باشد.
یک مشاهده میتواند معتبر باشد حتی اگر Steps قطعی هنوز معلوم نباشند. هدف تحقیق، تبدیل «گاهی خراب میشود» به Signature، شرایط و فرضیهٔ آزمونپذیر است.
Failure، Defect، Symptom و Root cause را جدا کنید
| مفهوم | مثال پرداخت |
|---|---|
| Failure | کاربر صفحهٔ «پرداخت موفق» میبیند ولی سفارش AwaitingPayment میماند. |
| Symptom | وضعیت UI و Server ناسازگار است یا اعلان ارسال نمیشود. |
| Defect | کد/طراحی ترتیب Eventها را بدون Guard معتبر میپذیرد. |
| Trigger | Timeout کلاینت، Callback دیرهنگام و Retry همزمان. |
| Root cause | State transition و Idempotency در رقابت اتمیک نیستند. |
گزارشدهنده Failure و زمینه را ثبت میکند؛ نباید Root cause را بدون شواهد قطعی بنویسد. عنوان «Race condition در Worker پرداخت» وقتی فقط UI ناسازگار دیده شده، فرضیه را بهجای مشاهده جا میزند.
علتهای رایج باگهای متناوب
Concurrency و Race condition
دو Thread، Request، Tab یا Worker به ترتیب متغیر به State مشترک میرسند. Lock، Transaction، Unique constraint یا Idempotency ناکافی میتواند نتیجه را وابسته به زمان کند.
Asynchrony و Eventual consistency
Queue، Cache، Search index یا Read replica هنوز بهروز نشده است. محصول باید Pending/Retry/Refresh را درست مدل کند؛ «کمی صبر کن» Oracle نیست مگر زمان و SLO مشخص باشد.
Network و Dependency
Timeout، Packet loss، DNS، Connection reuse، Retry، پاسخ دیرهنگام یا سرویس ثالث باعث مسیر متفاوت میشود. HTTP موفق هم لزوماً Outcome کسبوکار را تأیید نمیکند.
State، Cache و Test data
حساب مشترک، Session قدیمی، Cache گرم، ترتیب تستها یا Cleanup ناقص باعث میشود یک سناریو فقط بعد از سناریوی دیگر Fail شود. راهنمای مدیریت داده تست Isolation، Seed و Reset را پوشش میدهد.
Time، Locale و Calendar
مرز روز/ماه، منطقهٔ زمانی، Clock drift، تاریخ انقضا، Job زمانبندیشده و جلالی/میلادی رفتار را تغییر میدهند. Timestamp بدون Zone شواهد ناقص است.
Resource pressure
Memory، CPU، Disk، Connection pool، File descriptor یا Battery/background limit میتواند برنامه را فقط زیر فشار خاص خراب کند. Debugger یا Logging سنگین گاهی زمانبندی را عوض و مشکل را مخفی میکند؛ این حالت را Heisenbug مینامند.
Version و Configuration skew
Frontend، Backend، Schema، CDN، App، SDK یا Feature flag همزمان یک نسخه نیستند. Canary/Rollout ممکن است فقط بخشی از کاربران را به مسیر جدید بفرستد.
Randomness و دادهٔ نادر
Seed تصادفی ثبت نشده، UUID/Hash collision، ترتیب غیرقطعی Collection یا ترکیب نادر داده میتواند Failure کمتکرار بسازد. «Random test» بدون Seed شکست را غیرقابلبازتولید میکند.
در اولین وقوع چه چیزی را حفظ کنیم؟
ارزشمندترین لحظه همان اولین Failure است؛ State بعد از Refresh، Retry یا Logout ممکن است از بین برود. یک بستهٔ حداقلی:
- When: Timestamp دقیق UTC و زمان محلی با Zone؛
- What: Expected، Actual و Failure signature کوتاه؛
- Where: Environment، Region/Cluster، URL/Screen و Tenant آزمایشی؛
- Which version: Build، Commit، App version، API/Schema و Feature flag؛
- Who/role: نقش و شناسهٔ آزمایشی، بدون دادهٔ شخصی؛
- Trigger: آخرین Actionها، Navigation و وقفهها؛
- Frequency: چند بار از چند تلاش، نه «گاهی»؛
- Correlation: Request/Trace/Session/Job/Event ID؛
- Evidence: Screenshot/Video، Console، Network، Log، Trace، Metric و Crash report؛
- State: ورودی، رکوردهای مرتبط و اثرهای جانبی Sanitized؛
- Recovery: آیا Refresh/Retry/Restart مشکل را تغییر داد؟
اگر Evidence حجیم است، اصل فایل را در محل کنترلشده نگه دارید و در Ticket فقط Link دارای دسترسی و Expiry بگذارید. کپیکردن Log کامل در Comment میتواند Secret و دادهٔ مشتری را پخش کند.
شواهد وب، موبایل و Backend
| لایه | شواهد مفید | نکتهٔ حیاتی |
|---|---|---|
| Web | Browser/version، Console، Network timing، HAR، DOM state، Feature flag | Extension، Cache و Service worker را ثبت کنید. |
| Mobile | OS/model، App build، Lifecycle، network type، crash/device log، screen recording | Background/foreground، process death و permission مهماند. |
| API | Request/response Sanitized، status، latency، retry، idempotency key، trace ID | Token و payload شخصی را حذف کنید. |
| Backend | Structured logs، distributed trace، metric، deployment/config event | Clock و correlation بین سرویسها باید قابلاعتماد باشد. |
| Data/Queue | State history، transaction/audit، event ID، partition/offset، retry/DLQ | Snapshot read-only و مطابق مجوز بگیرید. |
| CI/Test | Seed، worker، order، artifact، retry history، environment allocation | Retry سبز اولیه را پنهان نکند. |
برای موبایل، مستندات رسمی Android Bug Report خروجیهای سیستمی، logcat و stack trace را توضیح میدهد و Apple بر Crash report کامل، Device log و Symbolication تأکید میکند. مقالهٔ تست اپلیکیشن موبایل Matrix دستگاه و Lifecycle را کامل میکند.
HAR، Log و Trace میتوانند دادهٔ حساس باشند
فایل تشخیصی را «فقط اطلاعات فنی» فرض نکنید. ممکن است Authorization، Cookie، Session، URL query، Request body، نام، شماره، پرداخت یا محتوای شخصی داشته باشد.
- در Chrome DevTools خروجی HAR sanitized را بر گزینهٔ دارای دادهٔ حساس ترجیح دهید.
- حتی HAR sanitized را بازبینی کنید؛ پاکسازی Headerهای رایج تضمین نمیکند دادهٔ برنامه در URL/Body نباشد.
- Secret، Token، Cookie، PAN و دادهٔ شخصی را Redact کنید.
- دسترسی، Retention، Download و حذف Artifact را محدود کنید.
- Trace attribute و Log message نباید دادهٔ حساس را به Observability منتقل کند.
- شناسهٔ Correlation را تصادفی/فنی نگه دارید؛ کدملی یا شماره همراه را ID نکنید.
در Production فقط از مسیرهای Observability و دسترسی Read-only مصوب استفاده کنید. برای «بازتولید» کاربر واقعی را Impersonate، دادهاش را تغییر یا Fault ایجاد نکنید مگر مجوز صریح، محیط مناسب و حفاظ عملیاتی وجود داشته باشد.
Correlation؛ اتصال یک Failure در سیستم توزیعشده
یک Screenshot میگوید کاربر چه دید؛ Trace میتواند نشان دهد همان Action از Gateway به Order، Payment و Queue چه مسیری رفت. W3C Trace Context قالب انتشار Context میان سرویسها را استاندارد میکند تا درخواستهای یک Trace قابل اتصال باشند.
یک قرارداد عملی:
- Trace/Request ID در پاسخ خطا یا Support code قابل دریافت باشد.
- ID از Client تا Gateway و سرویسها Propagate شود.
- Job/Event فرزند، Parent/correlation مناسب را حفظ کند.
- Log ساختیافته Build، service، environment و نتیجه داشته باشد.
- Timestamp سرویسها همگام و با Zone روشن باشد.
- Metric/trace sampling برای جریان حیاتی Evidence کافی بدهد.
- ID در پیام کاربر قابل کپی باشد اما دادهٔ حساس افشا نکند.
Instrumentation ضعیف خود یک Risk/Testability issue است. نبود Trace دلیل بستن Defect نیست؛ دلیل ایجاد کار بهبود مشاهدهپذیری است.
فرایند گامبهگام بازتولید باگ متناوب
۱. مشاهده را بدون سرزنش تثبیت کنید
گزارشدهنده را با «دوباره امتحان کن» تنها نگذارید. Expected/Actual، اثر و Signature را مشترک بازنویسی کنید. اگر ویدئو یا Log دارد، قبل از Expiry حفظ شود.
۲. Build و Scope را همسان کنید
Build، Config، Flag، Data version، Browser/App و Environment را با وقوع مقایسه کنید. Reproduction روی نسخهای دیگر، نتیجهٔ قطعی دربارهٔ نسخهٔ گزارششده نمیدهد.
۳. شرطها را به ماتریس تبدیل کنید
| بعد | مقادیر نمونه |
|---|---|
| State | Fresh، Warm cache، Session قدیمی، پس از Retry |
| Data | Tenant، نقش، حجم، تاریخچه، حالت سفارش |
| Timing | سریع، Delay کنترلشده، همزمان |
| Network | پایدار، Latency، Timeout، Switch/Offline |
| Version | آخرین Production، Candidate، Flag on/off |
| Resource | عادی، Memory/CPU/connection pressure مجاز |
| Order | تنها، بعد از Test X، دو Tab/Worker |
یکباره همهٔ عوامل را عوض نکنید. از احتمال/اثر و Evidence اولیه برای اولویت استفاده کنید؛ سپس یک عامل را تغییر و بقیه را ثابت نگه دارید.
۴. اجرای پایه و نرخ وقوع را ثبت کنید
ابتدا Baseline با شرایط گزارششده اجرا شود. نتیجه را «۳ Failure از ۵۰ تلاش» ثبت کنید. اگر هر تلاش تقریباً مستقل و احتمال وقوع p باشد، احتمال دیدن حداقل یک Failure در n تلاش برابر است با:
1 - (1 - p)^n
مثلاً با احتمال تقریبی ۵٪، حدود ۵۹ تلاش شانس مشاهدهٔ حداقل یک Failure را به نزدیک ۹۵٪ میرساند. این محاسبه فرض استقلال و p ثابت دارد؛ در Race، Cache یا Shared state ممکن است فرض برقرار نباشد. تعداد تکرار را از هزینه، اثر و مدل شکست انتخاب کنید؛ نه از یک عدد جهانی.
۵. Instrumentation هدفمند اضافه کنید
قبل از افزودن Log فراوان، سؤال بنویسید: «کدام Event اول رسید؟ کدام State خوانده شد؟ Retry چه ID داشت؟» سپس Log/Span/Metric حداقلی برای رد یا تأیید فرضیه اضافه کنید. Logging میتواند Timing را تغییر دهد؛ Baseline قبل و بعد را مقایسه کنید.
۶. Fault و Timing را کنترلشده تغییر دهید
در محیط مجاز از Stub، Network shaping، Fake clock، Pause/Delay و Controlled concurrency استفاده کنید. در Production اختلال نسازید. هدف بازسازی شرط است، نه تقلید حمله یا ایجاد خسارت.
- پاسخ دیرهنگام و Duplicate؛
- Timeout پیش/پس از Commit؛
- دو Request با Idempotency key یکسان؛
- ترتیب معکوس Event؛
- Clock در مرز انقضا؛
- Process restart یا Worker retry؛
- Cache cold/warm و Replica lag شبیهسازیشده.
۷. تغییرها را Binary search کنید
اگر Regression window معلوم است، Commit، Dependency، Config یا Flag را در محیط امن دو نیم کنید. Build artifact واقعی را نگه دارید؛ «کد فعلی روی Config قدیمی» ممکن است ترکیب نامعتبر بسازد.
۸. فرضیه و شاهد را جدا ثبت کنید
| فرضیه | پیشبینی | آزمایش | نتیجه |
|---|---|---|---|
| Callback دیرهنگام State را عقب میبرد | Event قدیمی پس از Paid، Awaiting مینویسد | ترتیب کنترلشده با Trace | تأیید/رد با State history |
| Cache قدیمی UI را گمراه میکند | Server Paid است ولی GET قدیمی میآید | Cache bypass و version logging | … |
این جدول از «حدسهای موازی و وصلههای متعدد» جلوگیری میکند.
۹. Minimal reproducible condition بسازید
وقتی Trigger پیدا شد، وابستگیهای غیرضروری را حذف کنید و کوچکترین Condition را نگه دارید. Apple نیز برای درخواست پشتیبانی فنی، در صورت امکان Sample project کوچک را پیشنهاد میکند. در محصول، Minimal case میتواند Test API/Integration یا State model باشد، نه الزاماً UI کامل.
۱۰. Fix، Stress repetition و Regression
پس از اصلاح:
- Condition دقیق پیشین دیگر Failure نسازد؛
- تعداد تکرار و Config ثبت شود؛
- مسیر عادی و Recovery خراب نشده باشند؛
- تست پایدار در پایینترین سطح مناسب اضافه شود؛
- Instrumentation مفید حفظ و دادهٔ اضافه حذف شود؛
- Production monitor برای Signature قبلی تعریف شود.
مثال عملی: سفارش پرداختشده که گاهی معلق میماند
مشاهده
در اپ خرید، کاربر از درگاه Sandbox با پیام موفق برمیگردد؛ تقریباً ۲ بار از ۴۰ اجرا سفارش AwaitingPayment میماند. Refresh گاهی آن را Paid میکند.
بستهٔ شواهد
- App/OS/Build و Timestamp؛
- Sandbox transaction و Order ID ساختگی؛
- Trace ID درخواست Return، Callback و Poll؛
- State history سفارش؛
- Network profile و زمان Background/Foreground؛
- Event ID/Retry count دو Worker؛
- ویدئوی UI بدون دادهٔ شخصی.
فرضیهها
- Client cache پاسخ قدیمی نشان میدهد.
- Callback دیرهنگام پس از Poll میرسد.
- Retry یک Event قدیمی را بعد از Paid دوباره اعمال میکند.
- Replica lag باعث GET قدیمی میشود.
آزمایش امن
در محیط تست، Simulator پرداخت پاسخ Success را با Delay و Duplicate کنترلشده میفرستد. همهٔ پیامها Correlation دارند. دو ترتیب Event و Retry با State history مقایسه میشوند. هدف، بررسی Invariant است: State نهایی نباید از Paid به AwaitingPayment برگردد و اثر مالی/موجودی باید Idempotent باشد.
این سناریو هم تست API و هم State/Integration میخواهد؛ راهنمای تست API مجوز، Idempotency، Contract و Concurrency را پوشش میدهد.
باگ متناوب یا Flaky test؟
Flaky test آزمونی است که بدون تغییر معنادار در Test object، Pass/Fail متناوب میدهد. علت میتواند Testware، محیط یا یک Defect واقعی محصول باشد. برچسب Flaky نباید خودکار به معنای «مشکل تست است» باشد.
| نشانه | فرض اولیه | بررسی |
|---|---|---|
| Sleep ثابت و Failure روی CI کند | Synchronization تست | انتظار رویداد/State و Trace |
| داده/حساب مشترک | Isolation تست | Namespace per run و order randomization |
| Actual محصول واقعاً Invariant را میشکند | Defect محصول | Log/State مستقل از Assertion |
| فقط یک Browser/Device | Compatibility یا Timing | Matrix هدف و diagnostic |
| Retry دوم سبز میشود | نامشخص | Artifact اجرای اول را حفظ و علت را Triage کنید |
Quarantine باید Owner، دلیل، اثر، Issue و مهلت داشته باشد. Silent retry سیگنال را مخفی میکند. در اجرای تست نتیجهٔ Fail/Blocked/Invalid و Triage از هم جدا شدهاند.
قالب گزارش باگ متناوب
Title: [Checkout][~۵%][Mobile] سفارش پس از بازگشت موفق از Sandbox گاهی AwaitingPayment میماند
First observed: UTC/local timestamp + Build
Business/user impact: …
Expected/Actual: …
Frequency: ۲/۴۰، با شرایط ثبتشده
Known conditions: OS/device/network/flag/data/state
Last actions: …
Correlation: trace/request/job/event IDs
Evidence: Sanitized links + expiry/access
Recovery: Refresh/Retry/Restart چه اثری داشت؟
Hypotheses: جدا از مشاهده، با confidence
Reproduction attempts: ماتریس و نتیجه
Current status: Confirmed / Observed / CNR-now / Need-info / Monitor
Next experiment/owner/date: …
عنوان Frequency را تقریبی و قابلبهروزرسانی نشان میدهد. «Random» یا «گاهی» بدون کسر اجرا، تصمیم نمیسازد.
وقتی هنوز بازتولید نشد چه کنیم؟
گزینهها را با Evidence و اثر انتخاب کنید:
- Confirmed by telemetry: بازتولید آزمایشگاهی نداریم، اما Trace/Crash/Invariant شکست را تأیید میکند.
- Observed, investigation open: مشاهده معتبر و آزمایش بعدی مشخص است.
- Need more information: دقیقاً چه Field/Artifactی لازم است و چه کسی میگیرد.
- CNR now + monitor: Signature، Dashboard/Alert، بازهٔ پایش و شرط Reopen تعریف شده است.
- Duplicate: Evidence به Root issue موجود متصل میشود؛ گزارش حذف نمیشود.
- Test/Environment issue: علت شناسایی و Testware/Environment issue مستقل ساخته میشود.
- Not a defect by decision: Expected behavior با مرجع و اثر توضیح داده میشود.
Close خودکار بعد از «سه بار پاس» سیاست ضعیفی است. اثر بالا و احتمال کم ممکن است Monitoring یا Instrumentation بیشتری بخواهد. وضعیتها و اختیارها را در چرخه عمر باگ تعریف کنید.
تست اکتشافی برای کشف شرط پنهان
وقتی ماتریس کامل معلوم نیست، Session اکتشافی ساختاریافته مفید است:
- Charter: بررسی اثر تغییر شبکه و Lifecycle بر ثبت سفارش؛
- Variables: Wi‑Fi/Cellular، Background، Timeout، Double tap، Retry؛
- Oracle: یک Order، State سازگار، اثر Idempotent، پیام قابلاقدام؛
- Evidence: Timestamp، Trace، Video و State history؛
- Debrief: پوشش، یافته، سؤال و آزمایش بعدی.
راهنمای تست اکتشافی Charter و Session note را بهشکل قابلردیابی توضیح میدهد.
متریکهای مفید برای Cannot Reproduce
| متریک | پرسش تصمیم | هشدار |
|---|---|---|
| زمان تا Evidence کافی | آیا Instrumentation و Support flow مناسباند؟ | سرعت بدون کیفیت شاهد کافی نیست. |
| گزارشهای دارای Build/Correlation | چه سهمی قابلتحقیق آغاز میشوند؟ | هدف سرزنش گزارشدهنده نیست؛ بهبود ابزار است. |
| CNR aging by impact | کدام مورد پراثر بیمالک مانده؟ | تعداد خام CNR بازیپذیر است. |
| Reproduction experiment yield | کدام Dimensionها بیشترین سیگنال میدهند؟ | موفقیت آزمایش را فقط «بازتولید شد» ندانید؛ رد فرضیه هم ارزش دارد. |
| Recurrence after close | کدام سیاست Close ضعیف است؟ | ممکن است Signature grouping ناقص باشد. |
| Flaky root-cause mix | محصول، تست، داده یا زیرساخت کجا سهم دارد؟ | آن را KPI فردی/تیمی نکنید. |
مقالهٔ متریکهای تست نرمافزار دربارهٔ Anti-gaming و اتصال شاخص به تصمیم توضیح بیشتری دارد.
اشتباههای رایج در بازتولید باگ
- «روی سیستم من نیست»: محیط و نسخه مقایسه نشدهاند.
- Refresh قبل از Evidence: State اولیه از بین میرود.
- تغییر چند عامل با هم: Trigger واقعی معلوم نمیشود.
- Root cause در عنوان: فرضیه به Fact تبدیل میشود.
- Log همهچیز: نویز، هزینه و نشت داده بالا میرود و Timing عوض میشود.
- HAR/Crash خام در Ticket عمومی: Secret و دادهٔ شخصی افشا میشود.
- سه اجرای پاس و Close: احتمال کم نادیده گرفته میشود.
- Retry بیصدا: Failure اول و نرخ واقعی مخفی میشوند.
- Flaky مساوی Test issue: Defect واقعی محصول ممکن است فرار کند.
- Fault injection در Production: تحقیق از دامنهٔ مجاز خارج و خطرناک میشود.
- CNR بدون Next step: Issue به انبار فراموشی تبدیل میشود.
چکلیست نهایی باگ متناوب
- Failure، Symptom، Trigger و Hypothesis جدا نوشته شدهاند.
- Build/Config/Flag/Data/Environment دقیق ثبتاند.
- Timestamp UTC+Zone و Correlation ID وجود دارد.
- Frequency بهصورت Failure/attempt گزارش شده است.
- Evidence پیش از Refresh/Retry حفظ و Sanitized شده است.
- ماتریس State/Timing/Network/Version/Resource ساخته شده است.
- هر آزمایش یک فرضیه و پیشبینی روشن دارد.
- Fault فقط در محیط و دامنهٔ مجاز اجرا میشود.
- Flaky test و Defect محصول با شواهد Triage شدهاند.
- Fix با Repetition، Regression و Monitor تأیید شده است.
- اگر CNR است، Owner، آزمایش/پایش بعدی و شرط Reopen دارد.
سوالات متداول باگ Cannot Reproduce
اگر باگ فقط یکبار رخ داد، گزارشش کنیم؟
بله، اگر Failure واقعی یا پراثر بوده است. همان بار اول Build، زمان، نقش، Correlation و Artifactها را حفظ کنید. در گزارش صریح بنویسید ۱ بار از چند تلاش و میزان اطمینان چقدر است.
چند بار برای بازتولید تلاش کنیم؟
عدد ثابت نداریم. احتمال تقریبی، استقلال تلاشها، اثر، هزینه و شرطهای شناختهشده تعیین میکنند. بهجای تکرار کور، ماتریس عوامل و Instrumentation بسازید؛ رد یک فرضیه نیز نتیجهٔ مفید است.
آیا Cannot Reproduce باید Close شود؟
نه خودکار. ممکن است با Telemetry تأیید، برای اطلاعات بیشتر باز، یا با Signature و بازهٔ Monitor نگه داشته شود. اگر Close میشود، دلیل، Evidence، شرط Reopen و ریسک پذیرفتهشده ثبت شود.
آیا فایل HAR sanitized کاملاً امن است؟
خیر. ابزار Headerهای حساس رایج را حذف میکند، اما URL، Query، Body یا دادهٔ خاص برنامه ممکن است باقی بماند. فایل را بازبینی، Redact، دسترسیمحدود و زماندار نگه دارید.
تفاوت باگ متناوب با Flaky test چیست؟
باگ متناوب Failure واقعی محصول است که شرطش ناپایدار است. Flaky test بدون تغییر معنادار Pass/Fail میدهد و علتش ممکن است Testware، Environment یا همان Defect محصول باشد. فقط با Triage و Evidence میتوان مرز را تعیین کرد.
منابع و یادداشت بازبینی
شواهد موبایل با مستندات رسمی Android/Apple، Network capture با Chrome DevTools و Correlation توزیعشده با W3C Trace Context تطبیق داده شده است. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. دسترسی Production، نگهداری Log و دادهٔ شخصی باید از سیاست امنیت/حریم خصوصی همان سازمان پیروی کند.
جمعبندی: Cannot Reproduce پایان تحقیق نیست؛ نام یک فاصلهٔ شواهدی است. اولین Failure را حفظ کنید، شرایط را به Dimension تبدیل کنید، Correlation بسازید، فرضیهها را با آزمایش کنترلشده رد یا تأیید کنید و اگر هنوز Trigger معلوم نیست، Monitoring و Owner بدهید. این رویکرد «گاهی خراب میشود» را به کار قابلمدیریت تبدیل میکند.
