NGHIÊN cứu CÔNG cụ KIỂM THỬ JMETER và ỨNG DỤNG TRONG KIỂM THỬ dự án PHẦN mềm QUẢN lý bán túi XÁCH

NGUYỄN THỊ MINH PHƯƠNG

NGHIÊN CỨU CÔNG CỤ KIỂM THỬ JMETER VÀ ỨNG DỤNG TRONG KIỂM THỬ DỰ ÁN PHẦN MỀM

QUẢN LÝ BÁN TÚI XÁCHChuyên ngành : Công nghệ thông tin

NGƯỜI HƯỚNG DẪN: TS.TRƯƠNG XUÂN QUANGThS.PHẠM THỊ THANH THỦY

Hà Nội – Năm 2020

LỜI CAM ĐOAN

Những nội dung trong đồ án tốt nghiệp này là thành quả từ sự nghiên cứu vàđược thực hiện dưới sự trực tiếp hướng dẫn của giảng viên hướng dẫn TS TrươngXuân Quang và ThS Phạm Thị Thanh Thủy.

Đồ án được thực hiện hoàn toàn mới, là thành quả của riêng em, không saochép theo bất cứ đồ án tương tự nào Mọi sự tham khảo sử dụng trong đồ án đềuđược trích dẫn các nguồn tài liệu trong báo cáo và danh mục tài liệu tham khảo.

Mọi sao chép không hợp lệ, vi phạm quy chế của nhà trường, em xin hoàntoàn chịu trách nhiệm.

Sinh viên thực hiện

Nguyễn Thị Minh Phương

LỜI CẢM ƠN

Để hoàn thành được đề tài đồ án tốt nghiệp này, trước hết em xin gửi lời cảmơn chân thành nhất đến các Cán bộ Giảng viên Khoa Công nghệ Thông tin, các cánbộ giảng viên trong Trường Đại học Tài nguyên Môi trường Hà Nội đã tận tìnhgiảng dạy và truyền đạt kiến thức cho em Đồng thời em xin gửi lời cảm ơn đặc biệtvề sự chỉ dạy, hướng dẫn tận tình của TS Trương Xuân Quang và ThS Phạm ThịThanh Thủy đã luôn tận tình hướng dẫn, giúp đỡ em trong suốt thời gian thực hiệnđồ án.

Em cũng xin gửi lời cảm ơn tới Khoa Công nghệ Thông tin – Trường Đại HọcTài nguyên Môi trường Hà Nội đã luôn quan tâm và tạo điều kiện giúp em hoànthành đề tài đồ án tốt nghiệp này Ngoài ra, em xin cảm ơn những người bạn đã giúpđỡ và trao đổi thêm nhiều thông tin về đề tài trong quá trình thực hiện đề tài này.

Cuối cùng em vô cùng biết ơn gia đình và bạn bè, những người đã luôn luôn ởbên cạnh em, động viên, chia sẻ với em trong suốt thời gian thực đề tài đồ án tốtnghiệp “Nghiên cứu công cụ kiểm thử JMeter và ứng dụng trong kiểm thử dựán phần mềm quản lý bán túi xách”.

Do kiến thức còn hạn chế, bài báo cáo của em không tránh khỏi những sai sót.Rất mong nhận được những lời góp ý từ quý Thầy cô để đồ án tốt nghiệp của emđược hoàn thiện và giúp em có thêm những kinh nghiệm quý báu.

Cuối cùng, em xin kính chúc các thầy cô giảng viên trường Đại học Tàinguyên và Môi trường Hà Nội nói chung, các thầy cô khoa công nghệ thông tin nóiriêng dồi dào sức khỏe và thành công trong sự nghiệp cao quý

Hà Nội, tháng 5 năm 2020

Sinh viên thực hiện

Nguyễn Thị Minh Phương

1.2.6 Phân loại kiểm thử phần mềm 19

1.2.7 Các mức độ nghiêm trọng của lỗi 25

1.2.8 Kiểm thử tự động 27

1.2.9 Nguyên tắc quan trọng trong kiểm thử phần mềm 30

CHƯƠNG 2 CÔNG CỤ KIỂM THỬ JMETER 32

2.1 Giới thiệu chung về JMeter 32

2.2 Ưu điểm và nhược điểm của JMeter [12] 33

2.3 Cài đặt JMeter 35

2.4 Các thành phần chính của JMeter 36

2.4.1 Test Plan 36

2.4.2 Các thành phần của Test Plan 36

2.4.3 Một số chức năng thường được sử dụng trong JMeter 38

2.4.4 Tạo Test Plan 46

CHƯƠNG 3 XÂY DỰNG PHẦN MỀM QUẢN LÝ BÁN TÚI XÁCH 50

3.1 Giới thiệu về phần mềm quản lý bán túi xách World Bag 50

3.1.1 Giới thiệu chung về phần mềm quản lý bán túi xách World Bag 50

3.2 Giao diện và một số chức năng chính của phần mềm quản lý bán túi xách WorldBag 59

CHƯƠNG 4 XÂY DỰNG CÁC KỊCH BẢN VÀ THỬ NGHIỆM KIỂM THỬHIỆU NĂNG PHẦN MỀM BÁN TÚI XÁCH BẰNG CÔNG CỤ JMETER 63

4.2.2 Thực hiện chạy các kịch bản để lấy kết quả 68

4.3 Phân tích, báo cáo, đánh giá kết quả kiểm thử 71

4.3.1 Phân tích 71

4.3.2 Kết quả báo cáo kiểm thử hiệu năng 72

4.3.3 Đánh giá, kết luận 78

KẾT LUẬN VÀ KIẾN NGHỊ 80TÀI LIỆU THAM KHẢO

DANH MỤC HÌNH ẢNH

Hình 1.1: Kiểm thử hộp đen 20

Hình 1.2: Bao phủ điều kiện trong kiểm thử hộp trắng 23

Hình 1.3: Bao phủ nhánh trong kiểm thử hộp trắng 24

Hình 2.1: Các loại Performance Testing trong JMeter 32

Hình 2.2: Mô phỏng tải trọng lớn trong JMeter 33

Hình 2.4: Giao diện chính của JMeter 36

Hình 2.5: HTTP Request 39

Hình 2.6: FTP Request 40

Hình 2.7: JDBC Request 41

Hình 2.8: CSV Data Set Config 42

Hình 2.9: Tạo Thread Group 46

Hình 2.10: Tạo HTTP Request Default 46

Hình 3.1: Biểu đồ use case cho toàn hệ thống 50

Hình 3.2: Biểu đồ phân rã chức năng quản lý sản phẩm và danh mục sản phẩm 51

Hình 3.3: Biểu đồ use case cho toàn hệ thống 52

Hình 3.4: Biểu đồ phân rã chức năng quản lý thông tin shop 53

Hình 3.5: Biểu đồ phân rã chức năng quản lý giao diện website 54

Hình 3.6: Biểu đồ tuần tự ca đăng nhập 55

Hình 3.7: Biểu đồ tuần tự ca đăng nhập 55

Hình 3.8: Biểu đồ tuần tự cho chức năng mua hàng 56

Hình 3.9: Biểu đò tuần tự cho chức năng tìm kiếm 56

Hình 3.10: Biểu đồ tuần tự cho chức năng xem chi tiết thông tin sản phẩm 57

Hình 3.11: Quan Hệ giữa các bảng trong CSDL 58

Hình 3.12: Giao diện người dùng của website phần mềm quản lý bán túi xách 59

Hình 3.13: Chức năng đăng kí 59

Hình 3.14: Chức năng đăng nhập 60

Hình 3.15: Chức năng tìm kiếm sản phẩm 60

Hình 3.16: Chi tiết sản phẩm 61

Hình 3.17: Chức năng giỏ hàng 61

Hình 3.18: Chức năng mua hàng 62

Hình 4.1: Test Plan sau khi được import vài Jmerter 67

Hình 4.2: Thiết lập các module 67

Hình 4.3: Cấu hình Thread, Loop, Ram-up 68

Hình 4.4: Di chuyển đến thư mục bin JMeter 68

Hình 4.5: Chạy lệnh tạo ra report html 69

