đồ án tốt nghiệp nghiên cứu các giải pháp kiểm thử ứng dụng trên nền web

PHẠM THỊ NGÀ

NGHIÊN CỨU CÁC GIẢI PHÁP KIỂM THỬ
ỨNG DỤNG TRÊN NỀN WEB

Chuyên ngành: Tin học ứng dụng

ĐỒ ÁN TỐT NGHIỆP ĐẠI HỌC

Hà Nội - Năm 2015


Giảng viên hướng dẫn: Đinh Tuấn Long
Sinh viên thực hiện:Phạm Thị Ngà :11B4

Chuyên ngành: Công nghệ thông tin

MÔN HỌC: ĐỒ ÁN TỐT NGHIỆP

Hà Nội - Năm 2015


LỜI NÓI ĐẦU
Em xin chân thành cảm ơn ban chủ nhiệm khoa Công nghệ thông tin, các
thầy cô giáo, gia đình và bạn bè đã động viên giúp đỡ em rất nhiều trong quá
trình làm đồ án này. Đặc biệt em xin bày tỏ lòng cảm ơn sâu sắc tới thầy giáo
hướng dẫn TS. Đinh Tuấn Long về sự tận tình, tận tâm hướng dẫn em từ những ý
tưởng đầu tiên cho đền lúc hoàn thành đồ án tốt nghiệp.
Em xin bày tỏ lòng biết ơn tới gia đình thân yêu, những người bạn thân đã
luôn tin tưởng, quan tâm, động viên, giúp đỡ em trong thời gian qua.
Em rất mong nhận được sự đánh giá, bổ sung và những lời chỉ bảo của các

thầy cô đề em có thể tiếp tục nghiên cứu kĩ hơn về lĩnh vực này.
Em xin chân thành cảm ơn!
Hà Nội, ngày 28 tháng 1 năm 2015
Nhóm sinh viên: Phạm Thị Ngà


MỤC LỤC

LỜI NÓI ĐẦU.....................................................................................................................
TÓM TẮT ĐỒ ÁN..............................................................................................................
MỞ ĐẦU.............................................................................................................................
Lý do chọn đề tài...........................................................................................................9
Mục đích nghiên cứu.....................................................................................................9
Phạm vi nghiên cứu.....................................................................................................10
Bố cục đề tài................................................................................................................10
CHƯƠNG 1
CƠ SỞ LÝ THUYẾT
1.1.

Một số định nghĩa về quá trình kiểm thử....................................................1

1.2.

Một số định nghĩa về quá trình kiểm thử phần mềm...................................2

1.3.

Mục tiêu của kiểm thử.................................................................................2

1.4.

Vai trò của kiểm thử....................................................................................2
CHƯƠNG 2:

NHỮNG VẤN ĐỀ LIÊN QUAN TỚI QUÁ TRÌNH KIỂM THỬ PHẦN MỀM
2.1.

Vòng đời kiểm thử..............................................................................................3

2.2.

Tiến trình test và các dạng test trong các giai đoạn............................................5

2.3.

Những thành phần của một kế hoạch kiểm thử..................................................9
CHƯƠNG 3
PHƯƠNG PHÁP VÀ CÁC LOẠI KIỂM THỬ

3.1.

Phương pháp kiểm thử......................................................................................10

3.1.1.

Khái niệm..................................................................................................10

3.1.2.

Các phương pháp.......................................................................................10

3.2.

Loại kiểm thử....................................................................................................13

3.3.

Tìm hiểu về công cụ kiểm thử hiệu năng ( webserver tress tool).....................16

3.3.1.

Một số công cụ kiểm thử hiệu năng..........................................................16

3.3.2.

Tìm hiểu về công cụ kiểm thử hiệu năng Webserver stress tool...............26

3.3.3.

Cài đặt........................................................................................................27

3.3.4.

Đối tượng thực nghiệm..............................................................................30

3.3.5.

Bảng lỗi.....................................................................................................38

CHƯƠNG 442
TRIỂN KHAI THỰC NGHIỆM VỚI KIỂM THỬ
4.1.

Đối tượng kiểm thử...........................................................................................42

4.2.

Tìm hiểu về ERP...............................................................................................43

4.3.

Mục tiêu............................................................................................................44

4.4.

Các loại report trong dự án Team link..............................................................44

4.5.

Thực nghiệm.....................................................................................................46

4.5.1.

Testcase......................................................................................................47

4.5.2.

Cách viết test case theo hàng ngang..........................................................48

4.5.3.

Cách viết test case theo hàng dọc..............................................................54

TÀI LIỆU THAM KHẢO...............................................................................................55


DANH MỤC HÌNH
Hình 1.1: Vòng đời kiểm thử.............................................................................................3
Hình 1.1: Minh họa 1 kế hoạch kiểm thử.........................................................................9
Hình 3.1 : Thực hiện cài đặt “ Bước 2”...........................................................................27
Hình 3.2 : Thực hiện cài đặt “ Bước 3”...........................................................................28
Hình 3.3 : Thực hiện cài đặt “ Bước 4”...........................................................................28
Hình 3.4 : Thực hiện cài đặt “ Bước 5”...........................................................................29
Hình 3.5 : Thực hiện cài đặt “ Bước 6”...........................................................................29
Hình 3.6 : Thực hiện cài đặt “ Bước 7”..........................................................................30
Hình 3.7 : Đối tượng thực nghiệm...................................................................................30
Hình 3.8 : Nhập dữ liệu cho TestType.............................................................................31
Hình 3.9 : Màn hình URLs..............................................................................................32
Hình 3.10 : Chạy Start test..............................................................................................33
Hình 3.11: Quá trình chạy...............................................................................................33
Hình 3.12: Quá trình chạy...............................................................................................34
Hình 3.13: Đưa kết quả test.............................................................................................34
Hình 3.14: màn hình View logfie Result.........................................................................35
Hình 3.15: màn hình View logfie Result.........................................................................35
Hình 3.16: màn hình View logfie Result.........................................................................36
Hình 3.17: màn hình View logfie Result.........................................................................36
Hình 3.18: màn hình View logfie Resul..........................................................................37
Hình 3.19: màn hình View logfie Resul..........................................................................37
Hình 4.1: Giao diện hệ thống “ website bán hàng giày, quần áo thể thao”....................42

