Performanța aplicațiilor este un subiect frecvent abordat, indiferent de natura apreciativă sau critică a contextului.Această performanță este de obicei clasificată ca fiind una din primele trei coordonate de impact asupra reputației și veniturilor unei companii și de asemenea asupra satisfacției clientului.
Am ales acest subiect deoarece testarea performanței unei soluții Desktop nu oferă o documentație extensivă pe internet sau un suport atât de bogat cum ne-am fi așteptat. Din acest motiv m-am gândit să împărtășesc nu doar din experiența proprie, dar și din cunoștințele altora exprimate în idei, orientări, preocupări sau riscuri de luat în considerare atunci când ni se cere să îndeplinim o astfel de sarcină.
Dacă vorbim de performanța unei aplicații, ar trebui să convenim încă de la început ce înțelegem prin "performanță". Vorbim de viteza de reacție a aplicației? Resursele consumate? Altceva?
În aplicațiile desktop aceasta poate avea diferite semnificații, pe care le voi explica în articolul de față.
Arhitectura
Din punct de vedere arhitectural există câteva stiluri de aplicații desktop. Layer-ele sunt în mare parte aceleași, dar așezarea lor sau interacțiunea dintre ele generează mai multe tipuri de aplicații desktop.
Printre cele mai utilizate layer-e amintim: UI (User Interface), BL (Business Layer), TL (Transfer Layer) and DB (Database Layer).
Voi menționa câteva exemple de arhitecturi folosite pe platforma desktop cu precizarea că nu acoperă toate combinațiile dintre tipurile și stilurile arhitecturale:
100% pur desktop - unde atât clientul cât și serverul împreună cu baza de date sunt instalate pe aceeași mașină, fără a avea nevoie de conexiune la rețea. Un exemplu aici poate fi Microsoft Money (o aplicație de managementul finanțelor destinată utilizatorului casnic). Este o aplicație pe un singur nivel (1-Tier), instalată și rulată pe un singur sistem de către un singur user.
O altă soluție în arhitectura Client-Server este folosirea așa numitului "Thin Client", care în acestă arhitectură (2-Tier) este folosit nu cu mult peste preluarea comenzilor utilizatorului și afișarea informațiilor prin intermediul unui monitor. Aplicația este copiată și instalată pe server, rulată la nivel de client, și folosită pe scară largă în infrastructurile de tip intranet ale universităților sau fabricilor. Un exemplu putând fi un student care folosește un client CITRIX instalat pe mașina proprie și rulând o aplicație internă pe serverul universității.
Aplicația Client-Server care folosește mai mulți clienți de tip "Rich Client" și unul sau mai multe Servere este cea mai întâlnită arhitectură pe platforma Desktop.
Această aplicație este desenată de asemenea pe două nivele (2-Tier) și utilizată cu precădere într-o infrastructură de tip intranet având un număr limitat de utilizatori. Conexiunea persistă până la log-out, iar aplicația este manipulată utilizând un meniu.
Un exemplu poate fi Microsoft Outlook sau oricare altă aplicație desktop pentru e-mail. Aplicația este instalată pe mașina locală, care se conectează din când în când sau permananet la server pentru primirea sau trimiterea email-urilor. Bineînțeles, această aplicație funcționează și fără conexiune la server, dar fără această conexiune nu se va putea duce la bun sfârșit operația de trimitere a unui e-mail.
Abordare
Testarea aplicațiilor client-server necesită câteva cunoștințe tehnice adiționale pentru a putea trata anumite efecte introduse de arhitectura client-server. De exemplu - separarea sau mutarea business layer-ului de pe client pe server ar putea crește încrederea și stabilitatea în datele oferite, dezavantajul fiind creșterea traficului pe rețea sau vulnerabilitatea în cazul unui atac de securitate.
Testarea acestor sisteme este într-adevar mai diferită comparativ cu testarea aplicatiilor web, dar această diferență nu este chiar atât de mare. Am putea chiar afirma că se apropie mai mult de testarea pe platforma mobile.
Ca să înțelegem cum putem testa aceste sisteme trebuie întâi să înțelegem exact când și de ce ar putea apărea aceste probleme de performanță. Având această înțelegere, soluția care ar trebui abordată în testare de multe ori este evidentă.
Testarea la nivel de client este mai mult percepută ca o testare funcțională. Acest lucru se întâmplă din cauză că aplicațiile desktop sunt concepute pentru a fi manipulate de un singur utilizator. Nu este adecvată abordarea testării performanței folosind abordarea specifică web. Dacă înregistrăm un flow după care folosim 100 de utilizatori virtuali cu scopul de a testa performanța întregului sistem, ne înșelăm. În acest caz nu vom testa performanța întregului sistem ci software-ul și hardware-ul stației pe care rulează testul/ele. De asemenea, resursele acesteia se vor consuma, fapt care va duce la blocare.
Testarea la nivel de client trebuie realizată luând în considerare următoarele aspecte:
Impactul acțiunilor utilizatorului - cât de rapid răspunde sistemul la solicitările venite de la utilizator;
Impactul asupra resurselor sistemului utilizatorului - cât de "light" este aplicația pentru stația utilizatorului. De exemplu: cât de rapid se deschide aplicația, câtă memorie utilizează sau compatibilitatea aplicaței cu alte aplicații instalate.
Partea de back-end dintr-o aplicație client-server este de obicei zona unde se concentrează testarea performanței. De multe ori abordarea pe partea de server este destul de apropiată față de cea folosită pentru Web: se înregistrează un flow sau mai multe, se creează unul sau mai multe profiluri de utilizatori finali (aici putem include comportamentul și numărul utilizatorilor pe fiecare flow sau chiar performanța stațiilor sau a rețelelor). Bazându-ne pe aceste profiluri putem aloca un număr diferit de utilizatori virtuali și rula acele teste de la nivel de Service-layer. Serverul ar trebui să poată procesa solicitări concurente venind de la diferiți clienți, având diferite profile.
Pe diverse canale de informare (prezentări, forumuri) am aflat că pentru a testa aplicații client-server, unii testeri au decis să folosească mai multe stații (de la 2 la 5) în calitate de clienți, pentru amble tipuri de testări funcțional-automatizată și de performanță. Fiecare stație era setată conform unui anumit profil care să simuleze un anumit grup de utilizatori finali, și care evident să exercite un stres specific pe întreaga structură.
Tool-uri
Dacă este să comparam tool-urile de pe piață care oferă suport pentru testarea performanței aplicațiilor Desktop și cele orientate Web, am putea afirma că există un dezechilibru; destul de puține în prima categorie. Însă și mai puține tool-uri oferă suport pe mai multe platforme cum ar fi: Desktop, Web sau Mobile.
Din experiență proprie și din investigațile făcute, am remarcat câteva tool-uri:
Apache JMeter - unul dintre cele mai cunoscute tool-uri gratuite și folosite mai cu seamă în testarea performanței la nivel de server, bază de date sau servicii; JMeter-ul nu controlează elementele grafice la nivel de interfață a utilizatorului în aplicațiile Desktop (de exemplu nu simulează apăsarea unui buton, scroll-ul sau poziția mouse-ului pe ecran), fapt pentru care nu este un tool potrivit pentru testarea performanței aplicațiilor desktop la nivel de interfață a clientului. Jmeter-ul este construit pentru a exercita un anumit stres asupra aplicațiilor care folosesc mai multe thread-uri sau utilizatori. Din moment ce avem o aplicație instalată pe un client, cel mai probabil vom avea un singur utilizator și nu ar avea niciun sens folosirea acestui tool în acest context. În schimb, mai multă logică ar avea testarea performanței unei baze de date independent de aplicația desktop
Telerik Test Studio - rulează teste funcționale ca teste de performanță, oferind o vizionare destul de avansată asupra rezultatelor testelor, perspectivă cronologică și comparații între mai multe teste. Acest tool este construit pentru testarea performanței aplicațiilor pe platforma Web și Desktop WPF (Windows Presentation Foundation). Nu are suport pentru aplicațiile construite pe tehnologia Windows Forms.
WCFStorm - este un tool simplu și ușor de utilizat pentru testarea serviciilor WCF (Windows Communication Foundation). Acesta suportă aproape toate tipurile de conexiuni netTcpBinding, wsHttpBinding și namedPipesBinding, cu excepția webHttp. De asemenea, poate fi utilizat pentru crearea de test case-uri funcționale și de performanță.
Datorită timpului limitat, nu am reușit să verific și alte tool-uri promovate în diferite prezentări, articole sau forum-uri. Le-aș adăuga totuși pentru a oferi o perspectivă mai bogată asupra acestui aspect: Microsoft Visual Studio, Borland Silk Performer, Seapine Resource Thief, Quotium Qtest Windows Robot (WR), LoginVSI, TestComplete împreună cu AQtime, WCF Load Test, Grinder sau Load Runner.
Într-un sistem clasic client-server, partea de client este o aplicație care trebuie instalată și utilizată de către un singur utilizator, ceea ce înseamnă că în majoritatea cazurilor nu se așteaptă ca aplicația să execute o mulțime de call-uri concurente, însă trebuie să răspundă cât mai prompt acțiunilor utilizatorului și să afișeze rezultatele fără o întârziere prea mare.
Aplicația instalată pe client precum și resursele consumate de aceasta este de obicei monitorizată cu ajutorul unui instrument numit Profiling.
Acest Profiling împreună cu un Performance Counter la nivel de SQL de exemplu, poate constitui o metodă solidă pentru a realiza ce se întâmplă de fapt in sistem (client și server).
Visual Studio are un profiler integrat. Fiind destul de avansat, permite măsurarea timpului necesar executării unei metode, precum și numărul apelărilor.
Pentru realizarea unui profiler la nivel de memorie, CLR Profiler permite vizualizarea consumului de memorie necesar rulării aplicației, dar și observarea obiectelor create de diferite metode.
Multe dintre tool-urile construite pentru testarea performanței de la nivel de interfață al utilizatorului pot fi folosite pentru înregistrarea unor flow-uri și mai târziu folosite pentru play-back pe mai multe stații.
Rezultate
Câteva dintre problemele identificate în urma testării performanței aplicațiilor desktop ar putea fi menționate:
Multe instanțe de SQL, greșit concepute. După optimizare, performanța s-a îmbunătățit simțitor.
Câteva SQL statement-uri care erau executate în mai mult de un minut, au fost îmbunătățite astfel încât să returneze rezultate în mai puțin de o secundă.
Câteva view-tables au fost identificate ca fiind incorecte
Câteva index-tables care nu au fost stabilite încă de la început, au fost identificate și create ulterior testării.
Prea multă memorie consumată în timpul rulării pe un profil care simula 1Gb RAM memorie. În acest caz performanța aplicației scade cu aproximativ 15% pe flow-urile principale.
Programul crash-uia uneori atunci când o anumită funcționalitate sau feature din aplicație era folosită mai des deoarece avea ca rezultat depășirea contoarelor sau a limitei de array-uri interne.
Performanța scăzută datorată unor "late binding"-uri excesive, plus ineficiență în crearea și distrugerea obiectelor.
Memory leak identificat în cazul în care aplicația era deschisă și neutilizată pentru o perioadă mai lungă de timp (câteva ore).
Riscuri
În testarea performanței sistemelor desktop, cele mai întâlnite probleme sunt relaționate la software și environment. Stabilitatea aplicației se pare că reprezintă îngrijorarea predominantă a testerului, cauza fiind multitudinea de situații în care tester-ul trebuie să lucreze cu o aplicație imperfectă sau neterminată.
Voi expune mai departe câteva dintre riscurile identificate și relaționate la testarea performanței soluțiilor desktop:
Un risc destul de întâlnit este legat de utilizarearesurselor locale în timpul scripting-ului primelor teste. Acest fapt duce de multe ori la blocarea sistemului din cauza consumării memoriei. Unele aplicații eșuează destul de des atunci când una dintre funcționalități este folosită mai intens. Testerul trebuie să urmeze flow-ul real în aplicație, să verifice și să permită tool-ului exercitarea un anumit stres, fapt care generează utilizare mai intensă. Bineînțeles, aceste probleme vor trebui rezolvate, însă există un impact asupra timpului, iar scripting-ul va trebui amânat până în momentul în care se rezolvă aceste probleme.
Crearea bazei de date specifică testării performanței implică probabil generarea a zeci de mii de intrări. Există două riscuri identificate în legătura cu această acțiune:
Simularea datelor "inventate" din tabele și integritatea lor nu sunt menținute. Nu toate proiectele beneficiază de o migrare a unui sistem mai vechi, caz în care o bază de date din producție poate fi adaptată. Riscul este mai mare atunci când baza de date trebuie construită de la început.
Al doilea risc este legat de faptul că regulile de business cum ar fi ajustarea financiară în diferite tabele nu este respectată.
În amândouă cazurile, este posibil ca simularea load-ului să nu fie compromisă, însă s-ar putea ca aplicația să nu poată manipula inconsistențele și să devină disfuncțională. Este important ca persoanele care pregătesc baza de date împreună cu popularea ei, să înțeleagă regulile de business, design-ul bazei de date și rolul aplicației.
Subestimarea efortului necesar pregătirii și rulării testelor poate fi de asemenea considerat un risc. Testarea performanței unui sistem client-server este o activitate complexă, mai ales din cauza problemelor care apar în timpul încercării de simulare a mediului și infrastructurii.
Ambiția prea optimistă, cel puțin în stadiul incipient al proiectului. Persoanele implicate de obicei prespun că baza de date este populată cu date valide, că fiecare tranzacție trebuie cuprinsă în testele de performanță sau că toți timpii trebuie măsurați. De obicei următoarea regulă, 80/20 se aplică: 80% din volumul bazei de date este furnizat de 20% dintre tabele. 80% din stresul asupra sistemului va fi generat de 20% dintre tranzacții. Doar 20% din tranzacțiile sistemului ar trebui măsurate deși testerii experimentați ar presupune că aici s-ar putea aplica regula 90/10. Managerii neexperimentati par să amestece valorile 90 și 10.
Tool-urile folosite pentru execuția testelor de performanță nu necesită cunoștințe extrem de bogate, având în vedere că aproape peste tot în dezvoltarea și testing-ul aplicațiilor există principii la care, dacă se aderă, ar trebui să ofere și testerilor cu o experiență medie capacitatea de a crea teste de performanță. Există o tendință comună în rândul managerilor și testerilor fără experiență în testarea performanței sistemelor, de a crede că procesul testării constă în două etape: scripting și rulare. Mai mult decât atât, riscul crește dacă există nevoia de a personaliza anumite tool-uri pe care acei testeri le folosesc.
Un alt risc identificat este legat de cunoștintele și abilitățile persoanelor implicate în proiect. Atunci când programatorilor care au realizat designul și au implementat o anumită funcționalitate li se cere să creeze o suită de teste automatizate pentru a putea fi utilizate la testarea performanței, dificultatea principală o reprezintă experiența în testare. Pe de altă parte, testerii experimentați care nu au nicio cunoștință în ceea ce privește sistemul pe care îl vor testa, de obicei vor avea nevoie de o mică perioadă de familiarizare cu aplicația. Ideal ar fi să lucreze împreună, însă dacă există probleme legate de resurse/cunoștințe, managerul de proiect va trebui să ia deciziile bazate pe risc și impact.
Concluzii
În final putem evidenția câteva concluzii referitoare la aplicațiile construite pe platforma Desktop:
Tool-urile sunt importante și esențiale, dar problemele nu se leagă doar de ele, provocarea ar fi mai degrabă identificarea scopului pentru care trebuie executate testele de performanță. Care ar putea fi îngrijorările legate de business, infrastructura sau așteptările utilizatorilor finali cu privire la aplicație? Scenariile de acest tip: cele mai comune, cele mai critice din punct de vedere al businessului sau cele care solicită cel mai mult aplicația din punct de vedere tehnic ar trebui luate în considerare chiar dacă la ele nu au consimțit în prealabil clientul.
Factori ca: firewall-uri, aplicația antivirus, arhitectura rețelei, infrastructura, sistem de operare cu Service pack-ul aferent sau chiar alte programe care rulează în același timp pe stație, toate afectează performanța întregului sistem. Toate acestea împreună formează un set de variabile pe care trebuie să le luăm în considerare.
Testarea performanței aplicațiilor desktop, este percepută ca fiind foarte apropiată de testarea functională si de asemenea de a scrie cod în acest scop. Pe forumurile de profil există o ușoară tendință ca persoanele implicate în testarea performanței să-și creeze propriul tool scris în .NET, Java, Perl, Python sau alte tehnologii pe care mai târziu să-l folosească deopotrivă în automatizarea testelor și testarea performanței.
Dacă ne referim strict la performanță, majoritatea vor înclina către testarea la nivel de Service layer/Bază de Date.
Este difícil să găsești un tool deja creat care să se potrivească majorității tehnologiilor folosite în aplicațiile desktop. Mai mult decat atât, să poată fi folosit și la înregistrarea flow-urilor din aplicație la nivel de interfață cu utilizatorul, apoi la play-back folosind mai multe stații sau utilizatori virtuali.
Pentru unele teste de performanță la nivel de client nici nu este nevoie întotdeauna de un tool special, ci mai degrabă de câteva cazuri de test bine desenate și gândite, grupate în suite, având câteva variabile.
Administratorii de baze de date, de sistem sau de rețea nu pot crea singuri suportul pentru testele de performanță. Din acest motiv, ei trebuie implicați în stadiile incipiente ale proiectului. Perspectivele lor îmbunătățesc calitatea testing-ului.
Multitudinea sistemelor de operare, versiunilor sau configurațiile hardware pot crea probleme în definirea profilurilor "utilizatorilor finali". E imposibilă simularea tuturor acestor combinații, prin urmare o idee bună putând fi prioritizarea configurațiilor OS vs. Hardware. Există tool-uri care pot simula limitările de hardware (disk, memory, network) unul dintre ele este Seapine Resource Thief.
În general, problemele testing-ului de performanță de ordin logistic, organizațional sau tehnic pot fi evitate aplicând principii cum ar fi:
abordarea testing-ului în arhitecturile cu două sau trei nivele este similar, diferă doar complexitatea;
tool-urile brevetate și cunoscute ajută, dar mai mult decât atât, se cere improvizare și inovare pentru ca o testare eficientă să se "întâmple";
atunci când se alege un tool care se dorește a fi folosit de la nivel de UI, trebuie avut în vedere tehnologia folosită la implementare. Nu am găsit un tool care să poată trata toate tehnologiile. De exemplu, unele tool-uri cum ar fi Telerik Test Studio pot înregistra flow-uri pe o aplicație implementată in WPF (Windows Presentation Foundation) și nu poate fi folosit dacă implementarea este făcută în Windows Forms.
Iată câteva deficiențe ale unora dintre tool-urile investigate:
dacă dorim să testăm un serviciu care transferă fișiere de exemplu, nu am găsit niciun tool capabil să facă browse pe disk pentru acel fișier;
aplicația desktop trebuie să fie deja pornită pentru majoritatea tool-urilor;
acțiunea Play-back este oprită dacă apare o pagină pop-up în timpul flow-ului (QA Wizard Pro);
operațiile de genul: Save, Open etc. , nu sunt suportate de tool-urile investigate.
La o primă vedere, testarea performanței aplicațiilor desktop pare să fie destul de diferită, soluțiile existente oferind o gamă destul de vastă în posibilitățile de testare. Cu toate acestea, să nu uităm că asigurarea calității fundamentale, împreună cu principiile de bază rămân la fel și se aplică tuturor.
