sinov modeli tizimning funksionalligini va/yoki foydalanuvchi xatti-harakatlarini tavsiflovchi mantiqiy tuzilma bo'lib, unga ko'ra test holatlari yaratiladi. Sinov modelini qurish konstruksiyani qurishdan boshlanadi, keyin tasdiqlangan struktura test holatlari bilan to'ldiriladi.

Modellar odatda tizimning talablari va/yoki kutilayotgan xatti-harakatlari asosida quriladi. Sinov modelini yaratish va uni boshqarish murakkab biznes mantig'iga ega bo'lgan yirik tizimlar uchun javob beradi va agile metodologiyalaridan foydalangan holda loyihalarga qo'llash qiyin, chunki test modelini boshqarish va sifatni ta'minlash jarayonini saqlash xarajatlari juda yuqori bo'ladi.

Test modelini boshqarish - bu test modelining qamrovini, test modelini tavsiflovchi stsenariylar sifatini va uni aktuallashtirishni nazorat qiluvchi jarayon.

Sinov modelini boshqarish butun davomida uzluksiz jarayondir hayot davrasi mahsulot.

Sinov modeli qamrovi

Barcha talablarning qoplanishini nazorat qilish uchun siz test stsenariylari bo'yicha talablarni qamrab olishni aniqlaydigan iz matritsalaridan foydalanishingiz mumkin (misolga qarang).
Sinov holatlarini tavsiflashdan oldin, test modelining tuzilishi mijoz bilan tasdiqlanishi kerak.

Skript sifati

Ssenariylarning sifatini boshqarish uchun nafaqat test holatlarini tavsiflash darajasini, balki ularning sifatini ham nazorat qilish kerak.

Sinov holatlarini tavsiflashni boshlashdan oldin tavsifning har bir darajasiga qo'yiladigan talablarni va test holatlarini tavsiflash sifati mezonlarini aniqlash kerak.

Sinov holatlarini tavsiflashning mumkin bo'lgan darajalari:

4-darajada mijoz bilan tuzilgan kelishuv shartnoma bilan almashtirilishi mumkin.

Sinov holatlarini tavsiflash uchun sifat mezonlari quyidagicha bo'lishi mumkin:

• Test holatlari talablarga muvofiq yozilishi kerak

Sinov - bu mahsulotning uning talablariga javob berishini tekshirish jarayoni. Shuning uchun, test ishining umumiy tavsifi qismida (testni kuzatish tizimlarida odatda "Xulosa" atamasi qo'llaniladi), talablar matnining qismlari bilan birgalikda muayyan talabga murojaat qilish kerak. Shunday qilib, loyihaning barcha ishtirokchilari uchun ushbu test ishi nima yozilganligi aniq bo'ladi.

• Batafsil shartlardan foydalaning

Test holatlarida vaqtni qanday tejash mumkin?

Barcha test holatlari uchun formatlash qoidalarini o'rnating. Shunday qilib, test ishi har qanday loyiha ishtirokchisi uchun tushunish va o'qish oson bo'ladi. Masalan, loyihada siz quyidagi qoidalarni kiritishingiz mumkin:

• Barcha kirish parametrlari qizil rang bilan belgilanishi kerak.
• Barcha skriptlar ko'k rang bilan ajratilishi kerak,
• Tugmalar, maydonlar, bloklarning barcha nomlari kursiv va qalin harflar bilan yozilgan.
• Muhim parchalar tagiga chizilgan.
• Har bir bajarilgan qadam kutilgan natijaga ega bo'lishi kerak.
• Sinov holatlaridagi har bir qadam faqat bitta harakatni va undan kutilgan natijani tasvirlashi kerak. Bular. muayyan bosqichda muvaffaqiyatsiz test ishini qabul qilganda, xato qaysi harakatda sodir bo'lganligi aniq bo'lishi kerak.
• Kutilgan natija aniq bo'lishi kerak.

Sinov holatlari aniq bo'lishi kerak, ya'ni. noaniq talqinga yo'l qo'ymaydigan, lekin barcha ishtirokchilar tomonidan aniq tushuniladigan tarzda ishlab chiqilishi va shakllantirilishi kerak.

Agar test holatlarini yozish uzoq vaqt talab qilsa, mutaxassis o'z xatolarini ko'rishni to'xtatganda vaziyat yuzaga kelishi mumkin. Buning uchun sizga yon tomondan qarash kerak - bu erda yordam beradi o'zaro ko'rib chiqish. Ushbu bosqichni test modelini ishlab chiqish o'z vaqtida uzaytirilgan va uzoq vaqt talab qiladigan hollarda o'tkazish tavsiya etiladi. Misol uchun, test stsenariylarini ishlab chiqish 1 oydan ko'proq vaqt talab qilganda.

Skript sifatini nazorat qilish jarayoni o'tkazilishi mumkin Sinov modeli nazorati bilan- maxsus tayyorlangan shablon.

Sinov modelini yangilash

Sinov modelini va test ishlarining o'zlarini talablarga muvofiqligini muntazam yangilab turish, shuningdek test ishlarining ustuvor yo'nalishlarini ko'rib chiqish kerak.

Yangilash uchun "Talablar matritsasi" ni saqlashingiz mumkin(Talablarni kuzatish matritsasi): ma'lum bir talabning har bir o'zgarishidan so'ng, test-kuzatuv tizimidan ushbu talab bilan bog'liq barcha test stsenariylari tanlanadi va yangilanadi.

Sinov modeli boshqaruvlari:

• sinov temir yo'li
• sinov havolasi
• Jira+Zefir
• Microsoft test menejeri (MTM)
• excel

Sinov ishlab chiqarilayotgan mahsulot sifatini baholash imkonini beruvchi jarayondir. Yuqori sifatli dasturiy mahsulot unga qo'yiladigan talablarga javob berishi kerak, ham funktsional, ham funktsional bo'lmagan. PS barcha talab qilinadigan VI-larni amalga oshirishi va kamchiliklarga ega bo'lmasligi kerak - haqiqiy hayot xususiyatlari yoki talab qilinadiganlardan xatti-harakatlar o'rtasidagi farq. Bundan tashqari, PS ishonchlilik xususiyatlariga ega bo'lishi kerak (ulanishlar, ishdan chiqishlar va boshqalar bo'lmasligi kerak), xavfsizlik, kerakli ishlashni ta'minlash, ishlatish uchun qulay, kengaytiriladigan va hokazo. Shunday qilib, test PSni tahlil qilish jarayonidir. , nuqsonlarni aniqlash va PS xususiyatlarini baholashga qaratilgan.

Sinov jarayonining maqsadlari

Sinovning maqsadi sifatni baholashdir dasturiy mahsulot orqali

• Komponentlarning o'zaro ta'sirini tekshirish;
• Komponentlarning to'g'ri integratsiyasini tekshirish;
• Barcha talablarning bajarilishining to'g'riligini tekshirish va kamchiliklarni aniqlash.

RUPda test jarayonining xususiyatlari

Sinov - bu takrorlanadigan jarayon hayot tsiklining barcha bosqichlarida. Sinov boshidan boshlanadi dastlabki bosqich kelajakdagi mahsulotga bo'lgan talablarni aniqlash va joriy vazifalar bilan chambarchas bog'lanish. Har bir iteratsiya uchun test maqsadi va unga erishish usullari aniqlanadi. Har bir iteratsiya oxirida ushbu maqsadga qanchalik erishilganligi, qo'shimcha testlar kerakmi yoki yo'qmi, printsiplar va sinov vositalarini o'zgartirish kerakmi, aniqlanadi.

