2009-10-18 25 views
12

Tôi có một Ứng dụng Java sử dụng JOGL để cung cấp một phần lớn GUI.Thử nghiệm tự động cho ứng dụng OpenGL

Có bất kỳ công cụ mà bạn biết, hoặc đã sử dụng có thể tự động kiểm tra các ứng dụng OpenGL (hoặc specificly hơn những người sử dụng JOGL)

Chỉ cần cập nhật: Các công cụ có thể chạy trên Linux hay Windows.

+0

tha thứ cho câu hỏi noob, nhưng điều gì khiến thử nghiệm ứng dụng OpenGL khác với bất kỳ thử nghiệm ứng dụng nào khác? – Bahbar

+1

Điều tôi thực sự muốn nói là tự kiểm tra chế độ xem OpenGL. Nhấp, kéo, xoay thu phóng vv .... Có các công cụ cho phép bạn ghi lại tương tác GUI của mình bằng cách nói ứng dụng Swing và phát lại chúng. Bạn có thể làm điều này cho tất cả các tương tác cốt lõi của bạn và phát lại nó như là thử nghiệm hồi quy. Tôi muốn một giải pháp tương tự cho OpenGL nhưng tôi không biết một giải pháp nào tồn tại. – hhafez

Trả lời

10

Tôi đã viết đơn vị kiểm tra cho C++ (Qt trên Linux) & OpenGL trước đây. Tôi không biết vì sao nó cũng không làm việc cho Java.

Những điều mà làm việc cho tôi là:

  • Tóm tắt cung cấp bối cảnh OpenGL của bạn để phần còn lại của mã của bạn không phụ thuộc vào nó. Trong trường hợp của tôi, ứng dụng chính sử dụng QGLWidget của Qt, nhưng các unittests đã sử dụng một bộ đệm dựa trên nền tảng mà tôi có thể tạo ra mà không có cơ sở hạ tầng cửa sổ nào (trừ một X11 DISPLAY được chỉ định). Sau đó tôi thêm một "tắt màn hình Mesa" (thực hiện phần mềm OpenGL thuần túy) để họ thậm chí còn làm việc trên một máy xây dựng không có đầu không có GPU.

  • Giữ mã OpenGL của bạn độc lập với mã GUI của bạn. Trong trường hợp của tôi, công cụ rendering "OpenGL" không biết gì về các lớp Qt (ví dụ: các sự kiện chuột). Xác định API có thể kiểm tra của riêng bạn mà không gắn với bất kỳ khái niệm GUI cụ thể nào và viết các kiểm tra cho nó.

  • Trong phần hủy, đọc nội dung từ bộ đệm khung bằng cách sử dụng glReadPixels và nhấn chúng với một số xác nhận về pixel nào là giá trị cụ thể hoặc đi xuống tuyến thử nghiệm hồi quy và so sánh chụp khung hình với hình ảnh được lưu trữ bạn biết là tốt (hoặc từ xác minh thủ công, hoặc bởi vì nó được sản xuất từ ​​một số mô hình tham chiếu khác).

  • Cho phép một chút mờ trong bất kỳ thử nghiệm hồi quy hình ảnh nào; hầu hết các triển khai OpenGL tạo ra sản lượng hơi khác nhau.

  • (Tôi không làm điều này, nhưng ...) Lý tưởng nhất là bạn muốn có thể kiểm tra lớp GUI bằng cách xác nhận rằng nó làm cho chuỗi cuộc gọi dự kiến ​​đến công cụ hiển thị của bạn phản ứng với hoạt động GUI. Nếu điều đó xảy ra, và bạn tự tin về lớp kết xuất của bạn vì các bài kiểm tra ở trên ... tốt, không cần phải thực hiện kết xuất. Vì vậy, tạo một đối tượng giả thích hợp của lớp kết xuất của bạn để sử dụng khi kiểm tra GUI (tôi sẽ tưởng tượng các thử nghiệm như "kéo chuột từ đây để kết quả trong một cuộc gọi đến lớp kết xuất để đặt ma trận biến đổi cụ thể" ...).

+1

