Các mục tiêu của kiểm thử giúp xác định cái gì cần kiểm thử. Trong các hoạt động phân tích và thiết kế kiểm thử, chúng ta sử dụng mục tiêu này làm hướng dẫn để thực hiện hai hoạt động chính:
- Xác định và điều chỉnh các điều kiện kiểm thử cho từng hạng mục kiểm thử
- Tạo testcase thực hiện các điều kiện kiểm thử đã xác định
Tuy nhiên, xác định các mục tiêu kiểm thử không thôi chưa đủ. Chúng ta không chỉ cần biết kiểm tra những gì, mà còn theo thứ tự nào và mức độ bao nhiêu. Do hạn chế về thời gian, mong muốn thử nghiệm các lĩnh vực quan trọng nhất trước tiên và phân bổ nguồn lực theo cách hiệu quả nhất có thể, chúng ta cần đánh thứ tự ưu tiên cho các điều kiện kiểm thử.
Mục tiêu của kiểm thử chức năng
Kiểm thử chức năng có thể áp dụng cho bất kỳ cấp độ kiểm tra nào và tồn tại trong suốt vòng đời. Nghĩa là chúng ta cần kiểm thử ở cấp độ đơn vị, tích hợp, hệ thống và chấp nhận.
Để xác định và ghi lại các điều kiện kiểm thử, có 2 lựa chọn quan trọng:
- Mức độ chi tiết mà chúng ta cần để mô tả các điều kiện thử nghiệm trong tài liệu
- Cấu trúc của tài liệu cho các điều kiện thử nghiệm
Cách Xác Định Mức Độ Chi Tiết Và Cấu Trúc Điều Kiện Kiểm Thử
Có một số cách phổ biến để xác định mức độ chi tiết và cấu trúc của các điều kiện kiểm thử:
Thứ nhất, làm việc song song với các tài liệu test basis.
Ví dụ: nếu bạn có tài liệu yêu cầu tiếp thị và tài liệu yêu cầu hệ thống trong tổ chức của mình, thì tài liệu trước thường ở cấp cao và tài liệu sau thường ở cấp thấp hơn. Vì vậy, bạn có thể sử dụng tài liệu yêu cầu tiếp thị để tạo các điều kiện kiểm tra cấp cao, sau đó sử dụng tài liệu yêu cầu hệ thống để xây dựng một hoặc nhiều điều kiện kiểm tra cấp thấp bên dưới mỗi điều kiện kiểm tra cấp cao.
Thứ hai, sử dụng với phân tích rủi ro chất lượng.
Theo cách tiếp cận này, chúng ta có thể phác thảo các tính năng chính và đặc điểm chất lượng ở mức cao. Sau đó, chúng ta có thể xác định một hoặc nhiều hạng mục rủi ro chất lượng chi tiết cho từng tính năng hoặc đặc điểm. Các hạng mục rủi ro chất lượng này là các điều kiện thử nghiệm.
Thứ ba, chuyển trực tiếp đến các yêu cầu cấp thấp nếu bạn chỉ có các yêu cầu chi tiết.
Trong trường hợp này, việc truy xuất nguồn gốc từ các điều kiện thử nghiệm chi tiết đến các yêu cầu là cần thiết để báo cáo quản lý và ghi lại những gì thử nghiệm cần thiết lập.
Thứ tư, chỉ xác định các điều kiện kiểm tra cấp cao, khi không có bất kỳ cơ sở kiểm tra chính thức nào. Ví dụ, trong kiểm thử thăm dò, một số người ủng hộ tài liệu về các điều kiện thử nghiệm dưới dạng điều lệ kiểm thử – test charters. Tại thời điểm đó, có rất ít hoặc không có chi tiết bổ sung nào được tạo cho các bài kiểm thử không có hoặc hầu như không có kịch bản.
Một lần nữa, điều quan trọng cần nhớ là mức độ chi tiết và cấu trúc được chọn phải phù hợp với chiến lược hoặc chiến lược kiểm tra. Và tất nhiên, những chiến lược đó phải phù hợp với kế hoạch kiểm tra, cũng như với bất kỳ chính sách kiểm tra hoặc sổ tay kiểm tra rộng hơn nào.
Ngoài ra, hãy nhớ rằng: tại thời điểm này, thật dễ dàng để nắm bắt thông tin truy xuất nguồn gốc trong khi bạn lấy các điều kiện thử nghiệm từ các tài liệu cơ sở thử nghiệm như requirements, designs, use cases, user manuals, v.v. Việc tạo lại thông tin đó sau này bằng cách kiểm tra các trường hợp thử nghiệm sẽ khó hơn nhiều.
Test Oracles
Test oracle là một nguồn mà chúng ta sử dụng để xác định kết quả dự kiến của một thử nghiệm. Chúng ta có thể so sánh những kết quả mong đợi này với kết quả thực tế khi chạy thử nghiệm. Đôi khi oracle là hệ thống hiện có. Đôi khi đó là hướng dẫn sử dụng. Đôi khi đó là kiến thức chuyên môn của một cá nhân. Chúng ta không bao giờ nên sử dụng chính mã như một oracle, ngay cả để kiểm tra cấu trúc, bởi vì đó chỉ đơn giản là kiểm tra xem trình biên dịch, hệ điều hành và phần cứng có hoạt động hay không.
Test Oracle được sử dụng khi chưa, hoặc không có tài liệu rõ ràng, đầy đủ về những gì hệ thống cần thực hiện. Oracle áp dụng cho tất cả các cấp độ kiểm thử. Tuy nhiên, test basis sẽ khác nhau tuỳ theo cấp độ. Các cấp độ kiểm tra cao hơn như acceptance testing, system testing phụ thuộc nhiều hơn vào yêu cầu đặc tả, use case và bussiness process đã xác định. Các cấp độ kiểm thử thấp hơn như component test và integration test phụ thuộc nhiều hơn vào đặc tả thiết kế cấp thấp.
Phân Tích Tĩnh
Ở một bài viết khác trong blog của mình mình đã giới thiệu chi tiết về Kỹ thuật phân tích tĩnh. Các bạn có thể xem chi tiết tại đây.
Vậy, tại sao phải tiến hành phân tích tĩnh:
Thứ nhất, giá trị của thử nghiệm tĩnh sớm trong vòng đời để phát hiện lỗi khi chúng tốn ít chi phí và dễ sửa hơn.
Thứ hai, vai trò phòng ngừa của thử nghiệm khi tham gia sớm vào vòng đời.
Thứ ba, việc thử nghiệm nên được tham gia sớm vào dự án.
Ba ý tưởng này có liên quan với nhau vì phân tích và thiết kế thử nghiệm là một hình thức thử nghiệm tĩnh, nó có tác dụng bổ sung với các hình thức thử nghiệm tĩnh khác và chúng ta chỉ có thể khai thác sức mạnh tổng hợp đó nếu chúng được tham gia vào đúng thời điểm.
Lưu ý rằng, tùy thuộc vào thời điểm hoàn thành công việc thiết kế và phân tích kiểm thử, bạn có thể xác định các điều kiện kiểm thử và trường hợp kiểm thử song song với các đánh giá và phân tích tĩnh của cơ sở kiểm thử. Trên thực tế, bạn có thể chuẩn bị cho cuộc họp xem xét yêu cầu bằng cách thực hiện phân tích và thiết kế thử nghiệm theo yêu cầu. Phân tích và thiết kế thử nghiệm có thể đóng vai trò là thử nghiệm tĩnh có cấu trúc, tập trung vào lỗi của đặc tả yêu cầu, tạo ra đầu vào hữu ích cho cuộc họp xem xét yêu cầu.
Metrics
Để đo lường mức độ hoàn thiện của phần này trong quy trình kiểm tra, chúng ta có thể đo lường như sau:
- Tỷ lệ phần trăm các yêu cầu hoặc rủi ro về chất lượng (sản phẩm) nằm trong các điều kiện thử nghiệm
- Tỷ lệ phần trăm các điều kiện thử nghiệm được bao phủ bởi các trường hợp thử nghiệm
- Số lỗi được tìm thấy trong quá trình phân tích và thiết kế thử nghiệm
Chúng ta có thể theo dõi các nhiệm vụ thiết kế và phân tích thử nghiệm dựa trên cấu trúc phân chia công việc, điều này rất hữu ích trong việc xác định xem chúng ta có đang tiến hành theo ước tính và tiến độ hay không.
Mình xin dừng bài viết này tại đây. Hẹn gặp lại các bạn trong các bài viết tiếp theo.
Happy testing!