Туршилт хийх. Үндсэн онол

Төслийн дараагийн хувилбарыг гаргасны дараа утаа, ариун цэврийн шалгалт шууд эхэлдэг. Олон залуу туршигчдын хувьд энэ үйл явц туйлын эмх замбараагүй мэт санагддаг. Та өөрийгөө таньж байна уу? Тэгвэл энэ нийтлэл танд зориулагдана. Одоо бид утааны шинжилгээ ба ариун цэврийн шинжилгээний тодорхойлолтыг авч үзээд тэдгээрийн ялгааг ойлгоход хялбар жишээн дээр харуулах болно.

Утааны шинжилгээ:

Үүссэн бүтээц нь туршилтанд тохиромжтой эсэхийг баталгаажуулахын тулд утааны туршилтыг хийдэг. Үүнийг мөн "тэг өдрийн" баталгаажуулалт гэж нэрлэдэг.

Энэ төрлийн шалгалт нь таныг цаг алдахаас сэргийлнэ. Хэрэв үндсэн шинж чанаруудтай холбоотой асуудал байгаа бөгөөд чухал алдаа засаагүй бол програмыг бүхэлд нь туршиж үзэх нь утгагүй юм.

Ариун цэврийн шинжилгээ:

Програмын үндсэн функцийг шалгахын тулд ариун цэврийн туршилтыг гаргах үе шатанд явуулдаг. Тэд ихэвчлэн цаашаа явдаггүй. Энэ туршилтыг заримдаа регрессийн тестийн товчилсон хувилбар гэж нэрлэдэг.
Гаргах эцсийн хугацаа нь нарийн регрессийн тест хийх нь бараг боломжгүй юм. Энэ тохиолдолд хэрэглээний үндсэн функцүүдийн ажиллагааг шалгадаг ариун цэврийн туршилт нь маш сайн ажил хийдэг.

Утаа болон ариун цэврийн шалгалтын ялгааг илүү сайн ойлгох жишээ:

Эхний хувилбарыг гаргахаар төлөвлөж байгаа төсөл бий. Хөгжүүлэгчийн баг уг бүтээлийг туршихаар гаргаж, туршилтын баг ажиллаж эхэлдэг. Хамгийн эхний шалгалт бол ур чадварын шалгалт юм. Та энэ хувилбартай ажиллах боломжтой эсэхээ олж мэдэх хэрэгтэй. Энэ бол утааны туршилт юм. Хэрэв баг бүтээн байгуулалттай цаашид ажиллах зөвшөөрөл өгвөл туршилтын гүнзгий шат руу илгээгдэнэ. Бүтэц нь "Нэвтрэх", "Админ" ба "Ажилтан" гэсэн гурван модультай гэж төсөөлөөд үз дээ. Туршилтын баг модуль бүрийн зөвхөн үндсэн функцүүдийн ажиллагааг шалгадаг бөгөөд дэлгэрэнгүй мэдээлэл өгөхгүй. Энэ нь ариун цэврийн шалгалт болно.

Утаа болон ариун цэврийн туршилтын хэд хэдэн ялгаа:

• Утааны туршилтыг хөгжүүлэгчид болон туршигчид гүйцэтгэдэг;
• Ариун цэврийн туршилтыг зөвхөн шалгагч нар хийдэг.

• Утааны сорил нь програмын бүх үндсэн функцийг эхнээс нь дуустал хамардаг;
• Ариун цэврийн шалгалт нь зөвхөн хэрэглээний тодорхой бүрэлдэхүүн хэсгийг шалгадаг.

• Утааны туршилт нь тогтвортой ба тогтворгүй барилга байгууламжийг хоёуланг нь дамжуулдаг;
• Барилгын харьцангуй тогтвортой хувилбар нь ариун цэврийн туршилтанд хамрагдаж байна.

Кирилл Флягин, тоглоомын дизайнер, QA удирдагч

Эдгээр төрлийн туршилтуудтай зуны аналогийг хийцгээе. Та тарвас худалдаж авахыг хүсч байна гэж бодъё. Утааны шинжилгээ гэдэг нь нүдээр шалгаж, туузыг нь харж, шахаж, товшиж, үнэлдэг. Ийм аргаар үнэхээр амттай жимс худалдаж авдаг мастерууд байдаг. Ариун цэврийн шинжилгээнд та дээд талд нь пирамид хайчилж, өнгийг нь шалгадаг (бүрэлдэхүүн хэсгүүдийн нэг нь), гэхдээ тарвас бүхэлдээ ийм байгаа эсэхийг огт мэдэхгүй. Гэхдээ та зүсэгдсэн хэсэгт бүрэн итгэлтэй байна.

Хэрэв та нэг файлаас бүрдэх энгийн компьютерийн программ бүтээхийг хүсвэл тухайн файлд бичсэн бүх кодыг цуглуулж холбоход л хангалттай. Хөгжлийн баг ажиллах ердийн төсөл дээр хэдэн зуун, бүр хэдэн мянган файл байх болно. Энэ нь гүйцэтгэх боломжтой програмыг бий болгох үйл явц улам бүр төвөгтэй болж, цаг хугацаа их шаарддаг болоход "хувь нэмэр оруулдаг": та програмыг янз бүрийн бүрэлдэхүүн хэсгүүдээс "угсрах" хэрэгтэй.

Жишээлбэл, Майкрософт болон бусад зарим програм хангамж хөгжүүлэлтийн компаниудад ашигладаг практик нь өдөр бүр программ зохиох явдал бөгөөд энэ нь утааны туршилтаар нэмэгддэг. Өдөр бүр файл бүрийг угсарч, холбож, гүйцэтгэж болохуйц программ болгон нэгтгэсний дараа програм өөрөө маш энгийн туршилтанд хамрагддаг бөгөөд үүний зорилго нь програмыг ажиллуулах явцад тамхи татдаг эсэхийг шалгах явдал юм. Эдгээр туршилтыг утааны тест гэж нэрлэдэг (англи хэлнээс утаа - утаа). Ихэнх тохиолдолд энэ үйл явц нь нэлээд сайн автоматжуулсан (эсвэл байх ёстой).

ДАВУУ ТАЛУУД. Энэхүү энгийн үйл явц нь хэд хэдэн чухал давуу талыг өгдөг.

Интеграцийн явцад эрсдэлийг багасгах

Хөгжүүлэгч багт тулгардаг хамгийн чухал эрсдэлүүдийн нэг бол хөгжүүлэгчид өөрсдөө тус тусад нь, бие биенээсээ хамааралгүйгээр код дээр ажилладаг бөгөөд үүний үр дүнд үйлдвэрлэлийн кодыг угсарч байх үед нарийн төвөгтэй програм санаснаар ажиллахгүй байх явдал юм. Төсөлд үл нийцэх байдал хэзээ илэрсэнээс хамааран програмыг дибаг хийх нь өмнөх интеграцчилалтай харьцуулахад илүү их хугацаа шаардагдана, ялангуяа програмын интерфейс өөрчлөгдсөн эсвэл програмын үндсэн хэсгүүдэд томоохон өөрчлөлт хийсний дараа.

Утааны туршилтыг өдөр бүр угсарч, ажиллуулснаар интеграцийн алдааны эрсдлийг бууруулж, цаг тухайд нь хариу өгөх, хуримтлагдахаас урьдчилан сэргийлэх боломжтой.

Чанар муутай програм хангамжийн бүтээгдэхүүний эрсдэлийг бууруулах

Бүтээгдэхүүний чанар муу нь интеграцийн явцад гарсан алдаа, бэрхшээлээс шууд хамаардаг. Өдөр бүр утааны сорилын хамгийн бага багцыг ажиллуулах нь төслийг хэрэгжүүлэхэд алдаа, бэрхшээл гарахаас сэргийлдэг. Төслийг нэг удаа тогтвортой байдалд оруулсан бол мөнхөд тогтвортой байна. Ингэснээр та алдаа гарах түвшинд чанарыг нь бууруулахыг хэзээ ч зөвшөөрөхгүй.

Алдааг оношлоход тусална уу

Хэрэв нэг өдөр бүтээгдэхүүн бүтээгдээгүй бол (алдаатай бүтээгддэг) өдөр бүр утааны туршилт хийж, утааны шалтгааныг олоход илүү хялбар болно. Өчигдөр ажиллаж байсан, өнөөдөр ажиллахгүй байгаа бүтээгдэхүүн нь хоёр барилгын хооронд ямар нэг зүйл буруу болсны тод дохио юм.

Сайжруулсан ёс суртахуун

Хэрэв бүтээгдэхүүн ажиллаж, өдөр бүр илүү олон шинэ чанар, функцийг олж авдаг бол хөгжүүлэгчид онолын хувьд өсөх ёстой бөгөөд энэ бүтээгдэхүүн яг юу хийх нь тийм ч чухал биш юм. Бүтээгдхүүн нь дэлгэцэн дээр тэгш өнцөгт дүрс гарч байсан ч түүний "тархины хүүхэд" хэрхэн ажиллаж байгааг харах нь хөгжүүлэгчийн хувьд үргэлж таатай байдаг :)

Өдөр бүр хийц, утааны сорилыг ашиглах

Энэ зарчмын зарим нарийн ширийн зүйлийг энд оруулав.

Өдөр тутмын програм бүтээх

Өдөр тутмын угсралтын үндсэн хэсэг бол хамгийн сүүлд дууссан хэсгийг угсрах явдал юм. Жим МакКарти Програм хангамжийн хөгжлийн динамик (Microsoft Press, 1995) номоо бичиж, төслийн өдөр тутмын бүтээн байгуулалтыг төслийн зүрхний цохилт гэж нэрлэжээ. Зүрхний цохилт байхгүй бол төсөл байхгүй, үхсэн. Майкл Кусумано, Ричард В. Селби нар өдөр тутмын барилга байгууламжийг төслийн синхрончлолын түлхэц гэж тодорхойлсон (Microsoft Secrets, The Free Press, 1995). Хөгжүүлэгч бүр кодыг өөр өөрийнхөөрөө бичдэг бөгөөд код нь төслийн нийтээр хүлээн зөвшөөрөгдсөн хүрээнээс хэтэрч магадгүй - энэ нь хэвийн үзэгдэл боловч синхрончлолын импульс бүрт код нь стандарт руу буцаж ирдэг. Синхрончлолын импульсийг байнга ашиглан хөгжүүлэхийг шаардаснаар та төслийг синхрончлолоос бүрмөсөн гарахаас сэргийлнэ.

