Tiếp theo bài viết về Phân tích và Thiết kế kiểm thử, hôm nay hãy cùng mình tìm hiểu giai đoạn tiếp theo trong quy trình kiểm thử phần mềm nhé.
Triển Khai Kiểm Thử
Triển khai kiểm thử – Test implementation bao gồm tất cả các công việc cần thiết còn lại để có thể sẵn sàng cho việc bắt đầu chạy test case. Tại thời điểm này, việc phân tích và thiết kế công việc đã xong, vậy những công việc còn lại là gì?
- Chỉ định thủ tục kiểm thử – test procedure. Có nghĩa cần tổ chức các test case thành các test procedure (hoặc test scripts).
- Chuẩn bị dữ liệu kiểm thử
- Phân bổ nguồn lực tiến hành kiểm thử. Những câu hỏi cần trả lời bao gồm: Ai là người chạy thử nghiệm? Họ nên chạy chúng theo thứ tự nào? Môi trường nào là cần thiết cho những bài kiểm tra nào? Chúng ta cần trả lời những câu hỏi này.
- Xem xét liệu tất cả các tiêu chí đầu vào đã rõ ràng và có được đáp ứng không.
Chúng ta hãy cùng tìm hiểu sâu hơn về các công việc này trong các phần dưới đây.
Chỉ Định Thủ Tục Kiểm Thử
Chỉ định thủ tục kiểm thử – test procedure bao gồm việc xác định ai sẽ tiến hành test procedure, khi nào, trong môi trường kiểm thử nào, với dữ liệu gì.
Chúng ta phải đánh giá các ràng buộc có thể yêu cầu chạy thử nghiệm theo một thứ tự cụ thể. Nếu nhận thấy có những lý do những yếu tố phụ thuộc này mà test procedure không thể áp dụng theo quy trình đã được thiết lập trước đó, thì có hai lựa chọn: Một, thay đổi trình tự để phù hợp với các trở ngại khác nhau đã được phát hiện ra. Hai là, loại bỏ các chướng ngại vật.
Môi Trường Kiểm Thử
Các môi trường thử nghiệm đã sẵn sàng để sử dụng chưa? Hãy xem xét một số vấn đề chúng ta cần giải quyết trước khi biết câu trả lời.
Nếu môi trường kiểm thử bị cấu hình sai, chúng ta sẽ nhận được các kết quả kiểm tra vô ích. Môi trường thử nghiệm được cấu hình đúng cách là gì và nó giúp ích gì cho chúng ta?
Thứ nhất, một môi trường kiểm thử được cấu hình phù hợp cho phép tìm ra lỗi trong các điều kiện kiểm thử mà chúng ta dự định chạy. Ví dụ: nếu chúng ta muốn kiểm tra hiệu suất, nó cho phép chúng ta tìm ra những tắc nghẽn không mong muốn có thể làm chậm hệ thống.
Thứ hai, môi trường kiểm thử được cấu hình đúng cách sẽ hoạt động bình thường khi không xảy ra lỗi. Nói cách khác, nó không tạo ra nhiều kết quả dương tính giả – false positives.
Thứ ba, ở các cấp độ thử nghiệm cao hơn như thử nghiệm hệ thống và thử nghiệm tích hợp hệ thống, môi trường thử nghiệm được định cấu hình phù hợp sẽ sao chép môi trường sản xuất hoặc người dùng cuối. Nhiều khiếm khuyết, đặc biệt là các khiếm khuyết phi chức năng như các vấn đề về hiệu suất và độ tin cậy, rất khó nếu không nói là không thể tìm thấy trong môi trường thu nhỏ.
Dữ Liệu Kiểm Thử
Bạn cần biết mỗi test procedure cần dữ liệu gì. Hãy kiểm tra xem liệu dữ liệu có khả dụng trong thời gian bạn lập lịch chạy test procedure đó hay không. Giống như môi trường kiểm thử, hãy đảm bảo rằng dữ liệu kiểm thử không chỉ đã được tạo ra mà còn phải đảm bảo không có test procedure nào khác – hoặc bất kỳ hoạt động kiểm thử nào khác cho vấn đề đó có thể ảnh hưởng đến khả năng tồn tại và khả năng truy cập của dữ liệu trong thời gian sử dụng dữ liệu kiểm thử đã được lên lịch. Nhiều dữ liệu kiểm thử cũng là một vấn đề. Đối với các dự án chạy đồng thời kiểm thử thủ công và kiểm thử tự động. Việc cố gắng chạy kiểm thử thủ công vào ban ngày và kiểm thử tự động vào ban đêm, có thể dẫn đến nhiều vấn đề khi một quy trình được phát triển để khôi phục dữ liệu đúng cách tại thời điểm chuyển giao giữa kiểm thử thủ công và kiểm thử tự động (vào cuối ngày) và giữa kiểm thử tự động và kiểm thử thủ công (vào đầu ngày hôm sau).
Thực Hiện Kiểm Thử
Sau khi các vấn đề hậu cần của thiết lập ban đầu được xử lý, người thử nghiệm bắt đầu chạy các bước thử nghiệm cụ thể. Ở giai đoạn này, chúng ta đã đi vào trọng tâm của việc thực hiện kiểm thử. Việc cần làm là so sánh kết quả thực tế với kết quả mong đợi. Đây thực sự là thời điểm mà việc thử nghiệm tăng thêm giá trị hoặc loại bỏ giá trị khỏi dự án.
Câu hỏi quan trọng là: Điều gì sẽ xảy ra nếu chúng ta nhận thấy sự không khớp giữa kết quả mong đợi và kết quả thực tế?
Một số sự cố là lỗi thực sự. Lỗi xảy ra khi hệ thống hoạt động không đúng do một hoặc nhiều lỗi. Đây là tình huống lý tưởng khi một sự cố đã xảy ra. Nếu chúng ta đang xem một lỗi, một triệu chứng của một lỗi thực sự, chúng ta nên bắt đầu thu thập dữ liệu để giúp nhà phát triển giải quyết lỗi đó.
Một số sự cố không phải là lỗi mà là những kết quả dương tính giả. Kết quả dương tính giả xảy ra khi kết quả thực tế và dự kiến không khớp do đặc tả không chính xác, dữ liệu kiểm tra không hợp lệ, môi trường kiểm tra được định cấu hình không chính xác, lỗi do người chạy kiểm thử. v.v..
Nếu chúng ta có thể phát hiện ra kết quả dương tính giả ngay lập tức thì ngay thời điểm nó xảy ra, thiệt hại sẽ được hạn chế. Người kiểm tra nên sửa bài kiểm tra, điều này có thể liên quan đến một số công việc quản lý cấu hình nếu các bài kiểm tra được kiểm tra vào kho lưu trữ. Người thử nghiệm sau đó nên chạy lại thử nghiệm. Do đó, thiệt hại gây ra chỉ giới hạn ở việc người thử nghiệm lãng phí thời gian cùng với tác động có thể xảy ra của thời gian bị mất đó đối với lịch trình cộng với thời gian cần thiết để sửa bài kiểm tra và thời gian cần thiết để chạy lại bài kiểm tra.
Mình xin dừng bài viết hôm nay tại đây. Cảm ơn các bạn đã dành thời gian đọc bài viết của mình. Hẹn gặp lại các bạn trong bài viết tiếp theo trong loạt bài về Quy trình kiểm thử.
Happy testing!