Tải bản đầy đủ (.pdf) (88 trang)

Báo cáo tốt nghiệp đồ án Đề tài Nghiên cứu và ứng dụng công cụ kiểm thử tự động Jmeter vào kiểm thử hiệu năng Website

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

Đồ án tốt nghiệp

MỤC LỤC
MỤC LỤC................................................................................................................ 1
DANH MỤC CÁC HÌNH VẼ.................................................................................4
DANH MỤC CÁC BẢNG BIỂU............................................................................5
THÔNG TIN KẾT QUẢ NGHIÊN CỨU..............................................................6
MỞ ĐẦU..................................................................................................................8
LỜI CẢM ƠN..........................................................................................................9
CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM
THỬ PHẦN MỀM.................................................................................................10
1.1 Chất lượng phần mềm...............................................................................10
1.1.1

Định nghĩa chất lượng phần mềm......................................................10

1.1.2

Định nghĩa đảm bảo chất lượng phần mềm........................................10

1.2 Lỗi phần mềm............................................................................................11
1.2.1

Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm [10].................11

1.2.2

Các nguyên nhân gây lỗi phần mềm [4].............................................11

1.2.3


Chi phí cho việc sửa lỗi phần mềm....................................................13

1.2.4

Quy trình xử lý lỗi phần mềm [10].....................................................13

1.3 Kiểm thử phần mềm..................................................................................14
1.3.1

Khái niệm Kiểm thử phần mềm.........................................................14

1.3.2

Lý do cần kiểm thử phần mềm...........................................................14

1.3.3

Mục tiêu của Kiểm thử phần mềm.....................................................14

1.3.4

Các nguyên tắc cơ bản của Kiểm thử phần mềm [7]..........................15

1.4 Các phương pháp kiểm thử phần mềm.....................................................16
1.4.1

Kiểm thử tĩnh – Static testing [5].......................................................16

1.4.2


Kiểm thử động – Dynamic testing [5]................................................16

1.5 Các kỹ thuật cơ bản của kiểm thử phần mềm [4].....................................17
1.5.1

Kiểm thử hộp đen (Black Box Testing – BBT)..................................17

1.5.2

Kiểm thử hộp trắng (White Box Testing – WBT)..............................21

1.5.3

Kiểm thử hộp xám (Gray Box Testing – GBT)..................................24

SVTH: Nguyễn Thị Q

1

Khoa CNTT


Đồ án tốt nghiệp

1.6 Quy trình kiểm thử phần mềm [4]............................................................25
1.6.1

Các bước trong một quy trình kiểm thử phần mềm............................25

1.6.2


Mô hình phát triển và kiểm thử phần mềm hình chữ V......................27

1.6.3

Quy trình xây dựng kế hoạch kiểm thử..............................................28

CHƯƠNG 2: KIỂM THỬ TỰ ĐỘNG VÀ KIỂM THỬ HIỆU NĂNG.............30
2.1 Kiểm thử tự động (Automate Testing) [7].................................................30
2.1.1

Tổng quan về kiểm thử tự động..........................................................30

2.1.2

Lý do cần phải kiểm thử tự động [7]..................................................31

2.1.3

Ưu điểm và nhược điểm của kiểm thử tự động [7].............................31

2.1.4

Các trường hợp nên áp dụng kiểm thử tự động [7].............................31

2.1.5

So sánh Kiểm thử tự động với Kiểm thử thủ công.............................32

2.1.6


Quy trình kiểm thử tự động [4]..........................................................33

2.2 Kiểm thử hiệu năng...................................................................................38
2.2.1

Khái niệm về kiểm thử hiệu năng [7].................................................38

2.2.2

Các tiêu chí của kiểm thử hiệu năng [9].............................................38

2.2.3

Các yếu tố ảnh hưởng đến kiểm thử hiệu năng [9].............................39

2.2.4

Quy trình kiểm thử hiệu năng [9].......................................................40

CHƯƠNG 3: NGHIÊN CỨU CÔNG CỤ KIỂM THỬ HIỆU NĂNG JMETER
................................................................................................................................. 43
3.1 Giới thiệu chung về JMeter [8].................................................................43
3.2 Đặc trưng của Jmeter [8]..........................................................................44
3.3 Download Jmeter.......................................................................................45
3.4 Các thành phần chính của Jmeter [2][6]..................................................45
3.4.1

Test Plan.............................................................................................45


3.4.2

Các thành phần của Test Plan [3].......................................................50

3.4.3

Thứ tự thực hiện của một test plan.....................................................52

3.5 Webservice.................................................................................................53
3.6 JDBC REQUEST [2][6]............................................................................56
3.7 FTP REQUEST [2]...................................................................................61
CHƯƠNG 4: ỨNG DỤNG CÔNG CỤ JMETER VÀO KIỂM THỬ HIỆU
NĂNG HỆ THỐNG QUẢN TRỊ TÀI LIỆU DOCPRO.....................................63
SVTH: Nguyễn Thị Q

