Lập kế hoạch và thực hiện hoạt động kiểm thử cho website của thư viện trường đại học ngân hàng

Trang 1 TRƯỜNG ĐẠI HỌC NGÂN HÀNG TP HỒ CHÍ MINH KHOA HỆ THỐNG THƠNG TIN QU N LÝ Ả--- ĐỒ ÁN CHUYÊN NGÀNH HỆ THỐNG THÔNG TIN QU N LÝ ẢĐề tài: LẬP K HO CH VÀ TH C HI N HOẾẠỰỆẠT ĐỘNG KIỂM TH

TRƯỜNG ĐẠI HỌC NGÂN HÀNG TP HỒ CHÍ MINH

Giảng viên hướng dẫn : Hồ Thị Linh

TRƯỜNG ĐẠI HỌC NGÂN HÀNG TP HỒ CHÍ MINH

i

LỜI CẢM ƠN

nói riêng và trường Đại h c Ngân hàng Thành ph H ọ ố ồ Chí Minh nói chung đã truyền đạt vốn ki n th c quý báu cho em trong suế ứ ốt thời gian học tậ ại trường Nhờ có những lời p thướng dẫn, dạy b o c a các thả ủ ầy cô nên đề tài nghiên cứu của em mới có thể hoàn thiện tốt đẹp

Một l n n a, em xin chân thành cầ ữ ảm ơn cô ồ Thị Linh – người đã trự H c tiếp giúp đỡ, quan tâm, hướng dẫn em hoàn thành tốt bài báo cáo này trong thời gian qua

Trong quá trình th c hiự ện đồ án, vì th i gian và v n ki n th c còn h n ch , m c dù em ờ ố ế ứ ạ ế ặ

những thiếu sót và nhi u chề ỗ còn chưa chính xác Em rất mong nhận được sự chỉ b o, ảđóng góp ý kiến từ quý thầy cô giáo để em có thể bổ sung, hoàn thiện hơn bài đồ án lần này

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

ii

LỜI CAM ĐOAN

Những nội dung trong đồ án t t nghi p này là thành qu t s nghiên cố ệ ả ừ ự ứu và được thực hiện dưới sự hướng dẫn trực tiếp của giảng viên hướng dẫn Hồ Thị Linh

bất c ứ đồ án tương tự nào M i s tham kh o s dọ ự ả ử ụng trong đồ án đều được trích d n các ẫnguồn tài li u trong danh m c tài li u tham kh o ệ ụ ệ ả

Mọi sao chép không hợp l , vi ph m quy ch cệ ạ ế ủa nhà trường, em xin hoàn toàn chịu trách nhiệm

iii

iv

NHẬ N XÉT C A GI NG VIÊN PH N BI N Ủ Ả Ả Ệ

học 100% (3)

35

Ch16 Monetary system - good placeQuản trị

46

Ch11 Measuring the cost of living

Quản trị

29

v

MỤC LỤC

L ỜI MỞ ĐẦ .1 U

1 Lý do chọn đề tài 1

2 Tính cấp thiết: 1

3 Mục tiêu nghiên cứu 2

4 Đối tượng và phạm vi nghiên c u cứ ủa đề tài 2

5 Phương pháp nghiên cứu 2

6 Bố cục nội dung 2

Chương 1 CƠ SỞ LÝ LUẬN 3

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

1.1.2 Mục tiêu c a ki m th ủ ể ử phầ n m ềm: 3

1.2 Quy trình kiểm thử phần mềm: gồm có 5 bước 3

1.2.1 L ập k t hoế ạch 3

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

1.2.3 Phát tri n test scriptể .4

1.2.4 Thực hi n kiệ ểm thử 4

1.2.5 Đánh giá quá trình kiểm thử 5

1.3 Các c ấp độ kiểm thử phần mề .5 m 1.3.1 Unit Test (Ki m th ể ử đơn vị) 5

1.3.2 Integration Test (Ki m th tích hể ử ợp) 6

1.3.3 System Test (Ki m th h ể ử ệ thống) 7

1.3.4 Acceptance Test (Ki m th ể ử chấ p nh ận) 9

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

Trading HUB 3 Xác suất

36

vi

1.4.1 Kiểm th hử ộp đen (Black box testing) 10

1.4.2 Kiểm th h p tr ng (White box testing)ử ộ ắ .11

1.4.3 Kiểm th h p xámử ộ .12

1.5 T ổng quan về kiểm thử website 13

1.5.1 Kiểm th website là gì?ử .13

1.5.2 Hoạt động ki m th websiteể ử .13

1.6 Những nét chung v thiề ết k ca ki m th (test case):ế ể ử .16

1.6.1 Test case là gì? 16

1.6.2 Các kỹ thuật thi t k Test case:ế ế .16

1.6.3 C ấu trúc chính c a m t Test case:ủ ộ .21

1.6.4 Một số lưu ý khi viết Test case: 22

Chương 2. MÔ TẢ HỆ THỐNG VÀ PHƯƠNG PHÁP TIẾP CẬN HỆ THỐNG 23

2.1 Mô t nghi p vả ệ ụ của thư viện 23

2.2 Mô t h ả ệ thống 24

2.3 Cách ti p cế ận h ệ thống 25

Chương 3 LẬP KẾ HOẠ CH KI M TH Ể Ử WEBSITE THƯ VIỆN ĐẠI HỌC NGÂN HÀNG 27

