Kiểm thử không phải là một hoạt động độc lập.

Nó có vị trí trong mô hình vòng đời

phát triển phần mềm và do đó vòng đời được áp dụng sẽ quyết định phần lớn cách tổ
chức kiểm thử.

Có nhiều hình thức kiểm thử khác nhau. Bởi vì một số lĩnh vực, thường có các mối
quan tâm khác nhau, có liên quan đến vòng đời phát triển, điều quan trọng là phải hiểu
và xác định rõ ràng các cấp độ và loại kiểm thử khác nhau.

Chương này thảo luận về các mô hình phát triển phần mềm được áp dụng phổ biến
nhất, các cấp độ kiểm thử và các loại kiểm thử. Bảo trì có thể được coi là một ví dụ cụ
thể của một quy trình kiểm thử. Cách thức bảo trì ảnh hưởng đến quy trình kiểm thử,
các cấp độ, các loại và cách thức kiểm thử có thể được tổ chức được mô tả trong phần
cuối cùng của chương này.

CÁC MÔ HÌNH PHÁT TRIỂN PHẦN

MỀM
Các phần sẽ xuất hiện trong đề thi

1. Hiểu mối quan hệ giữa phát triển, hoạt động kiểm thử và sản phẩm công việc
trong vòng đời phát triển và đưa ra các ví dụ dựa trên đặc điểm và bối cảnh của
dự án và sản phẩm. (K2)
2. Nhận ra thực tế rằng các mô hình phát triển phần mềm phải được điều chỉnh cho
phù hợp với bối cảnh của dự án và các đặc tính của sản phẩm. (K1)
3. Nhắc lại lý tại sao có các mức độ kiểm thử khác nhau và các đặc điểm của bài
kiểm thử tốt trong bất kỳ mô hình vòng đời nào. (K1)

Quy trình phát triển được chọn cho một dự án sẽ phụ thuộc vào mục tiêu ngắn hạn và
mục tiêu dài hạn của dự án. Có rất nhiều vòng đời phát triển đã được phát triển để đạt
được các mục đích yêu cầu khác nhau.

Các vòng đời này bao gồm từ các phương pháp nhẹ và nhanh , trong đó thời gian đưa
ra thị trường là cốt lõi, cho đến các phương pháp được kiểm soát và tài liệu hóa đầy
đủ, trong đó chất lượng và độ tin cậy là động lực chính.

Mỗi phương pháp đều có vị trí trong việc phát triển phần mềm hiện đại và quy trình
phát triển phù hợp nhất nên được áp dụng cho mỗi dự án. Các mô hình chỉ rõ các giai
đoạn khác nhau của quy trình và trình tự thực hiện chúng.

Mô hình vòng đời được áp dụng cho một dự án sẽ có tác động lớn đến quy trình kiểm
thử được thực hiện. Kiểm thử không tồn tại một cách cô lập; hoạt động kiểm thử có
liên quan nhiều đến hoạt động phát triển phần mềm. Nó sẽ xác định cái gì, ở đâu và
khi nào của việc kiểm thử theo kế hoạch, ảnh hưởng đến kiểm thử hồi quy và phần lớn
xác định kỹ thuật kiểm thử nào sẽ sử dụng.

Cách tổ chức kiểm thử phải phù hợp với vòng đời phát triển nếu không sẽ không
mang lại lợi ích. Nếu thời gian để ra
thị trường là động lực chính, khi đó việc kiểm thử phải nhanh chóng và hiệu quả. Nếu
vòng đời phát triển phần mềm phải được tài liệu hóa đầy đủ, thì việc kiểm thử cũng
phải được tài liệu hóa đầy đủ.

Trong mọi vòng đời phát triển, một phần của kiểm thử tập trung vào kiểm thử xác
minh (verification) và một phần tập trung vào kiểm thử xác nhận (validation).

Xác minh liên quan đến việc đánh giá một sản phẩm, thành phần hoặc hệ thống làm
việc để xác định xem nó có đáp ứng các yêu cầu đặt ra hay không. Trên thực tế, việc
xác minh tập trung vào câu hỏi "Có phải sản phẩm được xây dựng theo đặc điểm kỹ
thuật không?".

Xác nhận có liên quan đến việc đánh giá một sản phẩm, thành phần hoặc hệ thống làm
việc để xác định xem nó có đáp ứng các nhu cầu và yêu cầu của người dùng hay
không. Việc xác thực tập trung vào câu hỏi "Liệu sản phẩm đã xây dựng phù hợp với
mục đích, ví dụ: nó có cung cấp giải pháp cho vấn đề không?".

MÔ HÌNH CHỮ V (V-MODEL)

Trước khi thảo luận về V-Model, ta sẽ xem xét mô hình đi trước nó.

Mô hình thác nước (waterfall) là một trong những mô hình sớm nhất được thiết kế.
Nó có một dòng thời gian tự nhiên, nơi các tác vụ được thực hiện theo cách tuần tự.

