Báo cáo MÔN HỌC Nhập môn công nghệ phần mềm

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
Khoa Cơng nghệ thơng tin

Báo cáo
MƠN HỌC: Nhập mơn cơng nghệ phần mềm
NHĨM MƠN HỌC: 11
Giảng viên: Đặng Ngọc Hùng
Nhóm sinh viên thực hiện: nhóm 23
Nguyễn Minh Tuân

B19DCCN604

Đỗ Như Đức

B19DCCN189

Nguyễn Tiến Chức

B19DCCN106

Hà Nội năm 2022


Chương 15: Luồng công việc thực thi
1. Khái niệm và mục tiêu nghiên cứu
-

-

Luồng công việc thực thi là quá trình chuyển đổi từ quá trình thiết kế chi tiết
thành mã nguồn ngơn ngữ lập trình. Trên thực tế đối với dự án phần mềm

phức tạp và có quy mơ lớn, việc thực hiện cả luồng công việc thực thi với
một cá nhân là điều rất khó và địi hỏi sự hợp tác của nhiều lập trình viên với
nhau. Sản phẩm khi đó sẽ được thực thi bởi một nhóm, làm việc đồng thời
trên các thành phần khác nhau nhỏ hơn của sản phẩm.
Mục tiêu
 Tìm hiểu luồng cơng việc thực thi trong kỹ thuật lập trình.
 Tìm hiểu các kĩ thuật kiểm thử hộp đen (black-box), kiểm thử hộp thuỷ
tinh (white-box) và kiểm thử phi thực thi (non-execution-based).
 Tìm hiểu các loại tích hợp (integration testing), kiểm thử sản phẩm
(product testing) và kiểm thử chấp nhận (acceptance testing).
 Đánh giá các tiêu chuẩn và các giải pháp tốt trong kỹ thuật lập trình.

2. Lựa chọn ngơn ngữ lập trình
-

-

Trong hầu hết trường hợp, việc xảy ra vấn đề phải lựa chọn ngơn ngữ lập
trình thường khơng phát sinh dưới các trường hợp sau đây.
 Khách hàng (client) yêu cầu sản phẩm phải được thực thi dưới một ngôn
ngữ lập trình cố định
 Khi sản phẩm phải được thực thi trên một mơi trường hạn chế nào đó mà
những ngơn ngữ lập trình khác khơng có tính khả dụng.
Nếu giả sử ta đặt ra vấn đề ngơn ngữ lập trình nào phù hợp nhất để thực thi
sản phẩm: Công ty COBOL có hơn 200 nhân viên đã được đào tạo và sử
dụng thành thạo ngơn ngữ lập trình COBOL được nhiều năm. Một ngơn ngữ
lập trình mới là Java mạnh mẽ hơn nhiều xuất hiện và câu hỏi được đặt ra là
ngôn ngữ nào sẽ phù hợp để thực thi các sản phẩm của công ty COBOL. Để
trả lời vấn đề này chúng ta đi xem xét các khía cạnh:
 Vấn đề bảo trì: việc thực thi các sản phẩm mới bằng Java vẫn phải đảm

bảo việc bảo trì những sản phẩm cũ viết bằng COBOL Việc quản lý hai
phân lớp lập trình viên khác nhau là khơng hề dễ dàng bởi vấn đề bất
đồng có thể xảy ra khi lập trình viên Java thường được trả lương cao hơn
do nhân lực lúc đầu khan hiếm.
 Vấn đề chi phí: Quá trình tuyển dụng và đào tạo lập trình viên bằng ngơn
ngữ mới sẽ tốn rất nhiều kinh phí và thời gian của công ty. Mặt khác
công ty sẽ phải tốn thêm một khoản để đầu tư các thiết bị phần cứng,
phần mềm phục vụ việc lập trình bằng ngơn ngữ mới.




-

Q trình chuyển đổi lựa chọn ngơn ngữ lập trình mới có thể gây ra nhiều
hậu quả về tài chính cũng như nhân lực cho doanh nghiệp.

Khi sản phẩm khó hoặc không thể được thực thi bằng ngôn ngữ lập trình sẵn
có: vấn đề lựa chọn ngơn ngữ lập trình khác phù hợp hoặc mạnh mẽ hơn là
điều cần thiết để phù hợp với yêu cầu sản phẩm của khách hàng. Việc thực
hiện lựa chọn này ví dụ có thể đánh giá theo các cách sau:
 Đánh giá theo chi phí: Doanh nghiệp phải tính tốn chi phí cần phải đầu
tư để thực hiện dự án theo từng loại ngôn ngữ khả dụng. Ngơn ngữ lập
trình phù hợp nhất sẽ cho lợi nhuận cao và chi phí thực hiện nhỏ nhất.
 Đánh giá theo rủi ro: Xét các rủi ro có thể gặp phải và phương hướng giải
quyết. Ngơn ngữ lập trình phù hợp nhất là ngơn ngữ cho rủi ro thấp nhất.

3. Ngơn ngữ lập trình thế hệ thứ 4
-

-

-

-

Thế hệ thứ nhất: Ở thời kì sơ khai của lập trình phần mềm, chưa hề có khái
niệm trình biên dịch hay thông dịch, phần mềm được viết bằng mã nhị phân,
hoặc bảng mạch và switch.
Thế hệ thứ 2: hợp ngữ ra đời khiến và hoạt động bằng cách dịch hợp ngữ
sang mã máy. Việc lập trình và bảo trì trở nên dễ dàng hơn tuy nhiên độ dài
mã chương trình vẫn tương tự mã máy.
Thế hệ thứ 3: ý tưởng của ngơn ngữ lập trình thế hệ thứ 3 là các loại ngôn
ngữ bậc cao như C, C++, Pascal hoặc Java khiến cho việc lập trình trở nên
dễ dàng hơn khi mỗi dịng mã có thể biên dịch và thực thi thay cho 5-10
dòng mã máy. Tuy nhiên việc bảo trì các phần mềm viết bằng hợp ngữ thời
điểm này lại tốn ít chi phí hơn.
Thế hệ thứ 4: ý tưởng của ngơn ngữ lập trình thứ 4  có từ những cuối năm
1970. Mục tiêu của việc thiết kế ngơn ngữ thế hệ thứ 4 (4GL) này là mỗi
dịng mã sẽ tương đương với 30-50 dịng mã máy. Vì thế giúp rút ngắn quá
trình phát triển sản phẩm và khiến việc bảo trì dễ dàng hơn.

1. Các quy chuẩn phổ biến khi lập trình
1.1.Sử dụng tên biến thích hợp và có nghĩa 
-

-

Việc đặt tên biến thích hợp và có nghĩa là vơ cùng quan trọng với việc bảo
trì phần mềm do thành phần mã được viết ra bởi một lập trình viên sẽ có thể

bảo trì bởi nhiều hơn 1 người, việc bảo trì sẽ dàng và tiết kiệm chi phí hơn
nếu các tên biến được đặt theo đúng quy chuẩn ngay từ khi thực thi.
Các quy chuẩn đặt tên biến:






Đặt tên biến thích hợp: chọn duy nhất một tên biến có nghĩa hay vì nhiều
tên biến đều cùng chỉ một đối tượng. Ví dụ khơng nên dùng cả tên biến là
average và medium trong cùng một chương trình bởi chúng có nghĩa
gần tương đương.
Đồng bộ thứ tự cách đặt tên biến: nếu đã chọn một thứ tự cho các thành
phần trong tên biến, thì các tên biến tương tự cũng phải tn theo thứ tự
đó. Ví dụ: “frequencyMax” thì không nên dùng cách đặt tên
“minFrequency” cho giá trị min. Thay vì đó hãy đồng bộ thành
“frequencyMin”.

1.2.Chú thích khi viết mã
-

-

Tại sao cần chú thích mã: 
 Mục tiêu quan trọng của việc chú thích là khiến đoạn mã có thể dễ dàng
đọc và hiểu bởi những lập trình viên khác điều hành hoặc thực hiện dự án
cùng. Việc chú thích mã cũng sẽ giúp cho việc bảo trì và đảm bảo chất
lượng phần mềm tốt và dễ dàng hơn.
 Mã tự chú thích: là cách viết mã có tính mơ tả cao và có thể hiểu một

cách dễ dàng mà khơng cần chú thích. Tuy nhiên lập trình viên có thể
viết cách này khá hiếm.
Các vấn đề gặp phải khi khơng chú thích mã:
 Với các lập trình viên thiếu kinh nghiệm việc viết mã không đảm bảo
chất lượng là hồn tồn có thể xảy ra, điều này khiến việc thực thi và bảo
trì trở nên khó khăn hơn.
 Với đoạn mã khơng có chú thích nếu giả dụ có thay đổi nhân sự thì nhân
sự mới sẽ gặp khó khăn khi làm việc với đoạn mã có sẵn. 

1.3.Sử dụng tham số
-

Tại sao nên sử dụng tham số để gán giá trị hằng số:
 Sử dụng tham số khiến hằng số trở nên có ý nghĩa thay vì những con số
khơng rõ ràng.
 Tránh việc vơ tình thay đổi giá trị biến khiến sinh ra lỗi trong phần mềm
hoặc cho kết quả khơng chính xác.
 Việc thay đổi giá trị hằng số sẽ dễ dàng hơn vì dùng tham số tương quan
thay vì cố định.

1.4.Sắp xếp bố cục mã nguồn hợp lý


-

Với sự ra đời của các IDE hiện đại có chức năng định dạng được tích hợp
sẵn thì việc sắp xếp bố cục mã nguồn càng dễ dàng hơn. Tuy nhiên ta vẫn
nên xem xét các tiêu chí để sắp xếp:





Thụt lùi đầu dòng và sử dụng ngoặc
Nên viết mỗi câu lệnh trên một dòng
Sử dụng dòng trống để phân cách các đoạn mã

1.5.Câu lệnh điều kiện lồng nhau
-

Ta đánh giá cách sử dụng các câu lệnh điều kiện if lồng nhau qua các trường
hợp sau đây:
 TH1 (Figure 15.3): bố cục mã trong sơ đồ 15.3 sắp xếp rất rối và thiếu
hợp
lý.



TH2 (Figure 15.4): Cấu trúc bố cục mã dễ đọc hơn tuy việc lồng nhiều
câu điều kiện if else khiến việc kiểm tra tính đúng đắn của đoạn mã trở
nên khó khăn



TH3 (Figure 15.5): Sử dụng phương pháp đơn giản hóa điều kiện if-if
phức tạp bằng tốn tử && 




Sử dụng câu lệnh lặp lồng nhau sao cho bố cục hợp lí và có thể đơn giản

hố bằng các tốn tử nếu có thể, khơng nên dùng q 3 câu điều kiện if
lồng nhau.

5. Vấn đề quy chuẩn lập trình
- Quy chuẩn lập trình có thể vừa có lợi vừa gây khó khăn. Theo định nghĩa từ
trước với các module thực hiện nhiều và đa dạng các hoạt động không liên
quan đến nhau, thường đặt ra những luật như “mỗi module phải được viết
trong khoảng 35-50 dòng câu lệnh thực thi”. Hay nói một cách khác rõ ràng
hơn  là “lập trình viên phải báo với quản lý nếu muốn xây dựng một module
ít hơn 35 hoặc nhiều hơn 50 dòng lệnh thực thi”. Những quy chuẩn áp đặt
như vậy thường bị bỏ qua.
- Khác với với những quy chuẩn chung và phổ biến như với câu lệnh điều
kiện if không nên được đặt lồng nhau quá 3 lần. Lập trình viên thường
khơng tn thủ theo những quy chuẩn lập trình mà họ khơng hiểu tại sao lại
được áp dụng. Hơn thế nữa, việc áp đặt các quy chuẩn lập trình có thể gây ra
sự mâu thuẫn nội bộ giữa quản lý và lập trình viên.
- Quy chuẩn lập trình có thể được đặt ra bởi đơn vị quản lý chất lượng phần
mềm. Việc sử dụng các quy chuẩn lập trình khiến giai đoạn bảo trì dễ dàng
hơn. Tuy nhiên việc áp dụng nó cũng khiến cơng đoạn lập trình trở nên khó
khăn hơn với những quy chuẩn quá ngặt nghèo và phức tạp sẽ khiến hiệu
suất và tiến độ làm việc của dự án bị chậm lại.
- Thay vì đó nếu có thể áp dụng quy chuẩn lập trình vào hệ thống kiểm tra tự
động mà máy tính có thể kiểm tra như: kiểm tra lệnh if, số dòng, hay mã
lệnh sử dụng, … sẽ nâng cao chất lượng phần mềm đáng kể.

6. Tái sử dụng các đoạn mã
-

Việc tái sử dụng (reuse) là tương đối quan trọng trong ngành lập trình phần
mềm. Thời gian và chi phí có thể được tiết kiệm được đáng kể nếu có thể áp

dụng việc tái sử dụng lên các tiêu chí dự án như: yêu cầu chức, kế hoạch,
thiết kế, và các đoạn mã.


-

Đặc biệt tái sử dụng các đoạn mã trong quá trình thực thi là vơ cùng cần
thiết và quan trọng.

1. Phương pháp tích hợp
1.1.Khái niệm tích hợp
-

-

Tích hợp là quá trình ghép các thành phần mã lập trình lại thành một chương
trình hồn chỉnh.
Trong q trình tích hợp sẽ có khả năng phát sinh nhiều vấn đề như lỗi và
xung đột, địi hỏi phải có những biện pháp tích hợp hiệu quả.
Khái niệm:
  stub: là một đơn vị chương trình hoặc thành phần giả lập (thay thế cho
chương trình hoặc thành phần chưa hoàn thành) dùng để kiểm thử.
 driver: là một đoạn mã phục vụ mục đích kiểm thử gọi một thành phần
mã một hoặc nhiều lần, nếu có thể kiểm tra kết quả đầu ra.
Xét sơ đồ tích hợp sau đây: 








