🏅 Jak działa wydobywanie GPU?

GPU to ważna jednostka komputera, która odpowiada za renderowanie i wyświetlanie obrazów i filmów. Jednostki przetwarzania grafiki są zoptymalizowane do przetwarzania dużych bloków danych. Dlatego jest lepszy niż CPU do kopania. Jeśli kopiesz dowolną kryptowalutę za pomocą GPU, nie musisz często przełączać się między dwoma zadaniami. Dzięki temu może przetwarzać więcej haszy jednocześnie.

Proces zarządzania defektami w testowaniu oprogramowania

Co to jest proces zarządzania defektami?

Zarządzanie defektami to systematyczny proces identyfikacji i naprawy błędów. Cykl zarządzania defektami zawiera następujące etapy: 1) Odkrycie defektu, 2) Kategoryzacja defektów, 3) Naprawa defektu przez programistów, 4) Weryfikacja przez testerów, 5) Zamknięcie defektu, 6) Raporty o defektach na koniec projektu.

W tym temacie dowiesz się, jak zastosować proces zarządzania defektami w witrynie projektu Guru99 Bank. Aby zarządzać defektami, możesz wykonać poniższe kroki.

Krok 1) Odkrycie

W fazie odkrywania zespoły projektowe muszą odkryć jako wiele wady jako możliwy, zanim klient końcowy będzie mógł to odkryć. Mówi się, że wada została wykryta i zmieniona na status zaakceptowany gdy zostanie to potwierdzone i zaakceptowane przez programistów

W powyższym scenariuszu testerzy odkryli 84 defekty w serwisie Guru99.

Przyjrzyjmy się następującemu scenariuszowi: Twój zespół testowy odkrył pewne problemy na stronie internetowej Guru99 Bank. Uważają je za wady i zgłaszają zespołowi programistów, ale istnieje konflikt –

Co w takiej sytuacji zrobisz jako Menedżer Testów?

A) Zgadzam się z zespołem testowym, że jest to wada

B) Kierownik Testów przyjmuje rolę sędziego i decyduje, czy problem jest defektem, czy nie

C) Zgadzam się z zespołem programistów, że nie jest to wada

Poprawny

Błędny

W takim przypadku należy zastosować proces rozwiązywania konfliktu, a Ty pełnisz rolę sędziego, który zadecyduje, czy problem ze stroną internetową jest wadą, czy nie.

Krok 2) Kategoryzacja

Kategoryzacja defektów pomaga twórcom oprogramowania w ustaleniu priorytetów swoich zadań. Oznacza to, że tego rodzaju priorytet pomaga programistom w naprawianiu w pierwszej kolejności tych defektów, które są bardzo istotne.

Defekty są zwykle kategoryzowane przez Kierownika Testów –

Zróbmy małe ćwiczenie, jak następuje

Przeciągnij i upuść priorytet defektu poniżej

1) Działanie witryny jest zbyt wolne
2) Funkcja logowania do serwisu nie działa prawidłowo
3) GUI strony internetowej nie wyświetla się poprawnie Mobile urządzenia
4) Serwis nie zapamiętał sesji logowania użytkownika
5) Niektóre linki nie działają

Oto zalecane odpowiedzi

Nie.	Opis	Priorytet	Wyjaśnienie
1	Działanie witryny jest zbyt wolne	Wysoki	Błąd wydajnościowy może powodować ogromne niedogodności dla użytkownika.
2	Funkcja logowania na stronie nie działa prawidłowo	Krytyczny	Logowanie jest jedną z głównych funkcji serwisu bankowego. Jeśli ta funkcja nie działa, oznacza to poważne błędy
3	GUI strony internetowej nie wyświetla się poprawnie na urządzeniach mobilnych	Średni	Wada dotyczy użytkownika korzystającego ze Smartfona do przeglądania serwisu.
4	Strona nie pamięta sesji logowania użytkownika	Wysoki	Jest to poważny problem, gdyż użytkownik będzie mógł się zalogować, ale nie będzie mógł dokonywać dalszych transakcji
5	Niektóre linki nie działają	Niski	Jest to łatwe rozwiązanie dla programistów, a użytkownik nadal może uzyskać dostęp do witryny bez tych linków

