Nghiên cứu vận dụng kỹ thuật kiểm thử phần mềm dựa trên uml cho hệ thống quản lý thiết bị tại trường đại học kinh tế đại học đà nẵng

2 Mục tiêu nghiên cứu Mục tiêu của luận văn nghiên cứu được về kiểm thử phần mềm vào việc kiểm thử chức năng của một chương trình, để thực hiện được mục tiêu này thì cần phải đạt được n

ỌC ẴNG TRƯỜ G I HỌC SƯ P M

PHAN THẾ NHẬT

NGHIÊN CỨU VẬN DỤNG KỸ THUẬT KIỂM THỬ PHẦN MỀM DỰA TRÊN UML CHO HỆ THỐNG QUẢN LÝ THIẾT BỊ T TRƯỜ G I HỌC

KINH TẾ - I HỌC ẴNG

UẬ V T C S Ỹ THUẬT NGÀNH HỆ THỐNG THÔNG TIN

à ẵng - 2023

ỌC ẴNG TRƯỜ G I HỌC SƯ P M

PHAN THẾ NHẬT

NGHIÊN CỨU VẬN DỤNG KỸ THUẬT KIỂM THỬ PHẦN MỀM DỰA TRÊN UML CHO HỆ THỐNG QUẢN LÝ THIẾT BỊ T TRƯỜ G I HỌC

LỜ CA OA

Tôi xin cam đoan rằng đây là luận văn nghiên cứu của tôi, có sự hỗ trợ từ giáo viên hướng dẫn là TS Nguyễn Đình Lầu Các nội dung nghiên cứu và kết quả trong luận văn này là trung thực Những số liệu trong các bảng biểu phục vụ cho việc phân tích, nhận xét, đánh giá được tôi thu thập từ các nguồn khác nhau có ghi trong phần tài liệu tham khảo Ngoài ra, đề tài còn sử dụng một số nhận xét, đánh giá cũng như số liệu của các tác giả, cơ quan tổ chức khác, và cũng được thể hiện trong phần tài liệu tham khảo

Nếu phát hiện có bất kỳ sự gian lận nào tôi xin hoàn toàn chịu trách nhiệm trước Hội đồng, cũng như kết quả luận văn của mình

Đà Nẵng, ngày 11 tháng 2 năm 2023

Học viên

PHAN THẾ NHẬT

LỜI CẢ Ơ

Để hoàn thành chương trình cao học và viết luận văn này, em đã nhận được sự giúp đỡ và đóng góp nhiệt tình của các thầy cô trường Đại học Sư phạm, Đại học

Đà Nẵng

Trước hết, em xin chân thành cảm ơn các thầy cô trong Khoa Tin học, Đại học

Sư phạm - Đại học Đà Nẵng đã tận tình giảng dạy, trang bị cho em những kiến thức quý báu trong suốt khóa học cao học vừa qua Em xin gửi lời biết ơn sâu sắc tới TS Nguyễn Đình Lầu đã dành rất nhiều thời gian và tâm huyết hướng dẫn, chỉ bảo em trong suốt quá trình thực hiện đề tài

Xin chân thành cảm ơn gia đình, bạn bè đã nhiệt tình ủng hộ, giúp đỡ, động viên cả về vật chất lẫn tinh thần trong thời gian học tập và nghiên cứu

Trong quá trình thực hiện luận văn, mặc dù đã rất cố gắng nhưng cũng không tránh khỏi những thiếu sót Kính mong nhận được sự cảm thông và tận tình chỉ bảo của các thầy cô và các bạn

MỤC LỤC

LỜ CA OA i

LỜI CẢ Ơ ii

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT vi

DANH MỤC CÁC BẢNG vii

DANH MỤC HÌNH ẢNH viii

MỞ ẦU 1

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

2 Mục tiêu nghiên cứu 1

3 Đối tượng nghiên cứu 2

3.1 Đối tượng nghiên cứu 2

3.2 Phạm vi nghiên cứu 2

4 Phương pháp nghiên cứu 2

4.1 Nghiên cứu lý thuyết 2

4.2 Nghiên cứu thực nghiệm 2

5 Ý nghĩa khoa học thực tiễn của đề tài 2

6 Bố cục luận văn 3

C ƢƠ G 1 TỔNG QUAN VỀ PHÂN TÍCH THIẾT KẾ VÀ KIỂM THỬ PHẦN MỀM 4

1.1 Phát triển hệ thống phần mềm với ngôn ngữ UML 4

1.2 Khái niệm, chức năng và mục tiêu UML (Unified Modeling Language) 4

1.3 Giới thiệu các biểu đồ trong UML 5

1.4 Mục tiêu và vai trò UML trong phát triển phần mềm 12

1.4.1 Mục tiêu của UML 12

1.4.2 Vài trò của UML 13

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

1.5.1 Kiểm thử là gì? 15

1.5.2 Phân loại kiểm thử phần mềm 16

1.6 Kiểm thử dựa trên UML 19

1.6.1 Các thành phần cấu phần 19

1.6.2 UML và kiểm thử 20

C ƢƠ G 2 KIỂM THỬ PHẦN MỀM VỚI CÔNG CỤ KATALON STUDIO 22

2.1 Khái quát về kiểm thử ứng dụng trên nền tảng web 22

2.1.1 Giới thiệu ứng dụng web 22

2.1.2 Các kiểu ứng dụng web 22

2.1.3 Đặc điểm về chất lượng của một ứng dụng dạng web 23

2.1.4 Quy trình kiểm thử ứng dụng web hoặc phần mềm 23

2.1.5 Sự ảnh hưởng của nghiêm trọng ở các mức độ khác nhau do lỗi xây dựng phần mềm gây ra 24

2.2 Kiểm thử tự động và thủ công 25

2.2.1 Khái niệm 25

2.2.2 Đặc điểm 25

2.3 Các kiểu kiểm thử web 26

2.3.1 Kiểm thử chức năng 26

2.3.2 Kiểm thử khả năng sử dụng 27

2.3.3 Kiểm thử sự tương thích 28

2.3.4 Kiểm thử hiệu xuất 28

2.3.5 Kiểm thử bảo mật 29

2.4 Giới thiệu các công cụ hỗ trợ kiểm thử ứng dụng web 29

2.4.1 Công cụ kiểm thử hiệu năng 29

2.4.2 Công cụ kiểm thử bảo mật 29

2.4.3 Công cụ kiểm thử chức năng 30

