Sarežģītību noteikta programmatūras testēšana

1. Sarežģītību noteikta programmatūras testēšana Vineta Arnicāne, LU DF pētniece Vadītājs prof.J.Bičevskis 23.04.2013. Darbs izstrādāts ar Eiropas Sociālā fonda atbalstu projektos: - “Datorzinātnes pielietojumi un tās saiknes ar kvantu fiziku” Nr.2009/0216/1DP/1.1.1.2.0/09/APIA/VIAA/044 - «Atbalsts doktora studijām Latvijas Universitātē» Nr.2009/0138/1DP/1.1.2.1.2./09/IPIA/VIAA/004

2. Saturs • Darba mērķis, problēma, aktualitāte • Tehnoloģiskā sarežģītība - domēntestēšanas metožu sarežģītības novērtējumi • Organizacionālā sarežģītība • Ne-IT cilvēku iesaistīšana programmatūras testēšanā un izstrādē • SUP (Sponsor-User-Programmer) modelis • Daudzaģentu pieeja • IS izstrādes ietvars • Nobeigums

3. Sarežģītība Raksturojums, kas parāda ar kādas datu apstrādes problēmas risināšanu saistītās grūtības un ko parasti izsaka kāda šīs problēmas risināšanas gaitā patērējamā resursa terminos. Tā, piemēram, algoritmu var raksturot ar tā izpildes laika atkarību no apstrādājamo datu apjoma.1 1Akadēmiskā terminu datubāze AkadTerm, http://termini.lza.lv/term.php?term=sare%C5%BE%C4%A3%C4%ABt%C4%ABba&list=&lang=LV, skatīts 15.11.2012

4. Tehnoloģiskās un organizatoriskās sarežģītības • Tehnoloģiskā sarežģītība - grūtības, kas rodas tīri tehniski, izpildot testēšanas uzdevumu piemēram: • cik testpiemēru nepieciešams izpildīt, lai notestētu programmatūru atbilstoši kādai testēšanas metodei • cik daudz laika prasa testkomplekta izveide, izpilde, rezultātu novērtēšana • Organizatoriskās – grūtības testēšanas procesu pārvaldībā piemēram: • testēšanas komandas lielums un dažādība • testēšanas metožu un tehniku izvēle • uzdevumu sadales principi komandā

5. Aizstāvēšanai izvirzītās tēzes • Programmatūras testēšanas tehnoloģiskā sarežģītība ir tik liela, ka atbilstoši domēntestēšanas metodei nav iespējams pilnībā notestēt vairumu praksē sastopamo programmatūru • Problēmas, ko izraisa programmatūras testēšanas tehnoloģiskā sarežģītība, ir iespējams pārvarēt, mainot testēšanas procesu organizatoriskās sarežģītības - organizatorisko struktūru un procesu pārvaldības principus

6. Pētāmie jautājumi • Programmatūras testēšanas tehnoloģiskā sarežģītība – metožu sarežģītības novērtējumi • Programmatūras testēšanas organizatoriskās sarežģītības ietekmēšanas iespējas • SUP (Sponsor-User-Programmer) modelis • neIT cilvēku iesaistīšanā testēšanā • daudzaģentu sistēmu principu izmantošana • programmatūras izstrādes ietvars gala lietotāju iesaistīšanai izstrādē un testēšanā

7. Tehnoloģiskās sarežģītības • Apskatītās metožu grupas: • Ekvivalences klašu testēšana • Robežgadījumu testēšana • Kombinācijtestēšana • Modeļbāzētā testēšana • Tehnoloģisko sarežģītību veidi: • Izveidotā testkomplekta apjoms • Testkomplekta izveides algoritma sarežģītība • Testkomplekta izpildes un rezultātu novērtēšanas sarežģītība • Testkomplekta uzturēšanas sarežģītība

8. Ekvivalences klašu testēšanas metožu (EKTM) sarežģītība

9. Dažu robežvērtību testēšanas metožu (RVTM) sarežģītība

10. N – programmas parametru skaits, • Mi – parametra Xi pieļaujamo vērtību ekvivalences klašu skaits, • Qi – parametra Xi nepieļaujamo vērtību ekvivalences klašu skaits • Li – parametra Xi pieļaujamo vērtību ekvivalences klašu kopīgo robežvērtību skaits

11. N – programmas parametru skaits, • Mi – parametra Xi pieļaujamo vērtību ekvivalences klašu skaits, • Qi – parametra Xi nepieļaujamo vērtību ekvivalences klašu skaits • Li – parametra Xi pieļaujamo vērtību ekvivalences klašu kopīgo robežvērtību skaits

12. Testēšanas metožu iekļautība Metode M1 iekļauj(subsume)M2, ja katrai testējamai programmai p, specifikācijai s un testkomplektam t no tā, ka t ir adekvāts M1 testējot p pret s, seko, ka t ir adekvāts M2 for testējot p pret s

13. (9) (12) (16) (4) (11) (6) (17) (13) (10) (14) (5) (2) (7) (15) (3) (8) (1)

14. Rezultāti • Ekvivalences klašu testēšanas un robežvērtību testēšanas metodes: • Izveidots pārskats par avotos minētajām metodēm • Veikti testēšanas metožu sarežģītības novērtējumi ģenerētā testkomplekta apjoma nozīmē • Izveidota metožu iekļautības hierarhija • Identificētas tradicionālās testēšanas, kas balstīta uz vērtību apgabalu testēšanas modeļiem, galvenā problēma – sarežģītība, kas praktiskos lietojumos padara neiespējamu šo testēšanas modeļu lietošanu [Arn09] Arnicane, V. Complexity of Equivalence Class and Boundary Value Testing Methods, In: Scientific Papers University of Latvia, (Bārzdiņš, J., ed.),Vol 751, Computer Science and Information Technologies, University of Latvia, 2009, pp. 80-101

15. Testēšanas sistēma – kompleksa adaptīva socio-tehniska sistēma • Testēšanas sistēma • Testētāji – viņu prasmes un iemaņas: • Testēšanā • Testējamās programmatūras biznesa jomā • Testējamā programmatūra (prasības, dokumentācija, kods) • Testēšanas vide – datori, tīkli, telpas, līdzprogrammatūra, rīki... • Izstrādātāji, lietotāji, pasūtītāji • Ārējā sarežģītība • Testēšanas mērķi, uzdevumi • Ierobežojumi – laiks, budžets • Kompleksa uzvedība • Pašorganizācija • Evolūcija un ko-evolūcija • Emerģence

16. SUP (Sponsor-User-Programmer) modelis

17. SUP modelis un adekvāto darbību shēma

18. SUP modelis un sarežģītība • Strukturāli modelis nav sarežģīts • Ļauj skaidrāk izprast situāciju projektā katrai no iesaistītajām pusēm – samazina viņu darba sarežģītību • Prasa veltīt laiku un resursus modeļa uzturēšanai – palielina sarežģītību • Palielina iespēju, ka pretrunas prasībās, aplamas prasības tiks atklātas agri – samazina projekta kopējo sarežģītību – izmaksas, laiku

19. Ne-IT testētāji testēšanas procesā • Pozitīvais • Biznesa eksperti • Lieto funkcionālo testēšanu • Reālas situācijas, darbību secības, ievaddati • Robežgadījumi, ekvivalences klases – intuitīvi • Problemātiskais • Testpiemērs – darbību kopa, ne dati • Pozitīvā testēšana – “taisnās taciņas” • Grūti testēt agri dzīves ciklā • Neredz neparedzētu sistēmas uzvedību • Neprot veidot problēmziņojumus • Neprot strādāt ar datu bāzēm

20. Ne-IT testētāji un testēšanas sarežģītības samazināšana • Apmācības testēšanai vajadzīgajās prasmēs • Informācija motivācijai un izpratnei • Par testētāju lomu projektā, par testēšanas mērķiem • Testētāju grupas vieta projekta komandā, testēšanas un komandas darba psiholoģiskie aspekti • Vadības un darba organizācijas aspekti • Testētājam jājūt, ka viņa vārdam ir autoritāte un ka viņa darbs ir vajadzīgs • Vadītājam ir ļoti uzmanīgi jāseko līdzi testētāja izmantotā laika sadalījumam • Ir bīstami, ja ne-IT testētāji ir pakļauti izstrādes grupas vadītājam • Nepieciešams veidot arī savus iekšējos problēmu reģistrus • Jāveido vārdnīca • Daudzaģentu sistēmu principu izmantošana

21. Daudzaģentu sistēmu principi darbā ar ne-IT testētājiem • Aģenti • Uzskatam, ka visi darba darītāji ir primitīvi aģenti (var pieņemt, ka aģents ir cilvēka prasme un spēja veikt noteiktu darbību). • Atpazīstam katrā darbiniekā vai programmatūrā viņos mītošos aģentus, lai noskaidrotu, ar ko mēs varam operēt. • Noskaidrojam katra darbinieka vai programmatūras zināšanas un iespējas apgūt jaunas zināšanas un prasmes. • Standartiskiem un paredzamiem darbiem var izmantot zemākas kvalifikācijas aģentus-personas vai aģentus-programmatūru. • Nestandarta un inovatīviem darbiem jāizmanto augstas kvalifikācijas aģenti-personas un retāk aģenti-programmatūra. • Uzdevumi • Dalām problēmu uzdevumos, kurus sadalīt sīkāk apakšuzdevumos tik ilgi, kamēr katram primitīvajam uzdevumam var piemeklēt aģentu, kas to var veikt. • Dalām uzdevuma risinājumu jeb procesu atsevišķās nelielās darbībās un aktivitātēs, lai samazinātu procesa sarežģītību. • Noskaidrojam kritiskos uzdevumus, izvērtējot riskus no visu izpildītāju (pasūtītājs, izpildītājs, lietotājs) redzespunkta. • Noskaidrojam kritiskos uzdevumus, kuru izpildei ir aģentu deficīts.

22. Aģentbāzētās modelēšanas principi darbā ar ne-IT testētājiem • Darbības - nodrošināmies, lai operāciju ķēde neapstātos aģentu pasivitātes dēļ • Koordinācija • C1: Veicam stratēģijas nodrošināšanas un darbu veikšanas kontroles pasākumus, lai sasniegtu vēlamos mērķus. • C2: Izveidojam kooperēšanās iespēju un izdevīgumu starp aģentiem, jo pašorganizējošās sistēmas ir daudzkārt efektīvākas un dzīvotspējīgākas kritiskos apstākļos. Uzmanāmies, lai aģenti neaizrautos ar privāto mērķu piepildīšanu, ignorējot visas sistēmas mērķus. • C3: Izpētām, kādi koordinācijas mehānismi darbojas sistēmā un nodrošinām to līdzsvaru • Spējas • F1: Apzinām katra aģenta svarīgākās spējas, kas viņam piemīt. • F2: Apzinām svarīgākās spējas, kas nepieciešamas kritisko uzdevumu izpildei. • F3: Apzinām variantus, kā iztrūkstošās spējas var aizstāt ar esošajām spējām, iespējams, izvēloties citus risinājumus problēmai. • F4: Apzinām iespējas, kā iegūt iztrūkstošās spējas un nodrošinām to pakāpenisku iegūšanu

23. Rezultāti • Tiek piedāvāts programmatūras testēšanas procesos pielietot daudzaģentu sistēmu organizatoriskos principus, kas: • ļauj samazināt testēšanas sarežģītību • palīdz risināt testētāju kvalifikācijas problēmas, iesaistot galalietotājus sistēmas izstrādē un testēšanā • Piedāvāts testēšanas teorijā oriģināls modelis (SUP modelis) testēšanas efektivitātes paaugstināšanai, kuru raksturo nepieciešamība ņemt vērā sistēmu izstrādē iesaistīto dalībnieku atšķirīgu skatījumu uz veidojamo sistēmu

24. Rezultāti [Arn07] Arnicane, V. Use of Non-IT Testers in Software Development. In:8th International Conference on Product Focused Software Process Improvement (PROFES 2007), LNCS, (Münch, J., Abrahamsson, P., eds.), vol. 4589, Berlin, Springer, 2007, pp. 175-187 [AA09b] Arnicane, V., Arnicans, G. Using the Sponsor-User-Programmer Model to Improve the Testing Process, In: Scientific Papers University of Latvia (Bārzdiņš, J. ed.), vol 751, Computer Science and Information Technologies, University of Latvia, 2009, pp. 65-79 [AA08] Arnicane, V., Arnicans, G. Using the Principles of an Agent-Based Modeling for the Evolution of IS Testing Involving Non-IT Testers. In:Proceedings of 8th International Baltic Conference on Databases and Information Systems (Baltic DB&IS 2008) (Haav, H. M., Kalja A. eds.), June 2-5, Tallinn, Estonia, Tallinn University of Technology Press, 2008, pp. 129-140

25. Rezultāti [AA09a] Arnicane, V., Arnicans, G. Opportunities to Improve Software Testing Processes on the Basis of Multi-Agent Modeling, In: Frontiers in Artificial Intelligence and Applications. Databases and Information Systems V - Selected Papers from the Eighth International Baltic Conference, DB&IS 2008 (Haav, H.M., Kalja A. eds.), vol 187, IOS Press, Amsterdam Berlin Oxford Tokyo Washington, DC, 2009, pp. 143-154 [AA11] Arnicane, V., Arnicans, G. Evolutionary Reduction of the Complexity of Software Testing by Using Multi-Agent System Modeling Principles, In: Multi-Agent Systems - Modeling, Interactions, Simulations and Case Studies (Alkhateeb, F., Al Maghayreh, E., Abu Doush, I. eds.), InTech, 2011, pp. 149-174

26. Ietvars programmatūras izstrādei ar ne-IT cilvēku piedalīšanos programmēšanā • Programmatūra • Uzdevums – statistikas datu uzglabāšana • Daudz ievadformu, bet divi tipi • Fiksēta tabula • Tabula ar nezināmu rindiņu skaitu • Daudz atskaišu, bet trīs tipi • Fiksēta tabula • Tabula ar izvērsumu vienā virzienā • Tabula ar izvērsumu divos virzienos • Problēmas • Liels ievadformu un atskaišu skaits • Lietotāju un pasūtītāju pretrunīgas prasības • Izstrādātāju un testētāju skaits – mazs

27. Izstrādes ietvara risinājums • Viena programmatūra uz visām lietotāju saskarnēm • Lietotāju saskarnes definē paši lietotāji MS Excel vidē • Ieguvumi: • Lietotāji savā starpā spiesti vienoties, kādu saskarni vēlas • Lietotāji iegūst precīzi tādu saskarni, kādu izveidojuši • Jaunas saskarnes izveidošana izstrādē – ātra, nav nekas jāprogrammē • Jaunas saskarnes testēšana – ātra • Programmu testēšana – ļoti komplicēta, bet reti veicama, jo maz mainās lietotāju jaunu prasību dēļ • Trūkumi: • Saskarņu kopējās programmatūras sarežģītība liela

28. Ietvarā veidotas IS arhitektūra

29. Ietvara pielietojumi • 2 sistēmas, dzīves ilgums – 15 un 11 gadi • Saskarņu skaits: • 1.sistēma • ievadformas 205 • atskaites 1397 • 2.sistēma • ievadformas 132 • atskaites 185 • Programmatūra pārrakstīta “no nulles”, pārejot uz jaunu vidi • Izstrādes pieeja saglabāta

30. Ietvara izmantojums un sarežģītība • Saskarņu izstrādes un lietojamības testēšanas sarežģītība – pilnībā lietotāju ziņā • Programmu izstrādes un izmaiņu veikšanas sarežģītība – liela • Jaunu saskarņu pievienošanas sarežģītība IT departamentā – ļoti maza • Jaunu saskarņu testēšanas sarežģītība IT departamentā – ļoti maza • Ieguvums, salīdzinot ar COCOMO novērtējumu • 5 cilvēkmēneši pret 244 cilvēkmēnešiem 9 mēn. laikā • 31.5 cilvēkmēneši pret 142 cilvēkmēnešiem 8 mēn. laikā

31. Rezultāti • Tiek piedāvāts radoši pieiet ne-IT darba uzdevumiem sistēmu izstrādē, panākot savstarpējās izpratnes uzlabošanos un relatīvi nolīdzinot darba sarežģītību starp izstrādātājiem – IT cilvēkiem un ne-IT cilvēkiem, kā arī testētājiem [Arn11] Arnicane, V. End-User Development Framework with DSL for Spreadsheets, In: Perspectives in Business Informatics Research, Local Proceedings, 10th International Conference, BIR 2011 Associated Workshops and Doctoral Consortium, (Niedrite, L. Strazdina, R., Wangler, B. eds.), Riga Technical University, 2011, pp. 437-447 [Arn00] Arnicāne, V. Statistikas sistēmu datu ievades un atskaišu formu izstrādes metodoloģija, Ekonomikas un vadības zinību attīstības problēmas, Latvijas Universitātes zinātniskie raksti, 628.sējums, 2000, Rīga, pp. 9-12

32. Nobeigums • Ekvivalences klašu testēšanas un robežvērtību testēšanas metodes: • Izveidots pārskats par avotos minētājām metodēm • Veikti testēšanas metožu sarežģītības novērtējumi • Izveidota metožu iekļautības hierarhija • Izstrādāts SUP modelis un tā darbības principi izstrādes procesa uzlabošanā ar testēšanas palīdzību • Piedāvāts uzskatīt testēšanas sistēmu par kompleksu sistēmu • Definēti daudzaģentu modelēšanas principi izmantošanai testēšanas procesos • Izveidots ietvars IS izstrādei, iesaistot ne-IT cilvēkus izstrādē un testēšanā

33. Paldies!

34. “The lack of methodology description...” • 1.daļa - testēšanas tehnoloģiskā sarežģītība: • Ir veikti metožu domēntestēšanas sarežģītības novērtējumi no augšas un apakšas • Ir veikts literatūrā aprakstīto sarežģītības novērtējumu apskats citām metodēm, piemēram, kombinācijtestēšanai, modeļbāzētajai testēšanai • 2.daļa - organizacionālā sarežģītība • Ir problemātiski pierādīt, jo saistīta ar cilvēku izvēlēm

35. “The lack of comparative literature review...” “...publications are from the 1990s – 15-20 years old...” • Tehnoloģiskie aspekti – literatūras apskats ir, meklēti arī metožu izveidošanas pirmssākumi, sākot no 20.gs. 70-tajiem gadiem • Organizacionālie aspekti – piedāvāti oriģināli risinājumi, atbilstošas literatūras nav, izmantotā literatūra vairākumā gadījumu ir publicēta pēc 2000.gada

36. “The lack of presentation of rigorous (or any!) testing of the presented SUP model in practice...” “The same as above for the conjectures on multi-agent systemapproach to software testing process organization...” • Tiek piedāvāts līdzeklis darba sakārtošanai, kas izmantots reāli praksē • Trūkums – nav aprakstīti reālie piemēri • Arī SUP modelis demonstrē daudzaģentu sistēmu principu pielietojumu