Integratsion test senariylarini loyihalash va boshqarish

1. Kirish

Soʻrovnoma boshqaruv xizmati foydalanuvchilarga onlayn soʻrovlarga javob berish, xodimlar va administratorlarga esa natijalarni tekshirish va boshqarish imkonini beradi. Oʻzida oddiy ko‘rinayotgandek tuyulsa-da, ruxsatlar va ekran oqimlari foydalanuvchilar, xodimlar va administratorlar kabi rollarga qarab farq qiladi va autentifikatsiya usullari a'zolik holatiga qarab o'zgaradi. Bundan tashqari, bu tashqi integratsiya tizimlari bilan ma'lumot sinxronlashuvi bilan bog‘liq bo‘lib, shuning uchun alohida funktsiyalarning oddiy ishlashi bilan xizmatning umumiy sifatini kafolatlash qiyin.

Ushbu loyihada men QA rolida ishladim, bu erda talablarga muvofiq hujjatga asoslangan integratsiya test senariylarini yozdim va ularni uch bosqichda: ishlab chiqish (dev), staging (stg) va ishlab chiqarish (prod) orqali bajarib, boshqardim. Ushbu jarayonda men 71 ta test senariyasi (TS) va 376 ta batafsil test vazifasidan (TC) iborat integratsiya test hujjatini yakuniy ravishda yaratdim va boshqardim.

Ushbu maqola shunchaki 'testlar o'tkazildi' deb xabar bermaydi, balki senariyalarni ushbu tuzilishda dizayn qilganim sababim, istisno holatlarini chiqarish uchun ishlatilgan mezonlar va hujjatlarni qanday qilib boshqarish kerakligini markazga olib, tajribalarimni tartibga keltiradi.

2. Integratsiya Test Senariysi Dizayni uchun Zaruriyatning Orqa Foni

Loyihaning boshida biz har bir API va ekranning funksional darajadagi normal ishlashini tasdiqlayotgan edik. Biroq, a'zolik ro'yxatdan o'tishidan identifikatsiya tasdiqlashgacha bo'lgan oqim funksiyalarida, shartlar bilan kelishish va shifoxona axborot integratsiyasi orqali bosqich individual ravishda normal bo'lishi mumkin, ammo umumiy oqimda yoki avvalgi bosqichlardagi istisno ishlov berish sababli status qiymatlari noto'g'ri uzatilishi mumkin edi.

Bundan tashqari, bir xil ekran uchun ham, ko‘rsatilgan ma’lumotlar va amalga oshiriladigan harakatlar foydalanuvchilar, xodimlar, tibbiy xodimlar va administratorlar kabi rollarga qarab farq qilishi, 'Bu rol ushbu ekran orqali kirishda mo‘ljallanganidek cheklanganmi?' kabi tasdiqlovlarni funksional birlik testlari bilan almashtirishni imkonsiz qiladi. Shuning uchun, talablar aniqlanishi hujjatidagi individual funktsiyalarga asoslangan foydalanuvchi oqimi tomonidan tuzilgan integratsiya test senariysi zarur deb topildi.

Senariylarni alohida ishlab chiqish uchun uchta amaliy maqsad bor edi. Joylashtirishdan oldin regressiya test doirasini aniq belgilash, yangi xodimlarga hujjatlar orqali to‘liq xizmat oqimini tushunishga imkon berish va xatoliklar yuzaga kelganda qaysi senariy va holatlarda yuzaga kelganligini kuzatish uchun manba nuqtasini taqdim etish.

3. Talablar Aniqlanishi Hujjatini Test Senariyalariga Qanday Tuzish

Talablar aniqlanishi hujjati odatda funksional birliklar bo‘yicha tartibga solinadi. Agar bu bevosita test elementlariga o‘tkazilsa, bir holat juda keng bo‘lishi yoki aksincha, haddan tashqari bo‘laklarga bo‘linishi mumkin, bu esa umumiy oqimni noaniq qiladi. Buni hal qilish uchun men senariy hujjatini ikki qavatli tuzishda dizayn qildim.

Birinci qatlam test senariysi (TS) dir. TS foydalanuvchining bir maqsadga erishish uchun o'tishi kerak bo'lgan to'liq ish jarayonini bir blok sifatida qamrab oladi. Masalan, 'Shartnoma va identifikatsiya tasdiqlovchi' deb nomlangan bitta senariya, ism kiritish, telefon raqamini tekshirish va tasdiqlovchi raqamni tekshirish kabi turli bosqichlarni o'z ichiga olgan bitta maqsadga qaratilgan oqim sifatida belgilangan.