2.5 Công cụ kiểm thử Katalon Studio 30

2.5.1 Các chức năng chính 31

2.5.2 Làm việc với Katalon Studio 31

2.6 So sánh Katalon Studio với các công cụ khác 32

2.6.1 Ưu và nhược điểm của Katalon Studio 36

2.6.2 Đặc trưng của Katalon Studio[7] 37

C ƯƠ G 3 C ẶT CÔNG CỤ KATALON STUDIO VÀ THỰC NGHIỆM KIỂM THỬ C ƯƠ G TRÌ QUẢN LÝ THIẾT BỊ tRƯỜ G I HỌC KINH TẾ 39

3.1 Cài đặt và cấu hình công cụ Katalon Studio[7] 39

3.1.1 Cài đặt 39

3.1.2 Cấu hình 39

3.1 3 Giới thiệu các giao diện cửa sổ làm việc 40

3.1.4 Quy trình làm việc tuyến tính với Katalon Studio: 42

3.1.5 Cách viết một kịch bản test với Katalon Studio 43

3.2 Kiểm thử chương trình Quản lý thiết bị 45

3.2.1 Mô tả chương trình 45

3.2.2 Phân tích thiết kế bài toán trên cơ sở UML 46

3.2.2.1 Quy trình xây dựng tài liệu kiểm thử dựa trên mô hình UML 46

3.2.3 Thực nghiệm kiểm thử chương trình Quản lý thiết bị 47

3.2.3.1 Xây dựng mô hình use case với bài toán thực tế 47

3.2.3.2 Xây dựng luồng nghiệp vụ trên cơ sở tiếp cập hệ thống chức năng 47

3.2.3.3 Sinh ca kiểm thử 49

a Kiểm thử chức năng Đăng nhập hệ thống 49

b Kiểm thử chức năng Quản lý thiết bị 53

b.1 Chức năng Thêm mới thiết bị 53

b.2 Chức năng Sửa thông tin thiết bị 56

b.3 Chức năng Xóa thiết bị 58

3.3 Kết quả đạt được sau khi kiểm thử 59

TÀI LIỆU THAM KHẢO 61

PHỤ LỤC 62

DANH MỤC CÁC KÝ HIỆU, CHỮ VIẾT TẮT

MTM Microsoft Test Manager

API Application Programming Interface

IT Integration Testing

CSV Comma-Separated Values

SCM Software Configuration Management

QTP Quick Test Professional

actor Tác nhân

Black box Hộp đen

BVA Giá trị biên

CNTT Công nghệ thông tin

IBM Tên công ty máy tính

script Kịch bản

UC Biểu đồ UC (Use case diagrams)

UML Ngôn ngữ mô hình hóa tổng quát

White box Hộp trắng

IDE Integrated Development Enveironment

DANH MỤC CÁC BẢNG

Số ệu

2.1 Bảng phân loại mức độ nghiêm trọng của lỗi 25 2.2 Ưu điểm và nhược điểm công cụ Katalon Studio 26 2.3 So sánh tính năng Katalon Studio với công cụ khác 34 2.4 So sánh ưu nhược điểm của Katalon Studio với công cụ khác 35

3.2 Danh sách trình duyệt hỗ trợ Katalon Studio 40

1.9 Mô tả biểu đồ hoạt động thanh lý thiết bị 9 1.10 Mô tả biểu đồ gói hệ thống mua sắm online 10

1.13 Biểu đồ thời gian UML xác định hành vi của các đối tượng 12 1.14 Biểu đồ tương tác của hệ thống đăng ký thành viên 12

2.2 So sánh chi phí kiểm thử tự động và kiểm thử thủ công 26

Số hiệu

3.8 Biểu đồ trình tự cho ca sử dụng thêm mới thiết bị 48 3.9 Giao diện đăng nhập hệ thống quản lý thiết bị 49

3.11 Viết lệnh ca kiểm thử đăng nhập thành công 51

3.13 Thời gian thực thi case kiểm thử đăng nhập thành công 52

3.15 Màn hình các lệnh ca kiểm thử đăng nhập không thành công 52 3.16 Tiến trình kiểm thử test case không thành công 52 3.17 Thời gian thực thi ca kiểm thử không thành công 53 3.18 Báo cáo sau khi hoàn thành ca kiểm thử không thành công 53

3.20 Sơ đồ hoạt động chức năng thêm thiết bị 54 3.21 Đoạn lệnh thực ca kiểm thử thêm mới thiết bị 55 3.22 Thời gian xử lý ca kiểm thử thêm mới thiết bị 56 3.23 Sơ đồ mô tả chức năng chỉnh sửa thông tin thiết bị 56 3.24 Đoạnh lệnh ca kiểm thử sửa thông tin thiết bị 57

Số hiệu

3.25 Thời gian test ca kiểm thử chỉnh sửa thông tin thiết bị 58

MỞ ẦU

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

Tất cả các quy trình phát triển phần mềm đều trải qua các bước từ xác định yêu cầu, phân tích, xây dựng, kiểm thử, cho tới triển khai và bảo trì Trong đó kiểm thử là một khâu không thể thiếu trong quá trình phát triển phần mềm Nhiều hệ thống phần mềm thất bại do lỗi không được tìm ra Kiểm thử phần mềm là một công việc khá phức tạp, tốn nhiều công sức Quá trình kiểm thử sẽ gồm một số pha kết hợp trong đó như: kiểm thử đơn vị, kiểm thử chức năng, kiểm thử hệ thống, kiểm thử hồi quy và kiểm thử giải pháp Như vậy, kiểm thử phần mềm là điều kiện tiên quyết cho một sản phẩm phần mềm có chất lượng tốt

Do đặc thù của các trường Đại học nói chung và trường Đại học Kinh tế, Đại học Đà Nẵng nói riêng, khối lượng tài sản khá lớn nhưng giá trị tài sản phần lớn là thấp và nó thuộc về công cụ, dụng cụ… nên cần thiết phải có một hệ thống đáp ứng được các yêu cầu nghiệp vụ của hoạt động quản lý cơ sở vật chất theo yêu cầu đặt ra của nhà trường Mặc khác Nhà trường đã được triển khai mềm Quản lý công sản do Đại học Đà Nẵng quản lý, trường Đại học Kinh tế là thành viên của Đại học Đà Nẵng đã thực hiện tự chủ tài chính nên việc sở hữu một phần mềm riêng để quản lý

Cơ sở vật chất của nhà trường là điều tất yếu và cần thiết khi cần đối chiếu nhằm tránh thánh thoát tài sản