Зарим компанид төслийг өдөр бүр биш, харин долоо хоногт нэг удаа угсардаг заншилтай байдаг. Энэ систем буруу учраас... Энэ долоо хоногт төсөлд "эвдрэл" гарсан тохиолдолд дараагийн амжилттай бүтээн байгуулалтаас өмнө хоёр долоо хоног өнгөрч магадгүй юм. Энэ тохиолдолд компани өдөр тутмын төслийн угсралтын системийн бүх ашиг тусыг алддаг.

Амжилтгүй бүтээх эсэхийг шалгаж байна

Өдөр бүр төсөл барьж байгаа тохиолдолд төсөл ажиллах ёстой гэж үздэг. Гэсэн хэдий ч, хэрэв төсөл ажиллахгүй бол түүнийг засах нь 1-р зорилт болно.

Төсөл бүр өөрийн гэсэн стандарттай бөгөөд "угсрах явцад эвдрэх" гэсэн тэмдэгтэй байдаг. Энэхүү стандарт нь бага зэргийн согогийг хянахад хангалттай чанарын түвшинг тогтоох ёстой бөгөөд төслийг "гацааж" байгаа согогийг анзаарахгүй байх ёстой.

Сайн бүтэц нь дор хаяж дараахь зүйлийг агуулсан бүтэц юм.

• бүх файл, номын сан болон бусад бүрэлдэхүүн хэсгүүдийг амжилттай эмхэтгэсэн;
• бүх файл, номын сан болон бусад бүрэлдэхүүн хэсгүүдийн холбоосууд хүчинтэй байна;
• програмын зөв ажиллах боломжийг үгүйсгэх тогтвортой системийн алдаа байхгүй;
• Утааны бүх шалгалтыг давдаг.

Өдөр тутмын утааны шинжилгээ

Утааны туршилтыг төслийн эхнээс дуустал бүхэлд нь хийх ёстой. Тэдгээр нь бүрэн, иж бүрэн байх шаардлагагүй, гэхдээ бүх үндсэн функцүүдийн тестийг багтаасан байх ёстой. Утааны сорил нь хангалттай гүн байх ёстой бөгөөд хэрвээ амжилттай болбол төслийг тогтвортой гэж нэрлэж, илүү гүнзгий сорилтод хамрагдах боломжтой гэж нэрлэж болно.

Утааны шинжилгээ хийхгүйгээр өдөр бүр цуглардаг цэг алдагддаг. Энэ процесс нь бүтээгдэхүүний чанарыг хамгаалж, интеграцийн асуудал үүсэхийг зөвшөөрдөггүй. Үүнгүйгээр өдөр бүр бүтээх үйл явц нь цаг хугацаа алдах бөгөөд зорилго нь эмхэтгэлийг шалгах явдал юм.

Утааны сорилыг төсөлтэй ижил түвшинд боловсруулах ёстой. Эхний ээлжинд утааны туршилтууд нь төсөл "Сайн уу, Дэлхий!" Систем хөгжихийн хэрээр утааны шинжилгээ илүү гүнзгийрдэг. Эхний утааны шинжилгээнд зарцуулсан хугацааг хэдхэн секундын дотор тооцдог боловч систем томрох тусам утааны шинжилгээнд шаардагдах хугацаа мөн нэмэгддэг. Төслийн төгсгөлд утааны туршилт хэдэн цаг үргэлжилж болно.

Барилгын бүлгийг тодорхойлох

Ихэнх төслүүд дээр системийн өдөр тутмын бүтээн байгуулалтыг хянаж, утааны шинжилгээ хийх үүрэгтэй тодорхой хүн байдаг. Энэ ажил нь энэ ажилтны үүргийн нэг хэсэг боловч томоохон төслүүд дээр ийм ажилчид илүү байж болох бөгөөд ийм ажил нь тэдний гол үүрэг юм. Жишээлбэл, Windows NT 3.0 төсөл бүтээх баг дөрвөн хүнтэй байсан (Паскаль Захари, Тоглогч!, Чөлөөт хэвлэл, 1994).

Зөвхөн утга учиртай тохиолдолд л шинэчилсэн найруулга нэмнэ үү

Ихэвчлэн хувь хүн хөгжүүлэгчид өдөр бүр системд чухал өөрчлөлт оруулах боломжийг олгохын тулд кодыг удаан бичдэг. Тэд кодын томоохон хэсэг дээр ажиллаж, хэд хоног тутам системд нэгтгэх ёстой.

Ихэнх төслүүд дараагийн бүтээн байгуулалтыг суллаагүй тохиолдолд торгуулийн системтэй байдаг. Төслийн хамгийн эхэнд ажлын дизайныг хадгалах нь хамгийн чухал зүйл гэдгийг тодорхой хэлэх нь зүйтэй. Дараагийн бүтээцийг гаргахгүй байх нь онцгой тохиолдол байж болох ч дүрэм биш юм. Систем дахин ажиллах хүртэл хөгжүүлэгчид бүх зүйлийг орхихыг шаарддаг. Байнгын барилгын доголдол (ажиллагаагүй барилга байгууламжийг гаргах) тохиолдолд төслийг хэвийн байдалд оруулахад нэлээд хэцүү байдаг.

