NGHIÊN cứu CÔNG cụ KIỂM THỬ JMETER và ỨNG DỤNG TRONG KIỂM THỬ dự án PHẦN mềm QUẢN lý bán túi XÁCH

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 CÔNG CỤ KIỂM THỬ JMETER VÀ
ỨNG DỤNG TRONG KIỂM THỬ DỰ ÁN PHẦN MỀM
QUẢN LÝ BÁN TÚI XÁCH

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


NGUYỄN THỊ MINH PHƯƠNG
NGHIÊN CỨU CÔNG CỤ KIỂM THỬ JMETER VÀ
ỨNG DỤNG TRONG KIỂM THỬ DỰ ÁN PHẦN MỀM QUẢN
LÝ BÁN TÚI XÁCH

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

NGƯỜI HƯỚNG DẪN: TS.TRƯƠNG XUÂN QUANG
ThS.PHẠM THỊ THANH THỦY

Hà Nội – Năm 2020


1

LỜI CAM ĐOAN
Những nội dung trong đồ án tốt nghiệp này là thành quả từ sự nghiên cứu và
được thực hiện dưới sự trực tiếp hướng dẫn của giảng viên hướng dẫn TS. Trương
Xuân Quang và ThS. Phạm Thị Thanh Thủy.
Đồ án được thực hiện hoàn toàn mới, là thành quả của riêng em, không sao
chép theo bất cứ đồ án tương tự nào. Mọi sự tham khảo sử dụng trong đồ án đều
được trích dẫn các nguồn tài liệu trong báo cáo và danh mục tài liệu tham khảo.
Mọi sao chép không hợp lệ, vi phạm quy chế của nhà trường, em xin hoàn
toàn chịu trách nhiệm.
Sinh viên thực hiện

Nguyễn Thị Minh Phương


2

LỜI CẢM ƠN
Để hoàn thành được đề tài đồ án tốt nghiệp này, trước hết em xin gửi lời cảm
ơn chân thành nhất đến các Cán bộ Giảng viên Khoa Công nghệ Thông tin, các cán
bộ giảng viên trong Trường Đại học Tài nguyên Môi trường Hà Nội đã tận tình
giảng dạy và truyền đạt kiến thức cho em. Đồng thời em xin gửi lời cảm ơn đặc biệt
về sự chỉ dạy, hướng dẫn tận tình của TS. Trương Xuân Quang và ThS. Phạm Thị
Thanh Thủy đã luôn tận tình hướng dẫn, giúp đỡ em trong suốt thời gian thực hiện
đồ án.
Em cũng xin gửi lời cảm ơn tới Khoa Công nghệ Thông tin – Trường Đại Học
Tài nguyên Môi trường Hà Nội đã luôn quan tâm và tạo điều kiện giúp em hoàn
thành đề tài đồ án tốt nghiệp này. Ngoài ra, em xin cảm ơn những người bạn đã giúp
đỡ và trao đổi thêm nhiều thông tin về đề tài trong quá trình thực hiện đề tài này.
Cuối cùng em vô cùng biết ơn gia đình và bạn bè, những người đã luôn luôn ở
bên cạnh em, động viên, chia sẻ với em trong suốt thời gian thực đề tài đồ án tốt

nghiệp “ Nghiên cứu công cụ kiểm thử JMeter và ứng dụng trong kiểm thử dự
án phần mềm quản lý bán túi xách”.
Do kiến thức còn hạn chế, bài báo cáo của em không tránh khỏi những sai sót.
Rất mong nhận được những lời góp ý từ quý Thầy cô để đồ án tốt nghiệp của em
được hoàn thiện và giúp em có thêm những kinh nghiệm quý báu.
Cuối cùng, em xin kính chúc các thầy cô giảng viên trường Đại học Tài
nguyên và Môi trường Hà Nội nói chung, các thầy cô khoa công nghệ thông tin nói
riêng dồi dào sức khỏe và thành công trong sự nghiệp cao quý.
Hà Nội, tháng 5 năm 2020
Sinh viên thực hiện

