Bagaimana Anda menguji fitur Google Maps "Dapatkan Petunjuk Arah"?


13

(Saya membayangkan ini akan menjadi pertanyaan wawancara yang bagus , tetapi dalam kasus saya ini lebih pragmatis dari itu.)

Kami memiliki aplikasi besar & kompleks yang memodelkan proses reaksi kimia yang sangat panjang dan canggih antara puluhan komponen kimia. Kami berada pada tahap merancang Tes Penerimaan untuk aplikasi, tetapi kami agak gentar dengan jumlah jalur yang mungkin sulit untuk diuji. Terpikir oleh saya bahwa situasi kami sangat mirip dengan apa yang harus dihadapi oleh tim pengembang Google Maps ketika tiba saatnya untuk menguji algoritma perencanaan rute dalam fitur "Dapatkan Arahan" mereka. Jelas mereka tidak dapat menguji (memverifikasi dan memvalidasi) setiap rute yang memungkinkan. Jadi, bagaimana mereka mendapatkan kepercayaan bahwa aplikasi mereka akan bekerja dalam setiap situasi?

Dan karena saya tidak berharap untuk mengetahui bagaimana mereka melakukannya, izinkan saya bertanya kepada Anda: Bagaimana Anda mendesain test suite dengan cakupan kode yang memadai, untuk memuaskan diri Anda bahwa aplikasi yang diberikan kuat - ketika itu benar-benar mustahil untuk menyelidiki setiap jalur potensial melalui sistem?

Apa yang saya cari adalah prinsip-prinsip yang akan Anda gunakan untuk memecah masalah yang tak terselesaikan menjadi bagian-bagian yang lebih kecil, dapat ditelusuri, jumlah yang memberikan perkiraan yang memuaskan dari keseluruhan: "Saya tidak bisa menguji semuanya, tapi saya bisa menguji ini , ini dan ini - dan itu sudah cukup. " Saya tidak mencari pendekatan yang "terbukti benar", melainkan pendekatan yang bijaksana , mengingat keterbatasan waktu / anggaran dunia nyata.

(Saya menggunakan contoh peta Google sebagai sesuatu dari kertas untuk mengumpulkan jawaban yang sespesifik mungkin.)


Google Maps di masa lalu telah mencoba mengarahkan saya ke jalan satu-satunya di bus, jalan yang salah di jalan satu arah, dan untuk berbelok di persimpangan yang tidak ada (misalnya jalan layang dengan hanya offramp). Saya percaya mereka memiliki fitur "laporkan arah yang salah", tetapi itu mungkin bukan sesuatu yang akan berhasil dalam situasi Anda. Jawaban untuk sedikit tentang mereka menguji semuanya? Mereka tidak, dan mereka tidak benar-benar perlu.
John Lyon

Seperti biasa dengan pertanyaan semacam ini, saya sarankan Anda membaca buku dan artikel Nassim Nicholas Taleb. Inilah artikel teknis yang masuk ke matematika tetapi saya sangat merekomendasikan membaca buku-bukunya.
jfrankcarr

Saya tidak percaya Anda dapat merancang tes yang mencakup semua kasus untuk sesuatu yang cukup kompleks. Jika Anda tahu cara kerja bagian dalam, Anda dapat membuat tes untuk setiap jalur yang jelas tetapi akan selalu ada hal-hal yang tidak pernah dipikirkan oleh siapa pun. Anda hanya memikirkan sebanyak mungkin dan berharap yang Anda lewatkan tidak terlalu menjadi masalah.
Loren Pechtel

2
@ Jozzas: Semua yang Anda uraikan adalah kesalahan basis data, sebenarnya bukan masalah dengan algoritma arahan Google. Setara dengan itu pagi ini satnav saya mencoba mengarahkan saya ke jalan yang tidak terawat. Di sisi lain, ketika itu memberi saya saran penutupan jalur tentang jalan saya akan meninggalkan itu bug yang sebenarnya. (Penasihat jelas hanya melihat jalan yang Anda lewati, bukan rute yang dilewatinya.)
Loren Pechtel

1
Sebut saja "Beta". Selesai Ini cara Google.
Paystey

Jawaban:


10

Saya bekerja di bidang navigasi mobil lebih dari satu dekade yang lalu.

Langkah A) Gunakan paket referensi dan pilih set sampel besar, jalankan tes A / B. Tidak mencari ketepatan, mencari outlier - Rangkaian referensi menunjukkan Reroute 1234 sejauh 10,34 km, dan kami menghitung 123,5km.

Langkah B) - Saring perangkat lunak kami dan perangkat lunak referensi - Tambahkan lebih banyak sampel dan kurangi toleransi.

Langkah C) - Pengujian internal menggunakan pengetahuan lokal di seluruh rangkaian data global.

Langkah D) UAT ... "Tes Penerimaan Pengguna" Seperti dalam "Jual barang ini dan lihat apa yang paling dikeluhkan pelanggan"

Jika Anda pernah menggunakan produk pemetaan sekitar pertengahan 1990-an, Anda tahu apa yang saya maksud, kami yang masih memeriksa setiap belokan arah secara bergantian.

