Làm thế nào bạn có thể kiểm tra tính năng Google Maps Nhận Nhận Hướng dẫn?

(Tôi tưởng tượng đây sẽ là một câu hỏi phỏng vấn hay , nhưng trong trường hợp của tôi, nó thực dụng hơn thế.)

Chúng tôi có một ứng dụng lớn và phức tạp , mô hình hóa một quá trình phản ứng hóa học cực kỳ dài và phức tạp giữa hàng chục thành phần hóa học. Chúng tôi đang ở giai đoạn thiết kế Kiểm tra chấp nhận cho ứng dụng, nhưng chúng tôi hơi bị nản chí bởi số lượng đường dẫn có thể kiểm tra được. Tôi nhận thấy rằng tình huống của chúng tôi rất giống với những gì nhóm phát triển Google Maps phải đối mặt khi đến lúc kiểm tra thuật toán lập kế hoạch tuyến đường trong tính năng "Nhận chỉ đường" của họ. Rõ ràng là họ không thể kiểm tra (xác minh và xác nhận) mọi tuyến đường có thể. Vậy làm thế nào mà họ có được sự tự tin rằng ứng dụng của họ sẽ hoạt động trong mọi tình huống?

Và vì tôi không mong đợi tìm hiểu họ đã làm như thế nào , hãy để tôi hỏi bạn: Làm thế nào bạn sẽ thiết kế một bộ thử nghiệm với độ bao phủ mã đầy đủ, để thỏa mãn bản thân rằng một ứng dụng nhất định là mạnh mẽ - khi nó thực sự là không thể để thăm dò mọi con đường tiềm năng thông qua hệ thống?

Những gì tôi đang tìm kiếm là những nguyên tắc mà bạn sẽ sử dụng để phá vỡ một vấn đề khó giải quyết thành những phần nhỏ hơn, dễ điều khiển, tổng hợp đưa ra ước tính thỏa đáng cho toàn bộ: "Tôi không thể kiểm tra mọi thứ, nhưng tôi có thể kiểm tra điều này , cái này và cái này - và thế là đủ. " Tôi không tìm kiếm một cách tiếp cận "có thể chứng minh chính xác", mà là một cách tiếp cận thận trọng , với những hạn chế về ngân sách / thời gian trong thế giới thực.

(Tôi đang sử dụng ví dụ về bản đồ của Google như một thứ gì đó để thu hút các câu trả lời cụ thể nhất có thể.)

Tôi đã làm việc trong lĩnh vực điều hướng xe hơi hơn một thập kỷ trước.

Bước A) Sử dụng gói tham chiếu và chọn một bộ mẫu lớn, chạy thử nghiệm A / B. Không tìm kiếm sự chính xác, tìm kiếm các ngoại lệ - Bộ tham chiếu cho thấy Reroute 1234 là 10,3km, và chúng tôi đã tính được 123,5km.

Bước B) - Tinh chỉnh phần mềm của chúng tôi và phần mềm tham chiếu - Thêm nhiều mẫu hơn và giảm dung sai.

Bước C) - Trong thử nghiệm tại nhà bằng kiến ​​thức địa phương trên các tập dữ liệu toàn cầu.

Bước D) UAT ... "Kiểm tra chấp nhận người dùng" Như trong "Bán công cụ này và xem khách hàng phàn nàn gì nhất"

Nếu bạn đã từng sử dụng các sản phẩm lập bản đồ vào khoảng giữa những năm 1990 - 2000, bạn sẽ hiểu ý của tôi, những người trong chúng ta vẫn kiểm tra hướng rẽ theo từng hướng.

Quay lại với bạn câu hỏi ví dụ. Những gì bạn đang được hỏi là làm thế nào để chứng minh rằng một phần mềm là chính xác. Nếu bạn muốn chứng minh toán học, điều đó đã được chứng minh là có thể thực hiện được - đối với phần mềm đơn giản với mức giá vượt quá mọi ngân sách thực tế, đối với gói phần mềm phức tạp, đó vẫn là nghiên cứu .... NASA có các mô hình để viết phần mềm có độ tin cậy cao trong phạm vi giá cả có thể quản lý kinh tế, cũng như DoD và ngành hàng không - mặc dù vẫn cao hơn nhiều so với hầu hết sẵn sàng trả. Cuối cùng, số tiền bạn chuẩn bị trả là bao nhiêu .....

