Ядроны тестілеу стратегиясы
1) Қағидаттар
Пирамидалық-олжалық теңгерім. База - жылдам модульдік және келісімшарттық тестілер; жоғары - компоненттік және интеграциялық; үстінде - ең аз, бірақ бағалы e2e қабаты.
Shift-left. Ақауды неғұрлым ерте ұстасақ (линтер, статикалық талдау, property-based), соғұрлым арзан болады.
Deterministic by design. Уақытты, желіні, рандомды және сыртқы тәуелділіктерді басқарамыз.
Сапа экономикасы. Кез келген тест - бұл «сақтандыру»: мақсаты - жиынтық шығындарды барынша азайту (ақаулар + тестерді сүйемелдеу).
Тәуекелге бағдарлану. Жабын бизнес-инварианттар мен хаттамаларға (келісімшарттар, іспеттілік, консистенттілік) шоғырландырылады.
2) Тестілеу деңгейлері және жауапкершілік аймақтары
2. 1 Unit (модульдік)
Таза логиканы I/O-сыз тексереді.
Тек шекараны (порт/адаптер) дымқылдаймыз, деректер үшін фабрикаларды пайдаланамыз.
Жылдам (50-100 мс/тест ≤), параллельді.
2. 2 Contract (тұтынушы жеткізуші)
Сервистер арасындағы API-келісімшарттарды (HTTP/gRPC/event) белгілейді.
consumer-driven тәсілін пайдаланамыз: келісімшарттар VCS-де сақталады, жеткізушінің CI-де тексеріледі.
Интеграциялық e2e осалдығын азайтады.
2. 3 Component (нақты сақтау орны бар модульдің үстінде)
Сервистің бір бөлігін нақты ДБ/кэшпен контейнерде (Testcontainers) іске қосамыз.
Схемалардың, индекстердің, транзакциялардың, бұғаттаудың көші-қонын валидациялаймыз.
2. 4 Integration/System (сервистер арасындағы өтпелі жолдар)
Оқшауланған ортада сервистер жиынтығын көтереміз.
Жалғаспалы инварианттарды тексереміз: транзакциялау, ретра, демпотенттілік, қателерді өңдеу.
2. 5 E2E (ең төменгі «құнды» қабат)
Нақты хаттамалар және қоршаған орта «өнімдегідей», бірақ шектеулі сценарий жиынтығы: төлем → растау → сым; тіркеу → верификация → кіру.
Релиздер мен регресс шығару үшін жоғары тәуекелді фичтерді пайдаланамыз.
3) Қамырға жарамды сәулет
Порттар/адаптерлер (Hexagonal). Бизнес-ядро HTTP/SQL туралы білмейді; тәуелділіктер интерфейстер арқылы енгізіледі.
Уақыт/рандома инъекциясы. 'Clock', 'Random' - тәуелділік; тесттерде белгілейміз.
Конфигурацияланатын I/O абстракциясы. Кезектер, ДБ, KMS - тестілік іске асырулары бар интерфейстер арқылы.
Функционалдық инварианттар. Постдекаттар мен жағдайларды анық тұжырымдаймыз - оларды тестілеу мен мониторингілеу оңай.
4) Тестке арналған деректер
Статикалық JSON-фикстуралардың орнына фабрикалар/билерлер: морт.
Тест алдындағы идемпотенттік сидтер және БД ресет-хук (migrations → truncate → seed).
Кейстердің каталогтары: «нормалар», «шеттер», «қателер», «хаос».
Нақты ПД орнына синтетика: генераторлар, бүркемелеу, құпиялылық профильдері.
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 result6) Уақыт, таймауттар, уақыт белдеулері
Барлық сақталған уақыттар - UTC; тесттерде 'FixedClock' пайдаланамыз.
DST-кейстерді (дубли/сағаттарды жіберу), «жергілікті күн» терезелерін тестілейміз.
Таймауттарды монотонды сағаттармен тексереміз; NTP дірілдеуін елестетеміз.
7) Тұрақтылық және хаос
Fault-injection: желілік қателер, 5xx, кідірістер, ішінара тозу (кэш қол жетімді емес).
Chaos-тесттер pre-prod ортасында: тораптарды өшіру, кезектерді қайта жүктеу, BGP/Anycast үзілістері (эмуляция).
Fallback саясаты және UX деградациясы: тестілер дұрыс «graceful degradation» растауы тиіс.
8) Өнімділік
Сыни алгоритмдерге арналған микро-бенчмаркалар (CPU/alloc тіркеуімен).
Жүктеме профильдері: baseline (p50/p95), стресс (шыңы), есте сақтау кемуі үшін ұзартылған (soak).
Регресс-гейттер: егер p95 латенттілігі baseline> X% -дан нашар болса, build сәтсіз болады.
9) Қауіпсіздік және сәйкестік
SAST/Lint: кемшіліктерді/антипаттерндерді іздеу.
DAST/IAST: стендтегі базалық сценарийлер (XSS/SQLi/SSRF-сынамалар).
Secrets-scan: код пен артефактілерде кілттердің/парольдердің болмауы.
Privacy-тестілер: логдарда/трассировкаларда ПД болмауы, «келісімдерді басқаруды» сақтау, түсіру үшін анонимдеу профильдері.
10) Сапа өлшемдері және SLO
Test pass rate және flaky index (тұрақсыз тесттер саны/апта).
Coverage-мақсатты:- Ядроның сындарлы модульдері үшін 90-100%,
- Периферия үшін 70-80% (инварианттарға назар аудара отырып).
- Release risk score: жиынтығы: сыни файлдардағы өзгерістер × бенчмаркалардың құлдырауы × жаңа flaky.
- Қате бюджет: эксперименттермен және релиздердің жиілігімен прод-SLO (аптайм/қателер) байланысы.
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-мен карантин: тест релиздердi бөгемейдi, бiрақ N күндерде түзетiлуге/қайта жазылуға мiндеттi.
Сыни жолдың «өзегіндегі» жалаушаға нөлдік төзімділік.
13) Property-based, мутациялық және фазз-тестілеу
Property-based: қасиеттерді (коммутативтілік, идемпотенттілік, біркелкілік), шекті деректер генераторларын қалыптастырамыз.
Mutation testing: тесттердің «күшін» өлшейміз (олар енгізілген мутацияларды өлтіре ме).
Fuzzing: хаттамалар/парсерлер/форматтар (JSON, Protobuf, CSV), әсіресе қауіпсіздік шекараларында.
prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model14) Байқау және тесттермен байланыс
Тестілерді трассалау (логтардағы trace-id): pre-prod-да репликалау ыңғайлы.
Перформанс-прогондағы метриктердің снапшоттарын - артефакт ретінде сақтаймыз.
Логтарды бақылау: сезімтал өрістердің болмауы, логтардың мөлшері SLO шегінде.
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. Тесттердің прод-SLO және қате бюджетпен байланысы ашық рәсімделген бе?
10. Runbook 'және инварианттар каталогы құжатталған ба?
Қорытынды
Ядроны тестілеу стратегиясы - құралдардың тізімі емес, сәулеттік қабілеті: тестке жарамды дизайн, деңгейлердің қатаң иерархиясы, басқарылатын деректер, істен шығуға төзімділік және CI/CD-ге орнатылған метрика. Сипатталған тәжірибелерге сүйене отырып, команда жылдам және сенімді кері байланыс алады, ал релиздер болжамды және қауіпсіз болады.