Cấu trúc đúng của các thử nghiệm chức năng/chấp nhận

Question

Tôi hiện đang làm việc để xây dựng một bộ thử nghiệm chức năng/chấp nhận tự động cho một dự án, nhưng tôi không có nhiều kinh nghiệm viết các loại kiểm tra này, vì vậy tôi muốn có được một số đầu vào đúng cấu trúc chúng. Cụ thể, tôi đang làm việc với phần mở rộng Graphene của Arquillian.

Ví dụ, nói rằng tôi có 3 bài kiểm tra, A, B, và C.

Testa: Các thử nghiệm cách đăng nhập vào một tài khoản trong ứng dụng. Vì vậy, nếu thử nghiệm thành công, trình duyệt phải ở trên trang chủ/thông tin của tài khoản.

TestB: Kiểm tra sửa đổi mật khẩu của tài khoản. Điều này sẽ yêu cầu đăng nhập vào tài khoản, sau đó kiểm tra chức năng thay đổi mật khẩu.

TestC: Kiểm tra sửa đổi email của tài khoản. Điều này một lần nữa sẽ yêu cầu đăng nhập vào tài khoản, sau đó kiểm tra chức năng thay đổi email.

Nếu TestA thất bại do sự cố với mã đăng nhập, rõ ràng TestB và TestC cũng không thành công vì họ yêu cầu đăng nhập vào tài khoản.

Câu hỏi: Các thử nghiệm chức năng/chấp nhận tự động có trùng lặp với một quá trình cần thiết để hoàn thành bất kỳ thử nghiệm nào đang xác minh không? Trong trường hợp này, TestB và TestC cần phải đăng nhập vào tài khoản trước khi thực hiện bất kỳ điều gì khác. Nên mỗi bài kiểm tra một cách rõ ràng gọi cái gì đó như:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assertTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

Hoặc tôi nên sử dụng một số cách để chế giễu một tài khoản vào phiên có thể được sử dụng bởi các thử nghiệm B và C sao cho họ không thất bại ngay cả khi Testa (thực tế kiểm tra đăng nhập)?

Vì đây là những thử nghiệm chấp nhận bởi người dùng, nên tôi nên làm chính xác những gì người dùng sẽ làm và đăng nhập bất cứ khi nào cần thiết, nhưng tôi không chắc liệu đây có phải là bản sao không cần thiết. được xử lý như các đơn vị chức năng, tương tự như kiểm tra đơn vị tiêu chuẩn) và tôi muốn nhận phản hồi từ một người có nhiều kinh nghiệm hơn trong lĩnh vực này.

Xin cảm ơn trước. Hy vọng câu hỏi của tôi không quá phức tạp. :)

Answer 1

Cá nhân tôi đã làm điều đó để mỗi trường hợp kiểm tra sao chép hành động của người dùng càng nhiều càng tốt, nhưng cắt ra những nơi cần. Ví dụ: TestA: đăng nhập vào, truy cập đúng trang web, truy cập vào hệ thống quản trị, tìm người dùng và xóa một phần thông tin người dùng (chẳng hạn như tên), TestB: đăng nhập, vào trang web chính xác, chuyển đến đó là hệ thống quản trị, tìm người dùng và cố gắng xóa toàn bộ người dùng qua nút.

TestA và TestB kết thúc trên cùng một trang - trang chi tiết của người dùng. Vì vậy, trong bài kiểm tra A, tôi có thể làm điều đó một cách chính xác, chính xác cách người dùng thực hiện nó, nhưng trong bài kiểm tra B, tôi đi trực tiếp đến trang chi tiết cho người dùng đó, trái ngược với việc điều hướng đúng theo cách thủ công. Tại sao?

Tiết kiệm thời gian, tại sao tôi nên thực hiện lại điều hướng trong kiểm tra B khi kiểm tra A đã kiểm tra chưa? Hãy nhớ rằng các bài kiểm tra không nên phụ thuộc lẫn nhau - nếu cả ba bài kiểm tra đều thất bại vì bạn không thể đăng nhập - đó là toàn bộ vấn đề, bạn không thể đăng nhập, vì vậy bạn không thể thực hiện bất kỳ hành động nào khác.

Hãy suy nghĩ về điều đó với tư cách người dùng.Mỗi bài kiểm tra có một phần chức năng có thể xem được của người dùng mà họ đang thử nghiệm, nhưng nếu bạn không thể đăng nhập, người dùng không thể thấy bất kỳ chức năng nào hoặc làm bất cứ điều gì với chức năng này. Nếu tôi không thể đăng nhập, tôi không thể thay đổi mật khẩu, hoặc email của tôi - vì vậy các bài kiểm tra một cách hợp lý sẽ không thành công theo cách tương tự.

Answer 2

Đây thực sự là câu hỏi cho mỗi dự án, vì cả hai đều là phương pháp hợp lệ nhưng trong các trường hợp khác nhau, bạn nên ưu tiên hơn. Trong một hệ thống lớn, tôi thích chạy trường hợp kiểm tra từ đầu đến cuối bất kể tần suất lặp lại các bước này (ví dụ: tôi đăng nhập cho mọi thử nghiệm). Tôi tin rằng đây là những gì Arran đã nói rồi (+1!). Lý do tôi thường làm điều này là bởi vì đôi khi một trạng thái được thực hiện từ một màn hình trước đó có thể gây ra một lỗi sau đó và đó là loại điều kiểm tra tự động là rất tốt cho việc tìm kiếm. Tuy nhiên, với những điều này, tôi đảm bảo rằng dữ liệu thử nghiệm đều hợp lệ cho các bước dẫn đầu và nhắm đến giải pháp nhanh nhất có thể. Ví dụ: đăng nhập phải luôn có đúng người dùng và mật khẩu khi kiểm tra đăng nhập thành công, hoặc giả sử nó nên xử lý ngoại lệ hoặc tìm kiếm phần tử dễ nhận biết trên trang thay vì phức tạp hơn 'quan trọng'.

Với điều đó đã nói, bạn cũng có thể viết các thử nghiệm đang thử nghiệm nhiều yêu cầu trong một loại luồng chức năng. Nếu các bài kiểm tra ngắt dòng cần được viết để xác định khu vực mà nhiệm vụ tổng thể bị thất bại. Tôi sẽ chỉ đề nghị điều này cho các dự án nhỏ, hoặc nếu thử nghiệm không phải là một ưu tiên do thiếu nguồn lực. Ví dụ, chạy một thử nghiệm để đăng nhập, chọn một mục, đặt nó vào một giỏ hàng, đi kiểm tra và trả tiền sẽ kiểm tra tất cả chức năng này và cho phép một nhóm sửa chữa quá trình 'bao quát' thay vì chỉ một số, có khả năng bị ngắt kết nối , lỗi. Tuy nhiên, một lần nữa, tôi nghĩ rằng cách tiếp cận đầu tiên là kỹ lưỡng hơn nhưng cũng mất nhiều thời gian hơn (nhưng đáng làm thường xuyên :)).

Vì sợ rằng câu trả lời của tôi sẽ trở nên quá dài và tôi không đi xa hơn vào đây, nhưng có rất nhiều điều để nói về vấn đề này và tôi sẽ đề nghị ngồi xuống và vẽ ra những gì bạn đang cố gắng thử nghiệm trong ứng dụng, hiện tại và trong tương lai. Điều này có thể sẽ rất tiết lộ và khuyến khích cơ cấu kiểm tra tốt và thực hành viết tự động. Hy vọng điều này sẽ giúp và không quá dài :)

Answer 3

Trong một sự chấp nhận của người dùng kiểm tra bạn không muốn giả mạo, nhưng càng gần với cách người dùng cuối sẽ sử dụng hệ thống.

Tuy nhiên, chú thích kiểm tra đơn vị one assert per test có thể được mở rộng để kiểm tra chấp nhận: Trong TestA logic xác minh của bạn là về xác nhận đăng nhập phù hợp: Trong TestB bạn không cần phải lặp lại xác minh này, khẳng định rằng sửa đổi mật khẩu đã được xử lý chính xác .

Trong JUnit, người dùng có thể sử dụng assumeTrue thay vì assertTrue cho mục đích đó. Vì vậy, TestB của bạn sẽ trở thành:

/* ...initial test setup code here */ 
LoginPage.login(username, password); 
assumeTrue(onCorrectAccountPage); 
AccountModification.changePassword(newPassword); 

Bây giờ, nếu giả địnhTrở thất bại, kiểm tra đơn giản bị bỏ qua. TestA của bạn sẽ vẫn thất bại, tuy nhiên, nói cho bạn và người dùng cuối của bạn biết vấn đề thực sự là gì.