تست ابری چیست؟ راهنمای AWS، Azure و GCP برای QA

تست‌ها در یک Kubernetes موقت سبزند، اما Release در Production پس از تغییر Secret و Failover دیتابیس قطع می‌شود. تیم می‌گوید «ما در Cloud تست کرده‌ایم»؛ با این حال Environment تست از Managed database، IAM policy، Network path، Quota، Backup و Deployment topology واقعی متفاوت بوده است. اجرای Test runner روی یک VM ابری فقط محل Compute را عوض می‌کند؛ الزاماً رفتار Cloud workload را اثبات نمی‌کند.

تست ابری یا Cloud Testing یک اصطلاح چتری است. ممکن است به تست برنامه‌ای که روی Cloud اجرا می‌شود، استفاده از Cloud برای اجرای Test، آزمون Infrastructure/Configuration یا تمرین Reliability و Recovery اشاره کند. اگر این Scopeها جدا نشوند، تیم هزینه و ریسک را مقایسه می‌کند اما نمی‌داند دقیقاً چه Evidenceای خریده است.

تست ابری چیست؟ چهار دامنه‌ای که نباید مخلوط شوند

۱. Testing a cloud-hosted application

SUT روی IaaS، PaaS، Container platform، Serverless یا SaaS dependency اجرا می‌شود. هدف آزمون رفتار برنامه با Service limit، Identity، Network، Scaling، Storage consistency، Failure و Configuration واقعی است.

۲. Using cloud resources for testing

Test runner، Browser/device، Load generator یا Environment در Cloud provision می‌شود، حتی اگر SUT On-premise یا در Provider دیگری باشد. هدف می‌تواند Parallelism، Device access یا ظرفیت موقت باشد. این دامنه دربارهٔ زیرساخت اجرای Test است، نه الزاماً Cloud-native behavior محصول.

۳. Testing cloud infrastructure and configuration

IaC plan، Policy، IAM، Network، Encryption، Backup، Observability، Autoscaling و Drift بررسی می‌شوند. «Infrastructure deploy شد» Oracle کافی نیست؛ باید Reachability مجاز/غیرمجاز، Guardrail، Health و رفتار Upgrade/Destroy آزموده شود.

۴. Reliability، migration و recovery testing

Failover، Restore، Dependency outage، Zone/Region disruption، Queue backlog، Throttling، Rollback و RTO/RPO تمرین می‌شوند. این آزمایش‌ها مجوز، Blast radius، Steady state، Stop condition و Recovery evidence می‌خواهند.

یک Run می‌تواند چند دامنه داشته باشد

مثلاً Load generator در Azure، SUT در AWS و Analytics در GCP باشد. گزارش باید SUT location، Generator location، Data path، Provider dependency و مسئولیت هر Boundary را ثبت کند؛ عبارت «Cloud test» به‌تنهایی قابل‌ممیزی نیست.

تست در Cloud با تست Cloud-native چه تفاوتی دارد؟

جابجایی VM رفتار معماری را عوض نمی‌کند

انتقال Selenium Grid یا JMeter به VM ابری شاید Capacity provisioning را آسان کند، اما Autoscaling، Managed service، Event delivery یا Multi-zone recovery را آزمون نمی‌کند. این فقط Test infrastructure در Cloud است.

Cloud-native یعنی Dependency و Failure mode تازه

Control plane، Managed runtime، Identity federation، eventual consistency، ephemeral compute، queue، object storage، regional service و quota به System boundary وارد می‌شوند. Contract و Observability این Boundaryها باید در Test strategy حاضر باشند.

Production-like یک عبارت مطلق نیست

یک Environment می‌تواند برای Contract fidelity مناسب و برای Capacity نامناسب باشد. شباهت را بُعدی بنویسید: Version، Topology، Data shape، Network، Identity، Scale، Region، Observability و Dependency mode. Environment ارزان‌تر می‌تواند برای یک Risk کافی و برای Risk دیگر گمراه‌کننده باشد.

پیش از انتخاب Provider چه سؤال‌هایی پاسخ دهیم؟

تصمیم مورد حمایت چیست؟

Merge، Release، Capacity، Device support، Recovery، Migration یا Vendor selection؟ Test بدون Decision مصرف‌کننده ممکن است Artifact زیادی بسازد اما هیچ Gate یا Learning مشخصی نداشته باشد.

SUT و خارج از Scope کجاست؟

Application، Managed service، DNS، CDN، Identity provider، Bank sandbox، Queue، Client و Operator را روی Boundary map قرار دهید. Dependency خارج از کنترل باید Contract، Virtualization یا Failure policy داشته باشد.

چه Fidelity لازم است؟

برای Unit/Component به Local/container کافی است؛ برای IAM/Network باید Provider resource واقعی باشد؛ برای Performance به Topology و Capacity معتبر نیاز است؛ برای Disaster recovery باید Backup/Replica/Runbook واقعی با Scope امن تمرین شود.

