Thực hiện kiểm thử thủ công trên hệ thống quản lý thông tin internship management system (ims)

Mục tiêu của đề tài - Sau 10 tuần thực tập tại công ty, em đã tìm hiểu lý thuyết kiểm thử phần mềm, kỹ thuật viết test case để có thể viết test case cho chức năng của website, áp dụng

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

Đề tài:

THỰC HIỆN KIỂM THỬ THỦ CÔNG TRÊN HỆ THỐNG QUẢN

LÝ THÔNG TIN INTERNSHIP MANAGEMENT SYSTEM (IMS)

LỜI CẢM ƠN

Đầu tiên, chúng em xin gửi lời cảm ơn sâu sắc tới Thạc sĩ Cao Thị Nhâm đã dành thời gian, kiến thức và tận tâm để hỗ trợ và chỉ dẫn chúng em trong suốt quá trình nghiên cứu Cảm ơn 2 Mentors là anh Mai Phi Hùng và chị Lê Thị Thu Hồng đã bỏ thời gian quý báu của mình cũng như những kiến thức, nhiệt huyết trong nghề để truyền đạt cho chúng

em Những góp ý quý báu và sự động viên của cô và 2 Mentor đã giúp chúng em phát triển kiến thức và kỹ năng

Chúng em cũng muốn bày tỏ lòng biết ơn đến đơn vị thực tập TMA Solutions Bình Định vì sự hỗ trợ từ việc chỉ dẫn, kiến thức đến cơ sở vật chất mà họ đã cung cấp cho dự

án của chúng em Điều này đã giúp chúng em tiến xa hơn trong việc thu thập dữ liệu và phân tích, đồng thời tạo điều kiện thuận lợi để chúng em thực hiện nghiên cứu một cách hiệu quả

Lời cảm ơn chân thành và sâu sắc của chúng em dành tới tất cả mọi người

LỜI CAM ĐOAN

Chúng em xin cam đoan đề tài: “THỰC HIỆN KIỂM THỬ THỦ CÔNG CHO HỆ THỐNG QUẢN LÝ THỰC TẬP SINH INTERNSHIP MANAGEMENT SYSTEM” đây

là sự nghiên cứu của chúng em dưới sự hướng dẫn của Thạc sĩ Cao Thị Nhâm đến từ Khoa Thống kê tin học - trường Đại học Kinh tế cùng với sự chỉ dẫn và giúp đỡ của 2 Mentors anh Mai Phi Hùng và chị Lê Thị Thu Hồng đến từ đơn vị thực tập - Công ty TMA Solutions Bình Định Các kết quả trong chuyên đề do chúng em tự tìm hiểu, phân tích, vận dụng thực hiện một cách trung thực trong thời gian thực tập tại công ty Chúng em xin chịu hoàn toàn trách nhiệm, kỷ luật của bộ môn và nhà trường đề ra nếu như có vấn đề xảy ra

MỤC LỤC

LỜI CẢM ƠN vi

LỜI CAM ĐOAN vii

MỤC LỤC viii

DANH MỤC HÌNH ẢNH xi

DANH MỤC BẢNG BIỂU xii

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

LỜI MỞ ĐẦU 1

CHƯƠNG 1 TỔNG QUAN VỀ ĐƠN VỊ VÀ VỊ TRÍ THỰC TẬP 2

1.1 Giới thiệu tổng quát về doanh nghiệp thực tập 2

1.1.1 Tổng quan về doanh nghiệp 2

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

1.1.3 Cơ cấu tổ chức 3

1.1.4 Chính sách đãi ngộ 3

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

1.2.1 Khái niệm về Tester 3

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

1.2.3 Mức lương 4

1.2.4 Con đường phát triển 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 Khái niệm về kiểm thử phần mềm 6

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

2.1.5 Phân biệt Verification và Validation 7

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

2.2 Vòng đời phát triển phần mềm (Software Development Life Cycle – SDLC) 7 2.2.1 Phương thức Scrum (Scrum methodology) 8

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

2.3.1 Software Testing – Types of Testing 9

2.3.2 Các phương pháp kiểm thử phần mềm (Software Testing – Methods) 10

2.4 Các cấp độ kiểm thử (Software Testing – Levels) 12

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

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

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

2.4.4 Kiểm thử chấp nhận người dùng (User Acceptance Test) 14

2.5 Báo cáo lỗi 14

2.5.1 Tiêu đề lỗi 15

2.5.2 Mô tả lỗi 15

2.5.3 Mức độ nghiêm trọng 15

2.5.4 Ưu tiên 15

2.5.5 Tập đính kèm/Bằng chứng 16

2.5.6 Vòng đời của lỗi 16

CHƯƠNG 3 PHÂN TÍCH HỆ THỐNG 17

3.1 Tổng quan về hệ thống quản lý thông tin Internship Management System (IMS) 17 3.1.1 Giới thiệu chung về hệ thống IMS 17

3.1.2 Mô tả người dùng 17

3.2 Workflow hệ thống 17

3.3 Sơ đồ Use Case 18

3.3.1 Sơ đồ Usecase tổng quát 18

3.3.2 Chức năng chính tác nhân 19

3.4 Phân tích usecase “Quản lý ứng viên” 20

3.4.1 Sơ đồ tổng quát cho chức năng “Quản lý ứng viên” 20

3.4.2 Đặc tả yêu cầu cho Use Case “Thêm ứng viên” 21

3.4.3 Đặc tả yêu cầu cho Use Case “Sửa ứng viên” 23

3.4.4 Đặc tả cho Use case “ Tạo lịch phỏng vấn” 25

3.4.5 Đặc tả yêu cầu cho Use Case “Xóa ứng viên” 27

Chương 4: TRIỂN KHAI THỰC NGHIỆM 30

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

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

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

4.2 THIẾT KẾ TEST CASE 31

4.2.1 Các bước để tạo Test cases 31

4.2.2 Các cấu trúc của một Test cases 31

4.3 Kết quả kiểm thử: 32

4.4 Report bug: 32

4.5 Giới thiệu về phần mềm Trello: Error! Bookmark not defined Chương 5: KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 35

TÀI LIỆU THAM KHẢO 37

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

DANH MỤC HÌNH ẢNH

Hình 1.1 Logo TMA Solutions Bình Định 2

Hình 1.2 Sơ đồ cơ cấu tổ chức của công ty 3

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

Hình 2.2 Sơ đồ phương pháp Scrum 8

Hình 2.3 Sơ đồ vòng đời của lỗi 16

Hình 3.1 Workflow của hệ thống IMS 17

Hình 3.2 Sơ đồ Use Case tổng quát của hệ thống IMS 18

Hình 3.3 Sơ đồ Use Case cho chức năng “Quản lý ứng viên” 20

Hình 3.4 Giao diện màn hình Quản lý ứng viên 21

Hình 3.5 Màn hình thêm mới ứng viên 21

Hình 3.6 Màn hình với thông tin thêm mới của ứng viên 22

Hình 3.7 Màn hình hiển thị thông báo thêm ứng viên thành công 22

Hình 3.8 Hiển thị màn hình “Sửa ứng viên” 24

Hình 3.9 Hiển thị màn hình thông tin ứng viên đã được sửa 24

Hình 3.10 Hiển thị màn hình sửa ứng viên thành công 24

Hình 3.11 Hiển thị màn hình “Tạo lịch phỏng vấn” 26

Hình 3.12 Hiển thị màn hình với thông tin của lịch phỏng vấn 26

Hình 3.13 Hiển thị màn hình “Tạo lịch phỏng vấn thành công” 27

Hình 3.14 Hiển thị màn hình “Bạn có muốn xóa?” 28

Hình 3.15 Hiển thị màn hình “Xóa thành công” 28

Hình 4.1 Hình ảnh minh họa các thành phần của một Test Case 30

Hình 4.2 Bug Report trên Trello 34

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

QA : Quality Assurance

QC : Quality Control

IMS : Internship Manager System

STLC : Software Testing Life Cycle

SDLC : Software Development Life Cycle

LỜI MỞ ĐẦU

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

- Sau 10 tuần thực tập tại công ty, em đã tìm hiểu lý thuyết kiểm thử phần mềm, kỹ thuật viết test case để có thể viết test case cho chức năng của website, áp dụng kiến thức về kiểm thử phần mềm vào dự án để tìm lỗi

- Viết được Test case cho 1 chức năng cụ thể của hệ thống

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

- Đối tượng nghiên cứu: hệ thống quản lý thông tin Internship Management System (IMS)

- Phạm vi nghiên cứu: Thực hiện kiểm thử thủ công trên hệ thống quản lý thực tập

Internship Management System (IMS) cho chức năng Quản lý ứng viên

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

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

- Mở đầu

- Chương 1: Tổng quan về đơn vị và vị trí thực tập

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

- Chương 3: Phân tích hệ thống IMS

- Chương 4: Triển khai thực nghiệm

- Chương 5: Kết quả kiểm thử

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

CHƯƠNG 1 TỔNG QUAN VỀ ĐƠN VỊ VÀ VỊ TRÍ THỰC TẬP

1.1 Giới thiệu tổng quát về doanh nghiệp thực tập

1.1.1 Tổng quan về doanh nghiệp

- Tên cơ quan: Công ty TMA Solutions Bình Định

- Địa chỉ: 12 Đại lộ Khoa học, P.Ghềnh Ráng, TP.Quy Nhơn, Bình Định

- Email: contact@tma-binhdinh.vn

- Website: https://www.tma-binhdinh.vn/

Đượ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 4000

kỹ sư và 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)

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

Hình 1.1 Logo TMA Solutions Bình Định

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

 Tài chính, ngân hàng và bảo hiểm

 Sức khỏe và y tế

 Nông nghiệp và chế biến thực phẩm

1.1.3 Cơ cấu tổ chức

Hình 1.2 Sơ đồ cơ cấu tổ chức của công ty

1.1.4 Chính sách đãi ngộ

Tại TMA, môi trường làm việc tiện nghi, thoải mái không chỉ nằm ở cơ sở vật chất

mà còn ở các chính sách hỗ trợ về tài chính và chăm sóc sức khỏe cho nhân viên và gia đình Tiêu biểu là chương trình bảo hiểm chăm sóc sức khỏe toàn diện, chính sách cho vay tiền không lãi suất, chính sách hỗ trợ tài chính khẩn cấp cho các trường hợp khó khăn hoặc mắc bệnh hiểm nghèo…

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

1.2.1 Khái niệm về Tester

kiểm thử, thiết kế các ca kiểm thử, thực hiện các ca kiểm thử, ghi nhận và báo cáo lỗi, và đả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

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

 Kiến thức chuyên môn:

- 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…

- Nắm bắt được một số ngôn ngữ lập trình ở mức cơ bản để từ đó hiểu về kiến trúc

hệ thống của chính sản phẩm phần mềm mà mình chịu trách nhiệm

 Kỹ năng mềm:

- 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à có thể 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 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

 Mức lương tại công ty

- Mức lương thuộc vấn đề bảo mật của công ty nên không được công bố

- Công ty không có trợ cấp thử việc

 Mức lương ở Việt Nam

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 Bởi thế, Senior có thể quản lý, điều hành được cấp dưới, phối hợp với nhân viên để đem về kết quả cao hơn 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 Con đường phát triển

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:

- 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 CƠ SỞ LÝ THUYẾT 2.1 Tổng quan về kiểm thử phần mềm

2.1.1 Khái niệm về kiểm thử phần mềm

Kiểm thử phần mềm là một phương pháp để kiểm tra xem sản phẩm phần mềm được thực tế có phù hợp với các yêu cầu mong đợi hay không và để đảm bảo rằng sản phẩm đó không có khuyết điểm Nó liên quan đến việc thực thi các thành phần phần mềm/ hệ thống bằng cách sử dụng các công cụ thủ công hoặc tự động để đánh giá một hoặc nhiều thuộc tính quan tâm Mục đích của kiểm thử phần mềm là xác định các lỗi hoặc các yêu cầu còn thiếu đối lập với các yêu cầu thực tế

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

Kiểm tra xem phần mềm (sản phẩm) đã đáp ứng tất cả yêu cầu đã mô tả chưa hoặc xác nhận xem phần mềm đã hoàn thiện và hoạt động đúng như mong đợi của người dùng

và các bên liên quan khác chưa

Kiểm thử để ngăn ngừa lỗi bằng cách review tài liệu mô tả yêu cầu hay thiết kế hệ thống, bao gồm mã nguồn (source code) để phát hiện lỗi sớm

Kiểm thử nhằm nâng cao chất lượng phần mềm, tăng sự tin tưởng của khách hàng đối với phần mềm thông qua việc phát hiện lỗi và sửa lỗi (và dĩ nhiên là phải kiểm thử lại sau khi được sửa)

Cung cấp thông tin cho các bên liên quan (bao gồm quản lý dự án hay khách hàng tùy dự án) để họ có thể đưa ra quyết định về việc phát hành (release) một phần mềm nào

đó hay không

Giảm thiểu rủi ro do lỗi của phần mềm gây ra trong quá trình sử dụng thực tế

2.1.3 7 nguyên tắc trong kiểm thử phần mềm

- Kiểm tra cho thấy sự hiện diện của các khiếm khuyết

- Không thể kiểm tra hết mức

- Thử nghiệm sớm

- Phân cụm khiếm khuyết

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

- Thử nghiệm phụ thuộc vào ngữ cảnh

- Không có lỗi ngụy biện

2.1.4 Phân biệt Error, Bug, Fault, Failure

- Error: Lỗi là hành động của con người tạo ra kết quả không chính xác dẫn đến lỗi

- Bug: Sự hiện diện của lỗi tại thời điểm thực thi phần mềm

- Fault: Trạng thái của phần mềm do lỗi

- Failure: Độ lệch của phần mềm so với kết quả mong đợi

2.1.5 Phân biệt Verification và Validation

Verification là quá trình xác minh đảm bảo rằng sản phẩm được thiết kế để cung

cấp tất cả các chức năng cho khách hàng

Validation đang xác định xem hệ thống có tuân thủ các yêu cầu và thực hiện các

chức năng mà nó dự định và đáp ứng các mục tiêu của tổ chức cũng như nhu cầu của người dùng hay không

2.1.6 Phân biệt QA và QC

QA (Người đảm bảo bảo chất lượng) là một tập hợp các hoạt động cần thiết có kế

hoạch và có hệ thống để mang lại sự tin cậy đầy đủ rằng 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 dùng

QC (Người kiểm soát chất lượng) là quá trình so sánh chất lượng sản phẩm 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 sự không phù hợp

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

SDLC - Vòng đời phát triển phần mềm là một quá trình được sử dụng bởi ngành công nghiệp phần mềm để thiết kế, phát triển và thử nghiệm 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, đạt được hoàn thành trong thời gian và ước tính chi phí

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

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

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

 Giai đoạn 2: Thiết kế

 Giai đoạn 3: Thực hiện hoặc mã hóa

 Giai đoạn 4: Thử nghiệm

 Giai đoạn 5: Triển khai

 Giai đoạn 6: Bảo trì

2.2.1 Phương thức Scrum (Scrum methodology)

Scrum (framework) là một phương pháp làm việc để phát triển bền vững các sản phẩm phức tạp

Hình 2.2 Sơ đồ phương pháp Scrum

Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò

và trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù:

Product Owner: Là người tập hợp các task, quyết định độ ưu tiên task nào làm trước,

task nào làm sau

Scrum Master: Là người giúp cho team làm việc tốt nhất và bảo vệ team khi có vấn

đề xảy ra

Develop Team: Bao gồm Developer, Tester, Những người này có thể làm việc của

người khác

 Quy trình Scrum: 4 cuộc họp

Sprint Planning (họp kế hoạch Sprint): nhóm phát triển họp với Product Owner để

lên kế hoạch làm việc cho 1 sprint Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tacs vụ Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm

Daily Scrum Meeting (họp scrum hằng ngày): Scrum Master tổ chức cho đội sản

xuất họp hằng ngày trong khoảng 15p để nhóm phát triển chia sẻ tiến độ công việc, trong cuộc họp này từng người trong nhóm phát triển lần lượt trình bày để trả lời 3 câu hỏi: Hôm qua đã làm gì? Hôm nay sẽ làm gì? Có khó khăn trở ngại gì không?

Sprint review (họp sơ kết sprint): 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ản phẩm

Sprint Retrospective (họp cải tiến sprint): Là cuộc họp nhằm tập trung vào việc phát

huy những việc đã làm tốt, cải tiến những việc còn chưa tốt trong suốt sprint và rút ra các bài học kinh nghiệm cho các sprint tới Điều này không chỉ tập trung vào sản phẩm mà còn tập trung vào tổ chức, con người và môi trường làm việc

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

Kiểm thử thủ công là một loại kiểm thử phần mềm trong đó các trường hợp kiểm thử được thực hiện thủ công bởi người kiểm thử mà không sử dụng bất kỳ công cụ tự động nào Trong loại này, người kiểm tra đảm nhận vai trò của người dùng cuối và kiểm tra phần mềm để xác định bất kỳ hành vi hoặc lỗi không mong muốn nào

Có nhiều giai đoạn khác nhau để kiểm thử thủ công như kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận của người dùng

Người kiểm tra sử dụng kế hoạch kiểm tra, trường hợp kiểm tra hoặc kịch bản kiểm tra

để kiểm tra phần mềm nhằm đảm bảo tính hoàn chỉnh của kiểm tra

 Kiểm thử tự động

Kiểm thử tự động hóa, còn được gọi là kiểm thử tự động, là khi người kiểm thử viết các tập lệnh và sử dụng một phần mềm khác để kiểm tra sản phẩm Qúa trình này liên quan đến việc tự động hóa một quy trình thủ công Kiểm thử tự động được sử dụng để chạy lại các kịch bản kiểm thử được thực hiện thủ công, nhanh chóng và lặp đi lặp lại

Ngoài kiểm thử hồi quy, kiểm thử tự động hóa cũng được sử dụng để kiểm tra ứng dụng từ quan điểm tải, hiệu suất và căng thẳng Nó tăng phạm vi kiểm tra, cải thiện dộ chính xác, tiết kiệm thời gian và tiền bạc so với kiểm thử thủ công

Thực hiện kiểm thử tự động khi:

 Các dự án lớn và quan trọng

 Các dự án yêu cầu kiểm tra cùng một khu vực thường xuyên

 Yêu cầu không thay đổi thường xuyên

 Truy cập ứng dụng để tải và thực hiện với nhiều người dùng ảo

 Phần mềm ổn định đối với thủ nghiệp thủ công

 Thời gian có sẵn

2.3.2 Các phương pháp kiểm thử phần mềm (Software Testing – Methods)

 Kiểm thử hộp đen (Black-box Testing)

Kỹ thuật kiểm thử 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 thử không biết kiến trúc hệ thống và không có quyền truy cập vào mã

 Rất phù hợp và hiệu quản cho các đoạn mã lớn

 Truy cập vào nguồn code là không cần thiết

 Phân biệt rõ ràng quan điểm của người dùng với quan điểm của nhà phát triển

thông qua các vai trò đã được xác định rõ

 Một số lượng lớn người kiểm tra có kỹ năng vừa phải có thể kiểm tra ứng dụng

mà không cần kiến thức về triển khai, ngôn ngữ lập trình hoặc hệ điều hành

 Vùng phủ sóng mù, vì người kiểm tra không thể nhắm mục tiêu các đoạn mã cụ

thể hoặc các khu vực dễ bị lỗi

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

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

Thử nghiệm hộp trắng còn được gọi là thử nghiệm thủy tinh hoặc thử nghiệm hộp mở

Người kiểm tra cần biết hoạt động bên trong của mã nguồn và tìm ra đơn vị/đoạn

mã nào đang hoạt động không phù hợp

Ưu điểm

 Khi người kiểm tra có kiến thức về mã nguồn, sẽ rất dễ dàng tìm ra loại dữ liệu

nào có thể giúp kiểm tra ứng dụng một cách hiệu quả

 Do kiến thức của người kiểm thử về mã, phạm vi bảo phủ tối đa đạt được trong

quá trình viết kịch bản kiểm tra

Nhược điểm

 Do thực tế là cần một người kiểm thử lành nghề để thực hiện kiểm thử hộp trắng nên chi phí tăng lên

 Đôi khi không thể xem xét mọi ngóc ngách để tìm ra các lỗi tiềm ẩn có thể gây

ra sự cố, vì đường dẫn sẽ không được kiểm tra

 Rất khó để duy trì thử nghiệm hộp trắng vì nó yêu cầu các công cụ chuyên dụng như bộ phân tích mã và công cụ sửa lỗi

2.4 Các cấp độ kiểm thử (Software Testing – Levels)

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

Xây dựng: Một đơn vị ở đây là có thể kiểm thử các phần nhỏ nhất của bất kì phần

nào trong phần mềm Nó thường có một hoặc một vài đầu vào hoặc thường là một đầu ra duy nhất Một đơn vị ở đây nó có thể là một chương trình riêng lẻ, chức năng, thủ tục Các lỗi thường được sửa ngay sau khi tìm thấy và chúng không được báo cáo và theo dõi chính thức

Phương pháp: Kiểm thử đơn vị thường được thực hiện bởi phương pháp Kiểm thử

hộp trắng (White Box Testing) và thông thường là kiểm thử tự động

Thời điểm thực hiện: Là cấp độ đầu tiên của kiểm thử phần mềm và được thực hiện

trước khi kiểm tra tích hợp Mặc dù kiểm thử đơn vị thường được thực hiện sau khi viết

mã, nhưng đôi khi, đặc biệt trong quá trình phát triển dựa trên kiểm thử ( Test - Driven Development TDD), kiểm thử đơn vị tự động viết hoa khi viết mã

Người thực hiện: thường được thực hiện bởi nhà phát triển phần mềm

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

Phương pháp: Có thể được sử dụng bởi bất phương pháp như Kiểm thử hộp đen

(Black-box Testing), Kiểm thử hộp trắng (White-Box Testing) và Kiểm thử hộp xám (Gray-box Testing) Thông thường, phương pháp này phụ thuộc vào định nghĩa của bạn về

“đơn vị” và chính xác những gì bạn đang tích hợp Thử nghiệm có thể là thủ công hoặc thủ động

Thời điểm thực hiện: là cấp độ thứ hai của quy trình kiểm thử được thực hiện sau

kiểm thử đơn vị và trước khi kiểm thử hệ thống

Người thực hiện: thường được thực hiện bởi nhà phát triển và kiểm thử tích hợp hệ

thống người kiểm thử độc lập

Các loại kiểm thử tích hợp:

 Unit/ Component Integration Testing

 System Integration Testing

Các cách tiếp cận:

 Top Down

 Bottom Up

 Hybrid/Sandwich

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

Phương pháp: Thông thường, phương pháp Kiểm thử hộp đen (Black-box

Testing), trong đó cấu trúc bên trong của hệ thống được kiểm tra là không xác định, được

sử dụng Các bài kiểm tra thường được thực hiện thủ công nhưng xu hướng tự động hóa kiểm tra, đặc biệt cho Kiểm thử hồi quy (Regression Testing) đang tăng lên

Thời điểm thực hiện: Kiểm thử hệ thống là cấp độ thứ ba của kiểm thử phần mềm

được thực hiện sau Kiểm thử tích hợp và trước Kiểm thử chấp nhận

Người thực hiện: Thông thường, những người kiểm thử phần mềm độc lập thực

2.4.4 Kiểm thử chấp nhận người dùng (User Acceptance Test)

Phương pháp: Kiểm tra chấp nhận thường sử dụng phương pháp Kiểm tra hộp đen

và được thực hiện thủ công Hầu hết, việc kiểm tra không tuân theo một quy trình nghiêm ngặt và không theo kịch bản mà khá đặc biệt

Nhiệm vụ: Acceptance Test

Thời điểm thực hiện: Kiểm thử chấp nhận là cấp kiểm thử phần mềm thứ tư và cuối

cùng được thực hiện sau Kiểm thử hệ thống và trước khi đưa hệ thống vào sản xuất để sử dụng thực tế

 Các loại

Alpha Testing

Đượ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ản phẩ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 Testing

Đượ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ống trong môi trường riêng của họ - không phải nơi phát triển phần mềm

2.5 Báo cáo lỗi

2.5.1 Tiêu đề lỗi

- Tiêu đề nên chứa định nghĩa ngắn gọn về lỗi

- Tiêu đề có thể có tiền tố ngắn mô tả vị trí hoặc chức năng liên quan đến lỗi

- Tên có thể có hậu tố ngắn mô tả tình huống khi lỗi xuất hiện

2.5.2 Mô tả lỗi

- Mô tả lỗi nên chứa thông tin về cách tái hiện lỗi và đề xuất cho hành vi chính xác

- Mô tả lỗi nên chứa thông tin về:

 Mô tả chi tiết: Cung cấp nhiều chi tiết càng tốt

 Phương tiện: Đừng quên thêm ảnh chụp màn hình hoặc video

 Liên kết: nơi lỗi xuất hiện

 Kết quả thực tế: hiện tại nó hoạt động/ trông như thế nào

 Kết quả mong đợi: nó nên hoạt động/ trông như thế nào

 Bước để tái hiện

- Ưu tiên (Priority) xác định thứ tự mà chúng ta nên khắc phục một lỗi

- Mức độ ưu tiên (Priority) có thể được chia thành các loại sau:

 Low

 Medium

 High

2.5.5 Tập đính kèm/Bằng chứng

Bất kỳ bằng chứng nào về sự thất bại xảy ra nên được thu thập và nộp cùng báo cáo lỗi Điều này giúp trình bày một cách trực quan về mô tả của lỗi và giúp người xem, nhà phát triển hiểu rõ hơn về sự cố đó

2.5.6 Vòng đời của lỗi

Hình 2.3 Sơ đồ vòng đời của lỗi

CHƯƠNG 3 PHÂN TÍCH HỆ THỐNG 3.1 Tổng quan về hệ thống quản lý thông tin Internship Management System (IMS)

3.1.1 Giới thiệu chung về hệ thống IMS

IMS (Intern Management System) là phần mềm dành riêng cho TIP (TMA

Innovation Park) để quản lý thực tập sinh

IMS cung cấp các chức năng cho phép người dùng lưu lại thông tin cá nhân, bao

gồm hồ sơ, kỹ năng, và thông tin liên hệ Điều này giúp quản lý sinh viên và tổ chức thực

tập có được cái nhìn tổng quan về sinh viên

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

3.3 Sơ đồ Use Case

3.3.1 Sơ đồ Usecase tổng quát

Hình 3.2 Sơ đồ Use Case tổng quát của hệ thống IMS

3.3.2 Chức năng chính tác nhân

1 Admin Tác nhân thực hiện quản lý, giảm sát và nắm bắt từng yêu cầu từ phía

những đối tượng người dùng khác

Admin có thể thực hiện toàn quyền đối với hệ thống, các chức năng mà Admin có thể thực hiện bao gồm:

• Đăng nhập

• Quản lý khóa thực tập (Xem, thêm, xóa, sửa, tìm kiếm)

• Quản lý người hướng dẫn (Xem, thêm, xóa, sửa, tìm kiếm)

• Quản lý sinh viên viên thực tập (Chỉ định người hướng dẫn, xem, thêm, xóa, sửa, tìm kiếm)

• Quản lý ứng viên (Thêm, xóa, sửa, tìm kiếm,)

• Đánh giá kết quả (Xem)

• Chọn Batch

Bảng 3.1 Chức năng chính của Admin

3.4 Phân tích usecase “Quản lý ứng viên”

3.4.1 Sơ đồ tổng quát cho chức năng “Quản lý ứng viên”

Hình 3.3 Sơ đồ Use Case cho chức năng “Quản lý ứng viên”

Use case “Quản lý ứng viên” gồm các use case:

Sau khi Đăng nhập thành công, tại giao diện màn hình chính, người dùng chọn

“Quản lý thực tập”, tại màn hình “Hệ thống quản lý thực tập” người dùng chọn khóa thực tập, sau khi chọn khóa thực tập và bấm nút “Xác nhận, hệ thống sẽ hiển thị thông báo

“CHÀO MỪNG BẠN ĐÃ ĐẾN VỚI BATCH…”, người dùng bấm nút “Ứng viên” sau

đó chọn “Quản lý ứng viên” hệ thống sẽ hiển thị Danh sách ứng viên ứng với khóa thực tập đã chọn