Mitä on sovellusten testaus?
Toimituksellinen tiimi
⚡ Älykäs yhteenveto
Sovellustestaus validoi koko ohjelmistotuotteen yksittäisen yksikön sijaan ja kattaa käyttöliittymän, toiminnon, tietokannan ja kuormituskäyttäytymisen. Tällä sivulla selitetään nelivaiheinen elinkaari, kolme testausmenetelmää, testisuunnittelu, työkalut, mittarit ja mobiilikohtaiset käytännöt.
Mitä on sovellusten testaus?
Sovellusten testaus määritellään ohjelmistotestaustyypiksi, joka suoritetaan komentosarjojen avulla ja jonka motiivi on löytää ohjelmistossa virheitä. Se käsittelee koko sovelluksen testejä.
Se auttaa parantamaan sovellusten laatua samalla, kun se alentaa kustannuksia, maksimoi ROI:n ja säästää kehitysaikaa.
Ohjelmistosuunnittelussa sovellustestausta voidaan tehdä eri luokissa, kuten GUI, toiminnallisuus, tietokanta (taustajärjestelmä), lataustesti jne.
Sovellusten testauksessa testauksen elinkaaret sisältävät useita vaiheita, jotka sisältävät vaatimusanalyysin, testisuunnittelun, testianalyysin, testisuunnittelun, testin suorittamisen ja virheraportoinnin jne.
Nämä vaiheet ratkeavat lyhyeksi, toistettavaksi elinkaareksi, jota jokainen sovellus noudattaa.
Kuinka testata sovellusta?
Ohjelmistosovelluksilla ja -tuotteilla on useita muunnelmia tukemiensa ominaisuuksien ja toteuttamiensa prosessien suhteen. Joten sovellustestaus varmistaa, että tietty ohjelma tai sovellus toimii oikein.
Sovellusten testauksen elinkaari käsittää neljä vaihetta.
- Vaihe 1) Suunnittele testisuunnitelmat sovellusvaatimusten perusteella
- Vaihe 2) Kehitä manuaalisia testitapauksia ja automaattisia testiskriptejä
- Vaihe 3) Suorita toiminnallisia testejä sovellusvaatimusten vahvistamiseksi
- Vaihe 4) Suorita kuormitustestit ja säädä sovelluksen suorituskykyä
Suoritettavien testien tyyppi riippuu testattavan sovelluksen tyypistä. Sovellusten testaus on luokiteltu 3 segmenttiin.
- Verkkosovellusten testaus
- Työpöytäsovellusten testaus
- Mobiilisovellusten testaus
| Sovelluksen testaus | Suoritetun testauksen tyypit |
|---|---|
|
|
|
|
|
|
Verkko-, työpöytä- ja mobiilisovellusten testauksen vertailu
Kolmella segmentillä on yhteinen elinkaari, mutta ne eroavat jyrkästi toisistaan siinä, mikä todellisuudessa katkeaa. Riskien keskittymisen tunteminen kertoo, mihin testausbudjetti kannattaa käyttää.
| Eron kohta | verkko | pöytä- | Puhelinnumero |
|---|---|---|---|
| Käy | Verkon kautta toimiva selain | Yksi asennettu kone | Luuri tai tabletti |
| Päämuuttuja | Selain ja versio | Operating-järjestelmä ja laitteisto | Laite, käyttöjärjestelmäversio ja näytön koko |
| Verkkoriippuvuus | aina yhteydessä | Usein offline-tilassa | Ajoittainen, ja tappion on selvittävä |
| Suurin riski | Selaintenvälinen renderöinti ja lataus | Asennus ja yhteensopivuus | Laitteiden välinen pirstoutuminen |
| Keskeytä käsittely | Harvoin relevantti | Harvoin relevantti | Puhelut, ilmoitukset ja heikko akku |
| Päivityspolku | Palvelinpuoli, välitön kaikille | Käyttäjä asentaa korjauspäivityksen | Sovelluskaupan arvostelu, vaiheittainen käyttöönotto |
Mobiililaitteet sisältävät eniten hallitsemattomia muuttujia, minkä vuoksi niitä käsitellään erikseen myöhemmin tällä sivulla.
Sovellusten testausmenetelmät
Testausmenetelmä on jäsennelty tapa varmistaa, että ohjelmistosovellus testataan täydellisesti. Epäjärjestäytynyt ja huono testausmenetelmä voi johtaa epävakaaseen tuotteeseen.
Testaus voidaan suorittaa kolmella tavalla.
- Musta Box Testaus
- Valkoinen Box Testaus
- Harmaa Box Testaus
Musta Box Testaus
Musta Box Testaus tekniikkaa käytetään yleisesti testaamiseen Toiminnallinen testaus, Ei-toiminnallinen testaus, ja regressiotestaus. Mustalaatikkotestauksessa käytetyt strategiat ovat
- Vastaavuusluokan testaus
- Raja-arvon testaus
- Päätöksen taulukon testaus
- Tilasiirtymätaulukot
Valkoinen Box Testaus
Valkoisen laatikon testaus käytetään tyypillisesti ohjelmistokoodin testaamiseen sisäisten tietoturva-aukkojen, rikkinäisten tai huonosti jäsenneltyjen polkujen, ehdollisten silmukoiden toimivuuden jne. tarkistamiseksi. Valkolaatikkotestauksessa käytetyt strategiat ovat
- Code Kattavuusanalyysi
- Reitin kattavuus
Harmaa Box Testaus
Tämä testaustekniikka on yhdistelmä molempia mustia Box Testaus sekä White Box -testaus. Se suoritetaan löytääkseen vikoja perustuu väärään rakenteeseen tai sovelluksen käyttöön.
Testisuunnitelma sovellustestausta varten
Testisuunnitelma asiakirja on johdettu tuotteesta Description, Software Requirement Specification SRS tai Käyttötapausasiakirjat. Testin painopiste on mitä testataan, miten testataan, milloin testataan ja kuka testaa. Testisuunnitelmaasiakirjaa käytetään viestintävälineenä testiryhmän ja testipäälliköiden välillä.
Sovellusten testauksen vakiotestaussuunnitelman tulisi määrittää seuraavat ominaisuudet;
- Määritä testauksen laajuus
- Määrittele testauksen tavoite
- Lähestymistapa toiminnan testaamiseen
- Testausaikataulu
- Vika trackuningas ja raportointi
Sovellustestauksen aloitus- ja lopetuskriteerit
Testaussuunnitelmassa luetellaan viralliset aloitus- ja lopetuskriteerit parhaana käytäntönä, mutta ne kannattaa kirjata selkeästi esiin. Ilman niitä testivaihe joko alkaa epävakaassa kokoonpanossa tai ajautuu eteenpäin ilman sovittua loppuviivaa.
Pääsykriteerit on täytettävä ennen toteutuksen aloittamista.
- Vaatimukset ja turvallisuusraportti tarkistetaan ja niiden lähtökohdat määritetään.
- Testaussuunnitelma ja testitapaukset kirjoitetaan ja hyväksytään.
- Koontiversio otetaan käyttöön vakaassa testiympäristössä ja se läpäisee savutestin.
- Testidata ja tarvittavat tilit tai laitteet ovat saatavilla.
- Vika tracking-työkalu on konfiguroitu ja tiimillä on käyttöoikeudet.
Poistumiskriteerit osoittaa, että vaihe on täyttänyt tarkoituksensa.
- Kaikki suunnitellut testitapaukset suoritetaan ja tulokset kirjataan.
- Yhtään kriittistä tai vakavaa vikoja ei ole jäljellä.
- Sovittu vaatimusten mukainen kattavuus saavutetaan.
- Jäljelle jäävät, lievät viat dokumentoidaan ja yritys hyväksyy ne.
- Testin yhteenvetoraportti on allekirjoitettu.
Sovellusten testaustyökalut
Sovellusten testaamiseen on olemassa erilaisia testaustyökaluja. Työkalujen valinta riippuu siitä, minkä tyyppisen testauksen haluat suorittaa. Eri alustoille suositellaan erilaisia työkaluja. Sovellusten testaustyökalut varmistavat sovellusten suorituskyvyn, käytettävyyden ja toimivuuden useilla eri laitteilla.
Tässä muutamia niistä.
- Selenium
- IBM Rational Functional Tester (RFT)
- Hienosäätö (nyt OpenText LoadRunner, aiemmin HP ja Micro Focus)
- Apache JMeter
💡 Huomaa: IBM Rational Robot, joka on pitkään ollut listalla RFT:n rinnalla, on vedetty pois markkinoilta. Rational Functional Tester on nykyinen IBM tarjontaa, joten uusia projekteja ei pitäisi suunnitella Robotin ympärille.
Sovellustestauksen keskeiset mittarit
Testien suorittaminen osoittaa aktiivisuutta, ei tehokkuutta. Pieni joukko mittareita osoittaa, löytääkö testaus todella vikoja ja konvergoiko sovellus julkaisun laadun suhteen.
- Testin kattavuus: Vaatimusten osuus, joilla on vähintään yksi kartoitettu testitapaus. Alhainen kattavuus tarkoittaa testaamatonta toimintaa riippumatta läpäisyprosentista.
- Vika tiheys: Viat jaettuna koon mukaan, yleensä tuhatta koodiriviä tai moduulia kohden. Se osoittaa komponentit, jotka vaativat uudelleentyöstöä lisätestauksen sijaan.
- Vika vuoto: Tuotannossa löydetyt viat jaettuna löydettyjen vikojen kokonaismäärällä. Kasvava vuoto on selkein merkki siitä, että julkaisua edeltävästä testauksesta puuttuu jotain.
- Vianpoiston tehokkuus: Ennen julkaisua löydettyjen vikojen osuus kaikista vioista. Yli 90 prosentin luku on yleinen tavoite.
- Testin suoritusnopeus: Tapaukset ajautuvat suunniteltuja tapauksia vastaan, tracked sykliä kohden, joten lipsuminen näkyy aikaisin eikä vasta poistumisportilla.
TracTarkastele trendiä yksittäisen lukeman sijaan. Yksittäinen sykli kertoo hyvin vähän.
Sovellusten testauksen parhaiden käytäntöjen testaus
Oikean strategian valitseminen sovellustestaukselle on taattu tapa havaita sovelluksen viat. Siksi on erittäin tärkeää, että laadunvarmistustiimi noudattaa standardiprosessia havaitakseen enemmän virheitä ja vähemmän aikaa.
Sovelluksen testauksen parhaita käytäntöjä ovat mm
- Määritä toiminnalliset tiedot
- Revtarkastukset ja tarkastukset
- Muodolliset maahantulo- ja poistumiskriteerit
- Toiminnalliset testimuunnelmat
- Monialustainen testaus
- Automaattinen testin suoritus
Sovellusten testauksen haasteet
Sovellusta testatessaan testaaja voi kohdata monia haasteita
- Ongelmat tunnistetaan vain, kun käyttäjä soittaa
- Kyvyttömyys ennakoida muutoksen vaikutuksia
- Ei näkyvyyttä sovellus- ja toimintavirheistä
- Aikaavievä
Mobiilisovellusten testaus
Kuten verkkosovellusten testaus, Puhelinnumero Sovellustestaus perustuu myös samaan testausstrategiaan ja -menetelmään. Ero voi olla testauksessa käytettävissä työkaluissa. Joitakin yleisiä mobiilisovellustestauksessa käytettyjä työkaluja ovat Appium, TestComplete, Robotiumja Espresso.
Mobiilisovellustyypit luokitellaan kolmeen osioon
- Verkkosovellus - Käyttäjät käyttävät sitä verkon, kuten Internetin tai intranetin, kautta
- Alkuperäinen sovellus - Se on kehitetty tietylle alustalle ja asennettu tietokonelaitteeseen
- Hybridisovellus – Se yhdistää sekä verkko- että natiivisovellusten elementtejä, esimerkiksi Facebookin.
Useimmissa mobiilialustassa voit käyttää yksinkertaista CSS-, HTML-, JS- jne.
Esimerkkitestitapauksia mobiilisovellusten testaamiseen
Täydellinen mobiilitestaussovellusstrategia sisältää laite- ja verkkoinfrastruktuurin, kohdelaitteiden valinnan sekä tehokkaan manuaalisten ja automaattisten testaustyökalujen yhdistelmän, joka kattaa molemmat ei-toiminnallinen ja toiminnallinen testaus.
Mobiilisovelluksen osalta testattavat asiat ovat
- Asennus
- OTA
- Wi-Fi
- Datakaapeli
- Bluetooth:
- uninstallation
- Sovelluksen logo
- Roiskahtaa
- Muisti vähissä
- Visuaalinen palaute
- Poistu sovelluksesta
- Sovelluksen aloitus/uudelleenkäynnistys
Mobiilitestauksen haasteet
Mobiilikäyttäjien ja -laitteiden määrän kasvaessa mobiilisovelluksen testaamisesta tulee yhä monimutkaisempaa. Mobiilisovelluksen testaus eroaa merkittävästi työpöytäpohjaisen verkkosovelluksen testaamisesta. Yleisimpiä mobiilitestauksen haasteita ovat
- Kattava testikattavuus
- Hajanaisuuden hallinta (eri käyttöjärjestelmäversio, prosessori, muisti)
- Testisuunnitelman puute
- Aikapaine
- Fyysisten laitteiden puute
- Monimuotoisuus alustassa ja käyttöjärjestelmässä
