NGHIÊN cứu KIỂM THỬ PHẦN mềm và CÔNG cụ KIỂM THỬ PHẦN mềm tự ĐỘNG JMETER

TRƯỜNG ĐẠI HỌC TÀI NGUYÊN VÀ MÔI TRƯỜNG HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN


NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ
CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ ĐỘNG JMETER

Hà Nội – Năm 2020


TRƯỜNG ĐẠI HỌC TÀI NGUYÊN VÀ MÔI TRƯỜNG HÀ NỘI
KHOA CÔNG NGHỆ THÔNG TIN


ĐẶNG THỊ QUỲNH

NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ
CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ ĐỘNG JMETER

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

NGƯỜI HƯỚNG DẪN: THS PHÍ THỊ HẢI YẾN

Hà Nội – Năm 2020


LỜI CAM ĐOAN
Em xin cam đoan đề tài: “Nghiên cứu kiểm thử phần mềm và công cụ kiểm
thử phần mềm tự động JMeter” là một công trình nghiên cứu độc lập dưới sự hướng

dẫn của giáo viên hướng dẫn: ThS Phí Thị Hải Yến.
Ngoài ra không có bất cứ sự sao chép của người khác. Đề tài, nội dung báo
cáo thực tập là sản phẩm mà em đã nỗ lực nghiên cứu trong quá trình học tập tại
trường cũng như tham gia thực tập tại công ty FSoft.
Các số liệu, kết quả trình bày trong báo cáo là hoàn toàn trung thực, em xin
chịu hoàn toàn trách nhiệm, kỷ luật của bộ môn và nhà trường đề ra nếu như có vấn
đề xảy ra.


LỜI CẢM ƠN
Để bài đồ án này đạt kết quả tốt đẹp, em đã nhận được sự hỗ trợ, giúp đỡ của
nhiều cơ quan, tổ chức, cá nhân. Với tình cảm sâu sắc, chân thành cho phép em
được bày tỏ lòng biết ơn sâu sắc đến tất cả các cá nhân và cơ quan đã tạo điều kiện
giúp đỡ trong quá trình học tập và nghiên cứu đề tài.
Trước hết em xin gửi tới các thầy cô khoa Công nghệ thông tin trường Đại
học Tài nguyên và môi trường Hà Nội lời chúc sức khỏe và lời cảm ơn sâu sắc nhất.
Với sự quan tâm, dạy dỗ, chỉ bảo tận tình chu đáo của thầy cô, đến nay em đã có thể
hoàn thành đồ án, đề tài: "Nghiên cứu kiểm thử phần mềm và công cụ kiểm thử
phần mềm tự động JMeter"
Đặc biệt em xin gửi lời cảm ơn chân thành nhất tới cô giáo – ThS.Phí Thị Hải
Yến đã quan tâm giúp đỡ, hướng dẫn em hoàn thành tốt bài đồ án tốt nghiệp này
trong thời gian qua.
Em xin bày tỏ lòng biết ơn đến lãnh đạo trường Đại học Tài nguyên và môi
trường Hà Nội, các khoa phòng ban chức năng đã trực tiếp và gián tiếp giúp đỡ em
trong suốt quá trình học tập và nghiên cứu đề tài.
Với điều kiện thời gian cũng như kinh nghiệm còn hạn chế của một học viên,
bài đồ án này không thể tránh được những thiếu sót. Em rất mong nhận được sự chỉ
bảo, đóng góp ý kiến của các thầy cô để em có điều kiện bổ sung, nâng cao ý thức
của mình, phục vụ tốt hơn công tác thực tế sau này.
Em xin chân thành cảm ơn!

Hà Nội, tháng 6 năm 2020
Sinh viên thực hiện

Đặng Thị Quỳnh


