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 )
Mục lục
Bài tập lớn môn 1
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM 1
Đề tài số 22: 1
KIỂM THỬ TÍCH HỢP 1
( Integration testing ) 1
Mục lục 2
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM 2
Đề tài số 22: 2
KIỂM THỬ TÍCH HỢP 2
( Integration testing ) 2
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
Đề tài số 22:
KIỂM THỬ TÍCH HỢP
( Integration testing )
2
Giáo viên bộ môn :Nguyên thị hiên
Lớp :K3CNTT
Nhóm số 8 : SẦM VĂN NGHĨA
: VŨ DUY KHÁNH
: TẠ QUẢNG THU
: NGUYỄN QUỐC LONG
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,

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ử
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
4
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
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
5
• Khi có quá nhiều lỗi trong giai đoạn kiểm thử hệ thống và kiểm thử người

• 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.
• 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
7
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
Kế hoạch kiểm

thử
Dữ liệu
đầu vào
Kết quả mong
đợi
Kết quả thực
Thành
công/không
thành công
Ghi chú
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)
9
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

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
11
 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.
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

Lập hoá đơn
Giao hàng
Thanh toán
Báo cáo TB
đã bán
Kiểm tra chất
lượng hàng
Lập phiếu nhập
Thông báo từ
chối nhập
Lập phiếu bảo
hành
Lập hoá đơn
Báo cáo TB
tồn kho
Báo cáo TB
bảo hành
Thông báo từ
chối xuất
13
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:
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.

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
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ẽ
15
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:
3. Regression Testing (Kiểm thử hồi quy)
Mỗi khi một mô đun mới được bổ sung dưới dạng một bộ phận của kiểm thử tích
hợp, phần mềm sẽ thay đổi. Các đường dữ liệu mới được thiết lập, có thể xảy ra I/O mới,
và gọi ra logic điều khiển mới. Trong bước kiểm thử tích hợp tiếp theo, kiểm thử hồi quy
là sự thực hiện lại của một số chuỗi nhỏ trong các bài kiểm thử đã được thực hiện để đảm
bảo không sinh ra các hiệu ứng phụ.
Ở phạm vi rộng hơn, các bài kiểm thử thành công (bất kì loại nào) dẫn đến sự phát
hiện ra lỗi, và lỗi phải được sửa. Bất cứ khi nào một phần mềm được sửa lỗi, một số khía
cạnh của cấu trúc phần mềm (chương trình, tài liệu hoặc dữ liệu hỗ trợ nó) bị thay đổi.
Quản lý thư
viện
Quản lý mượn

phần mềm có bản quyền được phát triển. Nó được thiết kế dưới dạng một cơ cấu dùng
cho các dự án có giới hạn về thời gian chặt chẽ, cho phép nhóm phần mềm tiếp cận với dự
án trên một nền tảng thường xuyên. Phương pháp kiểm thử này xoay quanh các hoạt động
sau:
 Các bộ phận của phần mềm đã được đưa thành dạng code được tích hợp vào một
nhóm. Một nhóm có thể bao gồm các file dữ liệu, thư viện, các mô đun có thể tái
sử dụng, các bộ phận cần phải thực hiện một hoặc nhiều chức năng của sản phẩm.
 Một chuỗi các bài kiểm ta được thiết kế để tìm ra lỗi để giúp nhóm có thể thực
hiện tốt chức năng của nó. Mục đích là tìm ra lỗi có nhiều khả năng làm chậm tiến
trình phát triển phần mềm nhất.
 Nhóm được tích hợp với các nhóm khác và toàn bộ sản phẩm được tiến hành
smoke test hàng ngày. Phương pháp tích hợp có thể là từ trên xuống hoặc từ dưới
lên.
Tần số kiểm thử hằng ngày toàn bộ sản phẩm có thể làm một số người ngạc nhiên.
Tuy nhiên, tần số kiểm thử cho phép cả người quản lý và người thực tập một đánh giá
thực tế về quá trình kiểm thử tích hợp. McConnell [MCO96*] mô tả smoke test theo
cách sau đây:
Smoke test được tiến hành trên cả hệ thống từ đầu này đến đầu khác. Nó phải có
khả năng phát hiện được các vấn đề chính. Smoke test phải đủ toàn diện để nếu nhóm
được thông qua, bạn có thể giả sử rằng đủ ổn định để kiểm thử toàn diện hơn.
Smoke testing mang lại rất nhiều lợi ích khi được áp dụng vào các dự án phức tạp,
kĩ thuật phần mềm có quy định về thời gian nghiêm ngặt:
• Nguy cơ tích hợp được giảm thiểu. do smoke tests được thực hiện hàng ngày,
những hiện tượng không tương thích và các lỗi khác thường được phát hiện sớm,
giảm khả năng tác động đến kế hoạch thực hiện khi lỗi không được phát hiện.
• Chất lượng sản phẩm cuối cùng được nâng cao. Do phương pháp thực hiện là
hướng xây dựng (tích hợp), smoke testing có khả năng phát hiện lỗi chức năng và
các khuyết tật thiết kế ở mức bộ phận. Nếu các khuyết tật này được sửa sớm, ta sẽ
có chất lượng sản phẩm tốt hơn.
18