2

Khoa CNTT


Đồ án tốt nghiệp

4.1 Giới thiệu về Hệ thống quản trị tài liệu Docpro.......................................63
4.1.1

Hệ thống quản trị tài liệu Docpro là gì ?...........................................63

4.1.2

Các tính năng chính của hệ thống quản trị tài liệu Docpro.................64


4.2 Mô tả nghiệp vụ.........................................................................................65
4.2.1

Nghiệp vụ: Xuất file excel..................................................................65

4.2.2

Nghiệp vụ: Tìm kiếm tài liệu theo số ký hiệu.....................................65

4.2.3

Nghiệp vụ: Thống kê kho tài liệu theo năm........................................66

4.2.4

Nghiệp vụ: Tải tài liệu lên..................................................................67

4.3 Lập kế hoạch kiểm thử..............................................................................67
4.3.1

Mục tiêu kiểm thử..............................................................................67

4.3.2

Môi trường kiểm thử..........................................................................68

4.3.3

Kịch bản kiểm thử..............................................................................69


4.3.4

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

4.4 Thực hiện cấu hình và chạy trên Jmeter..................................................72
4.4.1

Cấu hình.............................................................................................72

4.4.2

Chạy để lấy kết quả............................................................................74

4.3 Phân tích, báo cáo, đánh giá kết quả kiểm thử........................................75
4.3.1

Phân tích.............................................................................................75

4.3.2

Kết quả báo cáo kiểm thử hiệu năng..................................................76

4.3.1

Đánh giá, kết luận..............................................................................84

KẾT LUẬN............................................................................................................86
5.1 Kết quả đạt được và hạn chế.....................................................................86
5.2 Hướng phát triển.......................................................................................86

TÀI LIỆU THAM KHẢO.....................................................................................87
DANH MỤC CÁC HÌNH VẼ
Hình 1-1 Kiểm thử hộp đen..................................................................................17
Hình 1-2 Bao phủ điều kiện trong kiểm thử hộp trắng......................................23
Hình 1-3 Bao phủ nhánh trong kiểm thử hộp trắng...........................................23
SVTH: Nguyễn Thị Q

3

Khoa CNTT


Đồ án tốt nghiệp

Hình 1-4 Quy trình kiểm thử phần mềm............................................................27
Hình 1-5 Mô hình phát triển và kiểm thử phần mềm hình chữ V....................27
Hình 2-1 Quy trình kiểm thử tự động..................................................................33
Hình 2-2 Bản kế hoạch chính và các bản kế hoạch chi tiết................................34
Hình 2-3 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra.......................35
Hình 3-1 Mô phỏng tải trọng lớn trong Jmeter...................................................44
Hình 3-2 Download Apache Jmeter.....................................................................45
Hình 3-3 Mở file chạy tool Jmeter........................................................................46
Hình 3-4 Giao diện của Jmeter.............................................................................46
Hình 3-5 Chọn template........................................................................................47
Hình 3-6 Đặt tên các bước....................................................................................47
Hình 3-7 Thêm các Listener..................................................................................48
Hình 3-8 Chỉnh sửa HTTP Proxy Server.............................................................49
Hình 3-9 Lưu kế hoạch kiểm thử.........................................................................49
Hình 3-10 Thực hiện chạy Test Plan....................................................................50
Hình 4-1 Mô hình quản lý văn bản tài liệu và điều hành Docpro......................63

Hình 4-2 Tính năng của hệ thống quản trị tài liệu và điều hành Docpro..........64
Hình 4-3 Ghi script................................................................................................73
Hình 4-4 Đặt Assertion, Timer, Listener.............................................................74
Hình 4-5 Cấu hình và chạy lấy kết quả................................................................75
Hình 4-6 Thông tin trả về......................................................................................76

DANH MỤC CÁC BẢNG BIỂU
Bảng 4-1 Môi trường máy chịu tải.......................................................................67
Bảng 4-2 Môi trường máy đẩy tải........................................................................67
Bảng 4-3 Kịch bản kiểm thử.................................................................................68
Bảng 4-4 Báo cáo kết quả......................................................................................76
SVTH: Nguyễn Thị Q

4

Khoa CNTT


Đồ án tốt nghiệp

THÔNG TIN KẾT QUẢ NGHIÊN CỨU
1. Thông tin chung
Tên đề tài:

Nghiên cứu và ứng dụng công cụ kiểm thử tự động Jmeter
vào kiểm thử hiệu năng Website

Sinh viên thực hiện: Nguyễn Thị Q
Lớp: Tin
Hệ đào tạo: Đại học chính quy

