# Web testing asoslari

> Web ilovani qanday test qilish kerak? Unit, integration, end-to-end, accessibility, performance va cross-browser testlari hamda test piramidasi.

Manba: https://learncode.uz/web-dasturlash/web-testing/
Sana: 2026-05-12

![Web loyiha unit, integration, end-to-end va qo'lda tekshiruv qatlamlaridan o'tishi](https://learncode.uz/images/web-dasturlash/web-testing-hero.webp)

*Testing kodning faqat bugun ishlashini emas, keyingi o'zgarishdan so'ng ham muhim xatti-harakat saqlanishini tekshiradi.*

Kod bir marta ishlagani uning barcha holatda to'g'ri ekanini anglatmaydi.
**Testing** kutilgan xatti-harakatni aniq talabga aylantirib, o'zgarishdan
keyin qayta tekshirish imkonini beradi. Test xato bo'lmasligini kafolatlamaydi,
lekin muhim muammoni foydalanuvchidan oldin topish ehtimolini oshiradi.

## Avval talabni yozing

Test yozishdan oldin nima to'g'ri hisoblanishini belgilang. Masalan, login
formasi uchun:

- to'g'ri email va parol yuborilganda profil ochiladi;
- noto'g'ri parolda tushunarli xato ko'rsatiladi;
- yuborish tugmasi so'rov davomida takror bosilmaydi;
- forma klaviatura bilan ishlaydi;
- server javob bermasa, qayta urinish imkoniyati chiqadi.

Aniq qabul mezoni bo'lmasa, test faqat kodning hozirgi holatini tasdiqlab,
asl foydalanuvchi ehtiyojini o'tkazib yuborishi mumkin.

## Test turlari

### Unit test

Bitta kichik funksiya yoki modulni alohida tekshiradi. Tez ishlaydi va xato
joyini aniq ko'rsatadi. Masalan, chegirma hisoblash funksiyasi yoki emailni
normalizatsiya qilish.

### Integration test

Bir nechta qism birga ishlashini tekshiradi. Masalan, API route ma'lumotni
tekshirishi, service qatlamini chaqirishi va bazaga yozishi.

### End-to-end test

Ilovani foydalanuvchi kabi brauzerda boshdan-oxir boshqaradi: sahifani ochadi,
formani to'ldiradi, tugmani bosadi va natijani tekshiradi. Ishonchi yuqori,
ammo unit testdan sekinroq va sozlash qimmatroq.

![Ko'p tez unit test, o'rtada integration va kamroq sekin end-to-end testlardan iborat test piramidasi](https://learncode.uz/images/web-dasturlash/test-piramidasi.webp)

*Ko'p tez unit testlar asos yaratadi, integration qismlar hamkorligini, kamroq E2E test esa muhim foydalanuvchi oqimini tekshiradi.*

> **Piramida qat'iy son emas**
>
> Test taqsimoti loyiha turiga bog'liq. Muhimi — barcha ishonchni sekin E2E
> testga yuklamaslik va faqat mayda unit testlar bilan foydalanuvchi oqimini
> tekshirilmay qoldirmaslik.

### Nimadan boshlash kerak

Loyihada hali bitta ham test bo'lmasa, "hammasini qoplash" degan maqsad
qo'ymang — u boshlashga to'sqinlik qiladi. Uch mezon bo'yicha tanlang.

Avval **eng qimmatga tushadigan** xatoni himoya qiling: to'lov, ruxsat
tekshiruvi, ma'lumot o'chirish. Bu joylardagi xato foydalanuvchiga real zarar
keltiradi.

Keyin **eng ko'p o'zgaradigan** mantiqni oling. Tez-tez tahrirlanadigan kod
tez-tez buziladi ham. Test uni har o'zgarishda tekshirib turadi.

Uchinchidan, **xato topilgan har joyga** test yozing. Xatoni tuzatishdan oldin
uni takrorlaydigan test yozing, keyin tuzating. Shunda test o'sha xato qaytmasligini
kafolatlaydi va siz tuzatish haqiqatan ishlaganini ko'rasiz.

### Test nimani almashtiradi

E2E testda haqiqiy tashqi xizmatni chaqirmaslik kerak: to'lov tizimi, email
yuborish yoki uchinchi tomon API'si. Ular sekin, pulli va sizga bog'liq emas.

Ularning o'rniga **mock** ishlatiladi — oldindan belgilangan javob qaytaradigan
soxta versiya. Bu testni tez va barqaror qiladi.

Lekin muvozanat kerak: hamma narsani mock qilsangiz, test faqat mock'larni
tekshiradi, haqiqiy tizimni emas. Amaliy qoida — **o'z kodingizni** haqiqiy
ishlating, faqat tashqi chegarani mock qiling.

## Web sifati faqat funksional test emas

Professional web test rejasi bir nechta yo'nalishni qamraydi:

- **accessibility** — klaviatura, semantika, kontrast va screen reader;
- **cross-browser** — maqsadli brauzer va qurilmalarda ishlash;
- **responsive** — kichik va katta ekranlarda layout;
- **performance** — yuklanish, javob va barqarorlik;
- **security** — ruxsat, ma'lumot tekshiruvi va keng tarqalgan zaifliklar;
- **visual regression** — komponent ko'rinishi kutilmaganda buzilmaganmi;
- **usability** — foydalanuvchi vazifani tushunib bajara oladimi.

Avtomatik test barcha yo'nalishni to'liq qoplay olmaydi. Masalan, rang
kontrastini vosita topishi mumkin, lekin xato matni odam uchun tushunarliligini
inson tekshiradi.

### Chekka holatlarni tanlash

Ko'p xato "odatiy" holatda emas, chekka holatda chiqadi. Har funksiya uchun
quyidagi ro'yxatni ko'rib chiqish odat bo'lsin:

| Holat | Misol |
|---|---|
| Bo'sh | Bo'sh ro'yxat, bo'sh matn, `null` |
| Bitta element | Ko'plik shakli to'g'ri ishlaydimi |
| Juda katta | 10 000 ta yozuv, 5 MB fayl |
| Chegara qiymat | 0, manfiy son, maksimal uzunlik |
| Noto'g'ri format | Raqam o'rniga matn, buzilgan sana |
| Takroriy | Bir xil email ikki marta yuborildi |

Bu ro'yxatni har safar yozib chiqish shart emas — vaqt o'tib u avtomatik
o'ylanadigan odatga aylanadi.

### Qo'lda test ham kerak

Avtomatik test ko'p narsani tekshiradi, lekin hammasini emas. Ba'zi savollarga
faqat odam javob bera oladi: xato xabari tushunarlimi, tugma qayerdaligi
mantiqiymi, foydalanuvchi keyingi qadamni bilyaptimi?

Shu sababli har muhim o'zgarishdan keyin qisqa qo'lda tekshiruv o'tkazing.
Asosiy oqimni foydalanuvchi kabi bajaring, faqat klaviatura bilan ham sinang
va kichik ekranda ko'ring. Bu bir necha daqiqa oladi, lekin avtomatik test
sezmaydigan muammolarni topadi.

## Testni ishonchli qilish

### Ishonchli test xususiyatlari

Yaxshi test:

- natijani foydalanuvchi ko'radigan xatti-harakat orqali tekshiradi;
- boshqa testdan mustaqil ishlaydi;
- vaqt, tarmoq yoki tasodifga keraksiz bog'lanmaydi;
- muvaffaqiyatsiz bo'lsa, sababini tushunarli ko'rsatadi;
- implementation detali o'zgarganda, xatti-harakat saqlansa buzilmaydi.

Masalan, tugmani ichki CSS class nomi bilan emas, accessible nomi —
`Savatga qo'shish` — orqali topish testni foydalanuvchi tajribasiga yaqinlashtiradi.

Bu tanlov yana bir foyda beradi: agar test elementni accessible nomi orqali
topa olmasa, demak ekran o'quvchi ham topa olmaydi. Ya'ni to'g'ri yozilgan
test bir vaqtning o'zida
[accessibility](https://learncode.uz/web-dasturlash/web-accessibility) muammosini ham ochib beradi.

Test nomiga ham e'tibor bering. `test1` yoki `login works` o'rniga nima
tekshirilayotgani aniq yozilsin: "noto'g'ri parolda xato xabari ko'rinadi".
Test yiqilganda uning nomi birinchi ma'lumot manbai bo'ladi.

![Funksional, accessibility, cross-browser, performance va security test yo'nalishlari](https://learncode.uz/images/web-dasturlash/web-test-matritsasi.webp)

*Web mahsulot funksional natijadan tashqari accessibility, moslik, tezlik va xavfsizlik bo'yicha ham tekshiriladi.*

### Beqaror testlar

Eng zararli test — ba'zan o'tadigan, ba'zan yiqiladigan test. U **flaky** deb
ataladi va jamoada ishonchni yo'q qiladi: bir necha marta bekorga yiqilgach,
odamlar qizil natijaga e'tibor bermay qo'yadi.

Sabablari odatda bir nechta:

| Sabab | Belgisi | Yechim |
|---|---|---|
| Qat'iy kutish | `sleep(2000)` bilan kutish | Element paydo bo'lishini kuting |
| Testlar bir-biriga bog'liq | Alohida ishlasa o'tadi | Har testda toza holat |
| Umumiy ma'lumot | Parallel ishlaganda yiqiladi | Har test o'z ma'lumotini yaratadi |
| Vaqt yoki tasodif | Ba'zi kunlarda yiqiladi | Vaqtni va tasodifni boshqaring |

Flaky testni "keyinroq tuzataman" deb qoldirmang. Uni darhol tuzating yoki
vaqtincha o'chiring — ishonchsiz test testsizlikdan yomonroq.

### Qamrov haqida ehtiyotkorlik

Test qamrovi (coverage) — kodning necha foizi test paytida bajarilgani.
Foydali ko'rsatkich, lekin uni maqsadga aylantirish xato.

Sababi oddiy: qamrov kod **bajarilganini** o'lchaydi, natija **tekshirilganini**
emas. Hech qanday tekshiruvsiz funksiyani chaqiradigan test ham qamrovni
oshiradi, lekin hech narsani himoya qilmaydi.

Yuz foiz qamrov ham xatosizlikni anglatmaydi. Ko'p xato kodning o'zida emas,
unutilgan holatda bo'ladi — bo'sh ro'yxat, juda katta son, kutilmagan format.
Bunday holat kodda umuman yozilmagan bo'lsa, qamrov uni ko'rsatmaydi.

Qamrovni yo'nalish sifatida ishlating: past qamrovli fayllar ro'yxati qayerga
e'tibor kerakligini aytadi. Lekin sonni ko'tarish uchun ma'nosiz test yozish
faqat qo'llab-quvvatlash yukini oshiradi.

### CI ichidagi test

Test va build pull request ochilganda avtomatik ishlasa, xato asosiy branchga
qo'shilishidan oldin ko'rinadi. CI jarayonida odatda format, lint, type check,
unit/integration test va production build ketma-ket bajariladi. E2E testlar
alohida preview muhitida ishlashi mumkin.

CI'ning eng muhim xususiyati — **tezlik**. Natija bir necha daqiqada kelsa,
dasturchi kutadi va tuzatadi. Yarim soat davom etsa, u boshqa ishga o'tadi va
kontekstni yo'qotadi. Shu sababli tez testlar (lint, unit) avval, sekinlari
(E2E) keyin ishlatiladi — muammo bo'lsa erta to'xtaydi.

Yana bir qoida: **qizil CI tuzatilmaguncha yangi ish qo'shilmaydi**. Buzilgan
asosiy branch butun jamoani to'sadi va vaqt o'tgani sari sabab topish
qiyinlashadi. Bu tamoyil [Git workflow](https://learncode.uz/web-dasturlash/git-github-workflow)
darsida ham asosiy o'rin egallaydi.

> **Birinchi test rejangiz**
>
> Oddiy kontakt formasi uchun uchta test yozing: bo'sh email yuborilmaydi,
> to'g'ri qiymatlar serverga bir marta yuboriladi, server xatosida foydalanuvchi
> matnli xabar ko'radi. So'ng ayni oqimni faqat klaviatura bilan qo'lda bajaring.

## Qisqacha xulosa

- Test kutilgan xatti-harakatni qayta tekshiriladigan talabga aylantiradi.
- Unit kichik qismni, integration qismlar hamkorligini, E2E to'liq oqimni tekshiradi.
- Accessibility, browser mosligi, performance va security ham test rejasiga kiradi.
- Yaxshi test foydalanuvchi xatti-harakatiga yaqin va mustaqil bo'ladi.
- CI testlarni har o'zgarishda avtomatik bajaradi.

Keyingi darsda [Git va GitHub workflow](https://learncode.uz/web-dasturlash/git-github-workflow)
— o'zgarishlarni xavfsiz boshqarish va jamoa bilan ishlashni ko'ramiz.