Ikkinchi qatlam test vazifasi (TC). TC senariy ichida tasdiqlanishi kerak bo'lgan individual shartlarni anglatadi. Yuqorida eslatib o'tilgan 'Shartnoma va identifikatsiya tasdiqlovchi' senariyida, ism kiritilmaganida, telefon raqami formati noto'g'ri bo'lganida va tasdiqlovchi raqam mos kelmaganda qanday boshqarilishi kabi ko'plab holatlar mavjud bo'ladi.

Senariylar va holatlarni ajratadigan ushbu tuzilma amaliy sohalarda afzalliklar taqdim etdi. Senariylar ro'yxatini tezda ko'zdan kechirish orqali xizmatning umumiy ish jarayonini bir qarashda tushunish mumkin, bajarish holat birligi bo'yicha batafsil boshqarilishi mumkin va xatoliklar sodir bo'lganda, qaysi senariyaning qaysi holatiga taalluqli ekanligini darhol aniqlash mumkin, bu esa dasturchilar jamoasi bilan aloqa xarajatlarini sezilarli darajada kamaytiradi.

4. Ikkita O'q: Maqsad va Funksional Soha Bo'yicha Tasniflash

Senariylar va holatlar soni oshgan sari, ularni oddiy ro'yxat formatida boshqarish qiyinlashadi. 71 ta senariya va 376 ta holatni samarali boshqarish uchun barcha holatlarga ikkita tasniflash o'qi berildi.

Birinchi o'q 'Target' deb nomlangan. U haqiqiy foydalanuvchilar, xodimlar, tibbiyot xodimlari, administratorlar, kiosklar va boshqalar rollari asosida tasniflangan. Bir xil funksionallikka ega bo'lsa ham, ekran tuzilishi va kirish huquqlari rolga qarab farq qiladi, shuning uchun agar bu o'q ajratilmasa, faqat ma'lum rollarda yuzaga keladigan muammolarni o'tkazib yuborish oson.

Ikkinchi o'q 'Classification' deb nomlangan bo'lib, u xizmatdagi funksional sohalar asosida tasniflangan, masalan, autentifikatsiya, formatlash, so'rovlar, statistik vizualizatsiya, mening sahifam, aloqa qutisi, boshqaruv paneli, menyu, boshqaruv va h.k. Ushbu o'q dasturlash jamoasiga kodni o'zgartirganda faqat ma'lum sohadagi holatlar bo'yicha regressiya testlarini o'tkazish imkonini berish uchun ishlab chiqilgan.

Bu ikki o'qi kesishishi orqali butun hujjatni ko'rmasdan faqat zaruriy doirani tezda ajratish mumkin, masalan 'administrator ekranidagi autentifikatsiya bilan bog'liq funktsiyalarni qayta tasdiqlash' yoki 'foydalanuvchi tomonidan ishlatiladigan barcha funktsiyalarni kompleks ravishda tasdiqlash'. Qisqa chiqarish davrini inobatga olgan holda, har safar 376 ta holatni qayta o'tkazish qiyin edi, shuning uchun ushbu tasniflash tizimi regressiya testlarini maqbul darajada qisqartirishga amaliy hissa qo'shdi.

5. Happy Path-dan o‘tib ketadigan istisno holatlarini aniqlash

Talablar spetsifikatsiyasi odatda normal oqim, ya'ni Happy Path-ni belgilaydi. Biroq, haqiqiy xizmat ko'rsatish jarayonida yuzaga keladigan ko'p sonli muammolar odatda normal oqimda emas, balki atrofdagi istisno vaziyatlarida yuz berishi mumkin. Ushbu istisno holatlarini to'liq aniqlash talablarni to'g'ridan-to'g'ri o'zgartirib yozish orqali qiyin, shuning uchun har safar senariy yozilganda quyidagi to'rt verifikatsiya usulini takroran qo'llash usuli ishlatilgan.

• Majburiy qiymatni tekshirish: Zaruriy kiritish elementi bo'sh bo'lsa, keyingi qadamga o'tishga urinish

• Formatni tekshirish: Belgilangan formatdan (raqamlar soni, ruxsat berilgan belgilar va boshqalar) chetga chiqadigan qiymatni kiritish

• Holatga asoslangan tekshirish: Mavjud yoki takroriy holat mavjud bo'lgan hollarda yoki qiymatlar bir-biriga mos kelmaydigan hollarda

• Siyosatga asoslangan tekshirish: Vaqt chegaralarini oshirish yoki urinishlarni cheklash kabi siyosatlar natijasida oqim o'zgaradigan hollarda

Quyidagi jadval autentifikatsiya bilan bog'liq senariylar uchun ushbu to'rt usulni qo'llash misollarini umumlashtiradi.