Điện thoại:
Email:
Thời gian thực hiện: 2017
2. Mục tiêu
Đề tài tìm hiểu cơ sở lý thuyết về kiểm thử cũng như cách triển khai công cụ
kiểm thử phần mềm tự động để giảm nhân lực kiểm thử và đảm bảo chất lượng
phần mềm hơn với công việc kiểm thử bằng tay.
Mục tiêu chính của đề tài là:
-

Nghiên cứu giai đoạn nào cần áp dụng công cụ kiểm thử tự động, các yếu tố
nào cần kiểm thử hiệu năng.

-

Hiểu rõ về các thành phần của bộ công cụ Jmeter.

-

Ứng dụng các kiến thức kiểm thử phần mềm và kiến thức về Jmeter để viết
kịch bản kiểm thử cho một ứng dụng cụ thể.

3. Nội dung chính
Đồ án được chia thành 4 phần như sau:

SVTH: Nguyễn Thị Q

5

Khoa CNTT



Đồ án tốt nghiệp

Chương 1: Tổng quan về chất lượng phần mềm và kiểm thử phần mềm:
Chương này trình bày những kiến thức cơ bản về chất lượng phần mềm, kiểm thử
phần mềm như các nguyên tắc kiểm thử, các phương pháp kiểm thử, các giai đoạn
kiểm thử phần mềm.
Chương 2: Kiểm thử tự động và kiểm thử hiệu năng: Trình bày các khái
niệm, quy trình, ưu nhược điểm của kiểm thử tự động và kiểm thử hiệu năng.
Chương 3: Nghiên cứu công cụ kiểm thử hiệu năng Jmeter: Chương này
trình bày tổng quan về công cụ Jmeter, cách cài đặt, sử dụng Jmeter, tạo một test
plan, các thành phần trong jmeter, khái niệm về webservice, tạo test plan
webservice, tạo test plan cho JDBC.
Chương 4: Ứng dụng công cụ Jmeter vào kiểm thử hiệu năng hệ thống
quản trị tài liệu Docpro: giới thiệu hệ thống quản trị tài liệu Docpro, các chức năng
chính của hệ thống, mô tả nghiệp vụ, lập kế hoạch kiểm thử, thực hiện cấu hình và
chạy Jmeter, phân tích báo cáo đánh giá kết quả.
4. Kết quả chính đạt được
 Qua quá trình nghiên cứu và triển khai ứng dụng kiểm thử hiệu năng website sử
dụng công cụ Jmeter Apache, em đã đạt được một số kết quả như sau:
 Nắm được cơ sở lý thuyết về kiểm thử, kỹ thuật kiểm thử, một số vấn đề
cần chú ý khi thực hiện kiểm thử cho một ứng dụng Web.
 Nắm được cơ sở lý thuyết về kiểm thử hiệu năng, các yếu tố được kiểm
thử trong kiểm thử hiệu năng, các yếu tố ảnh hưởng tới việc kiểm thử hiệu
năng.
 Tìm hiểu công cụ kiểm thử Jmeter và áp dụng nó vào việc kiểm thử hiệu
năng cho website.
 Bên cạnh những kết quả đạt được, đề tài còn có những hạn chế như sau:
SVTH: Nguyễn Thị Q

Khoa CNTT
6


Đồ án tốt nghiệp

 Chưa sử dụng công cụ kiểm thử Jmeter một cách triệt để.
 Trong quá trình chạy phần mềm, chất lượng mạng còn kém và không ổn
định nên kết quả test chỉ mang tính tương đối.

MỞ ĐẦU
1. Lý do chọn đề tài
Hiện nay, Internet đã trở thành một phần không thể thiếu trong cuộc sống với
hàng tỉ website cung cấp các dịch vụ thiết yếu như tìm kiếm thông tin, giải trí, học
tập, mua bán hàng hóa,… Bên cạnh những yếu tố ảnh hưởng tới chất lượng website
như giao diện, khả năng tương thích, chức năng của ứng dụng web và bảo mật thì
yếu tố hiệu năng là một trong những vấn đề rất quan trọng để đánh giá hệ thống và
khả năng mở rộng của web.
Việc xác định số người dùng tối đa, sức tải công việc cũng như thời gian xử lý
các thao tác của các ứng dụng web là rất quan trọng trong quá trình xây dựng và
phát triển web. Kiểm thử hiệu năng nhằm xác định tốc độ, khả năng phân tải và
mức độ tin tưởng của ứng dụng trong môi trường nhiều người dùng, có nhiều hoạt
động khác nhau. Công cụ kiểm tra tự động để kiểm tra hiệu năng ứng dụng web ở
điều kiện có sự điều chỉnh về mức độ tải có thể kể đến như: LoadRunner, Jmeter
Apache, LoadStorm, Pylot, The Grinder,… tuy nhiên, với khả năng chạy trên nhiều
hệ điều hành, hỗ trợ đa giao thức và hoàn toàn miễn phí nên Jmeter được xem là nổi
trội hơn.
Vì vậy, xuất phát từ nhu cầu thực tiễn, em chọn đề tài đồ án tốt nghiệp là :
“Nghiên cứu và ứng dụng công cụ kiểm thử tự động Jmeter vào kiểm thử hiệu
năng Website”

2. Ý nghĩa lý luận thực tiễn
SVTH: Nguyễn Thị Q

7

Khoa CNTT


Đồ án tốt nghiệp

Phần nghiên cứu lý thuyết sẽ cung cấp một cách nhìn tổng quát về quá trình
kiểm thử phần mềm và kiểm thử hiệu năng.
Đề tài đã ứng dụng những kiến thức đã học trong công nghệ phần mềm, kiểm
thử phần mềm góp phần nghiên cứu hiệu năng của các ứng dụng web ở môi trường
có những hoạt động với số lượng người dùng lớn.

SVTH: Nguyễn Thị Q

8

Khoa CNTT


Đồ án tốt nghiệp

LỜI CẢM ƠN
Trong quá trình thực hiện đề tài, em đã nhận được sự giúp đỡ và chỉ bảo tận
tình của thầy giáo hướng dẫn TS.Lê Hồng Anh. Em xin chân thành cảm ơn thầy đã
giúp em hoàn thành đồ án tốt nghiệp này.
Mặc dù đã cố gắng hoàn thiện đề tài nhưng trong quá trình thực hiện có thể còn

nhiều thiếu sót mong quý thầy cô tận tình chỉ bảo. Em xin chân thành cảm ơn!
Hà Nội, ngày 12 tháng 6 năm 2017
Sinh viên thực hiện

Nguyễn Thị Q

SVTH: Nguyễn Thị Q

9

Khoa CNTT


Đồ án tốt nghiệp

CHƯƠNG 1: TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ
KIỂM THỬ PHẦN MỀM
1.1 Chất lượng phần mềm
1.1.1 Định nghĩa chất lượng phần mềm
Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức,
cá nhân khác nhau. Trong phạm vi của đồ án này trình bày một số định nghĩa tiêu
biểu.
 Định nghĩa theo IEEE (1991)[10]:
 Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống,
thành phần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả.
 Định nghĩa 2: Chất lượng phần mềm là mức độ mà một hệ thống, thành
phần hệ thống hay tiến trình đáp ứng được yêu cầu và sự mong đợi của
khách hàng hay người sử dụng.
 Định nghĩa theo Pressman[10]: Chất lượng phần mềm là sự phù hợp của
các yêu cầu cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần

mềm được ghi lại rõ dàng bằng tài liệu với các đặc tính ngầm định của tất cả
các phần mềm được phát triển chuyên nghiệp.
1.1.2 Định nghĩa đảm bảo chất lượng phần mềm
Định nghĩa theo Daniel Galin[10]: Đảm bảo chất lượng phần mềm (Soft are
QualityAssure) là một tập hợp các hành động cần thiết được lên kế hoạch một cách
hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phần mềm phù hợp

SVTH: Nguyễn Thị Q

10

Khoa CNTT


Đồ án tốt nghiệp

để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản lý theo lịch
trình và hoạt động trong giới hạn ngân sách.
1.2

Lỗi phần mềm

1.2.1 Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm [10]
-

Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm
nhưng có thể hiểu và phát biểu một cách đơn giản thì "Lỗi phần mềm là
sự không khớp giữa chương trình và đặc tả của nó".

-


Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:

+ Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.
+ Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tả
nhưng lại không có trong sản phẩm thực tế.
+ Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu
đặc tả.
1.2.2 Các nguyên nhân gây lỗi phần mềm [4]
Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả
các nguyên nhân chủ quan và các nguyên nhân khách quan. Dưới đây là chín
nguyên nhân chủ yếu gây ra lỗi phần mềm:
 Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu
thường nằm ở phía khách hàng.
 Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Những lỗi này
thường xuất hiện trong giai đoạn đầu của dự án. Một số lỗi hay gặp phải:
SVTH: Nguyễn Thị Q

11

Khoa CNTT


Đồ án tốt nghiệp

hiểu sai chỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng
trình bày bằng lời nói và tài liệu, hiểu sai về phản hồi và thiếu quan tâm
đến những đề cập của khách hàng.
 Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và
nhà cung cấp để tránh lỗi trong giao tiếp. Ủy ban do quản trị dự án

đứng đầu và khách hàng phải giới thiệu những người hiểu về mặt
nghiệp vụ vào ủy ban đó.
 Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trường hợp
các nhà phát triển cố tình làm sai lệnh các yêu cầu trong tài liệu đặc tả.
Nguyên nhân của việc này đến từ các áp lực thời gian, ngân sách, hay cố
tình sử dụng lại các mô-đun từ các dự án trước mà chưa phân tích đầy đủ
những thay đổi để thích nghi với các yêu cầu mới.
 Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem
giải pháp như thế nào, sắp xếp ưu tiên xem bỏ được yêu cầu nào hay
sử dụng lại được mô-đun nào.
 Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên
gia thiết kế hệ thống, các kiến trúc sư hệ thống, kỹ sư phần mềm, các nhà
phân tích xây dựng phần mềm theo yêu cầu. Các lỗi điển hình bao gồm:
+ Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai.
+ Quy trình định nghĩa có chứa trình tự lỗi.
+ Sai sót trong các định nghĩa biên như > 3 hay ≥ 3.
SVTH: Nguyễn Thị Q

12

Khoa CNTT


Đồ án tốt nghiệp

+ Thiếu sót các trạng thái hệ thống phần mềm được yêu cầu.
+ Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viên
gây ra các lỗi lập trình. Những lý do này bao gồm: Sự hiểu sai các
tài liệu thiết kế, ngôn ngữ; sai sót trong ngôn ngữ lập trình; sai sót
trong việc áp dụng các công cụ phát triển; sai sót trong lựa chọn dữ

liệu...
+ Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình:
Các lỗi phần mềm có thể đến từ việc không tuân thủ các tài liệu và
tiêu chuẩn lập trình của các tổ chức phát triển phần mềm.
+ Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từ
chính quá trình kiểm thử khi mà người kiểm thử để lọt lỗi.
 Những lỗi này đến từ các nguyên nhân sau đây:
+ Kế hoạch kiểm thử chưa hoàn chỉnh, để sót yêu cầu cần kiểm thử.
+ Lỗi trong tài liệu và báo cáo kiểm thử.
+ Việc sửa chữa các lỗi được phát hiện không hoàn chỉnh do áp lực
thời gian hay do thiếu cẩn thận.
 Giải pháp khắc phục: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu
của dự án.

SVTH: Nguyễn Thị Q

13

Khoa CNTT


Đồ án tốt nghiệp

 Các lỗi thủ tục: Các thủ tục hướng dẫn cho người sử dụng tại từng bước của
tiến trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm
phức tạp mà các tiến trình được thực bằng nhiều bước, mỗi bước có thể có
nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian. Các lỗi có thể
đến từ việc viết các thủ tục.
 Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo
trì khi có nhữ ng sai sót trong các tài liệu liên quan. Những lỗi này có thể là

nguyên nhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì.
1.2.3 Chi phí cho việc sửa lỗi phần mềm
Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạn
nào của vòng đời phần mềm.Tuy nhiên công việc này nên được thực hiện càng sớm
càng tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phí cho việc tìm và
sửa lỗi càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thì chi phí cho
sửa lỗi sẽ trở nên rất lớn và ảnh hưởng trực tiếp đến uy tín của tổ chức phát triển
phần mềm.
1.2.4 Quy trình xử lý lỗi phần mềm [10]
Quy trình xử lý lỗi có thể bao gồm 6 bước chính:
Bước 0_Bắt đầu: Phát hiện phần mềm có lỗi.
Bước 1_Đưa lỗi lên hệ thống quản lý lỗi.
Bước 2_Gán lỗi cho nhân viên phát triển.
Bước 3_Xử lý lỗi.
Bước 4_Kiểm thử lại.
Bước 5_Đóng lỗi.

SVTH: Nguyễn Thị Q

14

Khoa CNTT


Đồ án tốt nghiệp

1.3 Kiểm thử phần mềm
1.3.1

Khái niệm Kiểm thử phần mềm

Kiểm thử phần mềm là quy trình được sử dụng để đánh giá, kiểm tra chất

lượng phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu của người sử
dụng đối với sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trong
các môi trường, các trường hợp khác nhau.
Có thể định nghĩa một cách dễ hiểu như sau [5]:
Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được
thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế
để làm, và không thực hiện bất cứ thứ gì không mong muốn. Đây là một pha quan
trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và
khách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?
1.3.2

Lý do cần kiểm thử phần mềm
+ Phần mềm nào cũng có lỗi bởi vì nó do con người làm ra.
+ Kiểm thử độ tin cậy của phần mềm.
+ Các lỗi đang dùng trong thực tế có thể rất tốn chi phí cũng như gây nguy
hiểm đến con người.
+ Tránh kiện tụng của khách hàng.
+ Phát triển doanh nghiệp.
+ Lỗi phát hiện càng sớm thì chi phí khắc phục càng nhỏ.

SVTH: Nguyễn Thị Q

15

Khoa CNTT


Đồ án tốt nghiệp


1.3.3

Mục tiêu của Kiểm thử phần mềm
-

Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểm
thử.

-

Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đến
khi đạt một mức độ chất lượng phần mềm chấp nhận được.

-

Thực thi những trường hợp kiểm thử một cách hiệu quả trong một giới
hạn ngân sách và lịch trình cho phép.

1.3.4

Các nguyên tắc cơ bản của Kiểm thử phần mềm [7]

Có 7 nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc đó là:
-

