SIT là gì? Kiểm thử tích hợp hệ thống kèm ví dụ.

Kiểm tra tích hợp hệ thống là gì?

WELFARE Thử nghiệm hội nhập được định nghĩa là một loại thử nghiệm 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 tiến hành 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 sự tương tác giữa các mô-đun của một hệ thống phần mềm. Nó liên quan đế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 quy định trong Tài liệu đặc tả yêu cầu phần mềm/Dữ liệu và Tài liệu thiết kế phần mềm.

Kiểm thử tích hợp hệ thống (SIT) cũng xác minh khả năng tương thích của một hệ thống phần mềm với các hệ thống 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 kiểm thử này, các mô-đun được kiểm thử riêng lẻ trước, 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 thử dần dần cho đến khi toàn bộ hệ thống được tích hợp.

Sơ đồ trên thể hiện quá trình xác định SIT: các mô-đun được xác thực riêng lẻ được hợp nhất từng bước cho đến khi một hệ thống tích hợp duy nhất được kiểm thử.

Tại sao phải kiểm thử 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 Khiếm khuyết đầu
• Sẽ có phản hồi trước đó về khả năng chấp nhận của từng mô-đun riêng lẻ
• Việc lập kế hoạch sửa lỗi rất linh hoạt và có thể chồng chéo với quá trình phát triển
• Luồng dữ liệu chính xác
• Luồng điều khiển chính xác
• Đúng thời điểm
• Sử dụng bộ nhớ đúng cách
• Đúng với yêu cầu phần mềm

Kiểm thử tích hợp hệ thống so với Kiểm thử hệ thống so với Kiểm thử chấp nhận người dùng

Vì ba cấp độ này liền kề nhau nên chúng thường bị nhầm lẫn. Thử nghiệm hệ thống SIT kiểm tra một công trình hoàn thiện so với các yêu cầu của nó, SIT kiểm tra các mối nối giữa các công trình, và Kiểm tra chấp nhận người dùng Phân tích khả năng thích ứng của doanh nghiệp từ góc nhìn của khách hàng. Bảng dưới đây phân loại chúng.

Tham số	Kiểm tra tích hợp hệ thống	Thử nghiệm hệ thống	Kiểm tra chấp nhận người dùng
Tiêu điểm chính	Giao diện và luồng dữ liệu giữa các mô-đun tích hợp	Hành vi của toàn bộ cấu trúc đã được lắp ráp	Sức khỏe kinh doanh dành cho mục đích sử dụng thực tế
mức độ thử nghiệm	Cấp độ hai	Cấp độ ba	Cấp độ cuối cùng trước khi ra mắt chính thức
Kỹ thuật	Hộp đen	Hộp đen, hộp trắng hoặc hộp xám	Hộp đen
Được thực hiện bởi	Người kiểm thử tích hợp và nhà phát triển	Nhóm kiểm thử độc lập	Khách hàng hoặc người dùng cuối
Các khuyết tật điển hình	Giao diện, thời gian, bộ nhớ và sơ đồ dữ liệuping lỗi	Lỗi hệ thống chức năng và phi chức năng	Khả năng sử dụng và sự không phù hợp về yêu cầu
Chạy khi	Sau Kiểm tra đơn vị	Sau SIT	Sau khi kiểm tra hệ thống

Trình tự thực hiện rất quan trọng. Kiểm thử đơn vị (UAT) kiểm tra các mô-đun, kiểm thử tích hợp hệ thống (SIT) kiểm tra các giao diện, kiểm thử hệ thống (System Testing) kiểm tra sản phẩm đã được lắp ráp, và kiểm thử chấp nhận người dùng (UAT) xác nhận sản phẩm đáp ứng kỳ vọng của doanh nghiệp. Bỏ quaping SIT đẩy các lỗi giao diện vào UAT, nơi mà mỗi bản sửa lỗi đều tốn chi phí cao hơn nhiều.

Cách thực hiện Kiểm tra tích hợp hệ thống

Đây là một kỹ thuật có hệ thống để xây dựng cấu trúc chương trình đồng thời tiến hành các bài kiểm tra nhằm phát hiện 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, có thể gặp phải một số lỗi.

Việc sửa những lỗi như vậy là khó khăn vì nguyên nhân cách ly rất phức tạp do việc mở rộng toàn bộ chương trình. Sau khi các lỗi này được khắc phục và sửa chữa, một lỗi mới sẽ xuất hiện và quá trình này tiếp tục liền mạch trong một vòng lặp vô tận.. Để tránh tình huống này, một phương pháp khác được sử dụng, đó là Tích hợp gia tăng. Phương pháp gia tăng được giải thích chi tiết trong phần tiếp theo.

