Verilənlər bazası testi. Verilənlər bazası yük testi. Datasets və Data Cədvəllərini başa düşmək

: Verilənlər bazalarını necə sınamaq və sazlamaq olar

Tətbiq kodunun avtomatik vahid testi sadə və sadədir. Verilənlər bazasını necə sınamaq olar? Və ya verilənlər bazası ilə işləyən proqram. Axı verilənlər bazası sadəcə proqram kodu deyil, verilənlər bazası öz vəziyyətini saxlayan obyektdir. Və əgər test zamanı verilənlər bazasındakı məlumatları dəyişməyə başlasaq (və bunsuz bizdə hansı test olacaq?!), onda hər sınaqdan sonra verilənlər bazası dəyişəcək. Bu, sonrakı testlərə müdaxilə edə və verilənlər bazasını həmişəlik korlaya bilər.

Problemi həll etməyin açarı əməliyyatlardır. Bu mexanizmin xüsusiyyətlərindən biri odur ki, əməliyyat tamamlanmadığı müddətcə siz həmişə bütün dəyişiklikləri geri ala və verilənlər bazasını əməliyyatın başlandığı vaxt vəziyyətinə qaytara bilərsiniz.

Alqoritm belədir:

əməliyyat açmaq;
lazım gələrsə, sınaq üçün hazırlıq addımlarını həyata keçiririk;
vahid testini həyata keçirin (və ya sadəcə olaraq əməliyyatını yoxlamaq istədiyimiz skripti işə salın);
skriptin nəticəsini yoxlamaq;
Biz verilənlər bazasını orijinal vəziyyətinə qaytararaq əməliyyatı ləğv edirik.

Test edilən kodda bağlanmamış əməliyyatlar olsa belə, xarici ROLLBACK yenə də bütün dəyişiklikləri düzgün şəkildə geri qaytaracaq.

Yaxşı olar ki, SQL skriptini və ya saxlanılan proseduru sınaqdan keçirək. Özü verilənlər bazasına qoşulan, yeni bir əlaqə açan bir tətbiqi sınaqdan keçirsək necə olar? Bundan əlavə, əgər biz sazlama işləri aparırıqsa, onda yəqin ki, verilənlər bazasına sazlanan tətbiqin gözü ilə baxmaq istəyəcəyik. Bu halda nə etməli?

Paylanmış əməliyyatlar yaratmağa tələsməyin, daha sadə həll yolu var! Standart SQL server alətlərindən istifadə edərək, bir əlaqədə əməliyyat aça və digərində davam etdirə bilərsiniz.

Bunun üçün siz serverə qoşulmalı, əməliyyat açmalı, həmin tranzaksiya üçün token əldə etməli və sonra bu tokeni sınaqdan keçirilən proqrama ötürməlisiniz. O, öz sessiyasında bizim əməliyyatımıza qoşulacaq və o andan etibarən sazlama sessiyamızda biz məlumatları tam olaraq sınaqdan keçirilən tətbiqin gördüyü kimi görəcəyik (həmçinin kilidləri hiss edəcəyik).

Hərəkətlərin ardıcıllığı aşağıdakı kimidir:

Sazlama sessiyasında əməliyyata başladıqdan sonra onun identifikatorunu tapmalıyıq. Bu, serverin əməliyyatları fərqləndirdiyi unikal sətirdir. Bu identifikator hansısa şəkildə sınaqdan keçirilən tətbiqə ötürülməlidir.

İndi tətbiqin vəzifəsi, etməli olduğu şeyi etməyə başlamazdan əvvəl nəzarət əməliyyatımızı bağlamaqdır.

Sonra proqram işləməyə başlayır, o cümlədən saxlanmış prosedurları yerinə yetirmək, əməliyyatlarını açmaq, izolyasiya rejimini dəyişdirmək... Amma bizim sazlama sessiyamız bütün bu müddət ərzində proqramla eyni əməliyyatın içərisində olacaq.

Tutaq ki, proqram cədvəli kilidləyir və onun məzmununu dəyişməyə başlayır. Bu anda heç bir başqa əlaqə kilidlənmiş masaya baxa bilməz. Ancaq sazlama sessiyamız deyil! Oradan verilənlər bazasına tətbiqin etdiyi kimi baxa bilərik, çünki SQL server bizim eyni əməliyyatda olduğumuza inanır.

Bütün digər seanslar üçün tətbiqin hərəkətləri kilidlər tərəfindən gizlədilir...

Sazlama sessiyamız kilidlərdən keçir (server onların öz kilidlərimiz olduğunu düşünür)!

Və ya təsəvvür edin ki, proqram SNAPSHOT rejimində öz simli versiyaları ilə işləməyə başlayır. Bu versiyalara necə baxa bilərəm? Ümumi bir əməliyyatla bağlı olsanız belə bu mümkündür!

Bu maraqlı prosesin sonunda nəzarət əməliyyatını geri qaytarmağı unutmayın. Bu, həm sazlama sessiyasından (sınaq prosesi normal başa çatarsa), həm də tətbiqin özündən (onda gözlənilməz bir şey olarsa) edilə bilər.

Bu barədə daha çox kurslarda öyrənə bilərsiniz

Bir neçə il əvvəl SQL-in birdən köhnəldiyi məlum oldu. Və NoSQL həlləri SQL dilini və relational məlumat saxlama modelini ataraq görünməyə və çoxalmağa başladı. Bu yanaşmanı dəstəkləyən əsas arqumentlər: böyük verilənlərlə işləmək bacarığı (eyni Big Data), məlumatların ən ekzotik strukturlarda saxlanması və ən əsası bütün bunları çox tez etmək bacarığı. NoSQL dünyasının ən məşhur nümayəndələrinin bunu necə etdiyini görək.

NoSQL-də sürət necə əldə edilir? Əvvəla, bu, tamamilə fərqli bir məlumat saxlama paradiqmasının nəticəsidir. SQL sorğularının təhlili və tərcüməsi, optimallaşdırıcının işi, cədvəllərin birləşdirilməsi və s. cavab müddətini xeyli artırır. Bütün bu təbəqələri çıxarsanız, sorğuları sadələşdirsəniz, diskdən birbaşa şəbəkəyə oxusanız və ya bütün məlumatları RAM-da saxlasanız, sürət qazana bilərsiniz. Həm hər sorğunun emal müddəti, həm də saniyədə sorğuların sayı azalır. Açar-dəyər verilənlər bazası belə ortaya çıxdı, ən tipik və geniş tanınan nümayəndəsi memcacheddir. Bəli, verilənlərə çıxışı sürətləndirmək üçün veb proqramlarda geniş istifadə olunan bu keş də NoSQL-dir.

NoSQL növləri

NoSQL sistemlərinin dörd əsas kateqoriyası var:

Açar - dəyər (açar-dəyər). Yalnız açarla verilənlər üzərində yazı və oxu əməliyyatlarına icazə verilən böyük hash cədvəli.
Sütun. Satır və sütunlu cədvəllər. Lakin SQL-dən fərqli olaraq, sətirdən sətrə sütunların sayı dəyişə bilər və sütunların ümumi sayı milyardlarla ölçülə bilər. Həmçinin hər sətirin özünəməxsus açarı var. Bu məlumat strukturunu hash cədvəlinin hash cədvəli kimi düşünə bilərsiniz, birinci açar sıra açarı, ikincisi isə sütun adıdır. İkinci dərəcəli indekslərin dəstəyi ilə seçimlər yalnız sətir düyməsi ilə deyil, sütundakı dəyərlə mümkündür.
Sənəd yönümlü. Strukturlaşdırılmış sənədlər topluları. Sənədin müxtəlif sahələrinə görə seçmək, həmçinin sənədin hissələrini dəyişdirmək mümkündür. Bu kateqoriyaya indekslər olan axtarış motorları da daxildir, lakin, bir qayda olaraq, sənədləri özləri saxlamırlar.
Qrafik. Riyazi qrafiklərin saxlanması üçün xüsusi olaraq hazırlanmışdır: qovşaqlar və onlar arasındakı əlaqələr. Bir qayda olaraq, onlar həmçinin qovşaqlar və keçidlər üçün ixtiyari atributlar toplusunu təyin etməyə və bu atributlar əsasında qovşaqları və keçidləri seçməyə imkan verir. Qrafiklərin keçməsi və marşrutların qurulması üçün alqoritmləri dəstəkləyir.

Test üçün ilk üç kateqoriyanın nümayəndələrini götürdük:

Test necə aparıldı

Bizim ixtiyarımızda dörd server maşını var idi. Hər birində səkkiz nüvəli Xeon, 32 GB RAM, hər biri 120 GB olan dörd Intel SSD var.

YCSB (Yahoo! Cloud Service Benchmark) istifadə edərək sınaqdan keçirdik. Bu, Yahoo! 2010-cu ildə Apache lisenziyası altında tədqiqat. Benchmark xüsusi olaraq NoSQL verilənlər bazalarını sınaqdan keçirmək üçün yaradılmışdır. İndi o, NoSQL üçün yeganə və kifayət qədər populyar meyar olaraq qalır, əslində standartdır. Yeri gəlmişkən, Java dilində yazılmışdır. Orijinal YCSB-yə Aerospike üçün bir sürücü əlavə etdik, MongoDB üçün sürücünü bir az yenilədik və nəticələrin çıxışı ilə bir az hiylə oynadıq.

MƏLUMAT

YCSB ilə yanaşı, siz, məsələn, JMeter istifadə edərək, NoSQL verilənlər bazasının işini yoxlaya bilərsiniz.

Kiçik klasterimizdə yük yaratmaq üçün səkkiz müştəri maşını lazım idi. Dörd nüvəli i5 və hər biri 4 GB RAM. Klasteri yükləmək üçün bir (yaxud iki, üç və ya dörd...) müştəri kifayət etmədi. Qəribə görünə bilər, amma həqiqətdir.

Bütün bunlar bir gigabitdə hərəkət etdi yerli şəbəkə. Ola bilsin ki, on gigabitlik şəbəkədə daha maraqlı olardı, amma bizdə belə avadanlıq yox idi. Bu daha maraqlıdır, çünki saniyədə əməliyyatların sayı yüz minlərlə ölçülməyə başlayanda biz şəbəkəyə daxil oluruq. Saniyədə gigabit (10^9 bit/s) ötürmə qabiliyyəti ilə şəbəkə yalnız təxminən 100.000 (10^5) kilobayt paket (~10^4 bit) ötürə bilər. Yəni saniyədə cəmi 100k əməliyyat alırıq. Amma əslində milyon almaq istəyirdik :).

Şəbəkə kartları da vacibdir. Düzgün server şəbəkə kartlarında müvafiq olaraq bir neçə giriş/çıxış kanalı var, onların hər birinin öz fasiləsi var. Ancaq Linux-da standart olaraq, bütün bu fasilələr bir prosessor nüvəsinə təyin edilir. Yalnız Aerospike-dən olan uşaqlar bu incəliyə diqqət yetirdilər və onların verilənlər bazası konfiqurasiya skriptləri şəbəkə kartı fasilələrini prosessor nüvələrinə səpələyir. Siz şəbəkə kartı kəsmələrini və onların prosessor nüvələri arasında necə paylandığını, məsələn, aşağıdakı əmrlə görə bilərsiniz: “cat /proc/interrupts | grep eth".