Hình 4.6: Cửa sổ command prompt sau khi tạo xong report 69

Hình 4.7: File csv report được tạo thành công 70

Hình 4.8: File Html report được tạo thành công sau khi CSV file được tạo ra 70

Hình 4.9: View report dashboard 71

Hình 4.10: Bảng Statistics 71

Hình 4.11: Error và Top 5 Error 72

DANH MỤC CÁC BẢNG BIỂU

Bảng 1.1: Mức độ nghiêm trọng của lỗi 26

Bảng 2.1: Các kí tự viết tắt trong Non- GUI 43

Bảng 2.2: Các thành phần của Aggegate Report 45

Bảng 4.1: Môi trường máy chịu tải 63

Bảng 4.2: Môi trường máy đẩy tải 63

Bảng 4.3: Kịch bản kiểm thử 64

Bảng 4.4: Tình Huống Test 65

Bảng 4.5: Kết quả số lượng người truy cập tối đa 72

Bảng 4.6: Kết quả Test Thực Tế 73

BCC Blind Carbon Copy

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol SecureJDK Java Development Kit

IP Internet Protocol

KPI Key Performance IndicatorCSDL Cơ Sở Dữ Liệu

MỞ ĐẦU1 Lý do chọn đề tài

Ngày nay, công nghệ thông tin nói chung và công nghệ phần mềm nói riêngđang chiếm một vị trí quan trọng trong trong cuộc sống của chúng ta Trong cuộcsống tất bật hiện nay, mọi việc đều được đơn giản và tối ưu hóa thời gian thông quaviệc ứng dụng công nghệ thông tin vào xử lý các công việc hàng ngày qua các ứngdụng phần mềm Vì vậy, công nghệ thông tin đang ngày càng được phát triển nhanhchóng kéo theo đó là hệ thống mạng và các phần mềm cũng được gia tăng đáng kể.

Nhưng song song với đó luôn tiềm ẩn những lỗi không mong muốn, mangtheo những mối nguy về thiệt hại kinh tế và xã hội, đôi khi là cả những uy tín củacác doanh nghiệp và các nhà phát triển phần mềm Những lỗi này có thể do tự bảnthân phần mềm bị hỏng vì không được kiểm duyệt kĩ lưỡng trước khi đưa cho ngườidùng cuối Cũng có thể do có người cố tình phá hoại nhằm đánh cắp thông tin cánhân như tài khoản ngân hàng, tài khoản điện tử, số điện thoại… Những vấn đề nangiải cấp thiết này ngày càng có xu hướng mở rộng trong các năm gần đây, điển hìnhnhư các vụ hacker tấn công vào tài khoản xã hội (Facebook, Instagram,…) củangười dùng, đánh cắp đi các thông tin mật và mạo danh lừa đảo Ví dụ điển hìnhtrong thời gian gân đây là sự cố phần mềm xe hơi Mazda, sự cố gây chết máy độtngột hàng loạt xe hơi tại Mỹ đã ảnh hưởng đến danh tiếng của hãng và làm người sửdụng hoang mang Qua ví dụ này cho thấy chất lượng của các phần mềm phải đượcquan tâm và kiểm tra cẩn thận nhiều lần trước khi đưa vào sử dụng Bởi vì, kiểmthử phần mềm là một trong những quy trình đảm bảo phần mềm hoạt động chínhxác theo yêu cầu của thiết kế và cũng nhằm ngăn chặn các lỗi hay hỏng hóc còntiềm tàng bên trong phần mềm Đối với các phần mềm gồm nhiều mô - đun haynhiều người cùng tham gia phát triển thì công việc kiểm thử phần mềm sẽ mất rấtnhiều thời gian, công sức và độ chính xác không đảm bảo nếu làm thủ công

Để rút ngắn thời gian, công sức và đem lại hiệu quả cao cho việc kiểm thửphần mềm cần có các cộng vụ kiểm thử tự động (Automatic Testing) Hiện nay,JMeter là một trong những công cụ hỗ trợ kiểm thử nổi trội nhất cho các ứng dụngWeb vì nó hoạt động được hầu hết trên các hệ điều hành và trình duyệt Chrome,

Cốc Cốc,… hỗ trợ đa giao thức và hoàn toàn miễn phí cho người sử dụng nên đượcđánh giá rất cao.

Đối với sinh viên ngành Công nghệ thông tin, kiến thức và kỹ năng về kiểmthử phần mềm là một trong những tiêu chí quan trọng trong đánh giá chất lượngchuẩn đầu ra của chương trình đào tạo tại Nhà trường Do đó, việc thực hiện đồ án

với tên đề tài “Nghiên cứu công cụ kiểm thử JMeter và ứng dụng trong kiểmthử dự án phần mềm quản lý bán túi xách” là rất cần thiết.

2 Mục tiêu

Đề tài tìm hiểu cơ sở lý thuyết về kiểm thử cũng như cách triển khai công cụkiểm thử phần mềm tự động để giảm nhân lực kiểm thử và đảm bảo chất lượngphần mềm hơn với công việc kiểm thử bằng tay.

Mục tiêu chính của đề tài là:

- Nghiên cứu giai đoạn nào cần áp dụng công cụ kiểm thử tự động, các yếu tốnào cần kiểm thử hiệu năng.

- Hiểu rõ về các thành phần của bộ công cụ JMeter.

- Ứng dụng các kiến thức kiểm thử phần mềm và kiến thức về JMeter để viếtkịch bản kiểm thử cho một ứng dụng cụ thể.

3 Nội dung chính

Đồ án được chia thành 4 phần như sau:

Chương 1: Phần mềm và kiểm thử phần mềm: Chương này trình bày những

kiến thức cơ bản về phần mềm, chất lượng phần mềm, kiểm thử phần mềm như cácnguyên tắc kiểm thử, các phương pháp kiểm thử, các giai đoạn kiểm thử phần mềm.

Chương 2: Công cụ JMeter: Chương này trình bày tổng quan về công cụ

JMeter, cách cài đặt, sử dụng JMeter, tạo một test plan, các thành phần trong

Chương 3: Xây dựng phần mềm quản lý bán túi xách: Chương này giới

thiệu,trình bày khái quát về phần mềm quản lý bán túi xách cùng các biểu đồusecase, biểu đồ tuần tự, biểu đồ phân rã các chức năng chính của phần mềm quảnlý bán túi xách.

Chương 4: Xây dựng các kịch bản và thử nghiệm kiểm thử hiệu năngphần mềm bán túi xách bằng công cụ JMeter: Chương này tập trung xây dựng

các kịch bản kiểm thử và tiến hành kiểm thử trên công cụ JMeter.

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

- Phương pháp nghiên cứu lý thuyết: Thu thập và nghiên cứu các tài liệu vềkiểm thử phần mềm.

- Phương pháp tổng hợp: Tổng hợp các tài liệu về kiểm thử phần mềm.

- Phương pháp thực nghiệm: Tiến hành xây dựng các kịch bản kiểm thử và ứngdụng test với công cụ kiểm thử tự động JMeter.

CHƯƠNG 1 PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM1.1 Phần mềm và các khái niệm liên quan

1.1.1 Phần mềm

- Phần mềm (Software) có thể hiểu là một tập hợp các tập tin có mối liên hệ

chặt chẽ với nhau, đảm bảo thực hiện một số nhiệm vụ, chức năng nào đó trên thiếtbị điện tử Các tập tin này có thể bao gồm: các file mã nguồn viết bằng một hoặcnhiều ngôn ngữ lập trình, các file dữ liệu (thư viện), các file hướng dẫn [4]

- Phần mềm thực hiện các chức năng của nó bằng cách gửi các chỉ thị trực tiếpđến phần cứng (Hardware) hoặc cung cấp dữ liệu để phục vụ các chương trình hayphần mềm khác.

- Việc thực thi nhiệm vụ có thể thể là tự động hoặc thực hiện theo các thôngtin, dữ liệu đầu vào.

