NGHIÊN cứu KIỂM THỬ PHẦN mềm và CÔNG cụ KIỂM THỬ PHẦN mềm tự ĐỘNG JMETER

Nên với mong muốn mọi người có một cái nhìn xác thực hơn, rõ ràng hơn vềkiểm thử phần mềm và tiếp cận gần với công cụ kiểm thử phần mềm tự động Jmeter để làm tiền đề cho việc định hướng

TRƯỜNG ĐẠI HỌC TÀI NGUYÊN VÀ MÔI TRƯỜNG HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN



NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ

CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ ĐỘNG JMETER

Hà Nội – Năm 2020

TRƯỜNG ĐẠI HỌC TÀI NGUYÊN VÀ MÔI TRƯỜNG HÀ NỘI

KHOA CÔNG NGHỆ THÔNG TIN



ĐẶNG THỊ QUỲNH

NGHIÊN CỨU KIỂM THỬ PHẦN MỀM VÀ

CÔNG CỤ KIỂM THỬ PHẦN MỀM TỰ ĐỘNG JMETER

Chuyên ngành : Công nghệ thông tin

Mã ngành : 7480201

NGƯỜI HƯỚNG DẪN: THS PHÍ THỊ HẢI YẾN

Hà Nội – Năm 2020

LỜI CAM ĐOAN

Em xin cam đoan đề tài: “Nghiên cứu kiểm thử phần mềm và công cụ kiểmthử phần mềm tự động JMeter” là một công trình nghiên cứu độc lập dưới sự hướngdẫn của giáo viên hướng dẫn: ThS Phí Thị Hải Yến

Ngoài ra không có bất cứ sự sao chép của người khác Đề tài, nội dung báocáo thực tập là sản phẩm mà em đã nỗ lực nghiên cứu trong quá trình học tập tạitrường cũng như tham gia thực tập tại công ty FSoft

Các số liệu, kết quả trình bày trong báo cáo là hoàn toàn trung thực, em xinchịu hoàn toàn trách nhiệm, kỷ luật của bộ môn và nhà trường đề ra nếu như có vấn

đề xảy ra

LỜI CẢM ƠN

Để bài đồ án này đạt kết quả tốt đẹp, em đã nhận được sự hỗ trợ, giúp đỡ củanhiều cơ quan, tổ chức, cá nhân Với tình cảm sâu sắc, chân thành cho phép emđược bày tỏ lòng biết ơn sâu sắc đến tất cả các cá nhân và cơ quan đã tạo điều kiệngiúp đỡ trong quá trình học tập và nghiên cứu đề tài

Trước hết em xin gửi tới các thầy cô khoa Công nghệ thông tin trường Đạihọc Tài nguyên và môi trường Hà Nội lời chúc sức khỏe và lời cảm ơn sâu sắc nhất.Với sự quan tâm, dạy dỗ, chỉ bảo tận tình chu đáo của thầy cô, đến nay em đã có thể

hoàn thành đồ án, đề tài: "Nghiên cứu kiểm thử phần mềm và công cụ kiểm thử phần mềm tự động JMeter"

Đặc biệt em xin gửi lời cảm ơn chân thành nhất tới cô giáo – ThS.Phí Thị HảiYến đã quan tâm giúp đỡ, hướng dẫn em hoàn thành tốt bài đồ án tốt nghiệp nàytrong thời gian qua

Em xin bày tỏ lòng biết ơn đến lãnh đạo trường Đại học Tài nguyên và môitrường Hà Nội, các khoa phòng ban chức năng đã trực tiếp và gián tiếp giúp đỡ emtrong suốt quá trình học tập và nghiên cứu đề tài

Với điều kiện thời gian cũng như kinh nghiệm còn hạn chế của một học viên,bài đồ án này không thể tránh được những thiếu sót Em rất mong nhận được sự chỉbảo, đóng góp ý kiến của các thầy cô để em có điều kiện bổ sung, nâng cao ý thứccủa mình, phục vụ tốt hơn công tác thực tế sau này

Em xin chân thành cảm ơn!

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

Sinh viên thực hiện

Đặng Thị Quỳnh

MỤC LỤC

LỜI CAM ĐOAN i

LỜI CẢM ƠN ii

MỤC LỤC iii

DANH MỤC CÁC CHỮ VIẾT TẮT vi

DANH MỤC CÁC HÌNH vii

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

MỞ ĐẦU 1

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

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

3 Phương pháp nghiên cứu đề tài 2

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

5 Nội dung chính 2

6 Kết quả chính đạt được 3

CHƯƠNG 1 TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM THỬ PHẦN MỀM 4

1.1 Chất lượng phần mềm 4

1.1.1 Định nghĩa chất lượng phần mềm 4

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

1.2 Lỗi phần mềm 4

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

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

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

1.2.4 Quy trình xử lý lỗi phần mềm 7

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

1.3.1 Khái niệm kiểm thử phần mềm 7

1.3.2 Lý do cần kiểm thử phần mềm 7

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

1.3.4 Các nguyên tắc cơ bản của kiểm thử phần mềm 8

1.4 Các phương pháp kiểm thử phần mềm 9

1.4.1 Kiểm thử tĩnh – Static testing 9

1.4.2 Kiểm thử động – Dynamic testing 9

1.5 Các kỹ thuật cơ bản của kiểm thử phần mềm 10

1.5.1 Kiểm thử hộp đen (Black Box Testing – BBT) 10

1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT) 12

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

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