Masalan, talablar spesifikatsiyasida 'mobil telefonni tasdiqlash kodini qabul qilish va tasdiqlashni amalga oshirish' deb bitta qatorda oddiy tarzda bayon etilgan bo'lsa-da, yuqoridagi naqshni qo'llash aslida tasdiqlash kodi uchun kirish yo'qligi, format xatolari, mos kelmasliklar, amal qilish muddati tugashi va urinishlar sonining oshirilishi kabi taxminan beshta holatni keltirib chiqardi. Shu tarzda, talab hujjatida aniq ko'rsatilmagan holatlarni QA nuqtai nazaridan oldindan chiqarishda eng ko'p vaqt va e'tiborni talab qiladigan qism, ssenariy yozish jarayonida bo'lgan.

6. Dev, stg va prod muhitlaridagi test strategiyasi

Yozilgan ssenariylar uch bosqichda amalga oshirildi: ishlab chiqish (dev), staging (stg) va ishlab chiqarish (prod). Uchtalik muhitning maqsadlari turlicha bo'lganligi sababli, bir xil holat uchun ham, tekshirishga bo'lgan nazar muhitga qarab turlicha yondashildi.

Dev muhitida funktsionallik tez va takroran nazorat qilinadigan test ma'lumotlari bilan tasdiqlanganligini ta'minlash maqsadida talablar bo'yicha amalga oshirilganligini, ya'ni mantiqning o'zining mosligini tezda tekshirildi. Stg muhitida tashqi integratsiya tizimlari bilan ma'lumotlarni sinxronlashtirish va kuzatuv tizimini qayta tasdiqlash ishlab chiqarishga o'xshash sharoitlarda amalga oshirildi va ko'p hollarda ishlov berish tartibi yoki tashqi tizimlardan javob kechikishlariga oid muammolar bu bosqichda aniqlandi.

Prod muhitida verifikatsiyaning ko'lami faqat kelishilgan asosiy jarayon va bu chiqarilishdan qisqa vaqt ichida o'zgargan joylarni tekshirish uchun mo'ljallangan smoke test bilan minimallashtirildi. Bu har bir muhit uchun turli maqsadlar va ko'lami o'rnatilishi orqali bir xil ssenariy hujjatidan samarali foydalanish imkonini berdi.

7. Test natijalarini yozish bo'yicha prinsiplari

Testlash jarayonida barcha holatlar aniq tarzda muvaffaqiyat yoki muvaffaqiyatsizlikka bo'linishi odatiy hisoblanmaydi. Tashqi tizimdan kelayotgan javobdan oldin verifikatsiya faqat amalga oshirilishi mumkin bo'lgan ko'plab vaziyatlar yoki siyosat sababli verifikatsiyadan chiqarilishi kerak bo'lgan hollarda ko'p vaziyatlar mavjud edi. Agar biz bu vaziyatlarni oddiygina muvaffaqiyatsizlik sifatida yozib qo'ysak, bu yozuvni keyingi ko'rish uchun boshqa ko'rishlar muammo sababini noto'g'ri tushunishi mumkin bo'lganligi sababli, natijalarni to'rt ta'lifga tasniflash prinsipi o'rnatildi.

BEKOR QILINDI va TO'SIQ sifatida qayd etilgan holatlar uchun biz doimo izohlar bo'limida aniq sabab qoldirdik. Masalan, xabarni qabul qilish va so'rov API chaqiruvining tashqi tizimdan bir martalik tranzaksiya sifatida ishlov berilganida, aniq xabar xususiyatining to'g'ri natijalarni kafolatlay olmaydi deb tasdiqlandi. Shunday qilib, biz mantiqni ajratishga va keyin qayta tasdiqlashga qaror qildik. Bu shunchaki 'muvaffaqiyatsiz' deb qoldirib, sabab va qayta tasdiqlash shartlarini birga yozish o'rniga TO'SIQ sifatida tasniflaganimiz sabab, mantiq keyinchalik ajratilganda bu holatni aniq topib qayta ishga tushirishimiz mumkin bo'ldi.

Bunga qo'shimcha ravishda, tekshirish va tuzatish mavzulari loyiha ichida emas, xizmatga mijoz tizim ekranining joylashtirilishi kabi xususiyatlar bo'lgan joylar mavjud. Ushbu maydonlarda xato topilganda, to'g'ridan-to'g'ri tuzatish imkoniyati bo'lmaganligi sababli, biz o'sha ekran uchun mas'ul shaxsni ko'rsatamiz va reproduktsiya shartlari bilan tuzatishlarni so'raymiz, va refleksiyani tasdiqlagandan so'ng, natijalarni yangilash uchun faqat o'sha holatni qayta bajarishimiz kerak. MUVAQQIYATIZ sifatida qayd etilgan holatlar asosan mas'ul ishlab chiqaruvchiga yetkazilgan bo'lib, o'zgartirish taqsimotidan so'ng, biz ulardan xalos bo'lish uchun bir xil TC_ID bilan qayta tasdiqlash jarayonini takrorladik. Ushbu jarayonda, ilgari tashkil etilgan ID tizimi va natija tasniflash printsiplari tashkilotlar o'rtasidagi aloqalarni samarali ravishda belgilab borganini tasdiqlash imkonini berdik.

