Kiểm thử thủ công chức năng tính lương và tìm hiểu kiểm thử tự động với phần mềm katalon studio cho chức năng đăng nhập website

Trang 1 TRƯỜNG ĐẠI HỌC THƯƠNG MẠI KHOA HTTT KINH TẾ VÀ THƯƠNG MẠI ĐIỆN TỬ BÀI THẢO LUẬN KIỂM THỬ PHẦN MỀM Kiểm thử thủ công chức năng tính lương và tìm hiểu kiểm thử tự động với phần mềm

TRƯỜNG ĐẠI HỌC THƯƠNG MẠI KHOA HTTT KINH TẾ VÀ THƯƠNG MẠI ĐIỆN TỬ

BÀI THẢO LUẬN KIỂM THỬ PHẦN MỀM

Kiểm thử thủ công chức năng tính lương và tìm hiểu kiểm thử tự động với phần mềm Katalon Studio cho chức năng đăng nhập

website

Giảng viên HD: TS.Vũ Diệu Hương

Lớp học phần: 2245ECIT3021

Nhóm 6:

56 – Nguyễn T.Hằng Nga 61 – Nguyễn Hoài Ngọc

57 – Lò Thị Ngà 62 – Nguyễn Khôi Nguyên

58 – Đoàn Thị Ngân 63 – Nguyễn Thị Nguyệt

59 – Đỗ Thị Hồng Ngọc 64 – Nguyễn Thị Minh Nguyệt (NT)

60 – Dương Thị Ngọc 65 – Lê Đình Nhật

Hà Nội, tháng 11/2022

1 | P a g e

BẢNG PHÂN CÔNG CÔNG VIỆC

Nhóm trưởng: Nguyễn Thị Minh Nguyệt

56 Nguyễn T.Hằng Nga Kiểm thử biên (đầu ra) Báo cáo kiểm thủ công

57 Lò Thị Ngà Lý thuyết kiểm thử, xây dựng test case tự động

58 Đoàn Thị Ngân Bảng quyết định (thiết kế + thực hiện)

59 Đỗ Thị Hồng Ngọc Phân hoạch tương đương (thiết kế + thực hiện)

60 Dương Thị Ngọc Dòng dữ liệu, powerpoint

61 Nguyễn Hoài Ngọc Xây dựng chương trình, Use Case, Dòng điều khiển

62 Nguyễn Khôi Nguyên Kiểm thử biên (đầu vào) (thiết kế + thực hiện)

63 Nguyễn Thị Nguyệt Chuẩn bị môi trường kiểm thử, word

64 Nguyễn Thị Minh Nguyệt Mô tả bài toán, Kế hoạch kiểm thử, Demo tự động

Kiểm soát quá trình thực hiện và hiệu chỉnh

65 Lê Đình Nhật Lý thuyết tự động, Giới thiệu Katalon Studio

2 | P a g e

MỤC LỤC

DANH MỤC BẢNG 4

DANH MỤC HÌNH ẢNH 5

MỞ ĐẦU 6

A CƠ SỞ LÝ THUYẾT 7

I Kiểm thử phần mềm 7

1 Khái niệm 7

2 Quy trình kiểm thử phần mềm 7

3 Các cấp độ kiểm thử 8

4 Các kỹ thuật kiểm thử phần mềm 8

5 Kỹ thuật thiết kế ca kiểm thử 9

II Kiểm thử tự động 10

1 Khái niệm kiểm thử tự động 10

2 Mục tiêu và nguyên tắc khi kiểm thử tự động 10

3 Kiến trúc của một bộ kiểm thử tự động 10

4 Ưu, nhược điểm khi sử dụng kiểm thử tự động 12

B THỰC HÀNH KIỂM THỬ THỦ CÔNG 14

I Phát biểu bài toán 14

1 Mô tả bài toán 14

2 Đặc tả bài toán 14

II Code của chương trình 15

1 Ngôn ngữ lập trình và thư viện sử dụng 15

2 Chương trình 15

III Kế hoạch kiểm thử 17

1 Mục tiêu kiểm thử 17

2 Chiến lược kiểm thử 17

3 Tiêu chí đảm bảo đầu ra 17

4 Quy trình thực hiện 17

5 Lịch trình thực hiện 18

6 Hoạch định nguồn lực 18

7 Phân công công việc 19

8 Các tài liệu báo cáo kiểm thử 20

IV Thiết kế kiểm thử 20

1 Thiết kế dựa trên mô tả ca sử dụng 20

3 | P a g e

2 Kiểm thử giá trị biên 24

3 Kiểm thử phân hoạch tương đương 50

4 Kiểm thử với bảng quyết định 52

5 Kiểm thử với dòng điều khiển 55

6 Kiểm thử dòng dữ liệu 61

V Chuẩn bị kiểm thử 70

1 Môi trường kiểm thử 70

2 Dữ liệu kiểm thử 70

VI Thực hiện kiểm thử chương trình 70

1 Kiểm thử giá trị biên 70

2 Kiểm thử phân hoạch tương đương 103

3 Kiểm thử với bảng quyết định 104

4 Kiểm thử với dòng điều khiển 106

