Bài giảng Nhập môn công nghệ phần mềm - Đại học Hàng Hải

kiểm thử hệ thống. 
Thông thường, kiểm thử theo cấu trúc tương ứng với mức độ đơn vị, kiểm thử theo chức năng 
tương ứng với mức độ hệ thống. 
Unit Test – Kiểm tra mức đơn vị 
Một Unit là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm tra được. Theo định nghĩa này, 
các hàm (Function), thủ tục (Procedure), lớp (Class), hoặc các phương thức (Method) đều có thể 
được xem là Unit. 
Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt 
trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông thường, Unit Test đòi 
hỏi kiểm tra viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo 
đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập 
và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được 
kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi 
trong một Unit, ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then … else là một nhánh. Thực 
tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm tra và quét hết Unit đòi hỏi phải có kỹ thuật, 
đôi khi phải dùng thuật toán để chọn lựa. 
Cũng như các mức kiểm tra khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các tình huống (test 
case) hoặc kịch bản (script), trong đó chỉ định rõ dữ liệu vào, các bước thực hiện và dữ liệu mong 
chờ sẽ xuất ra. Các test case và script này nên được giữ lại để tái sử dụng. 
Integration Test – Kiểm tra tích hợp 
Integration test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn 
thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp 
chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng. 
Integration Test có 2 mục tiêu chính: 
 Phát hiện lỗi giao tiếp xảy ra giữa các Unit. 
 Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (subsystem) và cuối cùng là nguyên hệ 
thống hoàn chỉnh (system) chuẩn bị cho kiểm tra ở mức hệ thống (System Test). 
Trong Unit Test, 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 tra đơn giản trên giao tiếp giữa Unit 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 thật sự được kiểm tra đầy đủ khi các Unit tích hợp với 
nhau trong khi thực hiện Integration Test. 
Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận 
trước đó bằng Unit Test, 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 
59 
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 (passed) 
các đợt Integration Test trước đó. Lúc này, ta chỉ cần kiểm tra 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 làm cho số lượng kiểm tra sẽ giảm đi rất nhiều, sai 
sót sẽ giảm đáng kể. 
Có 4 loại kiểm tra trong Integration Test: 
 Kiểm tra cấu trúc (structure): Tương tự White Box Test (kiểm tra 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), 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 lệnh và nhánh bên trong. 
 Kiểm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú trọng đến chức 
năng của chương trình, 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 tra hiệu năng (performance): Kiểm tra việc vận hành của hệ thống. 
 Kiểm tra khả năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống. 
System Test - Kiểm tra mức hệ thống 
Mục đích System Test là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu 
cầu đặt ra hay không. System Test bắt đầu khi tất cả các bộ phận của phầm mềm đã được tích hợp 
thành công. Thông thường loại kiểm tra này tốn rất nhiều công sức và thời gian. Trong nhiều trường 
hợp, việc kiểm tra đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các 
ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm 
tra cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu 
cầu khác liên quan đến chất lượng của toàn hệ thống. 
Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành 
vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối 
tượng khi chúng làm việc cùng nhau. Thông thường ta phải thực hiện Unit Test và Integration Test 
để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System 
Test. 
Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các 
thành phần đã được kiểm tra đầy đủ. Tại thời điểm này, lập trình viên hoặc kiểm tra viên (tester) bắt 
đầu kiểm tra phần mềm như một hệ thống hoàn chỉnh. Việc lập kế hoạch cho System Test nên bắt 
đầu từ giai đoạn hình thành và phân tích các yêu cầu. Phần sau ta sẽ nói rõ hơn về một quy trình 
System Test cơ bản và điển hình. 
System Test kiểm tra cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ 
tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm tra này đặc biệt thích hợp cho 
60 
việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi “tắc nghẽn” 
(deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, PM thường đã sẵn sàng cho khách 
hàng hoặc người dùng cuối cùng kiểm tra để chấp nhận (Acceptance Test) hoặc dùng thử 
(Alpha/Beta Test). 
Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực 
hiện bởi một nhóm kiểm tra viên hoàn toàn độc lập với nhóm phát triển dự án. 
Bản thân System Test lại gồm nhiều loại kiểm tra khác nhau (xem hình 3), phổ biến nhất gồm: 
 Kiểm tra chức năng (Functional Test): bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu 
cầu thiết kế. 
 Kiểm tra khả năng vận hành (Performance Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ 
thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn… 
 Kiểm tra khả năng chịu tải (Stress Test hay Load Test): bảo đảm hệ thống vận hành đúng 
dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc). Stress Test tập trung vào các trạng 
thái tới hạn, các “điểm chết”, các tình huống bất thường… 
 Kiểm tra cấu hình (Configuration Test) 
 Kiểm tra khả năng bảo mật (Security Test): bảo đảm tính toàn vẹn, bảo mật của dữ liệu và 
của hệ thống. 
 Kiểm tra khả năng phục hồi (Recovery Test): bảo đảm hệ thống có khả năng khôi phục trạng 
thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối 
với các hệ thống giao dịch như ngân hàng trực tuyến. 
Acceptance Test - Kiểm tra chấp nhận sản phẩm 
Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy 
quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh phần mềm 
thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán 
hợp đồng). 
Regression Test - Kiểm tra hồi quy 
Regression Test kiểm tra lại phần mềm sau khi có một sự thay đổi xảy ra, để bảo đảm phiên bản 
phần mềm mới thực hiện tốt các chức năng như phiên bản cũ và sự thay đổi không gây ra lỗi mới 
trên những chức năng vốn đã làm việc tốt. Regression test có thể thực hiện tại mọi mức kiểm tra. 
Bài tập: 
1. Trình bày phương pháp kiểm thử theo giá trị biên 
2. Trình bày phương pháp kiểm thử theo phân vùng tương đương 
3. Trình bày phương pháp kiểm thử theo đường cơ bản 
61 
62 
MỘT SỐ ĐỀ THI MẪU 
63 
Trƣờng Đại Học Hàng Hải Việt Nam 
Khoa Công nghệ Thông tin 
BỘ MÔN HỆ THỐNG THÔNG TIN 
-----***----- 
THI KẾT THÚC HỌC PHẦN 
Tên học phần: CÔNG NGHỆ PHẦN MỀM 
Năm học: x 
Đề thi số: Ký duyệt đề: 
x x 
Thời gian: 60 phút 
Câu 1: (2 điểm) 
Trình bày các đặc điểm của phần mềm? 
Câu 2: (2 điểm) 
Trình bày các quy trình phát triển phần mềm cố điển? 
Câu 3: (3 điểm) 
Trình bày các kỹ thuật thu thập yêu cầu: Phỏng vấn và Quan sát? 
Câu 4: (3 điểm) 
Trình bày kỹ thuật Mô hình hoá luồng chức năng của hệ thống? 
----------------------------***HẾT***---------------------------- 
Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi 
64 
Trƣờng Đại Học Hàng Hải Việt Nam 
Khoa Công nghệ Thông tin 
BỘ MÔN HỆ THỐNG THÔNG TIN 
-----***----- 
THI KẾT THÚC HỌC PHẦN 
Tên học phần: CÔNG NGHỆ PHẦN MỀM 
Năm học: x 
Đề thi số: Ký duyệt đề: 
x x 
Thời gian: 60 phút 
Câu 1: (2 điểm) 
Trình bày các ứng dụng của phần mềm? 
Câu 2: (2 điểm) 
Trình bày các quy trình phát triển phần mềm cố điển? 
Câu 3: (3 điểm) 
Trình bày các kỹ thuật thu thập yêu cầu: Họp nhóm và Bản câu hỏi? 
Câu 4: (3 điểm) 
Trình bày kỹ thuật Mô hình hoá luồng dữ liệu của hệ thống? 
----------------------------***HẾT***---------------------------- 
Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi 
65 
Trƣờng Đại Học Hàng Hải Việt Nam 
Khoa Công nghệ Thông tin 
BỘ MÔN HỆ THỐNG THÔNG TIN 
-----***----- 
THI KẾT THÚC HỌC PHẦN 
Tên học phần: CÔNG NGHỆ PHẦN MỀM 
Năm học: x 
Đề thi số: Ký duyệt đề: 
x x 
Thời gian: 60 phút 
Câu 1: (2 điểm) 
Trình bày các ứng dụng của phần mềm? 
Câu 2: (2 điểm) 
Biểu đồ luồng dữ liệu là gì? Các quy ước vẽ biểu đồ luồng dữ liệu? 
Câu 3: (3 điểm) 
Trình bày quá trình thiết kế phần mềm? 
Câu 4: (3 điểm) 
Kiểm thử là gì? Trình bày kỹ thuật kiểm thử theo giá trị biên? 
----------------------------***HẾT***---------------------------- 
Lưu ý: - Không sửa, xóa đề thi, nộp lại đề sau khi thi