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

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

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

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

Туршилтын загварын хамрах хүрээ

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

Скриптийн чанар

Хувилбарын чанарыг удирдахын тулд туршилтын тохиолдлуудын тодорхойлолтын түвшинг төдийгүй тэдгээрийн чанарыг хянах шаардлагатай.

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

Туршилтын тохиолдлын тайлбарын боломжит түвшин:

4-р түвшинд үйлчлүүлэгчтэй хийсэн гэрээг гэрээгээр сольж болно.

Туршилтын тохиолдлуудыг тодорхойлох чанарын шалгуур нь дараах байдалтай байж болно.

• Туршилтын тохиолдлуудыг шаардлагын дагуу бичсэн байх ёстой

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

• Нарийвчилсан урьдчилсан нөхцөлийг ашиглах

Туршилтын цагийг хэрхэн хэмнэх вэ?

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

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

Туршилтын тохиолдлууд нь хоёрдмол утгагүй байх ёстой, i.e. хоёрдмол утгатай тайлбарыг зөвшөөрөхгүй, харин бүх оролцогчдод ойлгомжтой байхаар боловсруулж, томъёолсон байх ёстой.

Хэрэв тестийн тохиолдлуудыг бичихэд удаан хугацаа шаардагддаг бол мэргэжилтэн алдаагаа харахаа больсон нөхцөл байдал үүсч болно. Үүнийг хийхийн тулд та хажуу талаас нь харах хэрэгтэй - энд туслах болно хөндлөн тойм. Туршилтын загварыг боловсруулах нь цаг хугацааны хувьд уртасгаж, удаан үргэлжлэх тохиолдолд энэ үе шатыг хийхийг зөвлөж байна. Жишээлбэл, туршилтын хувилбаруудыг боловсруулахад 1 сараас дээш хугацаа шаардагдана.

Скриптийн чанарын хяналтын процессыг явуулж болно Туршилтын загвар удирдлагатай- тусгайлан бэлтгэсэн загвар.

Туршилтын загварын шинэчлэл

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

Шинэчлэхийн тулд Та "шаардлагын матриц" -ыг хадгалах боломжтой(Requirement Traceability Matrix): Тодорхой шаардлагад өөрчлөлт орсоны дараа туршилтын хяналтын системээс энэхүү шаардлагад хамаарах бүх туршилтын хувилбаруудын сонголтыг хийж, шинэчилдэг.

Туршилтын загвар удирдлага:

• туршилтын төмөр зам
• туршилтын холбоос
• Жира+Зефир
• Microsoft Test Manager (MTM)
• excel

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

Туршилтын үйл явцын зорилго

Туршилтын зорилго нь чанарыг үнэлэх явдал юм програм хангамжийн бүтээгдэхүүндамжуулан

• Бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлийн шалгалт;
• Бүрэлдэхүүн хэсгүүдийн зөв нэгтгэлийг шалгах;
• Бүх шаардлагын хэрэгжилтийн үнэн зөвийг шалгаж, согогийг илрүүлэх.

RUP дахь туршилтын үйл явцын онцлог

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

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

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

шалгагч (шалгагч)системийн туршилт хийх үүрэгтэй. Түүний үүрэг хариуцлагад туршилтыг тохируулах, гүйцэтгэх, туршилтын гүйцэтгэлийг үнэлэх, алдаа дутагдлыг арилгах, илэрсэн согогийг бүртгэх зэрэг орно.

Олдворууд

Туршилтын явцад дараахь баримт бичгийг бүрдүүлнэ.

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

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

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

Туршилтын үр дүнтуршилтыг гүйцэтгэх явцад олж авсан өгөгдөл.

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

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

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

Төсөлд орох үе шат. Энэ үе шатанд туршилтын бэлтгэл ажил хийгдэнэ. Үүнд:

• Туршилтын шаардлага, туршилтын стратеги агуулсан туршилтын төлөвлөгөөг бий болгох. Бүх төрлийн туршилт (функциональ, ачаалал гэх мэт) эсвэл төрөл тус бүрээр тусдаа төлөвлөгөө гаргах боломжтой.
• Туршилтын хамрах хүрээний дүн шинжилгээ.
• Чанарын шалгуур үзүүлэлтийг боловсруулж, туршилтыг дуусгах.
• Туршилтын хэрэгслийг суурилуулах, ажиллуулахад бэлтгэх.
• Туршилтын хэрэгцээгээр тодорхойлогддог PS хөгжүүлэх төсөлд тавигдах шаардлагыг томъёолох.

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

• Туршилтын хувилбаруудыг боловсруулах.
• Туршилтын скрипт үүсгэх.
• Хяналтын даалгавруудыг боловсруулах.
• Туршилтын аргуудыг боловсруулах.
• Ажлын ачааллын загвар боловсруулах.

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

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

Туршилтын үр дүнд үндэслэн илэрсэн согогийг арилгахын тулд програмын кодонд өөрчлөлт оруулсны дараа туршилтыг давтан хийнэ.

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

Туршилтын үр дүнг шалгасан PS-ийн чанар болон туршилтын процессыг тодорхойлох боломжийг олгодог туршилтын хэмжүүр дээр үндэслэн үнэлдэг.

Хэрэгслийн дэмжлэг

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

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

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

Хүрхрээ загвар (Шугаман дараалсан програм хангамжийн амьдралын мөчлөгийн загвар)

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

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

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

Өмнөх нийтлэлээс хүрхрээ загварын талаар илүү ихийг мэдэж аваарай..

V-Загвар (Баталгаажуулалт ба Баталгаажуулах загвар)

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

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

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

• Үе шат шаардлагын тодорхойлолтууд. Хүлээн авах шалгалт нь энэ үе шатанд хамаарна. Үүний гол үүрэг бол системийн эцсийн хэрэглээнд бэлэн байдлыг үнэлэх явдал юм.
• Ямар үе шат өндөр түвшний дизайн эсвэл Өндөр түвшний дизайн (HDL). Энэ үе шат нь системийн туршилтад хамаарах бөгөөд нэгдсэн системд тавигдах шаардлагуудын нийцлийн үнэлгээг багтаана.
• Нарийвчилсан дизайны үе шат(Нарийвчилсан дизайн) нь системийн янз бүрийн бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлийг шалгах интеграцийн туршилтын үе шаттай зэрэгцээ юм.
• Дараа нь кодлох үе шатӨөр нэг чухал алхам эхэлнэ - нэгжийн туршилт. Програм хангамжийн бие даасан хэсэг, бүрэлдэхүүн хэсгүүдийн үйлдэл зөв, шаардлагад нийцэж байгаа эсэхийг шалгах нь маш чухал юм.

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

нэмэгдүүлсэн загвар

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

1. дизайн ба хөгжүүлэлт
2. туршилт
3. хэрэгжилт.

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

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

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

спираль загвар

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

1. Төлөвлөлт
2. Эрсдлийн шинжилгээ
3. Хөгжил
4. Зэрэг

Эхний мөчлөг дууссаны дараа хоёр дахь нь эхэлнэ. Програм хангамжийн туршилт нь төлөвлөлтийн үе шатнаас эхэлж, үнэлгээний үе шат хүртэл үргэлжилнэ. Спираль загварын гол давуу тал нь эхний туршилтын үр дүн нь мөчлөг бүрийн 3 дахь шатанд хийсэн шинжилгээний үр дүнгийн дараа шууд гарч ирдэг бөгөөд энэ нь чанарыг зөв үнэлэхэд тусалдаг. Гэхдээ энэ загвар нь нэлээд үнэтэй бөгөөд жижиг төслүүдэд тохиромжгүй гэдгийг санах нь зүйтэй.

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

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

Хурдан

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

Agile-ийн талаар илүү ихийг мэдэж аваарай(тэмдэглэл - англи хэл дээрх нийтлэл).

Extreme Programming (XP, Extreme Programming)

