Bài tập lớn môn Kiểm thử tích hợp ppt

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,

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 !
II. Giới thiệu chung về kiểm thử tích hợp
3
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ử
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

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
…
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.
6

• 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

tra
Phần mềm đã được
tích hợp
Báo cáo chấp thuận Kế hoạch phát triển
Tích hợp và kiểm tra
Phần mềm đã
được phát triển
Sơ đồ phát
triển
Các tiêu chuẩn để được
người dùng chấp nhận
8
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
kiểm
thử
Mô tả bài 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

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.
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
10
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ế
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
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

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
12
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.
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:
Đầ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
Quản lý mua, bán và bảo
hành thiết bị máy tính
Báo Cáo
Thống Kê
Lập báo cáo
doanh thu
QL Bán Hàng QL Nhập Hàng QL Bảo Hành
Kiểm tra hàng
trong kho
Lập phiếu đặt
hàng
Kiểm tra phiếu
bảo hành

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.

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ử.
QL Bán Hàng
Kiểm tra hàng
trong kho
Lập hoá
đơn
Giao hàng
Thanh toán Thông báo từ
chối xuất
Thanh toán
bằng tiền
mặt
Thanh toán
bằng thẻ
Giao hàng
tận nhà
14
 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
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

sách
Yêu cầu
mượn sách
Quản lý trả
sách
Quản lý sách
Quản lý số
lượng sách
Quản lý tình
trạng sách
16
Kiểm thử hồi quy hỗ trợ để đảm bảo rằng các thay đổi (do kiểm thử hoặc do các lý do
khác) không dẫn đến các lỗi khác.
Kiểm thử hồi quy có thể được thực hiện thủ công, bằng cách thực hiện lại các bài
kiểm thử hoặc sử dụng công cụ capture/playback. Công cụ Capture/playback cho phép kĩ
sư phần mềm thực hiện bài kiểm thử và lấy kết quả cho những lần chạy lại và so sánh.
Kiểm thử hồi quy bao gồm 3 lớp kiểm thử khác nhau:
 Mẫu đại diện sẽ thực hiện chức năng của phần mềm
 Các bài kiểm thử bổ sung tập trung vào chức năng phần mềm có thể bọ ảnh hưởng
bởi các thay đổi.
Các bài kiểm thử tập trung vào các bộ phận của phần mềm đã bị thay đổi
Hình 4: Sơ đồ luồng kiểm thử tích hợp (Source base77.com)
Do quá trình kiểm thử tích hợp được tiếp diễn, số bài kiểm thử tích hợp có thể tăng
lên khá nhiều. Vì thế, bộ kiểm thử hồi quy phải được thiết kế để chỉ bao gồm những bài
kiểm thử dùng để xử lý một hoặc nhiều lớp lỗi trong mỗi chức năng của chương trình.
việc thực hiện lại mỗi bài kiểm thử cho mỗi chức năng chương trình là không thực tế và
không hiệu quả một khi xảy ra sự thay đổi.
17
4. Smoke Testing
Smoke testing là một phương pháp kiểm thử thường được sử dụng khi sản phẩm

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

• Chuẩn đoán lỗi và sửa được đơn giản hóa. tương tự như phương pháp kiểm thử
tích hợp, lỗi lộ ra trong quá trình smoke testing thường gắn liền với “gia số phần
mềm mới” – điều này có nghĩa là, phần mềm vừa được bổ sung vào nhóm có khả
năng là nguyên nhân của lỗi mới xuất hiện.
• Tiến độ rất dễ tiếp cận. từng ngày một, các bộ phận của phần mềm càng được tích
hợp thêm và được đưa ra hoạt động. Điều này cải thiện không khí của nhóm và cho
phép người quản lý biết được rằng tiến độ đang được đẩy nhanh.
* [MCO96] McConnell, S., “Best Practices: Daily Build and Smoke Test”, IEEE
Software, vol. 13, no. 4, July 1996, 143–144.
5. Big Bang
Người ta xây dựng mối liên hệ giữa các đơn thể để tạo thành một phiên bản hệ
thống hoàn chỉnh, sau đó thử nghiệm phiên bản này.
Như vậy người ta cần đến nhiều trình điều khiển (Driver) mỗi trình điều khiển cho
một đơn thể, một trình stub cho tất cả các đơn thể của hệ thống, trừ đơn thể chính phải
được kiểm thử bằng phương pháp kiểm thử đơn vị
Phương pháp kiểm thử Big Bang có 2 đặc điểm chinh là:
• Kết hợp tất cả các modul đã kiểm thử thành 1 chương trình
• Tiến hành kiểm thử toàn bộ chương trình
Phương pháp Bing Bang không an toàn cho việc kiểm thử ở chỗ tất cả các sai sót
có thể xuất hiện cùng lúc, khi đó việc xác đinh từng lỗi sai sẽ gặp nhiều khó khăn. Hơn
nữa phương pháp kiểm thử này đòi hỏi một lượng tối đa các trình điều khiển và các stub.
Vì vậy thương thì người ta hay dùng các phương pháp kiểm thử từ trên xuống hay kiểm
thử từ dưới lên
6. Thảo luận xung quanh kiểm thử tích hợp (Comments on
Intergration Testing)
Đã có rất nhiều bài thảo luận (ví dụ [BEI84]*) về ưu điểm và nhược điểm của
phương pháp kiểm thử từ trên xuống và từ dưới lên. Nói chung, ưu điểm của phương
pháp này lại trở thành nhược điểm của phương pháp khác. nhược điểm chủ yếu của
phương pháp từ trên xuống là cần phải có các mô đun phụ và các khó khăn kiểm thử gặp
phải có thể theo kèm. Các vấn đề gắn liền với các mô đun phụ có thể nhanh chóng được

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)