3.1 Giới thiệ .27 u 3.1.1 T ổng quan 27

3.1.3 Mục đích 28

3.2 L ập k ế hoạ ch ki ểm thử cho các nghi p vệ ụ 29

3.2.1 Mục tiêu ki m thể ử 29

3.2.2 Xác định phạm vi ki m thể ử 29

3.2.3 Cách ti p cế ậ .30 n 3.2.4 Tiêu chí ki m th thành công / th t bể ử ấ ại 30

vii

3.2.5 Tiêu chí đình chỉ và kết thúc kiểm thử 30

3.3 Quản lý ki m thể ử 31

3.3.1 Các công việc đượ ậc l p k ế hoạch 31

3.3.2 Môi trường kiểm thử 31

3.3.3 Các công cụ kiểm thử 32

3.3.4 Nhân sự 32

3.3.5 L ịch trình công việc 33

3.3.6 Các rủi ro 33

Chương 4 THIẾT K TEST CASE CHO CÁC CHẾ ỨC NĂNG CỦA WEBSITE 34

4.1 Đăng nhậ .34 p 4.1.1 Mô tả nghi p vệ ụ 34

4.1.2 Kiểm th nghi p vử ệ ụ 35

4.1.3 Kiểm th User Interfaceử .37

4.1.4 Kiểm th Security/Sessionử .37

4.2 Đổi mật khẩ .37 u 4.2.1 Mô tả nghi p vệ ụ 37

4.2.2 Kiểm th nghi p vử ệ ụ 38

4.3 Gia hạn thời gian tài liệu 42

4.3.1 Mô tả nghiệp vụ 42

4.3.2 Kiểm th nghi p vử ệ ụ 42

4.4 Cho mượn sách 46

4.4.1 Mô tả nghi p vệ ụ 46

4.4.2 Kiểm th nghi p vử ệ ụ 47

4.5 Ma tr n truy xuậ ất 51

viii

4.6 Đánh giá kết quả kiểm thử 52

KẾT LUẬN 52

1 Kết quả đạt được: 52

2 Hạn ch cế ủa đề tài 52

3 Hướng phát tri n cể ủa đề tài 52

Tài li u tham khệ ảo 53

ix

DANH M C BỤ ẢNG BI U Ể

Hình 1 K thu t ki m th hỹ ậ ể ử ộp đen 16

Hình 2 K thu t ki m th h p trỹ ậ ể ử ộ ắng 19

Hình 3 Giao diện đăng nhập 34

Hình 4 nh minh ho Ả ạ khi đăng nhập thành công 36

Hình 5 nh minh ho Ả ạ khi đăng nhập không thành công 36

Hình 6 Giao diện màn hình đổi m t khậ ẩu 38

Hình 7 Sơ đồ trạ ng thái c a m t khủ ậ ẩu 39

Hình 8 nh minh ho i m t kh u thành côngẢ ạ đổ ậ ẩ 41

Hình 9 nh minh ho i m t kh u không thành côngẢ ạ đổ ậ ẩ 41

Hình 10 Giao di n màn hình gia h n tài liệ ạ ệu 42

Hình 11 nh minh ho gia h n tài liẢ ạ ạ ệu 45

Hình 12 nh minh ho gia h n tài li u thành côngẢ ạ ạ ệ 46

Hình 13 Ma tr n truy xu t ngu n gậ ấ ồ ốc 51

x

DANH MỤC HÌNH ẢNH, SƠ ĐỒ

Bảng 1 B ng các công vi c và các ràng buả ệ ộc 31

Bảng 2 B ng công c ả ụ kiểm thử 32

Bảng 3 B ng th ả ể hiện vai trò và trách nhiệm 33

Bảng 4 B ng l ch trình công viả ị ệc 33

Bảng 5 B ng các r i roả ủ 33

Bảng 6 Bảng điều ki n chệ ức năng đăng nhập 35

Bảng 7 Bảng test case đăng nhập 36

Bảng 8 B ảng sơ đồ trạng thái c a m t khủ ậ ẩu 39

Bảng 9 B ng quyả ết định c a chủ ức năng gia hạn tài li ệu 43

Bảng 10 B ng test case c a gia h n tài liả ủ ạ ệu 45

Bảng 11 B ng quyả ết định của cho mượn sách 48

Bảng 12 B ng test case cả ủa cho mượn sách 50

Bảng 13 Bảng đánh giá kết qu ả kiểm thử 52

lý thư viện sẽ giúp việc quản lý trở nên đơn giản và đặc biệt là tính chính xác cao, truy vấn thông tin được nhanh chóng theo nhiều yêu cầu khác nhau

Đây là một giải pháp hữu hiệu giúp tiết kiệm thời gian, công sức, đồng thời nâng cao hiệu qu khoa h c cho vi c quả ọ ệ ản lý thư viện Ngườ ử ụi s d ng có th d dàng tìm kiể ễ ếm sách, tài li u c n tìm Ch v i m t vài t khóa thệ ầ ỉ ớ ộ ừ ủ thư có thể ết được đầ bi u sách, tài li u ệnằm ở vị trí nào trong kho sách, hiện đầu sách vẫn còn hay đã cho mượn h t và các d ế ữliệu về người mượn sách, từ đó phục v tụ ốt hơn quá trình họ ậc t p, gi ng d y trong nhà ả ạtrường

