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

Хөөе Хабр! Нэг өдөр манай дотоод семинар дээр шалгалтын албаны дарга ахлагч маань “Шалгалт хийх шаардлагагүй” гэсэн үгээр яриагаа эхэлсэн. Танхимд байсан бүх хүмүүс чимээгүй болж, зарим нь бүр сандлаасаа унахыг оролдов. Тэрээр бодлоо үргэлжлүүлэв: Туршилтгүйгээр нарийн төвөгтэй, үнэтэй төслийг бүтээх бүрэн боломжтой. Тэгээд хамгийн их магадлалтайгаар ажиллах болно. Гэхдээ бүтээгдэхүүн нь байх ёстой зүйлээрээ ажиллана гэдгийг мэдээд өөртөө хэр их итгэлтэй болохыг төсөөлөөд үз дээ.

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

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

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

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

Энгийн жишээг харцгаая. Манай аппликейшнийг bryak.com-д урьдчилан бэлтгэдэг (бодит сайттай ижил төстэй байдал нь санамсаргүй тохиолдол юм). Бид туршилтын шинэ хувилбарыг бэлтгэж байршуулсан. Юуны өмнө юуг шалгах ёстой вэ? Би програмыг нээлттэй хэвээр байгаа эсэхийг шалгаж эхлэх болно. Хэрэв вэб сервер бидэнд "200" гэж хариулбал бүх зүйл хэвийн байгаа тул та функцийг шалгаж эхлэх боломжтой.

Энэ шалгалтыг хэрхэн автоматжуулах вэ? Зарчмын хувьд та хөтчийг өсгөх функциональ тест бичиж, хүссэн хуудсыг нээж, шаардлагатай хэмжээгээр харуулах эсэхийг шалгах боломжтой. Гэхдээ энэ шийдэл нь хэд хэдэн сул талуудтай. Нэгдүгээрт, энэ нь урт юм: хөтчийг эхлүүлэх үйл явц нь шалгахаас илүү удаан үргэлжлэх болно. Хоёрдугаарт, энэ нь нэмэлт дэд бүтцийг хадгалахыг шаарддаг: ийм энгийн туршилтын хувьд бид хаа нэгтээ хөтөчтэй серверийг хадгалах хэрэгтэй. Дүгнэлт: бид асуудлыг өөрөөр шийдэх хэрэгтэй.

Бидний анхны утааны сорил

Badoo дээр арын хэсэг нь ихэвчлэн PHP дээр бичигдсэн байдаг. Тодорхой шалтгааны улмаас нэгжийн тестүүд дээр бичигдсэн байдаг. Нийтдээ бид аль хэдийн PHPUnit-тэй болсон. Шаардлагагүй технологи үйлдвэрлэхгүйн тулд бид PHP дээр утааны тест бичихээр шийдсэн. PHPUnit-ээс гадна бидэнд URL клиент номын сан (libcurl) болон PHP өргөтгөлтэй ажиллах cURL хэрэгтэй.

Үнэн хэрэгтээ тестүүд нь серверт шаардлагатай хүсэлтийг гаргаж, хариултыг шалгадаг. Бүх зүйл getCurlResponse() арга болон хэд хэдэн төрлийн баталгаатай холбоотой.

Энэ арга нь өөрөө иймэрхүү харагдаж байна.

Нийтийн функц getCurlResponse($url, массив $params = [ 'күүки' => , 'post_data' => , 'толгой' => , 'user_agent' => , 'proxy' => , ], $follow_location = үнэн, $ хүлээгдэж буй_хариу = '200 OK') ($ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, (1); хэрэв байгаа бол); $params['cookies']) && $params['cookies']) ( $cookie_line = $this->prepareCookiesDataByArray($params['cookies']); curl_setopt($ch, CURLOPT_COOKIE, $cookie_line); ) хэрэв ( isset($params['headers']) && $params['headers']) ( curl_setopt($ch, CURLOPT_HTTPHEADER, $params['headers']); ) if (isset($params['post_data']) && $params['post_data']) ( $post_line = $this->preparePostDataByArray($params['post_data']); curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_line)); ($follow_location) ( curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); ) хэрэв (isset($params['proxy']) && $params['proxy']) ( curl_setopt($c) h, CURLOPT_PROXY, $params['proxy']); ) хэрэв (isset($params['user_agent']) && $params['user_agent']) ( $user_agent = $params['user_agent']; ) else ( $user_agent = USER_AGENT_DEFAULT; ) curl_setopt($ch, CURLOPT_USERAGENT, CURLOPT_USERAGENT) $user_agent); curl_setopt($ch, CURLOPT_AUTOREFERER, 1); $хариу = curl_exec($ch); $this->logActionToDB($url, $user_agent, $params); if ($follow_location) ( $this->assertTrue((bool)$response, "Хоосон хариулт хүлээн авлаа. Curl алдаа: " . curl_error($ch) . ", алдаа: " . curl_errno($ch)); $this ->assertServerResponseCode($response, $expected_response); ) curl_close($ch); $ хариу буцаах; )
Энэ арга нь өөрөө өгөгдсөн URL дээр серверийн хариуг буцаах боломжтой. Энэ нь күүки, толгой хэсэг, хэрэглэгчийн агент болон хүсэлт гаргахад шаардлагатай бусад өгөгдөл зэрэг параметрүүдийг оролт болгон хүлээн авдаг. Серверээс хариу ирэхэд арга нь хариу код нь хүлээгдэж буй кодтой таарч байгаа эсэхийг шалгадаг. Хэрэв тийм биш бол туршилт амжилтгүй болж, алдаа гарна. Энэ нь уналтын шалтгааныг тодорхойлоход хялбар болгохын тулд хийгддэг. Хэрэв энэ хуудсан дээр ямар ч элемент байхгүй гэж хэлэхэд тест амжилтгүй болбол алдаа нь хариу код нь хүлээгдэж буй "200" биш, жишээлбэл "404" гэсэн мессежээс бага мэдээлэлтэй байх болно.

Хүсэлтийг илгээж, хариуг хүлээн авах үед бид хүсэлтийг бүртгэдэг бөгөөд ингэснээр дараа нь шаардлагатай бол туршилт унах эсвэл эвдэрсэн тохиолдолд үйл явдлын гинжин хэлхээг дахин гаргахад хялбар болно. Би энэ талаар доор ярих болно.

Хамгийн энгийн тест нь иймэрхүү харагдаж байна.