Hình 4.2 Mô hình ERP....................................................................................................43
Hình 4.3: Báo cáo PO......................................................................................................44
Hình 4.4: Báo cáo cust PO..............................................................................................45
Hình 4.5: Báo cáo SO......................................................................................................45
Hình 4.6: Đối tượng Demo PO........................................................................................46
Hình 4.7: Đối tượng báo cáo Demo................................................................................47
Hình 4.7 Cách viết test case theo hàng ngang.................................................................53
Hình 4.8 Cách viết test case theo hàng dọc.....................................................................54


DANH MỤC BẢNG BIỂU
Bảng 3.1: Bảng báo lỗi (html erro)..................................................................................41


TÓM TẮT ĐỒ ÁN

Với đề tài “ Nghiên cứu các giải phải kiểm thử ứng dụng trên nền web”
này, em xây dựng dựa trên việc tìm hiểu lí thuyết và thực tế. Cụ thể là gồm hai
phần chính đó là: lý thuyết nằm trong chương 2,3 và nửa chương 4, phần đề mô
nằm trong cuối chương 4 và chương 5. Đăc biêt dự án em thực hiện đề mô là 1
dự án đang được phát triển tại Công Ty Hanel Soft Ware.


MỞ ĐẦU
Lý do chọn đề tài
Website ra đời đã mở ra hướng mới cho việc phát triển các ứng dụng trên
internet.Website kết hợp sử dụng nhiều công nghệ khác nhau cho phép hai ứng
dụng cùng ngôn ngữ, độc lập hệ điều hành trao đổi được với nhau thông quá
trượng mạng.Điểm khác biệt lớn nhất và đặc trưng nhất của một trang web là có
thể liên kết với các trang web khác, và các trang web khác ấy lại liên kết với rất nhiều

các trang nữa tạo thành một mạng lưới liên kết khổng lồ trên toàn thế giới.Tuy
nhiên, nó mang đến cho các nhà kiểm thử và phát triển phần mềm thách thức.
Sự phức tạp và tính linh hoạt, phụ thuộc các ứng dụng vào một dịch vụ,
thiếu thử nghiệm là một trong những thách thức kiểm thử mà các nhà phát triển
website phải đối mặt. Vì vậy, nhu cầu kiểm thử web ngày càng tăng lên trở thành
thiết yếu đối với dự án phần mềm.
Các lỗi là nguyên nhân chính của năng suất thấy và làkết quả của những
sai sót trong suốt vòng đời phát triển của phần mềm. Những lỗi này bao gồm mọi lỗi
thực thi, các lỗi bảo mật, thực hiện sai sót chức năng, lỗi sụp đổ hệ thống….. càng
sớm phát hiện vấn đề, càng dễ để sửa lỗi và giảm thời gian chi phí cho phần mềm.
Nói chung các nhà phát triên, nghiên cứu, những chuyên gia dựa vào thực
nghiệm kiểm tra tính đảm bảo các chức năng dịch vụ, độ tin cậy của website,
cung cấp các giải pháp kiểm thử phần mềm. Ngoài ra, Khả năng tương tác, an
ninh và các vấn đề liêm quan có ảnh hưởng tới nhà sản xuất và người sử dụng.
Bên cạnh đó , trong thời gian học tập tại khoa Công Nghệ Thông Tin em
đã được học và tìm hiểu, tiếp xúc một phần nhỏ cảu kiểm thử phần mềm.
Với những lí do đó, được sự hướng dẫn của thầy giáo TS.Đinh Tuấn Long
em đã chọn đề tài:” Nghiên cứu các giải pháp kiểm thử ứng dụng trên nền web”
làm hướng nghiên cứu cho đồ án tốt nghiệp của mình.
Mục đích nghiên cứu
Mục đích cảu đề tài là tìm hiểu những kiến thức tổng quan nhất về kiểm
thử và cách thiết kế các trường hợp kiểm thử( Test Case) trong kiểm thử website.
Và tìm hiểu những công cụ kiểm thử tự độngm giúp cho việc kiểm thử nhanh


chóng và hiệu quả hơn. Việc thực hiện đề tài giúp em tìm hiểu sâu hơn về lĩnh
vực rất hấp dẫn này, vận dụng được các kiến thức đã học để có thể thiết kế được
các trường hợp kiểm thử một cách có hiệu quả và áp dụng vào bài toán thực
tế.Hơn thế nữa, thực hiện đề tài này sẽ giúp em có những kiếm thức thực tế bổ
ích để phục vụ cho công việc trong tương lai.

Phạm vi nghiên cứu
Trong đề tài này em sẽ nghiên cứu về:
-

Lý thuyết kiểm thử
Tìm hiểu về công cụ kiểm thử hiệu năng web server streess tool
Thực hiện kiểm thử

