đồ án tốt nghiệp đại học ngành công nghệ thông tin nghiên cứu áp dụng kiểm thử tự động cho dự án thực tế

- - Xây dựng hệ thống Test case chỉ tiết cho từng phân hệ và thực tỈn các Test case đó bao gồm một số chức năng chính sau: ¢ Chức năng thêm sản phẩm e Chức năng đổi mật khâu ® Chức năng

TRUONG DAI HOC XAY DUNG HA NOI

KHOA CONG NGHE THONG TIN

DO AN

TOT NGHIEP DAI HOC

NGANH CONG NGHE THONG TIN

NGHIEN CUU AP DUNG KIEM THU TU DONG CHO DU AN THUC TE

Hà Nội, năm 2022

PHIẾU GIAO NHIEM VỤ ĐỎ ÁN TÓT NGHIỆP

1 Thông tin về sinh viên

Họ và tên sinh viên: Lê Thị Trang Điện thoại liên lạc: 0362132139 Email:

- Nghién etru cae ly thuyết về kiêm thử

- Xay dyng hé théng cac test case cho “Hé théng bán hàng”, thực thi các Test case dé

nâng cao chất lượng sản phẩm đầu ra phù hợp với các yêu cầu từ người dùng - _ Nghiên cứu các công cụ kiểm thử tự động, đặc biệt về Selenium WebDriver

Sử dụng Selenium WebDriver tạo ra các Test script thực thi một số Test case cơ bản 3 Các nhiệm vụ cụ thê của ĐATN

- Tìm hiểu các kiến thức cơ bản về lý thuyết kiểm thử thủ công và các công cụ kiểm

thự tự động đặc biệt là Selenum WebDriver - - Xây dựng hệ thống Test case chỉ tiết cho từng phân hệ và thực tỈn các Test case đó

bao gồm một số chức năng chính sau: ¢ Chức năng thêm sản phẩm

e Chức năng đổi mật khâu

® Chức năng đăng nhập

© Tính năng quản lý tích điểm

- _ Sử dụng Selenum WebDriver để xây dựng các Test Script và thực thi một số Test

cases cơ bản,

- Phối hợp với đội code trrong quá trình xây dựng,chỉnh sửa và hoàn thiện hệ thống

theo yêu cầu của người dùng 4 Loi cam doan của sinh viên

Tôi — Lê 7Ùị Trang - cam kết ĐATN là công trình nghiên cứu của bản thân tôi đưới sự hướng dẫn của 7% 7rẩn Khánh Dung

Các kết quả nêu trong ĐATN là trung thực, không phải là sao chép toàn văn của bất kỳ công trình nào khác

(Lê Thị Trang — 209363 — 631T3]

Hà Nội, ngày thang năm Tác giả ĐATN

Lê Thị Trang 5 Xác nhận của giảng viên hướng dẫn về mức độ hoàn thành ĐATN và cho phép bảo vệ

Hà Nội ngày tháng năm Giảng viên hướng dẫn

TS.Trần Khánh Dung

(Lê Thị Trang — 209363 — 631T3]

LOI CAM ON

Để đề tài đồ án tốt nghiệp này đạt kết quả tốt đẹp, em đã nhận được sự hỗ trợ, giúp đỡ rất nhiều của các tổ chức, cá nhân Với tình cảm sâu sắc, chân thành, cho phép em xin được bảy tỏ lòng biết ơn đến tất cả các cá nhân và tổ chức đã 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 thay cô của khoa Công nghệ thông tin nói riêng và các thầy cô trường Đại học Xây Dựng nói chung 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 các thầy cô trong suốt 4 năm đại học, đến nay em đã có thể hoàn thành đồ án tốt nghiệp với đề tài: “Nghiên cứu áp dụng Kiểm

thử tự động cho dự án thực tế”,

Đặc biệt, em xin gửi lời cảm ơn chân thành nhất tới cô giáo — TS Trần Khánh

Dung đã tận tình hướng dẫn em thực hiện và hoàn thành tốt đồ án này Trong thời gian

được làm việc với thầy, em đã được học hỏi thêm nhiều kiến thức và kinh nghiệm làm

việc Những kinh nghiệm này chắc chắn sẽ có ích cho bản thân em sau khi ra trường Sau cùng là lời cảm ơn tới các bạn cùng lớp 63IT3 đã gắn bó và giúp đỡ em trong suốt những năm học tại trường cũng như trong quá trình làm và hoàn thiện đề tài đồ án tốt nghiệp này

Với điều kiện thời gian cũng như kinh nghiệm còn hạn chế của một sinh viên, đồ án này không thê tránh khỏi 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ũng như phát triển bản thân, phục vụ tốt cho công tác thực tẾ sau này

Em xin chân thành cảm ơn!

Hà Nội, ngày 04 tháng UÌ năm 2022 Sinh viên thực hiện đồ án

Lê Thị Trang (Lê Thị Trang — 209363 — 631T3]

TOM TAT NOI DUNG DO AN TOT NGHIEP L Nội dung đồ án

1 Tìm hiểu cơ sở lý thuyết về kiểm thử phần mềm

- _ Khái niệm kiểm thử phần mềm

- _ Mục tiêu của kiểm thử phần mềm - _ Các nguyên tắc kiểm thử phần mềm

- Cac cap độ kiểm thử phan mém

2 Tìm hiểu về kiểm thử tự động

- _ Khái niệm kiểm thử tự động

- _ Ưu nhược điểm của kiêm thử tự động

- Tim hiéu các khái niệm về TestNG

4 Kiểm thử một số chức năng của hệ thống thực tế a Chức năng đăng nhập

b Chức năng đối mật khẩu

c Chức năng thêm sản phẩm

d Chức năng Quản lý tích điểm

5 Kết quả đạt được - Nhiệm vụ của sinh viên trong dự án

- _ Một số màn hình đã test và một số test case da thuc hién automation test

6 Kết luận và định hướng phát triển a Nêu những ưu điểm mà automatfion test có thê hỗ trợ người kiêm thử phân mềm đồng thời liệt kê ra những hạn chế vẫn còn tồn tại trong việc sử dụng

automation test trong viéc kiểm thử

IL Nội dung các chương trình bảy trong báo cáo - - Chương I: Đặt vẫn đề và định hướng giải pháp - _ Chương 2: Tìm hiểu cơ sở lý thuyết về kiểm thử - Chương 3: Xâu dựng hệ thống test case chỉ tiết cho một số chức năng chính

IIL Tw khéa tim kiém Kiểm thử

Test case Test Script

Thue thi Selenium WebDriver TestNG

[Lé Thi Trang — 209363 — 631T3]

DANH MUC HiINH ANH

Hình 1: Các cấp độ kiểm thử phần mềm 2-2 St E2 2512215217121 te 20

Hình 2: Quy trình kiểm thử tự động 2s E1 12211222 2.1812 HH HH re 24

Hình 3: Các bước lập kế hoạch kiém thtt ccccccccccccccccecesscsesessseseseseseseseseseesesseseevevecees 24

Hình 5: Các bước thực hiện kiểm thử 2222 SE E151 115515155515 1155 1E 2 HH rec 26

Hình 6: Một test case template thông thường được tester tạo đề bắt đầu quá trình kiểm 11 ccecccesesscssesecseeseesessesaececssesecssssecsecseesecsessessesssssesecssesecsecsecnsssisesseesseeeseessess 30 Hình 7: Mẫu test case tiếng anh có đầy đủ các thành phân chính và một số mục phụ hỗ

Hình 8: Giao diện phân hệ Thông tin khách hàng - - 2 22-22212222 22222 35

Hình 9:Giao diện phân hệ Lịch sử giao dịch KH 2.2 22 222 22222222 srxc2 40

Hình 10: Ciao điện phân hệ Chính sách tích 727 RRRERRRERERRRR an 44 Hình L1: Giao diện chức năng Điểm quy đổi ScS HE HH Hye 31 Hình 12: Giao diện chức năng Điểm tặng 5 c1 E1 rrrrei 34 Hình 14: Giao diện chức năng Chính sách hạng thẻ - 5-22 22 22212222222 szxs2 60

Hình 15: Giao diện chức năng Điêm/Hạng KH 2-52 SE 22121121 1E EEsEerrrrrei 64

Hình I6: Giao diện trang đăng nhập Hệ thống bán hàng - 2-5 cS cxszx‡rsz 67

Hình 17: Giao diện chức năng Đổi mật khâu 2 2S 12112121 121511812 erererrse 69

Hình 18: Giao diện chức năng Thêm mới sản phẩm -2- 25t SE 2125 EeEzrrrei 72 Hình 19: Thành phần của Selenium - 2-55 2S 2EE9EE271EE122171212121121 E12 xe 75

Hình 20: Luồng hoạt động của SelenTum -.- c2 221211121112 1221111 tre 79 Hình 21: Công cụ kiểm thử tự động Selenrum WeblDrIver c 2c co ccsc: 80

Hình 22: Giới thiệu TestN L0 1 121121121121 111201111211111211111101 11 1n ky 86 Hình 23: Tạo file testng.xmll - .- - E222 222121211111 11212121 11 11118111112 111111281 e 2g 90 Hình 24: Nội dung của file testng.xImÌ - ¿12c 2211211121121 11511111111 111 111111111 xk 90 Hình 25: Run testng.xml theo €Ïa§s c5 c2 1221211121211 12 122 1112211111111 211 kg 91 Hinh 26: Két qua run testng.xml theo class cccccccccsssssssessessesseesessessesessesessesessesseass 92 Hình 27: Run testng.xml theo method - c2 22 2111111221221 12121 1111111111111 kg 92 Hình 28: Run test hỗn hợp package, class và method 5c s cctEEEEEsrxsee 93 Hình 29: Kết quả run test hỗn hợp package, class và method - -csccsc sex szez 93 Hình 30: Sử dụng Include và exclude trong ftestNG che, 94 Hình 31: Code gọi ra các element và các hàm cơ sở cho các test case đăng nhap 95

Hình 32: Code một vài test case đăng nhập c1 2212222221112 11222 tre 96

Hình 33: File loginTest.xml để chạy các case đăng nhập - 5: 5c se 97 Hình 34: Kết quả thực thi automation các test case trong file emailable-report.html .98 Hình 35: Code gọi ra các element cần thiẾt 2-22 2221 E22 E121 errre 99 (Lê Thị Trang — 209363 — 631T3]

