Báo cáo nghiên cứu khoa học: " ỨNG DỤNG THANH TRA MÃ NGUỒN TRONG TIẾN TRÌNH PHÁT TRIỂN PHẦN MỀM" pdf

TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
1
ỨNG DỤNG THANH TRA MÃ NGUỒN
TRONG TIẾN TRÌNH PHÁT TRIỂN PHẦN MỀM
APPLICATION OF CODE INSPECTION
TO SOFTWARE DEVELOPMENT PROCESS

Nguyễn Thanh Bình
Trường Đại học Bách Khoa, Đại học Đà Nẵng
Nguyễn Thị Hùng
Trường Đại học Thể dục Thể Thao Đà Nẵng

TÓM TẮT
Phát triển phần mềm ngày càng phức tạp và chất lượng phần mềm ngày càng đòi hỏi
cao hơn. Kiểm thử phần mềm là một trong những hoạt động đóng vai trò quan trọng nhằm
nâng cao chất lượng phần mềm. Trong các kỹ thuật kiểm thử phần mềm, thanh tra mã nguồn là
kỹ thuật rất hữu hiệu nhằm phát hiện lỗi tiềm ẩn bên trong mã nguồn phần mềm. Tuy nhiên,
thanh tra mã nguồn thủ công được đánh giá là một công việc khó khăn và chi phí lớn. Vì vậy,
trong bài báo này chúng tôi trình bày giải pháp cải tiến qui trình thanh tra mã nguồn bằng cách
sử dụng các công cụ hỗ trợ phù hợp trong bối cảnh phát triển phần mềm ở Việt Nam nhằm
giảm thời gian và chi phí phát triển.
ABSTRACT
Software development is more and more complex and software quality is more and more
damanding. Software testing plays an important role in the improvement of software quality. In
software testing techniques, code inspection is an effective technique for detecting potential errors
in the code source. However, code inspection is regarded as a difficult and costly task. Hence, in
this paper we present the improvement of a code inspection process by using some automatic
tools to reduce time and cost in the context of software development in Vietnam.

1. Đặt vấn đề
Việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công cụ tiên tiến,

giúp cho việc xây dựng phần mềm đỡ mệt nhọc và hiệu quả hơn. Nhưng cũng chính với
sự phát triển như thế, chất lượng phần mềm ngày càng trở nên quan trọng đối với sự tồn
tại của mỗi phần mềm. Quá trình phát triển ph
ần mềm nguồn mở (PMNM) là quá trình
cho phép phát triển các phần mềm chất lượng và nhanh chóng. Tuy nhiên, chất lượng
phần mềm nguồn mở không được sự bảo đảm của thành viên hay tổ chức nào, chính vì
thế vấn đề thanh tra và kiểm thử phần mềm nguồn mở trở nên yêu cầu bức thiết hơn.
Thanh tra mã nguồn là quá trình dò tìm lỗi tiềm ẩn bên trong mã nguồn phần
mềm sau khi mã nguồn đã hết lỗi cú pháp và trước khi mã nguồn được biên dịch thành
chương trình thực thi [3]. Thanh tra mã nguồn được xem là phương pháp hiệu quả nhất
để phát hiện sớm lỗi tiềm ẩn bên trong mã nguồn, từ đó, giảm chi phí khắc phục lỗi và
nâng cao chất lượng phần mềm.
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
2
Trước đây, khi nói đến thanh tra mã nguồn là nói đến việc đọc từng dòng lệnh
rất thủ công và tốn thời gian. Tuy nhiên, với những môi trường phát triển ứng dụng hiện
nay những hạn chế đó có thể được cải thiện rất nhiều. Đối với những môi trường phát
triển như C, Visual Basic, Java… có những công cụ tích hợp sẵn trợ giúp cho việc thanh
tra mã nguồn rất mạnh. Để ứng dụng tốt công cụ hỗ trợ thanh tra, cần phải đánh giá, sắp
xếp lại các công cụ và đề xuất một qui trình thanh tra hiệu quả hơn.
Bài báo này được tổ chức như sau: mục 2 trình bày tổng quan về kỹ thuật thanh
tra mã nguồn; các loại lỗi phần mềm cần thanh tra được trình bày và phân tích ở mục 3;
mục 4 trình bày một số các công cụ hỗ trợ thanh tra mã nguồn; từ đó, đề xuất cải tiến
quy trình thanh tra mã nguồn kết hợp sử dụng các công cụ tự động được trình bày trong
mục 5; một số kết quả và đánh giá được trình bày trong mục 6; và cuối cùng là phần kết
luận.
2. Thanh tra mã nguồn
Thanh tra mã nguồn là một dạng của thanh tra phần mềm. Đó là tiến trình dò tìm
lỗi tiềm ẩn bên trong mã nguồn phần mềm sau khi mã nguồn đã hết lỗi cú pháp và trước
khi mã nguồn được biên dịch thành chương trình thực thi [3].

Tiến trình thanh tra được các công ty phần mềm áp dụng và linh động tùy theo
điều kiện của mình. Trong thực tế, mỗi nhóm thanh tra mã nguồn khoảng 4 – 6 người.
Thời gian cho mỗi lần họp nhóm không quá 2 giờ. Thông thường, báo cáo lỗi của nhóm
thanh tra được xem là tốt nếu có trên 70% mà tác giả của nó bắt buộc phải sửa (tức là lỗi
thực sự mà tác giả của mã nguồn phải công nhận). Nếu đọc mã nguồn thủ công thì trung
bình mỗi thanh tra viên có thể đọc khoảng 120 dòng mã nguồn mỗi giờ. Mỗi buổi họp
nhóm (khoảng 2 giờ) có thể duyệt qua được tối đa khoảng 1200 dòng mã nguồn [5] [6].
3. Các loại lỗi cần thanh tra
Lỗi trong mã nguồn rất đa dạng, năng suất phát hiện lỗi tùy thuộc nhiều vào kỹ
năng phân tích mã nguồn của các thanh tra viên. Lỗi cần thanh tra được phân chia thành
từng nhóm tương ứng với đặc điểm của đối tượng lập trình. Gồm các nhóm lỗi cơ bản sau:
- Lỗi dữ liệu: các lỗi liên quan đến xử l ý dữ liệu và kiểu dữ liệu.
- Lỗi cấu trúc điều khiển: các lỗi liên quan đến các lệnh cấu trúc điều khiển.
- Lỗi nhập xuất: các lỗi liên quan đến các xử l ý tệp, nhập, xuất dữ liệu.
- Lỗi giao tiếp giữa các hàm, thủ tục: các lỗi liên quan đến định nghĩa và sử dụng hàm.
- Lỗi sử dụng bộ nhớ: các lỗi liên quan đến xử lý bộ nhớ.
3.1. Lỗi dữ liệu
Bảng 1. Danh sách lỗi dữ liệu cần kiểm tra
STT Lỗi cần kiểm tra
1 Tính toán trên các biến không phải kiểu số?
2 Tính toán kiểu dữ liệu hỗn hợp?
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
3
3 Tính toán trên các biến có độ dài khác nhau?
4 Vùng nhớ có kích thước nhỏ hơn giá trị gán?
5 Kết quả tức thời tràn bộ nhớ?
6 Lỗi chia 0?
7 Biểu thức nhị phân không chính xác?
8 Giá trị của các biến ngoài vùng có nghĩa?
9 Các toán tử ưu tiên ngầm hiểu đúng hay không?

10 Các phép chia số nguyên chính xác không?
11 So sánh các biến không hợp kiểu?
12 So sánh kiểu hỗn hợp đúng không?
13 Các quan hệ so sánh chính xác không?
14 Các biểu thức logic đã chính xác chưa?
15 So sánh các giá trị nhị phân và thập phân đúng không?
16 Trình biên dịch ngầm hiểu các biểu thức logic không?
17 Sự phù hợp của các phép so sánh và các biểu thức logic?
18 Thứ tự ưu tiên của các toán tử so sánh có được ngầm hiểu đúng không?
3.2. Lỗi cấu trúc điều khiển
Bảng 2. Danh sách lỗi cấu trúc điều khiển cần kiểm tra
STT Lỗi cần kiểm tra
1 Rẽ nhiều nhánh có vượt qua?
2 Mỗi vòng lặp dừng hay không?
3 Chương trình dừng hay không?
4 Vòng lặp có bị bỏ qua vì điều kiện đầu vào?
5 Vòng lặp có thể bỏ qua có chính xác không?
6 Lỗi sai khác một lần lặp?
7 Câu lệnh thực hiện/kết thúc có phù hợp?
8 Không vét cạn các nhánh trong cấu trúc quyết định?
9 Lỗi chính tả, ngữ pháp trong thông tin đầu vào?
3.3. Lỗi nhập xuất
Bảng 3. Danh sách lỗi nhập xuất cần kiểm tra
STT Lỗi cần kiểm tra
1 Các thuộc tính tệp tin chính xác không?
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
4
2 Các câu lệnh mở tệp tin chính xác không?
3 Các chỉ định định dạng phù hợp với câu lệnh nhập, xuất?
4 Kích thước bộ đệm phù hợp với kích thước bản ghi?

5 Các tệp tin đã được mở trước khi sử dụng?
6 Các tệp tin được đóng sau khi sử dụng?
7 Các điều kiện kết thúc tệp tin được xử lý?
8 Các lỗi nhập xuất được xử lý?
9 Kiểm tra tính hợp lệ cho các đầu vào?
3.4. Lỗi giao tiếp giữa các hàm, thủ tục
Bảng 4. Danh sách lỗi giao tiếp cần kiểm tra
STT Lỗi cần kiểm tra
1 Số tham số đầu vào bằng số đối số?
2 Các thuộc tính của tham số và đối số phù hợp nhau?
3 Hệ thống đơn vị của tham số và đối số phù hợp nhau?
4 Số các đối số được truyền tới mô-đun gọi bằng số tham số?
5 Các thuộc tính của các đối số được truyền tới các mô-đun gọi bằng
các thuộc tính của các tham số?
6 Hệ thống đơn vị của các đối số được truyền tới các mô-đun gọi bằng
hệ thống đơn vị của các tham số?
7 Thuộc tính, thứ tự và số các tham số trong các hàm xây dựng sẵn là
chính xác?
8 Tham chiếu tới các tham số không phù hợp với điểm vào hiện tại?
9 Thay đổi các đối số chỉ nhập?
10 Các định nghĩa biến toàn cục phù hợp khi dùng trong các mô-đun?
11 Các hằng số truyền như các đối số?
3.5. Lỗi sử dụng bộ nhớ
Bảng 5. Danh sách lỗi sử dụng bộ nhớ cần kiểm tra
STT Lỗi cần kiểm tra
1 Sử dụng biến chưa khai báo?
2 Chỉ số nằm trong giới hạn?
3 Chỉ số không phải là số nguyên?
4 Lỗi tham chiếu rỗng?
5 Các thuộc tính đúng khi đặt bí danh?

TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
5
6 Các thuộc tính cấu trúc và bản ghi phù hợp?
7 Tính toán địa chỉ của dãy bit? Truyền đối số dãy bit?
8 Các thuộc tính lưu trữ chính xác?
9 Cấu trúc định nghĩa phù hợp trong các thủ tục?
10 Lỗi sai khác một lần lặp trong các chỉ mục hay phép toán trên chỉ số?
11 Các yêu cầu thừa kế thoả mãn?
12 Các biến đã được khai báo?
13 Các thuộc tính mặc định đúng?
14 Các mảng và chuỗi đã được khởi tạo?
15 Gán đúng các độ dài, kiểu và lớp lưu trữ?
16 Sự khởi tạo phù hợp với các lớp lưu trữ?
17 Các biến có tên giống nhau?
4. Các công cụ hỗ trợ thanh tra
Có nhiều công cụ hỗ trợ thanh tra mã nguồn được phát triển, trong phần này
chúng tôi trình bày một số công cụ nổi bật và được sử dụng trong tiến trình thanh tra đề
xuất ở mục tiếp theo.
4.1. Trình gỡ rối
Trình gỡ rối hỗ trợ cách tìm lỗi trong thời gian chạy bằng cách tác động các yếu
tố trong chương trình lẫn nhau, quan sát các biến và thử chúng với những giá trị khác
nhau. Ưu điểm chính của trình gỡ rối là cho phép lập trình viên xâm nhập nhanh chóng
và chính xác vào trong chính mã lệnh của chương trình. Tại điểm dừng bất kỳ, để theo
dõi các giá trị chúng ta sử dụng các cửa sổ. Tại đây, các câu lệnh có thể được gõ trực
tiếp để hiển thị, thay đổi các biến và những công cụ điều khiển.
4.2. Công cụ hỗ trợ đọc mã tìm lỗi tự động
Phần mềm hỗ trợ tìm lỗi tự động được thiết kế để phân tích mã nguồn và tìm ra lỗi.
Intelli J là một IDE (trình soạn thảo mã nguồn tích hợp) cho Java [9]. Ngoài các
tính năng của một IDE, Intelli J IDEA có một plugin (InspectionGadgets) hỗ trợ cho lập
trình viên tiến hành thanh tra mã nguồn Java một cách tự động. Sau khi duyệt qua từng

tập tin mã nguồn, chương trình sẽ liệt kê toàn bộ các lỗi tìm được. Với hơn 600 quy tắc
lỗi định sẵn, Intelli J là một chươ
ng trình hỗ trợ mạnh cho việc phát hiện tự động các lỗi
trong mã nguồn.
FlexeLint for C++ là chương trình hỗ trợ tìm ra lỗi trên mã nguồn C/C++ một
cách tự động. FlexeLint chạy trên nền Unix (phiên bản cho Windows là PC-lint) [7].
Đây là một chương trình rất mạnh với khả năng phát hiện hơn 800 loại lỗi khác nhau.
SSW Code Auditor quét tất cả các tập tin trong project để tìm ra các lỗi trên mã nguồn
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
6
viết bằng C# hay VB.NET [12]. Chương trình cho phép người dùng tạo ra các quy tắc
riêng cho mình và nó được tích hợp thẳng vào Visual Studio NET.
4.3. Công cụ hỗ trợ tiến trình thanh tra
Phần mềm hỗ trợ tiến trình được thiết kế để quản lý tiến trình thanh tra phần mềm.
Code Reviewer là sản phẩm của SmartBear [11]. Chương trình được thiết kế để
hỗ trợ cho việc thanh tra mã nguồn theo cặp (peer review). Tuy nhiên, nó không hỗ trợ
việc tìm ra lỗi có trong mã nguồn một cách tự động.
ReviewPro được phát triển bởi Software Development Technologies
Corporation [10]. Đây là một ứng dụng web hỗ trợ cho việc quản lý toàn bộ tiến trình
thanh tra phần mềm. Chương trình được đánh giá là có công cụ hỗ trợ dò lỗi mạnh với
khả năng giảm được 10 lần lỗi và tiết kiệm được từ 50% đến 80% giá thành.
IBIS là phần mềm nguồn mở hỗ trợ toàn bộ tiến trình thanh tra tổ chức phần
mềm [8].
5. Ứng dụng công cụ hỗ trợ để cải tiến quy trình thanh tra mã nguồn
Chúng tôi đề xuất tiến trình thanh tra với sự hỗ trợ của các công cụ trong hình 1.

Hình 1. Ứng dụng công cụ hỗ trợ trong tiến trình thanh tra.
Lập kế hoạch (Planning): Nhóm thanh tra chuẩn bị những gói mã nguồn cần
thanh tra và các tài liệu liên quan, các phần mềm và phương án hỗ trợ. Trưởng nhóm
thanh tra sắp đặt nhân sự tham gia thanh tra, lên kế hoạch thanh tra, sắp xếp nơi làm

việc, hội họp.
Phân công và phổ biến công việc (Overview): Trưởng nhóm thanh tra phân chia
vai trò và phân công việc cho từng thành viên trong nhóm. Các tác giả mã nguồn cung
cấp những kiến thức cần thiết về các gói mã nguồn và những tài liệu liên quan. Trưởng
nhóm thanh tra phổ biến cách thức và quy trình làm việc đến từng thành viên trong
nhóm.
Dò lỗi (Individual inspection): Thanh tra viên dò tìm lỗi trên các đoạn mã nguồn
Lập kế hoạch
Phân công
Dò lỗi
Họp nhóm
Sửa chữa
Tiếp tục
Công cụ dò lỗi
tự động

Công cụ quản
l ý
tiến trình

TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
7
đã được phân công. Trong bước này, thanh tra viên đặc biệt quan tâm sử dụng các
phương pháp thanh tra có sự hỗ trợ của phần mềm trợ giúp. Thanh tra viên trước hết
thực hiện thanh tra bằng các phần mềm dò lỗi tự động, khoanh vùng các loại lỗi tìm
được và tiếp tục thanh tra bằng bán tự động các lỗi khả nghi nhưng chưa được tìm ra.
Họp nhóm (Inspection meeting): Họp nhóm được tiến hành để cùng nhau quyết
định xem các “lỗi” đã tìm được do từng thanh tra viên có đích thực là lỗi hay không.
Lần lượt từng thanh tra viên sẽ trình bày nhanh về kết quả công việc của mình, cả nhóm
cùng thảo luận, tranh luận để đưa ra quyết định cuối cùng. Bước này kết thúc với danh

sách các lỗi được ghi vào mẫu biểu chính thức để gửi đến tác giả của mã nguồn đang
được thanh tra.
Sửa chữa mã nguồn (Rework): Tác giả mã nguồn tiến hành khắc phục, sửa chữa
những lỗi tìm được do quá trình thanh tra ở các bước trước. Thông thường, trong thực
tế, không phải “lỗi” nào cũng được sửa, bởi vì vẫn có khả năng nhóm thanh tra viên bắt
nhầm lỗi (không phải lỗi thật) và cũng có những “lỗi” không rõ ràng, cần phải tranh
luận.
Tiếp tục công việc (Follow-up): Trưởng nhóm thanh tra tiến hành kiểm tra, bảo
đảm tất cả những lỗi thực sự phải được khắc phục, sửa chữa. Ngoài ra, cũng cần khảo
sát xem có lỗi mới được phát sinh do quá trình sửa chữa hay không. Tùy vào kết quả
công việc, trưởng nhóm phải quyết định xem có cần phải tiếp tục tiến trình thanh tra mã
nguồn hay không; nếu kết quả công việc tốt thì các báo cáo được tổng hợp và tiến trình
dừng.
Các công cụ hỗ trợ quản l ý tiến trình được sử dụng xuyên suốt trong quá trình
thanh tra, bởi tất cả các thanh viên của nhóm thanh tra trong khi các công cụ dò lỗi tự
động được sử dụng trong quá trình dò lỗi của mỗi thanh tra viên.
6. Kết quả và đánh giá
Áp dụng tiến trình thanh tra cùng các công cụ hỗ trợ đề xuất ở trên, chúng tôi
thu nhận được kết quả tổng hợp trong các bảng 6 và 7.
Bảng 6. Khả năng thay thế thanh tra thủ công của các phần mềm dò lỗi tự động

Intelli J PC – lint SSW Code Auditor
Số quy tắc kiểm tra
600 quy tắc 800 quy tắc Không giới hạn
Dò lỗi tự động
Từng dòng, phần
chọn, chương trình
Cả chương trình Từng dòng hoặc cả
chương trình
Định vị mã chết

Tất cả các mã dư
thừa
Macro, lớp, khai báo dư thừa
…
Do người dùng định
nghĩa
Dõi giá trị
Tự động lưu và đối
sánh giá trị
Lưu giá trị, đối sánh và đưa
ra các cảnh báo khi cần
Tự động
Kiểm tra ngữ nghĩa
100 hàm thư viện và các
hàm người dùng
Người dùng tự định
nghĩa
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
8
Bảng 7. Khả năng hỗ trợ tiến trình thanh tra của các phần mềm

Code reviewer ReviewPro IBIS
Liên lạc
Qua chương trình Qua trang Web Qua mạng Internet
Thay thế họp
nhóm
Trao đổi hai chiều
giữa thanh tra viên và
người điều khiển
Mọi thành viên nhận và