Theo IEEE (1991): Phần mềm là các chương trình máy tính kết với các dữ liệuhoặc các tài liệu hướng dẫn, đặc tả, v.v thường gồm 4 phần được mô tả dưới đây:

 Chương trình máy tính: Thành phần này giúp cho máy tính thực thi các ứngdụng được yêu cầu

 Quy trình: Là thành phần xác định trình tự và kế hoạch trong đó các chươngtrình được thực hiện, phương pháp sử dụng và những người chịu trách nhiệm chocác hoạt động của kế hoạch

 Các tài liệu: Có rất nhiều những tài liệu cần thiết với nhân viên phát triển,người sử dụng và nhân viên bảo trì như: tài liệu thiết kế, tài liệu hướng dẫn sử dụng,tài liệu hướng dẫn bảo trì

 Dữ liệu: Dữ liệu bao gồm tham số, mã nguồn và các danh sách thích ứng củaphần mềm dành riêng cho người dùng cụ thể là dành cho hoạt động phần mềm [5]

1.1.2 Lỗi phần mềm

1.1.2.1 Định nghĩa lỗi phần mềm và phân loại lỗi phần mềm

- Định nghĩa lỗi phần mềm: Có rất nhiều định nghĩa về lỗi phần mềm nhưngcó thể hiểu và phát biểu một cách đơn giản thì "Lỗi phần mềm là sự không khớpgiữa chương trình và đặc tả của nó" [10]

- Dựa vào định nghĩa, ta có thể phân loại lỗi phần mềm thành 3 dạng:  Lỗi sai: Sản phẩm phần mềm được xây dựng khác với đặc tả.

 Lỗi thiếu: Các yêu cầu của sản phẩm phần mềm đã có trong đặc tảnhưng lại không có trong sản phẩm thực tế.

 Lỗi thừa: Sản phẩm thực tế có những tính năng không có trong tài liệu đặc tả.

1.1.2.2 Các nguyên nhân gây lỗi phần mềm [5]

Lỗi phần mềm có thể đến từ nhiều nguyên nhân khác nhau, trong đó có cả cácnguyên nhân chủ quan và các nguyên nhân khách quan Dưới đây là chín nguyênnhân chủ yếu gây ra lỗi phần mềm:

- Định nghĩa các yêu cầu bị lỗi: Những lỗi trong việc xác định yêu cầu

thường nằm ở phía khách hàng.

- Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển: Những lỗi này

thường xuất hiện trong giai đoạn đầu của dự án Một số lỗi hay gặp phải: hiểu saichỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng trình bày bằng lờinói và tài liệu, hiểu sai về phản hồi và thiếu quan tâm đến những đề cập của kháchhàng.

Giải pháp khắc phục: Cần có ủy ban liên kết giữa khách hàng và nhà cung

cấp để tránh lỗi trong giao tiếp Ủy ban do quản trị dự án đứng đầu và khách hàngphải giới thiệu những người hiểu về mặt nghiệp vụ vào ủy ban đó.

 Sai lệch có chủ ý với các yêu cầu phần mềm: Trong một số trường hợp các

nhà phát triển cố tình làm sai lệnh các yêu cầu trong tài liệu đặc tả Nguyên nhân củaviệc này đến từ các áp lực thời gian, ngân sách, hay cố tình sử dụng lại các mô-đun từcác dự án trước mà chưa phân tích đầy đủ những thay đổi để thích nghi với các yêu cầumới.

Giải pháp khắc phục: Dựa trên những thống kê để quyết định xem giải pháp

như thế nào, sắp xếp ưu tiên xem bỏ được yêu cầu nào hay sử dụng lại được mô-đunnào.

 Các lỗi thiết kế logic: Lỗi phần mềm xảy ra trong quá trình các chuyên gia

thiết kế hệ thống, các kiến trúc sư hệ thống, kỹ sư phần mềm, các nhà phân tích xâydựng phần mềm theo yêu cầu Các lỗi điển hình bao gồm:

+ Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai.+ Quy trình định nghĩa có chứa trình tự lỗi.

+ Sai sót trong các định nghĩa biên như > 3 hay ≥ 3.

+ Thiếu sót các trạng thái hệ thống phần mềm được yêu cầu.

+ Các lỗi lập trình: Có rất nhiều lý do dẫn đến việc các lập trình viên gây racác lỗi lập trình Những lý do này bao gồm: Sự hiểu sai các tài liệu thiết kế, ngônngữ; sai sót trong ngôn ngữ lập trình; sai sót trong việc áp dụng các công cụ pháttriển; sai sót trong lựa chọn dữ liệu

+ Không tuân thủ theo các tài liệu hướng dẫn và tiêu chuẩn lập trình: Các lỗiphần mềm có thể đến từ việc không tuân thủ các tài liệu và tiêu chuẩn lập trình củacác tổ chức phát triển phần mềm.

+ Thiếu sót trong quá trình kiểm thử: Lỗi phần mềm có thể đến từ chính quátrình kiểm thử khi mà người kiểm thử để lọt lỗi.

 Những lỗi này đến từ các nguyên nhân sau đây:

+ Kế hoạch kiểm thử chưa hoàn chỉnh, để sót yêu cầu cần kiểm thử.+ Lỗi trong tài liệu và báo cáo kiểm thử.

+ Việc sửa chữa các lỗi được phát hiện không hoàn chỉnh do áp lực thời gianhay do thiếu cẩn thận.

Giải pháp khắc phục: Lên kế hoạch kiểm thử cụ thể tại giai đoạn đầu của dự

 Các lỗi thủ tục: Các thủ tục hướng dẫn cho người sử dụng tại từng bước

của tiến trình Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm phứctạp mà các tiến trình được thực bằng nhiều bước, mỗi bước có thể có nhiều kiểu dữliệu và cho phép kiểm tra các kết quả trung gian Các lỗi có thể đến từ việc viết cácthủ tục.

 Các lỗi về tài liệu: Các lỗi về tài liệu là vấn đề của các đội phát triển và bảo

trì khi có nhữ ng sai sót trong các tài liệu liên quan Những lỗi này có thể là nguyênnhân gây ra lỗi trong giai đoạn phát triển kế tiếp và giai đoạn bảo trì.

1.1.2.3 Chi phí cho việc sửa lỗi phần mềm

Việc kiểm thử và sửa lỗi phần mềm có thể thực hiện trong bất cứ giai đoạnnào của vòng đời phần mềm Tuy nhiên, công việc này nên được thực hiện càngsớm càng tốt vì càng về giai đoạn sau của vòng đời phần mềm, chi phí cho việc tìmvà sửa lỗi càng tăng, đặc biệt là đến giai đoạn đã triển khai phần mềm thì chi phícho sửa lỗi sẽ trở nên rất lớn và ảnh hưởng trực tiếp đến uy tín của tổ chức pháttriển phần mềm.

1.1.2.4 Quy trình xử lý lỗi phần mềm [10]

Quy trình xử lý lỗi có thể bao gồm 6 bước chính: Bước 0_Bắt đầu: Phát hiện phần mềm có lỗi.Bước 1_Đưa lỗi lên hệ thống quản lý lỗi.Bước 2_Gán lỗi cho nhân viên phát triển.Bước 3_Xử lý lỗi.

Bước 4_Kiểm thử lại.Bước 5_Đóng lỗi.

1.1.3 Chất lượng và độ tin cậy của phần mềm

1.1.3.1 Chất lượng của phần mềm

Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức,cá nhân khác nhau Trong phạm vi của đồ án này trình bày một số định nghĩa tiêubiểu.

Định nghĩa theo IEEE (1991) [5]:

Định nghĩa theo Pressman [10]: Chất lượng phần mềm là sự phù hợp của các

yêu cầu cụ thể về hiệu năng và chức năng, các tiêu chuẩn phát triển phần mềm đượcghi lại rõ dàng bằng tài liệu với các đặc tính ngầm định của tất cả các phần mềmđược phát triển chuyên nghiệp.

Định nghĩa đảm bảo chất lượng phần mềm

Định nghĩa theo Daniel Galin [10]: Đảm bảo chất lượng phần mềm