Hình 36: Script thre hign test Cases ccc cece ccc cesecesecesseceeeeeseeseceeseeeecntseesesstees 99 Hình 37: Fie xml thực hiện run f€sf CaS€ L LG TQ S220 22331 511111 ng ng chế 100 Hình 38: Chọn phiên bản Chrome 1 222221122112 221 152111 1111811521511 181 11 ky 101

Hình 39: Download Chrome IDTIVeT - c2 2222121111211 2211 1132 111215111151 1xcHey 101 Hinh 40: Tai JDK 15.0.0 aaaadadadaddddddaắÝỶŸỶŸẲỶẢ 102 Hình 41: Cài đặt JIDK 15 - ĐC 2011211211 1211211 111111111 181101 1111111 khay 102

Hinh 42: Chon thu muc cai dat JDK 15 eee eecesseesscccceecccccsesesssnttttscceseceeeaeea 103 Hinh 43: Hoan thanh cai dat JD Koil ceeecceescccccececcceesessnttttsecececeeeeeseeseseeeeeaa 103 Hình 44: Cài đặt EclipseIDE oo cece 221122112211 122125 11121115115 111 151511111181 x rệt 104

Hình 45: Trang Marketplace 22c 1211122122211 1155115115111 1512k re 105

Hình 47: Cài đặt TesfNG Q0 0Q 2H 1n 011110111 HH k HH k khe 106

Hinh 48: Xac nhan Install Test NGwi ccc eee cecccccccccccccccssesevcvccccceceeaeeeeececseseeseeea 106 Hình 49: Khởi động lại máy -.L 0 22C 1 221221111111 1211 1211111112181 rệt 107 Hinh 50: Tạo dự án TmỚI - 0 TS g1 g1 kg ng 108

Hình 51: Thêm các file selenium và testN à L cnS Sn HH HH He 109 (Lê Thị Trang — 209363 — 631T3]

DANH MUC BANG

Bang 1: So sanh Alpha Test va Beta Test 0 2210 11212 re 23 Bảng 2: Phân tích các trường hợp kiêm thử của phân hệ Thông tin khách hàng 39

Bảng 3: Các trường hợp kiểm thử phân hệ lịch sử giao dịch KH - 44

Bảng 5: Các trường hợp kiểm thử chức năng Điểm quy đỔi 2-2 5s 53 Bảng 6: Các trường hợp kiểm thử chức năng Điểm tặng 5s 5c nen 39 Bảng 7: Các trường hợp kiểm thử chức năng Chính sách hạng thẻ 5-55 63 Bang 8: Cac trường hợp kiểm thử chức năng Điểm/Hạng KH 2c 67 Bảng 9: Phân tích các trường hợp kiểm thử đăng nhập 2 sec csrxe 69 Bảng 10: Các trường hợp kiêm thử chức năng Đôi mật khâu - s2 +scs se: 71 Bảng 11: Các trường hợp kiêm thử chức năng Thêm mới sản phẩm - 73 Bang 12: Ưu và nhược điểm của Selenium IDE 52s E2 SE ExEEEEE ri 76 Bảng 13: Ưu và nhược điểm của Selenium RC -55- c TH gH rrưe 76

Bảng 14: Ưu và nhược điểm của Selenium WebDriver 52 2n 2n ng nn sec, 77

Bảng 15: Hỗ trợ trình duyệt và môi trường của Selenium IDE và Selenium WebDriver C1111111111111111111111 1111111 11K TT KT 11111 1111111111111 11111111 1111 1111111111111 1.11 1111 1111 78 Bảng 16: Các command selenium được sử dụng thường xuyên 8l Bảng 17: Cú pháp định vị các phần tử trong Selenium WebDriver cscs¿ 82 Bảng 18: Kết quả các test case đăng nhập S13 1E 12121121 1t te 98 [Lé Thi Trang — 209363 — 631T3]

MUC LUC

CHUONG 1: DAT VAN ĐÈ VÀ ĐỊNH HƯỚNG PHÁT TRIỂN -: 13

I _ Lý do chọn đề tài 5c ST HE ng HT nh H1 ng ru 13 2 _ Tính cấp thiết của đề tải - c t1 21121211 1 1E EnHHgHg tư 13

3 Mục đích, đối tượng, phạm v1 nghiên cỨu - 2c 222 12s 2222 sec 14

4 Định hướng giải pháp - - c1 212221122111 121 112115 111111118125 111 ke 14

CHƯƠNG 2: TÌM HIẾU CƠ SỞ LY THUYÉT VỀ KIÊM THỦỬ : 17

I _ Tổng quan về kiểm thử phần mềm - + se E2 9212112127111 E xrkt 17

1.1 _ Kiểm thử phần mềm là gì 252 1 2E 1E SE E1 E211 1E te rưn 17

1.2 Mục tiêu của kiểm thử phan mm - 2 TH 2E E11 511 1 ren 17

13 Một số khái niệm liên quan đến kiểm thử phan TỂM 222cc S22 S2 22252 17 1.4 Các nguyên tắc cơ bản của kiêm thử phân mễằm ằ c5 cccccccec 18 L5 Các cấp độ kiểm thử phần mềm 5 2 E1 E2 1212121121 E.Ectxee 19

2 — Kiểm thử tự động c2 tt HH HH Hường 23 2.1 Khái niệm kiểm thử tự động - S5 TH gu grrờg 23

2.2 Tại sao cần kiểm thử tự động? cv 12g12 1n 11112111011 rà 23

2.3 _ Quy trình kiểm thử tự động 5s s t1 EE 2121822 HH grưyg 24

2.4 Ưu điểm và nhược điểm của kiêm thử tự động - 5 scccccrxecsrn 27

2.5 Các loại kiểm thử tự động L0 2.0212 H2 011g 11H 1x He 27

2.6 Các bước xây dựng kiêm thử tự động 5 se rryerưyn 28

CHƯƠNG 3: XÂY DỰNG HỆ THÔNG TEST CASE CHI TIẾT CHO MỘT SỐ

II 30

1.1 465i 8 ốẽaắÁDD HH 30

1.2 _ Các thành phần chính của test case tempÌafe + ccccs xxx csexsei 30 1.3 _ Xác định các trường hợp của fesf Ca§€ Q Q2 chớ 32 1.4 _ Các kỹ thuật thiết kế test case trong kiêm thử phần mềm 32

