Báo Cáo - Thực Tập Nghề Nghiệp - Chuyên Ngành - Quản Trị Hệ Thống Thông Tin - Đề Tài - Nghiên Cứu Và Triển Khai Manual Testing Trên Ứng Dụng Chăm Sóc Sức Khoẻ Vhealth

TRƯỜNG ĐẠI HỌC KINH TẾ 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 NGHIÊN CỨU VÀ TRIỂN KHAI MANUAL TESTING TRÊN ỨNG D[.]

TRƯỜNG ĐẠI HỌC KINH TẾ 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

NGHIÊN CỨU VÀ TRIỂN KHAI MANUAL TESTING TRÊN ỨNG DỤNG CHĂM SÓC SỨC KHOẺ VHEALTH

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

MỤC LỤC

LỜI CẢM ƠN ii

LỜI CAM ĐOAN iii

MỤC LỤC iv

DANH MỤC HÌNH ẢNH vii

DANH MỤC BẢNG BIỂU ix

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

LỜI MỞ ĐẦU xi

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

1.1 Giới thiệu tổng quát về công ty TMA Solutions Bình Định 1

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

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

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

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

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

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

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

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

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

2.1.2 Mục tiêu của kiểm thử 7

2.1.3 Quy trình phát triển phần mềm 7

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

2.1.5 Phân biệt Error/ Fault/ Failure 8

2.1.6 Phân biệt Verification & Validation 9

2.1.7 Phân biệt QA & QC 9

2.2 Vòng đời phát triển phần mềm 10

2.2.1 Giai đoạn phát triển phần mềm 10

2.2.2 Mô hình Water Fall 11

2.2.3 Mô hình V Model 12

2.2.4 Mô hình Agile 13

2.2.5 Phương pháp Scrum 13

2.2.6 Phương pháp Kanban 14

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

2.3.1 Manual Testing 15

2.3.2 Automation Testing 15

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

2.4.1 Static Testing 15

2.4.2 Dynamic Testing 15

2.4.3 White Box Testing 16

2.4.4 Black Box Testing 16

2.4.5 Gray Box Testing 16

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

2.5.1 Unit Testing 17

2.5.2 Integration Testing 17

2.5.3 System Testing 17

2.5.4 Acceptance Testing 17

2.6 Kỹ thuật thiết kế Test case và vòng đời bug 18

2.6.1 Kỹ thuật Specification-based 18

2.6.2 Kỹ thuật Experience-based 18

2.6.3 Giải thích vòng đời bug 18

2.6.4 Báo cáo bug trên Jira 19

2.6.5 Test case là gì? 20

2.6.6 Các loại kiểm thử ứng dụng Mobile 20

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

3.1 Tổng quan về ứng dụng 22

3.1.1 Giới thiệu về ứng dụng 22

3.1.2 Chức năng của ứng dụng 23

3.2 Triển khai dự án vHealth 23

3.2.1 Tài liệu đặc tả yêu cầu 23

3.2.1.1 Kết nối thiết bị đồng hồ thông minh 25b/25e 23

3.2.1.2 Theo dõi chỉ số sức khỏe 25

3.2.1.3 Cuộc gọi khẩn cấp SOS 28

3.2.1.4 Nhật ký triệu chứng 30

3.2.1.5 Theo dõi sức khoẻ người thân 31

3.2.2 Thiết kế và thực thi Test case 33

3.2.2.1 Test case kết nối thiết bị 33

3.2.2.2 Test case theo dõi chỉ số sức khoẻ 33

3.2.2.3 Test case cuộc gọi khẩn cấp SOS 34

3.2.2.4 Test case nhật ký triệu chứng 35

3.2.2.5 Test case theo dõi sức khoẻ người thân 36

3.3 Báo cáo Bug trên Jira 36

3.3.1 Kết nối thiết bị đồng hồ thông minh 25b/25e 36

3.3.2 Theo dõi chỉ số sức khỏe 38

3.3.3 Cuộc gọi khẩn cấp SOS 40

3.3.4 Nhật ký triệu chứng 42

3.3.5 Theo dõi sức khoẻ người thân 45

3.4 Kết quả 47

3.5 Kết luận 48

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 49

TÀI LIỆU THAM KHẢO 50

DANH MỤC HÌNH ẢNH

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

Hình 2: Nhóm Data Science Group 2

Hình 3: Công viên Sáng tạo TMA Bình Định 2

Hình 4: Quy trình phát triển phần mềm 7

Hình 5: Nguyên tắc của kiểm thử phần mềm 7

Hình 6: QA & QC 9

Hình 7: Mô hình Water Fall 11

Hình 8: Mô hình V Model 12

Hình 9: Mô hình Agile 13

Hình 10: Phương pháp Scrum 13

Hình 11: Phương pháp kiểm thử Static Testing 15

Hình 12: White Box Testing 16

Hình 13: Black Box Testing 16

Hình 14: Gray Box Testing 16

Hình 15: Gray Box Testing 17

Hình 16: Vòng đời bug 18

Hình 17: Giao diện ứng dụng vHealth 22

Hình 18: Luồng kết nối thiết bị 24

Hình 19: Giao diện kết nối thiết bị 25

Hình 20: Luồng theo dõi chỉ số sức khoẻ 26

Hình 21: Giao diện theo dõi chỉ số sức khoẻ 28

Hình 22: Luồng cuộc gọi khẩn cấp SOS 29

Hình 23: Giao diện cuộc gọi khẩn cấp SOS 30

Hình 24: Luồng nhật ký triệu chứng 30

Hình 25: Giao diện nhật ký triệu chứng 31

Hình 26: Luồng theo dõi sức khoẻ người thân 32

Hình 27: Giao diện theo dõi sức khoẻ người thân 32

Hình 28: Test case kết nối thiết bị 33

Hình 29: Test case theo dõi chỉ số sức khoẻ 34

Hình 30: Test case cuộc gọi khẩn cấp SOS 34

Hình 31: Test case nhật ký triệu chứng 35

Hình 32: Test case theo dõi sức khoẻ người thân 36

Hình 33: Bug thiết bị trùng lặp khi quét 36

Hình 34: Minh chứng cho Bug thiết bị trùng lặp khi quét 37

Hình 35: Bug ứng dụng không kết nối lại khi người dùng di chuyển <30 phút 37

Hình 36: Minh chứng cho Bug ứng dụng không kết nối lại khi người dùng 37

Hình 37: Bug ứng dụng hiện popup "Làm mới dữ liệu thất bại" sau khi nhập dữ liệu mặc dù người dùng không kết nối thiết bị 38

Hình 38: Minh chứng cho Bug ứng dụng hiện popup "Làm mới dữ liệu thất bại" sau khi nhập dữ liệu mặc dù người dùng không kết nối thiết bị 38

Hình 39: Bug Không hiển thị Báo cáo thống kê về giấc ngủ mặc dù có dữ liệu 38

Hình 40: Minh chứng cho Bug Không hiển thị Báo cáo thống kê về giấc ngủ mặc dù

có dữ liệu 39

Hình 41: Bug ứng dụng không hiển thị chất lượng giấc ngủ trước 12 giờ trưa 39

Hình 42: Minh chứng cho Bug ứng dụng không hiển thị chất lượng giấc ngủ trước 12 giờ trưa 39

Hình 43: Bug không đánh dấu là đã đọc khi nhấp vào xem trường hợp SOS 40

Hình 44: Minh chứng cho Bug không đánh dấu là đã đọc khi nhấp vào xem 40

Hình 45: Bug người dùng SOS nhưng nhận thông báo rủi ro cao trên tổng đài 41

Hình 46: Minh chứng cho Bug người dùng SOS nhưng nhận được thông báo 41

Hình 47: Bug Popup không tự động tắt sau 2 phút người dùng không thao tác 42

Hình 48: Minh chứng cho Bug Popup không tự động tắt sau 2 phút người dùng không thao tác 42

Hình 49: Bug Không gõ được dấu ở phần ghi chú 42

Hình 50: Minh chứng cho Bug Không gõ được dấu ở phần ghi chú 43

Hình 51: Bug khi thêm Triệu chứng khác, màn hình ứng dụng không hiển thị thông báo: '{triệu chứng khác}' không có trong danh sách khả dụng Vui lòng chọn mục bên dưới để thay thế 43

Hình 52: Minh chứng cho Bug khi thêm Triệu chứng khác, màn hình ứng dụng không hiển thị thông báo: '{triệu chứng khác}' không có trong danh sách khả dụng Vui lòng chọn mục bên dưới để thay thế 44

Hình 53: Bug khi thêm nhiều triệu chứng, định dạng ghi chú không đúng như thiết kế 44

Hình 54: Minh chứng cho Bug khi thêm nhiều triệu chứng, định dạng ghi chú không đúng như thiết kế 45

Hình 55: Bug mất chỉ số nhân sự trên màn hình quan trọng về sức khỏe ở chế độ xem của Người thân sau khi người dùng nhập BG 45

Hình 56: Minh chứng cho Bug mất chỉ số nhân sự trên màn hình quan trọng về sức khỏe ở chế độ xem của Người thân sau khi người dùng nhập BG 45

Hình 57: Bug Người thân không nhận được thông báo trên tổng đài khi người dùng gửi yêu cầu 46

Hình 58: Minh chứng cho Bug Người thân không nhận được thông báo trên tổng đài khi người dùng gửi yêu cầu 46

Hình 59: Bug ngắt giao diện người dùng trên tab Danh bạ 47

Hình 60: Minh chứng cho Bug ngắt giao diện người dùng trên tab Danh bạ 47

DANH MỤC BẢNG BIỂU

Bảng 1: So sánh QA và QC 10

Bảng 2: Phân loại chức năng của ứng dụng 23

Bảng 3: Thông tin của chức năng Kết nối thiết bị đồng hồ thông minh 25b/25e 23

Bảng 4: Mô tả luồng chính của chức năng Kết nối thiết bị đồng hồ thông minh 25b/25e 24

Bảng 5: Tính năng tích hợp với thiết bị 25b/25e 24

Bảng 6: Thông tin của chức năng Theo dõi chỉ số sức khỏe 25

Bảng 7: Mô tả luồng chính cho chức năng Theo dõi chỉ số sức khỏe 26

Bảng 8: Mô tả chỉ số sức khoẻ 26

Bảng 9: Thông tin của chức năng Cuộc gọi khẩn cấp SOS 28

Bảng 10: Mô tả luồng chính cho chức năng Cuộc gọi khẩn cấp SOS 29

Bảng 11: Thông tin của chức năng Nhật ký triệu chứng 30

Bảng 12: Mô tả luồng chính cho chức năng Nhật ký triệu chứng 31

Bảng 13: Thông tin của chức năng Theo dõi sức khoẻ người thân 31

Bảng 14: Mô tả luồng chính cho chức năng Theo dõi sức khoẻ người thân 32

Bảng 15: Kết quả sau khi thực hiện Manual testing 47

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

 CNTT: Công nghệ thông tin

 QA : Quality Assurance (Đảm bảo chất lượng)

 QC : Quality Control (Kiểm soát chất lượng)

 SDLC: Software Development Life Cycle (Vòng đời phát triển phần mềm)

 PO : Product Owner

 API : Application Programming Interface (Giao diện lập trình ứng dụng)

 N/A : No Answer (Không có câu trả lời)

 TCs : Test case

LỜI MỞ ĐẦU

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

Chăm sóc sức khoẻ đang trở thành một chủ đề quan trọng và được quan tâm ở cácquốc gia Với sự phát triển của công nghệ và ứng dụng di động, ứng dụng chăm sócsức khoẻ đã trở thành một lĩnh vực có tiềm năng phát triển rất lớn Việc nghiên cứu vàtriển khai manual testing trên ứng dụng VHealth cũng là một cơ hội để khám phá và

áp dụng các kỹ thuật, phương pháp kiểm thử phần mềm mới nhất và hiệu quả nhấttrong lĩnh vực chăm sóc sức khoẻ, giúp nâng cao trình độ chuyên môn và năng lựccủa các chuyên gia trong lĩnh vực này

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

Tìm hiểu và áp dụng các phương pháp và kỹ thuật kiểm thử phần mềm hiện đại,đảm bảo tính ổn định và an toàn cho sản phẩm, đồng thời cải tiến và tối ưu hóa quátrình kiểm thử phần mềm trên ứng dụng chăm sóc sức khoẻ VHealth Để từ đó tạo ramột sản phẩm chất lượng đến cho khách hàng

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

Nghiên cứu và triển khai các kỹ thuật kiểm thử thủ công trên ứng dụng chăm sócsức khoẻ VHealth giúp cải thiện tính năng, độ tin cậy và chất lượng của ứng dụng,đảm bảo ứng dụng hoạt động tốt và đáp ứng được nhu cầu của người dùng

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 Solutions Bình Định 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 TMA VÀ VỊ TRÍ TESTER 1.1 Giới thiệu tổng quát về công ty TMA Solutions Bình Định

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

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

TMA Solutions Bình Định là trung tâm phần mềm đầu tiên tại Thung lũng Sángtạo Quy Nhơn, Công viên Sáng tạo TMA mang sứ mệnh trở thành trung tâm pháttriển phần mềm và công nghệ cao hàng đầu tại miền Trung, góp phần quan trọng đưaThung lũng sáng tạo Quy Nhơn trở thành một điểm đến của công nghệ 4.0 tại ViệtNam Công viên Sáng tạo TMA bao gồm Trung tâm Phát triển Phần Mềm, XưởngPhần mềm, Trung tâm R&D, Trung tâm Khoa học Dữ liệu, Học viện Công Nghệ…với tổng diện tích sử dụng hơn 15,000m2 Dưới đây là mô tả tổng quan về lịch sửhình thành của Công ty TMA Solutions Bình Định:

 Năm 2017: TMA quyết định đầu tư xây dựng Công viên sáng tạo TMA Bình Định(TMA Innovation Park) tại Thung Lũng Sáng Tạo Quy Nhơn

- Thành lập Nhóm Data Science Group

- Tổ chức Ngày hội Công nghệ tại Đại học Quy Nhơn

Hình 2: Nhóm Data Science Group

 Năm 2020:

- Khai trương Công viên Sáng tạo TMA Bình Định

- Đạt 140 kỹ sư

- Khách hàng từ 6 nước (Mỹ, Úc, Pháp, Nhật Bản, Hàn Quốc, Singapore)

Hình 3: Công viên Sáng tạo TMA Bình Định

Qua các giai đoạn phát triển trên, TMA Bình Định đã xây dựng được một danhtiếng và thương hiệu đáng tin cậy trong lĩnh vực công nghệ thông tin và phần mềm.Với tầm nhìn và cam kết về chất lượng, công ty tiếp tục phát triển và đóng góp cho sựphát triển của ngành công nghệ thông tin Việt Nam

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

Tầm nhìn: Trở thành một trong những công ty hàng đầu về cung cấp giải pháp

phần mềm tại Việt Nam và trong khu vực

Sứ mệnh: Tôn trọng và mang đến cho khách hàng những sản phẩm, giải pháp

phần mềm tốt nhất với chi phí hợp lí nhất Đồng thời xây dựng mối quan hệ tin cậy,

uy tín, hợp tác cùng phát triển với các đối tác trong lĩnh vực công nghệ thông tin

1.1.3 Giá trị cốt lõi

Sự cam kết (Commitment): Biến lời hứa thành hiện thực

Sự trung thực (Honesty): Trung thực với người khác và chính mình

Sự Tôn trọng (Respect): Đối xử với người khác theo cách bạn muốn đối xử

1.1.4 Lĩnh vực hoạt động

 Tài chính, Ngân hàng & Bảo hiểm

Quản lý tài sản (Wealth management, asset management), Thị trường vốn (Capitalmarket), Quản lý vốn (Fund management), Quản lý đầu tư (Investment management),Phân tích tài chính (Financial analysis), Tài chính doanh nghiệp (Corporate finance),Quy trình bảo hiểm (Insurance process and workflow)

 Thương mại điện tử & Phân phối

Tư vấn, thiết kế, phát triển và triển khai hệ thống phần mềm trọn gói về thươngmại điện tử, Quản lý phân phối sản phẩm, Phân tích hành vi khách hàng, Dự báodoanh số, POS (Point of Sale)

 Sức khoẻ / Y tế

Phân tích thông tin bệnh nhân và sử dụng thuốc, Hệ thống thông tin y tế, Quản lývà phân tích dịch bệnh, Hồ sơ y tế điện tử, Hỗ trợ chuẩn đoán lâm sàng, Theo dõi sứckhỏe người già 24/24, Quản lý người cách ly tại nhà, Phần mềm nhà thuốc

 Giáo dục

Thư viện điện tử, Sách điện tử, Phân tích hành vi học online, Phân tích năng lựchọc sinh, Quản lý và điểm danh tự động, Quản lý trường học

 Nông nghiệp & Chế biến thực phẩm

Phân tích và tối ưu năng suất chăn nuôi bò, Quản lý quy trình trồng trọt, Hệ thốngthông tin nông nghiệp, Truy xuất nguồn gốc sản phẩm nông nghiệp, Tối ưu hiệu suấtmáy móc chế biến thực phẩm, Nhận dạng bệnh, Đánh giá chất lượng gỗ tự động

 Vận tải & Logistic

Quản lý giao nhận, Quản lý tài sản, Quản lý xe và tàu biển, Phân tích giao thông

Nhiệm vụ của một Tester:

- Tìm kiếm các lỗi của hệ thống phần mềm

- Trực tiếp thẩm định, xác minh xem hệ thống phần mềm này có đáp ứng các yêucầu kỹ thuật và yêu cầu nghiệp vụ hay không

- Hoàn thiện sản phẩm nhằm đáp ứng tối đa những yêu cầu đặt ra của khách hàngcả về mặt số lượng lẫn chất lượng

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

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

Đây là kỹ năng mà hầu hết người đi làm cần trang bị cho bản thân Một Tester có

kỹ năng phân tích sẽ giúp bạn có thể chia nhỏ một hệ thống phần mềm phức tạp thành

các đơn vị nhỏ hơn để hiểu rõ hơn về từng yếu tố riêng lẻ, điều đó sẽ giúp ban nângcao cả hiệu quả lẫn hiệu suất công việc để đạt kết quả tối đa.

 Kỹ năng học hỏi

Một Tester giỏi là người biết sẵn sàng chuyển đổi, học hỏi nhanh Các vấn đề cóthể đột ngột phát sinh trong quá trình chạy phần mềm Chính vì vậy các Tester sẽthường xuyên phải tự phân tích, học hỏi thông qua các hội nhóm hoặc đồng nghiệp củamình

 Kỹ năng giao tiếp

Kỹ năng giao tiếp hay còn được gọi là kỹ năng giải quyết mâu thuẫn Một Testerkhông thể làm việc độc lập mà thường phải làm việc nhóm hoặc trong các dự án hợptác Chính vì thế kỹ năng giao tiếp tốt sẽ giúp ích cho bạn rất nhiều khi bạn chuyển tiếpthông tin và cung cấp báo cáo về các khâu kiểm tra bạn đã làm Nếu bạn không giỏi kỹnăng giao tiếp thì sẽ rất khó truyền đạt cho người khác hiểu ý tưởng mà bạn đang theođuổi

 Kỹ năng làm việc nhóm

Kỹ năng làm việc nhóm sẽ giúp các Tester dễ dàng kết nối với các thành viên khác,nhất là Developer Công việc của một Tester có thể hiểu là cầu nối giữa nhà phát triểnphần mềm và người sử dụng phần mềm, trong đó, Developer đảm nhiệm hoàn thiệnphần mềm và Tester sẽ giúp khách hàng an tâm hơn về sản phẩm

Ngoài những kỹ năng chính trên một Tester còn cần phải có kỹ năng thiết kế, có kĩnăng tiếng Anh và có tính cách cẩn thận, tỉ mỉ, nhạy bén

1.2.3 Cơ hội nghề nghiệp

Từ một nghề còn khá xa lạ đối với các bạn trẻ, Tester đang dần trở thành một nghề

"HOT" tại Việt Nam với nhu cầu tuyển dụng ngày càng tăng cao Đây cũng được coilà một nghề nghiệp ổn định, đặc biệt là có cơ hội thăng tiến rõ ràng dựa vào năng lựcvà thâm niên

Nghề Tester có nhu cầu tuyển dụng cao, cơ hội ổn định sự nghiệp lâu dài Đặc biệt

không hề nhàm chán mới công nghệ luôn đổi mới Mỗi ngày các Tester sẽ phải làmviệc với những phần mềm khác nhau, mang đến nhiều sự thú vị Nghề Tester quantrọng nhất là kinh nghiệm được tích lũy nhiều năm hơn là tuổi trẻ Càng có nhiều kinhnghiệm thì hiệu quả công việc càng cao và chất lượng phần mềm được kiểm thử càngtốt Nhu cầu tuyển dụng Tester trong những năm gần đây liên tục tăng Nếu khả năngTiếng Anh tốt thì cơ hội để có những việc làm hấp dẫn càng lớn Không chỉ được làmviệc tại các doanh nghiệp công nghệ, bạn còn có cơ hội được làm tại các công ty nướcngoài.

Không chỉ có cơ hội việc làm cực kỳ hấp dẫn mà mức lương cho các vị trí Tester hiện nay cũng được đánh giá là khá cao so với thị trường Ở từng vị trí thu nhập của Tester sẽ khác nhau:

Intern Tester

Intern Tester hoặc Test thực tập thường rơi vào trường hợp các bạn sinh viên mới

ra trường và hầu như chưa từng có kinh nghiệm chuyên môn ở vi trí Tester, vì vậymức lương của Intern Tester thường dao động trong khoảng 3-6 triệu đồng/tháng

Fresh Tester

Khi bạn đã có một số kinh nghiệm nhất định ở vị trí Fresher và được nhận chínhthức sau khi kết thúc thời gian thử việc, bạn sẽ nhận được mức lương dao động trongkhoảng 6-8 triệu đồng/tháng

Junior Tester

Junior Tester là những người đã có kinh nghiệm nhất định và trải qua nhiều dự ánthực tế trong cương vị là một Tester, họ không chỉ hoàn thành nhiệm vụ mà còn cókhả năng sáng tạo và luôn tìm cách cải tiến hiệu quả và hiệu suất công việc JuniorTester sẽ nhận được mức lương trong khoảng 8-15 triệu đồng/tháng

Senior Tester

Senior Tester không chỉ giỏi về chuyên môn mà còn có khả năng quản lý độinhóm, phân chia công việc cho các thành viên, dẫn dắt họ nhằm đạt được những kết

quả xa hơn trong công việc và xây dựng con đường sự nghiệp vững vàng SeniorTester nhận mức lương dao động trong khoảng 20-22 triệu đồng/tháng.

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à quá trình thực thi 1 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, yêu cầu của sản phẩm đề đã đặt ra

2.1.2 Mục tiêu của kiểm thử

Mục đích của kiểm thử phần mềm là xác định các lỗi, lỗ hổng hoặc các yêu cầucòn thiếu so với yêu cầu thực tế

2.1.3 Quy trình phát triển phần mềm

Hình 4: Quy trình phát triển phần mềm

Quy trình phát triển phần mềm tuân thủ theo các bước quan trọng cần thiết cho cácnhà phát triển như phân tích yêu cầu và tài liệu đặc tả, phân tích và thiết kế hệ thống,thực hiện coding và unit test, kiểm thử và cuối cùng là cài đặt và bảo trì

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

Hình 5: Nguyên tắc của kiểm thử phần mềm

 Kiểm thử cho thấy sự hiện diện của lỗi

Kiểm thử phần mềm chỉ có thể chứng minh được phần mềm có lỗi nhưng khôngthể chứng minh được phần mềm đó không còn lỗi Kiểm thử phần mềm giúp giảm xácsuất lỗi chưa tìm thấy trong phần mềm

 Không thể kiểm thử cạn kiệt

Kiểm thử toàn bộ mọi thứ bao gồm cả điều kiện đầu vào và tiền điều kiện là khôngkhả thi cho các trường hợp có rất nhiều giá trị đầu vào và hệ thống phức tạp

 Thử nghiệm sớm

Kiểm thử nên được bắt đầu càng sớm càng tốt trong vòng đời phát triển phầnmềm Lỗi càng được tìm ra sớm thì càng tiết kiệm được thời gian và chi phí fix lỗi

 Phân cụm lỗi

Lỗi thường tập trung ở các chức năng chính có liên quan nhiều đến các chức năngkhác trong hệ thống Thông thường thì ta sẽ tìm được 80% lỗi của hệ thống trong 20%chức năng chính của hệ thống

 Nghịch lý thuốc trừ sâu

Nếu cùng một bộ test case đó ta test đi test lại nhiều lần sẽ bị nhờn và sẽ khôngtìm ra được bug mới

 Kiểm thử phụ thuộc vào ngữ cảnh

Kiểm thử là khác nhau trong các ngữ cảnh khác nhau

 Không có lỗi là sai lầm

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 đã sẵnsàng tung ra thị trường mà bộ test case đó tạo ra chỉ nhằm mục đích kiểm tra xem hệthống hoạt động có đúng với yêu cầu hay không chứ không nhằm mục đích tìm lỗimới

2.1.5 Phân biệt Error/ Fault/ Failure

Error: Là hành động của con người dẫn đến kết quả sai.

Fault: Lỗi xảy ra khi làm sai các step, process, hoặc chuẩn bị dữ liệu.

Failure: Lỗi khi có kết quả sai lệch so với yêu cầu đặc tả, là sự khác biệt giữa kết

quả thực tế trên màn hình và kết quả mong đợi của một thành phần, hệ thống hoặcservice nào đó

2.1.6 Phân biệt Verification & Validation

 Verification (xác minh):

- Xác minh xem việc thực thi sản phẩm (product) đúng theo yêu cầu đã được chỉđịnh hay chưa?

- Trả lời cho câu hỏi: "Did we build the system right?"

- Ví dụ: xác nhận theo SRS, design thực hiện ở giai đoạn code review trong team,unit test, integration and system test

 Validation (xác nhận):

- Xác nhận, kiểm tra xem chức năng (function) cần thiết và mong đợi của kháchhàng đã có trong sản phẩm hiện tại hay chưa?

- Trả lời cho câu hỏi: "Did we build the right system, appropriate, fix for use?"

- Ví dụ: xác nhận theo SRS, Requirement prototype xác nhận theo SRS review bởicustomer, acceptance test, beta test, hỗ trợ

2.1.7 Phân biệt QA & QC

Hình 6: QA & QC

a QA (Quality Assurance)

Là người chịu trách nhiệm đảm bảo chất lượng sản phẩm thông qua việc đưa raquy trình làm việc cho các bên liên quan

b QC (Quality Control)

Là kỹ sư quản lý chất lượng Đây là những người trực tiếp làm kiểm tra cho cácsản phẩm thực tế từng công đoạn của sản xuất

Bảng 1: So sánh QA và QC

Đảm bảo chất lượng (QA) Kiểm soát chất lượng (QC)

Là một quy trình được cân nhắc thận

trọng nhằm cung cấp sự đảm bảo rằng

phần mềm sẽ vượt qua được những yêu

cầu về chất lượng

Kiểm soát chất lượng là quy trình kiểmtra sự hoàn thành của các yêu cầu vềchất lượng phần mềm

Mục tiêu của QA là ngăn ngừa khiếm

Tất cả các thành viên trong nhóm có

trách nhiệm đảm bảo chất lượng

Testing team chịu trách nhiệm cho QC

Verification (xác minh) Validation (xác nhận)

QA đảm bảo rằng bạn đang làm đúng

điều phải làm

QC đảm bảo kết quả của những gì bạn

đã làm là những gì bạn mong đợi

2.2 Vòng đời phát triển phần mềm

2.2.1 Giai đoạn phát triển phần mềm

a Pha yêu cầu

Ở pha này bộ phận phân tích yêu cầu sẽ gặp gỡ, trao đổi với khách hàng và làm rõcác chức năng, các yêu cầu mà khách hàng muốn xây dựng trong phần mềm củamình

b Pha đặc tả

Đây là pha sẽ được thực hiện sau khi đã ghi nhận các yêu cầu của khách hàng vềbộ liệu SRS gọi là “Tài liệu đặc tả”

c Pha thiết kế

Ở pha này sau khi căn cứ vào tài liệu đặc tả, bộ phận thiết kế sẽ thiết kế đưa ragiao diện chung cũng như bộ phận lập trình sẽ thiết kế giao diện mức chi tiết theotừng chức năng của phần mềm.

d Pha lập trình

Ở pha này các lập trình viên (developer) sẽ lập trình xử lý chức năng, module theoyêu cầu được giao sau đó sẽ chuyển cho kiểm thử viên thực hiện kiểm tra các chứcnăng theo testcase được xây dựng dựa trên tài liệu đặc tả

e Pha kiểm thử

Ở pha này, kiểm thử viên sẽ thực hiện kiểm tra các chức năng này theo cáctestcase được xây dựng Trong quá trình kiểm thử theo testcase nếu có phát sinh lỗi,kiểm thử viên sẽ thực hiện báo bug lỗi để lập trình viên xử lý chức năng đó fix lỗi

f Pha triển khai bảo trì

Trong quá trình sử dụng phần mềm của khách hàng, công ty phát triển phần mềm

sẽ phải hỗ trợ, xử lý lỗi nếu có phát sinh trong quá trình sử dụng

2.2.2 Mô hình Water Fall

Trong mô hình thác nước, mỗi giai đoạn phải được hoàn thành trước khi giai đoạntiếp theo có thể bắt đầu và không có sự chồng chéo trong các giai đoạn

Hình 7: Mô hình Water Fall

Thu thập và phân tích yêu cầu: Tất cả các yêu cầu có thể có của hệ thống được phát

triển đều được ghi lại trong giai đoạn này và được ghi lại trong tài liệu đặc tả yêu cầu

Thiết kế hệ thống: Các đặc điểm kỹ thuật yêu cầu từ giai đoạn đầu tiên được nghiên

cứu trong giai đoạn này và thiết kế hệ thống được chuẩn bị

Implement: Với đầu vào từ thiết kế hệ thống, hệ thống được phát triển đầu tiên trong

các chương trình nhỏ gọi là đơn vị, được tích hợp trong giai đoạn tiếp theo Mỗi đơn

vị được phát triển và kiểm tra chức năng của nó, được gọi là kiểm thử đơn vị

Tích hợp và Kiểm thử: Tất cả các đơn vị được phát triển trong giai đoạn triển khai

đều được tích hợp vào một hệ thống sau khi kiểm tra từng đơn vị

Triển khai hệ thống: Sau khi thử nghiệm chức năng và phi chức năng được thực

hiện; sản phẩm được triển khai trong môi trường khách hàng hoặc tung ra thị trường

Bảo trì: Có một số vấn đề xảy ra trong môi trường khách hàng Để khắc phục những

vấn đề đó, các bản vá lỗi sẽ được phát hành

2.2.3 Mô hình V Model

Mô hình chữ V là một mô hình SDLC trong đó việc thực thi các quy trình diễn ratuần tự theo hình chữ V Mô hình V là một phần mở rộng của mô hình thác nước vàdựa trên sự liên kết của giai đoạn thử nghiệm cho từng giai đoạn phát triển tương ứng

Hình 8: Mô hình V Model

 V-Model - Giai đoạn Verification

Phân tích yêu cầu: Giai đoạn này liên quan đến việc trao đổi chi tiết với khách hàng

để hiểu những mong đợi và yêu cầu chính xác của họ

Thiết kế hệ thống: Thiết kế hệ thống sẽ có sự hiểu biết và chi tiết hóa thiết lập phần

cứng và giao tiếp hoàn chỉnh cho sản phẩm

Thiết kế kiến trúc: Thông số kỹ thuật kiến trúc được hiểu và thiết kế trong giai đoạn

này Thiết kế hệ thống được chia nhỏ hơn thành các mô-đun có chức năng khác nhau

đun hệ thống được chỉ định Điều quan trọng là thiết kế phải tương thích với các đun khác trong kiến trúc hệ thống và các hệ thống bên ngoài đơn vị

mô-Giai đoạn coding: Việc coding thực tế của các mô-đun hệ thống được thiết kế trong

giai đoạn thiết kế được thực hiện trong giai đoạn coding Code trải qua nhiều lầnreview code trước khi bản dựng cuối cùng được đưa vào kho lưu trữ

 V-Model - Giai đoạn Validation

Unit Testing: Kiểm thử đơn vị được thiết kế trong giai đoạn thiết kế mô-đun được

thực thi trên code trong giai đoạn xác thực này

Integration Testing: Kiểm thử tích hợp được liên kết với giai đoạn thiết kế kiến trúc System Testing: Kiểm thử hệ thống kiểm tra toàn bộ chức năng của hệ thống và giao

tiếp của hệ thống đang được phát triển với các hệ thống bên ngoài

Acceptance Testing: Kiểm thử chấp nhận được liên kết với giai đoạn phân tích yêu

cầu kinh doanh và liên quan đến việc kiểm tra sản phẩm trong môi trường người dùng

2.2.4 Mô hình Agile

Hình 9: Mô hình Agile

Phương pháp Agile có nghĩa là một phương pháp thúc đẩy quá trình phát triển vàthử nghiệm lặp đi lặp lại liên tục trong suốt vòng đời phát triển phần mềm của dự án.Trong mô hình Agile trong kiểm thử phần mềm, cả hoạt động phát triển và kiểm thửđều diễn ra đồng thời

2.2.5 Phương pháp Scrum

Hình 10: Phương pháp Scrum

Bước đầu tiên là PO tạo một danh sách công việc phải làm Sau đó PO chọn cácmục ưu tiên hàng đầu và cố gắng hoàn thành chúng trong 1 khoảng thời gian gọi làsprint.

Đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint Kếtquả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các côngviệc cần làm trong suốt một Sprint

Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiệncông việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như cácvướng mắc trong quá trình làm việc cùng nhau (Hôm qua làm gì? Hôm nay làm gì?Có issue gì không?)

Cuối sprint nhóm phát triển cũng với product owner sẽ rà soát lại các công việc đãhoàn tất trong sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sảnphẩm

Sprint Retrospective (họp cải tiến sprint): dưới sự trợ giúp của scrum master nhómphát triển sẽ rà soát lại toàn diện sprint vừa kết thúc và tìm cách cải tiến quy trình làmviệc cũng như bản thân sản phẩm

Mỗi Sprint có thời gian thống nhất, thường là 1 hoặc 2 tuần và thường không quá

4 tuần Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong ProductBacklog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căncứ tình hình thực tế

Cuối các phân đoạn, nhóm phát triển thường cho ra các phần nhỏ của sản phẩmcuối cùng Các phần nhỏ này thường là đầy đủ, có khả năng chạy tốt, được kiểm thửcẩn thận và có thể sử dụng ngay (gọi là potentially shippable product increment offunctionality) Theo thời gian, phân đoạn này tiếp nối phân đoạn kia, các phần chạyđược này sẽ được tích lũy, lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàngđược thỏa mãn

2.2.6 Phương pháp Kanban

Kanban là một hệ thống quản lý công việc giúp lập kế hoạch sản xuất tinh gọn.Cách tiếp cận này nhằm mục đích quản lý công việc bằng cách cân bằng nhu cầu côngviệc với năng lực hiện có và cải thiện việc xử lý vấn đề thắt cổ chai ở cấp hệ thống.

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

2.3.1 Manual Testing

Kiểm thử thủ công là một loại kiểm thử phần mềm trong đó người kiểm tra thựchiện chạy test case một cách thủ công mà không dùng bất cứ một công cụ tự độngnào Bất kì ứng dụng nào cũng đều phải được kiểm tra một cách thủ công trước khi cóthể thực hiện test tự động

2.3.2 Automation Testing

Kiểm thử tự động là một quá trình xử lý tự động các bước thực hiện một test case.Kiểm thử tự động được thực hiện bởi phần mềm kiểm thử tự động - hay còn gọi làAutomation Testing Tool

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

2.4.1 Static Testing

Hình 11: Phương pháp kiểm thử Static Testing

Thử nghiệm tĩnh là loại kiểm tra trong thực đó code không được hiện Được thựchiện bằng tay hoặc bằng một công cụ Với thử nghiệm tĩnh, chúng ta cố gắng tìm ralỗi, các lỗi code và mã độc tiềm ẩn trong ứng dụng phần mềm Static test bắt đầu sớmhơn trong vòng đời phát triển được gọi là thử nghiệm xác minh (verification testing)

2.4.2 Dynamic Testing

Thử nghiệm động được thực hiện khi code đang ở chế độ thực thi Thử nghiệmđộng được thực hiện trong môi trường thực thi chạy chương trình ứng dụng Thử

nghiệm dynamic còn được gọi là thử nghiệm xác nhận (Validation testing), đánh giásản phẩm

Thử nghiệm động gồm hai loại: Kiểm tra chức năng và Kiểm tra phi chức năng

2.4.3 White Box Testing

Kiểm thử hộp trắng (While box test) là phương pháp thử nghiệm phần mềm, trongđó các thiết kế, cấu trúc giải thuật bên trong, và việc thực hiện các công việc đều đượcbiết đến

Hình 12: White Box Testing

2.4.4 Black Box Testing

Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm màviệc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nộibộ hoặc hoạt động của nó

Hình 13: Black Box Testing

2.4.5 Gray Box Testing

Gray Box Testing là một phương pháp kiểm thử phần mềm được kết hợp giữaPhương pháp Kiểm thử Black Box (hộp đen) và White Box (hộp trắng) Trong Kiểmthử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần

Hình 14: Gray Box Testing

2.5.2 Integration Testing

Kiểm thử tích hợp là loại kiểm thử trong đó các module phần mềm hay từng chứcnăng riêng lẻ được tích hợp logic và được kiểm tra theo nhóm Mỗi dự án phần mềmgồm nhiều modules, được code bởi nhiều người khác nhau, vì vậy kiểm thử tích hợptập trung vào việc kiểm tra truyền dữ liệu giữa các module

Alpha test: Được thực hiện bởi các thành viên của tổ chức phát triển phần mềm

nhưng không liên quan trực tiếp đến dự án (Thường là các thành viên của quản lý sảnphẩm) Alpha test thực hiện test tại nơi sản xuất phần mềm, là một hình thức kiểm thửnội bộ, trước khi phần mềm được tiến hành kiểm thử Beta

Beta test: Được thực hiện bởi người dùng cuối cùng (thường là khách hàng) Beta

test thực hiện tại địa điểm của khách hàng, người dùng test hay sử dụng hệ thốngtrong môi trường riêng của họ - không phải nơi phát triển phần mềm

2.6 Kỹ thuật thiết kế Test case và vòng đời bug

2.6.1 Kỹ thuật Specification-based

Nhóm kỹ thuật specification-based chỉ tập trung kiểm thử những yếu tố bên ngoàicủa hạng mục kiểm thử Chúng có thể là các đặc điểm kỹ thuật, thiết kế, cách vậnhành bên ngoài,… Nhờ đó, tester có thể test chất lượng bên ngoài mà không làm hỏngcấu trúc bên trong phần mềm

2.6.2 Kỹ thuật Experience-based

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ếnthức, kinh nghiệm của tester sẽ là cơ sở để thiết kế test case Do đó, chất lượng củacác test case dựa trên kinh nghiệm sẽ hoàn toàn phụ thuộc vào tester

2.6.3 Giải thích vòng đời bug

Hình 16: Vòng đời bug

- Tester tìm thấy bug/defect

- Gán trạng thái cho bug: New/Mới

- Chuyển bug sang cho Quản lý dự án để phân tích

- Quản lý dự án quyết định xem bug có hợp lệ không

- Nếu như lỗi không hợp lệ, trạng thái sẽ được chuyển thành "Rejected/Đã từ chối."

- Nếu lỗi không bị rejected thì bước tiếp theo là kiểm tra xem nó có nằm trong phạm

vi không Giả sử chúng ta có một chức năng khác - chức năng email cho cùng mộtứng dụng và bạn thấy có vấn đề với điều đó Nhưng nó không nằm trong scope củalần phát hành ứng dụng lần này, trạng thái của bug đó có thể chuyển thành

- Khi code được fixed Bug sẽ được gán trạng thái là “Fixed/đã sửa xong”

- Tiếp theo, tester sẽ test lại phần code vừa được sửa Nếu như các phần test casesliên quan đều passed thì bug đó được đóng lại hay được chuyển trạng thái thành

“Closed” Nếu các trường hợp kiểm thử thất bại một lần nữa, lỗi được mở opened và lại được chuyển giao sang cho dev.

lại/re-2.6.4 Báo cáo bug trên Jira

- Jira là một ứng dụng theo dõi và quản lý lỗi / vấn đề trong dự án, được phát triểnbởi công ty phần mềm Atlassian của Australia Cách thức hoạt động của JIRA dựavào trọng tâm là kết quả công việc, có thể sử dụng ngay và linh hoạt

- Báo cáo lỗi Jira tóm tắt các lỗi hoặc lỗi được báo cáo theo các số liệu nhất định

- Tính năng cơ bản của Jira:

+ Quản lý, theo dõi tiến độ của dự án

+ Quản lý các tasks, bugs, cải tiến, tính năng mới hoặc bất kỳ vấn đề gì xảy ra+ Tạo ra và lưu lại những bộ lọc có cấu hình cao (dynamic queries) xuyên suốtmọi vấn đề trong hệ thống; chia sẻ bộ lọc với người sử dụng khác, hoặc đăng ký vànhận được các kết quả qua hệ thống thư điện tử định kỳ

+ Xây dựng quy trình làm việc tương thích với yêu cầu của từng dự án

+ Bảng dashboard cung cấp cho mỗi người dùng một không gian riêng để xemmọi thông tin liên quan đến cá nhân

+ Cung cấp nhiều loại báo cáo thống kê với nhiều loại biểu đồ khác nhau phù hợpvới nhiều loại hình dự án và đối tượng người dùng

2.6.5 Test case là gì?

Test cases là một tài liệu bao gồm một tập hợp các điều kiện hoặc hành động đượcthực hiện trên ứng dụng phần mềm và xác định kết quả mong muốn của nó Ở đâychúng ta thực hiện mô tả tài liệu với dữ liệu test, điều kiện tiên quyết và kết quả mongđợi

2.6.6 Các loại kiểm thử ứng dụng Mobile

 Kiểm thử gián đoạn (Interrupt Testing)

Kiểm thử gián đoạn là một quá trình kiểm thử một ứng dụng điện thoại di động màcác chức năng có thể bị gián đoạn trong khi sử dụng các ứng dụng