(Software Quality Assure) là một tập hợp các hành động cần thiết, được lên kếhoạch một cách hệ thống để cung cấp đầy đủ niềm tin rằng quá trình phát triển phầnmềm phù hợp để thành lập các yêu cầu chức năng kỹ thuật cũng như các yêu cầuquản lý theo lịch trình và hoạt động trong giới hạn ngân sách.

1.1.3.2 Độ tin cậy của phần mềm

Độ tin cậy của một hệ phần mềm là độ đo về mức độ tốt của các dịch vụ mà hệcung cấp cho máy tính Cần chú ý là người dùng không xét rằng các dịch vụ là quạntrọng như nhau: chẳng hạn, một hệ điều khiển máy bay có thể hiếm khi thất bại,nhưng nếu chúng có thất bại gây ra tai nạn máy bay thì các người bị nạn và thânnhân người bị nạn không thể xem hệ đó là đáng tin.

Độ tin cậy là một đặc trưng động của hệ thống, nó là một hàm của số các thấtbại phần mềm Một thất bại phần mềm là một sự kiện thi hành mà khi đó phần mềmhành xử không như người ta mong đợi Chú ý rằng một thất bại phần mềm khác mộthư hỏng phần mềm Hư hỏng phần mềm là một đặc trưng tĩnh, và nó sẽ gây ra thấtbại phần mềm khi mà mã lỗi được thi hành với một tập hợp đặc biệt các thông tinvào Các hư hỏng không phải luôn luôn xuất đầu lộ diện, vì vậy độ tin cậy phụthuộc vào việc sử dụng hệ thống như thế nào Không thể đưa ra một phát biểu đơngiản và khái quát về độ tin cậy phần mềm.

Các hư hỏng phần mềm không phải là các khuyết tật của chương trình Mộthành xử bất ngờ có thể xảy ra khi mà phần mềm phù hợp với các yêu cầu của nó,nhưng mà chính các yếu tố đó lại không đầy đủ Các sai sót trong các tư liệu phầnmềm cũng có thể dẫn đến các hành vi bất ngờ mặc dầu rằng phần mềm không cókhiếm khuyết.

Có công trình nghiên cứu đã chỉ ra rằng có thể rút bỏ 60% các khiếm khuyếtmà chỉ có thể cải tạo được 3% độ tin cậy Cũng có người đã chú ý rằng nhiều khiếmkhuyết trong sản phẩm chỉ là kết quả của hàng trăm hoặc hàng nghìn tháng sử dụng.

1.2 Kiểm thử phần mềm

1.2.1 Khái niệm

Kiểm thử phần mềm là quy trình được sử dụng để đánh giá, kiểm tra chấtlượng phần mềm ở nhiều khía cạnh khác nhau dựa trên các yêu cầu của người sửdụng đối với sản phẩm phần mềm, nhằm đảm bảo phần mềm hoạt động tốt trongcác môi trường, các trường hợp khác nhau.

Có thể định nghĩa một cách dễ hiểu như sau [2]:

Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được

thiết kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kếđể làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quantrọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống vàkhách hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay chưa?

-Lỗi phát hiện càng sớm thì chi phí khắc phục càng nhỏ.

1.2.3 Vai trò của kiểm thử phần mềm

- Phát hiện và xác định càng nhiều lỗi càng tốt ở các phần mềm được kiểm thử.- Tiến hành sửa lỗi ở các phần mềm được kiểm thử và kiểm thử lại cho đếnkhi đạt một mức độ chất lượng phần mềm chấp nhận được.

- Thực thi những trường hợp kiểm thử một cách hiệu quả trong một giới hạnngân sách và lịch trình cho phép.

1.2.4 Các cấp độ trong kiểm thử phần mềm

Có rất nhiều cách để chia cấp độ kiểm thử phần mềm, nhưng tựu chung lại sẽgồm 4 cấp độ sau:

4.2.4.1 Kiểm thử đơn vị (Unit Testing )[9]:

- Kiểm thử đơn vị là kiểm tra từng đơn vị phần mềm xem có hoạt động đúng

thiết kế hay không?

- Đơn vị dòng lệnh, nhóm dòng lệnh, một hàm, một thủ tục phục vụ một

nghiệp vụ nào đó, module, một chương trình sản phẩm Mức độ đơn vị lớn nhỏ dongười thực hiện làm kiểm thử đơn vị quyết định Để mức độ càng nhỏ cơ hội tìmlỗi, khắc phục lỗi càng lớn.

- Mục tiêu của kiểm thử đơn vị:

 Giảm rủi ro liên quan đến chất lượng sản phẩm, giúp xác minh việchoạt động của các yêu cầu chức năng, yêu cầu phi chức năng của cácthành phần có đúng mô tả thiết kế không?

 Xác định được sự tự tin vào chất lượng của thành phần sản phẩm, tìmlỗi trong các thành phần sản phẩm, ngăn chặn lỗi lọt đến các giai đoạnkiểm thử sau.

- Lí do cần kiểm thử đơn vị:

 Hỗ trợ xác định vị trí lỗi nhanh hơn Giảm chi phí, tăng chất lượng sản phẩm

- Kiểm thử đơn vị là giai đoạn đầu tiên của việc kiểm thử

- Các dữ liệu đầu vào của Kiểm thử đơn vị: thiết kế chi tiết, code, mô hình dữliệu, đặc tả về thành phần sản phẩm.

- Các loại kiểm thử đơn vị: Kiểm thử câu lệnh, kiểm thử quyết định haynhánh, kiểm thử điều kiện, kiểm thử đường đi.

- Người thực hiện kiểm thử đơn vị là Dev- Lỗi thường gặp khi kiểm thử đơn vị:

 Chức năng hoạt động không chính xác (không được mô tả trong tài liệuthiết kế chi tiết)

 Các vấn đề về luồng dữ liệu

 Code và logic của code không chính xác

4.2.4.2 Kiểm thử tích hợp (Integration Testing)[9]:

Kiểm thử tích hợp là việc kiểm tra về kết nối giữa các thành phần của 1 hệthống hoặc giữa các hệ thống phần mềm tập trung vào kiểm thử sự giao tiếp hay kếtnối về giao diện giữa các thành phần của 1 phần mềm hay các hệ thống với nhau.

- Mục tiêu của kiểm thử tích hợp:

 Giảm rủi ro liên quan đến chất lượng sản phẩn, giúp xác minh sự kếtnối, sự giao tiếp của các chức năng qua giao diện có theo mô tả cụ thểtrong thiết kế kiến trúc, thiết kế hệ thống không?

 Xác định sự tự tin vào chất lượng của các giao diện, tìm lỗi khi thựchiện, kiểm tra việc tích hợp có như thiết kế hệ thống không? Và ngăncác lỗi đến sau

- Khi nào cần kiểm thử tích hợp: Tùy thuộc vào các mức độ tích hợp, khithành phần đã được kiểm thử đơn vị rồi, tích hợp hệ thống khi hệ thống được kiểmthử hệ thống rồi.

- Các dữ liệu đầu vào của kiểm thử tích hợp: thiết kế hệ thống phần mềm, thiếtkế kiến trúc, giao diện giao thức…

- Lỗi thường gặp khi kiểm thử tích hợp: dữ liệu không chính xác, dữ liệu thiếuhoặc mã hóa không chính xác, lỗi xử lí, giả định không chính xác.

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

 Tích hợp đồng thời các thành phần, hệ thống cùng 1 lúc: Ưu điểm: Hoàn thành trước khi tích hợp

Nhược điểm: Tốn thời gian, khó tìm vị trí lỗi Tích hợp dần dần:

Ưu điểm: Dễ phát hiện nguyên nhân gây lỗiNhược điểm: Tốn thời gian tạo thành phần giả lập

1.2.4.3 Kiểm thử hệ thống (System Testing)[9]:

Là kiểm thử trên một hệ thống đầy đủ bao gồm kiểm thử chức năng và kiểmthử phi chức năng:

- Mục tiêu:

 Giảm rủi ro liên quan đến chất lượng sản phẩm.

 Xác minh hành vi chức năng, phi chức năng có hoạt động đúng yêu cầuđặc tả không.

 Giúp xác thực hệ thống sẽ hình thành như mong đợi của người dùng.- Xác định sự tự tin vào chất lượng của cả hệ thống.