Har bir topilgan nuqson loyiha ma'lumotlar bazasida aniqlangan vaziyat tavsifi bilan qayd etiladi. Tahlilchi bu haqiqiy nuqsonmi yoki ilgari aniqlangan nuqsonning takrorlanishimi yoki yo'qligini aniqlaydi. Topilgan nuqson tayinlanadi ustuvorlik Tuzatishning muhimligini ko'rsatadigan. Quyi tizimni, komponentni yoki sinfni ishlab chiqish uchun mas'ul bo'lgan dizayner yoki menejer tomonidan tayinlangan boshqa shaxs nuqsonni tuzatishga kirishadi. Kamchiliklarni bartaraf etish tartibi ularning ustuvorliklari bilan tartibga solinadi. Sinovchi testlarni takrorlaydi va nuqson tuzatilganligiga ishonch hosil qiladi (yoki ishonch hosil qilmaydi).

Test ishlab chiqaruvchisi testlarni rejalashtirish, ishlab chiqish va amalga oshirish uchun javobgardir. U test rejasi va modelini, test tartiblarini (pastga qarang) yaratadi va test natijalarini baholaydi.

sinovchi (sinovchi) tizim sinovlarini o'tkazish uchun javobgardir. Uning mas'uliyatiga testlarni o'rnatish va bajarish, sinov samaradorligini baholash, xatolarni tiklash va aniqlangan kamchiliklarni qayd etish kiradi.

Artefaktlar

Sinov jarayonida quyidagi hujjatlar tuziladi:

Sinov rejasi- har bir iteratsiyada sinov strategiyasini belgilaydigan hujjat. Unda joriy iteratsiyada testning maqsad va vazifalari, shuningdek, foydalaniladigan strategiyalar tavsifi mavjud. Rejada qanday resurslar talab qilinishi ko'rsatilgan va testlar ro'yxati keltirilgan.

Sinov modeli nima va qanday sinovdan o'tkazilishining ifodasidir. Model nazorat vazifalari, test usullari, test stsenariylari va kutilgan natijalar (test holatlari), test skriptlari va test o'zaro ta'sirlari tavsiflarini o'z ichiga oladi.

• Nazorat vazifasi- test ma'lumotlari to'plami, testni bajarish shartlari va kutilgan natijalar.
• Sinov usuli- nazorat vazifalarini belgilash va bajarish, shuningdek olingan natijalarni baholash bo'yicha ko'rsatmalarni o'z ichiga olgan hujjat.
• Sinov skripti- bu testning soddalashtirilgan tavsifi, shu jumladan dastlabki ma'lumotlar, harakatlar shartlari va ketma-ketligi, kutilgan natijalar.
• Sinov skripti test vositalaridan foydalangan holda avtomatlashtirilgan test paytida bajariladigan dasturdir.
• Test o'zaro ta'sirining tavsifi test komponentlari va sinov ob'ekti o'rtasida vaqt bo'yicha tartiblangan xabarlar oqimini aks ettiruvchi ketma-ketliklar yoki hamkorlik diagrammasi.

Sinov natijalari va testlarni bajarish jarayonida olingan ma'lumotlar.

Ish yuki modeli oxirgi foydalanuvchilar tomonidan bajariladigan tashqi funksiyalarni, bu funksiyalar doirasini va bu funksiyalar tomonidan yaratilgan ish yukini modellashtirish uchun foydalaniladi. Model real sharoitlarda tizimning ishlashini taqlid qiluvchi yuk va/yoki stress testlarini o'tkazish uchun mo'ljallangan.

Kamchiliklar- bu tizimning sinov paytida aniqlangan talablarga mos kelmasligi faktlarining tavsifi. Ular o'zgartirish so'rovlarining bir turi.

Sinov ishlari barcha bosqichlarda har bir iteratsiyada amalga oshiriladi, ammo loyihaning turli bosqichlarida maqsad va vazifalar sezilarli darajada farq qiladi.

Loyihaga kirish bosqichi. Ushbu bosqichda sinovga tayyorgarlik ko'riladi. Bunga quyidagilar kiradi:

• Sinov talablari va test strategiyalarini o'z ichiga olgan test rejasini tuzing. Sinovning barcha turlari (funktsional, yuk va boshqalar) uchun yagona reja yoki har bir tur uchun alohida rejalar tuzilishi mumkin.
• Sinov ko'lamini tahlil qilish.
• Sifat mezonlarini shakllantirish va sinovni yakunlash.
• Sinov asboblarini o'rnatish va ishga tayyorlash.
• Sinov ehtiyojlari bilan belgilanadigan PSni ishlab chiqish loyihasiga talablarni shakllantirish.

Rivojlanish bosqichi. Ushbu bosqichning takrorlanishida test modeli va tegishli artefaktlarni qurish boshlanadi. VI modeli allaqachon ushbu bosqichda mavjud bo'lganligi sababli, siz test stsenariylarini loyihalashni boshlashingiz mumkin. Shu bilan birga, testlarni o'tkazish tavsiya etilmaydi, chunki odatda ushbu bosqichda tugallangan PS bo'laklari mavjud emas. Quyidagi tadbirlar amalga oshiriladi:

• Test stsenariylarini ishlab chiqish.
• Test skriptlarini yaratish.
• Nazorat vazifalarini ishlab chiqish.
• Sinov usullarini ishlab chiqish.
• Ish yuki modelini ishlab chiqish.

Qurilish bosqichi. Ushbu bosqichda tugallangan tizim qismlari va prototiplari paydo bo'ladi, ular sinovdan o'tkazilishi kerak. Shu bilan birga, deyarli har bir iteratsiyada barcha modullar tekshiriladi (ilgari ishlab chiqilgan va sinovdan o'tgan va joriy iteratsiyada yangilari qo'shilgan). Oldingi iteratsiyalarda qo'llanilgan testlar regressiya testi uchun keyingi iteratsiyalarda ham qo'llaniladi, ya'ni yangi iteratsiyada ilgari amalga oshirilgan tizim funksionalligi saqlanib qolganligini tekshirish uchun. Quyidagi tadbirlar amalga oshiriladi:

• Har bir iteratsiya uchun test rejasini tuzing.
• Sinov modelini takomillashtirish va qo'shish.
• Testlarni bajarish.
• Topilgan kamchiliklarning tavsifi.
• Sinov natijalarining tavsifi.
• Sinov natijalarini baholash.

Sinov natijalariga ko'ra, aniqlangan kamchiliklarni bartaraf etish uchun dastur kodiga o'zgartirishlar kiritiladi, shundan so'ng sinov takrorlanadi.

Joylashtirish bosqichi. Ushbu bosqichning takrorlanishida dasturiy mahsulot sifatida butun PSni sinovdan o'tkazish amalga oshiriladi. Amalga oshirilgan tadbirlar avvalgi bosqich faoliyatiga o'xshaydi. Kamchiliklarni aniqlash o'zgarishlar va qayta sinovdan o'tish zarurligini aniqlaydi. Takroriy jarayon sinovni tugatish mezonlari bajarilgunga qadar takrorlanadi.