Extreme Programming нь Agile програм хангамж хөгжүүлэлтийн нэг жишээ юм. Энэхүү аргын нэг онцлог шинж чанар нь "хос програмчлал" бөгөөд нэг хөгжүүлэгч код дээр ажилладаг бол түүний хамтран ажиллагсад бичсэн кодыг байнга хянаж байдаг. Програм хангамжийн туршилтын процесс нь кодын эхний мөрийг бичихээс өмнө эхэлдэг тул маш чухал юм. Хэрэглээний модуль бүр нь нэгжийн тесттэй байх ёстой бөгөөд ингэснээр ихэнх алдааг кодлох үе шатанд засах боломжтой. Өөр нэг ялгаатай шинж чанар бол тест нь кодыг тодорхойлдог бөгөөд эсрэгээр нь биш юм. Энэ нь бүх тестүүд тэнцсэн тохиолдолд л тодорхой кодыг бүрэн гүйцэд гэж үзэж болно гэсэн үг юм. Үгүй бол код татгалзсан болно.

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

Скрум

Scrum - Agile аргачлалын нэг хэсэг бөгөөд програм хангамжийг хөгжүүлэх үйл явцыг удирдах зорилгоор бүтээгдсэн давтагдах нэмэгдэл хүрээ. Scrum-ийн зарчмын дагуу туршилтын баг дараах алхмуудад оролцох ёстой.

• Scrum төлөвлөлтөд оролцох
• Нэгжийн туршилтын дэмжлэг
• Хэрэглэгчийн түүхийн туршилт
• Хүлээн авах шалгуурыг тодорхойлохын тулд үйлчлүүлэгч болон бүтээгдэхүүний эзэмшигчтэй хамтран ажиллана
• Автоматжуулсан туршилтаар хангах

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

Үүний зэрэгцээ Scrum дахь Agile арга зүйн зарчмууд нь тодорхой шинж чанаруудыг бий болгоход хүргэдэг.

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

Өмнөх нийтлэлээс Scrum аргачлалын талаар илүү ихийг мэдэж аваарай..

Дүгнэлт

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

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

Вэб үйлчилгээний туршилт

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

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

Яагаад үнэлэх вэ?

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

1. Өөрийн сул талыг хайж олох.Мэдээжийн хэрэг, энэ нь бидэнд хэрэгтэй юу? Зөвхөн гашуудах төдийгүй, хаана сайжруулах шаардлагатай байгааг мэдэхийн тулд. Туршилтанд ямар функциональ хэсгүүд хамаарахгүй вэ? Бид юуг шалгаагүй юм бэ? Алдаа дутагдлын хамгийн их эрсдэл хаана байдаг вэ?
2. Үнэлгээний үр дүнгээс бид 100% хамрагдах нь ховор. Юуг сайжруулах вэ? Хаашаа явах? Одоо хэдэн хувьтай байна вэ? Бид үүнийг ямар ч даалгавараар хэрхэн нэмэгдүүлэх вэ? Бид хэр хурдан 100 хүрэх вэ? Эдгээр бүх асуултууд бидний үйл явцад ил тод, тодорхой байдлыг авчирдаг., тэдгээрийн хариултыг хамрах хүрээний тооцоогоор өгсөн болно.
3. Анхаарал төвлөрөл.Манай бүтээгдэхүүн 50 орчим өөр функциональ талбартай гэж бодъё. гарч ирэх шинэ хувилбар, мөн бид тэдгээрийн 1-ийг туршиж эхэлж, тэндээс үсгийн алдаа, хэд хэдэн пиксел шилжүүлсэн товчлуурууд болон бусад жижиг зүйлсийг олдог ... Одоо турших хугацаа дуусч, энэ функцийг нарийвчлан туршиж үзсэн болно .. Харин үлдсэн 50 нь юу? Хамрах хүрээний үнэлгээ нь одоогийн бодит байдал, эцсийн хугацаан дээр үндэслэн ажлуудыг эрэмбэлэх боломжийг олгодог.

Хэрхэн үнэлэх вэ?

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

Туршилтаар шаардлагын хамрах хүрээг үнэлэх