Kembali ke pertanyaan Anda contoh. Apa yang Anda tanyakan adalah bagaimana membuktikan bahwa suatu perangkat lunak benar. Jika Anda ingin bukti matematis, telah terbukti dapat dilakukan - untuk perangkat lunak sederhana dengan harga yang melebihi anggaran realistis, untuk paket perangkat lunak yang kompleks, yah, itu masih penelitian .... NASA memiliki model untuk menulis perangkat lunak yang sangat andal dalam harga yang dapat dikelola secara ekonomi, seperti halnya DoD dan industri penerbangan - meskipun masih jauh lebih tinggi daripada kebanyakan yang bersedia membayar. Pada akhirnya, tergantung pada seberapa banyak Anda siap untuk membayar .....

Sunting: Saya baru saja membaca ulang OP Anda. Tampaknya apa yang Anda cari adalah cara cepat dan murah untuk Menguji kualitas perangkat lunak yang kompleks. Anda tidak dapat menguji kualitas. Anda harus memiliki proses yang kuat sehingga Anda tahu bahwa apa yang dibangun berfungsi dengan benar. Jika Anda harus berpikir tentang cara membuktikannya benar dan Anda sudah memiliki "aplikasi besar dan kompleks", Anda sudah terlambat.


5

Kami salah satu pesaing Google. Jawaban kita? Pada dasarnya dua.

Pertama, kami menghitung solusi alamat-ke-alamat yang lengkap. Yup, itu matriks besar. Lebih buruk lagi, kami melakukannya sepanjang waktu, sepanjang hari dalam seminggu. Ada kesamaan yang cukup di domain input untuk cache hasil antara, yang membuat masalah bisa diselesaikan. Namun, cobalah untuk mendapatkan tingkat curah pada harddisk.

Perhatikan bahwa perhitungan offline ini dilakukan dengan menggunakan algoritma yang berbeda. Ini menggunakan jauh lebih banyak memori daripada algoritma yang ingin kami uji, tetapi tidak lebih linear (yaitu menggunakan kurang dari 1000 kali lebih banyak memori ketika menghitung seribu rute).

Kedua, pengguna yang berpartisipasi memberi kami hasil dunia nyata. Kami memvalidasi jutaan rute yang digerakkan. Apakah rute aktual secepat yang diperkirakan?

Dan tentu saja, Anda memang menemukan bug seperti itu. Setiap saat. Misalnya bentangan jalan yang dibatasi di kedua sisi oleh "zona hanya lalu lintas lokal" *. Hanya ada satu cara;) yang akan Anda temukan dalam pengujian, dan saat itulah Anda merencanakan rute ke jalan tertentu.

* "Zona khusus lalu lintas lokal" hanya dapat digunakan saat Anda memulai atau mengakhiri rute di zona tersebut. Karenanya, bentangan di tengah terputus dari jaringan jalan utama. Ini bisa berupa zonasi atau peta kesalahan.


3

Ini tidak seperti google menulis kode terpisah untuk setiap pasangan alamat di dunia. Dengan pengecualian heuristik yang menghasilkan skala yang lebih besar, algoritme untuk perjalanan 3 kaki persis sama dengan untuk 3000 kaki. Anda benar-benar menguji jalur yang lebih pendek dan menggunakan induksi untuk menunjukkan pengujian berlaku untuk jalur yang lebih panjang juga.

Anda memilih sampel yang sehat dari rute dunia nyata, dan memeriksanya terhadap apa yang muncul dari manusia. Anda membayar banyak perhatian untuk memberikan umpan balik kepada pengguna di rilis pertama Anda, dan membuatnya mudah bagi mereka untuk memberikannya. Anda menguji kondisi batas, seperti apakah rute terbaik sebenarnya mengharuskan bepergian jauh dari tujuan untuk sementara waktu, atau jika rute terpendek berdasarkan jarak memiliki 18 belokan dibandingkan dengan rute yang lebih langsung yang sedikit lebih lama. Anda melakukan pengujian negatif, seperti jika Anda mencoba mengemudi dari California ke Hawaii, dan memastikan telur paskah yang pintar ada di tempatnya.


Saya yakin semua yang Anda sarankan akurat, tetapi saya merasa bahwa itu masih belum cukup ketat. "Memilih sampel rute yang sehat" terdengar lebih seperti apa yang mungkin saya lakukan untuk proyek jangka perguruan tinggi, daripada apa yang akan dirancang oleh tim pengembangan kelas dunia. Dan sementara saya setuju dengan pengamatan Anda tentang rute 3-kaki vs 3000-kaki, menguji bahkan sebagian besar dari rute 3-kaki masih tampak cukup ambisius. Saya merasa bahwa kita masih kehilangan sesuatu yang mendasar di sini.
kmote

@kmote: "tapi saya tidak bisa menahan diri untuk merasa bahwa itu masih belum cukup ketat" Mengapa tidak, ini bekerja untuk industri perangkat lunak selama satu generasi, dan tidak ada tanda nyata bahwa itu akan digantikan dalam waktu dekat. Kita dibayar untuk menulis kode yang menghasilkan uang, bukan menulis kode yang sempurna. Kalau dipikir-pikir itu apa yang digunakan dalam Kedokteran, Teknik dan hampir semua profesi dan tampaknya melakukan industri-industri dengan cukup baik.
mattnz
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.