Sinov natijalari sinovdan o'tgan PS sifatini va sinov jarayonining o'zini aniqlash imkonini beruvchi test ko'rsatkichlari asosida baholanadi.

Instrumental qo'llab-quvvatlash

Takroriy test jarayoni testlarning bir necha marta takrorlanishini o'z ichiga olganligi sababli, qo'lda test samarasiz bo'lib qoladi va dasturiy mahsulot sifatini to'liq baholashga imkon bermaydi. Bu, ayniqsa, yuk va stress testlari uchun to'g'ri keladi, bu erda siz ish yukini simulyatsiya qilishingiz va katta miqdordagi ma'lumotlarni to'plashingiz kerak. Yechim testlarni kompilyatsiya qilish va bajarishni avtomatlashtirishni qo'llab-quvvatlovchi vositalardan foydalanishdir.

Ishlab chiqish jarayoni singari, dasturiy ta'minotni sinovdan o'tkazish jarayoni ham ma'lum bir metodologiyaga amal qiladi. Metodologiya deganda, bu holda biz loyiha ustida ishlayotganda siz foydalanadigan printsiplar, g'oyalar, usullar va tushunchalarning turli kombinatsiyalarini nazarda tutamiz.

Hozirgi vaqtda test o'tkazish uchun juda ko'p turli xil yondashuvlar mavjud bo'lib, ularning har biri o'z boshlang'ich nuqtalari, bajarish muddati va har bir bosqichda qo'llaniladigan usullarga ega. Va bir yoki boshqasini tanlash juda qiyin bo'lishi mumkin. Ushbu maqolada biz dasturiy ta'minotni sinovdan o'tkazishning turli yondashuvlarini ko'rib chiqamiz va mavjud xilma-xillikni boshqarishga yordam berish uchun ularning asosiy xususiyatlari haqida gapiramiz.