Танай багт шинжээчид байгаа бөгөөд тэд цагаа дэмий өнгөрөөдөггүй гэж бодъё. ажлын цаг. Тэдний ажлын үр дүнд үндэслэн RMS (Шаардлага удирдлагын систем) - HP QC, MS TFS, IBM Doors, Jira (нэмэлт залгаасуудтай) гэх мэт шаардлагыг бий болгосон. Энэ системд тэд тавигдах шаардлагад нийцсэн шаардлагыг тавьдаг (таутологийг уучлаарай). Эдгээр шаардлагууд нь атом, ул мөр, тодорхой... Ерөнхийдөө туршилт хийхэд тохиромжтой нөхцөл. Ийм тохиолдолд бид юу хийж чадах вэ? Скриптийн аргыг ашиглахдаа шаардлага, тестийг холбоно уу. Бид нэг системд шалгалт хийж, шаардлага-туршилтын холболтыг хийж, ямар шаардлагад шалгалт байгаа, аль нь байхгүй, эдгээр шалгалтыг хэзээ давсан, ямар үр дүнд хүрсэн талаарх тайланг хүссэн үедээ харах боломжтой.
Бид хамрах хүрээний газрын зураг авдаг, бид бүх илчлэгдсэн шаардлагыг хангадаг, бүгд аз жаргалтай, сэтгэл хангалуун байдаг, алдаа дутагдлыг үл тоомсорлодог ...

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

Асуудал: Шаардлага нь атом биш юм.

Шинжээчид заримдаа толгойдоо салаттай нүгэл үйлддэг бөгөөд ихэвчлэн энэ нь бүхэл бүтэн төсөлтэй холбоотой асуудлуудаар дүүрэн байдаг. Жишээлбэл, та текст засварлагчийг хөгжүүлж байгаа бөгөөд таны системд "html форматыг дэмжих ёстой" болон "дэмжигдээгүй форматтай файлыг нээх үед асуулт бүхий гарч ирэх цонх" гэсэн хоёр шаардлага байж болно. гарч ирэх ёстой." 1-р шаардлагын үндсэн баталгаажуулалтад хичнээн шалгалт шаардлагатай вэ? Тэгээд 2 дахь нь? Хариултуудын ялгаа нь зуу дахин их байх магадлалтай!!! Хэрэв 1-р шаардлагад дор хаяж 1 тест байгаа бол энэ нь хангалттай гэж бид хэлж чадахгүй, гэхдээ 2 дахь нь, магадгүй бүрэн.

Тиймээс, шалгуур үзүүлэлттэй байх нь бидэнд ямар ч баталгаа өгөхгүй! Энэ тохиолдолд манай хамрах хүрээний статистик юу гэсэн үг вэ? Бараг юу ч биш! Бид шийдэх ёстой!

1. Энэ тохиолдолд тестээр тавигдах шаардлагын автомат тооцоог арилгаж болно - энэ нь семантик ачааллыг даахгүй хэвээр байна.
2. Шаардлага бүрийн хувьд бид хамгийн өндөр ач холбогдол өгөхөөс эхлээд тест бэлддэг. Бэлтгэхдээ бид энэ шаардлагад ямар шалгалт шаардлагатай вэ, хэд нь хангалттай байх вэ? Бид бүрэн хэмжээний туршилтын дүн шинжилгээ хийдэг бөгөөд "нэг тест байна, гэхдээ зүгээр" гэж бүү орхи.
3. Ашигласан системээс хамааран бид туршилтыг хүсэлтээр экспортлох/байршуулах ба… бид эдгээр туршилтуудыг туршиж үздэг! Тэд хангалттай юу? Мэдээжийн хэрэг, ийм туршилтыг шинжээч, энэ функцийг хөгжүүлэгчтэй хамт хийх ёстой. Тестийг хэвлэж, хамт ажиллагсдаа хурлын өрөөнд түгжиж, "тиймээ, эдгээр шалгалтууд хангалттай" гэж хэлэх хүртэл бүү явуул (энэ нь зөвхөн бичгээр тохиролцсоны дараа, шалгалтанд дүн шинжилгээ хийхгүйгээр бүртгэлээ цуцлах зорилгоор эдгээр үгсийг хэлсэн тохиолдолд л тохиолддог). Аман хэлэлцүүлгийн үеэр танай хамт олон шүүмжлэл, орхигдсон шалгалт, буруу ойлгосон шаардлага гэх мэтийг хэлэх болно - энэ нь үргэлж тааламжтай байдаггүй, гэхдээ тест хийхэд маш хэрэгтэй байдаг!)
4. Шаардлагын дагуу туршилтыг дуусгаж, бүрэн гүйцэд эсэхийг тохиролцсоны дараа системд энэ шаардлагыг "туршилтанд хамрагдсан" статусаар тэмдэглэж болно. Энэ мэдээлэл нь "энд дор хаяж 1 тест байна" гэхээс хамаагүй илүү утгатай болно.

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