Bắt đầu từ đỉnh thác với một nghiên cứu khả thi và đi xuống thông qua các nhiệm vụ
khác nhau của dự án để hoàn thành việc triển khai vào môi trường thực tế. Thiết kế
chuyển sang phát triển, sau đó chuyển sang xây dựng và cuối cùng là thử nghiệm.

Kiểm thử có xu hướng xảy ra vào cuối vòng đời của dự án vì vậy lỗi được phát hiện
gần với ngày triển khai trực tiếp. Với mô hình này, rất khó để nhận được phản hồi
được chuyển ngược lên thác nước và có những khó khăn nếu cần thực hiện nhiều lần
lặp lại cho một giai đoạn cụ thể.
Mô hình thác nước
V-Model được phát triển để giải quyết một số vấn đề gặp phải khi sử dụng phương
pháp tiếp cận thác nước truyền thống. Lỗi được phát hiện quá muộn trong vòng đời, vì
kiểm thử không được tham gia cho đến khi kết thúc dự án.

Kiểm thử cũng tăng thêm thời gian thực hiện do sự tham gia muộn của nó. Mô hình
V-Model cung cấp hướng dẫn rằng kiểm thử cần bắt đầu càng sớm càng tốt trong
vòng đời, như chúng ta đã thấy trong Chương 1, là một trong những nguyên tắc cơ
bản của kiểm thử có cấu trúc.

Nó cũng cho thấy rằng kiểm thử không chỉ là một hoạt động dựa trên thực thi. Có một
loạt các hoạt động cần được thực hiện trước khi kết thúc giai đoạn lập trình. Các hoạt
động này nên được thực hiện song song với các hoạt động phát triển và người kiểm
thử cần làm việc với các nhà phát triển và BA để có thể thực hiện các tác vụ này.

Các sản phẩm công việc được tạo ra bởi các nhà phát triển và BA trong quá trình phát
triển là cơ sở để kiểm thử ở một hoặc nhiều cấp độ. Bằng cách bắt đầu thiết kế kiểm
thử sớm, lỗi thường được tìm thấy trong các tài liệu cơ sở kiểm thử. Thực tế là rất tốt
nếu có tester tham gia thậm chí sớm hơn, trong quá trình xem xét các tài liệu cơ sở
(dự thảo).
V-Model

V-Model là một mô hình minh họa cách các hoạt động kiểm thử xác minh và xác
nhận (verification and validation) có thể được tích hợp vào từng giai đoạn của vòng
đời. Trong V-Model, kiểm tra xác nhận diễn ra đặc biệt trong giai đoạn đầu (ví dụ:
xem xét các yêu cầu của người dùng) và vào cuối vòng đời (ví dụ: trong quá trình
kiểm thử chấp nhận của người dùng).

Mặc dù có các biến thể của V-Model, nhưng một loại V-Model phổ biến sử dụng bốn
cấp độ kiểm thử. Bốn cấp độ kiểm tra được sử dụng, mỗi cấp độ có mục tiêu riêng, là:

 Kiểm thử thành phần: tìm kiếm lỗi và xác minh hoạt động của các thành phần
phần mềm (ví dụ: mô-đun, chương trình, đối tượng, lớp, v.v.) có thể kiểm tra
riêng biệt;
 Kiểm thử tích hợp: kiểm tra giao diện giữa các thành phần, tương tác với các
phần khác nhau của hệ thống như hệ điều hành, hệ thống tệp và phần cứng hoặc
giao diện giữa các hệ thống;
 Kiểm thử hệ thống: liên quan đến hành vi của toàn bộ hệ thống/sản phẩm như
được xác định bởi phạm vi của một dự án phát triển hoặc sản phẩm. Trọng tâm
chính của kiểm thử hệ thống là xác minh theo các yêu cầu cụ thể;
 Kiểm thử chấp nhận: kiểm thử xác nhận nhu cầu của người dùng, yêu cầu và
các quy trình nghiệp vụ được tiến hành để xác định có chấp nhận hệ thống hay
không.

Các cấp độ kiểm thử khác nhau được giải thích và thảo luận chi tiết trong Phần 2.2.

Trong thực tế, V-Model có thể có nhiều hơn, ít hơn hoặc nhiều mức độ phát triển và
kiểm thử khác nhau, tùy thuộc vào dự án và sản phẩm phần mềm.

Ví dụ, có thể có kiểm thử tích hợp thành phần sau khi kiểm thử thành phần và kiểm
thử tích hợp hệ thống sau khi kiểm thử hệ thống.

