Daudzi programmatūras testēšanas metožu veidi

Pirms programmatūras publiskošanas, programmētāji pavada stundas, cenšoties izlīdzināt katru mazo kļūdu. Kamēr produkts neatbilst visām ieinteresētajām personām, tas nebūs pieejams komerciālai lietošanai.

Milzīgi programmatūras uzņēmumi, piemēram, Google, gūst panākumus, neskatoties uz zemas prioritātes kļūdām savā programmatūrā, jo viņiem ir pacientu ieguldītāji un lojāli lietotāji. Mazākiem uzņēmumiem un jaunizveidotajiem uzņēmumiem tomēr nav šī luksusa. Klienti sagaida, ka produkti veic to, ko viņi pieprasa pārdošanas lapā vai dokumentācijā. Tā kā tur ir daudz iespēju, viņi nedomās divreiz par lektu, ja produkts izšķērdēs savu laiku un naudu. Tāpēc pirms izlaišanas programmatūra tiek pārbaudīta precīzi, lai:

• izcelt atšķirības starp sākotnējo koncepciju un galīgo rezultātu
• pārbaudiet, vai programmatūra darbojas tā, kā dizaineri plāno
• apstipriniet, ka galaprodukts atbilst klientu prasībām
• novērtēt īpašības un kvalitāti

Testēšana notiek saskaņā ar stingru plānu, lai optimizētu personāla prasmes, laiku un naudu, vienlaikus nodrošinot ieinteresētajām personām būtisku informāciju, lai produktu varētu virzīt uz priekšu. Mērķis ir veicināt labu gala lietotāju pieredzi, izmantojot spēcīgu kvalitātes nodrošināšanas programmu.Ar tik augstām likmēm, QA vadītāji ir daži no labākajiem tehnoloģiju nozares darbiniekiem. Testēšana parasti notiek pēc šīm darbībām:

1. Prasību analīze, kurā vadītāji izklāsta plānu ieviest piemērotu pārbaudes stratēģiju.
2. Testi sākas un rezultāti tiek analizēti.
3. Jebkuri defekti tiek izlaboti, un programmatūra iet caur regresijas testu - sistēmu, lai pārbaudītu, vai programma joprojām darbojas pēc modifikācijām.
4. Testa noslēguma ziņojumā detalizēti aprakstīts viss process un rezultāti.

Indivīdi var kļūt par sertificētiem programmatūras testētājiem, izmantojot tādas organizācijas kā BCS, The Chartered Institute for IT, ISTQB® (Starptautiskā Programmatūras testēšanas Kvalifikācijas padome) un ASQ (agrāk American Quality for Quality).

Programmatūras testēšanas metodes

Melnās kastes un baltās kastes testēšana ir divas galvenās metodes produktu uzvedības un veiktspējas novērtēšanai, bet ir arī citas metodes.

• Melnās kastes testēšana: Šo metodi sauc arī par funkcionālo vai specifikāciju testēšanu, šī metode ir vērsta uz produkciju. Testētāji nav saistīti ar iekšējiem mehānismiem. Viņi tikai pārbauda, ​​vai programmatūra dara to, ko vajadzētu darīt. Zināšanas par kodēšanu nav nepieciešamas, un testētāji strādā lietotāja interfeisa līmenī.
• Baltās kastes testēšana: Šī metode izmanto kodēšanas zinātību kā daļu no testa procedūras. Ja produkts neizdodas, testeri iet tik dziļi kodā, cik nepieciešams, lai atrastu cēloni. Programmatūras izstrādātāji to dara paši, jo tie nosaka, kā produktam vajadzētu darboties. Šai metodei ir citi uzbūves bāzes un stikla kastes testēšana.

• Statiskā pārbaude: Testētāji pārbauda programmatūras kodu un dokumentāciju, bet neveic programmu. Statiskie testi sākas produkta izstrādes laikā verifikācijas procesa laikā.
• Dinamiskā testēšana: Programmatūra tiek izpildīta ar dažādām ieejām, un testētāji salīdzina izejas ar paredzamo darbību ar šo metodi.
• Grafiskā lietotāja interfeisa pārbaude: Tas pārbauda GUI īpašības, piemēram, teksta formatēšanu, teksta kastes, pogas, sarakstus, izkārtojumu, krāsas, fontus, fonta lielumus utt. GUI testēšana ir laikietilpīga, un trešo pušu uzņēmumi bieži veic uzdevumu, nevis izstrādātājus.

Testa līmeņi

Dažādos testēšanas līmeņos tiek izmantotas vājās vietas un pārklāšanās katrā programmatūras izstrādes dzīves cikla fāzē.

• Vienības pārbaude: Izstrādātāji pārbauda koda galvenās daļas, piemēram, klases, saskarnes un funkcijas / procedūras. Viņi zina, kā viņu kodam ir jāatbild un var veikt korekcijas atkarībā no produkcijas.
• Komponentu testēšana: Citi nosaukumi ir moduļu vai programmu testēšana. Tas ir līdzīgs vienības testēšanai, bet tajā ir augstāks integrācijas līmenis. Programmatūras moduļi tiek pārbaudīti, lai pārbaudītu to individuālo funkciju.
• Integrācijas pārbaude: Tas identificē kļūdas, kad moduļi ir integrēti. Dažādi integrācijas testi ir no augšas uz augšu, uz augšu un funkcionāli.

• Sistēmas testēšana: Projekta sastāvdaļas tiek pārbaudītas kopumā dažādās vidēs ar šo metodi. Tas ietilpst melnās kastes metodē un ir viens no galīgajiem testiem šajā procesā. Tas nosaka, vai sistēma darbojas tā, lai tā atbilstu biznesa un lietotāju vajadzībām.
• Alpha testēšana: Iekšējie darbinieki pārbauda programmatūru izstrādātāja vietnē simulētā vai faktiskā vidē. Pēc tam izstrādātāji novērš kļūdas un citus jautājumus.
• Beta testēšana: Pazīstams arī kā lauka testēšana, klienti pārbauda produktu savās vietnēs reālos apstākļos. Klienti var piedāvāt galalietotāju grupai iespēju pārbaudīt programmatūru, izmantojot iepriekšējas versijas vai beta versijas. Pēc tam attīstītājam tiek nosūtīta atgriezeniskā saite par iespējamiem uzlabojumiem.

• Pieņemšanas pārbaude: Arī melnās kastes testēšanas ietvaros klienti testē programmatūru, lai noskaidrotu, vai attīstītājs ir izveidojis programmu vēlamajām specifikācijām.

Testa veidi

Dažādi programmatūras testu veidi ir paredzēti, lai koncentrētos uz konkrētiem mērķiem.

• Instalēšanas pārbaude: Programmatūras testēšanas inženieris un konfigurācijas pārvaldnieks veic šo testu, lai nodrošinātu, ka gala lietotājs var instalēt un palaist programmu. Tā aptver tādas jomas kā instalācijas faili, instalācijas vietas un administratīvās privilēģijas.
• Attīstības pārbaude: Tas īsteno virkni sinhronizētu stratēģiju defektu atklāšanai un novēršanai. Tas ietver statisko kodu analīzi, vienādranga pārskatus, izsekojamību un metriku analīzi. Mērķis ir samazināt riskus un ietaupīt izmaksas.
• Izmantojamības pārbaude: Ar šo testu uzmanība tiek pievērsta lietotāju pieredzei. Tā mēra, cik labi ir izstrādāta GUI, un tā lietošanas ērtumu. Pārbaude pārbauda funkciju precizitāti un efektivitāti un testējamo personu emocionālās atbildes.

• Sanity testēšana: Tas norāda, vai programmatūra ir vērts laiku un izmaksas, lai turpinātu testus. Ja ir pārāk daudz trūkumu, agresīvāki testi netiks ievēroti.
• Dūmu pārbaude: Dūmu pārbaude atklāj pamata neveiksmes, kas ir pietiekami nopietnas, lai novērstu atbrīvošanu. Kad tas tiek veikts jaunā būvē, to sauc par būvēšanas verifikācijas testu.
• Regresijas pārbaude: Kad sistēma tiek pārveidota, regresijas pārbaude uzrauga negaidītu uzvedību. Tas norāda uz negatīvo ietekmi uz moduļiem vai komponentiem.
• Destruktīva testēšana: Testētāji ievada nenormālus ierakstus un atklāj programmatūras spēju pārvaldīt negaidītu ievadi. Tas parāda izstrādātājiem, cik droša programma ir kļūdu pārvaldībā.
• Atgūšanas testēšana: Ja aparatūras vai citu funkciju neizdodas, šis tests parāda, cik labi programmatūra var atgūt un turpināt darbību.
• Automatizēta testēšana: Tas veic funkcijas, ko grūti īstenot manuāli. Tā izmanto specifisku programmatūru, lai veiktu testus un sniegtu datus par faktiskajiem un sagaidāmajiem rezultātiem.
• Saderības pārbaude: Programmatūrai ir jādarbojas dažādās skaitļošanas vidēs, tāpēc tā pārbauda saderību ar dažādām sistēmām. Piemēram, vai programmatūra darbojas ar dažādām operētājsistēmām un tīmekļa pārlūkprogrammām?
• Veiktspējas pārbaude: Šis ir padziļināts tests, kas pārbauda programmatūras veiktspēju dažādos scenārijos. Tiek apkopota informācija par atsaucību, stabilitāti, resursu piešķiršanu un ātrumu. Turklāt šajā procesā piedalās tādi apakštesti kā apjoms, ietilpība un smaile.
• Drošības pārbaude: Tas mēra programmatūras spēju aizsargāt lietotāju drošību. Tas nozīmē autorizācijas funkcijas, autentifikāciju, konfidencialitāti, integritāti, pieejamību un neatzīšanu.
• Pieejamības pārbaude: Tas nav tāds pats kā lietojamības pārbaude. Tas nosaka, cik lielā mērā programmatūras lietotāji var izmantot dažādas spējas - mācīšanās un fiziskās invaliditātes.
• Internacionalizācijas un lokalizācijas testēšana: Rezultāti parāda, kā programmatūra var pielāgoties dažādām valodām un reģionālajām prasībām. Tas ietver komponentu pievienošanu konkrētām atrašanās vietām un teksta tulkošanu.