ev › Quraşdırma və konfiqurasiya › Proqram məhsulunun sınaqdan keçirilməsi. Onun daxilində digər funksiyalardan istifadə edən funksiyanın funksionallığını necə yoxlamaq olar? Müvafiq testi dəyişdirin

Proqram məhsulunun sınaqdan keçirilməsi. Onun daxilində digər funksiyalardan istifadə edən funksiyanın funksionallığını necə yoxlamaq olar? Müvafiq testi dəyişdirin

Əgər siz o qədər dözümlü olsanız belə, yarım saat ərzində qəzadan sonra proqramı 18 dəfə yenidən başlada bilsəniz və yalnız bundan sonra monitoru birbaşa pəncərəyə atsanız, razılaşarsınız ki, bu proqramla işləmək “qəza etməsəydi” daha rahat olardı. ” .

Necə əmin ola bilərsiniz ki, hazırladığınız proqramın qəzaya uğraması, donması və ya lazımi hərəkətlərinin yerinə yetirilməməsi halları çox nadir hala gəlir?

Dəqiq cavab bu sual Yox. Lakin əsrlər boyu ən müdrik elm adamları bu mövzu haqqında illərlə fikirləşdilər və bir çarə tapa bildilər ki, bütün proqram səhvlərini aradan qaldırmasa, heç olmasa onları aradan qaldırmaq üçün fəaliyyət illüziyası yaratsın.

Və bu vasitə adlanır SINAQ proqram məhsulu .

Müdrik insanların fikrincə, Testinq inkişafın keyfiyyətini təmin etmək üçün ən köklü üsullardan biridir proqram təminatı və komplektə daxildir təsirli vasitələr müasir sistem proqram məhsulunun keyfiyyətinin təmin edilməsi.

Proqram məhsulunun keyfiyyəti, məhsulun müştərisi, sponsoru, son istifadəçisi, məhsulun tərtibatçıları və testçiləri, dəstək mühəndisləri, marketinq işçiləri kimi maraqlı tərəflər baxımından məhsulun nə qədər “yaxşı” olduğunu müəyyən edən xüsusiyyətlər toplusu ilə xarakterizə olunur. , təlim və satış işçiləri. İştirakçıların hər birinin məhsul və onun nə qədər yaxşı və ya pis olması, yəni məhsulun keyfiyyətinin nə qədər yüksək olması barədə fərqli təsəvvürləri ola bilər. Beləliklə, məhsulun keyfiyyətinin təmin edilməsi probleminin qoyulması maraqlı tərəflərin, onların keyfiyyət meyarlarının müəyyən edilməsi və sonra bu meyarlara cavab verən optimal həll yolunun tapılması vəzifəsi ilə nəticələnir.

Nə vaxt və kim?

Təcrübəli tərtibatçıların fikrincə, proqram məhsulunun sınağı onun yaradılmasının lap əvvəlindən aparılmalıdır. Ancaq eyni zamanda, təcrübəli tərtibatçılar özləri sınaqda iştirak etməməlidirlər, çünki bu, kral məsələsi deyil. Proqram məhsulu tester adlanan xüsusi təlim keçmiş işçilər tərəfindən sınaqdan keçirilməlidir, çünki hətta ən təcrübəli tərtibatçı belə ən son optik alətlərdən istifadə etməklə öz səhvini görə bilməyəcək.

Bununla birlikdə, bütün tərtibatçılar razılaşırlar ki, bir proqram məhsulunun məqsədinə görə təsnifat baxımından sınaqdan keçirilməsi iki sinfə bölünməlidir:

Funksional sınaq
Qeyri-funksional sınaq

Funksional sınaq

Funksional sınaq proqram məhsulunun bu məhsulun yaradılması üçün texniki şərtlərdə göstərilən funksional tələblərə uyğunluğunun yoxlanılması deməkdir. Sadə dillə desək, funksional test proqram məhsulunun lazım olan bütün funksiyaları yerinə yetirib-yetirmədiyini yoxlayır.

Beləliklə, siz nəhayət funksional sınaq keçirməyə qərar verdiniz. Siz texniki spesifikasiyalara baxırsınız, funksional tələbləri oxuyursunuz və heç olmasa onların testin aparıla biləcəyi qaydada olmadığını başa düşürsünüz. Təəccüblənəcəksiniz ki, çoxdan çoxdan başqaları bu uyğunsuzluğu görüblər və onu necə aradan qaldıracağını anlayıblar.

Funksional sınaqların keçirilməsi üçün texniki nəzarət şöbəsinin əməkdaşları proqramın (API) funksionallığının sınaqdan keçirilməsi üçün sənəd proqramı və metodologiyası hazırlayır. PMI sənədində proqram məhsulu sınaq ssenarilərinin (sınaq nümunələri) siyahısı var Ətraflı Təsviri addımlar. Sınaq ssenarisinin hər bir addımı istifadəçinin (sınaq mütəxəssisinin) hərəkətləri və gözlənilən nəticələr - proqramın bu hərəkətlərə reaksiyası ilə xarakterizə olunur. Test proqramı və metodologiyası proqram məhsulunun real rejimdə işləməsini simulyasiya etməlidir. Bu o deməkdir ki, sınaq ssenarisi sistemin gələcək istifadəçilərinin yerinə yetirəcəyi əməliyyatların təhlili əsasında qurulmalı və yalnız tərtibatçı üçün başa düşülən süni şəkildə tərtib edilmiş manipulyasiya ardıcıllığı olmamalıdır.

Tipik olaraq, funksional sınaq iki səviyyədə aparılır:

Komponent (vahid) sınağı. Xüsusiyyətlərinə, məqsədinə və funksional xüsusiyyətlərinə yönəlmiş proqram məhsulunun ayrı-ayrı komponentlərinin sınaqdan keçirilməsi.
İnteqrasiya testi. Bu tip sınaq komponentlərin sınaqdan keçirilməsindən sonra həyata keçirilir və idarəetmə axınları və məlumat mübadiləsi səviyyəsində müxtəlif alt sistemlərin qarşılıqlı əlaqəsində qüsurların müəyyən edilməsinə yönəlib.

Qeyri-funksional sınaq

Qeyri-funksional test proqram məhsulunun erqonomika və ya performans kimi keyfiyyətlərini qiymətləndirir.

Düşünürəm ki, bu tip testlərin əhəmiyyəti aydındır və əsaslandırma tələb etmir. Axı, hamı başa düşür ki, məsələn, sistemin performansı kifayət deyilsə, o zaman istifadəçilər öz hərəkətlərinə cavab vermək üçün yarım gün gözləməli olacaqlar ki, bu da onların kütləvi qış yuxusuna səbəb ola bilər.

Adından da göründüyü kimi, qeyri-funksional test proqram məhsulunun qeyri-funksional tələblərə cavab verdiyini yoxlayır. texniki tapşırıqlar yaradılmasına görə. Və funksional testdə olduğu kimi, qeyri-funksional test üçün test proqramı və metodologiyası hazırlanır.

Çevik Dövrdə Quraşdırılmış Proqram Sınaqları və Uyğunluq

Sənaye standartlarına uyğunluq laqeyd qala biləcəyiniz və ya sonradan edə biləcəyiniz bir şey deyil; quraşdırılmış proqram təminatının (proqram təminatının) inkişafı prosesinin tərkib hissəsidir. Avionika, avtomobil və səhiyyə kimi bəzi sənayelər üçün mürəkkəb və problemsiz daxili sistemlərin işlənib hazırlanmasında keyfiyyət standartlarına ciddi riayət etmək məhsulu bazara çıxarmaq üçün həyati əhəmiyyət kəsb edir. Ənənəvi olaraq, sınaqlar standartlarla tənzimlənən sənayelər üçün quraşdırılmış sistemlərin inkişafında mühüm rol oynamışdır. Bununla belə, son illərdə müəyyən edilmiş sınaq təcrübələri və prosesləri, onların bu cür layihələrdə yeri və rolu əhəmiyyətli dərəcədə dəyişmişdir. Bu, oyun dəyişdirici idi və oyunun qaydaları dəyişdikdə, qalib gəlmək üçün onlarla birlikdə dəyişməlisən.

Yeni, qabaqcıl texnologiyaların daimi inkişafı ilə şirkətlər sürətlə dəyişən texnoloji dünyada itməmək üçün etibarlı, təhlükəsiz, istifadəsi asan və digər sistemlərlə uyğun gələn məhsulları tez bir zamanda bazara təqdim etməlidirlər. Belə bir vəziyyətdə, proqram təminatının hazırlanması prosesinin ciddi şəkildə ardıcıl olduğu və sınaqların ən sonunda həyata keçirildiyi ənənəvi şəlalə modeli keçmişə çevrilir. DevOps və Agile metodları getdikcə populyarlaşır, çünki onlar mühəndislərə əvvəllər bir-birini izləyən tapşırıqları eyni vaxtda yerinə yetirməyə imkan verir.

Performans testi

Performansın yoxlanılması mərhələsində ilk addım yük testidir, bunun məqsədi sistemin real iş rejiminə yaxın rejimdə xarici təsirlərə adekvat reaksiya verib-verməyəcəyini yoxlamaqdır.

Yük testinə əlavə olaraq, sınaqlar minimum aparat və maksimum yük şəraitində aparılır - stress testi, eləcə də işlənmiş məlumatın maksimum həcmi şəraitində sınaqlar - həcm testi.

Testin başqa bir növü var: sabitlik və etibarlılıq testi, bu, yalnız normal şəraitdə proqram məhsulunun uzunmüddətli sınaqdan keçirilməsini deyil, həm də qısamüddətli gərgin yüklərdən sonra onun normal işləmə qabiliyyətini əhatə edir.

Test üçün sənədlər

Yuxarıda qeyd edildiyi kimi, sınaq QOST 34.603-92 uyğun olaraq hazırlanmış proqram və test metodologiyasına uyğun olaraq həyata keçirilir.

Testi həyata keçirmək üçün proqram məhsulunun bütün iş rejimlərini sınaqdan keçirmək üçün kifayət qədər məlumatları ehtiva edən bir test işi hazırlanır. Tipik olaraq, sınaq işi real məlumatlar əsasında sifarişçi və podratçı tərəfindən birgə yaradılır.

Bütün növ performans testlərini həyata keçirmək üçün ən çox imkan verən sözdə məlumat generatoru yaradılır avtomatik rejim performansı qiymətləndirərkən obyektiv nəticə əldə etmək üçün kifayət qədər məlumat yaratmaq.

Sınaq zamanı testin bütün mərhələləri və mərhələlərinin başa çatması haqqında məlumatları və sınaq zamanı alınan şərhləri ehtiva edən bir sınaq protokolu tərtib edilir.

Test nəticəsi mənfi olarsa, çatışmazlıqlar düzəldilir və yenidən yoxlanılır.

Kəşfiyyat testi