Бага зэргийн торгууль нь системийн бүтээн байгуулалтын чанарыг хянах өндөр хэрэгцээг онцолж өгдөг. Зарим төслүүд дээр эвдэрсэн угсралтыг суллахын тулд угсралтын ажил бүтэлгүйтсэн хөгжүүлэгчдэд чихэр өгдөг. Ийм хөгжүүлэгчийн оффисын үүдэнд угсралтыг засах хүртэл харгалзах тэмдэг өлгөөтэй байдаг (хөгжүүлэгчид тусдаа оффистой бол :)). Бусад төслүүд дээр буруутай хөгжүүлэгчид хуурамч ямааны эвэр зүүх эсвэл "ёс суртахууны сан"-д тодорхой хэмжээний хандив өгөх ёстой (жишээ нь компанийн бодит түүхээс авсан).

Гэхдээ зарим төсөл дээр илүү ноцтой торгууль ногдуулдаг. Жишээлбэл, Microsoft-ын хөгжүүлэгчид өндөр ач холбогдолтой төслүүд дээр ажилладаг (Windows NT, Windows 95, Excel) пейжер зүүж, хэрэв аудит илэрсэн бол ажилдаа тайлагнах ёстой байв. Шөнийн 3 цагт эвдрэл, алдаа илрүүлсэн ч гэсэн.

Системийг угсарч, даралтын дор ч гэсэн "утах"

Төслийн нээлтийн хуваарийн дарамт нэмэгдэхэд өдөр бүр системийн бүтээн байгуулалтыг шалгах ажил нь цаг үрсэн мэт санагдаж магадгүй юм. Гэсэн хэдий ч энэ нь үнэн биш юм. Стресстэй нөхцөлд хөгжүүлэгчид ихэвчлэн алдаа гаргадаг. Тэд ердийн нөхцөлд байхгүй байсан хэрэгжилтийг гаргах дарамтыг мэдэрдэг. Тэд өөрсдийн кодоо нэгжийн тестээр ердийнхөөс хамаагүй бага анхааралтай шалгадаг. Ийм нөхцөлд код нь стресс багатай нөхцөл байдлаас хамаагүй хурдан энтропийн төлөвт ордог.

Энэ үйл явц хэнд ашигтай вэ? Зарим хөгжүүлэгчид өдөр тутмын бүтээн байгуулалтыг эсэргүүцэж, эсэргүүцлээ энэ үйл ажиллагаа нь бодит бус, их хэмжээний хөрөнгө оруулалтаар зөвтгөдөг. Гэхдээ сүүлийн үеийн бүх нарийн төвөгтэй системүүд өдөр бүр угсралт, утааны туршилтанд хамрагдсан. Майкрософт Windows NT 3.0 нь худалдаанд гарах үед 40,000 файл дотор 5,6 сая мөртэй байсан. Бүрэн бүтээх ажилд 19 цаг зарцуулсан бөгөөд олон компьютер дээр гүйцэтгэсэн. Гэсэн хэдий ч хөгжүүлэгчид системийг өдөр бүр угсарч чадсан. Мэргэжлийн багийн хувьд NT хөгжүүлэлтийн баг өдөр тутмын бүтээн байгуулалтаараа амжилтанд хүрсэн. Илүү төвөгтэй төслүүд дээр ажилладаг, тиймээс өдөр тутмын бүтээх үйл явцын давуу талыг ашигладаггүй хөгжүүлэгчид зарим үндэслэлтэй тайлбаруудыг авч үзэх хэрэгтэй.

Утааны шинжилгээ гэж юу вэ?

Утааны сорилт нь суурилуулсан бүтэц тогтвортой байгаа эсэхийг тодорхойлох програм хангамжийн туршилтын нэг төрөл гэж тодорхойлогддог. Энэ нь QA баг цаашдын туршилтыг үргэлжлүүлж чадах эсэхийг баталгаажуулах болно. Утааны сорил нь барилга тус бүр дээр хийгддэг хамгийн бага багц туршилтууд юм. Утааны сорилттой холбоотой мөчлөг энд байна

Утааны сорилт нь програм хангамжийг QA орчинд байршуулж, програмын тогтвортой байдлыг баталгаажуулах үйл явц юм. Үүнийг "Бүтээлийн баталгаажуулалтын тест" эсвэл "Итгэлийн тест" гэж нэрлэдэг.

Энгийнээр хэлбэл, бид чухал функцууд ажиллаж байгаа эсэхийг шалгаж байгаа бөгөөд туршилтанд хамрагдаж буй бүтээцэд ямар ч үзүүлбэр байхгүй эсэхийг шалгаж байна.

Энэ нь үндсэн функцүүдийн жижиг бөгөөд хурдан регрессийн тест юм. Энэ нь бүтээгдэхүүнийг туршихад бэлэн байгааг харуулсан энгийн тест юм. Энэ нь цаашдын туршилтыг цаг хугацаа, нөөцийг дэмий үрсэн болгохын тулд бүтээц нь алдаатай эсэхийг тодорхойлоход тусална.

Утааны туршилтууд нь уг барилгыг цаашдын албан ёсны туршилтад тэнцэх боломжийг олгодог. Утааны шинжилгээний гол зорилго нь гол асуудлуудыг эрт илрүүлэх явдал юм. Утааны туршилтууд нь системийн тогтвортой байдал, шаардлагад нийцэж байгааг харуулах зорилготой юм.