Do đó hệ thống thư viện trực tuyến của trường cần phải được phát triển và quản lý tốt mới có khả năng phục vụ sinh viên mọi lúc, mọi nơi, và cũng tối ưu hoá vai trò của một thư viện điện tử

Nhận thấy đượ ầc t m quan trọng đó, em chọn đề tài “ Lập k ho ch và th c hi n hoế ạ ự ệ ạt

của mình

2 Tính cấp thi ết:

Thực hi n các hoệ ạt động ki m thể ử website thư viện s giúp phát hiẽ ện ra các trường hợp gặp l i khi ỗ người dùng truy c p vào web, t ậ ừ đó sẽ phát tri n website hoàn thiể ện hơn, hoạt động hiệu quả hơn

4 Đối tượng và ph m vi nghiên c u cạ ứ ủa đề tài

Phạm vi nội dung: Đồ án nghiên c u lý thuy t ki m th ph n m m và áp d ng thi t k ứ ế ể ử ầ ề ụ ế ếtest case cho chức năng đăng nhập, đổi mật khẩu, gia hạn tài liệu, cho mượn tài li u cệ ủa website thư viện Trường Đại học Ngân hàng

5 Phương pháp nghiên cứu

Nghiên c u t ng quan v ki m th ph n m m và các kứ ổ ề ể ử ầ ề ỹ thuật ki m th , ể ử ở đây đồ án sẽ thiết k các test case cho ki m thế ể ử website bằng ki m thể ử ủ công cho các chức năng th

6 B ố cục nội dung

Với mục tiêu đề ra như vậy, nh ng n i dung và k t qu nghiên c u chính cữ ộ ế ả ứ ủa đồ án được trình bày trong bốn chương như sau:

- Chương 1: Cơ sở lý lu n ậ

- Chương 2: Mô tả ệ thố h ng và phương pháp tiếp c n hậ ệ thống

- Chương 3: Lập kế hoạch kiểm thử website thư viện đại học ngân hàng

- Chương 4: Thiết kế test case cho các chức năng của website

Quá trình bao gồm tất cả các hoạt động vòng đời, cả hoạt động tĩnh và năng động, quan

phẩm công việc liên quan đ xác địể nh rằng chúng đáp ứng các yêu c u cầ ụ thể, để chứng minh r ng chúng phù h p v i mằ ợ ớ ục đích và để phát hi n ra l ệ ỗi

1.1.2 Mục tiêu của ki ểm thử phầ n m ềm:

Kiểm th phử ần mềm thực hiện một chương trình với mục đích tìm lỗi Để:

Xác định xem hệ thống có đáp ứng các thông số k thuật hay không ỹ

Xác định xem hệ thống có đáp ứng được nhu cầu c a người dùng hay không ủ

Có được sự tự tin và cung cấp thông tin về mức độ ch t lượng ấ

Ngăn ngừa lỗi

1.2 Quy trình ki m th ể ử phầ n mềm: gồm có 5 bước

1.2.1 L ập kết ho ạch

Nhằm 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 chi 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 viên ể ử

Các bước lập kế hoạch kiểm thử:

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

Xác định các chiến lược ki m thể ử: Xác định phương thức, loại kiểm thử cần thực hiện và tiêu chí đầu ra

4

hiện ki m thể ử (số lượng người, yêu c u v ph n c ng, ph n m m, công c h ầ ề ầ ứ ầ ề ụ ỗtrợ…)

Lập thời gian cho các giai đoạn ki m ể thử:

Đánh giá kế hoạch: Trưởng dự án sẽ cùng những người liên quan tham gia đá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ử

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

Nhằm chỉ định các test case và các bước ki m tra chi ti t cho m i ph n mể ế ỗ ầ ềm Giai đoạn thiết kế test case là hết sức quan tr ng, nó ọ đảm bảo các tình hu ng kiố ểm thử bao ph tủ ất

cả các yêu cầu

1.2.3 Phát triển test script

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 các test script có khả năng chạy trên máy tính giúp tự động hóa vi c thệ ực thi các bước kiểm tra đã định nghĩa ở các bước thi t k ế ếkiểm th ử

1.2.4 Thực hi n ki m th ệ ể ử

Mục đích thực hiện kiểm tra các bước đã thiế ết k và ghi nh n k t qu ậ ế ả

Các bước thực hiện kiểm thử:

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, máy ch , mậ ầ ứ ầ ề ủ ạng, dữ liệu…) đã được cài đặt và sẵn 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

5

những l i không ph i do ph n m m mà do dỗ ả ầ ề ữ 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

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

Bao gồm 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

Phân 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ự ế, tổng hợp và g i thông tin yêu c u c t ử ầ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.ợ

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

Kiểm th ph n m m g m có 4 cử ầ ề ồ ấp độ: Unit test (Ki m thể ử đơn vị), Integration Tests (Kiểm th tích h p), System Tests (Kiử ợ ểm thử ệ thống) và Acceptance Tests (Ki m th h ể ửchấp nh n) Tùy theo yêu cậ ầu và đặc trưng của từng h ệ thống, kh ả năng và thời gian cho phép c a d án, khi l p k hoủ ự ậ ế ạch, người qu n lý d án s quyả ự ẽ ết định nh ng lo i kiữ ạ ểm thử được sử d ng ụ

1.3.1 Unit Test (Kiểm th ử đơn vị )