5 Kiểm thử với dòng dữ liệu 108

VII Báo cáo 109

C KIỂM THỬ TỰ ĐỘNG CHO CHỨC NĂNG ĐĂNG NHẬP BẰNG CÔNG CỤ KATALON STUDIO 110

I Tổng quan về Katalon Studio 110

1 Khái niệm về Katalon Studio 110

2 Ưu điểm của Katalon 110

3 Nhược điểm của Katalon 111

4 Yêu cầu cấu hình cài đặt 111

II Kiểm thử tự động chức năng đăng nhập bằng công cụ Katalon 112

1 Đặc tả yêu cầu kiểm thử chức năng đăng nhập cho website 112

2 Thiết kế Test case: 112

3 Chuẩn bị môi trường, dữ liệu kiểm thử: 112

III Demo kiểm thử tự động trên Katalon 114

IV Báo cáo 118

KẾT LUẬN 119

PHỤ LỤC 120 BIÊN BẢN HỌP LẦN 1 Error! Bookmark not defined BIÊN BẢN HỌP LẦN 2 Error! Bookmark not defined BIÊN BẢN HỌP LẦN 3 Error! Bookmark not defined

4 | P a g e

DANH MỤC BẢNG

Bảng 1 So sánh kiểm thử thủ công và kiểm thử tự động 13

Bảng 2 UC description 22

Bảng 3 Kịch bản hành vi luồng phụ 23

Bảng 4 Kịch bản hành vi rẽ nhánh 23

Bảng 5 Xác định các giá trị biên 24

Bảng 6 Thiết kế test case kiểm thử biên đầu vào 49

Bảng 7 Xác định biên từ giá trị đầu ra 49

Bảng 8 Thiết kế test case biên đầu ra 50

Bảng 9 Phân hoạch hình thức 50

Bảng 10 Phân hoạch lương cơ bản 50

Bảng 11 Phân hoạch ngày công 51

Bảng 12 Phân hoạch giờ tăng ca 51

Bảng 13 Phân hoạch giờ công 51

Bảng 14 Thiết kế test case phân hoạch tương đương 52

Bảng 15 Xây dựng đầu vào cho bảng quyết định 53

Bảng 16 Xây dựng hành động đầu ra cho bảng quyết định 53

Bảng 17 Bảng quyết định 53

Bảng 18 Thiết kế test case bảng quyết định 54

Bảng 19 Thiết kế test case dòng điều khiển C1 57

Bảng 20 Trường hợp kiểm thử C2 58

Bảng 21 Thiết kế test case dòng điều khiển C2 59

Bảng 22 Trường hợp kiểm thử C3 59

Bảng 23 Thiết kế test case dòng điều khiển C3 60

Bảng 24 Kịch bản kiểm thử đời sống biến ht 62

Bảng 25 Kịch bản kiểm thử đời sống biến ngaycong 63

Bảng 26 Kịch bản kiểm thử đời sống biến luongcoban 64

Bảng 27 Kịch bản kiểm thử đời sống biến giotangca 65

Bảng 28 Kịch bản kiểm thử đời sống biến giocong 66

Bảng 29 Kịch bản kiểm thử đời sống biến phucap 67

Bảng 30 Kịch bản kiểm thử đời sống biến luongtangca 68

Bảng 31 Kịch bản kiểm thử đời sống biến luongthuclinh 69

Bảng 32 Thực hiện kiểm thử biên đầu vào 102

Bảng 33 Thực hiện kiểm thử biên đầu ra 103

Bảng 34 Thực hiện kiểm thử phân hoạch tương đương 104

Bảng 35 Thực hiện kiểm thử bảng quyết định Version 1 105

Bảng 36 Thực hiện kiểm thử hồi quy bảng quyết định Version 2 106

Bảng 37 Sinh test case mới dòng điều khiển 107

Bảng 38 Thực hiện kiểm thử dòng điều khiển 108

Bảng 39 Kiểm thử bổ sung dòng dữ liệu 108

Bảng 40 Cấu hình bắt buộc cho Katalon 111

Bảng 41 Test case kiểm thử tự động 112

5 | P a g e

DANH MỤC HÌNH ẢNH

6 | P a g e

MỞ ĐẦU

Với sự phát triển như vũ bão của công nghệ thông tin nói chung và công nghệ phần mềm nói riêng, việc phát triển phần mềm ngày càng được hỗ trợ bởi nhiều công cụ tiên tiến, giúp cho việc xây dựng phần mềm đỡ mệt nhọc và hiệu quả hơn Tuy nhiên, vì độ phức tạp của phần mềm và những giới hạn về thời gian và chi phí, cho dù các hoạt động đảm bảo chất lượng phần mềm nói chung và kiểm thử nói riêng ngày càng chặt chẽ và khoa học, vẫn không đảm bảo được rằng các sản phẩm phần mềm đang được ứng dụng không