Nếu muốn kiểm thử thành phần mã a ta cần phải gộp và kiểm thử cả 3
thành phần mã b, c, d như một stub. 
Nếu muốn kiểm thử thành phần mã h ta cần có một driver gọi nó.
Tương tự nếu muốn kiểm thử thành phần mã d ta cần một driver và 2
stubs
Điều này khiến quá trình thực thi trở nên khó khăn khi q trình thực
hiện sẽ tốn rất nhiều công sức thiết lập stubs và drivers. Chưa kể, nếu q
trình thực thi hồn thành trước khi q trình tích hợp, việc phát hiện và
định vị lỗi gần như không thể thực hiện với các dự án lớn.
Địi hỏi cần phải có sự kết hợp giữa kiểm thử đơn vị và tích hợp.

1.2.Tích hợp Top-Down
-

Trong tích hợp top-down, nếu thành phần phía bên trên giao tiếp và gọi
thành phần bên dưới thì thành phần bên trên phải được thực thi và tích hợp
trước thành phần bên dưới.


-

-

Ưu điểm của tích hợp top-down:
 Hỗ trợ cơ lập và tìm lỗi: do các thành thành phần sẽ được thực thi và tích
hợp theo thứ tự từ trên xuống, khi thêm một thành phần hoặc liên kết một
thành phần khác vào bộ khung sẵn có, nếu có lỗi xảy ra ta có thể xác định

ngay lỗi có thể xảy ra ở thành phần liên kết với nó hoặc chính nó
 Có thể phát hiện lỗ hổng thiết kế sớm hơn: thứ tự sắp xếp thành thành
phần để kiểm thử và tích hợp sẽ chắc chắn rằng các thành phần logic sẽ
ln ln hoạt động ổn định.
Nhược điểm của tích hợp top-down:
 Có khả năng các thành phần được tái sử dụng sẽ không được kiểm thử
tương đối như nhau nếu được giả sử là thành phần không sinh lỗi và sẽ bị
bỏ qua. Nhưng trên thực tế có thể xảy ra các trường hợp phát sinh các lỗi
không ngờ đến.
 Dễ gặp rủi ro khi các thành thành phần điều hành tái sử dụng mà không
được kiểm thử kỹ lưỡng. Lý do là các thành thành phần điều hành thường
ở tầng dưới của kiến trúc tích hợp top-down và số lần được kiểm thử sẽ ít
hơn so với tầng trên.

1.3.Tích hợp Bottom-up
-

-

Trong tích hợp bottom-up, nếu thành phần bên trên giao tiếp với  và gọi
thành phần bên dưới thì thành phần bên dưới sẽ được thực thi và tích hợp
trước thành phần bên trên.
Tích hợp bottom-up:
 Ưu điểm: những thành thành phần điều hành (operational artifacts) sẽ
được kiểm thử một cách tồn diện qua các driver kiểm thử. Vì thế giải
bài tốn của tích hợp top-down bởi cơ chế bắt lỗi dễ dàng.
 Nhược điểm: các thành phần logic (logic artifacts) sẽ là các thành phần
được tích hợp cuối cùng. Do đó nếu có phát hiện lỗi thiết kế nghiêm
trọng nào đó trong giai đoạn cuối của dự án sẽ khiến quy trình làm việc
bị thay đổi hoặc cần trả một chi phí lớn cho việc tái thiết kế lại một phần

lớn của sản phẩm.

1.4.Tích hợp Sandwich


-

-

Xét lược đồ 15.7 trên hình, ta thấy 6 thành phần logic (tơ màu xám) được
tích hợp theo kiểu top-down, cịn 7 thành phần điều hành (tơ màu hồng)
được tích hợp theo kiểu bottom-up. 
Việc áp dụng kiến trúc kiểu này bởi là khi nếu dùng duy nhất kiến trúc topdown hoặc bottom-up đều sẽ không phù hợp với sản phẩm, giải pháp đưa ra
là phải phân vùng chúng. Hai phần được kiểm thử một cách riêng biệt theo
kiến trúc tích hợp của chúng, và khi ghép lại các giao thức giữa 2 nhóm sẽ
được kiểm thử từng phần đầy đủ.

1.5.Quá trình tích hợp của hướng đối tượng
-

Sản phẩm thiết kế theo hướng đối tượng có thể được tích hợp theo cả bằng
cách top-down hoặc bottom-up.
 Tích hợp theo top-down: các stub sẽ được sử dụng cho mỗi phương pháp
giống với các module.
 Tích hợp theo bottom-up: các đối tượng độc lập sẽ được thực thi và tích
hợp đầu tiên, sau đó đến các đối tượng mà chúng giao tiếp gọi các đối
tượng khác, cứ tích hợp như vậy cho đến khi sản phẩm hồn chỉnh.
 Tích hợp theo sandwich: tích hợp sandwich cũng có thể sử dụng tuỳ theo
từng thuộc tính từng thành phần, hay tuỳ theo thuộc tính của ngôn ngữ

lập trình. Có nhiều biến thể của tích hợp sandwich có thể được sử dụng
trong chương trình hướng đối tượng.
1.6.Quản lý tích hợp
-

-

Khi q trình tích hợp giữa các thành thành phần với nhau của mỗi lập trình
viên khác nhau có khả năng xảy ra sự xung đột hoặc khơng tương thích. Giả
sử lập trình viên thực thi đối tượng 01 sử dụng tài liệu thiết kế yêu cầu đối
tượng 01 truyền đến đối tượng 02 4 tham số, tuy nhiên theo tài liệu thiết kế
của lập trình viên thực thi đối tượng 02 chỉ có 3 tham số được truyền đến đối
tượng 02. Sự xung đột này đến từ việc chỉnh sửa lại tài liệu thiết kế mà thiếu
đi sự đồng bộ và thông báo cho các bên liên quan, khiến cho việc tích hợp
gặp vấn đề và tốn thêm thời gian và chi phí để giải quyết.
Để giải quyết vấn đề khơng tương thích như trên, cả q trình tích hợp phải
được vận hành bởi nhóm SQA (quản lý chất lượng phần mềm). Nhiệm vụ
của nhóm SQA là đảm bảo q trình tích hợp phải diễn ra thuận lợi và hoàn
thành đồng thời quyết định xem thành thành phần nào được tích hợp theo
kiểu nào và phụ trách phân chia cơng việc tích hợp cho mỗi lập trình viên. 
Nhóm SQA phải lên kế hoạch kiểm thử tích hợp trong kế hoạch quản
lý dự án phần mềm, đồng thời có trách nghiệm thực thi kế hoạch đó. Kết
thúc giai đoạn tích hợp, tất cả những thành thành phần đã được kiểm thử
được tích hợp thành một sản phẩm hồn chỉnh

8. Luồng công việc thực thi
-

-

