ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
ĐOÀN MẠNH ĐỨC NGHIÊN CỨU VÀ XÂY DỰNG CÔNG CỤ
KIỂM THỬ ỨNG DỤNG WEB LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN Hà Nội – 2014


Hà Nội – 2014
1 LỜI CẢM ƠN

Luận văn Thạc sĩ này được thực hiện tại Đại học Công Nghệ - Đại học Quốc
Gia Hà Nội dưới sự hướng dẫn của TS. Võ Đình Hiếu. Xin được gửi lời cảm ơn sâu
sắc đến thầy về định hướng khoa học, liên tục quan tâm, tạo điều kiện thuận lợi trong
suốt quá trình nghiên cứu hoàn thành luận văn này. Tôi xin được gửi lời cảm ơn đến
các thầy, cô trong Bộ môn Công nghệ phần mềm cũng như Khoa Công nghệ thông tin
đã mang lại cho tôi những kiến thức vô cùng quý giá và bổ ích trong quá trình theo học
tại trường.
Tôi cũng xin chân thành cảm ơn đến gia đình tôi, những sự quan tâm và động
viên của bố, mẹ và em gái đã giúp tôi có thêm nghị lực, cố gắng để hoàn thành luận
văn này.
Cuối cùng, xin gửi lời cảm ơn chân thành nhất đến các bạn cùng học K19, các
bạn đồng nghiệp đã giúp đỡ tôi trong suốt 2 năm học tập.

Hà Nội, ngày 30 tháng 10 năm 2014


Tôi xin chịu mọi trách nhiệm và mọi hình thức kỷ luật theo quy định cho lời
cam đoan này.

Hà Nội, ngày 30 tháng 10 năm 2014

Đoàn Mạnh Đức
3
2.2.2. Công cụ kiểm thử hàm 38
2.2.3. Công cụ kiểm thử khả năng chịu tải của ứng dụng Web 40
2.3. Thư viện hỗ trợ xây dựng công cụ kiểm thử tự động 41
CHƢƠNG 3 XÂY DỰNG CÔNG CỤ KIỂM THỬ TỰ ĐỘNG 44
3.1. Đặt vấn đề bài toán 44
4 3.2. Phân tích bài toán 45
3.3. Thỏa thuận khi sử dụng công cụ 50
3.4. Xây dựng công cụ 50
3.5. Ứng dụng công cụ vào thực tế 54
3.5.1. Ứng dụng vào form thành viên đăng nhập 54
3.5.2. Ứng dụng vào form đăng ký nhận bản tin 58
3.6. Đánh giá ưu nhược điểm của công cụ 60
CHƢƠNG 4 KẾT LUẬN 61
4.1. Tóm tắt kết quả làm được 61
4.2. Hạn chế 61
4.3. Hướng nghiên cứu 61
TÀI LIỆU THAM KHẢO 62
PHỤ LỤC 63
Phụ lục 1: Kết quả sau khi thực hiện kiểm thử form thành viên đăng nhập 63
Phụ lục 2: Kết quả sau khi thực hiện kiểm thử form đăng ký nhận bản tin 64


URL Uniform Resource Locator, đường dẫn tham chiếu tới tài nguyên trên
Internet. 6

DANH MỤC CÁC BẢNG

Bảng 1.1. Các điều kiện con kết hợp trong câu lệnh điều kiện 26
Bảng 1.2. Một số lỗi thường gặp trên ứng dụng Web 32
Bảng 2.1. Minh họa một số quy ước về lập trình của Microsoft. 34
Bảng 2.2. Hàm và từ khóa thường dùng của Selenium WebDriver 42

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 1.1. Mã nguồn minh họa Driver và Stub 13
Hình 1.2. Kiểm thử hồi quy được thực hiện tại các mức kiểm thử khác nhau. 17
Hình 1.3. Các câu lệnh tuần tự có bất thường loại 1. 22
Hình 1.4. Câu lệnh có bất thường loại 2. 22
Hình 1.5. Sơ đồ chuyển trạng thái của một biến tương ứng với những bất thường về
dòng dữ liệu. 23
Hình 1.6. Các biểu tượng xây dựng đồ thị dòng điều khiển. 25
Hình 1.7. Mã nguồn tính tổng các số từ 1 đến 9. 25
Hình 1.8. Đồ thị dòng điều khiển của mã nguồn hình 1.9 25
Hình 1.9. Ví dụ mã nguồn hàm ReturnAverage. 27
Hình 1.10. Đồ thị dòng dữ liệu minh họa hàm ReturnAverage. 28
Hình 2.1. Giao diện Fxcop 33
Hình 2.2. Mã nguồn được phân tích bởi Fxcop 34
Hình 2.3. Kết quả phân tích từ Fxcop 35
Hình 2.4. Giao diện công cụ JSLint 36
Hình 2.5. Mã nguồn được phân tích bởi JSLint 36
Hình 2.6. Kết quả phân tích từ JSLint 36
Hình 2.7. Giao diện Browser Shots 38
Hình 2.8. Giao diện người dùng trên các trình duyệt khác nhau. 38
Hình 2.9. Giao diện Selenium IDE. 38
Hình 2.10. Các thao tác xử lý được Selenium IDE ghi lại. 39
Hình 2.11. Mã HTML của ca kiểm thử được Selenium IDE lưu lại. 40
Hình 2.12. Giao diện công cụ loader.io 41
Hình 2.13. Kết quả khi thực thi kiểm thử với loader.io. 41
Hình 3.1. Form thêm người dùng trên ứng dụng Web. 44
Hình 3.2. Minh họa hộp thông báo đăng nhập thành công 46
Hình 3.3. Minh họa dòng thông báo từ ứng dụng Web đến người dùng 46
8 9
LỜI GIỚI THIỆU

Với sự phát triển của Internet và công nghệ phần mềm, các ứng dụng Web đang
dần thay thế các ứng dụng phần mềm truyền thống bởi tính tiện lợi của nó. Đi kèm với
thành công mà những ứng dụng Web mang lại cho nhà phát triển đó là những thách
thức như phải đảm bảo và nâng cao chất lượng cho người dùng khi sử dụng dịch vụ.
Một trong những giải pháp để hoàn thành tốt công việc này đó là thực hiện kiểm thử
phần mềm. Kiểm thử là một công việc tốn nhiều thời gian và chi phí, thông thường
thời gian dành cho việc kiểm thử chiếm đa số thời gian phát triển ứng dụng phần mềm.
Tuy nhiên, để thực hiện kiểm thử đòi hỏi kiểm thử viên phải kiên nhẫn và tỉ mỉ, chính
những điều này dẫn tới sự cần thiết của kiểm thử tự động. Kiểm thử tự động sẽ thực
hiện tự động các ca kiểm thử theo một kịch bản cho sẵn hoặc tự nó sinh ra. Những lợi
ích của các công cụ kiểm thử tự động mang lại là rất lớn tuy nhiên các tài liệu về kiểm
thử tự động được viết bằng tiếng Việt lại còn rất hạn chế. Xuất phát từ thực tế đó và
được sự gợi ý của giảng viên hướng dẫn, tôi lựa chọn đề tài luận văn “Nghiên cứu và
xây dựng công cụ kiểm thử ứng dụng Web” với mong muốn mang lại cho người đọc
một tài liệu hỗ trợ hữu ích trước khi quyết định sử dụng kiểm thử tự động cho ứng
dụng Web của mình.
Luận văn đƣợc cấu trúc thành bốn chƣơng:

hạn chế và hướng phát triển trong thời gian tới của luận văn. 11
phần mềm thực hiện một cách không xác định.
 Thất bại: xảy ra khi chức năng của phần mềm không thực hiện đúng như mong
đợi.
 Khuyết thiếu: là sự thiếu sót các trường hợp có thể xảy ra khi phần mềm hoạt
động, có thể do đặc tả thiếu hoặc thiếu sót khi lập trình.
12 Kiểm thử phần mềm có thể chia làm hai nhóm kỹ thuật chính là kỹ thuật kiểm
thử tĩnh và kỹ thuật kiểm thử động. Kiểm thử tĩnh là kỹ thuật không yêu cầu phải biên
dịch và chạy mã nguồn chương trình để thực hiện việc kiểm thử phần mềm. Kỹ thuật
này kiểm thử chương trình bằng cách kiểm tra cú pháp, cấu trúc mã nguồn của chương
trình hoặc rà soát các tài liệu liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi.
Trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử tĩnh
được sử dụng trong quy trình kiểm chứng. Kiểm thử động là kỹ thuật chỉ được thực
hiện khi mã nguồn chương trình phần mềm được biên dịch và chạy. Mục đích chính
của kỹ thuật kiểm thử động là thẩm định xem chương trình phần mềm có hoạt động
đúng và đầy đủ các chức năng như những mong muốn của người sử dụng hay không,
do đó trong quy trình kiểm chứng và thẩm định chất lượng phần mềm thì kiểm thử
động được sử dụng trong quy trình thẩm định.

1.1.2. Mức kiểm thử
Một sản phẩm phần mềm từ khi bắt đầu phát triển đến khi hoàn thành và đưa đến tay
người dùng cuối phải trải qua bốn mức kiểm thử đó là: Kiểm thử mức đơn vị, mức tích
hợp, mức hệ thống và mức chấp nhận.
Kiểm thử mức đơn vị
Kiểm thử mức đơn vị hay còn gọi là kiểm thử thành phần (module testing) là mức thấp
nhất trong các mức độ kiểm thử. Đơn vị ở đây có thể là một chức năng cụ thể, một
hàm (function), một lớp trong lập trình hướng đối tượng hoặc một thành phần nhỏ đã
hoàn thiện trong chương trình. Thường thì các lập trình viên sẽ đảm nhận kiểm thử ở

double x1, x2;
double delta = TinhDelta(a, b, c);
if(delta < 0)
Console.WriteLine(“Phuong trinh vo nghiem”);
else if (delta == 0)
{
x1 = -b / 2 * a;
Console.WriteLine(“Phuong trinh co 1 nghiem duy nhat x = ” + x1);
}
else
{
x1 = (-b + Math.Sqrt(delta)) / 2 * a;
x2 = (-b - Math.Sqrt(delta)) / 2 * a;
Console.WriteLine(“Phuong trinh co 2 nghiem x1=”+ x1 +“,x2= ”
+ x2);
}
}

public void Driver()
{
double a = 2, b = 9, c = 4;
TinhNghiemPTBac2(a, b, c);
}

public double TinhDelta(double a, double b, double c)
{
return b * b – 4 * a * c;
}
Hình 1.1. Mã nguồn minh họa Driver và Stub


không như đơn vị sử dụng mong đợi.
 Thay đổi tính năng: một đơn vị được sửa đổi nhưng các đơn vị sử dụng nó
không được điều chỉnh theo nên chức năng của chương trình bị ảnh hưởng.
 Sử dụng giao diện không đúng: đơn vị sử dụng không đúng giao diện của đơn
vị được gọi, có thể là do truyền sai kiểu dữ liệu.
 Hiểu giao diện không đầy đủ: xảy ra khi đơn vị gọi hiểu nhầm hoặc không đầy
đủ giao diện của đơn vị được gọi. Có thể ví dụ như trong lập trình hướng đối
tượng, bằng việc nạp chồng phương thức, có thể có nhiều phương thức trùng
tên nhưng khác nhau tham số đầu vào, việc truyền nhầm tham số có thể dẫn tới
việc gọi sai phương thức dẫn tới sai kết quả trả về.
 Không xử lý lỗi trả về: một đơn vị được gọi có thể trả về một mã lỗi nhưng đơn
vị gọi lại không kiểm tra lỗi mà coi đó là kết quả hoặc không biết sửa.
15  Lỗi xung đột tài nguyên: các đơn vị dùng chung bộ nhớ có thể bị xung đột khi
sử dụng. Ví dụ: một đơn vị vừa ghi dữ liệu vào một biến toàn cục thì đơn vị
khác lại ghi đè dữ liệu vào biến đó.
 Các vấn đề về phi chức năng: ví dụ với các hệ thống thời gian thực, việc xử lý
chậm có thể gây mất đồng bộ giữa các đơn vị.
Một số chiến lược được áp dụng trong kiểm thử mức tích hợp:
 Tích hợp từng bước (incremental).
 Tích hợp từ trên xuống (top - down).
 Tích hợp từ dưới lên (bottom - up).
 Tích hợp kẹp (sandwich).
 Tích hợp tất cả cùng một thời điểm (big bang).
Kiểm thử mức hệ thống
Kiểm thử mức hệ thống có nhiệm vụ kiểm tra xem hệ thống hoặc chương trình sau khi
đã tích hợp đầy đủ các đơn vị có hoạt động đúng với tài liệu đặc tả yêu cầu hay không.
Do hầu hết các lỗi, thiếu sót đã được kiểm tra và sửa chữa ở mức kiểm thử đơn vị và

bên trong không.
 Kiểm thử khả năng phục hồi (Recovery test): kiểm tra xem chương trình có thể
khôi phục hoạt động ổn định, khôi phục dữ liệu nếu bị tấn công hoặc mất dữ
liệu hay không.

Kiểm thử mức chấp nhận
Ở mức kiểm thử mức chấp nhận, người thực hiện việc kiểm tra chương trình chính là
những người sẽ sử dụng trực tiếp chương trình phần mềm sau này hay còn gọi là người
dùng cuối. Người dùng cuối là những người hiểu hơn ai hết cái họ muốn ở sản phẩm
như phần mềm có đáp ứng đầy đủ những chức năng mà họ cần hoặc có đúng với quy
trình công việc mà họ vẫn làm hay không? giao diện chương trình có dễ sử dụng hay
không? các thao tác sử dụng có quá phức tạp hay không? đây là những vấn đề mà các
kiểm thử viên hay người phát triển không thể kiểm tra được chính xác. Đây cũng là
mức quyết định xem sản phẩm đã thực sự hoàn thiện để chuyển tới tay người dùng hay
chưa. Các thiếu sót, lỗi sẽ được ghi lại trong quá trình kiểm tra và chuyển tới đội ngũ
phát triển để sửa chữa.
Kiểm thử mức chấp nhận giúp đảm bảo chương trình phần mềm có thể làm hài
lòng người sử dụng đem lại sự thống nhất về kỹ thuật giữa đội ngũ phát triển và khách
hàng. Tuy nhiên kiểm thử mức chấp nhận cũng có một số nhược điểm như tốn kém chi
phí sửa chữa nếu phát sinh lỗi, thiếu sót, thay đổi. Ngoài ra, người dùng thường sử
dụng chương trình một cách cẩn thận, không cố tình tạo ra các vi phạm (nhập sai kiểu
dữ liệu, dùng sai quy cách) khiến lỗi chưa thể bị phát hiện trong quá trình kiểm tra.
Kiểm thử hồi quy
Trong quá trình phát triển phần mềm, nếu có một sự thay đổi xảy ra như thay đổi yêu
cầu chức năng, quy trình xử lý thì đòi hỏi cần phải thực hiện việc kiểm tra lại để đảm
bảo rằng chương trình phần mềm vẫn hoạt động tốt, không phát sinh ra lỗi, kiểm thử
hồi quy sẽ thực hiện việc này. Kiểm thử hồi quy không phải là một mức kiểm thử
giống như các mức đã nêu ở trên, nó có thể thực hiện lại các mức kiểm thử và sử dụng
lại các ca kiểm thử đã được xây dựng. Hình 1.2 minh họa việc thực hiện kiểm thử ở
các mức lần lượt từ kiểm thử mức đơn vị đến kiểm thử mức chấp nhận và áp dụng

Phương pháp kiểm thử hộp đen có ưu điểm là không yêu cầu người thực việc
kiểm thử phải biết lập trình hay tham gia vào quá trình viết mã nguồn cho chương
trình, thậm chí người dùng cuối cũng có thể tham gia kiểm thử. Phương pháp cũng
không phụ thuộc vào cài đặt thuật toán, nếu có thay đổi trong mã nguồn vẫn có thể sử
dụng lại ca kiểm thử cũ. Phương pháp này cũng giúp loại bỏ những nhầm lẫn trong
việc thống nhất kỹ thuật, chức năng mà chương trình cung cấp giữa người dùng cuối
và đội ngũ thực hiện do đưa ra chương trình trực quan và rất hiệu quả khi kiểm thử
những chương trình lớn. Tuy nhiên nhược điểm của phương pháp kiểm thử hộp đen là
Kiểm thử mức
đơn vị
Kiểm thử mức
tích hợp
Kiểm thử mức
hệ thống
Kiểm thử mức
chấp nhận
Kiểm thử hồi quy
18 việc kiểm thử đầy đủ các trường hợp dữ liệu vào có thể có là không khả thi. Phương
cũng chỉ phát hiện ra các lỗi có thể quan sát được và nếu có lỗi thì không chỉ ra được
nguyên nhân, vị trí gây ra lỗi. Ngoài ra nếu không có tài liệu đặc tả chính xác thì rất
khó để thiết kế ca kiểm thử chính xác.
Kiểm thử hộp trắng
Kiểm thử hộp trắng là phương pháp kiểm thử dựa vào các cấu trúc, thuật toán bên
trong của chương trình để xác định chương trình có thực hiện đúng không. Để thực
hiện kiểm thử hộp trắng đòi hỏi người thực hiện phải có kiến thức về lập trình và kiến
trúc phần mềm đang được kiểm thử để có thể truy cập vào mã nguồn, cấu trúc thuật
toán. Một số tên gọi khác của kiểm thử hộp trắng là kiểm thử hộp thủy tinh, hộp trong

19 kiểm thử phức tạp thì không thể sử dụng kiểm thử tự động mà vẫn cần phải thực hiện
kiểm thử thủ công.

1.1.4. Ứng dụng Web
Khái niệm ứng dụng Web
Ứng dụng Web là một phần mềm mà người dùng có thể tương tác thông qua trình
duyệt Web. Ứng dụng Web không đòi hỏi người dùng phải cài đặt trước khi sử dụng
và có thể tương tác trên bất kỳ hệ điều hành hoặc thiết bị nào miễn là môi trường đó có
thể cài đặt và sử dụng một trình duyệt Web đủ tiêu chuẩn. Ứng dụng Web được cài đặt
trên máy chủ và giao tiếp với máy khách thông qua các bản tin HTTP, HTTPS.
Sự khác biệt giữa Ứng dụng Web và Website
Về mặt hoạt động thì cả ứng dụng Web lẫn Website đều là các ứng dụng phần mềm
được người dùng tương tác thông qua trình duyệt Web chính vì thế nên khái niệm ứng
dụng Web và Website thường quy về chung làm một. Tuy nhiên Website thiên về
khuynh hướng chỉ truyền tải thông tin đến người dùng còn ứng dụng Web thiên về
khuynh hướng tương tác qua lại giữa người dùng và ứng dụng. Có thể ví dụ đơn giản
về Website như sau: Website tin tức cung cấp cho người dùng các thông tin nhưng họ
chỉ có thể đọc chứ không thể chỉnh sửa. Minh họa về ứng dụng Web có thể nói đến
ứng dụng Google Docs cho phép người dùng tạo văn bản, chỉnh sửa và quản lý đem lại
sự tương tác như một phần mềm thực sự trên máy tính.
Sự khác biệt giữa mô hình máy khách – máy chủ (C-S) truyền thống và Web.
Ở phía máy khách thì mô hình C-S truyền thống đòi hỏi với mỗi hệ điều hành khác
nhau thì phải thiết kế ứng dụng phù hợp với hệ điều hành đó và để sử dụng ứng dụng
thì cần phải cài đặt, còn với mô hình Web thì do được sử dụng thông qua các trình
duyệt Web nên chỉ cần được thiết kế cho phù hợp chuẩn chung (HTML, các thành
phần khác như CSS, ngôn ngữ lập trình phía máy khách) mà các nhà cung cấp trình
duyệt Web đã thỏa thuận.

cách kiểm tra cú pháp, cấu trúc mã nguồn của chương trình hoặc rà soát các tài liệu
liên quan như tài liệu đặc tả, tài liệu thiết kế để tìm ra lỗi. Trong quy trình kiểm chứng
và thẩm định chất lượng phần mềm thì kiểm thử tĩnh được sử dụng trong quy trình
kiểm chứng.
Mục đích chính của kỹ thuật kiểm thử tĩnh là giúp phát hiện, lường trước lỗi
cũng như các thiếu sót, nhầm lẫn có thể có trong quá trình phát triển phần mềm một
cách sớm nhất. Điều này sẽ giúp giảm chi phí, thời gian và nhân lực để sửa chữa, khắc
phục lỗi nếu xảy ra. Việc thực hiện kiểm thử tĩnh có thể bằng tay (rà soát) hoặc tự
động bằng máy (phân tích tĩnh).
Kỹ thuật kiểm thử tĩnh đòi hỏi người thực hiện phải có kiến thức và kinh
nghiệm tốt. Ngoải ra với những chương trình có độ phức tạp cao thì để thực hiện kỹ
thuật này sẽ mất rất nhiều thời gian.

1.2.1. Rà soát
Các kỹ thuật rà soát có thể chia ra làm các bước sau:
 Rà soát không chính thức (informal review): thực hiện bằng cách đọc các tài
liệu liên quan và đưa ra các ghi chú, chưa cần phải phát hiện lỗi.
 Phản biện chéo (peer review): việc rà soát được thực hiện bởi đội ngũ lập trình
dự án phần mềm, mọi người cùng tham gia thảo luận để đưa ra thống nhất
chung về vấn đề kỹ thuật cho phù hợp với dự án. Cả đội sẽ cùng nhau rà soát
mã nguồn, tìm lỗi và đưa ra cách giải quyết.
 Thông qua (walkthrough): người viết các mã nguồn, tài liệu đặc tả, thiết kế, sẽ
giải thích từng bước trước toàn đội dự án nhằm đạt được sự hiểu rõ, đồng thuận,
sau đó nhận các phản hồi góp ý của thành viên trong đội dự án và đưa ra thay
đổi hợp lý.
21  Thanh tra (inspection): các thành viên quan trọng trong đội dự án sẽ tham gia
họp, một danh sách các vấn đề cần rà soát sẽ được lập và đưa ra để phát hiện lỗi

 Loại 1: Gán giá trị rồi lại gán tiếp giá trị. Xem xét hai câu lệnh ở hình 1.3, có
hai hàm f1 và f2 với 2 tham số lần lượt được truyền vào là y1 và y2. Có thể giải
thích vấn đề này theo bốn tình huống sau:
o Câu lệnh thứ nhất dư thừa khi câu lệnh thứ hai được thực hiện.
o Câu lệnh thứ nhất bị nhầm lẫn khi lập trình, câu lệnh đúng có thể là z =
f1(y1).
o Câu lệnh thứ hai bị nhầm lẫn, câu lệnh đúng có thể là
22 o z = f2(y2).
o Giữa hai câu lệnh bị thiếu một câu lệnh khác, có thể là câu lệnh z =
f3(x).

x = f1(y1);
x = f2(y2)

Hình 1.3. Các câu lệnh tuần tự có bất thường loại 1.

Chỉ người lập trình đoạn mã nguồn này mới có thể giải thích rõ được vấn đề
thuộc tình huống nào trong bốn tình huống đã nêu. Những vấn đề bất thường như này
rất hay xảy ra nên cần phân tích mã nguồn để phát hiện.
 Loại 2: Chưa gán giá trị nhưng được tham chiếu. Xem xét câu lệnh ở hình 1.4,
biến y2 chưa được gán giá trị đã được tham chiếu để tính toán. Có thể giải thích
vấn đề này theo hai tình huống sau:
o Biến y2 bị quên gán giá trị.
o Có sự nhầm lẫn khi tham chiếu biến y2, có thể biến đáng lẽ được tham
chiếu là biến y3 đã được gán ở bước nào đó phía trên câu lệnh tính toán
này.


 D (Defined): trạng thái đã được gán giá trị nhưng chưa được tham chiếu.
 R (Referenced): trạng thái đã được gán giá trị và đã được tham chiếu.
 A (Abnormal): trạng thái bất thường.
Các hành động gồm:
 d: gán giá trị.
 u: chưa gán giá trị hoặc khai báo lại không gán giá trị.
 r: tham chiếu.
Có thể diễn giải sơ đồ trong hình 1.5 như sau, một biến được khai báo nhưng
chưa được gán giá trị sẽ ở trạng thái U, nếu biến này được tham chiếu (hành động r)
thì biến sẽ ở trạng thái A, tức là xảy ra bất thường. Một biến ở trạng thái D, tức là đã
được gán giá trị, nếu xảy ra hành động d thì cũng sẽ vào trạng thái A.
Việc sử dụng kỹ thuật kiểm thử dòng dữ liệu tĩnh rất hiệu quả trong việc phát
hiện ra các bất thường về biến tuy nhiên vẫn cần kết hợp với kỹ thuật kiểm thử dòng
dữ liệu động để có thể phát hiện thêm các lỗi tiềm ẩn của chương trình.

1.3. Kỹ thuật kiểm thử động
Kiểm thử động là kỹ thuật chỉ được thực hiện khi mã nguồn chương trình phần mềm
được biên dịch và chạy. Mục đích chính của kỹ thuật kiểm thử động là thẩm định xem
chương trình phần mềm có hoạt động đúng và đầy đủ các chức năng như những mong
muốn của người sử dụng hay không, do đó trong quy trình kiểm chứng và thẩm định
chất lượng phần mềm thì kiểm thử động được sử dụng trong quy trình thẩm định.
Kỹ thuật kiểm thử động chia làm hai loại là kiểm thử chức năng và kiểm thử
phi chức năng. Kiểm thử chức năng được thực hiện bằng cách sử dụng trực tiếp chức
năng cần được kiểm thử, sau đó đưa dữ liệu đầu vào và nhận được dữ liệu đầu ra. Dữ
liệu đầu ra này sẽ được so sánh với dữ liệu đầu ra được ước lượng trước đó dựa theo
dữ liệu đầu vào và tài liệu đặc tả để tìm ra lỗi hoặc thiếu sót. Kiểm thử phi chức năng
bao gồm nhiều loại như kiểm thử hiệu năng hoạt động, độ tin cậy, khả năng bảo mật,
khả năng tương thích, tính sẵn sàng.
Kỹ thuật kiểm thử động có ưu điểm là thời gian và chi phí thực hiện thấp, có thể
thực hiện được ở tất cả các mức kiểm thử. Tuy nhiên nhược điểm của kỹ thuật là đòi