Nguyễn Thị Minh Phương


3

MỤC LỤ

LỜI CAM ĐOAN.....................................................................................................i
LỜI CẢM ƠN..........................................................................................................ii
MỤC LỤC............................................................................................................... iii
DANH MỤC HÌNH ẢNH.......................................................................................v
DANH MỤC CÁC BẢNG BIỂU..........................................................................vii
DANH MỤC CHỮ VIẾT TẮT............................................................................viii
MỞ ĐẦU..................................................................................................................1
1. Lý do chọn đề tài...................................................................................................1
2. Mục tiêu................................................................................................................2
3. Nội dung chính......................................................................................................2
CHƯƠNG 1. PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM..................................4
1.1 Phần mềm và các khái niệm liên quan.................................................................4

1.1.1 Phần mềm.........................................................................................................4
1.1.2 Lỗi phần mềm...................................................................................................4
1.1.3 Chất lượng và độ tin cậy của phần mềm...........................................................7
1.2 Kiểm thử phần mềm............................................................................................9
1.2.1 Khái niệm.........................................................................................................9
1.2.2 Lý do cần kiểm thử phần mềm.........................................................................9
1.2.3 Vai trò của kiểm thử phần mềm........................................................................9
1.2.4 Các cấp độ trong kiểm thử phần mềm............................................................10
1.2.5 Quy trình kiểm thử phần mềm........................................................................14
1.2.6 Phân loại kiểm thử phần mềm........................................................................19
1.2.7 Các mức độ nghiêm trọng của lỗi...................................................................25
1.2.8 Kiểm thử tự động............................................................................................27
1.2.9 Nguyên tắc quan trọng trong kiểm thử phần mềm..........................................30
CHƯƠNG 2. CÔNG CỤ KIỂM THỬ JMETER................................................32
2.1 Giới thiệu chung về JMeter...............................................................................32


4
2.2 Ưu điểm và nhược điểm của JMeter [12]..........................................................33
2.3 Cài đặt JMeter....................................................................................................35
2.4 Các thành phần chính của JMeter......................................................................36
2.4.1 Test Plan.........................................................................................................36
2.4.2 Các thành phần của Test Plan.........................................................................36
2.4.3 Một số chức năng thường được sử dụng trong JMeter....................................38
2.4.4 Tạo Test Plan..................................................................................................46
CHƯƠNG 3. XÂY DỰNG PHẦN MỀM QUẢN LÝ BÁN TÚI XÁCH............50
3.1 Giới thiệu về phần mềm quản lý bán túi xách World Bag..................................50
3.1.1 Giới thiệu chung về phần mềm quản lý bán túi xách World Bag....................50
3.2 Giao diện và một số chức năng chính của phần mềm quản lý bán túi xách World
Bag.......................................................................................................................... 59

CHƯƠNG 4. XÂY DỰNG CÁC KỊCH BẢN VÀ THỬ NGHIỆM KIỂM THỬ
HIỆU NĂNG PHẦN MỀM BÁN TÚI XÁCH BẰNG CÔNG CỤ JMETER....63
4.1 Xây dựng kịch bản kiểm thử..............................................................................63
4.1.1 Môi trường kiểm thử.......................................................................................63
4.1.2 Kịch bản kiểm thử..........................................................................................64
4.1.3 Phương pháp kiểm thử....................................................................................65
4.2 Thực hiện cấu hình và chạy trên JMeter............................................................66
4.2.1 Cấu hình.........................................................................................................66
4.2.2 Thực hiện chạy các kịch bản để lấy kết quả....................................................68
4.3 Phân tích, báo cáo, đánh giá kết quả kiểm thử...................................................71
4.3.1 Phân tích.........................................................................................................71
4.3.2 Kết quả báo cáo kiểm thử hiệu năng...............................................................72
4.3.3 Đánh giá, kết luận...........................................................................................78
KẾT LUẬN VÀ KIẾN NGHỊ...............................................................................80
TÀI LIỆU THAM KHẢO