Kiểm thử để chứng minh sự có mặt của lỗi và không chứng minh điều
ngược lại: Kiểm thử có thể cho thấy sự có mặt của lỗi nhưng không thể
chứng minh điều ngược lại là chương trình không có lỗi. Việc kiểm thử
giảm nguy cơ không tìm thấy lỗi trong phần mềm nhưng ngay cả khi

không tìm thấy lỗi thì cũng không thể chứng minh được sản phẩm phần
mềm được phát triển hoàn toàn chính xác.

-

Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện được cho
tất mọi trường hợp kiểm thử. Do vậy thay vì kiểm thử mọi khía cạnh, ta
phải tập trung vào kiểm thử nhữ ng yếu tố quan trọng và nhiều rủi do.

-

Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt
trong vòng đời phát triển phần mềm, và nên tập trung và những mục tiêu
kiểm thử nhất định.

SVTH: Nguyễn Thị Q

16

Khoa CNTT


Đồ án tốt nghiệp

-

Phân cụm lỗi: Một số lượng nhỏ các mô-đun phần mềm có thể chứa hầu
hết các lỗi được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung
hầu hết các lỗi vận hành.


-

Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lại
nhiều lần, các trường hợp kiểm thử giống nhau sẽ không phát hiện được
triệt để lỗi mới. Để khắc phục điều này ta có thể sử dụng nguyên tắc
"kiểm thử ngược", các trường hợp kiểm thử cần phải được xem xét và
duyệt lại một cách đều đặn, và việc kiểm thử mới cần phải được viết lại
để thực thi nhữ ng phần khác của phần mềm hay hệ thống để tìm ra nhữ
ng lỗi tiềm ẩn.

-

Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử được thực hiện trong
những hoàn cảnh khác nhau thì khác nhau.

-

Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp được gì
nếu hệ thống không dùng được hoặc không đáp ứng được yêu cầu và sự
mong đợi của khách hàng.

1.4 Các phương pháp kiểm thử phần mềm
Có rất nhiều phương pháp để kiểm thử phần mềm. Đánh giá, định hướng hoặc
kiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình thực tế trong
các tình huống được gọi là kiểm thử động. Kiểm thử tĩnh thông thường có thể được
bỏ qua khi thực hành nhưng kiểm thử động diễn ra khi bản thân chương trình đó
đang được sử dụng.
1.4.1 Kiểm thử tĩnh – Static testing [5]
Là phương pháp kiểm thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và
các đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi

SVTH: Nguyễn Thị Q

17

Khoa CNTT


Đồ án tốt nghiệp

tiết mà không cần chạy chương trình. Kiểu kiểm thử này thường được sử dụng bởi
chuyên viên thiết kế người mà viết mã lệnh một mình.
Kiểm thử tĩnh cũng có thể được tự động hóa. Nó sẽ thực hiện kiểm tra toàn
bộ bao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên
dịch mà xác nhận tính hợp lệ về cú pháp của chương trình.
1.4.2 Kiểm thử động – Dynamic testing [5]
Là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chương
trình để điều tra trạng thái tác động của chương trình. Đó là kiểm thử dựa trên các
ca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy các
chương trình. Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức là
kiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian.
Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy. Kiểm thử
động thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm tra
xem liệu đầu ra có như mong muốn hay không.
Kiểm thử động có thể bắt đầu trước khi chương trình đã hoàn tất 100% để
kiểm thử các phần cụ thể của mã và được áp dụng cho các chức năng riêng biệt
hoặc Module. Kỹ thuật điển hình cho điều này được sử dụng trong cả mạch
nhánh/trình điều khiển hoặc được thực hiện trong một môi trường gỡ lỗi nhất định.
1.5 Các kỹ thuật cơ bản của kiểm thử phần mềm [4]
1.5.1 Kiểm thử hộp đen (Black Box Testing – BBT)
 Định nghĩa

Kiểm thử hộp đen hay còn gọi là kiểm tra chức năng và thử nghiệm hành vi.
Xem chương trình như là một “hộp đen”, hoàn toàn không quan tâm về cách cư xử

SVTH: Nguyễn Thị Q

18

Khoa CNTT


Đồ án tốt nghiệp

và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường
hợp mà chương trình không thực hiện theo đặc tả của nó.

Hình 1-1 Kiểm thử hộp đen
Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm,
trong con mắt của các tester, giống như một hộp đen; bên trong mà người ta không
thể nhìn thấy. Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:


Chức năng không chính xác hoặc thiếu.



Lỗi giao diện.



Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài.




Hành vi hoặc hiệu suất lỗi.



Khởi tạo và chấm dứt các lỗi.

SVTH: Nguyễn Thị Q

19

Khoa CNTT


Đồ án tốt nghiệp

 Các phương pháp kiểm thử hộp đen
 Đoán lỗi: là một kỹ năng quan trọng của tester, thậm chí có thể gọi là nghệ
