KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.69 MB, 202 trang )

Bạn đang đọc: KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM – Tài liệu text

KIỂM THỬ
VÀ ĐẢM BẢO
CHẤT LƯỢNG

PHẦN MỀM

NĂM 2010

MỞ ĐẦU………………………………………………………………………………………………………………………..4
CHƯƠNG 1: CÁC KHÁI NIỆM …………………………………………………………………………………….5
1.1. Các định nghĩa ……………………………………………………………………………………………5
1.2. Vòng đời của việc kiểm nghiệm (testing life cycle):………………………………………..6
1.3. Phân loại kiểm nghiệm: ……………………………………………………………………………….7
1.4. Sự tương quan giữa các công đoạn xây dụng phần mềm và loại kiểm
nghiệm: Mô hình chữ V………………………………………………………………………………………….8
1.5. Sơ lượt các kỹ thuật và công đoạn kiểm nghiệm:…………………………………………….9
CHƯƠNG 2: KIỂM CHỨNG VÀ XÁC NHẬN (V & V ) ……………………………………………….13
2.1. Kiểm chứng và hợp lệ hoá………………………………………………………………………….13
2.1.1. Tổ chức việc kiểm thử phần mềm ……………………………………………………………….14
2.1.2. Chiến lược kiểm thử phần mềm ………………………………………………………………….15
2.1.3. Tiêu chuẩn hoàn thành kiểm thử …………………………………………………………………17
2.2. Phát triển phần mềm phòng sạch (cleanroom software development)………………18
2.2.1. Nghệ thuật của việc gỡ rối………………………………………………………………………….18
2.2.2. Tiến trình gỡ lỗi ………………………………………………………………………………………..18
2.2.3. Xem xét tâm lý …………………………………………………………………………………………19
2.2.4. Cách tiếp cận gỡ lỗi …………………………………………………………………………………..19
CHƯƠNG 3: KIỂM THỬ PHẦN MỀM……………………………………………………………………….22
3.1. Quá trình kiểm thử……………………………………………………………………………………22
3.2. Kiểm thử hệ thống …………………………………………………………………………………….24
3.3. Kiểm thử tích hợp……………………………………………………………………………………..25

CHƯƠNG 7: KIỂM THỬ PHẦN MỀM TRONG CÔNG NGHIỆP ……………………………….95

7.1. QUY TRÌNH KIỂM TRA PHẦN MỀM CƠ BẢN………………………………………..95
7.2. MÔ HÌNH KIỂM TRA PHẦN MỀM TMM (TESTING MATURITY
MODEL)…………………………………………………………………………………………………………….99
7.3. Các công cụ kiểm thử (Test tools)……………………………………………………………..105
7.3.1. TẠI SAO PHẢI DÙNG TEST TOOL ……………………………………………………….105
7.3.2. KHÁI QUÁT VỀ KTTĐ ………………………………………………………………………….106
7.3.3. GIỚI THIỆU CÔNG CỤ KTTĐ: QUICKTEST PROFESSIONAL……………….108
7.3.4. Kiểm thử đơn vị với JUnit………………………………………………………………………..112
CHƯƠNG 8: ƯỚC LƯỢNG GIÁ THÀNH PHẦN MỀM……………………………………………..129
8.1. Giới thiệu ……………………………………………………………………………………………….129
8.2. Năng suất phần mền ………………………………………………………………………………..131
8.3. Kỹ thuật ước lượng………………………………………………………………………………….135
8.4. Mô hình hoá chi phí thuật toán………………………………………………………………….137
8.5. Mô hình COCOMO …………………………………………………………………………………139
8.6. Mô hình chi phí giải thuật trong kế hoạch dự án………………………………………….147
8.7. Nhân viên và khoảng thời gian của dự án …………………………………………………..149
CHƯƠNG 9: QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM ……………………………………………….153
9.1. Chất lượng quá trình và chất lượng sản phẩm:…………………………………………….153
9.2. Chất lượng quá trình và chất lượng sản phẩm:…………………………………………….155
9.3. Đảm bảo chất lượng và các chuẩn chất lượng……………………………………………..156
9.4. Lập kế hoạch chất lượng…………………………………………………………………………..163
9.5. Kiểm soát chất lượng……………………………………………………………………………….164
9.6. CMM/CMMi ………………………………………………………………………………………….165
9.6.2. Cấu trúc của CMM ………………………………………………………………………………….166
9.6.3. So sánh giữa CMM và CMMi …………………………………………………………………..172
CHƯƠNG 10: QUẢN LÝ CẤU HÌNH…………………………………………………………………………174
10.1. Giới thiệu ……………………………………………………………………………………………….174
10.2. Kế hoạch quản trị cấu hình ……………………………………………………………………….176
11.2. Quản lý việc thay đổi……………………………………………………………………………….179
11.3. Quản lý phiên bản và bản phát hành…………………………………………………………..183

11.4. Quản lý bản phát hành ……………………………………………………………………………..186
11.5. Xây dựng hệ thống ………………………………………………………………………………….189
11.6. Các công cụ CASE cho quản trị cấu hình …………………………………………………..190
PHỤ LỤC- CÁC CÂU HỎI ÔN TẬP…………………………………………………………………………..197
1. Chất lượng và đảm bảo chất lượng phần mềm ……………………………………………………197
2. Các độ đo đặc trưng chất lượng phần mềm ………………………………………………………..198
3. Kiểm thử phần mềm ……………………………………………………………………………………….199
4. Quản lý cấu hình phần mềm …………………………………………………………………………….201
TÀI LIỆU THAM KHẢO……………………………………………………………………………………………202

MỞ ĐẦU
Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá là còn
yếu của các công ty phần mềm Việt Nam. Một số công ty trong nước hiện đã đạt các chuẩn
quốc tế CMM/CMMI trong nâng cao năng lực và quản lý chất lượng phần mềm, song chỉ
đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia công cho thị
trường nước ngoài.
Lâu nay, nói đến chất lượng phần mềm, không ít người nghĩ ngay đến vấn đề là xác
định xem phần mềm đó có phát sinh lỗi hay không, có “chạy” đúng như yêu cầu hay không
và cuối cùng thường quy về vai trò của hoạt động kiểm thử phần mềm (testing) như là hoạt
động chịu trách nhiệm chính.
Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tình
của hoạt động phát triển phần mềm, điều họ cần quan tâm là liệu sản phẩm cuối cùng giao
cho họ có đúng hạn hay không và làm việc đúng như họ muốn hay không.
Tuy nhiên theo quan điểm của người phát triển phần mềm, thực tế cho thấy hoạt động
kiểm thử phần mềm là quan trọng, nhưng không đủ để đảm bảo sản phẩm sẽ được hoàn
thành đúng hạn và đúng yêu cầu. Kiểm thử sau cùng để phát hiện lỗi là điều tất nhiên phải
làm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiều

thời gian để sửa chữa.
Thực tế cho thấy, để đảm bảo được hai tiêu chí “đơn giản” trên của khách hàng, đòi hỏi
tổ chức không chỉ vận hành tốt khâu kiểm thử phần mềm, mà phải tổ chức và duy trì sự
hoạt động nhịp nhàng của cả một hệ thống các công việc liên quan đến một dự án phần
mềm, từ đây xuất hiện một khái niệm có tên là “hệ thống quản lý chất lượng phần mềm”
bao gồm các quy trình được thực thi xuyên suốt chu kỳ phát triển của dự án phần mềm
song hành cùng việc kiểm thử phân mềm nhằm đảm bảo chất lượng cho phần mềm khi
chuyển giao cho khách hàng.
Với thực tế trên, là những người làm công tác đào tạo mong muốn cung cấp cho sinh
viên ngành công nghệ phần mềm – những người sẽ là nguồn nhân lực chủ yếu trong tương
lai của các doanh nghiệp phần mềm – những khái niệm, kiến thức và kỹ năng cơ bản ban
đầu về kiểm thử phần mềm, về qui trình quản lý chất lượng, đảm bảo chất lượng phần mềm
thông qua giáo trình (nội bộ) Kiểm thử và đảm bảo chất lượng phần mềm (Software
Testing and Quality Assurrance).
Giáo trình này với mục tiêu cung cấp cho sinh viên công nghệ phần mềm có được kiến
thức và kỹ năng về việc kiểm thử phần mềm, các công đoạn kiểm thử, các loại kiểm thử,
công cụ kiểm thử, xây dựng tài liệu kiểm thử, dữ liệu kiểm thử …. Và xây qui trình đảm
bảo chất lượng phần mềm, giới thiệu tổng quan về hệ thống quản lý chất lượng, nguyên
tắc, kỹ thuật … để đảm bảo rằng dự án phần mềm sẽ chuyển giao cho khách hàng đúng
hạn, đúng yêu cầu.
Đây là giáo trình sơ khởi, còn nhiều vấn đề chưa đi sâu phân tích và thực hiện, còn
mang tính lý thuyết nhiều. Tác giả hy vọng bạn đọc đóng góp ý kiến để phiên bản 2 đáp
ứng tốt hơn yêu cầu của nhiều độc giả, của sinh viên và kể cả những người đang công tác
tại các phòng phát triển và đảm bảo chất lượng phần mềm.

CHƯƠNG 1: CÁC KHÁI NIỆM

Các định nghĩa

1.1.

“Lỗi phần mềm là chuyện hiển nhiên của cuộc sống. Chúng ta dù cố gắng đến mức nào
thì thực tế là ngay cả những lập trình viên xuất sắc nhất cũng không có thể lúc nào cũng
viết được những đoạn mã không có lỗi. Tính trung bình, ngay cả một lập trình viên loại tốt
thì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước lượng rằng việc kiểm tra để tìm
ra các lỗi này chiếm phân nửa khối lượng công việc phải làm để có được một phần mềm
hoạt động được”. (Software Testing Techniques, Second Edition, by Boris Beizer, Van
Nostrand Reinhold, 1990, ISBN 1850328803).
Trên đây là một nhận định về công việc kiểm nghiệm (testing) chương trình.
Thật vậy, ngày nay càng ngày các chương trình (các phần mềm) càng trở lên phức
tạp và đồ sộ. Việc tạo ra một sản phẩm có thể bán được trên thị trường đòi hỏi sự nổ
lực của hàng chục, hàng trăm thậm chí hàng ngàn nhân viên. Số lượng dòng mã lên
đến hàng triệu. Và để tạo ra một sản phẩm thì không phải chỉ do một tổ chức đứng ra
làm từ đầu đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sản phẩm, thư viện
lập trình, … của nhiều tổ chức khác nhau… Từ đó đòi hỏi việc kiểm nghiệm phần
mềm càng ngày càng trở nên rất quan trọng và rất phức tạp.
Song song với sự phát triển các công nghệ lập trình, các ngôn ngữ lập trình… thì các
công nghệ và kỹ thuật kiểm nghiệm phần mềm ngày càng phát triển và mang tính
khoa học. Bài tiểu luận này với mục đích là tập hợp, nghiên cứu, phân tích các kỹ
thuật, các công nghệ kiểm nghiệm phần mềm đang được sử dụng và phát triển hiện
nay.
1.1.1. Định nghĩa:
Việc kiểm nghiệm là quá trình thực thi một chương trình với mục đích là tìm ra lỗi.
(Glen Myers)
Giải thích theo mục đích:
Việc thử nghiệm hiển nhiên là nói đến các lỗi (error), sai sót (fault), hỏng hóc (failure)
hoặc các hậu quả (incident). Một phép thử là một cách chạy phần mềm theo các

trường hợp thử nghiệm với mục tiêu là:
ƒ

Tìm ra sai sót.

Giải thích sự hoạt động chính xác.
(Paul Jorgensen)

1.1.2. Các thuật ngữ:
ƒ

Lỗi (Error):
– Là các lỗi lầm do con người gây ra.

Sai sót (Fault):
– Sai sót gây ra lỗi. Có thể phân loại như sau:

•

Sai sót do đưa ra dư thừa – chúng ta đưa một vài thứ không chính
xác vào mô tả yêu cầu phần mềm.

•

Sai sót do bỏ sót – Người thiết kế có thể gây ra sai sót do bỏ sót, kết
quả là thiếu một số phần đáng ra phải có trong mô tả yêu cầu phần
mềm.

Hỏng hóc (Failure):
– Xảy ra khi sai sót được thực thi. (Khi thực thi chương trình tại các nơi
bị sai thì sẽ xảy ra trạng thái hỏng hóc).

Kết quả không mong đợi, hậu quả (Incident)
– Là những kết quả do sai sót đem đến. Hậu quả là các triệu chứng liên
kết với một hỏng hóc và báo hiệu cho người dùng biết sự xuất hiện của
hỏng hóc.

Trường hợp thử (Test case)
– Trường hợp thử được liên kết tương ứng với hoạt động của chương
trình. Một trường hợp thử bao một một tập các giá trị đầu vào và một
danh sách các kết quả đầu ra mong muốn.

Thẩm tra (Verification)
– Thẩm tra là tiến trình nhằm xác định đầu ra của một công đoạn trong
việc phát triển phần mềm phù hợp với công đoạn trước đó.

Xác nhận (Validation)
– Xác nhận là tiến trình nhằm chỉ ra toàn hệ thống đã phát triển xong phù
hợp với tài liệu mô tả yêu cầu.

So sánh giữa Thẩm tra và Xác nhận:

1.2.

Thẩm tra: thẩm tra quan tâm đến việc ngăn chặn lỗi giữa các công đoạn.

Xác nhận: xác nhận quan tâm đến sản phẩm cuối cùng không còn lỗi.
Vòng đời của việc kiểm nghiệm (testing life cycle):

Bảng dưới đây mô tả các công đoạn phát triển một phần mềm và cách khắc phục lỗi.
Lỗi có thể xảy ra trong tất cả các công đoạn từ “Mô tả yêu cầu”, “Thiết kế” đến “Lập
trình”.
Từ công đoạn này chuyển sang công đoạn khác thường nảy sinh các sai sót (do dư thừa
hoặc thiếu theo mô tả yêu cầu).
Đến công đoạn kiểm nghiệm chúng ta sẽ phát hiện ra các hậu quả (các kết quả không mong
muốn).
Quá trình sửa lỗi bao gồm “phân loại lỗi”, “cô lập lỗi” (tìm ra nguyên nhân và nơi gây lỗi),
đề ra “giải pháp sửa lỗi” và cuối cùng là khắc phục lỗi.

Vòng đời của kiểm nghiệm
Lỗi

Sửa lỗi

Mô tả yêu cầu

Giải pháp sửa lỗi
Lỗi

Sai sót
Thiết kế

Cô lập lỗi
Lỗi

Sai sót
Lập trình

Phân loại lỗi

Sai sót

Hậu quả
Kiểm nghiệm

1.3.

Phân loại kiểm nghiệm:

Có 2 mức phân loại:
ƒ

Một là phân biệt theo mức độ chi tiết của các bộ phận hợp thành phần mềm.
– Mức kiểm tra đơn vị (Unit)
– Mức kiểm tra hệ thống (System)
– Mức kiểm tra tích hợp (Integration)

Cách phân loại khác là dựa trên phương pháp thử nghiệm (thường dùng ở mức
kiểm tra đơn vị)
– Kiểm nghiệm hộp đen (Black box testing) dùng để kiểm tra chức năng.
– Kiểm nghiệm hộp trắng (White box testing) dùng để kiểm tra cấu trúc.

Hình bên dưới biểu diễn sự tương quan của “các tiêu chí chất lượng phần mềm”, “mức độ
chi tiết đơn vị” và “phương pháp kiểm nghiệm”

Đặc điểm
An toàn
Ổn định
Thiết thực
Khả năng thi hành
Thân thiện người dùng

Chức năng
Phương pháp
Đơn vị (Unit)
Thành phần (Module)
Tích hợp (Integration)

White-box

Black-box

Hệ thống (System)
Mức độ chi tiết
1.4.

Sự tương quan giữa các công đoạn xây dụng phần mềm và loại kiểm
nghiệm: Mô hình chữ V

Mô hình này nhằm giải thích sự tương quan giữa các công đoạn xây dựng phần mềm và
các loại kiểm nghiệm. Ở mỗi công đoạn xây dựng phần mềm sẽ tương ứng với một loại
kiểm nghiệm và cần có một hồ sơ kiểm nghiệm tương ứng được thành lập để phục vụ cho
việc kiểm nghiệm.
Ví dụ:
–

Công đoạn: Yêu cầu phần mềm(requiements); Loại kiểm nghiệm: Kiểm nghiệm
chấp nhận (acceptance test); Hồ sơ: hồ sơ kiểm nghiệm chấp nhận (acceptance test
spec).

–

Công đoạn: Mô tả chi tiết phần mềm (specification); Loại kiểm nghiệm: Kiểm
nghiệm hệ thống(system test); Hồ sơ: hồ sơ kiểm nghiệm hệ thống (system test
spec).

–

Công đoạn: Hồ sơ kiến trúc (architecture spec); Loại kiểm nghiệm: Kiểm nghiệm
tích hợp (integration test); Hồ sơ: hồ sơ kiểm nghiệm tích hợp (integration test
spec).

–

Công đoạn: Thiết kế chi tiết (detailed design); Loại kiểm nghiệm: Kiểm nghiệm
khối (module test); Hồ sơ: hồ sơ kiểm nghiệm khối (module test spec).

–

Công đoạn: Viết mã (implementation code); Loại kiểm nghiệm: Kiểm nghiệm
đơn vị (unit test); Hồ sơ: hồ sơ kiểm nghiệm đơn vị (unit test spec).

acceptance test spec
acceptance test

requiements

system test spec
system test

specification

architecture
spec Sai sót

integration test spec
integration test

module test spec
module test

detailed design

unit test spec
implementation
code

unit test

Sơ lượt các kỹ thuật và công đoạn kiểm nghiệm:

1.5.

Các kỹ thuật và công đoạn kiểm nghiệm có thể chia như sau:
ƒ

Kiểm nghiệm tầm hẹp: kiểm nghiệm các bộ phận riêng rẽ.
– Kiểm nghiệm hộp trắng (White box testing)
– Kiểm nghiệm hộp đen (Black box testing)

Kiểm nghiệm tầm rộng:
– Kiểm nghiệm bộ phận (Module testing): kiểm nhiệm một bộ phận riêng
rẽ.
– Kiểm nghiệm tích hợp (Itegration testing): tích hợp các bộ phận và hệ
thống con.
– Kiểm nghiệm hệ thống (System testing): kiểm nghiệm toàn bộ hệ thống.
– Kiểm nghiệm chấp nhận (Acceptance testing): thực hiện bởi khách
hàng.

