Làm sao để biết và thực hiện được phương pháp tích hợp kiểm thử từ trên xuống và từ dưới lên? Làm sao để thực hành kỹ thuật kiểm thử hồi quy? Làm sao lập được tài liệu kiểm thử tích hợp?
Người mới tập sự trong thế giới phần mềm có thể hỏi một câu hỏi có vẻ hợp lý khi mọi mô đun đã được kiểm thử đơn vị xong: “Nếu tất cả chúng đã làm việc riêng biệt tốt, thì sao các anh lại hoài nghi rằng chúng không làm việc khi ta gắn chúng lại với nhau?”
Vấn đề, dĩ nhiên, là ở chỗ “gần chúng lại với nhau” – làm giao diện. Dữ liệu có thể bị mất qua giao diện; mô đun này có thể có sự bất cần, ảnh hướng bất lợi sang mô đun khác; các chức năng con, khi tổ hợp, không thể tạo ra chức năng chính mong muốn; những sự không chính xác chấp nhận được ở từng mô đun có thể bị khuếch đại lên đến mức không chấp nhận nổi; các cấu trúc dữ liệu toàn cục bộ có thể làm sinh ra vấn đề. Điều đáng buồn là danh sách này còn kéo dài mãi.
Kiểm thử tích hợp là một kĩ thuật hệ thống để xây dựng cấu trúc chương trình trong khi đồng thời tiến hành các kiểm thử để phát hiện lỗi liên kết với việc giao tiếp. Mục đích là lấy các mô đun đã kiểm thử đơn vị xong và xây dựng nên một cấu trúc chương trình được quy định bởi thiết kế.
Thường có một khuynh hướng cố gắng tích hợp không tăng dần; tức là xây dựng chương trình bằng cách dùng cách tiếp cận vụ nổ lớn “Big bang”. Tất cả các mô đun đều được tổ hợp trước. Toàn bộ chương trình được kiểm thử như một tổng thể và thường sẽ là một kết quả hỗn loạn!
Gặp phải một tập hợp các lỗi. Việc sửa đổi thành khó khăn vì việc cô lập nguyên nhân bị phức tạp bởi việc trải rộng trên toàn chương trình. Khi những lỗi này đã được sửa chữa thì những lỗi mới lại xuất hiện và tiến trình này cứ tiếp diễn trong chu trình vô hạn.
Tích hợp tăng dần là ngược lại với cách tiếp cận vụ nổ lớn. Chương trình được xây dựng và kiểm thử trong từng đoạn nhỏ, nơi lỗi dễ được có lập và sửa chữa hơn, giao diện có thể được kiểm thử đầy đủ hơn và cách tiếp cận hệ thống có thể được áp dụng. Trong những mục sau đây, một số chiến lược tích hợp tăng dần sẽ được thảo luận tới.
1. Tích hợp trên xuống.
Tích hợp trên xuống là cách tiếp cận tăng dần tới việc xây dựng cấu trúc chương trình. Các mô đun được tích hợp bằng cách đi dần xuống qua cấp bậc điều khiển, bắt đầu với mô đun điều khiển chính (chương trình chính). Các mô đun phụ thuộc (và phụ thuộc cuối cùng) vào mô đun điều khiển chính sẽ được tổ hợp dẫn vào trong cấu trúc theo chiều sâu trước hoặc chiều rộng trước.
Tiến trình tích hợp được thực hiện qua năm bước:
– Mô đun điều khiển chính được dùng như một khiển trình kiểm thử, và các cuống được thế vào cho tất cả các mô đun phụ thuộc trực tiếp vào mô đun điều khiến chính.
– Tuỳ theo các tiếp cận tích hợp được chọn lựa (nhưng theo chiều sâu hay theo chiều ngang trước), các cuống phụ thuộc được thay thế từng cái một mỗi lần bằng các mô đun thực tại.
– Việc kiểm thử được tiến hành khi từng mô đun được tích hợp vào.
– Khi hoàn thành từng tập các phép kiểm thử, cuống khác sẽ được thay thế bằng các mô đun thực.
– Kiểm thử hồi quy (tức là tiến hành tất cả hay một số các phép kiếm thử trước) có thể được tiến hành để đảm bảo những lỗi mới không bị đưa thêm vào.
Tiến trình này tiếp tục từ bước hai tới khi toàn bộ cấu trúc chương trình đã được xây dựng xong. Điều quan trọng là phải chú ý tiến hành các phép kiểm thử cho mỗi lần thay thế để kiểm chứng giao diện.
Chiến lược tích hợp trên xuống kiểm chứng việc điều khiến chính hay các điểm quyết định ngay từ đấu trong tiến trình kiểm thử. Trong một cấu trúc chương trình bố trí khéo, việc quyết định thường xuất hiện tại các mức trên trong cấp bậc và do đó được gặp phải trước. Nếu các vấn đề điều khiển chính quả là tồn tại thì việc nhận ra chúng là điều chủ chốt. Nếu việc tích hợp theo độ sâu được lựa chọn thì chức năng đầy đủ của phần mềm có thể được cài đặt và chứng minh.
Chẳng hạn, ta hãy xét một cấu trúc giao tác cổ điển trong đó cần tới một loạt các đầu vào trường tác phức tạp, rồi thu nhận và kiểm chứng chúng qua đường đi tới. Đường đi tới có thể được tích hợp theo cách trên xuống. Tất cả xử lý đầu vào (đối với việc phát tán giao tác về sau) có thể được biểu diễn trước khi các phần tử khác của cấu trúc được tích hợp vào. Việc biểu diễn ban đầu về khả năng chức năng là cách xây dựng niềm tin cho cả người phát triển và khách hàng.
Chiến lược phát triển trên xuống có vẻ như không phức tạp nhưng trong thực tế, các vấn đề logic có thể nảy sinh. Điều thông thường nhất của những vấn đề này xuất hiện khi việc xử lý tại mức thấp trong các mức đòi hỏi việc kiểm thử tích hợp ở mức trên. Cuống thay thế cho các mô đun cấp thấp vào lúc bắt đầu của kiếm thử trên xuống; do đó không có dữ liệu nào có nghĩa có thể chảy ngược lên trong cấu trúc chương trình.
Người kiểm thử đứng trước hai chọn lựa: (1) để trễ nhiều việc kiểm thử tới khi cuống được thay thế bằng mô đun thực thế, (2) xây dựng các cuống thực hiện những chức năng giới hạn mô phỏng cho mô đun thực tại và (3) tích hợp phần mềm từ mức đáy lên.
Cách tiếp cận thứ nhất (để trễ kiểm thử cho đến khi cuống được thay thế bởi mô đun thực tại) gây cho chúng ta bị mất điều khiển đối với tương ứng giữa kiểm thử đặc biệt và việc tổ hợp các mô đun đặc biệt. Điều này có thể dẫn tới những khó khăn trong việc xác định nguyên nhân lỗi, và có khuynh hướng vi phạm bản chất bị ràng buộc cao độ của cách tiếp cận trên xuống. Các tiếp cận thứ hai thì được, nhưng có thể dẫn tới tổng phí khá lớn, vì cuống càng ngày càng trở thành phức tạp hơn. Cách tiếp cận thứ ba, được gọi là kiểm thử dưới lên, được thảo luận trong mục sau.
2. Tích hợp từ dưới lên.
Kiểm thử tích hợp dưới lên, như tên nó đã hàm ý, bắt đầu xây dựng và kiểm thử với các mô đun nguyên tử (tức là các mô đun ở mức thấp nhất trong cấu trúc chương trình). Vì các mô đun này được tích hợp từ dưới lên trên nên việc xử lý yêu cầu đối với các mô đun phụ thuộc của một mức nào đó bao giờ cũng có sẵn, và nhu cầu về cuống bị dẹp bỏ.
Chiến lược tích hợp dưới lên có thể được thực hiện qua những bước sau:
– Các mô đun mức thấp được tổ hợp vào các chùm (đôi khi cũng còn được gọi là kiểu kiến trúc) thực hiện cho một chức năng của phần mềm đặc biệt.
– Trình điều khiển (một chương trình điều khiển cho kiểm thử) được viết ra để phối hợp vào trường hợp kiểm thử.
– Kiểm thử chùm.
– Loại bỏ Trình điều khiển và chùm được tổ hợp chuyển lên trong cấu trúc chương trình.
Khi việc tích hợp đi lên, nhu cầu về các trình điều khiển kiểm thử tách biệt ít dần. Trong thực tế, nếu hai mức đỉnh của cấu trúc chương trình được tích hợp theo kiểu trên xuống, thì số các tiến trình có thể được giảm bớt khá nhiều và việc tích hợp các chùm được đơn giản hơn rất nhiều.
3. Kiểm thử hồi quy.
Mỗi một lần một mô đun mới được thêm vào như là một phần của kiểm thử tích hợp, phần mềm thay đổi. Các đường dẫn dữ liệu mới được thiết lập, vào ra mới cũng xãy ra và logic điều khiển mới được gọi ra. Những thay đổi này có thể sinh ra vấn đề đối với các hàm đã làm việc hoàn hảo trước đó.
Trong một ngữ cảnh của một chiến lược kiểm thử phần mềm, kiểm thử hồi quy là việc thực hiện lại một vài tập hợp con các kiểm thử, mà đã được quản lý để đảm bảo những thay đổi đó không sinh ra các hiệu ứng phụ không kiểm soát được.
Trong một ngữ cảnh rộng như vậy, kiểm thử thành công (bất cứ loại nào) kết quả là tìm ra các lỗi và các lỗi phải được làm đúng. Một khi phần mềm đã được làm đúng, một vài bộ phận của cấu hình phần mềm (chương trình, các tài liệu của nó, dữ liệu hỗ trợ nó) bị thay đổi.
Kiểm thử hồi quy là hoạt động giúp đảm bảo rằng những thay đổi (trong toàn bộ quá trình kiểm thử hoặc các lý do khác) không dẫn tới các cách thức không lường trước hoặc các lỗi phát sinh thêm.
Kiểm thử hồi quy có thể thực hiện bằng thao tác bằng tay bằng cách thực hiện lại một tập hợp con của tất cả các trường hợp kiểm tra hoặc sử dụng các công cụ bắt lỗi tự động. Các công cụ bắt lỗi trở lại (capture – playback tools) cho phép người kỹ sư phần mềm có thể bắt được các trường hợp kiểm tra, và kết quả cho một chuỗi lỗi và so sánh trở lại. Bộ kiểm thử hồi quy bao gồm ba lớp các trường hợp kiểm thử khác nhau:
– Một là biểu diễn ví dụ của các trường hợp kiểm thử mà nó sẽ thực hiện với tất cả các chức năng của phần mềm.
– Thêm vào các kiểm thử ứng với các chức năng của phần mềm giống như là giả định khi thay đổi.
– Các trường hợp kiểm thử ứng với các thành phần của phần mềm đã bị thay đổi.
Giống như tiến trình kiểm thử tích hợp, số các kiểm thử hồi quy có thể tăng lên khá lớn. Vì thế bộ kiểm thử hồi quy nên được thiết kế để chỉ bao gồm các trường hợp kiểm thử mà nhằm vào một hay nhiều các lớp của lỗi trong mỗi chức năng chương trình chính. Rõ ràng là không thực tế và không hiệu quả để thực hiện lại tất cả các kiểm thử cho mọi chức năng của chương trình mỗi khi có sự thay đổi xảy ra.
4. Gợi ý về việc kiểm thử tích hợp.
Đã có nhiều thảo luận về ưu và nhược điểm tương đối của việc kiểm thử tích hợp trên xuống và dưới lên. Nói chung, ưu điểm của chiến lược này có khuynh hướng thành nhược điểm của chiến lược kia. Nhược điểm chính của cách tiếp cận trên xuống là cần tới các cuống và có thể có những khó khăn kiểm thử kèm theo liên kết với chúng.
Vấn đề liên quan tới các cuống có thể bù đắp lại bằng ưu điểm của việc kiểm thử các chức năng điều khiển chính sớm hơn. Nhược điểm chính của việc tích hợp dưới lên là ở chỗ “chương trình như một thực thể thì chưa tồn tại chừng nào mô đun cuối cùng chưa được thêm vào”. Nhược điểm này được làm dịu đi bằng thiết kế trường hợp kiểm thử sớm hơn và việc thiếu cuống.
Sự lựa chọn một chiến lược tích hợp phụ thuộc vào các đặc trưng phần mềm, và đôi khi cả lịch biểu dự án. Nói chung, một cách tiếp cận tổ hợp (đôi khi còn được gọi là kiểm thử bánh kẹp thịt) dùng chiến lược trên xuống cho các mức trên của cấu trúc chương trình, đi đôi với chiến lược dưới lên có các mức phụ thuộc, có thể là sự thỏa hiệp tốt nhất.
Khi việc kiểm thử tích hợp được tiến hành, người kiểm thử phải xác định mô đun găng. Một mô đun găng có duy nhất một hay nhiều đặc trưng sau: (1) đề cập tới nhiều yêu cầu phần mềm, (2) có mức điều khiển cao (nằm ở vị trí tương đối cao trong cấu trúc chương trình), (3) là phức tạp hay dễ sinh lỗi (độ phức tạp xoay vòng có thể được dùng làm một chỉ bảo) hay (4) có yêu cầu độ hoàn thiện xác định. Các mô đun găng nên được kiểm thử sớm nhất có thể được. Bên cạnh đó, kiểm thử hồi quy nên tập trung vào chức năng mô đun găng.
5. Lập tài liệu về kiểm thử tích hợp.
Kế hoạch tổng thể cho việc tích hợp phần mềm và một mô tả về các kiếm thử đặc biệt được ghi trong bản Đặc tả kiểm thử. Bản Đặc tả kiểm thử này có thể bàn giao được trong tiến trình kỹ nghệ phần mềm và trở thành một phần của cấu hình phần mềm.
Phạm vi kiểm thử tóm tắt các đặc trưng chức năng, sự hoàn thiện và thiết kế bên trong, cần phải được kiểm thử. Nỗ lực kiểm thử cần gắn kèm, tiêu chuẩn để hoàn tất từng giai đoạn kiểm thử cần được mô tả và các ràng buộc lịch biểu cần được làm tư liệu.
Phần kế hoạch kiểm thử mô tả chiến lược chung cho việc tích hợp. Việc kiểm thử được chia thành các giai đoạn và khối, đề cập tới các đặc trưng hành vi và chức năng riêng của phần mềm. Chẳng hạn, kiểm thử tích hợp cho một hệ thống CAD hướng đồ thị có thể được chia thành các giai đoạn kiểm thử sau:
– Giao diện người dùng (chọn chỉ lệnh; tạo ra việc vẽ; biểu diễn hiển thị; xử lý lỗi và biểu diễn lỗi).
– Thao tác và phân tích dữ liệu (tạo ra ký hiệu; tầm hướng; quay; tính các tính chất vật lý).
– Xử lý và sinh hiển thị (hiển thị hai chiều, …).
– Quản trị cơ sở dữ liệu (thâm nhập; cập nhật; toàn vẹn; hiệu năng).
Mỗi một trong các giai đoạn và giai đoạn con (được ghi trong dấu ngoặc tròn) đều nêu ra phạm trù chức năng rộng bên trong phần mềm và nói chung có thể có liên quan tới một lĩnh vực riêng của cấu trúc chương trình. Do đó, các khối chương trình (nhóm các mô đun) được tạo ra để tương ứng với từng giai đoạn.
Các tiêu chuẩn sau đây và phép kiểm thử tương ứng được áp dụng cho tất cả các giai đoạn kiểm thử:
– Tính thống nhất giao diện: Các giao diện bên trong và bên ngoài được kiểm thử khi từng mô đun (hay chùm) được tổ hợp vào trong cấu trúc.
– Hợp lệ chức năng: Tiến hành các kiểm thử đã được thiết kế để phát hiện ra lỗi chức năng.
– Nội dung thông tin: Tiến hành các kiểm thử đã được thiết kế để phát hiện ra lỗi liên kết với các cấu trúc dữ liệu cục bộ hay toàn cục được sử dụng.
– Sự hoàn thiện: Tiến hành kiểm thử đã được thiết kế để kiểm chứng các cặn hoàn thiện đã được thiết lập trong thiết kế phần mềm.
Những tiêu chuẩn này và các kiểm thử liên kết với chúng được thảo luận trong mục bản Đặc tả kiểm thử.
Lịch biểu để tích hợp, tổng phí phần mềm và các chủ thể có liên quan cũng được thảo luận như một phần của mục kế hoạch kiểm thử. Ngày tháng bắt đầu và kết thúc cho từng giai đoạn được thiết lập và “cửa sổ có sẵn” cho các mô đun đã xong kiểm thử đơn vị cũng phải được xác định.
Một mô tả tóm tắt về tổng phí phần mềm (cuống và khiển trình) tập trung vào các đặc trưng có thể yêu cầu nỗ lực đặc biệt. Cuối cùng, cũng phải mô tả môi trường và tài nguyên kiểm thử. Các cấu hình phần cứng bất thường, các bộ mô phỏng ngoại lai, các công cụ kỹ thuật kiểm thử, đặc biệt là một số trong nhiều chủ để có thể được thảo luận trong mục này.
Một thủ tục kiểm thử chi tiết cần tới để hoàn thành bản kế hoạch kiểm thử sẽ được mô tả trong mục thủ tục kiểm thử. Trật tự của việc tích hợp và các phép kiểm tử tương ứng tại mỗi bước tích hợp phải được mô tả. Một danh sách tất cả các trường hợp kiểm thử (có thể để tham khảo về sau) và kết quả dự kiến cũng nên được đưa vào.
Lịch sử các kết quả kiểm thử thực tại, các vấn đề, hay các đặc thù được ghi lại trong bốn mục của bản Đặc tả kiểm thử. Thông tin có trong mục này có thể rất quan trọng cho việc bảo trì phần mềm. Các tham khảo thích hợp các phụ lục cũng được trình bày trong hai mục cuối.
Giống như tất cả các phần tử khác của cấu hình phần mềm định dạng căn bản, công nghệ Đặc tả kiểm thử có thể được tổ chức theo nhu cầu cục bộ của tổ chức phát triển phần mềm. Tuy nhiên điều quan trọng cần lưu ý là một chiến lược tích hợp có trong bản Kế hoạch kiểm thử, và các chi tiết kiểm thử được mô tả trong bản Đặc tả kiểm thử là thành phần bản chất và phải có.
6. Các ví dụ về kiểm thử tích hợp.
Dưới đây là một số ví dụ thực tế về các loại kiểm thử tích hợp:
– Integration Testing (Kiểm thử tích hợp): Trong một ứng dụng thương mại điện tử, kiểm thử tích hợp có thể bao gồm kiểm tra cách mà module quản lý kho hàng và module giỏ hàng tương tác với nhau để đảm bảo dữ liệu được truyền đúng cách và không có lỗi trong quá trình giao dịch. Số liệu: Trong quá trình kiểm thử, 98% của 10,000 giao dịch thử nghiệm đã thành công, chỉ có 2% gặp lỗi.
– Bottom-Up Integration Testing (Kiểm thử từ dưới lên): Khi phát triển một hệ thống quản lý kho hàng, các module như quản lý kho, nhập hàng, xuất hàng được kiểm thử đầu tiên. Sau đó, các module này được tích hợp và kiểm thử để đảm bảo chúng hoạt động cùng nhau một cách chính xác. Số liệu: Các module cơ bản đã qua 500 lượt kiểm thử, với tỷ lệ thành công 99%. Khi tích hợp toàn hệ thống, tỷ lệ thành công của các chức năng tăng lên 97%.
– Top-Down Integration Testing (Kiểm thử từ trên xuống): Trong việc phát triển một hệ thống quản lý email, module chính như giao diện người dùng và quản lý email được kiểm thử đầu tiên. Sau đó, các module cấp thấp như lưu trữ email và gửi email được tích hợp và kiểm thử. Số liệu: 1,000 phiên kiểm thử giao diện người dùng cho thấy 95% thành công, khi tích hợp các module cấp thấp, tỷ lệ thành công giảm nhẹ xuống còn 93%.
– Big Bang Integration Testing (Kiểm thử toàn bộ): Khi phát triển một hệ thống quản lý học tập, tất cả các module như quản lý sinh viên, lớp học, và kết quả học được tích hợp cùng một lúc và kiểm thử một cách toàn diện để đảm bảo hệ thống hoạt động đúng như mong đợi. Số liệu: 5,000 lượt kiểm thử cho thấy 90% các chức năng hoạt động chính xác ngay lần đầu tiên, tuy nhiên 10% lỗi phát sinh đã gây ra thời gian sửa chữa kéo dài hơn dự kiến.
Những ví dụ này không chỉ minh họa các phương pháp kiểm thử mà còn cung cấp số liệu để giúp bạn hình dung rõ hơn về hiệu quả và thách thức của từng phương pháp. Hy vọng những ví dụ này giúp bạn hiểu rõ hơn về các phương pháp kiểm thử tích hợp!
Tác giả: Thạc Bình Cường
Bạn đang xem bài viết:
Kiểm thử tích hợp là gì?
Link https://vnlibs.com/cong-nghe/kiem-thu-tich-hop-la-gi.html
