Bir cihazla ilgili Android şikayetini tekrar edilebilir bir vakaya, kanıt paketine ve yararlı bir mühendislik devretimine dönüştürmek için pratik bir destek iş akışı.
Neden destek ekipleri birden fazla Android telefon bulunduruyor?
Bir müşteri bir başarısızlığı doğru bir şekilde tanımlayabilir ve yine de destek ekibinin onu yeniden üretememesine izin verebilir. Uygulama sürümü doğru olabilir, ancak sorun yalnızca bir üretici sürümünde, Android sürümünde, ekran boyutunda, izin durumunda, dilde, ağda veya pil politikasında görünür. Tek bir referans telefon bu aralığı temsil edemez. Bu nedenle mobil destek ekipleri, mühendislik zaten emülatörler ve otomatik testler kullandığında bile genellikle küçük bir gerçek Android telefonu seti saklarlar.
Hedef her modeli sahip olmak değil, üç soruyu hızlı bir şekilde yanıtlamak için yeterli kapsama alanı sağlamak. Ekip raporu nasıl üretebilir, hangi koşul onu tetikler ve mühendislik, tüm destek konuşmasını tekrarlamadan devam etmesine neyin kanıtı sağlayacak sorulara yanıt vermek için yeterli kapsama alanı sağlamaktır. AWS Device Farm da geliştiriciler ve QA ekiplerinin yanı sıra müşteri destek temsilcilerini tanımlar ve gerçek cihaz etkileşimini müşteri sorunlarını hata ayıklamak ve yeniden üretmek için bir yöntem olarak tanımlar.
- Kimlik doğrulama, ödeme, bildirim, izin, kamera, Bluetooth ve arka plan işlemi hataları.
- Belirli bir ekran yoğunluğunda, yazı tipi ölçeğinde, dilde veya gezinme modunda kırılan düzenler.
- Bir Android sürümü veya üretici donanım yazılımıyla bağlantılı yükseltme veya kurulum sorunları.
- Sadece bir ağ değişikliği, uygulama arka planı çalışması, pil kısıtlaması veya kesinti sonrasında ortaya çıkan sorunlar.
- Müşteri, yükseltmeden önce ekran görüntüsü, kısa kayıt, cihaz ayrıntıları ve kesin yeniden üretme adımları gerektiren raporlar veriyor.
Bir telefon seçmeden önce minimum kılıf verilerini toplayın
Rastgele telefonlara tıklayarak başlamayın. Öncelikle destek konuşmasını test edilebilir bir vakaya dönüştürün. Eksik giriş verileri, ekip bir cihazla ilgili kusuru bir hesap, yapılandırma, ağ veya eski verilerden ayırt edemediği için fiziksel cihaz kurulumundan daha fazla zaman kaybına neden olur.
| Durum alanı | Neden önemli | Kabul edilebilir kanıt |
|---|---|---|
| Uygulama sürümü ve yapılandırması | Test edilen yazılımı onaylar | Ekran, mağaza sürümü veya yapılandırma tanımlayıcısı hakkında |
| Telefon modeli ve Android sürümü | En yakın gerçek cihazı seçer | Ayar ekran görüntüsü veya teşhis metni |
| Kesin başlangıç durumu | Gizli yapılandırma farklılıklarını önler | Oturum açılmış durum, izinler, özellik bayrakları ve önceki ekran |
| Adımlar ve beklenen sonuç | Raporu tekrar oynatılabilir hale getirir | Sıralı adımlar ve olmalı olanlar |
| Gerçek sonuç ve zamanlama | Görsel, çökme, ağ ve gecikme hatalarını ayırır | Ekran görüntüsü, kısa kayıt, zaman damgası veya hata metni |
| Ağ, dil ve bölge | Çevresel koşulları ortaya koyar | Wi-Fi/mobil durum, bölge, saat dilimi ve pazar |
| sıklık | Kılavuzlar tekrar sayısını tekr | Her zaman, aralıklı, ilk başlatma veya uzun süreli beklemeden sonra |
Bir müşteri her şeyi sağlayamazsa, boşlukları sessizce doldurmak yerine bilinmeyenleri kaydedin. Destek hala bilinen yolu test edebilir, ancak mühendislik hangi varsayımların yapıldığını görebilmelidir. Müşterilere asla şifre, ödeme bilgileri, kimlik belgeleri, özel mesajlar veya ilgisiz kişisel dosyalar göndermelerini istemeyin.
Müşteri kanıtlarından küçük bir cihaz matrisi oluşturun
Faydalı bir destek masası, müşterilerinizin gerçekten kullandığı cihazlara dayanır, çekici bayrak telefonları bir raflarına değil. Analitik, çökme raporları, bilet hacmi ve gelir açısından kritik segmentlerle başlayın. Düşük maliyetli bir cihaz, yaygın bir orta sınıf model, yakın zamanda piyasaya sürülen bir bayrak telefonu ve çözülmemiş vakalarda tekrar tekrar ortaya çıkan herhangi bir üretici veya Android sürümünü seçin.
- Güvenilir ürün verilerinden en iyi cihaz modellerini ve Android sürümlerini içe aktarın.
- Benzer cihazları üretici donanım yazılımı, performans seviyesi, ekran özellikleri ve işletim sistemi nesiline göre gruplandırın.
- Önemli vakaların en büyük kısmını kapsayan en küçük fiziksel seti seçin.
- Sadece biletler veya ürün riski bakım maliyetini haklı çıkarıyorsa bir model ekleyin.
- Matrisi çeyrek yılda gözden geçirin ve artık anlamlı trafik veya risk oluşturmayan cihazları emekliye ayırın.
Üç ila altı telefonlu bir masa, genellikle büyük, bakımsız bir koleksiyondan daha kullanışlıdır. Daha geniş uyumluluk sürümleri hala bulut hizmetine gidebilir. Yerel masa, hızlı etkileşimli yeniden üretime, destek gösterilerine ve aynı cihazların tekrar tekrar kullanıldığı durumlar için mevcuttur. Fiziksel kurulum için, bkz.düşük maliyetli Android cihaz laboratuvar kılavuzu.
Çoklu telefon destek masasını düzenleyin
Her telefonun istikrarlı bir kimliği vardır. Onun için kısa bir kod verin, fiziksel olarak etiketleyin ve modelini, Android sürümünü, son sıfırlama tarihini, pil durumunu, bağlantı yöntemini, yüklü test sürümünü ve atanan test hesaplarını kaydedin. Birden fazla telefon bir bilgisayarı paylaşıyorsa güvenilir kablolar ve güçlü USB hub'ları kullanın; istikrarsız güç ve hasarlı kablolar uygulama kusurlarına benzeyen hatalar oluşturabilir.
Birden fazla Android telefonu kontrol edineğitim ekibi ekranları karşılaştırırken, cihazlar arasında geçiş yaparken veya yetkili bir kurulum adımını tekrar ederken ortak bir çalışma alanından. -deLaiCai Screen Mirroring, cihazlar bir Windows veya macOS masaüstü bilgisayardan görülebilir, böylece operatör telefonları almak için daha az zaman harcar ve kılıf durumunu karşılaştırmak için daha fazla zaman harcar. Gruplandırma, temiz baz çizgilerini, aktif destek durumlarını, düşük maliyetli cihazları ve sıfırlanmayı bekleyen telefonları ayırmak için yararlıdır.
- Karşılaştırma için bilinen iyi bir temel cihaz tutun.
- Mümkün olduğunca sentetik veriler içeren özel test hesaplarını kullanın.
- Önceki durumun sonucu değiştirebileceği durumlarda, vakalar arasında uygulama verilerini sıfırlayın.
- Telefon kodunu her ekran görüntüsünde veya durum notunda görünür tutun.
- Testi etkileyen durumlarda şarj, USB, Wi-Fi ve termal koşulları kaydedin.
Kontrollü bir çoğaltma geçişi çalıştırın
Faydalı bir sonuça giden en hızlı yol genellikle büyük bir eşzamanlı eylem sürümünün değil, kontrollü bir karşılaştırmanın yoludur. En yakın eşleşen cihazdan başlayın ve müşterinin başlangıç durumunu yeniden oluşturun. Bildirilen adımları hiçbir şey değiştirmeden bir kez çalıştırın. Sorun ortaya çıkarsa, sıklığı doğrulamak için tekrar deneyin. Eğer çıkmazsa, bir seferde bir değişken değiştirin: ağ, izin, dil, uygulama verileri, Android sürümü, üretici, yazı tipi ölçeği veya pil politikası.
- Telefon kodu, uygulama oluşturma, hesap türü, ağ, yerel bölge ve başlangıç ekranı ile durum kartını oluşturun.
- Müşterinin tam adımlarını en yakın eşleşen telefonda yeniden oluşturun.
- Bilinen iyi durumda olan temel telefon üzerinde aynı yolu tekrarlayın.
- Sadece bir şüpheli durumu değiştirin ve yolu tekrar çalıştırın.
- Tetikleyici izole olduğunda veya anlaşılan deneme limiti ulaşıldığında durun.
- Hem başarılı hem de başarısız girişimleri yazın; olumsuz kanıt, sonraki soruşturmayı daraltır.
Cihazlar zaten ayrılmışken senkronize giriş kullanmayın. Bir izin iletişim kutusu, yavaş yükleme, klavye veya güncelleme istemcisi aynı tıklamayı farklı kontrollerde gönderebilir. Paylaşılan eylemler yalnızca her seçilen telefonun görünürde aynı güvenli durumda olduğu sürece yararlıdır. Aksi takdirde, cihazları ayrı ayrı çalıştırın ve anlamaya çalıştığınız farkı koruyun.
Bir kanıt paketi oluşturun, mühendislik yeniden oynayabilir
Kullanışlı bir devir, hızlı bir şekilde gözden geçirilebilmek için yeterince küçüktür ve tekrar oynatılabilmesi için yeterince tamamlanmıştır. Bir bilet, ortam, adımlar, gözlemlenen sonuç, beklenen sonuç ve destekleyici kanıtları bağlamalıdır. Ekran görüntüleri statik bir durumu kanıtlar; kısa bir ekran kaydı zamanlamayı ve sırayı kanıtlar; günlükler arayüzün gösteremeyebileceği şeyi açıklar. Bunların hiçbiri diğerlerini değiştirmez.
| Eser | dahil etmek | kaçınmak |
|---|---|---|
| Vaka özeti | Başarısızlığı ve iş etkisini anlatan bir cümle | Bir sonuca sahip olmayan yapıştırılmış bir sohbet transkripti |
| çevre | Telefon kodu, model, Android sürümü, uygulama oluşturumu, dil ve ağ | Müşterinin telefonu hakkında doğrulanmamış tahminler |
| adım atmak | Belirtilmiş bir başlangıç durumundan numaralandırılmış eylemler | 'uygulamayı normal olarak kullan' gibi adımlar |
| Görsel kanıt | Tek odaklanmış ekran görüntüsü veya kısa kayıt | Bağlantısız ekranları içeren uzun kayıtlar |
| Günlükler | İlgili zaman aralığı ve tanımlayıcılar | Gizli bilgiler veya ilgisiz müşteri verilerini içeren tam günlükler |
| karşılaştırma | Etkilenen telefonda ve temel telefonda sonuç | Sadece bir telefon test ettikten sonra cihaz spesifikitesini iddia etmek |
| Üreme oranı | Denemeler ve gözlemlenen başarısızlıklar | ' Rastgele gerçekleşir' gibi desteklenmeyen bir beyan |
Dosyaları bilet kimliği, telefon kodu, sürüm ve zaman damgasıyla adlandırın. Devretme, bir mühendisin çoklu sohbet iş akışını açmadan birkaç dakika içinde başarısızlığı anlamasına olanak vermelidir. Daha geniş bir QA iş akışı için bkz.Mobil uygulama testleri için Android ekran yansıtma.
Yerel telefonları, emülatörleri veya bulut cihaz hizmeti seçin
Bu araçlar farklı kapsama sorunlarını çözer. Yerel bir telefon masası bir bulut cihaz çiftliği için bir yedek değildir ve bir bulut laboratuvarı destek ekibinin yanında tanıdık telefonların değerini ortadan kaldırmaz. Koşulun sadakatle yeniden üretilebilecek en ucuz ortamı seçin.
| çevre | En iyisi için | Ana sınırlama |
|---|---|---|
| Simülatör | Hızlı kurulum, erken kullanıcı arayüzü kontrolleri, tekrarlanabilir sanal yapılandırmalar | Her donanım, yazılım, sensör, termal veya taşıyıcı davranışını çoğaltılamaz |
| Yerel gerçek telefon masası | Sık sık etkileşimli vakalar, destek gösterileri, tekrarlayan modeller, USB/Bluetooth/kamera iş akışları | Ekibin sahip olduğu ve bakımını yaptığı cihazlara sınırlı |
| Bulut gerçek cihaz hizmeti | Nadir modeller, geniş yayın kapsamı, paralel otomatik çalıştırmalar, uzaktan ekipler | Seans maliyeti, müsaitlik durumu, veri işleme kuralları ve daha az fiziksel erişim |
| Müşteri destekli çoğaltma | Sadece müşterinin ortamında bulunan koşullar | Dikkatli talimatlar, onay ve sıkı veri en aza indirgeme gerektirir |
Pratik bir sırası, hızlı bir akıl sağlığı kontrolü için öncelikle emulator, muhtemelen gerçek cihaz kaynakları için yerel telefonlar ve model eksik olduğunda veya kılıfın daha geniş bir doğrulama gerektirdiğinde bulut cihazlarıdır.Bir PC veya Mac'te Android ekran yansıtımıDestek, dağıtılmış bir kuruluş filosunda politika yönetimi yerine yerel telefonlar üzerinde doğrudan görsel kontrol gerektirdiğinde en yararlıdır.
Yaratma sırasında müşteri verilerini koruyun
Gerçek cihaz sorun giderme işlemi dikkatli değilse kişisel bilgileri ortaya çıkarabilir. Standart olarak sentetik hesaplar ve test verileri kullanın. Üretim verileri gerçekten gerekliyse, doğru yetkilendirmeyi alın, erişimi kısıtlayın, yalnızca davanın ihtiyaç duyduğu şeyi kaydedin ve şirketin muhafaza politikasına uyun. AWS ayrıca cihaz hizmetinden kullanıcılara hesap kimlik bilgilerini, kişisel bilgileri veya diğer güvenlik hassasiyetli ayrıntıları girmemeleri konusunda uyarır, çünkü oturumlar günlükler ve video üretebilir.
- Bir müşterinin şifresini, ödeme bilgilerini, kimlik doğrulama jetonunu, özel fotoğraflarını veya kimlik belgelerini asla laboratuvar telefonuna kopyalamayın.
- Kanıt eklemeden önce ilgili olmayan isimleri, mesajları, e-posta adreslerini ve hesap numaralarını bulanıklaştırın veya kırpın.
- Test hesaplarını ortamlara göre ayrı tutun ve kimlik bilgilerini şirket politikasına göre döndürün.
- Saklama süresi sona erdiğinde ekran görüntülerini, kayıtları, günlükleri, indirilen dosyaları ve uygulama verilerini kaldırın.
- Politika bir denetim izni gerektirdiğinde hassas bir davaya kimin eriştiğini ve nedenini kaydedin.
İş akışını üç telefondan yönetin
Bir cep telefonu duvarı satın alarak başlamayın. Tekrar eden bir destek durumu sınıfı ve üç temsilci cihaz seçin: bilinen iyi bir temel, en yaygın müşteri telefonu ve zıt bir düşük uçlu veya üreticiye özel telefon. İş akışını iki hafta çalıştırın, ardından pilotun kapsayamadığı durumları başka bir cihaz veya bulut hizmeti çözebileceğine karar verin.
- Cihaz belirsizliği nedeniyle gecikmeye uğrayan on yakın bilet seçin.
- Gerekli giriş alanlarını ve tek bir kanıt paketi şablonunu tanımlayın.
- Temiz test hesaplarıyla üç telefonu etiketleyin ve hazırlayın.
- İlk anlamlı çoğaltmaya, açıklama döngülerine, tırmanma kabulüne ve çözülmemiş cihaz boşluklarına olan süreyi takip edin.
- Hangi telefon veya çevresel koşulun gerçekten sonucu değiştirdiğini inceleyin.
- Sadece kanıtlar tekrarlanan bir kapsama boşluğu gösterdiğinde genişletin.
Doğrulanması gereken sonuç basit: bir destek mühendisi bir vakayı alabilmeli, uygun bir telefon seçmeli, yolu yeniden oynatmalı ve birkaç ilgisiz sistemi aramadan kendi kendine yeterli bir devriye teslim edebilmelidir. Paylaşılan yerel bir çalışma alanı bu pilotu destekliyorsa,LaiCai Screen Mirroringseçilen Android telefonları bir Windows veya macOS bilgisayardan görünür ve kontrol edilebilir halde tutabilir.
Sık sorulan sorular
Bir destek ekibi kaç Android telefona ihtiyaç duyar?
Gerçek bilet ve kullanım verilerinden seçilen üç ila altı telefondan başlayın. Cihazları yalnızca tekrarlanan, önemli bir durumun mevcut matris veya ara sıra bir bulut oturumuyla karşılanamayacağı durumlarda ekleyin.
Her müşteri raporunu yeniden üretmeyi desteklemeli mi?
Hayır. Ciddiyeti, etkilenen kullanıcıları, iş etkisi, güvenlik riskini, tekrarlama olasılığını ve çoğalmanın bir sonraki eylemi değiştireceğini önceliklendirin. Bir cihaz laboratuvarı, her belirsiz şikayeti tekrar oynatma gereksinimi değil, bir karar verme aracıdır.
Senkronize kontrol, her telefonda birden fazla hata üretebilir mi?
Sadece cihazlar görünürde aynı durumda olduğunda ve eylem güvenli olduğunda. Zamanlama, iletişim kutuları, izinler, klavyeler veya düzenler farklılaştığında, telefonları ayrı ayrı çalıştırın. Farklılık kanıtdır, körü körüne tıklanacak bir şey değildir.
LaiCai bir mobil cihaz yönetimi platformunu değiştirir mi?
Hayır.LaiCai Screen Mirroringyerel bir görsel kontrol ve iş akışı aracıdır. Sıfır dokunuşlu kayıt, politika uygulanması, uygulama dağıtımı, envanter veya uzaktan silme gerektiren dağıtılmış kurumsal filolar uygun bir MDM veya EMM sistemi kullanmalıdır.