Kəşfiyyat testi (ad hoc test funksional testin alt növüdür. O, dəqiq sənədləşdirmə və tələblərin olmadığı, çevik inkişaf metodları ilə sürətlə inkişaf edən layihələrdə istifadə olunur. Kəşfiyyat testi proqram təminatının sınaqdan keçirilməsində ən yüksək aerobatikadır. Keyfiyyətli sınaqdan istifadə etmək mümkündür. yüksək ixtisaslı mütəxəssislər və demək olar ki, tamamilə ifaçıdan, onun təcrübəsindən, biliyindən (həm mövzu sahəsində, həm də sınaq metodlarında) və mahiyyətə tez çatmaq bacarığından asılıdır.

Stress Testi

Yük sınağı, yük altında sınaqdan keçirilən sistemin performansının təhlili prosesidir. Yük testinin məqsədi tətbiqin xarici yüklərə tab gətirmək qabiliyyətini müəyyən etməkdir. Tipik olaraq, testlər bir neçə mərhələdə aparılır.

1. Test skriptlərinin yaradılması

Effektiv təhlil üçün ssenarilər real istifadə hallarına mümkün qədər yaxın olmalıdır. İstisnaların həmişə mümkün olduğunu başa düşmək vacibdir və hətta ən təfərrüatlı sınaq planı tək bir işi əhatə etməyə bilər.

2. Test konfiqurasiyasının hazırlanması

Test ssenarilərinə sahib olduqda, artan yükün sırasını paylamaq vacibdir. Uğurlu təhlil üçün performansın qiymətləndirilməsi meyarlarını (cavab sürəti, sorğunun emal müddəti və s.) müəyyən etmək lazımdır.

3. Test testinin aparılması

Testlər apararkən, ssenarilərin icrasına və sınaqdan keçirilən sistemin reaksiyasına vaxtında nəzarət etmək vacibdir. Yüksək yüklərin təqlid edilməsi ciddi aparat və proqram infrastrukturu tələb edir. Bəzi hallarda işin dəyərini azaltmaq üçün riyazi modelləşdirmə üsullarından istifadə olunur. Aşağı yüklərdə alınan məlumatlar əsas götürülür və təxmini hesablanır. Simulyasiya edilmiş yükün səviyyəsi nə qədər yüksək olarsa, qiymətləndirmənin dəqiqliyi bir o qədər aşağı olar. Ancaq bu üsul xərcləri əhəmiyyətli dərəcədə azaldır.

Test avtomatlaşdırılması

Avtomatlaşdırılmış testin əsas xüsusiyyəti reqressiya testlərini tez aparmaq imkanıdır. Avtomatlaşdırmanın əsas üstünlükləri (Worsoft-un hesabatına görə) işçilərin səmərəliliyinin artırılması, qüsurların erkən aşkarlanması və s. yüksək keyfiyyət biznes prosesləri. Bu üstünlüklər əhəmiyyətli bir çatışmazlıq ilə kompensasiya olunur: yüksək qiymət - sınaq avtomatlaşdırmasının tətbiqi və dəstəklənməsi yüksək qiymətə görə, şirkətlərin təxminən 50% -i hələ də əsasən əl testindən istifadə edir.

İstifadə qabiliyyəti testi

İstənilən proqram istifadə olunmaq üçün yaradılır. İstifadə rahatlığı proqramın mühüm keyfiyyət göstəricisidir. İT sənayesi uğurlu istifadəyə yararlılıq düzəlişindən sonra həyata keçirilən layihələrin bir çox nümunəsini bilir. Auditoriya nə qədər geniş olsa, istifadəyə yararlılıq faktoru bir o qədər vacibdir. İstifadəyə yararlılıq testi istifadəçi davranışının ətraflı təhlilini əhatə edir. Erqonomikanı qiymətləndirmək üçün təkcə iş tapşırığını yerinə yetirmə sürəti haqqında deyil, həm də istifadəçinin duyğuları, üz ifadələri və səs tembri haqqında məlumatların olması vacibdir.

Konfiqurasiya testi

Konfiqurasiya testi tətbiqin müxtəlif platformalarda və buna görə də maksimum istifadəçi sayı üçün işləyəcəyinə əminlik verir. WEB proqramları üçün adətən cross-brauzer testi seçilir. Windows proqramları üçün - müxtəlif testlər əməliyyat sistemləri və bit ölçüləri (x86, x64). Konfiqurasiya testinin vacib komponenti sınaq infrastrukturudur: testlər aparmaq üçün daim sınaq maşınları parkına qulluq etmək lazımdır. Onların sayı 5-dən bir neçə onlarla arasında dəyişir.

İnteqrasiya testi

Layihənizdə birdən çox komponent varsa, onun inteqrasiya testinə ehtiyacı var. Mürəkkəb tətbiq arxitekturası ilə keyfiyyət təminatı üçün zəruri şərt proqram hissələrinin qarşılıqlı əlaqəsini yoxlamaqdır. Test “başdan-başa” işlərin işlənib hazırlanması və aparılması yolu ilə həyata keçirilir. İnteqrasiya testi komponent testindən sonra aparılır. Buna görə də, test işlərinin biznes istiqamətinə hörmətlə yanaşı, komponent testi təcrübəsini nəzərə almaq çox vacibdir.

Stress testi

Hər sistemin bir limiti var normal işləməsi. Həddini aşdıqda, sistem stress vəziyyətinə keçir və davranışını əhəmiyyətli dərəcədə dəyişir. Stress testi normal işləmə hədlərini aşan şərtlərdə tətbiqin işini yoxlayır. Bu, xüsusilə "kritik" proqramlar üçün vacibdir: bank proqramı, aviasiya sənayesi proqramları, tibb. Stress testi yalnız proqram təminatının hazırlanması mərhələsində deyil, həm də uzun müddət ərzində sistemin davranış məlumatlarını əldə etmək və emal etmək üçün bütün əməliyyat dövrü ərzində həyata keçirilir.

Fərz edək ki, əldə məlumat funksiyası var, keçən istifadəçi ID haqqında məlumat xəritəsini qaytarır. İndi bu funksiya üç müxtəlif növ xəritə yaratmaq üçün mənbə-a, mənbə-b və mənbə-c 3 funksiyasından istifadə edir. İndi biz bütün bu xəritələri bir xəritədə birləşdirəcəyik və əldə edilən məlumatlardan geri dönəcəyik.

Mən əldə məlumatı sınaqdan keçirəndəaçarlar üçün məlumatın mövcudluğunu yoxlamalıyam? Mənbə-a, mənbə-b və mənbə-c-dən biri uğursuz olarsa, bu funksiyanın vahid testlərində uğursuz olması məntiqlidirmi? Bu funksiyanın işi verilənlərə qoşulmaqdırsa və bu, kifayətdir, elə deyilmi?

2 cavab

Fərz edək ki, ötürülən istifadəçi ID-si haqqında məlumat xəritəsini qaytaran get-data funksiyası var.

Əla. Sonra yoxlamalısan. Verilmiş ID üçün düzgün məlumatları qaytarırsınız?

indi bu funksiya üç müxtəlif növ xəritə yaratmaq üçün mənbə-a, mənbə-b və mənbə-c 3 funksiyasından istifadə edir.

Testdə hansı icra detalına məhəl qoymamalısınız. Test etdiyiniz tək şey budur ki, iş vahidiniz (bu üsul) etməli olduğu işi edir (identifikator götürün və həmin ID üçün XYZ məlumatını qaytarın). Necə bu metodun heç bir əhəmiyyəti yoxdur - axırda bu vahid testinin əsas üstünlüyü ondan ibarətdir ki, siz metodun həyata keçirilməsini yenidən nəzərdən keçirə bilərsiniz və test bunu düzgün etdiyinizi yoxlayacaq.

Bununla belə, çox güman ki, məlumat mənbələrinə lağ etməli olacaqsınız, ona görə də nə vaxtsa test bu kodun necə işlədiyini bilməlidir. Burada üç rəqabətli məqsədi tarazlaşdırmalısınız: testi təcrid etmək (məlumatları ələ salmaqla), testi tələblərə və praqmatizmə yönəltməklə.

Axı bu vacib koddur. Həqiqi kodu dəstəkləmək üçün testlər var, çox vaxt sərf etmək və lakı yoxlamaq əngəlləri testlər qədər faydalı deyil. edilməsi .

Vahid testində siz yalnız bir sinfin funksionallığını sınamalısınız, əgər mənbə-a, mənbə-b və mənbə-c metodlarınız digər sinifləri çağırırsa, onları ələ salmalısınız (onlar öz siniflərində vahid sınaqdan keçirilməlidir).

İnteqrasiya testində siz onlar arasında qarşılıqlı əlaqədə olan çoxsaylı siniflərin davranışını sınayırsınız, bu o deməkdir ki, əldə edilən məlumat funksiyanız əldə edilən məlumatın düzgün olduğunu yoxlamalıdır (mənbə-a, mənbə-b və mənbə-c düzgündür və data düzgün bağlanıb).

Vahid testləri daha sadə və daha çox diqqət mərkəzindədir və tərtibatçılar tərəfindən yazılmalıdır. İnteqrasiya testləri adətən nisbətən tez köhnəlir (əgər varsa). daxili komponent dəyişdirildi), onların yerinə yetirilməsini çətinləşdirir. QA profili tərəfindən yaradılmalıdır.