DANH MỤC HÌNH ẢN


5

Hình 1.1: Kiểm thử hộp đen....................................................................................20
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.................................................24
Hình 2.1: Các loại Performance Testing trong JMeter.............................................32
Hình 2.2: Mô phỏng tải trọng lớn trong JMeter.......................................................33
Hình 2.4: Giao diện chính của JMeter.....................................................................36
Hình 2.5: HTTP Request.........................................................................................39
Hình 2.6: FTP Request............................................................................................40
Hình 2.7: JDBC Request.........................................................................................41

Hình 2.8: CSV Data Set Config...............................................................................42
Hình 2.9: Tạo Thread Group....................................................................................46
Hình 2.10: Tạo HTTP Request Default....................................................................46
Hình 2.11: Nhập dữ liệu URL..................................................................................47
Hình 2.12: Tạo HTTP Request................................................................................47
Hình 2.13: Thiết lập Listener...................................................................................48
Hình 2.14: Thực hiện chạy......................................................................................48
Hình 2.15: Kết quả sau khi chạy..............................................................................49
Hình 2.16: Kết quả nhận được.................................................................................49
Hình 3.1: Biểu đồ use case cho toàn hệ thống.........................................................50
Hình 3.2: Biểu đồ phân rã chức năng quản lý sản phẩm và danh mục sản phẩm.....51
Hình 3.3: Biểu đồ use case cho toàn hệ thống.........................................................52
Hình 3.4: Biểu đồ phân rã chức năng quản lý thông tin shop..................................53
Hình 3.5: Biểu đồ phân rã chức năng quản lý giao diện website.............................54
Hình 3.6: Biểu đồ tuần tự ca đăng nhập...................................................................55
Hình 3.7: Biểu đồ tuần tự ca đăng nhập...................................................................55
Hình 3.8: Biểu đồ tuần tự cho chức năng mua hàng................................................56
Hình 3.9: Biểu đò tuần tự cho chức năng tìm kiếm.................................................56
Hình 3.10: Biểu đồ tuần tự cho chức năng xem chi tiết thông tin sản phẩm............57


6
Hình 3.11: Quan Hệ giữa các bảng trong CSDL......................................................58
Hình 3.12: Giao diện người dùng của website phần mềm quản lý bán túi xách......59
Hình 3.13: Chức năng đăng kí.................................................................................59
Hình 3.14: Chức năng đăng nhập............................................................................60
Hình 3.15: Chức năng tìm kiếm sản phẩm...............................................................60
Hình 3.16: Chi tiết sản phẩm...................................................................................61
Hình 3.17: Chức năng giỏ hàng...............................................................................61
Hình 3.18: Chức năng mua hàng.............................................................................62

Hình 4.1: Test Plan sau khi được import vài Jmerter...............................................67
Hình 4.2: Thiết lập các module................................................................................67
Hình 4.3: Cấu hình Thread, Loop, Ram-up.............................................................68
Hình 4.4: Di chuyển đến thư mục bin JMeter..........................................................68
Hình 4.5: Chạy lệnh tạo ra report html....................................................................69
Hình 4.6: Cửa sổ command prompt sau khi tạo xong report....................................69
Hình 4.7: File csv report được tạo thành công.........................................................70
Hình 4.8: File Html report được tạo thành công sau khi CSV file được tạo ra........70
Hình 4.9: View report dashboard.............................................................................71
Hình 4.10: Bảng Statistics.......................................................................................71
Hình 4.11: Error và Top 5 Error...............................................................................72