gửi thông tin qua tệp log
đính kèm
Thảo luận qua diễn đàn
hoặc qua
P2Pconference
Quản lý tài
liệu
Tài liệu nguồn, đích
và theo vết tiến trình
Tạo cơ sở dữ liệu lưu trữ
theo từng thành viên
Theo tiến trình do
Fagan đề xuất
Xuất báo cáo
kết quả
Không hỗ trợ Người điều hành xử lý và
quyết định bước tiếp theo
Tự tổng hợp và xuất
báo cáo
Đối sánh mã,
quản lý
checklist
Giữa các thành viên
và các phiên bản
Không có Không có
Hiệu năng
quản lý
Giảm 85% công việc
quản lý thanh tra
Giảm 50-80% công việc Quản lý tự động hoàn

toàn
Từ hai bảng trên cho thấy việc sử dụng các công cụ hỗ trợ làm giảm thời gian và
chi phí rất nhiều. Như vậy tiến trình thanh tra đề xuất ở trên nên được ứng dụng vào quy
trình thanh tra trong các ứng dụng phát triển phần mềm hiện nay.
7. Kết luận
Thanh tra mã nguồn là một hoạt động quan trọng để đảm bảo chất lượng phần
mềm. Vấn đề của đề tài là khá mới mẻ ở Việt Nam. Việc nghiên cứu lựa chọn các công
cụ hỗ trợ công việc thanh tra phù hợp giúp cho việc thanh tra đạt hiệu quả cao hơn,
giảm chi phí và thời gian. Việc xây dựng tài liệu thanh tra phần mềm hợp lý sẽ giúp cho
việc tổ chức, quản lý và thực hiện thanh tra có hiệu quả.
Trong khuôn khổ bài báo này, chúng tôi trình bày qui trình thanh tra và các công
cụ hỗ trợ quản lý tiến trình cũng như các công cụ hỗ trợ đọc và dò lỗi, từ đó, áp dụng để
cải tiến qui trình thanh tra.
Kết quả nghiên cứu có thể áp dụng thực tế cho các đề tài và dự án phát triển
phần mềm, nó cũng có thể làm tài liệu tham khảo cho các cơ sở đang tiến tới đưa qui
trình thanh tra mã nguồn thành một qui trình bắt buộc trong dự án phát triển phần mềm
của họ. Đặc biệt, với xu thế sử dụng phần mềm mã nguồn mở như hiện nay thì đề tài
cung cấp những thông tin bổ ích cho người sử dụng trong việc lựa chọn và xác minh
chất lượng phần mềm, thúc đẩy sự phát triển phần mềm nguồn mở nói chung.

TÀI LIỆU THAM KHẢO
[1] Nguyễn Thanh Bình, Phân tích khả năng kiểm thử các đơn vị phần mềm, số 16,
Tạp chí Khoa học và Công nghệ, Đại học Đà Nẵng, 2006.
TẠP CHÍ KHOA HỌC VÀ CÔNG NGHỆ, ĐẠI HỌC ĐÀ NẴNG - SỐ 2(31).2009
9
[2] Huỳnh Phước Danh, Nguyễn Thanh Bình, Tổng quan về kiểm thử hệ thống hướng
đối tượng, Báo cáo tại Hội thảo Quốc gia lần thứ IX - Một số vấn đề chọn lọc của
Công nghệ Thông tin và Truyền thông, Đà Lạt, tháng 6, 2006.
[3] Trần Đan Thư, Phạm Minh Tuấn, Nguyễn Minh Huy, Tổng quan về qui trình công
nghệ và các hệ thống hỗ trợ thanh tra mã nguồn, Báo cáo tại Hội thảo Quốc gia lần

thứ VIII - Một số vấn đề chọn lọc của Công nghệ Thông tin và Truyền thông, 2005.
[4] Glenford J Mayers (1979), The Art of Software Testing, John Wiley & Sons, Inc.
[5] Fagan M. E. ,‘Design and code inspection to reduce errors in program
development’, IBM Systems Journal, Vol.15, No.3., 1976.
[6] Fagan M. E., ‘Advances in software inspections’. IEEE Transaction on Software
Engineering, SE-12 (7), 1986.
[7] Gimpel, FlexeLint/PC-lint for C/C++ : .
[8] IBIS Project,
[9] Intelli J IDEA,
[10] ReviewPro,
[11] SmartBear Code Reviewer, .
[12] SSW Code Auditor, .