TestRail - Layihə üçün fərdi parametrlər

Giriş

İşlədiyim bir çox layihələrdə insanlar TestRail-i özləri üçün fərdiləşdirmədilər və standart parametrlərlə idarə etdilər. Buna görə də, bu məqalədə işinizin səmərəliliyini artırmağa kömək edə biləcək fərdi parametrlər nümunəsini təsvir etməyə çalışacağam. Məsələn, mobil proqramların hazırlanması layihəsini götürək.

Kiçik imtina. Bu məqalə TestRail-in əsas funksionallığını (bunun üçün bir çox bələdçi var) və satış ifadələrini təsvir etmir, nə üçün testlərlə depo yaratmaq üçün bu xüsusi satıcını seçməli olduğunuzu rəngarəng şəkildə təsvir edir.

Plan-əsaslandırma (nə həyata keçiriləcək)

1. Ümumi tələblər

   1. Dava tamamilə hər kəsdən keçə bilməlidir

   2. Davalar mümkün qədər uzun müddət aktual qalmalıdır

   3. İşlər mobil tətbiqin funksionallığını mümkün qədər diqqətlə əhatə etməlidir ki, bu, ilk iki bəndlə ziddiyyət təşkil etməsin.

2. TestCase və TestScenario-ya ayırma

3. Müxtəlif növ TestRun-un sürətli formalaşması

   1. Tüstü

   2. Geri çəkilmə

   3. Təsir testi və s.

4. Case dəstəyi optimallaşdırılması

   1. "Ölü" sərt kodlu ekran görüntülərinin rədd edilməsi və "daşınan məlumatlara" keçid

Tələblər

Sahələri redaktə etmək üçün sizə administrator girişi lazımdır

Layihə növünün seçilməsi

Seçmək üçün üç layihə növü var:

Standart növü seçəcəyik. Bütün hallarda eyni vaxtda orada olacaq. Ağıllı filtrdən istifadə edəcəyik və bütün işləri eyni anda dinamik şəkildə idarə edəcəyik.

Test hallarının siyahısına baxmaq üçün sahələr əlavə edilir

Prioritet test hallarını göstərmək üçün sahə əlavə edək:

Digər sahələri də əlavə edə bilərsiniz.

Test işinin sahələrinin və teqlərinin təyin edilməsi

Parametrlər menyusunun açılması:

Bu sahələrə ehtiyacımız var:

“Xülasə” sahəsi (test işi başlığı)

Bu sahə artıq mövcuddur, biz yalnız onun istifadəsini sistemləşdiririk. Biz işləri TestCase və TestScenario-ya böləcəyik. Böyük bir iş siyahısını daha yaxşı oxumaq üçün xülasə yazmaq qaydaları ilə əvvəlcədən razılaşmaq daha yaxşıdır.

Test Ssenarisi:

Nümunə: TestScenario - Mobil Tətbiqin Əsas İstifadəsi

test işi:

Nümunə: MainScreen - Avtorizasiya bölməsi - Giriş girişi

Ümumilikdə, işin xülasəsində klassik bir anlayış görürük: “nə, harada, nə vaxt”. Biz həmçinin yüksək səviyyəli test skriptlərini və aşağı səviyyəli test işlərini avtomatlaşdırma üçün ən uyğun formada vizual olaraq ayırırıq.

"StartScreen" etiketi (TestScenario-nun başladığı ekran, həmçinin bir çox sınaq işi qonşu ekranlara toxuna bilər)

Lazım ola biləcəyi üçün: istifadəçini cari test işinin ekranına aparan işlərin mətnindən tipik addımları çıxaracağıq. (konkret test vəziyyəti yaratmaq üçün tipik addımlar) Bütün test halları üçün bütün tipik addımlar bir faylda yazılacaq. Bu barədə ayrıca ətraflı yazacam.

Yeni sahə yaradın:

Yeni sahənin komponentlərini doldurun:

Bu halda biz dəyərlər siyahısından seçim sahəsi yaradırıq. Bu sahə üçün dəyərləri daxil edin:

Qeyd edək ki, id dəyərləri birdən başlamır və ardıcıl deyil. Bu niyə edilir? Fakt budur ki, daxil edilmiş id ilə test hadisələrini qeyd etmişiksə,

və bundan sonra mövcud iki ekran arasında üçüncü ekran yaratmalıyıq,

onda biz identifikatoru yenidən yazmalı olacağıq və mövcud mətn işlərinin teqləri artıq ona əlavə olunduğu üçün onlar sadəcə silinir. Çox xoşagəlməz olacaq.

"Ekran" etiketi (TestCase-ə təsir edən ekranın adı)

Nəyə ehtiyacınız ola bilər: zərbə sınağı üçün lövbərlərdən biri. Məsələn, tərtibatçılar sərin bir yeni xüsusiyyət yaratdılar. Test etməliyik, lakin bunun üçün bu xüsusiyyətin tam olaraq nəyə təsir edə biləcəyini başa düşməliyik. Varsayılan olaraq, tətbiqin müxtəlif ekranlarının (Fəaliyyətlərin) müxtəlif siniflərə malik olması və buna görə də tətbiqin müxtəlif komponentlərini təşkil etdiyi paradiqmasından başlaya bilərik. Təbii ki, bu halda fərdi yanaşma lazımdır.

Misal: home_screen, MapScreen, PayScreen və s.

MovableData sahəsi (dəyişən test məlumatları ilə proxy verilənlər bazasına keçid)

Sonra, test vəziyyətlərində məlumatların aktuallığını qorumaq problemini həll etməyə çalışacağıq:

1. Həqiqi planlara keçidlər (bu, ölü ekran görüntüləri çəkməkdən daha yaxşıdır)