7
DANH MỤC CÁC BẢNG BIỂU
Bảng 1.1: Mức độ nghiêm trọng của lỗi..................................................................26
Bảng 2.1: Các kí tự viết tắt trong Non- GUI............................................................43
Bảng 2.2: Các thành phần của Aggegate Report......................................................45
Bảng 4.1: Môi trường máy chịu tải..........................................................................63
Bảng 4.2: Môi trường máy đẩy tải...........................................................................63
Bảng 4.3: Kịch bản kiểm thử...................................................................................64
Bảng 4.4: Tình Huống Test......................................................................................65
Bảng 4.5: Kết quả số lượng người truy cập tối đa...................................................72
Bảng 4.6: Kết quả Test Thực Tế..............................................................................73


8
DANH MỤC CHỮ VIẾT TẮT
IEEE
QA

PM
CC
BCC
HTTP
HTTPS
JDK
IP
KPI
CSDL

Institute of Electrical and Electronics Engineers
Quality Assurance
Project Manager
Carbon Copy
Blind Carbon Copy
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
Java Development Kit
Internet Protocol
Key Performance Indicator
Cơ Sở Dữ Liệu


1
MỞ ĐẦU
1. Lý do chọn đề tài
Ngày nay, công nghệ thông tin nói chung và công nghệ phần mềm nói riêng
đang chiếm một vị trí quan trọng trong trong cuộc sống của chúng ta. Trong cuộc
sống tất bật hiện nay, mọi việc đều được đơn giản và tối ưu hóa thời gian thông qua
việc ứng dụng công nghệ thông tin vào xử lý các công việc hàng ngày qua các ứng

dụng phần mềm. Vì vậy, công nghệ thông tin đang ngày càng được phát triển nhanh
chóng kéo theo đó là hệ thống mạng và các phần mềm cũng được gia tăng đáng kể.
Nhưng song song với đó luôn tiềm ẩn những lỗi không mong muốn, mang
theo những mối nguy về thiệt hại kinh tế và xã hội, đôi khi là cả những uy tín của
các doanh nghiệp và các nhà phát triển phần mềm. Những lỗi này có thể do tự bản
thân phần mềm bị hỏng vì không được kiểm duyệt kĩ lưỡng trước khi đưa cho người
dùng cuối. Cũng có thể do có người cố tình phá hoại nhằm đánh cắp thông tin cá
nhân như tài khoản ngân hàng, tài khoản điện tử, số điện thoại… Những vấn đề nan
giải cấp thiết này ngày càng có xu hướng mở rộng trong các năm gần đây, điển hình
như các vụ hacker tấn công vào tài khoản xã hội (Facebook, Instagram,…) của
người dùng, đánh cắp đi các thông tin mật và mạo danh lừa đảo. Ví dụ điển hình
trong thời gian gân đây là sự cố phần mềm xe hơi Mazda, sự cố gây chết máy đột
ngột hàng loạt xe hơi tại Mỹ đã ảnh hưởng đến danh tiếng của hãng và làm người sử
dụng hoang mang. Qua ví dụ này cho thấy chất lượng của các phần mềm phải được
quan tâm và kiểm tra cẩn thận nhiều lần trước khi đưa vào sử dụng. Bởi vì, kiểm
thử phần mềm là một trong những quy trình đảm bảo phần mềm hoạt động chính
xác theo yêu cầu của thiết kế và cũng nhằm ngăn chặn các lỗi hay hỏng hóc còn
tiềm tàng bên trong phần mềm. Đối với các phần mềm gồm nhiều mô - đun hay
nhiều người cùng tham gia phát triển thì công việc kiểm thử phần mềm sẽ mất rất
nhiều thời gian, công sức và độ chính xác không đảm bảo nếu làm thủ công.
Để rút ngắn thời gian, công sức và đem lại hiệu quả cao cho việc kiểm thử
phần mềm cần có các cộng vụ kiểm thử tự động (Automatic Testing). Hiện nay,
JMeter là một trong những công cụ hỗ trợ kiểm thử nổi trội nhất cho các ứng dụng
Web vì nó hoạt động được hầu hết trên các hệ điều hành và trình duyệt Chrome,