- Tìm lỗi, ngăn lỗi đến giai đoạn sau.- Lí do cần kiểm thử hệ thống.

- Kiểm tra, nhằm đảm bảo chức năng, đặc tính của một sản phẩm phần mềmđúng đủ theo đặc tả phần mềm.

- Thực hiện kiểm thử trên một môi trường gần giống với môi trường thực- Kiểm thử cuối cùng đại diện cho dự án, nhóm phát triển phần mềm để kiểmtra sản phẩm trước khi bàn giao cho khách hàng.

- Khi nào cần kiểm thử hệ thống:

 Hệ thống kiểm thủ đã hoàn thiện, phát triển xong.

 Các thành phần riêng lẻ trong hệ thống đã được kiểm thử. Kiểm thử tích hợp đã hoàn thành.

- Các tài liệu đặc tả chức năng, phi chức năng đã chốt và không thay đổiTestcase, Testdata phải sẵn sàng sử dụng.

- Các loại kiểm thử hệ thống: Chức năng, phi chức năng, liên quan đến thayđổi phần mềm.

- Môi trường kiểm thử phải giống môi trường thực tế nhất có thể.

- Các dữ liệu đầu vào của Kiểm thử hệ thống: yêu cầu hệ thống, tài liệu mô tảchức năng hệ thống, usecase, tài liệu mô tả hệ thống với một dịch vụ bên ngoài.

- Lỗi thường gặp khi kiểm thử hệ thống: tính toán không chính xác, các chứcnăng, phi chức năng hoạt động không đúng, luồng không đúng.

1.2.4.4 Kiểm thử chấp nhận (Acceptance Testing)[9]:

- Người sử dụng chấp nhận các hành động kiểm thử được thực hiện bởi ngườisử dụng cuối hay khách hàng với mục tiêu sản phẩm có đáp ứng đúng theo yêu cầuhay thỏa mãn các tiêu chí sản phẩm đã thống nhất không.

- Mục tiêu:

 Thiết lập sự tự tin về chất lượng của toàn hệ thống.

 Xác thực rằng hệ thống đã hoàn thành và hoạt động như mong muốncủa khách hàng.

 Xác minh rằng các hành vi chức năng, phi chức năng hoạt động đúngđặc tả.

- Lí do cần kiểm thử chấp nhận:

 Để chấp nhận sản phẩm dựa trên các tiêu chí chấp nhận đề ra từ trước. Đảm bảo các chức năng cần có và các chức năng mong muốn của

khách hàng được hiển thị trong sản phẩm phần mềm.

- Các dữ liệu đầu vào của kiểm thử chấp nhận: Quy trình nghiệp vụ, yêu cầungười dùng, tiêu chuẩn pháp lí, mô tả usecase, yêu cầu hệ thống, tài liệu hệ thống,tài liệu người dùng, các bước cài đặt, báo cáo phân tích rủi ro.

- Khi nào cần kiểm thử chấp nhận: Sau khi bàn giao và đã được thực hiệnkiểm thử hệ thống, được thực hiện bởi khách hàng hay người sử dụng tùy thuộc vàokhách hàng khi gối lên kiểm thử hệ thống.

- Các loại kiểm thử chấp nhận hoạt động đảm bảo phi chức năng được kiểmthử đảm bảo hệ thống thỏa mãn các thông số cụ thể, sao lưu, khôi phục Tuân thủkiểm thử tiêu chí, chính sách quy định thống nhất ban đầu

- Giai đoạn kiểm thử chấp nhận: Alpha: Khách hàng người sử dụng cuối

Beta: Khách hàng người sử dụng cuối môi trường khách hàng sau Alphakhông có sự theo dõi của lập trình viên.

- Lỗi thường gặp của Kiểm thử chấp nhận.

- Luồng không thỏa mãn, quy tắc nghiệp vụ không thực hiện chính xác, lỗi bảo mật.

Hoạt động:

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.- QA team sẽ thực hiện đọc hiểu, nghiên cứu và phân tích cụ thể các yêu cầutrong tài liệu đặc tả của dự án hoặc tài liệu khách hàng Qua hoạt động này, QAteam sẽ nắm bắt được các yêu cầu mà dự án đưa ra bao gồm yêu cầu kiểm thử chứcnăng/ phi chức năng nào.

- Ngoài ra, trong quá trình phân tích, nghiên cứu tài liệu, nếu có câu hỏi phátsinh hay đề xuất giải quyết, QA team sẽ đưa ra câu hỏi với các bên liên quan nhưBA( Business Analysis), PM( Project Manager), team leader, khách hàng để hiểuchính xác hơn về yêu cầu của sản phẩm Những câu hỏi này sẽ được lưu trữ vào fileQ&A (Question and Answer) Các câu hỏi nên được đưa ra dưới dạng Yes/Noquestion hoặc các lựa chọn để tiết kiệm thời gian trả lời cũng như hỗ trợ đưa ranhững gợi ý hay để xây dựng sản phẩm ngay từ đầu Như vậy, đương nhiên làchúng ta không nên nêu ra những câu hỏi dạng là gì, như thế nào, tại sao Nhữngcâu hỏi như thế thường mất thời gian để giải thích và cũng khó có thể giải thích mộtcách chi tiết nhất có thể Hơn nữa, đối với khách hàng không có sự hiểu biết về lĩnhvực phần mềm mà họ yêu cầu thì càng không thể trả lời những câu hỏi mang tínhchuyên môn cao Chính chúng ta sẽ là người hỗ trợ và đưa ra giải pháp thích hợpcho khách hàng lựa chọn.

Đầu ra:

Đầ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ântích rủi ro của việc kiểm thử phần mềm.

1.2.5.2 Test planning - Lập kế hoạch kiểm thử [10]Đầu vào:

Đầu vào của giai đoạn lập kế hoạch kiểm thử là các tài liệu đặc tả đã được cậpnhật thông qua các câu hỏi và trả lời được đưa ra trong giai đoạn phân tích yêu cầu,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.

Hoạt động:

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, testmanager hoặc test leader sẽ là người lập kế hoạch kiểm thử cho cả QA team Lập kếhoạch kiểm thử nhằm xác định một số yếu tố quan trọng sau:

- Xác định phạm vi (Scope) dự án: Dự án thực hiện trong thời gian bao lâu?

Bao gồm những công việc gì cho từng khoảng thời gian xác định? Từ đó đưa ra lịchtrình thực hiện cho từng công việc nhỏ sao cho phù hợp với toàn bộ đội dự án.

- Xác định phương pháp tiếp cận: Nói về cách tiếp cận để kiểm thử cho một

đối tượng nào đó, thì phải dựa vào nhiều thứ, ví dụ như: Thời gian cho phép test cóphù hợp với con số ước lượng, nhiều hay ít, yêu cầu chất lượng từ phía khách hàngthế nào? Cao, thấp hay khắc khe hay sao cũng được? Công nghệ / kỹ thuật sử dụngđể phát triển ứng dụng này là gì? Lĩnh vực của hệ thống/sản phẩm đang được test(domain) là gì? Từ đó, test manager có thể đưa ra những phương pháp và kế hoạchphù hợp nhất cho cả quá trình thực hiện dự án sao cho đúng với các tiêu chí chấpnhận của sản phẩm và kịp tiến độ với các mốc thời gian bàn giao, phát hành.

- Xác định các nguồn nhân lực: Bao nhiêu người tham gia dự án, ai sẽ test

phần nào, bao nhiêu tester tham gia? Tester và nhóm phát triển có kinh nghiệm vềlĩnh vực này không?

Thiết bị: số lượng server, version, máy tính, mobile để thực hiện test là baonhiêu.

- Lên kế hoạch thiết kế công việc test: Bản kế hoặc kiểm thử sẽ bao gồm