2. Test işi ekranına qədər tipik addımlar

3. SQL sorğuları

4. Xarici məlumatlara və digər məlumatlara keçidlər

Hər bir test vəziyyətində test məlumatlarını yazmaq əvəzinə, bir xarici fayl yaradacağıq və bütün test vəziyyətlərində ona keçid edəcəyik. Bu məlumatları yeniləyərkən, biz bütün test işlərindən keçmək və onları dəyişdirmək məcburiyyətində qalmayacağıq, lakin bu məlumatları yalnız bir yerdə dəyişdirmək mümkün olacaq. Hazır olmayan kimsə test işini açsa, o, test işinin gövdəsində bir fayla keçid və test məlumatları üçün ona getməyiniz lazım olduğuna dair bir işarə görəcək.

Bütün bu məlumatları layihədəki hər kəs üçün əlçatan olacaq bir xarici fayla yığacağıq. Məsələn, Google Sheet və ya Excel-dən istifadə edə və fayl daxilində axtarış qura bilərsiniz. Niyə bu xüsusi satıcılar? Fakt budur ki, biz paradiqmadan başlayırıq ki, komandadakı hər hansı bir şəxs əvvəlcə heç bir alət quraşdırmadan test işini aça və keçə bilməlidir.

Uğrunda Google Sheet SQL sorğularından istifadə etmək olar. Misal:

=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")

Uğrunda üstün olmaq Siz rahat ani axtarış makrolarını qura bilərsiniz. (filtrləmə) Misal по ссылке.

Əslində, ideya yeni deyil və testerin “Testing dot com” adlı ilk kitabında təsvir edilmişdir. (müəllif Savin Roman) Biz sadəcə Roman Savinin təklif etdiyi metodları TestRail-ə inteqrasiya edirik. Bunu etmək üçün yaradılmış fayla keçid olan bir sahə yaradın:

linkin standart dəyərini doldurun ki, hər yeni testdə artıq bir keçid olsun:

Xarici faylın yeri dəyişirsə (biz hər hansı bir fors-majoru təmin edirik), onda siz bir anda bütün test işlərində bir və ya bir neçə sahəni rahatlıqla dəyişə bilərsiniz:

"Təsvirlər" sahəsi (test işinin təsviri və ya ideyası, tipik təlimatlar)

Sizə nə lazım ola bilər: Bu mətn sahəsində biz test işinin qısa təsvirini və tipik təlimatları yerləşdirəcəyik.

Misal: Bu test işindən olan bütün test məlumatları (faktiki tərtibatlar, alətlərdən istifadə və digər məlumatlar) {...} keçidləri ilə qeyd olunur və MovableData-da yerləşir. Yuxarıdakı müvafiq sahədə MovableData ilə əlaqə saxlayın.

"Komponent" etiketi (mobil proqram komponenti)

Nə lazım ola bilər: təsir testi üçün. Əgər mobil tətbiqi komponentlərə (bir-birinə mümkün qədər az təsir edən) bölmək olarsa, onda bir komponentdə dəyişikliklər eyni komponent daxilində yoxlamaq üçün kifayət edəcək (bəzi risklərlə) və ümumi reqressiyaların aparılması üçün daha az səbəb olacaq. hər şeydən və hər şeydən. Bir komponentin digərinə təsir göstərə biləcəyi barədə məlumat varsa, təsir testi matrisi tərtib edilir.

Nümunə komponentlər: GooglePay, Sifariş, İstifadəçilər, Xəritə, Avtorizasiya və s.

"TAG" etiketi (filtrləmə üçün digər etiketlər)

Sınaq işini ixtiyari filtrləmə üçün etiketlərlə işarələmək. 

Üçün çox faydalıdır: 

1. müxtəlif tipik tapşırıqlar üçün TestRun-un sürətli tərtibi: tüstü, reqressiya və s.

2. testlər avtomatlaşdırılacaq və ya artıq avtomatlaşdırılacaq

3. hər hansı digər etiketlər

Misal: Smoke, Automated, WhiteLabel, ForDelete və s.

Test vəziyyətində sahələrin göstərilməsi qaydasının təyin edilməsi

Biz çoxlu yeni sahələr yaratdıq, onları rahat qaydada yerləşdirməyin vaxtı gəldi:

TestRun yaradılması

İndi biz üç kliklə tüstü sınağı üçün müvafiq hallarla yeni sınaq proqramı yaradacağıq:

Digər faydalı məsləhətlər

1. TestRail-də bir neçə layihə varsa, o zaman yalnız layihəniz üçün yeni sahələr yaratmağı unutmayın, əks halda qonşu komandalardan olan həmkarlar yeni qeyri-adi sahələrin yaranmasına çox təəccüblənəcəklər. Yerli huşunu itirmə mümkündür.

2. Çox sayda sahəyə malik olan halları oxşar tip qrupundan köçürmək yenilərini yaratmaqdan daha asandır:

3. Hesablar paylaşıla bilər. Məsələn: bir idarəçi, bir neçə istifadəçi.

Nəticə

Yuxarıdakı nümunələr bir neçə layihə üzrə həyata keçirilib və öz effektivliyini göstərib. Ümid edirəm ki, onlar bu alət haqqında anlayışınızı yaxşılaşdırmağa kömək edəcək və səmərəli və rahat “xəmir anbarı” yaratmağa kömək edəcəklər. Şərhlərdə TestRail-dən istifadə təcrübənizi və faydalı məsləhətləri təsvir etsəniz, çox minnətdar olaram.

Referanslar:

TestRail satıcı saytı

Kitab: "Testing .COM" (müəllif Roman Savin)

Diqqətiniz üçün təşəkkürlər!

Mənbə: www.habr.com