1.5.1. Các loại kiểm nghiệm tầm hẹp:
Các loại kiểm nghiệm này đựơc thực hiện để kiểm nghiệm đến các đơn vị (unit) hoặc các
khối chức năng (module).
a. Kiểm nghiệm hộp trắng (white-box testing)
Còn gọi là kiểm nghiệm cấu trúc. Kiểm nghiệm theo cách này là loại kiểm nghiệm sử dụng
các thông tin về cấu trúc bên trong của ứng dụng. Việc kiểm nghiệm này dựa trên quá trình
thực hiện xây dựng phần mềm.
Tiêu chuẩn của kiểm nghiệm hộp trắng phải đáp ứng các yêu cầu như sau:
ƒ

Bao phủ dòng lệnh: mỗi dòng lệnh ít nhất phải được thực thi 1 lần

Bao phủ nhánh: mỗi nhánh trong sơ đồ điều khiển (control graph) phải được đi

qua một lần.

Bao phủ đường: tất cả các đường (path) từ điểm khởi tạo đến điểm cuối cùng
trong sơ đồ dòng điều khiển phải được đi qua.

b. Kiểm nghiệm hộp đen (black-box testing)
Còn gọi là kiểm nghiệm chức năng. Việc kiểm nghiệm này được thực hiện mà không cần
quan tâm đến các thiết kế và viết mã của chương trình. Kiểm nghiệm theo cách này chỉ
quan tâm đến chức năng đã đề ra của chương trình. Vì vậy kiểm nghiệm loại này chỉ dựa
vào bản mô tả chức năng của chương trình, xem chương trình có thực sự cung cấp đúng
chức năng đã mô tả trong bản chức năng hay không mà thôi.
Kiểm nghiệm hộp đen dựa vào các định nghĩa về chức năng của chương trình. Các trường
hợp thử nghiệm (test case) sẽ được tạo ra dựa nhiều vào bản mô tả chức năng chứ không
phải dựa vào cấu trúc của chương trình.
c. Vấn đề kiểm nghiệm tại biên:
Kiểm nghiệm biên (boundary) là vấn đề được đặt ra trong cả hai loại kiểm nghiệm hộp đen
và hộp trắng. Lý do là do lỗi thường xảy ra tại vùng này.
Ví dụ:
if x > y then S1 else S2
Với điều kiện bao phủ, chỉ cần 2 truờng hợp thử là x>y và x<=y.
Với kiểm nghiệm đường biên thì kiểm tra với các trường hợp thử là x>y, xCác loại kiểm nghiệm tầm rộng:
Việc kiểm nghiệm này thực hiện trên tầm mức lớn hơn và các khía cạnh khác của phần
mềm như kiểm nghiệm hệ thống, kiểm nghiệm sự chấp nhận (của người dùng)…

a. Kiểm nghiệm Module (Module testing)
Mục đích: xác minh module đưa ra đã được xây dựng đúng hay chưa?
Vấn đề đặt ra: giả sử module I sử dụng các module H, K. Nhưng các module H và K chưa
sẳn sàng. Vậy cách nào để kiểm tra module I một cách độc lập?
Giải pháp đề ra là giả lập môi trường của module H và K.
Thông thường một module có thể gọi một tác vụ (hay một tiến trình) không phải của nó,
truy cập các cấu trúc dữ liệu không phải là cục bộ, hay được dùng bởi một module khác.
Hình sau mô tả module được đặt trong môi trường thử nghiệm.

PROCEDURE
UNDER TEST

STUB
CALL

DRIVER
CALL

ACCESS TO NONLOCAL VARIABLES

Ghi chú: Driver là module gọi thực thi làm cho module cần kiểm tra hoạt động, nó giả lập
các module khác sẽ sử dụng module này. Các tập dữ liệu chia sẻ mà các module khác thiết
lập trong thực tế cũng được thiết lập ở drive. Stub là module giả lập các module được
module đang kiểm tra sử dụng.
b. Kiểm nghiệm tích hợp:
Là cách kiểm nghiệm bằng cách tích hợp vào hệ thống từng module một và kiểm tra.
Ưu điểm:
ƒ

Dễ dàng tìm ra các lỗi vào ngay giai đoạn đầu.

Dễ dàng khoanh vùng các lỗi (tích hợp n modules, sau đó n + 1
modules).

Giảm việc sử dụng các stub và Driver

Có thể thực hiệm kiểm nghiệm tích hợp theo cả 2 cách bottom-up và top-down tùy thuộc
vào mối quan hệ sử dụng lần nhau giữa các module.
c. Kiểm nghiệm hệ thống:
Bao gồm một loạt các kiểm nghiệm nhằm xác minh toàn bộ các thành phần của hệ thống
được tích hợp một cách đúng đắn.

Mục đích của kiểm nghiệm hệ thống là để đảm bảo toàn bộ hệ thống hoạt động như ý mà
khách hàng mong muốn.
Bao gồm các loại kiểm nghiệm sau:
ƒ

Kiểm nghiệm chức năng (Function testing)
Kiểm tra hệ thống sau khi tích hợp có hoạt động đúng chức năng với
yêu cầu đặt ra trong bản mô tả yêu cầu hay không.
Ví dụ: với hệ thống xử lý văn bản thì kiểm tra các chức năng tạo tài
liệu, sửa tài liệu, xoá tài liệu… có hoạt động hay không.

Kiểm nghiệm hiệu suất (Perfomance testing)

Kiểm nghiệm mức độ đáp ứng (stress testing)
Thực thi hệ thống với giả thiết là các tài nguyên hệ thống yêu cầu
không đáp ứng được về chất lượng, ổn định và số lượng.

Kiểm nghiệm cấu hình (configuration tessting)
Phân tích hệ thống với các thiết lập cấu hình khác nhau.

Kiểm nghiệm ổn định (robustness tessting)
Kiểm nghiệm dưới các điều kiện không mong đợi ví dụ như người
dùng gõ lệnh sai, nguồn điện bị ngắt.

Kiểm nghiệm hồi phục (recovery testing)
Chỉ ra các kết quả trả về khi xảy ra lỗi, mất dữ liệu, thiết bị, dịch
vụ… hoặc xoá các dữ liệu hệ thống và xem khả năng phục hồi của
nó.

Xem thêm: Top 3 Phần Mềm Quản Lý Nhân Sự Chuyên Nghiệp

Kiểm nghiệm quá tải (overload testing)
Đánh giá hệ thống khi nó vượt qua giới hạn cho phép. Ví dụ: một hệ
thống giao tác (transaction) được yêu cầu thực thi 20 giao tác/giây.
Khi đó sẽ kiểm tra nếu 30 giao tác/giây thì như thế nào?

Kiểm nghiệm chất lượng (quality testing)
Đánh giá sự tin tưởng, vấn đề duy tu, tính sẳn sàng của hệ thống.
Bao gồm cả việc tính toán thời gian trung bình hệ thống sẽ bị hỏng
và thời gian trung bình để khắc phục.

Kiểm nghiệm cài đặt (Installation testing)
Người dùng sử dụng các chức năng của hệ thống và ghi lại các lỗi
tại vị trí sử dụng thật sự.
Ví dụ: một hệ thống được thiết kế để làm việc trên tàu thủy phải
đảm bảo không bị ảnh hưởng gì bởi điều kiện thời tiết khác nhau
hoặc do sự di chuyển của tàu.

d. Kiểm nghiệm chấp nhận
Nhằm đảm bảo việc người dùng có được hệ thống mà họ yêu cầu. Việc kiểm nghiệm này
hoàn thành bởi người dùng phụ thuộc vào các hiểu biết của họ vào các yêu cầu.
12

CHƯƠNG 2: KIỂM CHỨNG VÀ XÁC NHẬN (V & V )
2.1. Lập kế hoạch V&V (Verification and validation planning)
2.2. Kiểm tra phần mềm (Software inspections)

2.3. Phân tích tĩnh tự động (Automated static analysis)
2.4. Phát triển phần mềm phòng sạch (Cleanroom software development)

2.1.

Kiểm chứng và hợp lệ hoá

Kiểm thử phần mềm là một yếu tố trong chủ điểm rộng hơn thường được tham
khảo tới như vấn đề kiểm chứng và hợp lệ hoá (V&V). Kiểm chứng nói tới một tập
các hành động đảm bảo rằng phần mềm cài đặt đúng cho một chức năng đặc biệt.
Hợp lệ hoá nói tới một tập các hoạt động khác đảm bảo rằng phần mềm đã được xây
dựng lại theo yêu cầu của khách hàng. Bochm phát biểu điều này theo cách khác:
Kiểm chứng: “Chúng ta có làm ra sản phẩm đúng không? ”
Hợp lệ hoá: “Chúng ta có làm ra đúng sản phẩm không? ”
Định nghĩa về V&V bao quát nhiều hoạt động ta đã tham khảo tới như việc đảm bảo
chất lượng phần mềm (SQA).
Các phương pháp kỹ nghệ phần mềm cung cấp nền tảng để xây dựng nên chất lượng.
Các phương pháp phân tích, thiết kế và thực hiện (mã hoá) làm nâng cao chất lượng
bằng cách đưa ra những kỹ thuật thống nhất và kết quả dự kiến được. Các cuộc họp
xét duyệt kỹ thuật chính thức (thảo trình) giúp đảm bảo chất lượng của sản phẩm
được tạo ra như hệ quả của từng bước kỹ nghệ phần mềm. Qua toàn bộ tiến trình
này, việc đo đạc và kiểm soát được áp dụng cho mọi phần tử của cấu hình phần mềm.
Các chuẩn và thủ tục giúp đảm bảo tính thống nhất và tiến trình SQA chính thức
buộc phải thi hành “ triết lý chất lượng toàn bộ ”.
Việc kiểm thử cung cấp một thành luỹ cuối cùng để có thể thẩm định về chất lượng,
lỗi có thể được phát hiện ra một cách thực tế hơn.
Nhưng không nên coi kiểm thử như một tấm lưới an toàn. Như người ta vẫn nói, “
Bạn không thể kiểm thử được chất lượng. Nếu nó không sẵn có trước khi bạn bắt đầu
kiểm thử thì nó sẽ chẳng có khi bạn kết thúc kiểm thử.” Chất lượng được tổ hợp vào
trong phần mềm trong toàn bộ tiến trình kỹ nghệ phần mềm. Việc áp dụng đúng các

phương pháp và công cụ, các cuộc họp xét duyệt kỹ thuật chính thức và việc quản lý
vững chắc cùng cách đo đạc tất cả dẫn tới chất lượng được xác nhận trong khi kiểm
thử.

Hình 2.1 Đạt đến chất lượng phần mềm
Miller kể lại việc kiểm thử phần mềm về đảm bảo chất lượng bằng cách nói rằng
“động cơ nền tảng của việc kiểm thử chương trình là để xác nhận chất lượng phần
mềm bằng những phương pháp có thể được áp dụng một cách kinh tế và hiệu quả
cho cả các hệ thống quy mô lớn và nhỏ.”
Điều quan trọng cần lưu ý rằng việc kiểm chứng và hợp lệ hoá bao gồm một phạm vi
rộng các hoạt động SQA có chứa cả họp xét duyệt chính thức, kiểm toán chất lượng
và cấu hình, điều phối hiệu năng, mô phỏng, nghiên cứu khả thi, xét duyệt tài liệu, xét
duyệt cơ sở dữ liệu, phân tích thuật toán, kiểm thử phát triển, kiểm thử chất lượng,
kiểm thử cài đăt. Mặc dầu việc kiểm thử đóng một vai trò cực kỳ quan trọng trong
V&V, nhiều hoạt động khác cũng còn cần tới.

2.1.1. Tổ chức việc kiểm thử phần mềm
Với mọi dự án phần mềm, có một mâu thuẫn cố hữu về lợi ích xuất hiện ngay khi
việc kiểm thử bắt đầu. Người đã xây phần mềm bây giờ được yêu cầu kiểm thử phần
mềm. Điều này bản thân nó dường như vô hại; sau rốt, ai biết được chương trình kỹ
hơn là người làm ra nó? Nhưng không may, cũng những người phát triển này lại có
mối quan tâm chứng minh rằng chương trình là không có lỗi, rằng nó làm việc đúng
theo yêu cầu khách hàng, rằng nó sẽ được hoàn tất theo lịch biểu và trong phạm vi
ngân sách. Một trong những mối quan tâm này lại làm giảm bớt việc tìm ra lỗi trong
toàn bộ tiến trình kiểm thử.
Theo quan điểm tâm lý, việc phân tích và thiết kế phần mềm (cùng với mã hoá) là
nhiệm vụ xây dựng. Người kỹ sư phần mềm tạo ra một chương trình máy tính, tài liệu

về nó và các cấu trúc dữ liệu có liên quan. Giống như bất kỳ người xây dựng nào,
người kỹ sư phần mềm tự hào về dinh thự đã được xây dựng và nhìn ngờ vực vào bất

kỳ ai định làm sập đổ nó. Khi việc kiểm thử bắt đầu, có một nỗ lực tinh vi, dứt khoát
để “đập vỡ” cái người kỹ sư phần mềm đã xây dựng. Theo quan điểm của người xây
dựng, việc kiểm thử có thể được coi như (về tâm lý) có tính phá hoại. Cho nên người
xây dựng dè dặt đề cập tới việc kiểm thử thiết kế và thực hiện sẽ chứng tỏ rằng
chương trình làm việc, thay vì phát hiện lỗi. Điều không may lỗi sẽ hiện hữu. Và nếu
người kỹ sư phần mềm không tìm ra chúng thì khách hàng sẽ tìm ra.
Thường có một số nhận thức sai có thể được suy diễn sai lạc từ thảo luận trên: (1)
người phát triển phần mềm không nên tiến hành kiểm thử; (2) phần mềm nên được
“tung qua tường ” cho người lạ làm việc kiểm thử một cách tàn bạo; (3) người kiểm
thử nên tham gia vào dự án chỉ khi bước kiểm thử sắp sửa bắt đầu. Từng phát biểu
này đều không đúng.
Người phát biểu phần mềm bao giờ cũng có trách nhiệm với việc kiểm thử riêng các
đơn vị (mô đun) chương trình, để đảm bảo rằng mỗi mô đun thực hiện đúng chức
năng nó đã được thiết kế. Trong nhiều trường hợp, người phát triển cũng tiến hành
cả kiểm thử tích hợp – bước kiểm thử dẫn đến việc xây dựng (và kiểm thử) toàn bộ
cấu trúc chương trình. Chỉ sau khi kiến trúc phần mềm hoàn tất thì nhóm kiểm thử
độc lập mới tham gia vào.
Vai trò của nhóm kiểm thử độc lập (ITG) là loại bỏ vấn đề cố hữu liên quan tới việc
để người xây dựng kiểm thử những cái anh ta đã xây dựng ra. Việc kiểm thử độc lập
loại bỏ xung khắc lợi ích nếu không có nhóm đó thì có thể hiện hữu. Cuối cùng nhân
sự trong nhóm kiểm thử độc lập được trả tiền để tìm ra lỗi.
Tuy nhiên, người phát triển phần mềm không chuyển giao chương trình cho ITG rồi
bỏ đi. Người phát triển và ITE làm việc chặt chẽ trong toàn bộ dự án phần mềm để
đảm bảo rằng những kiểm thử kỹ lưỡng sẽ được tiến hành. Trong khi tiến hành kiểm

thử, người phát triển phải có sẳn để sửa chữa lỗi đã phát hiện ra.
ITG là một phần của nhóm dự án phát triển phần mềm theo nghĩa là nó tham dự
trong tiến trình đặc tả và vẫn còn tham dự (lập kế hoạch và xác định các thủ tục kiểm
thử) trong toàn bộ dự án lớn. Tuy nhiên, trong nhiều trường hợp ITG báo cáo cho tổ
chức đảm bảo chất lượng phần mềm, do đó đạt tới một mức độ độc lập có thể không
có được nếu nó là một phần của tổ chức phát triển phần mềm.

2.1.2. Chiến lược kiểm thử phần mềm
Tiến trình kỹ nghệ phần mềm có thể được xét theo vòng xoắn ốc, như được minh
hoạ trong Hình 2.2. Ban đầu, kỹ nghệ phần mềm xác định vai trò của phần mềm và
đưa tới việc phân tích yêu cầu phần mềm, chỗ thiết lập nên lĩnh vực thông tin, chức
năng, hành vi, hiệu năng, ràng buộc và tiêu chuẩn hợp lệ cho phần mềm. Đi vào trong
vòng xoắn ốc, chúng ta tới thiết kế và cuối cùng tới mã hoá. Để xây dựng phần mềm
máy tính, chúng ta đi dọc theo đường xoắn ốc, mỗi lần mức độ trừu tượng lại giảm
dần.
Một chiến lược cho kiểm thử phần mềm cũng có thể xem xét bằng cách đi theo đường
xoắn ốc của Hình 2.2 ra ngoài. Việc kiểm thử đơn vị bắt đầu tại tâm xoáy của xoắn ốc
và tập chung vào các đơn vị của phần mềm khi được cài đặt trong chương trình gốc.
Việc kiểm thử tiến triển bằng cách đi ra theo đường xoắn ốc tới kiểm thử tích hợp,
nơi tập trung vào thiết kế và việc xây dựng kiến trúc phần mềm. Đi thêm một vòng
xoáy nữa trên đường xoắn ốc chúng ta gặp kiểm thử hợp lệ, nơi các yêu cầu, được

thiết lập như một phần của việc phân tích yêu cầu phần mềm, được hợp lệ hoá theo
phần mềm đã được xây dựng. Cuối cùng chúng ta tới kiểm thử hệ thống, nơi phần
mềm và các phần tử hệ thống khác được kiểm thử như một toàn bộ. Để kiểm thử
phần mềm máy tính, chúng ta theo đường xoáy mở rộng dần phạm vi kiểm thử một
lần.