Бүтэц нь нэг буюу хэд хэдэн бүтээгдэхүүний функцийг хэрэгжүүлэхэд шаардлагатай бүх өгөгдлийн файлууд, номын сан, дахин ашиглах боломжтой модулиуд, инженерчлэгдсэн бүрэлдэхүүн хэсгүүдийг агуулдаг.

Энэ зааварт та сурах болно-

Бид хэзээ утааны шинжилгээ хийх вэ

Утааны туршилтыг програм хангамжийн шинэ функцуудыг боловсруулж, QA/үе шатлалын орчинд байрлуулсан одоо байгаа бүтээцтэй нэгтгэх болгонд хийдэг. Энэ нь бүх чухал функцууд зөв ажиллаж байгаа эсэхийг баталгаажуулдаг.

Энэхүү туршилтын аргын хувьд хөгжүүлэлтийн баг QA-д угсралтыг байрлуулдаг. Туршилтын тохиолдлуудын дэд бүлгүүдийг авч, дараа нь шалгагчид туршилтын кейсүүдийг угсралт дээр ажиллуулдаг. QA баг нь програмыг чухал функцүүдийн эсрэг туршиж үздэг. Эдгээр цуврал туршилтын тохиолдлууд нь бүтээгдсэн алдааг илрүүлэх зорилготой юм. Хэрэв эдгээр туршилтыг давсан бол QA баг Функциональ туршилтыг үргэлжлүүлнэ.

Аливаа алдаа нь системийг хөгжүүлэлтийн багт буцааж өгөх шаардлагатай байгааг харуулж байна. Барилгад өөрчлөлт орох бүрт бид тогтвортой байдлыг хангах үүднээс Утааны сорилыг хийдэг.

Жишээ: -Нэвтрэх цонхонд шинэ бүртгэлийн товчийг нэмж, шинэ кодоор бүтээх ажлыг эхлүүлсэн. Бид шинэ барилга дээр утааны шинжилгээ хийдэг.

Утааны шинжилгээг хэн хийх вэ

Бүтэцийг QA орчинд гаргасны дараа Утааны сорилтыг QA инженерүүд / QA удирдагч гүйцэтгэдэг. Шинэ бүтээн байгуулалт гарах бүрд QA баг нь утааны сорилт хийх програмын үндсэн функцийг тодорхойлдог. QA баг нь туршилтанд хамрагдаж буй программ дахь шоуны оролцогчдыг шалгадаг.

Бүтээлийг QA-д гаргахаас өмнө програмын зөв эсэхийг баталгаажуулахын тулд кодын хөгжүүлэлтийн орчинд хийсэн туршилтыг эрүүл мэндийн тест гэж нэрлэдэг. Энэ нь ихэвчлэн нарийн бөгөөд гүнзгий туршилт юм. Энэ нь боловсруулж буй програм нь үндсэн функциональ шаардлагад нийцэж байгаа эсэхийг шалгах процесс юм.

Эрүүл ахуйн шалгалт нь хөгжүүлэлтийн үе шат дууссаныг тодорхойлж, цаашдын туршилтын үе шатанд програм хангамжийн бүтээгдэхүүнийг давах эсэхээ шийддэг.

Бид яагаад утааны шинжилгээ хийдэг вэ?

Утааны сорил нь програм хангамжийг хөгжүүлэхэд чухал үүрэг гүйцэтгэдэг бөгөөд энэ нь эхний шатанд системийн зөв байдлыг баталгаажуулдаг. Ингэснээр бид туршилтын хүчин чармайлтыг хэмнэж чадна. Үүний үр дүнд утааны туршилт нь системийг сайн байдалд хүргэдэг. Утааны шинжилгээг дуусгасны дараа л функциональ туршилтыг эхлүүлнэ.

• Барилгад байгаа бүх шоуны зогсоолуудыг утааны шинжилгээгээр тодорхойлно.
• Барилга угсралтын ажлыг QA-д гаргасны дараа утааны туршилтыг хийдэг. Утааны туршилтын тусламжтайгаар ихэнх согогийг програм хангамжийн хөгжүүлэлтийн эхний үе шатанд илрүүлдэг.
• Утааны туршилтын тусламжтайгаар бид томоохон согогийг илрүүлэх, засах ажлыг хялбаршуулдаг.
• Утааны туршилт хийснээр QA баг шинэ кодоор илэрсэн програмын үйл ажиллагааны доголдлыг олж чадна.
• Утааны сорил нь гол ноцтой согогийг илрүүлдэг.

Жишээ 1:Бүртгэлийн цонх: Илгээх товчийг дарснаар хүчинтэй хэрэглэгчийн нэр, нууц үгээр дараагийн цонх руу шилжих боломжтой.

Жишээ 2:Хэрэглэгч вэб хуудаснаас гарах боломжгүй байна.

Утааны шинжилгээг хэрхэн хийх вэ?

Утааны туршилтыг ихэвчлэн гараар хийдэг боловч автоматжуулалтаар дамжуулан үүнийг хийх боломжтой байдаг. Байгууллага бүрт өөр өөр байж болно.

Гараар утааны туршилт хийх