1.6.1 Các bước trong một quy trình kiểm thử phần mềm 17

1.6.3 Quy trình xây dựng kế hoạch kiểm thử 20

1.7 Kiểm thử tự động và kiểm thử hiệu năng 21

1.7.1 Kiểm thử tự động (Automate Testing) 21

1.7.2 Kiểm thử hiệu năng 27

CHƯƠNG 2 NGHIÊN CỨU CÔNG CỤ KIỂM THỬ HIỆU NĂNG JMETER 31

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

2.2 Đặc trưng của JMeter 32

2.3.1 Test Plan 32

2.3.2 Các thành phần của Test Plan 37

2.4 Webservice 39

2.5 JDBC REQUEST 41

Hình 2.13 Giao diện một JDBC Connection Configuration 41

2.6 FTP REQUEST 43

CHƯƠNG 3 ỨNG DỤNG CÔNG CỤ JMETER VÀO KIỂM THỬ HIỆU NĂNG HỆ THỐNG OPEN SOURCE SIMPLCOMMERCE 46

3.1 Giới thiệu về Open Source SimplCommerce 46

3.1.1 Hệ thống Source SimplCommerce là gì ? 46

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

3.2.1 Môi trường kiểm thử 48

3.2.2 Kịch bản kiểm thử 49

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

3.3 Thực hiện cấu hình và chạy trên Jmeter 52

3.3.1 Cấu hình 52

3.3.2 Chạy để lấy kết quả 54

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

3.4.1 Phân tích 57

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

3.4.3 Đánh giá, kết luận 64

KẾT LUẬN 66

TÀI LIỆU THAM KHẢO 67

DANH MỤC CÁC CHỮ VIẾT TẮT

Thuật ngữ/

IEEE Institue of Electrical and

Electronic Engineers

Viện kỹ thuật điện và điện tử -

1 tổ chức phi lợi nhuận giúp phát triển, đổi mới công nghệ

hoặc các lớp có thể sử dụng lại được

mỗi mô-đun đảm nhiệm 1 chứcnăng riêng

phần mềm, chỉ sự kiểm tra tính hợp lệ của dữ liệu trên một yếu

tố của ứng dụngJDK Java Development Kit Bộ ứng dụng phát triển JavaJRE Java Runtime Environment Môi trường chạy Java

Manager

Bộ giao thức bảo mật của Microsoft nhằm cung cấp xác thực, tính toàn vẹn và bảo mật cho người dùngJDBC Java Database Connectivity Kết nối cơ sở dữ liệu Java

DANH MỤC CÁC HÌNH

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

Bảng 1.1 Ưu nhược điểm của kiểm thử hộp đen 12

Bảng 1.2 Ưu nhược điểm của kiểm thử hộp trắng 14

Bảng 1.3 Ưu nhược điểm của phương pháp kiểm thử hộp xám 15

Bảng 1.4 Bảng so sánh ba phương pháp kiểm thử 16

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

Hình 1.3 Mô hình phát triển và kiểm thử phần mềm hình chữ V 19

Hình 1.4 Quy trình kiểm thử tự động 24

Hình 1.5 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra 25

Hình 1.6 Quy trình kiểm thử hiệu năng 29

Hình 2.1 Mô phỏng tải trọng lớn trong Jmeter 32

Hình 2.2 Mở file chạy tool Jmeter 33

Hình 2.3 Giao diện của JMeter 33

Hình 2.4 Chọn template 34

Hình 2.5 Đặt tên các bước 34

Hình 2.6 Thêm các Listener 35

Hình 2.7 Chỉnh sửa HTTP Proxy Server 36

Hình 2.8 Lưu kế hoạch kiểm thử 36

Hình 2.9 Thực hiện chạy Test Plan 37

Hình 2.10 Các bước tạo 1 SOAP WebService Test Plan 40

Hình 2.11 Nhập thông tin cho Header Manager 40

Hình 2.12 Nhập các thông tin tương ứng cho webservice 40

Hình 2.14 Mô tả Driver type 41

Hình 2.15 Giao diện JDBC Request 42

Hình 2.16 Giao diện JDBC Request 43

Hình 2.17 Tạo một FTP Test Plan 44

Hình 2.18 Thêm FTP connection param 44

Hình 2.19 Lấy dữ liệu bằng file Zilla 44

Hình 2.20 Kiểm tra với phương thức GET 45

Hình 3.1 Trang chủ của SimplCommerce 46

Hình 3.2 Trang giao diện sản phẩm 46

Hình 3.3 Trang giao diện giỏ hàng 47

Hình 3.4 Trang giao diện thẻ thanh toán 47

Hình 3.5 Trang giao diện Admin của website 48

Hình 3.6 Test Plan được jmeter ghi lại với kịch bản kiểm thử số 1 (mua hàng cơ bản)52 Hình 3.7 Đặt Module, Assertion, Timer, Listener, User Parameter, Regular Expression 53

Hình 3.8 Cấu hình cho Thread, Loop, Ram-up 54

Hình 3.9 Di chuyển đến thư mục bin jmeter 55

Hình 3.10 Chạy lệnh tạo ra report html 55

Hình 3.11 Cửa sổ command prompt sau khi tạo xong report 56

Hình 3.12 File csv report được tạo thành công 56

Hình 3.13 File html report được tạo thành công sau khi csv file được tạo ra 57

Hình 3.14 View report dashboard 57

Hình 3.15 Bảng Statistics 58