các nội dung:

 Liệt kê các chức năng cần kiểm thử.

 Xác định thời gian kiểm thử: cần làm những công việc gì, trong thờigian bao lâu, cái nào thực hiện trước, cái nào thực hiện sau.

 Xác định điều kiện bắt đầu: xác định những điều kiện tối thiểu để bắtđầu hoạt động kiểm thử cho từng chức năng.

 Xác định điều kiện kết thúc: khi có những điều kiện nào thì sẽ kết thúcviệc 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áchhà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 Từ đó,vừa có thể tiết kiệm thời gian mà vẫn đưa ra được một kịch bản kiểm thử đầy đủ vàhiệu quả.

- 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 Đồng thời tester cũng cần đánh giá mứcđộ ưu tiên cho từng test case.

- 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ếtnhư test data, test script.

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

- Tester cần chuẩn bị một vài testcase để kiểm tra xem môi trường cài đặt đãsẵn sàng cho việc kiểm thử hay chưa Đây chính là việc thực thi các smoke testcase.

- Đo và phân tích tiến độ: kiểm thử viên cũng cần kiểm soát chặt chẽ tiến độcông việc của mình bằng cách so sánh tiến độ thực tế với kế hoạch, nếu chậm cầnphải điều chỉnh sao cho kịp tiến độ dự án, nếu nhanh cũng cần điều chỉnh vì có thểtest lead lên kế hoạch chưa sát với thực tế dự án Từ đó có thể sửa chữa test plan cầnđiều chỉnh để phù hợp với tiến độ dự án đưa ra.

- Report thường xuyên cho PM và khách hàng về tình hình thực hiện dự án:Cung cấp thông tin trong quá trình kiểm thử đã làm được những chức năng nào, cònchức năng nào, hoàn thành được bao nhiều phần trăm công việc, báo cáo các trườnghợp phát sinh sớm, tránh ảnh hưởng tiến độ công việc của cả ngày.

Hoạt động:

- Đây là giai đoạn cuối cùng trong quy trình kiểm thử phần mềm.

- Ở giai đoạn này, QA team thực hiện tổng kết, báo cáo kết quả về việc thựcthi test case, bao nhiêu case pass/ fail, bao nhiêu case đã được fix, mức độ nghiêmtrọng của lỗi, bao nhiêu lỗi cao/ thấp, lỗi còn nhiều ở chức năng nào, dev nào nhiềulỗi Chức năng nào đã hoàn thành test/ chưa hoàn thành test/ 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ốtvà 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:

Đầu ra của giai đoạn này bao gồm các tài liệu: Test report, Test result.

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

Có rất nhiều phương pháp để kiểm thử phần mềm Đánh giá, định hướng hoặckiểm tra được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trình thực tế trongcác tình huống được gọi là kiểm thử động Kiểm thử tĩnh thông thường có thể đượcbỏ qua khi thực hành nhưng kiểm thử động diễn ra khi bản thân chương trình đóđang được sử dụng.

1.2.6.1 Kiểm thử tĩnh – Static testing [2]

Là phương pháp kiểm thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các

đặc tả bằng tay, thông qua việc sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết

mà không cần chạy chương trình Kiểu kiểm thử này thường được sử dụng bởichuyên viên thiết kế người mà viết mã lệnh một mình.

Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn bộbao gồm các chương trình được phân tích bởi một trình thông dịch hoặc biên dịchmà xác nhận tính hợp lệ về cú pháp của chương trình

1.2.6.2 Kiểm thử động – Dynamic testing [2]

Là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chươngtrình để điều tra trạng thái tác động của chương trình Đó là kiểm thử dựa trên cácca kiểm thử xác định bằng sự thực hiện của đối tượng kiểm thử hay chạy cácchương trình Kiểm thử động kiểm tra cách thức hoạt động động của mã lệnh, tức làkiểm tra sự phản ứng vật lý từ hệ thống tới các biến luôn thay đổi theo thời gian.Trong kiểm thử động, phần mềm phải thực sự được biên dịch và chạy Kiểm thửđộng thực sự bao gồm làm việc với phần mềm, nhập các giá trị đầu vào và kiểm traxem liệu đầu ra có như mong muốn hay không.

Kiểm thử động có thể bắt đầu trước khi chương trình đã hoàn tất 100% đểkiểm thử các phần cụ thể của mã và được áp dụng cho các chức năng riêng biệthoặc Module Kỹ thuật điển hình cho điều này được sử dụng trong cả mạchnhánh/trình điều khiển hoặc được thực hiện trong một môi trường gỡ lỗi nhất định.

1.2.6.3 Kiểm thử hộp đen (Black Box Testing – BBT)[2]

a Định nghĩa

Kiểm thử hộp đen hay còn gọi là kiểm tra chức năng và thử nghiệm hành vi.Xem chương trình như là một “hộp đen”, hoàn toàn không quan tâm về cách cư xửvà cấu trúc bên trong của chương trình Thay vào đó, tập trung vào tìm các trườnghợp mà chương trình không thực hiện theo đặc tả của nó.

Hình 1.1: Kiểm thử hộp đen

Phương pháp này được đặt tên như vậy bởi vì các chương trình phần mềm,trong con mắt của các tester, giống như một hộp đen; bên trong mà người ta khôngthể nhìn thấy Phương pháp này cố gắng tìm ra các lỗi trong các loại sau:

- Chức năng không chính xác hoặc thiếu.- Lỗi giao diện.

- Lỗi trong cấu trúc dữ liệu hoặc truy cập cơ sở dữ liệu bên ngoài.- Hành vi hoặc hiệu suất lỗi.

- Khởi tạo và chấm dứt các lỗi.b.Các phương pháp kiểm thử hộp đen

- Đoán lỗi: là một kỹ năng quan trọng của tester, thậm chí có thể gọi là nghệthuật, một kiệt tác của trực giác Phương pháp này đặc biệt dựa vào kinh nghiệm vàkiến thức của tester Nhiều tester cố gắng đoán xem phần nào của hệ thống mà cókhả năng ẩn chứa lỗi Với phương pháp này, họ không cần một công cụ hay mộtkịch bản kiểm thử nào khi bắt đầu vào việc.

- Kiểm thử dựa vào đồ thị nguyên nhân - kết quả (Cause Effect Graphing): làmột kỹ thuật thiết kế kiểm thử phần mềm liên quan đến việc xác định các trườnghợp (điều kiện đầu vào) và các hiệu ứng (điều kiện đầu ra) Vì các hệ thống hiệnnay đều được phát triển trên nền tảng OOP (Object-oriented programming), do đó,chúng ta có thể có được một đồ thị các đối tượng mà hệ thống định nghĩa và kết nối.Từ đồ thị này, chúng ta dễ dàng biết các mối quan hệ của những đối tượng mà hệthống xử lý, từ đó sẽ cho chúng ta các kịch bản kiểm thử phù hợp.

- Phân vùng tương đương (Equivalence Class): Phân tích giá trị biên(Boundary Value Analysis), sử dụng bảng quyết định (Decision Tables)

c Ưu nhược điểm của kiểm thử hộp đen- Ưu điểm:

 Các tester được thực hiện từ quan điểm của người dùng và sẽ giúp đỡ trongviệc sáng tỏ sự chênh lệch về thông số kỹ thuật.

 Các tester theo phương pháp black box không có “mối ràng buộc” nào vớicode, và nhận thức của một tester rất đơn giản: một source code có nhiều lỗi, sửdụng nguyên tắc: "Hỏi và bạn sẽ nhận" các tester black box tìm được nhiều bug ởnơi mà các DEV không tìm thấy.

 Tester có thể không phải IT chuyên nghiệp, không cần phải biết ngôn ngữlập trình hoặc làm thế nào các phần mềm đã được thực hiện.

 Các tester có thể được thực hiện bởi một cơ quan độc lập từ các developer,cho phép một cái nhìn khách quan và tránh sự phát triển thiên vị.

 Hệ thống thật sự với toàn bộ yêu cầu của nó được kiểm thử chính xác.

 Thiết kế kịch bản kiểm thử khá nhanh, ngay khi mà các yêu cầu chức năngđược xác định.

- Nhược điểm:

 Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn.

 Khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, vàthiếu cả thời gian cho việc tập hợp này.

 Khả năng để bản thân kỹ sư lạc lối trong khi kiểm thử là khá cao.

1.2.6.4 Kiểm thử hộp trắng (White Box Testing – WBT)[2]