Nhiệm vụ của luồng công việc thực thi là triển khai đối tượng sản phẩm
phần mềm bằng ngơn ngữ lập trình được chọn. Chính xác hơn là, một sản
phẩm phần mềm lớn sẽ được phân mảnh ra thành các hệ thống nhỏ hơn, sau
đó được thực thi song song bởi các nhóm. Các hệ thống nhỏ hơn bao gồm
những thành phần hoặc các thành phần mã.
Sau khi các thành phần mã đã được viết, lập trình viên sẽ kiểm thử thành
phần đó, khái niệm đó gọi là kiểm thử đơn vị (unit testing). Sau khi đã kiểm
thử xong, lập trình viên chuyển thành phần mã xuống đơn vị quản lý chất
lượng phần mềm để kiểm thử sâu hơn. Giai đoạn kiểm thử sau đó được thực
hiện trong luồng công việc kiểm thử.

9. Luồng công việc kiểm thử trong thực thi
-

 Trong luồng công việc thực thi, nhiều loại kiểm thử sẽ được thực hiện:
 Kiểm thử đơn vị
 Tích hợp
 Kiểm thử sản phẩm


Kiểm thử chấp nhận
Các thành phần mã sẽ được kiểm thử bằng 2 loại kiểm thử:
 Kiểm thử không hợp cách (informal unit testing): thực hiện bởi lập trình
viên khi viết thành phần mã.
 Kiểm thử hợp cách (methodical unit testing): thực hiện bởi đơn vị quản
lý chất lượng phần mềm. Kiểm thử hợp cách có 2 loại: kiểm thử thực thi
và kiểm thử không thực thi.


-

10.


Lựa chọn Test Case

Việc lựa chọn test case rất quan trọng trong quá trình kiểm thử. Bởi vì sẽ có
vơ vàn khả năng xảy ra và việc test hết tất cả các khả năng là vơ cùng lãng
phí. Điều cần làm là cần xây dựng các test case một cách có hệ thống.

1. Kiểm thử dựa trên đặc điểm và kiểm thử đoạn mã
-

Dữ liệu cho việc kiểm thử có thể được xây dựng bằng 2 cách:
 Kiểm thử đặc điểm: với cách tiếp cận này, thành phần sẽ bị bỏ qua, phần
quan tâm duy nhất để tạo test case là tài liệu đặc tả. Còn được gọi là kiểm
thử hộp đen (black-box), kiểm thử hành vi (behavioral), kiểm thử hướng
dữ liệu (data-driven), kiểm thử hàm (functional), kiểm thử hướng vào ra
(input/output driven).
 Kiểm thử mã: chỉ kiểm thử thành phần và phần tài liệu đặc tả sẽ bị bỏ qua
khi lựa chọn test case. Còn được gọi là kiểm thử hộp thuỷ tinh, kiểm thử
hộp trắng, kiểm thử có cấu trúc, kiểm thử hướng logic.

2. Tính khả thi của kiểm thử đặc điểm
-

-

Ta xét: Các đặc tả cho dữ liệu một trạng thái của sản phẩm có các loại phiếu

giảm giá và các mẫu mã sản phẩm. Giả sử sản phẩm có 5 mẫu mã khác nhau
và có 7 loại phiếu giảm giá khác nhau cần được áp dụng. Kiểm thử tất cả các
tổ hợp giữa các mẫu mã sản phẩm và phiếu giảm giá ta được 35 test cases.
Sẽ là vô nghĩa nếu coi loại mẫu mã và phiếu giảm giá được tính tốn và xử
lý ở trong 2 thành phần riêng biệt và nên được kiểm thử riêng biệt. Trong
kiểm thử hộp đen, sản phẩm được coi như một hộp đen - có nghĩa là cấu trúc
bên trong của nó hồn tồn khơng được xét. 
Với số lượng sản phẩm và số các loại phiếu giảm giá càng nhiều thì số lượng
kết quả giá sản phẩm tính ra càng vơ cùng lớn. Tương tự với nếu xét nhiều
nhân tố hơn thì sẽ có vơ số test case và rất tốn thời gian để có thể kiểm thử
được hết số lượng test case đó.




Vì vậy kiểm thử đặc điểm đầy đủ là khơng khả thi trên thực tế bởi số
lượng test case khả thi là vơ cùng lớn. Vì vậy kiểm thử mã được đưa vào
xem xét.

3. Tính khả thi của kiểm thử mã
-

Hình thức phổ biến nhất của kiểm thử mã là kiểm thử tất cả các trường hợp
(các đường đi) trong đoạn mã. Để xem xét tính khả thi của kĩ thuật kiểm thử
này, xem xét một biểu đồ hoạt động sau:

-

Mặc dù biểu đồ hoạt động trơng có vẻ đơn giản, tuy nhiên xét kỹ hơn nó có
hơn 10^12 đường đi. Có 5 đường đi khả thi trong nhóm 6 hộp được tơ màu

xám và sau đó được lặp 18 lần, ta tính được tổng số đường đi khả thi trong
biểu đồ hoạt động như sau: 

-

=> Với một lần lặp đã có số đường đi rất lớn, nếu xét những thành
phần có độ phức tạp và quy mơ lớn hơn thì việc kiểm thử mã cũng
hồn tồn khơng khả thi giống như kiểm thử đặc điểm.
Kiểm thử đòi hỏi việc kiểm thử tất cả các đường đi khả thi. Tuy nhiên có
khả năng xảy ra khi kiểm thử tất cả các đường đi vẫn không thể phát hiện
được lỗi. Ta xét ví dụ sau:


-

-

Đoạn mã này có nhiệm vụ kiểm tra tính tương đương của 3 số dựa trên một
logic sai: nếu trung bình của 3 số bằng số đầu tiên thì 3 số đó bằng nhau.
Dựa trên 2 test case cho sẵn thì đoạn mã này sẽ được cho là chạy đúng. Tuy
nhiên nếu dùng một test case khác chưa được xét là x = 2 y = 1, z = 3 thì
đoạn mã sẽ có lỗ hổng và sai lệch.
Ví dụ trên cho ta thấy rằng xem xét tất cả các đường đi trong phần mềm là
khơng tin cậy, bởi vì phần mềm có thể tồn tại những đường đi gây sai lệch
chưa được xét. Tuy vậy, kiểm thử hướng đường đi là hồn tồn hợp lệ 
bởi vì nó vốn dĩ khơng loại trừ việc chọn dữ liệu kiểm thử có thể phát hiện
lỗi.
 Bởi vì sự đa dạng tổ hợp dữ liệu, cả kiểm thử mã đầy đủ và kiểm thử đặc
điểm đầy đủ đều khơng khả thi. Cần có một phương pháp để có thể phát
hiện lỗi nhiều nhất có thể, mặc dù có thể khơng đảm bảo việc phát hiện

tất cả các lỗi. Một phương pháp hợp lý đó là sử dụng kiểm thử hộp đen
sau đó tạo thêm các test case bằng phương pháp hộp thuỷ tinh.

11.


Kĩ thuật kiểm thử hộp đen

Kiểm thử hộp đen đầy đủ có thể u cầu hàng tỷ test case. Vì vậy phương
thức yêu cầu đặt ra là để tạo một tập hợp các test case nhỏ, tối ưu hoá khả
năng phát hiện lỗi trong khi giảm khả năng lãng phí test case khi phát hiện
lỗi giống nhau, mỗi test case cần độc lập về khả năng phát hiện lỗi.