Hình 3.16 Error và Top 5 Error 58

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

Bảng 1.1 Ưu nhược điểm của kiểm thử hộp đen 12

Bảng 1.2 Ưu nhược điểm của kiểm thử hộp trắng 14

Bảng 1.3 Ưu nhược điểm của phương pháp kiểm thử hộp xám 15

Bảng 1.4 Bảng so sánh ba phương pháp kiểm thử 16

Bảng 3.1 Môi trường máy chịu tải 48

Bảng 3.2 Môi trường máy đẩy tải 49

Bảng 3.3 Kịch bản kiểm thử 49

Bảng 3.4 Tình huống test 51

Bảng 3.4 Cấu hình cho Thread, Loop, Ram-up 54

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

Bảng 3.6 Kết quả test thực tế 60

MỞ ĐẦU 1.Lý do chọn đề tài

Cùng với sự phát triển vượt bậc của ngành nghề công nghệ thông tin, ngànhcông nghệ phần mềm đang dần chiếm một vị trí quan trọng trong xu hướng pháttriển của nền kinh tế công nghiệp hoá, hiện đại hóa đất nước Việc phát triển củacông nghệ phần mềm, việc đảm bảo chất lượng phần mềm luôn là một thách thức lớnđối với bản thân của mỗi một người làm phần mềm Ở Việt Nam hiện nay, việc kiểmthử phần mềm chưa thực sự được coi trọng, khi mà tỷ lệ kỹ sư kiểm thử phần mềm ởnước ta đang ở mức khá thấp Trong khi đó theo mức chuẩn quốc tế thì tỷ lệ này cầnđược giữ ở mức 3:1 nghĩa là cứ ba lập trình viên thì phải có một kiểm thử Tiếp đó,mức độ đáp ứng của kỹ sư kiểm thử phần mềm ở Việt Nam chưa cao do thiếu hụt cácđơn vị đào tạo chuyên sâu về kiểm thử và nước ta vẫn chưa trú trọng vào đào tạochuyên nghiệp cũng như có sự đầu tư đúng mức cho việc đào tạo ngành nghề này

Để làm ra một phần mềm vừa đáp ứng được nhu cầu của người dùng, vừakhông gây thiệt hại đối với người sản xuất khi có lỗi xảy ra thì công đoạn kiểm thửphần mềm là một công đoạn vô cùng quan trọng Kiểm thử phần mềm là công đoạnkiểm thử nhằm đảm bảo rằng tất cả các thành phần của phần mềm hoạt động ănkhớp với nhau, vận hành như mong đợi và đạt được các tiêu chí thiết kế của nhà sảnxuất Hoạt động kiểm thử phần mềm là một phần quan trọng của tiến trình phát triểnphần mềm Nó góp phần nâng cao chất lượng của phần mềm, là một quy trình bắtbuộc trong dự án phát triển phần mềm của đất nước

Nên với mong muốn mọi người có một cái nhìn xác thực hơn, rõ ràng hơn vềkiểm thử phần mềm và tiếp cận gần với công cụ kiểm thử phần mềm tự động Jmeter

để làm tiền đề cho việc định hướng tương lai sau khi tốt nghiệp của chính bản thân

em Em quyết định lựa chọn đề tài “Nghiên cứu kiểm thử phần mềm và công cụ kiểm thử phần mềm tự động JMeter” làm đề tài cho đồ án tốt nghiệp của mình 2.Mục tiêu của đề tài

2.1 Mục tiêu chung:

Giúp mọi người có một cách nhìn khách quan và tổng quát nhất về kiểm thửphần mềm cũng như là các công cụ kiểm thử phần mềm tự động, trong đó có công

cụ kiểm thử phần mềm Jmeter

2.2 Mục tiêu cụ thể:

- Nắm được kiến thức về kiểm thử phần mềm, quy trình thực hiện, triển khai

công việc kiểm thử phần mềm

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

- Nắm được cách thức sử dụng bộ công cụ JMeter

- Ứng dụng được các kiến thức kiểm thử phần mềm và kiến thức về Jmeter để

viết kịch bản kiểm thử cho phần mềm quản lý bán hàng

3 Phương pháp nghiên cứu đề tài

- 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 và tài liệu về bộ công cụ kiểm thử phần mềm JMeter

- Phương pháp tổng hợp: Tổng hợp các tài liệu, giới thiệu cơ sở lý thuyết về

kiểm thử phần mềm

- Phương pháp thực nghiệm: Tiến hành test thử ứng dụng đã xây dựng để

kiểm tra kết quả đạt được

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

4.1 Đối tượng

- Cơ sở lý thuyết về kiểm thử phần mềm, kiểm thử hiệu năng website

- Công cụ kiểm thử phần mềm tự động JMeter

4.2 Phạm vi nghiên cứu

- Tìm hiểu cơ sở lý thuyết về kiểm thử phần mềm, kiểm thử hiệu năng website

- Nghiên cứu, tìm hiểu cách sử dụng, thao tác với công cụ kiểm thử hiệu năngJmeter để thực hiện các kỹ thuật kiểm thử hiệu năng website

5 Nội dung chính

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

Chương 1: Tổng quan về chất lượng 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ề chất lượng phần mềm, kiểmthử phần mềm như các nguyê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, kiểm thử tự động và kiểm thử hiệu năng

Chương 2: Nghiên cứu công cụ kiểm thử hiệu năng Jmeter:

Chương này trình bày tổng quan về công cụ JMeter, cách cài đặt, sử dụngJMeter để tạo một test plan, các thành phần trong JMeter, khái niệm về web service,tạo test plan web service, tạo test plan cho JDBC

Chương 3: Ứng dụng công cụ Jmeter vào kiểm thử hiệu năng hệ thống Opensource SimplCommerce

Chương tập trung giới thiệu hệ thống của website, các chức năng chính khingười dùng đăng nhập hệ thống, lập kế hoạch kiểm thử, thực hiện cấu hình và chạyJMeter, phân tích báo cáo đánh giá kết quả

6 Kết quả chính đạt được

Qua quá trình nghiên cứu và triển khai ứng dụng kiểm thử hiệu năng websiteSimplCommerce sử dụng công cụ JMeter Apache, em đã đạt được một số kết quảnhư sau:

- Nắm được các phương pháp, kỹ thuật kiểm thử phần mềm

- Cài đặt được công cụ JMeter

- Ứng dụng được JMeter vào kiểm thử hiệu năng hệ thống Open SourceSimplcomerce

Bên cạnh những kết quả đạt được, đề tài còn có những hạn chế như sau:

- Chưa sử dụng công cụ kiểm thử JMeter một cách triệt để

- Trong quá trình chạy phần mềm, chất lượng mạng còn kém và không ổnđịnh nên kết quả test chỉ mang tính tương đối

CHƯƠNG 1 TỔNG QUAN VỀ CHẤT LƯỢNG PHẦN MỀM VÀ KIỂM

THỬ PHẦN MỀM

1.1 Chất lượng phần mềm

1.1.1 Định nghĩa chất lượng 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 em sẽ trình bày một số định nghĩatiêu biểu [1]

Định nghĩa theo IEEE:

Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống, thànhphần hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả

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

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

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ần mề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ầu quản lý theo lịch trình và hoạt động trong giới hạn ngân sách [2]

1.2Lỗi phần mềm

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ưng có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ớp giữachương trình và đặc tả của nó"

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ạikhô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.2.2 Các nguyên nhân gây lỗi phần mềm

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ườngnằ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àythườ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 sai chỉ dẫn trong tài liệu yêu cầu, hiểu sai thay đổi khi khách hàng trìnhbày bằng lời nó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ách hà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à cungcấ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ácnhà 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âncủa việ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ớicác yêu cầu mớ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ápnhư 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 giathiế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ênnhâ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ự án

- 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ủatiế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ức tạ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à chophép kiểm tra các kết quả trung gian Các lỗi có thể đến từ việc viết các thủ 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ảotrì 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.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àng sớmcà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ìm và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í chosử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át triểnphần mềm.

1.2.4 Quy trình xử lý lỗi phần mềm

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.3 Kiểm thử phần mềm

1.3.1 Khái niệm kiểm thử phần mề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 [1]

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

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?

1.3.2 Lý do cần kiểm thử phần mềm

- Phần mềm nào cũng có lỗi bởi vì nó do con người làm ra.

- Kiểm thử độ tin cậy của phần mềm.

- Các lỗi đang dùng trong thực tế có thể rất tốn chi phí cũng như gây nguy

hiểm đến con người

- Tránh kiện tụng của khách hàng.

- Phát triển doanh nghiệp.

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

1.3.3 Mục tiêu 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.3.4 Các nguyên tắc cơ bản của 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ử để chứng minh sự có mặt của lỗi và không chứng minh điều ngượclại Kiểm thử có thể cho thấy sự có mặt của lỗi nhưng không thể chứng minh điềungược lại là chương trình không có lỗi Việc kiểm thử giảm nguy cơ không tìm thấylỗi trong phần mềm nhưng ngay cả khi không tìm thấy lỗi thì cũng không thể chứngminh được sản phẩm phần mềm được phát triển hoàn toàn chính xác

- Không thể kiểm thử vét cạn: Việc kiểm thử không thể thực hiện được cho tấtmọi trường hợp kiểm thử Do vậy thay vì kiểm thử mọi khía cạnh, ta phải tập trungvào kiểm thử nhữ ng yếu tố quan trọng và nhiều rủi do

- Kiểm thử sớm: Các hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trongvòng đời phát triển phần mềm, và nên tập trung và những mục tiêu kiểm thử nhấtđịnh

- Phân cụm lỗi: Một số lượng nhỏ các mô-đun phần mềm có thể chứa hầu hếtcác lỗi được phát hiện ra trong suốt quá trình kiểm thử hoặc tập trung hầu hết cáclỗi vận hành

- Kiểm thử ngược: Nếu một phương pháp kiểm thử được lặp đi lặp lại nhiềulần, các trường hợp kiểm thử giống nhau sẽ không phát hiện được triệt để lỗi mới

Để khắc phục điều này ta có thể sử dụng nguyên tắc "kiểm thử ngược", các trường

hợp kiểm thử cần phải được xem xét và duyệt lại một cách đều đặn, và việc kiểmthử mới cần phải được viết lại để thực thi nhữ ng phần khác của phần mềm hay hệthống để tìm ra nhữ ng lỗi tiềm ẩn.

- Kiểm thử phụ thuộc vào ngữ cảnh: Việc kiểm thử được thực hiện trongnhững hoàn cảnh khác nhau thì khác nhau

- Sai lầm về việc không có lỗi: Tìm kiếm và sửa lỗi không thể giúp được gìnếu hệ thống không dùng được hoặc không đáp ứng được yêu cầu và sự mong đợicủa khách hàng