8. Senariy hujjatlarida identifikatorlarni (IDlarni) boshqarish printsiplari

Men amaliyot orqali shuni sezdimki, holatlar soni ko'payishi bilan, har bir holatni aniqlash uchun ID tizimi hujjatning umumiy ishonchliligiga ta'sir ko'rsatadi. Senariylar ichida TS_ID berildi va holatlarga TC_ID ketma-ket berildi; bu ID nafaqat senariy hujjati ichida ishlatilgan, balki bug' hisobotlari, regressiya test natijalarining jadvallari va tarqatish tekshirish ro'yxatlari kabi turli topshiriqlarda takroran keltirilgan.

Ushbu jarayonda amal qilgan eng muhim prinsip bu 'bir marta ID berilganda, uning mazmuni tasdiqlash shartlari o'zgarmasa, yangilanmasligi kerak' edi. Agar biron bir holatning tasdiqlash maqsadi butunlay o'zgarsa, mavjud ID mazmunini o'zgartirish o'rniga, biz mavjud IDni bekor qilib, yangi ID berishni tanladik, uni alohida holat sifatida ko'rib chiqdik. Imlo xatolarini tuzatish yoki ifodalarni aniqlashtirish kabi kichik o'zgarishlar bir xil IDni saqlash bilan amalga oshirildi, lekin tasdiqlash shartlari yoki kutilayotgan natijalar o'zgargan hollarda yangilanish bexosdan ID berildi.

Ushbu printsiplarga amal qilish sababi, ID oddiy raqam emas, balki aniq vaqt momentida sinov tarixini ko'rsatuvchi havola nuqtasidir. Agar bir xil ID ostidagi mazmun butunlay boshqa holatga o'zgartirilsa, bu o'sha IDga havola beruvchi bug' hisobotlari yoki ijro tarixlari aslida boshqa mazmunlarga qarab ketishiga olib keladi. Bu ma'lumotlar bazasi sxemalaridagi o'zgarishlar yoki API versiyalarini boshqarish bilan bir xil prinsipga amal qiladi, bu erda eski versiyani saqlab, yangi versiya qo'shiladi. Shuningdek, bir marta ID bekor qilinib, kelajakda qayta foydalanilmasligi uchun tamoyil o'rnatildi, bu esa hujjat tarixining to'liq saqlanishini ta'minlaydi.

9. Ilova natijalari va aks ettirish

Yuqoridagi printsiplarga asoslanib, biz 71 ta senariy va 376 ta sinov holatidan iborat integratsiya test hujjatini tayyorladik va ularni ketma-ket ravishda dev, stg, va prod muhitlarida bajardik. Holatlarning aksariyati odatdagi ko'rinishda o'tgan, ba'zilari esa tashqi tizim integratsiyasi yoki atrof-muhit cheklovlari sababli BEKOR QILINDI yoki TO'SIQ sifatida tasniflangan va alohida boshqarishda qoldi.

Eng katta saboq shundaki, integratsion test ssenariylarini yozishda, ko'p vaqt talab qiladigan vazifa talablar hujjatini o'qish emas, balki hujjatda ko'rsatilmagan istisno holatlarini topishdir. Men amaliyot orqali shuni ham tasdiqladimki, to'rt tasdiqlash tartibini va ID boshqaruvi yoki natijalarni klassifikatsiya qilish kabi ko'rinadigan oddiy qoidalarni mexanik tarzda qo'llash odati, shunda holatlar soni yuzlab bo'lganda butun hujjatning ishonchliligini qo'llab-quvvatlaydi.

Kelajakda, agar men bunday o'lchamdagi loyihani o'z zimmamga olsam, o'ylaymanki, loyiha boshidan butun jamoa bilan bo'lishish mumkin bo'lgan ssenariy dizayn prinsiplari va ushbu vaqt ichida o'rnatilgan hujjatlarni boshqarish qoidalarini hujjatlash to'g'ri bo'ladi va inson fikri muhim bo'lgan sohalarga, masalan, istisno holatlarni aniqlash kabi, qo'l bilan sinov resurslarini yo'naltirish uchun, takroriy bajariladigan regressiya testlarida avtomatlashtirish uchun hududlarni tanlashga e'tibor qaratish kerak.

eunice