1. Kiểm thử tương đương và phân tích giá trị giới hạn 
-

Giả sử một cơ sở dữ liệu chứa thông tin về các sản phẩm và có thể chứa các
bản ghi từ 1-16383. Khoảng từ 1-16383 được gọi là lớp tương đương bởi vì
nếu test case  một sản phẩm trong khoảng 1-16383 vẫn có thể hoạt động tốt,
thì test case những sản phẩm có khoảng xung quanh sẽ tương tự. Để chuẩn
xác hơn, ta sẽ chia số lượng bản ghi thành 3 lớp tương đương
 Nhỏ hơn 1 bản ghi
 Từ 1 đến 16383 bản ghi
 Lớn hơn 16383 bản ghi


-

Kiểm thử cơ sở dữ liệu sử dụng kĩ thuật lớp tương đương sẽ yêu cầu mỗi test
case từ mỗi lớp tương đương sẽ được chọn.

Để tối đa hoá khả năng tìm được lỗi nên sử dụng kĩ thuật phân tích giá trị
giới hạn. Trong khoảng từ (R1, R2) được liệt kê từ đầu ra hoặc đầu vào đặc
điểm, có 5 test cases nên được chọn, các giá trị nhỏ hơn R1, bằng R1, lớn
hơn R1 và nhỏ hơn R2, bằng R2, lớn hơn R2. Khi chỉ ra một đơn vị thuộc
một tập, thì 2 lớp tương đương nên được xét là lớp chứa đơn vị đó và lớp
khơng chứa đơn vị đó.
 Việc sử dụng lớp tương đương cùng với phân tích giá trị giới hạn nhằm
kiểm thử các đặc điểm đầu vào và đặc điểm đầu ra của một phương thức
cho việc sinh các tập dữ liệu test nhỏ với mục tiêu tìm ra nhiều nhiều lỗi
nhất có thể nếu các cách chọn test cases mạnh mẽ hơn không được áp
dụng.

2. Kiểm thử chức năng 
-

-

-

-

Một dạng kiểm thử khác của kiểm thử hộp đen là xây dựng dữ liệu test dựa
trên chức năng của đoạn mã. Trong kiểm thử chức năng, mỗi đơn vị của
chức năng hoặc hàm được triển khai ở trong thành phần sẽ được định danh.
Một ví dụ điển hình của quản lý nhà kho sẽ có những hàm như:
 get_next_database_record
 determine_whether_quantity_on_hand_is_below_the_reorder_point
Sau khi xác định được tất cả các hàm của thành phần, dữ liệu test sẽ được
xây dựng dựa trên các hàm khác nhau.  Từ đây, nếu các thành thành phần
bao gồm các hàm gọi các hàm con, kết nối bởi cấu trúc điều khiển của lập

trình cấu trúc, khi đó kiểm thử chức năng sẽ được thực hiện đệ quy.
Trên thực tế, các hàm cha không được xây dựng theo một cấu trúc từ các
hàm con. Thay vì đó, các hàm con thường được đan xen vào nhau theo một
cách nào đó. Để có thể tìm được các lỗi và lỗ hổng trong trường hợp này,
phân tích chức năng cần được thực hiện theo một chu trình khá phức tạp. 
Một nhân tố làm tăng tính phức tạp đó là các chức năng thường xun khơng
trùng hợp với các ranh giới thành phần. Vì thế sự phân biệt giữa kiểm thử
đơn vị và tích hợp trở nên một cách thiếu quan trọng hơn: một đoạn mã
không thể kiểm thử đồng thời nếu không kiểm thử một đoạn mã khác chứa
chức năng mà nó sử dụng. Vấn đề này cũng có thể xảy ra trong mơ hình
hướng đối tượng khi một phương thức của một đối tượng gọi một phương
thức của đối tượng khác.
 Các quan hệ ngẫu nhiên giữa các thành phần theo cách nhìn của kiểm thử
chức năng có thể tạo ra những hậu quả khơng chấp nhận được cho việc
quản lý. Ví dụ như việc quản lý cột mốc dự án hoặc deadline có thể trở


thành một thứ khó xác định được, trở thành chướng ngại cho việc xác
định trạng thái của sản phẩm theo kế hoạch quản lý dự án phần mềm.

12.
Case study Tổ chức MSG: Các test case kiểm thử
hộp đen
Test cases kiểm thử hộp đen cho case study Tổ chức MSG:
- Biểu đồ 15.13 và 15.14 minh hoạ các test cases kiểm thử hộp đen cho case
study tổ chức MSG. Đầu tiên xem xét các test cases nhận được từ các lớp
tương đương và phân tích giá trị giới hạn. Test case đầu tiên trong biểu đồ
15.13 kiểm tra xem sản phẩm có phát hiện lỗi nếu biến itemName (tên) của
một khoản đầu tư không bắt đầu bằng một chữ cái. 5 test cases tiếp theo kiểm
tra xem biến itemName có giá trị độ dài từ 1 – 25 kí tự hay khơng. Các test

cases tương tự cịn lại kiểm tra các mơ tả đặc điểm khác.
- Với kiểm thử hàm, có 10 hàm được liệt kê ở trong tài liệu đặc tả, như được
minh hoạ ở biểu đồ 15.14. Có tổng cộng 11 test cases liên quan đến việc sử
dụng các hàm này.
- Nên biết rằng các test cases ở đây có thể được phát triển ngay khi giai đoạn
phân tích hồn thành. Lý do mà nó được đề cập ở nội dung luồng thực thi là
nó có liên quan đến chủ đề lựa chọn test case. Cấu tạo chính của mọi kế hoạch
kiểm thử nên là một quy định rằng kiểm thử hộp đen nên được thực hiện ngay
khi quá trình phân tích đã được phê duyệt, nhằm thuận tiện cho nhóm SQA
trong luồng cơng việc thực thi.



13.


Kĩ thuật kiểm thử hộp thuỷ tinh

Trong kĩ thuật kiểm thử hộp thuỷ tinh, các test cases được lựa chọn dựa trên
việc xem xét đoạn mã hơn là các đặc điểm. Có nhiều hình thức kiểm thử hộp
thuỷ tinh, bao gồm nhánh (branch), câu lệnh (statement), bao quát đường
dẫn (path coverage).

1. Kiểm thử cấu trúc
-

Bao quát câu lệnh: dạng cơ bản nhất của kiểm thử đơn vị hộp thuỷ tinh là
bao quát câu lệnh (statement coverage): chạy hàng loạt các test cases trong
quá trình mỗi câu lệnh được thực thi ít nhất một lần. Hay có thể nói

-

-

-

Statement Coverage đảm bảo rằng tất cả các dòng lệnh trong mã nguồn đã
được kiểm tra ít nhất một lần. Nhược điểm của việc kiểm thử này là không
đảm bảo việc tất cả các kết quả của các nhánh sẽ được kiểm tra đúng cách.
Bao quát nhánh: một phiên bản cải tiến của statement coverage đó là bao
quát nhánh (branch coverage), thực hiện bằng cách chạy hàng loạt các các
test cases để đảm bảo rằng tất cả các nhánh đều được kiểm tra ít nhất một
lần.
Bao quát đường dẫn: phiên bản mạnh mẽ nhất của kiểm thử cấu trúc đó là
bao quát đường dẫn (path coverage), đó là kiểm tra mọi đường dẫn khả thi.
Như ta đã xét, với phần mềm ở trong vịng lặp sẽ có thể có số lượng đường
dẫn rất lớn. Vì vậy cần tìm ra một cách tối ưu khi giảm số lượng đường dẫn
cần xét trong khi tối đa hoá số lượng lỗi và lỗ hổng có thể phát hiện.  
 Một tiêu chí cho việc lựa chọn đường dẫn đó là chuỗi mã tuyến tính
(linear mã sequences). Để thực hiện, đầu tiên xác định một tập L từ đó
mà quản lí bước nhảy khi phần mềm chạy. Tập L sẽ bao gồm các điểm ra
và vào và các câu lệnh rẽ nhánh như lệnh if/go to. Các chuỗi mã tuyến
tính là các đường dẫn bắt đầu từ một phần tử của tập L và kết thúc cũng
tại một phần tử của tập L. Kĩ thuật này thực hiện thành cơng khi nó có
thể phát hiện nhiều lỗi và lỗ hổng trong khi không phải kiểm tra tất cả các
đường dẫn khả thi.
 Một cách khác để giảm số lượng đường dẫn phải kiểm tra đó là “tất cả
định nghĩa sử dụng bao quát đường dẫn  (all-definition-use-path
coverage)”. Tất cả các đường dẫn giữa định nghĩa của một biến và cách

sử dụng của định nghĩa đó đều được xác định bằng cơng cụ tự động. Sau
đó một test case sẽ được xây dựng cho mỗi đường dẫn đó.
Nhược điểm: khi sử dụng kiểm thử cấu trúc, người thực hiện kiểm thử có thể
bỏ sót test case thực hiện việc kiểm tra một câu lệnh, nhánh hay đường dẫn
nào đó. Nguyên nhân có thể là do một đường dẫn không khả thi (dead mã) ở
trong phần mảnh mã, có nghĩa là đường dẫn đó khơng thể được thực thi với
bất kì dữ liệu đầu vào nào.

2. Chỉ số độ phức tạp (complexity metrics)
-

-

Chỉ số đo độ phức tạp được tạo ra nhằm so sánh xem thành phần nào sẽ có
rủi ro sinh nhiều lỗi và lỗ hổng hơn. Nếu một thành phần có chỉ số đo độ
phức tạp vơ cùng cao thì nên xem xét việc thiết kế và thực thi lại từ đầu bởi
chi phí sẽ ít hơn so với việc tìm và gỡ lỗi. 
Các cách đo chỉ số độ phức tạp:
 Dựa trên số dòng mã: với các thành phần càng nhiều dịng thì sẽ có rủi ro
có càng nhiều lỗi.




13.
-

-

-

Kỹ thuật rà soát lướt qua và kiểm tra kỹ lưỡng

Ưu điểm của kỹ thuật rà soát mã:
 Việc sử dụng 2 kỹ thuật phát hiện lỗ hổng mà không cần thực thi này
khiến cho việc phát hiện lỗi trở nên nhanh chóng, hồn tồn và sớm hơn.
 Tăng hiệu suất tiến trình làm việc khi q trình tích hợp xảy ra ít lỗi hơn.
 Có thể giảm thiểu lên đến 95% chi phí bảo trì [Crossman, 1982]
Một lý do khác cho việc sử dụng rà soát mã là khi thực hiện kiểm thử thực
thi dựa trên test cases có chi phí cao.
 Kiểm thử thực thi sẽ rất tốn thời gian
 Rà soát mã sẽ phát hiện lỗi và giúp vá lỗi sớm hơn trong chu trình. so với
kiểm thử thực thi.

14.
-

Độ phức tạp chu kỳ: được xác định dựa trên số lượng nhánh trong thành
phần. Độ phức tạp chu kỳ cũng có thể sử dụng như số đo cho số lượng
test cases cần cho kiểm thử cấu trúc bao quát nhánh của thành phần.

So sánh các kĩ thuật kiểm thử đơn vị

Có rất nhiều nghiên cứu về các chiến lược kiểm thử đơn vị. Nghiên cứu
Myes[1978] so sánh ba loại kiểm thử hộp đen, kiểm thử kết hợp hộp đen và
hộp thuỷ tinh, rà soát mã với ba người. Nghiên cứu thực hiện kiểm thử một
sản phẩm phần mềm trong thử nghiệm được thực hiện bởi 59 lập trình viên
đã có kinh nghiệm. Cả ba kỹ thuật đều hiệu quả như nhau trong việc phát
hiện lỗi, nhưng rà sốt mã  được cho là ít tốn kém chi phí hơn so với hai kĩ
thuật kiểm thử còn lại.

Một nghiên cứu lớn được thực thi bởi Basili và Selby[1987] được tham gia
bởi 2 nhóm gồm 32 lập trình viên chun nghiệp và 42 sinh viên giỏi. Thử
nghiệm này so sánh kiểm thử hộp đen, kiểm thử hộp thuỷ tinh và kiểm một
người. Mỗi nhóm sẽ kiểm thử 3 sản phẩm phần mềm, mỗi lần dùng một kĩ
thuật kiểm thử khác nhau, đảm bảo rằng khơng có ai thử nghiệm trên một
sản phẩm nhiều hơn một cách. Kết quả nhận được rằng nhóm lập trình viên
chun nghiệp phát hiện lỗi nhiều hơn bằng cách rà sốt mã so với 2 cách
cịn lại, và tiến độ phát hiện lỗi cũng nhanh hơn. Bên nhóm sinh viên được
chia làm 2 nhóm nhỏ hơn, ở một nhóm khơng thấy có sự khác biệt đáng kể
về hiệu quả của 3 cách, ở nhóm cịn lại thấy kiểm thử hộp đen và hiệu quả
như nhau nhưng đều vượt qua kiểm thử hộp thuỷ tinh. Tuy nhiên tiến độ
phát hiện lỗi đều như nhau cho mỗi cách. Tóm lại, rà sốt mã sẽ giúp việc
phát hiện lỗi giao diện tốt hơn 2 kĩ thuật còn lại, trong khi kiểm thử hộp đen
là tốt nhất khi tìm các lỗi và lỗ hổng điều khiển.




15.
-

-

-

-

Kĩ thuật kiểm thử Cleanroom

Kỹ thuật kiểm thử Cleanroom là tập hợp của nhiều kĩ thuật phát triển phần