Krok 3) Rozwiązanie wady

Rozwiązywanie usterek w testowaniu oprogramowania jest to krok po kroku proces naprawiania defektów. Proces rozwiązywania defektów rozpoczyna się od przypisania defektów programistom, następnie programiści planują naprawę defektów według priorytetu, następnie defekty są naprawiane, a na koniec programiści wysyłają raport o rozwiązaniu do kierownika testów. Proces ten ułatwia naprawianie i śledzenie defektów.

Aby naprawić usterkę, możesz wykonać następujące czynności.

Cesja: Przypisany do programisty lub innego technika do naprawy i zmieniony na Odpowiadając.
Ustalanie harmonogramu: W tej fazie odpowiedzialność przejmuje strona programisty. Przygotują harmonogram naprawy tych usterek, w zależności od priorytetu wady.
Napraw usterkę: Podczas gdy zespół programistów naprawia defekty, Kierownik Testów śledzi proces usuwania defektów w porównaniu z powyższym harmonogramem.
Zgłoś uchwałę: Uzyskaj raport o rozwiązaniu od programistów po naprawieniu defektów.

Krok 4) Weryfikacja

Po zespole programistów ustalony i zgłaszane usterka, zespół testujący weryfikuje że wady zostały faktycznie usunięte.

Na przykład w powyższym scenariuszu, gdy zespół programistów zgłosił, że naprawił już 61 defektów, Twój zespół przeprowadziłby ponowne testy, aby sprawdzić, czy te defekty rzeczywiście zostały naprawione.

Krok 5) Zamknięcie

Po usunięciu i zweryfikowaniu wady, status wady zostaje zmieniony na zamknięte. Jeśli nie, wysłałeś powiadomienie do działu rozwoju, aby ponownie sprawdzili usterkę.

Krok 6) Zgłaszanie usterek

Zgłaszanie usterek w testowaniu oprogramowania to proces, podczas którego menedżerowie testów przygotowują i wysyłają raport o defektach do zespołu zarządzającego w celu uzyskania informacji zwrotnej na temat procesu zarządzania defektami i statusu defektów. Następnie zespół zarządzający sprawdza raport o defektach i przesyła informację zwrotną lub w razie potrzeby zapewnia dalsze wsparcie. Zgłaszanie usterek pomaga lepiej komunikować się, śledzić i szczegółowo wyjaśniać wady.

Zarząd ma prawo znać stan wady. Aby wspierać Cię w tym projekcie, muszą rozumieć proces zarządzania defektami. Dlatego musisz zgłosić im aktualną sytuację związaną z usterką, aby uzyskać od nich informację zwrotną.

Dlaczego potrzebujesz procesu zarządzania defektami?

Twój zespół znalazł błędy podczas testowania projektu Guru99 Banking.

Po tygodniu deweloper odpowiada –

W przyszłym tygodniu tester odpowie

Podobnie jak w powyższym przypadku, jeśli zgłaszanie usterek odbywa się ustnie, wkrótce sytuacja bardzo się komplikuje. Aby kontrolować błędy i skutecznie nimi zarządzać, potrzebny jest cykl życia defektów.

Ważne wskaźniki defektów

Wróć do powyższego scenariusza. Deweloperzy i zespoły testowe dokonują przeglądu zgłoszonych defektów. Oto wynik tej dyskusji

Jak mierzyć i oceniać jakość wykonania testu?

To pytanie, które każdy Kierownik Testów chce wiedzieć. Są 2 parametry, które możesz rozważyć jako następujące

W powyższym scenariuszu można obliczyć współczynnik odrzucenia dezercji (DRR) jest 20/84 = 0.238 (23.8%).