Ерөнхийдөө утааны шинжилгээг гараар хийдэг. Үүнд хандах хандлага нь нэг байгууллагаас нөгөөд өөр өөр байдаг. Утааны туршилтыг эгзэгтэй замуудын навигацыг хүлээгдэж буй байдлаар хийж, функциональ байдалд саад учруулахгүй байхын тулд бүтээцийг QA-д гаргасны дараа өндөр ач холбогдолтой функциональ тестүүдийг авч, системийн чухал согогийг илрүүлэхийн тулд шалгана. . Хэрэв туршилт амжилттай болбол бид функциональ туршилтыг үргэлжлүүлнэ. Хэрэв туршилт амжилтгүй болбол уг бүтээцээс татгалзаж, системийн зөв байдлыг хадгалахын тулд хөгжүүлэлтийн багт буцааж илгээнэ. QA баг зөв бүтээх хувилбарыг шалгах ёстой.

Алдаа / согогийг засах гэх мэт шаардлагатай өөрчлөлтүүдийг хийсний дараа асуудал үнэхээр шийдэгдсэн эсэхийг баталгаажуулахын тулд програм хангамжийг дахин туршиж үзэх шаардлагатай. Програм хангамжийг суулгасны дараа програмын ажиллагаа эсвэл согогийг засах зөв эсэхийг баталгаажуулахын тулд дараахь төрлийн туршилтуудыг хийх ёстой.

- Утааны шинжилгээ(Утааны сорил)

- Регрессийн тест(Регрессийн тест)

- Бүтээлийг туршиж байна(Баталгаажуулах тест)

- Ариун цэврийн туршилт эсвэл тууштай байдал / үйл ажиллагааны шалгалт(Эрүүл мэндийн сорил)

Үзэл баримтлал утааны туршилтинженерийн орчноос гаралтай. Шинэ тоног төхөөрөмж (“техник хангамж”) ашиглалтад оруулахдаа угсралтаас утаа гарахгүй бол туршилт амжилттай болсон гэж үзсэн. Програм хангамжийн туршилтын талбарт энэ нь бүх програмын модулиудын ажиллах чадварыг өнгөц шалгах, хурдан олдсон ноцтой, хаах согог байгаа эсэхийг шалгахад чиглэгддэг. Утааны сорилтын үр дүнд үндэслэн уг программ хангамжийн суулгасан хувилбарыг турших, ажиллуулах, хэрэглэгчдэд хүргэхийг зөвшөөрсөн эсэх талаар дүгнэлт гаргадаг. Ажлыг хөнгөвчлөх, цаг хугацаа, хүн хүч хэмнэхийн тулд утааны сорилын туршилтын скрипт автоматжуулалтыг хэрэгжүүлэхийг зөвлөж байна.

Регрессийн тестЭнэ нь програм эсвэл орчинд хийсэн өөрчлөлтийг шалгахад (гажиг засах, кодыг нэгтгэх, өөр үйлдлийн систем, мэдээллийн сан, вэб сервер эсвэл програмын сервер рүү шилжүүлэх) өмнө байгаа функцууд нь зориулалтын дагуу ажиллаж байгааг баталгаажуулах зорилготой туршилтын төрөл юм (мөн эрүүл ахуйн туршилт эсвэл тууштай байдал/үйл ажиллагааны туршилтыг үзнэ үү). Регресс нь иймэрхүү байж болно функциональ,тийм ба ажиллагаагүйтуршилтууд.

Дүрмээр бол хөгжүүлэлт, туршилтын эхний үе шатанд бичсэн тестийн тохиолдлуудыг регрессийн тест хийхэд ашигладаг. Энэ нь програмын шинэ хувилбарын өөрчлөлт нь одоо байгаа функцийг гэмтээхгүй байх баталгаа юм. Дараачийн туршилтын процессыг хурдасгах, програм хангамжийн хөгжлийн эхний үе шатанд согогийг илрүүлэхийн тулд регрессийн тестийг автоматжуулахыг зөвлөж байна.

"Регрессийн тест" гэсэн нэр томъёо нь ашиглалтын нөхцөл байдлаас хамааран өөр өөр утгатай байж болно. Жишээлбэл, Сэм Канер тайлбарлав 3 үндсэн төрөлрегрессийн тест:

- Алдааны регресс– залруулсан алдаа нь үнэхээр засаагүй гэдгийг нотлох оролдлого.

- Хуучин алдааны регресс- код эсвэл өгөгдөлд саяхан өөрчлөлт орсон нь хуучин алдааны засварыг эвдсэн болохыг нотлох оролдлого, жишээлбэл. хуучин алдаанууд дахин гарч эхлэв.

- Гаж нөлөөний регресс- Код эсвэл өгөгдөлд саяхан өөрчлөлт орсон нь программын бусад хэсгийг эвдсэн болохыг нотлох оролдлого.

Эрүүл мэндийн сорил -Энэ нь тодорхой нэг онцлог шинж чанар нь тодорхойлолтод заасны дагуу ажиллаж байгааг нотлоход хангалттай өндөр төвлөрсөн туршилт юм. Энэ нь регрессийн тестийн дэд хэсэг юм. Програмын тодорхой хэсэг эсвэл хүрээлэн буй орчинд өөрчлөлт оруулсны дараа түүний гүйцэтгэлийг тодорхойлоход ашигладаг. Ихэвчлэн гараар хийдэг.