Unit (Đơn vị) là một thành phần phần mềm nhỏ nhất có thể kiểm thử được Các hàm (Function), th t c (Procedure), lủ ụ ớp (Class) hay phương thức (Method) đều có thể được xem là Unit Unit được chọn để ểm tra thườ ki ng có kích thước nhỏ và chức năng hoạt động đơn giản, vì vậy thường không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận

và phân tích k t qu ki m th N u phát hi n l i, viế ả ể ử ế ệ ỗ ệc xác định nguyên nhân và khắc

6

nguyên lý đúc kết từ thực tiễn: th i gian t n cho Unit Test s ờ ố ẽ được đền bù b ng vi c tiằ ệ ết kiệm rất nhiều th i gian và chi phí cho viờ ệc kiểm th và sử ửa lỗi ở các mức kiểm thử sau

đó

Unit Test thường do lập trình viên thực hiệ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 Thông ế ố ỳ ể ầ ề

trình Mục đích của ki m th ể ử đơn vị là bảo đảm thông tin được xử lý và xu t (kh i Unit) ấ ỏ

là chính xác, trong mối tương quan vớ ữ liệi d u nh p và chậ ức năng của đơn vị Điều này thường đòi hỏi t t c ấ ả các nhánh bên trong unit đều phải được kiểm tra để phát hi n nhánh ệphát sinh l i Mỗ ột nhánh thường là m t chu i các lộ ỗ ệnh được th c thi trong m t unit Thự ộ ực

tế vi c ch n lệ ọ ựa 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ọ ựa.n l

Cùng v i các m c ki m th ớ ụ ể ử khác, unit test cũng đòi hỏi phải chuẩn bị trước test case (ca kiểm th ) ho c test script (kử ặ ịch b n kiả ểm thử), trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các test case và test script này nên được giữ lại để tái sử ụ d ng

(Nguồn: https://timoday.edu.vn/tong-quan-ve kiem- -thu-phan-mem-2/, 2020)

1.3.2 Integration Test (Ki m th tích hể ử ợp)

Integration test là k t h p các thành ph n c a mế ợ ầ ủ ột ứng d ng và ki m thụ ể ử như một ứng dụng đã hoàn thiện Trong khi unit test kiểm tra các thành phần và đơn vị riêng lẻ thì integration test k t h p chúng lế ợ ại với nhau và ki m tra s giao ti p giể ự ế ữa chúng

7

Hai m c tiêu chính c a integration test: ụ ủ

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 cùng là nguyên h ỏ ối ệ thống hoàn ch nh chu n b cho ki m th mỉ ẩ ị ể ử ở ức hệ thống

Trong unit test, l p trình viên c g ng phát hi n lậ ố ắ ệ ỗi liên quan đến chức năng và cấu trúc nội t i c a unit Có m t s phép ki m th ạ ủ ộ ố ể ử đơn giản trên giao ti p gi a unit v i các thành ế ữ ớphần liên quan khác, tuy nhiên m i giao tiọ ếp liên quan đến Unit chỉ thậ ự được kiểm t stra đầy đủ khi các unit tích hợp với nhau trong khi thực hiện kiểm thử tích hợp Trừ m t s ít ngo i l , integration test ch nên th c hi n trên nhộ ố ạ ệ ỉ ự ệ ững unit đã được kiểm tra c n thẩ ận trước đó bằng unit test, và t t c các l i mấ ả ỗ ức unit đã được s a chử ữa.(Nguồn: https://timoday.edu.vn/tong-quan-ve kiem- -thu-phan-mem-2/, 2020)

1.3.3 System Test (Ki ểm thử ệ thố h ng)

System test 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 System test bắt đầu khi tất cả các bộ phận của phần

mềm đã được tích hợp thành công Thông thường loại ểm th này t n r t nhi u công ki ử ố ấ ềsức và thời gian Trong nhiều trường hợp, vi c ki m thệ ể ử đòi hỏi m t sộ ố thiế ị phụ trợ, t bphần m m hoề ặc phần cứng đặc thù, đặc biệt là các ứng dụng, hệ thống phân b , hoố ặc hệ

thống nhúng mỞ ức độ ệ ống, ngườ h th i kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, s tin c y và các yêu cự ậ ầu khác liên quan đến chất lượng của toàn hệ thống

Điểm khác nhau then ch t giố ữa integration test và system test là system test chú trọng các hành vi và l i trên toàn h ỗ ệ thống, còn integration test chú tr ng s giao ti p gi a các ọ ự ế ữunit hoặc đối tượng khi chúng làm việc cùng nhau Thông thường, unit test và integration test cần phải thực hiện trước để bảo đảm mọi unit và sự tương tác giữa chúng hoạt động chính xáctrước khi thực hiện system test

System test th c hi n ki m th c các hành vi chự ệ ể ử ả ức năng của ph n m m l n các yêu c u ầ ề ẫ ầ

về chất lượng như độ tin c y, tính ti n l i khi s d ng, hi u ậ ệ ợ ử ụ ệ năng và bảo mật Mức kiểm thử này đặc bi t thích h p cho vi c phát hi n l i giao ti p v i ph n m m ho c ph n c ng ệ ợ ệ ệ ỗ ế ớ ầ ề ặ ầ ứbên ngoài, ch ng h n các lẳ ạ ỗi “tắc nghẽn” hoặc chi m d ng b nhế ụ ộ ớ Sau giai đoạn system test, ph n mầ ềm thường đã sẵn sàng cho khách hàng ho c nặ gười dùng cu i cùng ki m th ố ể ửchấp nh n s n phậ ả ẩm hoặc dùng thử ả s n phẩm

System test đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan System test

triển dự án Trong system test l i bao g m nhi u lo i ki m th khác nhau, m t sạ ồ ề ạ ể ử ộ ố ại lophổ bi n nhế ất gồm:

Functional Testing (Ki m th ể ử chức năng): Bảo đảm các hành vi c a h ủ ệ thống 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 ph n 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…)

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ị ải): Đảu t 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 ấ ậ