a Định nghĩa

Kiểm thử hộp trắng là phương pháp kiểm nghiệm dựa vào cấu trúc/mã lệnhchương trình WBT kiểm nghiệm một chương trình (một phần chương trình, haymột hệ thống, một phần của hệ thống) đáp ứng tốt tất cả các giá trị input bao gồm cảcác giá trị không đúng hay không theo dự định của chương trình Chiến lược nàyxuấ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ểmthử 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.

Do đó người kiểm thử hộp trắng phải có kỹ năng, kiến thức nhất định về ngônngữ lập trình được dùng, về thuật giải được dùng trong thành phần phần mềm để cóthể thông hiểu chi tiết về đoạn code cần kiểm thử Thường tốn rất nhiều thời gian vàcông sức nếu thành phần phần mềm quá lớn (thí dụ trong kiểm thử tích hợp haykiểm thử chức năng) Do đó kỹ thuật này chủ yếu được dùng để kiểm thử đơn vị.Trong lập trình hướng đối tượng, kiểm thử đơn vị là kiểm thử từng tác vụ của 1class chức năng nào đó.

Có 2 hoạt động kiểm thử hộp trắng:

- Kiểm thử luồng điều khiển: tập trung kiểm thử thuật giải chức năng

- Kiểm thử dòng dữ liệu: tập trung kiểm thử đời sống của từng biến dữ liệuđược dùng trong thuật giải.

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

Khi thực hiện kiểm thử bằng whitebox testing thì ta phải có một bộ test chochương trình đó Tuy nhiên để biết chắc chắn được là bộ test của chúng ta đã đầy đủcho tất cả các trường hợp hay chưa, ta sẽ áp dụng các kiến thức của coverage tesingđể đo đạc kết quả của chương trình khi thực hiện bộ kiểm thử Coverage testing có

thể hiểu là tỉ lệ (tính theo %) test case đã được thực hiện trên tổng số test case cầnthiết cho ứng dụng Nếu tỉ lệ này càng cao thì ứng dụng càng được test kỹ Mặc dùviệc đảm bảo ứng dụng có test coverage là 100% trong một số trường hợp là bất khảthi, nhưng ta vẫn sẽ luôn cố gắng để đạt được kết quả gần với con số đó nhất.

Return z; }

Nếu ta gọi foo(1,1) thì dòng z = x sẽ được thực hiện, còn nếu gọi foo(0,1) thìdòng z = x sẽ không được thực hiện, lúc đó test case của ta sẽ không thỏa điềukiệnbao phủ câu lệnh.

- Bao phủ điều kiện (Branch Coverage, Decision coverage): Kiểm thử đòi hỏiphải đủ trường hợp thử nghiệm như vậy mà mỗi điều kiện trong một quyết định cótrên tất cả các kết quả có thể ít nhất một lần Đó là các nhánh (quyết định) lấy cả 2trường hợp đúng và sai Nó giúp trong việc chứng thực tất cả các ngành có mã đảmbảo rằng đó không có chi nhánh dẫn đến hành vi bất thường của ứng dụng Ví dụđoạn mã:

Ta có thể sinh các test case bao phủ các điều kiện của nhánh:

Hình 1.2: Bao phủ điều kiện trong kiểm thử hộp trắng

- Bao phủ nhánh (Path Coverage): Trong các trường hợp kiểm thử được thựchiện trong một cách mà mọi con đường được thực hiện ít nhất một lần Tất cả cáccon đường kiểm soát có thể được thực hiện, bao gồm tất cả những con đường vònglấy bằng không, một lần, và nhiều (lý tưởng là tối đa) các trường hợp thử nghiệmđược chuẩn bị dựa trên các biện pháp phức tạp logic của một thiết kế thủ tục Đểhoàn thiện bao phủ nhánh, chúng ta phải xét thêm 2 trường hợp bug(a) khi đúng vàkhi sai.

Hình 1.3: Bao phủ nhánh trong kiểm thử hộp trắngc Ưu nhược điểm của kiểm thử hộp trắng

- Ưu điểm

 Kiểm tra được toàn bộ chương trình nguồn Phát hiện lỗi tại chỗ

 Tự động hóa kiểm thử- Nhược điểm

 Yêu cầu người kiểm thử phải am hiểu cấu trúc mã lệnh chương trình Do dóđòi hỏi tài nguyên nhân lực và máy tốn kém.

 Có khả năng tồn tại các tổ hợp lệnh khác nhau gây lỗi.

 Không kiểm thử hết đường đi với các vòng lặp lớn, phức tạp. Khó thực hiện và chi phí thực hiện cao

1.2.6.5 Kiểm thử hộp xám (Gray Box Testing – GBT)

a.Định nghĩa

Kiểm thử hộp xám là một phương pháp kiểm thử phần mềm được kết hợpgiữa kiểm thử hộp đen và kiểm thử hộp trắng Trong kiểm thử hộp đen, tester kiểmthử các hàng mục mà không cần biết cấu trúc bên trong của nó, còn trong kiểm thửhộp trắng thì tester biết được cấu trúc bên trong của chương trình Trong kiểm thửhộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần Tester có thể truycập vào cấu trúc dữ liệu bên trong và thuật toán của chương trình với mục đích là đểthiết kế test case, nhưng khi test thì test như là người dùng cuối hoặc mức hộp đen.Được gọi là kiếm thử hộp xám vì trong chương trình phần mềm, mắt của testergiống như hộp xám/bán trong suốt – nhìn qua hộp này ta chỉ có thể thấy được mộtphần [2]

b.Ứng dụng

Mặc dù phương pháp kiểm thử hộp xám có thể ứng dụng vào nhiều mức testkhác nhau nhưng chủ yếu nó hữu dụng trong mức Intergration Testing – kiểm thửtích hợp [2]

c Ưu nhược điểm của kiểm thử hộp xám

Ưu điểm và nhược điểm của Kiểm thử hộp xám được quyết định dựa vào sựkết hợp các ưu nhược điểm của kiểm thử hộp đen và hộp trắng [2]

1.2.7 Các mức độ nghiêm trọng của lỗi

Chương trình một khi đã xuất hiện lỗi đều kéo theo những hệ luỵ nghiêmtrọng Một trong những cách phân loại mức độ nghiêm trọng của lỗi thường đượcsử dụng là dựa trên tần suất xuất hiện: chỉ một lần, thỉnh thoảng, xuất hiện lại haylặp đi lặp lại nhiều lần Việc phân loại mức độ nghiêm trọng của lỗi sẽ giúp kiểmthử viên cũng như lập trình viên ý thức được đâu là lỗi cần được giải quyết trước,nhằm giảm thiểu tối đa những tổn thất về chi phí và nâng cao chất lượng cho sảnphẩm [10]

Bảng 1.1: Mức độ nghiêm trọng của lỗi

1 Critical

Lỗi này ngăn chặn hoặc cản trở việc thử nghiệm chứcnăng/sản phẩm hoặc người dùng không thể sử dụng đượcứng dụng/ hệ thống sẽ được xếp vào mức độ nghiêm trọng1.

Ví dụ:

 Kiểm tra tính năng đăng nhập của một trang web Khingười dùng đã điền thông tin đăng nhập và nhấp vào nút“Đăng nhập” -> Trang web bị treo, không có bất kỳ phảnhồi nào với người dùng và người dùng không thể có bất kỳthao tác nào với trang web.

 Kiểm tra tính năng đăng nhập thông qua gmail Sau khiđã nhập đúng tên và mật khẩu, thay vì đăng nhập, hệ thốngsẽ bị treo hoặc có một thông báo lỗi cho người dùng Đâylà một nghiêm trọng vì lỗi này khiến toàn bộ ứng dụngkhông sử dụng được

- Bất kỳ tính năng chính nào khi được implement nhưngkhông đáp ứng được yêu cầu sử dụng và tính năng hoạtđộng khác với dự kiến Lỗi này sẽ được xếp vào mức độnghiêm trọng 2.

- Hoặc một lỗi xảy ra khi chức năng hoạt động nhưng kếtquả hoàn toàn không đúng với yêu cầu.