Ариун цэврийн болон утааны шинжилгээний ялгаа.Зарим эх сурвалжууд ариун цэврийн болон утааны шинжилгээг ижил зүйл гэж эндүүрдэг. Эдгээр төрлийн туршилтууд нь янз бүрийн чиглэлд "хөдөлгөөний вектор", чиглэлтэй байдаг гэдэгт бид итгэдэг. Утааны сорилтоос ялгаатай нь эрүүл мэндийн тест нь шалгаж буй функцэд гүнзгий чиглэгддэг бол утааны сорил нь хамгийн богино хугацаанд туршилтаар аль болох их ажиллагааг хамрах зорилгоор өргөн хүрээнд чиглэгддэг.

Бүтээлийг туршиж байна Build Verification Test нь туршилтыг эхлүүлэхийн тулд гаргасан хувилбар нь чанарын шалгуурт нийцэж байгаа эсэхийг тодорхойлох зорилготой туршилт юм. Зорилгуудын хувьд энэ нь цаашдын туршилт эсвэл ашиглалтын шинэ хувилбарыг хүлээн авахад чиглэсэн Утааны сорилтой адил юм. Энэ нь гаргасан хувилбарын чанарын шаардлагаас хамааран илүү гүнзгий нэвтэрч болно.

Суурилуулалтын туршилт -амжилттай суулгалт, тохиргоог шалгах, түүнчлэн програм хангамжийг шинэчлэх, устгахад чиглэгдсэн. Одоогийн байдлаар програм хангамжийг суулгах хамгийн түгээмэл арга бол ашиглах явдал юм суулгагчид(тусгай хөтөлбөрүүд нь өөрсдөө бас зохих шалгалт шаарддаг). Бодит нөхцөлд суулгагч байхгүй байж болно. Энэ тохиолдолд та шаардлагатай бүх арга хэмжээ, шалгалтыг алхам алхмаар тайлбарласан зааварчилгаа эсвэл Readme файл хэлбэрээр бичиг баримтыг ашиглан програм хангамжийг өөрөө суулгах хэрэгтэй болно. Аппликейшн нь аль хэдийн ажиллаж байгаа орчинд байрлуулсан тархсан системд энгийн багц заавар хангалтгүй байж болно. Үүнийг хийхийн тулд суулгацын төлөвлөгөөг ихэвчлэн бичдэг (Байршуулах төлөвлөгөө), энэ нь зөвхөн програмыг суулгах алхмуудыг төдийгүй бүтэлгүйтсэн тохиолдолд өмнөх хувилбар руу буцах алхмуудыг багтаадаг. Суурилуулалтын төлөвлөгөө нь өөрөө бодит ашиглалтад ороход асуудал гарахаас зайлсхийхийн тулд туршилтын журмаар явагдах ёстой. Суурилуулалт нь нэг минут тутамд сул зогсолт нь нэр хүнд алдагдах, их хэмжээний хөрөнгө мөнгө, тухайлбал банк, санхүүгийн компаниуд, тэр ч байтугай баннер сүлжээ гэх мэт системүүд дээр хийгддэг бол энэ нь ялангуяа үнэн юм. Тиймээс суулгах туршилтыг програм хангамжийн чанарыг хангах хамгийн чухал ажлуудын нэг гэж нэрлэж болно.

Төлөвлөгөө бичих, суулгах туршилтыг алхам алхмаар хийх, суурилуулах ажлыг буцаах зэрэг цогц арга барилыг угсралтын туршилт эсвэл суурилуулалтын туршилт гэж нэрлэж болно.

Орчуулга нь зохиогчийн эргэцүүлэл, өөрийн туршлагаас оруулсан нэмэлтүүдээр шингэлсэн болно

Энэ юуны тухай вэ?

Энэ нийтлэлд би эдгээр төрлийн туршилтуудын ялгааг тодруулж, тайлбарлаж, нэг төрлийн шалгалт дуусч, нөгөө нь эхэлдэг хил хязгаарыг (нөхцөлтэй ч гэсэн) зурахыг хүсч байна.

Туршилтанд шинээр орсон хүмүүст (тэр ч байтугай туршлагатай тестерүүдэд) эдгээр ойлголтыг салгах нь хэцүү байж болно. Ариун цэврийн шалгалт хаана эхэлж, утааны шинжилгээ хаана дуусдагийг та яаж мэдэх вэ? Үүнийг "утаа" гэж нэрлэхийн тулд системийн эсвэл түүний бүрэлдэхүүн хэсгүүдийн функциональ туршилтыг хэр зэрэг хязгаарлах шаардлагатай вэ? Сайт дээрх хэрэглэгчийн нэвтрэх маягт руу нэвтрэх/нууц үг оруулах нь утааны сорилт уу, эсвэл сайтын хуудсан дээр гарч ирсэн нь аль хэдийн шалгалтанд тэнцсэн үү?

Хатуухан хэлэхэд та яг ямар ялгаа байгааг хэлж чадахгүй ч гэсэн тест хийх боломжтой хэвээр байх болно. Та одоо ямар төрлийн шалгалт хийж байгаагаа ялгах талаар бодох ч хэрэггүй. Гэсэн хэдий ч мэргэжлийн утгаараа өөрөөсөө дээгүүр өсөхийн тулд та юу хийж байгаагаа, яагаад, хэр зөв хийж байгаагаа мэдэх хэрэгтэй.

Боловсролын хөтөлбөр