Necə əmin ola bilərsiniz ki, hazırladığınız proqramın qəzaya uğraması, donması və ya lazımi hərəkətlərinin yerinə yetirilməməsi halları çox nadir hala gəlir?

Bu sualın dəqiq cavabı yoxdur. Lakin əsrlər boyu ən müdrik elm adamları bu mövzu haqqında illərlə fikirləşdilər və bir çarə tapa bildilər ki, bütün proqram səhvlərini aradan qaldırmasa, heç olmasa onları aradan qaldırmaq üçün fəaliyyət illüziyası yaratsın.

Və bu vasitə adlanır Proqram məhsulunun sınaqdan keçirilməsi.

Müdrik insanların fikrincə, Test proqram təminatının işlənib hazırlanmasının keyfiyyətini təmin etmək üçün ən köklü üsullardan biridir və müasir proqram təminatı məhsulunun keyfiyyət təminatı sisteminin effektiv alətləri toplusuna daxildir.

Nə vaxt və kim?

Bununla birlikdə, bütün tərtibatçılar razılaşırlar ki, bir proqram məhsulunun məqsədinə görə təsnifat baxımından sınaqdan keçirilməsi iki sinfə bölünməlidir:

Funksional sınaq
Qeyri-funksional sınaq

Funksional sınaq

Funksional sınaqların keçirilməsi üçün texniki nəzarət şöbəsinin əməkdaşları proqramın (API) funksionallığının sınaqdan keçirilməsi üçün sənəd proqramı və metodologiyası hazırlayır. PMI sənədində addımların ətraflı təsviri ilə proqram məhsulunun sınaq ssenarilərinin (sınaq nümunələri) siyahısı var. Sınaq ssenarisinin hər bir addımı istifadəçinin (sınaq mütəxəssisinin) hərəkətləri və gözlənilən nəticələr - proqramın bu hərəkətlərə reaksiyası ilə xarakterizə olunur. Test proqramı və metodologiyası proqram məhsulunun real rejimdə işləməsini simulyasiya etməlidir. Bu o deməkdir ki, sınaq ssenarisi sistemin gələcək istifadəçilərinin yerinə yetirəcəyi əməliyyatların təhlili əsasında qurulmalı və yalnız tərtibatçı üçün başa düşülən süni şəkildə tərtib edilmiş manipulyasiya ardıcıllığı olmamalıdır.