چه چیزی Cloud نباید دریافت کند؟

Production dataset، Secret، Token بانکی، Source محرمانه، Artifact بدون License یا Log حاوی PII ممکن است محدودیت داشته باشد. Data classification و Allowed destinations را قبل از Account ساختن مشخص کنید.

Exit و Cleanup چیست؟

چه کسی Environment را Destroy می‌کند؟ State، Log، Snapshot، Bucket و Secret چه زمانی حذف می‌شوند؟ اگر Vendor قطع شد Test چگونه اجرا می‌شود؟ این‌ها Requirements هستند، نه کار پس از Pilot.

مسئولیت مشترک در تست ابری؛ Provider دقیقاً چه چیزی را نمی‌گیرد؟

AWS: مسئولیت با Service انتخابی تغییر می‌کند

AWS Shared Responsibility Model توضیح می‌دهد AWS لایه‌های زیرساخت Cloud را اداره می‌کند و مسئولیت Customer با Service و Integration فرق دارد. در EC2، Guest OS و Application/Firewall config بیشتر با Customer است؛ در Managed service بخشی منتقل می‌شود. Identity، Data، Permission و Configuration شما همچنان باید آزموده شوند.

Azure: IaaS، PaaS و SaaS مرز متفاوت دارند

مدل رسمی Azure مسئولیت را بر اساس Service model تفکیک می‌کند و Data، Account و Access management را از مسئولیت‌های ماندگار Customer می‌داند. پس Pass شدن Provider compliance report، Secure configuration محصول شما را ثابت نمی‌کند.

GCP: Shared responsibility و Shared fate

Google Cloud دربارهٔ Shared responsibility و Shared fate تأکید می‌کند هر Service Configuration profile متفاوتی دارد و Provider می‌تواند Blueprint و Guidance بدهد؛ Customer همچنان Requirement کسب‌وکار، Data و Workload خود را می‌شناسد و باید Control را Verify کند.

ماتریس مسئولیت Test بسازید

Boundary	Provider evidence	Customer/team evidence	Owner
Physical/host	Service documentation/attestation	Service selection و inherited-control mapping	Cloud/Security
Identity	IAM capability	Role، Federation، MFA، least privilege، revocation	Security/Platform
Network	VPC/VNet capability	Route، firewall، private access، egress، DNS	Platform/Product
Data	Encryption/storage capability	Classification، key/access، retention، deletion	Data/Product
Application	Runtime contract	Code، configuration، dependency، test و monitoring	Product team
Recovery	Availability/backup feature	Architecture، eligibility، restore/failover drill	Product/SRE

معماری مرجع Cloud Testing؛ از Commit تا Cleanup

۱. Source و immutable build

Commit SHA یک Build تولید می‌کند؛ Artifact با Digest، SBOM/Provenance و Version ذخیره می‌شود. در Stageهای بعد همان Artifact Promote می‌شود، نه اینکه برای هر Environment دوباره Build شود.

۲. Account boundary

Test در Account/Subscription/Project جدا با Budget، Quota، Policy و Identity محدود اجرا می‌شود. Separation فقط نام Resource group نیست؛ Billing، IAM blast radius، Secret و Network boundary باید واقعی باشد.

۳. IaC و Environment manifest

Plan Review می‌شود، State امن نگه داشته می‌شود و Environment با Versionهای دقیق Provision می‌گردد. Manifest واقعیت Deploy‌شده را ثبت می‌کند؛ Drift detection اختلاف Desired و Actual را نشان می‌دهد.

۴. Data و dependency setup

Dataset versioned با Namespace ساخته می‌شود؛ Secret reference تزریق می‌شود؛ Dependency واقعی/Sandbox/Virtualized mode ثبت می‌گردد. Setup باید Idempotent و Cleanup قابل‌آزمون باشد.

۵. Health gate

DNS، Certificate، Identity، Route، Schema، Queue، Dependency و Observability قبل Test بررسی می‌شوند. «Pod running» یا «Deployment succeeded» Ready بودن Journey را ثابت نمی‌کند.

۶. Test execution و evidence

Run ID، Build، Manifest، Dataset، Runner image، Region و Timestamp به Result متصل می‌شوند. Trace/Metric/Log و Client-side result با Correlation ID قابل پیوندند.

۷. Decision و cleanup

Gate نتیجه را با Risk و Failure class تفسیر می‌کند؛ Environment TTL می‌گیرد؛ Destroy و Data deletion Verify می‌شود؛ هزینه به Team/Journey نسبت داده و Artifact موردنیاز با Retention policy حفظ می‌شود. طراحی Lane و سیاست Gate در راهنمای Continuous Testing در CI/CD تشریح شده است.

نمونه Manifest محیط تست ابری

environment_id: refund-pr-4821
purpose: integration-contract
owner: payments-team
provider: selected-in-pilot
account_boundary: qa-isolated
region: selected-region
commit: a17c9e2
artifact_digest: sha256:example
iac_revision: env-2.4.1
database_schema: refund-18
dataset:
  version: refund-fa-3
  namespace: pr-4821