Асуудал: Ямар ч шаардлага байхгүй.

Тэд төсөлд оролцоогүй, амаар хэлэлцдэг, хүн бүр өөрийн хүссэн / чаддаг зүйлээ, хэрхэн ойлгож байгаагаа хийдэг. Бид адилхан тест хийдэг. Үүний үр дүнд бид зөвхөн туршилт, хөгжүүлэлтээс гадна функцуудыг буруу хэрэгжүүлэхэд асар их тооны асуудалтай тулгардаг - бид огт өөр зүйлийг хүсч байна! Энд би "шаардлагыг өөрөө тодорхойлж, баримтжуулах" гэсэн сонголтыг зөвлөж болох бөгөөд энэ стратегийг практик дээрээ хэд хэдэн удаа ашигласан боловч 99% -д нь туршилтын багт ийм нөөц байдаггүй тул бага зэрэг явцгаая. нөөц их шаарддаг арга:

1. Онцлогын жагсаалтыг үүсгэ. Сами! Google-таблет хэлбэрээр, TFS дахь PBI форматаар - текст формат биш л бол аль нэгийг нь сонгоно уу. Бид статус цуглуулах шаардлагатай хэвээр байна! Бид энэ жагсаалтад бүтээгдэхүүний бүх функциональ хэсгүүдийг багтаасан бөгөөд задралын нэг ерөнхий түвшинг сонгохыг хичээгээрэй (та програм хангамжийн объект, хэрэглэгчийн скрипт, модуль, вэб хуудас, API арга, дэлгэцийн хэлбэрийг бичиж болно. .) - гэхдээ энэ бүгдийг нэг дор биш! Чухал зүйлийг алдахгүй байхад тань илүү хялбар, ойлгомжтой болгох НЭГ задлах формат.
2. Бид энэхүү жагсаалтын БҮРЭН БАЙДЛЫГ шинжээчид, хөгжүүлэгчид, бизнес эрхлэгчид, манай багийн хүрээнд зохицуулдаг ... Бүтээгдэхүүний чухал хэсгүүдийг алдахгүйн тулд бүх зүйлийг хийхийг хичээ! Хэр гүнзгий дүн шинжилгээ хийх нь танд хамаарна. Миний практикт бид хүснэгтэд 100 гаруй хуудас бүтээсэн хэдхэн бүтээгдэхүүн байсан бөгөөд эдгээр нь аварга том бүтээгдэхүүн байв. Ихэнхдээ 30-50 мөр нь цаашдын нарийн боловсруулалтанд хүрэх боломжтой үр дүн юм. Туршилтын тусгай шинжээчгүй жижиг багт илүү fichelista элементүүдийг хадгалахад хэтэрхий хэцүү байх болно.
3. Үүний дараа бид тэргүүлэх чиглэлүүдийг судалж, дээр дурдсан шаардлагын хэсэгт дурдсанчлан фичелистийн мөр бүрийг боловсруулна. Бид тест бичиж, ярилцаж, хангалттай эсэх талаар тохиролцдог. Бид статусуудыг тэмдэглэж, тэдгээрийн хувьд хангалттай туршилтууд байдаг. Бид багтай харилцах замаар шалгалтын статус, ахиц дэвшил, өргөжилтийг авдаг. Бүгд баяртай байна!

Харин... Шаардлагууд нь мөрдөгдөж болохуйц хэлбэрээр биш хэвээр хадгалагдвал яах вэ?

Асуудал: Шаардлагуудыг мөрдөх боломжгүй.

Төслийн талаар маш их хэмжээний баримт бичиг байдаг, шинжээчид минутанд 400 тэмдэгтийн хурдтайгаар бичдэг, танд техникийн үзүүлэлтүүд, техникийн үзүүлэлтүүд, зааварчилгаа, лавлагаа байдаг (ихэнхдээ энэ нь үйлчлүүлэгчийн хүсэлтээр тохиолддог) бөгөөд энэ бүхэн нь үүрэг гүйцэтгэдэг. шаардлагууд, бүх зүйл төсөл дээр удаан хугацааны туршид байсан. Ямар мэдээллийг хаанаас хайхаа эргэлзэж байна уу?
Өмнөх хэсгийг давтаж, бүхэл бүтэн багийг цэвэрлэхэд тусалсан!

1. Бид онцлог жагсаалт үүсгэдэг (дээрээс харна уу), гэхдээ шаардлагын нарийвчилсан тайлбаргүйгээр.
2. Онцлог бүрийн хувьд бид техникийн үзүүлэлт, тодорхойлолт, заавар болон бусад баримт бичгийн холбоосыг цуглуулдаг.
3. Бид тэргүүлэх чиглэлийн дагуу явж, тест бэлдэж, тэдгээрийн бүрэн бүтэн байдлын талаар тохиролцдог. Бүх зүйл адилхан, зөвхөн бүх баримт бичгийг нэг хавтан дээр нэгтгэсний ачаар бид тэдгээрт нэвтрэх хялбар байдал, ил тод байдал, шалгалтын тууштай байдлыг нэмэгдүүлдэг. Эцсийн эцэст бүх зүйл гайхалтай, бүгд аз жаргалтай байна!

Гэхдээ... Удахгүй... Сүүлийн долоо хоногт шинжээчид хэрэглэгчийн хүсэлтийн дагуу 4 өөр үзүүлэлтийг шинэчилсэн бололтой!!!

Асуудал: Шаардлага байнга өөрчлөгддөг.

Мэдээжийн хэрэг, зарим нэг тогтмол системийг турших нь сайхан байх болно, гэхдээ манай бүтээгдэхүүнүүд ихэвчлэн ажиллаж байна. Үйлчлүүлэгч ямар нэг зүйл хүссэн, манай бүтээгдэхүүнээс гадна хууль тогтоомжид ямар нэг зүйл өөрчлөгдсөн, хаа нэгтээ шинжээчид өнгөрсөн оны өмнөх жилийн шинжилгээний алдааг олж мэдэв ... Шаардлага нь өөрсдийн амьдралаар амьдардаг! Юу хийх вэ?

1. Та боломжийн жагсаалт, PBI, шаардлага, Wiki тэмдэглэл гэх мэт TK болон техникийн үзүүлэлтүүдийн холбоосыг аль хэдийн цуглуулсан гэж бодъё. Танд эдгээр шаардлагын тестүүд байгаа гэж бодъё. Тэгээд одоо шаардлага өөрчлөгдөж байна! Энэ нь RMS-д өөрчлөлт оруулах, эсвэл TMS (Task Management System) дахь даалгавар эсвэл шуудан дахь захидал гэсэн үг юм. Аль ч тохиолдолд энэ нь ижил үр дүнд хүргэдэг: таны тестүүд хуучирсан байна! Эсвэл тэдгээр нь хамааралгүй байж болно. Энэ нь тэдгээрийг шинэчлэх шаардлагатай гэсэн үг юм (туршилтын хамрах хүрээ хуучин хувилбарБүтээгдэхүүнийг ямар нэг байдлаар тийм ч их тооцдоггүй, тийм ээ?)
2. Онцлогуудын жагсаалтад, RMS, TMS (Test Management System - testrails, sitechco гэх мэт) тестүүдийг нэн даруй, ямар ч хамааралгүй гэж тэмдэглэх ёстой! HP QC эсвэл MS TFS дээр шаардлагыг шинэчлэх үед үүнийг автоматаар хийх боломжтой бөгөөд google-таблет эсвэл вики дээр та үзэг тавих хэрэгтэй болно. Гэхдээ та нэн даруй харах хэрэгтэй: туршилтууд нь хамаагүй! Энэ нь бид бүрэн дахин замыг хүлээж байна гэсэн үг юм: шинэчлэх, туршилтын дүн шинжилгээг дахин хийх, тестүүдийг дахин бичих, өөрчлөлтүүд дээр тохиролцох, зөвхөн дараа нь онцлог/шаардлагаа "туршилтанд хамрагдсан" гэж тэмдэглэнэ.