9

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 th c u hình): Kiể ử ấ ểm thử ự tương thích giữa phần mềm s

1.3.4 Acceptance Test (Kiểm th ử chấp nhận)

Thông thường, sau giai đoạn system test là acceptance test, được khách hàng thực hiện (hoặc ủy quy n cho m t nhóm th ba th c hi n) Mề ộ ứ ự ệ ục đích củ acceptance test là đểa chứng minh ph n m m th a mãn t t c yêu c u c a khách hàng và khách hàng ch p nhầ ề ỏ ấ ả ầ ủ ấ ận sản phẩm

Thực t cho th y, n u khách hàng không quan tâm và không tham gia vào quá trình phát ế ấ ếtriển ph n m m thì k t qu ki m th ầ ề ế ả ể ử chấp nh n s n phậ ả ẩm sẽ sai l ch r t l n, m c dù ph n ệ ấ ớ ặ ầmềm đã trải qua t t c các ki m th ấ ả ể ử trước đó Sự sai lệch này liên quan đến vi c hi u sai ệ ể

Gắn li n về ới giai đoạn acceptance test thường là m t nhóm nh ng dộ ữ ịch v và tài liụ ệu đi kèm, ph biổ ến như hướng dẫn cài đặt, s dử ụng… Tấ ảt c tài liệu đi kèm phải được c p ậnhật và ki m thể ử chặt ch ẽ