Chỉnh sửa: Tôi vừa đọc lại bạn OP. Có vẻ như những gì bạn đang tìm kiếm là một cách nhanh chóng và rẻ tiền để Kiểm tra chất lượng của một phần mềm phức tạp. Bạn không thể kiểm tra chất lượng. Bạn cần có một quy trình mạnh mẽ để bạn biết rằng những gì được xây dựng hoạt động chính xác. Nếu bạn phải suy nghĩ về cách chứng minh nó đúng và bạn đã có một "ứng dụng lớn và phức tạp", thì bạn đã quá muộn.

Chúng tôi là một trong những đối thủ cạnh tranh của Google. Câu trả lời của chúng tôi? Về cơ bản là hai.

Đầu tiên, chúng tôi tính toán giải pháp địa chỉ đầy đủ địa chỉ. Yup, đó là một ma trận lớn. Tệ hơn nữa, chúng tôi làm như vậy cho tất cả các thời điểm trong ngày, tất cả các ngày trong tuần. Có đủ sự tương đồng trong miền đầu vào để lưu trữ kết quả trung gian, điều này làm cho vấn đề trở nên dễ xử lý. Tuy nhiên, hãy cố gắng để có được một tỷ lệ lớn trên đĩa cứng.

Lưu ý rằng tính toán ngoại tuyến này được thực hiện bằng một thuật toán khác. Nó sử dụng bộ nhớ nhiều hơn nhiều so với thuật toán mà chúng tôi dự định thử nghiệm, nhưng không phải tuyến tính nhiều hơn (tức là nó sử dụng bộ nhớ ít hơn 1000 lần khi tính toán một nghìn tuyến đường).

Thứ hai, người dùng tham gia cung cấp cho chúng tôi kết quả thực tế. Chúng tôi xác nhận hàng triệu tuyến đường điều khiển. Các tuyến đường thực tế có nhanh như dự đoán không?

Và chắc chắn, bạn tìm thấy lỗi theo cách đó. Tất cả các lần. Ví dụ: đoạn đường bị giới hạn ở cả hai phía bởi "vùng chỉ dành cho giao thông địa phương" *. Chỉ có một cách duy nhất;) mà bạn sẽ tìm thấy trong thử nghiệm và đó là khi bạn lập kế hoạch tuyến đường đến con đường cụ thể đó.

_{* Chỉ có thể sử dụng "vùng chỉ lưu lượng truy cập cục bộ" khi bạn bắt đầu hoặc kết thúc tuyến đường trong khu vực đó. Đoạn đường ở giữa do đó bị ngắt kết nối với mạng lưới đường chính. Đây là lỗi phân vùng hoặc lỗi bản đồ.}

Nó không giống như google viết mã riêng cho mỗi cặp địa chỉ trên thế giới. Ngoại trừ các heuristic đá ở quy mô lớn hơn, thuật toán cho hành trình 3 chân hoàn toàn giống với 3000 chân. Bạn kiểm tra kỹ lưỡng các đường dẫn ngắn hơn và sử dụng cảm ứng để hiển thị thử nghiệm cũng áp dụng cho các đường dẫn dài hơn.

Bạn chọn một mẫu lành mạnh của các tuyến đường trong thế giới thực và kiểm tra xem nó có phù hợp với những gì con người nghĩ ra không. Bạn phải trả rất nhiều sự chú ý đến kết thúc phản hồi người dùng trong phiên bản đầu tiên của bạn, và làm cho nó dễ dàng cho họ để cung cấp nó. Bạn kiểm tra các điều kiện biên, như nếu tuyến đường tốt nhất thực sự yêu cầu di chuyển khỏi điểm đến trong một thời gian hoặc nếu tuyến đường ngắn nhất theo khoảng cách có 18 lượt so với tuyến đường trực tiếp dài hơn một chút. Bạn làm xét nghiệm âm tính, giống như nếu bạn đang cố lái xe từ California đến Hawaii và đảm bảo trứng Phục sinh thông minh được đặt đúng chỗ.