SSD-lər haqqında da danışmalıyıq. Bu sürücülərin həqiqətən buna dəyər olub olmadığını, yəni yaxşı performans təmin edib-etmədiyini anlamaq üçün NoSQL verilənlər bazalarının işini xüsusi olaraq bərk vəziyyətdə olan disklərdə yoxlamaq istədik. Buna görə də SSD-ni düzgün konfiqurasiya etməyə çalışdıq. Bu barədə daha çox yan paneldə oxuya bilərsiniz.

SSD-nin qurulması

Xüsusilə, SSD-lər həddindən artıq təminat adlanan hərəkətləri tələb edir. Fakt budur ki, SSD-də ünvan tərcüməsi təbəqəsi var. Əməliyyat sisteminə görünən blok ünvanları fləş yaddaşdakı fiziki bloklara heç uyğun gəlmir. Bildiyiniz kimi, fləş yaddaş məhdud sayda təkrar yazma dövrünə malikdir. Bundan əlavə, yazma əməliyyatı iki mərhələdən ibarətdir: silmə (çox vaxt eyni anda bir neçə blok) və yazmanın özü. Buna görə də, sürücünün uzunömürlülüyünü (hətta köhnəlməsini) və yaxşı yazma sürətini təmin etmək üçün disk nəzarətçisi yazarkən fiziki yaddaş bloklarını növbələşdirir. Əməliyyat sistemi müəyyən bir ünvana blok yazdıqda, yazma fiziki olaraq bəzi təmiz boş yaddaş blokunda baş verir və köhnə blok sonrakı (fon) silmək üçün əlçatan kimi qeyd olunur. Bütün bu manipulyasiyalar üçün disk nəzarətçisinə pulsuz bloklar lazımdır, nə qədər çox olsa, bir o qədər yaxşıdır. 100% dolu bir SSD olduqca yavaş ola bilər.

Pulsuz bloklar bir neçə yolla əldə edilə bilər. Siz görünən disk sektorlarının sayını təyin etmək üçün hdparm əmrindən (“-N” açarı ilə) istifadə edə bilərsiniz. əməliyyat sistemi. Qalanları tam nəzarətçinin ixtiyarında olacaq. Bununla belə, bu, hər bir aparatda işləmir (məsələn, AWS EC2-də işləmir). Başqa bir yol, bölmələr tərəfindən tutulmayan disk yerini tərk etməkdir (məsələn, fdisk tərəfindən yaradılmış bölmələr deməkdir). Nəzarətçi bu yerdən istifadə etmək üçün kifayət qədər ağıllıdır. Üçüncü yol, nəzarətçiyə pulsuz bloklar haqqında məlumat verə bilən fayl sistemlərindən və nüvə versiyalarından istifadə etməkdir. Bu eyni TRIM əmridir. Aparatımızda kifayət qədər hdparm var idi, ümumi disk həcminin 20% -ni parçalanmaq üçün nəzarətçiyə verdik.

I/O planlayıcısı SSD-lər üçün də vacibdir. Bu, səmərəliliyi artırmaq üçün I/O əməliyyatlarını (əsasən disk yazmalarını) qruplaşdıran və yenidən sıralayan nüvə alt sistemidir. Varsayılan olaraq, Linux ardıcıl olaraq mümkün qədər çox blok yazmaq üçün yazıları yenidən təşkil etməyə çalışan CFQ (Tamamilə Ədalətli Növbə) istifadə edir. Bu, adi spinning (belə deyirlər - spinning :)) diskləri üçün yaxşıdır, çünki onlar üçün xətti giriş sürəti təsadüfi bloklara daxil olmaqdan nəzərəçarpacaq dərəcədə yüksəkdir (başları köçürmək lazımdır). Lakin SSD-lər üçün xətti və təsadüfi yazı eyni dərəcədə effektivdir (nəzəri cəhətdən) və CFQ əməliyyatı yalnız lazımsız gecikmələr təqdim edir. Buna görə də, SSD diskləri üçün giriş/çıxış əmrlərini onların gəldiyi ardıcıllıqla yerinə yetirən NOOP kimi digər planlaşdırıcıları işə salmalısınız. Planlayıcını, məsələn, aşağıdakı əmrlə dəyişə bilərsiniz: "echo noop > /sys/block/sda/queue/scheduler", burada sda sizin diskinizdir. Ədalətli olmaq üçün qeyd etmək lazımdır ki, ən son nüvələr özləri SSD sürücülərini aşkar edə və onlar üçün düzgün planlaşdırıcını işə sala bilər.

İstənilən DBMS diskə intensiv yazmağı, həmçinin intensiv oxumağı xoşlayır. Linux, həqiqətən də, bu bloku oxuduqdan sonra növbəti bir neçəsini oxumaq istəyəcəyinizə ümid edərək, məlumatların qabaqcadan oxunmasını, aktiv oxunmasını sevir. Bununla belə, bir DBMS ilə və xüsusən də təsadüfi oxumaqla (və bu bizim seçimimizdir), bu ümidlər gerçəkləşmir. Nəticədə lazımsız oxuma və yaddaş istifadəmiz olur. MongoDB tərtibatçıları mümkünsə qabaqcadan oxunma dəyərini azaltmağı tövsiyə edir. Bunu “blockdev --setra 8 /dev/sda” əmri ilə edə bilərsiniz, burada sda sizin diskinizdir.

İstənilən DBMS çoxlu sayda fayl açmağı xoşlayır. Buna görə də, /etc/security/limits.conf faylında nofile limitlərini (istifadəçi üçün mövcud fayl deskriptorlarının sayı) 4k-dan xeyli yuxarı olan dəyərə qədər əhəmiyyətli dərəcədə artırmaq lazımdır.

Həm də qalxdı maraq Soruş: Dörd SSD-dən necə istifadə etmək olar? Əgər Aerospike onları sadəcə yaddaş kimi birləşdirirsə və hər hansı bir şəkildə müstəqil olaraq disklərə alternativ çıxış imkanı verirsə, onda digər verilənlər bazaları məlumatların yalnız bir qovluğuna malik olduqlarını göstərir. (Bəzi hallarda siz bir neçə kataloq təyin edə bilərsiniz, lakin bu, onların arasında məlumatların kəsilməsini nəzərdə tutmur.) Mən mdadm yardım proqramından istifadə edərək RAID 0 (zolaqlı) yaratmalı oldum. Güman edirəm ki, biri LVM ilə oynaya bilər, lakin verilənlər bazası satıcıları yalnız mdadm istifadə edərək təsvir edirlər.

Təbii ki, klasterdəki bütün maşınlarda (həm server, həm də müştəri) saatlar ntpd istifadə edərək sinxronlaşdırılmalıdır. Ntpdate burada uyğun deyil, çünki daha böyük sinxronizasiya dəqiqliyi tələb olunur. Bütün paylanmış sistemlər üçün qovşaqlar arasında vaxtın sinxronlaşdırılması çox vacibdir. Məsələn, Cassandra və Aerospike rekordun dəyişdirilmə vaxtını saxlayır. Əgər klasterin müxtəlif qovşaqlarında müxtəlif vaxt damğaları olan qeydlər varsa, ən yeni rekord qalib gələcək.

NoSQL verilənlər bazalarının özləri aşağıdakı kimi konfiqurasiya edilmişdir. Konfiqurasiya qutudan çıxarıldı və ən yaxşı performansa nail olmaq üçün sənədlərdə təsvir olunan bütün tövsiyələr tətbiq edildi. Çətin hallarda verilənlər bazası tərtibatçıları ilə əlaqə saxladıq. Çox vaxt tövsiyələr nüvələrin sayına və RAM miqdarına düzəlişlər ilə bağlıdır.

Quraşdırmağın ən asan yolu Couchbase-dir. Veb konsolu var. Klasterin bütün qovşaqlarında xidmətə başlamaq kifayətdir. Sonra qovşaqlardan birində vedrə yaradın (açar-dəyərlər üçün "səbət") və klasterə digər qovşaqları əlavə edin. Hər şey veb interfeys vasitəsilə edilir. Xüsusilə çətin parametrləri yoxdur.

Aerospike və Cassandra təxminən eyni şəkildə konfiqurasiya edilmişdir. Hər bir klaster qovşağında konfiqurasiya faylı yaratmalısınız. Bu fayllar hər bir node üçün demək olar ki, eynidir. Sonra şeytanları işə salın. Hər şey qaydasındadırsa, qovşaqlar bir çoxluqda birləşəcəklər. Konfiqurasiya faylı seçimlərini kifayət qədər yaxşı başa düşməlisiniz. Burada yaxşı sənədləşmə çox vacibdir.

Ən çətin şey MongoDB ilədir. Digər verilənlər bazalarında bütün qovşaqlar bərabərdir. Monqoda belə deyil. Mümkünsə, bütün verilənlər bazalarını eyni şəraitdə yerləşdirmək və hamı üçün təkrarlanma əmsalını 2-yə təyin etmək istədik. Bu o deməkdir ki, etibarlılıq və sürət üçün klasterdə verilənlərin iki nüsxəsi olmalıdır. Digər verilənlər bazalarında replikasiya faktoru sadəcə məlumat anbarının (və ya “səbət” və ya “sütun ailəsi”) qurulmasıdır. MongoDB-də məlumatların nüsxələrinin sayı klaster strukturu ilə müəyyən edilir. MongoDB klasterini yalnız ona həsr olunmuş rəsmi sənədləri iki dəfə oxumaqla düzgün konfiqurasiya edə bilərsiniz :). Bir sözlə, bizə qırıntılar və ya replika dəstləri lazımdır. Parçalar (yaxşı, yəqin ki, "parçalama" terminini eşitmisiniz) bütün məlumat dəstinin alt çoxluqları, eləcə də hər bir alt çoxluğun saxlanacağı klaster qovşaqlarıdır. Replika Dəstləri verilənlərin eyni nüsxələrini saxlayan çoxluq qovşaqları dəsti üçün MongoDB terminidir. Replika şəbəkəsində yazma əməliyyatlarını yerinə yetirən master node və master node məlumatlarının təkrarlandığı ikinci dərəcəli qovşaqlar var. Uğursuzluqlar halında, master node rolu replika dəstinin başqa qovşağına keçirilə bilər. Bizim vəziyyətimiz üçün (dörd server və məlumatın iki nüsxəsini saxlamaq istəyi) məlum olur ki, bizə iki parça lazımdır, onların hər biri məlumatları olan iki serverin replika dəstidir. Bundan əlavə, hər bir replika dəstinə sözdə arbitr əlavə edilməlidir ki, bu da məlumatları saxlamır, lakin yeni master node seçimində iştirak etmək üçün lazımdır. üçün replika şəbəkəsində qovşaqların sayı düzgün seçkilər qəribə olmalıdır. Siz həmçinin kiçik bir konfiqurasiya verilənlər bazasına ehtiyacınız var, o, qırıqlar haqqında məlumatı saxlayacaq və hansı məlumat diapazonunun hansı parçada saxlandığını saxlayacaq. Texniki olaraq, bu da MongoDB-dir, lakin (əsas məlumatlarla müqayisədə) çox kiçikdir. Arbitrləri və konfiqurasiya verilənlər bazasını müştəri maşınlarına yerləşdirdik. Və hər bir müştəridə konfiqurasiya verilənlər bazasına və hər bir müştəridən fraqmentlər arasında marşrut sorğularına daxil olacaq mongos demonunu (mongo keçidi) işə salmalısınız.