Sharshara modeli (chiziqli ketma-ket dasturiy ta'minotning hayot aylanishi modeli)

Sharshara modeli nafaqat dasturiy ta'minotni ishlab chiqish yoki sinovdan o'tkazish uchun, balki deyarli har qanday boshqa loyihalar uchun ham qo'llanilishi mumkin bo'lgan eng qadimgi modellardan biridir. Uning asosiy tamoyil vazifalarni bajarishning ketma-ketligi. Bu shuni anglatadiki, biz keyingi ishlab chiqish yoki sinov bosqichiga avvalgisi muvaffaqiyatli yakunlangandan keyingina o'tishimiz mumkin. Ushbu model kichik loyihalar uchun javob beradi va faqat barcha talablar aniq belgilangan bo'lsa qo'llaniladi. Ushbu metodologiyaning asosiy afzalliklari iqtisodiy samaradorlik, foydalanish qulayligi va hujjatlarni boshqarish.

Dasturiy ta'minotni sinovdan o'tkazish jarayoni ishlab chiqish jarayoni tugagandan so'ng boshlanadi. Ushbu bosqichda komponentlarning ishlashini alohida va umuman nazorat qilish uchun barcha kerakli testlar birliklardan tizim sinoviga o'tkaziladi.

Yuqorida aytib o'tilgan afzalliklarga qo'shimcha ravishda, sinovga bunday yondashuv o'zining kamchiliklariga ham ega. Sinov jarayonida har doim muhim xatolarni topish imkoniyati mavjud. Bu tizim komponentlaridan birini yoki hatto loyihaning butun mantig'ini butunlay o'zgartirish zaruratiga olib kelishi mumkin. Ammo palapartishlik modelida bunday vazifani bajarish mumkin emas, chunki ushbu metodologiyada oldingi bosqichga qaytish taqiqlanadi.

Oldingi maqoladan palapartishlik modeli haqida ko'proq bilib oling..

V-modeli (tekshirish va tasdiqlash modeli)

Sharshara modeli singari, V-model ham to'g'ridan-to'g'ri qadamlar ketma-ketligiga asoslanadi. Ushbu ikki metodologiya o'rtasidagi asosiy farq shundaki, bu holda test tegishli rivojlanish bosqichiga parallel ravishda rejalashtirilgan. Ushbu dasturiy ta'minotni sinovdan o'tkazish metodologiyasiga ko'ra, jarayon talablar aniqlangandan so'ng boshlanadi va statik testni boshlash mumkin bo'ladi, ya'ni. tekshirish va ko'rib chiqish, bu keyingi bosqichlarda yuzaga kelishi mumkin bo'lgan dasturiy ta'minot nuqsonlarining oldini oladi. Dasturiy ta'minotni ishlab chiqishning har bir darajasi uchun tegishli test rejasi tuziladi, u kutilgan natijalarni va ushbu mahsulot uchun kirish va chiqish mezonlarini belgilaydi.

Ushbu modelning sxemasi vazifalarni ikki qismga bo'lish tamoyilini ko'rsatadi. Dizayn va rivojlanish bilan bog'liq bo'lganlar chap tomonda joylashgan. Dasturiy ta'minotni sinovdan o'tkazish bilan bog'liq vazifalar o'ng tomonda joylashgan:

Ushbu metodologiyaning asosiy bosqichlari farq qilishi mumkin, lekin odatda quyidagilarni o'z ichiga oladi:

• Bosqich talablarning ta'riflari. Qabul qilish testi ushbu bosqichga tegishli. Uning asosiy vazifasi tizimning yakuniy foydalanishga tayyorligini baholashdir.
• Qaysi bosqich yuqori darajadagi dizayn yoki yuqori darajadagi dizayn (HDL). Ushbu bosqich tizimni sinovdan o'tkazishni nazarda tutadi va integratsiyalashgan tizimlarga qo'yiladigan talablarga muvofiqligini baholashni o'z ichiga oladi.
• Batafsil dizayn bosqichi(Batafsil dizayn) integratsiyani sinovdan o'tkazish bosqichiga parallel bo'lib, uning davomida tizimning turli komponentlari o'rtasidagi o'zaro ta'sirlar sinovdan o'tkaziladi.
• Keyin kodlash bosqichi Yana bir muhim qadam boshlanadi - birlik testi. Dasturiy ta'minotning alohida qismlari va tarkibiy qismlarining xatti-harakatlari to'g'ri va talablarga javob berishiga ishonch hosil qilish juda muhimdir.

Ko'rib chiqilayotgan test metodologiyasining yagona kamchiliklari sinov bosqichida topilgan dasturiy ta'minotdagi nuqsonlardan xalos bo'lish uchun qo'llanilishi mumkin bo'lgan tayyor echimlarning yo'qligi.

qo'shimcha model

Ushbu metodologiyani ko'p kaskadli dasturiy ta'minotni sinovdan o'tkazish modeli sifatida tavsiflash mumkin. Ish jarayoni bir qator tsikllarga bo'linadi, ularning har biri ham modullarga bo'linadi. Har bir iteratsiya dasturiy ta'minotga ma'lum funksiyalarni qo'shadi. O'sish uchta tsikldan iborat:

1. dizayn va ishlab chiqish
2. sinovdan o'tkazish
3. amalga oshirish.

Ushbu modelda mahsulotning turli xil versiyalarini bir vaqtning o'zida ishlab chiqish mumkin. Misol uchun, birinchi versiya sinov bosqichida bo'lishi mumkin, ikkinchi versiya esa ishlab chiqilmoqda. Uchinchi versiya bir vaqtning o'zida dizayn bosqichidan o'tishi mumkin. Bu jarayon loyihaning oxirigacha davom etishi mumkin.

Shubhasiz, ushbu metodologiya sinovdan o'tkazilayotgan dasturiy ta'minotdagi xatolarning maksimal miqdorini imkon qadar tezroq aniqlashni talab qiladi. Shuningdek, mahsulotning oxirgi foydalanuvchiga yetkazilishiga tayyorligini tasdiqlashni talab qiluvchi amalga oshirish bosqichi. Bu omillarning barchasi sinov talablarining og'irligini sezilarli darajada oshiradi.

Oldingi metodologiyalar bilan solishtirganda, incremental model bir qancha muhim afzalliklarga ega. U yanada moslashuvchan, talablarning o'zgarishi xarajatlarni kamaytirishga olib keladi va dasturiy ta'minotni sinovdan o'tkazish jarayoni samaraliroq bo'ladi, chunki test va disk raskadrovka kichik iteratsiyalardan foydalanish orqali ancha oson. Biroq, shuni ta'kidlash kerak umumiy qiymati kaskad modeliga qaraganda hali ham yuqori.

spiral model

Spiral model - bu bosqichma-bosqich yondashuv va prototiplashga asoslangan dasturiy ta'minotni sinovdan o'tkazish metodologiyasi. U to'rt bosqichdan iborat:

1. Rejalashtirish
2. Xatarlarni tahlil qilish
3. Rivojlanish
4. Baho

Birinchi tsikl tugagandan so'ng darhol ikkinchisi boshlanadi. Dasturiy ta'minotni sinovdan o'tkazish rejalashtirish bosqichidan boshlanadi va baholash bosqichiga qadar davom etadi. Spiral modelning asosiy afzalligi shundaki, birinchi sinov natijalari har bir tsiklning uchinchi bosqichida test natijalaridan so'ng darhol paydo bo'ladi, bu sifatni to'g'ri baholashga yordam beradi. Biroq, ushbu model juda qimmat bo'lishi mumkinligini va kichik loyihalar uchun mos kelmasligini yodda tutish kerak.

Ushbu model ancha eski bo'lsa-da, u ham sinov, ham ishlab chiqish uchun foydali bo'lib qolmoqda. Bundan tashqari, asosiy maqsad so'nggi paytlarda ko'plab dasturiy ta'minotni sinovdan o'tkazish metodologiyalari, shu jumladan spiral model o'zgardi. Biz ulardan nafaqat ilovalardagi nuqsonlarni aniqlash, balki ularni keltirib chiqargan sabablarni aniqlash uchun ham foydalanamiz. Ushbu yondashuv ishlab chiquvchilarga samaraliroq ishlashga va xatolarni tezda tuzatishga yordam beradi.

Oldingi blog postida spiral model haqida ko'proq o'qing..

Chaqqon

Agile dasturiy ta'minotni ishlab chiqish metodologiyasi va dasturiy ta'minotni sinovdan o'tkazishni o'z-o'zini tashkil etuvchi tashkilot doirasida doimiy o'zaro ta'sir natijasida interaktiv ishlanmalardan foydalanishga, talablarni dinamik shakllantirishga va ularning amalga oshirilishini ta'minlashga qaratilgan yondashuvlar majmuasi sifatida tavsiflash mumkin. ishchi guruhi. Ko'pgina tezkor dasturiy ta'minotni ishlab chiqish metodologiyalari qisqa iteratsiyalarda ishlab chiqish orqali xavfni minimallashtirishga qaratilgan. Ushbu moslashuvchan strategiyaning asosiy tamoyillaridan biri uzoq muddatli rejalashtirishga tayanmasdan, mumkin bo'lgan o'zgarishlarga tezda javob berish qobiliyatidir.

Agile haqida ko'proq bilib oling(eslatma - ingliz tilidagi maqola).

Ekstremal dasturlash (XP, ekstremal dasturlash)

Ekstremal dasturlash - tezkor dasturiy ta'minotni ishlab chiqishning bir misolidir. Ushbu metodologiyaning o'ziga xos xususiyati "juft dasturlash" bo'lib, unda bitta ishlab chiquvchi kod ustida ishlaydi, uning hamkasbi esa doimiy ravishda yozilgan kodni ko'rib chiqadi. Dasturiy ta'minotni sinab ko'rish jarayoni juda muhim, chunki u kodning birinchi qatori yozilishidan oldin boshlanadi. Har bir dastur moduli birlik testiga ega bo'lishi kerak, shunda ko'pchilik xatolar kodlash bosqichida tuzatilishi mumkin. Yana bir ajralib turadigan xususiyat shundaki, test kodni aniqlaydi, aksincha emas. Bu shuni anglatadiki, ma'lum bir kod qismi faqat barcha testlardan o'tgan taqdirdagina to'liq hisoblanishi mumkin. Aks holda, kod rad etiladi.

Ushbu metodologiyaning asosiy afzalliklari doimiy sinov va qisqa relizlar bo'lib, bu ta'minlashga yordam beradi yuqori sifatli kod.

Scrum

Scrum - Agile metodologiyasining bir qismi, dasturiy ta'minotni ishlab chiqish jarayonini boshqarish uchun yaratilgan takrorlanuvchi qo'shimcha ramka. Scrum printsiplariga ko'ra, test guruhi quyidagi bosqichlarda ishtirok etishi kerak:

• Scrum rejalashtirishda ishtirok etish
• Birlik sinovini qo'llab-quvvatlash
• Foydalanuvchi hikoyasi testi
• Qabul qilish mezonlarini aniqlash uchun mijoz va mahsulot egasi bilan hamkorlik qiling
• Avtomatlashtirilgan testlarni ta'minlash

Bundan tashqari, QA a'zolari, boshqa jamoa a'zolari kabi, kecha nima sinovdan o'tkazilgani va amalga oshirilganligi, bugun nima sinovdan o'tkazilishi, shuningdek, testning umumiy borishini muhokama qilish uchun barcha kundalik yig'ilishlarda ishtirok etishlari kerak.

Shu bilan birga, Scrum-dagi Agile metodologiyasining tamoyillari o'ziga xos xususiyatlarning paydo bo'lishiga olib keladi:

• Har bir foydalanuvchi hikoyasi uchun zarur bo'lgan harakatni taxmin qilish shart
• Sinovchi talablarga e'tiborli bo'lishi kerak, chunki ular doimo o'zgarishi mumkin.
• Kodning tez-tez o'zgarishi bilan regressiya xavfi ortadi.
• Sinovlarni bir vaqtda rejalashtirish va bajarish
• Agar mijozning talablari to'liq aniq bo'lmasa, jamoa a'zolari o'rtasida tushunmovchilik

Oldingi maqoladan Scrum metodologiyasi haqida ko'proq bilib oling..

Xulosa

Xulosa qilib shuni ta'kidlash kerakki, bugungi kunda u yoki bu dasturiy ta'minotni sinovdan o'tkazish metodologiyasidan foydalanish amaliyoti ko'p qirrali yondashuvni nazarda tutadi. Boshqacha qilib aytganda, biron bir metodologiya barcha turdagi loyihalar uchun mos kelishini kutmasligingiz kerak. Ulardan birini tanlash loyihaning turi, mijozning talablari, muddatlari va boshqalar kabi ko'plab jihatlarga bog'liq. Dasturiy ta'minotni sinovdan o'tkazish nuqtai nazaridan, ba'zi metodologiyalar uchun sinovni ishlab chiqishning boshida boshlash odatiy holdir, boshqalari uchun esa tizim tugashini kutish odatiy holdir.

Dasturiy ta'minotni ishlab chiqish yoki sinovdan o'tkazishda yordam kerak bo'ladimi, ishlab chiquvchilar va QA muhandislaridan iborat maxsus guruh ishlashga tayyor.

Veb-xizmat sinovi

Ko'pchilik Eng yaxshi yo'l mahsulotni yaxshi sinovdan o'tkazganimizni baholang - o'tkazib yuborilgan nuqsonlarni tahlil qiling. Bizning foydalanuvchilarimiz, amalga oshiruvchilarimiz, korxonalarimiz duch kelganlar. Siz ulardan ko'p narsalarni baholashingiz mumkin: biz etarlicha tekshirmagan narsamiz, mahsulotning qaysi sohalariga ko'proq e'tibor berish kerak, umuman olganda, kamchiliklarning foizi qancha va uning o'zgarishlar dinamikasi qanday. Ushbu ko'rsatkich (ehtimol sinovda eng keng tarqalgan) bilan hamma narsa yaxshi, lekin ... Biz mahsulotni chiqarganimizda va o'tkazib yuborilgan xatolar haqida bilganimizda, juda kech bo'lishi mumkin: Habré-da biz haqimizda g'azablangan maqola paydo bo'ldi, raqobatchilar tez tarqaladigan tanqid, mijozlar bizga ishonchini yo'qotdi, boshqaruv norozi.

Bunga yo'l qo'ymaslik uchun biz odatda sinov sifatini oldindan, chiqarilishidan oldin baholashga harakat qilamiz: mahsulotni qanchalik yaxshi va sinchkovlik bilan tekshiramiz? Qaysi sohalarga e'tibor berilmayapti, asosiy xavf qayerda, qanday taraqqiyot bor? Va bu savollarga javob berish uchun biz test qamrovini baholaymiz.

Nega baho berish kerak?

Har qanday baholash ko'rsatkichlari vaqtni behuda sarflashdir. Ayni paytda siz sinovdan o'tishingiz, xatolarni boshlashingiz, avtotestlar tayyorlashingiz mumkin. Sinov vaqtini qurbon qilish uchun sinov qamrovi ko'rsatkichlaridan qanday sehrli foyda olamiz?

1. O'zingizning zaif tomonlaringizni toping. Tabiiyki, bu bizga kerakmi? nafaqat qayg'urish, balki qayerda yaxshilanishlar kerakligini bilish. Sinovlar qaysi funktsional sohalarni qamrab olmaydi? Biz nimani tekshirmadik? Yo'qolgan xatolarning eng katta xavfi qayerda?
2. Biz kamdan-kam hollarda baholash natijalaridan 100% qamrab olamiz. Nimani yaxshilash kerak? Qayerga borish kerak? Hozir qancha foiz? Har qanday vazifa bilan uni qanday oshirishimiz mumkin? 100 ga qanchalik tez erisha olamiz? Bu savollarning barchasi bizning jarayonimizga shaffoflik va ravshanlik olib keladi., va ularga javoblar qamrov smetasi bilan beriladi.
3. Diqqat markazi. Aytaylik, mahsulotimizda 50 ga yaqin turli funksional sohalar mavjud. chiqib yangi versiya, va biz ulardan birinchisini sinab ko'rishni boshlaymiz va u erda matn terish xatolarini, bir nechta pikselni siljitgan tugmalarni va boshqa arzimas narsalarni topamiz ... Va endi sinov vaqti tugadi va bu funksionallik batafsil sinovdan o'tkazildi .. Qolgan 50 tasi? Qoplashni baholash hozirgi voqeliklar va muddatlarga asoslanib vazifalarni ustuvorlashtirishga imkon beradi.

Qanday baholash kerak?

Har qanday ko'rsatkichni amalga oshirishdan oldin, uni qanday ishlatishni hal qilish muhimdir. Aynan shu savolga javob berishdan boshlang - ehtimol uni qanday hisoblash yaxshiroq ekanligini darhol tushunasiz. Va men ushbu maqolada faqat ba'zi misollar va buni qanday qilish mumkinligi haqidagi tajribam bilan o'rtoqlashaman. Yechimlarni ko'r-ko'rona nusxalash uchun emas, balki sizning tasavvuringiz ushbu tajribaga tayanishi uchun, siz uchun ideal echimni o'ylab ko'ring.

Sinovlar orqali talablarni qoplashni baholash

Aytaylik, sizning jamoangizda tahlilchilar bor va ular vaqtlarini behuda o'tkazmaydilar. ish vaqti. Ularning ish natijalariga ko'ra RMS (Talablarni boshqarish tizimi) - HP QC, MS TFS, IBM Doors, Jira (qo'shimcha plaginlar bilan) va boshqalarda talablar yaratildi. Ushbu tizimda ular talablarga qo'yiladigan talablarga javob beradigan talablarni qo'yadilar (tavtologiya uchun uzr). Bu talablar atomik, kuzatilishi mumkin, o'ziga xosdir... Umuman olganda, sinov uchun ideal sharoitlar. Bunday holatda nima qilishimiz mumkin? Skriptlashtirilgan yondashuvdan foydalanganda, talablar va testlarni bog'lang. Biz bir xil tizimda testlarni o'tkazamiz, talab-test ulanishini amalga oshiramiz va istalgan vaqtda qaysi talablarda testlar bor, qaysilarida yo'q, bu testlar qachon o'tganligi va qanday natija berganligi haqida hisobotni ko'rishimiz mumkin.
Biz qamrov xaritasini olamiz, biz barcha ochilmagan talablarni qoplaymiz, hamma baxtli va mamnun, biz xatolarni o'tkazib yubormaymiz ...

Mayli, yerga qaytaylik. Ehtimol, sizda batafsil talablar yo'q, ular atomik emas, ba'zi talablar odatda yo'qoladi va har bir testni yoki hech bo'lmaganda har bir soniyani hujjatlashtirishga vaqt yo'q. Siz umidsizlikka tushishingiz va yig'lashingiz mumkin yoki sinov bu kompensatsion jarayon ekanligini tan olishingiz mumkin va biz loyihada tahlil va rivojlanish bilan qanchalik yomon bo'lsak, biz o'zimiz jarayonning boshqa ishtirokchilarining muammolarini qoplashga harakat qilishimiz kerak. Keling, muammolarni alohida tahlil qilaylik.

Muammo: Talablar atomik emas.

Tahlilchilar ham ba'zida boshlarida salat bilan gunoh qilishadi va odatda bu butun loyiha bilan bog'liq muammolarga olib keladi. Masalan, siz matn muharririni ishlab chiqmoqdasiz va tizimingizda ikkita talab bo'lishi mumkin (boshqalar qatorida): "html formatlash qo'llab-quvvatlanishi kerak" va "qo'llab-quvvatlanmaydigan formatdagi faylni ochganda, savol bilan qalqib chiquvchi oyna" paydo bo'lishi kerak." 1-talabni asosiy tekshirish uchun nechta test talab qilinadi? Va ikkinchisi uchun? Javoblardagi farq, katta ehtimol bilan, yuz barobarga yaqin!!! Agar 1-talab bo'yicha kamida 1 ta test mavjud bo'lsa, bu etarli, deb ayta olmaymiz - lekin 2-chi, ehtimol, to'liq.

Shunday qilib, talab testiga ega bo'lish bizga hech narsani kafolatlamaydi! Bu holatda bizning qamrov statistikamiz nimani anglatadi? Deyarli hech narsa! Biz qaror qilishimiz kerak!

1. Bunday holda, testlar bilan talablarni qoplashni avtomatik hisoblash olib tashlanishi mumkin - u hali ham semantik yukni ko'tarmaydi.
2. Har bir talab uchun, eng yuqori ustuvorlikdan boshlab, biz testlarni tayyorlaymiz. Tayyorlanayotganda biz ushbu talab uchun qanday testlar talab qilinishini tahlil qilamiz, qanchasi etarli bo'ladi? Biz to'liq test tahlilini o'tkazamiz va "bitta sinov bor, lekin yaxshi" deb o'ylamaymiz.
3. Amaldagi tizimga qarab, biz so'rov bo'yicha testlarni eksport qilamiz/yuklaymiz va… biz bu testlarni sinab ko'ramiz! Ular yetarlimi? Ideal holda, albatta, bunday sinov tahlilchi va ushbu funksiyani ishlab chiquvchisi bilan amalga oshirilishi kerak. Testlarni chop eting, hamkasblaringizni yig'ilish xonasida qulflang va ular "ha, bu testlar etarli" demaguncha qo'yib yubormang (bu faqat yozma kelishuv bilan sodir bo'ladi, bu so'zlar obunani bekor qilish uchun aytilganda, hatto testlarni tahlil qilmasdan ham. Og'zaki muhokama paytida sizning hamkasblaringiz tanqidni, o'tkazib yuborilgan testlarni, noto'g'ri tushunilgan talablarni va hokazolarni aytadilar - bu har doim ham yoqimli emas, lekin sinov uchun juda foydali!)
4. Talab bo'yicha testlarni yakunlab, ularning to'liqligi to'g'risida kelishib olingandan so'ng, tizimda ushbu talab "testlar bilan qoplangan" holati bilan belgilanishi mumkin. Ushbu ma'lumot "bu erda kamida 1 ta test mavjud" dan ko'proq narsani anglatadi.

Albatta, bunday kelishuv jarayoni juda ko'p resurslar va vaqtni talab qiladi, ayniqsa dastlab, amaliyot ishlab chiqilgunga qadar. Shuning uchun, faqat yuqori ustuvor talablarni va unga yangi takomillashtirishlarni amalga oshiring. Vaqt o'tishi bilan qolgan talablarni kuchaytiring va hamma xursand bo'ladi! Ammo ... va umuman talablar bo'lmasa?

Muammo: umuman talablar yo'q.

Ular loyihada yo'q, ular og'zaki muhokama qilinadi, har kim o'zi xohlagan / qila oladigan narsani qiladi va u qanday tushunadi. Biz ham xuddi shunday sinovdan o'tkazamiz. Natijada, biz nafaqat sinov va ishlab chiqishda, balki xususiyatlarni dastlab noto'g'ri amalga oshirishda juda ko'p muammolarga duch kelamiz - biz butunlay boshqacha narsani xohladik! Bu erda men "talablarni o'zingiz belgilang va hujjatlang" variantini maslahat bera olaman va hatto ushbu strategiyani o'z amaliyotimda bir necha marta qo'llaganman, ammo 99% hollarda test guruhida bunday resurslar yo'q - shuning uchun keling, kamroq boraylik. resurs talab qiladigan usul:

1. Xususiyatlar ro'yxatini yarating. Sami! Google-planshet shaklida, TFS-da PBI formatida - matn formati bo'lmasa, istalganini tanlang. Biz hali ham statuslarni yig'ishimiz kerak! Biz ushbu ro'yxatga mahsulotning barcha funktsional sohalarini kiritamiz va bitta umumiy parchalanish darajasini tanlashga harakat qilamiz (siz dasturiy ta'minot ob'ektlarini yoki foydalanuvchi skriptlarini, modullarni, veb-sahifalarni yoki API usullarini yoki ekran shakllarini yozishingiz mumkin .. .) - lekin bularning barchasi bir vaqtning o'zida emas! Siz uchun muhim narsalarni o'tkazib yubormaslikni osonlashtiradigan va aniqroq bo'ladigan BIR parchalanish formati.
2. Biz ushbu ro'yxatning TO'LIQligini tahlilchilar, ishlab chiquvchilar, biznes bilan, jamoamiz ichida muvofiqlashtiramiz ... Mahsulotning muhim qismlarini yo'qotmaslik uchun hamma narsani qilishga harakat qiling! Qanchalik chuqur tahlil qilish sizga bog'liq. Mening amaliyotimda biz jadvalda 100 dan ortiq sahifa yaratgan bir nechta mahsulotlar bor edi va bu ulkan mahsulotlar edi. Ko'pincha, 30-50 chiziq keyingi ehtiyotkorlik bilan ishlov berish uchun erishish mumkin bo'lgan natijadir. Maxsus test tahlilchilarisiz kichik jamoada Ko'proq fichelista elementlarini saqlash juda qiyin bo'ladi.
3. Shundan so'ng, biz ustuvorliklarni ko'rib chiqamiz va yuqorida tavsiflangan talablar bo'limida bo'lgani kabi, fichelistning har bir qatorini qayta ishlaymiz. Biz testlarni yozamiz, muhokama qilamiz, etarliligi haqida kelishib olamiz. Biz statuslarni belgilaymiz, ular uchun testlar etarli. Biz jamoa bilan muloqot qilish orqali maqom, taraqqiyot va testlarning kengaytirilishiga erishamiz. Hamma baxtli!

Lekin... Agar talablar saqlanib qolsa-chi, lekin kuzatilishi mumkin bo'lgan formatda emas?

Muammo: talablarni kuzatib bo'lmaydi.

Loyiha bo'yicha juda ko'p hujjatlar mavjud, tahlilchilar daqiqada 400 belgi tezlikda yozadilar, sizda texnik xususiyatlar, texnik xususiyatlar, ko'rsatmalar, ma'lumotnomalar mavjud (ko'pincha bu mijozning iltimosiga binoan sodir bo'ladi) va bularning barchasi talablar, va hamma narsa uzoq vaqt davomida loyihada bo'lgan. Qaysi ma'lumotni qaerdan qidirishni chalkashtirib yuborasizmi?
Oldingi bo'limni takrorlash, butun jamoani tozalashga yordam berish!

1. Biz xususiyatlar ro'yxatini yaratamiz (yuqoriga qarang), lekin talablarning batafsil tavsifisiz.
2. Har bir xususiyat uchun biz texnik xususiyatlar, spetsifikatsiyalar, ko'rsatmalar va boshqa hujjatlarga havolalarni yig'amiz.
3. Biz ustuvorliklar bo'yicha boramiz, testlarni tayyorlaymiz va ularning to'liqligiga rozi bo'lamiz. Hammasi bir xil, faqat bitta plastinada barcha hujjatlarning kombinatsiyasi tufayli biz ularga kirish qulayligini, shaffof statuslarni va testlarning izchilligini oshiramiz. Oxir-oqibat, hamma narsa ajoyib va ​​hamma baxtli!

Lekin... Ko'p vaqt o'tmay... O'tgan haftada tahlilchilar mijozlar so'rovlari asosida 4 xil spetsifikatsiyani yangilaganga o'xshaydi!!!

Muammo: talablar har doim o'zgarib turadi.

Albatta, ba'zi sobit tizimlarni sinab ko'rish yaxshi bo'lardi, lekin bizning mahsulotlarimiz odatda jonli. Buyurtmachi nimanidir so'radi, mahsulotimizdan tashqari qonunchilikda nimadir o'zgardi va qayerdandir tahlilchilar o'tgan yilgi tahlil xatosini topdilar... Talablar o'z hayotini yashaydi! Nima qilsa bo'ladi?

1. Aytaylik, siz TKga havolalar va xususiyatlar ro'yxati, PBI, talablar, Wiki eslatmalari va boshqalar ko'rinishidagi texnik xususiyatlarni to'pladingiz. Aytaylik, sizda ushbu talablar uchun testlar allaqachon mavjud. Va endi, talab o'zgarmoqda! Bu RMSdagi o'zgarishlarni yoki TMS (Vazifalarni boshqarish tizimi)dagi vazifani yoki pochtadagi xatni anglatishi mumkin. Qanday bo'lmasin, bu bir xil natijaga olib keladi: testlaringiz eskirgan! Yoki ular ahamiyatsiz bo'lishi mumkin. Bu shuni anglatadiki, ular yangilanishni talab qiladi (testlar bilan qamrab olish eski versiya mahsulot qandaydir tarzda juda ko'p hisoblanmaydi, to'g'rimi?)
2. Xususiyatlar ro'yxatida, RMSda, TMSda (Test boshqaruv tizimi - testrails, sitechco va boshqalar) testlar darhol va mutlaqo ahamiyatsiz deb belgilanishi kerak! HP QC yoki MS TFS da, bu talablarni yangilashda avtomatik ravishda amalga oshirilishi mumkin va Google-planshet yoki wiki-da siz qalamlarni qo'yishingiz kerak bo'ladi. Lekin siz darhol ko'rishingiz kerak: testlar ahamiyatsiz! Bu shuni anglatadiki, biz to'liq qayta yo'lni kutmoqdamiz: yangilang, test tahlilini qayta ishga tushiring, testlarni qayta yozing, o'zgarishlarga rozi bo'ling va shundan keyingina xususiyat/talabni yana "sinovlar bilan qoplangan" deb belgilang.

Bunday holda, biz test qamrovini baholashning barcha afzalliklarini va hatto dinamikada ham olamiz! Hamma baxtli!!! Lekin…
Ammo siz talablar bilan ishlashga shunchalik e'tibor qaratgansizki, endi sizda testlarni sinab ko'rish yoki hujjatlashtirish uchun vaqtingiz yo'q. Menimcha (va diniy janjal uchun ham joy bor!) talablar testlardan ko'ra muhimroq va bu yaxshi! Hech bo'lmaganda ular tartibda va butun jamoa biladi va ishlab chiquvchilar kerakli narsani qilishadi. LEKIN TESTLARNI HUJJATLASH UCHUN VAQT YO'Q!

Muammo: testlarni hujjatlashtirish uchun vaqt yetarli emas.

Aslida, bu muammoning manbai nafaqat vaqt etishmasligi, balki ularni hujjatlashtirmaslik uchun juda ongli tanlov bo'lishi mumkin (biz buni yoqtirmaymiz, biz pestitsid ta'siridan qochamiz, mahsulot juda tez-tez o'zgarib turadi va hokazo). Ammo bu holatda test qamrovini qanday baholash mumkin?

1. Sizga hali ham to'liq talablar yoki xususiyatlar ro'yxati sifatida talablar kerak, shuning uchun loyiha bo'yicha tahlilchilarning ishiga qarab yuqoridagi bo'limlardan biri hali ham zarur bo'ladi. Talab/xususiyatlar ro'yxati bormi?
2. Biz maxsus testlarni hujjatlashtirmasdan, qisqacha test strategiyasini tasvirlaymiz va og'zaki rozi bo'lamiz! Ushbu strategiya jadval ustunida, wiki sahifasida yoki RMS talabida ko'rsatilishi mumkin va yana kelishilgan bo'lishi kerak. Ushbu strategiyaning bir qismi sifatida ko'rib chiqishlar turli yo'llar bilan amalga oshiriladi, ammo siz buni bilib olasiz: qachon oxirgi marta sinovdan o'tgan va qanday strategiya bilan? Va bu ham yomon emas! Va hamma baxtli bo'ladi.

Lekin… Yana nima "lekin"? Qaysi???

Ayting, biz hamma narsani aylanib chiqamiz va sifatli mahsulotlar biz bilan bo'lsin!

| O'quv yili uchun darsni rejalashtirish | Modellashtirishning asosiy bosqichlari

2-dars
Modellashtirishning asosiy bosqichlari

Ushbu mavzuni o'rganish orqali siz quyidagilarni bilib olasiz:

Modellashtirish nima;
- modellashtirish uchun prototip sifatida nima xizmat qilishi mumkin;
- modellashtirish inson faoliyatida qanday o'rin tutadi;
- modellashtirishning asosiy bosqichlari qanday;
- kompyuter modeli nima;
Kompyuter tajribasi nima.

kompyuter tajribasi

Yangi dizayn ishlanmalariga hayot berish, ishlab chiqarishga yangi texnik echimlarni kiritish yoki yangi g'oyalarni sinab ko'rish uchun tajriba kerak. Tajriba - bu ob'ekt yoki model bilan amalga oshiriladigan tajriba. Bu ba'zi harakatlarni bajarish va eksperimental namunaning ushbu harakatlarga qanday munosabatda bo'lishini aniqlashdan iborat.

Maktabda siz biologiya, kimyo, fizika, geografiya darslarida tajribalar o'tkazasiz.

Korxonalarda yangi mahsulot namunalarini sinovdan o'tkazishda tajribalar o'tkaziladi. Odatda, buning uchun maxsus yaratilgan o'rnatish qo'llaniladi, bu laboratoriya sharoitida tajriba o'tkazishga imkon beradi yoki haqiqiy mahsulotning o'zi barcha turdagi sinovlardan o'tkaziladi (to'liq miqyosli eksperiment). Masalan, birlik yoki yig'ilishning ishlash xususiyatlarini o'rganish uchun u termostatga joylashtiriladi, maxsus kameralarda muzlatiladi, tebranish stendlarida sinovdan o'tkaziladi, tushiriladi va hokazo. Bu yangi soat yoki changyutgich bo'lsa yaxshi - halokat paytida yo'qotish katta emas. Agar bu samolyot yoki raketa bo'lsa-chi?