Có một số phương pháp gia tăng như kiểm tra tích hợp được tiến hành trên hệ thống dựa trên bộ xử lý đích. Phương pháp được sử dụng là Da Đen Box Kiểm tra. 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.

Việc 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ị dành riêng 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 mục tiêu để xác nhận lại là điều cần thiết.

Các bài kiểm tra xác nhận ở cấp độ này sẽ xác định các vấn đề cụ thể của môi trường, chẳng hạn như lỗi trong việc cấp phát và giải phóng bộ nhớ. Tính khả thi của việc thực hiện 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 đặc thù của hệ thống đích. Đối với một số hệ thống nhúng, sự liên kết với môi trường đích sẽ rất mạnh, khiến việc thực hiện tích hợp phần mềm trong môi trường máy chủ trở nên không khả thi.

Các phát triển phần mềm lớn sẽ chia tích hợp phần mềm thành một số cấp độ. Các cấp độ tích hợp phần mềm thấp hơn có thể chủ yếu dựa trên môi trường máy chủ, với các cấp độ tích hợp phần mềm sau này phụ thuộc nhiều hơn vào môi trường mục tiêu.

Lưu ý: Nếu chỉ kiểm thử phần mềm 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 đều đang được kiểm thử thì nó được gọi là Kiểm thử tích hợp phần mềm phần cứng [HSIT].

Cách tiếp cận gia tăng

Vì việc tích hợp mọi thứ cùng một lúc khiến việc xác định lỗi trở nên khó khăn, hầu hết các nhóm đều đi theo lộ trình từng bước như đã mô tả ở đây.

Thử nghiệm gia tăng là một cách thử nghiệm tích hợp. Trong loại phương pháp thử nghiệm này, trước tiên bạn thử nghiệm từng mô-đun của phần mềm riêng lẻ, sau đó tiếp tục thử nghiệm bằng cách thêm các mô-đun khác vào đó 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 theo từng đoạn nhỏ, ở đó các lỗi dễ dàng được tách biệt và sửa chữa hơn. Các giao diện có nhiều khả năng được kiểm tra toàn bộ hơn và có thể áp dụng phương pháp 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, mỗi cá nhân bắt đầu bằng cách chỉ kiểm tra giao diện người dùng, với chức năng cơ bản được mô phỏng bằng các phần sơ khai, sau đó bạn chuyển dần xuống dưới để tích hợp các lớp thấp hơn và thấp hơn như trong hì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 tích hợp vào cấu trúc theo 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:

1. 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 phần sơ khai được thay thế 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.
2. Các nhánh phụ đượ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 được chọn (chiều rộng trước hoặc chiều sâu trước).
3. Các thử nghiệm được thực hiện khi mỗi mô-đun được tích hợp.
4. Sau khi hoàn thành mỗi bộ bài kiểm tra, một sơ khai khác sẽ được thay thế bằng một mô-đun thực khi hoàn thành mỗi bộ bài kiểm tra
5. Để đảm bảo rằng các lỗi mới chưa được đưa ra 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 không phức tạp nhưng trên thực tế lại phát sinh các vấn đề về hậu cần.

Những vấn đề phổ biến nhất này xảy ra khi cần phải xử lý ở các mức thấp trong hệ thống phân cấp để kiểm tra đầy đủ các mức cao hơn.

Sơ khai thay thế các mô-đun cấp thấp khi bắt đầu thử nghiệm từ trên xuống và do đó không có dữ liệu quan trọng nào có thể đi lên trong cấu trúc chương trình.

Những thách thức mà người thử nghiệm có thể gặp phải:

• Trì hoãn nhiều bài kiểm tra 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 giới hạn mô phỏng mô-đun thực tế.
• Tích hợp phần mềm từ dưới cùng của hệ thống 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 đi 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 khó khăn trong việc xác định nguyên nhân sai sót có xu hướng vi phạm tính chất hạn chế cao của phương pháp tiếp cận từ trên xuống.

Cách tiếp cận thứ hai khả thi nhưng có thể dẫn đến chi phí đáng kể vì các phần gốc ngày càng phức tạp.

Cách 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 ở mức 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.

Theo cách tiếp cận này, việc xử lý yêu cầu đối với các mô-đun phụ ở một mức nhất định luôn sẵn có và nhu cầu về các phần sơ khai được loại bỏ.

Quá trình kiểm tra tích hợp này được thực hiện theo chuỗi bốn bước

1. Các mô-đun cấp thấp được kết hợp thành các cụm thực hiện chức năng phụ của phần mềm cụ thể.
2. Một trình điều khiển được viết để phối hợp đầu vào và đầu ra của trường hợp kiểm thử.
3. Cụm hoặc bản dựng đã được thử nghiệm.
4. Trình điều khiển bị loại bỏ và các cụm được kết hợp theo hướng đi lên trong cấu trúc chương trình.

Khi quá trình tích hợp tiến lên phía trên, nhu cầu về các trình điều khiển thử nghiệm riêng biệt sẽ giảm đi. 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 dưới, 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. Quá trình tích hợp tuân theo mô hình được minh họa bên dưới.

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.

Phương pháp tiếp cận vụ nổ lớn

Trong phương pháp 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 sẽ được tích hợp và sau đó đượ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.

Theo 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ì phải tích hợp 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.

Kiểm tra tích hợp phần cứng phần mềm

Kiểm tra tích hợp phần cứng phần mềm là một quá trình kiểm tra Thành phần phần mềm máy tính (CSC) để tìm các chức năng cấp cao trên môi trường phần cứng mục tiêu. Mục tiêu của thử nghiệm 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 được 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 việc 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ẽ đáp ứng các yêu cầu cấp cao. Các lỗi điển hình được phát hiện bằng phương pháp thử nghiệm 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 thể phát hiện lỗi bằng thử nghiệm tích hợp
• Phản hồi không chính xác với lỗi phần cứng
• Lỗi do trình tự, tải đầu vào nhất thời và quá độ nguồn điện đầu vào
• Vòng phản hồi hành vi không chính xác
• Kiểm soát phần cứng quản lý bộ nhớ không chính xác hoặc không đúng cách
• Vấn đề tranh chấp bus 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 chính xác của phần mềm có thể tải 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 thử nghiệm ở cấp độ này được tiến hành trên phần cứng mục tiêu.

• Kiểm thử hộp đen là phương pháp kiểm thử chính được sử dụng ở cấp độ kiểm thử này.
• Định nghĩa trường hợp thử nghiệm chỉ từ những yêu cầu cấp cao
• Kiểm thử phải được thực hiện trên phần cứng tiêu chuẩn sản xuất (đúng mục tiêu)

Những điều cần cân nhắc khi thiết kế các trường hợp thử nghiệm cho Tích hợp CTNH/SW

• Việc thu thập chính xác tất cả dữ liệu bằng phần mềm
• Mở rộng quy mô và phạm vi dữ liệu như mong đợi từ phần cứng đến phần mềm
• Xuất dữ liệu chính xác 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 ngoài thông số kỹ thuật (phạm vi bất thường)
• Dữ liệu ranh giới
• Xử lý ngắt
• Thời gian
• Sử dụng bộ nhớ chính xác (địa chỉ, chồng chéo, v.v.)
• Chuyển đổi trạng thái

Lưu ý: Để 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 cho đến khi hoàn tất quá trình bảo trì và hoàn thành. Các trường hợp thử nghiệm sẽ được thiết kế đặc biệt để kiểm tra đầy đủ các ngắt.

Kiểm thử tích hợp phần mềm với phần mềm

Đó là việc kiểm thử thành phần phần mềm máy tính hoạt động trong môi trường máy chủ/máy đích, đồng thời mô phỏng toàn bộ hệ thống [các thành phần phần mềm máy tính khác], và trên các 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ủ/mục tiêu mô phỏng. Phương pháp được sử dụng cho Tích hợp Phần mềm có thể là phương pháp gia tăng (từ trên xuống, từ dưới lên hoặc kết hợp cả hai, còn được gọi là phương pháp "sandwich" hoặc phương pháp lai).

Tiêu chí đầu vào và đầu ra để kiểm tra tích hợp

Sau khi phương pháp tiếp cận và hai biến thể tích hợp được thống nhất, câu hỏi còn lại là khi nào nhóm có thể bắt đầu và khi nào có thể dừng lại. Thông thường, khi thực hiện Kiểm thử Tích hợp, chiến lược ETVX (Tiêu chí Đầu vào, Nhiệm vụ, Xác thực và Tiêu chí Đầu ra) được sử dụng.

Tiêu chí nhập:

• 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 ra các trường hợp và quy trình kiểm thử
• Kết hợp các bản dựng mô-đun cấp thấp triển khai chức năng chung
• Phát triển một 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 như một tổng thể.
• Thực hiện lại tất cả các thử nghiệm trên nền tảng dựa trên bộ xử lý đích 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
• Phần mềm hoạt động đúng theo yêu cầu quy định