thuật, một kiệt tác của trực giác. Phương pháp này đặc biệt dựa vào kinh nghiệm và
kiến thức của tester. Nhiều tester cố gắng đoán xem phần nào của hệ thống mà có
khả năng ẩn chứa lỗi. Với phương pháp này, họ không cần một công cụ hay một
kịch bản kiểm thử nào khi bắt đầu vào việc.
 Kiểm thử dựa vào đồ thị nguyên nhân - kết quả (Cause Effect Graphing):
là một kỹ thuật thiết kế kiểm thử phần mềm liên quan đến việc xác định các trường
hợp (điều kiện đầu vào) và các hiệu ứng (điều kiện đầu ra). Vì các hệ thống hiện nay
đều được phát triển trên nền tảng OOP, do đó, chúng ta có thể có được một đồ thị
các đối tượng mà hệ thống định nghĩa và kết nối. Từ đồ thị này, chúng ta dễ dàng
biết các mối quan hệ của những đối tượng mà hệ thống xử lý, từ đó sẽ cho chúng ta

các kịch bản kiểm thử phù hợp.
 Phân vùng tương đương (Equivalence Class): là một kỹ thuật kiểm thử phần
mềm có liên quan đến phân chia các giá trị đầu vào thành các phân vùng hợp lệ và
không hợp lệ, sau đó chúng ta sẽ viết ra các kịch bản kiểm thử cho từng phần, chọn
giá trị đại diện từ mỗi phân vùng làm dữ liệu thử nghiệm.
-

Phân vùng tương đương: là kỹ thuật thực hiện test theo từng class đồng

giá trị (tập hợp điều kiện cùng một thao tác).
-

Tập hợp giá trị input có cùng một kết quả xử lý, tập hợp thời gian có cùng

một kết quả xử lý, tập hợp kết quả export được xử lý cùng một giá trị nhập.
-

Mục đích: Giảm đáng kể số lượng test case cần phải thiết kế vì với mỗi

lớp tương đương ta chỉ cần test trên các phần tử đại diện.
-

Chọn tối thiểu một giá trị đại diện từ các class đồng giá trị để tiến hành

test.

SVTH: Nguyễn Thị Q

20


Khoa CNTT


Đồ án tốt nghiệp

Nếu có lỗi xảy ra thì các giá trị khác trong class đồng giá trị cũng sẽ có
lỗi giống nhau.
 Phân tích giá trị biên (Boundary Value Analysis): là một kỹ thuật kiểm thử
phần mềm có liên quan đến việc xác định biên (ranh giới) của điều kiện mô tả cho
các giá trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ liệu kiểm
thử. Phương pháp phân tích giá trị biên sẽ đưa ra các giá trị đặc biệt, bao gồm loại dữ
liệu, giá trị lỗi, bên trong, bên ngoài biên giá trị, lớn nhất và nhỏ nhất.


Test giá trị biên được thực hiện theo trình tự dưới đây:
1. Tìm ra đường biên
2. Quyết định giá trị biên
3. Quyết định giá trị để test



Giá trị biên.



Dưới giá trị biên. (Nếu là class đồng giá trị)



Trên 1 giá trị biên. (Nếu là class đồng giá trị)


 Sử dụng bảng quyết định (Decision Tables)


Là dùng bảng để hiển thị danh sách các thao tác phần mềm được

quyết định trên các điều kiện khác nhau.


Decision table testing chú trọng vào nhiều điều kiện để thực hiện test.

Ngoài ra, kiểm thử hộp đen còn có một số kỹ thuật như: Domain Tests,
Orthogonal Arrays, State Models, Exploratory Testing (kiểm thử chủ yếu dựa vào
kinh nghiệm và khả năng focus vào việc test các chức năng của tester), All-pairs
testing (kiểm thử tất cả các cặp), ...
 Ưu nhược điểm của kiểm thử hộp đen
 Ưu điểm
SVTH: Nguyễn Thị Q

21

Khoa CNTT


Đồ án tốt nghiệp

-

Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ
trong việc sáng tỏ sự chênh lệch về thông số kỹ thuật.


-

Các tester theo phương pháp black box không có “mối ràng buộc” nào với
code, và nhận thức của một tester rất đơn giản: một source code có nhiều
lỗi, sử dụng nguyên tắc: "Hỏi và bạn sẽ nhận" các tester black box tìm
được nhiều bug ở nơi mà các DEV không tìm thấy.

-

Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn ngữ
lập trình hoặc làm thế nào các phần mềm đã được thực hiện.

-

Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer,
cho phép một cái nhìn khách quan và tránh sự phát triển thiên vị.

-

Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.

-

Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năng
được xác định.

 Nhược điểm
-


Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn.

-

Khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, và
thiếu cả thời gian cho việc tập hợp này.

-

Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao.

1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT)



