Praktyczny strumień pracy wsparcia do zamiany konkretnej skargi na system Android w powtarzalny przypadek, pakiet dowodów i przydatne przekazanie inżynierii.
Dlaczego zespoły wsparcia przechowywać więcej niż jeden telefon Android
Klient może dokładnie opisać awarię i nadal nie jest w stanie jej odtworzyć. Wersja aplikacji może mieć rację, ale problem pojawia się tylko na jednym producenta build, wersję Android, rozmiar wyświetlacza, stan zezwolenia, język, sieć lub polityka baterii. Jeden telefon referencyjny nie może reprezentować tego zakresu. Dlatego mobilne zespoły wsparcia często trzymają mały zestaw prawdziwych telefonów z systemem Android nawet wtedy, gdy inżynieria już używa emulatorów i testów automatycznych.
Celem nie jest posiadanie każdego modelu. Ma to na celu utrzymanie wystarczającego zakresu, aby szybko odpowiedzieć na trzy pytania: czy zespół może odtworzyć raport, który warunek go uruchamia, i jakie dowody pozwolą inżynieria kontynuować bez powtarzania całej rozmowy wsparcia? AWS Device Farm również identyfikuje przedstawicieli obsługi klienta obok deweloperów i zespołów QA, a także opisuje interakcję real- device jako sposób na debugowanie i powielanie problemów klientów.
- Uwierzytelnianie, płatności, powiadomienia, zezwolenia, aparat fotograficzny, Bluetooth, i niepowodzenia procesu tła.
- Układy, które psują się na danym ekranie gęstości, skali czcionek, języku lub trybie nawigacyjnym.
- Problemy z modernizacją lub instalacją związane z wersją Android lub firmware producenta.
- Problemy pojawiające się dopiero po zmianie sieci, cofnięciu aplikacji, ograniczeniu baterii lub przerwaniu.
- Raporty klientów, które wymagają zrzut ekranu, krótkie nagranie, szczegóły urządzenia i dokładne kroki reprodukcji przed eskalacją.
Zbierz minimalne dane przypadku przed wyborem telefonu
Nie zaczynaj od kliknięcia przez przypadkowe telefony. Najpierw przerób rozmowę wsparcia na testable. Brak danych wejściowych marnuje więcej czasu niż fizyczna konfiguracja urządzenia, ponieważ zespół nie może odróżnić specyficznej device- defektu od konta, build, network lub stale-data problem.
| Pole przypadku | Dlaczego to ma znaczenie? | Dopuszczalne dowody |
|---|---|---|
| Wersja aplikacji i budowa | Potwierdza testowane oprogramowanie | O ekranie, wersji lub identyfikatorze budowy |
| Model telefonu i wersja Android | Wybór najbliższego prawdziwego urządzenia | Ustawienia zrzutu ekranu lub tekstu diagnostycznego |
| Dokładny stan początkowy | Zapobiega ukrytym różnicom konfiguracji | Signed- in state, uprawnienia, flagi funkcji i ekran poprzedni |
| Działania i oczekiwane rezultaty | Pozwala na odtwarzanie raportu | Numeracja kroków plus to, co powinno się stać |
| Rzeczywisty wynik i harmonogram | Oddziela awarie wizualne, awaryjne, sieciowe i opóźniające | Zrzut ekranu, krótkie nagranie, znacznik czasu lub tekst błędu |
| Sieć, język i region | Eksponuje warunki środowiskowe | Wi- Fi / stan mobilny, locale, strefa czasowa i rynek |
| Częstość występowania | Przewodniki powtarzać liczbę | Zawsze, przerywany, pierwszy start, lub po długim bezczynności |
Jeśli klient nie może zapewnić wszystkiego, rejestrować to, co jest nieznane, zamiast po cichu wypełniać luki. Wsparcie może nadal testować znaną ścieżkę, ale inżynieria powinna być w stanie zobaczyć, które założenia zostały podjęte. Nigdy nie proś klientów o wysyłanie haseł, danych płatniczych, dokumentów tożsamości, prywatnych wiadomości lub niepowiązanych plików osobistych.
Zbuduj małą matrycę urządzenia z dowodów klienta
Przydatne biurko jest oparte na urządzeniach, z których faktycznie korzystają klienci, a nie na półce atrakcyjnych telefonów flagowych. Zacznij od analizy, raportów o katastrofach, wolumenu biletów i segmentów o krytycznym znaczeniu. Wybierz urządzenie niskokońcowe, wspólny model średniego zasięgu, najnowszy flagowy oraz dowolną wersję producenta lub Android, która pojawia się wielokrotnie w nierozwiązanych przypadkach.
- Eksportuj najlepsze modele urządzeń i wersje Android z wiarygodnych danych produktu.
- Grupa podobnych urządzeń wg producenta oprogramowania firmowego, poziomu wydajności, charakterystyk ekranu i wytwarzania systemu operacyjnego.
- Wybierz najmniejszy zestaw fizyczny, który obejmuje największą część ważnych spraw.
- Dodać model tylko wtedy, gdy ryzyko związane z biletami lub produktem uzasadnia koszty utrzymania.
- Przegląd matrycy kwartalnych i urządzeń na emeryturę, które nie stanowią już znaczącego ruchu lub ryzyka.
Trzy-do-sześciu-biurko jest często bardziej przydatne niż duża nieutrzymana kolekcja. Szerosze operacje kompatybilności mogą jeszcze przejść do usługi w chmurze. Lokalne biurko istnieje dla szybkiej interaktywnej reprodukcji, demonstracje wsparcia i przypadki, w których te same urządzenia są wykorzystywane wielokrotnie. Fizyczna konfiguracja, zobaczniskie koszty Android lab lab przewodnik.
Zorganizuj wielotelefoniczne biurko wsparcia
Każdy telefon potrzebuje stabilnej tożsamości. Podaj krótki kod, oznacz go fizycznie i napisz jego model, wersję z Androidem, ostatnią datę resetowania, stan baterii, metodę podłączenia, zainstalowaną konstrukcję testową i przypisane konta testowe. Korzystanie z niezawodnych kabli i zasilanych węzłów USB, gdy kilka telefonów dzieli jeden komputer; niestabilna moc i uszkodzone kable mogą spowodować awarie, które wyglądają jak wady aplikacji.
Sterowanie wieloma telefonami z systemem Androidze wspólnej przestrzeni roboczej, kiedy zespół musi porównać ekrany, poruszać się między urządzeniami lub powtórzyć autoryzowany krok konfiguracji. WLaiCai Screen Mirroring, urządzenia mogą być widoczne z jednej stacji roboczej Windows lub MacOS, więc operator spędza mniej czasu na odbieraniu telefonów i więcej czasu porównując stan sprawy. Grupowanie jest przydatne do oddzielenia czystych linii podstawowych, aktywnych przypadków wsparcia, urządzeń niskokońcowych i telefonów oczekujących na resetowanie.
- Zachowaj jedno znane urządzenie bazowe do porównania.
- W miarę możliwości należy wykorzystywać dedykowane rachunki testowe z danymi syntetycznymi.
- Zresetuj dane aplikacji pomiędzy przypadkami, kiedy stan poprzedzający może zmienić wynik.
- Kod telefonu jest widoczny w każdym zrzucie ekranu lub notatce.
- Ładowanie płyt, USB, Wi- Fi i warunki termiczne, gdy wpływają na badanie.
Uruchom kontrolowaną kartę reprodukcji
Najszybsza droga do użytecznego rezultatu jest zazwyczaj kontrolowane porównanie, a nie duża partia jednoczesnych działań. Zacznij od najbliższego urządzenia pasującego i odtwórz stan początkowy klienta. Uruchom zgłoszone kroki raz bez zmiany niczego. Jeśli pojawi się problem, powtórzyć, aby potwierdzić częstotliwość. Jeśli nie, należy zmienić jedną zmienną w czasie: sieć, pozwolenie, język, dane aplikacji, wersję Android, producenta, skalę czcionki lub politykę baterii.
- Tworzenie karty przypadku z kodem telefonu, budowania aplikacji, typu konta, sieci, locale i ekranu startowego.
- Odtworzyć dokładne kroki klienta na najbliższym telefonie pasującym.
- Powtarzaj tę samą ścieżkę na świadomym telefonie bazowym.
- Zmień tylko jeden podejrzany stan i uruchom ścieżkę ponownie.
- Zatrzymać się, gdy spust jest izolowany lub uzgodniony limit próby jest osiągnięty.
- Zapisz zarówno udane, jak i nieudane próby; negatywne dowody zawężają kolejne dochodzenie.
Nie używaj zsynchronizowanego wejścia, gdy urządzenia już się rozproszyły. Okno zezwolenia, wolne obciążenie, klawiatura lub polecenie aktualizacji może wysłać to samo kliknięcie do różnych sterowników. Wspólne działania są przydatne tylko wtedy, gdy każdy wybrany telefon jest widoczny w tym samym bezpiecznym stanie. W przeciwnym razie, obsłużyć urządzenia indywidualnie i zachować różnicę próbujesz zrozumieć.
Tworzenie dowodów inżynieria pakietu może powtórzyć
Przydatne przekazanie jest wystarczająco małe, aby szybko i wystarczająco kompletne, aby powtórzyć. Jeden bilet powinien łączyć środowisko, kroki, obserwowany wynik, oczekiwany wynik i dowody potwierdzające. Zrzut ekranu pokazuje stan statyczny; krótki zapis ekranu udowadnia czas i sekwencję; logi wyjaśniają, czego interfejs nie może pokazać. Żaden z nich nie zastępuje innych.
| Artefakt | Dołącz | Unikaj |
|---|---|---|
| Streszczenie sprawy | Jedno zdanie opisujące niepowodzenie i wpływ działalności gospodarczej | Zapis na czacie bez wniosku |
| Środowisko | Kod telefonu, model, wersja Android, budowa aplikacji, locale i sieci | Niezweryfikowane przypuszczenia dotyczące telefonu klienta |
| Kroki | Liczba akcji z określonego stanu wyjściowego | Kroki takie jak "używać aplikacji normalnie" |
| Wizualny dowód | Jeden zrzut ekranu lub krótkie nagranie | Długie nagrania zawierające niepowiązane ekrany |
| Logi | Odpowiedni zakres czasowy i identyfikatory | Pełne dzienniki zawierające tajemnice lub niepowiązane dane klienta |
| Porównanie | Wynik na telefon dotknięty i telefon podstawowy | Specyfika urządzenia mocującego po badaniu tylko jednego telefonu |
| Współczynnik reprodukcji | Próby i obserwowane niepowodzenia | Niewspierane oświadczenie takie jak "zdarza się losowo" |
Wymień pliki z identyfikatorem biletu, kodem telefonu, budowaniem i znacznikiem czasu. Przekazanie powinno pozwolić inżynierowi zrozumieć awarię w ciągu kilku minut bez otwierania wielu wątków czatu. Aby uzyskać szerszy zakres pracy QA, zobaczMirroning ekranu Android do testowania aplikacji mobilnych.
Wybierz lokalne telefony, emulatory lub usługę urządzenia w chmurze
Te narzędzia rozwiązują różne problemy z zasięgiem. Lokalne biurko telefoniczne nie zastępuje farmy urządzeń w chmurze, a laboratorium w chmurze nie eliminuje wartości znanych telefonów obok zespołu wsparcia. Wybierz najmniej drogie środowisko, które może odtworzyć stan wiernie.
| Środowisko | Najlepsze dla | Główne ograniczenie |
|---|---|---|
| Emulator | Szybka konfiguracja, wczesne sprawdzanie interfejsu użytkownika, powtarzalne konfiguracje wirtualne | Nie można odtwarzać każdego sprzętu, oprogramowania firmowego, czujnika, termicznego lub zachowania nośnika |
| Lokalne biuro real- phone | Częste interaktywne przypadki, demonstracje wsparcia, powtarzające się modele, przepływy pracy USB / Bluetooth / kamery | Ograniczone do urządzeń, które zespół posiada i utrzymuje |
| Usługa ponownego urządzenia w chmurze | Rzadkie modele, szeroki zasięg wydania, równoległe zautomatyzowane biegi, zdalne zespoły | Koszty sesji, dostępność, zasady obsługi danych i mniej fizycznego dostępu |
| Rozmnażanie wspomagane przez użytkownika | Warunki istniejące tylko w środowisku klienta | Wymaga starannych instrukcji, zgody i ścisłej minimalizacji danych |
Praktyczna sekwencja jest emulatorem najpierw dla szybkiego sprawdzenia zdrowia psychicznego, lokalnych telefonów dla prawdopodobnych przyczyn real- device, i urządzeń w chmurze, gdy model jest brakujący lub przypadku wymaga szerszego potwierdzenia.lustrzany ekran Android na komputerze PC lub Macjest najbardziej przydatny, gdy wsparcie wymaga bezpośredniej kontroli wizualnej lokalnych telefonów, a nie zarządzania polityką całej rozproszonej floty przedsiębiorstw.
Ochrona danych klientów podczas reprodukcji
Prawdziwe rozwiązywanie problemów z urządzeniami może ujawnić dane osobowe, jeśli proces jest nieostrożny. Użyj kont syntetycznych i danych testowych domyślnie. Jeśli dane produkcyjne są rzeczywiście wymagane, uzyskać odpowiednie zezwolenie, ograniczyć dostęp, uchwycić tylko to, czego potrzeba w przypadku, i zgodnie z polityką firmy zatrzymania. AWS podobnie ostrzega użytkowników swojej usługi urządzenia, aby nie wprowadzali danych uwierzytelniających konta, danych osobowych lub innych danych szczególnie chronionych, ponieważ sesje mogą generować logi i wideo.
- Nigdy nie kopiuj hasła klienta, informacji o płatnościach, symbolu uwierzytelniania, prywatnych zdjęć lub dokumentów tożsamości do telefonu laboratoryjnego.
- Niepowiązane nazwy, wiadomości, adresy e-mail i numery kont przed dołączeniem dowodów.
- Prowadzić rachunki testowe oddzielone od środowiska i obracać referencje zgodnie z polityką firmy.
- Usuwanie zrzutów ekranu, nagrań, dzienników, pobranych plików i danych aplikacji po zakończeniu okresu retencji.
- Zapis, który miał dostęp do delikatnej sprawy i dlaczego, gdy polityka wymaga ścieżki audytu.
Pilot przepływu pracy z trzech telefonów
Nie zaczynaj od kupowania ściany telefonów. Wybierz jedną powtarzającą się klasę wsparcia i trzy reprezentatywne urządzenia: know-good bazowy, najczęstszy telefon klienta i kontrastujący niski lub specyficzny telefon. Uruchom przepływ pracy przez dwa tygodnie, a następnie zdecydować, czy inne urządzenie lub usługa w chmurze rozwiązałaby sprawy, których pilot nie mógł pokryć.
- Wybierz dziesięć ostatnich biletów, które zostały opóźnione przez niepewność urządzenia.
- Określić wymagane pola poboru i jeden szablon pakietu dowodowego.
- Oznakuj i przygotuj trzy telefony z czystym kontem testowym.
- Czas na pierwsze znaczące odtwarzanie, pętle wyjaśniające, akceptację eskalacji i nierozwiązane luki urządzeń.
- Przegląd, który telefon lub stan środowiska rzeczywiście zmienił wynik.
- Rozwijać tylko wtedy, gdy dowody wykazują powtarzającą się lukę w zakresie zasięgu.
Wynik weryfikacji jest prosty: inżynier wsparcia powinien być w stanie otrzymać przypadek, wybrać odpowiedni telefon, powtórzyć ścieżkę i dostarczyć samodzielnie zawarte przekazanie bez przeszukiwania kilku niepowiązanych systemów. Jeśli wspólna lokalna przestrzeń robocza pomoże temu pilotowi,LaiCai Screen Mirroringmoże przechowywać wybrane telefony z systemem Android widoczne i sterowalne z jednego komputera Windows lub macOS.
Często zadawane pytania
Ile telefonów z Androidem potrzebuje zespół wsparcia?
Zacznij od trzech do sześciu telefonów wybranych z rzeczywistych danych o bilecie i użyciu. Dodawanie urządzeń tylko wtedy, gdy powtarzany, ważny przypadek nie może być objęty bieżącą macierzą lub okazjonalną sesją w chmurze.
Czy wsparcie powinno odtwarzać każdy raport klienta?
Nie. Pierwszeństwo dotkliwość, dotknięci użytkownicy, wpływ na biznes, ryzyko bezpieczeństwa, powtórzenie i czy reprodukcja zmieni kolejne działanie. Laboratorium urządzeń jest narzędziem decyzyjnym, a nie wymogiem powtarzania każdej niejasnej skargi.
Czy zsynchronizowana kontrola może odtworzyć błąd na każdym telefonie naraz?
Tylko wtedy, gdy urządzenia są widoczne w tym samym stanie i działanie jest bezpieczne. Kiedy czas, dialogi, uprawnienia, klawiatury, lub układy różnią się, obsługują telefony indywidualnie. Dywergencja jest dowodem, a nie czymś, przez co można przebić się na ślepo.
Czy LaiCai zastępuje platformę zarządzania urządzeniami mobilnymi?
Nie.LaiCai Screen Mirroringjest lokalnym narzędziem kontroli wizualnej i przepływu pracy. Rozproszone floty przedsiębiorstw, które potrzebują zaksięgowania zero-touch, egzekwowania przepisów, dystrybucji aplikacji, inwentaryzacji lub zdalnego wycierania, powinny korzystać z odpowiedniego systemu MDM lub EMM.