2009-07-16 43 views
7

Tôi đã từng làm việc trên một hệ thống tương đối lớn, và đây là lần đầu tiên tôi làm việc trên một hệ thống lớn (đồng thời xử lý hơn 200 kênh thông tin). Tôi biết cách sử dụng Junit để kiểm tra mọi phương pháp và cách kiểm tra các điều kiện biên. Nhưng vẫn còn, để kiểm tra hệ thống, tôi cần phải kiểm tra tất cả các giao tiếp và có lẽ vì vậy một số thử nghiệm căng thẳng là tốt (có thể có những thứ khác để làm, nhưng tôi không biết những gì họ đang có). Tôi hoàn toàn mới với thế giới thử nghiệm, và xin vui lòng cho tôi một số gợi ý hoặc chỉ cho tôi một số thông tin về cách một trình kiểm tra mã tốt sẽ làm thử nghiệm hệ thống.Làm cách nào để kiểm tra mã Java tốt nhất?

PS: 2 câu hỏi cụ thể mà tôi có là: cách thử nghiệm các chức năng riêng tư? cách kiểm tra giao diện và tránh tác dụng phụ?

Trả lời

6

Dưới đây là hai trang web có thể giúp:

Đầu tiên là một danh sách các open source Java tools. Nhiều công cụ là phần bổ trợ cho JUnit cho phép kiểm tra hoặc thử nghiệm dễ dàng hơn ở mức tích hợp cao hơn.

Tùy thuộc vào hệ thống của bạn, đôi khi JUnit sẽ làm việc cho các kiểm tra hệ thống, nhưng cấu trúc của thử nghiệm có thể khác nhau.

Đối với phương thức riêng tư, hãy kiểm tra this question (và câu hỏi mà nó tham chiếu).

Bạn không thể kiểm tra giao diện (vì không có hành vi), nhưng bạn có thể tạo một lớp thử nghiệm cơ sở trừu tượng để kiểm tra việc triển khai giao diện theo hợp đồng của giao diện.

EDIT: Ngoài ra, nếu bạn chưa có kiểm tra đơn vị, hãy xem Working Effectivly with Legacy Code; nó là phải cho mã thử nghiệm mà không được thiết lập tốt để thử nghiệm.

+0

+1 cho tham chiếu cuốn sách Feathers. –

+0

Tôi đã đặt mua cuốn sách ngay bây giờ. Cảm ơn. – Lily

3

Mocking là một cách hay để có thể mô phỏng các kiểm tra hệ thống trong thử nghiệm đơn vị; bằng cách thay thế (mocking) các tài nguyên mà thành phần khác phụ thuộc, bạn có thể thực hiện kiểm tra đơn vị trong môi trường "giống như hệ thống" mà không cần phải có toàn bộ hệ thống được xây dựng để thực hiện nó.

Đối với câu hỏi cụ thể của bạn: thông thường, bạn không nên sử dụng kiểm tra đơn vị để kiểm tra các chức năng riêng tư; nếu riêng tư, họ là riêng tư cho lớp học. Nếu bạn cần kiểm tra điều gì đó, hãy thử nghiệm phương thức công khai sử dụng phương thức riêng tư đó để thực hiện điều gì đó. Tránh các tác dụng phụ có thể có khả năng có vấn đề được thực hiện tốt nhất bằng cách sử dụng môi trường kiểm tra hoàn chỉnh (có thể dễ dàng bị xóa trở lại trạng thái "trinh") hoặc sử dụng chế nhạo, như được mô tả ở trên. Và các giao diện thử nghiệm được thực hiện bằng cách, kiểm tra các phương thức giao diện.

2

Chức năng riêng sẽ được kiểm tra khi các chức năng công khai gọi chúng. Thử nghiệm của bạn về chức năng công cộng chỉ quan tâm đến kết quả trả về là chính xác.

Khi giao dịch với API (với các gói hoặc URL khác hoặc thậm chí là tệp/mạng/cơ sở dữ liệu), bạn nên giả lập chúng. Một bài kiểm tra đơn vị tốt sẽ chạy trong một vài phần nghìn giây không phải trong vài giây. Mocking là cách duy nhất để làm điều đó. Nó có nghĩa là các lỗi giữa các gói có thể được xử lý dễ dàng hơn rất nhiều so với các lỗi logic ở cấp chức năng. Đối với Java easymock là một khung mocking rất tốt.

3

Thứ nhất, nếu bạn đã có một hệ thống lớn không có bất kỳ bài kiểm tra đơn vị nào và bạn dự định thêm một số thì hãy cho phép tôi đưa ra một số lời khuyên chung.

Từ việc duy trì hệ thống và làm việc với nó, bạn có thể đã biết các khu vực của hệ thống có xu hướng buggiest, có xu hướng thay đổi thường xuyên và có xu hướng không thay đổi rất nhiều. Nếu không, bạn luôn có thể xem qua các nhật ký kiểm soát nguồn (bạn đang sử dụng điều khiển nguồn, phải không?) Để tìm ra nơi mà hầu hết các sửa lỗi và thay đổi được tập trung. Tập trung nỗ lực thử nghiệm của bạn vào các lớp và phương pháp này. Có một quy tắc chung được gọi là quy tắc 80/20 được áp dụng cho toàn bộ phạm vi, đây là một trong số đó.

Nó nói rằng, trung bình, bạn sẽ có thể bao gồm 80 phần trăm các trường hợp vi phạm bằng cách chỉ làm 20% công việc. Tức là, bằng cách viết các bài kiểm tra chỉ với 20% mã, bạn có thể bắt được 80% các lỗi và hồi quy. Đó là bởi vì hầu hết các mã mong manh, mã thường được thay đổi và mã vi phạm tồi tệ nhất chỉ chiếm 20% của codebase. Trong thực tế, nó có thể thậm chí còn ít hơn.

Bạn nên sử dụng junit để thực hiện việc này và bạn nên sử dụng một cái gì đó như JMock hoặc một số thư viện nhại khác để đảm bảo bạn đang thử nghiệm riêng biệt. Đối với thử nghiệm hệ thống/thử nghiệm tích hợp, nghĩa là thử nghiệm mọi thứ trong khi chúng hoạt động cùng nhau, tôi có thể đề xuất FitNesse. Tôi đã có kinh nghiệm tốt với nó trong quá khứ.Nó cho phép bạn viết thử nghiệm của mình trong một trình duyệt web bằng cách sử dụng các bố cục giống như bảng đơn giản, nơi bạn có thể dễ dàng xác định đầu vào và đầu ra mong đợi của mình. Tất cả những gì bạn phải làm là viết một lớp sao lưu nhỏ gọi là Fixture, nó xử lý việc tạo ra các thành phần.

1

Bạn có thể xem danh sách này: Tools for regression testing/test automation of database centric java application? để biết danh sách các công cụ thú vị.

Như bạn dường như đã được sử dụng rộng rãi Junit nó có nghĩa là bạn đã "nhiễm test", đó là một điểm tốt ...

Theo kinh nghiệm cá nhân của tôi, điều khó khăn nhất để quản lý là dữ liệu. Ý tôi là, kiểm soát rất sâu sắc các dữ liệu agaisnt mà các bài kiểm tra được chạy.

0

Danh sách các công cụ được cung cấp trước hữu ích. Từ kinh nghiệm cá nhân, đây là những công cụ tôi thấy hữu ích:

Mocking - Mockito là một công cụ tuyệt vời và có kỹ thuật thông minh để đảm bảo bạn chỉ phải thử các phương pháp mà bạn thực sự quan tâm.

Kiểm tra cơ sở dữ liệu - DBunit không thể sử dụng để thiết lập dữ liệu thử nghiệm và xác minh tương tác cơ sở dữ liệu.

Kiểm tra ứng suất - Jmeter - một khi bạn thấy qua gui hơi clunky đây là một công cụ rất mạnh mẽ để thiết lập kịch bản và chạy thử nghiệm ứng suất.

Vì cách tiếp cận chung bắt đầu bằng cách cố gắng chạy thử nghiệm cho "đường dẫn hạnh phúc" thông thường thông qua ứng dụng của bạn, đây có thể là cơ sở để kiểm tra hồi quy và kiểm tra hiệu suất. Khi điều này hoàn tất, bạn có thể bắt đầu xem xét các trường hợp cạnh và các tình huống lỗi.

Mặc dù cấp độ kiểm tra này phải là thứ yếu để thử nghiệm đơn vị tốt.

Chúc may mắn!

Các vấn đề liên quan