Xuất phát từ những lý do trên, tác giả đề xuất lựa chọn đề tài “Nghiên cứu vận dụng kỹ thuật kiểm thử phần mềm dựa trên UML cho hệ thống quản lý thiết bị tạ trườn ại học Kinh tế - ại họ à ẵng” làm đề tài tốt nghiệp luận

văn cao học

2 Mục tiêu nghiên cứu

Mục tiêu của luận văn nghiên cứu được về kiểm thử phần mềm vào việc kiểm thử chức năng của một chương trình, để thực hiện được mục tiêu này thì cần phải đạt được những mục tiêu sau:

- Nắm vững các kỹ thuật kiểm thử chức năng các ứng dụng

- Nghiên cứu công cụ kiểm thử Katalon Studio để thiết kế kịch bản kiểm thử

tự động

- Tìm hiểu và đề xuất được các giải pháp giải quyết bài toán kiểm thử chức năng

- Tiến hành thu thập và nghiên cứu các tài liệu có liên quan đến đề tài

- Nghiên cứu lý thuyết kiểm thử phần mềm nói chung và kỹ thuật kiểm thử tự động nói riêng

- Vận dụng công cụ và cách thiết kế các kịch bản kiểm thử trong Katalon Studio

4.2 n ứu t ự n ệm

- Nghiên cứu và khai thác công cụ phần mềm Katalon Studio

- Cài đặt chương trình phần mềm cụ thể để thực hiện viết kịch bản kiểm thử

- Kiểm tra, thử nghiệm, nhận xét và đánh giá kết quả

5 Ý n ĩ o ọc thực tiễn củ đề tài

Kết quả nghiên cứu có thể làm tài liệu tham khảo cho các đơn vị phát triển phần mềm đang cần tiến hành kiểm thử các chương trình có sử dụng giao diện đồ họa

Về mặt lý thuyết: sẽ cung cấp một cách nhìn tổng quát về quá trình xây dựng

và thiết kế phần mềm theo hướng đối tượng, nắm được kiến thức về kiểm thử phần mềm, các loại kiểm thử phần mềm và công cụ hỗ trợ việc kiểm thử

Về mặt thực nghiệm: cung cấp một quy trình kiểm thử tự động cho các ứng

dụng sử dụng công cụ Katalon Studio để nâng cao hiệu quả công việc cho nhân viên kiểm thử

6 Bố cục luận văn

C ươn 1 Tổng quan về phân tích thiết kế và kiểm thử phần mềm

Chương này giới thiệu tổng quan về kiến thức thiết kế phần mềm UML, kiểm thử phần mềm, các giai đoạn kiểm thử Ưu điểm và nhược điểm của từng loại

C ươn 2 Kiểm thử phần mềm với công cụ Katalon Studio

Giới thiệu chi tiết về công cụ kiểm thử Katalon Studio, cùng với các ưu và nhược điểm cũng như hạn chế Công việc kiểm thử có rất nhiều việc khác nhau, để

hỗ trợ cho các kiểm thử viên, đã có nhiều công cụ ra đời Trong chương này sẽ tìm hiểu rõ hơn về công cụ Katalon Studio và các thành phần tích hợp vào nó

C ươn 3 Cà đặt công cụ Katalon Studio và thực nghiệm kiểm thử với ươn trìn quản lý thiết bị trườn ại học Kinh tế

Trong chương này chúng ta sẽ áp dụng những kiến thức được tìm hiểu ở chương 2 để tiến hành kiểm thử ứng dụng thực tế và dựa vào kết quả đạt được để đưa ra kết luận

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

C ƢƠ G 1 TỔNG QUAN VỀ PHÂN TÍCH THIẾT KẾ VÀ

KIỂM THỬ PHẦN MỀM 1.1 Phát triển hệ thống phần mềm với ngôn ngữ UML

Các hệ thống thường được phát triển theo hai cách:

 Phương pháp lập trình có cấu trúc

 Phương pháp lập trình hướng đối tượng

P ƣơn p áp lập trìn ƣớng cấu trúc: Chia dự án thành các chức năng,

mỗi chức năng cần được gải quyết thành các chức năng nhỏ hơn và xử lý chúng Điểm yếu của chức năng này là phụ thuộc thuộc vào dự án

P ƣơn p áp lập trìn ƣớn đố tƣợng: Có nhiều ưu điểm và tránh được

nhược điểm so với phương pháp lập trình cấu trúc phương pháp lập trình hướng đối tượng là phương pháp phát triển phần mềm dựa trên mô hình hệ thống

Có nhiều ngôn ngữ lập trình và công cụ phân tích thiết kế hướng đối tượng, trong công việc này, tôi sử dụng phân tích thiết kế dựa trên mô hình UML

1.2 Khái niệm, chứ năn và mục tiêu UML (Unified Modeling Language)

Khái niệm: UML là một ngôn ngữ mô hình hoá thống nhất có phần chính bao gồm những ký hiệu hình học, được các phương pháp hướng đối tượng sử dụng để thể hiện và miêu tả các thiết kế của một hệ thống UML có thể được sử dụng làm công cụ giao tiếp giữa người dùng, nhà phân tích, nhà thiết kế và nhà phát triển phần mềm

Ngôn ngữ UML tập hợp hàng loạt các phần tử đồ họa, chúng được kết hợp với nhau để tạo ra một biểu đồ Chính vì thế ngôn ngữ UML cũng có các nguyên tác để kết hợp các phần tử đó lại với nhau

Có bốn thành phần cở bản và chủ yếu của ngôn ngữ UML:

 Hướng nhìn (view): chỉ ra các khía cạnh khác nhau trong hệ thống mà chúng

ta cần phải mô hình hóa chúng Không chỉ là là bản vector, mà là một sự trừu tượng hóa bao gồm các biểu đồ khác nhau.Cũng chính từ các hướng nhìn này

nó kết nối các ngôn ngữ mô hình hóa lại với quy trình được chọn cho các giai đoạn phát triển

 Biểu đồ (diagram): miêu tả các nội dung bên trong một hương nhìn UML có tất cả 9 loại biểu đồ khác nhau được sử dụng trong những sự kết hợp khác nhau để cung cấp tất cả các hướng nhìn của một hệ thống

 Phân tử mô hình hóa (model element): tất cả các khái niệm được dung trong các biểu đồ gọi là các phần tử mô hình, thể hiện các đối tượng quen thuộc

 Cơ chế chung: chỉ nhận xét các thông tin cũng như thực hiện các quy tắc ngữ pháp chung về một phần tử mô hình; ngoài ra chúng còn cung cấp thêm các

