CHƯƠNG 1 NGHIÊN CỨU TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM Chương này trình bày một cách tóm tắt kiến thức cơ bản về kiểm thử phần mềm, kiểm thử tự động. Từ đó cách tiếp cận bài toán tối ưu trong kiểm thử được đề xuất và mô hình ưu tiên hóa và lựa chọn trường hợp kiểm thử được trình bày. Đồng thời, cũng đưa ra một số nghiên cứu của các tác giả trong lĩnh vực liên quan tới một số kĩ thuật tối ưu hóa trong kiểm thử phần mềm.1 Giới thiệu về kiểm thử phần mềm Phần này giới thiệu về kiểm thử phần mềm, các khái niệm xung quanh kiểm thử phần mềm và tự động hóa trong kiểm thử.1 Kiểm thử và các phương pháp kiểm thử khác nhau Định nghĩa 1.1 Tiêu chuẩn IEEE 610 (1990) định nghĩa trường hợp kiểm thử: Một bộ đầu vào, điều kiện thực thi, và kết quả mong đợi được xây dựng cho một mục tiêu nhất định, như kiểm tra một đường dẫn phần mềm, hay xác minh việc tuân theo những yêu cầu cụ thể Các tài liệu xác định đầu vào, kết quả mong đợi và một bộ điều kiện cho một đối tượng kiểm thử Kiểm thử phần mềm là phân tích được thực hiện để đánh giá chất lượng của hệ thống phần mềm dưới dạng một bài kiểm tra [13]. Có rất nhiều kỹ thuật kiểm thử để đảm bảo chắc chắn rằng một bộ phận hay một hệ thống được kiểm tra sẽ đáp ứng đúng yêu cầu đặc tả.
Rất nhiều các phương án khác nhau được sử dụng để chọn ra kỹ thuật kiểm thử hợp lí nhất. Điều này là do khối lượng kiểm thử là rất lớn trong khi thời gian và các chi phí khác là có hạn. Trong mô hình phát triển phần mềm, thời gian và tài nguyên cho kiểm thử là giới hạn. Mô hình phát triển phần mềm thác nước truyền thống [14] kiểm thử chỉ diễn ra khi hệ thống đã được thiết kế và triển 12 khai xong toàn bộ.
Tuy nhiên, trong mô hình phát triển nhanh agile ngày nay, kiểm thử diễn ra cùng giai đoạn với quá trình phát triển phần mềm. Chương này sẽ giới thiệu các phương pháp kiểm thử khác nhau cùng giải thích. Chúng có thể sẽ được nhóm lại dựa theo bộ tiêu chí nhất định và một phương pháp có thể thuộc về nhiều nhóm. Mỗi nhóm sẽ có những lợi thế và bất lợi nhất định mà người kiểm thử phải xem xét và đánh giá kĩ nhằm tận dụng chúng tốt nhất có thể.
Đầu tiên, phân loại theo cách nhìn của người thực thi kiểm thử, các phương pháp kiểm thử sẽ được chia làm hai loại chính là hộp trắng và hộp đen [15], ngoài ra còn có thêm hộp xám [16]. Thiết kết theo phương pháp hộp trắng cần có hiểu biết bên trong, cách hệ thống hoạt động. Ngược lại, thiết kế kiểm thử theo phương pháp nhóm hộp đen sẽ đánh giá tính năng của hệ thống mà không có hiểu biết gì về cách hoạt động bên trong hay mã triển khai. Hộp xám là phương pháp kết hợp khi hiểu biết về phần mềm được dùng để thiết kế các trường hợp kiểm thử còn việc thực hiện kiểm thử lại ở mức độ người dùng.
Tiếp tục, các phương pháp kiểm thử còn được phân chia theo mức độ. Thấp nhất là kiểm thử đơn vị [17] mà theo đó từng phần mã nguồn riêng rẽ cùng với dữ liệu đi kèm, thủ tục sử dụng và vận hành được kiểm thử để xác định là chúng hoạt động đúng. Những bài kiểm thử này chủ yếu viết bởi người lập trình viên sau khi hoặc thậm chí trước cả khi bắt đầu viết mã nguồn phần mềm [18] nhằm khuyến khích việc thiết kế kiến trúc phần mềm đơn giản hơn. Kiểm thử hộp trắng cũng liên quan trực tiếp tới mức độ kiểm thử này vì sự tương đồng về trong tính chất.
Mức độ thứ hai là kiểm thử kết hợp [19] là kiểm thử sự kết nối giữa các thành phần, tương tác tới các phần khác nhau trong một hệ thống đang vận hành. Tiếp theo là kiểm thử hệ thống đề cập tới hành vi của hệ thống được định nghĩa bởi phạm vi phát triển phần mềm [19]. Cuối cùng là kiểm thử chấp nhận, được thực hiện từ phía khách hàng cũng tại chính môi trường mà nó sẽ được vận hành. Trong đó, các trường hợp kiểm thử cũng sẽ chỉ gồm những điểm quan trọng từ điểm nhìn của khách hàng.
13 Các kĩ thuật kiểm thử còn có thể được chia theo công cụ, phần mềm hỗ trợ. Kiểm thử thủ công là các trường hợp việc kiểm thử được thực hiện mà không có sự hỗ trợ của phần mềm tự động nào. Người kiểm thử sẽ đi qua tất cả các bước trong kế hoạch kiểm thử để đảm bảo tất cả các chức năng của hệ thống có kết quả đúng theo yêu cầu. Các công đoạn này đều có thể được tự động hóa bằng phần mềm.
Tức là, một phần mềm tự động được điều khiển để thực hiện theo trường hợp kiểm thử và so sánh với kết quả đã định sẵn [20]. Các cách nhìn khác nhau về phân loại kiểm thử đều có thể được kết hợp lại và trong các công ty phần mềm ngày nay, nhiều phương án kiểm thử khác nhau đang được dùng để đảm bảo chất lượng. Và xu hướng hiện nay đó là đơn giản hóa việc kiểm thử tự động để làm đòn bẩy cho việc đầu tư vào kiểm thử thủ công.2 Kiểm thử tự động Kiểm thử phần mềm về bản chất là sự lặp đi lặp lại. Một danh sách các bước cần thực hiện, kiểm tra đầu ra, đưa hệ thống về trạng thái ban đầu và thực hiện lại các bước từ đầu.
Các nhân viên kiểm thử cùng triển khai trên một hệ thống, làm các bước giống hoặc gần giống nhau. Như vậy, kiểm thử là một hoạt động tương đối chậm và tốn kém. Sự thiếu khách quan của người kiểm thử có thể ảnh hưởng tới các bước quan trọng trong quy trình kiểm thử. Tuy nhiên, trong kiểm thử tự động, những điểm vừa liệt kê khó có thể xảy ra Tăng năng suất: Lý tưởng mà nói, một bộ trường hợp kiểm thử tự động nên được chạy mà không có sự can thiệp của con người.
Như vậy sẽ tiết kiệm được rất nhiều tài nguyên khi để việc kiểm thử chạy tự động ban đêm không cần người giám sát [21]. Kiểm thử tự động có thể làm ngắn lại vòng đời phát hành sản phẩm. Những lỗi do thay đổi trong hệ thống sẽ sớm được phát hiện sớm trong quy trình phát triển phần mềm, tiết kiệm công sức và tiền bạc [22] Hơn nữa, kiểm thử tự động có thể xử lí lượng lớn dữ liệu so với kiểm thử thủ 14 công, ví dụ cần kiểm thử trên bộ dữ liệu gồm hàng ngàn bản ghi sẽ gặp khó khăn nếu làm thủ công trong khi khá là đơn giản nếu thực hiện tự động. Tăng độ tin cậy: thể hiện ở việc kiểm thử tự động được chạy chính xác giống hệt nhau mỗi lần thực hiện.
Một hoạt động kiểm thử thủ công chắc chắc khó tránh khỏi các lỗi ở con người, nhất là ở các trường hợp lặp đi lặp lại, cần chuẩn bị nhiều, hoặc cần chú ý tới các bước phụ, nhỏ, chi tiết. Hơn nữa, việc để kiểm thử chạy tự động giải thoát người kĩ sư khỏi những việc lặp đi lặp lại mà tập trung hơn vào nghiên cứu hệ thống, thiết kế kế hoạch kiểm thử hiệu quả hơn [22]. Tăng độ bao phủ: Kiểm thử tự động chạy rất tương đối nhanh. Nhiều trường hợp kiểm thử được thực thi trong thời gian ngắn hơn sẽ dẫn đến việc có thể chạy nhiều trường hợp kiểm thử hơn, độ bao phủ phần mềm cao hơn.2 Bài toán tối ưu trong kiểm thử phần mềm Kiểm thử hồi quy chiếm 80% ngân sách kiểm thử [23].
Việc thực hiện yêu cầu thay đổi mới, kiểm tra lại phần mềm, sửa lỗi nhanh là phần quan trọng của kiểm thử hồi quy. Kiểm thử hồi quy mất rất nhiều thời gian cùng tài nguyên bị bó buộc và thường xuyên lặp đi lặp lại. Kiểm thử hồi quy thời gian thực bị hạn chế lớn về thời gian vì môi trường mô phỏng của chúng rất khắt khe và lưu trữ nhiều dự án. Kiểm thử lại toàn bộ, Chọn kiểm thử hồi quy (Regression Test Selection - RTS), Giảm thiểu bộ test (Test Suite Minimization - TSM) và Ưu tiên trường hợp kiểm thử (Test Case Prioritization - TCP) là các kỹ thuật kiểm thử hồi quy chiếm ưu thế.
Mỗi một trong các phương pháp này đều có những ưu điểm và nhược điểm riêng. Chiến lược Kiểm thử lại toàn bộ tốt khi bộ kiểm thử nhỏ. Tuy nhiên, khi bộ kiểm thử tăng quy mô, cần thiết có một cơ chế để sắp xếp chúng. Trong nghiên cứu đề cập từ [9] có trình bày về một số công nghệ chọn kiểm thử hồi quy.
Kỹ thuật chọn kiểm thử hồi quy an toàn chọn từng trường hợp kiểm thử tìm ra ít nhất một lỗi nhưng vẫn không đảm bảo lựa chọn thực sự an toàn vì các tiêu chí lấy sự an toàn là then chốt không phải lúc nào cũng được thực hiện [24]. Kỹ thuật lựa chọn trường hợp kiểm thử 15 không an toàn loại bỏ một số trường hợp kiểm thử, [25] đã chỉ ra rằng Giảm thiểu bộ kiểm thử (TSM) cho thấy mức giảm rất nhỏ (2% -7%) trong tỷ lệ phát hiện lỗi. Ưu tiên trường hợp kiểm thử (TCP) khắc phục những nhược điểm của cơ chế chọn hoặc giảm bằng cách không loại bỏ các trường hợp kiểm thử. Theo TCP, các trường hợp kiểm thử có mức độ ưu tiên cao hơn sẽ được thực hiện sớm hơn trong khi tiến hành kiểm thử.
Nếu được thực thi, TCP sẽ tiết kiệm thời gian và chi phí và sẽ không trở thành chi phí. Ưu tiên trường hợp kiểm thử có thể có hai loại – ưu tiên trường hợp kiểm thử chung và ưu tiên trường hợp kiểm thử cụ thể theo phiên bản. Trong ưu tiên trường hợp kiểm thử chung, sắp xếp thứ tự ưu tiên hữu ích đối với các phiên bản sửa đổi liên tiếp của một chương trình. Tuy nhiên, đối với ưu tiên trường hợp kiểm thử cụ thể, sắp xếp thứ tự chỉ có lợi cho một phiên bản cụ thể.
Juristo [26] gọi Ưu tiên trường hợp kiểm thử là một cải tiến trong kiểm thử vì nó có thể được liên kết với bất kỳ công nghệ nào khác để tăng tỷ lệ phát hiện lỗi. Trong Ưu tiên trường hợp kiểm thử, các trường hợp kiểm thử được sắp xếp dựa trên một số tiêu chí. Mục tiêu của ưu tiên trường hợp kiểm thử có thể đa dạng. Nó giống như tăng tỷ lệ phát hiện lỗi hoặc tăng việc nắm bắt các yêu cầu ưu tiên cao hoặc giảm chi phí và thời gian của cơ chế ưu tiên.