Jako deweloperzy automatyzacji, czyż nie odczuwamy satysfakcji, gdy słyszymy od zespołu testów manualnych lub klienta, jak wiele korzyści przyniosło im wykorzystanie stworzonej przez nas automatyzacji? W tym celu stawiamy na wysokiej jakości zestaw automatyzacji, który jest nie tylko solidny, lecz także łatwo dostosowuje się do aktualizacji wymaganych w związku ze zmianami wymagań biznesowych lub technicznych. Konserwacja powinna być łatwa — to właśnie nieustannie sobie przypominamy. Jak możemy to zapewnić?
Wśród wielu sposobów zapewnienia wysokiej jakości zestawu automatyzacji testów jednym z nich jest zapewnienie możliwości ponownego użycia — nie tylko poprzez ponowne wykorzystywanie często używanych kroków testowych, lecz także często używanych obiektów interfejsu użytkownika. W tym artykule wyjaśnię, jak możemy używać repozytoriów obiektów, aby zwiększyć możliwość ponownego użycia poprzez ponowne wykorzystywanie obiektów w projekcie automatyzacji testów interfejsu użytkownika.
- Czym jest repozytorium obiektów w automatyzacji testów?
- Dlaczego jest to ważne?
- Najlepsze praktyki podczas korzystania z repozytoriów obiektów
- Jak tworzyć repozytoria obiektów (przykłady)
Czym jest repozytorium obiektów w automatyzacji testów?
Gdy po raz pierwszy zaczynasz projektować zestaw automatyzacji testów, większość z nas dba o to, aby nie przepisywać bloków kodu. W tym celu tworzymy funkcje wielokrotnego użytku i udostępniamy wielokrotnego użytku bloki kodu w bibliotekach kodu. Czy jednak ponownie wykorzystywałeś często używane obiekty interfejsu użytkownika? Jeśli nie, wyjaśnię, jak możesz to zrobić, tworząc repozytorium obiektów jako podstawę.
Repozytorium obiektów to zbiór obiektów interfejsu użytkownika, które są ze sobą często powiązane. Nie tylko zwiększa ono możliwość ponownego użycia, lecz także zapewnia niezawodność i ułatwia zarządzanie elementami interfejsu użytkownika w zestawie automatyzacji.
Podczas tworzenia skryptów automatyzacji testów powiązałbyś kroki skryptu testowego z każdym z tych obiektów interfejsu użytkownika. Na przykład –
- Wpisywanie tekstu do obiektu interfejsu użytkownika będącego polem tekstowym
- Pobieranie tekstu z obiektu interfejsu użytkownika będącego etykietą
- Klikanie obiektu będącego hiperłączem... i tak dalej.
Jak zatem możesz zwiększyć możliwość ponownego użycia poprzez ponowne wykorzystywanie obiektów interfejsu użytkownika, na których pracują Twoje skrypty?
Jeśli używane przez Ciebie narzędzie do automatyzacji testów ma „repozytorium obiektów”, jest to łatwe. Korzystając z repozytorium obiektów, możesz gromadzić obiekty interfejsu użytkownika oraz dodawać, usuwać, zarządzać nimi lub aktualizować je w uporządkowany sposób. Ostatecznie możesz ponownie wykorzystywać obiekty, odwołując się do nich.
Przeanalizujmy sytuację, w której w zestawie automatyzacji testów nie używasz OR. W takim przypadku w osobnych skryptach automatyzacji testów korzystających z tego samego elementu interfejsu użytkownika dodawałbyś wiele kopii tego samego obiektu interfejsu użytkownika do każdego ze skryptów testowych, aby wykonywać na nim działania.
Rozważmy teraz sytuację, w której używamy OR. W takim przypadku mielibyśmy jedną lokalizację/repozytorium, w którym przechowywalibyśmy obiekty interfejsu użytkownika. Dzięki temu każdy skrypt testowy, który musi działać na tym samym obiekcie/elemencie interfejsu użytkownika, byłby powiązany z tym samym obiektem interfejsu użytkownika przechowywanym w OR. W zestawie testów istnieje tylko jedna kopia obiektu interfejsu użytkownika, a wiele skryptów testowych odwołuje się do tego samego obiektu interfejsu użytkownika lub go wywołuje. I właśnie tutaj pojawia się możliwość ponownego użycia!
Have an account? Log In
Dlaczego jest to ważne?
Po raz pierwszy zetknąłem się z OR, gdy używałem go w narzędziu IBM Rational Functional Test Automation. Od tamtej pory, za każdym razem, gdy poznaję nowe narzędzie, sprawdzam, czy ma ono funkcję OR.
Po raz pierwszy użyłem OR, gdy nasz zespół automatyzował rozbudowaną administracyjną konsolę internetową z wieloma stronami. Mieliśmy ponad 100 przypadków testowych do zautomatyzowania. Gdybyśmy nie użyli OR, automatyzacja byłaby ogromnym wyzwaniem. Przeanalizowaliśmy sytuację i doszliśmy do wniosku, że zestaw automatyzacji testów, który zamierzaliśmy zbudować, idealnie nadawał się do użycia OR.
Jakie były powody?
1. Każdy z automatyzowanych przez nas przypadków testowych zawierał kilka wspólnych podprzepływów, a zatem miał wspólne widżety interfejsu użytkownika.
Ponieważ istniały wspólne podprzepływy, w scenariuszach występowały oczywiste wspólne obiekty interfejsu użytkownika. Nie chcieliśmy wielokrotnie dodawać kopii tych samych obiektów interfejsu użytkownika, dlatego postanowiliśmy ponownie je wykorzystywać.
Na przykład zestaw przypadków testowych musiałby przejść przez te same odnośniki menu nawigacyjnego przed wykonaniem określonego zestawu kroków. Dlatego zaplanowaliśmy utworzenie repozytorium przeznaczonego wyłącznie do przechowywania wszystkich odnośników nawigacyjnych i zarządzania nimi. Następnie mogliśmy ponownie wykorzystywać odnośniki menu nawigacyjnego w pliku OR.
2. Poinformowano nas, że w przyszłości mogą wystąpić aktualizacje interfejsu użytkownika — dotyczące hiperłączy, etykiet itp.
Dlatego chcieliśmy mieć pewność, że gdy dojdzie do takiej aktualizacji interfejsu użytkownika, zestaw automatyzacji testów będzie można łatwo dostosować do zmiany, a wszelkie prace konserwacyjne będą szybkie i proste.
W tym momencie OR przyszedł nam z pomocą: nie musieliśmy wprowadzać zmian w repozytoriach obiektów interfejsu użytkownika w każdej kopii tego samego obiektu. Gdy nastąpiła zmiana, wystarczyło zaktualizować jeden powiązany obiekt w OR, a skrypty testowe uruchamiały się zgodnie ze zaktualizowanym obiektem interfejsu użytkownika.
3. Musieliśmy zbudować zestaw testów automatyzacji obejmujący ponad 100 skryptów w ciągu miesiąca!
W tym miejscu pojawiła się kolejna zaleta korzystania z OR: przyjmując podejście polegające na zbudowaniu OR, dzięki któremu nikt z nas nie musiał ponownie dodawać tych samych obiektów interfejsu użytkownika, zaoszczędziliśmy czas. Zbudowaliśmy dobrze zorganizowane OR, a wszystko, co musieliśmy zrobić, to napisać kod wokół obiektów uporządkowanych w OR.
Skupiliśmy się na celu przypadku testowego i logice biznesowej przypadków testowych, zamiast tracić czas na ponowne wymyślanie sposobu dodawania obiektów dla każdego skryptu testowego. Zaoszczędziliśmy czas i ostatecznie dostarczyliśmy zestaw testów automatyzacji w zakładanym terminie jednego miesiąca!
Najlepsze praktyki, których należy przestrzegać podczas korzystania z repozytoriów obiektów
Teraz, gdy znasz już sytuacje, w których repozytorium obiektów interfejsu użytkownika może być pomocne, czy nie chcesz wiedzieć, co sprawia, że działa ono tak dobrze?
1. Jako zespół ustalcie wspólny cel ponownego wykorzystania. Wspólnie zrozumcie, dlaczego może to pomóc zespołowi automatyzacji, zespołowi testów manualnych, a ostatecznie także klientowi.
2. Podczas tworzenia zestawu testów automatyzacji jako zespół zawsze pozostawajcie w synchronizacji i informujcie się nawzajem o tworzonych obiektach. Ustalcie zestaw zasad grupowania i konwencji nazewniczych, których wszyscy będziecie przestrzegać. Na początku możecie opracować plan organizowania i przechowywania poszczególnych plików OR. Na przykład obiekty menu nawigacyjnego w jednym pliku OR, obiekty interfejsu użytkownika strony logowania w innym pliku OR itd. Możecie również ustalić konwencje nazewnicze obiektów, aby można je było łatwo znaleźć.
3. Pamiętajcie, aby nazywać obiekty interfejsu użytkownika w sposób czytelny, ułatwiający ich znalezienie i powiązanie. Nazwijcie obiekty interfejsu użytkownika tak, aby każda osoba przeglądająca repozytorium interfejsu użytkownika w celu jego aktualizacji mogła łatwo znaleźć dany obiekt. W poniższym przykładzie pokażę taką sytuację.
Jak tworzyć repozytoria obiektów (przykłady)
Przejdźmy teraz do praktyki i zobaczmy, jak szybko rozpocząć pracę z repozytoriami obiektów. Narzędzia takie jak UFT, IBM RFT, UiPath Test Automation Suite i Power Automate zawierają repozytoria obiektów. Dlaczego więc czekać? Uwierz mi, to naprawdę bardzo proste!
Oto przykład OR, które utworzyłem dla witryny QAL:
Spójrz na powyższy interfejs użytkownika – zgrupowałem wszystkie widżety związane z wykonywaniem działań na widżetach interfejsu użytkownika logowania, ponieważ będą one wspólne dla kilku przypadków testowych. Następnie zgrupowałem razem odnośniki nawigacyjne. Jeśli zarejestrujemy te obiekty w grupie, a wszystkie skrypty testowe będą na początku każdego przypadku testowego korzystać z tej grupy obiektów odnośników interfejsu użytkownika, obiekty te będzie można ponownie wykorzystać zamiast dodawać je ponownie do repozytorium
Przykład użycia repozytorium obiektów w UiPath
Tak wygląda repozytorium obiektów w narzędziu UiPath:
W tym przykładzie repozytorium obiektów uporządkowałem obiekty „strony logowania” w jednym zestawie, a „główne odnośniki nawigacyjne” w innym. Dzięki temu, gdybym miał utworzyć kilka skryptów testowych, aby — powiedzmy — przetestować stronę logowania, wszystkie skrypty testowe „wywoływałyby” te same obiekty, które umieściłem w „stronie logowania”.
More Articles
Przykład użycia repozytorium obiektów w PowerAutomate
Tak wygląda repozytorium obiektów w narzędziu PowerAutomate:
Jak wspomniałem wcześniej, kluczem do ponownego wykorzystania jest również zadbanie o to, aby obiekty były nazwane w sposób ułatwiający ich późniejsze znalezienie. Zwróć uwagę na obiekt interfejsu użytkownika „meprmath_quiz”. W przeciwieństwie do innych pól nie możemy łatwo określić, do którego obiektu interfejsu użytkownika się odnosi. Dlatego w takim przypadku, mimo że po dodaniu obiektu interfejsu użytkownika dla pola tekstowego „quiz” wyświetlana nazwa pola to „meprmath_quiz”, moglibyśmy nazwać go na przykład „login_add”, aby ułatwić znalezienie obiektu podczas automatyzacji i utrzymywania OR.
Podsumowanie
Jak zatem używasz OR w swoim ulubionym narzędziu do automatyzacji testów? Chętnie się dowiemy.
Mam nadzieję, że ten artykuł pomoże Ci zrozumieć, jak OR wspiera zespół w dłuższej perspektywie. Mamy szczęście żyć w czasach, gdy większość narzędzi do automatyzacji testów ma dostępną funkcję OR. W związku z tym wystarczy, że sprawdzisz, jak działa ona w Twoim ulubionym narzędziu!
Dowiedziałeś się czegoś nowego z tego artykułu? Jeśli interesują Cię kolejne artykuły tego typu, nie zapomnij zasubskrybować biuletynu The QA Lead!
Powiązane materiały:
Powiązana lista narzędzi: OPROGRAMOWANIE DO TESTÓW WYDAJNOŚCIOWYCH DLA ZESPOŁÓW QA
Również warto sprawdzić:
