Xem mẫu
- Kiểm thử tích hợp Integration testing
Bài tập lớn môn
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
Đề tài số 22:
KIỂM THỬ TÍCH HỢP
( Integration testing )
1 Nhóm3
- Kiểm thử tích hợp Integration testing
Mục lục
I. Lời mở đầu ........................................................................................................ 1
Mục lục
II. Giới thiệu chung về kiểm thử tích hợp .............................................................. 6
1. Đặc điểm của kiểm thử tích hợp: ................................................................. 7
2. Khi nào thì sử dụng kiểm thử tích hợp?....................................................... 8
3. Mục tiêu của kiểm thử tích hợp: .................................................................. 9
4. Các bước kiểm thử tích hợp....................................................................... 10
5. Kế hoạch kiểm tra ...................................................................................... 11
6. Làm thế nào để viết một bài kiểm tra tích hợp?......................................... 12
7. Làm việc để hướng tới một bài kiểm tra tích hợp hiệu quả: ...................... 13
III. Một số phương pháp kiểm thử tích hợp ........................................................... 14
1. Top-down Intergration (Kiểm thử tích hợp từ trên xuống dưới)................ 14
2. Bottom-up Intergration (Kiểm thử tích hợp từ dưới lên) ........................... 18
3. Regression Testing (Kiểm thử hồi quy) ..................................................... 21
4. Smoke Testing ........................................................................................... 22
5. Big Bang .................................................................................................... 24
6. Thảo luận xung quanh kiểm thử tích hợp (Comments on Intergration
Testing) .............................................................................................................. 24
7. Tư liệu về kiểm thử tích hợp (Intergration Test Documentation) .............. 25
2 Nhóm3
- Kiểm thử tích hợp Integration testing
IV. Ví dụ 27
3 Nhóm3
- Kiểm thử tích hợp Integration testing
Bài tập lớn môn
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
Đề tài số 22:
KIỂM THỬ TÍCH HỢP
( Integration testing )
Giáo viên bộ môn :Vũ Thị Dương
Lớp : KHMT 1 K2
Nhóm số 3 : Đào Đức Anh
Nguyễn Thị Lệ Chi
Trần Trung Hiếu
Lê Thái Hoàng
4 Nhóm3
- Kiểm thử tích hợp Integration testing
I. Lời mở đầu
Trong ngành kỹ nghệ phần mềm, năm 1979, có một quy tắc nổi tiếng là: “Trong
một dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50% tổng chi phí được sử
dụng trong kiểm thử các chương trình hay hệ thống đã được phát triển”. Và cho đến nay,
sau gần một phần 3 thế kỷ, quy tắc đó vẫn còn đúng. Đã có rất nhiều ngôn ngữ, hệ thống
phát triển mới với các công cụ tích hợp cho các lập trình viên sử dụng phát triển ngày
càng linh động. Nhưng kiểm thử vẫn đóng vai trò hết sức quan trọng trong bất kỳ dự án
phát triển phần mềm nào.
Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “ Sinh viên của chúng
ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần thiết về cách để
kiểm thử một chương trình. Hơn nữa, chúng ta hiếm khi có được những lời khuyên bổ ích
để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làm về kiểm thử và gỡ
lỗi các bài tập của họ”.
Các tác giả của cuốn sách nổi tiếng “The Art of Software Testing” – Nghệ thuật
kiểm thử phần mềm, Glenford J. Myers, Tom Badgett, Todd M. Thomas, Corey Sandler
đã khẳng định trong cuốn sách của mình rằng: “ Hầu hết các thành phần quan trọng trong
các thủ thuật của một nhà kiểm thử chương trình là kiến thức về cách để viết các ca kiểm
thử có hiệu quả”. Việc kiểm thử phần mềm thật sự quan trọng trong “dây chuyền” sản
xuất phần mềm. Đây cũng chính là lý do để nhóm em nghiên cứu về đề tài này, và chính
xác hơn là về kiểm thử tích hợp mà chúng em sẽ trình bày dưới đây. Do còn nhiều khó
khăn trong việc thu thập và dịch tài liệu nên chúng em sẽ còn nhiều thiếu sót trong khi
trình bày, vậy kính mong cô giáo xem xét và giúp đỡ thêm cho chúng em.
Chúng em xin chân thành cảm ơn !
5 Nhóm3
- Kiểm thử tích hợp Integration testing
II. Giới thiệu chung về kiểm thử tích hợp
Một nhân viên mới chập chững bước vào giới phần mềm có thể sẽ đặt ra một câu
hỏi sau khi tất cả các Mô đun đã được kiểm thử “Nếu tất cả các Mô đun đều để riêng lẻ,
tại sao bạn lại nghi ngờ rằng chúng sẽ phát huy tác dụng khi được đặt cùng nhau?”. Tất
nhiên, vấn đề là ở chỗ đưa chúng vào một giao diện “cùng nhau”. Bạn có thể bị mất dữ
liệu trong giao diện; mô đun này vô ý có những ảnh hưởng tiêu cực tới mô đun khác; các
chức năng con khi kết hợp cùng với nhau có thể không tạo ra được chức năng mong
muốn; sự sai lệch ở mức có thể chấp nhận được bị phóng lên thành mức không thể chấp
nhận được; cấu trúc dữ liệu toàn cầu có thể gặp phải nhiều vấn đề. Thật không may là
danh sách này còn rất là dài.
Có một phương pháp kiểm thử có hệ thống để xây dựng cấu trúc chương trình
trong khi đó tiến hành các bài kiểm thử để phát hiện ra lỗi liên quan đến lập giao diện.
Mục tiêu là để kiểm thử các bộ phận và xây dựng một cấu trúc chương trình đã được
kiểm thử chính tả khi thiết kế.
Thường có xu hướng cố gắng thực hiện tích hợp không theo trình tự từng bước; có
nghĩa là để xây dựng một chương trình sử dụng phương pháp tiếp cận “tức thời/đột ngột”.
Tất cả các bộ phận được kết hợp trước với nhau. Toàn bộ chương trình được kiểm thử
6 Nhóm3
- Kiểm thử tích hợp Integration testing
dưới dạng tổng thể. Kết quả là thường xảy ra sự lộn xộn! Bạn gặp phải hàng loạt lỗi. Việc
sửa lỗi là rất khó vì việc cô lập các nguyên nhân rất phức tạp do chương trình quá rộng.
Một khi đã sửa được các lỗi này, các lỗi khác sẽ lại xuất hiện và quá trình cứ tiếp diễn
liên tục như thế.
Tích hợp theo trình tự từng bước mâu thuẫn với phương pháp tiếp cận “tức thời”.
Chương trình được thiết lập và kiểm thử trong các gia lượng nhỏ, nơi dễ tách và sửa lỗi
hơn; giao diện có khả năng được kiểm thử toàn bộ hơn; và có thể áp dụng một phương
pháp kiểm thử có hệ thống.
Phương pháp kiểm thử được nói đến ở đây là phương pháp kiểm thử tích hợp.
1. Đặc điểm của kiểm thử tích hợp:
Là một kiểu kiểm thử cao cấp hơn kiểm thử đơn vị (Unit testing) nhưng lại
được xếp thấp hơn kiểm thử hệ thống (System testing) và kiểm thử người
dùng (User Acceptance Testing)
Được thực hiện sau kiểm thử đơn vị nhưng trước kiểm thử hệ thống
Thường xuyên phát hiện được lỗ hổng cũng như các lỗi của hệ thống
Có thể áp dụng cho việc phát triển tự do
7 Nhóm3
- Kiểm thử tích hợp Integration testing
Hình 1. Sơ đồ các cấp độ kiểm thử
2. Khi nào thì sử dụng kiểm thử tích hợp?
Khi hệ thống là rất lớn (“500K + LOC”)
Khi hệ thống là cả phần mềm và phần cứng
Khi có quá nhiều lỗi trong giai đoạn kiểm thử hệ thống và kiểm thử người
dùng
Khi bạn có quá nhiều các tương tác giữa các phần mềm
Khi hệ thống thiết kế là một hệ thống thời gian thực
Khi ban có yêu cầu cao hơn về hệ thống của mình
…
8 Nhóm3
- Kiểm thử tích hợp Integration testing
3. Mục tiêu của kiểm thử tích hợp:
Phát hiện lỗi xảy ra giữa các Unit
Tích hợp các Unit thành các hệ thống nhỏ (subsyetem) và cuối cùng là
nguyên hệ thống hoàn chỉnh (system) chuẩn bị cho kiểm thử ở múc hệ
thống (system testing)
Trong kiểm thử đơn vị các lập trình viên cố gắng phát hiện lỗi liên quan đến chức
năng và cấu trúc nội tại của Unit. Có một số phép kiểm thử đơn giản trên giao tiếp với
các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự
kiểm tra đầy dủ khi các Unit kết hợp với nhau trong khi thực hiện kiểm thử tích hợp.
Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thự hiện trên các Unit đã được
kiểm tra cẩn thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức Unit đã được sửa
chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp
giả lập thì không cần phải thực hiện Integration Test nữa. Thực tế việc tích hợp giữa các
Unit dẫn đến những tình huống hoàn toàn khác.Một chiến lược cần quan tâm trong
Integration Test là nên tích hợp dần từng Unit. Một Unit tại một thời điểm được tích hợp
vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test
trước đó. Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các
Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều,
và sai sót sẽ giảm đáng kể.
Có 4 loại kiểm thử trong Integration Test:
Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử
cấu trúc nhằm bảo đảm các thành phần bên trong của một chương trình
chạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc nội tại
của chương trình chẳng hạn các câu lệnh và nhánh bên trong.
Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm
thử chức năng chỉ chú trọng đến chức năng của chương trình, mà không
quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình
theo yêu cầu kỹ thuật.
Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ
thống.
9 Nhóm3
- Kiểm thử tích hợp Integration testing
Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ
thống.
4. Các bước kiểm thử tích hợp
Kiểm tra tích hợp gồm các bước sau:
Bước 1: Thiết lập kế hoạch kiểm thử
Bước 2: Thiết lập các bài và dữ liệu kiểm thử
Bước 3: Tạo các tập lệnh để thực hiện các bài kiểm thử nếu có thể.
Bước 4: Một khi tất cả các bộ phận đã được tích hợp, thực hiện các bài
kiểm thử
Bước 5: Vá lỗi nếu có và kiểm thử mã
Bước 6: Lặp lại quy trình kiểm thử cho đến khi tất cả các bộ phận đã được
tích hợp thành công
10 Nhóm3
- Kiểm thử tích hợp Integration testing
Các tiêu chuẩn để được
Phần mềm đã Sơ đồ phát
Kế hoạch kiểm
người dùng chấp nhận
được phát triển triển
tra
Tích hợp và kiểm tra
Phần mềm đã được Báo cáo chấp thuận Kế hoạch phát triển
tích hợp
5. Kế hoạch kiểm tra
Nó mô tả một trong các yếu tố sau:
Các bài kiểm tra sẽ được tiến hành như thế nào
Danh sách các đối tượng cần được kiểm tra
Vai trò và trách nhiệm
Yêu cầu tiên quyết để bắt đầu kiểm tra
Kiểm tra môi trường
Giả thuyết
Làm gì sau khi kiểm tra thành công
Làm gì khi kiểm tra không thành công
11 Nhóm3
- Kiểm thử tích hợp Integration testing
6. Làm thế nào để viết một bài kiểm tra tích hợp?
Một bài kiểm thử đơn giản miêu tả chính xác bài kiểm tra sẽ được thực hiện như
thế nào. Các bài kiểm thử tích hợp tập trung vào dòng lưu chuyển dữ liệu/thông tin/kiểm
soát từ một bộ phận sang một bộ phận khác.
Vì thế các bài kiểm thử tích hợp phải tập trung vào những tình huống trong đó một
bộ phận được gọi ra từ một bộ phận khác. Tương tự toàn bộ chức năng áp dụng phải được
kiểm thử để đảm bảo rằng các áp dụng phát huy tác dụng khi các bộ phận khác nhau
được đặt cùng nhau.
Các bài kiểm thử tích hợp được đưa vào thành một nhóm từ một bộ các bài kiểm
thử tích hợp. Mỗi bộ có thể tập trung vào một đối tượng khác nhau. Nói cách khác, các
bộ kiểm thử khác nhau có thể được tạo ra để tập trung vào các lĩnh vực áp dụng khác
nhau.
Như đã nêu phía trước, một nhóm kiểm thử có thể được tạo ra để thực hiện các bài
kiểm tra. Vì thế các bài kiểm thử phải càng chi tiết càng tốt.
Bảng ví dụ bài kiểm thử:
ID bài Thành
Mô tả bài kiểm Dữ liệu Kết quả mong Kết quả
kiểm công/không Ghi chú
thử đầu vào đợi thực
thử thành công
Ngoài ra có thể bao gồm cả:
Tên bộ kiểm thử
Kiểm thử bằng
Ngày tháng
Kiểm thử lặp (Có thể thực hiện kiểm thử tích hợp lặp lại một hoặc nhiều
lần)
12 Nhóm3
- Kiểm thử tích hợp Integration testing
7. Làm việc để hướng tới một bài kiểm tra tích hợp hiệu quả:
Có rất nhiều yếu tố ảnh hưởng đến kiểm tra tích hợp phần mềm và kiểm tra phần
mềm:
1) Quản lý cấu trúc phần mềm: Do kiểm thử tích hợp tập trung vào việc tích hợp
các bộ phận và các bộ phận có thể được xây dụng bằng những người phát triển khác nhau
và thậm chí bởi những nhóm phát triển khác nhau, điều quan trọng là phiên bản các bộ
phận được kiểm tra. Điều này nghe có vẻ rất là cơ bản, nhưng vấn đề lớn nhất gặp phải là
tích hợp phiên phản các bộ phận chính xác. Kiểm tra tích hợp có thể thực hiện sau vài lần
lặp lại và vá lỗi mà các bộ phận có thể thay đổi. Vì thế, điều quan trọng là một chính sách
quản lý cấu trúc phần mềm (SCM) phải có sẵn. Chúng ta phải có khả năng tìm các bộ
phận và các phiên bản của chúng. Vì thế mỗi khi ta tích hợp các bộ phận ứng dụng,
chúng ta biết chính xác phiên bản này sẽ đi vào quá trình xây dựng.
2)Qúa trình xây dựng tự động nếu cần thiết: sẽ có rất nhiều lỗi do phiên bản không
chính xác các bộ phận được gửi cho quá trình xây dựng hoặc thiếu một số bộ phận. Nếu
có thể, viết một tập lệnh để tích hợp và triển khai các bộ phận. Điều này sẽ giảm các lỗi
thủ công.
3) Tài liệu: xắp xếp tài liệu quá trình tích hợp/xây dựng để loại bỏ các lỗi do bỏ
qua hoặc không nhìn thấy. Người chịu trách nhiệm tích hợp các phần mềm có thể quên
chạy tập lệnh yêu cầu và quá trình kiểm thử tích hợp sẽ không cho kết quả chính xác.
4) Tìm kiếm lỗi: Kiểm thử tích hợp sẽ mất hướng nếu không phát hiện chính xác
lỗi. Mỗi lỗi phải được ghi lại và tìm kiếm. Thông tin phải chỉ rõ cách vá lỗi. Đây là thông
tin vô giá. Nó có thể giúp hỗ trợ quá trình tích hợp và thực hiện trong tương lai.
Trong các phần sau đây trình bày một số bước tích hợp khác nhau.
13 Nhóm3
- Kiểm thử tích hợp Integration testing
III. Một số phương pháp kiểm thử tích hợp
1. Top-down Intergration (Kiểm thử tích hợp từ trên xuống dưới)
Kiểm thử tích hợp từ trên xuống dưới là một phương pháp gia lượng áp dụng cho
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 di chuyển
theo chiều hướng xuống theo trình tự kiểm soát cấp bậc, bắt đầu bằng mô đun điều khiển
chính (chương trình chính). Các mô đun phụ (và các mô đun sau cùng) đến mô đun điều
khiển chính được ghép lại thành một cấu trúc hoặc là theo lối nhanh nhất hoặc lâu nhất
(depth-first or bread-first manner).
Hình 2 Kiểm thử tích hợp từ trên xuống
Xem hình 2, tích hợp depth-first sẽ tích hợp tất cả các bộ phận vào một đường
điều khiển của cấu trúc. Việc lựa chọn con đường là rất mơ hồ và phụ thuộc vào đặc điểm
ứng dụng cụ thể. Ví dụ, lựa chọn đường theo chiều tay trái, các bộ phận M1, M2 , M5 sẽ
được tích hợp trước. tiếp đó M8 hoặc (nếu cần chức năng phù hợp của M2) M6 sẽ được
tích hợp. Sau đó, phương pháp điều khiển bàn tay phải và trung tâm sẽ được xây dựng.
Breadth-first integration kết hợp tất cả các bộ phận bổ sung trực tiếp ở mỗi mức độ,
chuyển qua cấu trúc theo phương ngang. Từ hình vẽ, các bộ phận M2, M3, và M4 (thay
cho S4) sẽ được tích hợp trước . Mức điều khiển tiếp theo, và cứ tiếp tục như thế
14 Nhóm3
- Kiểm thử tích hợp Integration testing
Quá trình tích hợp được thực hiện trong 5 bước:
Mô đun điều khiển chính được sử dụng làm bộ điều khiển kiểm thử và các mô đun
tiếp theo bổ sung cho tất cả các bộ phận bổ sung trực tiếp cho mô đun điều khiển
chính.
Tùy thuộc vào phương pháp tích hợp được chọn (ví dụ depth or breadth first), các
mô đun bổ sung tiếp theo được thay thế theo trình tự với các bộ phận thực.
Các bài kiểm thử sẽ được tiến hành khi mỗi mô đun được tích hợp
Khi hoàn thành từng bài kiểm thử một, các bộ phận tiếp theo sẽ được thay thế bởi
bộ phận thực.
Kiểm thử hồi quy (phần V) có thể được tiến hành để đảm bảo không xảy ra lỗi
mới.
Quá trình tiếp tục từ bước thứ hai cho đến khi toàn bộ cấu trúc chương trình được
xây dựng.
Các bước tích hợp theo hướng từ trên xuống kiểm thử các điểm điều khiển hoặc
quyết định chính ở phần đầu quá trình kiểm thử. trong một cấu trúc chương trình được
với hệ số rõ ràng, việc đưa ra quyết định sẽ diễn ra ở các bậc cao hơn theo trình tự và vì
thế được bắt gặp đầu tiên. Nếu tồn tại các vấn đề điều khiển chính, việc phát hiện ra sớm
là vô cùng cần thiết. Nếu chọn phương pháp tích hợp depthfirst, có thể tiến hành và trình
bày một chức năng hoàn chỉnh của phần mềm. Ví dụ, giả sử một cấu trúc chuyển giao
trong đó có một chuỗi các đầu vào tương tác với nhau được yêu cầu, thực hiện và hợp
thức hóa qua một đường đến. Đường đến có thể được tích hợp theo cách từ trên xuống
dưới. Tất cả các đầu vào xử lý (để chuyển đi sau này) có thể được thể hiện trước khi các
yếu tố khác của cấu trúc đã được tích hợp. Việc thể hiện ngay từ đầu khả năng mang
chức năng là rất có ích đối với người phát triển và khách hàng.
15 Nhóm3
- Kiểm thử tích hợp Integration testing
Phương pháp từ trên xuống có vẻ không phức tạp, nhưng trên thực tế, có thể nảy
sinh các vấn đề logic. Một trong những vấn đề thường gặp xảy ra khi xử lý ở mức thấp
theo thứ tự được yêu cầu để kiểm thử ở các mức cao hơn. Các mô đun phụ thay thế các
mô đun mức thấp ở giai đoạn đầu của quá trình kiểm thử từ trên xuống. Vì thế, không có
bất kì dữ liệu đáng kể nào có thể chuyển lên trên trong cấu trúc chương trình. Người kiểm
thử sẽ đứng giữa 3 lựa chọn:
Hoãn các bài kiểm thử lại cho đến khi các mô đun phụ được thay thế bằng mô đun
thực
Phát triển các mô đun phụ thực hiện các chức năng hạn chế thức đẩy mô đun thực
Tích hợp phần mềm từ dưới lên trên.
Phương pháp đầu tiên (hoãn các bài kiểm thử lại cho đến khi các mô đun phụ được
thay thế bằng mô đun thực) làm cho chúng ta mất điều khiển giữa các bài kiểm thử cụ thể
và sự kết hợp các mô đun cụ thể. Việc này có thể dẫn tới khó khăn trong việc xác định
nguyên nhân gây lỗi và có xu hướng vi phạm bản chất giới hạn của phương pháp từ trên
xuống. Phương pháp thứ 2 có thể phát huy tác dụng nhưng có thể dẫn đến tình trạng phải
thực hiện thêm nhiều bước nữa, vì các mô đun phụ trở nên ngày càng phức tạp. Phương
pháp thứ 3, gọi là kiểm thử từ dưới lên, được trình bày trong phần tiếp theo.
16 Nhóm3
- Kiểm thử tích hợp Integration testing
Ví dụ
Khi cần xây dựng một hệ thống quản lý bán hàng điện tử có mô hình như hình
dưới đây:
Quản lý mua, bán và bảo
hành thiết bị máy tính
Báo Cáo
QL Bán Hàng QL Nhập Hàng QL Bảo Hành
Thống Kê
Lập phiếu đặt
Kiểm tra hàng Lập báo cáo
Kiểm tra phiếu
hàng
trong kho doanh thu
bảo hành
Lập hoá đơn Kiểm tra chất
Lập phiếu bảo Báo cáo TB
lượng hàng
hành đã bán
Giao hàng Lập phiếu nhập
Lập hoá đơn
Báo cáo TB
tồn kho
Thanh toán Thông báo từ
chối nhập Báo cáo TB
bảo hành
Thông báo từ
chối xuất
Đầu tiên khi muốn xây dựng hệ thống ta phải xây dựng các chức năng chính của
hệ thống như chức năng quản lý bán hàng, quản lý nhập hàng, quản lý bảo hành, báo
cáo thống kê. Sau đó mới có thể xây dựng tiếp các chức năng con khác sau
17 Nhóm3
- Kiểm thử tích hợp Integration testing
Ta có lập một sơ đồ tích hợp các chức năng của hệ thống quản lý bán hàng như
sau:
QL Bán Hàng
Giao hàng
Kiểm tra hàng Lập hoá Thanh toán Thông báo từ
trong kho đơn chối xuất
Giao hàng Thanh toán Thanh toán
tận nhà bằng tiền bằng thẻ
mặt
Tùy theo yêu cầu của từng công ty mà ta có thể tích hợp hay loại bỏ bớt các thành
phần của hệ thống
2. Bottom-up Intergration (Kiểm thử tích hợp từ dưới lên)
Kiểm thử tích hợp từ dưới lên, như tên gọi của nó, bắt đầu xây dựng và kiểm thử
bằng các mô đun nguyên tử (có nghĩa là các bộ phận ở mức thấp nhất trong cấu trúc
chương trình). Do các bộ phận được tích hợp từ dưới lên, việc xử lý yêu cầu đối với các
bộ phận bổ sung cho một mức cho trước luôn có sẵn và loại bỏ yêu cầu cần các mô đun
bổ sung.
Phương pháp tích hợp từ dưới lên có thể được tiến hành theo các bước sau:
Các bộ phận ở mức thấp được kết hợp với nhau thành một nhóm thực hiện chức
năng phần mềm cụ thể.
Một driver (chương trình điều khiển để kiểm thử) được viết để kết hợp các đầu
vào và đầu ra kiểm thử.
18 Nhóm3
- Kiểm thử tích hợp Integration testing
Nhóm được kiểm thử
Các Driver được loại bỏ và nhóm được kết hợp di chuyển lên trên trong cấu trúc
chương trình.
Tích hợp tiến hành theo các bước trình bày trong hình 3. Các bộ phận được kết
hợp để hình thành nhóm 1, 2 và 3. Mỗi nhóm được kiểm thử bằng driver (trình bày dưới
dạng block nét đứt). Các bộ phận trong nhóm 1 và 2 bổ sung cho Ma. Drivers D1 và D2
được loại bỏ và nhóm được lập giao diện trực tiếp cho Ma. Tương tự, driver D3 cho
nhóm 3 được loại bỏ trước khi tích hợp bằng mô đun Mb. Cả Ma và Mb sẽ được tích hợp
bằng bộ phận Mc, và cứ như thế.
Hình 3: Kiểm thử tích hợp từ dưới lên
Khi tích hợp di chuyển lên phía trên, yêu cầu tách các driver kiểm thử giảm dần.
Thực tế, nếu 2 mức trên cùng của cấu trúc chương trình được tích hợp từ trên xuống, số
lượng driver có thể giảm đi và quá trình tích hợp của nhóm sẽ đơn giản hơn nhiều.
19 Nhóm3
- Kiểm thử tích hợp Integration testing
Ví dụ
Xây dựng hệ thống quản lý thư viện
Khi thư viên của nhà trường có phòng lưu trữ sách thì sẽ có nhu cầu có một phòng
ban quản lý các đầu sách, số lượng cùng loại, tình trạng của sách trong thư viện thì sẽ
phải thành lập một phòng quản lý sách. Sách của nhà trường lại có khả năng cho sinh
viên trong trường mượn để có thể học tập và ngiên cứu nên cùng với phòng quản lý sách
các yêu cầu mượn sách tạo lên một phòng mượn sách. Sau khi nghiên cứu xong sách sinh
viên lại có nhu cầu trả sách để có thể mượn sách khác và bộ phận quản lý trả sách được
thành lập. Dựa vào các thành phần đã nêu trên nhà trường có thể thành lập một thư viện
sách với các chức năng quản lý sách, cho mượn sách…tùy vào yêu cầu của mỗi trường
một khác nhau thì sẽ có cách cấu thành các thành phần khác nhau. Dưới đây là một sơ đồ
đơn giản về hệ thống quản lý thử viện được xây dựng theo phương pháp tích hợp từ dưới
lên:
Quản lý thư
viện
Quản lý Quản lý trả
mượn sách sách
Quản lý sách Yêu cầu
mượn sách
Quản lý số Quản lý tình
lượng sách trạng sách
20 Nhóm3
nguon tai.lieu . vn