1.4 Các phương pháp kiểm thử phần mềm

Có rất nhiều phương pháp để kiểm thử phần mềm Việc đánh giá, định hướnghoặc kiểm tra phần mềm được gọi là kiểm thử tĩnh, trong khi việc chạy mã lập trìnhthực tế trong các tình huống được gọi là kiểm thử động Kiểm thử tĩnh thông thường

có thể được bỏ qua khi thực hành nhưng kiểm thử động diễn ra khi bản thân chươngtrình đó đang được sử dụng [2]

1.4.1 Kiểm thử tĩnh – Static testing

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ịch

mà xác nhận tính hợp lệ về cú pháp của chương trình

1.4.2 Kiểm thử động – Dynamic testing

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ác

ca 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.5 Các kỹ thuật cơ bản của kiểm thử phần mềm

1.5.1 Kiểm thử hộp đen (Black Box Testing – BBT)

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ềmgiống như một hộp đen mà bên trong người ta không thể nhìn thấy Phương phápnày thực hiện để tìm ra 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

- 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 Phương pháp này đặc biệt dựavào kinh nghiệm và kiến thức của tester Nhiều tester cố gắng đoán xem phần nàocủ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ộtcông cụ hay một kị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, 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ẽ chochúng ta các kịch bản kiểm thử phù hợp

Phân vùng tương đương (Equivalence Class): là một kỹ thuật kiểm thử phầnmềm có liên quan đến phân chia các giá trị đầu vào thành các phân vùng hợp lệ vàkhông hợp lệ, sau đó chúng ta sẽ viết ra các kịch bản kiểm thử cho từng phần, chọngiá trị đại diện từ mỗi phân vùng làm dữ liệu thử nghiệm

Phân tích giá trị biên (Boundary Value Analysis): là một kỹ thuật kiểm thửphần mềm có liên quan đến việc xác định biên (ranh giới) của điều kiện mô tả chocác giá trị đầu vào và chọn giá trị ở biên và bên cạnh giá trị biên làm dữ liệu kiểmthử Phương pháp phân tích giá trị biên sẽ đưa ra các giá trị đặc biệt, bao gồm loại

dữ liệu, giá trị lỗi, bên trong, bên ngoài biên giá trị, lớn nhất và nhỏ nhất

Sử dụng bảng quyết định (Decision Tables): Là dùng bảng để hiển thị danhsách các thao tác phần mềm được quyết định trên các điều kiện khác nhau Decisiontable testing chú trọng vào nhiều điều kiện để thực hiện test.

Ngoài ra, kiểm thử hộp đen còn có một số kỹ thuật như: Domain Tests,Orthogonal Arrays, State Models, Exploratory Testing (kiểm thử chủ yếu dựa vàokinh nghiệm và khả năng focus vào việc test các chức năng của tester), All-pairstesting (kiểm thử tất cả các cặp),

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

Bảng 1.1 Ưu nhược điểm của kiểm thử hộp đen

Phù hợp, hiệu quả khi số lượng các

Phân biệt được rõ ràng quan điểm

của người dùng với quan điểm của

nhà phát triển

Độ bao phủ sẽ bị thiếu vì tester không kiểm trađược các đoạn lệnh của hệ thống hoặc tập trung vào các dòng lệnh dễ xảy ra lỗi

Không cần đòi hỏi những kiến thức

về ngôn ngữ lập trình ở các tester

để có thể kiểm thử hệ thống

Sẽ khó để có thể thiết kế đầy đủ các trường hợp kiểm thử

1.5.2 Kiểm thử hộp trắng (White Box Testing – WBT)

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) có đáp ứng tốt tất cả các giá trị input baogồm cả các giá trị không đúng hay không theo dự định của chương trình Chiếnlượ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ươngtrì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ươngtrì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

- 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ệntrên tổng số test case cần thiết cho ứng dụng Nếu tỉ lệ này càng cao thì ứng dụngcàng được test kỹ Mặc dù việc đảm bảo ứng dụng có test coverage là 100% trongmộ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

+ 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

- Ưu nhược điểm của kiểm thử hộp trắng

Bảng 1.2 Ưu nhược điểm của kiểm thử hộp trắng

Đối với những tester có kiến thức về

Giúp tối ưu hóa các dòng lệnh của hệ

thống

Đôi lúc sẽ là không khả thi khi kiểm tra chitiết từng dòng lệnh để có thể từ đó phát hiện ra các lỗi tiềm ẩn của hệ thống, có rất nhiều các luồng không thể kiểm tra được.Các dòng lệnh không cần thiết hoặc các

dòng lệnh có khả năng mang đến các lỗi

tiềm ẩn sẽ bị loại bỏ

Rất khó để duy trì phương pháp này liên tục, cần phải có những tool chuyên biệt như tool về phân tích code hay tool về pháthiện lỗi và sửa lỗi

Các tester có kiến thức về ngôn ngữ lập

trình sau khi đã thực hiện phương pháp

này thì sẽ dễ dàng đạt được độ bao phủ

lớn nhất khi thực hiện thiết kế các

trường hợp kiểm thử sau này

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

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ợp giữakiểm thử hộp đen và kiểm thử hộp trắng Trong kiểm thử hộp xám, cấu trúc bêntrong sản phẩm chỉ được biết một phần Tester có thể truy cập vào cấu trúc dữ liệubê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ưngkhi test thì test như là người dùng cuối hoặc mức hộp đen Loại kiểm thử này đượcgọi là kiếm thử hộp xám vì trong chương trình phần mềm, mắt của tester giố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ột phần

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 test khácnhau nhưng chủ yếu nó hữu dụng trong mức Intergration Testing – kiểm thử tích hợp

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

