ĐỀ tài KIỂM THỬ ỨNG DỤNG TRÊN nền KIỂM THỬ ỨNG DỤNG TRÊN nền WEB BẰNG WEB BẰNG CÔNG cụ SELENIUM
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.03 MB, 60 trang )
HỌC VIỆN NÔNG NGHIỆP VIỆT NAM
KHOA CÔNG NGHỆ THÔNG TIN
------- -------
KHÓA LUẬN TỐT NGHIỆP
ĐỀ TÀI:
KIỂM THỬ ỨNG DỤNG TRÊN NỀN WEB BẰNG
CƠNG CỤ SELENIUM
Giảng viên hướng dẫn: ThS. HỒNG THỊ HÀ
Sinh viên thực hiện:
hiện:
Vũ Khánh Huyền
Lớp:
K63HTTT
HÀ NỘI - 2022
TIEU LUAN MOI download : moi nhat
HỌC VIỆN NƠNG NGHIỆP VIỆT NAM
KHOA CƠNG NGHỆ THƠNG TIN
KHĨA LUẬN TỐT NGHIỆP
ĐỀ TÀI:
KIỂM THỬ ỨNG DỤNG TRÊN NỀN WEB BẰNG
CƠNG CỤ SELENIUM
Người thực hiện
Vũ Khánh Huyền
Khóa
63
Ngành
Cơng Nghệ Thơng Tin
Chun ngành
Người hướng dẫn
Hệ Thống Thơng Tin
ThS. Hồng Thị Hà
HÀ NỘI - 2022
1
TIEU LUAN MOI download : moi nhat
LỜI CẢM ƠN
Lời đầu tiên em xin chân thành cảm ơn các thầy, cô trong khoa Công nghệ
thông tin, trường Học Viện Nông Nghiệp Việt Nam đã tạo điều kiện thuận lợi
cho em trong quá trình học tập tại trường cũng như trong thời gian thực hiện
Khóa luận tốt nghiệp. Đặc biệt, em muốn gửi lời cảm ơn tới Thạc sỹ Hoàng Thị
Hà– giảng viên trực tiếp hướng dẫn, chỉ bảo, giúp em khắc phục những khó
khăn, thiếu sót để có thể hồn thành các phần trong khóa luận tốt nghiệp từ lý
thuyết cho tới thực hành sử dụng công cụ.
Mặc dù đã cố gắng với tất cả nỗ lực của bản thân để hồn thiện khóa luận,
nhưng do thời gian có hạn, năng lực và kinh nghiệm cịn hạn chế nên khóa luận
khơng thể tránh khỏi những thiếu sót. Kính mong nhận được sự đóng góp ý kiến
từ phía thầy cơ, bạn bè để em có thể nâng cao kiến thức của bản thân, hồn thiện
khóa luận được tốt hơn.
Em xin chân thành cảm ơn!
SINH VIÊN THỰC HIỆN
Vũ Khánh Huyền
2
TIEU LUAN MOI download : moi nhat
MỤC LỤC
LỜI CẢM ƠN............................................................................................................................2
MỤC LỤC..................................................................................................................................3
PHẦN I: MỞ ĐẦU.....................................................................................................................7
1.1
Tên đề tài
tài...
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.........
..........
.......7
..7
1.2
Đặt vấn đề.
đề.....
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.......
......7
...7
1.3
Mục đí
đích
ch – Yêu cầu.
cầu....
......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
........
.........
..........
.........7
....7
1.2.1 Mục đích:
đích:......................................................................................................7
1.2.2 Yêu cầu:........................................................................................................8
PHẦN II: TÌNH HÌNH NGHIÊN CỨU TRONG VÀ NGỒI NƯỚC................................8
2.1 Tình hình nghiên cứu trong nước......................................................................8
2.2 Tình hình nghiên cứu ngồi nước..................................................................
nước......................................... ............................9
...9
2.3 Đề tài và tính thời sự, tầm quan trọng của đề tài............................................9
tài..................................... .......9
PHẦN III: NỘI DUNG VÀ PHƯƠNG PHÁP NGHIỆN CỨU.............................................9
3.1 Địa điểm và thời gian nghiên cứu......................................................................9
a.
Nội dung nghiên cứu....
cứu...........
.............
.............
..............
.............
.............
..............
..............
.............
..............
........................9
................9
b.
Phương pháp nghiên cứu....
cứu..........
.............
..............
..............
.............
.............
..............
.............
.............
..............
..............
........10
.10
PHẦN IV: KẾT QUẢ VÀ THẢO LUẬN..............................................................................10
CHƯƠNG I: PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM.................................................10
1.1
1.1.1.
Phầ
Phần
nm
mềm
ềm và các khá
kháii n
niệm
iệm liên
liên q
quan
uan :...
:......
......
......
.......
.......
.......
.......
......
.......
.......
.......
.........
..........
......10
.10
Khái niệm:........
niệm:...............
.............
.............
..............
..............
.............
.............
..............
.............
...................
.............................10
................10
3
1.1.2.
Phân loại:.......
loại:..............
.............
.............
..............
..............
.............
.............
..............
..............
.............
.............
.........................10
..................10
Lỗi phần mềm:..
mềm:.........
..............
.............
.............
..............
.............
.............
..............
..............
......................
...........................11
............11
TIEU LUAN 1.1.3.
MOI download
:
moi nhat
1.1.4.
Yêu cầu của khách hàng:..
hàng:.........
.............
.............
..............
..............
.............
.....................
...............................12
................12
1.1.5.
Đặc tả yêu cầu phần mềm:.
mềm:........
..............
..............
.............
.............
..............
..............
.................
......................13
............13
1.1.6.
1.1.
6.
Chấ
Chấtt lượn
lượngg và độ tin cậy của phầ
phần
n mềm:
mềm:....
.......
.......
.......
......
.......
.......
......
.......
.........
..........
..........
......14
.14
1.2
Kiểm
Kiểm th
thử
ử phầ
phần
n mềm
mềm:..
:.....
.......
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.........
.........
.........
..........
..........
......14
.14
1.2.1
Khái niệm:........
niệm:...............
..............
.............
.............
..............
..............
.............
.............
..............
.............................
.............................14
.......14
1.2.2
Vai trò của kiểm thử phần mềm:...
mềm:.........
.............
..............
..............
.............
.............
..............
..................
............14
.14
1.2.3
Các cấp độ kiểm thử phần mềm:..
mềm:.........
..............
..............
.............
.............
..............
................
...................15
..........15
1.2.4
Quy trình kiểm thử phần mềm:...
mềm:..........
..............
.............
.............
..............
..............
.............
....................1
..............166
1.2.5
Phân loại kiểm thử phần mềm:..
mềm:.........
..............
.............
.............
..............
..............
.............
.............
................19
.........19
1.2.6
Các mức độ nghiê
nghiêm
m ttrọng
rọng của lỗi:.
lỗi:........
.............
.............
..............
..............
.............
.............
...................2
............233
1.2.7
1.2.88
1.2.
Ca kiểm thử:...
thử:.........
.............
..............
..............
.............
.............
..............
..............
.............
.............
..............
.........................23
..................23
Ngu
Nguyên
yên tắ
tắcc quan ttrọn
rọngg tron
trongg kiể
kiểm
m thử p
phần
hần m
mềm:.
ềm:.....
........
.........
..........
..........
..........
.......24
..24
1.3
Các kỹ tthuật
huật trong
trong ki
kiểm
ểm tthử:.
hử:....
......
.......
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
........
..........
.........2
....266
1.3.1
Kỹ thuật phân vùng tương đương:
đương:.......
..............
.............
.............
..............
..............
.............
..................26
............26
1.3.2
Kỹ thuật phân tích giá trị biên:........
biên:...............
.............
.............
..............
.....................
.............................27
...............27
1.3.3
Đốn lỗi:..
lỗi:........
.............
..............
..............
.............
.............
..............
.............
.............
..............
..............
.............
.....................
....................27
.....27
1.3.4
Kỹ thuật chuyển trạng thái:..
thái:.........
..............
..............
.............
.............
..............
.............
.............
.....................28
..............28
1.4
Kết luậ
luận:..
n:.....
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.......
......
.......
.......
......
.......
.......
......
.......
.......
.......
.......
......
........
..........
........28
...28
CHƯƠNG II: KIỂM THỬ ỨNG DỤNG TRÊN NỀN WEB...............................................29
2.1 Khái quát:..........................................................................................................29
2.2 Nội dung kiểm thử ứng dụng web:..................................................................29
4
2.2.1 Kiểm thử chức năng:.....................................................................................29
2.2.2 Kiểm thử tính khả dụng................................................................................30
2.2.3 Kiểm thử giao diện.........................................................................................30
2.2.4 Kiểm thử khả năng tương thích....................................................................31
TIEU LUAN 2.2.5
MOIKiểm
download
: moi nhat
thử hiệu năng........................................................................................31
2.2.6 Kiểm thử bảo mật...........................................................................................32
2.3 Các công cụ kiểm thử:......................................................................................32
2.3.1 Công cụ kiểm thử hiệu năng.........................................................................32
2.3.2 Công cụ kiểm thử bảo mật............................................................................33
2.3.3 Công cụ kiểm thử chức năng.........................................................................33
2.4 Kết luận:.............................................................................................................34
CHƯƠNG III: KIỂM THỬ ỨNG DỤNG TRÊN NỀN WEB BẰNG CÔNG CỤ
SELENIUM..............................................................................................................................35
3.1 Công cụ kiểm thử tự động Selenium:..............................................................35
3.1.1 Giới thiệu chung về Selenium:......................................................................35
3.1.2 Selenium IDE:................................................................................................36
3.2 Bài toán thực tế:................................................................................................49
3.2.1 Giới thiệu về website:.....................................................................................49
3.2.2 Kiểm thử các chức năng của website JVNET:............................................52
3.3 Kết luận:.............................................................................................................74
PHẦN V: KẾT LUẬN.............................................................................................................75
PHẦN VI: TÀI LIỆU THAM KHẢO....................................................................................76
5
PHẦN I: MỞ ĐẦU
1.1Tên đề tài
“Kiểm thử ứng dụng trên nền web bằng công cụ selenium”
1.2Đặt vấn đề
Ngày nay, với sự phát triển của các nền tảng thiết bị khác nhau như web,
di động, thiết bị Cloud, một sản phẩm phải hoạt động trên nhiều nền tảng khác
nhau hay phải tương thích với các sản phẩm khác là một yêu cầu bắt buộc và từ
đặt
raMOI
nhiều
thách
cácthiết
nhà nói
sản giúp
xuất,xác
phát
triển
phần
mềm.
Lúc này
TIEU đó
LUAN
:
moi
nhat
vai
trị của
kiểmdownload
thử làthức
thực cho
sự
cần
nhận
yêu
cầu,
giúp
đánh
giá
sản phẩm, tìm lỗi, ngăn ngừa lỗi…
Nhu cầu của nghề tester rất cao tuy nhiên hầu hết các bạn theo học ngành
Công Nghệ Thông Tin đều mong muốn làm nghề lập trình viên chứ khơng phải
là nghề Tester. Tại các cơng ty phần mềm nước ngồi trung bình cứ 1 lập trình
viên cần phải có tới 4 Tester, tuy nhiên ở Việt Nam tỷ lệ này lại ngược lại, với 5
lập trình viên thì mới có 1 tester. Chính sự mất cân đối này đã mở ra một nhu cầu
vô cùng lớn cho nghề Tester trong tương lai.
Bên cạnh đó, xu hướng áp dụng tự động hoá đang được triển khai rộng rãi
ở nhiều lĩnh vực, trong đó có kiểm thử phần mềm. Đặc biệt, khi kiểm thử phần
mềm là cơng đoạn chiếm phần lớn thời gian trong q trình phát triển dự án phần
mềm thì sự ra đời của các cơng cụ kiểm thử tự động càng có ý nghĩa hơn bao giờ
hết, giúp tiết kiệm thời gian, công sức và tiền bạc. Selenium là một công cụ hỗ
trợ kiểm thử tự động dành cho các ứng dụng Web, hoạt động trên hầu hết các
trình duyệt phổ biến hiện nay như Firefox, Chrome, Internet Explorer, Safari,
v.v. cũng như hỗ trợ số lượng lớn các ngơn ngữ lập trình Web phổ biến. Công cụ
Selenium hiện được đánh giá là một trong những công cụ tốt nhất cho kiểm thử
tự động các ứng dụng Web.
Trong q trình làm khóa luận, do còn hạn chế về kinh nghiệm thực tế, em
rất mong nhận được những góp ý chân thành từ thầy cơ và các bạn.
1.3 Mục đích – u cầu
1.3
1.2.1 Mục đích:
1.2.1
đích:
- Tìm hiểu lý thuyết chung về kiểm thử phần mềm.
6
- Hiểu được các công cụ hỗ trợ kiểm thử phần mềm đặc biệt là Selenium.
- Tìm hiểu sâu về các tính năng Selenium : đưa ra hướng dẫn cài đặt, sử
dụng hiệu quả bộ công cụ
- Áp dụng được kiến thức lý thuyết vừa tìm hiểu được để ứng dụng kiểm
thử cho một ứng dụng cụ thể.
1.2.2 Yêu cầu:
- Nắm vững được cơ sở lý thuyết chung vvềề kiểm thử phần mềm.
mềm.
- Nắm vững được cách sử dụng phần mềm Selenium.
Selenium.
- Áp dụng được các phương pháp về kiểm thử phần mềm.
PHẦN II: TÌNH HÌNH NGHIÊN CỨU TRONG VÀ NGỒI NƯỚC
2.1 Tình hình nghiên cứu trong nước
TIEU LUAN MOI download : moi nhat
Theo nghiên cứu của thì đến năm 2020,
nhân lực Kỹ sư kiểm thử còn thiếu trong thị trường lao động Việt Nam khoảng
10.000 người. Những ai theo học ngành CNTT đều đa phần là nghĩ ngay đến
nghề lập trình vì thế khiến đầu ra của nghề kỹ sư kiểm thử có số lượng thấp hơn
hẳn khiến các nhà tuyển dụng lao đao trong việc tìm kiếm nguồn nhân lực.
Cùng với ngành sản xuất phần mềm, Việt Nam là quốc gia có nhiều lợi thế
để trở thành quốc gia gia công phần mềm hàng đầu thế giới và đang là điểm đầu
tư lâu dài của các công ty công nghệ lớn như Samsung, LG, Renesas, Foxconn,
Fujitsu, Canon, Panasonic, HP, CSC, Sony,..Vì vậy nhu cầu sử dụng phần mềm
từ các cơng ty trong nước cũng như các đối tác nước ngoài đang gia tăng.
Hiện nay, ở Việt Nam, chưa có quy trình kiểm thử chung cho các doanh
nghiệp, các doanh nghiệp tự xây dựng và ban hành quy trình riêng cho mình.
Các kỹ thuật kiểm thử hiện đang được các doanh nghiệp hay dùng nhất, đó là:
các kỹ thuật kiểm thử dựa trên đặc tả, các kỹ thuật kiểm thử dựa trên cấu trúc
(kiểm
thử hộp
cũngnay
cóhọ
dùng
nhưng
khơngnhiều
nhiềuđến
và phải
do lập
trình
nhận. Bên
cạnhtrắng)
đó, hiện
cũng
chú trọng
các loại
kiểm
thửđảm
đặc
tính chất lượng phần mềm như: kiểm thử cài đặt, kiểm thử tương thích, kiểm thử
7
bảo mật. Ngồi việc
việc kiểm thử thủ ccơng
ơng thì một số kỹ thuật kiểm thử phải
phải sử dụng
các công cụ (tool test) để kiểm thử do số lượng các trường hợp kiểm thử lớn.
Không phải phần mềm nào viết ra cũng phù hợp cho việc kiểm thử và khơng
phải đơn vị nào cũng đủ kinh phí để sử dụng các tool test.. Đó là một trong
những khó khăn mà các đơn vị đang gặp phải.
2.2 Tình hình
hình nghiên cứu ngồi nước
nước
Testing ở thế giới đã phát triển từ lâu, nếu như ở Việt Nam ti lệ chỉ có 1
Tester thì có 5 lập trình viên nhưng ở nước ngoài tỉ lệ này là 4:1, như vậy với 4
Tester thì mới có một lập trình viên. Có thể nói Testing có rất nhiều tiềm năng
phát triển.
2.3 Đề tài và tính thời sự, tầm quan trọng của đề tài
2.3
Thỏa m
mãn
ãn nhu
nhu cầu của người
người dùng là
là việc
việc rất quan trọng
trọng khi
khi tạo
tạo ra sản
phẩm hay đảm bảo chất lượng phần mềm là một phần không thể thiếu trong quá
trình sản xuất phần mềm. Để tạo ra một sản phẩm chất lượng lại tiết kiệm kinh
phí, nguồn lực, thời gian khơng phải là một việc dễ dàng. Vì vậy, việc sử dụng
TIEU LUAN MOI download : moi nhat
công cụ hỗ trợ giúp quản lý chất lượng phần mềm được ưu tiên phát triển trong
ngành công nghệ phần mềm. Với đề tài “ Kiểm thử phần mềm và ứng dụng" sẽ
giúp ta hiểu rõ hơn việc tìm kiếm, theo dõi, xử lý, cập nhật và quản lý lỗi phát
sinh trong quá trình kiểm tra, kiểm thử phần mềm đảm bảo chất lượng phần mềm
trước khi được triển khai vào thực tế.
-
-
PHẦN III: NỘI DUNG VÀ PHƯƠNG PHÁP NGHIỆN CỨU
3.1
3.1 Địa điểm và thời gian nghiên cứu
Bộ môn Công nghệ phần mềm, khoa Công nghệ thông tin, Học viện Nông
Nghiệp Việt Nam.
Nam.
Địa điểm: Công ty TNHH Đầu tư và thương mại dịch vụ Việt Đức.
Thời gian nghiên cứu: 3 buổi/ tuần trong thời gian từ ngày 20/02/2022 đến
ngày 06/04/2021.
a. Nội
Nội dun
dungg ngh
nghiê
iên
n cứu
cứu
Tìm hiểu về lý thuyết kiểm thử phần mềm.
Tìm hiểu cách cài đặt, sử dụng cơng cụ kiểm thử tự động.
8
- Tìm hiểu tính năng, ưu điểm của Selenium.
- Ứng dụng kiểm thử trên web cụ thể.
b. Phương
Phương pháp
pháp ng
nghiê
hiên
n cứu
cứu
- Tham khảo tài liệu: Tham khảo tài liệu chuyên môn, tài liệu online,…
- Tham khảo ý kiến giáo viên hướng dẫn.
PHẦN IV: KẾT QUẢ VÀ THẢO LUẬN
Chương I: PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM
Phần đầu tiên này đi sâu vào việc tìm hiểu các khái niệm về phần mềm và
kiểm thử phần mềm, giúp khái quát việc phân loại kiểm thử phần mềm, đưa ra
các quy trình, mức độ trong kiểm thử phần mềm.
1.1 Phần mềm và
và các khái niệm liên quan
quan :
1.1.1.
1.1
.1. Khái
Khái niệm:
niệm:
Phần mềm (Software) có thể hiểu là một tập hợp các tập tin có
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
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ư
liệu (thư viện), các file hướng dẫn.
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
TIEU hay
LUAN
download : moi nhat
phầnMOI
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.
Phải có phần cứng thì phần mềm mới thực thi được. Thơng thường là máy
tính, các thiết bị giải trí truyền thông, bộ điều khiển trên máy công cụ – ô tô….
1.1.2.
1.1
.2. Phân
Phân loại:
loại:
Theo phương thức hoạt động
Phần mềm hệ thống dùng để vận hành máy tính nói riêng và các thiết bị
điện tử nói chung. Ví dụ: hệ điều hành máy tính Windows, Linux, Unix;
Các trình điều khiển (driver),
(driver), phần sụn (firmware)
(firmware) và BIOS.
BIOS. Hệ điều hành
di dộng iOS, Android, Windows Phone,…
9
Phần mềm ứng dụng – phần mềm máy tính : Các phần mềm văn phịng
(Microsoft Office, OpenOffice), trị chơi điện tử (game), các cơng cụ &
tiện ích khác (ví dụ như phần mềm quản lý chi tiêu cá nhân, phần mềm
quản lý công việc,…).
Phần mềm dịch mã (trình dịch) gồm trình biên dịch và trình thơng dịch, cụ
thể là chúng dịch các câu lệnh từ mã nguồn của ngơn ngữ lập trình sang
dạng ngơn ngữ máy sao cho thiết bị thực thi có thể hiểu được.
Nền tảng ứng dụng: như ASP.NET – nền tảng ứng dụng web của
Microsoft, cái này hỗ trợ việc tạo ra các ứng dụng web, dịch vụ web (web
service).
Theo khả năng hay quyền hạn can thiệp vào mã nguồn
Phần mềm mã nguồn đóng (closed source software): Là phần mềm mà mã
nguồn của nó không được công bố. Để sử dụng phần mềm nguồn đóng
phải được cấp bản quyền
quyền (mua, tặng là tùy).
Phần mềm mã nguồn mở (open source software): Là phần mềm mà mã
nguồn của nó được cơng bố rộng rãi, cơng khai và cho phép mọi người
tiếp tục phát triển phần mềm đó. Thường thì loại phần mềm này miễn phí.
1.1.3.
1.1
.3. Lỗi phần
phần mềm:
mềm:
Lỗi phần mềm là một lỗi hay hỏng hóc trong chương trình hoặc hệ thống máy
tính khiến nó tạo ra kết quả khơng chính xác hoặc khơng mong muốn hoặc hành
xử theo những cách không lường trước được.
Lỗi phần mềm thường xuất hiện ở các hình thức sau đây:
TIEU LUAN
download
SaiMOI
(Fault):
Khi phần :mềm
gạp lỗi sẽ đưa đến những saimoi
sót. nhat
Tuy nhiên,
khơng dễ để phát hiện ra sai sót trong q trình phát triển phần mềm. Sai
lầm có thể xuất hiện ngay ở đầu
đầu quy trình phát triển phần mềm khi người
người
phân tích, thiết kế bỏ sót thơng tin dẫn tới thiếu chức năng mà lẽ ra cần
phải có.
Thất bại (Failure): Thất bại dễ nhận thấy nhất khi một lỗi được thực thi.
Chúng thường xuất hiện dưới 2 dạng: thất bại có thể chạy được (ví dụ
như mã nguồn) và thất bại chỉ liên kết với các lỗi về nhiệm vụ. Ngồi
10
ra, có thể kể đến các thất bại liên quan tới các lỗi do bỏ quên. Chúng ta
có thể hạn chế thất bại ngay tại bước đầu tiên của quy trình phát triển
phần mềm nếu việc
việc khảo sát được thực hhiện
iện tốt.
Sự cố (Incident): Sự cố thường được liên kết với một thất bại. Tuy
nhiên nó khác với thất bại ở chỗ sự cố luôn hiển thị cho người dùng
hoặc kiểm thử viên biết về sự tồn tại của nó.
Thừa: 1 số chức năng khơng có trong bản đặc tả yêu cầu phần mềm nhưng
lại xuất hiện trong phần mềm được xây dựng.
Ngồi ra, cịn xuất hiện 1 số lỗi phi chức năng như phần mềm khó sử dụng,
tốc độ không đáp ứng yêu cầu (vấn đề hiệu năng) hay giao diện khó nhìn cũng dễ
khiến cho người sử dụng nghĩ rằng phần mềm đang hoạt động không đúng.
1.1.4.. Yêu cầu
1.1.4
cầu của khách
khách hàng:
hàng:
Phần mềm được phát triển dựa trên nhu cầu của khách hàng. Chính vì lẽ
đó, các chức năng của phần mềm được xây dựng dựa trên việc thu thập, phân
tích, khảo sát nhu cầu của khách hàng thông qua những yêu cầu cụ thể.
Đối với phần mềm, yêu cầu thường được tổng hợp từ nhiều người, nhiều
tổ chức có mức độ chun mơn và mức độ tham gia cũng như tương tác với phần
mềm khác nhau trong mơi trường hoạt động của nó.
Có thể phân loạ u cầu của khách hàng cho sản phẩm phần mềm thành
một số loại như sau:
Phân loại theo sản phẩm và tiến trình:
-u cầu sản phẩm:
phẩm: là những địi hỏi hay ràng buộc mà phần mềm phải thực
hiện.
-Yêu cầu tiến trình:
trình: là những ràng buộc liên quan đến việc phát triển phần mềm
(kĩ thuật sử dụng, mơ hình phát triển, v.v.).
Ví dụ:MOI
Khách
hàng muốn:phát
triển một website làm bài thi trực
TIEU LUAN
download
moituyến.
nhat
Lúc này, yêu
này, yêu cầu sản phẩm là xây dựng website thi trực tuyến với các tính
năng như quản lý câu hỏi; quản lý đề thi; cho phép người dùng có thể tham
gia làm bài thi; quản trị viên có thể duyệt các câu hỏi và bộ đề thi trước khi
11
đăng lên website. Việc website được phát triển theo mơ hình Agile hay mơ
hình thác nước chính là u
là u cầu tiến trình của sản phẩm phần mềm.
Phân loại theo chức năng
- Yêu cầu chức năng : đặc tả các chức năng mà phần mềm cần phải thực
hiện.
- Yêu cầu phi chức năng : là các ràng buộc về giải pháp và chất lượng (hiệu
năng, việc bảo trì, mức độ an tồn, bảo mật, v.v.)
- u cầu đặc tả các thuộc tính nổi bật : là đặc tả cho các thuộc tính phụ
thuộc vào sự vận hành, đặc biệt là kiến trúc hệ thống. Các thuộc tính này không
thể xác định được cho từng thành phần đơn lẻ.
Phân loại theo tính kiểm định
- Những
Những yêu
yêu cầu
cầu mang
mang tính
tính m
mơơ hồ,
hồ, khơng
khơng thể kiểm
kiểm định
định
- Những
Những u
u cầu
cầu đã
đã rõ ràng
ràng và có thể
thể kiểm
kiểm định
định được.
được.
Phân loại theo phạm vi đặc tả
- Yêu cầu hệ thống : đặc tả các cấu hình, cơ sở hạ tầng, phần cứng, phần
mềm, con người, kỹ thuật, v.v. của toàn bộ hệ thống.
- Yêu cầu phần mềm:
mềm: đặc tả các chức năng, giao diện, v.v. của các cấu
phần phần mềm.
1.1.5.. Đặc tả yêu
1.1.5
yêu cầu phần
phần mềm:
mềm:
Từ yêu cầu của khách hàng và những yêu cầu bắt buộc khác, đặc tả yêu
cầu phần mềm được viết ra để mơ tả một cách chính xác về các yêu cầu cần đáp
ứng của sản phẩm phần mềm. Đây cũng chính là tài liệu cơ sở để lập trình viên,
kiểm thử viên và các bộ phận khác dựa vào để phát triển phần mềm hoàn chỉnh,
đúng với yêu cầu đặt ra ban đầu. Các khái niệm về lỗi đã nói ở mục 1.1.3 cũng
chính là đề cập đến việc phần mềm sau khi xây dựng hoạt động không đúng với
bản đặc tả yêu cầu phần mềm. Tài liệu đặc tả yêu cầu phần mềm cũng cần cung
cấp đầy đủ các thơng tin về chi phí, rủi ro và lịch trình cho quá trình phát triển
sản phẩm. Đặc tả yêu cầu phần mềm được viết ra phục vụ rất nhiều đối tượng từ
người dùng hệ thống, khách hàng đến các nhà phát triển và bảo trì phần mềm.
TIEU LUAN MOI download : moi nhat
12
Do đó, tài liệu đặc tả nên được viết bằng ngôn ngữ tự nhiên, sử dụng biểu đồ,
bảng biểu để đảm bảo tính dễ hiểu, dễ
dễ sử dụng cho tất cả cá
cácc đối tượng trên.
trên.
1.1.6. Chất lượng và độ tin
tin cậy của phần mềm:
Chất lượng của phần mềm trước hết là sự đáp ứng các yêu cầu đề ra trong
bản đặc tả yêu cầu phần mềm. Có thể kể đến các yếu tố đại diện cho chất lượng
phần mềm như: tính đúng đắn, tính hiệu quả, độ tin cậy, tính khả kiểm thử, dễ
học, dễ sử dụng, dễ bảo trì… Ta có thể thấy độ tin cậy chỉ là một trong những
yếu tố đánh giá chất lượng phần mềm. Tuy nhiên người kiểm thử lại hay nhầm
lẫn giữa khái niệm chất lượng và độ tin cậy của phần mềm. Sau q trình kiểm
thử đảm bảo phần mềm có thể chạy ổn định, kiểm thử viên thường sẽ cho rằng
phần mềm lúc này
này đã đạt chất lượng ttốt.
ốt.
1.2 Kiểm thử phần
phần mềm:
mềm:
1.2.
1.2.11 Khái
Khái niệm
niệm::
Hiểu theo cách đơn giản hơn, kiểm thử phần mềm là quá trình tìm thất bại
hoặc chứng tỏ việc tiến hành của phần mềm là đúng đắn.
1.2.2
1.2
.2 Vai trò
trò của
của kiểm
kiểm thử
thử phần
phần mề
mềm:
m:
Kiểm thử phần mềm chiếm một vị trí quan trọng trong việc nâng cao chất
lượng cũng như độ tin cậy của phần mềm trong quá trình phát triển. Hồn thành
vịng quay “đưa lỗi vào – tìm lỗi – khử lỗi đi” của quy trình kiểm thử phần mềm
sẽ thu lại được những cải tiến đáng kể cho chất lượng sản phẩm phần mềm. Việc
biết được sản phẩm phần mềm tốt tới mức nào trước khi đưa vào sử dụng sẽ hạn
chế tối đa những rủi ro gặp phải trong quá trình phát triển phần mềm.
13
TIEU LUAN MOI download : moi nhat
Hình 1.1: Vịng đời của q trình kiểm thử
1.2.3
1.2
.3 Các cấp
cấp độ kiểm
kiểm thử p
phần
hần mềm:
mềm:
Có 4 cấp độ kiểm thử phần mềm sau:
Kiểm thử đơn vị:
vị: Cấp độ này chủ yếu do lập trình viên trực tiếp
thực hiện. Phần mềm khi phát triển sẽ bao gồm nhiều đơn vị chức năng (hàm,
phương thức) hợp thành. Mỗi lập trình viên sẽ đảm nhiệm việc phát triển một
hay nhiều đơn vị chức năng. Kiểm thử đơn vị chính là việc lập trình viên sau khi
hồn thành code đơn vị chức năng của mình sẽ tiến hành kiểm thử chức năng đó
một cách cô lập nhằm phát hiện ra lỗi và khắc phục trước khi tích hợp với các
đơn vị chức năng khác. Kiểm thử đơn vị thường được tiến hành theo 2 giai đoạn:
kiểm thử đơn vị tĩnh và kiểm thử đơn vị động.
Kiểm thử tích hợp:
hợp: Sau khi kiểm thử đơn vị được tiến hành bởi
chính lập trình viên viết ra nó, các đơn vị chức năng sẽ được ghép lại với nhau
để tạo thành hệ thống đầy đủ và có thể làm việc được. Các đơn vị chức năng hoạt
động tốt khi ở trạng thái độc lập riêng rẽ, nhưng khi ghép lại sẽ có thể xuất hiện
những lỗi về giao diện hoặc cho ra kết quả không đúng khi phải sử dụng dữ liệu
từ những đơn vị chức năng khác. Đó chính là lý do tại sao phải tiếp tục kiểm thử
để phát hiện ra những lỗi kể trên. Người ta thường chia bước kế tiếp này thành 2
giai đoạn: kiểm thử tích hợp và kiểm thử hệ thống. Ở mức kiểm thử tích hợp, các
đơn vị chức năng được kết hợp lại với nhau và tiến hành kiểm thử chúng theo
14
TIEU LUAN MOI download : moi nhat
phương pháp tăng dần để đảm bảo cụm các đơn vị chức năng
năng sẽ làm việc ổn định
định
trong môi trường thử nghiệm.
Kiểm thử hệ thống:
thống: Sau khi tất cả các đơn vị chức năng đã được
tích hợp lại với nhau tạo thành một hệ thống hoàn chỉnh, kiểm thử hệ thống sẽ
được thực thi để đảm bảo sản phẩm phần mềm đáp ứng đầy đủ các yêu cầu trong
bản đặc tả yêu cầu phần mềm. Đây là công việc tốn nhiều cơng sức nhất trong
q trình kiểm thử phần mềm. Đồng thời cũng sử dụng nhiều kỹ thuật kiểm thử
khác nhau như: kiểm thử giao diện người dùng, kiểm thử chức năng, kiểm thử
hiệu năng, kiểm thử tính dễ dùng, v.v. để hồn tất cơng việc kiểm thử trong cấp
độ này.
Kiểm thử chấp nhận:
nhận: Khi kiểm thử hệ thống hoàn tất, sản phẩm
phần mềm được coi như đã sẵn sàng cho việc đưa vào sử dụng thực tế. Lúc này,
phần mềm cần được tiến hành cấp độ kiểm thử cuối cùng – kiểm thử chấp nhận
bởi chính khách hàng hay người sử dụng phần mềm. Tuy có phần tương tự như
kiểm thử hệ thống nhưng mục đích chính của kiểm thử chấp nhận là quyết định
việc đưa vào sử dụng chính thức sản phẩm phần mềm. Người ta dựa trên các số
liệu thống kê thực tế về chất lượng, độ tin cậy của phần mềm để quyết định triển
khai cho người dùng cuối. Kiểm thử chấp nhận thường được thực hiện dưới hình
thức cho một nhóm người dùng thử sản phẩm phần mềm để phát hiện các lỗi và
nhận phản hồi từ người dùng. Trong đó, phiên bản alpha dành cho đội phát triển
phần mềm và phiên bản beta được cung cấp cho người sử dụng thật để đưa ra
đánh giá trong môi trường thực tế. Ở thời điểm hiện tại, kiểm thử chấp nhận
được coi là cấp độ quy chuẩn bắt buộc khơng thể thiếu trong quy trình phát triển
của nhiều sản phẩm phần mềm.
1.2.4
1.2
.4 Quy trình
trình kiể
kiểm
m thử phần
phần mềm:
mềm:
Các giai đoạn trong quy trình kiểm thử phần mềm được biểu diễn tổng
quát bằng sơ đồ sau:
15
Phân tích yêu cầu
TIEU LUAN MOI download : moi nhat
Lập kế hoạch kiểm thử
Thiết kế kịch bản cho quy
trình kiểm thử
Thiết lập mơi trường kiểm
thử
Thực hiện kiểu kiểm thử
Đóng chu trình kiểm thử
Hình 1-2: Quy
Quy trình kiểm thử phần
phần mềm.
Phân tích u cầu
Giai đoạn đầu tiên của quy trình kiểm thử là phân tích các u cầu thơng
qua những tài liệu bao gồm: tài liệu yêu cầu của khách hàng, prototype của
khách hàng, tài liệu đặc tả yêu cầu của phần mềm, tài liệu thiết kế hệ thống…
QA Team có nhiệm vụ phân tích và xác định những u cầu của khách
hàng, trong đó có yêu cầu về kiểm thử chức năng/phi chức năng của phần mềm.
Trong quá trình phân tích, QA Team có thể đặt ra câu hỏi để hiểu chính xác hơn
về yêu cầu của sản phẩm, đồng thời hỗ trợ đưa ra giải pháp thích hợp cho khách
hàng.
Lập kế hoạch kiểm thử
Dựa vào tài liệu nhận được trong giai đoạn đầu, Test Lead hoặc Test
Manager sẽ lên kế hoạch kiểm thử phần mềm cho QA team để xác định một số
yếu tố:
Phạm vi dự án: Thời gian thực hiện dự án bao lâu? Trong từng khoảng
thời gian sẽ có những cơng việc gì?
Phương pháp tiếp cận: Dựa vào yêu cầu chất lượng của khách hàng, thời
gian test, kỹ thuật phát triển ứng dụng, lĩnh vực của sản phẩm… Test Manager sẽ
16
đưa ra phương pháp tiếp cận sao cho đảm bảo tiến độ và chất lượng sản phẩm.
Sau khi kết thúc giai đoạn này, QA team cần nhận được test plan, test schedule,
test estimation.
Thiết lập môi trường kiểm thử
Trong
đoạn này, :các
Tester sẽ đọc hiểu tất cả các tàimoi
liệu,nhat
từ đó xác
TIEU LUAN
MOIgiai
download
định những việc cần làm, chức năng nào cần test hoặc khơng. Sau đó, dựa vào kế
hoạch
kỹ thuật
kịch
kiểmtrường
thử, Tester
sẽ bắtthử
đầucóviết
cầu
củavàtest
case: thiết
Thể kế
hiện
tấtbản
cả các
hợp kiểm
thểtest
phátcase.
sinhYêu
để
đáp ứng yêu cầu sản phẩm. Ngoài test
test case, Tester cũng cần ch
chuẩn
uẩn bị các dữ liệu
cần thiết khác như test data, test script, test design, test automation script.
Thiết lập môi trường kiểm thử
Đây là một trong những giai đoạn đóng vai trị rất quan trọng trong
Software Testing Life Cycle (vòng đời phát triển phần mềm). Dựa trên yêu cầu
khách hàng và đặc thù của sản phẩm, môi trường kiểm thử sẽ được xác định.
Tester cần chuẩn bị smoke test case để kiểm tra môi trường cài đặt đã đáp ứng
yêu cầu và sẵn sàng cho giai đoạn kiểm thử tiếp theo hay chưa.
Thực hiện kiểu kiểm thử
Theo test case đã thiết kế và môi trường kiểm thử đã hoàn tất cài đặt,
Tester sẽ báo cáo bug lên tool quản lý lỗi và theo dõi đến khi fix bug thành cơng.
Tiếp đó, Tester thực hiện retest để verify các fix bug và regression test trong
trường hợp có sự thay đổi. Sau khi hoàn tất giai đoạn này, các chuyên viên kiểm
thử cần có được test results (kết quả kiểm thử) và defect reports (danh sách các
lỗi tìm được).
Đóng chu trình kiểm thử
Để đóng chu trình kiểm thử, QA Team cần có được những tài liệu đã được
tổng hợp và hoàn thiện từ những giai đoạn trước: tài liệu phân tích đặc tả yêu
cầu, test plan, defect reports, test results… Tiếp đó, QA team sẽ tổng kết, báo
17
cáo về q trình kiểm thử, có bao nhiêu bug đã được fix, bug có nghiêm trọng
hay khơng, chức năng nào cịn lỗi, chức năng nào đã hồn thành…
1.2.5 Phân
1.2.5
Phân loại
loại kiểm
kiểm thử
thử phần
phần mềm:
mềm:
1) Kiểm thử thủ
thủ công (Manual
(Manual Testing
Testing))
Kiểm thử thủ cơng thường được thực hiện bằng chính bản thân kiểm thử
viên (tester). Họ sẽ tương tác với ứng dụng hoặc phần mềm và API bằng cơng cụ
thích hợp. Từ đó tester tìm ra điểm khơng phù hợp hay các lỗi của hệ thống.
Cách kiểm thử truyền
truyền thống này thường tốn kém vì nó u cầu mơ
mơii trường kiểm
CùngMOI
với đó,
việc tự thực
hiện các thao tác kiểm thử có thểmoi
dễ xảy ra lỗi do
TIEU thử.
LUAN
:
con
người.
Vì download
người kiểm thử
có thể mắc lỗi chính tả hoặc bỏ quanhat
các bước
trong tập lệnh kiểm thử (test script).
2) Kiểm thử
thử tự động
động (Autom
(Automation
ation Testing)
Testing)
Ngược lại, kiểm thử tự động được thực hiện bởi máy móc, thực thi tập
lệnh kiểm thử đã được viết trước. Các lệnh kiểm thử này có thể khác nhau rất
nhiều về độ phức tạp. Từ việc kiểm tra các đơn vị nhỏ nhất trong mã nguồn
nguồn như
method, class đến việc đảm bảo rằng việc thực hiện một chuỗi các hành động
phức tạp trong giao diện
diện người dùng sẽ dẫn đến kết
kết quả giống nhau. Nhiều
Nhiều người
cho rằng phương pháp này mạnh mẽ và đáng tin cậy hơn so với kiểm thử thủ
công. Nhưng chất lượng của các lệnh kiểm thử tự động phụ thuộc việc các tập
lệnh kiểm thử được viết ra có tốt hay khơng. Trong kiểm thử động, người ta chia
làm 2 kỹ thuật: kiểm thử hộp trắng (kiểm thử cấu trúc) và kiểm thử hộp đen
(kiểm thử chức năng).
a. Kiểm
Kiểm tthử
hử hộp
hộp ttrắ
rắng
ng:: là một phương pháp kiểm thử phần mềm trong đó
tester biết về cấu trúc nội bộ / thiết kế. Người kiểm tra chọn đầu vào để
thực hiện các đường dẫn thông qua mã và xác định đầu ra thích hợp.
18
Hình 1-3: Hình
Hình minh họa kiểm thử
thử hộp trắng
Kiểm thử hộp trắng bao gồm phân tích dịng dữ liệu, điều khiển dịng,
dịng thông tin, mã thực hành, ngoại lệ và những lỗi trình bày trong hệ thống để
kiểm tra những hành động của phần mềm không được định hướng trước.
TIEU LUAN MOI download : moi nhat
Phương pháp kiểm tra hộp trắng áp dụng cho các mức độ kiểm tra phần
mềm sau đây: (Tuy nhiên, nó là chủ yếu áp dụng cho các kiểm thử đơn vị )
Unit Testing(Kiểm thử đơn vị): Để kiểm tra đường dẫn trong một đơn vị.
Integration Testing(Test
Testing(Test tích hợp): Để kiểm tra đường dẫn giữa các đơn vị.
System Testing(Test hệ thống): Để kiểm tra các đường dẫn giữa các hệ
thống con.
Ưu điểm:
Test có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi cho GUI
để có thể test
Test kỹ càng hơn, có thể bao phủ hầu hết các đường dẫn
Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh
Cho phép tìm kiếm các lỗi ẩn bên trong
Các lập trình viên có thể tự kiểm tra
Giúp tối ưu việc mã hoá
Do
cầuđakiến
soátyêu
lỗi tối
nhất.thức cấu trúc bên trong của phần mềm, nên việc kiểm
Nhược điểm:
19
Vì các bài kiểm tra rất phức tạp, địi hỏi phải có các nguồn lực có tay nghề
cao, với kiến thức sâu rộng về lập trình và thực hiện.
Maintenance test script có thể là một gánh nặng nếu thể hiện thay đổi quá
thường xuyên.
Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng dụng đang
được test, nên các công cụ để phục vụ cho mọi loại triển khai / nền tảng có
thể khơng sẵn có.
b. Kiểm
Kiểm tthử
hử hộp
hộp đen
đen:: là một phương pháp kiểm thử phần mềm được thực
hiện mà không biết được cấu tạo bên trong của phần mềm, là cách mà các
tester kiểm tra xem hệ thống như một chiếc hộp đen, khơng có cách nào
nhìn thấy bên trong của cái hộp.
TIEU LUAN MOI download : moi nhat
Hình 1-4: Hình
Hình minh họa kiểm thử
thử Hộp đen
Black Box Testing chủ yếu là được thực hiện trong Function test và
System test.
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.
20
Ưu điểm:
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,
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 tồn bộ 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:
TIEU LUAN
MOIđiểm:
download : moi nhat
Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn
Nhiều dự án khơng
khơng có thơng số rõ ràn
ràngg thì việc thiết kế te
test
st case rất khó và
do đó 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.
Chỉ có một số nhỏ các đầu vào có thể được kiểm tra và nhiều đường dẫn
chương trình sẽ được để lại chưa được kiểm tra.
21
Kiểm thử black box được xem như "là bước đi trong mê cung tối đen mà
khơng mang đèn pin” bởi vì tester khơng biết phần mềm đang test đã được
xây dựng như thế nào. Có nhiều trường hợp khi một tester viết rất nhiều
trường hợp test để kiểm tra một số thứ có thể chỉ được test bằng một
trường hợp test và/hoặc một vài phần cuối cùng không được test hết.
1.2.6
1.2
.6 Các mức
mức độ nghi
nghiêm
êm trọng
trọng của
của lỗi:
lỗi:
1
2
Nhẹ
Vừa
3
Khó chịu
4
Bực mình
Lỗi chính tả
Hiểu lầm hoặc thừa thơng tin
Tên bị thiếu, cụt chữ hoặc hố đơn có giá trị 0.0
đồng
Một vài giao dịch khơng được xử lý
56
7
8
9
10
N
ọntgrọng
Rấgthniêgm
hiêtrm
Cực
Cực kỳ nghi
nghiêm
êm trọn
trọngg
Quá quắt
Thảm hoạ
Dịch
Dịch hoạ
hoạ
Mửấtlýgigaioaodịdcịhch sai
X
Lỗi
Lỗi rấ
rấtt nghi
nghiêm
êm trọn
trọngg th
thườ
ường
ng xuyê
xuyênn xảy
xảy ra
Huỷ hoại cơ sở dữ liệu
Hệ thống dừng hoạt động
Thảm
Thảm hoạ
hoạ chuy
chuyển
ển sa
sang
ng mứ
mứcc lâ
lâyy la
lann
1.2.
1.2.77 Ca ki
kiểm
ểm thử:
thử:
Ca kiểm thử mô tả dữ liệu bao gồm: đầu vào, hành động hoặc sự kiện và
kết quả đầu ra mong đợi (expected results) để xác định liệu 1 ứng dụng, hệ thống
phần mềm hoặc một trong các tính năng của nó có hoạt động đúng như mong
muốn hay
TIEU không.
LUAN MOI download : moi nhat
Cấu trúc của một ca kiểm thử thông thường bao gồm:
- Test case ID: Xác định số lượng trường hợp cần kiểm thử.
- Function (Chức năng): Các function có thể được chia nhỏ dựa theo chức năng
của hệ thống nhằm giúp ca kiểm thử trở nên rõ ràng hơn.
- Pre-condition: Điều kiện đầu vào của ca kiểm thử, ví dụ như khi thực hiện kiểm
thử form đăng nhập, pre-condition sẽ là form đăng nhập phải được hiển thị ra.
22
- Test Data: Dữ liệu đầu vào cần chuẩn bị trước khi kiểm thử.
- Test Steps: Mô tả chi tiết các bước thực hiện kiểm thử.
- Expected Results: Kết quả mong đợi sau khi thực hiện các bước kiểm thử.
- Actual result: Mô tả kết quả thực tế khi thực hiện kiểm thử trên môi trường của
hệ thống. Actual result thường bao gồm các giá trị: pass, fail, untested, N/A.
- Comments: Có thể chứa screen shot hoặc thông tin liên quan khi thực hiện ca
kiểm thử.
Một ca kiểm thử được
được cho là hiệu quả khi:
Dựa vào ca kiểm thử có thể tìm thấy lỗi.
Tìm được nhiều lỗi khó phát hiện.
Chỉ ra được những điểm ban đầu mà khi thực hiện kiểm thử khơng
tìm ra vấn đề.
Ca kiểm thử cần có những bước thực hiện kiểm thử (Test steps)
đơn giản, minh bạch, dễ hiểu.
Các trường hợp thử nghiệm nên có giá trị, tóm tắt và ngắn.
Các ca kiểm thử nên có sự liên kết: Mỗi ca kiểm thử cần được
đánh số thứ tự (Test case ID) để đảm bảo ca kiểm thử đã bao phủ
100% bản đặc tả yêu cầu phần mềm.
Ca kiểm thử có thể bảo trì: Nên viết ca kiểm thử sao cho khi có
thay đổi, chỉnh sửa thì các bên liên quan có thể dễ dàng nhận thấy
được sự thay đổi đó.
Ca kiểm thử có tính ứng dụng cao.
TIEU 1.2.8
LUAN
MOI
download
:
Nguyên
Nguy
ên tắc
quan trọng
trọng
trong
trong kiểm
kiểm thử
thử phần mềm: moi nhat
1) Kiểm thử
thử chứng
chứng minh
minh sự hiện
hiện diện của lỗi
lỗi
Bằng việc kiểm thử, chúng ta có thể làm giảm lượng bugs khi áp dụng
nhiều phương pháp kiểm thử lên phần mềm. Tuy nhiên khi được đưa lên môi
23
trường thật, người dùng cuối hồn tồn có thể thấy nhiều lỗi khác khơng tìm thấy
trong q trình kiểm thử. Kiểm thử chứng minh được sản phẩm có lỗi nhưng
khơng thể chứng minh rằng sản phẩm khơng cịn lỗi. Điều này có nghĩa là, sẽ
ln có lỗi khơng được phát hiện trong phần mềm, ngay cả khi khơng tìm thấy
lỗi, cũng khơng đồng nghĩa rằng phần mềm đúng hoàn toàn.
2) Kiểm thử toàn
toàn bộ là khơng
khơng khả
khả thi
Đúng vậy, rất khó để kiểm tra tồn bộ các module cũng như các tính năng,
kết hợp với đầu vào và đầu ra trong suốt quá trình kiểm tra. Các sản phẩm phần
mềm hiện nay cực kỳ đa dạng và phức tạp, được phát triển trên nhiều nền tảng,
thêm vào đó, ngày càng có nhiều cơng nghệ mới, khả năng kết nối dữ liệu lớn…
khiến việc kiểm thử tồn bộ gần như là khơng thể. Thay vì cố gắng kiểm thử
tồn bộ, hãy xác định mức độ quan trọng và độ ưu tiên của các module để kiểm
thử những phần cần thiết hoặc gặp nhiều nguy cơ hơn.
3) Kiểm
Kiểm thử
thử càng
càng sớm càng
càng tốt
Chi phí cho việc khắc phục, sửa lỗi sẽ tỷ lệ thuận với thời gian phát hiện ra
lỗi đó. Khơng ít phần mềm khi chuẩn bị giao cho khách hàng mới phát hiện ra
lỗi xuất hiện ngay từ bản đặc tả yêu cầu phần mềm hay bản phân tích thiết kế hệ
thống. Điều này gây ra những thiệt hại không nhỏ cho quá trình phát triển phần
mềm. Vì vậy, kiểm thử phần mềm ngay từ những giai đoạn đầu của quy trình
phát triển là điều
điều hết sức cần thiết.
4) Lỗi thườ
thường
ng phân
phân bổ tập
tập trung
trung
Lỗi thường tập trung nhiều ở những chức năng chính của phần mềm. Do
đó,
trung
tìmtrong
ra lỗi những
ở những
chức
nàyhiệu
sẽ giúp
thiểu kiểm
thời gian
thử.tập
Đây
là một
cách
cơnăng
bản và
quả giảm
nhất trong
thử kiểm
phần
mềm.
5) Nghịch
Nghịch lý tthuố
huốcc trừ
trừ sâu
sâu
Trong trồng trọt, nếu người nông dân sử dụng lặp lại một liều trừ sâu, các
loại sâu bệnh sẽ dần dần thích nghi và trở nên “nhờn” với loại thuốc trừ sâu đó.
Tương tự với kiểm thử phần mềm, khi lặp đi lặp lại một test case, thì xác suất
tìm được lỗi là rất thấp. Nguyên nhân là hệ thống hồn thiện hơn, lỗi tìm thấy đã
sửaMOI
theo test
case cũ. Để
xử lý hiệu ứng “thuốc trừ sâu” này,
case cần
TIEU được
LUAN
download
:
moitest
nhat
24
được thường xuyên xem lại và chỉnh sửa, thêm nhiều test case mới để tìm lỗi
mới (regression test).
Thêm vào đó, QA/ Tester cũng không nên phụ thuộc quá nhiều vào các kỹ
thuật test sẵn có. Bạn cần liên tục cải tiến các phương pháp có sẵn để làm việc
kiểm thử hiệu quả hơn.
6) Kiểm thử phụ
phụ thuộc
thuộc vào ngữ cảnh
cảnh
Kiểm thử phụ thuộc vào ngữ cảnh, nói một cách đơn giản, là việc kiểm
thử một trang thương mại điện tử sẽ phải khác cách test một ứng dụng đọc tin
tức. Tất cả các phần mềm đều được phát triển theo cách khác nhau. Và việc áp
dụng chung một “cách giải” là sai lầm. Bạn cần sử dụng cách tiếp cận khác nhau,
phương thức, kỹ thuật test khác nhau, loại test phụ thuộc vào loại phần mềm/
ứng dụng/ website.
7) Quan niệm sai lầm
lầm về việc
việc “hết
“hết lỗi”
lỗi”
Việc khơng tìm thấy lỗi khơng có nghĩa là khơng tồn tại lỗi trong phần
mềm. Chúng ta chỉ có thể hạn chế tối đa lỗi có thể gặp phải chứ khơng thể triệt
tiêu tồn bộ lỗi có thể gặp phải.
1.3 Các kỹ thuật trong
trong kiểm
kiểm thử:
1.3.1 Kỹ thuật
thuật phân
phân vù
vùng
ng tương
tương đươn
đương:
g:
Kỹ thuật phân vùng tương đương có đặc điểm là:
Chia miền dữ liệu đầu vào của một chương trình thành các vùng
dữ liệu tương đương nhau.
Tất cả các giá trị trong một vùng tương đương sẽ cho ra kết quả
đầu ra giống nhau.
Có thể chọn ra một giá trị đại diện trong một vùng tương đương để
tiến hành kiểm thử.
25
TIEU LUAN MOI download : moi nhat
Hình 1-5:
1-5: Minh
Minh họa kỹ thuật
thuật phân vùng tương đđương
ương
1.3.2
1.3
.2 Kỹ thuật
thuật phân
phân tích
tích giá
giá trị
trị biên:
biên:
Phân tích giá trị biên tập trung vào các giá trị tại biên của miền xác định
để xây dựng ca kiểm thử. Mục đích là tìm ra lỗi có thể xảy ra ở gần các giá trị
biên này. Phân tích giá trị biên chính là trường hợp đặc biệt của kỹ thuật phân
vùng tương đương. Dựa trên những vùng giá trị tương đương, kiểm thử viên sẽ
xác định giá trị biên giữa những vùng này và thiết kế ca kiểm thử phù hợp.
Hình 1-6:
1-6: Minh
Minh họa kỹ thuật
thuật phân tích giá tr
trịị biên.
Với kỹ thuật phân tích giá trị biên, kiểm thử viên cần chú ý tới một số
giá trị sau để sinh ca kiểm thử:
Giá trị nhỏ nhất.
Giá trị gần kề lớn hơn giá trị nhỏ nhất.
Giá trị gần kề nhỏ hơn giá trị nhỏ nhất.
Giá trị bình thường.
Giá trị gần kề nhỏ hơn giá trị lớn nhất
Giá trị lớn nhất.
Giá trị gần kề lớn hơn giá trị lớn nhất
1.3.
1.3.33 Đoán
Đoán lỗi:
lỗi:
26
TIEU LUAN MOI download : moi nhat