Hər bir NoSQL verilənlər bazası məlumatların təqdim edilməsinin özünəməxsus üsuluna və üzərində etibarlı əməliyyatlara malikdir. Buna görə də YCSB istənilən verilənlər bazasının (o cümlədən SQL) maksimum ümumiləşdirilməsi yolunu tutmuşdur.

YCSB-nin işlədiyi məlumat dəsti açar və dəyərdir. Açar 64 bitlik hash ehtiva edən sətirdir. Beləliklə, YCSB özü verilənlər bazasındakı qeydlərin ümumi sayını bilərək, onlara tam indeksdən istifadə edərək daxil olur və verilənlər bazası üçün açarlar dəsti tamamilə təsadüfi görünür. Dəyər təsadüfi ikili məlumatların onlarla sahəsidir. Varsayılan olaraq, YCSB kilobayt ölçülü qeydlər yaradır, lakin xatırladığınız kimi, gigabit şəbəkəsində bu, bizi saniyədə yalnız 100k əməliyyatla məhdudlaşdırır. Buna görə də, testlərdə bir qeydin ölçüsünü 100 bayta qədər azaltdıq.

YCSB bu verilənlər üzərində çox sadə əməliyyatlar həyata keçirir: daxiletmə yeni giriş açar və təsadüfi məlumatla, açarla qeydi oxumaq, açarla qeydi yeniləmək. Heç bir cədvəl birləşdirilmir (və əslində yalnız bir “masa” nəzərdə tutulur). İkinci dərəcəli düymələrdə seçim yoxdur. Şərtə görə çoxlu seçim yoxdur (yalnız yoxlama əsas açarın uyğun olub-olmamasıdır). Bu çox primitivdir, lakin istənilən verilənlər bazasında edilə bilər.

Testdən dərhal əvvəl verilənlər bazası məlumatlarla doldurulmalıdır. Bunu YCSB özü edir. Əslində, bu, yalnız daxiletmə əməliyyatlarından ibarət bir yükdür. İki məlumat dəsti ilə təcrübə etdik. Birincisi, klaster qovşaqlarının RAM-a, 50 milyon qeydə, təxminən 5 GB təmiz məlumatlara uyğun olacağına zəmanət verilir. İkincisi RAM-a, 500 milyon qeydə, təxminən 50 GB təmiz məlumata sığmayacağına zəmanət verilir.

Testin özü - müəyyən bir əməliyyat dəstinin yerinə yetirilməsi - yük altında həyata keçirilir fərqli növlər. Əhəmiyyətli bir parametr əməliyyatların nisbətidir - nə qədər oxunuş olmalıdır və nə qədər yeniləmə. Biz iki növdən istifadə etdik: ağır yazma (Ağır yazma, 50% oxuma və 50% yeniləmə) və əsasən oxuma (Əsasən oxuma, 95% oxuma və 5% yeniləmə). Hansı əməliyyatın yerinə yetiriləcəyi hər dəfə təsadüfi seçilir, faizlər əməliyyatın seçilmə ehtimalını müəyyən edir.

YCSB əməliyyatı yerinə yetirmək üçün müxtəlif qeyd (açar) seçim alqoritmlərindən istifadə edə bilər. Bu, vahid paylama (bütün məlumat dəstindən istənilən açar eyni ehtimalla seçilə bilər), eksponensial paylama (məlumat dəstinin "əvvəlində" düymələr daha tez-tez seçiləcək) və digərləri ola bilər. Lakin Yahoo komandası tipik bir paylama olaraq zipfian adlananı seçdi. Bu vahid paylamadır ki, bununla belə müəyyən açarlar (açarların ümumi sayının kiçik bir faizi) digərlərindən əhəmiyyətli dərəcədə daha tez seçilir. Bu, məsələn, bloglardakı populyar yazıları simulyasiya edir.

YCSB çoxlu iplərlə başlayır, onların hər birində bir döngə işlədir, hamısı eyni maşında. Bir müştəri maşınında yalnız dörd nüvə ilə, orada dörddən çox mövzu işlətməyə çalışmaq olduqca əsəbidir. Buna görə də YCSB-ni eyni vaxtda səkkiz müştəri maşınında işlətdik. Başlamağı avtomatlaşdırmaq üçün biz parça və crondan (daha doğrusu, at) istifadə etdik. Kiçik bir Python skripti hər bir müştəridə YCSB-ni işə salmaq üçün lazım olan əmrləri yaradır, bu əmrlər hər bir müştəridə gələcəkdə ən yaxın dəqiqə üçün eyni vaxtda növbəyə qoyulur. Sonra at işə salınır və YCSB eyni vaxtda bütün səkkiz müştəridə uğurla işə salınır (və ya parametrlər səhvdirsə, o qədər də yaxşı deyil). Nəticələri toplamaq üçün (YCSB log faylları) parça yenidən istifadə olunur.

nəticələr

Beləliklə, ilkin nəticələr hər bir müştərinin YCSB qeydləridir. Bu qeydlər belə görünür (faylın son hissəsi göstərilir):

Əməliyyatlar, 1187363 , Yenidən Sınaqlar, 0 , AverageLatency(biz), 3876.5493619053314 , MinLatency(biz), 162 , MaxLatency(biz), 278190 , 95thPercentileLatency(ms), 92PercentileLatency(ms), 12Percentile 118 7363, Yenidən qoşulmalar , 0.0 , RunTime(ms), 303574.0 , Əməliyyatlar, 1249984.0 , Ötürmə qabiliyyəti (ops/san), 4117.5594747903315

Gördüyünüz kimi, müəyyən bir növdə bir sıra əməliyyatlar var (in bu misalda- oxuyur), orta, minimum və maksimum gecikmələr, əməliyyatların 95 və 99% -nin yerinə yetirildiyi gecikmə, uğurlu əməliyyatların sayı (qaytarma kodu 0), ümumi sınaq müddəti, bütün əməliyyatların ümumi sayı və orta sayı saniyədə əməliyyatlar. Bizi daha çox orta gecikmə (AverageLatency) və saniyədə əməliyyatların sayı (Throughput) maraqlandırır.

Başqa bir Python skriptindən istifadə edərək, bir dəstə jurnaldan məlumatlar cədvəldə toplandı və cədvəldən gözəl qrafiklər quruldu.

nəticələr

NoSQL verilənlər bazası iki qrupa bölünür: sürətli və yavaş. Açar-dəyər verilənlər bazası gözlənildiyi kimi sürətli oldu. Aerospike və Couchbase rəqabətdən xeyli irəlidədir.

Aerospike həqiqətən çox sürətli verilənlər bazasıdır. Və demək olar ki, saniyədə bir milyon əməliyyata çata bildik (yaddaşdakı məlumatlar üzrə). Aerospike SSD-lərdə də kifayət qədər yaxşı işləyir, xüsusən nəzərə alsaq ki, bu rejimdə Aerospike yaddaşda məlumatların keşini istifadə etmir, lakin hər sorğu üçün diskə daxil olur. Bu o deməkdir ki, siz həqiqətən də böyük miqdarda məlumatı Aerospike-ə yerləşdirə bilərsiniz (RAM deyil, kifayət qədər disklər olduqda).

Couchbase sürətlidir, lakin yalnız yaddaş əməliyyatlarında sürətlidir. SSD test qrafikləri Couchbase-in sürətini RAM miqdarından bir qədər böyük məlumat həcmi ilə göstərir - cəmi 200 milyon qeyd. Bu, digər verilənlər bazalarının sınaqdan keçirildiyi 500 milyondan nəzərəçarpacaq dərəcədə azdır. Couchbase sadəcə daha çox qeyd daxil edə bilmədi, məlumat keşini yaddaşdan diskə çıxarmaqdan imtina etdi və yazmağı dayandırdı (yazmalar uğursuz olardı). Bu, yaxşı bir keşdir, lakin yalnız RAM-a uyğun olan məlumatlar üçün.

Cassandra oxuduğundan daha sürətli yazan yeganə verilənlər bazasıdır :). Bunun səbəbi ona yazmaq jurnala (diskdə) yazdıqdan dərhal sonra uğurla (ən sürətli versiyada) tamamlanır. Ancaq oxumaq üçün yoxlamalar, diskdən bir neçə oxunuş, ən son qeydin seçilməsi tələb olunur. Cassandra etibarlı və kifayət qədər sürətli genişlənə bilən məlumat arxividir.

MongoDB yazmaq üçün olduqca yavaş, lakin oxumaq üçün nisbətən sürətlidir. Əgər verilənlər (daha doğrusu, işləyən dəst adlanırsa - daim daxil olan cari verilənlər toplusu) yaddaşa sığmırsa, o, çox yavaşlayır (və YCSB sınaqdan keçirərkən məhz belə olur). MongoDB-nin çox yüksək yüklər altında problemlər yarada bilən qlobal oxuma/yazma kilidi olduğunu da xatırlamaq lazımdır. Ümumiyyətlə, MongoDB internet üçün yaxşı verilənlər bazasıdır.

PS

Performans problemlərinə bir az ara verək və SQL və NoSQL həllərinin daha da necə inkişaf edəcəyinə baxaq. Əslində indi gördüyümüz məlum hekayənin təkrarıdır. Bütün bunlar artıq iyirminci əsrin altmışıncı və yetmişinci illərində baş verib: relyasiya verilənlər bazalarından əvvəl iyerarxik, obyekt və digərləri və başqaları var idi. Sonra standartlaşdırma istədim və SQL ortaya çıxdı. Və hər biri öz sorğu dilini və API-ni dəstəkləyən bütün ciddi DBMS-lər SQL-ə keçdi. Sorğu dili və əlaqə modeli standart oldu. Maraqlıdır ki, indi onlar SQL-i NoSQL-ə köçürməyə çalışırlar ki, bu da mövcud NoSQL-in üstündə həm sarğıların, həm də NewSQL adlı tamamilə yeni verilənlər bazalarının yaradılmasına gətirib çıxarır.

Əgər NoSQL SQL-in “ağır mirası”ndan imtina etmək qərarına gəlsə, məlumatların saxlanmasına yanaşmaları yenidən nəzərdən keçirsə və tamamilə yeni həllər yaratdısa, o zaman NewSQL termini SQL-i “canlandırmaq” hərəkətini təsvir etmək üçün istifadə olunur. NoSQL-dən ideyalar götürən uşaqlar SQL verilənlər bazalarını yeni səviyyədə yenidən yaratdılar. Məsələn, NewSQL dünyasında siz tez-tez məlumatları yaddaşda saxlayan, lakin tam hüquqlu SQL sorğuları, cədvəl birləşmələri və digər tanış olan verilənlər bazası tapırsınız. Bir çox məlumatı hələ də saxlamaq üçün bu verilənlər bazalarına parçalanma mexanizmləri quraşdırılmışdır.

NewSQL-ə VoltDB, TokuDB, MemDB və başqaları daxildir. Bu adları xatırlayın, bəlkə də tezliklə hər İT konfransında onlar haqqında danışılacaq.

Verilənlər bazasının sınaq xidməti sistemi kommersiya istismarına təqdim edərkən riskləri minimuma endirməyə kömək edəcək. Siz verilənlər bazasının düzgünlüyünü və təhlükəsizliyini əvvəlcədən yoxlaya biləcəksiniz.
Verilənlər bazasının sınaqdan keçirilməsi prosesi zamanı proqramlar bazasının fəaliyyətinin funksional və qeyri-funksional tələblərə uyğunluğu yoxlanılır. Arxitekturasına verilənlər bazası daxil edən proqramlar verilənlər bazası test prosedurunu tələb edir, məsələn: korporativ İnformasiya sistemləri, mobil və veb proqramlar.

Verilənlər bazasının performansı idarəetmə və biznes tətbiqlərinin effektivliyində mühüm amildir. Məlumatların axtarışı və ya yazılması yavaşdırsa, proqramın normal işləmə qabiliyyəti azalır. Zəif performansın səbəbini tapmaq üçün yeganə yol kəmiyyət ölçmələri aparmaq və performans probleminə nəyin səbəb olduğunu müəyyən etməkdir.
Verilənlər bazasında performans darboğazlarının müəyyən edilməsi problemləri bilavasitə metrikalar, performans ölçmə metodları və onların həyata keçirilməsi texnologiyası ilə bağlıdır. İri korporasiyalar və böyük verilənlər bazaları üçün verilənlər bazası performansının müəyyən edilməsi probleminin daha bir çox vacib aspekti var: proqramların uzunmüddətli sənaye istismarı üçün İT infrastrukturunun müəyyən edilməsi. Bu, son nəticədə aparat və əsas proqram təminatına ilkin investisiyanın daha dəqiq müəyyən edilməsinə gətirib çıxarır. Verilənlər bazasının yüksək performansı platformadan və avadanlıqdan çox asılı olduğundan və onlar uzun müddət alınaraq istismar edilir.
Verilənlər bazası performansını ölçmək üçün ən vacib ölçülər bunlardır:

dövr üzrə əməliyyatların sayı ( müxtəlif növlərəməliyyatlar);
hər əməliyyat üzrə daxil/çıxış əməliyyatlarının (oxu sətirlərinin) sayı və onun icra müddəti;
hər əməliyyat üzrə cədvəl üzrə oxunan sətirlərin sayı;
diapazon üzrə hər tranzaksiya üzrə I/O əməliyyatlarının orta sayı;
SQL ifadələri CPU vaxtının (istifadəçi, sistem) yüksək əməliyyat xərclərinə malikdir.
bəyanatın icrasının başlanğıc və bitmə vaxtları
çeşidləmə əməliyyatlarını tamamlamaq üçün vaxt (çeşidlərin sayı, çeşidləmələrin sayı, çeşidlərin tamamlanması üçün vaxt), ən yüksək keçən vaxt istifadəsi və ən aşağı indeksdən istifadə səmərəliliyi.

Cədvəl məkanı səhifələri və bufer hovuzları üçün (məlumatların oxunması, indekslərin oxunması üçün), çeşidləmələrin yerinə yetirilməsi, kommunal proqramların işə salınması, kataloqlar və keş yaddaş paketləri üçün performans ölçmə göstəriciləri ilə yanaşı, məlumatlara səmərəli girişi sazlamaq üçün yaddaşdan istifadə göstəriciləri də vacibdir.

Verilənlər bazasını sınaqdan keçirərkən başqa nələri yoxlamaq lazımdır?

Məlumat xəritələşdirilməsi

Verilənlər bazasındakı əlaqələrin dizayn sənədlərinə uyğun olduğundan əmin olun. Bütün CRUD əməliyyatları üçün istifadəçi proqram GUI-dən Saxla, Yenilə, Axtar və ya Sil kliklədikdə müvafiq cədvəllərin və qeydlərin yeniləndiyini yoxlayın.

ACID əməliyyat xüsusiyyətləri

Əməliyyatların ACID xüsusiyyətlərinə atomiklik, tutarlılıq, izolyasiya və güc daxildir. Verilənlər bazası testi zamanı bu dörd xüsusiyyəti yoxlamaq lazımdır. Verilənlər bazası paylanırsa, bu sahə daha geniş sınaq tələb edir.

Məlumatların bütövlüyü

Qeyd edək ki, müxtəlif proqram modulları (məsələn, ekranlar və formalar) eyni məlumatdan istifadə edir və CRUD əməliyyatlarını fərqli şəkildə yerinə yetirir. Buna görə də, məlumatların son vəziyyətinin hər yerdə bərabər şəkildə əks olunduğundan əmin olmalısınız. Sistem bütün formalarda və ekranlarda yenilənmiş dəyərləri göstərməlidir. Buna verilənlərin bütövlüyü deyilir.

Biznes məntiqinin həyata keçirilməsinin dəqiqliyi

Bu gün verilənlər bazaları qeydləri saxlamaqdan daha çoxu üçün nəzərdə tutulub. Onlar inkişaf etdiricilərə verilənlər bazası səviyyəsində biznes məntiqini həyata keçirmək üçün geniş imkanlar verən çox güclü alətlərə çevriliblər. Güclü verilənlər bazası xüsusiyyətlərinə misal olaraq "referensial bütövlüyü", əlaqə məhdudiyyətləri, tetikleyiciler və saxlanılan prosedurları göstərmək olar. Beləliklə, verilənlər bazası tərəfindən təklif olunan bu və bir çox digər funksiyalardan istifadə edərək tərtibatçılar verilənlər bazası səviyyəsində biznes məntiqini həyata keçirirlər. Test edən şəxs həyata keçirilən biznes məntiqinin düzgün olmasını və düzgün işləməsini təmin etməlidir.

Verilənlər bazasını necə sınamaq olar?

SQL sorğularının yazılması

Verilənlər bazasının test prosesini düzgün təşkil etmək üçün test edənlər SQL və DML (Data Manipulation Language) haqqında yaxşı biliyə malik olmalı və verilənlər bazasının daxili strukturunu aydın şəkildə başa düşməlidirlər. Bu, verilənlər bazasını test etməyin ən yaxşı və etibarlı yoludur, xüsusən də aşağı və orta mürəkkəbliyə malik proqramlar üçün. Ancaq təsvir olunan iki ilkin şərt yerinə yetirilməlidir. Tətbiq çox mürəkkəbdirsə, test edənin bütün lazımi SQL sorğularını özü yazması çətin və ya hətta qeyri-mümkün olacaq. Buna görə də, bəzi mürəkkəb sorğular halında, tester yardım üçün tərtibatçıya müraciət edə bilər. Bu üsul təkcə testin yaxşı aparıldığına əminlik vermir, həm də SQL sorğularını yazmaq bacarığını artırır.

Cədvəllərdə verilənlərə baxmaq

Əgər test edən şəxs SQL-i bilmirsə, o zaman o, verilənlər bazasının cədvəllərinə (əlaqələrinə) baxaraq proqramın qrafik interfeysindən istifadə edərək CRUD əməliyyatının nəticəsini yoxlaya bilər. Verilənlər bazasını yoxlamaq üçün bu üsul cədvəl strukturu haqqında yaxşı bilik tələb edir və bir az yorucu və çətin ola bilər, xüsusən də verilənlər bazası və cədvəllər çoxlu məlumatlara malik olduqda. Əgər test məlumatları bir neçə cədvəldə yerləşərsə, verilənlər bazasını yoxlamağın bu üsulu sınaqçılar üçün çətin ola bilər.

Tərtibatçı Yardımı

Tester GUI-də istənilən CRUD əməliyyatlarını yerinə yetirir və tərtibatçı tərəfindən yazılmış müvafiq SQL sorğularını yerinə yetirməklə onların nəticələrini yoxlayır. Bu metod nə SQL-i yaxşı bilmək, nə də proqram verilənlər bazası strukturunu yaxşı bilmək tələb etmir.Metod sadə görünür və yaxşı seçim verilənlər bazasını sınaqdan keçirmək üçün. Lakin onun mənfi tərəfi xaosdur. Tərtibatçının yazdığı sorğu semantik cəhətdən səhvdirsə və ya istifadəçinin tələblərini düzgün yerinə yetirmirsə? Bu halda, sınaq məhsulun keyfiyyətinə dair heç bir zəmanət vermir.

Verilənlər bazası məlumatlarının bütövlüyünü yoxlamaq üçün bir metodologiya nümunəsi

Verilənlər bazaları və verilənlər bazası prosesləri müstəqil alt sistem kimi sınaqdan keçirilməlidir. Bu halda verilənlərin interfeysi kimi hədəf istifadəçi interfeysi olmayan bütün alt sistemlər sınaqdan keçirilməlidir. Aşağıdakı cədvəldə müəyyən edilmiş testləri dəstəkləmək üçün alətlər və üsulları müəyyən etmək üçün verilənlər bazası idarəetmə sistemində (DBMS) əlavə tədqiqat aparılmalıdır.

Metodologiyanın məqsədləri	Arızalı hədəf alqoritmləri və ya məlumatların korlanması müşahidə oluna və qeydə alına bilməsi üçün UI-dən asılı olmayaraq verilənlər bazasına giriş metodlarının və proseslərinin sınaqdan keçirilməsi.
Metodologiya	Hər bir verilənlər bazasına giriş metodu və ya prosesini çağırın, hər birini etibarlı və etibarsız məlumat və ya məlumat sorğuları ilə doldurun. Verilənlərin düzgün doldurulmasını və bütün verilənlər bazası hadisələrinin gözlənildiyi kimi baş verməsini təmin etmək üçün verilənlər bazasını yoxlamaq və ya lazım olduqda düzgün məlumatların əldə edilməsini təmin etmək üçün geri qaytarılmış məlumatların təsdiqlənməsi.
Oracles(problemi müəyyən etməyə kömək edən evristik mexanizm)	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti Şəkil və Əsas Bərpa Aləti Yedəkləmə və bərpa vasitələri Quraşdırma monitorinq alətləri (reyestr, HDD, CPU, yaddaş və s.) SQL Database Utilities və Tools Məlumat Yaratma Vasitələri
Uğur meyarları	Bu texnika verilənlər bazasına daxil olmaq üçün bütün əsas metodların və proseslərin sınaqdan keçirilməsini dəstəkləyir.
Xüsusiməlumat	Test üçün DBMS inkişaf mühiti və ya drayverlərdən verilənlər bazasına birbaşa məlumat daxil etmək və ya dəyişdirmək tələb oluna bilər. Proseslər əl ilə çağırılmalıdır. Kiçik verilənlər bazası və ya verilənlər bazası minimum ölçü(məhdud sayda daxilolma ilə) bütün pozulmuş hadisələrin əhatə dairəsini genişləndirmək üçün istifadə edilməlidir.

Məqalənin tərcüməsi Rizvan Jafri

Bu günlərdə verilənlər bazası proqramın qaçılmaz hissələrindən biridir. Tətbiq icra edildikdə, son istifadəçi əsasən istifadə edir CRUD əməliyyatları verilənlər bazası aləti tərəfindən təmin edilir.

C: Yaradın(Yarat) - 'Yarat' əməliyyatı istifadəçi hər hansı yeni əməliyyatı saxladıqda həyata keçirilir.
R: Alın(Geri götür) - "Geri götür" əməliyyatı istifadəçi hər hansı saxlanmış əməliyyatı axtardıqda və ya ona baxdıqda həyata keçirilir.
U: Yeniləyin(Yeniləmə) - "Yeniləmə" əməliyyatı istifadəçi mövcud qeydi redaktə etdikdə və ya dəyişdirdikdə həyata keçirilir.
D: Sil(Sil) - 'Sil' əməliyyatı istifadəçi sistemdən hər hansı bir qeydi sildikdə həyata keçirilir.

Hansı verilənlər bazasından istifadə edilməsinin və əməliyyatın əvvəllər necə yerinə yetirildiyinin (birləşmə və ya alt sorğu, tetikleyici və ya saxlanılan prosedur, sorğu və ya funksiya) əhəmiyyəti yoxdur. Maraqlısı odur ki, istənilən proqramın istifadəçi interfeysindən tutmuş istifadəçi tərəfindən həyata keçirilən bütün verilənlər bazası əməliyyatları bu dörd CRUD əməliyyatından biridir.

Verilənlər bazasını sınaqdan keçirərkən nəyi yoxlamaq lazımdır?

1) Məlumat xəritələşdirilməsi:
Verilənlər bazasındakı əlaqələrin dizayn sənədlərinə uyğun olduğundan əmin olun. Bütün CRUD əməliyyatları üçün istifadəçi proqram GUI-dən Saxla, Yenilə, Axtar və ya Sil kliklədikdə müvafiq cədvəllərin və qeydlərin yeniləndiyini yoxlayın.

2) ACID əməliyyat xüsusiyyətləri:
Əməliyyatların ACID xüsusiyyətlərinə daxildir atomluq, sonrakı ardıcıllıq, izolyasiya Və güc. Verilənlər bazası testi zamanı bu dörd xüsusiyyəti yoxlamaq lazımdır. Verilənlər bazası paylanırsa, bu sahə daha geniş sınaq tələb edir.

3) Məlumatların bütövlüyü:
Qeyd edək ki, müxtəlif proqram modulları (məsələn, ekranlar və formalar) eyni məlumatdan istifadə edir və CRUD əməliyyatlarını fərqli şəkildə yerinə yetirir. Buna görə də, məlumatların son vəziyyətinin hər yerdə bərabər şəkildə əks olunduğundan əmin olmalısınız. Sistem bütün formalarda və ekranlarda yenilənmiş dəyərləri göstərməlidir. Buna verilənlərin bütövlüyü deyilir.

4) Biznes qaydalarının həyata keçirilməsinin dəqiqliyi:
Bu gün verilənlər bazaları qeydləri saxlamaqdan daha çoxu üçün nəzərdə tutulub. Onlar inkişaf etdiricilərə verilənlər bazası səviyyəsində biznes məntiqini həyata keçirmək üçün geniş imkanlar verən çox güclü alətlərə çevriliblər. Güclü verilənlər bazası xüsusiyyətlərinə misal olaraq "referensial bütövlüyü", əlaqə məhdudiyyətləri, tetikleyiciler və saxlanılan prosedurları göstərmək olar. Beləliklə, verilənlər bazası tərəfindən təklif olunan bu və bir çox digər funksiyalardan istifadə edərək tərtibatçılar verilənlər bazası səviyyəsində biznes məntiqini həyata keçirirlər. Test edən şəxs həyata keçirilən biznes məntiqinin düzgün olmasını və düzgün işləməsini təmin etməlidir.

Yuxarıda təsvir olunan məqamlar verilənlər bazası testinin ən vacib aspektləridir. Verilənlər bazasının sınağı kritik bir iş işidir və heç vaxt lazımi təlim olmadan təcrübəsiz işçilərə həvalə edilməməlidir.

Verilənlər bazasını necə sınamaq olar?

1. SQL sorğularının yazılması
Verilənlər bazasını düzgün və dəqiq yoxlamaq üçün ilk növbədə testerin SQL və DML (Data Manipulation Language) dilini çox yaxşı bilməsi lazımdır. İkincisi, test edən şəxs verilənlər bazasının daxili strukturunu yaxşı başa düşməlidir. Bu iki şərt yerinə yetirilərsə, işçi verilənlər bazasını sınaqdan keçirməyə hazırdır. O, tətbiqin UI-dən istənilən CRUD əməliyyatlarını yerinə yetirəcək və sonra SQL sorğularından istifadə edərək icra nəticələrini yoxlayacaq.
Bu, verilənlər bazasını test etməyin ən yaxşı və etibarlı yoludur, xüsusən də aşağı və orta mürəkkəbliyə malik proqramlar üçün. Ancaq təsvir olunan iki ilkin şərt yerinə yetirilməlidir. Əks halda, verilənlər bazası testinin bu üsulu sizin üçün işləməyəcək.
Tətbiq çox mürəkkəbdirsə, test edənin bütün lazımi SQL sorğularını özü yazması çətin və ya hətta qeyri-mümkün olacaq. Buna görə də, bəzi mürəkkəb sorğular halında, tester yardım üçün tərtibatçıya müraciət edə bilər.
Bu üsul təkcə testin yaxşı aparıldığına əminlik vermir, həm də SQL sorğularını yazmaq bacarığını artırır.

2. Cədvəllərdə verilənlərə baxmaq
Əgər test edən şəxs SQL dilini bilmirsə, o zaman verilənlər bazasının cədvəllərinə (əlaqələrinə) baxaraq proqramın qrafik interfeysindən istifadə etməklə CRUD əməliyyatının nəticəsini yoxlaya bilər. Verilənlər bazasını yoxlamaq üçün bu üsul cədvəl strukturu haqqında yaxşı bilik tələb edir və bir az yorucu və çətin ola bilər, xüsusən də verilənlər bazası və cədvəllər çoxlu məlumatlara malik olduqda.
Əlavə olaraq, yoxlanılacaq məlumatlar bir neçə cədvəldə olarsa, verilənlər bazasını yoxlamağın bu üsulu test edənlər üçün çox çətin ola bilər.

3. Tərtibatçı Yardımı
Bu, ən asan yoldur. Tester GUI-də istənilən CRUD əməliyyatlarını yerinə yetirir və tərtibatçı tərəfindən yazılmış müvafiq SQL sorğularını yerinə yetirməklə onların nəticələrini yoxlayır. Bu metod nə SQL-i yaxşı bilmək, nə də proqram verilənlər bazası strukturunu yaxşı bilmək tələb etmir.
Beləliklə, bu üsul sadə görünür və DB testi üçün yaxşı seçimdir. Lakin onun mənfi tərəfi xaosdur. Tərtibatçının yazdığı sorğu semantik cəhətdən səhvdirsə və ya istifadəçinin tələblərini düzgün yerinə yetirmirsə? Bu halda, sınaq məhsulun keyfiyyətinə dair heç bir zəmanət vermir.

Nəticə

Verilənlər bazası demək olar ki, hər bir tətbiqin əsas və ən vacib hissəsidir. Beləliklə, verilənlər bazası testi ciddi diqqət, SQL sorğularının yazılmasında yaxşı bacarıqlar, verilənlər bazası strukturu haqqında biliklər və müvafiq hazırlıq tələb edir.

Testin effektiv olmasına əmin olmaq üçün bu dörd xüsusiyyətin hamısına sahib olan şəxsə təyin edilməlidir. Əks halda, məhsulun çatdırılmasından sonra, çox güman ki, tətbiqin səhv və ya gözlənilməz davranışı, müştərinin tapacağı səhvlər olacaq.

Metodologiyanın məqsədləri:	Arızalı hədəf alqoritmləri və ya məlumatların korlanması müşahidə oluna və qeydə alına bilməsi üçün UI-dən asılı olmayaraq verilənlər bazasına giriş metodlarının və proseslərinin sınaqdan keçirilməsi.
Metodologiya:	Hər bir verilənlər bazasına giriş metodu və ya prosesini çağırın, hər birini etibarlı və etibarsız məlumat və ya məlumat sorğuları ilə doldurun. Verilənlərin düzgün doldurulmasını və bütün verilənlər bazası hadisələrinin gözlənildiyi kimi baş verməsini təmin etmək üçün verilənlər bazasını yoxlamaq və ya lazım olduqda düzgün məlumatların əldə edilməsini təmin etmək üçün geri qaytarılmış məlumatların təsdiqlənməsi.
Oracles:
Tələb olunan alətlər:	SQL verilənlər bazası utilitləri və alətləri məlumat yaratmaq alətləri
Uğur meyarları:	Bu texnika verilənlər bazasına daxil olmaq üçün bütün əsas metodların və proseslərin sınaqdan keçirilməsini dəstəkləyir.
Xüsusi məlumat:	Test üçün DBMS inkişaf mühiti və ya drayverlərdən verilənlər bazasına birbaşa məlumat daxil etmək və ya dəyişdirmək tələb oluna bilər. Proseslər əl ilə çağırılmalıdır. Bütün zədələnmiş hadisələrin əhatə dairəsini genişləndirmək üçün kiçik və ya minimal ölçülü verilənlər bazaları (məhdud sayda qeydlərlə) istifadə edilməlidir.

Funksiya testi

Test hədəf funksiyasının testi istifadə halları və ya biznes prosesi funksiyaları və qaydaları üçün birbaşa izlənilə bilən tələblərə diqqət yetirməlidir. Bu testlərin məqsədi məlumatların düzgün qəbul edilməsini, işlənməsini və qaytarılmasını, habelə biznes prosesi qaydalarının müvafiq icrasını yoxlamaqdır. Bu test növü qara qutu texnikalarına əsaslanır, yəni proqramın yoxlanması və onun daxili prosesləri Qrafik İstifadəçi İnterfeysi (GUI) istifadə edərək proqramla qarşılıqlı əlaqədə olmaq və tapıntıları və ya nəticələri təhlil etməklə həyata keçirilir. Aşağıdakı cədvəl hər bir tətbiq üçün tövsiyə olunan sınaq çərçivəsini müəyyən edir.

Metodologiyanın məqsədləri:	Hədəf alqoritmini izləmək və qeyd etmək üçün naviqasiya, daxiletmə, məlumatların işlənməsi və qaytarılması daxil olmaqla sınaq hədəfinin funksionallığını yoxlayın.
Metodologiya:	Test mövzuları və ya funksiyaları və funksionallıq Bunu yoxlamaq üçün etibarlı və etibarsız məlumatlardan istifadə edərək hər bir istifadə ssenarisi üçün ayrıca istifadə halları: etibarlı məlumatlardan istifadə edərkən gözlənilən nəticələr əldə edilir Yanlış məlumat istifadə edilərsə, müvafiq səhv və ya xəbərdarlıq mesajları göstərilir bütün iş prosesi qaydaları müvafiq olaraq tətbiq edilir
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti şəkil yaratmaq və əsas bərpa aləti ehtiyat nüsxə və bərpa alətləri quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.) məlumat yaratmaq alətləri
Uğur meyarları:	bütün əsas istifadə ssenariləri bütün əsas funksiyalar
Xüsusi məlumat:	Xüsusiyyət testinin icrasına və performansına təsir edən elementləri və ya problemləri (daxili və ya xarici) müəyyən edin və ya təsvir edin.

Biznes Prosesi Cycle Testing

Biznes prosesi dövrü testi zamanla yerinə yetirilən tapşırıqları təqlid etməlidir<Имя проекта>. Siz bir il kimi bir dövr təyin etməli və il ərzində baş verəcək əməliyyatları və tapşırıqları yerinə yetirməlisiniz. Buraya bütün gündəlik, həftəlik və aylıq dövrlər, eləcə də tarixə əsaslanan hadisələr daxildir.

Metodologiyanın məqsədləri:	Tələb olunan biznes prosesi modellərinə və hədəf alqoritmini izləmək və qeyd etmək planlarına uyğun olaraq test hədəf proseslərini və fon proseslərini sınaqdan keçirin.
Metodologiya:	Test aşağıdakıları etməklə bir iş prosesinin bir neçə dövrünü simulyasiya edir: Test hədəfinin xüsusiyyətlərini yoxlamaq üçün istifadə edilən testlər dəyişdiriləcək və ya müəyyən müddət ərzində bir neçə fərqli istifadəçini simulyasiya etmək üçün hər bir funksiyanın yerinə yetirilmə sayını artırmaq üçün genişləndiriləcək. Bütün tarix və ya vaxtdan asılı funksiyalar etibarlı və etibarsız tarix və dövrlərdən istifadə etməklə yerinə yetiriləcək. Vaxtaşırı yerinə yetirilən bütün funksiyalar lazımi vaxtda yerinə yetiriləcək və ya işə salınacaq. Test aşağıdakıları yoxlamaq üçün etibarlı və etibarsız məlumatlardan istifadə edəcək: Etibarlı məlumatlar istifadə edildikdə, gözlənilən nəticələr əldə edilir. Yanlış məlumat istifadə edilərsə, müvafiq səhv və ya xəbərdarlıq mesajları göstərilir. Bütün iş prosesi qaydaları müvafiq olaraq tətbiq edilir.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti şəkil yaratmaq və əsas bərpa aləti ehtiyat nüsxə və bərpa alətləri məlumat yaratmaq alətləri
Uğur meyarları:	Bu texnika bütün kritik iş prosesi dövrlərinin sınaqdan keçirilməsini dəstəkləyir.
Xüsusi məlumat:	Sistem tarixləri və hadisələri xüsusi köməkçi tapşırıqlar tələb edə bilər. Müvafiq tələbləri və sınaq prosedurlarını müəyyən etmək üçün biznes prosesi modeli tələb olunur.

İstifadəçi interfeysi sınağı

İstifadəçi interfeysi (UI) testi istifadəçinin proqram təminatı ilə qarşılıqlı əlaqəsini yoxlayır. UI testinin məqsədi istifadəçi interfeysinin istifadəçiyə test hədəfinin xüsusiyyətlərinə müvafiq giriş və naviqasiya təmin etməsini təmin etməkdir. Bundan əlavə, UI testi UI-dəki obyektlərin gözlənildiyi kimi işləməsini və korporativ və ya sənaye standartlarına uyğun olmasını təmin etməyə kömək edir.

Metodologiyanın məqsədləri:	Standartlara və hədəf alqoritminə uyğunluğu izləmək və qeyd etmək üçün aşağıdakıları sınayın: İş prosesinin funksiyalarını və tələblərini əks etdirən test hədəfinin naviqasiyası, o cümlədən pəncərədən pəncərəyə, sahədən sahəyə metodlar və giriş metodlarından istifadə (tab düymələri, siçan hərəkətləri, klaviatura qısa yolları). Siz pəncərə obyektlərini və menyular, ölçü, tərtibat, vəziyyət və fokus kimi xüsusiyyətləri sınaya bilərsiniz.
Metodologiya:	Hər bir proqram pəncərəsi və obyekt üçün düzgün naviqasiya və obyekt vəziyyətlərini yoxlamaq üçün hər pəncərə testləri yaradın və ya dəyişdirin.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika sınaq skriptinin avtomatlaşdırılması alətini tələb edir.
Uğur meyarları:	Bu texnika istifadəçilər tərəfindən geniş istifadə olunacaq hər bir ev ekranının və ya pəncərənin sınaqdan keçirilməsini dəstəkləyir.
Xüsusi məlumat:	Fərdi obyektlərin və üçüncü tərəf obyektlərinin bütün xassələrinə daxil olmaq mümkün deyil.

Performans Profili

Performans profili cavab vaxtlarını, əməliyyat sürətlərini və digər vaxta həssas tələbləri ölçən və qiymətləndirən performans testidir. Performans profilinin yaradılmasının məqsədi performans tələblərinə nail olunduğunu yoxlamaqdır. Performans profili iş yükü və ya aparat konfiqurasiyası kimi şərtlərin funksiyası kimi test hədəfinin performans alqoritmlərini profilləşdirmək və dəqiqləşdirmək üçün həyata keçirilir və həyata keçirilir.

Qeyd: Aşağıdakı cədvəldə sadalanan əməliyyatlar "məntiqi iş prosesi əməliyyatları" kimi təsnif edilir. Bu əməliyyatlar müəyyən bir müqavilənin əlavə edilməsi və ya dəyişdirilməsi kimi test məqsədindən istifadə etməklə müəssisənin yerinə yetirməsi gözlənilən xüsusi istifadə halları kimi müəyyən edilir.

Metodologiyanın məqsədləri:	Hədəf alqoritmi və tətbiq performans məlumatlarını müşahidə etmək və qeyd etmək üçün aşağıdakı şərtlər altında müəyyən funksional əməliyyatlar və ya biznes prosesi funksiyaları üçün alqoritmləri sınaqdan keçirin:
Metodologiya:	Biznes prosesinin funksiyalarını və dövrlərini yoxlamaq üçün nəzərdə tutulmuş test prosedurlarını tətbiq edin. Hər bir əməliyyatda yerinə yetirilən iterasiyaların sayını artırmaq üçün əməliyyatların və ya skriptlərin sayını artırmaq üçün məlumat fayllarının dəyişdirilməsi. Skriptlər eyni sistemdə işlədilməlidir ( ən yaxşı variant- bir istifadəçi, bir əməliyyatla başlayın) və birdən çox müştəri ilə təkrarlayın (virtual və ya faktiki, aşağıda xüsusi məlumatlara baxın).
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti Rational Quantify kimi proqram performansını profilləşdirmə aləti quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.)
Uğur meyarları:	Bu texnika testi dəstəkləyir: Tək tranzaksiya və ya tək istifadəçi: Testin tətbiqi problemlərinə görə uğursuzluq olmadan tranzaksiya ssenarilərini uğurla təqlid edin. Çoxsaylı əməliyyatlar və ya birdən çox istifadəçi: Testin tətbiqi problemlərinə görə uğursuzluq olmadan iş yükünü uğurla təqlid edin.
Xüsusi məlumat:	Kompleks performans testinə serverdə arxa plan yükü daxildir. Aşağıdakılar daxil olmaqla bir neçə üsuldan istifadə edilə bilər: Birbaşa serverə, adətən Strukturlaşdırılmış Sorğu Dili (SQL) çağırışları şəklində "əməliyyatların çatdırılması". Bir neçə müştərini, adətən bir neçə yüz müştərini simulyasiya etmək üçün "virtual" istifadəçi yükünün yaradılması. Bu yükü əldə etmək üçün uzaq terminal emulyasiya alətlərindən istifadə olunur. Bu texnika şəbəkəni "məlumat axını" ilə doldurmaq üçün də istifadə edilə bilər. Sistemdə bir yük yaratmaq üçün hər biri test skriptlərini işlədən bir neçə fiziki müştəridən istifadə edin. Performans testi xüsusi sistemdə və ya xüsusi vaxtda aparılmalıdır. Bu, tam nəzarət və dəqiq ölçmələri təmin edir. Performans sınağı üçün istifadə olunan verilənlər bazası ya faktiki ölçüdə olmalı, ya da bərabər ölçüdə olmalıdır.

Yük testi

Yük testi, performans alqoritmlərini və test hədəfinin müxtəlif iş yükləri altında müvafiq şəkildə işləməyə davam etmək qabiliyyətini ölçmək və qiymətləndirmək üçün test hədəfinin müxtəlif iş yüklərinə məruz qaldığı bir performans testidir. Yük sınağının məqsədi gözlənilən maksimum əməliyyat yükünə məruz qaldıqda sistemin düzgün işləməsini müəyyən etmək və təmin etməkdir. Yük testi həmçinin cavab müddəti, əməliyyat sürəti və digər vaxtla əlaqəli parametrlər kimi performans parametrlərini qiymətləndirir.

Qeyd: Aşağıdakı cədvəldə sadalanan əməliyyatlar "məntiqi iş prosesi əməliyyatları" kimi təsnif edilir. Bu əməliyyatlar istifadəçinin proqramdan istifadə edərkən yerinə yetirməsi gözlənilən xüsusi funksiyalar kimi müəyyən edilir, məsələn, verilmiş müqavilənin əlavə edilməsi və ya dəyişdirilməsi.

Metodologiyanın məqsədləri:	Hədəf alqoritmi və sistem performansı məlumatlarını izləmək və qeyd etmək üçün müxtəlif iş yükü şəraitində təyin edilmiş əməliyyatları və ya iş prosesinin variasiyalarını yerinə yetirin.
Metodologiya:	Biznes prosesinin funksionallığını və dövrlərini əsas kimi yoxlamaq üçün hazırlanmış əməliyyat test skriptlərindən istifadə edin, lakin lazımsız iterasiyaları və gecikmələri aradan qaldırın. Hər bir əməliyyatın yerinə yetirilmə sayını artırmaq üçün əməliyyatların və ya testlərin sayını artırmaq üçün məlumat fayllarının dəyişdirilməsi. İş yüklərinə - məsələn, gündəlik, həftəlik və aylıq - pik yüklər daxil edilməlidir. İş yükləri həm orta, həm də pik yükləri təmsil etməlidir. İş yükləri həm ani, həm də uzunmüddətli pik yükləri təmsil etməlidir. İş yükləri müxtəlif sınaq mühiti konfiqurasiyalarında sınaqdan keçirilməlidir.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.) resurs məhdudlaşdıran alətlər; məsələn, Konservləşdirilmiş İstilik məlumat yaratmaq alətləri
Uğur meyarları:	Bu texnika iş yükünün emulyasiya testini dəstəkləyir ki, bu da testin tətbiqi problemlərinə görə uğursuzluqlar olmadan iş yükünün uğurlu emulyasiyasıdır.
Xüsusi məlumat:	Yük testi xüsusi sistemdə və ya xüsusi vaxtda aparılmalıdır. Bu, tam nəzarət və dəqiq ölçmələri təmin edir. Yük testi üçün istifadə olunan verilənlər bazası ya faktiki ölçüdə olmalı, ya da bərabər ölçüdə olmalıdır.

Gərginlik testi

Stress testi, sistemin gözlənilən tolerantlıqlarda və ya ondan kənar şərtlərdə necə uğursuz olduğunu anlamaq üçün həyata keçirilən və həyata keçirilən performans testinin bir növüdür. Bu, adətən resurs çatışmazlığını və ya resurslar uğrunda rəqabəti əhatə edir. Aşağı resurs şərtləri test məqsədinin normal şəraitdə aşkar olmayan şəkildə necə uğursuz olduğunu göstərir. Digər çatışmazlıqlar verilənlər bazası kilidləri və ya şəbəkə bant genişliyi kimi paylaşılan resurslar üçün mübahisə nəticəsində yarana bilər, baxmayaraq ki, bu testlərdən bəziləri adətən xüsusiyyət və yük testində aparılır.

Metodologiyanın məqsədləri:	Sınaq hədəfinin funksiyalarını aşağıdakı gərginlik şəraitində sınaqdan keçirin. uğursuzluq sistemə uyğun olaraq işləməyə davam etmək üçün: az miqdarda yaddaş və ya serverdə boş yaddaşın olmaması (RAM və daimi yaddaş) əlaqəli və ya simulyasiya edilmiş istifadəçilərin fiziki və ya faktiki olaraq mümkün olan maksimum sayı birdən çox istifadəçi eyni məlumat və ya hesablarla eyni əməliyyatları yerinə yetirir "həddindən artıq" əməliyyat həcmi və ya şərtlərin qarışığı (yuxarıda Performans Profili bölməsinə baxın)
Metodologiya:	Məhdud resursları sınaqdan keçirmək üçün testlər tək sistemdə aparılmalı, serverdə operativ yaddaş və daimi yaddaş azaldılmalı və ya məhdudlaşdırılmalıdır. Digər gərginlik testləri üçün ən pis əməliyyat həcmini və ya hər ikisinin qarışığını yaratmaq üçün eyni və ya əlavə testləri həyata keçirən çoxsaylı müştərilər istifadə edilməlidir.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti əməliyyat yükünün planlaşdırılması və idarə edilməsi vasitəsi quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.) resurs məhdudlaşdıran alətlər; məsələn, Konservləşdirilmiş İstilik məlumat yaratmaq alətləri
Uğur meyarları:	Bu texnika gərginlik emulyasiya testini dəstəkləyir. Stress şərtləri kimi müəyyən edilən bir və ya daha çox şəraitdə sistem uğurla təqlid oluna bilər və sistemin yaranan vəziyyətinin müşahidələri şərti təqlid zamanı və sonra qeyd oluna bilər.
Xüsusi məlumat:	Şəbəkədə stress yaratmaq üçün şəbəkə alətləri mesajlar və paketlərlə şəbəkəni yükləmək üçün tələb oluna bilər. Sistem üçün istifadə olunan davamlı yaddaş verilənlər bazası artımı üçün mövcud yeri məhdudlaşdırmaq üçün müvəqqəti olaraq azaldılmalıdır. Müştərilərin eyni məlumat qeydlərinə və ya hesablarına eyni vaxtda daxil olmasını sinxronlaşdırmalısınız.

Bacarıq testi

Tutum testi, sistemin uğursuzluğuna səbəb olan məhdudiyyətlərə çatılıb-çatılmadığını müəyyən etmək üçün test hədəfini böyük həcmli məlumatlara məruz qoyur. Tutum sınağı həmçinin sınaq hədəfinin müəyyən müddət ərzində idarə edə biləcəyi davamlı maksimum yükü və ya tutumu müəyyən edir. Məsələn, əgər test hədəfi hesabat yaratmaq üçün verilənlər bazası qeydləri toplusunu emal edirsə, tutum testi böyük bir test verilənlər bazasından istifadə edəcək və bunu yoxlayacaq. proqram təminatı yaxşı işləyir və düzgün hesabat verir.

Metodologiyanın məqsədləri:	Hədəf alqoritmini müşahidə etmək və qeyd etmək üçün aşağıdakı yüksək tutumlu ssenarilərdə test hədəfinin funksionallığını sınaqdan keçirin: Uzun müddət ərzində eyni (performans baxımından ən pis) iş prosesi funksiyasını yerinə yetirən əlaqəli və ya simulyasiya edilmiş müştərilərin maksimum (faktiki və ya fiziki mümkün) sayı. Verilənlər bazasının maksimum ölçüsünə (faktiki və ya miqyasına) çatıldı və birdən çox sorğu və ya hesabat əməliyyatları eyni vaxtda həyata keçirilir.
Metodologiya:	Performans profili və ya yük testi üçün hazırlanmış testlərdən istifadə edin. Uzun müddət ərzində tranzaksiyaların ən pis həcmini və ya onların qarışığını (bax stress testi) yaratmaq üçün eyni və ya əlavə testlər keçirən çoxsaylı müştərilər istifadə edilməlidir. Verilənlər bazasının maksimum ölçüsü (faktiki, miqyaslı və ya təmsilçi məlumatlarla doldurulmuş) yaradılır və uzun müddət ərzində sorğuları və hesabat əməliyyatlarını yerinə yetirmək üçün bir neçə müştəri eyni vaxtda istifadə olunur.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti əməliyyat yükünün planlaşdırılması və idarə edilməsi vasitəsi quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.) resurs məhdudlaşdıran alətlər; məsələn, Konservləşdirilmiş İstilik məlumat yaratmaq alətləri
Uğur meyarları:	Bu texnika potensial emulyasiya testini dəstəkləyir. Çox sayda istifadəçi, verilənlər, əməliyyatlar və ya sistemdən istifadənin digər aspektləri uğurla təqlid edilə bilər və tutum testi zamanı sistem vəziyyətində dəyişikliklər müşahidə edilə bilər.
Xüsusi məlumat:

Təhlükəsizlik və girişə nəzarət testi

Təhlükəsizlik və girişə nəzarət testi təhlükəsizliyin iki əsas sahəsinə diqqət yetirir:

Məlumatlara və ya biznes prosesi funksiyalarına giriş daxil olmaqla, proqram səviyyəsində qorunma

Giriş və ya daxil olmaqla sistem səviyyəsində təhlükəsizlik uzaqdan giriş sistemə

Tələb olunan qorunma səviyyəsinə əsaslanaraq, tətbiq səviyyəsində qoruma subyektlərin yalnız müəyyən xüsusiyyətlərə və ya istifadə hallarına çıxışının olmasını və ya onlar üçün mövcud olan məlumatların məhdud olmasını təmin edir. Məsələn, məlumatların daxil edilməsi və yeni hesabların yaradılması hamıya, silinməsinə isə yalnız menecerlərə icazə verilə bilər. Əgər məlumat səviyyəsində təhlükəsizlik varsa, o zaman sınaq “1-ci tip istifadəçinin” maliyyə məlumatları da daxil olmaqla, bütün müştəri məlumatlarına, “2-ci tip istifadəçinin” isə yalnız həmin müştəri haqqında demoqrafik məlumatlara çıxışına malik olmasını təmin edir.

Sistem səviyyəsində təhlükəsizlik yalnız sistem icazələri olan istifadəçilərin proqramlara və yalnız müvafiq şlüzlər vasitəsilə daxil olmasını təmin edir.

Metodologiyanın məqsədləri:	Hədəf alqoritmini müşahidə etmək və qeyd etmək üçün aşağıdakı şərtlər altında sınaq hədəfini sınayın: Tətbiq səviyyəsində qorunma: subyektin yalnız bu tip istifadəçinin giriş hüquqlarına malik olduğu funksiyalara və məlumatlara çıxışı var. Sistem səviyyəsində təhlükəsizlik: Tətbiqlərə giriş sistem və proqram icazələri olanlarla məhdudlaşır.
Metodologiya:	Tətbiq səviyyəsində təhlükəsizlik: Bütün istifadəçi növlərini və hər bir istifadəçi növünün daxil olmasına icazə verilən funksiyaları və məlumatları müəyyənləşdirin və siyahıya salın. Hər bir istifadəçi növü üçün testlər yaradın və hər bir istifadəçi növü üçün müəyyən edilmiş əməliyyatlar yaratmaqla bütün giriş hüquqlarını yoxlayın. İstifadəçi növünün dəyişdirilməsi və eyni istifadəçilər üçün testlərin təkrar icrası. Hər bir halda, əlavə funksiyalara və ya məlumatlara girişin düzgün şəkildə icazə verildiyini və ya rədd edildiyini yoxlamaq. Sistem Səviyyəsinə Giriş: Aşağıdakı Xüsusi Məlumata baxın.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: Test Skripti Avtomatlaşdırma Aləti Təhlükəsizlik boşluqlarını yoxlamaq və tapmaq üçün "Hacker" alətləri ƏS təhlükəsizlik idarəetmə vasitələri
Uğur meyarları:	Bu metodologiya hər bir məlum istifadəçi növü üçün təhlükəsizlik parametrlərinin təsirinə məruz qalan müvafiq xüsusiyyətlərin və məlumatların sınaqdan keçirilməsini dəstəkləyir.
Xüsusi məlumat:	Sistemə giriş yoxlanılmalı və müvafiq sistem və ya şəbəkə administratorları ilə müzakirə edilməlidir. Bu test lazım olmaya bilər, çünki o, şəbəkə və ya sistem idarəetmə funksiyalarının bir hissəsi ola bilər.

Fəlakətin bərpasının sınaqdan keçirilməsi

Fəlakətin bərpası sınağı test hədəfinin geniş məlumat itkisi və ya məlumat bütövlüyü ilə müxtəlif aparat, proqram təminatı və şəbəkə nasazlıqlarından uğurla bərpa oluna biləcəyini təsdiqləyir.

Fəaliyyətini davam etdirməli olan sistemlər üçün fəlakətin bərpası sınağı, uğursuzluqdan sonra bərpa edildikdə, alternativ və ya ehtiyat sistemlərin məlumat və ya əməliyyatları itirmədən uğursuz olan sistemi düzgün şəkildə "ələ keçirməsini" təmin edir.

Bərpa sınağı, tətbiqin və ya sistemin cihazın giriş/çıxış xətaları və ya etibarsız verilənlər bazası göstəriciləri və açarları kimi nasazlığa səbəb olan ekstremal şərtlərə və ya simulyasiya edilmiş şərtlərə məruz qaldığı antaqonist sınaq prosesidir. Bərpa prosesləri işə salınır və tətbiqin və ya sistemin və məlumatların düzgün bərpasına nail olunduğunu yoxlamaq üçün proqram və ya sistem monitorinq edilir və idarə olunur.

Metodologiyanın məqsədləri:	Uğursuzluq şərtlərini simulyasiya edin və verilənlər bazası, proqramlar və sistemin bərpa proseslərini (əllə və avtomatik) istədiyiniz məlum vəziyyətə gətirin. Bərpa edildikdən sonra əməliyyat alqoritmini izləmək və qeyd etmək üçün sınaqlara aşağıdakı növ şərtlər daxildir: müştəri sistemində enerji kəsilməsi server sistemində enerji kəsilməsi şəbəkə serverləri vasitəsilə əlaqənin kəsilməsi DASD (birbaşa yaddaşa giriş cihazları) və DASD nəzarətçiləri ilə əlaqənin kəsilməsi və ya enerji itkisi natamam dövrlər (məlumatların filtrasiya proseslərinin kəsilməsi, verilənlərin sinxronizasiya proseslərinin kəsilməsi) etibarsız göstəricilər və verilənlər bazası açarları verilənlər bazasındakı etibarsız və ya zədələnmiş məlumat elementləri
Metodologiya:	Bərpa testini dəstəkləmək üçün bir sıra əməliyyatlar yaratmaq üçün əsas kimi iş prosesinin funksionallığını və dövrləri yoxlamaq üçün artıq yaradılmış testlərdən istifadə edə bilərsiniz. İlk addım bərpa müvəffəqiyyəti üçün testləri müəyyən etməkdir. Müştəri sistemində enerji kəsilməsi: Kompüteri söndürün. Server sisteminin enerji kəsilməsi: Server üçün söndürmə prosedurlarını simulyasiya edir və ya işə salır. Şəbəkə serverləri vasitəsilə kəsinti: Şəbəkə bağlantısı itkisini simulyasiya edir və ya işə salır (birləşdirici telləri fiziki olaraq ayırmaq və ya şəbəkə serverlərinə və ya marşrutlaşdırıcılara enerjini kəsmək). DASD və DASD nəzarətçiləri ilə əlaqənin kəsilməsi və ya enerji itkisi: simulyasiya və ya bir və ya daha çox DASD və ya DASD nəzarətçiləri ilə əlaqənin fiziki itkisi. Yuxarıdakı və ya simulyasiya edilmiş şərtlərə çatdıqda, əlavə əməliyyatlar icra edilməli və bu ikinci sınaq mərhələsinə çatdıqda bərpa prosedurlarına müraciət edilməlidir. Natamam döngələri sınaqdan keçirərkən, verilənlər bazası proseslərinin özləri dayandırılmalı və ya vaxtından əvvəl dayandırılmalıdır istisna olmaqla, yuxarıda təsvir edilən eyni metodologiyadan istifadə olunur. Aşağıdakı şərtlərin sınaqdan keçirilməsi məlum verilənlər bazası vəziyyətinə çatmağı tələb edir. Bir neçə verilənlər bazası sahələri, göstəricilər və açarlar əl ilə və birbaşa verilənlər bazasında zədələnməlidir (verilənlər bazası alətlərindən istifadə etməklə). Əlavə əməliyyatlar tətbiq xüsusiyyətlərinin sınaqdan keçirilməsindən və biznes prosesi dövrlərindən və tam tamamlanmış dövrlərdən olan testlərdən istifadə etməklə həyata keçirilməlidir.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: şəkil yaratmaq və əsas bərpa aləti quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.) ehtiyat nüsxə və bərpa alətləri
Uğur meyarları:	Bu texnika testi dəstəkləyir: Tətbiqlərin, verilənlər bazası və sistemin bir və ya bir neçə kombinasiyasını əhatə edən bir və ya daha çox simulyasiya edilmiş uğursuzluqlar. Tətbiqlərin, verilənlər bazası və sistemin bir və ya bir neçə kombinasiyasını əhatə edən bir və ya bir neçə simulyasiya edilmiş bərpa, məlum arzu olunan vəziyyətə.
Xüsusi məlumat:	Bərpa testi əsasən müdaxilə edir. Elektrik kabellərinin ayrılması üçün prosedurlar (güc və ya əlaqə itkisini simulyasiya edərkən) arzuolunan və ya mümkün olmaya bilər. Diaqnostik proqram vasitələri kimi alternativ üsullar tələb oluna bilər. Sistemlərdən (və ya kompüter əməliyyatlarından), verilənlər bazalarından və şəbəkə qruplarından resurslar tələb edir. Bu testlər adi iş saatlarından kənarda və ya təcrid olunmuş sistemdə aparılmalıdır.

Konfiqurasiya testi

Konfiqurasiya testi müxtəlif aparat və proqram konfiqurasiyaları altında test hədəfinin performansını yoxlayır. Əksər iş mühitlərində müştəri iş stansiyaları, şəbəkə əlaqələri və verilənlər bazası serverləri üçün spesifik aparat spesifikasiyası fərqli ola bilər. Müştəri iş stansiyalarında müxtəlif proqram təminatı yüklənmiş ola bilər (məsələn, proqramlar, drayverlər və s.) və müxtəlif resurslardan istifadə etməklə eyni vaxtda bir çox müxtəlif proqram kombinasiyası aktiv ola bilər.

Metodologiyanın məqsədləri:	Müxtəlif konfiqurasiyalarda hədəf alqoritmini müşahidə etmək və qeyd etmək və konfiqurasiya statusunda fərqləri müəyyən etmək üçün tələb olunan aparat və proqram konfiqurasiyalarında test hədəfini yoxlayır.
Metodologiya:	Funksional testlərin tətbiqi. Microsoft® Excel® və Microsoft® Word® proqramları kimi testlə əlaqəli olmayan müxtəlif proqram təminatını testin bir hissəsi kimi və ya sınaqdan əvvəl açmaq və bağlamaq. Test hədəfi və qeyri-test hədəf proqram təminatı ilə qarşılıqlı əlaqədə olan obyektləri simulyasiya etmək üçün seçilmiş əməliyyatları yerinə yetirin. Müştəri iş stansiyasında mövcud əsas yaddaşı minimuma endirərək yuxarıdakı prosesi təkrarlayın.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: şəkil yaratmaq və əsas bərpa aləti quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.)
Uğur meyarları:	Bu texnika gözlənilən dəstəklənən inkişaf mühitlərində icra edilən test hədəf elementlərinin bir və ya bir neçə kombinasiyasının sınaqdan keçirilməsini dəstəkləyir.
Xüsusi məlumat:	Hansı qeyri-məqsədli proqram təminatı tələb olunur, əlçatandır və masaüstündə əlçatandır? Hansı proqramlar daha çox istifadə olunur? Proqramlar hansı verilənlər üzərində işləyir? məsələn, Excel-də açıq olan böyük cədvəl və ya Word-də 100 səhifəlik sənəd? Bu testin bir hissəsi olaraq siz həmçinin şəbəkəni, şəbəkə serverlərini və ümumilikdə sistem verilənlər bazalarını sənədləşdirməlisiniz.

Quraşdırmanın sınaqdan keçirilməsi

Quraşdırmanın sınaqdan keçirilməsinin iki məqsədi var. Birincisi, proqram təminatının quraşdırıla biləcəyinə əmin olmaqdır (məs yeni quraşdırma, yeniləmə və tam və ya xüsusi quraşdırma) müxtəlif standart və qeyri-standart şərtlər altında. Qeyri-adi şərtlərə qeyri-kafi disk sahəsi, kataloqlar yaratmaq üçün kifayət qədər icazələrin olmaması və s. İkinci məqsəd quraşdırmadan sonra proqram təminatının düzgün işləməsini yoxlamaqdır. Bir qayda olaraq, bu, funksionallığı yoxlamaq üçün hazırlanmış bir sıra testlərin icrası ilə həyata keçirilir.

Metodologiyanın məqsədləri:	Quraşdırma davranışını və konfiqurasiya vəziyyəti dəyişikliklərini müşahidə etmək və qeyd etmək üçün aşağıdakı şərtlər altında hər bir tələb olunan aparat konfiqurasiyasında test hədəfi quraşdırmasını həyata keçirin: yeni quraşdırma: əvvəllər heç vaxt quraşdırılmamış yeni sistem<Имя проекта> yeniləmə: əvvəllər quraşdırıldığı sistem<Имя проекта>, eyni versiya versiya yeniləməsi: əvvəllər quraşdırıldığı sistem<Имя проекта>, əvvəlki versiya
Metodologiya:	Hədəf sistem şərtlərini sınamaq üçün avtomatlaşdırılmış və ya əl ilə skriptlər hazırlayın. yeni:<имя проекта>heç quraşdırılmayıb <имя проекта>eyni və ya əvvəlki versiya artıq quraşdırılmışdır Quraşdırmaya başlayın və ya tamamlayın. Əvvəlcədən müəyyən edilmiş funksiya testi ssenarilərinin tətbiqi, əməliyyatların icrası.
Oracles:	Test nəticələrini düzgün müşahidə etmək üçün texnikada istifadə edilə bilən bir və ya bir neçə strategiyanı təsvir edin. Orakl həm müşahidənin aparıla biləcəyi metodun elementlərini, həm də mümkün uğur və ya uğursuzluğu göstərən müəyyən nəticənin xüsusiyyətlərini özündə birləşdirir. İdeal olaraq, oracles avtomatlaşdırılmış testlər vasitəsilə müvəffəqiyyətin və ya uğursuzluğun ilkin qiymətləndirilməsinə imkan verən özünü yoxlama aparacaq. Bununla belə, nəticələrin avtomatik müəyyən edilməsi ilə bağlı risklərdən xəbərdar olmalısınız.
Tələb olunan alətlər:	Bu texnika aşağıdakı alətləri tələb edir: şəkil yaratmaq və əsas bərpa aləti quraşdırma monitorinq vasitələri (reyestr, sabit disk, CPU, yaddaş və s.)
Uğur meyarları:	Bu texnika bir və ya bir neçə quraşdırma konfiqurasiyasında hazırlanmış məhsulun quraşdırılmasının sınaqdan keçirilməsini dəstəkləyir.
Xüsusi məlumat:	Hansı əməliyyatlar<имя проекта>Tətbiqi etibarlı bir test təmin etmək üçün seçilməlidir<имя проекта>uğurla quraşdırılıb və heç bir mühüm proqram komponenti əskik olmayıb?