Энэ тохиолдолд бид тестийн хамрах хүрээний үнэлгээний бүх ашиг тусыг, тэр ч байтугай динамик байдлаар авдаг! Бүгд баяртай байна!!! Гэхдээ…
Гэхдээ та шаардлагуудтай ажиллахад маш их анхаарал хандуулж байсан тул одоо тестийг шалгах эсвэл баримтжуулах хангалттай цаг байхгүй. Миний бодлоор (мөн шашны маргаантай газар байдаг!) шалгуур нь шалгалтаас илүү чухал бөгөөд энэ нь илүү дээр юм! Наад зах нь тэд эмх цэгцтэй, бүх баг мэдэж байгаа бөгөөд хөгжүүлэгчид яг хэрэгтэй зүйлээ хийж байна. ГЭХДЭЭ ТЕСТИЙГ БАРИМТ БИЧГЭЭХ ЦАГ БАЙХГҮЙ!

Асуудал: Туршилтыг баримтжуулахад хангалттай хугацаа байхгүй.

Үнэн хэрэгтээ, энэ асуудлын эх үүсвэр нь зөвхөн цаг хугацаа дутмаг төдийгүй тэдгээрийг баримтжуулахгүй байх таны ухамсартай сонголт байж болно (бид үүнд дургүй, пестицидийн нөлөөллөөс зайлсхийдэг, бүтээгдэхүүн хэтэрхий олон удаа өөрчлөгддөг гэх мэт). Гэхдээ энэ тохиолдолд тестийн хамрах хүрээг хэрхэн үнэлэх вэ?

1. Танд бүрэн шаардлага эсвэл онцлог шинж чанаруудын жагсаалт хэрэгтэй хэвээр байгаа тул дээрх хэсгүүдийн аль нэг нь төслийн шинжээчдийн ажлаас хамааран шаардлагатай хэвээр байх болно. Шаардлага/онцлогын жагсаалт байна уу?
2. Бид тодорхой туршилтуудыг баримтжуулалгүйгээр богино хугацааны туршилтын стратегийг тайлбарлаж, амаар зөвшөөрч байна! Энэ стратегийг хүснэгтийн багана, вики хуудас эсвэл RMS-ийн шаардлагад зааж өгч болох бөгөөд дахин тохиролцсон байх ёстой. Энэхүү стратегийн нэг хэсэг болгон тоймыг янз бүрийн аргаар хийх болно, гэхдээ та хэзээ болохыг мэдэх болно сүүлийн удаатуршиж үзсэн бөгөөд ямар стратегитай вэ? Энэ нь бас муу биш гэдгийг та харж байна! Мөн хүн бүр аз жаргалтай байх болно.

Гэхдээ… Өөр юу "гэхдээ"? Аль нь???

Бид бүх зүйлийг тойрон гарах болно гэж хэлээрэй, өндөр чанартай бүтээгдэхүүн бидэнтэй хамт байх болтугай!

| Хичээлийн жилийн хичээлийн төлөвлөлт | Загварын үндсэн үе шатууд

Хичээл 2
Загварын үндсэн үе шатууд

Энэ сэдвийг судалснаар та дараахь зүйлийг сурах болно.

Загварчлал гэж юу вэ;
- загварчлалын прототип болж чадах зүйл;
- хүний ​​үйл ажиллагаанд загварчлал ямар байр суурь эзэлдэг вэ;
- загварчлалын үндсэн үе шатууд юу вэ;
- компьютерийн загвар гэж юу вэ;
Компьютерийн туршилт гэж юу вэ.

компьютерийн туршилт

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

Сургуульд та биологи, хими, физик, газарзүйн хичээл дээр туршилт хийдэг.

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

Лабораторийн болон бүрэн хэмжээний туршилтууд нь их хэмжээний материаллаг зардал, цаг хугацаа шаарддаг боловч тэдгээрийн ач холбогдол нь маш их юм.

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