Bố cục đề tài
Đề tài “ Nghiên cứu các giải pháp kiểm thử ứng dụng trên nền web” gồm:
Chương 1: Cơ sở lí thuyết
1.1. Tổng quan về quá trình kiểm thử
1.2.Một số định nghĩa về quá trình kiểm thử phần mềm
1.3.Mô hình khái niệm của quá trình kiểm thử
1.4.Mục tiêu của kiểm thử
1.5.Vai trò của kiểm thử
Chương 2: Những vấn đề liên quan tới quá trình kiểm thử phần mềm
2.1.Vòng đời kiểm thử
2.2. Tiến trình test và các dạng test trong các giai đoạn
2.3.Những thành phần của một kế hoạch kiểm thử
2.4.Các chỉ tiêu đánh giá kiểm thử
Chương 3: Phương pháp và các loại kiểm thử
3.1.Phương pháp kiểm thử
3.2.Các loại kiểm thử
3.3.Tìm hiểu về công cụ kiểm thử hiệu năng ( web server stress tool)
Chương 4: Triển khai thực nghiệm việc kiểm thử


1

CHƯƠNG 1
CƠ SỞ LÝ THUYẾT
1.1.

Một số định nghĩa về quá trình kiểm thử
Kiểm thử là việc kiểm tra kết quả thực hiện của chương trình máy tính

xem có đúng với các mục tiêu đã đặt ra với nó không thông qua việc thực hiện ở
một số mẫu thử.Kiểm thử phần mềm bao gồm quá trình kiểm tra và kiểm định để
đảm bảo phần mềm đáp ứng nhu cầu người dùng, phần mềm chạy đúng chức
năng.Kiểm thử phần mềm có thể được thực hiện ở bất kỳ giai đoạn nào trong
phát triển phần mềm, phổ biến nhất là kiểm thử sau khi yêu cầu người dùng hoàn
thiện hoặc phần mềm vừa xong giai đoạn phát triển. Tuy nhiên, trong quy trình
phát triển phần mềm theo kiểu Agile thì kiểm thử phần mềm là quy trình đi cùng
với việc phát triển phần mềm.Kiểm thử là việc tìm ra những lỗi trong bản thân
phần mềm, việc kiểm thử này trong phần mềm sẽ biểu thị ra những thiếu sót mà
ta có thể nhận thấy trong hành vi của phần mềm, và tìm ra những phần không
tuân theo quy định và đi lệch ra khỏi những yêu cầu của phần mềm.
Theo một số nhà nghiên cứu thì kiểm thử phần mềm được định nghĩa như sau:
 Dijkstra: Kiểm thử sẽ hiện thị những lỗi hiện có, nhưng không hiển thị
lỗi chưa thấy.
 Beizer
Định luật 1: Mọi phương pháp bạn sử dụng để ngăn ngừa hoặc tìm thấy
lỗi bỏ đi một phần lỗi rắc rối, cái mà những phương thức cần.
Định luật 2: Phần mềm phức tạp lớn hơn những giới hạn khả năng quản
lý. Những người kiểm thử không tốt hơn trong thiết kế lỗiso với những lập trình
viên kiểm thử trong thiết kế mã.
 IEEE: Kiểm thử là tiến trình vận hành hệ thống hoặc thành phần dưới
những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra
đánh giá về hệ thống hoặc thành phần đó.

 Myers: Kiểm thử là tiến trình thực thi chương trình với mục đích tìm
thấy lỗi.(The art of software testing)


2

Giữa kiểm thử và gỡ rối có sự khác biệt: Kiểm thử nhằm phát hiện ra lỗi
trong khi đó gỡ rối là việc xác định bản chất lỗi và định lỗi trong chương trình,
sau đó tiến hành sữa lỗi.
1.2.

Một số định nghĩa về quá trình kiểm thử phần mềm
Một sai sót(Error): Là một sự nhầm lẫn hay một sự hiểu sai trong quá

trình phát triển phần mềm của người phát triển.Một lỗi(fault, defect): Xuất hiện
trong phần mềm như là kết qủa của một sai sót.Một hỏng hóc(failure):là kết quả
của một lỗi xuất hiện làm cho chương trình không hoạt động được hoặc hoạt
động được nhưng không cho kết quả như mong muốn.
Sai sót

Lỗi

Hỏng hóc

Dữ liệu thử(test data): Dữ liệu vào cần cung cấp cho phần mềm khi thực
thi.Kịch bản kiểm thử(test scenario): Các bước thực hiện khi kiểm thử.Phán xét
kiểm thử(test oracle): Là việc đánh giá của kiểm thử, có hai cách đánh giá đó là
bằng chương trình(tự động), bằng con người(thủ công).Kiểm thử viên(tester):
Người thực hiện kiểm thử.Ca kiểm thử(test case):Tập dữ liệu kiểm thử, điều kiện
kiểm thử, để đưa ra kết quả mong đợi.

1.3.

Mục tiêu của kiểm thử
Bằng việc kiểm thử sẽ tìm ra được những lỗi trong phần mềm

(Myers,1979)và thiết lập chất lượng của phần mềm(Hetzel,1988).Việc kiểm thử
thành công khi bạn tìm được ít nhất một lỗi, và đưa ra sự đánh giá với độ tin cậy
lớn.Đáp ứng được các yêu cầu công việc và kỹ thuật đã được qui định trong thiết
kế và trong lúc phát triển, làm việc như mong đợi và có thể thực thi với các đặc
tính giống nhau.
1.4.
-

Vai trò của kiểm thử

Testing để tìm ra lỗi, ghi nhận các thông tin về lỗi, nhưng không sữa lỗi.


3

-

Testing giúp kiểm định phần mềm, đảm bảo rằng phần mềm “đủ tốt” với độ
rủi ro “thấp nhất” có thể.


4

CHƯƠNG 2:
NHỮNG VẤN ĐỀ LIÊN QUAN TỚI QUÁ TRÌNH KIỂM THỬ PHẦN

MỀM
2.
2.1.

Vòng đời kiểm thử
Vòng đời của kiểm thử bắt đầu từ việc kiểm điểm yêu câu, lập kế hoạch