Các cấp độ kiểm thử có thể được kết hợp hoặc tổ chức lại tùy thuộc vào bản chất của
dự án hoặc kiến trúc hệ thống. Để tích hợp sản phẩm phần mềm bán sẵn (COTS)
thương mại vào hệ thống, người mua chỉ có thể thực hiện kiểm thử tích hợp ở cấp hệ
thống (ví dụ: tích hợp với cơ sở hạ tầng và các hệ thống khác) và ở giai đoạn sau kiểm
thử chấp nhận
Lưu ý rằng các loại sản phẩm công việc được đề cập trong Hình 2.2 ở phía bên trái
của mô hình chữ V chỉ là một minh họa. Trong thực tế, chúng có nhiều tên gọi khác
nhau. Các tài liệu tham khảo cho các sản phẩm công việc chung bao gồm Tích hợp
mô hình trưởng thành khả năng (CMMi) hoặc "Quy trình vòng đời phần mềm" từ
ISO/IEC 12207.

CMMi là một khuôn khổ để cải tiến quy trình cho cả kỹ thuật hệ thống và kỹ thuật
phần mềm. Nó cung cấp hướng dẫn về nơi tập trung và cách thức, để tăng mức độ
hoàn thiện của quá trình. ISO/IEC 12207 là một tiêu chuẩn quy trình vòng đời phần
mềm tích hợp đang nhanh chóng trở nên phổ biến hơn.

Nội dung tiếp theo sẽ tiếp tục giới thiệu về các mô hình phát triển phần mềm khác.

Vòng đời phát triển lặp

Không phải tất cả các vòng đời đều tuần tự. Ngoài ra còn có các vòng đời lặp đi lặp
lại hoặc tăng dần, thay vì một dòng thời gian phát triển từ đầu đến cuối, ta chuyển qua
một số giai đoạn vòng đời khép kín nhỏ hơn cho cùng một dự án. Như với V-Model,
có nhiều biến thể của vòng đời lặp.
Đặc điểm chung của các phương pháp tiếp cận lặp là phần chuyển giao được chia
thành các phần tăng thêm hoặc các bản với mỗi phần có thêm chức năng mới.

Phần gia tăng ban đầu sẽ chứa cơ sở hạ tầng cần thiết để hỗ trợ xây dựng chức năng
ban đầu. Phần gia tăng được tạo ra bởi một lần lặp có thể được kiểm thử ở một số cấp
độ như một phần của quá trình phát triển. Các bước tiếp theo sẽ cần kiểm thử chức
năng mới, kiểm thử hồi quy chức năng hiện có và kiểm thử tích hợp các phần mới với
phần hiện có.

Kiểm thử hồi quy ngày càng quan trọng đối với tất cả các lần lặp sau lần đầu tiên.
Điều này có nghĩa là sẽ cần nhiều công việc kiểm thử hơn ở mỗi giai đoạn chuyển
giao tiếp theo, điều này phải được cho phép trong các kế hoạch của dự án.

Vòng đời này có thể chuyển giao các chức năng quan trọng ra thị trường sớm, có thể
dễ quản lý hơn vì khối lượng công việc được chia thành nhiều phần nhỏ hơn và có thể
giảm chi phí đầu tư ban đầu mặc dù có thể tốn nhiều chi phí hơn trong thời gian dài.

Ngoài ra, sự hiện diện sớm trên thị trường sẽ có nghĩa là kiểm thử xác nhận được thực
hiện ở mỗi bước gia tăng, do đó đưa ra phản hồi sớm về giá trị kinh doanh và tính phù
hợp để sử dụng của sản phẩm.

Ví dụ về các mô hình phát triển lặp hoặc tăng dần là nguyên mẫu (prototyping), phát
triển ứng dụng nhanh (Raid Application Development - RAD), Quy trình thống nhất
hợp lý (Rational Unified Process - RUP) và phát triển nhanh gọn (Agile).

Với mục đích hiểu rõ hơn về các mô hình phát triển lặp và vai trò thay đổi của kiểm
thử, một giải thích ngắn gọn về cả RAD và Agile được cung cấp.
Phát triển ứng dụng nhanh RAD
Phát triển ứng dụng nhanh (RAD) chính thức là sự phát triển song song các chức năng
và tích hợp sau đó. Các thành phần/chức năng được phát triển song song như thể
chúng là các dự án nhỏ, các phát triển được đóng gói theo thời gian, chuyển giao và
sau đó được lắp ráp thành một nguyên mẫu hoạt động.

Điều này có thể rất nhanh chóng cung cấp cho khách hàng một cái gì đó để xem và sử
dụng cũng như cung cấp phản hồi về việc chuyển giao và yêu cầu của họ.

Có thể thay đổi và phát triển sản phẩm nhanh chóng bằng cách sử dụng phương pháp
luận này. Tuy nhiên, đặc điểm kỹ thuật sẽ cần được phát triển vào một thời điểm nào
đó, và dự án sẽ cần phải kiểm soát một cách chính thức hơn trước khi đi vào sản xuất.
Phương pháp luận này cho phép xác nhận sớm các rủi ro công nghệ và đáp ứng nhanh
chóng các yêu cầu thay đổi của khách hàng.

