PyUseCase

PyUseCase là một phần mềm thử nghiệm giao diện cho PyGTK.
duy trì thử nghiệm giao diện với một trường hợp sử dụng ghi
Việc ghi lại các ý hơn là các cơ
Cách tự nhiên nhất để tạo ra các bài kiểm tra thông qua một giao diện người dùng đơn giản chỉ là để thực hiện các hành động mà bạn muốn thực hiện và có một công cụ có thể ghi lại chúng và sau đó sao chép chúng sau này. Đây là một cách đơn giản và nhanh chóng để tạo ra các bài kiểm tra GUI và có khá nhiều công cụ mà làm điều này.
Hầu hết các công cụ vài bài kiểm tra chặt chẽ để các GUI
Các vấn đề bắt đầu khi bạn có một vài kiểm tra và thay đổi giao diện của bạn. Ghi âm có thể là một cách tuyệt vời để tạo ra các bài kiểm tra, nhưng đó là một cách khủng khiếp để duy trì số lượng lớn trong số họ. Nó là dễ bị lỗi, bực bội và rất tốn thời gian khi bạn có một vài bài kiểm tra. Thế hệ đầu tiên của các công cụ ghi lại vị trí điểm ảnh và phá vỡ ngay sau khi bạn thay đổi độ phân giải màn hình của bạn. Hôm nay của các công cụ thỏa thuận về cơ chế GUI: tìm thấy một bảng với một tên nào đó và nhấp vào cột thứ ba của hàng thứ tư. Họ có thể sống sót và thay đổi màn hình nhỏ tái sắp xếp của GUI nhưng không nhiều người khác. Các kịch bản ghi là dày đặc và không truyền đạt mục đích của thử nghiệm, và là một cuốn sách đóng cho tất cả mọi người phi kỹ thuật (và đôi khi để tất cả mọi người ngoại trừ các tác giả của công cụ).
Vấn đề cơ bản là một trong những khớp nối. Các xét nghiệm và các GUI được kết chặt chẽ với nhau và có thể không thoải mái khác nhau độc lập với nhau. Điểm này được thực hiện tốt bởi Robert C. Martin trong blog của mình ở đây và kết luận của ông là giao diện thử nghiệm là vốn giòn và bạn nên làm càng ít về nó như là bạn có thể nhận được ngay với.
Điều này có vẻ khá bại mặc dù. Có giá trị rất lớn trong việc có thể để chứng minh những gì các bài kiểm tra của bạn làm cho một người sử dụng của hệ thống. Nếu bài kiểm tra bỏ qua các giao diện người sử dụng thì quá trình đó đòi hỏi một số tiền hợp lý của kỹ năng kỹ thuật và rất nhiều niềm tin từ phía người dùng của bạn. Và dù sao, các nhà phát triển phần mềm giải quyết các vấn đề khớp nối tất cả các thời gian. Câu trả lời là, như thường lệ, để giới thiệu một mức gián tiếp.
Breaking các khớp nối với một bản đồ UI
Người kinh doanh và người dùng thường làm việc trong trường hợp sử dụng. Đây là những mô tả cấp cao của một chuỗi các hành động trong một ngôn ngữ mà họ hiểu: tức là các tên miền. Do đó, ý tưởng về một "trường hợp sử dụng ghi" là một công cụ mà có thể ghi âm và phát lại trình tự như vậy và từ đó nắm bắt được ý định của người sử dụng. Điều này sau đó sẽ cho phép hiểu biết tăng lên, ít phụ thuộc vào hình thức chính xác của các giao diện và dễ dàng điều chỉnh các xét nghiệm hiện có mà không cần phải dùng đến cách nhấn tất cả các nút một lần nữa.
Cơ chế cơ bản là chúng ta duy trì một ánh xạ giữa các hành động mà hiện nay có thể được thực hiện với giao diện và báo cáo của chúng tôi bằng ngôn ngữ của miền này. Thay đổi giao diện thì có nghĩa là bản đồ duy nhất này cần được cập nhật, nhưng các xét nghiệm có thể vẫn được giữ nguyên, tiếp tục mô tả những gì cần phải được thực hiện trên cấp độ khái niệm. Lập bản đồ này có dạng của một tập tin bên ngoài trong PyUseCase 3.0 và sắp tới là JUseCase 3.0, trong khi ở phiên bản cũ nó có dạng của thiết bị đo đạc trong mã ứng dụng.
Kiểm tra các hành vi thông qua các bản ghi và TextTest
Vì vậy, ghi trường hợp sử dụng của chúng tôi có thể ghi âm và phát lại usecases cho chúng tôi. Nhưng làm thế nào chúng ta có thể kiểm tra xem những gì chúng ta thấy trên màn hình là chính xác? Hầu hết các công cụ GUI làm điều này bằng cách cho phép các kịch bản thử nghiệm có chứa "khẳng định", mà tìm một số widget và kiểm tra xem một số tài sản của nó là bằng một giá trị hardcoded. Điều này tạo ra sự phụ thuộc chưa nhiều trên GUI bố trí hiện tại và không thể được "ghi nhận" trong bất kỳ cách tự nhiên, nhưng đã được lập trình trong khi thực tế. Không "usecase" sẽ tự nhiên có chứa thông tin này: nếu nó đã làm nó sẽ biến thành một kịch bản thử nghiệm.
Thảo luận này không phải là trên trang web TextTest cho không có gì. Nếu chúng ta chỉ có thể nhận được các ứng dụng của chúng tôi để sản xuất một bản ghi của những gì các giao diện trông giống như chúng ta có thể kiểm tra những gì nó làm bằng cách giám sát các nội dung của nhật ký sử dụng TextTest. PyUseCase 3.0 hiện điều này cho bạn: nó tạo ra một loại ASCII-art log của GUI xuất hiện hiện hành và theo dõi thay đổi nó. Ứng dụng có thể bổ sung cho nó với khai thác gỗ của chính nó như là nó muốn. Với trường hợp sử dụng máy ghi âm khác các ứng dụng cần để xây dựng nhật ký riêng của mình cho mục đích này hiện nay.
Đồng bộ hóa các bài kiểm tra bằng mã số nhạc cụ
Hầu như tất cả những nỗ lực của giao diện thử nghiệm đang cản bởi vấn đề với việc bảo đảm các kịch bản chờ đợi đủ lâu trước khi tiến hành khi một cái gì đó xảy ra trong nền. Các giải pháp bao gồm từ những cách phức tạp để chờ đợi cho một số widget để có một diện mạo nào đó (chưa phụ thuộc nhiều hơn vào GUI-cơ) để "ngủ" báo cáo tự do nằm rải rác xung quanh. Những thất bại khi hệ thống được nạp và gây ra các xét nghiệm để chạy chậm hơn nhiều hơn bình thường. Bất cứ ai mà không có kiến ​​thức thân mật của mã này là thiếu trang bị để giải quyết vấn đề như vậy, nhưng làm như vậy là một phần quan trọng của văn bản thử nghiệm.
Trường hợp sử dụng Recorders giới thiệu các khái niệm về một "ứng dụng tổ chức sự kiện". Đây là cơ bản một số thiết bị đo đạc trong các mã mà chỉ cho các trường hợp sử dụng máy ghi âm một điều gì đó đã xảy ra mà cần phải được chờ đợi, do đó cho phép các máy ghi âm để ghi và phát lại chờ đợi cũng như nhấp chuột. Đây là những mô tả chi tiết ở đây.
macro ghi âm cũng như kiểm tra
Cao cấp, dễ dàng thao tác "usecases" rất hữu ích cho những thứ khác hơn là thử nghiệm. Họ cũng là cực kỳ hữu ích cho người sử dụng của hệ thống những người có thể tạo macro của riêng mình cho trình tự của các hành động mà họ thường xuyên thực hiện.
Chúng được gọi là "giao diện phím tắt" ở đây. Một máy ghi tình huống sử dụng thông thường sẽ cho phép một ứng dụng để yêu cầu một "thanh công cụ" từ nó, trong đó có các điều khiển để ghi âm và phát lại chúng có thể được đưa vào ứng dụng GUI như mong muốn. Bên cạnh đó cho phép người dùng tạo các macro, họ cũng có thể được sử dụng để tạo ra các khái niệm trừu tượng mức độ cao hơn cho "ngôn ngữ thử nghiệm" mô tả ở trên, giúp kiểm tra trong việc thực hiện các hành động lặp đi lặp lại để đạt được một màn hình nhất định để thử nghiệm. Đây là những mô tả chi tiết ở đây.
Thông tin chi tiết có thể được tìm thấy trên trang chủ của dự án

là gì mới trong phiên bản này:.

• hỗ trợ rất cơ bản cho wxPython là thêm vào.
• Ngoài ra còn có một số cải tiến và sửa lỗi cho PyGTK. Đáng chú ý, gtk.Dialog.run hiện đang được hỗ trợ mà không cần thay đổi mã nguồn.
• Python 2.6 và PyGTK 2.12 hoặc mới hơn đang yêu cầu.
• Giao diện thiết bị đo đạc dựa trên di sản đã được gỡ bỏ.

Yêu cầu :

• Python
• PyGTK
• TextTest