kiểm thử. Sau đó là ghi ra các ý tưởng các trường hợp kiểm thử. Từ các trường
hợp kiểm thử này đưa ra tất cả các trường hợp kiểm thử và các kịch bản kiểm
thử.Sử dụng các thủ tục hay kịch bản kiểm thử này, người kiểm thử có thể phát
họa toàn bộ kiểm thử hệ thống hay kiểm thử tích hợp. Kết quả kiểm thử sẽ được
đánh giá bởi các tiêu chí kiểm thử đặt ra ban đầu. Mô hình kiểm thử là một dãy
các kế hoạch, các trường hợp kiểm thử và các thủ tục kiểm thử. Trong tiến trình
bảo trì và nâng cấp dự án, thì kiểm thử đóng vai trò quan trọng. Cụ thể là:

Hình 1.1: Vòng đời kiểm thử
Kiểm điểm yêu cầu: Người kiểm thử kiểm điểm yêu cầu phần mềm để dùng
chúng và chắc rằng chúng là kiểm thử được. (Nếu chúng không kiểm thử được
thì yêu cầu là mơ hồ và cần được xem lại); đây là một hoạt động quan trọng trong


5

nguyên lí kĩ nghệ phần mềm chủ trương người kiểm thử phải tham gia sớm trong
dự án phần mềm và làm việc chặt chẽ với các kĩ sư yêu cầu để chắc rằng các yêu
cầu phần mềm là tốt và đầy đủ trước khi dự án bắt đầu.
Lập kế hoạch kiểm thử: Người kiểm thử biết cái gì cần được kiểm thử, và lập
kế hoạch các hoạt động kiểm thử của họ như: Chuẩn bị chiến lược kiểm thử, kế
hoạch kiểm thử, lịch biểu kiểm thử và ước lượng thời gian kiểm thử. Bởi vì
người kiểm thử tham gia sớm vào trong dự án, họ có thể làm việc chặt chẽ với

kiến trúc sư phần mềm và người thiết kế phần mềm trong việc xác định mọi cấu
phần của sản phẩm phần mềm, cả yêu cầu chức năng và phichức năng.Người
kiểm thử cũng giúp nhận diện giao diện giữa phần cứng và phần mềm cũng như
lập kế hoạch cách kiểm thử các yêu cầu này.
-

Để thiết kế 1 kế hoạch kiểm thử thường dùng Msproject

Cách tạo test plan bằng Msproject : Muốn lên được test plan tốt, người lên kế
hoạch cần phải dựa vào một số yếu tố sau:’’ master plan kế hoạch tổng thể của
dự án Code Plan, kế hoạch coding sản phẩm, nhân sự trong nhóm, trình độ và
năng lực của các thành viên trong nhóm,chính sách mục tiêu chất lương của
công ty , các yêu cầu test của khách hàng hoặc hệ thống,khách hàng cần test như
thế nào, đảm bảo dự án hoạt động tốt trên các môi trường gì, có cần dùng công
cụ test hiệu năng, hiệu suất hay không?
Ví dụ: Tạo 1 test plan bao gồm các nội dung công việc của tester để thực hiện
test 1 website đơn giản.
o
o
o


Yêu cầu: Hoàn thành test trong vòng 1 tháng
Test trên các môi trường : IE7, 8, 9, FF3.6.8, chrome
Thực hiện test hiệu năng, hiệu suất của website
Các bước thực hiện

Bước 1: Viết đầy đủ các đầu mục công việc cần thực hiện vào phần Task Name
Bước 2: Điền thông tin người làm các task
Bước 3: Điền thông tin Predecessors. Nối các task lại với nhau

6

Bước 4: Xác định ngày bắt đầu và ngày hoàn thành task. Hệ thống tự động bỏ
qua 2 ngày nghỉ là thứ 7 và CN. Tuy nhiên người làm plan vẫn có thể chọn thứ 7
và chủ nhật theo chủ ý.
Bước 5: Điền % complete nếu các task đã hoàn thành hoặc comment lại nếu có
các vấn đề phát sinh.
Thiết kế kiểm thử: Người kiểm thử bắt đầu xây dựng các trường hợp kiểm
thử, kịch đoạn kiểm thử và dữ liệu kiểm thử dựa trên yêu cầu/thiết kế của phần
mềm. Họ cũng tạo ra việc dõi vết các yêu cầu để chắc việc kiểm thử là đầy đủ
bao quát mọi chi tiết của yêu cầu phần mềm.Bằng việc hiểu thiết kế trong chi
tiết, người kiểm thử có thể phát triển các trường hợp kiểm thử tốt hơn và dữ liệu
kiểm thử cho dự án.
Các modul mà người kiểm thử cần phải thiết kế khi kiêm thử:Viết tescase
modul quản trị hệ thống,viết testcase modul quản trị dự án, viết testcase modul
quản trị thiết bị, unit test modul quản trị hệ thống,unit test modul quản trị dự án,
unit test modul quản trị thiết bị,modul test : liệt kê các modul của hệ thống,
system test toàn bộ hệ thống, thực hiện test hiệu năng hệ cho hệ thống, tổng hợp
và lên báo cáo kết quả test, viết tài liệu hướng dẫn sử dụng hệ thống, viết tài liệu
đào tạo hệ thống,lưu tài liệu lên tài nguyên chung và kết thúc dự án
Thiết lập môi trường kiểm thử: Người kiểm thử thiết lập môi trường kiểm thử
và chắc rằng nó là hệt như với môi trường người dùng.
Thực hiện kiểm thử: Người kiểm thử thực hiện các trường hợp kiểm thử của
họ và kịch đoạn kiểm thử trong môi trường kiểm thử để xác định chất lượng của
phần mềm (Qua/Hỏng) và phát sinh kết quả kiểm thử và báo cáo khiến khuyết.
Người kiểm thử tiến hành kiểm thử chức năng, kiểm thử tích hợp, và kiểm thử hệ
thống và giúp khách hàng tiến hành kiểm thử chấp nhận của người dùng.
2.2.