mềm khác nhau, bao gồm một mơ hình chu trình tăng dần, các kĩ thuật chính
thức cho việc phân tích và thiết kế và các kĩ thuật kiểm thử đơn vị không
thực thi như rà soát lướt qua và kiểm tra kỹ lưỡng. Một tiêu chí quan trọng
của Cleanroom đó là thành phần sẽ khơng được biên dịch cho đến khi hồn
tất kiểm tra và đã thực hiện các kĩ thuật kiểm thử khơng thực thi.
Kĩ thuật kiểm thử Cleanroom cũng có thể áp dụng cho những dự án phần
mềm lớn và có những kết quả khá ấn tượng. Một thước đo liên quan đó là tỉ
lệ lỗi (testing fault rate) được tính bằng cách tính trung bình số lỗi có trên
một KLOC (1000 dòng mã). Thước đo này được sử dụng phổ biến cùng
Cleanroom thay vì các kĩ thuật phát triển phần mềm truyền thống khác.
So sánh kĩ thuật kiểm thử truyền thống và kỹ thuật Cleanroom:
 Kĩ thuật kiểm thử truyền thống: các lỗi phát hiện bởi lập trình viên trong
q trình phát triển mã sẽ khơng được ghi lại. Các lỗi chỉ được ghi lại khi
đoạn mã được gửi đến đơn vị quản lý chất lượng phần mềm SQA khi quá
trình test kỹ hơn được thực hiện
 Kỹ thuật Cleanroom: các lỗi được ghi lại ngay từ thời điểm biên dịch cho
đến thời điểm thực hiện các kĩ thuật kiểm thử thực thi.

16.
-

Thử nghiệm trên cho thấy rà soát cũng có khả năng phát hiện lỗi như
kiểm thử hộp đen và hộp thuỷ tinh mặc dù kiểm thử hộp đen và hộp thuỷ
tinh có tính hiệu quả hơn so với việc kiểm . Tuy nhiên, cũng có vài thử
nghiệm cho thấy việc kết hợp thêm kiểm  sẽ tìm được các loại lỗi đa dạng
hơn. Nói cách khác, các kĩ thuật này bổ sung lẫn nhau và cần được sử
dụng trong quá trình phát triển của mọi sản phẩm phần mềm.

 Vấn đề tiềm ẩn khi kiểm thử đối tượng

Phần mềm hướng đối tượng có cấu trúc và hành vi khác so với phần mềm
thực hiện bằng ngôn ngữ hướng thủ tục. Phần mềm hướng đối tượng không
phân rã chức năng trong các thủ tục riêng biệt, nó có các đối tượng và các
lớp, sự tương tác với nhau thông qua gửi thông báo và dùng chung các định
nghĩa thông qua sự thừa kế.
Sử dụng hướng đối tượng trong dự án được cho là có thể có những ưu điểm
cho việc giảm số lượng công việc kiểm thử:
 Tái sử dụng quá thừa kế là thế mạnh của lập trình hướng đối tượng: khi
một lớp đã được kiểm tra, đối số sẽ được tiếp tục, khiến việc kiểm tra lại
là không cần thiết


Các phương thức mới ở lớp con cần được kiểm tra, nhưng các phương
thức được kế thừa thì khơng cần
 Trên thực tế, những ưu điểm trên chỉ đúng một phần, kiểm thử đối tượng
có thể tồn tại những vấn đề mà chỉ hướng đối tượng mới có.
Xét các vấn đề với kiểm thử lớp và kiểm thử đối tượng
 Theo định nghĩa, một lớp (class) là một kiểu dữ liệu trừu tượng cho phép
việc kế thừa, và đối tượng được định nghĩa bởi lớp. Có nghĩa là một lớp
khơng thể cách nào có thể kiểm thử thực thi mà chỉ có thể được thực thi
thơng qua đối tượng của nó. Lớp chỉ có thể kiểm thử thơng qua các kĩ
thuật kiểm thử không thực thi.
  Một object được định nghĩa có thể có nhiều cho đến ít phương thức. Sẽ
có những phương thức thay đổi trạng thái dữ liệu state của object. Khi ta
muốn kiểm tra các phương thức đó thì cần ít nhất phải gửi thêm một câu
u cầu lấy dữ liệu để xem phương thức đó có hoạt động đúng hay
không. Vấn đề nảy sinh khi đối tượng không bao gồm các phương thức
hỗ trợ việc xác định giá trị state. Một cách xử lý đó là thêm một phương
thức chỉ phục vụ riêng cho việc xác định giá trị và chỉ khả dụng cho mục
đích kiểm thử

 Một phương thức được kế thừa có thể vẫn phải được kiểm tra lại ngay kể
cả khi nó đã được kiểm tra kĩ ở lớp cha. 
Để chứng minh vấn đề với phương thức được kế thừa ta một cây kế thừa
sau:


-

-


 
-

-

-

Trong ví dụ trên ta thấy 2 phương thức chính đó là printNode và phương
thức  displayNodeContents có sử dụng phương thức printRoutine. Lớp
BinaryTreeLớp kế thừa lớp cha (RootedTreeLớp) sẽ kế thừa phương thức 
printNode từ RootedTreeLớp.printRoutine và ghi đè phương thức
displayNodeContents.
Vấn đề nảy sinh khi lớp thứ ba BalancedBinaryTreeLớp kế thừa lớp
BinaryTreeLớp và ghi đè phương thức printRoutine. Tuy nhiên phương
thức displayNodeContents được kế thừa từ 
BinaryTreeLớp. displayNodeContents lại sử dụng phương thức
printRoutine
từ
RootedTreeLớp.printRoutine

thay
vì
BalancedBinaryTreeLớp.printRoutine.
 Vì thế cho dù đã kiểm thử kĩ càng phương thức từ BinaryTreeLớp, môi
trường của lớp BalancedBinaryTreeLớp vẫn phải kiểm thử lại từ đầu.
Công việc này lại càng phức tạp hơn vì theo lý thuyết có nhiều lý do tại
sao chúng cần được kiểm thử lại với nhiều test cases khác nhau.
Sử dụng hướng đối tượng giảm tải công việc kiểm thử: 
 Vấn đề chỉ có thể xảy ra thông qua sự tương tác giữa các phương thức 





17.
-

-

-

-

 Các

khía cạnh quản lý của kiểm thử đơn vị

Trong quá trình phát triển, việc quyết định xem một phần mảnh mã được
dành bao nhiêu thời gian, chi phí là vơ cùng quan trọng. Kỹ thuật phân tích
chi phí và lợi ích (cost-benefit analysis) trở thành một công cụ hữu ích trong

việc giải quyết bài toán kinh tế trong dự án phần mềm. Ví dụ như việc xem
xét chi phí kiểm sốt chất lượng có vượt q lợi ích của việc đảm bảo sản
phẩm có thoả mãn đặc điểm đề ra hay khơng, hay so sánh chi phí chạy thêm
nhiều test case để kiểm thử chuyên sâu với chi phí rủi ro nếu phần mềm sản
phẩm chưa được kiểm thử kỹ lưỡng.
Một phương pháp tiếp cận khác để quyết định có nên kiểm thử một phần
mảnh có nên tiếp tục hoặc đánh giá số lượng lỗi gọi là phân tích độ tin cậy.
Phương pháp phân tích độ tin cậy có thể được sử dụng để cung cấp thơng số
ước tính cịn bao nhiêu lỗi hoặc lồ hổng cịn tồn tại.
Có vơ số phương pháp để xác định thơng số ước tính của số lỗi hoặc lỗ hổng
còn tồn tại nhưng chúng đều có một ý tưởng chung, ta xét ví dụ dưới đây:
Giả sử một thành phần đã được kiểm thử trong vịng 1 tuần. 23 lỗi được tìm
thấy vào ngày thứ hai, thứ ba 7 lỗi, thứ tư 5 lỗi, thứ năm 2 lỗi, và khơng có
lỗi nào vào ngày thứ sáu. Bởi vì số lượng lỗi giảm đều đặn từ 23 lỗi một
ngày xuống cịn khơng lỗi nào, ta có thể xác định gần như mọi lỗi đã được
tìm thấy và có thể dừng việc kiểm thử.