Hình 2.3 Các bước kiểm thử phần mềm
Xem xét tiến trình này theo quan điểm thủ tục vì việc kiểm thử bên trong hoàn
cảnh kỹ nghệ phần mềm thực tại là một chuỗi gồm ba bước được thực hiện tuần tự
nhau. Các bước này được vẽ trong Hình 2.3. Ban đầu, việc kiểm thử tập trung vào
từng mô đun riêng biệt, đảm bảo rằng nó vận hành đúng đắn như một đơn vị. Do đó
mới có tên kiểm thử đơn vị. Kiểm thử đơn vị dùng rất nhiều các kỹ thuật kiểm thử
hộp trắng, thử các đường đặc biệt trong cấu trúc điều khiển của một mô đun để đảm
bảo bao quát đầy đủ và phát hiện ra lỗi tối đa. Tiếp đó các mô đun phải được lắp
ghép hay tích hợp lại để tạo nên bộ trình phần mềm hoàn chỉnh. Việc kiểm thử tích
hợp đề cập tới các vấn đề có liên quan tới các vấn đề kiểm chứng và xây dựng chương
trình. Các kỹ thuật thiết kế kiểm thử hộp đen chiếm đại đa số trong việc tích hợp,
mặc dầu một số giới hạn các kiểm thử hộp trắng cũng có thể dược dùng để đảm bảo
bao quát đa số các đường điều khiển.
Sau khi phần mềm đã được tích hợp (được xây dựng), một tập các phép kiểm thử cao
cấp sẽ được tiến hành. Các tiêu chuẩn hợp lệ (được thiết lập trong phân tích yêu cầu)
cũng phải được kiểm thử. Việc kiểm thử hợp lệ đưa ra sự đảm bảo cuối cùng rằng
phần mềm đáp ứng cho tất cả các yêu cầu chức năng, hành vi và sự hoàn thiện. Các
kỹ thuật kiểm thử hộp đen được dùng chủ yếu trong việc hợp lệ hoá này.
Bước kiểm thử cấp cao cuối cùng rơi ra ngoài phạm vi của kỹ nghệ phần mềm và
rơi vào hoàn cảnh rộng hơn của kỹ nghệ hệ thống máy tính. Phần mềm, một khi được
hợp lệ hoá, phải được tổ hợp với các phần tử hệ thống khác (như phần cứng, con
người, cơ sở dữ liệu). Kiểm thử hệ thống kiểm chứng lại rằng tất cả các yếu tố có

khớp đúng với nhau không và rằng chức năng/ độ hoàn thiện hệ thống toàn bộ đã đạt
được.

2.1.3. Tiêu chuẩn hoàn thành kiểm thử
Câu hỏi cổ điển nảy sinh mỗi khi có việc thảo luận về kiểm thử phần mềm là: Khi
nào chúng ta thực hiện xong kiểm thử – làm sao ta biết rằng chúng ta đã kiểm thử
đủ? Đáng buồn là không có câu trả lời xác định cho câu hỏi này, nhưng có một vài sự
đáp ứng thực tế và những nỗ lực ban đầu theo hướng dẫn kinh nghiệm.
Một đáp ứng cho câu hỏi trên là: Bạn chẳng bao giờ hoàn thành việc kiểm thử,
gánh nặng đơn giản chuyển từ bạn (người phát triển) sang khách hàng của bạn. Mỗi
lúc khách hàng / người dùng thực hiện một chương trình máy tính thì chương trình
này lại được kiểm thử trên một tập dữ liệu mới. Sự kiện đúng mức này nhấn mạnh
tầm quan trọng của các hoạt động đảm bảo chất lượng phần mềm khác. Một đáp ứng
khác (có điều gì đó nhạo báng nhưng dẫu sao cũng chính xác) là : Bạn hoàn thành
việc kiểm thử khi bạn hết thời gian hay hết tiền.
Mặc dầu số ít người thực hành sẽ biện minh cho những đáp ứng trên, người kỹ
sư phần mềm cần những tiêu chuẩn chặt chẽ hơn để xác định khi nào việc kiểm thử
đủ được tiến hành. Musa và Ackerman gợi ý một đáp ứng dựa trên tiêu chuẩn thống
kê: “ Không, chúng ta không thể tuyệt đối chắc chắn rằng phần mềm sẽ không bao
giờ hỏng, nhưng theo mô hình thống kê đúng về lý thuyết và hợp lệ về thực nghiệm
thì chúng ta đã hoàn thành kiểm thử đủ để nói với sự tin tưởng tới 95% rằng xác suất
của 1000 giờ vận hành CPU không hỏng trong một môi trường được xác định về xác
suất là ít nhất 0.995”
Dùng mô hình hoá thống kê và lí thuyết độ tin cậy phần mềm, các mô hình về
hỏng hóc phần mềm (được phát hiện trong khi kiểm thử) xem như một hàm của thời
gian thực hiện có thể được xây dựng ra. Một bản của mô hình sai hỏng, được gọi là
mô hình thực hiện- thời gian Poisson lô ga rit, có dạng:
f(t)= ( 1p ) x ln[ l0(pt +1) ]

(17.1)

với f(t) = số tích luỹ những hỏng hóc dự kiến xuất hiện một khi phần mềm đã
được kiểm thử trong một khoảng thời gian thực hiện t.

l0 = mật độ hỏng phần mềm ban đầu (số hỏng trên đơn vị thời gian) vào lúc
bắt đầu kiểm thử.
P = việc giảm theo hàm mũ trong mật độ hỏng khi lỗi được phát hiện và sữa
đổi được tiến hành.

Mật độ hỏng thể nghiệm. l(t), có thể được suy ra bằng cách lấy đạo hàm của f(t):
l0

F(t) = l 0 pt +1

(17.2)

Dùng mối quan hệ trong phương trình (2.2), người kiểm thử có thể tiên đoán
việc loại bỏ lỗi khi việc kiểm thử tiến triển. Mật độ lỗi thực tại có thể được chấm lên
trên đường cong dự kiến (hình 2.4). Nếu dữ liệu thực tài được thu thập trong khi

kiểm thử và mô hình thực hiện – thời gian theo logarit Poisson là xấp xỉ gần nhau với
số điểm dữ liệu thì mô hình này có thể được dùng để dự đoán thời gian kiểm thử toàn
bộ cần để đạt tới mật độ hỏng thấp chấp nhận được.
Bằng cách thu thập các độ đo trong khi kiểm thử phần mềm và dùng các mô
hình về độ tin cậy phần mềm hiện có, có thể phát triển những hướng dẫn có nghĩa để
trả lời câu hỏi: Khi nào thì chúng ta hoàn thành việc kiểm thử? Còn ít tranh luận về
việc có phải làm công việc thêm nữa hay không trước khi các quy tắc định tính cho
kiểm thử có thể xác định, nhưng cách tiếp cận kinh nghiệm hiện đang tồn tại được coi
là tốt hơn đáng kể so với trực giác thô.

2.2.

Phát triển phần mềm phòng sạch (cleanroom software development)

Cleanroom là một qui trình phát triển phần mềm hơn là một kỹ thuật kiểm thử. Cho
đến bây giờ, kỹ thuật này vẫn được xem là một cách mới của việc suy nghĩ về kiểm
thử và đảm bảo chất lượng phần mềm. Ý tưởng của cleanroom là nhằm tránh tiêu
tốn chi phí cho hoạt động phát hiện và gỡ bỏ các lỗi bằng cách viết mã lệnh chương
trình một cách chính xác ngay từ ban đầu với những phương pháp chính thống như
kỹ thuật chứng minh tính đúng đắn trước khi kiểm thử.
2.2.1. Nghệ thuật của việc gỡ rối
Kiểm thử phần mềm là một tiến trình có thể được vạch kế hoạc và xác định một cách
hệ thống. Việc thiết kế trường hợp kiểm thử có thể tiến hành một chiến lược xác định
và có kết quả được tính toán theo thời gian.
Gỡ lỗi xuất hiện như hậu quả của việc kiểm thử thành công. Tức là, khi một trường
hợp kiểm thử phát hiện ra lỗi thì việc gỡ lỗi là tiến trình sẽ nảy sinh để loại bỏ lỗi.
Mặc dầu việc gỡ lỗi có thể nên là một tiến trình có trật tự, nó phần lớn còn là nghệ
thuật. Người kỹ sư phần mềm khi tính các kết quả của phép thử, thường hay phải
đương đầu với chỉ dẫn “triệu chứng” và vấn đề phần mềm. Tức là, cái biểu lộ ra bên
ngoài của lỗi và nguyên nhân bên trong của lỗi có thể có mối quan hệ không hiển
nhiên tới một lỗi khác. Tiến trình tâm trí ít hiểu biết gắn một triệu chứng với nguyên
nhân chính việc gỡ lỗi.
2.2.2. Tiến trình gỡ lỗi
Gỡ lỗi không phải là kiểm thử, nhưng bao giờ cũng xuất hiện như một hệ quả kiểm
thử. Tham khảo đến hình 2.12 thì tiến trình gỡ lỗi bắt đầu với việc thực hiện kiểm
thử. Kết quả được thẩm định và gặp việc thiếu sự tương ứng giữa kết quả trông đợi
và thực tế. Trong nhiều trường hợp, dữ liệu không tương ứng là triệu chứng của một
nguyên nhân nền tảng còn bị che kín. Tiến trình gỡ lỗi cố gắng ghép triệu chứng với
nguyên nhân, từ đó dẫn tới việc sửa lỗi.
Tiến trình gỡ lỗi bao giờ cũng sinh ra một trong hai kết quả logic: (1) Nguyên
nhân sẽ được tìm ra, sửa chữa và loại bỏ hay (2) nguyên nhân sẽ không được tìm ra.

Trong trường hợp sau, người thực hiện gỡ lỗi có thể hoài nghi một nguyên nhân, thiết
kế ra một trường hợp kiểm thử giúp hợp lệ hoá hoài nghi của mình, và việc lầm
hướng tới việc sửa lỗi theo cách lặp lại.

Tại sao gỡ lỗi lại khó? Rất có thể tâm lý con người (xem mục sau) có liên quan tới
nhiều câu trả lời hơn là công nghệ phần mềm. Tuy nhiên môt vài đặc trưng của lỗi
đưa ra vài manh mối:
o Triệu chứng và nguyên nhân có thể xa nhau về mặt địa lý. Tức là, những
triệu chứng có thể xuất hiện trong một phần này của chương trình, trong khi
nguyên nhân thực tế có thể định vị ở một vị trí xa. Các cấu trúc chương
trình đi đôi với nhau làm trầm trọng thêm tình huống này.
o Triệu chứng có thể biến mất (tạm thời) khi một lỗi khác được sửa chữa.
o Triệu chứng thực tế có thể gây ra không lỗi (như do sự không chính xác của
việc làm tròn số).
o Triệu chứng có thể được gây ra do lỗi con người không dễ lần dấu vết.
o Triệu chứng có thể là kết quả của vấn đề thời gian, thay vì vấn đề xử lý.
o Có thể khó tái tạo lại chính xác các điều kiện vào (như ứng dụng thời gian
thực trong đó thứ tự vào không xác định)
o Triệu chứng có thể có lúc có lúc không. Điều này đặc biệt phổ biến trong
các hệ thống nhúng việc đi đôi phần cứng và phần mềm không chặt chẽ.
o Triệu chứng có thể do nguyên nhân được phân bố qua một số các nhiệm vụ
chạy trên các bộ xử lý khác nhau.
o Trong khi gỡ lỗi, chúng ta gặp không ít các lỗi chạy từ việc hơi khó chịu
(như định dạng cái ra không đúng) tới các thảm hoạ (như hệ thống hỏng,
gây ra các thiệt hại kinh tế hay vật lý trầm trọng). Xem như hậu quả của
việc tăng lỗi, khối lượng sức ép để tìm ra lỗi cũng tăng thêm. Thông
thường, sức ép buộc người phát triển phần mềm phải tìm ra lỗi và đồng thời

đưa vào thêm hai lỗi nữa.
2.2.3. Xem xét tâm lý
Không may, dường như có một số bằng cớ là sự tinh thông gỡ lỗi thuộc bẩm sinh con
người. Một số người làm việc đó rất giỏi, số khác lại không. Mặc dù bằng cớ kinh
nghiệm về gỡ lỗi vẫn còn để mở cho nhiều cách hiểu, nhưng biến thiên lớn nhất trong
khả năng gỡ lỗi đã được báo cáo lại đối với các kỹ sư phần mềm có cùng nền tảng
kinh nghiệm và giáo dục.
Bình luận về khía cạnh gỡ lỗi của con người, Shneiderman phát biểu:
Gỡ lỗi là một trong những phần chán nhất của lập trình. Nó có yếu tố của việc giải
quyết vấn đề hay vấn đề hóc búa, đi đôi với việc thừa nhận khó chịu rằng bạn đã sai
lầm. Hay âu lo và không sẵn lòng chấp nhận khả năng lỗi làm tăng khó khăn cho
công việc. May mắn là có sự giảm nhẹ và bớt căng thẳng khi lỗi cuối cùng đã được
sửa lỗi.
Mặc dầu có thể khó học được việc gỡ lỗi, người ta vẫn đề nghị ra một số cách tiếp cận
tới vấn đề. Chúng ta xem xét những vấn đề này trong mục tiếp.

2.2.4. Cách tiếp cận gỡ lỗi
Bất kể tới cách tiếp cận nào được chọn gỡ lỗi có một mục tiêu quan trọng hơn cả: tìm
ra và sửa chữa nguyên nhân lỗi phần mềm. Mục tiêu này được thực hiện bằng tổ hợp

các đánh giá có hệ thống, trực giác và may mắn. Bradley mô tả cách tiếp cận gỡ lỗi
theo cách này:
Gỡ lỗi là việc ứng dụng trực tiếp phương pháp khó học đã từng được phát triển hơn
2500 năm qua. Cơ sở của việc gỡ lỗi là định vị nguồn gốc của vấn đề [nguyên nhân]
bằng việc phân hoạch nhị phân, thông qua các giả thiết làm việc để dự đoán các giá
trị mới cần kiểm tra.
Ta hãy lấy một ví dụ không phải phần mềm: Đèn trong nhà tôi không làm việc. Nếu

không có gì trong nhà làm việc thì nguyên nhân phải là cầu chì chính hay ở bên
ngoài; tôi nhìn quanh để liệu xem hàng xóm có bị tắt đèn hay không. Tôi cắm chiếc
đèn nghi ngờ vào ổ cắm khác và cắm một đồ điện khác vào mạch nghi ngờ. Cứ thế
tiến hành các phương án giải quyết kiểm thử.

Nói chung, có thể đưa ra ba loại các tiếp cận gỡ lỗi:
•
Bó buộc mạnh bạo
•
Lật ngược
•
Loại bỏ nguyên nhân
Loại bó buộc mạnh bạo có lẽ là phương pháp thông dụng nhất và kém hiệu quả nhất
để cô lập nguyên nhân của lỗi phần mềm. Chúng ta áp dụng phương pháp gỡ lỗi bó
buộc mạnh bạo khi tất cả các phương pháp khác đều thất bại. Dùng triết lý “cứ để
máy tính tìm ra lỗi”, người ta cho xổ ra nội dung bộ nhớ, gọi tới chương trình lưu dấu
vết khi chạy và nạp chương trình với lệnh WRITE. Chúng ta hy vọng rằng đâu đó
trong bãi lầy thông tin dược tạo ra, chúng ta có thể tìm ra được một nguyên nhân của
lỗi. Mặc dầu đống thông tin được tạo ra cuối cùng có thể dẫn tới thành công, thường
hơn cả là nó dẫn đến phí phạm công sức và thời gian. Phải dành suy nghĩ vào đó
trước hết đã.
Lật ngược lại cách tiếp cận khá thông dụng có thể được dùng trong những chương
trình nhỏ. Bắt đầu tại chỗ chúng được phát hiện ra, lật ngược theo những chương
trình gốc (một cách thủ công) cho tới chỗ tìm ra nguyên nhân. Không may là khi số
dòng chương trình gốc tăng lên, số con đường lật ngược tiềm năng có thể trở nên
không quản lý nổi.
Cách tiếp cận thứ ba tới gỡ lỗi – loại bỏ nguyên nhân được biểu lộ bằng việc quy nạp
hay diễn dịch và đưa vào khái niệm về phân hoạch nhị phân. Dữ liệu có liên quan tới
việc xuất hiện lỗi được tổ chức để cô lập ra các nguyên nhân tiềm năng. Một “giả thiết
nguyên nhân” được nêu ra và dữ liệu trên được dùng để chứng minh hay bác bỏ giả

thiết đó. Một cách khác, ta có thể xây dựng ra một danh sách mọi nguyên nhân đặc
biệt có nhiều hứa hẹn thì dữ liệu sẽ được làm mịn thêm để cố gắng cô lập ra lỗi.
Từng cách tiếp cận gỡ lỗi trên đây đều có thể được bổ sung thêm bởi công cụ gỡ lỗi.
Chúng ta có thể áp dụng một phạm vi rộng các trình biên dịch gỡ lỗi, nhưng trợ giúp
gỡ lỗi động (“Bộ dò dấu vết”), các bộ sinh trường hợp kiểm thử tự động, sổ bộ nhớ và
bảng tham khảo chéo. Tuy nhiên các công cụ đều không phải là cách thay thế cho việc
đánh giá dựa trên tài liệu thiết kế phần mềm đầy đủ và chương trình gốc rõ ràng.
Trong nhiều trường hợp, việc gỡ lỗi phần mềm máy tính tựa như việc giải quyết vấn
đề trong thế giới kinh doanh. Brow và Sampson đã đưa ra một cách tiếp cận gỡ lỗi
tên là “Phương pháp”, đó là việc thích nghi các kỹ thuật giải quyết vấn đề quản lý.
Các tác giả này đề nghị phát triển một bản đặc tả về các độ lệch, mô tả cho vấn đề
bằng cách phác họa “cái gì, khi nào, ở đâu và với phạm vi nào?”

Mỗi một trong những vấn đề nêu trên (cái gì, khi nào, ở đâu và với phạm vi nào) đều
được chỉ ra thành những đáp ứng là hay không là để phân biệt rõ rệt giữa cái gì đã
xảy ra và cái gì đã không xảy ra. Một khi thông tin về lỗi đã được ghi lại thì người ta
xây dựng ra một giả thiết nguyên nhân dựa trên các phân biệt quan sát được từ
những đáp ứng là hay không là. Việc gỡ lỗi tiếp tục dùng cách tiếp cận qui nạp hay
diễn dịch được mô tả phần trên trong mục này.
Bất kỳ thảo luận nào về cách tiếp cận và công cụ gỡ lỗi cũng đều không đầy đủ nếu
không nói tới một đồng minh mạnh mẽ: Người khác! Khái niệm về “lập trình vô ngã”
của Weinberg (được thảo luận trước đây trong cuốn sách này) nên được mở rộng
thành gỡ lỗi vô ngã. Mỗi người chúng ta đều có thể nhớ lại điều gì khó xử khi mất
hàng giờ, hàng ngày vì một lỗi dai dẳng. Một đồng nghiệp vẩn vơ đi qua trong nỗi
thất vọng rồi chúng tôi giải thích và tung ra bản tin chương trình ra. Lập tức (dường
như) nguyên nhân lỗi bị phát hiện ra. Mỉm cười một cách ngạo nghễ, anh bạn đồng
nghiệp chúng ta biến mất. Một quan điểm mới mẻ, không bị che phủ bởi hàng giờ

thất vọng, có thể tạo ra những điều kỳ diệu. Câu châm ngôn cuối cùng về gỡ lỗi có thể
là: Khi tất cả mọi thứ khác đều sai thì hãy nhờ sự giúp đỡ.
Một khi lỗi đã được tìm ra, thì nó phải được sửa chữa. Nhưng khi chúng ta đã lưu ý,
việc sửa một lỗi đôi khi có thể lại đưa vào một lỗi khác và do đó lại gây hại hơn là tốt.
Van Vleck gợi ý ba câu hỏi đơn giản người kỹ sư phần mềm nên hỏi trước khi tiến
hành sửa chữa để loại bỏ nguyên nhân gây lỗi:
•