dependencies:
  bank:
    mode: virtualized
    contract: callback-v3
observability:
  run_id: run-20260806-4821
  trace_required: true
ttl: 6h
cleanup:
  data: verify-deletion
  resources: destroy-from-state

Manifest چه چیزی را حل می‌کند؟

Run قابل‌بازتولیدتر، Failure قابل‌تفکیک و هزینه قابل‌انتساب می‌شود. Manifest تضمین نمی‌کند Environment واقعاً همین State را دارد؛ Health evidence و Drift check مکمل آن‌اند.

چه چیزی نباید در Manifest باشد؟

Secret value، Token، Password، داده کاربر یا اطلاعات پرداخت. فقط Reference امن، Version و Metadata غیرحساس ثبت شود.

Portfolio محیط؛ همهٔ تست‌ها را به یک Cloud Environment نفرستید

Local و Component

سریع، ارزان و جدا برای Logic و Contract داخلی. Container/Test double مفید است، اما Provider IAM/Network/Managed semantics را کامل تقلید نمی‌کند.

Ephemeral per-change

Isolation و Reproducibility بهتر؛ Provision latency، Quota و Cost بالاتر. برای Integration slice محدود مناسب است، نه Clone کامل Production برای هر Pull Request.

Shared integration

Dependency مشترک و هزینه کمتر؛ Data collision، Drift و Booking risk دارد. Namespace، baseline، change window و Support contract ضروری است.

Performance environment

Topology و Capacity کنترل‌شده، Generator جدا، Observability و Stop rule دارد. هم‌زمانی با Functional run یا تغییر زیرساخت نتیجه را مخدوش می‌کند.

Production-safe verification

Synthetic probe، Canary و Recovery drill محدود برای Failureهایی که در Lab دقیق بازتولید نمی‌شوند. Authorization، حساب/داده تست، Blast radius و Rollback لازم است.

راهبرد کامل Lifecycle، Manifest و Drift در راهنمای مدیریت محیط تست آمده است.

AWS، Azure و GCP؛ مقایسه Capability به‌جای اعلام برنده

نام و قابلیت Service، Region، Quota، Pricing و Retirement تغییر می‌کند. جدول زیر نمونهٔ خانواده‌های جاری در زمان بازبینی است، نه کاتالوگ کامل یا رتبه‌بندی.

Capability	AWS نمونه	Azure نمونه	Google Cloud نمونه
Compute/containers	EC2، ECS/EKS، Lambda	VMs، Container Apps/AKS، Functions	Compute Engine، Cloud Run/GKE، Cloud Functions
Build/artifact	CodeBuild/CodePipeline، ECR	Azure Pipelines/GitHub Actions، ACR	Cloud Build، Artifact Registry
IaC	CloudFormation/CDK	Bicep/ARM و Terraform	Infrastructure Manager/Terraform
Observability	CloudWatch/X-Ray ecosystem	Azure Monitor/Application Insights	Cloud Monitoring/Logging/Trace
Secrets	Secrets Manager/KMS	Key Vault	Secret Manager/Cloud KMS
Device/browser	Device Farm	Playwright Workspaces برای Browser	Firebase Test Lab برای Mobile
Managed load example	Runner/Solution/partner patterns	Azure Load Testing	Runner روی Compute/GKE/Cloud Run و partner patterns
Fault injection example	AWS FIS	Azure Chaos Studio	Application/Kubernetes/managed-service-specific drills

عدم تقارن جدول عمدی است

Serviceها هم‌ارز یک‌به‌یک نیستند. مثلاً Browser workspace، Mobile device lab و CI runner مسئله‌های متفاوتی حل می‌کنند. نبود نام در یک سلول به معنی ناتوانی Provider نیست؛ ممکن است معماری با Primitive، Open-source یا Partner ساخته شود.

اکوسیستم موجود یک Preference است، نه Verdict

Identity، Network، Skill و Contract موجود می‌تواند TCO را کم کند، اما Must-have مانند Region، Data policy یا Framework support را نباید با «از قبل Azure/AWS/GCP داریم» دور زد.

تست در AWS؛ چه چیزهایی را در PoC بررسی کنیم؟

Device Farm را با Region و Framework واقعی بسنجید

مستندات جاری AWS Device Farm جریان Android/iOS و محدودیت Region را شرح می‌دهد؛ در زمان بازبینی Service در us-west-۲ ارائه شده است. Device catalog، Queue، Test package، private-backend connectivity، Artifact/Log و Pricing را با App واقعی Verify کنید.

AWS FIS برای Fault injection است، نه مجوز Chaos

AWS Fault Injection Service Managed experiment روی Workloadهای AWS فراهم می‌کند. قبل اجرا Target resolution، IAM role، Steady state، CloudWatch stop condition، Safety lever، Account scope و Recovery را آزمایش کنید.