18.
-

Có thể hồn tồn phát hiện vấn đề thơng qua việc kiểm thử với các test
cases khác nhau
Các lớp con cần được kiểm thử lại cùng với các phương thức có sự tương
tác với các phương thức khác. 

 Vấn

đề tái thực thi hay gỡ lỗi 

Khi nhóm quản lý chất lượng phần mềm phát hiện lỗi, thành phần mã bị lỗi

sẽ được chuyển giao cho lập trình viên đã viết nó để gỡ lỗi, q trình đó có
thể gọi là phát hiện lỗi và điều chỉnh đoạn mã. 
Trong một số trường hợp, thành phần mã bị lỗi nên được bỏ đi và thiết kế
cũng như thực thi lại từ đầu. Để hiểu tại sao điều này là cần thiết, ta xem xét
biểu đồ sau:


Biểu đồ thể hiện một khái niệm rằng khả năng còn tồn đọng những lỗi trong
một thành phần tỷ lệ thuận với số lỗi đã được tìm thấy. Để giải thích cho
điều này, ta giả sử có 2 thành phần mã a1 và a2 có độ dài như nhau và cả hai
đều đã được kiểm thử cùng một lượng thời gian như nhau. Cho rằng chỉ có 2
lỗi được tìm thấy ở thành phần a1, trong khi đó có 48 lỗi được tìm thấy ở
thành phần a2, vì vậy rất có khả năng thành phần a2 sẽ cịn tồn tại nhiều lỗi
hơn cả thành phần a1.
 Việc kiểm thử bổ sung hay gỡ lỗi một thành phần có nhiều lỗi có thể tốn
rất nhiều thời gian và chi phí. Để thuận lợi cho việc phát triển trước mắt
và lâu dài, tốt hơn nên bỏ thành phần đó và xây dựng lại từ đầu.
Tuy vậy, sự phân bố của các lỗi giữa các module là không đồng dạng với nhau.
Theo một nghiên cứu của Endres[1975] khi xem xét 212 module có 512 lỗi
được phát hiện, thì chỉ có một lỗi được tìm thấy trong 112 module, các module
cịn lại tồn tại một số lượng lỗi nhất định từ 14 đến 28 lỗi. Những module bất ổn
như vậy nên được xem xét bỏ đi và thực thi lại từ đầu.
Một cách cho công việc quản lý nếu gặp các trường hợp như trên đó là định ra
giới hạn lỗi tối đa có thể được phát hiện bởi một thành phần, nếu vượt quá giới
hạn này, thành phần sẽ bị bỏ đi và nên được thực hiện lại bởi lập trình viên có
chun môn cao hơn. Giới hạn tối đa này thay đổi tuỳ theo ứng dụng và các
thành phần khác nhau. Nếu xét một thành phần mã có nhiệm vụ đọc dữ liệu từ
cơ sở dữ liệu và xử lý sẽ có giới hạn lỗi nhỏ hơn nhiều so với một thành phần
phức tạp trong hệ thống hỗ trợ ngắm bắn của xe tăng. Một cách để quyết định
xem giới hạn lỗi cho một thành phần là tham khảo số lỗi từ các thành phần

tương tự cần bảo trì. Nhưng việc loại bỏ thành phần nếu vượt quá giới hạn lỗi
vẫn phải được đảm bảo.


-

-


19.
-

-

-

 Kiểm thử tích hợp

Kiểm thử tích hợp: mỗi thành phần cần phải được kiểm thử trước khi được
tích hợp. Điểm mấu chốt ở đây là thành phần mới cần phải được kiểm thử
như bằng phương pháp chuyên dụng và sau đó cần phải kiểm tra để đảm các
thành phần đã được tích hợp hoạt động bình thường như cũ.
Cơng cụ CASE: là một loại gói phần mềm hỗ trợ việc thiết kế và thực thi
phần mềm.
Về cơ bản, quá trình kiểm thử phần mềm có thể được đơn giản hố bằng
cách lưu trữ dữ liệu đầu vào cho test case trong một file. Phần mềm sau đó
được khởi chạy, và lấy các dữ liệu liên quan cần thiết đã được lưu trữ. Với
sự hỗ trợ của công cụ CASE, cả chu trình này đều có thể được tự động hố.
Cơng cụ CASE chạy từng test case đã được thiết lập và so sánh với kết quả
mong muốn, sau đó gửi báo cáo lại cho từng test case. Các test cases sau đó

được lưu trữ lại cho mục đích kiểm thử hồi quy bất cứ khi nào phần mềm
được chỉnh sửa. SilkTest là một ví dụ cho cơng cụ hỗ trợ việc này.
Vấn đề đặt ra khi phần mềm có một giao diện người dùng, thì cách tiếp cận
như trên sẽ không khả thi. Dữ liệu test như mở một menu hay nhấp một nút
không thể lưu trữ trên file như những dữ liệu thông thường và nếu kiểm thử
giao diện bằng cách thủ cơng thì sẽ rất tốn thời gian và công sức. Giải pháp
cho vấn đề này là sử dụng các công cụ CASE đặc biệt hỗ trợ việc ghi lại các
thao tác nhấp chuột, gõ phím,… Giao diện sẽ được kiểm thử thủ công chỉ
một lần để tạo kịch bản cho file dữ liệu test sau đó dữ liệu sẽ được sử dụng
cho những lần kiểm thử tự động sau. Một số công cụ case hỗ trợ kiểm thử
giao diện là QARun và XRunner.

20. Thử nghiệm sản phẩm
Có hai loại phần mềm chính:
 phần mềm thương mại bán sẵn (COTS) : Mục đích của thử nghiệm sản
phẩm COTS: là để đảm bảo rằng tồn bộ sản phẩm khơng có lỗi. Khi q
trình kiểm tra sản phẩm hồn tất, sản phẩm sẽ trải qua quá trình kiểm tra
alpha và beta.
 Phần mềm tùy chỉnh trải qua quá trình thử nghiệm sản phẩm hơi khác
nhau.Nhóm SQA phải đảm bảo rằng sản phẩm sẽ khơng thất bại trong
q trình kiểm tra chấp nhận. Việc một sản phẩm không thể vượt qua
kiểm tra chấp nhận sẽ gây tác động xấu đến tổ chức phát triển.
Nhóm SQA phải kiểm thử sản phẩm gần giống với kiểm thử chấp nhận: