Wprowadzenie
Z pewnością słyszałeś o testach regresyjnych i akceptacyjnych. Ale czy wiesz, ile faktycznie wydaje się na testy akceptacyjne w projekcie?
Możemy szybko uzyskać odpowiedź za pomocą systemu śledzenia czasu, takiego jak TMetric.
W naszym projekcie testy akceptacyjne aplikacja komputerowa obejmująca około 100 zestawów zajęła ponad 2 osobo-tygodnie. Największe trudności mieli nowi specjaliści ds. kontroli jakości, którzy nie znali dobrze aplikacji. W porównaniu z bardziej doświadczonymi specjalistami QA, poświęcali oni znacznie więcej czasu na każdy przypadek testowy.
Jednak moim zdaniem najbardziej nieprzyjemna była ta część – jeśli przed wydaniem zostaną znalezione jakieś krytyczne błędy, testy akceptacyjne muszą zostać wykonane ponownie po naprawieniu tych błędów.
Pisemne testy jednostkowe trochę pomogły, ale nadal w większości skróciły czas poświęcony na testowanie regresji. Dzięki temu, gdy liczba testów ręcznych osiągnęła poziom krytyczny, zaczęliśmy dążyć do automatyzacji.
ROI
Przed napisaniem automatycznych testów UI musieliśmy ocenić, na ile opłacalne są nasze inwestycje. Zrobiliśmy to z pomocą ROI (Return On Investment https://en.wikipedia.org/wiki/Return_on_investment)
Obliczanie ROI testowania interfejsu użytkownika również stało się interesującym zadaniem z wieloma nieznanymi zmiennymi:
ROI =Zysk / Wydatki
lub
ROI =(Zysk – Wydatki) / Wydatki
Na tym etapie potrzebowaliśmy małego prototypu, który pomógłby nam oszacować wszystkie niezbędne wydatki. Wykazał bardzo dziwne wyniki:wykonanie testów akceptacyjnych zajmuje mniej więcej tyle samo czasu, co automatyzacja tego procesu. Początkowo informacje te wydawały się wątpliwe, ale kiedy dokładniej zbadaliśmy, powody stały się jasne:
- Nowi specjaliści ds. kontroli jakości mogą mieć ograniczoną wiedzę na temat kroków opisanych w przypadkach testowych. Kiedy tak się stanie, kilka osób będzie zaangażowanych w testy akceptacyjne, aby lepiej zrozumieć sytuację. W tym miejscu powinniśmy również pamiętać o tym, jak istotne są posiadane przez nas informacje o ustawieniach i wymaganiach środowiska.
- Czasami ludzie zaangażowani w testy akceptacyjne spędzają czas na uczeniu się dokumentacji technicznej.
- Sama aplikacja współdziała z określonym zestawem usług. Jeśli któryś z nich jest niedostępny, mniej doświadczeni specjaliści ds. kontroli jakości spędzą czas na opisaniu błędów, które z kolei zbadają deweloperzy. W rezultacie marnuje się czas, ponieważ niezbędna usługa po prostu nie działała poprawnie po wyłączeniu/aktualizacji sprzętu/ponownym uruchomieniu komputera.
- Komputery testerów kontroli jakości nie są zbyt wydajne. Jeśli nie ma dysku SSD, zauważysz to już podczas instalacji. Ponadto, jeśli aplikacja działa pod dużym obciążeniem, możliwe jest, że zostanie użyty powolny plik stronicowania.
- Szczerze mówiąc, daliśmy się ponieść emocjom i zapomnieliśmy, że pracujemy z automatyzacją. A tak przy okazji, czy zamknąłeś kartę Youtube w swojej przeglądarce?
Wróćmy teraz do ROI. Dla uproszczenia obliczenia zostały wykonane według czasu. Obliczmy zysk jako oszczędności na testach ręcznych, a okres, któremu przyjrzymy się, to jeden rok:
Zysk =(X – Y) * N =(60 – 1) * 8 =472 dni
X – czas poświęcony na testy manualne (60 dni)
Y – czas poświęcony na wykonanie testów automatycznych (1 dzień)
N – czas, w którym dokonano akceptacji
Następnie przyjrzymy się wydatkom:
Wydatki =A + B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80
A – Koszt licencji na narzędzie do automatyzacji. W naszym przypadku wykorzystano bezpłatne narzędzie.
B – Szkolenie specjalisty QA (10 dni)
C – Przygotowanie infrastruktury (5 dni)
D – Opracowanie testów (50 dni)
E – Przeprowadzanie testów i opisywanie błędów wykrytych w procesie (7 dni)
F – Utrzymanie testów (8 dni)
Razem:
ROI =Zysk / Wydatki =472 / 80 =5,9
Oczywiście niektóre aspekty są tutaj szacunkowe. Aby ocenić własne obliczenia, poświęciliśmy trochę czasu na zbadanie możliwości oferowanych przez płatne rozwiązania i różne kalkulatory ROI. Dzięki temu obliczyliśmy średnią wartość ROI na 2 lub 3, co jest świetnym wynikiem.
Istniejące frameworki
Po przyjrzeniu się kwestiom organizacyjnym, skupmy się na kwestiach natury technicznej. Najważniejszym z nich był wybór frameworka do automatyzacji testów naszej aplikacji desktopowej. Na podstawie cech naszego projektu mieliśmy następujące wymagania:
- Testy zostaną opracowane i uruchomione na komputerach z systemem Windows
- Struktura powinna być dostosowana do testowania aplikacji komputerowych
- Testowanie interfejsu użytkownika można zintegrować z procesem CI. Używaliśmy już Jenkinsa, więc tutaj było lepiej
- Możliwość pisania testów w przyjaznym dla użytkownika IDE – musi mieć podświetlanie składni, nawigację po skryptach testowych i uzupełnianie kodu w stylu IntelliSense
- Minimalne wydatki na szkolenie QA. Z pewnych powodów nasi specjaliści QA nie chcieli pisać testów w Brainfuck
- Preferowana jest społeczność na Stack Overflow, MSDN itp.
Test zakończony
Ta platforma początkowo przemówiła do nas ze względu na swoją dojrzałość, co dało nadzieje w kwestiach technicznych.
Pierwszą rzeczą, jaką napotkaliśmy, było niestabilne i raczej przestarzałe IDE. Środowisko radziło sobie z podświetlaniem składni mniej lub bardziej przyzwoicie, ale występowały poważne problemy z nawigacją (Przejdź do definicji), wyszukiwaniem i autouzupełnianiem kodu:ta funkcja nie działała w ogóle w około 60% przypadków. Wbudowany rejestrator i analogowy Inspect działały bez zarzutu. W końcu IDE sprawiło nam niemiłą niespodziankę, gdy zaczęło przekazywać do aplikacji argumenty. Spodziewano się, że spowodowało to błędy w działaniu aplikacji:
--no-sandbox program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent
Na tym etapie zaangażowaliśmy wsparcie TestComplete w sytuację, aby spróbować zaoszczędzić czas i ocenić jakość wsparcia technicznego przed potencjalnym zakupem licencji. Po przesłaniu kilku listów do pomocy technicznej otrzymaliśmy odpowiedź – powinniśmy zignorować argumenty przekazane do aplikacji. Dziwne, prawda? Badając dalej, odkryliśmy, że te argumenty są wymagane do testowania aplikacji korzystających z CEF. W naszym kolejnym liście stwierdziliśmy, że używamy CEF, a specjaliści ds. wsparcia powiedzieli nam, aby nie ignorować argumentów. Kiedy zapytaliśmy, jak dokładnie ich użyć, odpowiedź zmieniła się z powrotem na „Ignoruj argumenty”.
Porzucając rozmowę z pomocą techniczną, zwróciliśmy się do dokumentacji IDE (bez większej nadziei). Zawierał więcej informacji, ale nie znaleźliśmy niczego związanego z omawianą sprawą. Ponadto, zgodnie z tą samą dokumentacją, IDE powinno zachowywać się inaczej od samego początku.
Zakłada się, że testy w TestComplete będą pisane przy użyciu VBScript.
Jeśli spojrzysz na to wystarczająco długo, możesz to usłyszeć. Microsoft sugeruje przekształcenie tego „cudu” w skrypty PowerShell. Alternatywnie można użyć JavaScript i Python, co pomaga w tej sytuacji.
Jako darmowe narzędzie TestComplete byłby znośny, ale ich strona ma stronę z cenami, a ceny są na użytkownika. W rezultacie po zakupie narzędzia otrzymamy:
- IDE, które chcesz zamknąć
- Zgodność ze skryptami z 1996 roku
- Rejestrator, abyśmy nie zapisywali wszystkiego ręcznie
- Kolejna inspekcja, ale z dzwonkami i gwizdkami
- Dwa rodzaje odpowiedzi pomocy technicznej
- Dokumentacja, która nie przedstawia rzeczywistości
Najgorsza transakcja handlowa w historii, przejdźmy dalej.
Zakodowany interfejs użytkownika
Taktyczny odwrót, przegrupowanie i flankujemy problem. Z jednej strony nauczyliśmy się używać Visual Studio jako IDE. Z drugiej strony nasze podejście opierało się na komponentach DevExpress UI, których używamy. W rezultacie znaleźliśmy kilka interesujących informacji o frameworku Coded UI, który jest oficjalnie używany w DevExpress do automatyzacji testowania interfejsu użytkownika. Ta struktura jest tak zintegrowana z wewnętrznym procesem testowania, że istnieje nawet rozszerzenie do Visual Studio.
Istniała rozległa społeczność, Microsoft promował narzędzie na swojej stronie internetowej, a o tym produkcie wspomniano również w „Microsoft Visual Studio”. Krótko mówiąc, wszystko wyglądało obiecująco i zaczęliśmy przygotowywać framework.
Pierwszym wymaganiem, jakie napotkaliśmy, było Visual Studio Enterprise. Co więcej, ta wersja Visual Studio była potrzebna nie tylko do pisania testów, ale także do ich uruchamiania. Oznacza to, że mstest, przez który zostanie wykonane uruchomienie w przypadku CI, powinien również być częścią edycji Enterprise.
Wszystkie niezbędne narzędzia kodowanego interfejsu użytkownika można zainstalować, zaznaczając odpowiednie pola wyboru podczas instalowania lub modyfikowania VS.
Podejście do pisania testów było dość przyjemne:polecenia zintegrowane z powłoką pozwalały na szybkie uruchomienie rejestratora, który generuje test jednostkowy oraz klasę „map” opisującą interfejs użytkownika. Dodatkowe narzędzia zintegrowane z VS zapewniały możliwość tworzenia osobnych klas testowych bez wywoływania kodu.
Jedyną osobliwością, jaką zauważyliśmy, była klasa częściowa, która posiadała opis kontrolki i była podzielona na dwie części. Wraz z wieloma innymi rzeczami jest to opisane w dokumentacji. Ta dokumentacja jest wystarczająca do wygodnego procesu pracy:przykłady kodu i zrzuty ekranu sprawiają, że wszystkie informacje techniczne są łatwo dostępne i łatwe do zrozumienia. Mówiąc prościej, gdy rejestrator opisuje interfejs użytkownika, generowany jest plik „Designer.cs”. Ten plik jest odpowiedzialny za ponowne wykorzystanie kodu opisującego interfejs użytkownika. Wszystko, z czym rejestrator nie mógł sobie poradzić, powinno być napisane ręcznie i zapisane gdzieś poza automatycznie wygenerowaną częścią klasy. Jest to bardzo podobne do częściowych klas napisanych przez projektantów VS podczas tworzenia kontrolek. Priorytet operacji wykonywanych na kontrolkach i sprawdzania ich stanu jest opisany w metodzie, do której rejestrator w pomocny sposób dodaje standardowy atrybut TestMethod.
Chmury zaczęły gromadzić się nad frameworkiem, gdy zaczęliśmy przyglądać się rzeczom generowanym przez rejestrator . Przede wszystkim przesłonił niektóre problemy z aplikacją:właściwość Nazwa niektórych kontrolek nie została określona, a rejestrator uznał, że nazwanie tego absurdalnego przypadku naruszenia reguły jest akceptowalny i przeszukał kontrolki w tekście. Ponadto bardzo nieefektywnie radził sobie ze złożonymi kontrolkami. Na przykład węzły TreeView były przeszukiwane według indeksu węzłów, co powodowało, że stworzona klasa „mapy” była bezużyteczna w przypadku rozbudowy interfejsu. A wartość rejestratora znacząco spadła w naszych oczach – jaki sens ma automatyczne generowanie kodu, jeśli trzeba to później sprawdzić?
Mogliśmy pogodzić się z tym wszystkim i znaleźć godne pochwały rozwiązanie, ale nagle uderzył piorun:Microsoft stwierdził, że ta technologia jest już przestarzała. Dzięki temu VS 2019 stał się ostatnią wersją Visual Studio, która obsługuje kodowany interfejs użytkownika. Możliwość uzależnienia się od VS 2019 teraz i przez kilka lat wcześniej nie wydawała się aż tak przerażająca, ale nasz projekt jest dość duży, więc trudności mogą zacząć się gdzieś dalej (np. 2025).
Podsumujmy. Dzięki kodowanemu interfejsowi użytkownika będziemy mieć:
- Potężne płatne IDE
- Cała infrastruktura już stworzona do testów:zarówno po stronie IDE, jak i naszego CI
- Możliwość zwrócenia się do dowolnego programisty z naszego projektu o pomoc, ponieważ piszemy testy w C# w tym samym IDE
- Duża ilość dobrej jakości dokumentacji
- Kilku smutnych specjalistów QA, którzy umieścili swój kod w automatycznie wygenerowanej części klasy, a następnie zgubili go podczas procesu autogeneracji
- Dużo wygenerowanego kodu tego rodzaju działa i który trzeba poddać ścisłej kontroli
- Niezwykle przejrzyste podejście do CI:możesz pisać kod do uruchamiania testów przez mstest z zamkniętymi oczami
- Powoli umierający czerwony olbrzym automatyzacji, który stale wyrasta z nowych testów i jest niebezpiecznie bliski przekształcenia się albo w gasnącego białego karła, reprezentowanego przez całkowicie odizolowaną maszynę z nieodwracalnie przestarzałym oprogramowaniem, albo w wybuch supernowej, gdy projekt eksploduje pod wpływem presja nowych aktualizacji.
Wszystko brzmiało dobrze, z wyjątkiem ostatniego punktu. Dlatego musieliśmy kontynuować nasze poszukiwania.
Stos testowy.Biały
Pracowaliśmy nad testami prototypów z pomocą White równolegle do badania funkcjonalności Coded UI.
Sam White jest okładką wokół bibliotek „Microsoft.Automation”, które wyglądały bardzo obiecująco, a White jest również podobny do Coded interfejs użytkownika. Jednak po bliższym przyjrzeniu się okazało się, że jest znacznie bardziej surowy i można to zauważyć wszędzie – od braku rejestratora po rzeczywistą strukturę testu. Na przykład uruchomienie aplikacji, wyszukanie okna i naciśnięcie przycisku „Wykonaj” wygląda tak:
var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);
var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);
var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();
app.WaitWhileBusy(); Nawet jeśli nie ma narzekań na uruchomienie aplikacji, to konieczność pracy z klasą InvokePattern jest bardzo wątpliwa. Klasa InitializeOption również wygląda dziwnie, ponieważ ma dostęp do statycznej składowej WithCache, ale powinna być używana wyłącznie wewnętrznie:
public class InitializeOption {
//
// Summary:
// This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }
//
// Summary:
// Specify the unique identification for your window. White remembers the location
// of UIItems inside a window as you find them. Next time when items inside the
// same window is found they are located first based on position which is faster.
//
// Parameters:
// identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}
Dziwne decyzje, takie jak ta, są wszędzie, a framework okazuje się zbyt abstrakcyjny dla kontroli jakości.
Dokumentacja jest przyzwoitej jakości i pozostawiła dobre ogólne wrażenie. Kod źródłowy projektu był hostowany na github, ale ostatnie zatwierdzenie pochodziło z 8 stycznia 2016 r.
Podsumowując informacje o White, mielibyśmy:
- Przyzwoita dokumentacja
- Dostęp do kodu źródłowego
- Mała społeczność
- Konieczność wyjaśnienia wszystkim specjalistom ds. kontroli jakości, że zachowanie kontroli jest implementowane przez klasę Pattern
- Stare repozytorium, z którego na pewno musielibyśmy się rozwidlić
Najbardziej nieprzyjemną częścią była konieczność opracowania własnego frameworka, czego chcielibyśmy uniknąć. Musieliśmy więc iść dalej.
Apium
Już wcześniej napotkaliśmy Appium w naszych poszukiwaniach, ale zaczęliśmy rozważać to poważnie dopiero po tym, jak Microsoft przestał używać kodowanego interfejsu użytkownika.
Na pierwszy rzut oka testowanie za pomocą Appium wygląda jak automat z trzema bębnami. Pierwsza pokazuje język, dla którego istnieje API umożliwiające interakcję ze sterownikiem. Daje to możliwość pisania testów w dowolnym znanym języku:Python, C#, Java itp. Druga rolka pokazuje aplikację sterownika, która służy jako warstwa pośrednia między testami a testowanym produktem. Jak opisano w dokumentacji, interakcja z testami odbywa się za pomocą protokołu JSON Wire – to właśnie daje nam możliwość pisania testów w dowolnym języku. A trzecia rolka pokazuje obiekt, który testujemy. Nie ma znaczenia, czy jest to witryna internetowa, aplikacja mobilna czy aplikacja komputerowa, o ile odpowiedni sterownik jest uruchomiony. Jak widać, komponenty są elegancko wymienne.
Oszacowanie trafności pakietu było satysfakcjonujące – na stronie Github mogliśmy zobaczyć, że repozytorium ma świeże zatwierdzenia. Podczas badania repozytorium WinAppDriver dowiedzieliśmy się, że jest w nim nawet nagrywarka.
Zaczęliśmy zauważać pewne problemy podczas pisania prototypu. Na przykład, ponieważ platforma jest zbyt uniwersalna, element WindowsElement odpowiedzialny za kontrolkę pulpitu ma metodę FindElementByCssSelector, która podczas wykonywania zgłasza następujący wyjątek:„Nieoczekiwany błąd. Niewdrożone polecenie:strategia lokalizatora selektora css nie jest obsługiwana”. W następnym artykule bardziej szczegółowo omówimy problemy, które napotkaliśmy podczas pracy z tym frameworkiem, ale na razie chciałbym powiedzieć, że poradziliśmy sobie z nimi wszystkimi.
Podsumowując, oto, co będziemy mieli podczas korzystania z Appium:
- Możliwość testowania funkcjonalności aplikacji wymagającej interakcji z przeglądarką (otwarcie strony z opiniami, aktywacja online, sprawdzenie dostarczania poczty) w zakresie jednej infrastruktury i jednego testu
- Możliwość pracy z dowolną edycją Visual Studio
- Możliwość testowania aplikacji komputerowych korzystających z przeglądarki do renderowania interfejsu użytkownika. Dobrym przykładem może być Azure Data Studio
- Wszystkie zalety, które uzyskujemy dzięki kodowanemu interfejsowi użytkownika
- Bezpłatny framework, którego Microsoft zaleca używać
- Infrastruktura znana specjalistom ds. kontroli jakości, którzy pracowali z Selenium
- Repozytorium zaktualizowane o nowe zatwierdzenia
- Przyzwoicie duża społeczność, która jednak nie jest tak duża jak społeczność Coded UI
- Rejestrator o ograniczonej funkcjonalności
- Konieczność uruchomienia aplikacji sterownika do testowania. Niezbyt wygodne, ale ma własną funkcję rejestrowania
- Wiele możliwości strzelenia sobie w stopę dzięki niefortunnemu dziedziczeniu WindowsElement po AppiumWebElement
Przechodząc przez wszystkie punkty z wymaganiami dotyczącymi frameworków i porównując wszystkie problemy znalezione w każdym z tych frameworków, w końcu wybraliśmy Appium.
Wniosek
Praca ze wszystkimi tymi frameworkami była interesująca, ponieważ każdy z nich opierał się na unikalnej filozofii podejścia do testów automatycznych. Część z nich dopiero zaczynała swoją drogę, podczas gdy inne dochodziły do zaćmienia lub już zniknęły. Możesz uniknąć zagubienia się w wielu dostępnych rozwiązaniach, tworząc listę konkretnych wymagań dla narzędzia i mając odpowiedzialny zespół o ugruntowanej interakcji między jego członkami. I nie zapominaj, że przyszłe testy są takim samym projektem, jak zwykły kod, z zaległościami, tablicami, CI, refaktoryzacją i wszystkim innym.
