Kiểm thử tích hợp hệ thống là gì?
Kiểm thử tích hợp hệ thống được định nghĩa là một loại kiểm thử phần mềm được thực hiện trong môi trường phần cứng và phần mềm tích hợp để xác minh hoạt động của hệ thống hoàn chỉnh. Đây là thử nghiệm được thực hiện trên một hệ thống tích hợp, hoàn chỉnh để đánh giá sự tuân thủ của hệ thống với yêu cầu cụ thể của nó.
Kiểm thử tích hợp hệ thống (SIT) được thực hiện để xác minh các tương tác giữa các mô-đun của hệ thống phần mềm. Nó đề cập đến việc xác minh các yêu cầu phần mềm cấp cao và cấp thấp được chỉ định trong Đặc tả / Dữ liệu Yêu cầu Phần mềm và Tài liệu Thiết kế Phần mềm.
Nó cũng xác minh sự tồn tại của một hệ thống phần mềm với những người khác và kiểm tra giao diện giữa các mô-đun của ứng dụng phần mềm. Trong loại thử nghiệm này, đầu tiên các mô-đun được thử nghiệm riêng lẻ và sau đó được kết hợp để tạo thành một hệ thống.
Ví dụ, các thành phần phần mềm và / hoặc phần cứng được kết hợp và kiểm tra dần dần cho đến khi toàn bộ hệ thống được tích hợp.
Trong hướng dẫn này, bạn sẽ học-
- Kiểm thử tích hợp hệ thống là gì?
- Tại sao phải kiểm tra tích hợp hệ thống
- Cách thực hiện kiểm tra tích hợp hệ thống
- Tiêu chí vào và ra để kiểm tra tích hợp
- Kiểm tra tích hợp phần cứng với phần mềm
- Kiểm tra tích hợp phần mềm đến phần mềm
- Phương pháp tiếp cận từ trên xuống
- Phương pháp tiếp cận từ dưới lên
- Cách tiếp cận Big Bang
Tại sao phải kiểm tra tích hợp hệ thống
Trong Kỹ thuật Phần mềm, Kiểm tra Tích hợp Hệ thống được thực hiện bởi vì,
- Nó giúp phát hiện sớm các khiếm khuyết
- Phản hồi trước đó về khả năng chấp nhận của từng mô-đun sẽ có sẵn
- Lập lịch cho các bản sửa lỗi rất linh hoạt và nó có thể bị chồng chéo với quá trình phát triển
- Dòng dữ liệu chính xác
- Dòng điều khiển chính xác
- Thời gian chính xác
- Sử dụng bộ nhớ chính xác
- Đúng với yêu cầu phần mềm
Cách thực hiện kiểm tra tích hợp hệ thống
Đó là một kỹ thuật có hệ thống để xây dựng cấu trúc chương trình trong khi tiến hành kiểm tra để phát hiện ra các lỗi liên quan đến giao diện.
Tất cả các mô-đun đều được tích hợp trước và toàn bộ chương trình được kiểm tra tổng thể. Nhưng trong quá trình này, một số lỗi có thể gặp phải.
Việc sửa những lỗi như vậy rất khó vì nguyên nhân cô lập rất phức tạp do sự mở rộng lớn của toàn bộ chương trình. Khi những lỗi này được sửa chữa và khắc phục, một lỗi mới sẽ xuất hiện và quá trình tiếp tục liền mạch trong một vòng lặp vô tận . Để tránh tình trạng này, một cách tiếp cận khác được sử dụng, Tích hợp gia tăng. Chúng ta sẽ xem chi tiết hơn về cách tiếp cận gia tăng ở phần sau của hướng dẫn.
Có một số phương pháp gia tăng như các bài kiểm tra tích hợp được thực hiện trên một hệ thống dựa trên bộ xử lý đích. Phương pháp được sử dụng là Kiểm tra hộp đen. Có thể sử dụng tích hợp từ dưới lên hoặc từ trên xuống.
Các trường hợp kiểm thử chỉ được xác định bằng cách sử dụng các yêu cầu phần mềm cấp cao.
Tích hợp phần mềm cũng có thể đạt được phần lớn trong môi trường máy chủ, với các đơn vị cụ thể cho môi trường mục tiêu tiếp tục được mô phỏng trong máy chủ. Việc lặp lại các thử nghiệm trong môi trường đích để xác nhận một lần nữa sẽ là cần thiết.
Kiểm tra xác nhận ở cấp độ này sẽ xác định các vấn đề về môi trường cụ thể, chẳng hạn như lỗi trong cấp phát bộ nhớ và hủy cấp phát. Tính thực tiễn của việc tiến hành tích hợp phần mềm trong môi trường máy chủ sẽ phụ thuộc vào mức độ chức năng mục tiêu cụ thể ở đó. Đối với một số hệ thống nhúng, việc kết hợp với môi trường đích sẽ rất mạnh, khiến việc tiến hành tích hợp phần mềm trong môi trường chủ là không thực tế.
Sự phát triển phần mềm lớn sẽ phân chia tích hợp phần mềm thành một số cấp độ. Các mức độ tích hợp phần mềm thấp hơn có thể chủ yếu dựa vào môi trường máy chủ, với các mức độ tích hợp phần mềm sau này sẽ phụ thuộc nhiều hơn vào môi trường đích.
Lưu ý: Nếu chỉ phần mềm đang được kiểm tra thì nó được gọi là Kiểm thử tích hợp phần mềm phần mềm [SSIT] và nếu cả phần cứng và phần mềm đang được kiểm tra, thì nó được gọi là Kiểm tra tích hợp phần mềm phần cứng [HSIT].
Tiêu chí vào và ra để kiểm tra tích hợp
Thông thường trong khi thực hiện Kiểm tra tích hợp, chiến lược ETVX (Tiêu chí mục nhập, Tác vụ, Xác thực và Tiêu chí thoát) được sử dụng.
Tiêu chuẩn nhập cảnh:
- Hoàn thành Kiểm tra Đơn vị
Đầu vào:
- Dữ liệu yêu cầu phần mềm
- Tài liệu thiết kế phần mềm
- Kế hoạch xác minh phần mềm
- Tài liệu tích hợp phần mềm
Các hoạt động:
- Dựa trên các yêu cầu Cấp cao và Cấp thấp, tạo các trường hợp và thủ tục thử nghiệm
- Kết hợp các bản dựng mô-đun cấp thấp triển khai một chức năng chung
- Phát triển một bộ khai thác thử nghiệm
- Kiểm tra bản dựng
- Sau khi kiểm tra được thông qua, bản dựng được kết hợp với các bản dựng khác và được kiểm tra cho đến khi hệ thống được tích hợp toàn bộ.
- Thực hiện lại tất cả các bài kiểm tra trên nền tảng dựa trên bộ xử lý mục tiêu và thu được kết quả
Tiêu chí thoát:
- Hoàn thành thành công việc tích hợp mô-đun Phần mềm trên Phần cứng mục tiêu
- Hiệu suất chính xác của phần mềm theo các yêu cầu được chỉ định
Kết quả đầu ra
- Báo cáo kiểm tra tích hợp
- Các trường hợp và thủ tục kiểm tra phần mềm [SVCP].
Kiểm tra tích hợp phần cứng phần cứng
Kiểm thử tích hợp phần cứng phần cứng là một quá trình kiểm tra các thành phần phần mềm máy tính (CSC) cho các chức năng cấp cao trên môi trường phần cứng đích. Mục tiêu của kiểm thử tích hợp phần cứng / phần mềm là kiểm tra hành vi của phần mềm đã phát triển được tích hợp trên thành phần phần cứng.
Kiểm tra tích hợp phần cứng-phần mềm dựa trên yêu cầu
Mục đích của kiểm tra tích hợp phần cứng / phần mềm dựa trên yêu cầu là để đảm bảo rằng phần mềm trong máy tính mục tiêu sẽ thỏa mãn các yêu cầu cấp cao. Các lỗi điển hình được phát hiện bởi phương pháp kiểm tra này bao gồm:
- Lỗi giao diện phần cứng / phần mềm
- Vi phạm phân vùng phần mềm.
- Không có khả năng phát hiện lỗi bằng kiểm tra tích hợp
- Phản hồi không chính xác đối với lỗi phần cứng
- Lỗi do trình tự, tải đầu vào tạm thời và quá độ nguồn đầu vào
- Phản hồi lặp lại hành vi không chính xác
- Kiểm soát không chính xác hoặc không thích hợp phần cứng quản lý bộ nhớ
- Vấn đề tranh chấp xe buýt dữ liệu
- Hoạt động không chính xác của cơ chế xác minh tính tương thích và tính đúng đắn của phần mềm có thể tải tại hiện trường
Tích hợp phần cứng phần mềm liên quan đến việc xác minh các yêu cầu cấp cao. Tất cả các bài kiểm tra ở cấp độ này đều được thực hiện trên phần cứng đích.
- Kiểm thử hộp đen là phương pháp kiểm tra chính được sử dụng ở cấp độ kiểm tra này.
- Chỉ xác định các trường hợp kiểm thử từ các yêu cầu cấp cao
- Một bài kiểm tra phải được thực hiện trên phần cứng tiêu chuẩn sản xuất (trên mục tiêu)
Những điều cần cân nhắc khi thiết kế các trường hợp kiểm thử cho Tích hợp HW / SW
- Thu thập chính xác tất cả dữ liệu bằng phần mềm
- Chia tỷ lệ và phạm vi dữ liệu như mong đợi từ phần cứng đến phần mềm
- Đầu ra chính xác của dữ liệu từ phần mềm đến phần cứng
- Dữ liệu trong thông số kỹ thuật (phạm vi bình thường)
- Dữ liệu bên ngoài thông số kỹ thuật (phạm vi bất thường)
- Dữ liệu ranh giới
- Làm gián đoạn quá trình xử lý
- Thời gian
- Sử dụng bộ nhớ chính xác (định địa chỉ, chồng chéo, v.v.)
- Chuyển đổi trạng thái
Lưu ý: Đối với kiểm tra ngắt, tất cả các ngắt sẽ được xác minh độc lập với yêu cầu ban đầu thông qua bảo dưỡng đầy đủ và sau khi hoàn thành. Các trường hợp kiểm thử sẽ được thiết kế đặc biệt để kiểm tra đầy đủ các ngắt.
Kiểm tra tích hợp phần mềm đến phần mềm
Đây là quá trình kiểm tra Thành phần phần mềm máy tính hoạt động trong máy chủ / máy tính đích
Môi trường, trong khi mô phỏng toàn bộ hệ thống [các CSC khác] và trên chức năng cấp cao.
Nó tập trung vào hành vi của một CSC trong môi trường máy chủ / đích được mô phỏng. Cách tiếp cận được sử dụng cho Tích hợp phần mềm có thể là cách tiếp cận gia tăng (từ trên xuống, từ dưới lên hoặc kết hợp cả hai).
Cách tiếp cận gia tăng
Kiểm thử gia tăng là một cách kiểm tra tích hợp. Trong loại phương pháp thử nghiệm này, trước tiên bạn kiểm tra từng mô-đun của phần mềm riêng lẻ và sau đó tiếp tục kiểm tra bằng cách nối các mô-đun khác vào nó rồi đến mô-đun khác, v.v.
Tích hợp gia tăng là sự tương phản với cách tiếp cận vụ nổ lớn. Chương trình được xây dựng và thử nghiệm trong các phân đoạn nhỏ, nơi các lỗi dễ dàng hơn để cô lập và sửa chữa. Các giao diện có nhiều khả năng được kiểm tra hoàn toàn và có thể áp dụng cách tiếp cận kiểm tra có hệ thống.
Có hai loại thử nghiệm tăng dần
- Cách tiếp cận từ trên xuống
- Cách tiếp cận từ dưới lên
Phương pháp tiếp cận từ trên xuống
Trong kiểu tiếp cận này, cá nhân bắt đầu bằng cách chỉ thử nghiệm giao diện người dùng, với chức năng cơ bản được mô phỏng theo sơ khai, sau đó bạn di chuyển xuống dưới tích hợp các lớp thấp hơn và thấp hơn như thể hiện trong hình ảnh bên dưới.
- Bắt đầu với mô-đun điều khiển chính, các mô-đun được tích hợp bằng cách di chuyển xuống dưới thông qua hệ thống phân cấp điều khiển
- Các mô-đun phụ của mô-đun điều khiển chính được kết hợp vào cấu trúc theo cách thức ưu tiên chiều rộng hoặc chiều sâu.
- Tích hợp theo chiều sâu tích hợp tất cả các mô-đun trên một đường dẫn điều khiển chính của cấu trúc như được hiển thị trong sơ đồ sau:
Quá trình tích hợp mô-đun được thực hiện theo cách sau:
- Mô-đun điều khiển chính được sử dụng làm trình điều khiển thử nghiệm và các sơ khai được thay thế cho tất cả các mô-đun trực thuộc mô-đun điều khiển chính.
- Các sơ khai cấp dưới được thay thế lần lượt bằng các mô-đun thực tế tùy thuộc vào cách tiếp cận đã chọn (chiều rộng trước hoặc chiều sâu trước).
- Các bài kiểm tra được thực hiện khi mỗi mô-đun được tích hợp.
- Khi hoàn thành mỗi bộ bài kiểm tra, một phần sơ khai khác được thay thế bằng một mô-đun thực khi hoàn thành mỗi bộ bài kiểm tra
- Để đảm bảo rằng các lỗi mới chưa được đưa vào Kiểm tra hồi quy có thể được thực hiện.
Quá trình tiếp tục từ bước 2 cho đến khi toàn bộ cấu trúc chương trình được xây dựng. Chiến lược từ trên xuống nghe có vẻ tương đối đơn giản, nhưng trong thực tế, các vấn đề hậu cần lại nảy sinh.
Sự cố thường gặp nhất trong số này xảy ra khi yêu cầu xử lý ở các cấp thấp trong hệ thống phân cấp để kiểm tra các cấp trên một cách đầy đủ.
Stub thay thế các mô-đun cấp thấp khi bắt đầu kiểm tra từ trên xuống và do đó không có dữ liệu quan trọng nào có thể chảy lên trong cấu trúc chương trình.
Những thách thức mà Tester có thể gặp phải:
- Trì hoãn nhiều thử nghiệm cho đến khi các phần sơ khai được thay thế bằng các mô-đun thực tế.
- Phát triển các sơ khai thực hiện các chức năng hạn chế mô phỏng mô-đun thực tế.
- Tích hợp phần mềm từ cuối cấu trúc phân cấp trở lên.
Lưu ý: Cách tiếp cận đầu tiên khiến chúng tôi mất một số quyền kiểm soát đối với sự tương ứng giữa các thử nghiệm cụ thể và việc kết hợp các mô-đun cụ thể. Điều này có thể dẫn đến việc khó xác định nguyên nhân của các lỗi có xu hướng vi phạm tính chất hạn chế cao của phương pháp từ trên xuống.
Cách tiếp cận thứ hai là khả thi nhưng có thể dẫn đến chi phí đáng kể, vì các sơ khai ngày càng trở nên phức tạp.
Phương pháp tiếp cận từ dưới lên
Tích hợp từ dưới lên bắt đầu xây dựng và thử nghiệm với các mô-đun ở cấp thấp nhất trong cấu trúc chương trình. Trong quá trình này, các mô-đun được tích hợp từ dưới lên trên.
Trong cách tiếp cận này, quá trình xử lý yêu cầu đối với các mô-đun dưới một cấp nhất định luôn sẵn sàng và nhu cầu về các sơ khai được loại bỏ.
Quá trình kiểm tra tích hợp này được thực hiện theo một loạt bốn bước
- Các mô-đun cấp thấp được kết hợp thành các cụm thực hiện một chức năng con của phần mềm cụ thể.
- Một trình điều khiển được viết để điều phối đầu vào và đầu ra của test case.
- Cụm hoặc bản dựng được thử nghiệm.
- Trình điều khiển được loại bỏ và các cụm được kết hợp di chuyển lên trên trong cấu trúc chương trình.
Khi tích hợp tiến lên, nhu cầu về các bài học lái xe thử nghiệm riêng biệt. Trên thực tế, nếu hai cấp độ cao nhất của cấu trúc chương trình được tích hợp từ trên xuống, số lượng trình điều khiển có thể giảm đáng kể và việc tích hợp các cụm được đơn giản hóa rất nhiều. Tích hợp theo mô hình được minh họa bên dưới. Khi tích hợp tiến lên, nhu cầu về các bài học lái xe thử nghiệm riêng biệt.
Lưu ý: Nếu hai cấp độ cao nhất của cấu trúc chương trình được tích hợp Từ trên xuống, số lượng trình điều khiển có thể giảm đáng kể và việc tích hợp các bản dựng được đơn giản hóa rất nhiều.
Cách tiếp cận Big Bang
Theo cách tiếp cận này, tất cả các mô-đun không được tích hợp cho đến khi và trừ khi tất cả các mô-đun đã sẵn sàng. Khi chúng đã sẵn sàng, tất cả các mô-đun được tích hợp và sau đó nó được thực thi để biết liệu tất cả các mô-đun tích hợp có hoạt động hay không.
Trong cách tiếp cận này, rất khó để biết nguyên nhân gốc rễ của sự thất bại vì tích hợp tất cả mọi thứ cùng một lúc.
Ngoài ra, sẽ có nhiều khả năng xảy ra các lỗi nghiêm trọng trong môi trường sản xuất.
Cách tiếp cận này chỉ được áp dụng khi thử nghiệm tích hợp phải được thực hiện cùng một lúc.
Tóm lược:
- Tích hợp được thực hiện để xác minh các tương tác giữa các mô-đun của một hệ thống phần mềm. Nó giúp phát hiện sớm các khiếm khuyết
- Kiểm tra tích hợp có thể được thực hiện đối với Tích hợp Phần cứng-Phần mềm hoặc Phần cứng-Phần cứng
- Kiểm thử tích hợp được thực hiện bằng hai phương pháp
- Cách tiếp cận gia tăng
- Cách tiếp cận vụ nổ lớn
- Trong khi thực hiện Kiểm tra tích hợp, chiến lược ETVX (Tiêu chí mục nhập, Nhiệm vụ, Xác thực và Thoát) thường được sử dụng.