• Thao tác và phân tích dữ liệu (tạo ký hiệu, xác định kích thước, quay, tính toán và
tính chất vật lý)
20
• Xử lý và tạo hiển thị (hiển thị 2 chiều, hiển thị 3 chiều, biểu đồ)
• Quản lý dữ liệu (truy cập, update, nhất quán và làm việc)
Mỗi giai đoạn và các giai đoạn nhỏ (trong ngoặc đơn) miêu tả nhóm chức năng rộng hơn
trong phần mềm và có thể liên quan tới phân vùng cụ thể của cấu trúc chương
trình. Vì thế, nhóm chương trình (nhóm mô đun) được tạo ra tương đương với từng
giai đoạn. Các tiêu chí sau đây và các bài kiểm tra tương ứng với chúng được áp dụng cho
tất cả các giai đoạn kiểm tra:
• Thống nhất về giao diện. Các giao diện bên trong và bên ngoài được kiểm tra dưới
dạng từng mô đun một và được tích hợp với cấu trúc.
• Tính phù hợp về chức năng. Các bài kiểm tra được thiết kế để phát hiện ra lỗi được
tiến hành.
• Nội dung thông tin. Các bài kiểm tra được thiết kế để phát hiện lỗi có liên quan
đến cấu trúc khu vực và toàn bộ được thực hiện.
• Khả năng làm việc. Các bài kiểm tra được thiết kế để xác nhận các mức hoạt động
được thiết lập trong quá trình thiết kế phần mềm được thực hiện.
Kế hoạch tiến hành tích hợp, phát triển các phần mềm phía trên, và các chủ đề liên
quan được thảo luận riêng một phần trong kế hoạch kiểm tra. Bắt đầu và ngừng ngày
tháng từng giai đoạn được thực hiện và các “cửa sổ có sẵn” cho từng mô đun được kiểm
tra được xác định. Mô tả ngắn về phần mềm (nhóm và driver) tập trung vào các đặc điểm
có thể yêu cầu nỗ lực lớn. Cuối cùng, môi trường và nguồn kiểm tra được miêu tả. Các
cấu trúc phần cứng bất thường, chương trình mô phỏng không chính xác, và các công cụ
kiểm tra hoặc kĩ thuật kiểm tra đặc biệt chỉ là một số ít trong số những chủ đề có thể được
thảo luận.
Quy trình kiểm tra chi tiết cần thiết để đạt được kế hoạch kiểm tra được mô tả sau.
Thứ tự tích hợp và các bài kiểm tra tương ứng tại mỗi bước tích hợp được miêu tả. Một
danh sách các bài kiểm tra (để sau này có thể xem lại) và kết quả mong muốn cũng được
bao gồm trong đó.

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.

• R5. Thông báo lỗi nhập dữ liệu.
23
Hình 5: Đồ thị nguyên nhân – kết quả
Bước tiếp theo là tạo bảng quyết định mục vào giới hạn. Chọn kết quả R1 là đầu
tiên. R1 có mặt nếu nút các nút 12 và 3 = 1,0. Nút 12 = 1 khi 1 và 2 = 1,1.
Áp dụng lần lượt cho sự có mặt của từng kết quả đầu vào, ta được bảng quyết định
như sau:
24
Bảng quyết định
1 2 3 4 5
1 1 1 1 1 0
2 1 1 0
3 0 1
4 1
R1 1 0 0 0 0
R2 0 1 0 0 0
R3 0 0 1 0 0
R4 0 0 0 1 0
R5 0 0 0 0 1
Bước cuối cùng là chuyển đổi bảng quyết định thành các ca kiểm thử. Các ca kiểm
thử thu được như sau:
STT Các điều kiện Ca kiểm thử Hành động
25