نقاط سؤال در AWS

• Account/Organization و SCP چگونه Test blast radius را محدود می‌کند؟
• Private runner به SUT و Artifact چگونه وصل می‌شود؟
• Spot interruption برای Test workload قابل‌پذیرش است و Result آن چگونه Classify می‌شود؟
• Data transfer، NAT، Log ingestion و idle resource چه سهمی از TCO دارند؟
• Service quota و Region dependency در Peak test چیست؟

تست در Azure؛ چه چیزهایی را در PoC بررسی کنیم؟

Azure Load Testing دامنه و محدودیت مشخص دارد

مستندات جاری Azure Load Testing آن را Service مدیریت‌شده برای تولید Load معرفی می‌کند که در زمان بازبینی JMeter و Locust، Endpoint خصوصی، CI integration و Failure criteria را پشتیبانی می‌کند. Generator health، Region، Engine count، VNet path، Metrics و Auto-stop را با workload واقعی Verify کنید.

Azure Chaos Studio با Scope و Identity کار می‌کند

Azure Chaos Studio در زمان بازبینی Workspace/Scenario و Experimentهای Service-direct/Agent-based دارد. Subscription/Resource group scope، Managed identity، Target region، Fault library، Stop process و Report را قبل Production drill ارزیابی کنید.

نقاط سؤال در Azure

• Subscription/Management group و Policy boundary چگونه است؟
• Entra ID یا Token برای Runner چه Risk و Expiry دارد؟
• Playwright Workspaces Region/Browser/runner/version/quota با Matrix شما سازگار است؟
• Azure Monitor metric فقط برای Azure-hosted component چه مزیت/محدودیتی دارد؟
• هزینه Test engine، result retention، Log و private networking چگونه جمع می‌شود؟

تست در GCP و Firebase؛ چه چیزهایی را در PoC بررسی کنیم؟

Firebase Test Lab را Device matrix واقعی بدانید

مستندات Firebase Test Lab برای iOS Device/configuration matrix، Result و محدودیت‌های Framework/Run را توضیح می‌دهد. Device availability، physical/virtual difference، OS، locale، Queue، Inconclusive، video limitation، private backend و Result storage را در همان زمان PoC بررسی کنید.

Cloud Build و Artifact flow

اگر Build/Test روی GCP اجرا می‌شود، Trigger، Worker pool، Private network، Service account، Artifact Registry، provenance، log access و egress را بررسی کنید. Hosted default و Private pool یک Risk profile ندارند.

نقاط سؤال در GCP

• Organization/Folder/Project و Service account boundary چگونه است؟
• Cloud Run/GKE/Compute runner برای workload stateful یا long-running مناسب است؟
• Cloud Monitoring/Trace چگونه به Run ID و Test result وصل می‌شود؟
• Firebase device catalog و Framework support با Mobile stack شما تطبیق دارد؟
• Region، quota، network egress و Artifact/Log retention چه هزینه‌ای دارند؟

Gateهای انتخاب AWS، Azure یا GCP

Must-haveهای غیرقابل‌امتیازدهی

• دسترسی قانونی/قراردادی و Payment/Support قابل اتکا برای سازمان.
• Region و Service availability مناسب؛ Quota قابل دریافت.
• Data classification، residency، retention و deletion قابل اجرا.
• Private/public connectivity و IP/DNS/TLS نیازمند.
• Identity federation، least privilege و Audit log.
• Framework/runtime/device/OS موردنیاز.
• Budget، alert، hard guardrail و Cleanup.
• Export و Exit path برای Test asset/result.

Preferenceهای امتیازی

پس از عبور Gate، Developer experience، Provision time، p95 Queue، Diagnostic، Ecosystem fit، Cost predictability، Managed capability، portability، Support و Team skill را Weight کنید. Weight باید از Risk و Strategy سازمان بیاید.

Disqualifier نمونه

عدم امکان حذف Verified داده، نیاز به Long-lived administrator key، نبود Region/Device ضروری، عدم دسترسی پایدار از شبکه سازمان یا ممنوعیت قراردادی می‌تواند Candidate را پیش از Score حذف کند.

PoC باید Production-like باشد، نه Demo فروشنده

یک Build واقعی، private endpoint، Synthetic dataset فارسی، Failure injection کنترل‌شده، Change exercise، Peak کوچک، Cleanup و Export نتیجه را امتحان کنید. Demo سبز بدون تغییر و خرابی، Maintainability و Support را نشان نمی‌دهد.

نمونه Scorecard وزنی پس از Gate

معیار	وزن نمونه	Evidence PoC
Production fidelity	۲۰	همان Service/identity/network semantics
Security/data	۱۵	Threat review، deletion، audit، secret flow
Reliability/diagnostic	۱۵	Failure drill و Trace-to-result
Framework/capability fit	۱۵	Run واقعی، نه feature checklist
Cost predictability	۱۰	دو سناریوی usage + alert/limit
Provision/queue time	۱۰	p50/p95 چند Run
Maintainability/upgrade	۵	Change exercise
Exit/export	۵	Delete/migrate rehearsal
Support/access in Iran	۵	Contract/network/payment evidence

وزن‌ها مثال‌اند. امتیاز بالا نمی‌تواند Must-have شکست‌خورده را جبران کند. Confidence هر Score و Source Evidence را کنار آن ثبت کنید.

امنیت Cloud Test Environment

Account isolation و least privilege

Runner نباید Owner/Admin دائمی باشد. Role جدا برای Provision، Execute، Read evidence و Destroy بسازید؛ Permission boundary و Short-lived credential ترجیح دارد. Break-glass ثبت و منقضی شود.

Secret lifecycle

Secret در Repository، YAML Manifest، Test data یا Screenshot نباشد. Secret manager، workload identity، rotation، access audit و Revocation را Test کنید. Mask کردن UI جای حذف از Raw log را نمی‌گیرد.

Network و egress

Private endpoint، firewall/security group، DNS، certificate و outbound allowlist را Explicit کنید. Open کردن ۰.۰.۰.۰/۰ برای حل Test connectivity Debt امنیتی است، نه راه‌حل موقت بی‌اثر.

Testware supply chain

Runner image، Plugin، Browser binary، JMeter extension و Action باید Version/pin، provenance و vulnerability process داشته باشند. Test infrastructure با Permission بالا هدف جذابی برای حمله است.

Rules of Engagement

Performance، DAST و Fault injection روی Shared/Production resource بدون مجوز کتبی، Target دقیق، زمان، Stop condition و contact ممنوع است. اصول کامل در راهنمای تست امنیت نرم‌افزار آمده است.

داده تست در Cloud؛ واقع‌گرایی بدون نشت

Production copy پیش‌فرض نیست

Encryption تنها Risk را حل نمی‌کند؛ Access، re-identification، retention، backup، log، cross-border transfer و deletion باقی می‌مانند. Synthetic، Factory، masked subset و Tokenization را بر اساس هدف انتخاب کنید.

Namespace و Parallel safety

هر Run Tenant/User/Order namespace دارد؛ Unique key و Cleanup idempotent است؛ TTL رکورد orphan را جمع می‌کند. Timezone، Currency، Unicode، Referential integrity و State history در Specification داده ثبت می‌شوند.

Deletion verification

Destroy resource لزوماً Snapshot، Object version، Log و Backup را پاک نمی‌کند. Data inventory و retention class بسازید و Evidence حذف/انقضا را Verify کنید.

Lifecycle و Privacy در راهنمای مدیریت داده تست به‌صورت کامل آمده است.

IaC برای محیط تست؛ تکرارپذیری با محدودیت

Desired، planned، deployed و actual state

Code Desired را بیان می‌کند؛ Plan تغییر را؛ Apply نتیجه Deploy را؛ Provider واقعیت Actual را دارد. Drift یا Failure جزئی می‌تواند میان این Stateها فاصله بسازد. Test باید Plan، Policy و Health actual را ببیند.

State و Plan حساس‌اند

IaC state می‌تواند ID، Endpoint یا Secret داشته باشد. Backend امن، encryption، access، lock، backup و audit لازم است. Plan Artifact نیز Retention و Redaction می‌خواهد.

Destroy تست شود

Dependency order، prevent-destroy، orphan، retained bucket، snapshot و quota release را بررسی کنید. Environment که فقط ساخته می‌شود اما پاک نمی‌شود Ephemeral نیست.

Drift را کورکورانه اصلاح نکنید

Drift ممکن است Incident mitigation یا تغییر غیرمجاز باشد. Detect→Classify→Approve→Reconcile؛ Auto-apply بدون Context می‌تواند Recovery را برگرداند یا داده حذف کند.

تست Load و Performance در Cloud

مدل بار پیش از Generator

Journey mix، arrival rate/closed users، payload، session، think time، cache warm/cold، duration و geographic source را از داده/فرض مستند بسازید. تعداد «کاربر هم‌زمان» به‌تنهایی workload نیست.

Generator health

CPU، memory، network، connection، error و clock خود Generator را Monitor کنید. Saturation Generator می‌تواند SUT را بهتر از واقع نشان دهد. Calibration و distributed clock sync لازم است.

Network و Region

Load از Region نزدیک، Internet واقعی، VPN یا private link Latency متفاوت می‌سازد. Path، DNS، CDN و egress cost را ثبت کنید. Multi-region load فقط وقتی User geography یا resilience آن را می‌طلبد.

Stop condition و هزینه

Error/latency/SLO، Provider throttling، resource saturation، Business impact و Budget threshold می‌توانند Stop rule باشند. Auto-stop Service جای Approval و Watcher را نمی‌گیرد.

نتیجه‌گیری بدون Average

p50/p95/p99، error by type، throughput/goodput، saturation و Server telemetry را Correlate کنید. برای Workload و Oracle دقیق‌تر به راهنمای تست عملکرد مراجعه کنید.

Browser و Mobile Device Farm در Cloud

Matrix از کاربر و Risk می‌آید

OS/version/device/browser/engine/locale/network را از Analytics تصحیح‌شده، Support و Contract انتخاب کنید. همهٔ Deviceهای Catalog را اجرا نکنید؛ Matrix باید Versioned و Journey-based باشد.

Emulation با Real device یکی نیست

Emulator/virtual browser برای Feedback سریع مناسب است؛ Camera، sensor، thermal، permission، vendor skin، push و network radio به Real device نیاز دارد. Cloud physical device نیز دقیقاً Device کاربر با Account/Network او نیست.

Queue، Capacity و Inconclusive

Device availability و Provider infrastructure می‌تواند Run را Block یا Inconclusive کند. Status semantics، Retry، Billing، Artifact و fallback device class را در Contract Test execution تعریف کنید.

Privacy روی Device Lab

APK/IPA، Test package، screenshot، video، log و backend credential به Vendor می‌رود. Data classification، reset statement، result bucket، retention، access و deletion را بررسی کنید.

برای Device/OS/Network و Lifecycle matrix از راهنمای تست اپلیکیشن موبایل و برای Browser/Device coverage از ماتریس تست سازگاری استفاده کنید.

Resilience و Disaster Recovery در Cloud

Hypothesis و Steady state

«اگر Zone A از دسترس خارج شود، Checkout در کمتر از X دقیقه با Error rate زیر Y بازیابی می‌شود» قابل‌آزمون است. «Chaos اجرا کنیم» هدف نیست.

Blast radius و target selection

Account، Region، Resource tag، percentage و Dependency دقیق را محدود کنید. Empty target باید Fail شود؛ selection drift و auto-scaling می‌تواند Target ناخواسته بسازد.

Stop و Rollback مستقل

Alarm/Watcher، Safety lever، credential و Runbook را قبل Fault Verify کنید. فرد اجراکننده نباید تنها مسیر Stop باشد. Rollback نیز تمرین و زمان‌گیری شود.

Backup وجود دارد؛ Restore را ثابت کنید

Snapshot status و SLA سند، RPO/RTO شما را ثابت نمی‌کند. Restore جدا، checksum/invariant، application compatibility، access و cutover/reconciliation را آزمون کنید.

آزمایش Production تدریجی است

ابتدا Fake/Component، سپس isolated integration، Staging، Game day محدود و در صورت نیاز Production-safe. هر مرحله Evidence و Risk پذیرش‌شده مرحله بعد را تعیین می‌کند.

هزینه تست ابری؛ فرمول TCO به‌جای Pay-as-you-go

TCO =
compute + storage + requests + network/egress
+ managed test minutes + device/browser minutes
+ telemetry + artifact/result retention
+ licenses + idle/orphan resources
+ failed reruns + engineering/support
+ security/compliance + migration/exit

Allocation

Tag/label شامل Team، Environment، Run، Purpose، TTL و Owner باشد. Shared cost با Driver روشن مانند compute-minute یا test-minute تخصیص یابد، نه تقسیم مساوی بی‌معنا.

Budget guardrail

Budget/alert به‌تنهایی Resource را متوقف نمی‌کند. Quota، policy، max parallelism، TTL controller، auto-stop و approval برای Run بزرگ لازم است.

Cost per useful signal

هزینه را با Test count تقسیم نکنید. Compute/Device دقیقه و Engineer time را نسبت به Signal قابل‌اقدام، Risk covered و Decision latency بسنجید. Test flaky ارزان می‌تواند هزینه Triage زیادی بسازد.

قیمت را در مقاله ثابت نکنید

Price، Region، Free tier، commitment و egress تغییر می‌کنند. Calculator و Contract همان تاریخ را با دو سناریوی Normal/Peak و Currency/Tax/Support محاسبه کنید.

Vendor lock-in، Portability و Multi-cloud

Lock-in صفر هدف واقع‌بینانه نیست

Managed database، Identity، Queue و Observability ارزش و coupling ایجاد می‌کنند. سؤال این است که Coupling آگاهانه، مستند و متناسب با ارزش باشد و Exit-critical asset قابل‌خروج بماند.

Microservice خودکار Portability نمی‌دهد

Service count بیشتر می‌تواند Contract، data gravity و operation را پیچیده‌تر کند. Container نیز API/Identity/Network/Storage semantics Provider را حذف نمی‌کند.

Portable core و provider adapters

Test intent، Dataset spec، Result schema و Domain DSL را تا حد مفید مستقل نگه دارید؛ Provision/Identity/Observability adapterها Provider-specific باشند. Abstraction فقط روی Variation واقعی ساخته شود.

Exit test

Export Test asset/result، Rotate credential، Restore data، Run critical suite در fallback، Recreate minimal environment و Delete Vendor resources را تمرین کنید. RTO خروج و Data deletion evidence ثبت شود.

Multi-cloud پیش‌فرض نیست

دو Provider هزینه Skill، Network، Identity، Security، Observability و Test matrix را زیاد می‌کنند. فقط Requirement کسب‌وکار/ریسک معتبر باید آن را توجیه کند، نه ترس کلی از Lock-in.

ملاحظات ویژه ایران

Terms، حساب و پرداخت

قبل از معماری، شرایط استفاده، کشور/هویت مجاز، روش پرداخت، Support و امکان Suspend را با منبع رسمی و مشاور مرتبط بررسی کنید. دورزدن محدودیت Contract ریسک توقف ناگهانی و از دست‌رفتن Data/Artifact دارد.

شبکه و Latency

دسترسی به Console/API/Registry/Binary ممکن است ناپایدار باشد. Timeout، retry، resumable upload، Mirror/Cache مجاز، private connectivity و fallback runner را تست کنید. Latency از ایران نباید با Latency کاربر جهانی مخلوط شود.

Data location

Region نزدیک الزاماً از نظر Contract، Data policy یا دسترسی مناسب نیست. Classification، transfer، key control، backup و deletion را با الزامات سازمانی/حقوقی همان زمان تطبیق دهید؛ این راهنما نظر حقوقی نیست.

Supply chain و Self-host fallback

Runner image، Browser binary، Package و IaC provider را در Artifact repository مجاز Cache کنید؛ Version/Checksum/License و update process داشته باشید. Fallback باید تمرین شود، نه فایل نصب قدیمیِ بدون Patch.

فارسی و پرداخت محلی

Locale fa-IR، Timezone Asia/Tehran، RTL/BiDi، فونت، ارقام، تومان/ریال، تاریخ، بانک callback، Signature، Reconciliation و Connectivity متغیر را در Dataset/Matrix بیاورید. Cloud scale جای Domain oracle را نمی‌گیرد.

Pilot سی‌روزه انتخاب Cloud Testing

روزهای ۱ تا ۵: Charter و Gate

• Decision، SUT boundary، Risk و خارج از Scope را بنویسید.
• Must-have/Disqualifier و سه Candidate را ثبت کنید.
• Data classification، Account model، Budget و RoE را تصویب کنید.
• Baseline زمان Provision/Run/Triage و هزینه فعلی را بگیرید.

روزهای ۶ تا ۱۲: Foundation

• Account/Identity/Network و Secret flow را کمینه بسازید.
• Artifact immutable، IaC، State و Manifest را برقرار کنید.
• Dataset synthetic فارسی و Cleanup/TTL را پیاده کنید.
• Health gate و Run-to-trace correlation را اضافه کنید.

روزهای ۱۳ تا ۲۰: Workload واقعی

• Component/Integration، Browser/device یا Load slice منتخب را اجرا کنید.
• p50/p95 Queue/Provision/Run و Failure class را جمع کنید.
• Cost شامل Telemetry، Egress، Idle و Engineer time را ثبت کنید.
• Private dependency و Service quota را عمداً آزمایش کنید.

روزهای ۲۱ تا ۲۶: Change و Failure

• نسخه Product/Test/IaC را تغییر و Maintenance effort را بسنجید.
• یک Dependency failure و یک Provider/runner failure تزریق کنید.
• Stop/rollback، Export و fallback run را تمرین کنید.
• Destroy و deletion را Verify کنید.

روزهای ۲۷ تا ۳۰: Decision record

Gate pass/fail، Score با Confidence، TCO دو سناریو، Risk باقی‌مانده، Lock-in، Support/access و تصمیم Adopt/Revise/Reject را ثبت کنید. برای Pilot تا Scale از قالب استراتژی اتوماسیون تست استفاده کنید.

معیارهای سالم Cloud Testing

دسته	Metric	هشدار
Flow	p50/p95 Provision، Queue، useful feedback	Average Tail را پنهان می‌کند
Trust	Product/Test/Data/Environment/Dependency/Unknown	Retry Pass، Fail اول را حذف نکند
Environment	Health-pass، Drift، blocked run، cleanup success	Resource count Outcome نیست
Cost	Cost per useful signal/Journey	Test count denominator ضعیف است
Security	Unauthorized path، secret age، exception expiry	Scanner count امنیت نیست
Reliability	RTO/RPO evidence، recovery success	Backup success با Restore فرق دارد
Portability	Fallback/exit rehearsal time	ادعای vendor-neutral بدون Run کافی نیست

ضدالگوهای رایج تست ابری

Cloud-first بدون Problem statement

همه Suiteها مهاجرت می‌کنند چون Cloud «آینده» است. درمان: Decision/Risk و Thin slice؛ Local test ارزشمند را بی‌دلیل جابه‌جا نکنید.

Clone کامل Production برای هر PR

هزینه/زمان/Quota زیاد و Fidelity همچنان ناقص است. درمان: Risk-specific environment portfolio و Contract/component در پایین‌ترین Level.