2
Cốc Cốc,… hỗ trợ đa giao thức và hoàn toàn miễn phí cho người sử dụng nên được
đánh giá rất cao.
Đối với sinh viên ngành Công nghệ thông tin, kiến thức và kỹ năng về kiểm

thử phần mềm là một trong những tiêu chí quan trọng trong đánh giá chất lượng
chuẩn đầu ra của chương trình đào tạo tại Nhà trường. Do đó, việc thực hiện đồ án
với tên đề tài “Nghiên cứu công cụ kiểm thử JMeter và ứng dụng trong kiểm
thử dự án phần mềm quản lý bán túi xách” là rất cần thiết.
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:
Chương 1: 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ề phần mềm, 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: Công cụ 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.
Chương 3: Xây dựng phần mềm quản lý bán túi xách: Chương này giới
thiệu,trình bày khái quát về phần mềm quản lý bán túi xách cùng các biểu đồ
usecase, biểu đồ tuần tự, biểu đồ phân rã các chức năng chính của phần mềm quản
lý bán túi xách.


3
Chương 4: Xây dựng các kịch bản và thử nghiệm kiểm thử hiệu năng

phần mềm bán túi xách bằng công cụ JMeter: Chương này tập trung xây dựng
các kịch bản kiểm thử và tiến hành kiểm thử trên công cụ JMeter.
4. Phương pháp nghiên cứu
- 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.
- Phương pháp tổng hợp: Tổng hợp các tài liệu về kiểm thử phần mềm.
- Phương pháp thực nghiệm: Tiến hành xây dựng các kịch bản kiểm thử và ứng
dụng test với công cụ kiểm thử tự động JMeter.
5. Kết quả đạt được
- Nắm được các phương pháp, kĩ thuật kiểm thử phần mềm.
- Cài đặt thành công công cụ Jmeter
- Ứng dụng thành công Jmeter cho kiểm thử hiệu năng phần mềm quản lý bán túi
xách World Bag.


4
CHƯƠNG 1. PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM
1.1 Phần mềm và các khái niệm liên quan
1.1.1 Phần mềm
- Phần mềm (Software) có thể hiểu là một tập hợp các tập tin có mối liên hệ
chặt chẽ với nhau, đảm bảo thực hiện một số nhiệm vụ, chức năng nào đó trên thiết
bị điện tử. Các tập tin này có thể bao gồm: các file mã nguồn viết bằng một hoặc
nhiều ngôn ngữ lập trình, các file dữ liệu (thư viện), các file hướng dẫn. [4]
- Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếp
đến phần cứng (Hardware) hoặc cung cấp dữ liệu để phục vụ các chương trình hay
phần mềm khác.
- Việc thực thi nhiệm vụ có thể thể là tự động hoặc thực hiện theo các thông
tin, dữ liệu đầu vào.
Theo IEEE (1991): Phần mềm là các chương trình máy tính kết với các dữ liệu
hoặc các tài liệu hướng dẫn, đặc tả, v.v. thường gồm 4 phần được mô tả dưới đây:

 Chương trình máy tính: Thành phần này giúp cho máy tính thực thi các ứng
dụng được yêu cầu.
 Quy trình: Là thành phần xác định trình tự và kế hoạch trong đó các chương
trình được thực hiện, phương pháp sử dụng và những người chịu trách nhiệm cho
các hoạt động của kế hoạch.
 Các tài liệu: Có rất nhiều những tài liệu cần thiết với nhân viên phát triển,
người sử dụng và nhân viên bảo trì như: tài liệu thiết kế, tài liệu hướng dẫn sử dụng,
tài liệu hướng dẫn bảo trì.
 Dữ liệu: Dữ liệu bao gồm tham số, mã nguồn và các danh sách thích ứng của
