Kỹ thuật thể nghiệm từ thử nghiệm truyền thống cũng có thể được sử dụng trong thí điểm Agile. Thêm vào đó, các kỹ thuật và thuật ngữ thí điểm cụ thể của Agile được sử dụng trong các dự án Agile.
|
|
|
ảnh minh họa : học kiểm thử |
Cơ sở kiểm tra
Trong các dự án nhanh, sản phẩm tồn đọng thay thế các tài liệu đặc tả đề nghị. Nội dung của việc tồn đọng sản phẩm thường là những câu chuyện của người dùng. Các yêu cầu phi chức năng cũng được chú ý trong các câu chuyện của người dùng. Do đó, cơ sở thử nghiệm trong các dự án Agile là câu chuyện của người dùng.
Để đảm bảo kiểm tra chất lượng, những điều sau đây cũng có thể được xem xét bổ sung làm cơ sở thể nghiệm
Trải nghiệm từ các lần lặp lại trước đó của cùng một dự án hoặc các dự án trước đây.
Các chức năng, kiến trúc, thiết kế, mã và đặc điểm chất lượng hiện có của hệ thống.
Lỗi dữ liệu từ các dự án ngày nay và quá cố.
Phản hồi của khách hàng.
Tài liệu người dùng.
Định nghĩa của Done
Định nghĩa hoàn thành (DoD) là các tiêu chí được sử dụng trong các dự án Agile để bảo đảm hoàn thành một hoạt động trong phần tồn đọng của Sprint. DoD có thể đổi thay từ nhóm Scrum này sang nhóm Scrum khác, nhưng nó phải nhất quán trong một nhóm.
DoD là một danh sách kiểm tra các hoạt động cần thiết bảo đảm thực hiện các chức năng và tính năng trong một câu chuyện của người dùng cùng với các đề nghị phi chức năng là một phần của câu chuyện của người dùng. Câu chuyện của người dùng đạt đến giai đoạn Xong sau khi hết thảy các mục trong danh sách soát DoD được hoàn thành. Một DoD được san sẻ giữa các nhóm.
Một DoD tiêu biểu cho một câu chuyện của người dùng có thể chứa
Tiêu chí ưng ý kiểm tra chi tiết
Tiêu chí để đảm bảo tính nhất quán của User Story với những người khác trong Iteration
Tiêu chí cụ thể can dự đến Sản phẩm
Các góc cạnh hành vi chức năng
Đặc điểm phi chức năng
Giao diện
đề nghị dữ liệu thể nghiệm
soát vùng phủ sóng
Tái cấu trúc
đề nghị coi xét và ưng chuẩn
Ngoài DoD cho Câu chuyện của người dùng, DoD cũng được đề nghị
ở mọi cấp độ rà
cho từng tính năng
cho mỗi lần lặp lại
để phát hành
thông tin kiểm tra
Người soát cần có thông tin kiểm tra sau
Câu chuyện của người dùng cần được soát
Tiêu chí hài lòng được kết liên
Giao diện hệ thống
Môi trường nơi Hệ thống được đợi mong sẽ hoạt động
Tính khả dụng của phương tiện
kiểm tra vùng phủ sóng
DoD
Trong các dự án Agile, vì thí nghiệm không phải là một hoạt động lần lượt và kiểm thử được cho là hoạt động trong một chế độ hợp tác, đó là bổn phận của người kiểm tra
Có được thông tin rà soát cần thiết trên cơ sở liên tiếp.
Xác định khoảng trống thông báo ảnh hưởng đến thể nghiệm.
Giải quyết các khoảng trống hiệp tác với các thành viên khác trong nhóm.
Quyết định khi nào đạt đến mức thể nghiệm.
đảm bảo các thử nghiệm hợp được thực hành tại các thời khắc hiệp.
Thiết kế thí nghiệm chức năng và phi chức năng
Trong các dự án Agile, các kỹ thuật thể nghiệm truyền thống có thể được dùng, nhưng trọng điểm là thí nghiệm sớm. Các trường hợp thí điểm cần phải được đặt trước khi bắt đầu triển khai.
Đối với thiết kế thí điểm chức năng, người thí điểm và nhà phát triển có thể sử dụng các kỹ thuật thiết kế thử nghiệm Hộp đen truyền thống như
Phân vùng tương đương
phân tách giá trị ranh giới
Bảng quyết định
Chuyển tiếp tiểu bang
Class Tree
Đối với thiết kế thí điểm phi chức năng, vì các yêu cầu phi chức năng cũng là một phần của mỗi câu chuyện của người dùng, các kỹ thuật thiết kế thí nghiệm hộp đen chỉ có thể được dùng để thiết kế các trường hợp kiểm tra có liên can.
thử nghiệm dò xét
Trong các dự án Agile, thời kì thường là yếu tố giới hạn cho Phân tích thể nghiệm và thiết kế thí điểm. Trong những trường hợp như vậy, các kỹ thuật kiểm tra dò hỏi có thể được kết hợp với các kỹ thuật thí nghiệm truyền thống.
kiểm tra dò hỏi (ET) được định tức là học tập đồng thời, thiết kế thí nghiệm và thực hành soát. Trong thể nghiệm Exploratory, người thể nghiệm chủ động kiểm soát thiết kế của các bài rà soát khi chúng được thực hành và dùng thông báo thu được trong khi thí nghiệm để thiết kế các bài kiểm tra mới và tốt hơn.
rà Exploratory có ích để thích nghi với các đổi thay trong các dự án Agile.
thể nghiệm dựa trên rủi ro
thể nghiệm dựa trên rủi ro là thử nghiệm dựa trên nguy cơ thất bại và giảm thiểu rủi ro bằng cách dùng các kỹ thuật thiết kế thí nghiệm.
Rủi ro chất lượng sản phẩm có thể được xác định là một vấn đề tiềm ẩn với chất lượng sản phẩm. Rủi ro chất lượng sản phẩm bao gồm
Rủi ro chức năng
Rủi ro hiệu suất phi chức năng
Rủi ro khả năng dùng phi chức năng
phân tách rủi ro phải được thực hiện để đánh giá xác suất (khả năng) và tác động của từng rủi ro. Sau đó, các rủi ro được ưu tiên
Rủi ro cao yêu cầu thí nghiệm rộng rãi
Rủi ro thấp chỉ đề nghị rà Cursory
Các thí nghiệm được thiết kế bằng cách dùng các kỹ thuật rà soát ăn nhập dựa trên chừng độ rủi ro và đặc điểm rủi ro của từng rủi ro. Các thí điểm sau đó được thực hành để giảm thiểu rủi ro.
rà soát hợp
Fit Tests là rà ưng tự động. phương tiện Fit và FitNesse có thể được sử dụng để tự động hóa các thí nghiệm chấp nhận.
FIT sử dụng JUnit, nhưng mở rộng chức năng kiểm tra. Các bảng HTML được sử dụng để hiển thị các trường hợp Kiểm thử. Lịch thi đấu là một lớp Java phía sau bảng HTML. Lịch thi đấu lấy nội dung của bảng HTML và chạy các trường hợp thử nghiệm trên dự án đang được thí điểm.
No comments:
Post a Comment