Негизги сыноо стратегиясы

1) Принциптер

Пирамида-олжо балансы. База - тез модулдук жана контракттык тесттер; жогоруда - компоненттик жана интеграциялык; чокусунда - минималдуу, бирок баалуу катмар e2e.
Shift-left. Канчалык эрте кемчиликти кармасак (линтер, статикалык анализ, property-based), ошончолук арзан болот.
Deterministic by design. Биз убакытты, тармакты, рандомду жана тышкы көз карандылыкты башкарабыз.
Сапат экономикасы. Ар бир тест - бул "камсыздандыруу": максаты - жалпы чыгымдарды азайтуу (кемчиликтер + тесттерди колдоо).
Тобокелдик багыты. Каптоо бизнес-инварианттарга жана протоколдорго (контракттар, демпотенттүүлүк, консистенттүүлүк) топтолот.

2) Тестирлөөнүн деңгээли жана жоопкерчилик зонасы

2. 1 бирдик (модулдук)

I/O жок таза логикасын текшерүү.
Чек араны гана мокойбуз (порт/адаптер), маалыматтар үчүн фабрикаларды колдонобуз.
Fast (≤ 50-100 ms/тест), параллелдүү.

2. 2 Contract (керектөөчү камсыздоочу)

Кызматтардын ортосундагы API-контракттар (HTTP/gRPC/event) белгиленет.
Биз consumer-driven ыкмасын колдонобуз: келишимдер VCS сакталат, CI берүүчүдө текшерилет.
интеграциялык e2e морт азайтуу.

2. 3 Component (модулдун үстүндө, реалдуу сактоо менен)

Биз контейнерде реалдуу DD/кэш менен кызматтын бир бөлүгүн ишке киргизүү (Testcontainers).
Биз схемалар, индекстер, бүтүмдөр, бөгөттөө көчүрүү тастыктады.

2. 4 Integration/System (кызматтардын ортосундагы жолдор аркылуу)

Биз обочолонгон чөйрөдө кызматтардын топтомун көтөрөбүз.
Биз инварианттарды текшерип жатабыз: транзакциялуулук, ретра, демпотенттүүлүк, каталарды иштетүү.

2. 5 E2E (минималдуу "баалуу" катмар)

Чыныгы протоколдор жана айлана-чөйрө "прод сыяктуу", бирок чектелген скрипт топтому: төлөм → ырастоо → зым; каттоо → текшерүү → кирүү.
Биз релиздерди жана регресс жогорку тобокелдик fich чыгаруу үчүн колдонулат.

3) Камырга жарактуу архитектура

Порттор/адаптерлер (Hexagonal). Бизнес өзөгү HTTP/SQL жөнүндө билбейт; көз карандылыктар интерфейстер аркылуу ишке ашырылат.
Убакыт/жолугушуу инъекциясы. 'Clock', 'Random' - көз карандылык; тесттерде жазып жатабыз.
Конфигурациялануучу I/O абстракциясы. Кезектер, DD, KMS - тесттик ишке ашыруу менен интерфейстер аркылуу.
Функционалдык инварианттар. Биз пост-шарттарды жана предикаттарды так формулировкалайбыз - аларды тестирлөө жана мониторинг жүргүзүү оңой.

4) тесттер үчүн маалыматтар

Factory/Bilders ордуна статикалык JSON түзөтүү: аз морт.
Idempotent сиддер жана сыноо алдында DD reset-hook (migrations → truncate → seed).
Кейстердин каталогдору: "нормалар", "чети", "каталар", "башаламандык".
Синтетика ордуна реалдуу PD: генераторлор, жашыруу, купуялык профилдери.

5) Атаандаштык жана демпотенттүүлүк

Жарыш тесттер (race): атаандаштык жазуулар/камдар/блоктор.
Демпотенттик ачкычтарды текшерүү (мисалы, '(operation, external_id)'): кайталап чалуулар абалын өзгөртпөйт.
Ретрайдар жана таймауттар: убактылуу каталар болгон учурда тууралыкка кепилдик беребиз.

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6) Убакыт, убакыт, убакыт алкактары

Бардык сакталган убакыт - UTC; сыноолордо 'FixedClock' колдонушат.
Биз DST-учурларда (double/саат өтүү), терезелер "жергиликтүү күн" сыноо.
Таймауттар монотондук саат менен текшерилет; NTP титиреп.

7) Туруктуулук жана башаламандык

Fault-injection: тармак каталар, 5xx, кечигүү, жарым-жартылай деградация (кэш жеткиликтүү эмес).
Pre-prod чөйрөдө Chaos-тесттер: түйүндөрдү өчүрүү, кезектерди ашыкча жүктөө, BGP/Anycast үзүлүшү (эмуляция).
Fallback саясаты жана UX деградациясы: тесттер туура "graceful degradation" тастыкташы керек.

8) аткаруу