(Nguồn: https://timoday.edu.vn/tong-quan-ve kiem- -thu-phan-mem-2/, 2020)

10

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

1.4.1 Kiểm th h p ử ộ đen (Black box testing)

Kiểm th hử ộp đen hay còn gọi là ki m th ể ử hướng d ữ liệu Trong k ỹ thuật này người kiểm thử xem ph n mầ ềm như là mộ ộp đen Ngườt h i ki m th ể ử hoàn toàn không quan tâm đến cấu trúc, hành vi bên trong ph n mầ ềm Người kiểm th ử chỉ quan tâm đến vi c tìm ra các ệlỗi mà ph n m m không x ầ ề ử lý theo đúng đặc t c a nó Vì th d ả ủ ế ữ liệu ki m th xu t phát ể ử ấ

từ đặc tả

Kiểm th hử ộp đen cố ắ g ng tìm ra các l i trong các lo i sau: ỗ ạ

Các chức năng thiếu hoặc không đúng so với bản đặc tả

Các l i thi hành ỗ

Lỗi giao diện

Các lỗi cấu trúc d u trong vi c truy cữ liệ ệ ập cơ sở ữ liệ d u bên ngoài

Các lỗi kh i tở ạo hoặc kết thúc

Các lỗi khác

Một số loại kiểm th hử ộp đen hay dùng

Kiểm th phân tích giá tr biên ử ị

Kiểm th dử ựa vào đồ thị nguyên nhân – ế k t qu ả

Sử dụng b ng quyả ết định

chênh l ch v thông s k ệ ề ố ỹ thuật Theo phương pháp này, tester 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 Các tester có thấ ể được th c hi n b i mự ệ ở ột cơ quan độ ậc l p

từ các developer, cho phép một cái nhìn khách quan và tránh s phát tri n thiên vự ể ị

Nhược điểm: D ữ liệu đầu vào yêu c u m t khầ ộ ối lượng m u khá l n Nhi u d án không ẫ ớ ề ự

có thông s rõ ràng thì vi c thi t kố ệ ế ế các trường h p ki m th rợ ể ử ất khó và do đó khó viết

11

kịch b n ki m th cả ể ử ần xác định t t c các y u tấ ả ế ố đầu vào, và c y u tả ế ố thời gian 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 để ại chưa được lkiểm tra

(Nguồn: https://timoday.edu.vn/tong-quan-ve kiem- -thu-phan-mem-2/, 2020)

1.4.2 Kiểm th h p tr ng (White box testing) ử ộ ắ

Kiểm thử hộp trắng còn g i là ki m th c u trúc D a vào thu t giọ ể ử ấ ự ậ ải cụ thể, vào c u trúc ấ

dữ liệu bên trong của đơn vị ph n m m c n ki m thầ ề ầ ể ử để xác định đơn vị phần mềm đó

có th c hiự ện đúng không Do đó người ki m th h p tr ng ph i có kể ử ộ ắ ả ỹ năng, kiến thức nhất định v ngôn ng lề ữ ập trình được dùng, v ề thuật giải được dùng trong ph n mầ ềm để

có thể thông hi u chi tiể ết về đoạn code c n ki m th ầ ể ử

Kiểm th h p trử ộ ắng thường t n r t nhi u th i gian và công s c n u ph n m m quá lố ấ ề ờ ứ ế ầ ề ớn (thí d trong ki m th tích h p hay ki m thụ ể ử ợ ể ử chức năng) Do đó kỹ thuật này ch yủ ếu được dùng để kiểm thử đơn vị, ki m thử từng tác vụ ủể c a m t l p chức năng ộ ớ

Tiêu chu ẩn củ a ki m nghi m h p trể ệ ộ ắng phải đáp ứ ng các yêu cầu như sau: Bao ph dòng l nh: mủ ệ ỗi dòng lệnh ít nh t phấ ải được th c thi 1 lự ần

Bao ph nhánh: mủ ỗi nhánh trong sơ đồ điều khi n phể ải được đi qua một lần Bao phủ đường: t t cấ ả các đường từ điểm kh i tở ạo đến điểm cuối cùng trong sơ

đồ dòng điều khiển phải đư c đi qua ợ

Các kỹ thu t kiậ ểm thử ộ h p tr ng: ắ

Kiểm th ử đường dẫn cơ sở

Kiểm th cử ấu trúc điều khi n bao gể ồm các kĩ thuật: ki m thể ử điều ki n và kiệ ểm thử vòng l p ặ

12

Ưu điểm: Buộc các chuyên gia ki m th ph i suy lu n c n thể ử ả ậ ẩ ận về việc ki m th l i vì ể ử ỗvậy l i sỗ ẽ được triệt để, cho phép tìm ki m các lế ỗi ẩn bên trong Do yêu c u ki n thầ ế ức cấu trúc bên trong c a ph n m m, nên vi c ki m soát l i tủ ầ ề ệ ể ỗ ối đa nhất

Nhược điểm: Khá m t th i gian và công sấ ờ ức nhưng vẫn s t n t i lẽ ồ ạ ỗi Đòi hỏi người kiểm th có kinh nghi m và am hi u v ki m thử ệ ể ề ể ử cũng như về ấ c u trúc bên trong của phần mềm được thử nghiệm

(Nguồn: https://timoday.edu.vn/tong-quan-ve kiem- -thu-phan-mem-2/, 2020)

1.4.3 Kiểm th h p xám ử ộ

Kiểm th h p xám là mử ộ ột phương pháp kiểm th ph n mử ầ ềm được k t h p giế ợ ữa phương pháp ki m th Black Box và White Box Trong ki m th hể ử ể ử ộp đen tester kiểm thử các hạng m c mà không c n bi t c u trúc bên trong cụ ầ ế ấ ủa chương trình, còn kiểm th h p tr ng ử ộ ắthì tester biết được c u trúc bên trong c a cấ ủ hương trình Trong kiểm th h p xám, c u ử ộ ấtrúc bên trong s n ph m chả ẩ ỉ được bi t m t ph n Tester có th truy c p vào c u trúc d ế ộ ầ ể ậ ấ ữliệu bên trong và thu t toán cậ ủa chương trình với mục đích là để thi t k ế ế các trường h p ợkiểm thử, nhưng khi thực hiện ki m th ể ử thì test như người dùng cu i hoố ặc là ở mức hộp đen

Mặc dù phương pháp kiểm thử hộp xám có thể được dùng trong các mức khác nhau của kiểm th , tuy nhiên nó ch yử ủ ếu đượ ử ục s d ng trong ki m th ể ử tích hợp

Kiểm th h p xám nh m tìm ra tử ộ ằ ối đa số l i v c u trúc d ỗ ề ấ ữ liệu c a h p tr ng và l i chủ ộ ắ ỗ ức

hiện ki m th trên giao di n cể ử ệ ủa chương trình (yêu cầu chương trình phải chạy được mới kiểm th ử được, không can thi p vào code) ệ

13

người dùng và nhà phát triển trong quá trình thử nghiệm Thử nghiệm dựa trên yêu cầu của người dùng chứ không phải người thiế ết k

Nhược điểm: H u hầ ết các trường h p ki m thợ ể ử đều khó thi t k Ki m th h p xám ế ế ể ử ộkhông được coi là một phương pháp hiệu quả vì không có nhiều kịch bản để kiểm thử (Nguồn: https://timoday.edu.vn/tong-quan-ve kiem- -thu-phan-mem-2/, 2020)

1.5 T ổng quan v ề kiể m th website ử

1.5.1 Kiểm th website là gì? ử

Kiểm th ử website được xem là hoạt động kiểm tra và phát hiện ra nh ng lữ ỗi tiềm ẩn sau quá trình xây dựng, cũng như phát triển Nh m mằ ục đích khắc phục nh ng s c còn sót, ữ ự ốtrước khi đưa sản phẩm đến tay khách hàng và người dùng

Nhờ có quá trình ki m th , mà các vể ử ấn đề liên quan đến tính năng, dịch v web, b o mụ ả ật, khả năng xử lý lưu lượng truy c p k p thậ ị ời được gi i quyả ết và mang đến m t website ộvận hành ổn định và mượt mà hơn

1.5.2 Hoạ t đ ng ki m th website ộ ể ử

Kiểm th ử chức năng: Đảm bảo website khi bàn giao đến tay khách hàng đáp ứng đúng

những nhu c u mà hầ ọ đã đặt ra Cần chú ý đến các y u t sau:ế ố

Kiểm tra chất lượng các liên k t t n t i trong website:ế ồ ạ Bao g m các liên kồ ết nội b , liên k t ngoài, liên k t mail, liên kộ ế ế ết đến các vị trí trong cùng m t trang ộ

Đảm bảo chúng luôn hoạt động ổn định, nếu không k p thị ời tìm ra hướng khắc phục, tránh làm ảnh hưởng đến hoạt động của toàn bộ trang

Kiểm tra form hi n th trên web:ể ị Hỗ trợ việc thu thập dữ ệu tli ừ người dùng, đồng thời lưu trữ chúng vào cơ sở ữ liệu d

Kiểm tra Cookie và Session: Thực hi n check các ng dệ ứ ụng đăng nhập trong từng phiên và cho phép vô hi u hóa t p tin cookie ệ ậ

Kiểm th ử khả năng bảo mật: Nhằm xác minh h ệ thống thông tin b o v và duy trì chả ệ ức

được thực hiện v i những hoạt động như: ớ

Kiểm tra tài kho n/ mả ật khẩu không h p l ợ ệ

Kiểm tra Captcha đã được thêm vào chưa

Kiểm tra khả năng truy cập của thư mục / tập tin website

Kiểm tra các chức năng liên quan đến bảo mật SSL

Kiểm tra truy c p trái phép vào các trang an toàn, nậ ếu người dùng chuy n t ể ừ

"https" sang "http" sẽ có thông báo thích h p hi n thợ ể ị, và ngược lại

Kiểm th ử khả năng sử ụng: d Đánh giá hoạt động trang web, xác định kh ả năng người dùng h c cách v n hành, chu n bọ ậ ẩ ị đầu vào và gi i thích k t quả ế ả đầu ra c a trang web, ủ

Test n i dung d a trên các vộ ự ấn đề như lỗi chính tả, l i ng pháp, lỗ ữ ỗi ảnh, c u trúc ấ

và chất lượng n i dung ộ

Test logic liên kết, cùng kh ả năng điều hướng

Test văn hóa khu vực, cũng như đối tượng sử dụng

Kiểm th s ử ự thương thích: Xem xét quá trình hoạt động của website với từng c u hình ấphần m m và ph n cề ầ ứng được hỗ trợ, thông qua một số phương pháp:

Kiểm tra khả năng tương thích in ấn

Kiểm tra sự tương thích của trình duyệt

Kiểm tra tương thích theo thiết bị và hệ điều hành

Kiểm tra sự tương thích trên các cấu trúc cơ sở ữ liệ d u khác nhau

15

Kiểm th ử trải nghiệm giao diện: Đảm bảo t t c thông tin gi a các máy ch ấ ả ữ ủ được thực hiện chu n xác, kẩ ịp th i phát hi n nhờ ệ ững xung đột trong quá trình ng d ng hoứ ụ ạt động Dựa trên 03 yếu t c t lõi: ố ố

Kiểm tra Web server: Test quá trình x lý các yêu cử ầu web có được ch p nh n, ấ ậ

đảm bảo không yêu cầu nào b từ chối hoặc bị rò r ị ỉ

Kiểm tra Application server: Xem xét yêu cầu có được gửi đến đúng server, các

lỗi có đư c tìm th y và hi n thợ ấ ể ị đến Admin hay không

Kiểm tra Database server: Xem xét các k t qu truy vế ả ấn cơ sở ữ liệu d

Kiểm th ử hiệ u su ất: Nhằm xác định khả năng đáp ứng, cũng như độ ổn định dưới một tải nhất định, thường được chia thành 02 dạng chính:

Kiểm thử trọng t i: Ki m tra khả ể ả năng làm việc của website, ph n ng c a máy ả ứ ủchủ dưới dạng trình duy t g i yêu cệ ử ầu, xác định các vấn đề ề độ trễ ạ v m ng Kiểm th s c chử ứ ịu đựng: Test tốc độ ả t i trang, hi u su t website khi nhiệ ấ ều người dùng cùng đăng nhập hoặc khi tăng khối lượng dữ liệu trong cơ sở dữ liệu

Kiểm th ử cơ sở ữ liệu: Đảm b o m i d d ả ọ ữ liệu có độ tin c y cao, thông qua các hoậ ạt động như:

Truy v n d u không nên m t quá nhi u th i gian ấ ữ liệ ấ ề ờ

Kiểm tra các truy vấn được th c hiự ện mà không x y ra l ả ỗi

Việc load dữ u và kliệ ết quả nhận được với các câu truy v n dài ấ

Dữ liệu nhận được trên cơ sở ữ liệu và hi n th trên website có chính xác hay d ể ịkhông?

Thêm m i, c p nh t ho c xóa d ớ ậ ậ ặ ữ liệu trong cơ sở dữ liệu nên duy trì tính toàn v n ẹcủa dữ liệu

(https://thietkewebso.com/blog-cong-nghe/bai-viet/kiem-thu-website- -gi-la

1569/, 2022)

1.6.2 Các ỹ thu t thi k ậ ết kế Test case:

a Phân vùng tương đương (Equivalence Partitioning)

Là phương pháp chia miền đầu vào của một chương trình thành các lớp dữ liệu, từ đó suy d n ra các ca ki m thẫ ể ử, thường được tiến hành theo 2 bước sau:

B1: phân các vùng dữ liệu thành các vùng điều kiện tương đương

B2: Xác định các ca kiểm thử

17

Nguyên tắc xác định các lớp tương đương:

Nếu điều kiện đầu vào định rõ giới hạn của một mảng thì chia vùng tương đương thành

3 tình huống: Xác định m t lộ ớp tương đương hợp lệ Xác định hai lớp tương đương không hợp l Ví d : giá tr c a m t kh u ph i t 6-24 ký t , v y ta có 1 l p giá tr ệ ụ ị ủ ậ ẩ ả ừ ự ậ ớ ị tương đương hợp lệ là [6-24], 2 lớp tương đương không hợp lệ là: <6 và 24>

Nếu điều kiện đầu vào là một giá trị xác định thì chia vùng tương đương thành 3 tình huống: M t lộ ớp tương đương hợp lệ Hai lớp tương đương không hợp lệ Ví d : test font ụchữ = 12, v y ta có 1 l p giá tr ậ ớ ị tương đương hợp lệ là 12, 2 lớp tương đương không hợp

lệ là: <12 và 12>

b Phân tích giá trị biên (Boundary Value Analysis)

Test các giá trị biên của các vùng dữ liệ u vào và ra

18

c Bảng quyết định (Decision Table Testing)

Bảng quyết định là một kỹ thuật t t khi input có nhiố ều điều ki n và có nhi u action ệ ềoutput Giúp giảm thời gian ch y thạ ử nhưng vẫn gi bao ph cữ đủ độ ủ ủa test

d Chuyển đổi trạng thái (State Transition Testing)

Đây là một phương pháp kiểm thử mà trong đó dựa vào thay đổi điều kiện đầu vào gây

ra thay đổi trạng thái trong phần mềm được kiểm thử Trong k thuỹ ật này, tester s ẽ cung cấp c giá tr ki m thả ị ể ử đầu vào h p l và không h p lợ ệ ợ ệ, sau đó xác định cách x lý cử ủa

hệ thống

Các bước tạo bảng chuyển đổi trạng thái:

1 Liệt kê t t c các tr ng thái t biấ ả ạ ừ ểu đồ chuyển đổi tr ng thái vào cạ ột đầu tiên của bảng

2 Liệt kê t t cấ ả các kế ợp event/condition t h

3 Tạo b ng vả ới trong đó, mỗi hàng sẽ cho 1 tr ng thái vạ ới kết hợp event/condition

e Use cases Testing

Là m t kộ ỹ thuật ki m th ph n mể ử ầ ềm, giúp xác định các test cases bao ph toàn b h ủ ộ ệthống trên cơ sở chuyển giao t ừ điểm bắt đầu đến điểm kết thúc Ta có th s d ng Kiể ử ụ ểm thử Use Case để tìm các liên kết còn thiếu sót hay các yêu c u không hoàn ch nh, tầ ỉ ừ đó tìm cách khắc phục, hệ thống s ẽ hoạt động chính xác hơn

20

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

a Statement testing (ki m th câu lể ử ệnh) Trong kỹ thuật statement testing, mọi câu

lệnh trong c u trúc code sấ ẽ thực thi ít 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

b Decision testing (kiểm th quyử ết định) Decision testing sẽ thực thi, test nh ng ữquyết định dựa trên decision result (kết quả quyết định) Để làm điều này, test case

sẽ đi theo các control flow từ decision point (điểm quyết định) 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

c 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 này, test ỹcase được thiết kế để những điều kiện Boolean có thể thực thi d dàng ễ

d Multiple condition testing (ki m thể ử đa điề u kiệ Mn) ục đích của k thu t này 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 ạ ả

Kỹ thu Experience-base: ật

Phụ thuộc vào hi u bi t ể ế và năng lực của tester

Kiến th c, kinh nghi m cứ ệ ủa tester là cơ sở để thiết kế test case

Nhóm k thuỹ ật này được chia thành 2 loại:

a 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ử

b Error guessing (phỏng đoán lỗi) Error guessing được dùng để dự đoán 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

21

đây của phần mềm, các lỗi đã và có khả năng xuất hiện, những lỗi mà tester từng phát hiện,…

(Nguyễn Văn Nam, 2021)

1.6.3 Cấu trúc chính của m ột Test case:

Mã test case (ID test case): Giá tr cị ần để xác định th t c a test case ID có th ứ ự ủ ểbao g m ch và s ồ ữ ố được đánh dấu theo th tứ ự tăng dần

kiểm tra chức năng nào Ở ụ m c này, Tester s mô t công viẽ ả ệc th c hiự ện

Dữ liệu kiểm th (Test Data):ử Dữ liệu c n chu n b ầ ẩ ị để thực hiện việc kiểm th , ử

có th có ho c không tùy t ng quy mô d án Tester có thể ặ ừ ự ể để ở ạ d ng tên data hoặc đường d n tẫ ới file

Các bước thực hiện (Test Steps): Mô tả chi ti t những bước thực hi n test Tuy ế ệnhiên, Tester nên mô t m t cách ng n g n và thả ộ ắ ọ ật rõ ràng Đồng th i không nên ờ

bỏ qua các sự kiện thi t yế ếu để có th d dàng thể ễ ực hiệ ạn l i khi có l ỗi

bước kiểm thử Kết quả mong muốn thường dựa trên yêu c u c a khách hàng ầ ủhoặc đánh giá theo tài li u chuyên môn ệ

Kết qu ả thực t (Test Results):ế 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 sẽ là pass, fail hoặc pending

Ví dụ: Test case cho chức năng Thay đổi m t kh u ậ ẩ