MỤC LỤC
LỜI CAM ĐOAN.....................................................................................................i
LỜI CẢM ƠN..........................................................................................................ii
MỤC LỤC............................................................................................................... iii
DANH MỤC CÁC CHỮ VIẾT TẮT....................................................................vi
DANH MỤC CÁC HÌNH.....................................................................................vii
DANH MỤC CÁC BẢNG BIỂU...........................................................................ix
MỞ ĐẦU..................................................................................................................1
1. Lý do chọn đề tài...................................................................................................1
2. Mục tiêu của đề tài................................................................................................1
3. Phương pháp nghiên cứu đề tài.............................................................................2
4. Đối tượng và phạm vi nghiên cứu đề tài................................................................2
5. Nội dung chính......................................................................................................2
6. Kết quả chính đạt được..........................................................................................3
CHƯƠNG 1. TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM THỬ
PHẦN MỀM............................................................................................................4
1.1 Chất lượng phần mềm.........................................................................................4
1.1.1 Định nghĩa chất lượng phần mềm.....................................................................4
1.1.2 Định nghĩa đảm bảo chất lượng phần mềm.....................................................4
1.2 Lỗi phần mềm.....................................................................................................4
1.2.1 Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm......................................4
1.2.2 Các nguyên nhân gây lỗi phần mềm................................................................5
1.2.3 Chi phí cho việc sửa lỗi phần mềm..................................................................6
1.2.4 Quy trình xử lý lỗi phần mềm..........................................................................7

1.3 Kiểm thử phần mềm...........................................................................................7
1.3.1 Khái niệm kiểm thử phần mềm.......................................................................7
1.3.2 Lý do cần kiểm thử phần mềm........................................................................7
1.3.3 Mục tiêu của kiểm thử phần mềm...................................................................8
1.3.4 Các nguyên tắc cơ bản của kiểm thử phần mềm.............................................8
1.4 Các phương pháp kiểm thử phần mềm...............................................................9


1.4.1 Kiểm thử tĩnh – Static testing..........................................................................9
1.4.2 Kiểm thử động – Dynamic testing..................................................................9
1.5 Các kỹ thuật cơ bản của kiểm thử phần mềm...................................................10
1.5.1 Kiểm thử hộp đen (Black Box Testing – BBT).............................................10
1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT)..........................................12
1.5.3 Kiểm thử hộp xám (Gray Box Testing – GBT)..............................................14
1.6 Quy trình kiểm thử phần mềm..........................................................................17
1.6.1 Các bước trong một quy trình kiểm thử phần mềm.......................................17
1.6.3 Quy trình xây dựng kế hoạch kiểm thử..........................................................20
1.7 Kiểm thử tự động và kiểm thử hiệu năng...........................................................21
1.7.1 Kiểm thử tự động (Automate Testing)............................................................21
1.7.2 Kiểm thử hiệu năng........................................................................................27
CHƯƠNG 2. NGHIÊN CỨU CÔNG CỤ KIỂM THỬ HIỆU NĂNG JMETER...31
2.1 Giới thiệu chung về JMeter...............................................................................31
2.2 Đặc trưng của JMeter.........................................................................................32
2.3.1 Test Plan.........................................................................................................32
2.3.2 Các thành phần của Test Plan........................................................................37
2.4 Webservice........................................................................................................39
2.5 JDBC REQUEST..............................................................................................41
Hình 2.13 Giao diện một JDBC Connection Configuration....................................41
2.6 FTP REQUEST.................................................................................................43
CHƯƠNG 3. ỨNG DỤNG CÔNG CỤ JMETER VÀO KIỂM THỬ HIỆU

NĂNG HỆ THỐNG OPEN SOURCE SIMPLCOMMERCE............................46
3.1 Giới thiệu về Open Source SimplCommerce....................................................46
3.1.1 Hệ thống Source SimplCommerce là gì ?.......................................................46
3.2 Lập kế hoạch kiểm thử.....................................................................................48
3.2.1 Môi trường kiểm thử......................................................................................48
3.2.2 Kịch bản kiểm thử.........................................................................................49
3.2.3 Phương pháp kiểm thử...................................................................................51
3.3 Thực hiện cấu hình và chạy trên Jmeter............................................................52


3.3.1 Cấu hình........................................................................................................52
3.3.2 Chạy để lấy kết quả........................................................................................54
3.4 Phân tích, báo cáo, đánh giá kết quả kiểm thử...................................................57
3.4.1 Phân tích.........................................................................................................57
3.4.2 Kết quả báo cáo kiểm thử hiệu năng...............................................................59
3.4.3 Đánh giá, kết luận...........................................................................................64
KẾT LUẬN............................................................................................................66
TÀI LIỆU THAM KHẢO.....................................................................................67


DANH MỤC CÁC CHỮ VIẾT TẮT

Thuật ngữ/
Chữ viết tắt
IEEE

Tên tiếng anh

Nghĩa tiếng việt

Institue of Electrical and

Viện kỹ thuật điện và điện tử -

Electronic Engineers

1 tổ chức phi lợi nhuận giúp
phát triển, đổi mới công nghệ

Test Cases
User
Framework

Các trường hợp kiểm thử
Tên đăng nhập
Là một tập hợp các thư viện
hoặc các lớp có thể sử dụng lại
được
Là một phần của chương trình,

Module

mỗi mô-đun đảm nhiệm 1 chức
năng riêng
Một thuật ngữ trong kiểm thử

Validate

phần mềm, chỉ sự kiểm tra tính
hợp lệ của dữ liệu trên một yếu

JDK
JRE
NTLM

Java Development Kit
Java Runtime Environment
New Technology LAN

tố của ứng dụng
Bộ ứng dụng phát triển Java
Môi trường chạy Java
Bộ giao thức bảo

Manager

mật của Microsoft nhằm cung
cấp xác thực, tính toàn vẹn và

JDBC

Java Database Connectivity

bảo mật cho người dùng
Kết nối cơ sở dữ liệu Java


DANH MỤC CÁC HÌNH
Hình 1.1 Kiểm thử hộp đen.....................................................................................10
Bảng 1.1 Ưu nhược điểm của kiểm thử hộp đen......................................................12
Bảng 1.2 Ưu nhược điểm của kiểm thử hộp trắng....................................................14

Bảng 1.3 Ưu nhược điểm của phương pháp kiểm thử hộp xám...............................15
Bảng 1.4 Bảng so sánh ba phương pháp kiểm thử...................................................16
Hình 1.2 Quy trình kiểm thử phần mềm..................................................................19
Hình 1.3 Mô hình phát triển và kiểm thử phần mềm hình chữ V.............................19
Hình 1.4 Quy trình kiểm thử tự động......................................................................24
Hình 1.5 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra..............................25
Hình 1.6 Quy trình kiểm thử hiệu năng...................................................................29
Hình 2.1 Mô phỏng tải trọng lớn trong Jmeter........................................................32
Hình 2.2 Mở file chạy tool Jmeter...........................................................................33
Hình 2.3 Giao diện của JMeter................................................................................33
Hình 2.4 Chọn template..........................................................................................34
Hình 2.5 Đặt tên các bước.......................................................................................34
Hình 2.6 Thêm các Listener.....................................................................................35
Hình 2.7 Chỉnh sửa HTTP Proxy Server.................................................................36
Hình 2.8 Lưu kế hoạch kiểm thử.............................................................................36
Hình 2.9 Thực hiện chạy Test Plan..........................................................................37
Hình 2.10 Các bước tạo 1 SOAP WebService Test Plan..........................................40
Hình 2.11 Nhập thông tin cho Header Manager......................................................40
Hình 2.12 Nhập các thông tin tương ứng cho webservice.......................................40
Hình 2.14 Mô tả Driver type....................................................................................41
Hình 2.15 Giao diện JDBC Request........................................................................42
Hình 2.16 Giao diện JDBC Request........................................................................43
Hình 2.17 Tạo một FTP Test Plan............................................................................44
Hình 2.18 Thêm FTP connection param..................................................................44
Hình 2.19 Lấy dữ liệu bằng file Zilla......................................................................44
Hình 2.20 Kiểm tra với phương thức GET..............................................................45


Hình 3.1 Trang chủ của SimplCommerce................................................................46
Hình 3.2 Trang giao diện sản phẩm.........................................................................46

Hình 3.3 Trang giao diện giỏ hàng..........................................................................47
Hình 3.4 Trang giao diện thẻ thanh toán..................................................................47
Hình 3.5 Trang giao diện Admin của website..........................................................48
Hình 3.6 Test Plan được jmeter ghi lại với kịch bản kiểm thử số 1 (mua hàng cơ bản)52
Hình 3.7 Đặt Module, Assertion, Timer, Listener, User Parameter, Regular
Expression...............................................................................................................53
Hình 3.8 Cấu hình cho Thread, Loop, Ram-up........................................................54
Hình 3.9 Di chuyển đến thư mục bin jmeter............................................................55
Hình 3.10 Chạy lệnh tạo ra report html...................................................................55
Hình 3.11 Cửa sổ command prompt sau khi tạo xong report...................................56
Hình 3.12 File csv report được tạo thành công........................................................56
Hình 3.13 File html report được tạo thành công sau khi csv file được tạo ra...........57
Hình 3.14 View report dashboard............................................................................57
Hình 3.15 Bảng Statistics........................................................................................58
Hình 3.16 Error và Top 5 Error................................................................................58


DANH MỤC CÁC BẢNG BIỂU
Bảng 1.1 Ưu nhược điểm của kiểm thử hộp đen......................................................12
Bảng 1.2 Ưu nhược điểm của kiểm thử hộp trắng....................................................14
Bảng 1.3 Ưu nhược điểm của phương pháp kiểm thử hộp xám...............................15
Bảng 1.4 Bảng so sánh ba phương pháp kiểm thử...................................................16
Bảng 3.1 Môi trường máy chịu tải...........................................................................48
Bảng 3.2 Môi trường máy đẩy tải............................................................................49
Bảng 3.3 Kịch bản kiểm thử....................................................................................49
Bảng 3.4 Tình huống test.........................................................................................51
Bảng 3.4 Cấu hình cho Thread, Loop, Ram-up.......................................................54
Bảng 3.5 Kết quả số lượng người truy cập tối đa....................................................59
Bảng 3.6 Kết quả test thực tế...................................................................................60

MỞ ĐẦU
1.Lý do chọn đề tài
Cùng với sự phát triển vượt bậc của ngành nghề công nghệ thông tin, ngành
công nghệ phần mềm đang dần chiếm một vị trí quan trọng trong xu hướng phát
triển của nền kinh tế công nghiệp hoá, hiện đại hóa đất nước. Việc phát triển của
công nghệ phần mềm, việc đảm bảo chất lượng phần mềm luôn là một thách thức lớn
đối với bản thân của mỗi một người làm phần mềm. Ở Việt Nam hiện nay, việc kiểm
thử phần mềm chưa thực sự được coi trọng, khi mà tỷ lệ kỹ sư kiểm thử phần mềm ở
nước ta đang ở mức khá thấp. Trong khi đó theo mức chuẩn quốc tế thì tỷ lệ này cần
được giữ ở mức 3:1 nghĩa là cứ ba lập trình viên thì phải có một kiểm thử. Tiếp đó,
mức độ đáp ứng của kỹ sư kiểm thử phần mềm ở Việt Nam chưa cao do thiếu hụt các
đơn vị đào tạo chuyên sâu về kiểm thử và nước ta vẫn chưa trú trọng vào đào tạo
chuyên nghiệp cũng như có sự đầu tư đúng mức cho việc đào tạo ngành nghề này.
Để làm ra một phần mềm vừa đáp ứng được nhu cầu của người dùng, vừa
không gây thiệt hại đối với người sản xuất khi có lỗi xảy ra thì công đoạn kiểm thử
phần mềm là một công đoạn vô cùng quan trọng. Kiểm thử phần mềm là công đoạn
kiểm thử nhằm đảm bảo rằng tất cả các thành phần của phần mềm hoạt động ăn
khớp với nhau, vận hành như mong đợi và đạt được các tiêu chí thiết kế của nhà sản
xuất. Hoạt động kiểm thử phần mềm là một phần quan trọng của tiến trình phát triển
phần mềm. Nó góp phần nâng cao chất lượng của phần mềm, là một quy trình bắt
buộc trong dự án phát triển phần mềm của đất nước.
Nên với mong muốn mọi người có một cái nhìn xác thực hơn, rõ ràng hơn về
kiểm thử phần mềm và tiếp cận gần với công cụ kiểm thử phần mềm tự động Jmeter
để làm tiền đề cho việc định hướng tương lai sau khi tốt nghiệp của chính bản thân
em. Em quyết định lựa chọn đề tài “Nghiên cứu kiểm thử phần mềm và công cụ
kiểm thử phần mềm tự động JMeter” làm đề tài cho đồ án tốt nghiệp của mình.
2.Mục tiêu của đề tài
2.1. Mục tiêu chung:
Giúp mọi người có một cách nhìn khách quan và tổng quát nhất về kiểm thử

phần mềm cũng như là các công cụ kiểm thử phần mềm tự động, trong đó có công
cụ kiểm thử phần mềm Jmeter


2.2. Mục tiêu cụ thể:
- Nắm được kiến thức về kiểm thử phần mềm, quy trình thực hiện, triển khai
công việc kiểm thử phần mềm
- Hiểu rõ các thành phần của bộ công cụ JMeter
- Nắm được cách thức sử dụng bộ công cụ JMeter
- Ứng dụng được 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 phần mềm quản lý bán hàng
3. Phương pháp nghiên cứu đề tài
- Phương pháp nghiên cứu lý thuyết: Thu thập và nghiên cứu các tài liệu về
kiểm thử phần mềm và tài liệu về bộ công cụ kiểm thử phần mềm JMeter
- Phương pháp tổng hợp: Tổng hợp các tài liệu, giới thiệu cơ sở lý thuyết về
kiểm thử phần mềm.
- Phương pháp thực nghiệm: Tiến hành test thử ứng dụng đã xây dựng để
kiểm tra kết quả đạt được.
4. Đối tượng và phạm vi nghiên cứu đề tài
4.1. Đối tượng
- Cơ sở lý thuyết về kiểm thử phần mềm, kiểm thử hiệu năng website
- Công cụ kiểm thử phần mềm tự động JMeter
4.2. Phạm vi nghiên cứu
- Tìm hiểu cơ sở lý thuyết về kiểm thử phần mềm, kiểm thử hiệu năng website
- Nghiên cứu, tìm hiểu cách sử dụng, thao tác với công cụ kiểm thử hiệu năng
Jmeter để thực hiện các kỹ thuật kiểm thử hiệu năng website
5. Nội dung chính
Đồ án được chia thành 3 phần như sau:
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, kiểm thử tự động và kiểm thử hiệu năng.


Chương 2: 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ề web service,
tạo test plan web service, tạo test plan cho JDBC.
Chương 3: Ứng dụng công cụ Jmeter vào kiểm thử hiệu năng hệ thống
Opensource SimplCommerce
Chương tập trung giới thiệu hệ thống của website, các chức năng chính khi
người dùng đăng nhập hệ thống, 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ả.
6. 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
SimplCommerce sử dụng công cụ JMeter Apache, em đã đạt được một số kết quả
như sau:
- Nắm được các phương pháp, kỹ thuật kiểm thử phần mềm
- Cài đặt được công cụ JMeter
- Ứng dụng được JMeter vào kiểm thử hiệu năng hệ thống Open Source
Simplcomerce
Bên cạnh những kết quả đạt được, đề tài còn có những hạn chế như sau:
- 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.


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 em sẽ trình bày một số định nghĩa
tiêu biểu [1].
Định nghĩa theo IEEE:
Đị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: 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: Đảm bảo chất lượng phần mềm (Soft are
quality assure) 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
để 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 [2].
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
Đị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
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:
- 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.
+ 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.
- 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
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.
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 [1].
Có thể định nghĩa một cách dễ hiểu như sau:
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ỏ.
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
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.
- 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. Việc đánh giá, định hướng
hoặc kiểm tra phần mềm đượ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 [2].
1.4.1 Kiểm thử tĩnh – Static testing
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 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
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
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ử
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
giống như một hộp đen mà bên trong người ta không thể nhìn thấy. Phương pháp
này thực hiện để tìm ra 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.
- 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. 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 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.


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:
Bảng 1.1 Ưu nhược điểm của kiểm thử hộp đen
Ưu điểm
Nhược điểm

Phù hợp, hiệu quả khi số lượng các Bị giới hạn độ bao phủ của các trường hợp
dòng lệnh của hệ thống lớn.
Không cần truy cập vào các dòng

kiểm thử.
Sẽ không hiệu quả bởi thực tế các tester bị giới

lệnh.
Phân biệt được rõ ràng quan điểm

hạn kiến thức về hệ thống.
Độ bao phủ sẽ bị thiếu vì tester không kiểm tra

của người dùng với quan điểm của được các đoạn lệnh của hệ thống hoặc tập
nhà phát triển.
trung vào các dòng lệnh dễ xảy ra lỗi.
Không cần đòi hỏi những kiến thức Sẽ khó để có thể thiết kế đầy đủ các trường
về ngôn ngữ lập trình ở các tester

hợp kiểm thử.

để có thể kiểm thử hệ thống.
1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT)
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) có đá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 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à:
+ 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.
+ 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.
+ 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. Để
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.