Bảng 1.3 Ưu nhược điểm của phương pháp kiểm thử hộp xám

Vì là sự kết hợp giữa kiểm thử hộp

trắng và kiểm thử hộp đen nên có được

ưu điểm của cả hai phương pháp này

Vì phương pháp này không dựa trên việc truy cập code của hệ thống nên sẽ không tránh được việc độ bao phủ của các trường hợp kiểm thử bị giới hạn

Các tester sử dụng phương pháp này

không dựa vào các dòng lệnh của hệ

thống mà chủ yếu dựa trên các tài liệu

định nghĩa giao diện cũng như các tài

liệu đặc tả chức năng

Khi sử dụng phương pháp này thì nhiều trường hợp kiểm thử có thể bị dư thừa nếu

mà những nhà thiết kế phần mềm đã chạy các trường hợp kiểm thử này trước đó

Trong phương pháp này các tester có

thể thiết kế nên những trường hợp kiểm

thử đặc biệt xung quanh các giao thức

kết nối và các loại dữ liệu khác nhau

Việc kiểm tra tất cả các luồng đầu vào của

hệ thống là không thể thực hiện được vì bị giới hạn về mặt thời gian kiểm thử và sẽ dẫn đến có rất nhiều các luồng hoạt động của hệ thống không được kiểm tra

Việc kiểm thử được hoàn thành từ góc

nhìn của người dùng chứ không phải từ

Bảng 1.4 Bảng so sánh ba phương pháp kiểm thử

Kiểm thử hộp đen Kiểm thử hộp xám Kiểm thử hộp trắng

Không cần quan tâm đến các

luồng hoạt động trong hệ

thống

Cần có kiến thức nhất định về các luồng hoạt động bên trong hệ thống

Cần nắm được toàn bộ các luồng hoạt động bên trong hệ thống.Được biết đến với các tên gọi

khác như: closed-box testing,

data-driven testing hoặc

Được thực hiện bởi người

dùng cuối, kiểm thử viên và

lập trình viên

Được thực hiện bởi người dùng cuối, kiểm thử viên và lập trình viên

Thường thì được hoàn thành bởi kiểm thử viên

và lập trình viên

Việc kiểm thử dựa trên kết

quả mong muốn và kết quả

Vì chỉ quan tâm đến các giá

trị đầu vào, kết quả đầu ra và

kết quả mong đợi nên đây là

phương pháp tốn ít thời gian

nhất cũng như đô bao phủ các

trường hợp không đầy đủ

Mức độ đầy đủ của các trường hợp kiểm thử ở mức vừa phải

và mức độ tốn thời gian là vừa phải

Đầy đủ nhất và tốn nhiều thời gian nhất

Kiểm thử hộp đen Kiểm thử hộp xám Kiểm thử hộp trắng

nhất

Không thích hợp để kiểm tra

các thuật toán trong hệ thống

Không thích hợp để kiểm tra các thuật toán trong hệ thống

Thích hợp để kiểm tra các thuật toán trong hệ thống

Phương pháp này sẽ được

hoàn thành bởi cơ chế phát

hiện lỗi

Các miền dữ liệu và các giới hạn có thể

sẽ được test nếu các tester có kiến thức vềnó

Các miền dữ liệu và các giới hạn sẽ được test

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

1.6.1 Các bước trong một quy trình kiểm thử phần mềm

Quy trình kiểm thử là 1 chuỗi các hoạt động, phương thức thực hiện mà conngười phải làm để thực hiện kiểm thử cho hệ thống phần mềm

Quy trình kiểm thử phần mềm bao gồm các bước:

+ Lập kế hoạch kiểm tra

+ Phân tích, thiết kế test case

+ Phát triển test script

+ Nguồn lực kiểm thử

+ Tài nguyên môi trường kiểm thử, bao gồm các tài nguyên phần cứng vàphần mềm

+ Mốc bàn giao các tài liệu kiểm thử

Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện Kếtquả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm thử phần mềm bao gồmnhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian và phânđịnh lực lượng kiểm tra viên, xác định tiêu chí kết thúc kiểm thử

b Phân tích và thiết kế test:

Nhằm chỉ định các test case và các bước kiểm tra chi tiết cho mỗi phần Giaiđoạn thiết kế test là hết sức quan trọng, nó đảm bảo tất cả các tình huống kiểm trahết tất cả các yêu cầu

Các bước thiết kế test:

+ Xác định và mô tả test case

+ Mô tả các bước chi tiết để kiếm tra

+ Xem xét và khảo sát độ bao phủ của việc kiểm tra

+ Xem xét test case và các bước kiểm tra

c Phát triển test script:

Bước này thường không bắt buộc trong các loại và mức kiểm tra, chỉ yêu cầutrong những trường hợp đặc thù cần thiết kế, tạo ra các test script có khả năng chạytrên máy tính giúp tự động hoá việc thực thi các bước kiểm tra đã định nghĩa ở cácbước thiết kế test

f Tổng kết quá trình kiểm thử:

Viết báo cáo tổng kết

Hình 1.2 Quy trình kiểm thử phần mềm 1.6.2 Mô hình phát triển và kiểm thử phần mềm hình chữ V

 Các tính chất cần ghi nhận trên mô hình chữ V:

Hình 1.3 Mô hình phát triển và kiểm thử phần mềm hình chữ V

+ Các hoạt động hiện thực và các hoạt động kiểm thử được tách biệt nhưng độquan trọng là như nhau

+ Chữ V minh họa các khía cạnh của hoạt động Verification và Validation.+ Cần phân biệt giữa các mức độ kiểm thử ở đó mỗi mức kiểm thử là kiểm thửtrên mức phát triển phần mềm tương ứng

- Mô hình phát triển tăng tiến - tương tác:

Quy trình thiết lập các yêu cầu phần mềm, thiết kế, xây dựng, kiểm thử hệthống phần mềm được thực hiện như 1 chuỗi các chu kỳ phát triển ngắn hơn Hệthống có được từ 1 bước lặp được kiểm thử ở nhiều cấp trong việc phát triển hệthống đó Kiểm thử hồi quy có độ quan trọng tăng dần theo các bước lặp (không cầntrong bước đầu tiên) Thanh kiểm tra và kiểm định có thể được thực hiện theo kiểutăng dần trên từng bước lặp.

Các tính chất của quy trình kiểm thử tốt:

+ Cần có 1 mức độ kiểm thử cho mỗi công đoạn phát triển phần mềm

+ Các mục tiêu kiểm thử sẽ bị thay đổi, mỗi mức kiểm thử nên có các mục tiêuđặc thù của mình

+ Việc phân tích và thiết kế testcase cho 1 mức độ kiểm thử nên bắt đầu sớmnhất như có thể có

+ Các tester nên xem xét các tài liệu sớm như có thể có, ngay sau khi các tàiliệu này được tạo ra trong chu kỳ phát triển phần mềm

+ Số lượng và cường độ của các mức kiểm thử được điều khiển theo các yêucầu đặc thù của project phần mềm đó

1.6.3 Quy trình xây dựng kế hoạch kiểm thử

Sau khi xây dựng xong kế hoạch kiểm thử, ta có thể thay đổi nó nhưng phảituân thủ quy trình yêu cầu thay đổi Các hoạt động chính trong việc xây dựng kếhoạch kiểm thử:

- Định nghĩa mục đích, phạm vi, chiến lược, cách tiếp cận, các điều kiệnchuyển, các rủi ro, kế hoạch giảm nhẹ và tiêu chí chấp thuận

- Định nghĩa cách thức thiết lập môi trường và các tài nguyên được dùng choviệc kiểm thử

- Thiết lập cơ chế theo dõi lỗi phát hiện

- Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần mềm

- Báo cáo trạng thái kiểm thử

- Phát hành leo thang (Escalating Issues)

1.7 Kiểm thử tự động và kiểm thử hiệu năng

1.7.1 Kiểm thử tự động (Automate Testing)

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ử

a 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ử bằng một công cụ nhằm rút ngắn thời gian kiểm thử Mục đíchcủ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ử trong quá trình kiểmthử 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, )

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

Kiểm thử phần mềm tự động với mục đích:

- 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 con ngườ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ử

c Ư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

- Nhược điểm:

+ Chi phí cao cho việc chuyển giao công nghệ và đào tạo nhân viên

+ Tốn chi phí đầu tư lớn cho việc phát triển công cụ kiểm thử tự động

+ Tốn chi phí và thời gian cho việc tạo các kịch bản kiểm thử và bảo trì cáckịch bản kiểm thử

+ Giai đoạn chuẩn bị kiểm thử yêu cầu nhiều nhân lực

+ 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

d 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ử Việc bổ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àmcho những tính năng khác đã kiểm tra tốt chạy sai mặc dù phần mã chương trì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 đặc biệt

e 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 đây

sẽ 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óa

là 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 gian kiể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ảnphát hành (release), chúng ta phải chạy lại cùng một tập hợp các kiểm thử đã làm cóthể dẫn đễn sự mệt mỏi và lãng phí

f Quy trình kiểm thử tự động

Hình 1.4 Quy trình kiểm thử tự động

- Lập kế hoạch kiểm tra

+ Mục đích: Nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai vàthực hiện

+ Kết quả của bước lập kế hoạch là bản tài liệu kế hoạch kiểm thử phần mềm,bao gồm nhiều chi tiết từ các loại kiểm tra, chiến lược kiểm tra, cho đến thời gian vàphân định lực lượng kiểm tra viên

- Các bước lập kế hoạch:

+ Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽđược kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra Yêu cầu kiểm tra cũngđược dùng để xác định nhu cầu nhân lực

+ Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quátrình cũng như chất lượng kiểm tra Ví dụ: kỹ năng và kinh nghiệm của kiểm traviên quá yếu, không hiểu rõ yêu cầu

+ Xác định chiến lược kiểm tra: chỉ định phương pháp tiếp cận để thực hiệnviệc kiểm tra trên phần mềm, chỉ định các kỹ thuật và công cụ hỗ trợ kiểm tra, chỉđịnh các phương pháp dùng để đánh giá chất lượng kiểm tra cũng như điều kiện đểxác định thời gian kiểm tra

+ Xác định nhân lực, vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phầncứng, phần mềm, công cụ, thiết bị giả lập cần thiết cho việc kiểm tra

+ Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác địnhchi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quátrình kiểm tra

+ Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch chi tiết

+ Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người

có liên quan, kể cả trưởng dự án và có thể cả khách hàng Việc xem xét nhằm bảođảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai sóttrong các bản kế hoạch