Laboratoriya va keng ko'lamli tajribalar katta moddiy xarajatlar va vaqtni talab qiladi, ammo ularning ahamiyati, shunga qaramay, juda katta.

Rivojlanish bilan kompyuter texnologiyasi yangi noyob tadqiqot usuli - kompyuter tajribasi paydo bo'ldi. Ko'pgina hollarda, kompyuter simulyatsiyasi bo'yicha tadqiqotlar yordam berish uchun keldi va ba'zan hatto tajriba namunalari va sinov skameykalarini almashtirish uchun keldi. Kompyuter tajribasini o'tkazish bosqichi ikki bosqichni o'z ichiga oladi: tajriba rejasini tuzish va tadqiqot o'tkazish.

Tajriba rejasi

Tajriba rejasi model bilan ishlash ketma-ketligini aniq aks ettirishi kerak. Bunday rejadagi birinchi qadam har doim modelni sinab ko'rishdir.

Sinov - bu tuzilgan modelning to'g'riligini tekshirish jarayoni.

Test - modelni qurishning to'g'riligini aniqlash imkonini beruvchi dastlabki ma'lumotlar to'plami.

Olingan modellashtirish natijalarining to'g'riligiga ishonch hosil qilish uchun quyidagilar zarur: ♦ modelni yaratish uchun ishlab chiqilgan algoritmni tekshirish; ♦ tuzilgan model asl nusxaning simulyatsiyada hisobga olingan xususiyatlarini to'g'ri aks ettirishiga ishonch hosil qiling.