Phương pháp phát triển hệ thống động [Dynamic System Development Methodology -
DSDM] là một quy trình RAD đã được tinh chỉnh cho phép đưa ra các biện pháp kiểm
soát để ngăn quá trình vượt ra khỏi tầm kiểm soát.

Hãy nhớ rằng vẫn cần thiết có việc thực hành phát triển tốt để các phương pháp này
hoạt động. Cần duy trì quản lý cấu hình chặt chẽ đối với những thay đổi nhanh chóng
đang được thực hiện trong một số chu kỳ phát triển song song.
Từ góc độ thử nghiệm, cần lập kế hoạch rất cẩn thận và cập nhật kế hoạch thường
xuyên vì mọi thứ sẽ thay đổi rất nhanh (xem Chương 5 để biết thêm về kế hoạch kiểm
thử).

Quy trình RAD khuyến khích phản hồi tích cực của khách hàng. Khách hàng có thể
nhìn thấy sản phẩm sớm, có thể cung cấp phản hồi về thiết kế và có thể quyết định,
dựa trên chức năng hiện có, có nên tiếp tục phát triển hay không, chức năng nào sẽ
bao gồm trong phần chuyển giao tiếp theo hoặc thậm chí dừng dự án nếu không mang
lại giá trị mong đợi.

Một giải pháp tập trung vào kinh doanh sớm trên thị trường mang lại lợi tức đầu tư
(ROI) sớm và có thể cung cấp thông tin tiếp thị có giá trị cho doanh nghiệp. Do đó,
xác nhận với quá trình phát triển RAD là một hoạt động sớm và chính.

Phát triển nhanh gọn (Agile)

Extreme Programming (XP) hiện là một trong những mô hình vòng đời phát triển
nhanh nổi tiếng nhất. Phương pháp này được cho là thân thiện với con người hơn các
phương pháp phát triển truyền thống.

Một số đặc điểm của XP là:

 Nó thúc đẩy việc tạo ra các câu chuyện kinh doanh để xác định chức năng.
 Nó yêu cầu một khách hàng trực tiếp để có phản hồi liên tục, xác định và thực
hiện kiểm thử chấp nhận chức năng.
 Nó thúc đẩy lập trình cặp (pair programming) và quyền sở hữu chia sẻ code
giữa các nhà phát triển.
 Nó tuyên bố rằng các kịch bản kiểm thử thành phần sẽ được viết trước khi lập
trình và những bài kiểm thử đó phải được tự động hóa.
 Nó nói rằng việc tích hợp và kiểm thử code sẽ diễn ra nhiều lần trong ngày.
 Nó nói rằng luôn thực hiện giải pháp đơn giản nhất để đáp ứng các vấn đề ngày
nay.

Với XP, có rất nhiều lần lặp yêu cầu kiểm thử. Các nhà phát triển XP viết mọi trường
hợp kiểm thử mà họ có thể nghĩ ra và tự động hóa chúng.
Mỗi khi code thay đổi, nó sẽ được kiểm thử thành phần và sau đó được tích hợp với
code hiện có, sau đó được kiểm thử tích hợp hoàn toàn bằng cách sử dụng toàn bộ các
trường hợp kiểm thử.

Điều này cho phép tích hợp liên tục, theo đó có nghĩa là các thay đổi được kết hợp
liên tục vào bản phần mềm được xây dựng. Đồng thời, tất cả các trường hợp kiểm thử
phải chạy ở 100% nghĩa là tất cả các trường hợp kiểm thử đã được xác định và tự
động hóa đều được thực thi và vượt qua.

XP không phải là việc thực hiện các hoạt động cực đoan trong quá trình phát triển, mà
là thực hiện các hoạt động bổ sung giá trị gia tăng đã biết một cách cực đoan

Kiểm thử trong một mô hình vòng đời

Tóm lại, bất kỳ mô hình vòng đời nào đang được sử dụng, có một số đặc điểm của
kiểm thử tốt:
 Đối với mỗi hoạt động phát triển có một hoạt động kiểm thử tương ứng;
 Mỗi cấp độ kiểm thử có các mục tiêu kiểm thử cụ thể cho cấp độ đó;
 Việc phân tích và thiết kế các bài kiểm thử cho một mức độ kiểm thử nhất định
nên bắt đầu trong quá trình phát triển hoạt động tương ứng;
 Người kiểm thử nên tham gia vào việc xem xét tài liệu ngay khi có bản nháp
trong quy trình phát triển.
Ở phần tiếp theo, chúng ta sẽ tìm hiểu về Các cấp độ kiểm thử.

CẤP ĐỘ KIỂM THỬ

Các mục sẽ xuất hiện trong đề thi

So sánh các cấp độ thử nghiệm khác nhau: mục tiêu chính, đối tượng kiểm thử điển
hình, mục tiêu kiểm thử điển hình (ví dụ: chức năng hoặc cấu trúc) và các sản
phẩm công việc liên quan, người kiểm thử, loại lỗi cần được xác định. (K2)