Критикалык алгоритмдер үчүн микро-эталондор (CPU/alloc бекитүү менен).
Жүктөө Profils: baseline (p50/p95), стресс (чокусу), узартылган (soak) эстутум агуусу үчүн.
Регресс-гейт: p95 латенттүүлүк начар baseline> X% болсо, куруу ишке ашпай калат.

9) Коопсуздук жана шайкештик

SAST/Lint: кемчиликтерди/анти-паттерн издөө.
DAST/IAST: Негизги стенд сценарийлери (XSS/SQLi/SSRF үлгүлөрү).
Secrets-scan: код жана артефакттарда ачкычтардын/сырсөздөрдүн жоктугу.
Privacy-тесттер: Логин/Tracking PD жоктугу, "макулдуктарды башкаруу" сактоо, жүктөө үчүн анонимдештирүү профилдери.

10) Сапат өлчөө жана SLO

Test pass rate жана flaky index (туруксуз тесттердин саны/жума).

• 90-100% маанилүү ядро модулдары үчүн,
• периферия үчүн 70-80% (инварианттарга басым жасоо менен).
• Release risk score: жыйындысы: критикалык файлдарды өзгөртүү × эталондордун кулашы × жаңы flaky.
• Ката бюджет: тажрыйба жана релиздер жыштыгы менен prod-SLO (aptime/каталар) бир топ.

11) CI/CD жана гейт

1. Lint/Format/TypeCheck

2. Unit + Property-based

3. Contract provider/consumer

4. Component (Testcontainers)

5. Integration + Perf smoke

6. Security (SAST/Secrets)

7. Build/Package + SBOM

8. Deploy to pre-prod + e2e + chaos smoke

Гейтс: контракттардын төмөндөшү, латенттүүлүктүн өсүшү, жаңы критикалык алсыздыктар боюнча токтоо.

Кэш жана шардинг: параллелизм жана инкременталдык прогондор (өзгөртүлгөн модулдар боюнча) аркылуу pipeline тездетүү.

12) Flaky-тесттер: аныктоо жана дарылоо

Автоповтор + кворум (2/3 прогон).
Флак үлгүлөрүнүн детектору: убакытка/жолугушууга/бүдөмүк күтүүлөргө көз карандылык.
SLA менен карантин: тест релиздерди бөгөттөп эмес, бирок оңдоого/N күндөрдө кайра жазууга милдеттүү.
Маанилүү жолдун "өзөгүндө" флакыга нөлдүк толеранттуулук.

13) Property-негизделген, мутациялык жана фазалык тестирлөө

Property-based: касиеттерин түзүү (коммутативдүүлүк, боштук, монотондук), чек маалымат генераторлору.
Мутация тестирлөө: тесттердин "күчүн" өлчөө (алар киргизилген мутацияларды өлтүрөбү).
Fuzzing: протоколдор/парсерлер/форматтар (JSON, Protobuf, CSV), өзгөчө коопсуздук чектеринде.

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14) Байкоо жана тесттер менен байланыш

Trace сыноо (логдордо trace-id): pre-prod-жылы replay үчүн ыңгайлуу.
Аткарууну өткөрүүдө метриктердин снапшоттары - артефакт катары сакталат.
Logs Control: сезгич талаалардын жоктугу, SLO ичинде logs көлөмү.

15) Документтер жана жол-жоболор

Test Handbook: кайсы жерде тесттер баштоо үчүн, кантип жазуу үчүн фабрика, кантип жаңыртуу келишимдер.
Runbooks: окуя реплика, тез диагностика, кайра чыгаруу.
Инварианттар каталогу: системалык кепилдиктердин жана тиешелүү тесттерге/алерттерге шилтемелердин тизмеси.

16) Архитектордун чек тизмеси

1. Ядронун инварианттары жана оор жолдору сүрөттөлөбү?
2. Тесттердин деңгээлинин матрицасы жана алардын SLO (убакыт, туруктуулук) барбы?
3. Келишимдер берүүчүнүн жана керектөөчүнүн CI версияланат жана тастыкталат?
4. Убакыт/жолугушуу/тармак тесттерде көзөмөлдөнөт (FixedClock, Fault-injector)?
5. Орнотулган Testcontainers/изоляцияланган DD, миграция текшерилет?
6. Регрессия үчүн спектакль-базлайндар жана дарбазалар барбы?
7. SAST/Secrets-scan жана privacy-логин текшерүү кирет?
8. flaky эсепке алуу жана SLA туура бар?
9. Тесттердин прод-СЛО жана жаңылыш бюджет менен байланышы ачык-айкын жасалганбы?
10. Runbook жана инварианттар каталогу документтештирилди?

Корутунду

Негизги сыноо стратегиясы инструменттердин тизмеси эмес, архитектуралык жөндөмдүүлүгү: тестке жарамдуу дизайн, катуу деңгээлдердин иерархиясы, башкарылуучу маалыматтар, ката каршылык жана CI/CDге орнотулган метриктер. Жогоруда баяндалган тажрыйбаларды ээрчип, команда тез жана ишенимдүү пикир алат, жана релиздер алдын ала жана коопсуз болуп калат.