có lỗi Lỗi vẫn luôn tiềm ẩn trong mọi sản phẩm phần mềm và cũng có thể gây những thiệt hại khôn lường Kiểm thử phần mềm là một quá trình liên tục, xuyên suốt mọi giai đoạn phát triển phần mềm để đảm bảo rằng phần mềm thoả mãn các yêu cầu thiết kế và các yêu cầu đó đáp ứng các nhu cầu của người dùng Các kỹ thuật kiểm thử phần mềm đã và đang được nghiên cứu, và việc kiểm thử phần mềm đã trở thành quy trình bắt buộc trong các dự

án phát triển phần mềm trên thế giới Kiểm thử phần mềm là một hoạt động rất tốn kém, mất thời gian, và khó phát hiện được hết lỗi Vì vậy, việc kiểm thử phần mềm đòi hỏi phải

có chiến lược phù hợp, một kế hoạch hợp lý và việc thực hiện được quản lí chặt chẽ Và đặt ra một vấn đề hiển nhiên là kiểm thử các phần mềm chạy trên di động này để xem chúng có đáp ứng được các yêu cầu đề ra ban đầu hay không trước khi phát hành sản phẩm tới tay người tiêu dùng Đó là lý do nhóm 6 em chọn đề tài “Kiểm thử thủ công chức năng tính lương và tìm hiểu kiểm thử tự động với phần mềm Katalon Studio cho chức năng đăng nhập website” làm đề tài thảo luận Mục đích của đề tài: Tìm hiểu cơ sở lý thuyết về kiểm thử nói chung và kiểm thử thủ công hệ thống chức năng tính lương nhân sự và kiểm thử tự động với phần mềm Katalon Studio cho chức năng đăng nhập website nói riêng để giảm thời gian tín lương và đảm bảo chất lượng phần mềm hơn với công việc

2 Quy trình kiểm thử phần mềm

2.1 Requirement analysis - Phân tích yêu cầu

Phân tích yêu cầu là giai đoạn đầu tiên trong quy trình kiểm thử phần mềm Xác định cái gì cần kiểm thử Thực hiện nghiên cứu và phân tích cụ thể các yêu cầu trong tài liệu đặc tả của dự án hoặc tài liệu khách hàng qua đó nắm bắt các yêu cầu của dự án đưa

ra bao gồm yêu cầu kiểm thử chức năng/ phi chức năng nào Đầu ra của giai đoạn phân tích yêu cầu bao gồm tài liệu chứa các câu hỏi và câu trả lời liên quan đến nghiệp vụ của

hệ thống, tài liệu báo cáo tính khả thi, phân tích rủi ro của việc kiểm thử phần mềm

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

Dựa vào các tài liệu được cung cấp và cập nhật mới nhất, thông thường, test manager hoặc test leader sẽ là người lập kế hoạch kiểm thử Đầu ra của giai đoạn lập kế hoạch bao gồm các tài liệu như kế hoạch kiểm thử, ước tính thử nghiệm, lịch trình kiểm thử

2.3 Test case development - Thiết kế kịch bản kiểm thử

Review tài liệu: Đầu tiên, các kiểm thử viên cần review lại tất cả các tài liệu để xác định công việc cần làm, các công việc có khác gì so với dự án trước khách hàng đưa cho, chức năng nào cần test, chức năng nào không cần test lại nữa

Viết test case/ checklist: Sau đó, tester bắt tay vào việc viết test case chi tiết dựa vào

kế hoạch đã đưa ra và vận dụng các kỹ thuật thiết kế kịch bản kiểm thử Test case cần bao phủ được tất cả các trường hợp kiểm thử có thể xảy ra cũng như đáp ứng đầy đủ các tiêu chí của sản phẩm

Chuẩn bị dữ liệu kiểm thử: Cùng với việc tạo ra các test case chi tiết, đội kiểm thử cũng cần chuẩn bị trước các dữ liệu kiểm thử cho các trường hợp cần thiết

Review test case/ checklist: Sau khi hoàn thành, các thành viên trong đội kiểm thử hoặc test leader cũng cần review lại test case đã tạo để có thể bổ sung, hỗ trợ lẫn nhau nhằm tránh những sai sót trong thiết kế test case và rủi ro về sau

Sau khi hoàn thành thiết kế kịch bản kiểm thử, đội kiểm thử sẽ có các tài liệu bao gồm: test design, test case, checklist, test data, test automation script

2.4 Test environment setup - Thiết lập môi trường kiểm thử

Việc cài đặt môi trường kiểm thử là giai đoạn cũng rất quan trọng trong vòng đời phát triển phần mềm Môi trường kiểm thử sẽ được quyết định dựa trên những yêu cầu của

8 | P a g e

khách hàng, hay đặc thù của sản phẩm ví dụ như server/ client/ network, Đầu ra của giai đoạn này là môi trường đã được cài đặt đúng theo yêu cầu, sẵn sàng cho việc kiểm thử

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

Thực hiện các test case như thiết kế và mức độ ưu tiên đã đưa ra trên môi trường đã được cài đặt So sánh với kết quả mong đợi sau báo cáo các bug xảy ra, quản lý lỗi và theo dõi trạng thái của lỗi đến khi được sửa thành công Thực hiện lại kiểm tra để xác minh các lỗi đã được sửa chữa và kiểm tra hồi quy khi có sự thay đổi liên quan Trong quá trình thực hiện kiểm thử, kiểm thử viên cũng có thể hỗ trợ, đề xuất cho cả đội dự án để có giải pháp hợp lý và kết hợp công việc hiệu quả Đầu ra của giai đoạn này là test results ( kết quả kiểm thử), defect reports( danh sách các lỗi tìm được)

2.6 Test cycle closure - Đóng chu trình kiểm thử

Đây là giai đoạn cuối cùng trong quy trình kiểm thử phần mềm Thực hiện tổng hợp

và viết báo cáo kết quả về việc thực thi test case, bao nhiêu case pass/ fail, bao nhiêu test case phát hiện ra lỗi, mức độ nghiêm trọng của lỗi…Chức năng nào đã hoàn thành kiểm thử/ chưa hoàn thành kiểm thử/ trễ tiến độ bàn giao Đánh giá các tiêu chí hoàn thành như phạm vi kiểm tra, chất lượng, chi phí, thời gian, mục tiêu kinh doanh quan trọng Ngoài ra, giai đoạn này cũng thảo luận tất cả những điểm tốt, điểm chưa tốt và rút ra bài học kinh nghiệm cho những dự án sau, giúp cải thiện quy trình kiểm thử Đầu ra của giai đoạn này bao gồm các tài liệu: Test report, Test results

3 Các cấp độ kiểm thử

o Unit Testing - Kiểm thử mức đơn vị

o Integration Testing - Kiểm thử tích hợp

o System testing - Kiểm thử hệ thống

o Acceptance Testing - Kiểm thử chấp nhận

4 Các kỹ thuật kiểm thử phần mềm

4.1 Black Box Testing - Kiểm thử hộp đen

Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao Phương pháp này thường dùng để test chức năng, giao diện,… Ưu điểm của kiểm thử hộp đen là kiểm thử khá nhanh ngay khi các yêu cầu chức năng được xác định, hệ thống thực và toàn bộ yêu cầu được kiểm thử chính xác Tuy nhiên nhược điểm của kỹ thuật này là yêu cầu lượng mẫu khá lớn, khó viết kịch bản

và thời gian tập hợp các yếu tố đầu vào, xây dựng test case khá lâu

4.2 White Box Testing - Kiểm thử hộp trắng

Là phương pháp kiểm thử phần mềm kiểm tra cấu trúc nội bộ hoặc hoạt động của một ứng dụng dựa trên đặc tả bên trong chương trình, dựa vào mã nguồn, cấu trúc chương trình Kiểm thử hộp trắng thường phát hiện các lỗi lập trình Trong khi kiểm thử hộp trắng

có thể được áp dụng tại mức độ test đơn vị, tích hợp hệ thống của quá trình kiểm thử phần

9 | P a g e

mềm, nó thường được thực hiện ở cấp đơn vị Hai kỹ thuật kiểm thử hộp trắng phổ biến là kiểm thử luồng điều khiển và kiểm thử luồng dữ liệu

5 Kỹ thuật thiết kế ca kiểm thử

5.1 Kiểm thử giá trị biên

Kiểm thử giá trị biên (boundary value testing) là một trong những kỹ thuật được áp dụng phổ biển nhất trong cách tiếp cận kiểm thử chức năng (kiểm thử hộp đen).Các test case được thiết kế bao gồm các giá trị tại biên và giá trị trung bình Giá trị biên được xác định 3 data set bao gồm: In-bound (biên), Out of bound (ngoài biên), On bound (trong biên) đối với miền xác định Và kiểm thử biên với miền giá trị Mục đích nhằm kiểm tra khoảng giá trị hợp lệ của dữ liệu được nhập có thể xảy ra lỗi lập trình hoặc đặc tả làm các biểu thức điều kiện không chính xác

5.2 Kiểm thử phân hoạch tương đương

Kiểm thử lớp tương đương là phương pháp chia miền dữ liệu kiểm thử thành các miền con sao cho dữ liệu trong mỗi miền con có cùng tính chất đối với chương trình, có nghĩa là các ca kiểm thử của một miền con sẽ cùng gây lỗi cho chương trình, hay cùng cho kết quả đúng, hay cùng cho kết quả sai tương tự nhau Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương

5.3 Kiểm thử với bảng quyết định

Bảng quyết định là một kỹ thuật test được sử dụng để kiểm tra các hành vi hệ thống với các cách kết hợp input đầu vào khác nhau Đây là một cách tiếp cận có hệ thống, kết quả của các kết hợp đó và hành vi hệ thống tương ứng của chúng sẽ được ghi lại dưới dạng bảng Cấu trúc bảng quyết định chia thành bốn phần chính:

o Các biểu thức điều kiện C1, C2, C3

o Giá trị điều kiện T, F, –

o Các hành động A1, A2, A3, A4

o Giá trị hành động, có (xảy ra) hay không, X là có

Bảng quyết định với các giá trị điều kiện chỉ là T, F, và – gọi là bảng quyết định lôgic

5.4 Kiểm thử với dòng điều khiển