Туршилтын төлөвлөгөө

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

Туршилт гэдэг нь бүтээгдсэн загварын зөв эсэхийг шалгах үйл явц юм.

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

Хүлээн авсан загварчлалын үр дүнгийн үнэн зөв эсэхийг шалгахын тулд дараахь зүйлийг хийх шаардлагатай: ♦ загвар бүтээх боловсруулсан алгоритмыг шалгах; ♦ бүтээсэн загвар нь загварчлалд харгалзан үзсэн анхны шинж чанарыг зөв тусгасан эсэхийг шалгаарай.

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

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

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

Судалгаа хийж байна

Туршилтын дараа та бүтээсэн загварын зөв гэдэгт итгэлтэй байвал судалгаанд шууд орж болно.

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

Компьютерийн туршилтыг бэлтгэх, явуулах схемийг Зураг 11.7-д үзүүлэв.

Цагаан будаа. 11.7. Компьютерийн туршилтын схем

Симуляцийн үр дүнгийн шинжилгээ

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

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

Санаж байх ёстой гол зүйл бол илэрсэн алдаа нь бас үр дүн юм. Алдаанаасаа суралцдаг гэдэг зүйр цэцэн үг байдаг. Оросын агуу яруу найрагч А.С.Пушкин мөн энэ тухай бичжээ.

Өө, бидэнд ямар олон гайхалтай нээлтүүд бий
Гэгээрлийн сүнсийг бэлтгэ
Мөн туршлага, хэцүү алдааны хүү,
Мөн суут ухаантан, парадокс найз,
Боломж, бурхан бол зохион бүтээгч ...

Хяналтын асуулт, даалгавар

1. Загварчлалын асуудлын мэдэгдлийн үндсэн хоёр төрөл юу вэ?

2. Г.Остерийн сайн мэдэх "Асуудлын ном"-д дараах асуудал бий.

Муу шулам уйгагүй хөдөлмөрлөж, өдөрт 30 гүнжийг гинжит болгон хувиргадаг. Тэр 810 гүнжийг катерпиллар болгоход хэдэн өдөр шаардагдах вэ? 15 хоногийн дотор ажлаа дуусгахын тулд өдөрт хэдэн гүнжийг катерпиллар болгох ёстой вэ?
"Хэрэв ... юу болох вэ" гэсэн асуултын аль нь, "хэрхэн үүнийг хийх вэ ..." гэсэн асуултын аль нь вэ?

3. Загварчлалын хамгийн алдартай зорилгыг жагсаа.

4. Г.Остерийн "Асуудлын дэвтэр"-ээс тоглосон асуудлыг албан ёсоор бич:

Бие биенээсээ 27 км-ийн зайд байрлах хоёр лангуунаас хоёр догшин нохой нэгэн зэрэг үсрэн гарч ирэв. Эхнийх нь 4 км / цаг хурдтай, хоёр дахь нь 5 км / цаг хурдтай ажилладаг.
Хэдий болтол тэмцэл эхлэх вэ?

5. "Хос гутал" объектын аль болох олон шинж чанарыг нэрлээрэй. Төрөл бүрийн зорилгоор объектын мэдээллийн загварыг зохиох:
■ явган аялал хийх гутал сонгох;
■ тохиромжтой гутлын хайрцаг сонгох;
■ гутал арчилгааны тос худалдан авах.

6. Мэргэжил сонгох зөвлөмж гаргахад өсвөр насны хүүхдийн ямар шинж чанарууд чухал вэ?

7. Компьютерийг яагаад симуляцид өргөн ашигладаг вэ?

8. Таны мэддэг компьютерийн загварчлалын хэрэгслүүдийг нэрлэ.

9. Компьютерийн туршилт гэж юу вэ? Жишээ хэлье.

10. Загварын туршилт гэж юу вэ?

11. Загвар хийх явцад ямар алдаа гардаг вэ? Алдаа илэрсэн тохиолдолд юу хийх ёстой вэ?

12. Симуляцийн үр дүнгийн шинжилгээ гэж юу вэ? Ихэвчлэн ямар дүгнэлт гаргадаг вэ?