bù lại bởi các ưu điểm của các chức năng điều khiển kiểm thử chính. Nhược điểm chủ yếu
19
của phương pháp tích hợp từ dưới lên là “chương trình dưới dạng tổng thể không tồn tại
cho đến khi bổ sung mô đun cuối cùng” [MYE79*]. Nhược điểm này được giảm bớt đi
bằng cách thiết kế kiểm thử dễ dàng hơn và không có các mô đun phụ.
Việc lựa chọn phương pháp tích hợp phụ thuộc vào đặc điểm phần mềm và đôi khi
phụ thuộc vào kế hoạch dự án. Nói chung, một phương pháp kết hợp sử dụng kiểm thử từ
trên xuống cho các mức cao hơn của cấu trúc chương trình, kết hợp với kiểm thử từ dưới
lên cho các mức bổ sung có thể là một giải pháp tốt nhất.
Khi thực hiện kiểm thử tích hợp, người kiểm thử phải chỉ rõ mô đun quan trọng.
Một mô đun quan trọng có một hoặc các tính chất sau:
(1) Giải quyết một số yêu cầu phần mềm
(2) Có mức độ điều khiển cao (cao cả trong cấu trúc chương trình)
(3) Phức tạp và không có lỗi (sự phức tạp có thể được dùng làm bộ chỉ báo)
(4) Có các yêu cầu hoạt động tốt.
Các mô đun quan trọng phải được kiểm thử càng sớm càng tốt. Thêm vào đó, kiểm
thử hồi quy phải tập trung vào chức năng của mô đun quan trọng.
* [BEI84] Beizer, B., Software System Testing and Quality Assurance, Van Nostrand-
Reinhold, 1984.
* [MYE79] Myers, G., The Art of Software Testing, Wiley, 1979.
7. Tư liệu về kiểm thử tích hợp (Intergration Test Documentation)
Một kế hoạch tổng thể cho sự tích hợp phần mềm và một mô tả về các bài kiểm tra
cụ thể được đưa ra trong phần Mô tả kiểm tra. trong đó gồm một kế hoạch kiểm tra, một
quy trình kiểm tra, là một sản phẩm của quá trình phần mềm và trở thành một phần trong
cấu trúc phần mềm. Kế hoạch kiểm tra miêu tả toàn bộ quy trình tích hợp. Kiểm tra được
chia thành các giai đoạn và các nhóm đề cập đến các đặc điểm chức năng và hoạt động
của phần mềm. Ví dụ, kiểm tra tích hợp hệ thống CAD có thể chia ra thành các giai đoạn
kiểm tra như sau:
• Giao tiếp với người dùng (lựa chọn điều khiển, tạo hình vẽ, biểu diễn minh họa, xử
lý lỗi và biểu diễn)

Một bản ghi kết quả kiểm tra, các vấn đề hoặc những khó khăn được ghi lại trong
phần miêu tả kiểm tra. Thông tin có trong phần này có thể rất quan trọng trong quá trình
duy trì phần mềm. Mẫu tham khảo phù hợp và phụ lục cũng được trình bày kèm theo.
Tương tự như các phẩn tử của cấu trúc phần mềm khác, định dạng miêu tả kiểm tra
có thể đi kèm trong nhu cầu cục bộ của việc tổ chức kĩ thuật phần mềm. Tuy nhiên, điều
21
quan trọng là phải chú ý rằng quy trình tích hợp (có trong kế hoạch kiểm tra) và chi tiết
kiểm tra ( miêu tả trong quy trình kiểm tra) là những yếu tố quan trọng.
IV. Ví dụ
Chương trình đọc vào 3 giá trị nguyên từ hộp thoại vào. Ba giá trị này tương ứng
với chiều dài 3 cạnh của 1 tam giác. Chương trình hiển thị 1 thông điệp cho biết tam giác
đó là tam giác thường, cân, hay đều.
Ba giá trị nhập vào thỏa mãn là 3 cạnh của một tam giác khi và chỉ khi cả 3 số đều
là số nguyên dương, và tổng của 2 số bất kỳ trong 3 số phải lớn hơn số thứ 3. Khi đó, một
tam giác đều là tam giác có 3 cạnh bằng nhau, tam giác cân là tam giác có 2 trong 3 cạnh
bằng nhau, và tam giác thường thì có 3 cạnh khác nhau.
Mã lệnh của chương trình:
22
Do đặc tả có sự kết hợp đầu vào nên trước tiên, áp dụng phương pháp vẽ đồ thị
nguyên nhân – kết quả.
Nguyên nhân là:
• Cả 3 giá trị nhập vào đều là số nguyên dương.
• Tổng 2 số bất kỳ trong 3 số lớn hơn số còn lại.
• Hai trong 3 số có giá trị bằng nhau.
• Ba số có giá trị bằng nhau.
Kết quả là:
• R1. Thông báo ba giá trị nhập vào lập thành tam giác thường.
• R2. Thông báo ba giá trị nhập vào lập thành tam giác cân.
• R3. Thông báo ba giá trị nhập vào lập thành tam giác đều.
• R4. Thông báo ba giá trị nhập vào không lập thành một tam giác.