пропозиції роботи
Wypowiedzi
-
Hej,
Właśnie niedawno team mój zaczał się "bawić" pomiarami Code Coverage. W zasadzie to wyszła odgórna inicjatywa co by tu zmierzyć pokrycie kodu testami automatycznymi. Wyniki wyszły zaskakujące, choć należało sie ich spodziewać. Otóż samo uruchomienie aplikacji (kilka linii skryptu testowego) pokrywa okolo 20% kodu. Oczywiście podczas startu aplikacji procesowana jest duża ilość danych (z bazy i wogóle). Jednak te "20%" daje dużo do myślenia. Po wykonaniu wszystkich skryptow dostaliśmy wynik > 50%.
Oto nasze wnioski (oczywiście bez odkrywania ameryki):
* Aby zwiększyć pokrycie wystarczy po prostu uruchamiać poszczególne moduły, funkcje aplikacji BEZ SPRAWDZANIA CZY RZECZYWIŚCIE DZIAŁAJĄ PRAWIDŁOWO (nie jakość a ilość :)
* Uruchomienie aplikacji + widoku głównego pokrywa do 20% kodu
* Code Coverage - nie może być PODSTAWOWĄ METRYKĄ POKRYCIA TESTÓW. Podstawową metryką musi byc REQUIREMENTS COVERAGE a dodatkowo CODE COVERAGE
* Bardzo dobre pokrycie aplikacji testami jest wtedy, gdy:
** REQUIREMENTS COVERAGE > 50% (a bliskie 100% dla najważniejszych funkcjonalności)
** CODE COVERAGE > 70%
KK -
Z konkretnych (darmowych) rozwiązań mogę polecić:
1) Fitness (.Net oraz Java)
http://fitnesse.org/
2) Selenium (Web)
http://selenium.openqa.org/
KK -
Postaram sie w najblizszym czasie napisac cos (jakis maly felietonik wraz z przykladami).
KK -
Lukasz,
Najprosciej na starcie kazdego skryptu sprawdzac czy przegladarka jest uruchomiona, jesli tak - zamykamy i rozpoczynamy test.
PS Odnosnie Descriptive Programming - jak bedzeisz wdrazal (sie) to Daj znac. Moge podzielic sie doswiadczeniem.
KK -
Jeśli tylko jesteś w stanie przechwycić wystąpięnie "sytuacji z kosmosu" to w przypadku Web-owej aplikacji sprawa jest prosta - zamykasz wszystkie przeglądarki i przechodzisz do następnego skryptu.
-
Ha, to robimy imprezę w Grodzie Kraka :)
-
Czemu Warszawa a nie Kraków?
:) -
Jeszcze odnosnie "script review"...
W mojej poprzedniej firmie, jako, ze pracowalismy zgodnie z CMM Level 5 przeglady skryptow testowych byly formalnymi inspekcjami i nawet byl specjalny tool do tego stworzony. Proces review wygladal doslownie jak w sylabusie ISTQB, czyli planning, kick-off meeting, review, follow-up, etc. Wymagana ilosc osob to 3-5 i nie bylo przepros. Ktos madry wyliczyl, ze podczas code review ZNAJDOWANYCH JEST 60-70% BLEDOW!!! Czyli jak widac potezne narzedzie to jest.
W obecnej firmie robimy to w mniej formalny sposob, jako peer-to-peer meting, ale nigdy nie jest tak, ze dany skrypt jest konczony bez takowego review.
KK -
Lukasz,
Pisalem o tym na innym forum SJSI ale pozwole sobie skopiowac. Metoda jest sprawdzona.
###
Zakladamy, ze Systemu nie posiada wymagan (lub sa ale niekompletne, przestarzale, etc.). Zakladamy rowniez, ze System jest znany przez testera (tester to zwykle jedyna osoba, ktora wie najwiecej :).
Bierzemy, siadamy i robimy analize, czyli rozkladamy system na w miare atomowe kawalki/funkcjonalnosci, spisujemy je w postaci listy (chodzi o spisanie tytulow, bez zadnych opisow !!!). Czesem do tego celu mozemy posluzyc sie manualem (jesli jest) lub jakas inna dokumentacja.
Mogbym tu wkleic przykladow liste tytulow wymagan ale wolalbym tego nie robic ze wzgledu na Policy.
Czasem mozna zalozyc, ze kazdy formularz aplikacji to 1 wymaganie. Wszystko zalezy od systemu. Czasem oczywiscie jest to bardzo zlozone (nie latwe) zadanie. Jednakze, w ciagu 1-3 dni jestesmy w stanie przygotowac taka liste 100 - 500 tytulow wymagan (im wiecej tym lepiej), przy czym wymagania moga byc pogrupowane w tzw. Functional Area.
Nastepnie zbieramy wszystkie istniejace testy i probujemy zmapowac je do tych wymagan. Czasem jest tak, ze jeden test pasuje do wielu wymagan, czasem jedno wymaganie jest pokryte wieloma testami.
I tu uwaga, jesli mamy wymaganie i do niego podlaczone sa jakies testy, ale czujemy, ze wymaganie nie jest wystarczajaco pokryte to:
1) Testy sa kiepskie (lub)
2) Wymaganie to nie jest atomowe tzn. mozna je rozbic.
Jesli mamy jakis test nie podlaczony do zadnego wymagania, to znaczy, ze... nie wypisalismy wszystkich.
Mierzenie Requirements Coverage jest teraz banalnie proste. Oczywiscie dla duzej ilosci testow i wymagan nalezy wykorzystac toola w stylu QC, choc Excel tez moze byc!
My wykorzystujemy Quality Center w nastepujacy sposob:
1) Requirements - tu wrzucamy tytuly wymagan
2) Test Plan - tu umieszczamy testy
3) Test Lab - tu jest robiona egzekucja (testow).
Dziala to fajnie a Coverage jest obliczany automatycznie.
Metoda daje oczywscie szacunkowey poglad, ale zawsze lepsze to niz nic czyli zgadywanie. -
Dariusz P.:
Krzysztof Kukla:
>2) CC > 30%
O proszę - czyli robicie też white-box testing jak rozumiem? To
chyba rzadkość. Mam wrażenie, że większość testerów specjalizuje się w black-boxie :)
Darek,
To, ze to napisalem to wcale nie znaczy, ze to robimy :).
I jeszcze jedno zdanie odnosnie tego co napisal Lukasz - testerzy nie sa od jakosi tylko od znajdowania bugow (temat rzeka oczywiscie, ale to znajdowanie bugow wlasnie jest pryncypalem testowania). Pozwole sobie otworzyc nowy watek odnosnie tego tematu (co by to wicej watkow na forum bylo). -
Hej Lukasz,
Metryki:
1) Tracebility - pokrycie wymagan testami
2) Code Coverage - nie musze tlumaczyc
I teraz jesli:
1) Traceblity ~100% dla najwazniejszych wymagan (nie dla wszystkichm, ale tych najwazniejszych)
2) CC > 30%
to jest b. dobre pokrycie (b. dobra jakosc testowania).
Ponadto, przydalo by sie wdrozyc proces review test procedur oraz
test case-ow, tak aby miec pewnosc, ze test faktycznie pokrywa dana funkcjonalnosc.
PS Oczywiscie to tylko teoria, w praktyce jest tak, jak pisal Dawid "jakos to bedzie" :)
KKKrzysztof Kukla edytował(a) ten post dnia 08.07.08 o godzinie 10:57 -
Hej,
Nie korzystalem nigdy z darmowych tooli tego typu, ale sprobuj poszukac tu:
http://testing.tigris.org/
Moze cos uda Ci sie znalezc,
KK -
Hej Sergey,
Jeszcze jedna rzecz przyszla mi na mysl!!! Otoz istnieje na rynku oprogramowanie sluzace do wyszukiwania tego typu anomalii w zbiorze danych generalnie. Z tego co pamietam to tego typu soft nazywa sie "rule engines". Nalezy go "doimplementowac" do aplikacji no i oczywiscie zdefiniowac odpowiednie reguly.
Tu Masz darmowe toole do C#:
http://csharp-source.net/open-source/rule-engines
Tu Masz darmowe toole do Javy:
http://java-source.net/open-source/rule-engines
Jest jeszcz komercyjny iLog (do Javy i C#)
Jesli chodzi o C++ to nie wiem, ale zapewne cos jest.
Pozdrawiam,
KK -
Zgadzam sie z Toba. Nie jest to problem latwy. Nie nalezy sie ludzic, ze tool poprawi wszystko. Nalezy jednak sprobowac stworzy takie query, ktore zwroci liste np. potencjalnie zduplikowanych rekordow (gosci i firm) i dac uzytkownikom mozliowosc ich scalania.
-
Ja spotkalem sie tylko z S-Curve i to w przypadku testow regresyjnych.
http://en.wikipedia.org/wiki/Logistic_function
KK -
P.S. do tej pory robił to jeden z głównych lekarzy o zdolnościach administracyjnych korygując i czyszcząc co-miesięcznie wpisy.
Na czym polega ta korekcja? Sa jakies reguly? -
...a i jeszcze jedno - dlaczego QTP zapisuje test w jakze zdumiewajace postaci? Jakies katalogi, miliony binarek, po co to wszystko? Czy nie wystarczy plik VBS + Excel + jakies deskryptory w postaci tekstowych XML-i? Dlaczego Object Repository nie jest plikiem XML tylko jakas dziwna binarka? Dlaczego kazde Reusable Action (nie polecam uzywac) korzysta z osobnego redundantnego repozytorium, ktore to jest kolejna binarka? Dlaczego prosty skrypt QTP zajmuje 2MB a nie 20kB? Dlaczego dopiero w wersji 9.5 wprowadzili zarzadzanie Checkpointami takze, ze czlowiek wkurzony musial sobie storzyc wlasny framework do checkpointow? Dlaczego QTP otwiera sie prze 2min na moim kompie? Dlaczego trzeba stosowac wodotryski azeby moc debugowac w kodzie biblioteki? Dlaczego nie mozna wogole debugowac kodu bibliotek dolaczonych do bibliotek? Dlaczego Checkpoint jest kolejna binarka a nie plikem XML lub jakims innym teksciakiem? Dlaczego QTP jest takie drogie? Dlaczego zastosowano ten badziewny jezyk skryptowy a nie jakis normalny obiektowy (Java/C#)?
Dlaczego?
:) -
Adam Frelak:
Jak chodzi o zbior bibliotek to nie mialem nigdy problemow z otwarciem na raz wiekszej ilosci, tak kwestie otwierania kilku testow, badz nawet akcji na raz uwazam akurat za zbedne.
Przykladowo - operacja zrefaktorowania jakiejs kluczowej metody (np dodanie parametru) dla jednego testu QTP przechowywanego w Quality Center na serwerze w USA trwa przykladowo 1min.
- 10s - otwarcie
- 30s - zmiana (powiedzmy)
- 20s - zapis
Jesli testow jest 100 to szlag Cie trafia po zmianie 10.
W lepszym srodowisku deweloperskim, takie rzeczy robi sie automatem korzystajac z opcji "Refactoring". W normalnym "sorce navigatorze" wystarczy mozliwosc wyszukania czegos po wszystkich plikach (testach).
Wedlug mnie brak tego Quick Test Pro powoduje, ze tool ten jest malo ... profesjonalny.
PS Widzialem podobny CR zostal juz dawno zgloszony producentowi ale chyba jego zrobienie wymagalo by ... przepisanie QTP. -
Odnosnie automatycznego dodawania obiektow - to problem da sie rozwiazac poprzez uzywanie wyrazen regularnych w wartosciach obiektow.
-
Drodzy Ludkowie,
Wystepuje z pytaniem co chielibyscie zmienic w QTP tak azeby tool owy byl w stanie wzbudzac ogolny szacun.
Mnie osobiscie straszliwie drzazni niemoznosc otworzenia i pracowania na calym projekcie (tj. zbiorze testow i bibliotek). Ta opcja jest oczywiscie-oczywista w kazdym normalnym srodowisku dev.
Jako pracownik szacownej firmy mam wplyw na to co sie robi w HP/Mercury. Znaczy sie zdarzalo sie tak, ze w HP/Mercury robili SCR-y zglaszane przez nas.
KK
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