phần mềm dành riêng cho người dùng cụ thể là dành cho hoạt động phần mềm. [5]


5
1.1.2 Lỗi phần mềm
1.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ó". [10]
- 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.1.2.2 Các nguyên nhân gây lỗi phần mềm [5]
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ừ


6
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


7
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.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.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.
1.1.3 Chất lượng và độ tin cậy của phần mềm
1.1.3.1 Chất lượng của 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) [5]:


8
- Đị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.
Đị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
(Software 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.
1.1.3.2 Độ tin cậy của phần mềm
Độ tin cậy của một hệ phần mềm là độ đo về mức độ tốt của các dịch vụ mà hệ
cung cấp cho máy tính. Cần chú ý là người dùng không xét rằng các dịch vụ là quạn
trọng như nhau: chẳng hạn, một hệ điều khiển máy bay có thể hiếm khi thất bại,
nhưng nếu chúng có thất bại gây ra tai nạn máy bay thì các người bị nạn và thân
nhân người bị nạn không thể xem hệ đó là đáng tin.
Độ tin cậy là một đặc trưng động của hệ thống, nó là một hàm của số các thất
bại phần mềm. Một thất bại phần mềm là một sự kiện thi hành mà khi đó phần mềm
hành xử không như người ta mong đợi. Chú ý rằng một thất bại phần mềm khác một
hư hỏng phần mềm. Hư hỏng phần mềm là một đặc trưng tĩnh, và nó sẽ gây ra thất
bại phần mềm khi mà mã lỗi được thi hành với một tập hợp đặc biệt các thông tin
vào. Các hư hỏng không phải luôn luôn xuất đầu lộ diện, vì vậy độ tin cậy phụ
thuộc vào việc sử dụng hệ thống như thế nào. Không thể đưa ra một phát biểu đơn
giản và khái quát về độ tin cậy phần mềm.


9
Các hư hỏng phần mềm không phải là các khuyết tật của chương trình. Một
hành xử bất ngờ có thể xảy ra khi mà phần mềm phù hợp với các yêu cầu của nó,
nhưng mà chính các yếu tố đó lại không đầy đủ. Các sai sót trong các tư liệu phần
mềm cũng có thể dẫn đến các hành vi bất ngờ mặc dầu rằng phần mềm không có
khiếm khuyết.
Có công trình nghiên cứu đã chỉ ra rằng có thể rút bỏ 60% các khiếm khuyết
mà chỉ có thể cải tạo được 3% độ tin cậy. Cũng có người đã chú ý rằng nhiều khiếm
khuyết trong sản phẩm chỉ là kết quả của hàng trăm hoặc hàng nghìn tháng sử dụng.
1.2 Kiểm thử phần mềm
1.2.1 Khái niệ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 [2]:
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.2.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ỏ.


10
1.2.3 Vai trò 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.2.4 Các cấp độ trong kiểm thử phần mềm
Có rất nhiều cách để chia cấp độ kiểm thử phần mềm, nhưng tựu chung lại sẽ
gồm 4 cấp độ sau:
4.2.4.1 Kiểm thử đơn vị (Unit Testing )[9]:

- Kiểm thử đơn vị là kiểm tra từng đơn vị phần mềm xem có hoạt động đúng
thiết kế hay không?
- Đơn vị dòng lệnh, nhóm dòng lệnh, một hàm, một thủ tục phục vụ một
nghiệp vụ nào đó, module, một chương trình sản phẩm. Mức độ đơn vị lớn nhỏ do
người thực hiện làm kiểm thử đơn vị quyết định. Để mức độ càng nhỏ cơ hội tìm
lỗi, khắc phục lỗi càng lớn.
- Mục tiêu của kiểm thử đơn vị:
 Giảm rủi ro liên quan đến chất lượng sản phẩm, giúp xác minh việc
hoạt động của các yêu cầu chức năng, yêu cầu phi chức năng của các
thành phần có đúng mô tả thiết kế không?
 Xác định được sự tự tin vào chất lượng của thành phần sản phẩm, tìm
lỗi trong các thành phần sản phẩm, ngăn chặn lỗi lọt đến các giai đoạn
kiểm thử sau.
- Lí do cần kiểm thử đơn vị:
 Hỗ trợ xác định vị trí lỗi nhanh hơn
 Giảm chi phí, tăng chất lượng sản phẩm
- Kiểm thử đơn vị là giai đoạn đầu tiên của việc kiểm thử.


11
- Các dữ liệu đầu vào của Kiểm thử đơn vị: thiết kế chi tiết, code, mô hình dữ
liệu, đặc tả về thành phần sản phẩm.
- Các loại kiểm thử đơn vị: Kiểm thử câu lệnh, kiểm thử quyết định hay
nhánh, kiểm thử điều kiện, kiểm thử đường đi.
- Người thực hiện kiểm thử đơn vị là Dev
- Lỗi thường gặp khi kiểm thử đơn vị:
 Chức năng hoạt động không chính xác (không được mô tả trong tài liệu
thiết kế chi tiết)
 Các vấn đề về luồng dữ liệu
 Code và logic của code không chính xác

4.2.4.2 Kiểm thử tích hợp (Integration Testing)[9]:
Kiểm thử tích hợp là việc kiểm tra về kết nối giữa các thành phần của 1 hệ
thống hoặc giữa các hệ thống phần mềm tập trung vào kiểm thử sự giao tiếp hay kết
nối về giao diện giữa các thành phần của 1 phần mềm hay các hệ thống với nhau.
- Mục tiêu của kiểm thử tích hợp:
 Giảm rủi ro liên quan đến chất lượng sản phẩn, giúp xác minh sự kết
nối, sự giao tiếp của các chức năng qua giao diện có theo mô tả cụ thể
trong thiết kế kiến trúc, thiết kế hệ thống không?
 Xác định sự tự tin vào chất lượng của các giao diện, tìm lỗi khi thực
hiện, kiểm tra việc tích hợp có như thiết kế hệ thống không? Và ngăn
các lỗi đến sau.
- Khi nào cần kiểm thử tích hợp: Tùy thuộc vào các mức độ tích hợp, khi
thành phần đã được kiểm thử đơn vị rồi, tích hợp hệ thống khi hệ thống được kiểm
thử hệ thống rồi.
- Các dữ liệu đầu vào của kiểm thử tích hợp: thiết kế hệ thống phần mềm, thiết
kế kiến trúc, giao diện giao thức…
- Lỗi thường gặp khi kiểm thử tích hợp: dữ liệu không chính xác, dữ liệu thiếu
hoặc mã hóa không chính xác, lỗi xử lí, giả định không chính xác.
- Các loại kiểm thử tích hợp:


12
 Tích hợp đồng thời các thành phần, hệ thống cùng 1 lúc:
Ưu điểm: Hoàn thành trước khi tích hợp
Nhược điểm: Tốn thời gian, khó tìm vị trí lỗi
 Tích hợp dần dần:
Ưu điểm: Dễ phát hiện nguyên nhân gây lỗi
Nhược điểm: Tốn thời gian tạo thành phần giả lập
1.2.4.3 Kiểm thử hệ thống (System Testing)[9]:
Là kiểm thử trên một hệ thống đầy đủ bao gồm kiểm thử chức năng và kiểm

thử phi chức năng:


13
- Mục tiêu:
 Giảm rủi ro liên quan đến chất lượng sản phẩm.
 Xác minh hành vi chức năng, phi chức năng có hoạt động đúng yêu cầu
đặc tả không.
 Giúp xác thực hệ thống sẽ hình thành như mong đợi của người dùng.
- Xác định sự tự tin vào chất lượng của cả hệ thống.
- Tìm lỗi, ngăn lỗi đến giai đoạn sau.
- Lí do cần kiểm thử hệ thống.
- Kiểm tra, nhằm đảm bảo chức năng, đặc tính của một sản phẩm phần mềm
đúng đủ theo đặc tả phần mềm.
- Thực hiện kiểm thử trên một môi trường gần giống với môi trường thực
- Kiểm thử cuối cùng đại diện cho dự án, nhóm phát triển phần mềm để kiểm
tra sản phẩm trước khi bàn giao cho khách hàng.
- Khi nào cần kiểm thử hệ thống:
 Hệ thống kiểm thủ đã hoàn thiện, phát triển xong.
 Các thành phần riêng lẻ trong hệ thống đã được kiểm thử.
 Kiểm thử tích hợp đã hoàn thành.
- Các tài liệu đặc tả chức năng, phi chức năng đã chốt và không thay đổi
Testcase, Testdata phải sẵn sàng sử dụng.
- Các loại kiểm thử hệ thống: Chức năng, phi chức năng, liên quan đến thay
đổi phần mềm.
- Môi trường kiểm thử phải giống môi trường thực tế nhất có thể.
- Các dữ liệu đầu vào của Kiểm thử hệ thống: yêu cầu hệ thống, tài liệu mô tả
chức năng hệ thống, usecase, tài liệu mô tả hệ thống với một dịch vụ bên ngoài.
- Lỗi thường gặp khi kiểm thử hệ thống: tính toán không chính xác, các chức
năng, phi chức năng hoạt động không đúng, luồng không đúng.

1.2.4.4 Kiểm thử chấp nhận (Acceptance Testing)[9]:


14
- Người sử dụng chấp nhận các hành động kiểm thử được thực hiện bởi người
sử dụng cuối hay khách hàng với mục tiêu sản phẩm có đáp ứng đúng theo yêu cầu
hay thỏa mãn các tiêu chí sản phẩm đã thống nhất không.
- Mục tiêu:
 Thiết lập sự tự tin về chất lượng của toàn hệ thống.
 Xác thực rằng hệ thống đã hoàn thành và hoạt động như mong muốn
của khách hàng.
 Xác minh rằng các hành vi chức năng, phi chức năng hoạt động đúng
đặc tả.
- Lí do cần kiểm thử chấp nhận:
 Để chấp nhận sản phẩm dựa trên các tiêu chí chấp nhận đề ra từ trước.
 Đảm bảo các chức năng cần có và các chức năng mong muốn của
khách hàng được hiển thị trong sản phẩm phần mềm.
- Các dữ liệu đầu vào của kiểm thử chấp nhận: Quy trình nghiệp vụ, yêu cầu
người dùng, tiêu chuẩn pháp lí, mô tả usecase, yêu cầu hệ thống, tài liệu hệ thống,
tài liệu người dùng, các bước cài đặt, báo cáo phân tích rủi ro.
- Khi nào cần kiểm thử chấp nhận: Sau khi bàn giao và đã được thực hiện
kiểm thử hệ thống, được thực hiện bởi khách hàng hay người sử dụng tùy thuộc vào
khách hàng khi gối lên kiểm thử hệ thống.
- Các loại kiểm thử chấp nhận hoạt động đảm bảo phi chức năng được kiểm
thử đảm bảo hệ thống thỏa mãn các thông số cụ thể, sao lưu, khôi phục. Tuân thủ
kiểm thử tiêu chí, chính sách quy định thống nhất ban đầu
- Giai đoạn kiểm thử chấp nhận:
Alpha: Khách hàng người sử dụng cuối
Beta: Khách hàng người sử dụng cuối môi trường khách hàng sau Alpha
không có sự theo dõi của lập trình viên.

- Lỗi thường gặp của Kiểm thử chấp nhận.
- Luồng không thỏa mãn, quy tắc nghiệp vụ không thực hiện chính xác, lỗi
bảo mật.


15