- Thiết kế Test

+ Mục đích: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết chomỗi phiên bản phần mềm Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảmtất cả các tình huống kiểm tra "quét" hết tất cả yêu cầu cần kiểm tra Thiết kế testkhông phải chỉ làm một lần, nó sẽ được sửa chữa, cập nhật, thêm hoặc bớt xuyênsuốt chu kỳ phát triển phần mềm, vào bất cứ lúc nào có sự thay đổi yêu cầu, hoặcsau khi phân tích thấy cần được sửa chữa hoặc bổ sung

Hình 1.5 Thời điểm phù hợp để thiết lập các kế hoạch kiểm tra

- Các bước thiết kế test bao gồm:

+ Xác định và mô tả test case: xác định các điều kiện cần thiết lập trước vàtrong lúc kiểm tra Mô tả đối tượng hoặc dữ liệu đầu vào, mô tả các kết quả mongchờ sau khi kiểm tra

+ Mô tả các bước chi tiết để kiểm tra: các bước này mô tả chi tiết để hoànthành một test case khi thực hiện kiểm tra Thao tác này nhằm chi tiết hóa các bướccủa một test case, cũng như chỉ định các loại dữ liệu nào cần có để thực thi các testcase, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống + Xem xét và khảo sát độ bao phủ của việc kiểm tra: mô tả các chỉ số và cáchthức xác định việc kiểm tra đã hoàn thành hay chưa? bao nhiêu phần trăm phần

mềm đã được kiểm tra? Để xác định điều này có hai phương pháp: căn cứ trên yêucầu của phần mềm hoặc căn cứ trên số lượng code đã viết.

+ Xem xét test case và các bước kiểm tra: Việc xem xét cần có sự tham gia củatất cả những người có liên quan, kể cả trưởng dự án nhằm bảo đảm các test case và

dữ liệu yêu cầu là đủ và phản ánh đúng các yêu cầu cần kiểm tra, độ bao phủ đạtyêu cầu, cũng như để phát hiện (và sữa chữa) các sai sót

- Phát triển Test Script

Mục đích: Bước này thường không bắt buộc trong các loại và mức kiểm tra,chỉ yêu cầu trong trường hợp đặc thù cần thiết kế, tạ ra các Test Script có khả năngchạy trên máy tính giúp tự động hóa việc thực thi các bước kiểm tra đã định nghĩa ởbước thiết kế test

- Các bước phát triển Test Script bao gồm:

+ Tạo Test Script: thủ công hoặc dùng công cụ hỗ trợ để phát sinh Script mộtcách tự đông

+ Kiểm tra Test Script: xem có “chạy” tốt không nhằm đảm bảo các TestScript hoạt động đúng yêu cầu, thể hiện đúng ý đồ qua các bước kiểm tra

+ Thành lập các bộ dữ liệu ngoài dành cho các Test Script: bộ dữ liệu này sẽđược các Test script sử dụng khi thực hiện kiềm tra tự động Việc tách riêng dữ liệucho phép dễ dàng thay đổi dữ liệu khi kiểm tra, cũng như giúp việc chỉnh sửa hoặctái sử dụng các Script sau này

+ Xem xét và khảo sát độ bao phủ của việc kiểm tra: đảm bảo các test scriptđược tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu

- Đánh giá quá trình kiểm tra

+ Đánh giá quá trình kiểm tra thường thông qua các bước sau:

+ Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh giá

sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửithông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ đểkiểm tra sau đó

+ Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao phủyêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra (tính trên các yêu cầu của phầnmềm và số lượng code đã viết).

+ Phân tích lỗi: Đưa ra số liệu phục vụ cho việc cải tiến các qui trình pháttriển, giảm sai sót cho các chu kỳ phát triển và kiểm tra sau đó Ví dụ, tính toán tỷ lệphát sinh lỗi, xu hướng gây ra lỗi, những lỗi "ngoan cố" hoặc thường xuyên tái xuấthiện

+ Xác định quá trình kiểm tra có đạt yêu cầu hay không: Phân tích đánh giá đểxem các Test Case và chiến lược kiểm tra đã thiết kế có bao phủ hết những điểmcần kiểm tra hay không? Kiểm tra có đạt yêu cầu dự án không? Từ những kết quảnày, kiểm tra viên có thể sẽ phải thay đổi chiến lược hoặc cách thức kiểm tra

+ Báo cáo tổng hợp: Tổng hợp kết quả các bước ở trên và phải được gửi chotất cả những người có liên quan

1.7.2 Kiểm thử hiệu năng

a Khái niệm về kiểm thử hiệu năng

Kiểm thử hiệu năng được thực hiện để xác định tốc độ một hệ thống thực hiệnhay xử lý một khối lượng công việc cụ thể Hiệu năng chủ yếu được xác định bởi sựkết hợp của các yếu tố: số lượng tối đa người dùng truy cập đồng thời mà ứng dụng

có thể đáp ứng được (capacity measure), thông lượng (throughput) hay số lượnggiao dịch thành công trong một khoảng thời gian nhất định (transaction per second)

và thời gian đáp ứng (response time) là thời gian cần để hoàn thành một nhiệm vụhay chức năng Ngoài ra kiểm thử hiệu năng cũng dùng để đo khả năng chiếm dụngtài nguyên máy tính như RAM usage, CPU usage…

b Các tiêu chí của kiểm thử hiệu năng