cơ chế mở rộng ngôn ngữ UML cho phù hợp với phương pháp xác định

1.3 Giới thiệu các biểu đồ trong UML

Biểu đồ là các hình vẽ bao gồm các ký hiệu phần tử mô hình hóa sắp xếp để minh họa cho một thành phần cụa thể hay một khía cạnh cụ thể của hệ thống

Có 12 biểu đồ do UML cung cấp để miêu tả cấu trúc và thiết kế hệ thống trong phần mềm như sau:

Biểu đồ UC (Use case diagrams): Biểu đồ này chỉ ra một số tác nhân ngoại cảnh và các mối liên kết của chúng đối với một use case hệ thống cung cấp Các use case được miêu tả duy nhất theo hướng nhìn từ ngoài vào của các tác nhân) hành vi

hệ thống theo sự mong đợi của người dung)

Tác nhân (actor): chỉ người dùng của hệ thống tác nhân này có thể là người dùng thực cũng có thể là các hệ thống máy tính Có thể hiểu một actor có thể thực hiện được một use case và ngược lại

Ký hiệu tác nhân:

hoặc

Hình 1.1 Các ký hiệu đồ họa của biểu đồ Use Cases

Một biểu đồ UC có thể được vẽ cho bất cứ hệ thống phần mềm Ví dụ trong hệ thống xử lý đặt hàng, phòng Cở sở vật chất đưa yêu cầu tới công ty ngoài Trong trường hợp này, phòng Cơ sở vật chất là một tác nhân sử dụng hệ thống để đặt hàng cho các bộ phận Tương tự, phòng Cơ sở vật chất cũng nhận nguồn cung cấp để cập

nhật kho Các UC cho Actor phòng Cơ sở vật chất (Facility Department) là đặt hàng (Order Parts) và nhận nguồn cung cấp (Accept Supply)

Hình 1.2 UC cho hệ thống xử lý đặt hàng

Biểu đồ lớp (Class diagrams): một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp

hệ thống Là tập hợp các đối tượng cùng nhau chia sẽ vè các thuộc tính, thao tác,quan hệ và ngữ nghĩa

Người ta có thể vẽ biểu đồ lớp bằng cách nhận biết các lớp trong hệ thống Ví dụ: Xác định thuộc tính lớp khách hàng có các trường cơ bản như: Mã khách hàng, tên khách hàng, địa chỉ, điện thoại, …

Hình 1.3 Biểu đồ lớp cho một hệ thống bán hàng

Biểu đồ đối tượng (Object diagrams): là biểu đồ miêu tả một phiên làm việc của biểu đồ lớp và thường được sử dụng các ký tự như biểu đồ lớp Sự khác biệt giữa hai loại biểu đồ này nằm ở chỗ biểu đồ đối tượng chỉ ra một loạt các đối tượng thực thể của lớp, thay vì các lớp

Hình 1.4 Các ký hiệu minh họa cho biểu đồ đố tƣợng

Có thể vẽ biểu đồ đối tượng bằng cách nhận biết lớp trong hệ thống

Hình 1.5 Biểu đồ đố tƣợng minh họa cho hệ thống xử lý đặt hàng

Biểu đồ giao tiếp (Communication diagrams): mô tả sự tương tác giữa các đối tượng bằng thông điệp

Hình 1.6 Biểu đồ giao tiếp cho hệ thống xử lý đặt hàng

Biểu đồ trình tự (Sequence diagrams): chỉ ra một tác động giữa một loạt các đối tượng bằng thông điệp thứ tự thời gian, các đối tượng được biểu diễn bằng các đường thẳng đứng Trục thời gian có hướng từ trên xuống dưới trong biểu đồ, và biểu đồ chỉ ra sự trao đổi thông điệp giữa các đối tượng khi thời gian trôi qua Các thông điệp này được biểu diễn bằng các đường gạch ngang gắn liền với mũi tên

(biểu thị thông điệp) nối liền giữa những đường thẳng đứng thể hiện đối tượng Trục thời gian cùng những lời nhận xét khác thường sẽ được đưa vào biểu đồ

Hình 1.7 Biểu đồ tuần tự cho hệ thống xử lý đặt hàng

Biểu đồ trạng thái (State Machine diagrams): Nó chỉ ra tất cả các trạng thái mà đối tượng của lớp này có thể có, và những sự kiện (event) nào sẽ gây ra sự thay đổi trạng thái Chúng ta có thể vẽ biểu đồ trạng thái bằng cách sử dụng các lớp và các

UC được nhận biết bởi hệ thống

Hình 1.8 Mô tả về biểu đồ trạng thái

Biểu đồ hành động (Activity diagrams): chỉ ra dòng hoạt động của hệ thống, bao gồm các trạng thái hoạt động, trong đó từ một trạng thái hoạt động sẽ chuyển sang trạng thái khác sau khi một hoạt động tương ứng được thực hiện Nó chỉ ra trình tự các bước, tiến trình thực hiện cũng như các điểm quyết định và sự rẽ nhánh theo luồng sự kiện

Hình 1.9 Mô tả biểu đồ hoạt động thanh lý thiết bị

Biểu đồ gói (Package Diagrams): mô tả tất cả các lớp và giao tiếp có quan hệ với nhau của hệ thống gom nhóm cùng nhau vào một gói Để miêu tả rõ hơn về các lớp và giao tiếp có liên quan với nhau, UML cung cấp biểu đồ gói Biểu đồ gói giúp việc miêu tả các gói khác nhau trong hệ thống phần mềm và mối quan hệ phụ thuộc giữa chúng

Hình 1.10 Mô tả biểu đồ gói hệ thống mua sắm online

Biểu đồ thành phần (Component diagrams): chỉ ra cấu trúc vật lý của các thành phần trong hệ thống, bao gồm: các thành phần mã nguồn, mã nhị phân, thư viện và các thành phần thực thi

Hình 1.11 Mô tả biểu đồ thành phần hệ thống ATM

Biểu đồ triển khai (Deployment diagrams): chỉ ra cách bố trí vật lý các thành phần theo kiến trúc được thiết kế của hệ thống.Biểu đồ triển khai có thể sử dụng để chỉ ra các thành phần nào có thể chạy trong node nào

Hình 1.12 ô tả b ểu đồ tr ển ệ t ốn n

Biểu đồ thời gian (Timing Diagrams): thường được sử dụng để miêu tả sự thay đổi trạng thái và giá trị của một hoặc nhiều đối tượng trong một khoảng thời gian Biểu đồ thời gian thường được sử dụng thiết kế phần mềm nhúng

Biểu đồ thời gian có hai loại:

Ký hiệu ngắn gọn (Concise notation)

Ký hiệu dày (Robust notation)

Ký hiệu ngắn gọn (Concise notation): Trong biểu đồ này có giá trị đường sống

mô tả sự thay đổi giá trị của các đối tượng trọng khoảng thời gian Thời gian trôi qua được thể hiện trên trục X và giá trị là được hiển thị bằng các vạch chỉ cho biết

sự thay đổi giá trị

Hình 1.14 Biểu đồ tươn tá ủa hệ thốn đăn ký thành viên

1.4 Mục tiêu và vai trò UML trong phát triển phần mềm

1 4 1 ụ t u ủ U

Có thể nói rằng mô hình là một sự đơn giản hoá hiện thực Mô hình được xây dựng để chúng ta dễ dàng hiểu và hiểu tốt hơn hệ thống cần xây dựng [2]

Nói tóm lại, thông qua mô hình hóa giúp ta mô tả được mặt bản chất của một vấn đề hoặc một cấu trúc phức tạp bằng cách loại bỏ những chi tiết không quan trọng, khiến cho bài toán trở nên dễ hiểu và dễ nắm bắt hơn

Việc biểu diễn mô hình thoả mãn các yếu tố sau:

 Chính xác (accurate): Mô tả đúng hệ thống cần xây dựng

 Đồng nhất (consistent): Các view khác nhau không được mâu thuẫn với nhau

 Có thể hiểu được (understandable): Cho cả người xây dựng lẫn sử dụng

 Dễ thay đổi (changeable)

 Dễ dàng liên hệ với các mô hình khác

Mục đích của UML là cho phép người dùng xác định được mô hình của hệ thống Phần quan trọng của mô hình người dùng là định nghĩa các ngữ nghĩa của hệ thống đang được phát triển Ngôn ngữ mô hình hóa thống nhất biểu diễn mô hình theo hướng đối tượng được xây dựng với mục đích là:

 Mô hình hoá các hệ thống, sử dụng các khái niệm hướng đối tượng

 Thiết lập một kết nối từ nhận thức của con người đến các sự kiện cần mô hình hoá

 Giải quyết vấn đề về mức độ thừa kế trong các hệ thống phức tạp, có nhiều ràng buộc khác nhau

 Tạo một ngôn ngữ mô hình hoá có thể sử dụng được bởi người và máy Cùng với việc sử dụng UML, người dùng tạo ra mô hình ứng dụng Mục tiêu của nó là tạo ra một mô hình hoàn chỉnh, ổn định và chính xác Code có thể tự động tạo ra nếu ta dùng các công cụ như Rhapsody, hoặc công cụ tự viết ra Việc mã code sinh tự động có rất nhiều ưu điểm như giảm nguồn lực và bảo trì tính ổn định giữa

mô hình UML và mã lệnh, cả hai đều dùng để tạo nên hệ thống cuối cùng

1 4 2 Và trò ủ U

UML có thể được sử dụng trong nhiều giai đoạn, từ phát triển, thiết kế cho tới thực thi và bảo trì Vì mục đích chính của ngôn ngữ này là dùng các biểu đồ hướng đối tượng để mô tả hệ thống, nên miền ứng dụng của UML bao gồm nhiều loại hệ

thống khác nhau như: Hệ thống thông tin, hệ thống kỹ thuật, hệ thống nhúng, hệ thống phân bố, hệ thống giao dịch, phần mềm hệ thống

UML có mặt trong hầu hết các giai đoạn phát triển hệ thống:

Nghiên cứu sơ bộ: use cases thể hiện các yêu cầu của người dùng Phần miêu

tả use case xác định các yêu cầu, phần diagram thể hiện mối quan hệ và giao tiếp với hệ thống

Phân tích: Mục đích chính của giai đọan này là trừu tượng hóa và tìm hiểu các

cơ cấu có trong phạm vi bài toán Class diagrams trên bình diện trừu tượng hóa các thực thể ngoài đời thực được sử dụng để làm rõ sự tồn tại cũng như mối quan hệ của chúng Chỉ những lớp (class) nằm trong phạm vi bài toán mới đáng quan tâm

Thiết kế: Kết quả phần analysis được phát triển thành giải pháp kỹ thuật Các lớp được mô hình hóa chi tiết để cung cấp hạ tầng kỹ thuật như giao diện, nền tảng cho database, … Kết quả phần thiết kế (Design) là các đặc tả chi tiết cho giai đoạn xây dựng phần mềm

Phát triển: Mô hình Design được chuyển thành code Lập trình viên sử dụng các UML diagrams trong giai đoạn Design để hiểu vấn đề và tạo code

Kiểm thử: Sử dụng các UML diagrams trong các giai đoạn trước Có 4 hình thức kiểm tra hệ thống:

Kiểm thử đơn vị (class diagrams & class specifications) : kiểm tra từng đơn thể, được dùng để kiểm tra các lớp hay các nhóm đơn thể

Kiểm thử tích hợp (integration diagrams & collaboration diagrams) : kiểm tra tích hợp là kiểm tra kết hợp các cấu phần với các lớp để xem chúng hoạt động với nhau có đúng không

Kiểm thử hệ thống (use-case diagrams) : kiểm tra xem hệ thống có đáp ứng được chức năng mà người dùng yêu cầu hay không

Kiểm thử chấp nhận: Kiểm tra tính chấp nhận được của hệ thống, thường được thực hiện bởi khách hàng, việc kiểm tra này thực hiện tương tự như kiểm tra hệ thống

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

Kiểm thử phần mềm là một trong những khâu quan trọng của quy trình phát triển phần mềm nhằm kiểm tra xem phần mềm làm ra có những lỗi gì cần khắc phục

Kiểm thử không thể chứng minh được phần mềm là hết lỗi mà nó chỉ giúp cho người viết mã nguồn tìm ra và có biện pháp khắc phục càng nhiều lỗi càng tốt Thực chất kiểm thử phần mềm là các cách thức làm việc với máy tính và chương trình, tuy nhiên với những phần mềm lớn, việc kiểm thử cũng yêu cầu có sự phối hợp của nhiều nhóm chuyên môn phụ trách các thành phần riêng biệt, cho nên kiểm thử cũng cần các kĩ năng của con người