Phương pháp kiểm thử dòng điều khiển dựa trên khái niệm đồ thị dòng điều khiển (control flow graph) Đồ thị này được xây dựng từ mã nguồn của chương trình/đơn vị chương trình Đồ thị dòng điều khiển là một đồ thị có hướng gồm các đỉnh tương ứng với các câu lệnh/nhóm câu lệnh và các cạnh là các dòng điều khiển giữa các câu lệnh/nhóm câu lệnh Nếu i và j là các đỉnh của đồ thị dòng điều khiển thì tồn tại một cạnh từ i đến j nếu lệnh tương ứng với j có thể được thực hiện ngay sau lệnh tương ứng với i Mục tiêu của phương pháp kiểm thử luồng điều khiển là đảm bảo mọi đường thi hành của đơn vị phần mềm cần kiểm thử đều chạy đúng Rất tiếc trong thực tế, công sức và thời gian để đạt mục tiêu trên đây là rất lớn, ngay cả trên những đơn vị phần mềm nhỏ

1 Khái niệm kiểm thử tự động

Kiểm thử tự động là quá trình thực hiện một cách tự động các bước trong một kịch bản kiểm thử bằng việc sử dụng một công cụ nhằm rút ngắn thời gian kiểm thử Đó là một kỹ thuật tự động trong đó người kiểm thử tự viết các tập lệnh và sử dụng phần mềm phù hợp

để kiểm thử phần mềm Nó về cơ bản là một quá trình tự động hóa của một quy trình kiểm thử thủ công Giống như kiểm thử hồi quy, kiểm thử tự động cũng được sử dụng để kiểm thử ứng dụng theo quan điểm tải, hiệu năng và ứng suất

2 Mục tiêu và nguyên tắc khi kiểm thử tự động

2.1 Mục tiêu của kiểm thử tự động

• Tăng độ tin cậy

• Giảm sự nhàm chán

• Giảm chi phí tổng cho quá trình kiểm thử

2.2 Nguyên tắc khi kiểm thử tự động

• Không đủ tài nguyên: Khi số lượng Test Case quá nhiều mà kiểm thử viên không thể hoàn tất trong thời gian cụ thể

• Kiểm tra hồi quy: Nâng cấp phần mềm, kiểm tra lại các tính năng đã chạy tốt và những tính năng đã sửa Tuy nhiên, việc này khó đảm bảo về mặt thời gian

• Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt (Đo tốc độ trung bình xử lý một yêu cầu của Web server, xác định cấu hình máy thấp nhất mà phần mềm vẫn có thể hoạt động tốt)

3 Kiến trúc của một bộ kiểm thử tự động

• Quản lý kiểm thử: công cụ này cho phép quản lý việc thực hiện/thực thi các ca

kiểm thử Nó giám sát việc thực hiện từng ca kiểm thử ứng với bộ giá trị đầu vào, giá trị đầu ra mong muốn và giá trị đầu ra thực tế

• Sinh các ca kiểm thử: là một trong những công cụ quan trọng của các bộ kiểm thử

tự động Tùy thuộc vào các kỹ thuật kiểm thử được áp dụng, công cụ này sẽ sinh ra tập các ca kiểm thử cho chương trình/đơn vị chương trình cần kiểm thử Các ca kiểm

11 | P a g e

thử được sinh ra chỉ chứa giá trị đầu vào để thực hiện nó Các giá trị này có thể được

lựa chọn trong cơ sở dữ liệu hoặc được sinh một cách ngẫu nhiên

• Sinh giá trị đầu ra mong muốn: Các ca kiểm thử được sinh ra bởi công cụ trên chỉ

chứa các giá trị đầu vào Công cụ này cho phép sinh ra giá trị đầu ra mong muốn ứng với mỗi bộ dữ liệu đầu vào của mỗi ca kiểm thử Giá trị đầu ra mong muốn này

sẽ được so sánh với giá trị đầu ra thực tế khi thực hiện ca kiểm thử này nhằm phát

hiện ra các lỗi, khiếm khuyết của sản phẩm

• So sánh kết quả kiểm thử: Công cụ này so sánh giá trị đầu ra thực tế và giá trị đầu

ra mong muốn của mỗi ca kiểm thử khi nó được thực hiện trên chương trình/đơn vị

chương trình cần kiểm thử

• Tạo báo cáo kiểm thử: Một trong những ưu điểm của các bộ công cụ kiểm thử tự

động là nó có cơ chế sinh báo cáo kiểm thử một cách chính xác và nhất quán Dựa vào kết quả của công cụ so sánh kết quả kiểm thử, công cụ này sẽ tự động sinh ra

báo cáo kết quả kiểm thử theo định dạng mong muốn của đơn vị phát triển

• Phân tích động: Công cụ này cung cấp một cơ chế kiểm tra việc thực hiện của các

câu lệnh của chương trình cần kiểm thử nhằm phát hiện ra các lỗi và phát hiện các

câu lệnh/đoạn lệnh không được thực hiện bởi một tập các ca kiểm thử cho trước

• Bộ mô phỏng: Có nhiều loại mình mô phỏng được cung cấp trong các bộ kiểm thử

tự động Mục đích của các công cụ này là mô phỏng quá trình thực hiện của chương

trình cần kiểm thử

Ảnh 1 Kiến trúc công cụ kiểm thử tự động

12 | P a g e

4 Ưu, nhược điểm khi sử dụng kiểm thử tự động

Ưu điểm:

chóng, phát hiện sớm các lỗi, Loại bỏ lỗi của con người khi thực hiện các bài kiểm tra, cho phép các bài kiểm tra chính xác hơn và có thể thực hiện kể cả thiếu nguồn nhân lực

so với con người, đặc biệt trong trường hợp có quá nhiều ca kiểm thử cần được thực thi, nên độ tin cậy của kiểm thử tự động thường cao hơn so với kiểm thử thủ công Nhờ độ

ổn định cao, kiểm thử tự động có thể thực thi các ca kiểm thử với độ chính xác cao hơn

kiểm thử trong một thời gian ngắn Điều này giúp chúng ta tăng độ bao phủ trong giai đoạn kiểm thử hồi quy

lần, có thể sử dụng cho nhiều phiên bản ứng dụng khác nhau

Nhược điểm

động khó hơn nhiều so với kiểm thử thủ công vì cập nhật hay chỉnh sửa yêu cầu nhiều công việc như debug, thay đổi dữ liệu đầu vào và cập nhật code mới

khá tốt nhưng chúng vẫn còn nhiều hạn chế Ngoài ra nhân lực đạt yêu cầu có thể sử dụng thành thạo các công cụ này cũng không nhiều

So sánh kiểm thử tự động với kiểm thử thủ công

Độ linh

động

Linh động do kiểm thử thủ công nên

có thể phát hiện và xử lý những tình huống phát trình trong quá trình kiểm thử Và có thể tìm ra lỗi mới

Không linh động vì kiểm thử theo script kiểm thử hiệu năng và tải trọng nên quá trình kiểm thử không phát hiện

ra lỗi mới Chỉ thích hợp với kiểm thử hồi quy

13 | P a g e

Phụ

thuộc

Phụ thuộc vào trạng thái của con

người nên kết quả test có thể kém

chính xác đối với dự án lớn có nhiều

ca kiểm thử

Nhất quán, nên kết quả kiểm thử là chính xác và không phụ thuộc vào yếu

tố ngoại cảnh

trình kiểm thử sẽ tìm đc ra lỗi mới

Kiểm thử tự động thích hợp cho việc kiểm thử lặp đi lặp lại, có thể tái sử dụng test Script Thích hợp giả lập kiểm thử hiệu năng, chịu tải cũng như giả lập hệ thống kiểm thử

kiểm thử 1 chức năng lặp đi lặp lại

thì sẽ tốn nhiều thời gian, khó chính

xác, khó tối ưu tài nguyên máy tính

Nếu sử dụng kiểm thử tự động mà kiểm thử ít sẽ rất lãng phí thời gian và nhân lực

Bảng 1 So sánh kiểm thử thủ công và kiểm thử tự động

14 | P a g e

B THỰC HÀNH KIỂM THỬ THỦ CÔNG Kiểm thử thủ công trên chức năng tính lương nhân sự

I Phát biểu bài toán

1 Mô tả bài toán

Xây dựng chương trình mô phỏng chức năng tính lương cho nhân viên của công ty TNHH Công nghệ và Thương mại Mai Sơn Nhân viên phòng nhân sự cần nhập vào hình thức làm việc: bán thời gian - part time (4 tiếng/ngày) hoặc giờ hành chính - fulltime (8 tiếng/ngày),

số giờ công thực tế với nhân viên part time hoặc số ngày công thực tế với nhân viên full time Đối với nhân viên full time, lương cơ bản dựa trên hợp đồng, sẽ nhập thêm số giờ tăng ca (nếu có)

Hệ thống sẽ tính toán và hiển thị mức lương cho nhân viên dựa trên các yêu cầu sau:

Với nhân viên part time, một tháng làm tối đa 120 giờ, với tiền lương 25.000/giờ

Với nhân viên fulltime, số ngày công thực tế không quá số ngày công tiêu chuẩn là 26

Nhân viên có thể tăng ca và không tăng ca quá 40 giờ/tháng, lương một giờ = lương cơ bản/ ( 8 * số ngày công tiêu chuẩn), mỗi tiếng tăng ca sẽ tăng thêm 15% Đối với tiền phụ cấp, nhân viên sẽ được nhận phụ cấp là 500.000 bao gồm chi phí xăng xe và ăn trưa cho

26 ngày Nếu làm dưới 26 ngày thì tính theo công thức: = (số ngày làm việc/số ngày công tiêu chuẩn) *500.000 Lương cơ bản nhân viên tùy thuộc vào hợp đồng Tiền lương nhân viên được tính như sau:

Lương thực lĩnh = lương cơ bản * (số ngày công thực tế/số ngày công tiêu chuẩn) + lương tăng ca + phụ cấp

Chương trình in ra màn hình kết quả là lương nhân viên nhận được khi đảm bảo đủ các điều kiện hoặc thông báo giá trị nhập chưa đúng đến người dùng

Ảnh 2 Mô tả bài toán

15 | P a g e