Kết quả đầu ra

• Báo cáo thử nghiệm tích hợp
• Các trường hợp và quy trình kiểm thử phần mềm [SVCP].

Những thách thức thường gặp trong kiểm thử tích hợp hệ thống

Ngay cả với phương pháp tiếp cận hợp lý và tiêu chí thoát rõ ràng, môi trường tích hợp vẫn tạo ra những vấn đề không bao giờ xuất hiện trong quá trình kiểm thử đơn vị. Nhận biết chúng sớm giúp giữ cho tiến độ thực hiện khả thi.

• Môi trường không phù hợp: sự tích hợp môi trường thử nghiệm Hiếm khi phản ánh chính xác sản phẩm thực tế, do đó các lỗi về thời gian và cấu hình chỉ được phát hiện vào giai đoạn rất muộn.
• Sự sẵn sàng phụ thuộc: Các giao diện của bên thứ ba và các giao diện cũ thường chưa hoàn thiện, buộc người kiểm thử phải dựa vào các đoạn mã giả lập và trình mô phỏng lâu hơn nhiều so với dự kiến.
• Dữ liệu không nhất quán: Hai mô-đun có thể biểu diễn cùng một bản ghi theo cách khác nhau, dẫn đến sự không khớp ngầm thay vì các lỗi có thể nhìn thấy.
• Trách nhiệm về lỗi: Khi một sự cố xảy ra giữa hai nhóm, cần tiến hành phân tích nguyên nhân gốc rễ và quản lý lỗi Giảm tốc độ một cách rõ rệt.
• Chi phí hồi quy: mỗi giao diện mới đều mở rộng kiểm tra hồi quy bộ ứng dụng, vì vậy việc thực thi lại thủ công nhanh chóng trở nên không khả thi.

Hầu hết các vấn đề này là rủi ro về tiến độ hơn là bế tắc kỹ thuật. Việc thống nhất ngày hoàn thiện giao diện, phạm vi mô phỏng và quyền phân loại lỗi trước khi tích hợp bản dựng đầu tiên sẽ loại bỏ phần lớn các vấn đề này. Đối với các giao diện do nhà cung cấp sở hữu, hãy ghi lại định dạng thông báo đã thống nhất và người liên hệ để giải quyết vấn đề, vì việc thiếu người chịu trách nhiệm sẽ làm chậm quá trình khắc phục lâu hơn mức độ nghiêm trọng của lỗi.

Các phương pháp thực hành tốt nhất cho kiểm thử tích hợp hệ thống

Chu trình SIT lặp lại phụ thuộc ít hơn vào công cụ mà phụ thuộc nhiều hơn vào kỷ luật xung quanh giao diện, dữ liệu và bằng chứng. Năm phương pháp dưới đây phù hợp với cả hệ thống nhúng nhỏ và hệ thống đa nhà cung cấp lớn, và mỗi phương pháp đều giúp giảm thiểu việc làm lại ở các cấp độ kiểm thử sau này.

1. Trước tiên hãy lập bản đồ mọi giao diện. Hãy liệt kê từng trao đổi dữ liệu, hướng trao đổi, giao thức và chủ sở hữu của nó trước khi viết bất kỳ trường hợp kiểm thử nào.
2. Ưu tiên theo mức độ rủi ro. Hãy xác minh các giao diện truyền tải tiền, thông tin nhận dạng hoặc dữ liệu được quy định trước khi xác minh các giao diện mang tính thẩm mỹ.
3. Thiết kế dữ liệu kiểm thử thực tế. Bao gồm các phạm vi bình thường, ranh giới và bất thường để các lỗi về tỷ lệ và làm tròn được phát hiện sớm.
4. Tự động hóa các đường dẫn ổn định. Giao diện dây kiểm tra vào tích hợp liên tục quy trình sao cho mỗi lần xây dựng đều xác minh lại chúng.
5. Giữ bằng chứng traccó thể. Liên kết mỗi kết quả với một yêu cầu thông qua tracma trận khả năng Vì vậy, các tiêu chí thoát khỏi dự án có thể được chứng minh, chứ không chỉ được khẳng định.

⚠ Mẹo: Cố định các thông số kỹ thuật giao diện trước khi bắt đầu tích hợp. Việc thay đổi muộn định dạng thông báo sẽ làm mất hiệu lực các trường hợp kiểm thử ở cả hai phía của giao diện và là nguyên nhân phổ biến nhất dẫn đến việc phải làm lại kiểm thử tích hợp hệ thống (SIT).

Câu Hỏi Thường Gặp