15 Một số lưu ý khi khi viết t€S{ Ca§€ s ST Tnhh ng HH Hye 34 2 Thực hành viết test case chỉ tiết cho các chức TIẴN Q 222 222222 35

2.1 _ Quản lý tích điểm cc TT HH HH trưa 35

(Lê Thị Trang — 209363 — 631T3]

2.2 H@ thong ban hang cece cececcscescesessesveseesessesessssvsseseceessvseesecsvssesecareecees 67 CHUONG 4: SU DUNG CONG CU SELENIUM WEBDRIVER DE XAY DUNG

TEST SCRIPT CHO MOT SO TEST CASE CO BAN w.eesccscecssteessseesesstieteesneeen 74

I _ Téng quan vé Selemium cc.cccceccecsccsscssescssesvesessesessesevssesssnssvsseseseesavseesesereess 74 1.1 Selentum Integrated Development Environment (Selenium [DE) 75 1.2 _ Selenum Remofe Control (Selenium R) 2 2522222 76 Na 00a 77 IS ai 5 77

1.5 _ Lưu ý về Hỗ trợ trình duyệt và môi trường s5 se se se rrerereey 78

1.6 Cách lựa chọn Công cụ Selenium phù hợp - 2 22c c2 scc+ccsxs 78 1.7 Selenium hoat động như thé MAO? eo ccccecccecececscscscsesescsesescsesescsssesesevevecsees 79 2 Công cụ kiểm thử tự động Selenrum WeblDrIver c c2 c2 e2 80

2.1 Các command được sử dụng thường xuyên óc 2c se 81 2.2 Các phương pháp tìm kiếm các đối tượng WebElement csscs¿ 82

2.3 Các câu lệnh điều hướng trình duyệt 5c 5S E seeryt 84

2.4 Các lệnh swltch - c9 2099 11110110 1v S1 g3 155511 ng nà 84 2.5 @ i0 0/1 cccccceeecseeeececccccecccccevseeessttttttsseeeeeccccesseeeenaea 85

EAW va c6 86

3.5 Các tính năng nồi bật của Tes(NG sS T2 SE 1E net re 87 3.6 Mét 86 wu diém ca TestNG cccccccccccccscscssscscscsescsssescscsesvscsvsvsesesvseseseseees 87 3.7 Các bước viết một test case sử dụng TestNG co se 87

3.8 Chu thich (Annotation) trong Test NG ccc 222 nhe ne, 87

3.9 Lợi ích của việc sử dụng chú thích - - c2 2 221221 12112221111 1x rrkey 88

3.10 Những method assert tiêu biêu do TestNG cung cấp cscccccse: 88 3.11 Xử ly User Interactons với Actions class và Robot cÌass 88 3.12 File testng.xmiL 2 2 2112121212111 111121118115 1111811181121 khe re 90

4 Sử dụng công cụ kiểm thử tự động để tạo Test Script cơ bản 94

4.L _ Chức năng đăng nhập 2L 2 222221211121 11 151112211111 vey 94

4.2 _ Tính năng Quản lý tích điểm 5-1 S1 E1 12121121 E1 prg rên 98

CHƯƠNG 5: KẾT LUẬN VÀ ĐỊNH HƯỚNG PHÁT TRIỂN -. - 100

(Lê Thị Trang — 209363 — 631T3]

Lo K@tQuatnecccccccccccccccccccccccecevesescsvsvsvesesesvsveseseavsvsveseacsvavavsreassseveseseseatsteeesssecavens 100

PM ` 100 3 Định hướng phát triển cccc che 100

0059 2225 101

1.1 Download Chrome IDTIVeT c1 11211511153 191 119211181111 1211 811 re 101 1.2 — Cài đặt Java JDK ST HH HH Hà He nhu 101 1.3 — Cải đặt Eclipse 2 2211121112212 HH He 104 14 Cài đặt TestNG trong EcÌipse - c2 2212 Hee 105 r8 0i e- 109

(Lê Thị Trang — 209363 — 631T3]

CHUONG 1: DAT VAN DE VA DINH HUONG PHAT TRIEN 1 Ly do chon dé tai

Các sản phâm phần mềm nói chung và các ứng dụng web nói riêng đang ngày càng

được sử dụng rộng rãi và chứng tỏ vai trò to lớn của chúng trong mọi hoạt động thực tế

của con người hiện nay Từ việc kinh doanh bán hàng online, thanh toán các hóa đơn mua bán, trao đôi thông tin qua mạng internet, đến việc số hóa các quy trình sản xuất, quản lý dữ liệu theo các bài toán nghiệp vụ khác nhau Tuy nhiên, chất lượng của các sản phâm này chưa thực sự được đảm bảo, gây ra hao phí rất lớn trong quá trình phát triên phần mềm, nhất là trong giai đoạn bảo trì

Đề đáp ứng những yêu cầu ngày càng cao của người dùng và nâng cao chất lượng sản pham đầu ra mà vẫn dam bảo chỉ phí chấp nhận được khi phát triển ứng dụng, đồng thời giảm thiêu tôi đa chỉ phí trong giai đoạn bảo trì (thường chiếm đến 70% chi phi trong chu kỳ sống của phần mềm ứng dụng), kiểm thử là một công việc không thẻ thiếu trong quá trình phát triển phần mềm và là một công việc phù hợp với khả năng và định hướng của tôi

Với mục tiêu tích lũy thêm những kinh nghiệm và hiểu biết về lĩnh vực này, tôi đã lựa

chọn đề tài này như một hướng nghiên cứu cho việc đảm bảo chất lượng sản pham

phần mềm, đặc biệt là với các ứng dụng web

2 Tính cấp thiết của đề tài

Do nhu cầu rất lớn của xã hội mà các hệ thông website từ nhỏ đến lớn đã và đang phát triên nhanh chóng về số lượng Tuy nhiên cùng với trình độ của đội ngũ kỹ thuật viên,

định hướng phát triển sản phẩm phần mềm; với áp lực kinh doanh, giá thành sản

phẩm mà chất lượng của đa số các hệ thông website ở Việt Nam mới chỉ dừng ở

mức “chấp nhận được” Các khâu từ thiết kế chỉ tiết, đến kiêm thử, đánh giá chất

lượng, tinh dé sử dụng, trải nghiệm người dùng của ứng dụng thường đều bị lược bớt và chỉ tập trung vào việc mã hóa phần mềm để nhanh chóng cho ra các bản mẫu có thê sử dụng được ngay

Trong tình hình này, việc “Kiểm thử và đánh giá chất lượng của ứng dụng” từ nhiều

góc nhìn (chủ yếu từ phía người sử dụng) là rất cần thiết Bởi lẽ nó đóng vai trò đánh

giá một cách chuẩn xác kết quả của việc phát triển ứng dụng từ một góc nhìn khác không phải từ nhà phát triên hay chỉ đơn thuần dựa trên góc nhìn của người sử dụng mà người kiêm thử cần có những hiểu biết về kiến trúc hệ thống bên trong, về quy trình nghiệp vụ và đóng vai trò người dùng cuối để sử dụng hệ thống, từ đó sẽ giúp ích rất nhiều trong việc cải thiện chất lượng cũng như giảm thiểu tối đa chỉ phi bao trì cho các sản phẩm phần mềm, đặc biệt là với các ứng dụng web

(Lê Thị Trang — 209363 — 631T3]

I3 Từ những kiến thức cơ bản đã có ở (3.L.), tiến hành xây dựng hệ thông Test

case chi tiết cho các chức năng chính của phân hệ lõi và một số phân hệ con

chính thuộc "Hệ thống bán hàng”

III4 Tìm hiểu công cụ kiểm thử tự động và áp dụng đề xây dụng nên Test Scrip cho một số Test case cơ bản ở (3.3.)

4 Dịnh hướng giải pháp Một quá trình nghiên cứu khoa học thường sẽ theo một quy trình nhất định từ: Khao sat nhu cầu thực tế Thu thập tài liệu, Lựa chọn phương pháp, Lựa chọn công nghệ, và cuối cùng là áp dụng lý thuyết vào thực tế Và đồ án này của tôi cũng sẽ di theo quy trình đó

- _ BI Khảo sát nhu cầu thực tế: Song hành với việc các phan mém ứng dụng được phát trién ngay cảng nhiều thì chất lượng của sản phẩm phần mềm cũng đang được quan tâm nhiều hơn, do nó đang trở thành một yêu tố quyết định dẫn đến sự thành bại của một ứng dụng Nắm bắt được nhu cầu đó, tôi đã quan tâm và bắt tay vào tìm hiểu và nghiên cứu các kỹ thuật nhằm nâng cao chất lượng cho các ứng dụng phần mềm Đề khi tôi có cơ hội

tham gia vào một dự án có thê phát hiện sớm các sai sót, hỏng hóc, lỗi trong các

giai đoạn của quá trình phát triên Điều này sẽ rất có lợi cho việc cắt giảm hao phi

(về cả kinh tế và công sức lao động) một cách tôi đa, đảm bảo đạt được yêu cầu đặt

ra ban đầu là: “nâng cao chất lượng đầu ra của phần mềm” - - B2, Thu thập tài liệu:

Do đây là một lĩnh vực đã không còn xa lạ gì trên thế giới và nhưng lại còn khả mới mẻ và chưa có nhiều sự chuyên nghiệp ở Việt Nam, nên việc thu thập tài liệu cũng như tìm kiểm các công nghệ phụ trợ còn khá khó khăn cho tôi do hạn chế về thời gian, kinh nghiệm và sự bất đồng ngôn ngữ Tôi đã có gắng tìm kiếm các tài liệu liên quan và nghiên cứu sự phù hợp của nó với hướng đi trong đồ án này Các tài liệu trong lĩnh vực này còn khá tổng quan và trừu tượng, chưa có một tài liệu nào thực sự hoàn chỉnh và đầy đủ, chỉ tiết để có thê sử dụng trực tiếp Kết quả của đỗ án này là tống hợp của rất nhiều các tài liệu liên quan khác nhau trong lĩnh vực còn khá mới mẻ này

® Kiểm thử thủ công bằng cách tự thực thi các Test case đã viết, xem xét trao

đổi với nhóm phát triển hệ thống để đưa ra các mức độ và giải pháp giải quyết vẫn đề

© _ Tìm hiểu công cụ kiểm thử tự động và áp dụng để xây dựng nên Test Script cho một số chức năng cơ bản để xem mức độ tối ưu hóa về mặt thời gian và

chỉ phí, những khó khăn, hạn chế của kiêm thử tự động so với kiểm thử thủ

công Sau một thời gian nỗ lực nghiên cứu và tìm tòi, tôi cũng đã chọn được các phương pháp thích hợp với từng hướng đi cụ thê, cho phép hiện thực hóa hướng nghiên cứu nảy

- - B4, Lựa chọn công nghệ:

Với yêu cầu xây dựng Test Script phuc vu cho việc kiểm thử tự động một số Test

case cơ bản, công cụ như Selenium IDE (để tự động sinh các ca kiểm thử) và

Selentum WebDriver (là một thư viện tích hợp vào Editor đề hỗ trợ cho việc chỉnh

sửa Test Script) sẽ rất phù hợp và giúp cho việc thực hiện kiêm thử tự động cũng như tùy chọn các ca kiểm thử dễ dàng hơn Do đó, công cụ được lựa chọn sử dụng trong Đồ án tốt nghiệp này là: Selenium WebDriver

- BS Ap dung lý thuyết vào thực tế: Dựa trên một dự án thực tế với người dùng là người bán hàng, cụ thể là “Hệ thống

bán hàng”, tôi đã áp dụng những kiến thức về kiểm thử ở trên vào kiểm thử ứng

dụng web với các yêu cầu nghiệp vụ thực tế tiếp nhận được từ phía người dùng Xuất phát điểm từ những tìm hiểu và nghiên cứu của bản thân, cùng sự trợ giúp từ nhiều phía, tôi đã thực hiện đề tài này trong khoảng thời gian khá eo hẹp và cũng đã

đạt được một số kết quả nhất định

Nội dung chính của Đồ án tốt nghiệp cũng như các kết quả đạt được sau quá trình tìm hiểu, nghiên cứu và áp dụng thực tế tôi sẽ mô tả chi tiết hơn trong các phần tiếp theo sau đây

(Lê Thị Trang — 209363 — 631T3]

CHUONG 2: TIM HIEU CO SO LY THUYET VE KIEM THU

1 Tổng quan về kiểm thử phần mềm 1.1 Kiểm thử phần mềm là gì

Kiểm thử phần mềm có nhiều định nghĩa khác nhau được đề xuất bởi nhiều tô

chức hay cá nhân khác nhau Ví dụ như một số định nghĩa nỗi bật sau:

e - Dịnh nghĩa của Myer (1979): “Kiểm thử phần mềm là quá trình thực thi một

chương trỉnh với mục đích tìm ra lỗi.”

® - Hai định nghĩa của IEEE (1990):

o Kiém thử phần mềm là quá trình vận hành một hệ thống hoặc một thành

phần của hệ thông với các điều kiện xác định, nhận xét và ghi lại các kết

quả, tạo ra đánh giá về những khía cạnh của hệ thống hay thành phần đó o_ Kiểm thử phần mềm là quá trình phân tích các yếu tổ phần mém dé phat

hiện những khác biệt giữa chương tình với các điều kiện yêu cầu và đánh

giá các đặc điểm của các yếu tô phần mềm

> Từ các định nghĩa trên, có thê định nghĩa một cách dễ hiểu và khái quát

nhất: Kiêm thử phần mềm là quá trình thực thi I chương trình với mục đích tìm ra lỗi Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng và của sản phẩm đã đặt ra

1.2 Mục tiêu của kiếm thử phần mềm

¢ Tim cac bug phat sinh trong giai đoạn phát triền e - Đạt được sự tự tin và cung cấp thông tin về mức độ chất lượng © Dê ngăn ngừa lỗi

® Đảm bảo kết quả cuỗi cùng đáp ứng các yêu cầu kinh doanh và người sử dụng

¢ Để đạt được sự tín nhiệm của khách hàng bằng cách cung cấp cho họ một sản phẩm chất lượng

1.3 Một số khái niệm liên quan đến kiểm thử phần mềm e - Chất lượng phần mềm (Software quality): là mức độ mà một hệ thống, thành

phần hay quy trình đáp ứng các yêu cầu của đặc tả phần mềm, các nhu cầu mong đợi của khách hàng hoặc người sử dụng

® Đảm bảo chất lượng phần mềm (Software quality assurance): là một quy trình có kế hoạch và hệ thống của tat cả các hành động cần thiết đê cung cấp các thông tin đầy đủ đảm bảo các sản phâm có phù hợp với các yêu cầu về

kỹ thuật hay không Mục đích cuối cùng là để đánh giá quy trình sản xuất

sản phẩm phần mềm (Lê Thị Trang — 209363 — 631T3]

¢ Xac nhan (Validation): la qua trinh danh gia mét hé thong hay các phần

trong hay cuối của quá trình phát triển để xác định xem nó có đáp ứng yêu cầu quy định

® Re-test (Test lại): là việc kiểm tra lại những test case đã fail từ lần kiểm tra

cuối cùng và xác minh những test case đó đã hoạt động theo kết quả mong muốn

® Lỗi (Error/Mistake): Lỗi là những van đề mà con người mắc phải trong quá trình phát triển các sản phẩm phần mềm (lỗi do con người gây ra)

® Sai (Bug/Defect /Fault): Là một khiếm khuyết trong một thành phần hoặc hệ thông mà nó có thê làm cho thành phần hoặc hệ thống này không thực hiện đúng chức năng yêu cầu của nó

e That bai (Failure): Thất bại xuất hiện khi một lỗi được thực thi (sự khác biệt

giữa thực tế làm ra và yêu cầu khách hàng) ¢ Sucéd (Incident): Khi thất bại xuất hiện, nó có thể hiển thị hoặc không, tức là

rõ ràng hoặc không rõ ràng đối với người dùng hoặc người kiểm thử Sự cố

là triệu chứng liên kết với một thất bại và thê hiện cho người dùng hoặc

người kiểm thử về sự xuất hiện của thất bại này

© Ca kiểm thử (Test case): Ca kiểm thử gồm một tập các dữ liệu đầu vào và một xâu các giá trị đầu ra mong đợi đối với phan mềm, mục đích là dựa vào đó để kiểm tra xem phần mềm có thỏa các yêu cầu đặt ra hay không

®_ Kịch bản kiểm thử (Test script: Một kịch bản kiểm thử là một nhóm mã

lệnh dạng đặc tả kịch bản dùng để tự động hóa một quy trình hay một ca kiểm tra, giúp cho việc kiêm tra nhanh hơn, hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi

1.4 Các nguyên tắc cơ bản của kiểm thử phần mềm - _ Nguyên tắc 1: Kiểm thử luôn có lỗi

© Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thê chứng minh rằng một phần mềm không có lỗi

®_ Kiêm thử làm giảm xác suất lỗi tiềm ân trong phần mềm, ngay cả khi đã

kiêm thử nghiêm ngặt phần mềm vẫn có thê còn lỗi Vì vậy, cần phải tìm

được càng nhiều lỗi càng tốt - Nguyên tắc 2: Kiểm thử toàn bộ là không thể

®_ Kiểm thử với tất cả các kết hợp đầu vào và đầu ra, với tất cả các kịch bản là

không thê trừ khi kiêm thử chỉ bao gồm một số ít trường hợp thì có thê kiêm

thử toàn bộ

e Thay vi kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên sự mức độ ưu tiên người kiểm thử có thể tập trung việc kiểm thử vào một số điểm cần thiết, có

(Lê Thị Trang — 209363 — 631T3]

1.5

nguy cơ lỗi cao hơn Nghĩa là phải lên kế hoạch kiểm thử, thiết kế trường

hợp kiểm thử sao cho có độ bao phủ nhiều nhất và giảm thiêu rủi ro sót lỗi

khi đến tay người dùng Nguyên tắc 3: Kiếm thử càng sớm càng tốt

¢ Để tìm được lỗi sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm

cảng tốt trong quy trình phát triển (vòng đời phát triển) phần mềm hoặc hệ

thống, và nên tập trung vào các hoạt động/mục tiêu đã xác định trước ® Các hoạt động kiểm thử được bắt đầu càng sớm thì sẽ phát hiện ra lỗi sớm

khi đó ít tốn công đề tìm lỗi và sửa chữa Nguyên tắc 4: Sự tập trung của lỗi e - Thông thường, lỗi tập trung vào những module, thành phần chức năng chính

của hệ thống Nếu xác định được điều nay ban sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả

Nguyên tắc 5: Nghịch lý thuốc trừ sâu e - Nếu bạn sử dụng cùng một tập hợp các trường hợp kiêm thử liên tục, sau đó

một thời gian các trường hợp kiểm thử không tìm thấy lỗi nào mới Hiệu quả của các trường hợp kiểm thử bắt đầu giảm xuống sau một số lần thực hiện, vì vậy luôn luôn chúng ta phải luôn xem xét và sửa đối các trường hợp kiêm thử trên một khoảng thời gian thường xuyên

Nguyên tắc 6: Kiểm thử phụ thuộc vào ngữ cảnh © _ Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta

phải tiếp cận kiểm thử theo nhiều ngữ cảnh khác nhau Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di động bằng cách sử dụng chiến lược kiểm

thử giống nhau, thì đó là sai Chiến lược để kiêm thử ứng dụng web sẽ khác với kiêm thử ứng dụng cho thiết bị di động của Android

Nguyên tắc 7: Không có lỗi — sai lầm e - Việc không tìm thấy lỗi trên sản phâm không đồng nghĩa với việc sản phẩm

da san sang dé tung ra thị trường Việc không tìm thấy lỗi cũng có thê là do

bộ trường hợp kiểm thử được tạo ra chỉ nhằm kiểm tra những tính năng được

làm đúng theo yêu cầu thay vì nhằm tìm kiếm lỗi mới

Các cấp độ kiểm thử phần mềm

Một sản phâm phần mềm từ khi bắt đầu phát triển đến khi hoàn thành và đến tay

người dùng cuối thường trải qua bốn mức kiểm thử bao gồm: Unit test (Kiểm thử đơn vị), Intergration Tests (Kiểm thử tích hợp), System Tests (Kiểm thử hệ thống) và Acceptance Tests (Kiểm thử chấp nhận) Tùy theo yêu cầu và đặc (Lê Thị Trang — 209363 — 631T3]

Unit Testing là giai đoạn đầu tiên trong kiểm thử phần mềm Unit Testing được

thực hiện nhằm kiểm tra và xác định các module riêng lẻ thuộc mã nguồn có hoạt

động đúng hay không Mục đích của kiểm thử mức đơn vị như sau:

® Xác định mỗi đơn vị phần mềm có đang thực hiện theo đúng thiết kế ban đầu

hay không e Thông qua thử nghiệm sẽ giúp khắc phục những phát sinh do việc thay đổi hay

bảo trì code Unit Testing giúp tiết kiệm chỉ phí, thời gian và thể diện khi phát hiện ra lỗi Kiểm thử thực hiện trên các hàm (Function), thủ tục (Procedure), lớp (Class) hay

phương thức (Method) đều được coi là kiểm thử mức đơn vị Đề thực hiện được kiểm thử ở mức này, kiêm thử viên phải có hiểu biết về thiết kế

chương trình, đòi hỏi phải kiểm tra từng nhánh lệnh và code, trong thực tế việc lựa

chọn các nhánh đề đơn gián hóa việc kiểm thử và bao phủ hết unit đòi hỏi phải có

kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa nên người thực hiện kiểm thử mức này thường được thực hiện bởi lập trình viên

Công đoạn này cần được thực hiện cảng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm

(Lê Thị Trang — 209363 — 631T3]

+,

Integration Testing |] (Kiém thử tích hợp) là một loại kiểm thử trong đó các module

của phần mềm được tích hợp logic và được kiêm thử theo nhóm Một dự án phần mềm điện hình bao gồm nhiều module, được code bởi các lập trình viên Kiểm thử tích hợp là kiêm thử sự tương thích giữa các module đó Do đó,

kiêm thử tích hợp còn được gọi làI & T(Tich hop va Kiém thir), String Testing (Kiêm thử chuỗi) và đôi khi là Thread Testing (Kiêm thử luồng)

Hai mục tiêu chính: © - Phát hiện lỗi giao tiếp xảy ra giữa các Unit ¢ Tích hợp các Unit đơn lẻ thành các hệ thông nhỏ và cuối cùng là nguyên hệ

thông hoàn chính chuẩn bị cho kiêm thử ở mức hệ thống

Kiểm thử tích hợp gồm bốn loại kiểm tra: ¢ Kiém tra cấu trúc (structure): Tương tự White Box Test (kiểm tra nhằm đảm

bảo các thành phần bên trong của một chương trình chạy đúng), chú trọng

đến hoạt động của các thành phan câu trúc nội tại của chương trình, các lệnh

va các nhánh bên trong ® Kiêm tra chức năng (functional): Tương tự Black Box Test (kiểm tra chỉ chú

trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong), chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật ¢ Kiém tra hiéu nang (performance): Kiém tra việc vận hành của hệ thống ® Kiém tra kha năng chịu tải (stress): Kiểm tra các giới hạn của hệ thống Mức độ 3: System Testing — Kiêm thử hệ thống

System Testing (Kiểm thử hệ thống) là một phương pháp theo dõi và đánh giá hành vi của sản phâm hoặc hệ thống phần mềm hoàn chỉnh và đã được tích hợp đây đủ, dựa vào đặc tả và các yêu cầu chức năng đã được xác định trước Đó là giải pháp cho câu hỏi "Liệu hệ thống hoàn chỉnh có hoạt động đúng với yêu cầu hay không?" System Testing duoc thir nghiém trong hép den, tire là chỉ có các tính năng làm việc bên ngoài của phần mềm được đánh giá trong quá trình thử nghiệm này Nó

không đòi hỏi bất kỳ kiến thức nội bộ nào về coding, lập trình, thiết ké, và hoàn

toàn dựa trên quan điểm của người dùng System test gom nhiều loại kiểm thử khác nhau, một số loại pho bién nhat gồm:

¢ Functional Testing (Kiém thir chirc nang): Bao dam cac hanh vi ca hé thong

thỏa mãn đúng yêu câu thiết kẻ

¢ Interface/GUI Test (Kiểm thử giao diện người dùng): Là kỹ thuật kiểm thử

để xác nhận xem giao diện của phan mềm có hoạt động đúng như mong đợi

hay không (về các đôi tượng trên giao diện, vị trí, màu sắc, lỗi chính tả, trạng thái của các đôi tượng

(Lê Thị Trang — 209363 — 631T3]

Performance Testing (Kiểm thử hiệu năng): Đảm bảo tôi ưu việc phân bồ tải

nguyên hệ thông (bộ nhớ, .) nhằm đạt các chí tiêu như thời gian xử lý hay

đáp ứng câu truy vấn Stress Test (Kiểm thử khả năng chịu tải): Đảm bảo hệ thống vận hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) Stress Test tập trung vào các trạng thái tới hạn, các “điểm chết”, các tình huống bất thường như đang giao dịch thì ngắt kết nỗi (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM )

Configuration test (Kiém thtr cau hinh): Kiém thử sự tương thích giữa phần mềm và phân cứng

Security Test (Kiém thử bảo mật): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống

Recovery Test (Kiểm thử khả năng phục hồi): Bảo đảm hệ thông có khả năng khôi phục trạng thái ôn định trước đó trong tinh huéng mat tài nguyên hoặc dữ liệu, đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến

s* Mức độ 4: Acceptance Testing - Kiểm thử chấp nhận - _ Acceptance Testing (Kiêm thử chấp nhận) là một kiểm thử nhằm xác định hệ thông

phần mềm có đạt yêu cầu kỹ thuật hay không Bằng việc kiểm tra các hành vi của

hệ thống qua dữ liệu thực tế, kiêm thử chấp nhận sẽ xác định có hay không việc hệ

thống đáp ứng được các tiêu chí lẫn yêu cầu của khách hàng - _ Một số kỹ thuật được sử dụng trong Acceptance Testing đó là: phân tích giá trị biên

giới, phân vùng tương đương và sử dụng bảng quyết định

- Kiểm thử chấp nhận gồm 2 loại là: Alpha test và Beta test Sự phân biệt của 2 loại kiểm thử được thẻ hiện rõ rệt như bảng sau:

Chi str dụng kỹ thuật kiêm tra hộp đen

Xác định các lỗi có thê xảy Ta Kiếm tra chât lượng của sản phâm

Các nhà phát triển bắt đầu sửa lỗi ngay

sau khi chúng được xác định

Người dùng tìm thấy lỗi và phản hỏi là

cân thiết

Chu kỳ thực hiện dài Chỉ mât một vài tuân

Có thê dê dàng thực hiện vì nó được

Sẽ được thực hiện trong phiên bản tương

(Lê Thị Trang — 209363 — 631T3]

thực hiện trước khi kết thúc quá trình

Chức năng và khả năng sử dụng đã

được thử nghiệm

Khả năng sử dụng, chức năng, bảo mật,

độ tin cậy được kiểm tra với độ sâu tương tự

Bang 1: So sanh Alpha Test va Beta Test

2 Kiếm thử tự động

Kiểm thử tự động là thực hiện kiểm thử phần mềm một cách tự động các

bước trong một kịch bản kiểm thử bằng một chương trình đặc biệt với các

tập lệnh và sử dụng phần mềm phù hợp để kiêm thử phần mềm Về cơ bản nó là một quá trình tự động hóa của một quy trình kiểm thử thủ công giúp

cho người thực hiện việc kiêm thử phần mềm không phải lặp đi lặp lại các 2.1 Khái niệm kiếm thử tự động

bước nhàm chán 2.2 Tại sao cần kiểm thử tự động?

e _ Tiết kiệm tiền bạc và thời gian kiểm thử: Kiểm thử tự động sử dụng các công cụ có sẵn đề ghi lại bộ kiêm thử này và phát lại nó theo yêu câu Kiểm thử tự động là tự động hóa công việc, không cần can thiệp của con người nên có thê chạy tự động kiêm tra mà không cần giám sát

¢ Tăng độ chính xác: Nhờ độ ôn định cao, kiêm thử tự động có thẻ thực thi

các test case với độ chính xác cao hơn

® - Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiêm thử tự động, chúng

ta có thể thực thi số lượng lớn test case trong một thời gian ngắn Nên độ

bao phủ của nó rất cao Điều này giúp chúng ta tăng độ bao phủ trong giai doan regression test

® - Hoàn thành các công việc mà con người không thê làm được: Nếu chúng ta muốn thực thi load test, performance test, thi kiểm thử tự động là cách duy nhất

e Tự động tăng tốc độ thực hiện kiểm tra, có thể nhanh hon 70% so với

kiêm tra thủ công

(Lê Thị Trang — 209363 — 631T3]

2.3 Quy trình kiểm thử tự động

Phát triển Test Seript

Hình 2: Quy trình kiểm thử tự động “+ Lap kết hoạch

- Mục đích: Chỉ định và mô tả các loại kiểm thử sẽ được triển khai và thực hiện

Kết quả là bản kế hoạch kiểm thử phần mềm bao gồm chỉ tiết từ các loại kiểm

thử, chiến lược kiểm thử, cho đến thời gian và phân định lực lượng kiêm thử

————> Xác định yêu cầu kiếm thử IT

Xác định các chiến lược kiêm the | Kế hoach kiểm

Thông báo tới các bên liên quan |

®© Xác định yêu cầu kiểm thử: Xác định những gì cần phải kiểm thử dựa theo

yêu cầu từ khách hàng, đặc tả yêu cầu người sử dụng

(Lê Thị Trang — 209363 — 631T3]

đánh giá xem bản kế hoạch kiểm thử có phù hợp với yêu cầu dự án chưa

Nếu chưa thì sẽ phải thực hiển sửa lại theo yêu cầu

® Thông báo tới các bên liên quan: Trưởng dự án sẽ gửi thông báo toàn bộ những người trong dự án có liên quan đến kế hoạch kiểm thử

“> Thiết kế test case (thiết kế trường hợp kiểm thử)

- Mục đích: Nhằm chỉ định các test case và các bước kiểm tra chỉ tiết cho mỗi

| Xem xét và đánh giá % | |

Chưa đạt [

Ta ( Kêtthúc )

Hình 4: Các bước thiết kế kiểm thử

s* Phát triển Test Script - Mục đích: Bước này thường không bắt buộc trong các loại và mức kiểm thử, chỉ

yêu cầu trong những trường hợp đặc thù cần thiết kế, tạo ra cac test script co kha

năng chạy trên máy tính giúp tự động hóa việc thực thị các bước kiểm tra đã định nghĩa ở các bước thiết kế test case

(Lê Thị Trang — 209363 — 631T3]

Trong do, mét test script được hiểu là một nhóm mã lệnh dang đặc tả kịch bản

dùng đề tự động hóa một trình tự kiểm thử, giúp cho việc kiểm thử nhanh hơn,

hoặc cho những trường hợp mà kiểm thử bằng tay sẽ rất khó khăn hoặc không

khả thi Cac test script co thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm thử tự động

|

ho /

Thiết lập môi trường và cài đặt: Đề thực hiện kiểm thử, thao tác đầu tiên cần

làm là xác lập và khởi động môi trường kiêm thử Việc này nhằm đảm bảo tất cả

các bộ phận liên quan (phần cứng, phần mềm, may chu, mang, dữ liệu ) đã

duoc cai dat va san sàng trước khi chính thức bắt đầu thực hiện kiểm thử Tiến hành kiểm thử theo các trường hợp kiểm thử đã chuẩn bị Thâm định kết quả kiêm thử: Sau khi tiễn hành kiểm thử, kết quả kiểm thử cần được xem xét để đảm bảo kết quả nhận được là đáng tin cậy Nhận biết được

những lỗi không phải do phần mềm mà do đữ liệu dùng để kiểm thử, môi trường

kiêm thử, hoặc các bước kiểm thử gây ra Nếu thực sự lỗi xảy ra do quá trình

kiểm thử, cần phải sửa chữa và kiểm tra lại từ đầu

s* Đánh giá quá trình kiểm thử

(Lê Thị Trang — 209363 — 631T3]

- Bao gom xem xét và đánh giá kết quả kiêm thử lỗi, chỉ định các yêu cầu thay

đổi và tính toán số liệu liên quan đến quá trình kiểm thử (chăng hạn số giờ, thời

gian kiểm tra, số lượng lỗi ) - _ Các bước đánh giá quá trình kiểm thứ: ¢ Thống kê số lượng lỗi

e Phan tích kết quả kiểm thử và yêu cầu sửa chữa: Chỉ định và đánh giá sự khác

biệt giữa kết quả mong đợi và kết quả thực tế, tổng hợp và gửi thông tin yêu cầu

sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau

đó

© Đánh giá chất lượng sản phâm kiêm thử: Từ những kết quả kiểm thử, nhóm

kiêm thử sẽ xem xét, đánh giá chất lượng sản phẩm ® Thông báo tới các bên liên quan: Trưởng dự án sẽ thông báo cho các bên liên

quan về kết quả kiêm thử đạt được

2.4 Ưu điểm và nhược điểm của kiểm thử tự động # Ưu điểm

e D6 tin cay cao: Céng cu kiém thử tự động có sự ôn định cao hơn so với các

e© Tốc độ cao: Do là công cụ kiểm thử tự động bằng máy nên việc kiểm thử tự

động nhanh hơn nhiều so với kiểm thử thủ công

Chi phí thấp: Nếu áp dụng kiểm thử tự động một cách khoa học giúp người thực hiện giảm chị phí, thời gian và nhân lực

Nhược điểm

® Các công cụ kiểm thử tự động mặc dù rất thuận tiện về nhiều phương diện

nhưng thực tế dù như thế nào đi chăng nữa thì nó cũng không phải là một công cụ có thê thay thế hoàn toàn quá trình kiêm thử thủ công

Để thực hiện các thiếp lặp tự động thì vẫn cần một TBƯỜI CÓ kiến thức về lập trỉnh, tư duy logic

© Mất thời gian và công sức để tạo mới và chỉnh sửa script phức tạp © Mất chi phí cho các các công cụ tự động hóa như phí bản quyền, bảo trì, đào

tạo

2.5 Các loại kiểm thử tự động

Kiếm thử chức năng (Lê Thị Trang — 209363 — 631T3]

‹ s

Kiểm thử chức năng là một loại kiểm thử hộp đen và test case của nó được viết

dựa trên đặc tả của ứng dụng phần mềm Các chức năng được kiêm thử bằng cách nhập vào các giá trị nhập vào và kiểm tra các kết quả đầu ra, không quan tâm đến cấu trúc bên trong của phần mềm

Kiểm thử chức năng phần mềm là một quy trình cố gắng tìm ra các sự khác biệt giữa đặc tả bên ngoài của phần mềm và thực tế của phần mềm cung cấp Một số công cụ kiểm thử chức năng: Selenium, QTP (Quick Test Pro), Appium, Kiém thir hiéu nang (Performance Testing)

Kiểm thử hiệu năng là một loại kiểm thử nhằm xác định mức độ đáp ứng, độ tin

cậy và khả năng mở rộng hệ thông dưới một khối lượng truy cập nhất định Kiểm thử hiệu năng thường được dùng để giúp xác định tắc nghẽn trong một hệ thống, thiết lập một đường cơ sở để kiểm thử trong tương lai, hỗ trợ điều chỉnh

hiệu suất hiệu quả, xác định sự phù hợp mục tiêu và yêu cầu hiệu suất, và thu

thập dữ liệu hoạt động liên quan khác để giúp các bên liên quan đưa ra quyết định liên quan đến chất lượng chung của các ứng dụng đang được kiểm thử Ngoài ra, các kết quả từ việc kiểm thử hiệu suất và phân tích có thể giúp nhà phát triển ước tính cầu hình phần cứng cần thiết để hỗ trợ các ứng dụng khi đưa sản phẩm đi vào sử dụng rộng rãi

Một số công cụ kiểm thử hiệu nang:0 LoadRunner, Jmeter Cac bước xây dựng kiểm thử tự động

Bước l1: Phân tích khả năng áp dụng kiểm thử tự động

Kiểm thử viên không thê tự động hoá mọi việc trong kiêm thử phần mềm được Có những phần mềm mới hay công nghệ viết ra phần mềm mà những công cụ

kiểm thử tự động hiện tại chưa hỗ trợ hoặc chỉ hỗ trợ một phân

Bước 2: Lựa chọn công cụ kiểm thử tự động thích hợp

Sau khi xác định được sản phẩm hiện tại có thê làm kiểm thử tự động hay không

thì kiểm thử viên cần đặt ra câu hỏi và xác định những van dé sau:

e - Nên sử dụng công cụ kiêm thử tự động nào?

® Công cụ kiểm thử nào hỗ trợ kiểm thử tự động cho công nghệ mà sản phâm sử dụng?

® Ưu nhược điểm của từng công cụ? ® - Ngôn ngữ kịch bản nào mà công cụ kiểm thử sử dụng? (Lê Thị Trang — 209363 — 631T3]

e Nhan sy hién tai c6 quen thudc voi céng cu do hay khéng? s* Bước 3: Xây dựng môi trường làm việc thích hợp

Môi trường làm việc bao gồm các khái niệm, chu trình, thủ tục và môi trường

mà kịch bản kiểm thử tự động được thiết kế và viết ra Bên cạnh đó, nó cũng nên bao gồm luôn cầu trúc thư mục, lưu trữ các kịch bản kiểm thử cũng như các

mối quan hệ logic giữa các thành phân

s* Bước 4: Viết kịch bản kiểm thử, thực thi và phân tích kết quả

Dựa trên các kịch bản kiểm thử đã được tạo ra bằng kiểm thử thủ công, dựa vào

ngôn ngữ kịch bản mà công cụ kiểm thử tự động hỗ trợ, người kiểm thử viết các

đoạn mã tương tác với sản phâm phần mềm trên các môi trường và thực thi nó

Sau khi thực thi các đoạn mã, người kiểm thử cần phân tích các kết quả đạt được và ghi lại các vấn đề của sản phâm, nếu CÓ

(Lê Thị Trang — 209363 — 631T3]

CHUONG 3: XAY DUNG HE THONG TEST CASE CHI TIET CHO MOT SO

CHUC NANG CHINH CUA HE THONG

1 Test case 1.1 Khái nệm

- _ Theo wikipedia: Test caselà “một tập hợp các thông số đầu vào kiểm thử, điều

kiện thực thi, và kết quả mong đợi được phát triển cho một mục tiêu cụ thể, như

thực hiện một chương trình cụ thể hay kiểm tra sự tuân thủ với một yêu cầu cụ

thể.”

- Vay test case là gì? Test case (Kịch bản kiểm thử) hiểu đơn giản là tài liệu dùng để mô tả: Dữ liệu đầu vào (Input) — Hành động (Active) — Kết quả mong đợi (Expected response) đề xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không

- Test case thường được Tester viết trên Excel hoặc Google Sheet Một test case có thể có các phan đặc thủ khác nhau như mã test case, tén test case, muc tiêu test, các điều kiện test, các yêu cau data input, cac bước thực hiện và các kết quả

mong đợi Mức chỉ tiết test case dựa vào ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm

1.2 Các thành phần chính của test case template Ngoài việc tìm hiểu test case là gì, nắm vững được các thành phần test case cũng đóng vai trò quan trọng đề tạo nên được những bộ test case chất lượng Test case template (biểu mẫu) thường gồm 5 phần chính: ID, mục đích kiểm thử, các bước thực hiện, kết quả mong đợi, kết quả thực tế

| TC_002 vua | | | | Not execte

3 |Usability Testing TC_003 Passed eeting eee Te_004 Ỉ(Vaiddata1

Edit a meeting TC_005 Jaid data 1}

[Lé Thi Trang — 209363 — 631T3]

Hinh 6: M6t test case template thông thường được tester tao dé bat dau

quá trình kiêm thứ a ID cua test case la gi?

ID cua test case la gia trị cần để xác định số lượng trường hợp cần đề kiêm thử Công thức viết ID có thê tham khảo như sau: Ký tự viết tắt tên dự án + Số thứ

tự Ví dụ: Tên dự án là ITNavi Blog, ID có thê đặt như sau: IBI, IB2, IB3

b Muc dich kiém thir (Summary) Mục đích kiêm thử mô tả ngắn gọn tester sẽ “Kiém tra chức năng gì?” hay “Test những gì” Tại đây, tester sẽ đề cập một cách chỉ tiết những gì mình sẽ test Ví

dụ: Check nhập ký tự đặc biệt vào field “Password” c Các bước thực hiện (Sfeps to reproduce)

Các bước thực hiện trong test case la muc mô tả ngắn gọn, rõ ràng các bước

thực hiện test Steps to reproduce phải đi kèm đữ liệu đầu vào của test Dữ liệu test chính là phần Input (Dữ liệu đầu vào) để kiểm tra xử lý hệ thống và trả ra

kết quả mong đợi Việc xác định dữ liệu đầu vào của test khá tôn thời gian khi

Tester phải xử lý data đề tìm ra nhập cái gì sẽ ra được kết quả mong muốn

Ví dụ: Tester nhập dữ liệu test

« Nhap username = Trangle18 ¢ Nhap password = 12345678 ¢ Click button [Login]

d Két qua mong muon (Expected results)

Trong test case, Expected results hién thị kết quả mong đợi từ những bước kiểm thử Tester sẽ đề cập một cách rõ ràng kết quả mong đợi của ứng dụng hoặc hệ thống Từ căn cứ kết quả mong đợi, tester sẽ đánh giá được phần mềm có Lỗi ( bug/defect) không, test case bị Fail không Kết quả mong đợi sẽ dựa vào tải liệu nghiệp vụ, yêu cầu khách hàng đưa ra

Ví dụ: Đăng nhập không thành công - Hệ thống báo lỗi khi nhập quá ký tự cho phép vao field “Username”

e Két qua thuc té (Test results) cua test case

Test results trong test case sẽ hiển thị kết quả thực tế từ những bước thực hiện trên môi trường của hệ thông Thông thường, tester sẽ đánh giá test case sau quá trình kiểm thử là: pass, fail & pending.Trong quá trình test, nếu kết quả không (Lê Thị Trang — 209363 — 631T3]

giống như mong đợi thi tester sẽ điền Fail Nếu kết quá khớp với mong đợi có nghĩa test case thành công, tester sẽ điền Pass Trạng thái Pending được hiểu đơn giản là test case đang gặp vấn đề cần phải thảo luận lại để tiếp tục kiêm thử

ID Test case Description | Test case Procedure Expected Result | Test Result

1 Username and Password Message displays Test user name and textbox = empty Username and password 1 Passwword empty of this case 2 Click "Log in” button are required Pass

e Abnormal case: Cac truong hop kiém thir bat binh thuong ¢ Boundary case: Cac truong hop kiém tra boundary (Phan tich giá trị biên) - Vidy: Truong hop kiém tra chire nang email:

Normal case sẽ gôm:

o Login dung dia chi email da ton tai trong hé thong o Login dia chi email chưa tồn tại trong hệ thống

o Login sai địa chỉ email không khớp với emal đã tồn tại trong hệ thông Abnormal case sé g6m:

o Login véi email khéng có ky tr @ o Login khi dang offline mode (Khong co internet)

o Login khi co dién thoai goi dén

Boundary case sé gom:

o Kiém tra khi nhap email co ký tự tối thiêu vào ô text

o_ Kiểm tra khi nhập email có ký tự tôi đa vào ô text

(Lê Thị Trang — 209363 — 631T3]

là kỹ thuật sẽ phân loại các input thanh nhimg phan vùng theo một logic nhất định Từ đó, tester sẽ chọn một input từ mỗi phân vùng đề thiết kế và thực thi test case Nếu input đó hợp lệ hoặc không hợp lệ thì cả phân vùng cũng hợp lệ hoặc không hợp lệ

- Boundary value analysis (phan tich gia ti bién): Boundary value analysis được dùng đề phát hiện lỗi ở những boundary value (giá trị biên) Test case sẽ được thiết kế cùng với các boundary value của equivalence partiioning Nếu input nằm trong boundary value thì test case là positive testing (kiểm thử tích cực) Ngược lại, néu input nam ngoai boundary value thi test case là negative testing (kiém thử tiêu cực)

- Decision table testing (kiém thir bang quyét dinh): Decision table là kỹ thuật kiêm thử giúp tester danh gia output khi két hop cac input voi nhau Bang quyét định trình bày các điều kiện input cùng những hành động hay output tương ứng Qua đó, bạn có thể xây dựng logic phần mềm dựa trên bảng quyết định - State transition testing (kiém thử chuyên đổi trạng thái): Khi dùng kỹ thuật

state transition, tester bắt buộc phân tích phan mềm theo một trình tự nhất định Trinh tự này là thứ tự chuyển đổi trạng thái của phần mềm trong sơ đồ chuyên

đổi trạng thái Kỹ thuật này được dùng để kiêm thử khả năng nhập, thoát và

chuyền đổi trạng thái của phần mềm - Use case testing (kiểm thử trường hợp sử dụng): Kỹ thuật này dựa vào use

case (trường hợp sử dụng) Use case mô tả sự tương tác giữa phần mềm và tác nhân khác như người dùng, hệ thống khác, Do đó, test case được thiết kế dựa trên use case giúp test các yêu cầu nghiệp vụ, chức năng

b KY thuật sirucfure-based Nhóm kỹ thuật structure-based giúp tester kiếm thử cấu trúc và cách vận hành bên trong của phần mềm Cấu trúc phần mềm thường bao gồm code (mã), control flow (luỗng điều khiến), data flow (luồng dữ liệu), Lúc này, tester sẽ nạp các input đề thực thi code và kiểm tra đối chiếu những output thu được Vì có liên quan đến cầu trúc phần mềm nên tester phải có kiến thức lập trình Dưới

đây là các kỹ thuật thiết kế test case thuộc nhóm structure-based:

(Lê Thị Trang — 209363 — 631T3]

- Statement testing (kiém thir cau lénh): Trong ky thuat statement testing, moi

câu lệnh trong câu trúc code sẽ thực thi it nhất một lần Qua đó, tester có thé test

được cách vận hành của toàn bộ source code (mã nguồn) phần mềm Tuy nhiên,

tester không thể kiểm thử điều kiện sai mà chỉ có thể thực thi các điều kiện

đúng - Decision testing (kiém thtr quyét dinh): Decision testing sé thực thi, test những

quyét dinh dya trén decision result (két qua quyét dinh) Dé lam diéu nay, test case sé di theo cac control flow tr decision point (diém quyét dinh) Decision testing giúp kiêm thử xem có câu lệnh không thê truy cập hay gây bất thường không

- Condition testing (kiểm thử điều kiện): Condition testing được dùng đề test các biểu thức Boolean có dạng True (đúng) hoặc False (sai) Mỗi biểu thức Boolean

sẽ được thực thi ít nhất một lần bằng cả tham số True và False Với kỹ thuật nay, test case được thiết kế dé những điều kiện Boolean có thể thực thi dễ đàng

- Multiple condition testing (kiém thir da diéu kién): Muc dich cia ky thuat nay là kiêm thử mọi tô hợp điều kiện có thể của quyết định Công thức tính số tô

hợp này là 2 lũy thừa bậc N, với N là số biến điều kiện Số lượng tổ hợp này

cũng chính là số lượng test case mà bạn phải dùng - _ Path testing (kiểm thử lộ trình): Trong kỹ thuật này, tester sẽ test từng câu lệnh

có trong source code để tìm lỗi Việc này giúp xác định lỗi tiềm ân trong một đoạn code Tuy nhiên, tester không nên áp dụng kỹ thuật path testing khi kiểm thử các phần mềm phức tạp Với câu trúc code phức tạp, số test case hay câu

lệnh mà bạn phải kiêm thử là rất nhiều

c Kỹ thuật experience-based Như tên gọi của mình, nhóm kỹ thuật này phụ thuộc vào hiểu biết và năng lực của tester Những kiến thức, kinh nghiệm của tester sẽ là cơ sở để thiết kế test

case Do do, chat lượng của các test case dựa trên kinh nghiệm sẽ hoàn toàn phụ

thuộc vào fester Nhóm kỹ thuật này được chia thành 2 loại: - _ Exploratory testing (kiểm thử thăm dò): Đây là kỹ thuật test không cần chuẩn

bị hay theo một lịch trình cụ thể Khi thực hiện exploratory testing, tester sé vừa phân tích phần mềm, vừa thiết kế và thực thi kiểm thử Ngoài ra, việc lên kế hoạch và lưu kết quả cũng diễn ra linh động trong quá trình kiểm thử

- _ Error guessing (phỏng đoán lỗi): Error guessing duoc ding dé dy doan các lỗi tiềm ân dựa trên kiến thức của tester Những kiến thức này thường về cách vận hành trước đây của phần mềm, các lỗi đã và có khả năng xuất hiện, những lỗi ma tester timg phat hién,

[Lé Thi Trang — 209363 — 631T3]

1.5 Một số lưu ý khi khi viét test case Viết test case đơn giản, minh bạch, dễ hiểu Tránh viết rườm rà, dải đòng, không đúng thông tin

Ưu tiên viết ngắn gọn, rõ ràng để các tester khác có thê đọc hiểu và test theo

được

Dữ liệu test cần được ghi đầy đủ ở từng testcase tránh trường hợp bắt đầu test mới di tim Input

Khi viết xong testcase nên được review chéo bởi tester khác trong team

Khi viết test case phải từ vị trí người dùng, người đang trải nghiệm phần mềm Không nên gộp quá nhiều kết quả conñrm vào I case Nên tách mỗi kết quả

confirm ra tung case tránh lộn xôn, sai lệch kết quả test

Test case nên vận dụng các kỹ thuật phô biến Ví dụ kiểm thử hộp đen nên vận dụng kỹ thuật: Phân tích giá trị biên (Boundary Value Analysis), phân vùng tuong duong (Equivalence Partitioning), bang quyét dinh (Decision Table), doan 16i (Error guessing)

2 Thực hành viết test case chỉ tiết cho các chức năng 2.1 Quản lý tích điểm

a lhông tin khách hàng s* Giao diện chức năng

Mã tích điểm Xờ{ Số điện thoại Tên Khách hàng Trang that Remark Tên công tự Mã số thuế

99771707919 Lễ teeta v PIC phẻ đuyệt Ss

00215454546 Test 11 v PIC pind đuyệt ® 00206454554 Testi v PIC phe ouytt 3

Toàn Test 1592 ¥ ' phé cuyệt

Lễ Hữu Tiên » PC pid đuyệt

Lé Th Test? v PIC pine đuyệt 09477777717 Test số 6 « PIC phd cpt 09874641210 La Tests ` PC phẻ đuyệt

00033547878 Tiếp Test 3 v PIC phé cuytt 0228545454 Test2 * P1 phẻ đuyệt 0312455775 Tiền Trang 90 cute v PIC phủ cuyệt 0352123110 test mượt ¥ raf 05458449444 Test Phê Duyệt Tự v Đ: phẻ cuyệt < 0 0987641232 La The Test 1 x PIC phủ uyệt Clog ty 0193138 TEOLOYALTY000002058 0352123129 Test Chin v

TÊOLOYAILTY900009057 0904972548 nguyen vi nứnh * TEOtL0VALTYð00009056 0304973548 nguyen xí ninh v TEOLLOYALTY000000054 0304505600 H:hehoho v

TEOLOVALTYO 3 0911111194% 123412 534 TOAFM ^ ÐX phé cuyệt

TEOLOYALTYð (1352180180 Tân Test! v PIC phê đuyệt TEOLOYALTYO 700 0912485776 Trang ¥ PIC phé cuytt

TEOLOVALTYCO0OZ2099 O9S5S454545 My Name's Chang Đã ph đưyệt ¥ '% phẻ đuyệt Hình 3: Giao điện phân hệ Thông tin khách hàng

(Lê Thị Trang — 209363 — 631T3]

s* Phân tích các trường hợp kiểm thử

Test

No Catesory Testcase Name Priority Step to Step Expected Result

Man hinh chinh khi hié

he ke mm enn ộ lọc: 1 Vào màn hình

Ae SA kh “Thông tin khách ‘dn thi man hj

1 - Các trường dữ liệu: bố | Normal |, ong eee Hien thi man hình nhự

ính tả hàng” thiết kế có sẵn

, ug 2 Nhân nút [Hiện bộ - Thư tự phím tắt lọc]

- Thuộc tính Input/ output Man hinh chire nang

Thêm mới/ Sửa KH tích 1 Vào màn hình

điểm *Thôngtinkhách | Hiển thị màn hình như

2 - Các trường dữ liệu: bố Normal |hàng” thiệt kê có săn

cục, chính tả 2 Nhắn nút [Thêm - Thử tự phím tắt mới]/ [Sửa] Check GUI |- Thuộc tính Input/ output

| —| M: x hinh h ; =

DSKH chưa phê duyệt: Ộ l , ` wa LA “Thông tin khách " : ` - Các trường đữ liệu: bỗ Vy Hién thị màn hình

3 cuc, 9 hinh ti i a " Normal hang” 2 Nhắn nút [DSKH : giống iống thiết kế có sã thiết kế có sản

- Thư tự Tab, phím tắt chưa phê duyệt] u

- Thuộc tính Input/ output p về

[| Màn hình chức năng L mạ dẫn 3 1 Vào màn hình

aye “Thông tin khách ¬¬

4 - Các trường đữ liệu: bỗ Normal |hang” Hién thi man “hình

cục, chính tả , „ở 2 Nhân nút [LS thay Lo giống thiết kế có sẵn

- Thư tự Tab, phím tắt đổi]

L

- Thuộc tính Input/ output

1 Vào màn hình 5 Cae button ở màn hình Hish “Thôn tin " ích Trạng thái các button

chính 8 hà oe ang” ae” thả hiện theo quy định

Các button ở các màn hình “Thông tin khách Đố

6 Check tran: chức năng DSKH chưa High |hàng” thẻ hiện th định

26x 1858 | thê duyệt 2 Nhắn nút [DSKH | P?9 *€n theo quy d

(Lê Thị Trang — 209363 — 631T3]

Trường in Các trường /ex | Cá ờng: 1 Vào màn hình

man ° ue - Ho ` “Thông tin khách Được nhập tất cả các

9 ới/Sủ - Đệm Email Normal |hàng” ký tự: số, chữ (hoa,

KH "ch - Tên 7 Nei ; 2 Nhắn nút [Thêm |thường), đặc biệt 1c! -

3 - Địa chỉ cap mới|/ [Sửa]

điểm

Trưà 1 Vào màn hình Gồm m các giá tri: các giá trí

10 khi hiện bộ -,:2 va | Trường "Trạng thái” Normal |hang” K ở wn aa |e Lu choi ae

- Nữ combobox

1 Vao man hinh ; trong man “The, nant khá h Gom các tỉnh/ TP đã đc

ong tin GÌ A 13 |hình chức |Trường "Tình/TP" Normal |) 5 8 khai báo trong hệ

khách ứng khi chon Tinh/ TP, 14 |hàng tích ÍTrường "Quận/Huyện" |Normal các giá trị nảy da de

diém khai báo trong hệ

thống 1 Vào màn hình - Hợp lệ:

Trường “Thông tin khách + Chỉ nhập các kí tự số

15 | number khi | Truong "SDT" Normal |hàng” từ 0-9, không nhập ký

Hiện bộ lọc 2 Nhân nút [Hiện bộ | tự đặc biệt, chữ, số tp

16 |năng Thêm | Truong "SDT" Normal ẽ K ở } từ 0-9, không nhập ký

hàng tích

điểm

17 | Trường Cac truong: Normal 1 Vao man hinh - Có định dạng:

date khi - Ngay tao tr “Thông tin khách dd/mm/yyyy

[Lé Thi Trang — 209363 — 631T3]

- Ngay tao dén hang” - Khi chon vao biéu

hiện bộ lọc |- GD từ ngày 2 Nhắn nút [Hiện bộ | tượng lịch thì hiện bộ

18 |năng Thêm |- Ngày sinh Normal ẽ to - Khi chon vao biéu

res sk 2 Nhan nut [Thém : un ae

mới/Sửa - Ngày cập sa) / Si tượng lịch thì hiện bộ

diém

Hợp lê 1 Vào màn hình - Enable nút lưu khi

ợp lệ: “Thông ne tin khách „ điện đủ các trường bat ¬ ⁄

- Các trường nhập phải hàng" een buộc " u 6

19 Chức năng oe Ại nu sme bit 7c nã ung định d High ‘8/2 Nhdn nut [Thém |- Lưu chính xác các : ,

Thêm ven aun cag trong 08 méi] / [Sia] thông tin đã nhập ra

mới/Sửa | buộc ori id

ghi thì enable 2 button

Chức năng 1 Vào màn hình Phê duyệt l và a choi

Danh sach “Thông tin khách ông tin khác| Sau khi bâm Phê ke 2I khách | Phê duyệt Từ chối khách Hinh lhẻ ne duyét/Tu choi ban ghi

i ang”

hàng chưa |hàng chưa đc phê duyệt 8 S K ở đó thì cột Trạng thái

được phê ˆ chưa phê duyệt| A ˆ của bản ghỉ đó ngoài ˆ ˆ ,

trạng thái Đã phê

duyệt/Từ chối

9 th, ai Xem những thông tin đã Hinh “Thông tin KH” thông tin đã thay đôi và thôn ‘i ‘etl , ng tin được thay đổi 1 2 Nhân nút [LS thay |thông tin gốc của KH đổi] 2 sau khi thực hiện sửa

1 Vào màn hình -Néu KH đã có giao

“Thông tin khách dịch thì thông báo KH 23 Chức năng | Xóa l bản ghi thông tin Hish hàng” đã có giao dịch, Ko

xóa {KH 18) |2 Chọnlbảnghi |xóa được

trên grid - Nếu KH chưa có giao

3 Nhân nút [Xóa] dịch gì thì được xóa

24 | Chức năng | Xuất ra danh sách KH tích | High |1 Vào mản hình Xuất chính xác các

xuất sang | điểm “Thông tin KH” thông tỉn khách hàng excel 2 Nhắn nút [Xuất |tích điểm

(Lê Thị Trang — 209363 — 631T3]

sang excel]

- Trạng thái từ chối

> cột Remark cho 1 Vào màn hình phép nhập “Thông tin khách - Trạng thái Chưa phê

đỗi trạng Đôi trạng thái KH tích 2 Chon I ban ght —> cột Remark khong 25 thai trên điểm , High KH trén grid cho nhap va hién thi:

grid va lưu phê duyệt Từ chối/ |- KH có Trạng thái

Chưa phê duyệt chưa phê duyệt thì

4 Nhân nút [Lưu] |trong mản DSKH chưa

phê duyệt sẽ hiển thi

khách hàng đó 1 Vào màn hình

“Thông tin KH”

Chức năng kos pn nak pas cà Tà ` LÁ Ay ike ah: 26|_ Lưu cột Lưu hiên thị các cột được High bén le phai man hình và bam lưu cột hiện thị hiển thị chọn 3 Tích chọn các cột |sẽ hiện thị những cột

|| 1 Vào màn hình

28 trén gid High |2 Nhập dữ liệu cân đúng khi nhập

tìm vào ô filter trên °

grid Phan trang Dam bao:

- Số lượng bản ghi trên / page = số lượng row 1 Vào màn hình config trong | page Check chức năng phân “Thong tin khach - 86 tổng số bản ghi:

trang: next / back 2 Nhân nút mũi tên A eg |trong tiên độ kan

next/ back - Số trang: tổng số

lượng bán ghi/ số lượng row config trong

page

Eq Check chức năng thay đổi |High 1 Vào màn hình Đảm bảo:

số lượng bản ghỉ mặc định “Thông tin khách - Số lượng bản ghỉ trên

(Lê Thị Trang — 209363 — 631T3]

/ page = số lượng row config trong | page - Số tổng số bản ghi: hàng” tổng số bản phi xe trên Í trang 2 Chọn số lượng trong tiến độ

muốn hiển thị - Số trang: tổng số

Lịch sử giao dịch KH

Giao dịch Lịch sử giao dịch { Q.DSKH enh báo } [ 2 Lum cjt hiéa thị \ CfKhôi phục bộ lọc ) ( Q Ẩnbộ lọc ) ( E3 Xuất sang exce! } ( + Than mái )

Tên Khách hàng Mã tích điểm KH Số Diện thoại Biển số xe GD Từ ngày zB GD Dén ngay # Loại hình áp dụng Tất cả v Lich sử giao dịch Khách Hàng

Đại Lý "Tên KH ĐT Liên Hệ Mã tích điểm Mau xe Ma xe Maxe SX Mau xe TBD Trần Trang5 so cute 0912455775 TBDLOVALTY000000062 Corolla Cro Den m TBD Trần Trang5 so cute 0912455775 TBDLOVALTY000000062 Corolla Cro cxG c6 Trang ngoc Fs TBD Test 2 0225545454 TBDLOVALTY000022726 Voloz VLE B $ TBD Trần Trang5 so cute 0912455775 TBDLOYALTY000000062 Vios VE Nâu vàng TBD Lê Hữu Tiến 0913444555 TBDLOYALTY000022735 Corolla Cro cxG

TBD Lê Hữu Tiến 0913444555 TBDLOYALTY000022735 Corolla Cro TBD Lê Hữu Tiến 0913444555 TBDLOYALTY000022735 Corolla Cro cxe TBD Lê Hữu Tiến 0913444555 TBDLOYALTY000022735 Corolla Cro cxG c6 ĐỎ

TBD Lê HữU Tiến 0913444555 TBDLOYALTY000022735 CoollaCro CXG C6 Đỏ

TBD Lê Hữu Tiến 0913444555 TBDLOYALTY000022735 Corolla Cro CXG œ6 Đỏ TBD Nguyên Duy Văn ph 0988919798 TBOLOYALTY000022676 Corolla Cro Đen TBD Nguyên Thúy Hang 0900111000 TBDLOYALTY000022650 Lexus: ES250 F S

TBD Tân Test1 0350180180 TBDLOVALTY000000052 Lexus: ES250 F S TBD Trần Trang5 so cute 0912455775 TBDLOVALTY000000062 Lexus: ES250 F S TBD Test số 6 08877777 'TBDLOYALTY000022733 Laxus ES250 F S TBD Test2 0225545454 TBDLOVALTY000022726 Lexus ES250 FS TBD Test10 00206454 'TBDLOYALTY000022728 Lexus ES250 FS TBD Lê Test13 99778787 TBDLOYALTY000022740 Lexus: ES250

TBD Test Phê Duyệt Tự 05458445 TBDLOYALTY000022721 Lexus ES250 F $

TBD Test Phé Duyệt Tự 05458443 TBDLOYALTY000022721 Lexus ES250 F S ES22F Xanh TBD Test 2 0225545454 TBDLOYALTY000022726 Lexus ES250 F § ES22F Xanh

TBD Test Số 6 05877777 TBDLOYALTY000022733 Rush RG cc pen

TBD Lê Test5 09876543 TBDLOYALTY000022732 Veloz VLG VH Đen TBD nguyen vi ninh 0904973588 TBDLOYALTY000000057 Lexus: ES250 F S ES22F Xanh TBD Trần Trang5 so cute 0912455775 TBDLOVALTY000000062 Lexus: ES250F S ES22F Be

TED nguyen vi ninh 0904973588 TBDLOYALTY000000057 Laxus ES250 F S ES22F Xanh 1 đến 20 trong tổng số 156 4 4 Trang1/8 y M Hiểnth[20 v]

Hinh 9:Giao điện phân hệ Lịch sử giao dịch KH

s* Phân tích các trường hợp kiểm thử

- Thuộc tính Input/ output

Ti thai cac butt

Cac button 6 man hinh 1 Vào màn “Lịch sử rang hạt các uuen

3 „ High oo, os được thê hiện theo quy

Cá

t ae Các trường: 1 Vào màn “Lịch sử Được nhập tắt cả các ký

; sở th ex - Mã tích điểm KH ion (S9 địch KH” i s số he (hoa, tn 2 : số, chữ (hoa, thường), fet hiện bộ Í Tên Khách hàng kg È"Í2 Bám nút [Hiện bộ | ” Ÿ°:' dac biét 6

vo" |- Biên số xe lọc] lọc

Trường

text tr —¬ - Ũ ` 1 Vào màn “Lịch sử kp ae

màn chức |Các trường: iao dịch KH” Được nhập tât cả các ký

Gồm các giá trị:

Trường 1 Vào màn “Lịch sử K2 - New Car

7 cornbobox | Trường "Loại hình áp Hinh giao dịch KH” - Tât cả - Bảo hiểm

khihiện |dụng" !Ế”Í2 Bấm nút [Hiện bộ [' on - Phu Kién bộ lọc lọc] - BP - Goi PPM

- EW

Cac 1 Vào man “Lich str |Gém cdc gia trị:

truong ¬ ea giao dich KH” -PM - Bảo hiểm

8 |combobox Trường "Loại hình áp High |2 Bam nút [Thêm |_ GI - Phu Kiên

trong màn dụng mới| - BP - Gói PPM

| — năng x A x z x

9 Truong "Mau xe” High Gom cac mau xe da de

[Lé Thi Trang — 209363 — 631T3]