Kiểm thử thủ công và tự động với robot framework trên website guru99 bank

Mục tiêu của đề tài Với đề tài "Kiểm thử thủ công và tự động với Robot Framework trên website Guru99 Bank" em hy vọng có thể: - Xây dựng và nâng cao kỹ năng kiểm thử thủ công và

ĐẠI HỌC KINH TẾ

TRƯỜNG ĐẠI HỌC ĐÀ NẴNG KHOA THỐNG KÊ – TIN HỌC

BÁO CÁO THỰC TẬP NGHỀ NGHIỆP NGÀNH HỆ THỐNG THÔNG TIN QUẢN LÝ

CHUYÊN NGÀNH QUẢN TRỊ HỆ THỐNG THÔNG TIN

TÊN ĐỀ TÀI:

KIỂM THỬ THỦ CÔNG VÀ TỰ ĐỘNG VỚI ROBOT FRAMEWORK

TRÊN WEBSITE GURU99 BANK

Đơn vị thực tập : Công ty TMA Solutions Bình Định

Giảng viên hướng dẫn : TS Hoàng Thị Thanh Hà

LỜI CẢM ƠN

Em xin phép được gửi sự tri ân sâu sắc và lời cảm ơn chân thành nhất đối với các thầy cô giáo Khoa Thống kê - Tin học trường Đại Học Kinh Tế Đà Nẵng đã tạo điều kiện để em có

cơ hội thực tập nghề nghiệp Đặc biệt, em xin trân trọng cảm ơn cô TS Hoàng Thị Thanh Hà

đã nhiệt tình hướng dẫn để em có thể hoàn thành tốt kì thực tập này

Em xin chân thành gửi lời cảm ơn đến Mentor Trịnh Xuân Bảo đã hướng dẫn trực tiếp, chỉ đạo và tạo mọi điều kiện giúp đỡ em trong suốt quá trình học cũng như thực tập tại đây Bên cạnh đó, em cũng trân trọng gửi lời cảm ơn đến quý công ty TMA Solutions Bình Định đã tạo điều kiện thuận lợi cho em được tìm hiểu thực tiễn trong suốt quá trình thực tập tại công ty nói chung và toàn thể anh chị trong DG6 nói riêng Sự hỗ trợ, chia sẻ kiến thức của các anh chị đã tạo điều kiện thuận lợi cho em hoàn thành nhiệm vụ thực tập một cách hiệu quả

Trong suốt quá trình thực tập cũng như quá trình tìm hiểu, sẽ không thể tránh khỏi những

sự thiếu sót và hạn chế Em rất mong nhận được những ý kiến đóng góp và phản hồi từ quý thầy cô để em có thể khắc phục được những sai sót cũng như rút ra được những bài học cho mình và trau dồi thêm những kiến thức mới Em xin chân thành cảm ơn!

LỜI CAM ĐOAN

Em xin cam đoan đề tài “Manual to Automation Test with Robot Framework on website Guru99 Bank” là kết quả nghiên cứu độc lập dưới sự hướng dẫn của T.S Hoàng Thị Thanh Hà

và Mentor Trịnh Xuân Bảo không có sự sao chép từ bất kỳ nguồn nào khác Ngoài ra, trong bài báo cáo có sử dụng một số nguồn tài liệu tham khảo đã được trích dẫn nguồn và chú thích

rõ ràng Em xin hoàn toàn chịu trách nhiệm trước bộ môn, Khoa và nhà trường về sự cam đoan này

MỤC LỤC

LỜI CẢM ƠN iii

LỜI CAM ĐOAN iv

MỤC LỤC v

DANH MỤC HÌNH ẢNH viii

DANH MỤC BẢNG BIỂU x

DANH MỤC CÁC TỪ VIẾT TẮT xi

LỜI MỞ ĐẦU xii

CHƯƠNG 1 TỔNG QUAN VỀ CÔNG TY VÀ VỊ TRÍ TESTER 1

1.1 Tổng quan về công ty TMA Solutions 1

1.1.1 Giới thiệu về công ty 1

1.1.2 Tầm nhìn và sứ mệnh 2

1.1.3 Giá trị cốt lõi 2

1.2 Tổng quan về vị trí Tester 2

1.2.1 Mô tả về vị trí Tester 2

1.2.2 Các kĩ năng cần có của một Tester 3

1.2.3 Cơ hội nghề nghiệp 4

1.2.4 Mức lương của Tester 5

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT 6

2.1 Tổng quan về kiểm thử phần mềm 6

2.1.1 Giới thiệu về kiểm thử phần mềm 6

2.1.2 Các nguyên tắc của kiểm thử phần mềm 7

2.1.3 Vòng đời kiểm thử phần mềm (STLC) 8

2.1.4 Phân biệt các thuật ngữ trong Tester 9

2.1.5 Vòng đời phát triển phần mềm (SDLC) 10

2.2 Các loại kiểm thử phần mềm 15

2.2.1 Manual Testing 15

2.2.2 Automation Testing 15

2.2.3 Security Testing 15

2.2.4 API Testing 16

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

2.3.1 Static Testing 17

2.3.2 Dynamic Testing 17

2.3.3 White Box Testing & Black Box Testing & Gray Box Testing 18

2.4 Cấp độ của kiểm thử 19

2.4.1 Unit Testing 19

2.4.2 Integration Testing 20

2.4.3 System Testing 20

2.4.4 User Acceptance Testing (UAT) 22

CHƯƠNG 3 TRIỂN KHAI DỰ ÁN 22

3.1 Công cụ sử dụng 22

3.1.1 Python 22

3.1.2 Visual Studio Code (VSCode) 24

3.1.3 Robot Framework 25

3.1.4 Selenium Library 27

3.2 Thực hiện kiểm thử trên Website 28

3.2.1 Môi trường thực hiện 28

3.2.2 Giới thiệu về website Guru99 Bank 28

3.2.2 Đặc tả yêu cầu 28

3.2.3 Test cases 40

3.2.4 Thực hiện kiểm thử tự động 43

TÀI LIỆU THAM KHẢO 51

CHECK LIST CỦA BÁO CÁO 52

PHỤ LỤC 53

DANH MỤC HÌNH ẢNH

Hình 1 Công ty TMA Solutions Bình Định 1

Hình 2 Logo Công ty TMA Solutions Bình Định 1

Hình 3 Vòng đời kiểm thử phần mềm (STLC) 8

Hình 4 Error, Bug, Fault và Failure 9

Hình 5 Vòng đời phát triển phần mềm (SDLC) 10

Hình 6 Mô hình thác nước (Waterfall Model) 12

Hình 7 Mô hình Agile 12

Hình 8 Scrum Framework 14

Hình 9 Black Box Testing 18

Hình 10 White Box Testing 19

Hình 11 Gray Box Testing 19

Hình 12 Python 22

Hình 13 Visual Studio Code 24

Hình 14 Robot Framework 25

Hình 15 Selenium Library 27

Hình 16 Website Guru99 Bank 28

Hình 17 Màn hình “Đăng ký” 30

Hình 18 Màn hình “Đăng nhập” 32

Hình 19 Màn hình “Đổi mật khẩu” 34

Hình 20 Màn hình “Thêm khách hàng mới” 36

Hình 21 Màn hình “Thêm tài khoản mới” 38

Hình 22 Testcase chức năng “Đăng ký” và “Đăng nhập” 40

Hình 23 Testcase chức năng “Đổi mật khẩu 41

Hình 24 Testcase chức năng “Thêm khách hàng mới” (1) 41

Hình 25 Testcase chức năng “Thêm khách hàng mới” (2) 42

Hình 26 Testcase chức năng “Thêm tài khoản mới” 42

Hình 27 Keywords (1) 44

Hình 28 Keywords (2) 44

Hình 29 Chạy Test case chức năng “Đăng ký” 45

Hình 30 Chạy Test case chức năng “Đăng nhập”(1) 46

Hình 31 Chạy Test case chức năng “Đăng nhập” (2) 46

Hình 32 Chạy Test case chức năng “Đổi mật khẩu”(1) 47

Hình 33 Chạy Test case chức năng “Đổi mật khẩu”(2) 48

Hình 34 Bảng tổng hợp chạy Test case tự động 49

DANH MỤC BẢNG BIỂU

Bảng 1 Bảng tính năng/Modules 29

Bảng 2 Bảng đặc tả yêu cầu chức năng “Đăng ký” 31

Bảng 3 Bảng đặc tả yêu cầu chức năng “Đăng nhập” 33

Bảng 4 Bảng đặc tả yêu cầu chức năng “Đổi mật khẩu” 35

Bảng 5 Bảng đặc tả yêu cầu chức năng “Thêm khách hàng mới” 37

Bảng 6 Bảng đặc tả yêu cầu chức năng “Thêm tài khoản mới” 40

Bảng 7 Bảng tổng hợp Test case 43

DANH MỤC CÁC TỪ VIẾT TẮT

STT Kí hiệu chữ viết tắt Chữ viết đầy đủ

LỜI MỞ ĐẦU

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

Guru99 Bank là một website giả định nhưng tương tự như môi trường thực tế của nhiều doanh nghiệp Việc kiểm thử trên môi trường này giúp hiểu rõ hơn về các thử nghiệm kiểm tra thực tế và cách tương tác với ứng dụng web phức tạp

Robot Framework là một công cụ phổ biến và có cộng đồng người sử dụng đông đảo Điều này đảm bảo rằng có thể dễ dàng tìm thấy tài liệu, hướng dẫn và hỗ trợ từ cộng đồng khi gặp khó khăn trong quá trình kiểm thử tự động

2 Mục tiêu của đề tài

Với đề tài "Kiểm thử thủ công và tự động với Robot Framework trên website Guru99 Bank" em hy vọng có thể:

- Xây dựng và nâng cao kỹ năng kiểm thử thủ công và tự động vào việc kiểm thử thực

tế trên website Guru99 Bank

- Xác định được các lỗi trên hệ thống hoặc các yêu cầu chưa đáp ứng với các yêu cầu thực tế đã được đề ra

3 Đối tượng và phạm vi nghiên cứu

- Đối tượng nghiên cứu: Website Guru99 Bank và công cụ kiểm thử tự động Robot Framework

- Thời gian: Nghiên cứu được thực hiện trong 10 tuần (19/6/2023 - 25/8/2023)

- Phạm vi nghiên cứu: Tập trung vào việc kiểm thử thủ công và tự động một số chức năng cho Website Guru99 Bank với công cụ Robot Framework

4 Kết cấu của đề tài

Đề tài được tổ chức gồm phần mở đầu, 3 chương nội dung và phần kết luận

- Mở đầu

- Chương 1: Tổng quan về công ty TMA và vị trí Tester

- Chương 2: Cơ sở lý thuyết

- Chương 3: Triển khai dự án

- Kết luận và hướng phát triển

CHƯƠNG 1 TỔNG QUAN VỀ CÔNG TY VÀ VỊ TRÍ TESTER 1.1 Tổng quan về công ty TMA Solutions

1.1.1 Giới thiệu về công ty

Hình 1 Công ty TMA Solutions Bình Định

TMA Solutions được thành lập năm 1997, với sự phát triển vững mạnh trong suốt 25 năm qua, tự hào là công ty phần mềm hàng đầu Việt Nam hiện nay với 16 năm liên tiếp (2004

- 2019) đạt huy chương vàng xuất khẩu phần mềm; Top 10 công ty FinTech, AI và IoT Công

ty có hơn 4000 kỹ sư tài năng đang làm việc, cùng nhau xây dựng hình ảnh TMA năng động và chuyên nghiệp trên bản đồ công nghệ thông tin toàn cầu

Hình 2 Logo Công ty TMA Solutions Bình Định

Khách hàng là những tập đoàn công nghệ cao hàng đầu thế giới từ 30 quốc gia TMA hiện có 7 chi nhánh tại Việt Nam (6 tại Tp.HCM và 1 ở Tp Quy Nhơn) cùng 6 chi nhánh ở nước ngoài (Mỹ, Úc, Canada, Đức, Nhật, Singapore)

1.1.2 Tầm nhìn và sứ mệnh

Tầm nhìn: Trở thành một công ty công nghệ thông tin hàng đầu toàn cầu, đồng thời góp phần xây dựng một cộng đồng thông tin năng động và phát triển bền vững TMA Solutions tập trung vào việc mang lại giá trị cao nhất cho khách hàng, đồng thời tạo ra một môi trường làm việc cởi mở, sáng tạo và thu hút nhân tài

Sứ mệnh: Cung cấp các giải pháp công nghệ thông tin hàng đầu và dịch vụ phần mềm chất lượng cao để giúp khách hàng nâng cao hiệu suất kinh doanh, tăng cường sự cạnh tranh và đạt được sự thành công bền vững TMA Solutions cam kết đem đến sự hài lòng cho khách hàng thông qua việc tạo ra các sản phẩm và dịch vụ chất lượng cao, đáng tin cậy và đột phá công nghệ

1.1.3 Giá trị cốt lõi

Sự tôn trọng: đối xử với người khác theo cách bạn muốn được đối xử

Trung thực: trung thực với những người khác và chính bạn

Sự cam kết: chúng tôi chuyển đổi lời hứa thành hiện thực

1.2 Tổng quan về vị trí Tester

1.2.1 Mô tả về vị trí Tester

Vị trí Tester là một vai trò quan trọng trong quá trình phát triển phần mềm Tester (hay còn được gọi là kiểm thử viên) đảm nhận nhiệm vụ kiểm tra, đánh giá và đảm bảo chất lượng của phần mềm trước khi nó được đưa ra sử dụng Công việc của Tester là tìm ra các lỗi, thiếu sót và vấn đề khác trong phần mềm và đưa ra báo cáo để nhóm phát triển có thể sửa chữa

Nhiệm vụ và trách nhiệm phổ biến của Tester:

- Xây dựng kế hoạch kiểm thử: Tester phải thiết lập kế hoạch kiểm thử dựa trên yêu cầu

và tài liệu liên quan Kế hoạch này bao gồm các bước kiểm thử, tài nguyên cần thiết và lịch trình thực hiện

- Thiết kế ca kiểm thử: Tester phải xác định các ca kiểm thử cần thiết dựa trên yêu cầu

và thiết kế của phần mềm Điều này bao gồm việc xác định các kịch bản kiểm thử, dữ liệu thử nghiệm và môi trường kiểm thử

- Thực hiện kiểm thử: Tester thực hiện các ca kiểm thử theo kế hoạch đã thiết lập Điều này có thể bao gồm việc chạy các kịch bản kiểm thử, nhập liệu thử nghiệm và theo dõi quá trình kiểm thử

- Ghi lại kết quả kiểm thử: Tester ghi lại kết quả kiểm thử và tạo báo cáo về các lỗi và vấn đề đã phát hiện Báo cáo này cung cấp thông tin chi tiết về các lỗi, bước tái hiện và bước sửa chữa đề xuất

- Tương tác với nhóm phát triển: Tester làm việc chặt chẽ với nhóm phát triển để báo cáo các lỗi và thảo luận về việc sửa chữa Họ cũng cung cấp thông tin về chất lượng của phần mềm để giúp đội ngũ phát triển cải thiện sản phẩm

- Kiểm tra hệ thống và hiệu suất: Tester có thể thực hiện các kiểm thử hệ thống để đảm bảo tính ổn định và tương thích của phần mềm trên các môi trường khác nhau Họ cũng

có thể thực hiện kiểm thử hiệu suất để đánh giá khả năng phản hồi và tải của ứng dụng

- Đảm bảo chất lượng: Tester có trách nhiệm đảm bảo chất lượng của phần mềm bằng cách tìm ra lỗi và đảm bảo rằng chúng được sửa chữa trước khi phần mềm được triển khai

1.2.2 Các kĩ năng cần có của một Tester

Kiến thức về kiểm thử phần mềm:

- Hiểu biết về các phương pháp kiểm thử, loại kiểm thử, mô hình kiểm thử, kiểm thử tự động và kiểm thử thủ công

- Biết cách xây dựng các kịch bản kiểm thử, testcase và test plan

- Hiểu về quy trình kiểm thử và quy trình phát triển phần mềm

Kiến thức về lĩnh vực ứng dụng:

- Hiểu về ngữ cảnh và mục tiêu của ứng dụng đang được kiểm thử

- Nắm rõ các yêu cầu chức năng và phi chức năng của ứng dụng

Kỹ năng phân tích:

- Có khả năng phân tích các yêu cầu kiểm thử và biến chúng thành các testcase và kịch bản kiểm thử cụ thể

- Biết cách định danh và ưu tiên các testcase quan trọng và có ảnh hưởng

Kỹ năng sử dụng công cụ kiểm thử:

- Hiểu và sử dụng các công cụ kiểm thử phần mềm như Selenium, JIRA, Bugzilla, TestRail, v.v

- Có khả năng tự động hóa kiểm thử để tăng hiệu quả và tiết kiệm thời gian

Kỹ năng ghi chép và báo cáo:

- Biết cách ghi chép kết quả kiểm thử và lỗi một cách chi tiết và rõ ràng

- Có khả năng báo cáo về tiến độ kiểm thử và tình trạng chất lượng của ứng dụng

Kỹ năng gỡ lỗi (Debugging):

- Biết cách tìm hiểu và gỡ lỗi các lỗi và vấn đề trong quá trình kiểm thử

- Có khả năng xác định nguyên nhân gây ra lỗi và báo cáo chúng một cách chính xác

Kiên nhẫn và sự chi tiết:

- Có tính kiên nhẫn trong việc kiểm thử các tính năng và tính năng của ứng dụng

- Đảm bảo sự chi tiết và tỉ mỉ trong việc kiểm tra để tìm ra các lỗi và vấn đề tiềm ẩn

Khả năng làm việc theo nhóm:

- Có khả năng làm việc cộng tác trong môi trường nhóm phát triển và làm việc chặt chẽ với các thành viên khác của nhóm

1.2.3 Cơ hội nghề nghiệp

Cơ hội nghề nghiệp của Tester trong ngành công nghiệp phần mềm hiện nay là rất hấp dẫn và đa dạng Vai trò của Tester là đảm bảo chất lượng của phần mềm trước khi được đưa vào

sử dụng, và với sự gia tăng về số lượng và phức tạp của ứng dụng phần mềm, vai trò này trở nên ngày càng quan trọng Dưới đây là một số cơ hội nghề nghiệp của Tester:

- Tester/Quality Assurance (QA) Engineer: Đây là vai trò cơ bản của Tester, thực hiện

kiểm thử và đảm bảo chất lượng phần mềm Tester thường làm việc trong quy trình

phát triển phần mềm và đảm bảo rằng các yêu cầu kiểm thử được thỏa mãn và các lỗi được phát hiện và gỡ bỏ

- Test Automation Engineer: Tester tự động hóa kiểm thử bằng cách sử dụng các công

cụ tự động hóa kiểm thử Vai trò này yêu cầu kiến thức về lập trình và kỹ năng sử dụng các công cụ tự động hóa như Selenium, Appium, Robot Framework, và nhiều công cụ khác

- Software Quality Analyst: Tester chuyên về đánh giá và đảm bảo chất lượng toàn

diện của phần mềm Họ thực hiện kiểm thử, phân tích lỗi, và đánh giá hiệu suất và khả năng mở rộng của ứng dụng

- Test Manager/Lead: Tester có thể tiến thẳng trở thành quản lý kiểm thử Vai trò này

đòi hỏi kiến thức rộng về kiểm thử phần mềm và kỹ năng quản lý dự án Họ đảm bảo

tổ chức và điều phối quá trình kiểm thử cũng như quản lý nhóm Tester

- DevOps Engineer: DevOps Engineer kết hợp giữa phát triển và vận hành hệ thống

Tester có thể đóng góp trong việc triển khai tự động, kiểm thử liên tục và đảm bảo rằng phần mềm được triển khai một cách ổn định và đáng tin cậy

- Security Tester/Penetration Tester: Tester chuyên về kiểm thử bảo mật của phần

mềm, tìm kiếm và đánh giá các lỗ hổng bảo mật Vai trò này ngày càng quan trọng khi mà an ninh thông tin là ưu tiên hàng đầu của các tổ chức

- Mobile App Tester: Tester chuyên về kiểm thử ứng dụng di động trên các nền tảng và

thiết bị khác nhau Với sự phát triển mạnh mẽ của ứng dụng di động, cơ hội trong lĩnh vực này ngày càng tăng

- Game Tester: Tester đánh giá và kiểm thử các trò chơi điện tử, đảm bảo rằng chúng

hoạt động một cách suôn sẻ và đáng chơi

1.2.4 Mức lương của Tester

- Hiện nay ở Việt Nam mức lương Tester dao động từ 8 – 25 triệu đồng/tháng Tuy nhiên mức thu nhập này còn thay đổi mạnh mẽ tùy thuộc vào vị trí công việc, kinh nghiệm làm việc, tùy từng công ty Ví dụ như mức lương của Automation Tester của công ty

A có thể là 1000 USD nhưng ở một công ty khác thì là 800 USD

- Mức lương trung bình phổ biến của Tester hiện nay tại Việt Nam là 15 triệu 800 nghìn đồng mỗi tháng Điều đó có nghĩa là 50% nhân viên làm việc Tester có mức thu nhập dưới 15.800.000 đồng, còn 50% còn lại có thu nhập trên 15.800.000 đồng Có thể thấy mức thu nhập mà nghề Tester đem lại là tương đối cao so với thị trường hiện nay

CHƯƠNG 2 CƠ SỞ LÝ THUYẾT

2.1 Tổng quan về kiểm thử phần mềm

2.1.1 Giới thiệu về kiểm thử phần mềm

Kiểm thử phần mềm là một quá trình thực thi một chương trình hoặc ứng dụng với mục đích tìm ra các lỗi phần mềm Và được sử dụng để xác định tính đúng đắn, đầy đủ và chất lượng của phần mềm máy tính được phát triển

Kiểm thử phần mềm là cần thiết bởi vì tất cả chúng ta đều phạm sai lầm Một số sai lầm

đó không quan trọng, nhưng một số lại rất tốn kém hoặc nguy hiểm Chúng ta cần kiểm tra mọi thứ tránh sai sót tối đa để giao sản phẩm cho khách hàng Đảm bảo rằng khách hàng thấy

tổ chức đáng tin cậy và duy trì sự hài lòng của họ đối với ứng dụng

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

- Đảm bảo chất lượng của sản phẩm

- Phòng ngừa và phát hiện lỗi

- Sẵn sàng tích hợp và sửa đổi phần mềm

- Cung cấp thông tin để ra quyết định cho giai đoạn tiếp theo

- Thảo luận về việc tạo các trường hợp thử nghiệm

- Tăng cường độ tự tin trong công việc

- Tìm ra được lỗi trước khi đến tay khách hàng

2.1.2 Các nguyên tắc của kiểm thử phần mềm

- Kiểm thử chỉ ra sự hiện diện của lỗi: Kiểm thử phần mềm chỉ có thể phát hiện lỗi,

giúp giảm xác suất lỗi tồn tại chứ không thể chứng minh rằng phần mềm đó không có lỗi

- Kiểm thử càng sớm càng tốt: tìm ra các lỗi sớm thì sẽ tiết kiệm thời gian, chi phí để

khắc phục các lỗi đó hơn

- Thực hiện kiểm thử toàn bộ là không thể: Trong thực tế các dự án thường diễn ra,

đối với các giai đoạn gấp rút và điều kiện không cho phép Kiểm thử toàn bộ là không thể Thay vì 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 chúng

ta có thể tập trung việc kiểm thử vào một số điểm cần thiết

- Phân cụm lỗi: Trong quá trình thực hiện kiểm thử, ta sẽ thấy rằng có lỗi tập trung ở

một số ít các module chức năng trong sản phẩm đang kiểm thử khi phát hiện lỗi trong một chức năng nào thì chức năng đó ở những màn hình khác thường sẽ có lỗi tương tự như vậy

- Nghịch lý thuốc trừ sâu: không dùng 1 test case đã có để test đi test lại 1 phần mềm

vì cũng giống như là hiện tượng lờn thuốc, lúc đấy ta sẽ ko tìm ra bug nữa, vì thế các test case cần phải được xem xét và sửa đổi thường xuyên

- Kiểm thử theo ngữ cảnh: Chân lý này thể hiện rằng với mỗi sản phẩm khác nhau,

trong những lĩnh vực công việc khác nhau thì việc kiểm thử cũng sẽ khác nhau

Ví dụ: các sản phẩm phần mềm yêu cầu tính an toàn cao thì sẽ phải kiểm thử khác với

các sản phẩm thương mại khác

- Sự sai lầm về việc không có lỗi: kiểm thử không chỉ đơn giản là tìm và sửa lỗi việc

tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựng xong mà không thể dùng được và không đáp ứng được nhu cầu của người dùng

2.1.3 Vòng đời kiểm thử phần mềm (STLC)

Hình 3 Vòng đời kiểm thử phần mềm (STLC)

Vòng đời kiểm thử phần mềm (Software Testing Life Cycle - STLC) gồm 6 giai đoạn:

- Đọc và phân tích tài liệu

Đọc, hiểu các đặc tả yêu cầu của khách hàng, đưa ra các câu hỏi và giải thích vd như là test ở môi trường nào…

- Lập kế hoạch kiểm thử

Ở bước này sẽ tiến hành phân công việc, liệt kê ra những công việc sẽ làm, phải đưa ra được mình sẽ làm những gì và trong vòng bao lâu Xác định mục đích để biết được giới hạn

project là ở đâu

- Phát triển Testcase

Sau khi có test plan, dựa vào các yêu cầu của ứng dụng (tài liệu đặc tả), tiến hành viết ra các test case

- Thiết lập môi trường

Tiến hành thiết lập môi trường test, xem ứng dụng cần gì, chạy trên hệ điều hành nào (windown, androi, IOS, … ) bất cứ môi trường nào trong tài liệu đặt tả đã yêu cầu

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

Sau khi đưa sản phẩm lên môi trường kiểm thử, tester tiến hành thực thi các test case đã viết, ghi lại các lỗi

- Theo dõi vòng đời kiểm thử

Tổng hợp các report, sau khi có tất cả các report, cả team sẽ tiến hành đánh giá chất lượng của team ở giai đoạn vừa qua, test case viết có ổn hay không, có cập nhật nhiều hay không, có

bao nhiêu bug, từ đó rút ra được kinh nghiệm, có những pratices cho dự án trong tương lai

2.1.4 Phân biệt các thuật ngữ trong Tester

Phân biệt Error, Bug, Fault và Failure

Hình 4 Error, Bug, Fault và Failure

Error: là lỗi do con người tạo ra trong quá tình phát triển phần mềm, sự không cẩn

thận của Dev ví dụ như code thiếu dâú chấm, dấu phẩy Error có thể tương đương với sự nhầm lẫn (mistake)

Bug: Khi Tester kiểm thử phần mềm và tìm ra lỗi

Fault: là trạng thái khi xảy ra error

Failure: là lỗi tìm được trong quá trình sản phẩm được dùng trong thực tế, đó chính là

độ lệch của kết quả thực tế so với kết quả mong đợi

Phân biệt Verification và Validation

- Varification: xác minh và làm đúng theo yêu cầu của khách hàng dựa trên các tài liệu đặc tả và thông số kĩ thuật

- Validation: xác thực xem có đúng như mong đợi thực tế của khách hàng không

Phân biệt QA và QC

- QA (Quality Assurance - Đảm bảo chất lượng): Giúp cho team hoạt động theo đúng quy trình phát triển phần mềm, hạn chế ngăn ngừa lỗi

- QC (Quality Control – Kiểm soát chất lương): Thường là tester, thực hiện việc xác định lỗi và đảm bảo phần mềm đó kh có lỗi

2.1.5 Vòng đời phát triển phần mềm (SDLC)

Hình 5 Vòng đời phát triển phần mềm (SDLC)

- Các giai đoạn Software Development Life Cycle - SDLC (Vòng đời phát triển phần mềm) là một loạt các giai đoạn mà các dự án phần mềm trải qua từ khi bắt đầu đến khi hoàn thành

- SDLC gồm 6 giai đoạn:

Giai đoạn 1: Thu thập và phân tích yêu cầu

- Các yêu cầu sẽ được thu thập trong giai đoạn này sẽ trả lời các câu hỏi như:

Ai sẽ sử dụng hệ thống?

Họ sẽ sử dụng hệ thống như thế nào?

Những dữ liệu nào sẽ được nhập / xuất vào hệ thống ?

Giai đoạn 2: Design

- Ở giai đoạn này, từ các yêu cầu được thu thập trong giai đoạn đầu tiên sẽ tiến hành thiết

kế hệ thống và phần mềm cơ bản

Giai đoạn 3: Implementation/ Coding

- Từ các design đã được thiết kế ở giai đoạn trước dev sẽ code theo

Giai đoạn 4: Testing

- Sau khi code xong, từ những yêu cầu được thu thập ở giai đoạn đầu tiên, tester sẽ tiến hành kiểm thử để đảm bảo rằng sản phẩm đáp ứng được các yêu cầu của khách hàng

Giai đoạn 5: Deployment

- Sau khi kiểm thử thành công sản phẩm được triển khai cho khách hàng sử dụng Giai đoạn 6: Maintenance

- Khi khách hàng sử dụng hệ thống thực tế thì theo thời gian sẽ xuất hiện các vấn đề cần được giải quyết Nên giai đoạn này gọi là bảo trì Bảo trì thường từ 1-3 tháng để xem khi họ sử dụng có feedback hay lỗi gì không

- Các mô hình vòng đời phát triển phần mềm:

Waterfall model

V model Incremental model RAD model

Agile model (Scrum and Kanban Methodology) Iterative model

Spiral model

Mô hình Waterfall

Hình 6 Mô hình thác nước (Waterfall Model)

- Mô hình Waterfall là một mô hình phát triển phần mềm tuần tự Có các giai đoạn tương

tự như SDLC Tất cả cùng làm một giai đoạn, mỗi giai đoạn chỉ bắt đầu khi giai đoạn trước đó hoàn thành và không thể quay lại

Mô hình Agile

Hình 7 Mô hình Agile

- Để giải quyết các mô hình phát triển phần mềm truyền thống như mô hình Waterfall quá cứng nhắc và khó thích nghi với sự thay đổi và tương tác của khách hàng thì mô hình Agile đã được phát triển để giải quyết các vấn đề này

- Agile Model là một phương pháp phát triển phần mềm đề cập đến quá trình lặp đi lặp lại để phát triển và cải tiến sản phẩm Chia dự án thành các interation, mỗi interation là một chu kỳ phát triển sản phẩm tập trung vào phát triển một chức năng của sản phẩm

để đảm bảo sự hoàn thiện và đáp ứng yêu cầu của khách hàng Trong quá trình interation, sản phẩm được phát triển một cách tương tác và linh hoạt với sự tham gia

tích cực của khách hàng để đảm bảo rằng sản phầm đáp ứng được yêu cầu và mong đợi của khách hàng

- Mỗi interation bao gồm các hoạt động như lập kế hoạch, thiết kế, code, kiểm thử, đánh giá:

Lập kế hoạch: Xác định mục tiêu cụ thể cho interation và lên kế hoạch cho các hoạt

động của interation

Thiết kế: Thiết kế các tính năng hoặc chức năng cần thiết trong interation, đảm bảo

tính tương thích, tính bảo mật và tính mở rộng của sản phẩm

Phát triển/ code: Thực hiện các công việc lập trình, kiểm tra code và tích hợp các

thành phần phần mềm để tạo sản phẩm hoàn chỉnh

Kiểm thử: Thực hiện các cuộc kiểm thử để đảm bảo tính hoạt động, độ tin cậy và hiệu

suất của sản phẩm

Đánh giá: Đánh giá kết quả của interation, đảm bảo rằng các mục tiêu đã đặt ra được

đáp ứng và đưa ra các cải tiến cho interation tiếp theo

Scrum Methodology

- Scrum tập trung vào việc tạo ra các sản phẩm phần mềm có giá trị cao trong các khối thời gian ngắn gọi là Sprint

- Scrum team bao gồm: Scrum master, product owner, development team

Scrum master: giúp team hoạt động theo đúng mô hình Scrum, loại bỏ những trở ngại Product owner: gặp khách hàng và thu thập yêu cầu

Development team: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất nhiều

đội, nhiều người tham gia

Khung làm việc của Scrum:

Hình 8 Scrum Framework

Đầu tiên Product Owner sẽ đi gặp khách hàng, thu thập yêu cầu và viết các Product Backlog

→ tiến hành một cuộc họp sprint planing testing → lấy một phần trong Product Backlog để họp => đầu ra là Sprint Backlog (chia nhỏ task để thực hiện công việc)

Một Sprint kéo dài từ 1-4 tuần (thường là 2 tuần)

Mỗi ngày đều có Daily scrum meeting: mỗi người trả lời các câu hỏi: Hôm qua đã làm gì? Hôm nay làm gì? Có gặp khó khăn gì trong task của mình không? → Cập nhật burndown/up charts

Sprint burndown charts: mức độ hoàn thành (đồ thị sẽ chỉ thời gian giảm dần)

Sprint burnup charts: tiến độ task hoàn thành tăng dần đến hết task

Kết thúc các công việc → sprint review: hoàn thành được bao nhiêu task? (task phải rõ ràng, cụ thể, hoàn thành bao nhiêu sprint backlog, test được bao nhiêu bugs)

Cuối cùng là Sprint Retrospective: cả team nêu ra những điểm tốt, chưa tốt như 2 tuần vừa qua làm việc có hiệu quả không? Có xích mích nào cần giải quyết không? Có thiếu thiết bị không?

Kanban Methodology

Ban đầu, Kanban được phát triển bởi Toyota trong ngành sản xuất ô tô và sau đó đã được

áp dụng rộng rãi trong các lĩnh vực khác, bao gồm phát triển phần mềm

- Phương pháp Kanban: sử dụng bảng Kanban hay bảng quản lý công việc, trong đó các công việc được biểu diễn bằng các thẻ note, và di chuyển qua các giai đoạn khác nhau của quy trình làm việc (ví dụ: “to do", “doing", “done") Mỗi giai đoạn được đại diện bởi một cột trên bảng Kanban Làm xong bước nào kéo mình làm tiếp bước khác → Phương pháp này đánh giá sự tự giác của mình

- Kanban giúp tổ chức công việc linh hoạt, giảm thời gian chờ đợi và cải thiện hiệu suất làm việc

2.2 Các loại kiểm thử phần mềm

2.2.1 Manual Testing

Là quá trình kiểm tra phần mềm bằng tay, tức là người thử nghiệm thực hiện các ca kiểm thử và kiểm tra các tính năng, chức năng và tương tác của phần mềm một cách thủ công, mà không sử dụng bất kỳ công cụ tự động hóa nào

2.2.2 Automation Testing

Yêu cầu phải có kiến thức về lập trình, tester sẽ viết các lệnh và sử dụng một phần mềm khác để test một phần mềm Ngoài ra còn sử dụng để chạy lại các kịch bản kiểm thử được hiện thủ công nhanh chóng và lặp đi lặp lại

2.2.3 Security Testing

- Security testing là quá trình kiểm thử hoặc đánh giá các hệ thống, ứng dụng, sản phẩm hoặc quy trình để xác định các lỗ hổng bảo mật, vấn đề liên quan đến sự bảo mật và các rủi ro tiềm ẩn Mục tiêu của việc thực hiện security testing là để đảm bảo rằng hệ thống hoạt động một cách an toàn và bảo mật, giúp ngăn chặn các cuộc tấn công và đảm bảo bảo vệ thông tin nhạy cảm của người dùng

- Các phạm vi của security testing bao gồm kiểm tra các lỗ hổng bảo mật trong phần mềm, ứng dụng web, ứng dụng di động, cơ sở dữ liệu, hệ thống mạng, cũng như kiểm tra các quy trình và chính sách bảo mật của tổ chức

- Các phương pháp thường được sử dụng trong security testing bao gồm penetration testing (kiểm thử xâm nhập), vulnerability scanning (quét lỗ hổng), code review (đánh giá mã nguồn), social engineering (kỹ thuật xâm nhập bằng xã hội), và nhiều phương pháp kiểm thử khác nhau

2.2.4 API Testing

API testing là quá trình kiểm thử các giao diện lập trình ứng dụng (APIs - Application Programming Interfaces) API là một bộ tập các quy tắc và các phương thức mà cho phép hai ứng dụng phần mềm khác nhau giao tiếp và trao đổi dữ liệu và chức năng với nhau Nó giúp cho việc tích hợp ứng dụng và chia sẻ dữ liệu trở nên dễ dàng và linh hoạt hơn

Trong quá trình phát triển phần mềm, thường có hai ứng dụng sử dụng API của nhau để giao tiếp, ví dụ như ứng dụng di động gọi API của máy chủ để lấy dữ liệu từ máy chủ API testing nhằm đảm bảo rằng các giao diện này hoạt động đúng và đáp ứng các yêu cầu về chức năng và bảo mật

Các phương pháp và kỹ thuật thường được sử dụng trong API testing bao gồm:

- Kiểm tra giao diện API (API endpoint testing): Kiểm tra các yêu cầu và phản hồi của API bằng cách gửi các yêu cầu HTTP và kiểm tra kết quả trả về

- Kiểm tra kiểu dữ liệu (Data type testing): Kiểm tra tính hợp lệ của dữ liệu đầu vào và đầu ra của API, đảm bảo rằng các kiểu dữ liệu được truyền đúng cách

- Kiểm tra chức năng (Functional testing): Kiểm tra tính hợp lệ và đáp ứng yêu cầu chức năng của API, bao gồm cả kiểm tra các tình huống biên và tình huống bất thường

- Kiểm tra hiệu năng (Performance testing): Đánh giá hiệu suất của API, bao gồm thời gian phản hồi, tải cao, và khả năng chịu tải

- Kiểm tra bảo mật (Security testing): Kiểm tra bảo mật của API, đảm bảo rằng nó không bị lộ thông tin quan trọng hoặc dễ bị tấn công

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

2.3.1 Static Testing

Static testing là một phương pháp kiểm thử phần mềm được thực hiện trong giai đoạn phân tích và thiết kế của quy trình phát triển phần mềm Điểm đặc trưng của static testing là nó không yêu cầu thực thi code hoặc chạy phần mềm trong môi trường thực tế Thay vào đó, nó tập trung vào việc xem xét và đánh giá các tài liệu, code, mô hình và các yêu cầu khác liên quan đến phần mềm

Các hoạt động phổ biến trong static testing bao gồm:

- Code reviews: Đánh giá mã nguồn của phần mềm để xác định lỗi lập trình, thiếu sót

và tuân thủ các quy chuẩn lập trình

- Requirement reviews: Xem xét và đánh giá yêu cầu của hệ thống hoặc ứng dụng để

đảm bảo rằng chúng đủ rõ ràng, đầy đủ và có thể thực hiện được

- Design reviews: Kiểm tra và đánh giá thiết kế hệ thống hoặc giao diện người dùng để

đảm bảo tính hợp lý và khả thi

- Document reviews: Xem xét các tài liệu, tài liệu hướng dẫn, tài liệu vận hành để đảm

bảo tính đầy đủ và chính xác

- Model reviews: Xem xét các mô hình thiết kế, mô hình dữ liệu, và các mô hình khác

liên quan để phát hiện lỗi thiết kế

- Walkthroughs: Là một quy trình kiểm thử bằng cách điểm qua từng phần của mã

nguồn hoặc tài liệu để phát hiện lỗi và cải thiện

Static testing giúp phát hiện lỗi và vấn đề sớm trong quy trình phát triển phần mềm, từ đó giảm thiểu chi phí và thời gian sửa lỗi sau này Nó là một phương pháp hiệu quả để cải thiện chất lượng phần mềm và đảm bảo rằng sản phẩm cuối cùng đáp ứng các yêu cầu và mong đợi của người dùng

2.3.2 Dynamic Testing

Dynamic testing là một phương pháp kiểm thử phần mềm được thực hiện bằng cách thực thi mã hoặc chạy ứng dụng trong môi trường thực tế để đánh giá hoạt động của nó Điểm đặc

trưng của dynamic testing là nó tập trung vào việc kiểm tra phần mềm trong thời gian chạy để xác định các lỗi, vấn đề và hiệu suất của ứng dụng

Kĩ thuật Dynamic Testing được chia làm 3 loại:

- Specification-based techniques

- Structure-based techniques

- Experience-based techniques

Specification-based techniques (Kĩ thuật dựa trên đặc điểm kĩ thuật):

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

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

Kiểm tra bảng quyết định (Decision Table Testing)

Sơ đồ chuyển đổi trạng thái (State Transition Diagrams)

Use Case Testing

2.3.3 White Box Testing & Black Box Testing & Gray Box Testing

Black box testing (kiểm thử hộp đen) là pp trong đó tester sẽ không biết về cấu trúc, logic hoặc code của phần mềm Họ chỉ tập trung vào đầu vào và đầu ra của hệ thống để kiểm tra các chức của luồng công việc của phần mềm

Hình 9 Black Box Testing

White box testing (kiểm thử hộp trắng): thấy được bên trong lập trình viên viết gì, tester yêu cầu phải có kĩ năng lập trình, tester sẽ nhìn vào code và hiểu code từ đó đưa ra những test case để tìm bugs

Hình 10 White Box Testing

Gray box testing là một phương pháp kiểm thử phần mềm kết hợp cả hai phương thức kiểm thử: black box testing (kiểm thử hộp đen) và white box testing (kiểm thử hộp trắng) Trong gray box testing, người kiểm thử có một lượng hạn chế thông tin về cấu trúc và code bên trong của ứng dụng, tức là họ biết một số thông tin về cấu trúc bên trong, nhưng không hoàn toàn biết rõ các chi tiết

Hình 11 Gray Box Testing

2.4 Cấp độ của kiểm thử

2.4.1 Unit Testing

- Kiểm thử đơn vị là cấp độ kiểm thử phần mềm trong đó các đơn vị/thành phần riêng lẻ của phần mềm được kiểm tra Mục đích là để xác nhận rằng mỗi đơn vị của phần mềm hoạt động như thiết kế

- Đơn vị ở đây có thể là một hàm, một phương thức, một class hoặc một module

- Do Unit test được tiến hành trong quá trình lập trình, người thực hiện Unit test có thể chính là Dev