Muốn làm tốt công việc thử nghiệm, ngoài việc nắm vững các kỹ thuật thử nghiệm điển hình, người thử nghiệm còn phải phát triển kế hoạch thử nghiệm, chuẩn bị dữ liệu thử nghiệm, chạy thử nghiệm, viết báo cáo kết quả thử nghiệm và biết cách quản lý mọi thứ

Kiểm thử nên được nhìn nhận từ nhiều góc độ khác nhau liên quan đến phần mềm: kiểm thử chức năng, kiểm thử hiệu suất, cấu hình, bảo mật và liên quan đến quá trình kiểm thử: trang web thử nghiệm đơn giản, thử nghiệm tích hợp, thử nghiệm hệ thống, thử nghiệm chấp nhận; Đồng thời, phải quản lý toàn bộ quá trình kiểm thử: ghi nhận tình hình lỗi, sửa chữa, kiểm tra lại

1.5.1 ểm t ử là ì?

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ó đáp ứng đúng với các yêu cầu thiết kế đã đặt ra trước đó hay không Và đảm bảo rằng sản phẩm đó không có lỗi hay các khiếm khuyết nào khác Quá trình kiểm thử nó bao gồm việc kiểm tra phân tích, quan sát và đánh giá từ các khía cạnh khác nhau

Mục đích là xác định các lỗi, khiếm khuyết hoặc các yêu cầu còn thiếu so với yêu cầu thực tế

Qua đó cho chúng ta thấy được tầm quan trọng của việc kiểm thử phần mềm đối với sự phát triển phần mềm Với kiểm thử phần mềm, nếu có bất kỳ lỗi nào, nó

có thể được xác định sớm và giải quyết trước khi giao sản phẩm

Các lợi ích của việc kiểm thử:

Mang lại hiệu quả về mặt chi phí: Đây là một lợi ích quan trọng nhất của khâu kiểm thử phần mềm, thực chất chúng ta có thể thấy rằng các lỗi thiết kế khó có thể loại trừ một cách hoàn toàn đối với bất kỳ hệ thống nào

Bảo mật: Một sản phẩn phần mềm được tạo ra mà không có sự đảm bảo an toàn thông tin cho khách hàng thì sản phẩm đó không mang lại

sự tin cậy cho khách hàng Chính vì vậy, kiểm thử giúp loại bỏ các rủi

ro về vấn đề này trong sản phẩm

Chất lượng sản phẩm: Đây là yêu cầu thiết yếu của bất kỳ sản phẩm phần mềm nào Kiểm thử phần mang lại sự an tâm hơn cho khách hang về chất ượng của một sản phẩm tạo ra

1.5.2 P ân loạ ểm t ử p ần mềm

Kiểm thử phần mềm không phải là một việc đơn lẻ Nó có nhiều hình thức khác nhau và được phân loại theo một số tiêu chí Về cơ bản, kiểm thử phần mềm được chia làm 4 loại:

a Kiểm thử chức năng (Black box):

Một trong những chiến lược kiểm thử quan trọng nhất là kiểm thử hộp đen, theo hướng dữ liệu hoặc đầu vào (đầu ra) Trong thử nghiệm hộp đen, chương trình được coi như một "hộp đen" và nó không quan tâm đến hành vi và cấu trúc bên trong của chương trình Với cách tiếp cận này, việc kiểm tra dữ liệu chỉ được thực hiện từ các thông số kỹ thuật

Các phương pháp kiểm thử hộp đen:

 Phân hoạch tương đương - Equivalence partitioning

 Phân tích giá trị biên - Boundary value analysis

 Kỹ thuật đồ thị nhân quả

 Kiểm thử so sánh

 Kiểm thử dựa trên đặc tả - Specification-base testing

b Kiểm thử so sánh

Kiểm thử so sánh có thể giúp các kỹ sư kiểm thử hiểu được điểm mạnh và yếu của mỗi sản phẩm phần mềm Cách tiếp cận của kiểm thử so sánh nó đều liên quan đến việc so sánh các tập tin và thư mục[4]

Dựa vào ý tưởng đó, các nhà nghiên cứu đã đề xuất phát triển các phiên bản phầm mềm riêng biệt cho các ứng dụng chính, ngay cả khi chỉ một phiên bản được

sử dụng trong hệ thống phân phối Phiên bản độc lập này tạo nền tảng cho các kỹ thuật kiểm tra hộp đen được gọi là đo điểm chuẩn phía sau

Khi có nhiều cài đặt của cùng một đặc tả được tạo ra, các trường hợp kiểm thử được thiết kế để dùng những kĩ thuật hộp đen khác (như phân hoạch tương đương) cũng được áp dụng cho từng bản Nếu các kết quả của mỗi bản là giống nhau thì người ta nhận xét rằng tất cả các cài đặt đều đúng Nếu chúng khác nhau thì từng ứng dụng sẽ được nghiên cứu lại để xác định liệu rằng khiếm khuyết trong một hay nhiều bản có phải là nguyên nhân sinh ra sự khác biệt hay không

Kiểm thử so sánh không phải là hết sức dễ dùng Nếu đặc tả mà từ đó tất cả các bản đã xây dựng bị lỗi thì mọi bản đều có thể phản ánh lỗi đó Bên cạnh đó, nếu từng bản độc lập lại tạo ra kết quả giống nhau, nhưng không đúng, thì việc kiểm thử điều kiện sẽ không phát hiện được lỗi

c Kiểm thử dựa trên đặc tả[4]

Tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn

Ưu, nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản là: một mã lệnh phải có lỗi Sử dụng nguyên tắc “Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên

đã không tìm ra Hay nói cách khác, người ta cũng nói kiểm thử hộp đen “giống như

là đi trong bóng đêm mà không cần ánh sáng”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà có thể chỉ cần kiểm tra bằng một ca kiểm thử duy nhất

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”

d Kiểm thử cấu trúc (White box)

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng)[4]

Các phương pháp kiểm thử hộp trắng:

Kiểm thử giao diện lập trình ứng dụng- API testing (applitcation programing interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và riêng tư

Bao phủ mã lệnh - Code coverage: tạo các kiểm tra để đáp ứng một số tiêu chuẩn về bao phủ mã lệnh

Các phương pháp gán lỗi - Fault injection

Các phương pháp kiểm thử hoán chuyển - Mutation testing methods

Kiểm thử tĩnh - Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh Phương pháp kiểm thử hộp trắng thường được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen Nó cho phép các nhóm phần mềm khảo sát các phần của một hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra

1.6 Kiểm thử dựa trên UML

1.6.1 Các t àn p ần ấu p ần

Một cấu phần gồm một tập các thuộc tính, phương thức, và các sự kiện Mỗi cấu phần đều có một tên, một định danh thể hiện cấu phần đó Thuộc tính đóng gói các trạng thái hoặc đặc điểm của mỗi cấu phần Mỗi thuộc tính có một kiểu Phương thức mô tả hành vi và các dịch vụ của cấu phần

Sự kiện mô tả hoạt động của cấu phần mà nó cài đặt Mỗi sự kiện cũng có một kiểu xác định

Hình vẽ dưới mô tả chi tiết cấu thành cấu phần phần mềm bao gồm:

 Hình chữ nhật: thể hiện các thuộc tính public

 Hình tròn: biểu thị các phương thức trong cấu phần

 Hình thoi: mô tả các sự kiện

C = (P, M, E, I)

Hình 1.15 Cấu trúc mô tả một cầu phần

Trong đó:

P = {p:T | p ∈ Tập định nghĩa, T ∈ Kiểu}

M = {(v,a,t,i(p)) | v ∈ Tập hiển thị, a ∈ truy cập, t ∈ kiểu i ∈ tập định nghĩa, p

∈ tham số}

E = {e:T | e ∈ sự kiện, T ∈ kiểu}

I : 2P × 2M × 2E Công nghệ phần mềm cấu phần được áp dụng để cập nhật một cấu phần hoặc tích hợp nhiều cấu phần với nhau để sinh ra một cấu phần mới hoặc ứng dụng với

sự kết hợp định nghĩa trong một hạ tầng cấu phần

Dựa trên các đặc điểm đó các cấu trúc cây kế thừa các cấu phần có thể được sử dụng để xây dựng các cấu phần mới dựa trên một số các đặc điểm cấu phần đã xây dựng trước

1.6.2 UML và ểm t ử

Sử dụng mô hình hóa trong quá trình sản xuất phần mềm giúp cho việc xác định các yêu cầu tốt hơn, thiết kế rõ ràng và khả năng bảo trì hệ thống cao hơn Lược đồ UML cũng được sử dụng ở nhiều dạng khác nhau hỗ trợ từng giai đoạn của quy trình kiểm thử bao gồm đơn vị, chức năng, hệ thống, hồi quy và giải pháp kiểm thử Bảng dưới đây mô tả sự hỗ trợ của UML trong các giai đoạn kiểm thử phần mềm[3]:

oạ ểm t ử ều ện áp ụn oạ lỗ ƣợ đồ UML

Sự đúng đắn, các điều kiện xử lý lỗi trước/ sau, tính bất biến

Lược đồ lớp và trạng thái

Chức năng Chức năng hệ thống

Hành vi thuộc về chức năng và API, các vấn đề

về tích hợp

Lược đồ tương tác

và lớp

oạ ểm t ử ều ện áp ụn oạ lỗ ƣợ đồ UML

Hệ thống Các chuỗi vận hành

Khả năng làm việc, giải quyết xung đột, đồng

bộ, khôi phục

Các lược đồ use case, hoạt động và tương tác

Hồi quy Các chức năng hệ

thống

Hành vi không giống với mong đợi do sự thay đổi hoặc cập nhật chức năng mới

Giống với kiểm thử chức năng

Giải pháp

Giao tiếp bên trong hệ thống

Các vấn đề vận hành bên trong

Các lược đồ use case

và lươc đồ triển khai

Bảng 1.1 UML hỗ trợ các loại kiểm thử

C ƢƠ G 2 KIỂM THỬ PHẦN MỀM VỚI CÔNG CỤ

KATALON STUDIO 2.1 Khái quát về kiểm thử ứng dụng trên nền tảng web

2.1.1 G ớ t ệu ứn ụn web

Có các loại website thể hiện sự đa dạng và phong phú, các loại web thu nhỏ theo hai dạng là web kiểu tĩnh và web kiểu động Ngoài ra, chúng ta đều biết ứng dụng trên nền Web có những đặc thù khác biệt hoàn toàn so với ứng dụng di động, ứng dụng desktop, Ứng dụng trên nền Web không giới hạn chỉ ở điện thoại thông minh, máy vi tính hay máy tính bảng, mà được thiết kế để chạy trên nhiều nền tảng khác nhau Trên mỗi nền tảng lại có những yêu cầu riêng về cấu hình, độ phân giải

và các thao tác, Đó chính là những vấn đề được đặt ra cho các nhà phát triển phần mềm trong việc đảm bảo chất lượng cho các ứng dụng trên nền Web khi phải chạy trên đa nền tảng Vì thế cần phải đưa ra một chiến lược hiệu quả cho kiểm thử, tránh những rủi ro, nâng cao chất lượng cho ứng dụng Web

2.1.2 Cá ểu ứn ụn web

Một website tĩnh đơn giản là trang web sẽ hiển thị cùng một nội dung cho tất

cả khách đang truy cập trang web vào những thời điểm khác nhau - hay còn được gọi là một trang web thông tin

Các website này hướng đến nhiều thông tin có thể hành động hơn và bao gồm cách thức hướng dẫn, các mẹo và thủ thuật, sửa chữa, hướng dẫn thông tin hỗ trợ,

…

Website tĩnh được viết hoàn toàn dựa trên nền tảng HTML, CSS và thêm các hiệu ứng từ Javascript nếu muốn Trong trường hợp muốn chỉnh sửa các chi tiết hay giao diện của website tĩnh, người chủ sở hữu website cần phải yêu cầu các nhà cung cấp dịch vụ hoặc các lập trình viên hỗ trợ Loại trang web này sẽ không có bất kỳ chức năng chính nào và hoàn toàn phụ thuộc vào thiết kế giao diện người dùng Trang web động là loại mà người dùng có thể cập nhật và thay đổi nội dung trang web của họ thường xuyên, được viết kèm theo một bộ công cụ quản trị để

người quản trị web có thể dễ dàng thay đổi một số chi tiết trong website mà họ mong muốn Đây được gọi là các CMS (Hệ thống quản trị cơ sở dữ liệu)

Kiểm tra chức năng là điều quan trọng nhất được thực hiện trong khi kiểm tra ứng dụng web Web app có thể chứa nhiều chức năng phức tạp nên người kiểm thử cần phải rất cẩn thận trong khi kiểm tra

2.1.3 ặ đ ểm về ất lƣợn ủ một ứn ụn ạn web

Ứng dụng trên nền Web sử dụng trên nhiều trình duyệt, không thể biết trước được trình duyệt Web của người dung sử dụng: Một ứng dụng Web chạy tốt trên trình duyệt Google Chrome nhưng trên Mozilla Firefox hay Safari thì có thể không như ý muốn Để tránh cho sự bất tiện này đòi hỏi người làm kiểm thử phải triển khai ca kiểm thử trên nhiều trình duyệt khác nhau, kiểm tra độ tương thích và tìm ra những lỗi để lập trình viên đưa ra sự thay đổi cho phù hợp với mọi trình duyệt Ứng dụng trên nền Web thường có lượng truy cập lớn, nhiều người sử dụng trên cùng một thời điểm: Với những ứng dụng Web có lượng người truy cập trung bình hoặc ít thì điều này không xảy ra vấn đề gì nghiêm trọng Nhưng với những ứng dụng chạy trên nền Web có lượng người truy cập lớn, thực hiện nhiều thao tác truy vấn dữ liệu cùng lúc có thể sẽ dẫn tới việc server bị quá tải Kiểm thử hộp trắng phát huy hiệu quả rất cao trong trường hợp này

2.1.4 Quy trìn ểm t ử ứn ụn web oặ p ần mềm

Kiểm thử phần mềm hoặc ứng dụng bao gồm nhiều giai đoạn với sự phối hợp của nhiều bên liên quan chứ không chỉ là một hoạt động đơn lẻ Chính vì thế, cần có quy trình kiểm thử phần mềm để làm rõ các công đoạn, các bước kiểm thử, người chịu trách nhiệm và khi nào việc kiểm thử được tiến hành trong toàn bộ quy trình phát triển phần mềm Nói cách khác, quy trình kiểm thử phần mềm chính là chuỗi các hoạt động được tiến hành để thực hiện việc kiểm thử Các giai đoạn trong quy trình kiểm thử phần mềm được biểu diễn tổng quát bằng sơ đồ sau:

Hình 2.1 Quy trình kiểm thử phần mềm 2.1.5 Sự ản ƣởn ủ n m trọn ở á mứ độ á n u o lỗ xây

1 Mức độ nhẹ Lỗi chính tả

2 Vừa Gây ra hiểu lầm hoặc thừa và thiếu thông tin

3 Khó chịu Các thông tin bị thiếu, sai chữ hoặc các giá trị hóa

đơn 0 đồng

4 Bực mình Một vài các giao dịch do không được xử lý

5 Nghiêm trọng Không giao dịch hoàn toàn

6 Rất nghiêm trọng Xử lý sai giao dịch

7 Cực kỳ nghiêm trọng Lỗi rất nghiêm trọng thường xuyên xảy ra

8 Quá quắt Hủy hoại hoàn toàn hoàn toàn hệ thống cơ sở dữ liệu

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

Phân tích yêu cầu kiểmthử

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

Thiết kế kiểm thử Chuẩn bị môi trường kiểm thử

Thực thi kiểm thử

Kết thúc kiểm thử

9 Thảm họa Hệ thống bị tê liệt hoàn toàn không hoạt động

10 Dịch họa Thảm hỏa lây lan các thông tin

Bảng 2.1 Bảng phân loại mứ độ nghiêm trọng của lỗi

2.2 Kiểm thử tự động và thủ công

2 2 1 á n ệm

Kiểm thử phần mềm tự động là thực hiện kiểm thử phần mềm bằng một chương trình đặc biệt với rất ít hoặc không có sự tương tác của con người, giúp cho người thực hiện việc kiểm thử phần mềm (tester) không phải lặp đi lặp lại các bước nhàm chán Công cụ kiểm thử tự động có thể lấy dữ liệu từ file bên ngoài (excel, csv…) nhập vào ứng dụng, so sánh kết quả mong đợi (từ file excel, csv…) với kết quả thực tế và xuất ra báo cáo kết quả kiểm thử

Kiểm thử thủ công: là làm mọi công việc hoàn toàn bằng tay, từ viết test case đến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiện một số sự kiện khác như click nút và quan sát kết quả thực tế, sau đó so sánh kết quả thực tế với kết quả mong muốn trong test case, điền kết quả test Hiện nay, phần lớn các tổ chức, các công ty phần mềm, hoặc các nhóm làm phần mềm đều thực hiện kiểm thử thủ công là chủ yếu

Thích hợp kiểm thử trong trường hợp các test case chỉ phải thực hiện một số ít lần

Giảm được chi phí ngắn hạn

Tốn thời gian Đối với mỗi lần release, người kiểm thử vẫn phải thực hiện lại một tập hợp các test case đã chạy dẫn đến sự mệt mỏi

và lãng phí effort

Kiểm thử thủ công là không thể thay thế vì người ta không thể tự động hóa mọi thứ

Tự động Thích hợp với trường hợp phải Tốn kém hơn kiểm thử thủ công,

test nhiều lần cho một case, có tính ổng định và tin cậy cao hơn

so với kiểm thử thủ công

Có thể thực hiện các thao tác lặp

đi lặp lại (nhập dữ liệu, click, check kết quả ) giúp tester không phải làm những việc gây nhàm chán và dễ nhầm lẫn như vậy

Giảm chi phí đầu tư dài hạn

chi phí đầu tư ban đầu lớn

Bảng 2.2 Ƣu đ ểm và n ƣợc đ ểm của công cụ Katalon Studio

Biểu đồ sau đây ta có thể so sánh sự thiệt hơn giữa kiểm thử tự động và kiểm thử thủ công Chi phí ban đầu cho kiểm thử tự động cao hơn so với kiểm thử bằng tay nhưng theo thời gian thì giá trị này bị đổi ngược lại

Hình 2.2 So sánh chi phí kiểm thử tự động và kiểm thử thủ công

2.3 Các kiểu kiểm thử web

2 3 1 ểm t ử ứ năn

Kiểm thử chức năng yêu cầu kiểm thử viên thực hiện kiểm thử tất cả các link trong trang Web, định dạng được sử dụng trong các trang Web để gửi và nhận các thông tin cần thiết từ người dùng Ngoài ra còn có kết nối cơ sở dữ liệu, kiểm tra cookie và xác minh HTML/CSS, …