+1 cho tất cả lời khuyên tốt. Để so sánh framebuffer, chúng tôi đã viết một ứng dụng nhỏ có sự khác biệt mờ về hình ảnh nhìn vào các vùng đồng bằng cảm nhận, thay vì các giá trị pixel tuyệt đối. –

+0

Vấn đề là GUI là một khung được xây dựng tùy chỉnh được xây dựng bằng cách sử dụng JOGL. Đó là lý do tại sao số 2 không thể hoạt động. Ví dụ: chúng tôi sử dụng để tạo các yếu tố đồ họa trên màn hình mà người dùng có thể tương tác với tất cả bằng cách sử dụng JOGL. Tôi cần một cách để tự động hóa tương tác người dùng .... – hhafez

+2

Sử dụng bất kỳ thư viện cụ thể nào để triển khai GUI không thành vấn đề. Tạo một lớp GraphicsContext tóm tắt khung/khung OpenGL và một lớp GUI trừu tượng hóa bất kỳ tính năng GUI nào bạn cần. Sau đó, việc triển khai lớp GUI có thể hiển thị cho triển khai ngữ cảnh hiển thị, nhưng ứng dụng của bạn sẽ không cần phải quan tâm cách chúng hoạt động cùng nhau. –

2

Tôi đã nghĩ đến việc sử dụng công cụ khác biệt hình ảnh như PDiff để kiểm tra mã OpenGL, bằng cách chụp nhanh, lưu chúng vào đĩa và so sánh với đầu ra hồi quy trước đó. Bằng cách đó, công cụ thực sự xấu (thiếu kết cấu) bật lên nhưng những điều không đáng kể của con người (chẳng hạn như sự khác biệt nhỏ được đề cập ở trên giữa việc thực hiện) đi qua tốt.

Ngoài ra, để tự động tương tác người dùng, các lớp GUI phải đủ mở để bạn gửi sự kiện hoặc gọi 'nhấp' trên một nút, hoặc bạn phải chèn các sự kiện OS theo cách thủ công vào ứng dụng của mình. Điều này là có thể, nhưng rắc rối hơn nhiều. Có thể dễ dàng hơn để mở lớp GUI, nếu đó là Mã nguồn mở.

+0

SSIM ("Chỉ số tương đồng về cấu trúc") - http://en.wikipedia.org/wiki/Structural_similarity - là một trình so sánh hình ảnh khác dựa trên những cân nhắc về nhận thức. – timday

3

Bạn có thể thử nghiệm ứng dụng dựa trên JOGL của mình bằng cách sử dụng Sikuli thực hiện tự động hóa giao diện người dùng thông qua nhận dạng hình ảnh techonolgy trên ảnh chụp màn hình.

Tôi hiện đang sử dụng Sikuli để thử nghiệm chức năng ứng dụng Java chủ yếu dựa trên số NASA Worldwind Java SDK (dựa trên JOGL). Sử dụng Sikuli Java API bộ thử nghiệm của tôi có thể nhận ra các biểu tượng trong canvas OpenGL, nhấp vào chúng và kéo chúng xung quanh. Sikuli cũng có thể nhận ra và trích xuất văn bản từ canvas thông qua OCR, tuy nhiên hiệu suất của điều này có vẻ là một hit-and-miss (tùy thuộc vào ngôn ngữ, phông chữ, kích thước và màu nền phía sau văn bản).

Tôi đã thực hiện rất nhiều thử nghiệm giao diện người dùng tự động bằng cách sử dụng các công cụ khác hoạt động bằng cách xem xét bộ công cụ cửa sổ (ví dụ: Swing, SWT, Windows nguyên bản) và thấy rằng Sikuli chạy chậm hơn nhiều so với những công cụ đó. xử lý hình ảnh mà nó cần phải làm sau hậu trường. Cũng lưu ý rằng Sikuli hiện yêu cầu ứng dụng của bạn chạy trong một cửa sổ (không phải ở chế độ toàn màn hình).

Sikuli chạy trên cả Windows và Linux. Tôi khuyên bạn nên thử nó. Tôi không thể tìm thấy bất kỳ công cụ nào khác có khả năng thực hiện mức độ kiểm tra chức năng của một ứng dụng dựa trên OpenGL.