Long-lived admin key در CI

راه‌اندازی آسان اما Blast radius بزرگ است. درمان: workload identity، short-lived credential، scope و audit.

Pay-as-you-go برابر ارزان

Idle، egress، log، rerun و Engineer time دیده نمی‌شود. درمان: TCO و budget/quota/TTL guardrail.

Auto-scaling بدون Generator validation

Test ممکن است Quota/Generator را بسنجد نه SUT را. درمان: Generator health، calibrated load و server telemetry.

Retry همهٔ Infrastructure failureها

Outage و quota پنهان می‌شوند. درمان: Attempt history، Failure taxonomy، bounded retry و SLO Provider dependency.

IaC برابر بدون Drift

Apply موفق با Actual state متفاوت می‌ماند. درمان: Manifest، health، drift detect و controlled reconciliation.

Vendor-neutral به هر قیمت

Abstraction کم‌ارزش Feature و Diagnostic را محدود می‌کند. درمان: portable intent/evidence و coupling آگاهانه با Exit test.

چک‌لیست پیش از Go-live محیط تست ابری

• چهار Scope Cloud Testing و Decision روشن است؟
• Account/Subscription/Project و Billing جداست؟
• Provider/Customer/Team responsibility matrix داریم؟
• Artifact، IaC، Manifest، Dataset و Runner version ثبت می‌شوند؟
• Identity کوتاه‌عمر، Secret manager و least privilege داریم؟
• Network/egress/DNS/TLS و private dependency تست شده؟
• Health gate و Failure taxonomy اجرا می‌شود؟
• Trace/Metric/Log به Run ID وصل و داده حساس Redact است؟
• Quota، Region، Queue و Service limit در PoC دیده شده؟
• Budget، max parallelism، TTL، Cleanup و deletion verification داریم؟
• Load/Fault test مجوز، Stop و Rollback دارد؟
• TCO شامل egress/telemetry/idle/rerun/people/exit است؟
• Service retirement/change و Review date Owner دارد؟
• Fallback/Export/Exit حداقل یک بار تمرین شده؟
• شرایط دسترسی، پرداخت، شبکه، داده و فارسی ایران بررسی شده؟

پرسش‌های متداول تست ابری

تست ابری چه تفاوتی با تست سنتی دارد؟

تفاوت فقط محل سرور نیست. Cloud می‌تواند Provisioning API، Service model، Identity، Quota، Managed dependency، Region و Cost meter وارد Boundary کند. یک Test همان رفتار را ممکن است Local یا Cloud اجرا کند؛ Scope و Evidence تعیین می‌کند تفاوت معنادار است یا نه.

کدام‌یک برای تست بهتر است: AWS، Azure یا GCP؟

برندهٔ عمومی وجود ندارد. Production fidelity، Region/Service/Quota، Data/Identity، Framework، Network، TCO، Support/access و Exit شما تعیین‌کننده‌اند. Must-have را Gate و Candidateهای باقی‌مانده را با PoC یکسان مقایسه کنید.

آیا تست در Cloud ارزان‌تر است؟

ممکن است برای Capacity موقت و کاهش Idle asset ارزان‌تر باشد، اما تضمین نیست. Compute، Device minute، Storage، Request، Egress، Telemetry، License، Idle، Failed rerun، Engineer time و Exit را در دو سناریوی Normal/Peak حساب کنید.

آیا می‌توان داده Production را برای تست به Cloud برد؟

پیش‌فرض امن «خیر تا اثبات نیاز و کنترل» است. Classification، مجوز، Minimization، Masking/Pseudonymization، Re-identification، Access، Region، Backup، Retention و deletion باید ارزیابی شوند. Synthetic یا Factory معمولاً نقطه شروع بهتری است.

آیا Multi-cloud از Vendor lock-in جلوگیری می‌کند؟

نه خودکار. Multi-cloud coupling و عملیات بیشتری می‌سازد. Test intent/result/data spec را تا حد مفید قابل‌انتقال، Adapterهای Provider را جدا و Exit-critical path را تمرین کنید؛ فقط Requirement واقعی باید اجرای هم‌زمان چند Provider را توجیه کند.

منابع و تاریخ بازبینی

منابع رسمی استفاده‌شده

• AWS، Azure و Google Cloud: مدل‌های مسئولیت امنیتی
• AWS Device Farm و AWS Fault Injection Service
• Azure Load Testing و Azure Chaos Studio
• Firebase Test Lab

حدود و تازگی

بازبینی محتوایی: مرداد ۱۴۰۵. Service name، Region، Device، Framework، Quota، Pricing، SLA و Retirement ممکن است سریع تغییر کنند. مستندات و Contract همان نسخه/Region را پیش از خرید یا Gate مرجع قرار دهید. فهرست سرویس‌ها نمونه است؛ هیچ ادعای رتبه‌بندی یا برابری قابلیت میان Providerها ندارد.