Tiến trình test và các dạng test trong các giai đoạn
Các dự án có thể được chia thành 3 giai đoạn test. Giai đoạn đầu tiên gọi

là kiểm thử Alpha, giai đoạn thứ 2 là kiểm thử Beta, giai đoạn 3 là giai đoạn cuối


7

cùng. Trong từng giai đoạn, có những gợi ý và đề xuất các phương pháp test phù
hợp, gồm:
- Kiểm thử chức năng là một nhóm kiểm thử rất rộng bao gồm FAST,
TOFT, kiểm thử biên, kiểm thử dạng khám phá và các dạng khác. Để định nghĩa
tốt hơn phạm vi của kiểm thử chức năng, hãy xem các mức hoạt động khác nhau
của một ứng dụng.FAST: Mỗi đầu vào và điều khiển duyệt có hoạt động đúng
như mong đợi? TOFT: Ứng dụng có thể thực hiện các chức năng hữu ích như
mong đợi? Kiểm thử biên điều gì xảy ra khi sử dụng các giá trị biên? Kiểm thử
lỗi ép buộc điều gì xảy ra khi một điều kiện lỗi xuất hiện? Kiểm thử dạng khám
phá kinh nghiệm nói lên điều gì về các vùng tiềm ẩn vấn đề trong ứng dụng?
Kiểm thử dạng khám phá bao gồm việc nghiên cứu, lập kế hoạch, và thực thi
kiểm thử một cách đồng thời. Tấn công phần mềm: Tại sao phần mềm bị lỗi?
Làm thế nào bạn có thể biến những bài học kinh nghiệm thành các hoạt động
tương tác nhằm công kích và phát hiện các lỗi phần mềm?
- FAST
FAST: (Funcitonal acceptance simple testing) Kiểm thử đơn giản chấp
nhận chức năng .Kiểm thử đơn giản chấp nhận chức năng-FAST là mức thứ hai
của kiểm thử chấp nhận phát hành(Release acceptance testing- RAT). Kiểm thử
FAST bao phủ toàn bộ các chức năng theo chiều rộng, nhưng không theo chiều
sâu.Kiểm thử này thực thi mức thấp nhất chức năng mỗi lệnh trong chương trình.
Sự kết hợp của các chức năng không được kiểm thử trong phạm vi của kiểm thử

FAST. Vấn đề này được xem sét trong kiểm tra hướng tác vụ TOFT Có thể từ
chối kiểm thử FAST nếu trong quá trình làm có quá nhiều lỗi hoặc phiên bản đó
không hợp lệ
Mục tiêu của FAST: Kiểm tra tích hợp các hành vi điều khiển giao diện
như: Text box, pull down list, radio button… dựa trên thiết kế. Kiểm thử này yêu
cầu kiểm tra sự tồn tại của các điều khiển giao diện trên mỗi trang, cửa sổ hay
hộp thoại.Kiểm tra trạng thái mặc định, kiểm tra thứ tự tab, hành vi của các phím
tắt Ctrl- X, Ctrl- V…và các phím truy cập khác.Hơn nữa trong tiến trình này bạn


8

sẽ hiểu được logic thực hiện của người phát triển khi xây dựng các chức năng
cho người dùng cuối.
Trong môi trường WEB FAST cần kiểm tra: Các liên kết như liên kết nội
dung, liên kết thumbnail, liên kết ánh xạ… Các điều khiển cơ bản như điều khiển
tiến,lùi, phóng to, thu nhỏ, các điều khiển giao diện Khác. Kiểm tra các lệnh
hành động như thêm , xóa, cập nhật và các loại xử lý dữ kiệu khác, kiểm thử dữ
liệu đầu vào. Chức năng đăng nhập, login, logout, thông báo, email, tìm kiếm ,
quên mật khẩu
Một số lỗi bạn có thể tìm kiếm thấy trong tiến trình này bao gồm: Liên kết
bị đứt,hình ảnh thiếu liên kết không đúng ,hình ảnh không đúng , liên kết đúng
nhưng không có nội dung hoặc nội dung không cập nhật,lỗi trong tính toán đặt
mua hàng hóa. Bỏ qua sự phân loại trong thẻ tín dụng , hấp nhận thẻ tín dụng hết
hạn, nội dung không đúng hoặc ngữ cảnh trả lời email tự động không đúng,
không thông minh trong việc kiểm tra địa chỉ, trình chủ không trả lời lỗi DNS –
không có thông điệp cập nhật trình chủ gửi đến người dùng. Không có khả năng
kiểm tra các địa chỉ email không hợp lệ của người dùng.
-

Kiểm thử hướng tác vụ FAST
Kiểm thử hướng tác vụ FAST(Task oriented Functional testing) Kiểm tra

hướng tác vụ là việc kiểm tra tính đúng đắn và hữu ích của chương trình.Đây là
kiểm thử “tích cực” bằng cách so sánh công việc thực hiện với các tài liệu đặc tả
sản phẩm và đặc tả yêu cầu nếu có hoặc với mong đợi hợp lý của người
dùng.Nếu hành vi hay kết quả khác với đặc tả thì báo lỗi.Các kiểm thử TOFT
được thực hiện với một danh sách các chức năng cần được kiểm thử. Để có được
danh sách các chức năng này thì đặc tả sản phẩm cần được phân tích kỹ
lưỡng.Sản phẩm cũng cần được kiểm tra xem chức năng nào không được định
nghĩa rõ không. Tóm lại tất cả các chức năng đều trở thành một mục trong sanh
sách các chức năng cần kiểm thử. Có các yêu tố cạnh tranh hay phát triển thị
trường cũng được nghiên cứu trong giai đoạn này.
Ví dụ: 1 trang web cần load xong trong 2s, thì yêu cầu này cũng được đưa
vào danh sách kiểm thử.