Нийтийн функц testStartPage() ( $url = 'bryak.com'; $response = $this->getCurlResponse($url); $this->assertHTMLPresent("
Энэ шалгалт нь нэг секундээс бага хугацаа шаардагдана. Энэ хугацаанд бид үүнийг шалгасан эхлэх хуудас"200" гэж хариулдаг бөгөөд энэ нь биеийн элементтэй. Ижил амжилттайгаар бид хуудсан дээрх хэдэн ч элементийг туршиж үзэх боломжтой бөгөөд туршилтын үргэлжлэх хугацаа мэдэгдэхүйц өөрчлөгдөхгүй.

Ийм туршилтын давуу талууд:

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

Сүүлийн цэгийн тухайд. Төсөлөөс багагүй тогтвортой гэсэн үг.

Зөвшөөрөл

Анхны утааны сорилоо бичээд гурван хоног өнгөрлөө гэж бодъё. Мэдээжийн хэрэг, энэ хугацаанд бид олсон бүх зөвшөөрөлгүй хуудсуудыг туршилтаар бүрхсэн. Бид хэсэг сууж, баярласан ч манай төслийн хамгийн чухал бүх зүйл зөвшөөрлийн ард байгааг ойлгосон. Би үүнийг бас яаж шалгах вэ?

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

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

Энэ хуудсыг дурын хөтөч дээр нээж, шалгагчийг нээнэ үү. Бид хэрэглэгчийн мэдээллийг оруулаад маягтыг илгээдэг.

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

Ямар ч хөтчийн хөгжүүлэгчийн хэрэглүүрт та cURL гэж хуулбарыг сонгон хүсэлтийг хуулж болно. Энэ маягт дээр командыг консолд оруулаад тэндээс харж болно. Үүнтэй ижил газарт параметрүүдийг өөрчлөх эсвэл нэмэх замаар шалгаж болно.

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

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

Нийтийн функц testAuthPage() ( $url = 'bryak.com'; $күүки = $this->getAuthCookies(' [имэйлээр хамгаалагдсан]', '12345'); $response = $this->getCurlResponse($url, ['күүки' => $күүки]); $this->assertHTMLPresent(" ", $response, "Алдаа: тест хуудасны үндсэн элементийг олж чадсангүй."); )
Бидний харж байгаагаар зөвшөөрлийн күүкийг хүлээн авч, дараагийн хүсэлтэд нэмэх аргыг нэмсэн. Энэ арга нь өөрөө маш энгийн байдлаар хэрэгждэг:

Нийтийн функц getAuthCookies($email, $password) ( // күүки аль хэдийн авсан эсэхийг шалгах If (array_key_exist($email, self::$known_cookies))) ( self::$known_cookies[$email]; буцаана) $url = self::DOMAIN_STAGING .'/auth_page_adds'; $post_data = ['имэйл' => $имэйл, 'нууц үг' => $нууц үг]; $response = $this->getCurlResponse($url, ['post_data' => $ post_data]); $күүки = $this->parseCookiesFromResponse($response); // цаашид ашиглахын тулд күүки хадгалдаг self::$known_cookies[$email] = $cookies; return $cookies; )
Энэ арга нь эхлээд өгөгдсөн и-мэйл (таны тохиолдолд энэ нь нэвтрэх эсвэл өөр зүйл байж болно) аль хэдийн хүлээн авсан зөвшөөрлийн күүкитэй эсэхийг шалгадаг. Хэрэв байгаа бол тэр буцааж өгнө. Үгүй бол хэрэглэгчийн цахим шуудан, нууц үг зэрэг шаардлагатай параметр бүхий зөвшөөрлийн хуудас руу (жишээ нь, bryak.com/auth_page_adds) хүсэлт гаргадаг. Энэ хүсэлтийн хариуд сервер толгойг илгээдэг бөгөөд тэдгээрийн дотор бидний сонирхсон күүки байдаг. Энэ нь иймэрхүү харагдаж байна:

HTTP/1.1 200 OK Сервер: nginx Content-Type: text/html; charset=utf-8 Дамжуулах-кодлох: хэсэгчилсэн Холболт: амьд байлгах Set-Cookie: нэр=утга; хугацаа дуусна=2016 оны 11-р сарын 30-ны Лхагва гарагийн 10:06:24 GMT; Хамгийн их нас=-86400; зам =/; домэйн=bryak.com
Эдгээр толгой хэсгээс энгийн энгийн илэрхийлэл ашиглан күүкиний нэр болон түүний утгыг авах хэрэгтэй (бидний жишээнд энэ нь нэр=утга). Хариултыг задлан шинжлэх арга маань дараах байдалтай байна.

$this->assertTrue((bool)preg_match_all("/Set-Cookie: (([^=]+)=([^;]+);.*)\n/", $response, $mch1), " Серверийн хариултаас "күүки" авах боломжгүй. Хариулт: " . $response);
Күүкийг хүлээн авсны дараа бид үүнийг зөвшөөрөл олгохын тулд аливаа хүсэлтэд аюулгүйгээр нэмж болно.

Унах туршилтын шинжилгээ

Дээрхээс харахад ийм тест нь серверт илгээсэн хүсэлтүүдийн багц юм. Бид хүсэлт гаргадаг, хариуг нь өөрчилдөг, дараагийн хүсэлтийг гаргадаг гэх мэт. Миний толгойд ийм бодол орж ирэв: хэрэв ийм шалгалт арав дахь хүсэлтэд бүтэлгүйтвэл түүний бүтэлгүйтсэн шалтгааныг олоход хэцүү байж магадгүй юм. Амьдралаа хэрхэн хялбарчлах вэ?

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

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

Жишээлбэл, хуудаснаас HTML-ийн хэсгийг олж чадаагүй тул бидний тест амжилтгүй болсон:

Холбоос
Бид цуглуулагчдаа очоод холбогдох хуудсыг нээнэ үү.

Та энэ хуудастай хөтөч дээрх бусад HTML хуудастай ижил аргаар ажиллах боломжтой. Та CSS байршуулагчийг ашиглан дутуу элементийг хайж олох боломжтой бөгөөд хэрэв үнэхээр байхгүй бол түүнийг өөрчилсөн эсвэл алдагдсан гэж шийдээрэй. Бид алдаа олсон байж магадгүй! Хэрэв элемент байгаа бол бид туршилтын хаа нэгтээ алдаа гаргасан байж магадгүй - бид энэ чиглэлд анхааралтай хандах хэрэгтэй.

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

Дээр тайлбарласан бүртгэлүүд нь задлан шинжлэхэд алдаа гаргахад туслахаас гадна бидний туршиж үзсэн зөвшөөрөгдсөн болон зөвшөөрөлгүй хуудасны жагсаалтыг гаргахад тусалдаг. Үүнийг харахад цоорхойг олж, арилгахад хялбар байдаг.

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

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

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

Үр дүн

Одоогоор бид *Teamcity-г нээж байна* wow, аль хэдийн 605 тест байна. Бүх туршилтууд зэрэгцээ явагдахгүй бол дөрөв хүрэхгүй минутын дотор явагдана.

Энэ хугацаанд бид дараахь зүйлийг баталгаажуулна.

• манай төсөл бүх хэл дээр нээгддэг (үүнээс 40 гаруй нь манайд үйлдвэрлэгддэг);
• гол улс орнуудын хувьд төлбөрийн зөв хэлбэрийг холбогдох төлбөрийн аргын хамт харуулсан;
• API-ийн үндсэн хүсэлтүүд зөв ажилладаг;
• дахин чиглүүлэх хуудас зөв ажилладаг (зохих хэрэглэгчийн агенттай гар утасны сайт руу орно);
• бүгд дотоод төслүүдзөв харуулсан.

Selenium WebDriver-ийн туршилтыг хийх нь хэд дахин илүү цаг хугацаа, нөөц шаарддаг. Шошго нэмэх

• Jargon File дээрх утааны тест

Викимедиа сан. 2010 он.

Бусад толь бичгүүдэд "Утаа тест" гэж юу болохыг харна уу.

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

утааны тест- Шаталтын бүрэн байдлыг тодорхойлох туршилтыг хийсэн ... Автомашины нэр томъёоны толь бичиг

утааны тест- 1. нэр үг a) Хоолой эсвэл хоолой руу утаа үлээхтэй холбоотой гоожсон сорил. б) Цахилгаан эрчим хүч хэрэглэхээс бүрдсэн шинээр баригдсан электрон тоног төхөөрөмжийн урьдчилсан туршилт, ямар ч аймшигтай утас байхгүй эсэхийг шалгах ... … Wiktionary

утааны туршилт- Энэ нь сантехник, модон салхины засвар, электроник, компьютерийн програм хангамж боловсруулах, зугаа цэнгэлийн салбарт хэрэглэгддэг нэр томъёо юм. Энэ нь засварын ажил эсвэл анхны угсралтын дараа хийгдсэн анхны туршилтыг хэлж байгаа бөгөөд туршилтанд хамрагдаж буй систем нь … … Wikipedia

утааны туршилт- bzw. Rauchtest нь Begriff aus dem Englischen, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung юм. Нэмж дурдахад … … Deutsch Wikipedia

Утаа- энэ нь материалд өртөх үед ялгардаг агаар дахь хатуу ба шингэн тоосонцор, хийн цуглуулга юм [SFPE Галаас хамгаалах инженерийн гарын авлага] ... … Wikipedia

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

утааны бөмбөг- Утааны бөмбөг гэдэг нь гал асаах үед утаа гаргах зориулалттай салют юм. Онгоцноос утаа гаргадаг төхөөрөмжүүд байдаг ч утааны бөмбөг гэсэн нэр томъёо нь гурван төрлийн төхөөрөмжийг тодорхойлоход хэрэглэгддэг: # Утааны бөмбөг нь хөндий, интоор юм… … Wikipedia

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

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

АШИГТ. Энэхүү энгийн үйл явц нь хэд хэдэн чухал давуу талыг өгдөг.

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

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

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

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

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

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

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

Ёс суртахууны сайжруулалт

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

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

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

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

Өдөр тутмын барилгын үндсэн хэсэг бол хамгийн сүүлд хийгдсэн хэсгийг бүтээх явдал юм. Жим МакКарти Програм хангамжийн хөгжлийн динамик номдоо (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 хөгжүүлэлтийн баг амжилтынхаа ихэнхийг өдөр тутмын бүтээн байгуулалтад өртэй. Бага цалинтай ажилладаг хөгжүүлэгчид нарийн төвөгтэй төслүүдмөн, тиймийн тул, өдөр тутмын угсралтын үйл явцын давуу талыг бүү ашигла, өөрсдөө зарим нэг үндэслэлтэй тайлбарыг гаргаж ирэх талаар бодох хэрэгтэй.

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

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

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

- Туршилт хийх(Баталгаажуулах тест)

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

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

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

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

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

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

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

- Регресс гаж нөлөө(Гаж нөлөөний регресс)- Сүүлийн үеийн код эсвэл өгөгдлийн өөрчлөлт нь хөгжүүлж буй програмын бусад хэсгийг эвдсэн болохыг нотлох оролдлого.

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

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

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

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

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