Kiểm thử thủ công trên hệ thống quản lý thực tập sinh – internship management system (ims)

Mu ̣c tiêu của đề tài  Nghiên cứu quá trình thực thi kiểm thử trên hệ thống quản lý thực tập sinh – Internship Management System IMS  Sau khi thực tập 10 tuần tại công ty, có thể thực

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

KIỂM THỬ THỦ CÔNG TRÊN HỆ THỐNG QUẢN LÝ THỰC TẬP SINH – INTERNSHIP MANAGEMENT SYSTEM (IMS)

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

Giảng viên hướng dẫn : ThS Nguyễn Văn Chức

LỜI CẢM ƠN

Báo cáo thực tập nghề nghiệp chuyên ngành Quản trị hệ thống thông tin với đề tài

“Kiểm thử thủ công trên hệ thống quản lý thực tập sinh – Internship Management System (IMS)” là cố gắng không ngừng của bản thân em cùng với sự giúp đỡ của thầy cô, các anh chị Mentor

Trước hết, em xin gửi lời cảm ơn đến thầy Nguyễn Văn Chức – Giáo viên hướng dẫn trực tiếp của em, đã tận tình giúp đỡ em trong suốt thời gian thực tập hè vừa qua Em cũng xin chân thành cảm ơn anh Mai Phi Hùng – Mentor hướng dẫn đã chỉ bảo em trong nghiệp vụ của kiểm thử viên, chia sẻ cho em các kinh nghiệm và hướng dẫn em đi đúng công việc mà một kiểm thử viên cần làm, giúp em hoàn thành đề tài này tốt hơn

Một lần nữa em xin cảm ơn tất cả mọi người đã giúp đỡ em trong quá trình thực hiện đề tài này

LỜI CAM ĐOAN

Em xin cam đoan báo cáo “Kiểm thử thủ công trên hệ thống quản lý thực tập sinh – Internship Management System (IMS)” là kết quả nghiên cứu độc lập của em trong thời gian thực tập tại công ty TMA Solutions Bình Định cùng sự hướng dẫn tận tình của giáo viên hướng dẫn Nguyễn Văn Chức

Nội dung dự án là trung thực, ngoài một số định nghĩa ở phần lý thuyết thì tất cả hoàn toàn được thực hiện trên cơ sở khóa học của công ty TMA Solutions Bình Định, không sao chép bất kỳ nguồn nào khác Nếu có bất kỳ hành vi sao chép nào hoặc vấn đề xảy ra em xin được chịu hoàn toàn 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 v

DANH MỤC HÌNH ẢNH ix

DANH MỤC BẢNG BIỂU x

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

LỜI MỞ ĐẦU 1

1 Mu ̣c tiêu của đề tài 1

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

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

CHƯƠNG 1 GIỚI THIỆU CÔNG TY VÀ VỊ TRÍ VIỆC LÀM 2

1.1 Tổng quan về công ty TMA Solutions Bình Định 2

1.1.1 Thông tin về công ty 2

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í việc làm 3

1.2.1 Tìm hiểu thông tin về công việc thực tập - Tester 3

1.2.2 Yêu cầu về kiến thức và kĩ năng 3

1.2.3 Mức lương 4

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

CHƯƠNG 2 TỔNG QUAN VỀ CƠ SỞ LÝ THUYẾT 5

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

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

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

2.1.3 Quy trình kiểm thử 5

2.1.4 Bảy nguyên tắc của kiểm thử 6

2.1.5 Sự khác nhau giữa Error / Fault / Failure 7

2.1.6 Phân biệt giữa QA và QC 7

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

2.2.1 Khái niệm 8

2.2.2 Mô hình Scrum 9

2.3 Kiểu và phương pháp trong kiểm thử phần mềm 10

2.3.1 Kiểu kiểm thử 10

2.3.2 Phương pháp kiểm thử 11

2.3.3 Cấp độ trong kiểm thử 11

2.4 Test case 13

2.4.1 Khái niệm Test case 13

2.4.2 Thông số điển hình của test case 13

2.4.3 Các loại kỹ thuật thiết kế test case 14

2.5 Bug Life Cycle 15

CHƯƠNG 3 TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ TẬP SINH – INTERNSHIP MANAGEMENT SYSTEM (IMS) 17

3.1 Tổng quát về hệ thống 17

3.1.1 Mục đích 17

3.1.2 Chức năng của hệ thống 17

3.2 Đặc tả yêu cầu 17

3.3 Đặc tả giao diện phần mềm 18

3.3.1 Giao diện màn hình “QUẢN LÝ KHÓA THỰC TẬP” 18

3.3.2 Giao diện màn hình “QUẢN LÝ NHÓM” 21

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

4.1.1 Môi trường kiểm thử 27

4.1.2 Dữ liệu kiểm thử 27

4.1.3 Trạng thái của test case 27

4.2 Thiết kế test case 28

4.2.1 Các bước để tạo test case 28

4.2.2 Cấu trúc của một test case 28

4.2.3 Test case cho chức năng “Sửa khóa thực tập” 28

4.2.4 Test case cho chức năng “Thêm nhóm thực tập” 29

4.2.5 Test case cho chức năng “Sửa nhóm thực tập” 30

4.3 Tổng kết 31

4.3.1 Kết quả kiểm thử chức năng “Sửa khóa thực tập” 31

4.3.2 Kết quả kiểm thử chức năng “Thêm nhóm thực tập” 31

4.3.3 Kết quả kiểm thử chức năng “Sửa nhóm thực tập” 31

4.3.4 Report Bug trên Trello 31

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

TÀI LIỆU THAM KHẢO 35

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

DANH MỤC HÌNH ẢNH

Hình 2.1 Bảy nguyên tắc của kiểm thử 6

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

Hình 2.3 Mô hình SCRUM 9

Hình 2.4 Các cấp độ kiểm thử 11

Hình 2.5 Bug Life Cycle 16

Hình 3.1 Giao diện màn hình “CHỌN KHÓA THỰC TẬP”……… 18

Hình 3.2 Giao diện màn hình chọn “Quản lý khóa thực tập” 19

Hình 3.3 Giao diện màn hình “QUẢN LÝ KHÓA THỰC TẬP” 19

Hình 3.4 Giao diện màn hình chọn “Quản lý nhóm” 22

Hình 3.5 Giao diện màn hình “QUẢN LÝ NHÓM” 22

Hình 4.1 Giao diện khi truy cập vào hệ thống IMS……… 27

Hình 4.2 Chức năng “Sửa khóa thực tập” 29

Hình 4.3 Test case cho chức năng “Sửa khóa thực tập” 29

Hình 4.4 Chức năng “Thêm nhóm thực tập” 29

Hình 4.5 Test case cho chức năng “Thêm nhóm thực tập” 30

Hình 4.6 Chức năng “Sửa nhóm thực tập” 30

Hình 4.7 Test case cho chức năng “Sửa nhóm thực tập” 30

Hình 4.8 Report Bug của chức năng “Sửa khóa thực tập” 32

Hình 4.9 Report Bug của chức năng “Thêm nhóm thực tập” 33

Hình 4.10 Report Bug của chức năng “Sửa nhóm thực tập” 33

DANH MỤC BẢNG BIỂU

Bảng 2.1 Phân biệt giữa QA và QC 7

Bảng 3.1 Yêu cầu chức năng “QUẢN LÝ KHÓA THỰC TẬP”……… 17

Bảng 3.2 Yêu cầu chức năng “QUẢN LÝ NHÓM” 18

Bảng 3.3 Đặc tả yêu cầu cho tính năng “Sửa khóa thực tập” 21

Bảng 3.4 Đặc tả yêu cầu cho tính năng “Sửa nhóm thực tập” 24

Bảng 3.5 Đặc tả yêu cầu cho tính năng “Thêm nhóm thực tập” 26

Bảng 4.1 Tài khoản sử dụng……… 27

Bảng 4.2 Kết quả kiểm thử chức năng “Sửa khóa thực tập” 31

Bảng 4.3 Kết quả kiểm thử chức năng “Thêm nhóm thực tập” 31

Bảng 4.4 Kết quả kiểm thử chức năng “Sửa nhóm thực tập” 31

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

IMS : Internship management system

Tester : Chuyên viên kiểm thử

Tp HCM : Thành phố Hồ Chí Minh

R&D : Research and Development

UML : Unified Modeling Language

QA : Quality Assurance

QC : Quality Control

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

PO : Product Owner

LỜI MỞ ĐẦU

1 Mu ̣c tiêu của đề tài

 Nghiên cứu quá trình thực thi kiểm thử trên hệ thống quản lý thực tập sinh – Internship Management System (IMS)

 Sau khi thực tập 10 tuần tại công ty, có thể thực hành kiểm thử thủ công bao gồm việc viết các bộ test case và áp dụng để kiểm thử cho một chức năng của một website

và thu được kết quả cụ thể

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

 Đối tượng: Hệ thống quản lý thực tập sinh – Internship Management System (IMS)

 Phạm vi nghiên cứu: Các kiến thức cơ bản và tổng quan về kiểm thử phần mềm

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

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

 Mở đầu

 Chương 1: Giới thiệu công ty

 Chương 2: Tổng quan về cơ sở lý thuyết

 Chương 3: Tổng quan về hệ thống quản lý thực tập sinh – Internship Management

System (IMS)

 Chương 4: Thiết kế test case và tổng kết

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

CHƯƠNG 1 GIỚI THIỆU CÔNG TY VÀ VỊ TRÍ VIỆC LÀM

1.1 Tổng quan về công ty TMA Solutions Bình Định

1.1.1 Thông tin về công ty

Được thành lập năm 1997, TMA là tập đoàn công nghệ hàng đầu Việt Nam với

3500 kỹ sư và khách hàng là những tập đoàn công nghệ 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)

Tháng 6 năm 2018, TMA đã mở chi nhánh tại Bình Định Sau hơn 4 năm, TMA Bình Định đã phát triển nhanh chóng với hơn 400 kỹ sư Là trung tâm phần mềm đầu tiên tại Thung lũng sáng tạo Quy Nhơn, Công viên sáng tạo TMA mang sứ mệnh trở thành trung tâm phát triể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 đưa Thung 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ệt Nam Công viên sáng tạo TMA bao gồm Trung tâm phát triển Phần Mềm, Trung tâm R&D, trung tâm Khoa Học Dữ Liệu,…với tổng diện tích sử dụng hơn 15,000m2

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

Trong nhiều năm qua, mặc dù đối mặt với nhiều thách thức, nhưng TMA đã luôn chứng minh được khả năng làm việc, giữ vững cam kết cam kết chất lượng đối với khách hàng Để có được những thành công đó, TMA đã và đang duy trì phát triển những giá trị cốt lõi:

 Sự cam kết

 Sự trung thực

 Sự tôn trọng

1.2 Tổng quan về vị trí việc làm

1.2.1 Tìm hiểu thông tin về công việc thực tập - Tester

Tester (hoặc chuyên viên kiểm thử) là người chịu trách nhiệm kiểm tra phần mềm hoặc sản phẩm công nghệ để đảm bảo rằng nó hoạt động như mong đợi và đáp ứng được các yêu cầu chức năng và chất lượng Công việc của tester bao gồm việc tạo ra kế hoạch kiểm thử, thiết kế và thực hiện các kiểm thử, ghi nhận và báo cáo lỗi, đảm bảo rằng phần mềm hoạt động một cách ổn định và đáng tin cậy

Tester có vai trò quan trọng trong quá trình phát triển phần mềm, giúp phát hiện và khắc phục các lỗi và vấn đề có thể gặp phải trước khi phần mềm được triển khai hoặc đưa

ra thị trường Công việc của tester đòi hỏi kiến thức về quy trình kiểm thử, kỹ năng phân tích và sáng tạo, khả năng ghi nhận và báo cáo lỗi một cách chi tiết, và sự chú trọng đến chi tiết và chất lượng

Tester thường là thành viên của bộ phận kiểm thử phần mềm trong một tổ chức phát triển phần mềm, và có thể làm việc cùng với các nhóm lập trình viên, kỹ sư phần mềm và quản lý dự án để đảm bảo rằng phần mềm được kiểm thử một cách toàn diện và chất lượng

1.2.2 Yêu cầu về kiến thức và kĩ năng

Kiến thức về kiểm thử phần mềm: Cần phải hiểu về các phương pháp kiểm thử phần mềm, quy trình kiểm thử, và các tiêu chí đánh giá chất lượng phần mềm Bạn cần biết cách xác định yêu cầu kiểm thử, thực hiện kiểm thử, và báo cáo kết quả kiểm thử

Kiến thức về phân tích yêu cầu và thiết kế phần mềm: Hiểu về cách đọc, hiểu và phân tích tài liệu yêu cầu phần mềm để xác định các trường hợp kiểm thử Có khả năng đọc và hiểu các bản thiết kế phần mềm, bao gồm sơ đồ luồng dữ liệu, sơ đồ UML, sơ đồ cấu trúc dữ liệu, vv

Kiến thức về ngôn ngữ lập trình: Hiểu về ngôn ngữ lập trình phổ biến như Java, C3, Python, hoặc JavaScript Điều này giúp bạn có khả năng đọc và hiểu mã nguồn, tạo và thực thi các ca kiểm thử tự động

Kỹ năng ghi chép và báo cáo: có khả năng ghi chép chi tiết và quá trình kiểm thử, kết quả, và lỗi phát hiện lỗi được Biết cách tạo báo cáo kiểm thử chuyên nghiệp để trình bày kết quả cho các thành viên khác trong dự án

Kỹ năng xử lý lỗi: Có khả năng phân tích và đánh giá lỗi phát hiện được trong quá trình kiểm thử Hiểu về cách ghi lại lỗi một cách chi tiết và tái hiện lỗi để giúp các nhà phát triển sửa lỗi

Kỹ năng kiểm thử tự động: có kiến thức về các công cụ kiểm thử tự động Biết cách viết kịch bản kiểm thử tự động và chạy các bộ kiểm thử tự động để tăng tính tự động hóa

và hiệu suất kiểm thử

Kỹ năng giao tiếp và làm việc nhóm: có khả năng làm việc cùng nhóm phát triển phần mềm, giao tiếp hiệu quả với các thành viên khác trong dự án Có khả năng thuyết phục và trình bày ý kiến một cách rõ ràng

Sự kiên nhẫn và quan tâm đến chi tiết: Kiểm thử phần mềm đòi hỏi sự kiên nhẫn và quan tâm đến từng chi tiết nhỏ Bạn cần có khả năng kiểm tra một số lượng lớn các trường hợp kiểm thử, kiểm tra kỹ lưỡng tùng phần của phần mềm để đảm bảo tính ổn định và chất lượng của nó

1.2.3 Mức lương

Hiện nay, ở Việt Nam mức lương Tester dao động từ 7 – 22 triệu đồng/tháng Tuy nhiên, mức lương sẽ khá chênh lệch đối dựa vào kinh nghiệm làm việc và mức độ chuyên môn của mỗi người

 Intern Test: đối với sinh viên khi mới tốt nghiệp chưa có kinh nghiệm, mức lương khá thấp Trung bình thu nhập ở vị trí này sẽ dao động khoảng từ 3 – 6 triệu/tháng

 Fresh Tester: Về cơ bản họ đã nắm vững các kiến thức nhưng chưa có kinh nghiệm hay chuyên môn sâu Chính vì thế, Fresh Tester thu nhập khi mới ra trường dao động khoảng từ 6 – 8 triệu/tháng

 Junior Tester: đây là nhân viên đã có nhiều kinh nghiệm, kiến thức cũng như trình

độ chuyên môn tốt Junior Tester Vì thế, lương trung bình của vị trí này cao hơn 2 cấp bậc trên là khoảng 15 triệu/tháng

 Senior Tester: hay còn được gọi là người quản lý, lãnh đạo Họ là người có kinh nghiệm phong phú, hiểu biết sâu rộng về Tester Vì thế, thu nhập của Senior Tester thường rất cao, rơi vào khoảng từ 22 triệu

1.2.4 Cơ hội nghề nghiệp

Nghề tester hiện nay có rất nhiều vị trí phù hợp cho từng năng lực khác nhau Ở mỗi

vị trí cũng có những mức lương khác nhau Vì thế để đạt đến trình độ cao nhất cần phải trau dồi thêm kiến thức và kỹ năng Dưới đây là một số vị trí tester:

 Fresher QA: 1-3 năm kinh nghiệm

 Kỹ sư kiểm thử phần mềm: 3-5 năm kinh nghiệm

 Leader QA: 5-6 năm kinh nghiệm

 Quản lý: 8 – 11 năm kinh nghiệm

 Quản lý cấp cao: trên 14 năm kinh nghiệm

CHƯƠNG 2 TỔNG QUAN VỀ 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 xác định tính đúng đắn của phần mềm bằng cách xem xét tất cả các thuộc tính của nó (độ tin cậy, khả năng mở rộng, khả năng di động, khả năng sử dụng và khả năng tái sử dụng) và việc thực thi các thành phần phần mềm để tìm ra lỗi hoặc khiếm khuyết của phần mềm

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

Kiểm thử phần mềm là một phần tích hợp của vòng đời phát triển phần mềm Nếu không có điều này, ứng dụng không thể chuyển đến miền công cộng Hơn nữa, kiểm thử phần mềm xác nhận hoạt động của một ứng dụng theo đặc điểm kỹ thuật

2.1.3 Quy trình kiểm thử

 Quy trình phát triển phần: 4 hoạt động sau:

 Đặc tả phần mềm, kỹ thuật yêu cầu: xác định các chức năng chính của phần mềm

và các ràng buộc xung quanh nó

 Phát triển phần mềm: thiết kế và xây dựng phần mềm

 Xác minh và xác nhận: phần mềm được kiểm tra xem có đúng thông số kỹ thuật và đáp ứng nhu cầu của người dùng hay không

 Cập nhật phần mềm: phần mềm được cập nhật/ sửa đổi để đáp ứng các thay đổi theo yêu cầu của khách hàng

2.1.4 Bảy nguyên tắc của kiểm thử

Hình 2.1 Bảy nguyên tắc của kiểm thử

 Kiểm thử cho thấy sự tồn tại của lỗi: Kiểm thử chỉ có thể chứng minh được rằng

phần mềm có lỗi nhưng không có nghĩa là phần mềm không còn lỗi hay hết lỗi Chúng ta nên tập trung mở rộng thiết kế các trường hợp kiểm thử (test case) qua từng phiên bản phần mềm để có thể tìm được càng nhiều lỗi càng tốt

 Kiểm thử toàn bộ là không thể: Không thể kiểm tra hết toàn bộ tất cả các chức

năng của một phần mềm Thay vì kiểm thử toàn bộ, chúng ta có thể dựa vào phân tích rủi ro, độ ưu tiên, sử dụng kỹ thuật test để lựa chọn các test case phù hợp nhất

 Kiểm thử càng sớm càng tốt: Nguyên tắc này yêu cầu bắt đầu kiểm thử phần mềm

giai đoạn đầu của vòng đời phát triển phần mềm Các hoạt động kiểm thử phần mềm

ở giai đoạn đầu sẽ giúp phát hiện Bug sớm hơn Ngoài ra giúp tiết kiệm thời gian và chi phí cho giai đoạn tiếp theo

 Lỗi thường đi theo cụm: Kỹ thuật phân tách các ca kiểm thử thành các nhóm sao

cho các ca kiểm thử trong cùng một nhóm có khả năng phát hiện các lỗi giống nhau hoặc có cùng một nguyên nhân gây ra lỗi Mục tiêu là tối đa hóa hiệu quả kiểm thử bằng cách giảm số lượng ca kiểm thử cần thiết để phát hiện lỗi

 Nghịch lý thuốc trừ sâu: Một bộ test case được sử dụng lặp đi lặp lại sẽ không tìm

ra được các lỗi mới Vì các lỗi được tìm thấy đã được sửa trong giai đoạn trước, còn những lỗi khác thì chưa được tìm thấy Cho nên các bộ test case cần phải được xem xét cập nhật thường xuyên để giúp tìm ra lỗi mới

 Quan niệm sai lầm về việc hết lỗi: “Testing có thể được sử dụng để chứng minh

sự tồn tại của lỗi, nhưng không thể chứng minh tính đúng đắn hoàn toàn của phần mềm.”

 Kiểm thử phụ thuộc vào ngữ cảnh: Bằng cách phụ thuộc vào ngữ cảnh, các ca

kiểm thử có thể được thiết kế sao cho gần với thực tế nhất, giúp phát hiện lỗi một cách toàn diện hơn và đảm bảo rằng phần mềm hoạt động đúng đắn trong nhiều tình huống khác nhau

2.1.5 Sự khác nhau giữa Error / Fault / Failure

 Error: Là lỗi do nhà phát triển hiểu sai yêu cầu hoặc yêu cầu không được xác định chính xác

 Fault: Lỗi có thể xảy ra trong phần mềm vì nó chưa được thêm mã chịu lỗi, khiến ứng dụng hoạt động

 Failure: Nhiều khiếm khuyết làm cho hệ thống không phản hồi hoặc hỏng

2.1.6 Phân biê ̣t giữa QA và QC

Đảm bảo chất lượng là một tập hợp các

hoạt động có kế hoạch và có hệ thống cần

thiết để cung cấp các sản phẩm và dịch vụ

sẽ phù hợp với các yêu cầu cụ thể và đáp

ứng nhu cầu của người sử dụng

Đảm bảo chất lượng đảm bảo đang làm

những điều đúng đắn, đúng cách

QA tập trung vào việc xây dựng chất

lượng và do đó ngăn ngừa các khuyết tật

QA là cho toàn bộ SDLC

Kiểm soát chất lượng là quá trình mà chất lượng sản phẩm được so sánh với các tiêu chuẩn áp dụng và hành động được thực hiện khi phát hiện thấy sự không phù hợp Kiểm soát chất lượng đảm bảo kết quả của những gì chúng tôi đã làm là những

gì chúng tôi mong đợi

QC tập trung vào việc kiểm tra chất lượng

và do đó phát hiện ra các khuyết tật

QC dành cho phần kiểm tra trong SDLC

Bảng 2.1 Phân biệt giữa QA và QC

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

2.2.1 Khái niệm

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

Vòng đời phát triển phần mềm là một quy trình được ngành công nghiệp phần mềm

sử dụng để thiết kế, phát triển và kiểm tra phần mềm chất lượng cao SDLC nhằm mục đích sản xuất một phần mềm chất lượng cao đáp ứng hoặc vượt quá mong đợi của khách hàng, hoàn thành trong thời gian và chi phí ước tính

Có sáu giai đoạn trong vòng đời phát triển phần mềm:

 Giai đoạn 1: Requirement Gathering and Analysis - Trong giai đoạn này, khách

hàng nêu yêu cầu, thông số kỹ thuật và bất cứ yêu cầu đặc biệt nào khác liên quan đến sản phẩm Tất cả các yêu cầu này được thu thập bởi giám đốc kinh doanh hoặc giám đốc dự án hoặc nhà phân tích của công ty cung cấp dịch vụ

 Giai đoạn 2: Design - Giai đoạn mô tả bao gồm phân tích chi tiết phần mềm mới

theo giai đoạn yêu cầu Đây là giai đoạn ưu tiên cao trong vòng đời của mạng phát triển của một hệ thống vì thiết kế logic của hệ thống được chuyển đổi thành thiết kế vật lý

 Giai đoạn 3: Development - Trong giai đoạn này, công việc được chia thành các

đơn vị nhỏ và bắt đầu mã hóa bởi nhóm các nhà phát triển theo thiết kế đã thảo luận

ở giai đoạn trước và theo yêu cầu của khách hàng đã thảo luận trong giai đoạn yêu cầu để tạo ra kết quả mong muốn

 Giai đoạn 4: Testing - Kiểm thử là bước cuối cùng của quá trình hoàn thiện hệ

thực sự cung cấp kết quả theo yêu cầu được giải quyết cho giai đoạn yêu cầu hay không

 Giai đoạn 5: Deployment - Khi quá trình kiểm thử phần mềm được hoàn thành với

kết quả thỏa mãn và không có vấn đề gì còn tồn tại là phần mềm điều hành, nó sẽ được triển khai cho khách hàng sử dụng

 Giai đoạn 6: Maintenance - Giai đoạn bảo trì là giai đoạn cuối cùng và lâu dài của

vòng đời phát triển sản phẩm ví nó là quá trình tiếp tục diễn ra cho đến khi vòng đời của phần mềm kết thúc Trong giai đoạn này cũng bao gồm việc thực hiện các thay đổi trong phần cứng và phần mềm để duy trì hiệu quả hoạt động nhằm cải thiện hiệu suất của nó, nâng cá tính năng bảo mật và theo yêu cầu của khách hàng trong thời gian tới

2.2.2 Mô hình Scrum

Hình 2.3 Mô hình SCRUM

Scrum là framework phát triển dựa trên phương pháp Agile - mô hình linh hoạt, Scrum là một khung quản lý được các đội ngũ sử dụng để tự tổ chức và hoạt động vì một mục tiêu chung Khung này mô tả một loạt các cuộc họp, công cụ và vai trò để bàn giao dự

án hiệu quả

Một nhóm Scrum là nhóm tự quản, liên chức năng, các thành viên trong nhóm luôn

hỗ trợ và cùng nhau phát triển Nhóm Scrum được tạo ra để tối ưu hóa sự sáng tạo, linh hoạt và năng suất, hiệu quả Một Scrum team bao gồm các vị trí sau:

 Product Owner: Là người chịu trách nhiệm về sự thành công của dự án, người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm

PO phải là người có tầm nhìn, quyền hạn và sự sẵn sàng, chịu trách nhiệm truyền đạt tầm nhìn và các ưu tiên cho nhóm phát triển

 Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại Scrum Master hoạt động để loại bỏ bất kỳ trở ngại nào đang cản trở nhóm đạt được các mục tiêu chạy nước rút của mình

 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 Nhóm phát triển chịu trách nhiệm tự tổ chức để hoàn thành công việc

Các sự kiện trong SCRUM:

 Sprint: Một trong như sự kiện quan trọng nhất của Scrum là Sprint Một sprint kéo dài từ 2-4 tuần Đây là khoảng thời gian phát triển và phát hành sản phẩm

 Sprint Plan: Lên kế hoạch công việc, trả lời các câu hỏi làm sao và làm thế nào để gia tăng hiệu quả công việc trong sprint sắp tới

 Daily Scrum meeting: Là cuộc họp diễn ra khoảng 15 phút hằng ngày Trong cuộc họp ngắn này sẽ trả lời các câu hỏi tôi đã làm gì trong ngày hôm qua, tôi cần làm gì trong ngày hôm nay, tôi có đang gặp trở ngại gì không Mục tiêu của cuộc họp này

là giúp nâng cao năng suất và giải quyết khó khăn để đạt mục tiêu

 Sprint Review: Trong cuộc họp này sẽ trao đổi những gì đã hoàn thành trong sprint vừa qua, bàn về các việc phải làm trong sprint sắp tới Cuộc họp này sẽ có sự tham gia của các bên liên quan, giúp nâng cao sự tương tác và hiệu quả

 Sprint Retrospective: Là cuộc họp để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục cải tiến qua từng Sprint

2.3 Kiểu và phương pháp trong kiểm thử phần mềm

2.3.1 Kiểu kiểm thử

 Manual Testing

Manual Testing là việc thử nghiệm một phần mềm hoàn toàn bằng tay bởi người Tester Nó được thực hiện nhằm phát hiện lỗi trong phần mềm đang được phát triển Trong manual testing, Tester sẽ thực hiện các trường hợp kiểm thử và tạo báo cáo kiểm thử hoàn

2.3.2 Phương pháp kiểm thử

 Kiểm thử hộp đen (Black – box Testing)

Kỹ thuật kiểm tra mà không có bất kỳ kiến thức nào về hoạt động bên trong của ứng dụng được gọi là kiểm thử hộp đen

Người kiểm tra không biết gì về kiến trúc hệ thống và không có quyền truy cập vào

mã nguồn

 Kiểm thử hộp trắng (White – box Testing)

Kiểm thử hộp trắng là việc điều tra chi tiết về logic và cấu trúc bên trong của mã

Để thực hiện kiểm tra hộp trắng trên một ứng dụng, người kiểm tra cần biết các hoạt động bên trong của mã

2.3.3 Cấp độ trong kiểm thử

Kiểm thử phần mềm có 4 cấp độ: Unit Test (Kiểm thử đơn vị), Integration Test (Kiểm thử tích hợp), System Test (Kiểm thử hệ thống), Acceptance Test (Kiểm thử chấp nhận) Tùy vào 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 từng 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

Hình 2.4 Các cấp độ kiểm thử

Công việc này không hề đơn giản và có thể có lỗi về giao diện giữa các đơn vị và cần xác minh các thành phần trong phần mềm có tương tác được với nhau hay không, có hoạt động phối hợp cùng với nhau được không và cần phải kiểm thử để phát hiện những lỗi này

 Do kiểm thử viên thực hiện

 Các nhóm kiểm thử lớn dần cho đến khi thành một hệ thống

2.3.4.3 System Test

Kiểm thử mức này được áp dụng khi đã có một hệ thống đầy đủ sau khi tất cả các thành phần đã được tích hợp Mục đích của việc kiểm thử hệ thống là để đảm bảo rằng việc cài đặt tuân thủ đầy đủ các yêu cầu được đặc tả của người dùng

Là mức kiểm thử nhằm đưa hệ thống vào vận hành thử nghiệm tại các môi trường khác nhau nhằm tìm ra các lỗi hệ thống, tính tương thích, kiểm thử cả hệ thống về chức năng chính, sự liên kết giữa các module với nhau, kiểm thử giao diện

 Do kiểm thử viên thực hiện

2.3.4.4 Acceptance Test

Khi mà nhóm kiểm thử hệ thống đã thỏa mãn với một sản phẩm, sản phẩm đó đã sẵn sàng để đưa vào sử dụng Kiểm thử chấp nhận được thực thi bởi chính các khách hàng nhằm đảm bảo sản phẩm phần mềm được làm đúng như mong đợi của họ

Có 2 loại kiểm thử chấp nhận:

 Kiểm thử pháp nhân doanh nghiệp (Alpha Testing) là một nhóm người thực hiện test tại nơi sản xuất phần mềm Alpha Testing là một hình thức kiểm thử chấp nhận nội bộ, được tiến hành bởi các nhà sản xuất phần mềm, trước khi phần mềm được tiến hành kiểm thử Beta

 Kiểm thử chấp nhận người dùng (Beta Testing) được thực hiện tại địa điểm của khách hàng hoặc người dùng thực hiện test hay sử dụng phần mềm bên ngoài, không phải tại nơi sản xuất phần mềm

2.4 Test case

2.4.1 Khái niệm Test case

Trường hợp thử nghiệm là một tài liệu, trong đó có một tập hợp dữ liệu thử nghiệm, điều kiện tiên quyết, kết quả mong đợi và điều kiện hậu kỳ, được phát triển cho một kịch

bản thử nghiệm cụ thể để xác minh sự tuân thủ theo một yêu cầu cụ thể

Test case đóng vai trò là điểm bắt đầu cho quá trình thực thi thử nghiệm và sau khi

áp dụng một tập hợp các giá trị đầu vào, ứng dụng có một kết quả cuối cùng và rời khỏi hệ

thống tại một số điểm kết thúc hoặc còn được gọi là điều kiện hậu thực thi

2.4.2 Thông số điển hình của test case

● Test Case ID (Mã và tên của test case)

● Test Scenario (Kịch bản kiểm thử)

● Test Case Description (Mô tả test case)

● Test Steps (Mô tả các bước)

● Prerequisite (Điều kiện tiên quyết)

● Test Data (Dữ liệu kiểm thử)

● Expected Result (Kết quả mong đợi)

● Actual Result (Kết quả thực tế)

● Environment Information (Thông tin về môi trường)

● Comments (Nhận xét)