9

-

Kiểm thử lỗi ép buộc – FET( Forced- error tests- FET)FET là cố ý tạo ra
những điều kiện lỗi phần mềm.
Mục tiêu: Tìm các điều kiện lỗi không được phát hiện và/hoặc bị xử lý sai.

Các điều kiện lỗi cần được sử dụng hợp lý nghĩa là ứng dụng phục hồi thành
công, hệ thống phục hồi thành công hay các ứng dụng thoát ra mà không làm
hỏng dữ liệu hệ thống
Ví dụ: Trường họ tên: Không cho nhập số->Bạn nhập 1 hoặc nhiều số
hoặc tất cả các chữ số->có thông báo không? Hãy nhớ rằng với bất kỳ điều kiện

hợp lệ nào cũng tồn tại một điều kiện không hợp lệ đi kèm với nó.Làm cách nào
để có thể kiểm thử các dạng trên tốt? Thu thập danh sách các thông điệp lỗi từ
các lập trình viên , phỏng vấn các LTV để kiếm các lỗ hổng .Khảo sát dữ liệu
chuỗi ký tự trong tệp nguồn ,thu thập thông tin từ đặc tả, sử dụng tiện ích để trích
lọc các chuỗi ký tự kiểm thử từ tệp nguồn nhị phân hoặc scrip. Sử dụng kinh
nghiệm của bạn
- Kiểm thử điều kiện biên và phân tích lớp tương đương- FET
Kiểm thử điều kiện biên (FET) trong đó các biên của mỗi biến được kiểm thử.
Ví dụ: 1 trường văn bản với một giới hạn từ 2 đến 7 ký tự.
Vậy check: 00 9999999
Nhập 8 ký tự được ko? Nhập 1 ký tự được không?Bỏ trống thì sao?Nhập
chữ và số thì sao?Nhập toàn chữ thì sao?
-

Kiểm thử biên là mở rộng của kiểm thử hướng tác vụ TOFT và kiểm thử ép

-

buộc FET, giữa các loại kiểm thử có sự chồng chéo lẫn nhau.
Kiểm thử khám phá- Exploratory testing
Kiểm dạng khám phá còn được gọi là kiểm thử phi cấu trúc (Unstructured

-

testing) hay kiểm thử phi hình thức (ad hoc testing)
Muốn thực hiện kiểm thử dạng này, tester cần suy nghĩ sáng tạo, thực hiện
kiểm thử hành vi mà chúng ta không mong đợi hoặc cố tình làm sai


10

2.3.

Những thành phần của một kế hoạch kiểm thử
Đầu vào để lập lên kế hoạch kiểm thử:Kế hoạch của dự án, đặc tả yêu cầu

của phần mềm, người lập kế hoạch Test, người tham gia Test, thời gian kiểm thử,
phạm vi Test, kinh phí giành cho việc Test, công cụ Test.
Người lập kế hoạch kiểm thử thường là trưởng nhóm Test có kinh nghiệm
dựa vào các yêu cầu của phần mềm mà đưa ra phạm vi Test cho phù hợp với
trình độ người Test, thời gian, chi phí. Khi đưa ra phạm vi rồi thì làm tốt phạm vi
đó thì coi như đạt yêu cầu theo kế hoạch Test đưa ra.
Các công việc cần thực hiện là đầu ra của kế hoạch kiểm thử:
- Nghiên cứu tài liêu dự án(phân tích, thiết kế), tìm hiểu công cụ Test cho
kiểu Test đã đặt ra.
- Thiết kế Test Case theo phạm vi Test.
- Thực hiện kiểm tra phần mềm theo nội dung Test Case
- Báo lỗi khi phát hiện được
- Viết báo cáo kết quả Test sau khi thực hiện xong
Đây là hình ảnh của 1 kế hoạch kiểm thử dùng microsoft project

Hình 1.1: Minh họa 1 kế hoạch kiểm thử


11

CHƯƠNG 3
PHƯƠNG PHÁP VÀ CÁC LOẠI KIỂM THỬ
3.
3.1.

Phương pháp kiểm thử
3.1.1. Khái niệm
Là hoạt động kiểm tra xem phần mềm có chạy chính xác hay không

(Verification) và có thoả mãn yêu cầu của khách hàng hay không (Validation)
nhằm hướng tới mục tiêu Chất lượngcho phần mềm.
Các bạn chú ý 2 khái niệm Verification và Validation.Các hoạt động
Verification chiếm 80%, Validation chiếm 20% khối lượng công việc kiểm thử.
Tuy nhiên, hiệu quả của Validation có thể tác động lên 80% hiệu quả chung của
dự án/sản phẩm. Verification là điều kiện Cần, còn Validation là điều kiện Đủ.
3.1.2. Các phương pháp
Theo khái niệm thông thường được nhắc đến Testing thường gồm 2
phương pháp là: Kiểm thử hộp đen (Black Box Testing) và Kiểm thử hộp trắng
(White Box Testing). Gần đây trong các phương pháp test kiểu Box còn phát
triển thêm khái niệm Kiểm thử hộp xám (Grey Box Testing).
Nhưng theo ISTQB thì có 2 kiểu kiểm thử là: Kiểm thử động (Dynamic
Testing) và kiểm thử tĩnh (Static Testing)
-

Kiểm thử hộp đen:Là phương pháp phổ biến nhất hiện tại.Được thực hiện khi
Tester chỉ test ở mặt front-end của ứng dụng, không quan tâm đến cấu trúc

-

code bên trong của ứng dụng.
Kiểm thử hộp trắng:Là phương pháp kiểm thử dựa trên cấu trúc bên trong của
ứng dụng (coi ứng dụng là 1 cái hộp, gọi là hộp trắng vì mình nhìn vào bên
trong hộp và kiểm tra ở phần bên trong; còn gọi là Hộp đen vì mình coi bên
trong hộp là vùng tối không biết đến, chỉ săm soi ở bên ngoài cái hộp

đó).Kiểm thử hộp trắng (được biết đến như là kiểm thử tính rõ ràng của hộp,


12

kiểm thử hộp kính, kiểm thử hộp trong suốt và kiểm thử cấu trúc) giúp kiểm
thử được cấu trúc nội bộ hoặc hoạt động của một chương trình, như tương
phản với chức năng được bộc lộ của người dùng cuối. Một góc nhìn nội bộ
của hệ thống trong kiểm thử hộp trắng giống như là các kỹ năng lập trình
được sử dụng để thiết kế ra các tình huống kiểm thử. Các Tester lựa chọn yếu
tố đầu vào để thực hiện đường dẫn thông qua các mã và xác định được kết
quả đầu ra thích hợp. Điều này tương tự các nút kiểm thử trong một mạch, ví
dụ như kiểm thử thông mạch (ICT).
Trong khi kiểm thử hộp trắng có thể được áp dụng tại đơn vị, tích hợp hệ
thống và các cấp độ của quá trình kiểm thử phần mềm, nó thường được thực hiện
ở cấp đơn vị. Nó có thể kiểm thử đường dẫn trong một đơn vị, liên kết giữa các
đơn vị trong quá trình tích hợp, và giữa các hệ thống con trong một kiểm thử hệ
thống cấp. Mặc dù phương pháp này thiết kế kiểm thử có thể phát hiện ra nhiều
lỗi hoặc các vấn đề, nó có thể không phát hiện các phần chưa thực hiện của các
đặc điểm kỹ thuật hoặc yêu cầu thiếu sót.
Các kỹ thuật được sử dụng trong kiểm thử hộp trắng bao gồm:
 Kiểm thử API (giao diện lập trình ứng dụng) - kiểm thử ứng dụng có sử dụng
các API công cộng và cá nhân.
 Kiểm thử độ bao phủ mã - tạo ra các bài kiểm thử để đáp ứng một số tiêu chí
của bảo hiểm mã (ví dụ, các nhà thiết kế kiểm thử có thể tạo ra các bài kiểm
thử để làm tất cả các câu lệnh trong chương trình được thực hiện ít nhất một
lần).
 Phương pháp chèn lỗi - cố tình đưa ra những lỗi lầm để đánh giá hiệu quả
của các chiến lược kiểm thử.Phương pháp kiểm thử đột biến và phương pháp
thử tĩnh.Các công cụ bao phủ mã có thể đánh giá đầy đủ của một bộ kiểm thử

đã được tạo ra bằng phương pháp bất kỳ nào đó, bao gồm cả kiểm thử hộp
đen. Điều này cho phép nhóm nghiên cứu phần mềm kiểm thử các bộ phận
của một hệ thống mà hiếm khi được kiểm thử và đảm bảo rằng các điểm
chức năng quan trọng nhất đã được kiểm thử. Bao phủ mã giống như một
phần mềm metric có thể báo cáo tỷ lệ phần trăm cho.Bao phủ chức năng: dựa


13

vào các báo cáo của chức năng này thực hiện.Bao phủ câu lệnh: dựa vào các
báo cáo về số lượng các dòng được thực hiện để hoàn thành kiểm thử.100%
bao phủ câu lệnh đảm bảo rằng tất cả các đường dẫn mã, hoặc các nhánh
(trong điều kiện của luồng điều khiển) được thực hiện ít nhất một lần. Điều
này hữu ích trong việc đảm bảo đúng chức năng nhưng không đủ kể từ khi
các mã tương tự có thể thực hiện tiến trình xử lý dữ liệu đầu vào khác nhau
dù đúng hoặc không.
- Kiểm thử hộp xám:Là phương pháp khá mới mẻ mới hình thành và đòi hỏi
trình độcao. Là kiểu trung gian giữa Hộp đen và Hộp trắng, trong đó Tester phải
vận dụng các kiến thức về thuật toán, cấu trúc bên trong chương trình, ..như của
hộp trắng nhưng để thiết kế TestCase theo hướng người sử dụng hoặc có
TestCase như của hộp đen.Kiểm thử hộp xám liên quan đến hiểu biết về cấu trúc
dữ liệu bên trong và các thuật toán cho mục đích của các bài kiểm thử thiết kế.
Khi thực hiện những bài kiểm thử với User hoặc mức độ hộp đen, Tester không
nhất thiết phải truy cập vào mã nguồn của phần mềm. Ta có thể thao tác với dữ
liệu đầu vào và định dạng đầu ra không xác định như hộp xám bởi vì đầu vào và
đầu ra rõ ràng ở bên ngoài của "hộp đen" mà chúng được hệ thống gọi ra trong
quá trình kiểm thử. Sự phân biệt này là đặc biệt quan trọng khi tiến hành kiểm
thử tích hợp giữa hai Module được viết mã bởi hai nhà phát triển khác nhau, mà
ở đó chỉ có các giao diện được bộc lộ ra để kiểm thử.
 Tuy nhiên, các kiểm thử mà yêu cầu thay thế một kho lưu trữ dữ liệu

back-end như một cơ sở dữ liệu hoặc một tập tin đăng nhập không xác
định như hộp xám, người dùng sẽ không thể thay đổi các kho lưu trữ dữ
liệu trong khi sản phẩm vẫn đang hoạt động bình thường.
 Kiểm thử hộp xám cũng có thể bao gồm kỹ thuật đảo ngược để xác định
đối tượng, giá trị biên hoặc các thông báo lỗi.
 Khi biết được những khái niệm cơ bản về cách thức các phần mềm hoạt