Tipik olaraq, funksional sınaq iki səviyyədə aparılır:

Komponent (vahid) sınağı. Xüsusiyyətlərinə, məqsədinə və funksional xüsusiyyətlərinə yönəlmiş proqram məhsulunun ayrı-ayrı komponentlərinin sınaqdan keçirilməsi.
İnteqrasiya testi. Bu növ sınaq komponentlərin sınaqdan keçirilməsindən sonra həyata keçirilir və idarəetmə axınları və məlumat mübadiləsi səviyyəsində müxtəlif alt sistemlərin qarşılıqlı əlaqəsində qüsurların müəyyən edilməsinə yönəlib.

Qeyri-funksional sınaq

Qeyri-funksional test proqram məhsulunun erqonomika və ya performans kimi keyfiyyətlərini qiymətləndirir.

Adından da göründüyü kimi, qeyri-funksional sınaq proqram məhsulunun onun yaradılması üçün texniki spesifikasiyalardakı qeyri-funksional tələblərə uyğunluğunu yoxlayır. Və funksional testdə olduğu kimi, qeyri-funksional test üçün test proqramı və metodologiyası hazırlanır.

Çevik Dövrdə Quraşdırılmış Proqram Sınaqları və Uyğunluq

Performans testi

Test üçün sənədlər

Yuxarıda qeyd edildiyi kimi, sınaq QOST 34.603-92 uyğun olaraq hazırlanmış proqram və test metodologiyasına uyğun olaraq həyata keçirilir.

Bütün növ performans testlərini aparmaq üçün, performansı qiymətləndirərkən obyektiv nəticə əldə etmək üçün avtomatik olaraq kifayət qədər məlumat yaratmağa imkan verən sözdə məlumat generatoru yaradılır.

Sınaq zamanı testin bütün mərhələləri və mərhələlərinin başa çatması haqqında məlumatları və sınaq zamanı alınan şərhləri ehtiva edən bir sınaq protokolu tərtib edilir.

Test nəticəsi mənfi olarsa, çatışmazlıqlar düzəldilir və yenidən yoxlanılır.

Kəşfiyyat testi

Stress Testi

1. Test skriptlərinin yaradılması

2. Test konfiqurasiyasının hazırlanması

3. Test testinin aparılması

Test avtomatlaşdırılması

Avtomatlaşdırılmış testin əsas xüsusiyyəti reqressiya testlərini tez aparmaq imkanıdır. Avtomatlaşdırmanın əsas üstünlükləri (Worsoft-un hesabatına görə) işçilərin səmərəliliyinin artırılması, qüsurların erkən aşkarlanması və iş proseslərinin yüksək keyfiyyətidir. Bu üstünlüklər əhəmiyyətli bir çatışmazlıq ilə kompensasiya olunur: yüksək qiymət - sınaq avtomatlaşdırmasının tətbiqi və dəstəklənməsi yüksək qiymətə görə, şirkətlərin təxminən 50% -i hələ də əsasən əl testindən istifadə edir.

İstifadə qabiliyyəti testi

Konfiqurasiya testi

Konfiqurasiya testi tətbiqin müxtəlif platformalarda və buna görə də maksimum istifadəçi sayı üçün işləyəcəyinə əminlik verir. WEB proqramları üçün adətən cross-brauzer testi seçilir. Windows proqramları üçün - müxtəlif əməliyyat sistemlərində və bit sürətlərində sınaq (x86, x64). Konfiqurasiya testinin vacib komponenti sınaq infrastrukturudur: testlər aparmaq üçün daim sınaq maşınları parkına qulluq etmək lazımdır. Onların sayı 5-dən bir neçə onlarla arasında dəyişir.

İnteqrasiya testi

Stress testi

Hər hansı bir sistemin normal işləməsi üçün bir məhdudiyyət var. Həddini aşdıqda, sistem stress vəziyyətinə keçir və davranışını əhəmiyyətli dərəcədə dəyişir. Stress testi normal işləmə hədlərini aşan şərtlərdə tətbiqin işini yoxlayır. Bu, xüsusilə "kritik" proqramlar üçün vacibdir: bank proqramı, aviasiya sənayesi proqramları, tibb. Stress testi yalnız proqram təminatının hazırlanması mərhələsində deyil, həm də uzun müddət ərzində sistemin davranış məlumatlarını əldə etmək və emal etmək üçün bütün əməliyyat dövrü ərzində həyata keçirilir.

Bütün növlər arasında funksional sınaq haqlı olaraq lider mövqe tutur, çünki proqram ilk növbədə düzgün işləməlidir, əks halda istifadə rahatlığı, təhlükəsizlik və kifayət qədər sürət tamamilə faydasız olacaqdır. Müxtəlif test üsullarını mənimsəməklə yanaşı, hər bir mütəxəssis ən təsirli nəticə əldə etmək üçün testin necə düzgün aparılacağını başa düşməlidir.

Funksional test: əsas səyləri hara yönəltmək olar?

Vahid və sistem testi üçün;

“Ağ” və ya “qara” qutunu yoxlamaq üçün;

Əllə sınaq və avtomatlaşdırma üçün;

Yeni funksionallığı sınamaq və ya;

"Mənfi" və ya "müsbət" testlər üçün.

Bütün bu fəaliyyət sahələri arasında, hər birinin üstünlüklərindən maksimum istifadə edərək səyləri tarazlaşdırmaq üçün "orta" olacaq düzgün yolu tapmaq vacibdir.

Proqram təminatının yoxlanılması həyata keçirilir fərqli yollar, bunlardan biri qara qutu və ya verilənlərə əsaslanan testdir.

Bu vəziyyətdə proqram "qara qutu" nöqteyi-nəzərindən təqdim olunur və proqramın davranışının spesifikasiyaya uyğun gəlməyəcəyi halları müəyyən etmək üçün test aparılır. Bütün səhvlər, hərtərəfli test vasitəsilə həyata keçirilən məlumatların idarə edilməsi yolu ilə müəyyən edilir, yəni mümkün olan hər şeydən istifadə edilir

Əgər proqram üçün əmrin icrası ondan əvvəlki hadisələrdən asılıdırsa, o zaman bütün mümkün ardıcıllıqların yoxlanılmasını tələb edəcəkdir. Aydındır ki, əksər hallarda hərtərəfli sınaq keçirmək sadəcə qeyri-mümkündür, buna görə də daha tez-tez proqramın bütün daxil edilmiş məlumatların kiçik bir hissəsində işləməsi ilə məhdudlaşan məqbul və ya ağlabatan variantı seçirlər. Bu seçim spesifikasiyalardan heç bir sapmaya tam zəmanət verir.

Funksional test düzgün testin seçilməsini nəzərdə tutur. Eyni zamanda, onlar üçün dəstlər yaratmaq üçün aşağıdakı üsulları ayırmaq adətdir:

Sərhəd dəyərinin təhlili;

Ekvivalent bölmə;

Səhv ehtimalı;

Səbəblər və nəticələr arasındakı əlaqənin təhlili.

Onların hər birini ayrıca nəzərdən keçirə bilərsiniz.

Sərhəd dəyərinin təhlili. Sərhəd dəyərləri adətən ekvivalentlik siniflərinin sərhədlərində yerləşənlər kimi başa düşülür. Belə yerlərdə səhv tapmaq ehtimalı yüksəkdir. Belə bir metodun istifadəsi mütəxəssisdən müəyyən yaradıcılıq, həmçinin nəzərdən keçirilən bu konkret problemdə ixtisas tələb edir.

Ekvivalent bölmə. Giriş parametrlərinin bütün mümkün dəstləri bir neçə ekvivalentlik sinfinə bölünür. Məlumatlar oxşar səhvlərin aşkarlanması prinsipi əsasında birləşdirilir. Ümumiyyətlə qəbul edilir ki, əgər bir sinfin dəsti səhv göstərirsə, ekvivalentlər də bunu göstərəcək. Funksional test tərəfindən bu üsul iki mərhələdə həyata keçirilir: birincidə ekvivalentlik sinifləri müəyyən edilir, ikincisində isə artıq xüsusi testlər formalaşdırılır.

Səbəb-nəticə əlaqələrinin təhlili. Sistem bu cür yoxlamalar aparmaqla yüksək performanslı testləri seçə bilir. Bu zaman səbəb kimi ayrıca giriş şərti, nəticə kimi isə çıxış şərti görülür. Metod bütün növ səbəbləri müəyyən nəticələrə aid etmək fikrinə, yəni eyni səbəb-nəticə əlaqələrini aydınlaşdırmağa əsaslanır. Proqram məhsulunun sınaqdan keçirilməsi bir neçə mərhələdə həyata keçirilir, nəticədə səbəblər və sonrakı nəticələrin siyahısı verilir.

tərtibatçıların iş standartlarından və ya həyata keçirmə planlarından qəsdən kənara çıxmaları;
funksional və interfeys tələblərinin spesifikasiyası inkişaf standartlarına uyğun gəlmədən hazırlanır ki, bu da proqramların fəaliyyətinin pozulmasına səbəb olur;
inkişaf prosesinin təşkili - layihə menecerinin resurslarının (insan, texniki, proqram təminatı və s.) qeyri-kafi və ya qeyri-kafi idarə olunması və layihə elementlərinin sınaqdan keçirilməsi və inteqrasiyası məsələləri.

ISO/IEC 12207 standartının tövsiyələri əsasında sınaq prosesinə baxaq və hər bir həyat dövrü prosesində aşkar edilən səhvlərin növlərini verək.

Tələblərin İnkişafı Prosesi. Sistemin ilkin konsepsiyasını və sistemə ilkin tələbləri təyin edərkən analitiklər spesifikasiya xətalarına yol verirlər üst səviyyə sistemlər və mövzu sahəsinin konseptual modelinin qurulması.

Bu prosesdə tipik səhvlər:

son istifadəçilər üçün tələblərin spesifikasiyasının qeyri-adekvatlığı - proqram təminatının əməliyyat mühiti və ya istifadəçilərlə qarşılıqlı əlaqəsinin düzgün təyin edilməməsi;
fərdi və ümumi proqram xüsusiyyətlərinə dair müştəri tələblərinə uyğun gəlməməsi;
funksional xüsusiyyətlərin səhv təsviri;
müştəri tələblərinin həyata keçirilməsinin bütün aspektləri üçün alətlərin olmaması və s.

Dizayn Prosesi.Alqoritmləri, idarəetmə məntiqini, verilənlər strukturlarını, interfeysləri, verilənlər axınının modelləşdirilməsi məntiqini, giriş-çıxış formatlarını və s. təsvir edilərkən komponentlərin layihələndirilməsində səhvlər baş verə bilər. Bu xətalar analitik spesifikasiyalarındakı qüsurlara və dizayn qüsurlarına əsaslanır. Bunlara aşağıdakılarla bağlı səhvlər daxildir:

ətraf mühitlə istifadəçi interfeysinin tərifi ilə;
funksiyaların təsviri ilə (komponentlər toplusunun yoxlanılması zamanı aşkar edilən komponentlərin məqsəd və vəzifələrinin qeyri-adekvatlığı);
informasiyanın emalı prosesinin və proseslər arasında qarşılıqlı əlaqənin müəyyən edilməsi ilə (komponentlərin və proseslərin əlaqələrinin düzgün müəyyən edilməməsinin nəticəsi);
ayrı-ayrı komponentləri və bütövlükdə proqram təminatını təsvir edərkən məlumatların və onların strukturlarının səhv spesifikasiyası ilə;
modul alqoritmlərinin səhv təsviri ilə;
baş vermə şəraitinin müəyyən edilməsi ilə mümkün səhvlər proqramda;
layihə üçün qəbul edilmiş standartları və texnologiyaları pozmaqla.

Kodlaşdırma mərhələsi.Bu mərhələdə sistemin işlənib hazırlanması və sazlanması zamanı dizayn qüsurlarının, proqramçıların və menecerlərin səhvlərinin nəticəsi olan xətalar yaranır. Səhvlərin səbəbləri bunlardır:

giriş parametrləri, massiv indeksləri, dövrə parametrləri, çıxış nəticələri, 0-a bölünmə və s. dəyərlərə nəzarətin olmaması;
çağırılan alt proqramlardan, funksiyalardan və s.-dən qayıdış kodlarının təhlili zamanı qeyri-müntəzəm vəziyyətlərin düzgün idarə edilməməsi;
kodlaşdırma standartlarının pozulması (pis şərhlər, irrasional modulların paylanması və komponent və s.);
müxtəlif obyektləri və ya bir obyektin müxtəlif adlarını təyin etmək üçün bir addan istifadə, zəif ad mnemonika; - müxtəlif tərtibatçılar tərəfindən proqrama uyğun olmayan dəyişikliklər və s.

Test prosesi.Bu prosesdə quraşdırma və sınaq texnologiyasını yerinə yetirərkən, sınaq dəstləri və sınaq ssenarilərini seçərkən və s. zamanı proqramçılar və sınaqçılar tərəfindən səhvlərə yol verilir. Bu cür xətaların səbəb olduğu proqram təminatında yaranan nasazlıqlar müəyyən edilməli, aradan qaldırılmalı və komponentin statistikasına təsir etməməlidir. ümumiyyətlə proqram səhvləri.

Baxım prosesi.Xidmət prosesi zamanı əməliyyat sənədlərindəki çatışmazlıqlar və qüsurlar, dəyişdirilə bilən və oxuna bilən göstəricilərin qeyri-kafi olması, həmçinin proqram təminatının saxlanmasına və/və ya təkmilləşdirilməsinə cavabdeh olan şəxslərin səriştəsizliyi nəticəsində yaranan xətalar aşkar edilir. Edilən dəyişikliklərin xarakterindən asılı olaraq, bu mərhələdə əvvəlki mərhələlərdə əvvəllər sadalanan səhvlərə bənzər demək olar ki, hər hansı bir səhv baş verə bilər.

Proqramlarda baş verən bütün səhvlər adətən aşağıdakı siniflərə bölünür [7.12]:

məntiqi və funksional səhvlər;
hesablama və icra zamanı xətaları;
giriş/çıxış və verilənlərin manipulyasiya xətaları;
interfeys səhvləri;
məlumat həcmi səhvləri və s.

Məntiqi səhvlər alqoritmin məntiqinin pozulmasının, dəyişənlərin və operatorların daxili uyğunsuzluğunun, həmçinin proqramlaşdırma qaydalarının səbəbidir. Funksional səhvlər funksiyaların düzgün təyin edilməməsi, onların tətbiqi qaydasının pozulması və ya icrasının tam olmaması və s.

Hesablama səhvləri mənbə məlumatlarının və həyata keçirilən düsturların qeyri-dəqiqliyi, metod səhvləri, hesablama əməliyyatlarının və ya operandların düzgün tətbiq edilməməsi nəticəsində yaranır. İcra zamanı xətaları tələb olunan sorğunun emal sürətinin və ya proqramın bərpa vaxtının təmin edilməməsi ilə əlaqələndirilir.

I/O xətaları və verilənlərin manipulyasiyası verilənlərin proqramın icrası üçün keyfiyyətsiz hazırlanmasının, verilənlər bazalarına daxil edilərkən və ya ondan alınarkən uğursuzluqların nəticəsidir.

İnterfeys səhvləri ayrı-ayrı elementlərin bir-biri ilə əlaqəsindəki səhvlərə istinad edilir ki, bu da onlar arasında məlumatların ötürülməsi zamanı, eləcə də əməliyyat mühiti ilə qarşılıqlı əlaqə zamanı özünü göstərir.

Həcm səhvləri verilənlərə aiddir və həyata keçirilən giriş üsulları və verilənlər bazası ölçülərinin sistem məlumatlarının real həcmini və ya onların işlənməsinin intensivliyini təmin etməməsinin nəticəsidir.

Verilmiş əsas səhv sinifləri müxtəlif növ proqram komponentləri üçün xarakterikdir və proqramlarda müxtəlif yollarla özünü göstərir. Beləliklə, verilənlər bazası ilə işləyərkən məlumatların təqdim edilməsində və manipulyasiyasında səhvlər baş verir, məntiqi səhvlər tətbiq edilən məlumatların emalı prosedurlarının dəqiqləşdirilməsində və s. Hesablama proqramlarında hesablama xətaları, idarəetmə və emal proqramlarında isə məntiqi və funksional xətalar üstünlük təşkil edir. Müxtəlif funksiyaları yerinə yetirən çoxlu müxtəlif proqramlardan ibarət olan proqram təminatında səhvlər ola bilər fərqli növlər. İnterfeys xətaları və həcm pozuntuları istənilən sistem növü üçün xarakterikdir.

Proqramlarda səhvlərin növlərinin təhlili proqram təminatının düzgünlüyünü təmin etmək üçün test planları və test üsulları yaratmaq üçün ilkin şərtdir.

Proqram təminatının işlənib hazırlanmasına dəstək vasitələrinin (CASE texnologiyaları, model və proqramların layihələndirilməsi üçün obyekt yönümlü metodlar və alətlər) hazırkı inkişaf mərhələsində proqram təminatının ən çox yayılmış səhvlərdən qorunduğu və beləliklə, aşağıdakı səhvlərin baş verməsinin qarşısını alan dizayn həyata keçirilir. proqram qüsurları.

Səhv və uğursuzluq arasındakı əlaqə.Proqramda xətanın olması, bir qayda olaraq, onun işləməsi zamanı proqram təminatının sıradan çıxmasına gətirib çıxarır. "Səhv-uğursuzluğun" səbəb-nəticə əlaqələrini təhlil etmək üçün aşağıdakı hərəkətlər yerinə yetirilir:

dizayn və proqramlaşdırma texnologiyalarında qüsurların müəyyən edilməsi;
dizayn prosesindəki qüsurlarla insan səhvləri arasında əlaqə;
nasazlıqların, qüsurların və mümkün səhvlərin, eləcə də inkişafın hər bir mərhələsində qüsurların təsnifatı - layihənin spesifikasiyasında, proqram modellərində səhvlər nəticəsində müəyyən bir inkişaf prosesində edilən insan səhvlərinin və obyektdəki qüsurların müqayisəsi;
həyat dövrünün bütün mərhələlərində yoxlanış və səhvlərdən qorunma, habelə inkişafın hər bir mərhələsində qüsurların aşkar edilməsi;
nasazlıqlar və qüsurlar haqqında məlumatların lokallaşdırılması, toplanması və təhlili üçün qarşılıqlı əlaqə sisteminin və üsullarının işlənib hazırlanması üçün proqram təminatındakı qüsur və nasazlıqların müqayisəsi;
proqram təminatının sənədləşdirilməsi və sınaqdan keçirilməsi proseslərinə yanaşmaların inkişafı.

Səhv-uğursuzluq səbəbkarlığının əsas məqsədi müəyyən siniflərin səhvlərinin yoxlanılması və aşkarlanması üçün üsul və vasitələri, habelə çoxsaylı verilənlər toplusunda testin tamamlanması meyarlarını müəyyən etməkdir; proqram təminatının hazırlanması, sınaqdan keçirilməsi və texniki xidmət prosesinin təşkilinin təkmilləşdirilməsi yollarının müəyyən edilməsində.

Budur uğursuzluq növlərinin aşağıdakı təsnifatı:

sistem miqyasında proqram təminatının işləmədiyi avadanlıq;
məlumat, giriş məlumatlarında və məlumatların rabitə kanalları vasitəsilə ötürülməsində səhvlər, habelə giriş cihazlarının nasazlığı (texniki nasazlıqların nəticəsi);
erqonomik, operatorun maşınla qarşılıqlı əlaqəsi zamanı yaranan səhvlər (bu nasazlıq ikinci dərəcəli nasazlıqdır və məlumat və ya funksional nasazlıqlara səbəb ola bilər);
proqram təminatı, komponentlərdə səhvlər varsa və s.

Bəzi səhvlər tələblərin müəyyən edilməsində, dizaynında, çıxış kodunun yaradılmasında və ya sənədlərdə çatışmazlıqların nəticəsi ola bilər. Digər tərəfdən, onlar proqramın hazırlanması zamanı və ya ayrı-ayrı proqram elementlərinin interfeyslərinin işlənib hazırlanması zamanı (parametrlərin sırasının pozulması, daha az və ya daha çox parametrlər və s.) yaranır.

Səhvlərin mənbələri.Layihənin, komponentlərin, kodun və sənədlərin hazırlanması zamanı xətalar yarana bilər. Bir qayda olaraq, onlar proqram təminatının icrası və ya texniki xidməti zamanı ən gözlənilməz və fərqli nöqtələrdə aşkar edilir.

Proqramdakı bəzi səhvlər tələblərin müəyyən edilməsində, dizaynında, kodun yaradılmasında və ya sənədlərdə çatışmazlıqların nəticəsi ola bilər. Digər tərəfdən, proqramın və ya onun elementlərinin interfeyslərinin işlənməsi zamanı xətalar yaranır (məsələn, rabitə parametrlərinin təyin edilməsi qaydası pozulduqda - tələb olunandan az və ya çox və s.).

Səhvlərin səbəbi müştəri tələblərinin anlaşılmamasıdır; layihə sənədlərində tələblərin qeyri-dəqiq dəqiqləşdirilməsi və s. Bu, sifarişçinin təklif etdiyi kimi işləməyəcək bəzi sistem funksiyalarının həyata keçirilməsinə gətirib çıxarır. Bununla əlaqədar olaraq, tələblərin bəzi təfərrüatlarının dəqiqləşdirilməsi üçün sifarişçi və tərtibatçı arasında birgə müzakirə aparılır.

Sistemin inkişaf komandası həmçinin sistemin təsvirinin sintaksisini və semantikasını dəyişə bilər. Bununla belə, bəzi səhvlər aşkar edilə bilməz (məsələn, bu ifadələrin indeksləri və ya dəyişən dəyərləri səhv təyin edilmişdir).

Kateqoriyada məşhur: