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

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

2

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

3

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ā

4

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

5

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ā

6

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

7

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

N

ii 1

max(M )

N

ii 1

M

N N

i ii 1 i 1

max(M ) Q

N

i ii 1

(M Q )

N N

i ii 1i 1

M Q

EKTM Shēma Sarežģītība

N-parametru skaits

Mi-pieļaujamo vērtību EK skaits

Qi-nepieļaujamo vērtību EK skaits

Vājā

Stiprā

Robustā vājā

Robustā jauktā

Robustā stiprā

RVTM Shēma Sarežģītības augšējā robeža N-parametru skaits

Mi-pieļaujamo vērtību ekvivalences klašu skaits

Vājā vienkāršā ārējā

Stūra vājā iekšējā

Robustā sliktākā gadījuma

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

NN

ii 1

7 M

N

ii 1

4N M

NN 1

ii 1

(2 1) M

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

(4)

(7)

(15)

(1)(3)

(2)

(14)

(13)

(11)

(6)

(8)

(9)

(5)

(10)

(17)

(16)

(12)

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īvaisBiznesa ekspertiLieto funkcionālo testēšanuReālas situācijas, darbību secības, ievaddatiRobežgadījumi, ekvivalences klases – intuitīvi

o Problemātiskaiso Testpiemērs – darbību kopa, ne datio Pozitīvā testēšana – “taisnās taciņas”o Grūti testēt agri dzīves ciklāo Neredz neparedzētu sistēmas uzvedībuo Neprot veidot problēmziņojumuso 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

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

23

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

24

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

25

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

Ietvarā veidotas IS arhitektūra

28

Templates

Front-end Software

Back-end Software

Data Ontology

Data

DS

LInput

Documents Reports

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ā

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

31

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ā

Paldies!

“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

34

“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

35

“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 system approach 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

36