Định nghĩa
Kiểm thử hộp trắng là phương pháp kiểm nghiệm dựa vào cấu trúc/mã lệnh

chương trình. WBT kiểm nghiệm một chương trình (một phần chương trình, hay
một hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm cả
các giá trị không đúng hay không theo dự định của chương trình. Chiến lược này
SVTH: Nguyễn Thị Q

22

Khoa CNTT


Đồ án tốt nghiệp


xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm
thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả
mã lệnh thực hiện chúng).
Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định về
ngôn ngữ lập trình được dùng, về thuật giải được dùng trong thành phần phần mềm
để có thể thông hiểu chi tiết về đoạn code cần kiểm thử. Thường tốn rất nhiều thời
gian và công sức nếu thành phần phần mềm quá lớn (thí dụ trong kiểm thử tích hợp
hay kiểm thử chức năng). Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn
vị. Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1
class chức năng nào đó.
Có 2 hoạt động kiểm thử hộp trắng :
 Kiểm thử luồng điều khiển: tập trung kiểm thử thuật giải chức năng.
 Kiểm thử dòng dữ liệu: tập trung kiểm thử đời sống của từng biến dữ liệu
được dùng trong thuật giải.


Các phương pháp kiểm thử hộp trắng
Khi thực hiện kiểm thử bằng whitebox testing thì ta phải có một bộ test cho

chương trình đó. Tuy nhiên để biết chắc chắn được là bộ test của chúng ta đã đầy đủ
cho tất cả các trường hợp hay chưa, ta sẽ áp dụng các kiến thức của coverage tesing
để đo đạc kết quả của chương trình khi thực hiện bộ kiểm thử.
Coverage testing có thể hiểu là tỉ lệ (tính theo %) test case đã được thực hiện
trên tổng số test case cần thiết cho ứng dụng. Nếu tỉ lệ này càng cao thì ứng dụng
càng được test kỹ. Mặc dù việc đảm bảo ứng dụng có test coverage là 100% trong
một số trường hợp là bất khả thi, nhưng ta vẫn sẽ luôn cố gắng để đạt được kết quả
gần với con số đó nhất.
Có 3 kĩ thuật kiếm thử hộp trắng là:

SVTH: Nguyễn Thị Q


23

Khoa CNTT


Đồ án tốt nghiệp


Bao phủ câu lệnh (Statement Coverage) : Kiểm thử sao cho mỗi câu lệnh

được thực thi ít nhất 1 lần. Ví dụ đoạn mã:
Public int foo(int x, int y) Int z = 0; If (x > 0 && y > 0) { z = x; } Return z; }
Nếu ta gọi foo(1,1) thì dòng z = x sẽ được thực hiện, còn nếu gọi foo(0,1) thì
dòng z = x sẽ không được thực hiện, lúc đó test case của ta sẽ không thỏa điều kiện
bao phủ câu lệnh.


Bao phủ điều kiện (Branch Coverage, Decision coverage): Kiểm thử đòi hỏi

phải đủ trường hợp thử nghiệm như vậy mà mỗi điều kiện trong một quyết định có
trên tất cả các kết quả có thể ít nhất một lần. Đó là các nhánh (quyết định) lấy cả 2
trường hợp đúng và sai. Nó giúp trong việc chứng thực tất cả các ngành có mã đảm
bảo rằng đó không có chi nhánh dẫn đến hành vi bất thường của ứng dụng. Ví dụ
đoạn mã:

Ta có thể sinh các test case bao phủ các điều kiện của nhánh:




Hình 1-2 Bao phủ điều kiện trong kiểm thử hộp trắng
Bao phủ nhánh (Path Coverage): Trong các trường hợp kiểm thử được thực

hiện trong một cách mà mọi con đường được thực hiện ít nhất một lần. Tất cả các
con đường kiểm soát có thể được thực hiện, bao gồm tất cả những con đường vòng
lấy bằng không, một lần, và nhiều (lý tưởng là tối đa) các trường hợp thử nghiệm
được chuẩn bị dựa trên các biện pháp phức tạp logic của một thiết kế thủ tục. Để
SVTH: Nguyễn Thị Q

24

Khoa CNTT


Đồ án tốt nghiệp

hoàn thiện bao phủ nhánh, chúng ta phải xét thêm 2 trường hợp bug(a) khi đúng và
khi sai.

Hình 1-3 Bao phủ nhánh trong kiểm thử hộp trắng


Ưu nhược điểm của kiểm thử hộp trắng
 Ưu điểm
-

Kiểm tra được toàn bộ chương trình nguồn

-


Phát hiện lỗi tại chỗ

-

Tự động hóa kiểm thử

 Nhược điểm
-

Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình.
Do dó đòi hỏi tài nguyên nhân lực và máy tốn kém.

-

Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi.

-

Không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp.

-

Khó thực hiện và chi phí thực hiện cao

SVTH: Nguyễn Thị Q

25

Khoa CNTT



×