Modelni qurish algoritmining to'g'riligini tekshirish uchun dastlabki ma'lumotlarning test to'plami qo'llaniladi, buning uchun yakuniy natija oldindan ma'lum yoki boshqa usullar bilan oldindan belgilanadi.

Misol uchun, agar siz modellashtirishda hisoblash formulalaridan foydalansangiz, unda siz dastlabki ma'lumotlar uchun bir nechta variantni tanlashingiz va ularni "qo'lda" hisoblashingiz kerak. Bu sinov elementlari. Model qurilgach, siz bir xil kirishlar bilan sinovdan o'tkazasiz va simulyatsiya natijalarini hisoblash natijasida olingan xulosalar bilan solishtirasiz. Agar natijalar mos keladigan bo'lsa, unda algoritm to'g'ri ishlab chiqilgan, agar bo'lmasa, ularning nomuvofiqligi sababini izlash va yo'q qilish kerak. Test ma'lumotlari haqiqiy vaziyatni umuman aks ettirmasligi va semantik tarkibga ega bo'lmasligi mumkin. Biroq, sinov jarayonida olingan natijalar sizni dastlabki ma'lumot yoki belgi modelini o'zgartirish haqida o'ylashga undashi mumkin, birinchi navbatda uning semantik mazmuni belgilangan qismida.

Tuzilgan model simulyatsiyada hisobga olingan asl nusxaning xususiyatlarini aks ettirishiga ishonch hosil qilish uchun haqiqiy manba ma'lumotlariga ega test namunasini tanlash kerak.

Tadqiqot o'tkazish

Sinovdan so'ng, tuzilgan modelning to'g'riligiga ishonchingiz komil bo'lganda, siz to'g'ridan-to'g'ri o'rganishga o'tishingiz mumkin.

Rejada simulyatsiya maqsadlariga javob beradigan eksperiment yoki tajribalar seriyasi bo'lishi kerak. Har bir tajriba natijalarni tushunish bilan birga bo'lishi kerak, bu modellashtirish natijalarini tahlil qilish va qarorlar qabul qilish uchun asos bo'lib xizmat qiladi.

Kompyuter tajribasini tayyorlash va o'tkazish sxemasi 11.7-rasmda ko'rsatilgan.

Guruch. 11.7. Kompyuter tajribasi sxemasi

Simulyatsiya natijalarini tahlil qilish

Modellashtirishning yakuniy maqsadi qaror qabul qilish bo'lib, u simulyatsiya natijalarini har tomonlama tahlil qilish asosida ishlab chiqilishi kerak. Bu bosqich hal qiluvchi - yo o'qishni davom ettirasiz, yoki tugatasiz. 11.2-rasmda natijalarni tahlil qilish bosqichi avtonom holda mavjud bo'lishi mumkin emasligini ko'rsatadi. Olingan xulosalar ko'pincha qo'shimcha tajribalar seriyasiga, ba'zan esa muammoni o'zgartirishga yordam beradi.

Sinov va tajribalar natijalari yechimni ishlab chiqish uchun asos bo'lib xizmat qiladi. Agar natijalar topshiriqning maqsadlariga mos kelmasa, bu avvalgi bosqichlarda xatolarga yo'l qo'yilganligini anglatadi. Bu muammoning noto'g'ri bayoni yoki axborot modelining haddan tashqari soddalashtirilgan tuzilishi yoki modellashtirish usuli yoki muhitining muvaffaqiyatsiz tanlanishi yoki modelni qurishda texnologik usullarning buzilishi bo'lishi mumkin. Agar bunday xatolar aniqlansa, modelni tuzatish kerak, ya'ni oldingi bosqichlardan biriga qaytish. Tajriba natijalari simulyatsiya maqsadlariga javob bermaguncha jarayon takrorlanadi.

Esda tutish kerak bo'lgan asosiy narsa shundaki, aniqlangan xato ham natijadir. Maqolda aytilganidek, siz xatolaringizdan saboq olasiz. Bu haqda buyuk rus shoiri A. S. Pushkin ham shunday yozgan:

Oh, bizda qancha ajoyib kashfiyotlar bor
Ma'rifat ruhini tayyorlang
Va tajriba, qiyin xatolarning o'g'li,
Va daho, paradokslar do'stim,
Va tasodif, xudo ixtirochi ...

Nazorat savollari va topshiriqlari

1. Modellashtirish muammosi bayonining ikkita asosiy turi qanday.

2. G. Osterning mashhur "Muammolar kitobi"da quyidagi muammo bor:

Yovuz jodugar tinmay mehnat qilib, kuniga 30 ta malikani tırtılga aylantiradi. 810 ta malikani tırtılga aylantirish uchun unga necha kun kerak bo'ladi? 15 kun ichida ishni bajarish uchun kuniga qancha malika tırtıllara aylanishi kerak?
Qaysi savolni "agar ... nima bo'ladi" turiga va qaysi biri "bunday qilish kerak ..." turiga bog'liq bo'lishi mumkin?

3. Modellashtirishning eng mashhur maqsadlarini sanab o'ting.

4. G. Osterning "Muammolar kitobi" dan o'ynoqi muammoni rasmiylashtiring:

Bir-biridan 27 km uzoqlikda joylashgan ikkita budkadan bir vaqtning o'zida ikkita g'amgin it bir-biriga sakrab chiqdi. Birinchisi soatiga 4 km, ikkinchisi esa 5 km / soat tezlikda ishlaydi.
Jang qachongacha boshlanadi?

5. Iloji boricha "er-xotin poyabzal" ob'ektining ko'plab xususiyatlarini nomlang. Turli maqsadlar uchun ob'ektning axborot modelini tuzing:
■ yurish uchun poyabzal tanlash;
■ mos poyabzal qutisini tanlash;
■ poyabzalni parvarish qilish uchun krem ​​sotib olish.

6. Kasb tanlash bo'yicha tavsiyanoma berish uchun o'smirning qanday xususiyatlari zarur?

7. Nima uchun kompyuter simulyatsiyada keng qo'llaniladi?

8. Sizga ma'lum bo'lgan kompyuterni modellashtirish vositalarini ayting.

9. Kompyuter tajribasi nima? Misol keltiring.

10. Model sinovi nima?

11. Modellashtirish jarayonida qanday xatolarga duch keladi? Xato topilganda nima qilish kerak?

12. Simulyatsiya natijalarini tahlil qilish nima? Odatda qanday xulosalar chiqariladi?