động như thế nào, Tester thực hiện kiểm thử phần mềm từ bên trong tốt
hơn so với bên ngoài. thường, một Tester hộp xám sẽ được phép thiết lập
một môi trường kiểm thử bị cô lập với các hoạt động như gieo một cơ sở


14

dữ liệu. Các kiểm thử có thể quan sát trạng thái của sản phẩm được kiểm
thử sau khi thực hiện hành động nhất định giống như việc thực hiện các
câu lệnh SQL đối với cơ sở dữ liệu và sau đó thực hiện truy vấn để đảm
bảo rằng những thay đổi dự kiến đã được phản ánh. Kiểm thử hộp xám
thực hiện kịch bản kiểm thử thông minh, dựa trên thông tin hạn chế. Điều
này sẽ đặc biệt áp dụng cho các kiểu xử lý dữ liệu, kể cả xử lý ngoại lệ, và
cứ thế.
- Kiểm thử động:Là hình thức kiểm thử các chương trình "chạy" tức là
chương trình phải hoạt động với đầu vào và sinh ra đầu ra nhất định.
- Kiểm thử tĩnh: Là hình thức Kiểm tra các chương trình thông qua hoạt
động Review. Các lỗi phát hiện ra từ hoạt động review đôi khi quan trọng hơn
nhiều so vơi lỗi của chương trình từ hoạt động kiểm thử động, đặc biệt là các lỗi
từ mức Bussiness Analysis và Analysis & Design.
3.2.

Loại kiểm thử
- Test Unit là gì? Là kiểu test kiểm tra code xem liệu chức năng nó đang

thực hiện có đúng cách hay không theo như yêu cầu.
- Test Shakeout là gì? Kiểu test này cơ bản là kiểu test về khả năng của hệ
thống mạng, kết nối dữ liệu và sự tương tác của các module. Thông thường thì
kiểu test này là do nhóm quản lý cấu hình chuẩn bị thiết lập các môi trường test
thực sự. Họ cũng test xem liệu các thành phần chính của phần mềm có hoạt động
bất thường không. Kiểu test này thực hiện trước khi tiến hành thực hiện
trong môi trường test. Sau khi test shakeout, bước kế tiếp là test smoke
(kiểu test được thực hiện bởi tester sau khi biên dịch, được tiến hành trong
môi trường test).
- Test smoke là gì? Là kiểu test được thực hiện khi phần code được biên
dịch mới chỉ được chuẩn bị tiến hành trong môi trường test. Kiểu này cơ bản
giống như kiểu ad hoc để kiểm tra đại khái để chắc rằng các chức năng chính có
bị bất thường không? Nó mở đầu cho quá trình test bởi Tester QA. Sau khi test
smoke, các tester sẽ thực hiện test khả năng thực hiện của các chức năng.
- Test Chức năng là gì? Là kiểu test liệu mỗi và mọi chức năng của ứng
dụng đó đang làm việc có như yêu cầu của tài liệu. Nó là kiểu test chính mà 80%


15

công việc test được thực hiện. Trong kiểu test này thì các testcase được thực hiện
(hoặc thi hành).
- Test Tích hợp là gì? là kiểu test kiểm tra liệu tất cả các module là được kết
hợp hoặc chưa kết hợp lại cùng với nhau thực hiện công việc có đạt được kết
quả như tài liệuyêu cầu đã được xác định (do mỗi lập trình viên thực hiện trên
các module khác nhau. Khi họ hoàn thành đoạn code của họ, nhóm quản lý cấu
hình ráp chúng lại với nhau và chuẩn bị biên dịch. Các tester cần chắc rằng các
module này bây giờ đã được kết hợp và làm việc theo như yêu cầu – tức là phải
test theo như yêu cầu).

- Test hồi quy là gì? Khi một chức năng mới được thêm vào phần mềm,
chúng ta cần chắc chắn rằng phần chức năng mới được thêm vào không phá hỏng
các phần khác của ứng dụng. Hoặc khi lỗi đã được chỉnh sửa, chúng ta cần chắc
chắn rằng lỗi chỉnh sửa không phá hỏng các phần khác trong ứng dụng. Để test
điều này chúng ta thực hiện kiểu test lặp đi lặp lại gọi là test hồi quy.
- Test hệ thống là gì? Khi tester hoàn thành công việc test (các tester test
ứng dụng trong các môi trường test, nghĩa là họ test với dữ liệu test, không test
trên dữ liệu thật), ứng dụng (phần mềm) phải được test trên môi trường thật.
Nó nghĩa là gì, tức là kể từ khi các tester test nó trong môi trường test với dữ
liệu test, chúng ta phải chắc chắn rằng ứng dụng làm việc tốt trong môi trường
thật với dữ liệu thật. Trong môi trườngtest, một vài điều không thể test hoặc
thao tác giả. Tất cả sẽ khác nhau và cơ sở dữ liệu khác nhau, một số thao tác có
thể không làm việc như mong đợi khi ứng dụng được chuyển từ môi trường
test

sang

môi

trường

sản

phẩm

(test

enviroment

to

production

environment).
- Test tải dữ liệu? Là kiểu test kiểm tra thời gian đáp lại người dùng với ứng
số lượng người dùng bất kỳ trong một ngữ cảnh nào đó của cùng một ứng dụng
tại cùng một thời điểm.
- Test tải trọng là gì? Là kiểu test kiểm tra thời gian đáp lại người dùng với
ứng số lượng người dùng bất kỳ trong nhiều ngữ cảnh khác nhau của cùng một
ứng dụng tại cùng một thời điểm.
- Test hiệu suất là gì? Trong loại test này, ứng dụng được test dựa vào sức
nặng như sự phức tạp của giá trị, độ dài của đầu vào, độ dài của các câu truy