Inny przykład zakłada, że witryna banku Guru99 ma sumę 64 defekty, ale Twój zespół testowy tylko je wykrywa 44 wady, tj. przegapiły 20 wady. Dlatego można obliczyć współczynnik wycieku defektu (DLR) wynoszący 20/64 = 0.312 (31.2%).

Wnioski: jakość wykonania testów ocenia się na podstawie następujących dwóch parametrów

Im mniejsza wartość DRR i DLR, tym lepsza jakość wykonania testu. Jaki jest zakres proporcji do przyjęcia? Zakres ten można zdefiniować i zaakceptować jako podstawę w celu projektu lub można odwoływać się do wskaźników podobnych projektów.

W tym projekcie zalecaną wartością akceptowalnego współczynnika jest 5 ~ 10%. Oznacza to, że jakość wykonania testu jest niska. Powinieneś znaleźć środek zaradczy, aby zmniejszyć te wskaźniki, takie jak

Poprawa umiejętności testowania członka.
Spędzać więcej czasu do testowania wykonania, zwłaszcza do przeglądania wyników testowania.

Najczęstsze pytania

Błąd jest konsekwencją/wynikiem błędu w kodowaniu.

A Wada w testowaniu oprogramowania to odmiana lub odchylenie aplikacji od wymagań użytkownika końcowego lub oryginalnych wymagań biznesowych. Wada oprogramowania to błąd w kodowaniu, który powoduje nieprawidłowe lub nieoczekiwane wyniki działania programu, który nie spełnia rzeczywistych wymagań. Testerzy mogą natknąć się na takie defekty podczas wykonywania przypadków testowych.

Te dwa terminy różnią się bardzo cienką linią. W branży oba są usterkami, które należy naprawić, dlatego niektórzy producenci używają ich zamiennie Testowanie zespołów.

Kiedy testerzy wykonują przypadki testowe, mogą natknąć się na wyniki testów, które są sprzeczne z oczekiwanymi wynikami. Ta różnica w wynikach testów nazywana jest wadą oprogramowania. Te defekty lub odmiany są określane w różnych organizacjach pod różnymi nazwami, takimi jak problemy, problemy, błędy lub incydenty.

Raport o błędach w testowaniu oprogramowania to szczegółowy dokument dotyczący błędów znalezionych w aplikacji. Raport o błędzie zawiera szczegółowe informacje na temat błędów, takie jak opis, data znalezienia błędu, nazwisko testera, który go znalazł, nazwisko programisty, który go naprawił itp. Raport o błędzie pomaga zidentyfikować podobne błędy w przyszłości, dzięki czemu można ich uniknąć.

Identyfikator_defektu – Unikalny numer identyfikacyjny wady.
Wada Descriptjon – Szczegółowy opis Usterki zawierający informację o module, w którym stwierdzono Usterkę.
Wersja – Wersja aplikacji, w której stwierdzono defekt.
Kroki - Szczegółowe kroki wraz ze zrzutami ekranu, dzięki którym programista może odtworzyć defekty.
Data powstania – Data zgłoszenia wady
Odniesienie- gdzie w Twoim przypadku Podaj odniesienie do dokumentów, takich jak wymagania, projekt, architektura, a może nawet zrzuty ekranu błędu, aby pomóc zrozumieć wadę
Wykryty przez - Imię i nazwisko/identyfikator testera, który zgłosił usterkę
Stan - Status wady, więcej na ten temat później
Naprawiono przez – Imię/identyfikator programisty, który to naprawił
Data zamknięcia – Data usunięcia wady
Dotkliwość który opisuje wpływ wady na zgłoszenie
Priorytet co jest związane z pilnością usunięcia usterki. Priorytet ważności może być wysoki/średni/niski w zależności od pilności, z jaką defekt powinien zostać naprawiony

Kliknij tutaj jeśli film nie jest dostępny

Zasoby:

Pobierz przykładowy szablon zgłaszania usterek