•

Liệu nguyên nhân gây lỗi này có bị tái tạo ở phần khác của chương trình hay không?
Trong nhiều tình huống, một khiếm khuyết chương trình bị gây ra bởi một mẫu hình
logic sai sót có thể còn phát sinh ở đâu đó khác nữa. Việc xem xét tường minh về
mẫu hình logic này có thể làm phát hiện ra thêm các lỗi khác
“Lỗi tiếp” có thể bị đưa vào là gì khi tôi chữa lỗi này? Trước khi việc sửa lỗi được
tiến hành, chương trình gốc (hay tốt hơn, thiết kế) nên được đánh giá lại để thẩm
định việc dính nối các cấu trúc logic dữ liệu. Nếu việc sửa lỗi được tiến hành trong
một phần có độ dính nối cao thì càng phải để tâm nhiều khi tiến hành bất kỳ một sự
thay đổi nào.

Ta có thể làm gì để ngăn cản lỗi này ngay từ đầu? Câu hỏi này là bước đầu tiên
hướng tới việc thiết lập một cách tiếp cận đảm bảo chất lượng phần mềm thống kê.
Nếu ta sửa chương trình cũng như sản phẩm thì lỗi sẽ loại bỏ chương trình hiện tại và
có thể bị khử bỏ mọi chương trình tương lai

CHƯƠNG 3: KIỂM THỬ PHẦN MỀM

Mục tiêu của chương này là mô tả quá trình kiểm thử phần mềm và đưa ra các kỹ thuật
kiểm thử. Khi đọc chương này, bạn sẽ:
–

Hiểu được sự khác biệt giữa kiểm thử hợp lệ và kiểm thử khiếm khuyết.

–

Hiểu được các nguyên lý của kiểm thử hệ thống và kiểm thử bộ phận.

–

Hiểu được ba chiến lược có thể sử dụng để sinh các trường hợp kiểm thử hệ thống.

–

Hiểu được các đặc điểm bản chất của công cụ phần mềm được sử dụng để kiểm thử
tự động.

3.1.

Quá trình kiểm thử

Quá trình kiểm thử phần mềm có hai mục tiêu riêng biệt:
1. Chứng minh cho người phát triển và khách hàng thấy các yêu cầu của phần mềm.
Với phần mềm truyền thống, điều này có nghĩa là bạn có ít nhất một thử nghiệm
cho mỗi yêu cầu của người dùng và tài liệu hệ thống yêu cầu.Với các sản phẩm
phần mềm chung, điều đó có nghĩa là bạn nên thử nghiệm tất cả các đặc tính của hệ
thống sẽ được kết hợp trong sản phẩm phát hành.
2. Phát hiện các lỗi và khiếm khuyết trong phần mềm: phần mềm thực hiện không

đúng, không như mong đợi hoặc không làm theo như đặc tả. Kiểm tra khiếm
khuyết tập trung vào việc tìm ra tất cả các kiểu thực hiện không như mong đợi của
hệ thống, như sự đổ vỡ hệ thống, sự tương tác không mong muốn với hệ thống
khác, tính toán sai và sai lạc dữ liệu.

Kiểm thử
thành phần

Kiểm thử
hệ thống

Nhóm kiểm thử độc lập

Người phát triển phần mềm

Hình 3.1 Các giai đoạn kiểm thử

Các
trường hợp
kiểm thử

Thiết kế trường hợp
kiểm thử

Chuẩn bị dữ liệu
kiểm thử

Dữ liệu

Các kết quả

kiểm thử

Chạy chương trình
với dữ liệu kiểm thử

Báo cáo
kiểm thử

So sánh các kết quả
Với các trường hợp
thử nghiệm

Hình 3.2 Một mô hình của quá trình kiểm thử phần mềm

Mục tiêu thứ nhất dẫn đến kiểm thử hợp lệ, sử dụng tập các thử nghiệm phản ánh mong
muốn của người dùng để kiểm tra xem hệ thống có thực hiện đúng không. Mục tiêu thứ hai
dẫn đến kiểm thử khiếm khuyết: các trường hợp kiểm thử được thiết kế để tìm ra các
khiếm khuyết. Các trường hợp kiểm thử có thể được làm không rõ và không cần phản ánh
cách hệ thống bình thường được sử dụng. Với kiểm thử hợp lệ, một thử nghiệm thành công
là thử nghiệm mà hệ thống thực hiện đúng đắn. Với kiểm thử khiếm khuyết, một thử
nghiệm thành công là một thử nghiệm tìm ra một khiếm khuyết, nguyên nhân làm cho hệ
thống thực hiện không chính xác.
Kiểm thử có thể không chứng minh được phần mềm không có khiếm khuyết, hoặc nó sẽ
thực hiện như đặc tả trong mọi trường hợp. Rất có thể một thử nghiệm bạn bỏ qua có thể

phát hiện ra các vấn đề khác trong hệ thống. Như Dijstra, một người đi đầu trong việc phát
triển kỹ nghệ phần mềm, đã tuyên bố (1972): kiểm thử chỉ có thể phát hiện ra các lỗi hiện
tại, chứ không thể đưa ra tất cả các lỗi.
Nói chung, vì vậy, mục tiêu của kiểm thử phần mềm là thuyết phục người phát triển phần
mềm và khách hàng rằng phần mềm là đủ tốt cho các thao tác sử dụng. Kiểm thử là một
quá trình được dùng để tạo nên sự tin tưởng trong phần mềm.
Mô hình tổng quát của quá trình kiểm thử được mô tả trong hình 3.2. Các trường hợp
kiểm thử sự chỉ rõ của đầu vào để thử nghiệm và đầu ra mong đợi từ hệ thống cộng với
một bản báo cáo sản phẩm đã được kiểm thử. Dữ liệu kiểm thử là đầu vào, được nghĩ ra để
kiểm thử hệ thống. Dữ liệu kiểm thử thỉnh thoảng có thể được tự động sinh ra. Sinh các
trường hợp kiểm thử tự động là điều không làm được. Đầu ra của thử nghiệm chỉ có thể
được dự đoán bởi người hiểm biết về hoạt động của hệ thống.
Kiểm thử toàn diện: mọi chương trình có thể thực hiện tuần tự được kiểm tra, là điều
không thể làm được. Vì vậy, kiểm thử, phải được thực hiện trên một tập con các trường
hợp kiểm thử có thể xảy ra. Trong lý tưởng, các công ty phần mềm có những điều khoản
để lựa chọn tập con này hơn là giao nó cho đội phát triển. Những điều khoản này có thể
dựa trên những điều khoản kiểm thử chung, như một điều khoản là tất cả các câu lệnh
trong chương trình nên được thực thi ít nhất một lần. Một sự lựa chọn là những điều khoản
kiểm thử có thể sự trên kinh nghiệm sử dụng hệ thống, và có thể tập trung vào kiểm thử
các đặc trưng hoạt động của hệ thống. Ví dụ:
1. Tất cả các đặc trưng của hệ thống được truy cập thông qua thực đơn nên được kiểm
thử.
2. Kết hợp các chức năng (ví dụ định dạng văn bản) được truy cập thông qua cùng thực
đơn phải được kiểm thử.
3. Khi đầu vào được đưa vào, tất cả các chức năng phải được kiểm thử với cùng một thử
nghiệm đúng đắn và thử nghiệm không đúng đắn.
Điều đó rõ ràng từ kinh nghiệm với sản phẩm phần mềm lớn như phần mềm xử lý văn
bản, hoặc bảng tính có thể so sánh các nguyên tắc thông thường được sử dụng trong lúc
kiểm thử sản phẩm. Khi các đặc trưng của phần mềm được sử dụng cô lập, chúng làm việc
bình thuờng. Các vấn đề phát sinh, như Whittaker giải thích (Whittaker, 2002), khi liên kết

các đặc trưng không được kiểm thử cùng nhau. Ông đã đưa ra một ví dụ, khi sử dụng phần
mềm xử lý văn bản sử dụng sử dụng lời chú thích ở cuối trang với cách sắp xếp nhiều cột
làm cho văn bản trình bày không đúng.
Khi một phần của quá trình lập kế hoạch V & V, người quản lý phải đưa ra các
quyết định ai là người chịu trách nhiệm trong từng bước kiểm thử khác nhau. Với
hầu hết các hệ thống, các lập trình viên chịu trách nhiệm kiểm thử các thành phần

mà họ đã triển khai. Khi các lập trình viên đã hoàn thành các công việc đó, công việc
được giao cho đội tổng hợp, họ sẽ tích hợp các môđun từ những người phát triển
khác nhau để tạo nên phần mềm và kiểm thử toàn bộ hệ thống. Với hệ thống quan
trọng, một quá trình theo nghi thức có thể được sử dụng, các người thử độc lập chịu
trách nhiệm về tất cả các bước của quá trình kiểm thử. Trong kiểm thử hệ thống
quan trọng, các thử nghiệm được kiểm thử riêng biệt và hồ sơ chi tiết của kết quả
kiểm thử được duy trì.
Kiểm thử các thành phần được thực hiện bởi những người phát triển thường dựa
trên hiểu biết trực giác về cách hoạt động của các thành phần. Tuy nhiên, kiểm thử
hệ thống phải dựa trên văn bản đặc tả hệ thống. Đó có thể là một đặc tả chi tiết yêu
cầu hệ thống, hoặc nó có thể là đặc tả hướng người sử dụng ở mức cao của các đặc
tính được thực hiện trong hệ thống. Thường có một đội độc lập chịu trách nhiệm
kiểm thử hệ thống, đội kiểm thử hệ thống làm việc từ người sử dụng và tài liệu yêu
cầu hệ thống để lập kế hoạch kiểm thử hệ thống.
Hầu hết các thảo luận về kiểm thử bắt đầu với kiểm thử thành phần và sau đó
chuyển đến kiểm thử hệ thống. Tôi đã đảo ngược thử tự các thảo luận trong chương
này bởi vì rất nhiều quá trình phát triển phần mềm bao gồm việc tích hợp các thành
phần sử dụng lại và được lắp vào phần mềm để tạo nên các yêu cầu cụ thể. Tất cả các
kiểm thử trong trường hợp này là kiểm thử hệ thống, và không có sự tách rời trong
quá trình kiểm thử thành phần.

Xem thêm: Top 3 Phần Mềm Quản Lý Nhân Sự Chuyên Nghiệp

3.2.

Kiểm thử hệ thống

Hệ thống gồm hai hoặc nhiều thành phần tích hợp nhằm thực hiện các chức năng hoặc đặc
tính của hệ thống. Sau khi tích hợp các thành phần tạo nên hệ thống, quá trình kiểm thử hệ
thống được tiến hành. Trong quá trình phát triển lặp đi lặp lại, kiểm thử hệ thống liên quan
với kiểm thử một lượng công việc ngày càng tăng để phân phối cho khách hàng; trong quá
trình thác nước, kiểm thử hệ thống liên quan với kiểm thử toàn bộ hệ thống.
Với hầu hết các hệ thống phức tạp, kiểm thử hệ thống gồm hai giai đoạn riêng biệt:
1. Kiểm thử tích hợp: đội kiểm thử nhận mã nguồn của hệ thống. Khi một vấn đề
được phát hiện, đội tích hợp thử tìm nguồn gốc của vấn đề và nhận biết thành phần
cần phải gỡ lỗi. Kiểm thử tích hợp hầu như liên quan với việc tìm các khiếm khuyết
của hệ thống.
2. Kiểm thử phát hành: Một phiên bản của hệ thống có thể được phát hành tới người
dùng được kiểm thử. Đội kiểm thử tập trung vào việc hợp lệ các yêu cầu của hệ
thống và đảm bảo tính tin cậy của hệ thống. Kiểm thử phát hành thường là kiểm thử
“hộp đen”, đội kiểm thử tập trung vào mô tả các đặc tính hệ thống có thể làm được
hoặc không làm được. Các vấn đề được báo cáo cho đội phát triển để gỡ lỗi chương
trình. Khách hàng được bao hàm trong kiểm thử phát hành, thường được gọi là
kiểm thử chấp nhận. Nếu hệ thống phát hành đủ tốt, khách hàng có thể chấp nhận
nó để sử dụng.
Về cơ bản, bạn có thể nghĩ kiểm thử tích hợp như là kiểm thử hệ thống chưa đầy đủ
bao gồm một nhóm các thành phần. Kiểm thử phát hành liên quan dến kiểm thử hệ
thống phát hành có ý định phân phối tới khách hàng. Tất nhiên, có sự gối chồng lên

nhau, đặc biệt khi phát triển hệ thống và hệ thống đuợc phát hành khi chưa hoàn thành.
Thông thường, sự ưu tiên hàng đầu trong kiểm thử tích hợp là phát hiện ra khiếm
khuyết trong hệ thống và sự ưu tiên hàng đầu trong kiểm thử hệ thống là làm hợp lệ các
yêu cầu của hệ thống. Tuy nhiên trong thực tế, có vài kiểm thử hợp lệ và vài kiểm thử
khiếm khuyết trong các quá trình.

3.3.

Kiểm thử tích hợp

Quá trình kiểm thử tích hợp bao gồm việc xây dựng hệ thống từ các thành phần và
kiểm thử hệ thống tổng hợp với các vấn đề phát sinh từ sự tương tác giữa các thành
phần. Các thành phần được tích hợp có thể trùng với chính nó, các thành phần có thể
dùng lại được có thể thêm vào các hệ thống riêng biệt hoặc thành phần mới được phát
triển. Với rất nhiều hệ thống lớn, có tất cả 3 loại thành phần được sử dụng. Kiểm thử
tích hợp kiểm tra trên thực tế các thành phần làm việc với nhau, được gọi là chính xác
và truyền dữ liệu đúng vào lúc thời gian đúng thông qua giao diện của chúng.
Hệ thống tích hợp bao gồm một nhóm các thành phần thực hiện vài chức năng của hệ
thống và được tích hợp với nhau bằng cách gộp các mã để chúng làm việc cùng với
nhau. Thỉnh thoảng, đầu tiên toàn bộ khung của hệ thống được phát triển, sau đó các
thành phần được gộp lại để tạo nên hệ thống. Phương pháp này được gọi là tích hợp từ
trên xuống (top-down). Một cách lựa chọn khác là đầu tiên bạn tích hợp các thành phần
cơ sở cung cấp các dịch vụ chung, như mạng, truy cập cơ sở dữ liệu, sau đó các thành
phần chức năng được thêm vào. Phương pháp này được gọi là tích hợp từ dưới lên
(bottom-up). Trong thực tế, với rất nhiều hệ thống, chiến lược tích hợp là sự pha trộn
các phương pháp trên. Trong cả hai phương pháp top-down và bottom-up, bạn thường
phải thêm các mã để mô phỏng các thành phần khác và cho phép hệ thống thực hiện.
Một vấn đề chủ yếu nảy sinh trong lúc kiểm thử tích hợp là các lỗi cục bộ. Có nhiều
sự tương tác phức tạp giữa các thành phần của hệ thống, và khi một đầu ra bất thường
được phát hiện, bạn có thể khó nhận ra nơi mà lỗi xuất hiện. Để việc tìm lỗi cục bộ

được dễ dàng, bạn nên thường xuyên tích hợp các thành phần của hệ thống và kiểm thử
chúng. Ban đầu, bạn nên tích hợp một hệ thống cấu hình tối thiểu và kiểm thử hệ thống
này. Sau đó bạn thêm dần các thành phần vào hệ thống đó và kiểm thử sau mỗi bước
thêm vào.

3.4. Kiểm thử phát hành ………………………………………………………………………………….. 273.5. Kiểm thử hiệu năng ………………………………………………………………………………….. 313.6. Kiểm thử thành phần ………………………………………………………………………………… 323.7. Kiểm thử giao diện …………………………………………………………………………………… 333.8. Thiết kế trường hợp thử ( Test case design ) ………………………………………………….. 353.9. Tự động hóa kiểm thử ( Test automation ) …………………………………………………….. 45CH ƯƠNG 4 : CÁC PHƯƠNG PHÁP KIỂM THỬ ………………………………………………………… 494.1. Phương pháp white-box : ……………………………………………………………………………. 504.2. Phương pháp black-box : ……………………………………………………………………………. 59CH ƯƠNG 5 : KIỂM THỬ TÍCH HỢP ………………………………………………………………………….. 665.1. Tích hợp trên xuống. ………………………………………………………………………………… 665.2. Tích hợp dưới lên. ……………………………………………………………………………………. 685.3. Kiểm thử nội quy ……………………………………………………………………………………… 695.4. Gợi ý về việc kiểm thử tích hợp …………………………………………………………………. 715.5. Lập tài liệu về kiểm thử tích hợp ………………………………………………………………… 72CH ƯƠNG 6 : KỸ NGHỆ ĐỘ TIN CẬY PHẦN MỀM …………………………………………………… 756.1. Giới thiệu ………………………………………………………………………………………………… 756.2. Xác nhận tính đáng tin cậy ………………………………………………………………………………… 766.2.1. Sơ thảo hoạt động giải trí …………………………………………………………………………………….. 786.2.2. Dự đoán tính đáng tin cậy …………………………………………………………………………………. 796.3. Đảm bảo tính bảo đảm an toàn ………………………………………………………………………………… 826.3.1. Những luận chứng về tính bảo đảm an toàn ………………………………………………………………. 836.3.2. Đảm bảo quá trình ……………………………………………………………………………………. 866.3.3. Kiểm tra tính bảo đảm an toàn khi triển khai …………………………………………………………….. 886.4. Các trường hợp bảo đảm an toàn và đáng tin cậy được ………………………………………………………. 89CH ƯƠNG 7 : KIỂM THỬ PHẦN MỀM TRONG CÔNG NGHIỆP ………………………………. 957.1. QUY TRÌNH KIỂM TRA PHẦN MỀM CƠ BẢN ……………………………………….. 957.2. MÔ HÌNH KIỂM TRA PHẦN MỀM TMM ( TESTING MATURITYMODEL ) ……………………………………………………………………………………………………………. 997.3. Các công cụ kiểm thử ( Test tools ) …………………………………………………………….. 1057.3.1. TẠI SAO PHẢI DÙNG TEST TOOL ………………………………………………………. 1057.3.2. KHÁI QUÁT VỀ KTTĐ …………………………………………………………………………. 1067.3.3. GIỚI THIỆU CÔNG CỤ KTTĐ : QUICKTEST PROFESSIONAL. ……………… 1087.3.4. Kiểm thử đơn vị chức năng với JUnit ……………………………………………………………………….. 112CH ƯƠNG 8 : ƯỚC LƯỢNG GIÁ THÀNH PHẦN MỀM …………………………………………….. 1298.1. Giới thiệu ………………………………………………………………………………………………. 1298.2. Năng suất phần mền ……………………………………………………………………………….. 1318.3. Kỹ thuật ước đạt …………………………………………………………………………………. 1358.4. Mô hình hoá ngân sách thuật toán …………………………………………………………………. 1378.5. Mô hình COCOMO ………………………………………………………………………………… 1398.6. Mô hình ngân sách giải thuật trong kế hoạch dự án Bất Động Sản …………………………………………. 1478.7. Nhân viên và khoảng chừng thời hạn của dự án Bất Động Sản ………………………………………………….. 149CH ƯƠNG 9 : QUẢN LÝ CHẤT LƯỢNG PHẦN MỀM ………………………………………………. 1539.1. Chất lượng quy trình và chất lượng mẫu sản phẩm : ……………………………………………. 1539.2. Chất lượng quy trình và chất lượng loại sản phẩm : ……………………………………………. 1559.3. Đảm bảo chất lượng và những chuẩn chất lượng …………………………………………….. 1569.4. Lập kế hoạch chất lượng ………………………………………………………………………….. 1639.5. Kiểm soát chất lượng ………………………………………………………………………………. 1649.6. CMM / CMMi …………………………………………………………………………………………. 1659.6.2. Cấu trúc của CMM …………………………………………………………………………………. 1669.6.3. So sánh giữa CMM và CMMi ………………………………………………………………….. 172CH ƯƠNG 10 : QUẢN LÝ CẤU HÌNH ………………………………………………………………………… 17410.1. Giới thiệu ………………………………………………………………………………………………. 17410.2. Kế hoạch quản trị thông số kỹ thuật ………………………………………………………………………. 17611.2. Quản lý việc đổi khác ………………………………………………………………………………. 17911.3. Quản lý phiên bản và bản phát hành ………………………………………………………….. 18311.4. Quản lý bản phát hành …………………………………………………………………………….. 18611.5. Xây dựng mạng lưới hệ thống …………………………………………………………………………………. 18911.6. Các công cụ CASE cho quản trị thông số kỹ thuật ………………………………………………….. 190PH Ụ LỤC – CÁC CÂU HỎI ÔN TẬP ………………………………………………………………………….. 1971. Chất lượng và đảm bảo chất lượng phần mềm …………………………………………………… 1972. Các độ đo đặc trưng chất lượng phần mềm ……………………………………………………….. 1983. Kiểm thử phần mềm ………………………………………………………………………………………. 1994. Quản lý thông số kỹ thuật phần mềm ……………………………………………………………………………. 201T ÀI LIỆU THAM KHẢO …………………………………………………………………………………………… 202M Ở ĐẦUQuản lý chất lượng phần mềm là yếu tố không mới nhưng theo một số ít nhìn nhận là cònyếu của những công ty phần mềm Nước Ta. Một số công ty trong nước hiện đã đạt những chuẩnquốc tế CMM / CMMI trong nâng cao năng lượng và quản trị chất lượng phần mềm, tuy nhiên chỉđếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia công cho thịtrường quốc tế. Lâu nay, nói đến chất lượng phần mềm, không ít người nghĩ ngay đến yếu tố là xácđịnh xem phần mềm đó có phát sinh lỗi hay không, có ” chạy ” đúng như nhu yếu hay khôngvà ở đầu cuối thường quy về vai trò của hoạt động giải trí kiểm thử phần mềm ( testing ) như là hoạtđộng chịu nghĩa vụ và trách nhiệm chính. Với quan điểm của người mua, điều này hoàn toàn có thể đúng, họ không cần chăm sóc nội tìnhcủa hoạt động giải trí tăng trưởng phần mềm, điều họ cần chăm sóc là liệu mẫu sản phẩm sau cuối giaocho họ có đúng hạn hay không và thao tác đúng như họ muốn hay không. Tuy nhiên theo quan điểm của người tăng trưởng phần mềm, thực tiễn cho thấy hoạt độngkiểm thử phần mềm là quan trọng, nhưng không đủ để đảm bảo loại sản phẩm sẽ được hoànthành đúng hạn và đúng nhu yếu. Kiểm thử sau cuối để phát hiện lỗi là điều tất yếu phảilàm, nhưng trong rất nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiềuthời gian để sửa chữa thay thế. Thực tế cho thấy, để đảm bảo được hai tiêu chuẩn ” đơn thuần ” trên của người mua, đòi hỏitổ chức không chỉ quản lý và vận hành tốt khâu kiểm thử phần mềm, mà phải tổ chức triển khai và duy trì sựhoạt động uyển chuyển của cả một mạng lưới hệ thống những việc làm tương quan đến một dự án Bất Động Sản phầnmềm, từ đây Open một khái niệm có tên là ” mạng lưới hệ thống quản trị chất lượng phần mềm ” gồm có những quá trình được thực thi xuyên suốt chu kỳ luân hồi tăng trưởng của dự án Bất Động Sản phần mềmsong hành cùng việc kiểm thử phân mềm nhằm mục đích đảm bảo chất lượng cho phần mềm khichuyển giao cho người mua. Với thực tiễn trên, là những người làm công tác làm việc đào tạo và giảng dạy mong ước phân phối cho sinhviên ngành công nghệ phần mềm – những người sẽ là nguồn nhân lực hầu hết trong tươnglai của những doanh nghiệp phần mềm – những khái niệm, kỹ năng và kiến thức và kỹ năng và kiến thức cơ bản banđầu về kiểm thử phần mềm, về qui trình quản trị chất lượng, đảm bảo chất lượng phần mềmthông qua giáo trình ( nội bộ ) Kiểm thử và đảm bảo chất lượng phần mềm ( SoftwareTesting and Quality Assurrance ). Giáo trình này với tiềm năng cung ứng cho sinh viên công nghệ phần mềm có được kiếnthức và kiến thức và kỹ năng về việc kiểm thử phần mềm, những quy trình kiểm thử, những loại kiểm thử, công cụ kiểm thử, thiết kế xây dựng tài liệu kiểm thử, tài liệu kiểm thử …. Và xây qui trình đảmbảo chất lượng phần mềm, trình làng tổng quan về mạng lưới hệ thống quản trị chất lượng, nguyêntắc, kỹ thuật … để đảm bảo rằng dự án Bất Động Sản phần mềm sẽ chuyển giao cho người mua đúnghạn, đúng nhu yếu. Đây là giáo trình sơ khởi, còn nhiều yếu tố chưa đi sâu nghiên cứu và phân tích và triển khai, cònmang tính kim chỉ nan nhiều. Tác giả kỳ vọng bạn đọc góp phần quan điểm để phiên bản 2 đápứng tốt hơn nhu yếu của nhiều fan hâm mộ, của sinh viên và kể cả những người đang công táctại những phòng tăng trưởng và đảm bảo chất lượng phần mềm. CHƯƠNG 1 : CÁC KHÁI NIỆMCác định nghĩa1. 1. “ Lỗi phần mềm là chuyện hiển nhiên của đời sống. Chúng ta dù cố gắng nỗ lực đến mức nàothì thực tiễn là ngay cả những lập trình viên xuất sắc nhất cũng không hoàn toàn có thể khi nào cũngviết được những đoạn mã không có lỗi. Tính trung bình, ngay cả một lập trình viên loại tốtthì cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh. Người ta ước đạt rằng việc kiểm tra để tìmra những lỗi này chiếm phân nửa khối lượng việc làm phải làm để có được một phần mềmhoạt động được ”. ( Software Testing Techniques, Second Edition, by Boris Beizer, VanNostrand Reinhold, 1990, ISBN 1850328803 ). Trên đây là một nhận định và đánh giá về việc làm kiểm nghiệm ( testing ) chương trình. Thật vậy, ngày này càng ngày những chương trình ( những phần mềm ) càng trở lên phứctạp và đồ sộ. Việc tạo ra một loại sản phẩm hoàn toàn có thể bán được trên thị trường yên cầu sự nổlực của hàng chục, hàng trăm thậm chí còn hàng ngàn nhân viên cấp dưới. Số lượng dòng mã lênđến hàng triệu. Và để tạo ra một mẫu sản phẩm thì không phải chỉ do một tổ chức triển khai đứng ralàm từ đầu đến cuối, mà yên cầu sự link, tích hợp của rất nhiều mẫu sản phẩm, thư việnlập trình, … của nhiều tổ chức triển khai khác nhau … Từ đó yên cầu việc kiểm nghiệm phầnmềm ngày càng trở nên rất quan trọng và rất phức tạp. Song song với sự tăng trưởng những công nghệ tiên tiến lập trình, những ngôn từ lập trình … thì cáccông nghệ và kỹ thuật kiểm nghiệm phần mềm ngày càng tăng trưởng và mang tínhkhoa học. Bài tiểu luận này với mục tiêu là tập hợp, điều tra và nghiên cứu, nghiên cứu và phân tích những kỹthuật, những công nghệ tiên tiến kiểm nghiệm phần mềm đang được sử dụng và tăng trưởng hiệnnay. 1.1.1. Định nghĩa : Việc kiểm nghiệm là quy trình thực thi một chương trình với mục tiêu là tìm ra lỗi. ( Glen Myers ) Giải thích theo mục tiêu : Việc thử nghiệm hiển nhiên là nói đến những lỗi ( error ), sai sót ( fault ), hỏng hóc ( failure ) hoặc những hậu quả ( incident ). Một phép thử là một cách chạy phần mềm theo cáctrường hợp thử nghiệm với tiềm năng là : Tìm ra sai sót. Giải thích sự hoạt động giải trí đúng mực. ( Paul Jorgensen ) 1.1.2. Các thuật ngữ : Lỗi ( Error ) : – Là những lỗi lầm do con người gây ra. Sai sót ( Fault ) : – Sai sót gây ra lỗi. Có thể phân loại như sau : Sai sót do đưa ra dư thừa – tất cả chúng ta đưa một vài thứ không chínhxác vào miêu tả nhu yếu phần mềm. Sai sót do bỏ sót – Người phong cách thiết kế hoàn toàn có thể gây ra sai sót do bỏ sót, kếtquả là thiếu một số ít phần đáng ra phải có trong miêu tả nhu yếu phầnmềm. Hỏng hóc ( Failure ) : – Xảy ra khi sai sót được thực thi. ( Khi thực thi chương trình tại những nơibị sai thì sẽ xảy ra trạng thái hỏng hóc ). Kết quả không mong đợi, hậu quả ( Incident ) – Là những hiệu quả do sai sót đem đến. Hậu quả là những triệu chứng liênkết với một hỏng hóc và báo hiệu cho người dùng biết sự Open củahỏng hóc. Trường hợp thử ( Test case ) – Trường hợp thử được link tương ứng với hoạt động giải trí của chươngtrình. Một trường hợp thử bao một một tập những giá trị nguồn vào và mộtdanh sách những tác dụng đầu ra mong ước. Thẩm tra ( Verification ) – Thẩm tra là tiến trình nhằm mục đích xác lập đầu ra của một quy trình trongviệc tăng trưởng phần mềm tương thích với quy trình trước đó. Xác nhận ( Validation ) – Xác nhận là tiến trình nhằm mục đích chỉ ra toàn mạng lưới hệ thống đã tăng trưởng xong phùhợp với tài liệu diễn đạt nhu yếu. So sánh giữa Thẩm tra và Xác nhận : 1.2. Thẩm tra : thẩm tra chăm sóc đến việc ngăn ngừa lỗi giữa những quy trình. Xác nhận : xác nhận chăm sóc đến loại sản phẩm ở đầu cuối không còn lỗi. Vòng đời của việc kiểm nghiệm ( testing life cycle ) : Bảng dưới đây miêu tả những quy trình tăng trưởng một phần mềm và cách khắc phục lỗi. Lỗi hoàn toàn có thể xảy ra trong toàn bộ những quy trình từ “ Mô tả nhu yếu ”, “ Thiết kế ” đến “ Lậptrình ”. Từ quy trình này chuyển sang quy trình khác thường phát sinh những sai sót ( do dư thừahoặc thiếu theo diễn đạt nhu yếu ). Đến quy trình kiểm nghiệm tất cả chúng ta sẽ phát hiện ra những hậu quả ( những tác dụng không mongmuốn ). Quá trình sửa lỗi gồm có “ phân loại lỗi ”, “ cô lập lỗi ” ( tìm ra nguyên do và nơi gây lỗi ), đề ra “ giải pháp sửa lỗi ” và sau cuối là khắc phục lỗi. Vòng đời của kiểm nghiệmLỗiSửa lỗiMô tả yêu cầuGiải pháp sửa lỗiLỗiSai sótThiết kếCô lập lỗiLỗiSai sótLập trìnhPhân loại lỗiSai sótHậu quảKiểm nghiệm1. 3. Phân loại kiểm nghiệm : Có 2 mức phân loại : Một là phân biệt theo mức độ chi tiết cụ thể của những bộ phận hợp thành phần mềm. – Mức kiểm tra đơn vị chức năng ( Unit ) – Mức kiểm tra mạng lưới hệ thống ( System ) – Mức kiểm tra tích hợp ( Integration ) Cách phân loại khác là dựa trên chiêu thức thử nghiệm ( thường dùng ở mứckiểm tra đơn vị chức năng ) – Kiểm nghiệm hộp đen ( Black box testing ) dùng để kiểm tra tính năng. – Kiểm nghiệm hộp trắng ( White box testing ) dùng để kiểm tra cấu trúc. Hình bên dưới màn biểu diễn sự đối sánh tương quan của “ những tiêu chuẩn chất lượng phần mềm ”, “ mức độchi tiết đơn vị chức năng ” và “ chiêu thức kiểm nghiệm ” Đặc điểmAn toànỔn địnhThiết thựcKhả năng thi hànhThân thiện người dùngChức năngPhương phápĐơn vị ( Unit ) Thành phần ( Module ) Tích hợp ( Integration ) White-boxBlack-boxHệ thống ( System ) Mức độ chi tiết1. 4. Sự đối sánh tương quan giữa những quy trình xây dụng phần mềm và loại kiểmnghiệm : Mô hình chữ VMô hình này nhằm mục đích lý giải sự đối sánh tương quan giữa những quy trình kiến thiết xây dựng phần mềm vàcác loại kiểm nghiệm. Ở mỗi quy trình thiết kế xây dựng phần mềm sẽ tương ứng với một loạikiểm nghiệm và cần có một hồ sơ kiểm nghiệm tương ứng được xây dựng để Giao hàng choviệc kiểm nghiệm. Ví dụ : Công đoạn : Yêu cầu phần mềm ( requiements ) ; Loại kiểm nghiệm : Kiểm nghiệmchấp nhận ( acceptance test ) ; Hồ sơ : hồ sơ kiểm nghiệm đồng ý ( acceptance testspec ). Công đoạn : Mô tả cụ thể phần mềm ( specification ) ; Loại kiểm nghiệm : Kiểmnghiệm mạng lưới hệ thống ( system test ) ; Hồ sơ : hồ sơ kiểm nghiệm mạng lưới hệ thống ( system testspec ). Công đoạn : Hồ sơ kiến trúc ( architecture spec ) ; Loại kiểm nghiệm : Kiểm nghiệmtích hợp ( integration test ) ; Hồ sơ : hồ sơ kiểm nghiệm tích hợp ( integration testspec ). Công đoạn : Thiết kế cụ thể ( detailed design ) ; Loại kiểm nghiệm : Kiểm nghiệmkhối ( module test ) ; Hồ sơ : hồ sơ kiểm nghiệm khối ( module test spec ). Công đoạn : Viết mã ( implementation code ) ; Loại kiểm nghiệm : Kiểm nghiệmđơn vị ( unit test ) ; Hồ sơ : hồ sơ kiểm nghiệm đơn vị chức năng ( unit test spec ). acceptance test specacceptance testrequiementssystem test specsystem testspecificationarchitecturespec Sai sótintegration test specintegration testmodule test specmodule testdetailed designunit test specimplementationcodeunit testSơ lượt những kỹ thuật và quy trình kiểm nghiệm : 1.5. Các kỹ thuật và quy trình kiểm nghiệm hoàn toàn có thể chia như sau : Kiểm nghiệm tầm hẹp : kiểm nghiệm những bộ phận riêng rẽ. – Kiểm nghiệm hộp trắng ( White box testing ) – Kiểm nghiệm hộp đen ( Black box testing ) Kiểm nghiệm tầm rộng : – Kiểm nghiệm bộ phận ( Module testing ) : kiểm nhiệm một bộ phận riêngrẽ. – Kiểm nghiệm tích hợp ( Itegration testing ) : tích hợp những bộ phận và hệthống con. – Kiểm nghiệm mạng lưới hệ thống ( System testing ) : kiểm nghiệm hàng loạt mạng lưới hệ thống. – Kiểm nghiệm gật đầu ( Acceptance testing ) : thực thi bởi kháchhàng. 1.5.1. Các loại kiểm nghiệm tầm hẹp : Các loại kiểm nghiệm này đựơc thực thi để kiểm nghiệm đến những đơn vị chức năng ( unit ) hoặc cáckhối công dụng ( module ). a. Kiểm nghiệm hộp trắng ( white-box testing ) Còn gọi là kiểm nghiệm cấu trúc. Kiểm nghiệm theo cách này là loại kiểm nghiệm sử dụngcác thông tin về cấu trúc bên trong của ứng dụng. Việc kiểm nghiệm này dựa trên quá trìnhthực hiện kiến thiết xây dựng phần mềm. Tiêu chuẩn của kiểm nghiệm hộp trắng phải cung ứng những nhu yếu như sau : Bao phủ dòng lệnh : mỗi dòng lệnh tối thiểu phải được thực thi 1 lầnBao phủ nhánh : mỗi nhánh trong sơ đồ tinh chỉnh và điều khiển ( control graph ) phải được điqua một lần. Bao phủ đường : toàn bộ những đường ( path ) từ điểm khởi tạo đến điểm cuối cùngtrong sơ đồ dòng tinh chỉnh và điều khiển phải được đi qua. b. Kiểm nghiệm hộp đen ( black-box testing ) Còn gọi là kiểm nghiệm tính năng. Việc kiểm nghiệm này được thực thi mà không cầnquan tâm đến những phong cách thiết kế và viết mã của chương trình. Kiểm nghiệm theo cách này chỉquan tâm đến tính năng đã đề ra của chương trình. Vì vậy kiểm nghiệm loại này chỉ dựavào bản miêu tả công dụng của chương trình, xem chương trình có thực sự phân phối đúngchức năng đã diễn đạt trong bản chức năng hay không mà thôi. Kiểm nghiệm hộp đen dựa vào những định nghĩa về công dụng của chương trình. Các trườnghợp thử nghiệm ( test case ) sẽ được tạo ra dựa nhiều vào bản miêu tả tính năng chứ khôngphải dựa vào cấu trúc của chương trình. c. Vấn đề kiểm nghiệm tại biên : Kiểm nghiệm biên ( boundary ) là yếu tố được đặt ra trong cả hai loại kiểm nghiệm hộp đenvà hộp trắng. Lý do là do lỗi thường xảy ra tại vùng này. Ví dụ : if x > y then S1 else S2Với điều kiện kèm theo bao trùm, chỉ cần 2 truờng hợp thử là x > y và x < = y. Với kiểm nghiệm đường biên giới thì kiểm tra với những trường hợp thử là x > y, xCác loại kiểm nghiệm tầm rộng : Việc kiểm nghiệm này triển khai trên tầm mức lớn hơn và những góc nhìn khác của phầnmềm như kiểm nghiệm mạng lưới hệ thống, kiểm nghiệm sự đồng ý ( của người dùng ) … 10 a. Kiểm nghiệm Module ( Module testing ) Mục đích : xác định module đưa ra đã được thiết kế xây dựng đúng hay chưa ? Vấn đề đặt ra : giả sử module I sử dụng những module H, K. Nhưng những module H và K chưasẳn sàng. Vậy cách nào để kiểm tra module I một cách độc lập ? Giải pháp đề ra là giả lập thiên nhiên và môi trường của module H và K.Thông thường một module hoàn toàn có thể gọi một tác vụ ( hay một tiến trình ) không phải của nó, truy vấn những cấu trúc tài liệu không phải là cục bộ, hay được dùng bởi một module khác. Hình sau diễn đạt module được đặt trong thiên nhiên và môi trường thử nghiệm. PROCEDUREUNDER TESTSTUBCALLDRIVERCALLACCESS TO NONLOCAL VARIABLESGhi chú : Driver là module gọi thực thi làm cho module cần kiểm tra hoạt động giải trí, nó giả lậpcác module khác sẽ sử dụng module này. Các tập dữ liệu san sẻ mà những module khác thiếtlập trong thực tiễn cũng được thiết lập ở drive. Stub là module giả lập những module đượcmodule đang kiểm tra sử dụng. b. Kiểm nghiệm tích hợp : Là cách kiểm nghiệm bằng cách tích hợp vào mạng lưới hệ thống từng module một và kiểm tra. Ưu điểm : Dễ dàng tìm ra những lỗi vào ngay quá trình đầu. Dễ dàng khoanh vùng những lỗi ( tích hợp n modules, sau đó n + 1 modules ). Giảm việc sử dụng những stub và DriverCó thể thực hiệm kiểm nghiệm tích hợp theo cả 2 cách bottom-up và top-down tùy thuộcvào mối quan hệ sử dụng lần nhau giữa những module. c. Kiểm nghiệm mạng lưới hệ thống : Bao gồm một loạt những kiểm nghiệm nhằm mục đích xác định hàng loạt những thành phần của hệ thốngđược tích hợp một cách đúng đắn. 11M ục đích của kiểm nghiệm mạng lưới hệ thống là để đảm bảo hàng loạt mạng lưới hệ thống hoạt động giải trí như mong muốn màkhách hàng mong ước. Bao gồm những loại kiểm nghiệm sau : Kiểm nghiệm công dụng ( Function testing ) Kiểm tra mạng lưới hệ thống sau khi tích hợp có hoạt động giải trí đúng tính năng vớiyêu cầu đặt ra trong bản diễn đạt nhu yếu hay không. Ví dụ : với mạng lưới hệ thống giải quyết và xử lý văn bản thì kiểm tra những công dụng tạo tàiliệu, sửa tài liệu, xoá tài liệu … có hoạt động giải trí hay không. Kiểm nghiệm hiệu suất ( Perfomance testing ) Kiểm nghiệm mức độ cung ứng ( stress testing ) Thực thi mạng lưới hệ thống với giả thiết là những tài nguyên mạng lưới hệ thống yêu cầukhông cung ứng được về chất lượng, không thay đổi và số lượng. Kiểm nghiệm thông số kỹ thuật ( configuration tessting ) Phân tích mạng lưới hệ thống với những thiết lập thông số kỹ thuật khác nhau. Kiểm nghiệm không thay đổi ( robustness tessting ) Kiểm nghiệm dưới những điều kiện kèm theo không mong đợi ví dụ như ngườidùng gõ lệnh sai, nguồn điện bị ngắt. Kiểm nghiệm hồi sinh ( recovery testing ) Chỉ ra những hiệu quả trả về khi xảy ra lỗi, mất tài liệu, thiết bị, dịchvụ … hoặc xoá những tài liệu mạng lưới hệ thống và xem năng lực phục sinh củanó. Kiểm nghiệm quá tải ( overload testing ) Đánh giá mạng lưới hệ thống khi nó vượt qua số lượng giới hạn được cho phép. Ví dụ : một hệthống giao tác ( transaction ) được nhu yếu thực thi 20 giao tác / giây. Khi đó sẽ kiểm tra nếu 30 giao tác / giây thì như thế nào ? Kiểm nghiệm chất lượng ( quality testing ) Đánh giá sự tin yêu, yếu tố trùng tu, tính sẳn sàng của mạng lưới hệ thống. Bao gồm cả việc đo lường và thống kê thời hạn trung bình mạng lưới hệ thống sẽ bị hỏngvà thời hạn trung bình để khắc phục. Kiểm nghiệm setup ( Installation testing ) Người dùng sử dụng những công dụng của mạng lưới hệ thống và ghi lại những lỗitại vị trí sử dụng thật sự. Ví dụ : một mạng lưới hệ thống được phong cách thiết kế để thao tác trên tàu thủy phảiđảm bảo không bị ảnh hưởng tác động gì bởi điều kiện kèm theo thời tiết khác nhauhoặc do sự chuyển dời của tàu. d. Kiểm nghiệm chấp nhậnNhằm đảm bảo việc người dùng có được mạng lưới hệ thống mà họ nhu yếu. Việc kiểm nghiệm nàyhoàn thành bởi người dùng phụ thuộc vào vào những hiểu biết của họ vào những nhu yếu. 12CH ƯƠNG 2 : KIỂM CHỨNG VÀ XÁC NHẬN ( V và V ) 2.1. Lập kế hoạch V&V ( Verification and validation planning ) 2.2. Kiểm tra phần mềm ( Software inspections ) 2.3. Phân tích tĩnh tự động hóa ( Automated static analysis ) 2.4. Phát triển phần mềm phòng sạch ( Cleanroom software development ) 2.1. Kiểm chứng và hợp lệ hoáKiểm thử phần mềm là một yếu tố trong chủ điểm rộng hơn thường được thamkhảo tới như yếu tố kiểm chứng và hợp lệ hoá ( V&V ). Kiểm chứng nói tới một tậpcác hành vi đảm bảo rằng phần mềm setup đúng cho một công dụng đặc biệt quan trọng. Hợp lệ hoá nói tới một tập những hoạt động giải trí khác đảm bảo rằng phần mềm đã được xâydựng lại theo nhu yếu của người mua. Bochm phát biểu điều này theo cách khác : Kiểm chứng : “ Chúng ta có làm ra mẫu sản phẩm đúng không ? ” Hợp lệ hoá : “ Chúng ta có làm ra đúng mẫu sản phẩm không ? ” Định nghĩa về V&V bao quát nhiều hoạt động giải trí ta đã tìm hiểu thêm tới như việc đảm bảochất lượng phần mềm ( SQA ). Các giải pháp kỹ nghệ phần mềm cung ứng nền tảng để thiết kế xây dựng nên chất lượng. Các giải pháp nghiên cứu và phân tích, phong cách thiết kế và triển khai ( mã hoá ) làm nâng cao chất lượngbằng cách đưa ra những kỹ thuật thống nhất và tác dụng dự kiến được. Các cuộc họpxét duyệt kỹ thuật chính thức ( thảo trình ) giúp đảm bảo chất lượng của sản phẩmđược tạo ra như hệ quả của từng bước kỹ nghệ phần mềm. Qua hàng loạt tiến trìnhnày, việc đo đạc và trấn áp được vận dụng cho mọi thành phần của thông số kỹ thuật phần mềm. Các chuẩn và thủ tục giúp đảm bảo tính thống nhất và tiến trình SQA chính thứcbuộc phải thi hành “ triết lý chất lượng hàng loạt ”. Việc kiểm thử cung ứng một thành luỹ ở đầu cuối để hoàn toàn có thể thẩm định và đánh giá về chất lượng, lỗi hoàn toàn có thể được phát hiện ra một cách trong thực tiễn hơn. Nhưng không nên coi kiểm thử như một tấm lưới bảo đảm an toàn. Như người ta vẫn nói, “ Bạn không hề kiểm thử được chất lượng. Nếu nó không sẵn có trước khi bạn bắt đầukiểm thử thì nó sẽ chẳng có khi bạn kết thúc kiểm thử. ” Chất lượng được tổng hợp vàotrong phần mềm trong hàng loạt tiến trình kỹ nghệ phần mềm. Việc vận dụng đúng cácphương pháp và công cụ, những cuộc họp xét duyệt kỹ thuật chính thức và việc quản lývững chắc cùng cách đo đạc toàn bộ dẫn tới chất lượng được xác nhận trong khi kiểmthử. 13H ình 2.1 Đạt đến chất lượng phần mềmMiller kể lại việc kiểm thử phần mềm về đảm bảo chất lượng bằng cách nói rằng “ động cơ nền tảng của việc kiểm thử chương trình là để xác nhận chất lượng phầnmềm bằng những giải pháp hoàn toàn có thể được vận dụng một cách kinh tế tài chính và hiệu quảcho cả những mạng lưới hệ thống quy mô lớn và nhỏ. ” Điều quan trọng cần chú ý quan tâm rằng việc kiểm chứng và hợp lệ hoá gồm có một phạm virộng những hoạt động giải trí SQA có chứa cả họp xét duyệt chính thức, truy thuế kiểm toán chất lượngvà thông số kỹ thuật, điều phối hiệu năng, mô phỏng, điều tra và nghiên cứu khả thi, xét duyệt tài liệu, xétduyệt cơ sở tài liệu, nghiên cứu và phân tích thuật toán, kiểm thử tăng trưởng, kiểm thử chất lượng, kiểm thử cài đăt. Mặc dầu việc kiểm thử đóng một vai trò cực kỳ quan trọng trongV và V, nhiều hoạt động giải trí khác cũng còn cần tới. 2.1.1. Tổ chức việc kiểm thử phần mềmVới mọi dự án Bất Động Sản phần mềm, có một xích míc cố hữu về quyền lợi Open ngay khiviệc kiểm thử mở màn. Người đã xây phần mềm giờ đây được nhu yếu kiểm thử phầnmềm. Điều này bản thân nó có vẻ như vô hại ; sau rốt, ai biết được chương trình kỹhơn là người làm ra nó ? Nhưng không may, cũng những người tăng trưởng này lại cómối chăm sóc chứng tỏ rằng chương trình là không có lỗi, rằng nó thao tác đúngtheo nhu yếu người mua, rằng nó sẽ được hoàn tất theo lịch biểu và trong phạm vingân sách. Một trong những mối chăm sóc này lại làm giảm bớt việc tìm ra lỗi trongtoàn bộ tiến trình kiểm thử. Theo quan điểm tâm ý, việc nghiên cứu và phân tích và phong cách thiết kế phần mềm ( cùng với mã hoá ) lànhiệm vụ thiết kế xây dựng. Người kỹ sư phần mềm tạo ra một chương trình máy tính, tài liệuvề nó và những cấu trúc tài liệu có tương quan. Giống như bất kể người thiết kế xây dựng nào, người kỹ sư phần mềm tự hào về dinh thự đã được kiến thiết xây dựng và nhìn nghi vấn vào bất14kỳ ai định làm sập đổ nó. Khi việc kiểm thử mở màn, có một nỗ lực phức tạp, dứt khoátđể “ đập vỡ ” cái người kỹ sư phần mềm đã kiến thiết xây dựng. Theo quan điểm của người xâydựng, việc kiểm thử hoàn toàn có thể được coi như ( về tâm ý ) có tính phá hoại. Cho nên ngườixây dựng dè dặt đề cập tới việc kiểm thử phong cách thiết kế và thực thi sẽ chứng tỏ rằngchương trình thao tác, thay vì phát hiện lỗi. Điều không may lỗi sẽ hiện hữu. Và nếungười kỹ sư phần mềm không tìm ra chúng thì người mua sẽ tìm ra. Thường có 1 số ít nhận thức sai hoàn toàn có thể được suy diễn sai lầm từ luận bàn trên : ( 1 ) người tăng trưởng phần mềm không nên triển khai kiểm thử ; ( 2 ) phần mềm nên được “ tung qua tường ” cho người lạ thao tác kiểm thử một cách tàn tệ ; ( 3 ) người kiểmthử nên tham gia vào dự án Bất Động Sản chỉ khi bước kiểm thử sắp sửa mở màn. Từng phát biểunày đều không đúng. Người phát biểu phần mềm khi nào cũng có nghĩa vụ và trách nhiệm với việc kiểm thử riêng cácđơn vị ( mô đun ) chương trình, để đảm bảo rằng mỗi mô đun thực thi đúng chứcnăng nó đã được phong cách thiết kế. Trong nhiều trường hợp, người tăng trưởng cũng tiến hànhcả kiểm thử tích hợp – bước kiểm thử dẫn đến việc kiến thiết xây dựng ( và kiểm thử ) toàn bộcấu trúc chương trình. Chỉ sau khi kiến trúc phần mềm hoàn tất thì nhóm kiểm thửđộc lập mới tham gia vào. Vai trò của nhóm kiểm thử độc lập ( ITG ) là vô hiệu yếu tố cố hữu tương quan tới việcđể người kiến thiết xây dựng kiểm thử những cái anh ta đã thiết kế xây dựng ra. Việc kiểm thử độc lậploại bỏ xung khắc quyền lợi nếu không có nhóm đó thì có thể hiện hữu. Cuối cùng nhânsự trong nhóm kiểm thử độc lập được trả tiền để tìm ra lỗi. Tuy nhiên, người tăng trưởng phần mềm không chuyển giao chương trình cho ITG rồibỏ đi. Người tăng trưởng và ITE thao tác ngặt nghèo trong hàng loạt dự án Bất Động Sản phần mềm đểđảm bảo rằng những kiểm thử kỹ lưỡng sẽ được thực thi. Trong khi triển khai kiểmthử, người tăng trưởng phải có sẳn để sửa chữa thay thế lỗi đã phát hiện ra. ITG là một phần của nhóm dự án Bất Động Sản tăng trưởng phần mềm theo nghĩa là nó tham dựtrong tiến trình đặc tả và vẫn còn tham gia ( lập kế hoạch và xác lập những thủ tục kiểmthử ) trong hàng loạt dự án Bất Động Sản lớn. Tuy nhiên, trong nhiều trường hợp ITG báo cáo giải trình cho tổchức đảm bảo chất lượng phần mềm, do đó đạt tới một mức độ độc lập hoàn toàn có thể khôngcó được nếu nó là một phần của tổ chức triển khai tăng trưởng phần mềm. 2.1.2. Chiến lược kiểm thử phần mềmTiến trình kỹ nghệ phần mềm hoàn toàn có thể được xét theo vòng xoắn ốc, như được minhhoạ trong Hình 2.2. Ban đầu, kỹ nghệ phần mềm xác lập vai trò của phần mềm vàđưa tới việc nghiên cứu và phân tích nhu yếu phần mềm, chỗ thiết lập nên nghành thông tin, chứcnăng, hành vi, hiệu năng, ràng buộc và tiêu chuẩn hợp lệ cho phần mềm. Đi vào trongvòng xoắn ốc, tất cả chúng ta tới phong cách thiết kế và ở đầu cuối tới mã hoá. Để thiết kế xây dựng phần mềmmáy tính, tất cả chúng ta đi dọc theo đường xoắn ốc, mỗi lần mức độ trừu tượng lại giảmdần. Một kế hoạch cho kiểm thử phần mềm cũng hoàn toàn có thể xem xét bằng cách đi theo đườngxoắn ốc của Hình 2.2 ra ngoài. Việc kiểm thử đơn vị chức năng khởi đầu tại tâm xoáy của xoắn ốcvà tập chung vào những đơn vị chức năng của phần mềm khi được setup trong chương trình gốc. Việc kiểm thử tiến triển bằng cách đi ra theo đường xoắn ốc tới kiểm thử tích hợp, nơi tập trung chuyên sâu vào phong cách thiết kế và việc thiết kế xây dựng kiến trúc phần mềm. Đi thêm một vòngxoáy nữa trên đường xoắn ốc tất cả chúng ta gặp kiểm thử hợp lệ, nơi những nhu yếu, được15thiết lập như một phần của việc nghiên cứu và phân tích nhu yếu phần mềm, được hợp lệ hoá theophần mềm đã được thiết kế xây dựng. Cuối cùng tất cả chúng ta tới kiểm thử mạng lưới hệ thống, nơi phầnmềm và những thành phần mạng lưới hệ thống khác được kiểm thử như một hàng loạt. Để kiểm thửphần mềm máy tính, tất cả chúng ta theo đường xoáy lan rộng ra dần khoanh vùng phạm vi kiểm thử mộtlần. Hình 2.3 Các bước kiểm thử phần mềmXem xét tiến trình này theo quan điểm thủ tục vì việc kiểm thử bên trong hoàncảnh kỹ nghệ phần mềm thực tại là một chuỗi gồm ba bước được triển khai tuần tựnhau. Các bước này được vẽ trong Hình 2.3. Ban đầu, việc kiểm thử tập trung chuyên sâu vàotừng mô đun riêng không liên quan gì đến nhau, đảm bảo rằng nó quản lý và vận hành đúng đắn như một đơn vị chức năng. Do đómới có tên kiểm thử đơn vị chức năng. Kiểm thử đơn vị chức năng dùng rất nhiều những kỹ thuật kiểm thửhộp trắng, thử những đường đặc biệt quan trọng trong cấu trúc điều khiển và tinh chỉnh của một mô đun để đảmbảo bao quát rất đầy đủ và phát hiện ra lỗi tối đa. Tiếp đó những mô đun phải được lắpghép hay tích hợp lại để tạo nên bộ trình phần mềm hoàn hảo. Việc kiểm thử tíchhợp đề cập tới những yếu tố có tương quan tới những yếu tố kiểm chứng và thiết kế xây dựng chươngtrình. Các kỹ thuật phong cách thiết kế kiểm thử hộp đen chiếm đại đa số trong việc tích hợp, mặc dầu 1 số ít số lượng giới hạn những kiểm thử hộp trắng cũng hoàn toàn có thể dược dùng để đảm bảobao quát đa phần những đường điều khiển và tinh chỉnh. Sau khi phần mềm đã được tích hợp ( được thiết kế xây dựng ), một tập những phép kiểm thử caocấp sẽ được triển khai. Các tiêu chuẩn hợp lệ ( được thiết lập trong nghiên cứu và phân tích nhu yếu ) cũng phải được kiểm thử. Việc kiểm thử hợp lệ đưa ra sự đảm bảo sau cuối rằngphần mềm phân phối cho toàn bộ những nhu yếu tính năng, hành vi và sự triển khai xong. Cáckỹ thuật kiểm thử hộp đen được dùng hầu hết trong việc hợp lệ hoá này. Bước kiểm thử cấp cao ở đầu cuối rơi ra ngoài khoanh vùng phạm vi của kỹ nghệ phần mềm vàrơi vào thực trạng rộng hơn của kỹ nghệ mạng lưới hệ thống máy tính. Phần mềm, một khi đượchợp lệ hoá, phải được tổng hợp với những thành phần mạng lưới hệ thống khác ( như phần cứng, conngười, cơ sở tài liệu ). Kiểm thử mạng lưới hệ thống kiểm chứng lại rằng toàn bộ những yếu tố có16khớp đúng với nhau không và rằng tính năng / độ triển khai xong mạng lưới hệ thống hàng loạt đã đạtđược. 2.1.3. Tiêu chuẩn triển khai xong kiểm thửCâu hỏi cổ xưa phát sinh mỗi khi có việc luận bàn về kiểm thử phần mềm là : Khinào tất cả chúng ta triển khai xong kiểm thử – làm thế nào ta biết rằng tất cả chúng ta đã kiểm thửđủ ? Đáng buồn là không có câu vấn đáp xác lập cho câu hỏi này, nhưng có một vài sựđáp ứng trong thực tiễn và những nỗ lực bắt đầu theo hướng dẫn kinh nghiệm tay nghề. Một phân phối cho câu hỏi trên là : Bạn chẳng khi nào hoàn thành xong việc kiểm thử, gánh nặng đơn thuần chuyển từ bạn ( người tăng trưởng ) sang người mua của bạn. Mỗilúc người mua / người dùng triển khai một chương trình máy tính thì chương trìnhnày lại được kiểm thử trên một tập tài liệu mới. Sự kiện đúng mức này nhấn mạnhtầm quan trọng của những hoạt động giải trí đảm bảo chất lượng phần mềm khác. Một đáp ứngkhác ( có điều gì đó nhạo báng nhưng dẫu sao cũng đúng chuẩn ) là : Bạn hoàn thànhviệc kiểm thử khi bạn hết thời hạn hay hết tiền. Mặc dầu số ít người thực hành thực tế sẽ biện minh cho những phân phối trên, người kỹsư phần mềm cần những tiêu chuẩn ngặt nghèo hơn để xác lập khi nào việc kiểm thửđủ được thực thi. Musa và Ackerman gợi ý một phân phối dựa trên tiêu chuẩn thốngkê : “ Không, tất cả chúng ta không hề tuyệt đối chắc như đinh rằng phần mềm sẽ không baogiờ hỏng, nhưng theo quy mô thống kê đúng về kim chỉ nan và hợp lệ về thực nghiệmthì tất cả chúng ta đã hoàn thành xong kiểm thử đủ để nói với sự tin yêu tới 95 % rằng xác suấtcủa 1000 giờ quản lý và vận hành CPU không hỏng trong một môi trường tự nhiên được xác lập về xácsuất là tối thiểu 0.995 ” Dùng mô hình hoá thống kê và lí thuyết độ an toàn và đáng tin cậy phần mềm, những quy mô vềhỏng hóc phần mềm ( được phát hiện trong khi kiểm thử ) xem như một hàm của thờigian thực thi hoàn toàn có thể được kiến thiết xây dựng ra. Một bản của quy mô sai hỏng, được gọi làmô hình thực thi – thời hạn Poisson lô ga rit, có dạng : f ( t ) = ( 1 p ) x ln [ l0 ( pt + 1 ) ] ( 17.1 ) với f ( t ) = số tích luỹ những hỏng hóc dự kiến Open một khi phần mềm đãđược kiểm thử trong một khoảng chừng thời hạn thực thi t. l0 = tỷ lệ hỏng phần mềm khởi đầu ( số hỏng trên đơn vị chức năng thời hạn ) vào lúcbắt đầu kiểm thử. P = việc giảm theo hàm mũ trong tỷ lệ hỏng khi lỗi được phát hiện và sữađổi được triển khai. Mật độ hỏng thể nghiệm. l ( t ), hoàn toàn có thể được suy ra bằng cách lấy đạo hàm của f ( t ) : l0F ( t ) = l 0 pt + 1 ( 17.2 ) Dùng mối quan hệ trong phương trình ( 2.2 ), người kiểm thử hoàn toàn có thể tiên đoánviệc loại bỏ lỗi khi việc kiểm thử tiến triển. Mật độ lỗi thực tại hoàn toàn có thể được chấm lêntrên đường cong dự kiến ( hình 2.4 ). Nếu tài liệu thực tài được tích lũy trong khi17kiểm thử và quy mô triển khai – thời hạn theo logarit Poisson là xê dịch gần nhau vớisố điểm tài liệu thì quy mô này hoàn toàn có thể được dùng để Dự kiến thời hạn kiểm thử toànbộ cần để đạt tới tỷ lệ hỏng thấp đồng ý được. Bằng cách tích lũy những độ đo trong khi kiểm thử phần mềm và dùng những môhình về độ an toàn và đáng tin cậy phần mềm hiện có, hoàn toàn có thể tăng trưởng những hướng dẫn có nghĩa đểtrả lời thắc mắc : Khi nào thì tất cả chúng ta triển khai xong việc kiểm thử ? Còn ít tranh luận vềviệc có phải làm việc làm thêm nữa hay không trước khi những quy tắc định tính chokiểm thử hoàn toàn có thể xác lập, nhưng cách tiếp cận kinh nghiệm tay nghề hiện đang sống sót được coilà tốt hơn đáng kể so với trực giác thô. 2.2. Phát triển phần mềm phòng sạch ( cleanroom software development ) Cleanroom là một qui trình tăng trưởng phần mềm hơn là một kỹ thuật kiểm thử. Chođến giờ đây, kỹ thuật này vẫn được xem là một cách mới của việc tâm lý về kiểmthử và đảm bảo chất lượng phần mềm. Ý tưởng của cleanroom là nhằm mục đích tránh tiêutốn ngân sách cho hoạt động giải trí phát hiện và gỡ bỏ những lỗi bằng cách viết mã lệnh chươngtrình một cách đúng mực ngay từ khởi đầu với những giải pháp chính thống nhưkỹ thuật chứng tỏ tính đúng đắn trước khi kiểm thử. 2.2.1. Nghệ thuật của việc gỡ rốiKiểm thử phần mềm là một tiến trình hoàn toàn có thể được vạch kế hoạc và xác lập một cáchhệ thống. Việc phong cách thiết kế trường hợp kiểm thử hoàn toàn có thể triển khai một kế hoạch xác địnhvà có tác dụng được đo lường và thống kê theo thời hạn. Gỡ lỗi Open như hậu quả của việc kiểm thử thành công xuất sắc. Tức là, khi một trườnghợp kiểm thử phát hiện ra lỗi thì việc gỡ lỗi là tiến trình sẽ phát sinh để loại bỏ lỗi. Mặc dầu việc gỡ lỗi hoàn toàn có thể nên là một tiến trình có trật tự, nó hầu hết còn là nghệthuật. Người kỹ sư phần mềm khi tính những hiệu quả của phép thử, thường hay phảiđương đầu với hướng dẫn “ triệu chứng ” và yếu tố phần mềm. Tức là, cái biểu lộ ra bênngoài của lỗi và nguyên do bên trong của lỗi hoàn toàn có thể có mối quan hệ không hiểnnhiên tới một lỗi khác. Tiến trình tâm lý ít hiểu biết gắn một triệu chứng với nguyênnhân chính việc gỡ lỗi. 2.2.2. Tiến trình gỡ lỗiGỡ lỗi không phải là kiểm thử, nhưng khi nào cũng Open như một hệ quả kiểmthử. Tham khảo đến hình 2.12 thì tiến trình gỡ lỗi khởi đầu với việc triển khai kiểmthử. Kết quả được thẩm định và đánh giá và gặp việc thiếu sự tương ứng giữa hiệu quả trông đợivà trong thực tiễn. Trong nhiều trường hợp, tài liệu không tương ứng là triệu chứng của mộtnguyên nhân nền tảng còn bị trùm kín. Tiến trình gỡ lỗi cố gắng nỗ lực ghép triệu chứng vớinguyên nhân, từ đó dẫn tới việc sửa lỗi. Tiến trình gỡ lỗi khi nào cũng sinh ra một trong hai tác dụng logic : ( 1 ) Nguyênnhân sẽ được tìm ra, thay thế sửa chữa và vô hiệu hay ( 2 ) nguyên do sẽ không được tìm ra. Trong trường hợp sau, người triển khai gỡ lỗi hoàn toàn có thể thiếu tín nhiệm một nguyên do, thiếtkế ra một trường hợp kiểm thử giúp hợp lệ hoá thiếu tín nhiệm của mình, và việc lầmhướng tới việc sửa lỗi theo cách lặp lại. 18T ại sao gỡ lỗi lại khó ? Rất hoàn toàn có thể tâm ý con người ( xem mục sau ) có tương quan tớinhiều câu vấn đáp hơn là công nghệ phần mềm. Tuy nhiên môt vài đặc trưng của lỗiđưa ra vài manh mối : o Triệu chứng và nguyên do hoàn toàn có thể xa nhau về mặt địa lý. Tức là, nhữngtriệu chứng hoàn toàn có thể Open trong một phần này của chương trình, trong khinguyên nhân trong thực tiễn hoàn toàn có thể xác định ở một vị trí xa. Các cấu trúc chươngtrình song song với nhau làm trầm trọng thêm trường hợp này. o Triệu chứng hoàn toàn có thể biến mất ( trong thời điểm tạm thời ) khi một lỗi khác được thay thế sửa chữa. o Triệu chứng thực tế hoàn toàn có thể gây ra không lỗi ( như do sự không đúng mực củaviệc làm tròn số ). o Triệu chứng hoàn toàn có thể được gây ra do lỗi con người không dễ lần dấu vết. o Triệu chứng hoàn toàn có thể là tác dụng của yếu tố thời hạn, thay vì yếu tố giải quyết và xử lý. o Có thể khó tái tạo lại đúng mực những điều kiện kèm theo vào ( như ứng dụng thời gianthực trong đó thứ tự vào không xác lập ) o Triệu chứng hoàn toàn có thể có lúc có lúc không. Điều này đặc biệt quan trọng phổ cập trongcác mạng lưới hệ thống nhúng việc đi đôi phần cứng và phần mềm không ngặt nghèo. o Triệu chứng hoàn toàn có thể do nguyên do được phân bổ qua 1 số ít những nhiệm vụchạy trên những bộ giải quyết và xử lý khác nhau. o Trong khi gỡ lỗi, tất cả chúng ta gặp không ít những lỗi chạy từ việc hơi không dễ chịu ( như định dạng cái ra không đúng ) tới những thảm hoạ ( như mạng lưới hệ thống hỏng, gây ra những thiệt hại kinh tế tài chính hay vật lý trầm trọng ). Xem như hậu quả củaviệc tăng lỗi, khối lượng sức ép để tìm ra lỗi cũng tăng thêm. Thôngthường, sức ép buộc người tăng trưởng phần mềm phải tìm ra lỗi và đồng thờiđưa vào thêm hai lỗi nữa. 2.2.3. Xem xét tâm lýKhông may, có vẻ như có 1 số ít bằng cớ là sự tinh thông gỡ lỗi thuộc bẩm sinh conngười. Một số người thao tác đó rất giỏi, số khác lại không. Mặc dù bằng cớ kinhnghiệm về gỡ lỗi vẫn còn để mở cho nhiều cách hiểu, nhưng biến thiên lớn nhất trongkhả năng gỡ lỗi đã được báo cáo giải trình lại so với những kỹ sư phần mềm có cùng nền tảngkinh nghiệm và giáo dục. Bình luận về góc nhìn gỡ lỗi của con người, Shneiderman phát biểu : Gỡ lỗi là một trong những phần chán nhất của lập trình. Nó có yếu tố của việc giảiquyết yếu tố hay yếu tố hóc búa, song song với việc thừa nhận không dễ chịu rằng bạn đã sailầm. Hay âu lo và không sẵn lòng đồng ý năng lực lỗi làm tăng khó khăn vất vả chocông việc. May mắn là có sự giảm nhẹ và bớt stress khi lỗi sau cuối đã đượcsửa lỗi. Mặc dầu hoàn toàn có thể khó học được việc gỡ lỗi, người ta vẫn đề xuất ra 1 số ít cách tiếp cậntới yếu tố. Chúng ta xem xét những yếu tố này trong mục tiếp. 2.2.4. Cách tiếp cận gỡ lỗiBất kể tới cách tiếp cận nào được chọn gỡ lỗi có một tiềm năng quan trọng hơn cả : tìmra và thay thế sửa chữa nguyên do lỗi phần mềm. Mục tiêu này được triển khai bằng tổ hợp19các nhìn nhận có mạng lưới hệ thống, trực giác và suôn sẻ. Bradley miêu tả cách tiếp cận gỡ lỗitheo cách này : Gỡ lỗi là việc ứng dụng trực tiếp chiêu thức khó học đã từng được tăng trưởng hơn2500 năm qua. Cơ sở của việc gỡ lỗi là xác định nguồn gốc của yếu tố [ nguyên do ] bằng việc phân hoạch nhị phân, trải qua những giả thiết thao tác để Dự kiến những giátrị mới cần kiểm tra. Ta hãy lấy một ví dụ không phải phần mềm : Đèn trong nhà tôi không thao tác. Nếukhông có gì trong nhà thao tác thì nguyên do phải là cầu chì chính hay ở bênngoài ; tôi nhìn quanh để liệu xem hàng xóm có bị tắt đèn hay không. Tôi cắm chiếcđèn hoài nghi vào ổ cắm khác và cắm một đồ điện khác vào mạch hoài nghi. Cứ thếtiến hành những giải pháp xử lý kiểm thử. Nói chung, hoàn toàn có thể đưa ra ba loại những tiếp cận gỡ lỗi : Bó buộc mạnh bạoLật ngượcLoại bỏ nguyên nhânLoại gò bó khỏe mạnh có lẽ rằng là giải pháp thông dụng nhất và kém hiệu suất cao nhấtđể cô lập nguyên do của lỗi phần mềm. Chúng ta vận dụng giải pháp gỡ lỗi bóbuộc khỏe mạnh khi tổng thể những giải pháp khác đều thất bại. Dùng triết lý “ cứ đểmáy tính tìm ra lỗi ”, người ta cho xổ ra nội dung bộ nhớ, gọi tới chương trình lưu dấuvết khi chạy và nạp chương trình với lệnh WRITE. Chúng ta kỳ vọng rằng đâu đótrong bãi lầy thông tin dược tạo ra, tất cả chúng ta hoàn toàn có thể tìm ra được một nguyên do củalỗi. Mặc dầu đống thông tin được tạo ra sau cuối hoàn toàn có thể dẫn tới thành công xuất sắc, thườnghơn cả là nó dẫn đến phí phạm công sức của con người và thời hạn. Phải dành tâm lý vào đótrước hết đã. Lật ngược lại cách tiếp cận khá thông dụng hoàn toàn có thể được dùng trong những chươngtrình nhỏ. Bắt đầu tại chỗ chúng được phát hiện ra, lật ngược theo những chươngtrình gốc ( một cách thủ công bằng tay ) cho tới chỗ tìm ra nguyên do. Không may là khi sốdòng chương trình gốc tăng lên, số con đường lật ngược tiềm năng hoàn toàn có thể trở nênkhông quản trị nổi. Cách tiếp cận thứ ba tới gỡ lỗi – vô hiệu nguyên do được biểu lộ bằng việc quy nạphay diễn dịch và đưa vào khái niệm về phân hoạch nhị phân. Dữ liệu có tương quan tớiviệc Open lỗi được tổ chức triển khai để cô lập ra những nguyên do tiềm năng. Một “ giả thiếtnguyên nhân ” được nêu ra và tài liệu trên được dùng để chứng tỏ hay bác bỏ giảthiết đó. Một cách khác, ta hoàn toàn có thể kiến thiết xây dựng ra một list mọi nguyên do đặcbiệt có nhiều hứa hẹn thì tài liệu sẽ được làm mịn thêm để nỗ lực cô lập ra lỗi. Từng cách tiếp cận gỡ lỗi trên đây đều hoàn toàn có thể được bổ trợ thêm bởi công cụ gỡ lỗi. Chúng ta hoàn toàn có thể vận dụng một khoanh vùng phạm vi rộng những trình biên dịch gỡ lỗi, nhưng trợ giúpgỡ lỗi động ( “ Bộ dò dấu vết ” ), những bộ sinh trường hợp kiểm thử tự động hóa, sổ bộ nhớ vàbảng tìm hiểu thêm chéo. Tuy nhiên những công cụ đều không phải là cách thay thế sửa chữa cho việcđánh giá dựa trên tài liệu phong cách thiết kế phần mềm khá đầy đủ và chương trình gốc rõ ràng. Trong nhiều trường hợp, việc gỡ lỗi phần mềm máy tính tựa như việc xử lý vấnđề trong quốc tế kinh doanh thương mại. Brow và Sampson đã đưa ra một cách tiếp cận gỡ lỗitên là “ Phương pháp ”, đó là việc thích nghi những kỹ thuật xử lý yếu tố quản trị. Các tác giả này đề xuất tăng trưởng một bản đặc tả về những độ lệch, diễn đạt cho vấn đềbằng cách phác họa “ cái gì, khi nào, ở đâu và với khoanh vùng phạm vi nào ? ” 20M ỗi một trong những yếu tố nêu trên ( cái gì, khi nào, ở đâu và với khoanh vùng phạm vi nào ) đềuđược chỉ ra thành những cung ứng là hay không là để phân biệt rõ ràng giữa cái gì đãxảy ra và cái gì đã không xảy ra. Một khi thông tin về lỗi đã được ghi lại thì người taxây dựng ra một giả thiết nguyên do dựa trên những phân biệt quan sát được từnhững phân phối là hay không là. Việc gỡ lỗi liên tục dùng cách tiếp cận qui nạp haydiễn dịch được miêu tả phần trên trong mục này. Bất kỳ luận bàn nào về cách tiếp cận và công cụ gỡ lỗi cũng đều không khá đầy đủ nếukhông nói tới một liên minh can đảm và mạnh mẽ : Người khác ! Khái niệm về “ lập trình vô ngã ” của Weinberg ( được luận bàn trước đây trong cuốn sách này ) nên được mở rộngthành gỡ lỗi vô ngã. Mỗi người tất cả chúng ta đều hoàn toàn có thể nhớ lại điều gì khó xử khi mấthàng giờ, hàng ngày vì một lỗi dai dẳng. Một đồng nghiệp vẩn vơ đi qua trong nỗithất vọng rồi chúng tôi lý giải và tung ra bản tin chương trình ra. Lập tức ( dườngnhư ) nguyên do lỗi bị phát hiện ra. Mỉm cười một cách ngạo nghễ, anh bạn đồngnghiệp tất cả chúng ta biến mất. Một quan điểm mới lạ, không bị bao trùm bởi hàng giờthất vọng, hoàn toàn có thể tạo ra những điều kỳ diệu. Câu châm ngôn sau cuối về gỡ lỗi có thểlà : Khi tổng thể mọi thứ khác đều sai thì hãy nhờ sự trợ giúp. Một khi lỗi đã được tìm ra, thì nó phải được sửa chữa thay thế. Nhưng khi tất cả chúng ta đã chú ý quan tâm, việc sửa một lỗi nhiều lúc hoàn toàn có thể lại đưa vào một lỗi khác và do đó lại gây hại hơn là tốt. Van Vleck gợi ý ba câu hỏi đơn thuần người kỹ sư phần mềm nên hỏi trước khi tiếnhành sửa chữa thay thế để vô hiệu nguyên do gây lỗi : Liệu nguyên do gây lỗi này có bị tái tạo ở phần khác của chương trình hay không ? Trong nhiều trường hợp, một khiếm khuyết chương trình bị gây ra bởi một mẫu hìnhlogic sai sót hoàn toàn có thể còn phát sinh ở đâu đó khác nữa. Việc xem xét tường minh vềmẫu hình logic này hoàn toàn có thể làm phát hiện ra thêm những lỗi khác “ Lỗi tiếp ” hoàn toàn có thể bị đưa vào là gì khi tôi chữa lỗi này ? Trước khi việc sửa lỗi đượctiến hành, chương trình gốc ( hay tốt hơn, phong cách thiết kế ) nên được nhìn nhận lại để thẩmđịnh việc dính nối những cấu trúc logic tài liệu. Nếu việc sửa lỗi được triển khai trongmột phần có độ dính nối cao thì càng phải để tâm nhiều khi thực thi bất kể một sựthay đổi nào. Ta hoàn toàn có thể làm gì để ngăn cản lỗi này ngay từ đầu ? Câu hỏi này là trong bước đầu tiênhướng tới việc thiết lập một cách tiếp cận đảm bảo chất lượng phần mềm thống kê. Nếu ta sửa chương trình cũng như loại sản phẩm thì lỗi sẽ vô hiệu chương trình hiện tại vàcó thể bị khử bỏ mọi chương trình tương lai21CHƯƠNG 3 : KIỂM THỬ PHẦN MỀMMục tiêu của chương này là miêu tả quy trình kiểm thử phần mềm và đưa ra những kỹ thuậtkiểm thử. Khi đọc chương này, bạn sẽ : Hiểu được sự độc lạ giữa kiểm thử hợp lệ và kiểm thử khiếm khuyết. Hiểu được những nguyên tắc của kiểm thử mạng lưới hệ thống và kiểm thử bộ phận. Hiểu được ba kế hoạch hoàn toàn có thể sử dụng để sinh những trường hợp kiểm thử mạng lưới hệ thống. Hiểu được những đặc thù thực chất của công cụ phần mềm được sử dụng để kiểm thửtự động. 3.1. Quá trình kiểm thửQuá trình kiểm thử phần mềm có hai tiềm năng riêng không liên quan gì đến nhau : 1. Chứng minh cho người tăng trưởng và người mua thấy những nhu yếu của phần mềm. Với phần mềm truyền thống cuội nguồn, điều này có nghĩa là bạn có tối thiểu một thử nghiệmcho mỗi nhu yếu của người dùng và tài liệu mạng lưới hệ thống nhu yếu. Với những sản phẩmphần mềm chung, điều đó có nghĩa là bạn nên thử nghiệm tổng thể những đặc tính của hệthống sẽ được phối hợp trong loại sản phẩm phát hành. 2. Phát hiện những lỗi và khiếm khuyết trong phần mềm : phần mềm thực thi khôngđúng, không như mong đợi hoặc không làm theo như đặc tả. Kiểm tra khiếmkhuyết tập trung chuyên sâu vào việc tìm ra toàn bộ những kiểu triển khai không như mong đợi củahệ thống, như sự đổ vỡ mạng lưới hệ thống, sự tương tác không mong ước với hệ thốngkhác, đo lường và thống kê sai và sai lầm tài liệu. Kiểm thửthành phầnKiểm thửhệ thốngNhóm kiểm thử độc lậpNgười tăng trưởng phần mềmHình 3.1 Các quy trình tiến độ kiểm thửCáctrường hợpkiểm thửThiết kế trường hợpkiểm thửChuẩn bị dữ liệukiểm thửDữ liệuCác kết quảkiểm thửkiểm thửChạy chương trìnhvới tài liệu kiểm thửBáo cáokiểm thửSo sánh những kết quảVới những trường hợpthử nghiệmHình 3.2 Một quy mô của quy trình kiểm thử phần mềm22Mục tiêu thứ nhất dẫn đến kiểm thử hợp lệ, sử dụng tập những thử nghiệm phản ánh mongmuốn của người dùng để kiểm tra xem mạng lưới hệ thống có triển khai đúng không. Mục tiêu thứ haidẫn đến kiểm thử khiếm khuyết : những trường hợp kiểm thử được phong cách thiết kế để tìm ra cáckhiếm khuyết. Các trường hợp kiểm thử hoàn toàn có thể được làm không rõ và không cần phản ánhcách mạng lưới hệ thống thông thường được sử dụng. Với kiểm thử hợp lệ, một thử nghiệm thành cônglà thử nghiệm mà mạng lưới hệ thống thực thi đúng đắn. Với kiểm thử khiếm khuyết, một thửnghiệm thành công xuất sắc là một thử nghiệm tìm ra một khiếm khuyết, nguyên do làm cho hệthống triển khai không đúng mực. Kiểm thử hoàn toàn có thể không chứng tỏ được phần mềm không có khiếm khuyết, hoặc nó sẽthực hiện như đặc tả trong mọi trường hợp. Rất hoàn toàn có thể một thử nghiệm bạn bỏ lỡ có thểphát hiện ra những yếu tố khác trong mạng lưới hệ thống. Như Dijstra, một người đi đầu trong việc pháttriển kỹ nghệ phần mềm, đã công bố ( 1972 ) : kiểm thử chỉ hoàn toàn có thể phát hiện ra những lỗi hiệntại, chứ không hề đưa ra tổng thể những lỗi. Nói chung, vì thế, tiềm năng của kiểm thử phần mềm là thuyết phục người tăng trưởng phầnmềm và người mua rằng phần mềm là đủ tốt cho những thao tác sử dụng. Kiểm thử là mộtquá trình được dùng để tạo nên sự tin cậy trong phần mềm. Mô hình tổng quát của quy trình kiểm thử được diễn đạt trong hình 3.2. Các trường hợpkiểm thử sự chỉ rõ của đầu vào để thử nghiệm và đầu ra mong đợi từ mạng lưới hệ thống cộng vớimột bản báo cáo giải trình loại sản phẩm đã được kiểm thử. Dữ liệu kiểm thử là nguồn vào, được nghĩ ra đểkiểm thử mạng lưới hệ thống. Dữ liệu kiểm thử nhiều lúc hoàn toàn có thể được tự động hóa sinh ra. Sinh cáctrường hợp kiểm thử tự động hóa là điều không làm được. Đầu ra của thử nghiệm chỉ có thểđược Dự kiến bởi người hiểm biết về hoạt động giải trí của mạng lưới hệ thống. Kiểm thử tổng lực : mọi chương trình hoàn toàn có thể thực thi tuần tự được kiểm tra, là điềukhông thể làm được. Vì vậy, kiểm thử, phải được triển khai trên một tập con những trườnghợp kiểm thử hoàn toàn có thể xảy ra. Trong lý tưởng, những công ty phần mềm có những điều khoảnđể lựa chọn tập con này hơn là giao nó cho đội tăng trưởng. Những lao lý này có thểdựa trên những pháp luật kiểm thử chung, như một pháp luật là toàn bộ những câu lệnhtrong chương trình nên được thực thi tối thiểu một lần. Một sự lựa chọn là những điều khoảnkiểm thử hoàn toàn có thể sự trên kinh nghiệm tay nghề sử dụng mạng lưới hệ thống, và hoàn toàn có thể tập trung chuyên sâu vào kiểm thửcác đặc trưng hoạt động giải trí của mạng lưới hệ thống. Ví dụ : 1. Tất cả những đặc trưng của mạng lưới hệ thống được truy vấn trải qua thực đơn nên được kiểmthử. 2. Kết hợp những công dụng ( ví dụ định dạng văn bản ) được truy vấn trải qua cùng thựcđơn phải được kiểm thử. 3. Khi đầu vào được đưa vào, toàn bộ những công dụng phải được kiểm thử với cùng một thửnghiệm đúng đắn và thử nghiệm không đúng đắn. Điều đó rõ ràng từ kinh nghiệm tay nghề với loại sản phẩm phần mềm lớn như phần mềm giải quyết và xử lý vănbản, hoặc bảng tính hoàn toàn có thể so sánh những nguyên tắc thường thì được sử dụng trong lúckiểm thử loại sản phẩm. Khi những đặc trưng của phần mềm được sử dụng cô lập, chúng làm việcbình thuờng. Các yếu tố phát sinh, như Whittaker lý giải ( Whittaker, 2002 ), khi liên kếtcác đặc trưng không được kiểm thử cùng nhau. Ông đã đưa ra một ví dụ, khi sử dụng phầnmềm giải quyết và xử lý văn bản sử dụng sử dụng lời chú thích ở cuối trang với cách sắp xếp nhiều cộtlàm cho văn bản trình diễn không đúng. Khi một phần của quy trình lập kế hoạch V và V, người quản trị phải đưa ra cácquyết định ai là người chịu nghĩa vụ và trách nhiệm trong từng bước kiểm thử khác nhau. Vớihầu hết những mạng lưới hệ thống, những lập trình viên chịu nghĩa vụ và trách nhiệm kiểm thử những thành phần23mà họ đã tiến hành. Khi những lập trình viên đã triển khai xong những việc làm đó, công việcđược giao cho đội tổng hợp, họ sẽ tích hợp những môđun từ những người phát triểnkhác nhau để tạo nên phần mềm và kiểm thử hàng loạt mạng lưới hệ thống. Với mạng lưới hệ thống quantrọng, một quy trình theo nghi thức hoàn toàn có thể được sử dụng, những người thử độc lập chịutrách nhiệm về toàn bộ những bước của quy trình kiểm thử. Trong kiểm thử hệ thốngquan trọng, những thử nghiệm được kiểm thử riêng không liên quan gì đến nhau và hồ sơ chi tiết cụ thể của kết quảkiểm thử được duy trì. Kiểm thử những thành phần được thực thi bởi những người tăng trưởng thường dựatrên hiểu biết trực giác về cách hoạt động giải trí của những thành phần. Tuy nhiên, kiểm thửhệ thống phải dựa trên văn bản đặc tả mạng lưới hệ thống. Đó hoàn toàn có thể là một đặc tả cụ thể yêucầu mạng lưới hệ thống, hoặc nó hoàn toàn có thể là đặc tả hướng người sử dụng ở mức cao của những đặctính được triển khai trong mạng lưới hệ thống. Thường có một đội độc lập chịu trách nhiệmkiểm thử mạng lưới hệ thống, đội kiểm thử mạng lưới hệ thống thao tác từ người sử dụng và tài liệu yêucầu mạng lưới hệ thống để lập kế hoạch kiểm thử mạng lưới hệ thống. Hầu hết những luận bàn về kiểm thử khởi đầu với kiểm thử thành phần và sau đóchuyển đến kiểm thử mạng lưới hệ thống. Tôi đã đảo ngược thử tự những luận bàn trong chươngnày do tại rất nhiều quy trình tăng trưởng phần mềm gồm có việc tích hợp những thànhphần sử dụng lại và được lắp vào phần mềm để tạo nên những nhu yếu đơn cử. Tất cả cáckiểm thử trong trường hợp này là kiểm thử mạng lưới hệ thống, và không có sự tách rời trongquá trình kiểm thử thành phần. 3.2. Kiểm thử hệ thốngHệ thống gồm hai hoặc nhiều thành phần tích hợp nhằm mục đích thực thi những tính năng hoặc đặctính của mạng lưới hệ thống. Sau khi tích hợp những thành phần tạo nên mạng lưới hệ thống, quy trình kiểm thử hệthống được thực thi. Trong quy trình tăng trưởng lặp đi lặp lại, kiểm thử mạng lưới hệ thống liên quanvới kiểm thử một lượng việc làm ngày càng tăng để phân phối cho người mua ; trong quátrình thác nước, kiểm thử mạng lưới hệ thống tương quan với kiểm thử hàng loạt mạng lưới hệ thống. Với hầu hết những mạng lưới hệ thống phức tạp, kiểm thử mạng lưới hệ thống gồm hai quy trình tiến độ riêng không liên quan gì đến nhau : 1. Kiểm thử tích hợp : đội kiểm thử nhận mã nguồn của mạng lưới hệ thống. Khi một vấn đềđược phát hiện, đội tích hợp thử tìm nguồn gốc của yếu tố và phân biệt thành phầncần phải gỡ lỗi. Kiểm thử tích hợp hầu hết tương quan với việc tìm những khiếm khuyếtcủa mạng lưới hệ thống. 2. Kiểm thử phát hành : Một phiên bản của mạng lưới hệ thống hoàn toàn có thể được phát hành tới ngườidùng được kiểm thử. Đội kiểm thử tập trung chuyên sâu vào việc hợp lệ những nhu yếu của hệthống và đảm bảo tính an toàn và đáng tin cậy của mạng lưới hệ thống. Kiểm thử phát hành thường là kiểm thử “ hộp đen ”, đội kiểm thử tập trung chuyên sâu vào diễn đạt những đặc tính mạng lưới hệ thống hoàn toàn có thể làm đượchoặc không làm được. Các yếu tố được báo cáo giải trình cho đội tăng trưởng để gỡ lỗi chươngtrình. Khách hàng được bao hàm trong kiểm thử phát hành, thường được gọi làkiểm thử đồng ý. Nếu mạng lưới hệ thống phát hành đủ tốt, người mua hoàn toàn có thể chấp nhậnnó để sử dụng. Về cơ bản, bạn hoàn toàn có thể nghĩ kiểm thử tích hợp như là kiểm thử mạng lưới hệ thống chưa đầy đủbao gồm một nhóm những thành phần. Kiểm thử phát hành tương quan dến kiểm thử hệthống phát hành có dự tính phân phối tới người mua. Tất nhiên, có sự gối chồng lên24nhau, đặc biệt quan trọng khi tăng trưởng mạng lưới hệ thống và mạng lưới hệ thống đuợc phát hành khi chưa triển khai xong. Thông thường, sự ưu tiên số 1 trong kiểm thử tích hợp là phát hiện ra khiếmkhuyết trong mạng lưới hệ thống và sự ưu tiên số 1 trong kiểm thử mạng lưới hệ thống là làm hợp lệ cácyêu cầu của mạng lưới hệ thống. Tuy nhiên trong thực tiễn, có vài kiểm thử hợp lệ và vài kiểm thửkhiếm khuyết trong những quy trình. 3.3. Kiểm thử tích hợpQuá trình kiểm thử tích hợp gồm có việc thiết kế xây dựng mạng lưới hệ thống từ những thành phần vàkiểm thử mạng lưới hệ thống tổng hợp với những yếu tố phát sinh từ sự tương tác giữa những thànhphần. Các thành phần được tích hợp hoàn toàn có thể trùng với chính nó, những thành phần có thểdùng lại được hoàn toàn có thể thêm vào những mạng lưới hệ thống riêng không liên quan gì đến nhau hoặc thành phần mới được pháttriển. Với rất nhiều mạng lưới hệ thống lớn, có tổng thể 3 loại thành phần được sử dụng. Kiểm thửtích hợp kiểm tra trên trong thực tiễn những thành phần thao tác với nhau, được gọi là chính xácvà truyền tài liệu đúng vào lúc thời hạn đúng trải qua giao diện của chúng. Hệ thống tích hợp gồm có một nhóm những thành phần thực thi vài công dụng của hệthống và được tích hợp với nhau bằng cách gộp những mã để chúng thao tác cùng vớinhau. Thỉnh thoảng, tiên phong hàng loạt khung của mạng lưới hệ thống được tăng trưởng, sau đó cácthành phần được gộp lại để tạo nên mạng lưới hệ thống. Phương pháp này được gọi là tích hợp từtrên xuống ( top-down ). Một cách lựa chọn khác là tiên phong bạn tích hợp những thành phầncơ sở phân phối những dịch vụ chung, như mạng, truy vấn cơ sở tài liệu, sau đó những thànhphần công dụng được thêm vào. Phương pháp này được gọi là tích hợp từ dưới lên ( bottom-up ). Trong trong thực tiễn, với rất nhiều mạng lưới hệ thống, kế hoạch tích hợp là sự pha trộncác chiêu thức trên. Trong cả hai chiêu thức top-down và bottom-up, bạn thườngphải thêm những mã để mô phỏng những thành phần khác và được cho phép mạng lưới hệ thống thực thi. Một yếu tố đa phần phát sinh trong lúc kiểm thử tích hợp là những lỗi cục bộ. Có nhiềusự tương tác phức tạp giữa những thành phần của mạng lưới hệ thống, và khi một đầu ra bất thườngđược phát hiện, bạn hoàn toàn có thể khó nhận ra nơi mà lỗi Open. Để việc tìm lỗi cục bộđược thuận tiện, bạn nên liên tục tích hợp những thành phần của mạng lưới hệ thống và kiểm thửchúng. Ban đầu, bạn nên tích hợp một mạng lưới hệ thống thông số kỹ thuật tối thiểu và kiểm thử hệ thốngnày. Sau đó bạn thêm dần những thành phần vào mạng lưới hệ thống đó và kiểm thử sau mỗi bướcthêm vào. 25

Source: https://bacxiunong.com
Category: Blog

Bacxiunong TOP Hay Nhất Mọi Thời Đại

KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM – Tài liệu text

KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Trả lời Hủy

KIỂM THỬ VÀ ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM

Related Posts

Trả lời Hủy