Ví dụ:

 Khi gửi mail, người dùng không được phép thêm nhiềungười nhận trong phần CC/BCC, lỗi này được phân loại làlỗi Major vì đây là chức năng chính của ứng dụng nhưngnó lại không hoạt động bình thường.

 Các lỗi liên quan đến việc không đảm bảo được sự duytrì dữ liệu không chính xác (incorrect data persistence) ,các vấn đề hác về dữ liệu hoặc các hành vi ứng dụng saiđều được xếp vào loại mức độ nghiêm trọng 2.

3 Minor/Moderate

Bất kỳ tính năng nào được implement nhưng không đápứng yêu cầu sử dụng và hoạt động khác với mong đợinhưng có tác động không đáng kể hoặc không gây ảnhhưởng lớn đến ứng dụng/phần mềm, sẽ được phân loại theomức độ nghiêm trọng 3 Những lỗi ở mức độ này thườnggây ảnh hưởng cho hệ thống phần mềm ở mức thấp nhất vàít ảnh hưởng đến trải nghiệm của người dùng.

Ví dụ: Khi tiến hành mua hàng online, thay vì người dùng

chỉ cần click 1 lần để thêm sản phẩm thì khách hàng phảiclick 2 lần để thêm sản phẩm vào giỏ hàng.

Các lỗi về layout, font-size, font casing hoặc lỗi chính tả sẽđược phân loại mức độ nghiêm trọng 4 Lỗi này thường sẽkhông có tác động đến các chức năng của hệ thống Tuynhiên để hoàn chỉnh ứng dụng và tạo cho người dùng có sựtrải nghiệm tốt nhất về sản phẩm của mình thì các lỗi nàynên được sửa sau khi đã khắc phục, xử lý các vấn đề, lỗinghiêm trọng.

1.2.8 Kiểm thử tự động

Kiểm thử đang được xem là giải pháp chủ yếu nhằm đảm bảo chất lượng chocác sản phẩm phần mềm Tuy nhiên, các hoạt động kiểm thử hiện nay chủ yếu đượcthực hiện một cách thủ công và tiêu tốn khoảng 30-50% tài nguyên (thời gian, nhânlực và chi phí) của quá trình phát triển sản phẩm phần mềm Hơn nữa, độ phức tạpcủa các phần mềm ngày càng tăng và trong môi trường cạnh tranh như hiện nay đòihỏi các công ty phần mềm phải áp dụng các phương pháp và công cụ nhằm tự độnghóa các hoạt động kiểm thử [4]

1.2.8.1 Tổng quan về 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ộtkịch bản kiểm thử Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời giankiểm thử

Mục đích của kiểm thử tự động là giảm thiểu thời gian, công sức và kinh phí,tăng độ tin cậy, tăng tính hiệu quả và giảm sự nhàm chán cho người kiểm thử trongquá trình kiểm thử sản phẩm phần mềm.

Kiểm thử tự động sẽ được sử dụng khi dự án không đủ tài nguyên (thời gian,nhân lực và chi phí), phải thực hiện kiểm thử hồi quy khi sản phẩm được sửa đổihoặc nâng cấp và cần kiểm thử lại các tính năng đã thực hiện tốt trước đó, kiểm trakhả năng vận hành của sản phẩm trong các môi trường đặc biệt (đo tốc độ xử lýtrung bình ứng với mỗi yêu cầu, xác định khả năng chịu tải tối đa, xác định cấu hìnhtối thiểu để thực thi hệ thống, kiểm tra các cơ chế an ninh và an toàn ).

1.2.8.2 Lý do cần phải kiểm thử tự động

- Giảm bớt công sức và thời gian thực hiện quá trình kiểm thử- Tăng độ tin cậy.

- Giảm sự nhàm chán cho conngười

- Rèn luyện kỹ năng lập trình cho kiểm thử viên- Giảm chi phí cho tổng quá trình kiểm thử.

1.2.8.3 Ưu điểm và nhược điểm của kiểm thử tự động Ưu điểm:

- Kiểm thử chính xác và có thể bao quát thông tin.

- Theo dõi được chính xác kết quả từng giai đoạn và các báo cáo tổng hợp.- Cần ít nhân lực trong quá trình kiểm thử.

- Chu kỳ kiểm thử diễn ra trong thời gian ngắn.

- Hiệu năng của kiểm thử các lớp vượt xa tầm với của kiểm thử thủ công.

- Khu vực kiểm thử tự động có thể không bao quát đầy đủ, không áp dụngđược trong việc tìm lỗi mới của phần mềm.

1.2.8.4 Các trường hợp nên áp dụng kiểm thử tự động

Không phải lúc nào cũng nên áp dụng kiểm thử tự động trong việc kiểm thửphần mềm, vì nhiều khi chi phí và thời gian cho việc kiểm thử tự động còn lớn hơnnhiều so với kiểm thử thủ công Dưới đây là một số trường hợp nên áp dụngphương pháp kiểm thử tự động để đạt được hiệu quả cao về thời gian, chi phí cũngnhư chất lượng.

- Trường hợp không đủ tài nguyên: Là khi số lượng trường hợp kiểm thử lặplại quá nhiều trên nhiều môi trường kiểm thử khác nhau, không có đủ nguồn nhânlực để kiểm thử thủ công trong một giới hạn thời gian nào đó.

- Trường hợp kiểm thử hồi qui: Trong quá trình phát triển phần mềm, nhómlập trình thường đưa ra nhiều phiên bản phần mềm liên tiếp để kiểm thử Thực tếcho thấy việc đưa ra các phiên bản phần mềm có thể là hàng ngày, mỗi phiên bảnbao gồm những tính năng mới, hoặc tính năng cũ được sửa lỗi hay nâng cấp Việcbổ sung hoặc sửa lỗi mã chương trình cho những tính năng ở phiên bản mới có thểlàm cho những tính năng khác đã kiểm tra tốt chạy sai mặc dù phần mã chươngtrình của nó không hề chỉnh sửa.

- Trường hợp kiểm thử khả năng vận hành phần mềm trong môi trường đặcbiệt.

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

Không phải mọi kiểm thử đều có thể thực hiện tự động và sẽ khó khăn khi lựachọn kiểm thử theo cách nào Những điểm mạnh và điểm yếu được liệt kê dưới đâysẽ giúp chúng ta dễ dàng hơn khi lựa chọn giải pháp kiểm thử tự động hay kiểm thửthủ công.

Điểm mạnh:

- Kiểm thử tự động:

 Nếu ta phải thực hiện một loạt các kiểm tra liên tục và lặp lại thì tự động hóalà một lợi lớn Giúp thực hiện "kiểm tra khả năng tương thích" - kiểm thử phầnmềm trên cấu hình khác nhau.

 Nó cung cấp cho chúng ta khả năng để thực hiện tự động hóa các kiểm thửhồi quy trong một thời gian ngắn.

 Nó cung cấp cho chúng ta khả năng để thực hiện kiểm thử hồi quy trên mộtđoạn code liên tục thay đổi.

 Có thể chạy đồng thời trên các máy khác nhau do đó giảm thời giankiểm thử.

 Giảm được chi phí dài hạn.

-Kiểm thử thủ công:

 Kiểm thử thủ công tốn thời gian hơn.

 Đối với mỗi bản phát hành (release), chúng ta phải chạy lại cùng một tậphợp các kiểm thử đã làm có thể dẫn đễn sự mệt mỏi và lãng phí.

1.2.9 Nguyên tắc quan trọng trong kiểm thử phần mềm

Có 7 nguyên tắc cơ bản cần chú ý khi kiểm thử phần mềm, các nguyên tắc đó là:

- Kiểm thử đưa ra lỗi: Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi,nhưng không thể chứng minh rằng phần mềm không có lỗi Kiểm thử được thực hiệnbằng những kĩ thuật khác nhau Kiểm thử làm giảm xác suất lỗi chưa tìm thấy vẫncòn trong phần mềm, ngay cả khi đã kiểm thử nghiêm ngặt phần mềm vẫn có thể cònlỗi Vì vậy chúng ta phải tìm được càng nhiều lỗi càng tốt [10]