- Số giờ tăng ca (đối với nhân viên full time)

Output: Mức lương nhân viên hoặc giá trị không đúng quy định

Điều kiện tính lương:

a, Nếu là nhân viên part time:

- 0 < số giờ công thực tế =< 120 giờ

- tiền lương = 25.000 * số giờ

b, Nếu là nhân viên full time:

Số ngày công tiêu chuẩn là 26

Phụ cấp: 500.000/tháng (chuyên cần, xăng xe, ăn uống)

Tiền lương = lương cơ bản * số ngày công thực tế/ số ngày công tiêu chuẩn + số tiền tăng

ca + tiền phụ cấp

o <= lương cơ bản = < 20 triệu/tháng

o 20 <= số ngày công thực tế = < 26 ngày

o 0 =< số giờ tăng ca = < 40 tiếng, mỗi tiếng tăng ca tăng thêm 15% lương/giờ

o Tiền tăng ca = số giờ * 1.15 * (lương cơ bản/ (số ngày công tiêu chuẩn * 8)

o Tính tiền phụ cấp = 500000/số ngày công tiêu chuẩn * số ngày công thực tế

Hệ thống kiểm tra các giá trị đầu vào: [giờ công] hoặc [lương cơ bản >> Ngày công thực

tế >> giờ tăng ca] và thông báo lỗi với giá trị xảy ra lỗi đầu tiên

c, Miền xác định đầu vào

- Hình thức làm việc: boolean: (0)- partime (1)-fulltime

- Giờ công thực tế (0;120]

- Lương cơ bản: số thực; đơn vị: nghìn đồng; miền xác định [1.000; 20.000]

- Ngày công thực tế: kiểu số nguyên, miền xác định: part time fulltime [20; 26]

- Số giờ tăng ca: số thực (giờ) miền giá trị [0;40]

d, Miền giá trị đầu ra

- Tiền lương: kiểu số thực

Đơn vị: nghìn đồng

Miền giá trị đối với nhân viên fulltime: [1153.23; 24923.1]

Miền giá trị đối với nhân viên partime: (0; 3000]

- Thông báo giá trị không đúng quy định

II Code của chương trình

1 Ngôn ngữ lập trình và thư viện sử dụng

16 | P a g e

usingnamespace std;

int main(intargc, char** argv) {

bool ht(true);

int ngaycong, giocong;

float giotangca, luongtangca, phucap;

float luongcoban, luongthuclinh;

cout << " -CHUONG TRINH TINH LUONG NHAN VIEN -"<< endl; cout << "Nhap hinh thuc lam viec cua nhan vien " << endl << "Neu la nhan vien part time: Chon (0)" << endl << "Neu la nhan vien fulltime: Chon (1) " << endl; cout << "chose: "; cin >> ht;

cout <<"Ngay cong khong hop le!"; }

else {

if (0 <= giotangca && giotangca <= 40) {

luongtangca = giotangca * 1.15 * (luongcoban / 208); phucap = 500 * ngaycong / 26;

luongthuclinh = luongcoban * ngaycong / 26 + luongtangca + phucap;

cout <<"Tien luong nhan vien fulltime la: "<<

luongthuclinh <<" nghin dong";

else cout <<"Luong co ban khong nam trong gia tri cho phep!"; }

2 Chiến lược kiểm thử

Kiểm thử chức năng tính lương hoạt động chính xác bằng việc thực hiện kiểm thử thủ công dựa trên 6 kỹ thuật kiểm thử (thiết kế kiểm thử UC, kiểm thử biên, phân hoạch tương đương, bảng quyết định, dòng điều khiển và dòng dữ liệu) đưa vào các dữ liệu hợp

lệ và không hợp lệ để xác nhận: kết quả mong đợi khi xảy ra với dữ liệu hợp lệ, thông báo lỗi xuất hiện khi nhập vào dữ liệu không hợp lệ Tiêu chí hoàn thành: các testcase đều được thực hiện và các lỗi có thể xác định được đề cập

3 Tiêu chí đảm bảo đầu ra

o Run rate: Tỷ lệ giữa số các trường hợp kiểm thử được thực hiện/tổng số trường hợp kiểm thử của đặc tả kiểm thử đạt 100%

o Pass rate: tỷ lệ giữa số lượng các trường hợp kiểm thử pass/số lượng các trường hợp kiểm thử được thực hiện đạt trên 85%

4 Quy trình thực hiện

o Chuẩn bị các trường hợp, kịch bản cần kiểm tra

18 | P a g e

o Thiết kế các test case và số liệu cho quá trình kiểm thử

o Thực thi các trường hợp kiểm thử và kiểm tra kết quả

o Kiểm tra lại sau khi sửa lỗi

o Xây dựng kế hoạch kiểm thử

o Đánh giá test case và test data

o Kiểm tra báo cáo kết quả dự án

Máy kiểm thử Laptop Dell, Acer, …

Những cấu hình cụ thể cần thiết RAM tối thiểu: 4GB DDR3

Ổ cứng tối thiểu: 500GB HDD và 128GB SSD

19 | P a g e

CPU tối thiểu: Core i5, tốc độ từ 2.5 GHz trở lên Màn hình: 15.6 inch trở lên

Yêu cầu về phần mềm

Hệ điều hành Window 10 (64 bit) trở lên

Phần mềm hỗ trợ Dev C++

Visual Studio Visual Code

7 Phân công công việc

Người lập: Minh Nguyệt

1 Thiết kế kiểm

thử

Thiết kế Use Case Hằng Nga 15/10

3 Kiểm thử phân hoạch tương đương Đỗ Ngọc 15/10

20 | P a g e

8 Thực hiện

kiểm thử

8 Các tài liệu báo cáo kiểm thử

1 Kế hoạch

kiểm thử

Tài liệu này cần được lập bởi test leader trước khi kiểm thử

2 Test Case Mô tả các trường hợp

3 Test report Khi kiểm thử hết một vòng hoặc trước khi kết thúc dự án cần cho ra

báo cáo tổng kết quá trình đánh giá trình bày tổng kết về kết quả kiểm thử và đánh giá hệ thống

IV Thiết kế kiểm thử

1 Thiết kế dựa trên mô tả ca sử dụng

1.1 Mô tả ca sử dụng

Ảnh 3 Biểu đồ UC chức năng tính lương

21 | P a g e

STT Use-Case Name: Tính lương R1 – Quan trọng

1 Tác nhân chính: Nhân viên kế toán

2 Mục tiêu:

Ca sử dụng tính lương được thực hiện bởi người dùng (nhân viên kế toán) trong

hệ thống Sau khi vào chương trình, người dùng có thể chọn hình thức làm khác nhau để sử dụng chức năng tính lương của hệ thống

3 Mô tả hoạt động:

Người dùng vào chương trình tính lương Sau đó chọn hình thức làm partime hoặc fulltime để thực hiện chức năng tính lương cho từng hình thức làm

4 Ngoại lệ/ràng buộc để thực hiện:

Người dùng là nhân viên kế toán có phần mềm Dev C hoặc Visual Studio sử dụng đoạn code tính lương

5 Mối quan hệ

- Có liên quan đến Nhân viên toàn bộ công ty

- Có liên quan đến Ban Giám đốc

- Có liên quan đến lập báo cáo tiền lương

6 Luồng sự kiện chính:

1 Nhân viên vào phần mềm có chương trình tính lương

2 Chọn chức năng tính lương và gọi UC tương ứng

3 Hệ thống thông báo tiền lương

4 Kết thúc ca sử dụng

2.2.1 Người dùng nhập lương cơ bản của nhân viên

2.2.2 Người dùng nhập số ngày công thực tế của nhân viên

2.2.3 Người dùng nhập số giờ tăng ca của nhân viên

2.2.4 Hệ thống thực hiện tính lương

2.2.5 Hệ thống hiển thị tiền lương của nhân viên fulltime

2.2.6 Kết thúc ca sử dụng

8 Ngoại lệ

Rẽ nhánh A1 Người dùng nhập giờ công của nhân viên parttime không hợp lệ

Hệ thống hiển thị "Số giờ không đúng quy định!"

Rẽ nhánh A2 Người dùng nhập lương cơ bản của nhân viên fulltime không hợp

lệ

Hệ thống hiển thị "Lương cơ bản không đúng quy định"

Rẽ nhánh A3 Người dùng nhập số ngày công thực tế của nhân viên fulltime

Hệ thống hiển thị "Ngày công thực tế không đúng quy định"

Rẽ nhánh A4 Người dùng nhập số giờ tăng ca của nhân viên fulltime

Hệ thống hiển thị "Số giờ tăng ca không đúng quy định"

Bảng 2 UC description 1.2 Các trường hợp kiểm thử theo kịch bản hành vi

23 | P a g e

2.1.1 Nhập giờ công nhân viên

partime (0; 120]

Người dùng có thể nhập giờ công nhân viên

2.1.3 Hệ thống hiển thị tiền lương

nhân viên partime

Hiển thị thành công và tiền lương chính xác

2.2 Chọn nhân viên fulltime Thành công

2.2.1 Nhập lương cơ bản của nhân

viên [1000 - 20000]

Người dùng có thể nhập lương

cơ bản nhân viên

2.2.2 Nhập số ngày công thực tế của

nhân viên [20;26]

Người dùng có thể nhập số ngày công thực tế nhân viên

2.2.3 Nhập số giờ tăng ca của nhân

viên [0;40]

Người dùng có thể nhập số giờ tăng ca của nhân viên

2.2.5 Hệ thống hiển thị tiền lương

A1 Nhập giờ công nhân viên

của nhân viên fulltime

Hệ thống hiển thị "Ngày công thực tế không đúng quy định"

A4 Nhập số giờ tăng ca của nhân

viên fulltime

Hệ thống hiển thị "Số giờ tăng ca không đúng quy định"

Bảng 4 Kịch bản hành vi rẽ nhánh

2 Kiểm thử giá trị biên

2.1 Kiểm thử giá trị biên - miền xác định

Phương pháp lấy giá trị biên: min, min – 1, min +1, max, max – 1, max + 1, mean Hình thức

mean =

10000 Giờ tăng