Các đặc điểm chính cho mỗi cấp độ kiểm thử được thảo luận và xác định để có thể
phân tách rõ ràng hơn các cấp độ kiểm thử khác nhau.
Sự hiểu biết và định nghĩa kỹ lưỡng về các cấp độ kiểm thử khác nhau sẽ xác định các
phần còn thiếu, ngăn ngừa sự chồng chéo và lặp lại. Đôi khi đưa ra sự chồng chéo có
chủ ý để giải quyết những rủi ro cụ thể. Hiểu được liệu chúng ta có muốn chồng chéo
hay không và loại bỏ những khoảng trống sẽ làm cho việc kiểm thử hiệu quả hơn.

KIỂM THỬ THÀNH PHẦN

Kiểm thử thành phần, còn được gọi là kiểm thử đơn vị, kiểm thử mô-đun hay kiểm
thử chương trình, tìm kiếm lỗi và xác minh hoạt động của phần mềm (ví dụ: mô-đun,
chương trình, đối tượng, lớp, v.v.) có thể kiểm thử riêng biệt.

Kiểm thử thành phần có thể được thực hiện tách biệt với phần còn lại của hệ thống tùy
thuộc vào bối cảnh của vòng đời phát triển và hệ thống.

Hầu hết các phần mềm sơ khai (stub) và trình điều khiển (driver) thường được sử
dụng để thay thế phần mềm bị thiếu và mô phỏng giao diện giữa các thành phần phần
mềm một cách đơn giản. Một stub được gọi từ thành phần phần mềm sẽ được kiểm
thử; còn trình điều khiển gọi đến một thành phần được kiểm thử (xem Hình 2.5).

Kiểm thử thành phần có thể bao gồm kiểm tra chức năng và các đặc điểm phi chức
năng cụ thể như hành vi tài nguyên (ví dụ: rò rỉ bộ nhớ), kiểm thử hiệu suất hoặc độ
bền cũng như kiểm thử cấu trúc (ví dụ: phạm vi quyết định). Các trường hợp kiểm thử
bắt nguồn từ các sản phẩm công việc như thiết kế phần mềm hoặc mô hình dữ liệu.

Thông thường, kiểm thử thành phần xảy ra với quyền truy cập vào mã đang được
kiểm tra và với sự hỗ trợ của môi trường phát triển, chẳng hạn như khung kiểm tra
đơn vị hoặc công cụ gỡ lỗi và trong thực tế, thường liên quan đến lập trình viên đã
viết mã.

Đôi khi, tùy thuộc vào mức độ rủi ro có thể áp dụng, kiểm thử thành phần được thực
hiện bởi một lập trình viên khác, do đó mang lại tính độc lập. Lỗi thường được sửa
ngay sau khi chúng được tìm thấy, mà không cần chính thức ghi lại các sự cố được
tìm thấy.

Một cách tiếp cận trong kiểm thử thành phần, được sử dụng trong Extreme
Programming (XP), là chuẩn bị và tự động hóa các trường hợp kiểm thử trước khi mã
hóa. Đây được gọi là phương pháp tiếp cận kiểm thử đầu tiên hoặc phát triển theo
hướng kiểm thử. Cách tiếp cận này có tính lặp lại cao và dựa trên các chu kỳ phát
triển các trường hợp kiểm thử , sau đó xây dựng và tích hợp các đoạn mã nhỏ và thực
hiện các kiểm thử thành phần cho đến khi chúng được vượt qua.

KIỂM THỬ TÍCH HỢP

Kiểm thử tích hợp kiểm tra giao diện giữa các thành phần, tương tác với các phần
khác nhau của hệ thống như hệ điều hành, hệ thống tệp và phần cứng hoặc giao diện
giữa các hệ thống. Lưu ý rằng kiểm thử tích hợp nên được phân biệt với các hoạt động
tích hợp khác.

Kiểm tra tích hợp thường được thực hiện bởi người tích hợp, nhưng tốt nhất là do
người kiểm thử tích hợp cụ thể hoặc nhóm kiểm thử.

Có thể có nhiều hơn một cấp độ kiểm thử tích hợp và nó có thể được thực hiện trên
các đối tượng kiểm thử có kích thước khác nhau. Ví dụ:

 Kiểm thử tích hợp thành phần kiểm tra sự tương tác giữa các thành phần phần
mềm và được thực hiện sau khi kiểm thử thành phần;
 Kiểm thử tích hợp hệ thống kiểm tra sự tương tác giữa các hệ thống khác nhau
và có thể được thực hiện sau khi kiểm thử hệ thống. Trong trường hợp này, tổ
chức đang phát triển có thể chỉ kiểm soát một mặt của giao diện, vì vậy các
thay đổi có thể gây mất ổn định. Các quy trình nghiệp vụ được thực hiện dưới
dạng quy trình công việc có thể liên quan đến một loạt hệ thống thậm chí có thể
chạy trên các nền tảng khác nhau.

Phạm vi tích hợp càng lớn, càng khó tách rời các lỗi đối với một giao diện cụ thể, điều
này có thể dẫn đến tăng rủi ro. Điều này dẫn đến các cách tiếp cận khác nhau để kiểm
thử tích hợp.
Một điểm cực đoan là tất cả các thành phần hoặc hệ thống được tích hợp đồng thời,
sau đó mọi thứ đều được kiểm thử tổng thể. Đây được gọi là kiểm thử tích hợp " big
bang". Kiểm thử big bang có lợi thế là mọi thứ đã hoàn thành trước khi bắt đầu kiểm
thử tích hợp. Không cần phải mô phỏng các bộ phận (khi chưa hoàn thành). Nhược
điểm lớn là nói chung việc này tốn nhiều thời gian và khó tìm ra nguyên nhân gây ra
lỗi.

Vì vậy, tích hợp big-bang có vẻ là một ý tưởng hay khi lập kế hoạch dự án, lạc quan
và hy vọng sẽ không gặp vấn đề gì.

Nếu ai đó nghĩ rằng kiểm thử tích hợp sẽ tìm thấy lỗi, thì đó là một thực tiễn tốt để
xem xét liệu có thể tiết kiệm thời gian bằng cách chia nhỏ quy trình kiểm thử tích hợp
hay không.

Một điểm cực đoan khác là tất cả các chương trình đều được tích hợp từng cái một và
một bài kiểm thử được thực hiện sau mỗi bước (kiểm thử gia tăng). Giữa hai thái cực
này, có một loạt các biến thể. Phương pháp gia tăng có ưu điểm là lỗi được tìm thấy
sớm trong từng phần nhỏ hơn khi nó tương đối dễ dàng để phát hiện ra nguyên nhân.
Một bất lợi là nó có thể tốn nhiều thời gian vì phải phát triển và sử dụng trình điều
khiển trong quá trình kiểm thử.

Trong kiểm thử tích hợp gia, một loạt các khả năng tồn tại, một phần tùy thuộc vào kiến trúc hệ thống:
 Top-down (trên xuống): việc kiểm thử diễn ra từ trên xuống dưới, tuân theo
luồng điều khiển hoặc cấu trúc kiến trúc (ví dụ: bắt đầu từ GUI (giao diện
người dùng) hoặc menu chính). Các thành phần hoặc hệ thống được thay thế
bằng các stub.
 Bottom-up (dưới lên): việc kiểm thử diễn ra từ dưới cùng của luồng kiểm soát
trở lên. Các thành phần hoặc hệ thống được thay thế bởi drivers.
 Gia tăng chức năng: việc tích hợp và kiểm thử diễn ra trên cơ sở các chức
năng như được ghi trong đặc tả chức năng.
Trình tự tích hợp ưu tiên và số lượng các bước tích hợp cần thiết phụ thuộc vào vị trí
trong kiến trúc của các giao diện rủi ro cao.

Sự lựa chọn tốt nhất là bắt đầu tích hợp với những giao diện được cho là sẽ gây ra hầu
hết các vấn đề. Làm như vậy sẽ ngăn ngừa được lỗi lớn ở cuối giai đoạn kiểm thử tích
hợp. Để giảm nguy cơ phát hiện lỗi muộn, việc tích hợp thường nên tăng dần thay vì
"big-bang".

Lý tưởng nhất là người kiểm thử nên hiểu kiến trúc và ảnh hưởng đến việc lập kế
hoạch tích hợp. Nếu các bài kiểm thử tích hợp được lên kế hoạch trước khi các thành
phần hoặc hệ thống được xây dựng, chúng có thể được phát triển theo thứ tự cần thiết
để kiểm thử hiệu quả nhất.

Ở mỗi giai đoạn tích hợp, người kiểm thử chỉ tập trung vào chính quá trình tích hợp.
Ví dụ, nếu họ đang tích hợp thành phần A với thành phần B, họ quan tâm đến việc
kiểm tra giao tiếp giữa các thành phần, chứ không phải chức năng của một trong hai
thành phần.

Cả hai phương pháp tiếp cận chức năng và cấu trúc có thể được sử dụng. Kiểm thử
các đặc tính phi chức năng cụ thể (ví dụ: hiệu suất) cũng có thể được đưa vào kiểm
thử tích hợp. Kiểm thử tích hợp có thể được thực hiện bởi các nhà phát triển, nhưng
có thể được thực hiện bởi một nhóm chuyên gia kiểm thử tích hợp riêng biệt hoặc bởi
một nhóm chuyên gia gồm các nhà phát triển/tích hợp bao gồm cả các chuyên gia phi
chức năng.

Phần tiếp theo sẽ trình bày về các cấp độ kiểm thử khác.

KIỂM THỬ HỆ THỐNG

Kiểm thử hệ thống liên quan đến hành vi của toàn bộ hệ thống/sản phẩm như được
xác định bởi phạm vi của một dự án phát triển hoặc sản phẩm. Có thể bao gồm các
kiểm thử dựa trên đặc tả rủi ro và/hoặc yêu cầu, quy trình nghiệp vụ, trường hợp sử
dụng hoặc các mô tả mức cao khác về hành vi của hệ thống, tương tác với hệ điều
hành và tài nguyên hệ thống.

Kiểm thử hệ thống thường là hoạt động kiểm thử cuối cùng thay mặt cho quá trình
phát triển để xác minh rằng hệ thống đáp ứng đặc điểm kỹ thuật và mục đích của nó
có thể là tìm ra càng nhiều lỗi càng tốt.

Hầu hết các thủ tục được thực hiện bởi những người kiểm thử chuyên nghiệp, tạo
thành một nhóm kiểm thử chuyên dụng và đôi khi độc lập trong quá trình phát triển,
báo cáo cho người quản lý phát triển hoặc người quản lý dự án.

Trong một số tổ chức, việc kiểm thử hệ thống được thực hiện bởi một nhóm bên thứ
ba hoặc bởi BA. Mức độ độc lập cần thiết được dựa trên mức độ rủi ro có thể áp dụng
và điều này sẽ có ảnh hưởng lớn đến cách tổ chức kiểm thử hệ thống.

Kiểm thử hệ thống cần điều tra cả các yêu cầu chức năng và phi chức năng của hệ
thống. Các bài kiểm thử phi chức năng điển hình bao gồm hiệu suất và độ tin cậy.
Người kiểm thử cũng có thể cần phải giải quyết các yêu cầu không đầy đủ hoặc không
có tài liệu. Kiểm thử hệ thống đối với các yêu cầu chức năng bắt đầu bằng cách sử
dụng các kỹ thuật dựa trên đặc điểm kỹ thuật (hộp đen) phù hợp nhất cho khía cạnh
của hệ thống được kiểm thử.

Ví dụ, một bảng quyết định có thể được tạo ra để kết hợp các tác động được mô tả
trong các quy tắc nghiệp vụ. Các kỹ thuật dựa trên cấu trúc (hộp trắng) cũng có thể
được sử dụng để đánh giá mức độ kỹ lưỡng của các phần tử được kiểm thử như cấu
trúc menu hoặc điều hướng trang web (xem Chương 4 để biết thêm về các loại kỹ
thuật khác nhau).

Kiểm thử hệ thống yêu cầu một môi trường kiểm thử được kiểm soát, kiểm soát các
phiên bản phần mềm, phần mềm kiểm thử và dữ liệu kiểm thử (xem Chương 5 để biết
thêm về quản lý cấu hình).

Kiểm thử hệ thống được thực hiện bởi tổ chức phát triển trong một môi trường (được
kiểm soát thích hợp). Môi trường kiểm thử phải tương ứng với mục tiêu cuối cùng
hoặc môi trường thực càng nhiều càng tốt để giảm thiểu rủi ro của các lỗi cụ thể về
môi trường không được tìm thấy bằng cách kiểm thử.

KIỂM THỬ CHẤP NHẬN

Khi tổ chức phát triển đã thực hiện kiểm thử hệ thống và đã sửa chữa tất cả hoặc hầu
hết lỗi, hệ thống sẽ được giao cho người dùng hoặc khách hàng để kiểm thử chấp
nhận. Bài kiểm thử chấp nhận phải trả lời các câu hỏi như: "Hệ thống có thể được phát
hành không?", "Những rủi ro (kinh doanh) nổi bật, nếu có là gì?" và "Sự phát triển có
đáp ứng được không?".
Kiểm thử chấp nhận thường là trách nhiệm của người dùng hoặc khách hàng, mặc dù
các bên liên quan khác cũng có thể tham gia. Việc thực hiện kiểm thử chấp nhận yêu
cầu một môi trường kiểm thử cho hầu hết các khía cạnh, đại diện cho môi trường sản
xuất.

Mục tiêu của kiểm thử chấp nhận là thiết lập sự tin cậy của hệ thống, một phần của hệ
thống hoặc các đặc tính phi chức năng cụ thể, ví dụ: khả năng sử dụng của hệ thống.

Kiểm thử chấp nhận thường tập trung nhất vào loại kiểm thử xác nhận, theo đó cố
gắng xác định xem hệ thống có phù hợp với mục đích hay không.

Tìm kiếm lỗi không nên là trọng tâm chính trong kiểm thử chấp nhận. Mặc dù nó
đánh giá mức độ sẵn sàng của hệ thống để triển khai và sử dụng, nhưng nó không nhất
thiết phải là mức thử nghiệm cuối cùng. Ví dụ, một kiểm thử tích hợp hệ thống quy
mô lớn có thể đến sau khi hệ thống được chấp nhận.

Kiểm thử chấp nhận có thể xảy ra ở nhiều cấp độ, ví dụ:

 Sản phẩm phần mềm thương mại Off The Shelf (COTS) có thể được kiểm thử
chấp nhận khi nó được cài đặt hoặc tích hợp.
 Kiểm thử nghiệm chấp nhận về khả năng sử dụng của một thành phần có thể
được thực hiện trong quá trình kiểm thử thành phần.
 Kiểm thử chấp nhận của một chức năng cải tiến mới có thể thực hiện trước khi
kiểm thử hệ thống.
Trong quá trình thực hiện kiểm thử chấp nhận đối với hệ thống hỗ trợ doanh nghiệp,
có thể phân biệt hai loại kiểm thử chính; do đặc tính đặc biệt của chúng, chúng thường
được chuẩn bị và thực hiện riêng biệt.

Kiểm thử chấp nhận của người dùng (user acceptance test - UAT) chủ yếu tập trung
vào chức năng do đó xác nhận tính phù hợp để sử dụng của hệ thống bởi người dùng
doanh nghiệp, trong khi kiểm thử chấp nhận hoạt động (còn gọi là kiểm thử chấp nhận
sản xuất) xác nhận xem hệ thống có đáp ứng yêu cầu đối với hoạt động.

UAT được thực hiện bởi người dùng và người quản lý ứng dụng. Về mặt lập kế
hoạch, UAT thường liên kết chặt chẽ với kiểm thử hệ thống, và trong nhiều trường
hợp sẽ được tổ chức một phần chồng chéo về thời gian.

Nếu hệ thống được kiểm thử bao gồm nhiều hoặc ít hệ thống con độc lập, thì kiểm thử
chấp nhận cho một hệ thống con tuân thủ các tiêu chí dừng của kiểm thử hệ thống, có
thể bắt đầu trong khi một hệ thống con khác có thể vẫn đang trong giai đoạn kiểm thử
hệ thống.

Trong hầu hết các tổ chức, quản trị hệ thống sẽ thực hiện kiểm thử chấp nhận ngay
trước khi hệ thống được phát hành. Kiểm thử chấp nhận có thể bao gồm kiểm thử các
tác vụ sao lưu/khôi phục, khắc phục thảm họa, bảo trì và kiểm tra định kỳ các lỗ hổng
bảo mật.

Các loại kiểm thử chấp nhận khác gồm kiểm thử chấp nhận hợp đồng (contract
acceptance testing) và kiểm thử chấp nhận tuân thủ (compliance acceptance testing).

Kiểm thử chấp nhận hợp đồng được thực hiện dựa trên các tiêu chí chấp nhận của hợp
đồng để sản xuất phần mềm. Việc chấp nhận phải được xác định chính thức khi hợp
đồng được thỏa thuận.

Kiểm thử chấp nhận tuân thủ hoặc kiểm thử chấp nhận tuân thủ được thực hiện dựa
trên các quy định phải được tuân thủ, chẳng hạn như các quy định của chính phủ, luật
pháp hoặc quy định về an toàn.

Nếu hệ thống đã được phát triển cho thị trường đại chúng (ví dụ: phần mềm thương
mại lâu đời (COTS)), trong một số trường hợp kiểm thử nó cho người dùng cá nhân
hoặc khách hàng là không thực tế.

Phản hồi là cần thiết từ những người dùng tiềm năng hoặc người dùng hiện tại trên thị
trường trước khi sản phẩm phần mềm được đưa ra bán thương mại. Loại hệ thống này
thường trải qua hai giai đoạn kiểm chấp nhận.
Đầu tiên được gọi là kiểm thử alpha. Kiểm thử này diễn ra tại môi trường của nhà
phát triển. Một bộ phận người dùng tiềm năng và các thành viên trong tổ chức của nhà
phát triển được mời sử dụng hệ thống. Các nhà phát triển quan sát người dùng và lưu
ý các vấn đề. Kiểm thử alpha cũng có thể được thực hiện bởi một nhóm thử nghiệm
độc lập.

Kiểm thử beta (hoặc field testing), gửi hệ thống đến một nhóm người dùng người cài
đặt nó và sử dụng nó trong các điều kiện làm việc trong thế giới thực. Người dùng gửi
các bản ghi chép về các sự cố xảy ra với hệ thống cho tổ chức phát triển nơi để sửa
lỗi.

Lưu ý rằng các tổ chức có thể sử dụng các thuật ngữ khác, chẳng hạn như kiểm thử
chấp nhận tại nhà máy và kiểm thử chấp nhận tại hiện trường cho các hệ thống được
kiểm thử trước và sau khi được chuyển đến địa điểm của khách hàng.

Ở phần tiếp theo của chương 2, chúng ta sẽ tìm hiểu về các loại kiểm thử.