Kỹ thuật kiểm thử phần mềm từ thử nghiệm truyền thống cũng có thể được sử dụng trong thử nghiệm Agile.
Để đảm bảo kiểm thử chất lượng, những điều sau đây cũng có thể được coi là cơ sở kiểm thử
Kinh 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 trong quá khứ.
Các chức năng, kiến trúc, thiết kế, mã và các đặc tính chất lượng hiện có của hệ thống.
Khiếm khuyết dữ liệu từ các dự án hiện tại và quá khứ.
Phản hồi của khách hàng.
Tài liệu người dùng.
Định nghĩa Hoàn thành (DoD) là tiêu chí được sử dụng trong các dự án Agile để đảm bảo hoàn thành một hoạt động trong hồ sơ tồn đọng của Sprint. DoD có thể thay đổi từ nhóm Scrum này sang nhóm 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 thử các hoạt động cần thiết đảm bảo thực hiện các chức năng và tính năng trong câu chuyện của người dùng cùng với các yêu cầu phi chức năng là một phần của câu chuyện người dùng. Câu chuyện người dùng đạt đến giai đoạn Xong sau khi tất cả các mục trong danh sách kiểm thử DoD được hoàn thành. Một DoD được chia sẻ trên toàn đội.
Tiêu chí chấp nhận thử nghiệm chi tiết
Tiêu chí để đảm bảo tính nhất quán của Câu chuyện người dùng với những người khác trong Lặp lại
Tiêu chí cụ thể liên quan đến sản phẩm
Các khía cạnh hành vi chức năng
Đặc điểm phi chức năng
Yêu cầu dữ liệu thử nghiệm
kiểm thử vùng phủ sóng
Tái cấu trúc
Ngoài DoD cho Câu chuyện của người dùng, DoD cũng được yêu cầu
ở mọi cấp độ kiểm thử
cho mỗi tính năng
cho mỗi lần lặp
để phát hành
Người kiểm thử cần có thông tin kiểm thử sau
Câu chuyện người dùng cần được kiểm thử
Tiêu chí chấp nhận liên kết
Giao diện hệ thống
Môi trường nơi Hệ thống dự kiến sẽ hoạt động
Công cụ có sẵn
kiểm thử vùng phủ sóng
Trong các dự án Agile, vì thử nghiệm không phải là một hoạt động tuần tự và người thử nghiệm phải làm việc trong chế độ hợp tác, nên trách nhiệm của người thử nghiệm là
Có được thông tin kiểm thử phần mềm cần thiết trên cơ sở liên tục.
Xác định các lỗ hổng thông tin ảnh hưởng đến thử nghiệm.
Giải quyết các khoảng trống hợp tác với các thành viên khác trong nhóm.
Quyết định khi đạt đến một mức độ thử nghiệm.
Đảm bảo kiểm thử thích hợp thực hiện tại thời điểm thích hợp.
Thiết kế kiểm thử 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 sử dụng, nhưng trọng tâm là thử nghiệm sớm. Các trường hợp thử nghiệm cần được đưa ra trước khi bắt đầu thực hiện.
Đối với thiết kế thử nghiệm chức năng, người thử nghiệ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ị biên
Bàn quyết định
Chuyển nhà nước
Cây lớp
Đối với thiết kế thử nghiệ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 sử dụng để thiết kế các trường hợp thử nghiệm có liên quan.
Trong các dự án Agile, thời gian thường là yếu tố giới hạn cho Phân tích thử nghiệm và Thiết kế thử nghiệm. Trong những trường hợp như vậy, các kỹ thuật kiểm thử thăm dò có thể được kết hợp với các kỹ thuật kiểm thử truyền thống.
Khám phá thử nghiệm (ET) được định nghĩa là học tập đồng thời, thiết kế thử nghiệm và thực hiện thử nghiệm. Trong Thử nghiệm thăm dò, người kiểm thử chủ động kiểm soát thiết kế của các thử nghiệm khi chúng được thực hiện và sử dụng thông tin thu được trong khi thử nghiệm để thiết kế các thử nghiệm mới và tốt hơn.
kiểm thử thăm dò có ích để phù hợp với những thay đổi trong các dự án Agile.
Thử nghiệm dựa trên rủi ro là thử nghiệm dựa trên rủi ro thất bại và giảm thiểu rủi ro bằ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 định nghĩa 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 sử dụng phi chức năng
Phân tích rủi ro đượ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 đòi hỏi phải thử nghiệm rộng rãi
Rủi ro thấp chỉ yêu cầu kiểm thử chữ thảo
Các thử nghiệm được thiết kế bằng cách sử dụng các Kỹ thuật kiểm thử phù hợp dựa trên Mức độ rủi ro và Đặc điểm rủi ro của từng rủi ro. Các thử nghiệm sau đó được thực hiện để giảm thiểu rủi ro.
kiểm thử phần mềm Fit là kiểm thử chấp nhận tự động. Công cụ Fit và FitNesse có thể được sử dụng để tự động hóa các bài kiểm thử chấp nhận.
FIT sử dụng JUnit, nhưng mở rộng chức năng thử nghiệm. Bảng HTML được sử dụng để hiển thị các trường hợp thử nghiệm. Lịch thi đấu là một lớp Java đằng 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ử nghiệm.
Ngoài ra, các kỹ thuật và thuật ngữ kiểm thử cụ thể của Agile được sử dụng trong các dự án Agile.
Trong các dự án nhanh, tồn đọng sản phẩm thay thế các tài liệu đặc tả yêu cầu. Nội dung của tồn đọng sản phẩm là câu chuyện người dùng thông thường.
Cơ sở kiểm thử
Trong các dự án nhanh, tồn đọng sản phẩm thay thế các tài liệu đặc tả yêu cầu. Nội dung của tồn đọng sản phẩm là câu chuyện người dùng thông thường.
Các yêu cầu phi chức năng cũng được quan tâm 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.
 |
| Học kiểm thử phần mềm |
Để đảm bảo kiểm thử chất lượng, những điều sau đây cũng có thể được coi là cơ sở kiểm thử
Kinh 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 trong quá khứ.
Các chức năng, kiến trúc, thiết kế, mã và các đặc tính chất lượng hiện có của hệ thống.
Khiếm khuyết dữ liệu từ các dự án hiện tại và quá khứ.
Phản hồi của khách hàng.
Tài liệu người dùng.
Định nghĩa Xong
Định nghĩa Hoàn thành (DoD) là tiêu chí được sử dụng trong các dự án Agile để đảm bảo hoàn thành một hoạt động trong hồ sơ tồn đọng của Sprint. DoD có thể thay đổi từ nhóm Scrum này sang nhóm 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 thử các hoạt động cần thiết đảm bảo thực hiện các chức năng và tính năng trong câu chuyện của người dùng cùng với các yêu cầu phi chức năng là một phần của câu chuyện người dùng. Câu chuyện người dùng đạt đến giai đoạn Xong sau khi tất cả các mục trong danh sách kiểm thử DoD được hoàn thành. Một DoD được chia sẻ trên toàn đội.
Một DoD điển hình cho câu chuyện người dùng có thể chứa
Tiêu chí chấp nhận thử nghiệm chi tiết
Tiêu chí để đảm bảo tính nhất quán của Câu chuyện người dùng với những người khác trong Lặp lại
Tiêu chí cụ thể liên quan đến sản phẩm
Các khía cạnh hành vi chức năng
Đặc điểm phi chức năng
Giao diện
Yêu cầu dữ liệu thử nghiệm
kiểm thử vùng phủ sóng
Tái cấu trúc
Yêu cầu xem xét và phê duyệt
Ngoài DoD cho Câu chuyện của người dùng, DoD cũng được yêu cầu
ở mọi cấp độ kiểm thử
cho mỗi tính năng
cho mỗi lần lặp
để phát hành
Thông tin kiểm thử
Người kiểm thử cần có thông tin kiểm thử sau
Câu chuyện người dùng cần được kiểm thử
Tiêu chí chấp nhận liên kết
Giao diện hệ thống
Môi trường nơi Hệ thống dự kiến sẽ hoạt động
Công cụ có sẵn
kiểm thử 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 tuần tự và người thử nghiệm phải làm việc trong chế độ hợp tác, nên trách nhiệm của người thử nghiệm là
Có được thông tin kiểm thử phần mềm cần thiết trên cơ sở liên tục.
Xác định các lỗ hổng thông tin ảnh hưởng đến thử nghiệm.
Giải quyết các khoảng trống hợp tác với các thành viên khác trong nhóm.
Quyết định khi đạt đến một mức độ thử nghiệm.
Đảm bảo kiểm thử thích hợp thực hiện tại thời điểm thích hợp.
Thiết kế kiểm thử 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 sử dụng, nhưng trọng tâm là thử nghiệm sớm. Các trường hợp thử nghiệm cần được đưa ra trước khi bắt đầu thực hiện.
Đối với thiết kế thử nghiệm chức năng, người thử nghiệ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ị biên
Bàn quyết định
Chuyển nhà nước
Cây lớp
Đối với thiết kế thử nghiệ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 sử dụng để thiết kế các trường hợp thử nghiệm có liên quan.
Thử nghiệm thăm dò
Trong các dự án Agile, thời gian thường là yếu tố giới hạn cho Phân tích thử nghiệm và Thiết kế thử nghiệm. Trong những trường hợp như vậy, các kỹ thuật kiểm thử thăm dò có thể được kết hợp với các kỹ thuật kiểm thử truyền thống.
Khám phá thử nghiệm (ET) được định nghĩa là học tập đồng thời, thiết kế thử nghiệm và thực hiện thử nghiệm. Trong Thử nghiệm thăm dò, người kiểm thử chủ động kiểm soát thiết kế của các thử nghiệm khi chúng được thực hiện và sử dụng thông tin thu được trong khi thử nghiệm để thiết kế các thử nghiệm mới và tốt hơn.
kiểm thử thăm dò có ích để phù hợp với những thay đổi 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 rủi ro thất bại và giảm thiểu rủi ro bằ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 định nghĩa 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 sử dụng phi chức năng
Phân tích rủi ro đượ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 đòi hỏi phải thử nghiệm rộng rãi
Rủi ro thấp chỉ yêu cầu kiểm thử chữ thảo
Các thử nghiệm được thiết kế bằng cách sử dụng các Kỹ thuật kiểm thử phù hợp dựa trên Mức độ rủi ro và Đặc điểm rủi ro của từng rủi ro. Các thử nghiệm sau đó được thực hiện để giảm thiểu rủi ro.
Kiểm thử sự phù hợp
kiểm thử phần mềm Fit là kiểm thử chấp nhận tự động. Công cụ Fit và FitNesse có thể được sử dụng để tự động hóa các bài kiểm thử chấp nhận.
FIT sử dụng JUnit, nhưng mở rộng chức năng thử nghiệm. Bảng HTML được sử dụng để hiển thị các trường hợp thử nghiệm. Lịch thi đấu là một lớp Java đằng 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ử nghiệm.
Không có nhận xét nào:
Đăng nhận xét