• Утааны шинжилгээ: харьцангуй тогтворгүй гэж үзэж байгаа төслийн (системийн) шинэ бүтээцийг (хувилбарыг) турших болгонд гүйцэтгэдэг. Бид эгзэгтэй AUT (Туршилтанд хамрагдах програм) функцүүд хүлээгдэж буй байдлаар ажиллаж байгаа эсэхийг баталгаажуулах хэрэгтэй. Энэ төрлийн туршилтын санаа нь ноцтой асуудлуудыг аль болох эрт илрүүлж, урт, нарийн төвөгтэй туршилтуудад гүнзгий орохгүйн тулд туршилтын эхний үе шатанд энэхүү бүтээн байгуулалтыг (шинэчилсэн найруулгад буцаах) татгалзаж, улмаар дэмий үрэхээс зайлсхийх явдал юм. илт гэмтэлтэй програм хангамж дээр цаг.
• Ариун цэврийн туршилт: Гүйцэтгэлийг нарийвчлан тодорхойлохын тулд харьцангуй тогтвортой програм хангамжийг олж авах бүрт ашигладаг. Өөрөөр хэлбэл, системийн үйл ажиллагааны чухал хэсгүүд шаардлагатай хэмжээнд бага түвшинд ажиллаж байгааг баталгаажуулж байна.

• Дахин туршилт хийх: онцлог/функцэд аль хэдийн согогтой байсан бөгөөд эдгээр согогийг саяхан зассан бол гүйцэтгэнэ
• Регрессийн тестүүд: үнэндээ арслангийн цаг хугацаа юу шаарддаг, яагаад туршилтын автоматжуулалт байдаг вэ? AUT-ийн регрессийн туршилтыг шинэ (нэмэгдсэн) програмын функцууд / тогтмол согогууд нь өмнө нь ажиллаж байсан (болон туршсан) одоо байгаа, одоо байгаа функцэд нөлөөлөхгүй эсэхийг шалгах шаардлагатай үед хийгддэг.

Гэхдээ үндсэндээ?

Жишээ: Бидэнд хэрэглэгчийн интерфэйс болон RESTful API бүхий вэб үйлчилгээ бий. Туршилтын хувьд бид дараахь зүйлийг мэднэ.

• Энгийн болгох үүднээс энэ нь 10 нэвтрэх цэгтэй, манай тохиолдолд ижил IP дээр байрладаг
• Бид бүгдээрээ GET хүсэлтийг хүлээн авч json форматаар зарим өгөгдлийг буцаадаг гэдгийг бид мэднэ.

• Эдгээр нэвтрэх цэгүүдийн аль нэгэнд нь энгийн GET хүсэлтийг гүйцэтгэж, json форматаар хариу хүлээн авснаар утааны сорилт амжилттай болсон гэдэгт бид аль хэдийн итгэлтэй байна.
  Хэрэв эдгээр нэвтрэх цэгүүдийн аль нэг нь мэдээллийн сангаас өгөгдлийг буцаадаг бол эхнийх нь буцаадаггүй бол та програм ажиллаж байгаа эсэхийг шалгахын тулд өөр асуулга ажиллуулах шаардлагатай болно.
  өгөгдлийн сангийн хүсэлтийг зөв боловсруулах. Энэ нь "утаа" тестийг дуусгах болно.

  Өөрөөр хэлбэл, бид хүсэлтийг бөглөсөн - үйлчилгээнээс хариу ирсэн бөгөөд энэ нь "тамхи татаагүй", өөрөөр хэлбэл 4xx эсвэл 5xx алдааг буцаагаагүй бөгөөд json-ийн оронд тодорхойгүй зүйл. Энэ үед бид “утаа” шалгалтыг давсан гэж хэлж болно. UI ижил аргаар ажиллаж байгаа эсэхийг шалгахын тулд та хуудсыг хөтөч дээр нэг удаа нээхэд л хангалттай.

• Энэ тохиолдолд ариун цэврийн шалгалт нь api-д нэвтрэх бүх 10 цэгт хүсэлтийг гүйцэтгэх, хүлээн авсан json-г хүлээгдэж буй зүйлтэй шалгах, түүнчлэн шаардлагатай өгөгдөл байгаа эсэхийг шалгахаас бүрдэнэ.
• Регрессийн тестүүд нь утаа + эрүүл саруул байдал + UI-аас бүрдэх бөгөөд нэг овоолгод хамт ажилладаг. Зорилго: 11-р нэвтрэх цэгийг нэмэх нь нууц үг сэргээх гэх мэт эвдэрсэн эсэхийг шалгаарай.
• Энэ жишээн дэх дахин шалгалт нь жишээлбэл, дараагийн бүтээц дэх эвдэрсэн API нэвтрэх цэг нь зориулалтын дагуу ажиллаж байгаа эсэхийг цэг бүрээр шалгах явдал юм.

Үүнийг нэгтгэн дүгнэе

UPD:
Ихэнхдээ "тууштай байдлын туршилт" эсвэл "эрүүл мэндийн сорил" -ыг "ариун цэврийн шалгалт" гэж нэрлэдэг. Энэ нь англи хэлний sanity гэдэг үгийн авианы шинж чанараас үүдэлтэй гэж би бодож байна, энэ нь "ариун цэврийн" гэсэн үгтэй төстэй юм. Google Translate нь тодорхой байдлыг авчирдаг. Хоёр сонголтыг интернетээс авах боломжтой. Энэ зүйлийн талаар "ариун цэврийн" туршилтыг "тууштай байдлын туршилт" гэж үзнэ үү.

Зөвлөгөө өгсөнд баярлалаа