NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG KIỂM THỬ WEBSITE THI ĐUA KHEN THƢỞNG

Tổng quan tình hình nghiên cứu thuộc lĩnh vực của đề tài. Trong giai đoạn phát triểncủa công nghệ thông tin, ngành công nghệ phần mềm đang ngày chiếm một vị trí quantrọng trong xu hƣớng phát triển kinh tế công nghiệp hóa hiện đại hóa của đất nƣớc ta.Cùng với sự phát triển của công nghệ phần mềm, lỗi phần mềm và chất lƣợng phần mềmluôn là thách thức với bản thân ngành phần mềm khi thực tế đã chứng minh, kiểm thửphần mềm là giai đoạn chiếm đến hơn 40% thời gian, kinh phí và nguồn nhân lực pháttriển dự án phần mềm hiện nay. Bên cạnh đó số lƣợng kỹ sƣ kiểm thử phần mềm Việt Nam hiện nay vẫn chƣa đápứng đƣợc nhu cầu thị trƣờng. Các dự án lập trình phần mềm trên thế giới, trung bình cứ3 lập trình viên có1 kiểm thử viên trong khi đó ở Việt Nam số lƣợng đó là 5 : 1. Tại hộinghị quốc tế kiểm thử tự động năm 2011 tại TP.HCM cho biết với đà phát triển củangành công nghiệp phần mềm nhƣ hiện nay thì Việt Nam trong thời gian tới sẽ thiếukhoảng 10.000 tester. Chúng ta đã và đang chứng kiến sự tăng trƣởng đáng kinh ngạccủa ngành công nghiệp phần mềm trong vài thập kỷ qua. Nếu nhƣ trƣớc đây phần mềmmáy tính chỉ đƣợc sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệu thì ngày naynó đã đƣợc ứng dụng vào mọi mặt của của đời sống hàng ngày của con ngƣời, từ cácứng dụng nhỏ để điều khiển các thiết bị dùng trong gia đình đến các ứng dụng lớn hơnnhƣ trợ giúp điều khiển các phƣơng tiện và hệ thống giao thông, trả tiền cho các hoáđơn, quản lý và thanh toán về tài chính, v.v...Vì thế con ngƣời ngày càng phụ thuộc chặtchẽ vào các sản phẩm phần mềm và do vậy đòi hỏi về chất lƣợng của các sản phẩm phầnmềm ngày càng cao, tức là các phần mềm phải đƣợc sản xuất với giá thành hạ, dễ dùng,an toàn và tin cậy đƣợc. Kiểm thử có phƣơng pháp là một hoạt động không thể thiếutrong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lƣợng nêu trên của cácsản phẩm phần mềm. Kiểm thử phần mềm là đề tài đang ngày càng nhận đƣợc sự quantâm, nghiên cứu lớn bởi tầm quan trọng của nó. Các kỹ thuật kiểm thử đã và đang đƣợcnghiên cứu phát triển trong ngành phần mềm trên khắp thế giới, nổi bật nhƣ ISTQB(International Software Testing Quanlifications Board) là một tổ chức phi lợi nhuậncung cấp chứng chỉ thẩm định chất lƣợng của kiểm thử phần mềm có giá trị toàn cầu đãđƣa ra hệ thống một loạt các tài liệu, sách cung cấp kiến thức về lý thuyết kiểm thử vàkỹ thuật kiểm thử phần mềm. Ở nƣớc ta, trong khoa Công nghệ thông tin thuộc cáctrƣờng đại học đã đặt kiểm thử phần mềm thành một môn học chính thức và xây dựnggiáo trình, bài giảng riêng cho môn học này, ví dụ nhƣ bài giảng điện tử môn học kiểmthử và bảo đảm chất lƣợng phần mềm của tác giả Thạc Bình Cƣờng, Khoa Công nghệthông tin, Trƣờng đại học Bách khoa Hà Nội đã trình bày khá chi tiết về lý thuyết các kỹthuật kiểm thử. Ngoài ra là các đề tài nghiên cứu đi sâu vào một kỹ thuật kiểm thử riêng

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT HÀ NỘI

NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG

KIỂM THỬ WEBSITE THI ĐUA KHEN THƯỞNG

Hà Nội, 2017

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT

ĐỒ ÁN TỐT NGHIỆP

CHUYÊN NGÀNH TIN HỌC TRẮC ĐỊA

ĐỀ TÀI

NGHIÊN CỨU VÀ ỨNG DỤNG KỸ THUẬT KIỂM THỬ HỘP ĐEN TRONG

KIỂM THỬ WEBSITE PHẦN MỀM THI ĐUA KHEN THƯỞNG

ThS NGUYỄN TUẤN ANH

Bộ môn Tin học trắc địa

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

MỤC LỤC

DANH MỤC CÁ C HÌ NH VẼ 6

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

KÝ HIỆU THUẬT NGỮ 8

LỜI CẢM ƠN 10

THÔNG TIN NGHIÊN CỨU 11

1 Thông tin chung 11

2 Mục tiêu 11

3 Nội dung chính 11

MỞ ĐẦU 12

1 Giới thiệu tổng quan 12

2 Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài 13

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

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

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

1.3 Lỗi phần mềm 15

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

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

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

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

1.4 Kiểm thử phần mềm 17

1.4.1 Khái niệm kiểm thử phần mềm 17

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

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

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

1.4.5 Các phương pháp kiểm thử 19

1.4.5.1 Kiểm thử tĩnh – Static testing 19

1.4.5.3 Kiểm thử hộp đen - Black box testing 20

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

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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

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

1.5.3 Nhân lực kiểm thử phần mềm 25

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

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

1 6.1 Kiểm thử đơn vị – Unit test 29

1.6.2 Kiểm thử tích hợp – Intergration Test 30

1.6.3 Kiểm thử hệ thống – System Test 31

1.6.4 Kiểm thử chấp nhận sản phẩm – Acceptance Test 34

1.6.5 Một số cấp độ kiểm thử khác 34

1.7 Nguyên tắc kiểm thử phần mềm 35

CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ HỘP ĐEN 36

2.1 Giới thiệu 36

2.2 Quy trình kiểm thử hộp đen tổng quát 36

2.3 Equivalence Partitioning – Kỹ thuật phân lớp tương đương 37

2 4 Boundary Value Analysis – Kỹ thuật phân tích giá trị biên 39

2.5 Decision Tables – Kỹ thuật sử dụng bảng quyết định 39

2.6 Pairwise Testing – Kỹ thuật kiểm thử các bộ n thần kỳ 42

2.7 State Transition/Diagram Testing - Kỹ thuật biểu đồ chuyển trạng thái 47

2.8 Use case Testing – Kỹ thuật sử dụng use case 47

2.9 Cause-Effect Diagram – Kỹ thuật dùng đồ thị nhân quả 48

2.10 Kỹ thuật đoán lỗi 52

2.11 Kết luận 53

CHƯƠNG 3: TRIỂN KHAI KIỂM THỬ WEBSITE THI ĐUA KHEN THƯỞNG54 3.1 Kiểm thử ứng dụng Website 54

3.2 Kiểm thử website thi đua khen thưởng tỉnh thanh hóa 55

3.2.1 Giới thiệu bài toán 55

3.2.2 Biểu đồ mô tả các chức năng sẽ được thực hiện kiểm thử hộp đen 56

3.2.3 Thiết kế định hướng trường hơp kiểm thử 57

3.3 Thiết kế bộ các test case 61

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

3.3.1 Test case kiểm thử chức năng đăng nhập, thay đổi mật khẩu, đăng

xuất 61

3.3.2 Test case kiểm thử chức năng đăng kí 67

3.3.3 Testcase kiểm thử chức năng Quản lý đợt thi đua 69

3.3.4 Test case kiểm thử chức năng Hồ sơ lưu 79

3.3.5 Test case sử dụng kỹ thuật use case 84

3.3.6 Testcase kiểm thử Giao diện 88

3.4 Thực thi test và báo cáo kết quả 89

TÀI LIỆU THAM KHẢO 92

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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

Hình 1-2 Sơ đồ nhân lực kiểm thử phần mềm 22

Hình 1- 3 Xây dựng kế hoạch kiểm thử 23

Hình1- 4 Sơ đồ các cấp độ kiểm thử .26

Hình 2-1 Quy trình kiểm thử hộp đen tổng quát 34

Hình 2-2 Giao diện đăng nhập hệ thống 36

Hình 2-3 Cấu trúc bảng quyết định 38

Hình 2-4 Giao diện PictMaster Tool 44

Hình 2-5 Đồ thị nhân – quả cho bài toán tính thuế thu nhập 48

Hình 3-1 Giao diện phần mềm thi đua khen thưởng .53

Hình 3-2 Biểu đồ quản lý testcase .54

Hình 3-3 Màn hình đăng nhập thi đua khen thưởng 58

Hình 3-4 Màn hình chức năng đăng kí 64

Hình 3-5 Màn hình quản lý đợt thi đua 66

Hình 3-6 Màn hình quản lý hồ sơ 75

Hình 3-7 Biểu đồ use case thi đua khen thưởng 80

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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

Bảng 1-1 Kiểm thử giao diện người sử dụng 30

Bảng 2-1 Bảng quyết định bài toán kiểm tra thẻ đường sắt 39

Bảng 2-2 Bảng các trường hợp kiểm thử sử dụng kỹ thuật pairwise testing 43

Bảng 2-3 Khuôn mẫu đặc tả use case theo Alistair Cockburn 46

Bảng 2-4 Bảng các ký hiệu sử dụng trong đồ thị nguyên nhân – hệ quả 46

Bảng 2-5 Bảng quyết định cho đồ thị nhân – quả bài toán tính thuế thu nhập 49

Bảng 2-6 Bảng testcase sử dụng kỹ thuật dùng đồ thị nhân – quả 50

Bảng 3-1 Bảng thiết kế quy trình kiểm thử 58

Bảng 3-2 Test case đăng nhập – đăng xuất – thay đổi mật khẩu phần mềm thi đua khen thưởng 59

Bảng 3-3 Bảng dùng kỹ thuật quyết định chức năng đăng kí 64

Bảng 3-4 Testcase đăng kí thi đua 66

Bảng 3-5 Testcase đợt thi đua 68

Bảng 3-6 Testcase quản lý hồ sơ 76

Bảng 3-7 Testcase giao diện 78

Bảng 3-8 Mô tả use case .82

Bảng 3-9 Testcase sử dụng kỹ thuật use case 82

Bảng 3-10 Bảng báo cáo 85

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

KÝ HIỆU THUẬT NGỮ

Intergration Tests Câu hỏi và trả lời

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

LỜI CẢM ƠN

Đồ án tốt nghiệp này được thực hiện tại Trường đại học Mỏ - Địa chất Em xin cảm ơn các thầy cô giáo Bộ môn Tin học trắc địa và khoa Công nghệ thông tin Trường đại học Mỏ - Địa chất đã tạo mọi điều kiện thuận lợi về mặt thủ tục trong quá trình em làm đồ án

Em xin chân thành cảm ơn thầy giáo Ths Nguyễn Tuấn Anh đã trực tiếp tận tình hướng dẫn, giúp đỡ, tạo mọi điều kiện thuận lợi trong suốt quá trình em làm đồ án, luôn theo sát và đưa ra những lời khuyên, động viên kịp thời giúp em hoàn thành đồ án một cách suất sắc nhất; cảm ơn các thầy cô giáo đã trực tiếp giảng dạy trong suốt thời gian học tập tại trường

Để thực hiện được các thử nghiệm trong nghiên cứu này, em xin chân thành cảm

ơn Công ty cổ phẩn đầu tư và phát triển Tâm Việt đã tạo điều kiện thuận lợi cho em được thực tập tốt nghiệp tại công ty Đặc biệt em xin gửi lời cảm ơn tới Giám Đốc Lương Thanh Bình – đảm bảo chất lượng phần mềm đã trực tiếp hướng dẫn, giúp đỡ tận tình để em có thể nắm bắt công việc, nghiên cứu kiến thức về kiểm thử phần mềm và vận dụng những kiến thức được học vào thực hành dự án

Bên cạnh đó, con xin gửi lời cảm ơn tới bố mẹ chị gái và em trai đã giúp đỡ, sát cánh bên con trong những hoàn cảnh khó khăn nhất Và con cũng xin gửi lời cảm ơn tới các bác, các anh chị đã và luôn động viên tinh thần giúp con có thêm nghị lực phấn đấu trong học tập và cuộc sống

Mặc dù đã hết sức cố gắng hoàn thành đồ án với toàn bộ nỗ lực của bản thân, nhưng với năng lực kiến thức bản thân còn hạn chế nên đồ án không tránh khỏi những thiếu sót Kính mong thầy cô và các bạn góp ý, giúp đỡ em để em có thể hoàn thiện kiến thức của bản thân nhiều hơn và phát triển đồ án, định hướng mới hơn trong tương lai

Một lần nữa, em xin trân trọng gửi lời cảm ơn tới tất cả mọi người và em mong sẽ nhận được nhiều sự góp ý quý báu của các thầy cô và các bạn Em xin chân thành cảm ơn!

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

THÔNG TIN NGHIÊN CỨU

1 Thông tin chung

- Tên đề tài: Nghiên cứu và ứng dụng kiểm thử hộp đen trong kiểm thử website phần mềm thi đua khen thưởng

- Sinh viên thực hiện: Nguyễn Thị Vân

- Đồ án tốt nghiệp được thực hiện tại: Hà Nội

- Thời gian thực hiện: 2017

2 Mục tiêu

Mục tiêu chính của đề tài là đưa ra cái nhìn tổng quan về các kỹ thuật kiểm thử và đi sâu vào việc tìm hiểu các kỹ thuật kiểm thử hộp đen đã và đang được sử dụng Đồng thời áp dụng được các kỹ thuật đó vào quy trình kiểm thử cho phần mềm Thi đua khen

thưởng

3 Nội dung chính

- Xác định mục tiêu đề tài

- Nghiên cứu các vấn đề kiểm thử

- Tìm hiểu phân tích các kỹ thuật kiểm thử hộp đen

- Tìm hiểu quy trình nghiệp vụ của phần mềm

- Lựa chọn các kỹ thuật kiểm thử thích hợp

- Thiết kế test case cho phần mềm

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

MỞ ĐẦU

1 Giới thiệu tổng quan

Tổng quan tình hình nghiên cứu thuộc lĩnh vực của đề tài Trong giai đoạn phát triển của công nghệ thông tin, ngành công nghệ phần mềm đang ngày chiếm một vị trí quan trọng trong xu hướng phát triển kinh tế công nghiệp hóa hiện đại hóa của đất nước ta Cùng với sự phát triển của công nghệ phần mềm, lỗi phần mềm và chất lượng phần mềm luôn là thách thức với bản thân ngành phần mềm khi thực tế đã chứng minh, kiểm thử phần mềm là giai đoạn chiếm đến hơn 40% thời gian, kinh phí và nguồn nhân lực phát triển dự án phần mềm hiện nay

Bên cạnh đó số lượng kỹ sư kiểm thử phần mềm Việt Nam hiện nay vẫn chưa đáp ứng được nhu cầu thị trường Các dự án lập trình phần mềm trên thế giới, trung bình cứ

3 lập trình viên có1 kiểm thử viên trong khi đó ở Việt Nam số lượng đó là 5 : 1 Tại hội nghị quốc tế kiểm thử tự động năm 2011 tại TP.HCM cho biết với đà phát triển của ngành công nghiệp phần mềm như hiện nay thì Việt Nam trong thời gian tới sẽ thiếu khoảng 10.000 tester Chúng ta đã và đang chứng kiến sự tăng trưởng đáng kinh ngạc của ngành công nghiệp phần mềm trong vài thập kỷ qua Nếu như trước đây phần mềm máy tính chỉ được sử dụng để tính toán khoa học kỹ thuật và xử lý dữ liệu thì ngày nay

nó đã được ứng dụng vào mọi mặt của của đời sống hàng ngày của con người, từ các ứng dụng nhỏ để điều khiển các thiết bị dùng trong gia đình đến các ứng dụng lớn hơn như trợ giúp điều khiển các phương tiện và hệ thống giao thông, trả tiền cho các hoá đơn, quản lý và thanh toán về tài chính, v.v Vì thế con người ngày càng phụ thuộc chặt chẽ vào các sản phẩm phần mềm và do vậy đòi hỏi về chất lượng của các sản phẩm phần mềm ngày càng cao, tức là các phần mềm phải được sản xuất với giá thành hạ, dễ dùng,

an toàn và tin cậy được Kiểm thử có phương pháp là một hoạt động không thể thiếu trong quy trình sản xuất phần mềm để đảm bảo các yếu tố chất lượng nêu trên của các sản phẩm phần mềm Kiểm thử phần mềm là đề tài đang ngày càng nhận được sự quan tâm, nghiên cứu lớn bởi tầm quan trọng của nó Các kỹ thuật kiểm thử đã và đang được nghiên cứu phát triển trong ngành phần mềm trên khắp thế giới, nổi bật như ISTQB (International Software Testing Quanlifications Board) là một tổ chức phi lợi nhuận cung cấp chứng chỉ thẩm định chất lượng của kiểm thử phần mềm có giá trị toàn cầu đã đưa ra hệ thống một loạt các tài liệu, sách cung cấp kiến thức về lý thuyết kiểm thử và

kỹ thuật kiểm thử phần mềm Ở nước ta, trong khoa Công nghệ thông tin thuộc các trường đại học đã đặt kiểm thử phần mềm thành một môn học chính thức và xây dựng giáo trình, bài giảng riêng cho môn học này, ví dụ như bài giảng điện tử môn học kiểm thử và bảo đảm chất lượng phần mềm của tác giả Thạc Bình Cường, Khoa Công nghệ thông tin, Trường đại học Bách khoa Hà Nội đã trình bày khá chi tiết về lý thuyết các kỹ thuật kiểm thử Ngoài ra là các đề tài nghiên cứu đi sâu vào một kỹ thuật kiểm thử riêng

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Tuy nhiên, trong quá trình tìm hiểu làm đồ án thì chưa có đề tài cụ thể nào về việc vận dụng tất cả các kỹ thuật kiểm thử vào việc phân tích, kiểm thử cho một sản phẩm phần mềm thực tế nào mà phần lớn mới chỉ dừng lại ở việc chỉ ra những ví dụ demo đơn lẻ cho từng kỹ thuật Đặc biệt kiểm thử phần mềm thi đua đua khen thưởng là một lĩnh vực kiểm thử khá mới mẻ và đang thu hút các công ty phát triển phần mềm thì đề tài về vấn

đề này hiện chưa được nghiên cứu cụ thể trong một đề tài nào

2 Tính cấp thiết, ý nghĩa khoa học và thực tiễn của đề tài

Kiểm thử phần mềm đứng ở vị trí hết sức nhạy cảm, nó là bước đệm giữa giai đoạn xây dựng phần mềm và sử dụng phần mềm, trước khi giao sản phẩm hoàn chỉnh cho khách hàng Mặc dù công việc kiểm thử phần mềm không xa lạ song những khái niệm

và kỹ thuật lại khá rắc rối Ở mỗi loại và mỗi miền ứng dụng riêng biệt lại có các đặc thù riêng và cần được bổ trợ bởi các kỹ thuật kiểm thử riêng cho chúng Người kiểm thử có thể hiểu và tự phát triển các kỹ thuật kiểm thử thích hợp cho các hệ thống phức tạp và chuyên dụng hơn dựa trên các kỹ thuật cơ bản Phần mềm đã và đang được ứng dụng vào trong tất cả mọi mặt của cuộc sống hàng ngày, trong đó thi đua khen thưởng là lĩnh vực được cho là cơ hội lớn đối với ngành phần mềm trong nước khi mà các dự án về giáo dục, hành chính luôn được chú trọng Để giải quyết việc thủ tục hồ sơ khen thưởng giấy tờ cồng kềnh phức tạp Việc tạo ra một sản phẩm có thể bán được trên thị trường đòi hỏi sự nỗ lực của hàng chục, hàng trăm thậm chí hàng ngàn nhân viên Số lượng dòng mã lên đến hàng triệu Và để tạo ra một sản phẩm thì không phải chỉ do một tổ chức đứng ra làm từ đầu đến cuối, mà đòi hỏi sự liên kết, tích hợp của rất nhiều sản phẩm, thư viện lập trình, của nhiều tổ chức khác nhau Từ đó đòi hỏi việc kiểm thử phần mềm càng ngày càng trở nên rất quan trọng

Sự ra đời của phần mềm thi đua khen thưởng mang đến hàng loạt các giải pháp cho thủ tục hồ sơ hành chính đi kèm mang lại những hiệu quả to lớn trong công tác quản lý

hồ sơ, mặt khác còn là công cụ giúp Lãnh đạo, cán bộ giám sát kiểm soát hoạt đông thi đua khen thưởng tỉnh giám sát, kiểm soát hoạt động thi đua khen thưởng ở các đơn vị cơ

sở Điều này mở ra một thời cơ lớn cho ngành công nghệ phần mềm đồng thời với đó là

sự cạnh tranh về hiệu quả, chất lượng phần mềm của các đơn vị thực hiện Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá là còn yếu của các công ty phần mềm Việt Nam Kiểm thử là một hoạt động mang tính sống còn trong các

dự án sản xuất hoặc gia công phần mềm Người làm phần mềm đều hiểu rõ vai trò quan trọng của nó, tuy nhiên không phải ai (trong ngành và ngoài ngành) cũng đều hiểu rõ hoạt động này Bản thân công việc kiểm thử phần mềm cũng là một lĩnh vực hoạt động độc lập và khá “hấp dẫn”.Song song với sự phát triển các công nghệ lập trình, các ngôn ngữ lập trình thì các công nghệ và kỹ thuật kiểm thử phần mềm ngày càng phát triển và mang tính khoa học Mỗi một cơ quan, đơn vị lại có yêu cầu riêng về kỹ năng đối với

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

người phụ trách kiểm thử Đứng trước một phần mềm cần kiểm thử mà người kiểm thử không có kiến thức hay thông tin nào về thông tin hiện thực phần mềm như mã nguồn của phần mềm, giải thuật được dùng, các dữ liệu xử lý thì kiểm thử hộp đen là chính chiến lược cho vấn đề này Việc hiểu và nắm vững các kỹ thuật kiểm thử hộp đen là yêu cầu cơ bản, quan trọng hàng đầu đối với một người thực hiện công việc kiểm thử Từ những phân tích trên, xác định được việc nắm rõ các kỹ thuật kiểm thử là yêu cầu tiên quyết của một người thực hiện công việc kiểm thử Trong báo cáo đồ án này được chia thành 3 chương với nội dung 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 về những định nghĩa cơ bản về phần mềm, ngành công nghệ phần mềm, lỗi phần mềm, và qui trình xử lý lỗi phần mềm Kiến thức cơ bản về kiểm thử 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ử hộp đen, kiểm thử hộp trắng

Chương 2: Trình bày các kỹ thuật kiểm thử hộp đen: Kỹ thuật phân lớp tương

đương, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định, kỹ thuật kiểm thử n bộ, kỹ thuật dùng lược đồ trạng thái, kỹ thuật dùng use case, kỹ thuật dùng đồ thị nhân quả và kỹ thuật đoán lỗi

Chương 3: Kiểm thử giao diện ứng dụng Website

Chương này trình bày khái quát về Kiểm thử ứng dụng Website, đặc điểm về chất lượng của một ứng dụng Website, áp dụng viết kịch bản và thực thi kiểm thử cho một số chức năng cơ bản của ứng dụng website Thi đua khen thưởng

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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 Đị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 trình bày một số định nghĩa tiêu biểu Định nghĩa theo IEEE (1991):

- Định nghĩa 1: Chất lượng phần mềm là một mức độ mà một hệ thống, thành phần

hệ thống hay tiến trình đáp ứng được yêu cầu đã được đặc tả

- Định nghĩa 2: Chất lượng phần mềm là mức độ mà một hệ thống, thành phần hệ thống hay tiến trình đáp ứng được yêu cầu và sự mong đợi của khách hàng hay người sử dụng

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

1.3 Lỗi phần mềm

1.3.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ữa chươ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ạ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.3.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ác nguyên nhân chủ quan và các nguyên nhân khách quan Dưới đây là chín nguyên nhân chủ yếu gây ra lỗi phần mềm:

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Đị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 sai chỉ 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ờ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à 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àng phả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ệch các yêu cầu trong tài liệu đặc tả Nguyên nhân củ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ới cá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á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ô-đun nà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ây dự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 ra cá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ôn ngữ; 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át triể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ỗi phầ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ủa cá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 gian hay do thiếu cẩn thận

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 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ủ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ứ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à 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á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ảo trì đôi 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ên nhâ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.3.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ạn nà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ớ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ì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í 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át triển phần mềm

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

1.4.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ất lượ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 trong cá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:

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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 quan trọ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.4.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.4.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 đến khi đạ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ạn ngân sách và lịch trình cho phép

1.4.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ược lạ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ều ngượ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ấy lỗ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ứng minh đượ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ất mọ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 trung vào kiểm thử những yếu tố quan trọng và nhiều rủi ro

 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 trong vò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ết cá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ác lỗi vận hành

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 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ều lầ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ểm thử 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 trong nhữ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 đợi của khách hàng

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

Là phương pháp 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ởi chuyê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

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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

Là phương pháp thử phần mềm thông qua việc dùng máy chạy chương trì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ác chươ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 tra xem liệu đầu ra có như mong muốn hay

không Các phương pháp kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests…

1.4.5.3 Kiểm thử hộp đen- Black box testing

Một trong những chiến lược kiểm thử quan trọng là kiểm thử hộp đen, hướng dữ liệu, hay hướng vào/ra Kiểm thử hộp đen xem chương trình như là một “Hộp đen” Mục đích của bạn là 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 không thực hiện theo đặc tả của nó

Theo hướng tiếp cận này, dữ liệu kiểm tra được lấy chỉ từ các đặc tả

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

 Phân lớp tương đương – EQUIVALENCE PARTITIONING

 Phân tích giá trị biên BOUNDARY VALUE ANALYSIS

 Kiểm thử mọi cặp ALL - PAIRS TESTING

 Kiểm thử Fuzz FUZZ TESTING

 Kiêm thử dựa trên mô hình – MODEL - BASED TESTING

 Ma trận dấu vết TRACEABILITY MATRIX

 Kiểm thử thăm dò EXPLORATORY TESTING

 Kiểm thử dựa trên đặc tả SPECIFICATION - BASE TESTING

Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra

từ đối tượng kiểm thử Mức kiểm thử viên mà khi đó có thể xác minh là đối tượng với

dữ liệu đầu vào đã cho, giá trị đầu ra (cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để ngăn chặn những rủi ro chắc chắn

 Ưu, nhược điểm

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

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

tìm ra Nhưng mặt khác, người cũng nói kiểm thử hộp đen “Giống như là đi trong bóng tối mà không có đen vậy” Bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào Đó là lí do mà có nhiều trường hợp mà một kiểm thử duy nhất, và/hoặc một số phần mềm của chương trình không được kiểm tra chút nào

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

1.4.5.4 Kiểm thử hộp trắng – White box testing

Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm

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

chương trình (và cả mã lệnh thực hiện chúng)

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

 Kiểm thử giao diện lập trình ứng dụng - API testing (application programming

interface): là phương pháp kiểm thử của ứng dụng sử dụng các API công khai và

riêng tư

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

về bao phủ mã lệnh

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

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

 Kiểm thử tĩnh – Static testing: kiểm thử hộp trắng bao gồm mọi kiểm thử tĩnh

 Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen Điều này cho phép các nhóm phần mềm khảo sát các phần của một hệ thống

ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra

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

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

Thuật ngữ: Software Test Process là 1 chuỗi các hoạt động, phương thức thực hiện

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

 Thực hiện test

 Đánh giá kết quả test

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

a) Lập kế hoạch :

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Nhiệm vụ quan trọng trong phần lập kế hoạch kiểm thử là xác định được các yếu tố sau:

 Các giai đoạn kiểm thử áp dụng cho dự án

 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ết quả của bước lập kế hoạch là bản tài liệu kế hoạch KTPM 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, 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 testcase và các bước kiểm tra chi tiết cho mỗi phiên PM 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 tra hế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 testcase và các bước kiểm tra

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

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

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

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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

 Bước 1: Requirements Definition (Xác định yêu cầu): Đóng vai trò xác định yêu cầu bài toán, tính chất công việc, khi bước này hoàn thành thi được đưa vào bước kiểm thử Acceptance Test (kiểm thử chấp nhận)

 Bước 2: Functional system design (Thiết kế chức năng hệ thống): Bước này được xảy ra trên kỹ thuật hệ thống và thiết kế, nó là bước mức độ cao vì thời điểm này, nó phải cung cấp được tổng quan về giải pháp xử lý, nền tảng xây dựng, hệ thống sản phẩm, và các dịch vụ Sau khi bước này được hoàn thành nó chuyển sang mức System Test(kiểm thử hệ thống)

 Bước 3: Technical system design (Thiết kế kỹ thuật hệ thống): Sau khi hoàn thành bước này chuyển sang mức test: Integration (tich hợp)

 Bước 4: Component Specification (Đặc tả thành phần): Đây là bước mức độ thấp của thiết kế, là giai đoạn mà sản phẩm phần mềm đã được tiến hành thiết

kế thực tế, bắt đầu đi vào xác định các yếu tố logic, các sơ đồ lớp với mọi phương thức, mối liên quan giữa các lớp, giai đoạn này có thể phát sinh các mâu thuẫn, sự phù hợp hay không phù hợp….Sau khi bước này được thực hiện thành công thì được chuyển đến công đoạn test gọi là Unit/Component Test (kiểm thử đơn vị, thành phần)

 Ưu điểm và Nhược Điểm

 Ưu điểm

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

Preparation Acceptance

Preparation

Preparation Integration Requirements

Specification

Unit/Component

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Đơn giản dễ sử dụng

- Có hoạt động, kế hoạch cụ thể cho quá trình test

- Tiết kiệm được thời gian, và có cơ hội thành công cao hơn waterfall

- Chủ động trong việc phát hiện bug, sớm tìm ra bug ngay từ những bước đầu

 Nhược điểm

- Độ linh hoạt ít và còn tồn tại sự cứng nhắc Nó thể hiện ở chỗ cứ sau mỗi step thì lại phải có một - công đoạn test, nếu yêu cầu dự án không quá phức tạp và dễ hiểu, thì việc thực hiện nhiều công đoạn test như vậy là tốn thời gian

- Giống với waterfall, sản phẩm của dự án chỉ được xuất hiện khi tất cả các bước được hoàn thành xong, không có nguyên mẫu ngay từ ban đầu Không đáp ứng được yêu cầu dịch vụ vừa phát triển, song song với vừa bán sản phẩm

- Nếu có sự thay đổi về kỹ thuật ở nửa chừng, thì sẽ phải quay lại các bước đầu tiên, thực hiện lại, update lại tài liệu

 Áp dụng cho những dự án như thế nào.

 Dự án có kích thước nhỏ, và trung bình, các yêu cầu dự án là rõ ràng, cố định

 Khi team phát triển có đội ngũ kỹ thuật tốt, có nguồn tài nguyên phong phú, sẵn

có để đảm bảo được yêu cầu, đọc nhanh, test nhanh và coding nhanh

 Nếu khách hàng có sự tự tin cao trong yêu cầu thiết kế (nghĩa là ít thay đổi, ít dao động) thì V model là lựa chọn cần thiết

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 :

 Qui 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ừ một bước lặp được kiểm thử ở nhiều cấp trong việc phát triển

Các tính chất của qui 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

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Việc phân tích và thiết kế test case cho 1 mức độ kiểm thử nên bắt đầu sớm nhấ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ài liệ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êu cầu đặc thù của project phần mềm đó

 Sơ đồ tổ chức phổ biến của đội kiểm thử

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ện chuyể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 cho việ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ử

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

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

- Raising Testing related PIR (Process Improvement Request)/ PCR (Process Change Request)

- Các thành phần chính trong kế hoạch kiểm thử

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

 Kế hoạch kiểm thử: Test Planning

Test Manager (Người quản lí kiểm thử) hoặc Test Leader (Quản lí nhóm kiểm thử sẽ

xây dựng kế hoạch ban đầu về kiểm thử

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Xem lại bởi QC team (đội kiểm tra chất lượng), Developers (lập trình viên), Business Analysis (Phân tích Kinh doanh), TA (if need), PM (quản lí dự án) and Customer (khách hàng)

- Chấp thuận bởi: Project Manager (Quản lí dự án) and Customer (khách hàng)

- Hiệu chỉnh trong suốt chu kỳ kiểm thử để phản ánh các thay đổi nếu cần thiết Nhiệm vụ của Test Plan (Kế hoạch kiểm thử):

- Xác định phạm vi kiểm thử, các rủi ro, mục tiêu

- Xác định cách tiếp cận (đối tượng kiểm thử, độ bao phủ, số người tham gia, các tài liệu liên quan)

- Thực thi chính sách, chiến lược kiểm thử

- Xác định nguồn lực tham gia kiểm thử (con người, phần cứng, phần mềm, thiết

bị, công cụ hỗ trợ)

- Lên kế hoạch phân tích, thiết kế, thực thi, đánh giá

- Xác định tiêu chí kết thúc kiểm thử

Bước 2

 Phân tích & thiết kế kiểm thử (Test Analysis – Design )

Test Analyst (Phân tích kiểm thử) hoặc Test Designer (Thiết kế kiểm thử) sẽ thiết kế

(định nghĩa) các testcase từ các yêu cầu liên quan (thí dụ từ thông tin trong usecase)

- Sẽ thiết kế (định nghĩa) các testcase từ các yêu cầu chức năng và các yêu cầu không chức năng của phần mềm

- Các testcase cần bao phủ tất cả khía cạnh kiểm thử cho từng yêu cầu phần mềm

- Các testcase cần bao phủ tất cả yêu cầu trong các chiến lược kiểm thử

- Nếu cần kiểm thử tự động, Test Designer (Nhân viên thiết kế kiểm thử) sẽ xây dựng các kịch bản dựa trên các testcase/Test procedures

Các testcase cần được:

- Xem xét lại bởi Project Leader (Quản lí dự án), Developer (Lập trình viên) có liên quan, các Testers (nhân viên kiểm thử) khác, Test Leader (Quản lí nhóm test), Business Analysis và Customer (Khách hàng)

- Chấp thuận bởi Test Leader (quản lí nhóm test) hoặc Customer (Khách hàng)

- Hiệu chỉnh/cập nhật nếu Tester đã tìm được những lỗi mà không nằm trong các testcase hiện có

Bước 3

 Thi hành kiểm thử (Test Executing)

- Tester sẽ được bố trí công việc bởi Test Leader (Quản lí nhóm kiểm thử) để thi hành kiểm thử

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Thi hành kiểm thử theo từng testcase

- Thực hiện kiểm thử đặc biệt

- Thực hiện kịch bản kiểm thử mà không được định nghĩa trong testcase

- Kiểm thử lại các lỗi đã được sửa

- Tester sẽ tạo các báo cáo về lỗi trong suốt quá trình kiểm lỗi và theo dõi chúng cho đến khi chúng đã được xử lý

- Ở công đoạn kiểm thử độ chấp thuận, Customer sẽ thi hành kiểm thử để kiểm định xem hệ thống phần mềm có thỏa mãn các nhu cầu người dùng không

Bước 4

 Báo cáo kiểm thử (Test Report and Evaluation)

Test Manager hoặc Test Leader sẽ phân tích các lỗi trong hệ thống theo dõi các lỗi

- Tạo các báo cáo lỗi

- Đánh giá các kết quả kiểm thử, thống kê các yêu cầu thay đổi

- Tính và phân phối các thông tin đo lường hoạt động kiểm thử

- Tạo bảng tổng kết đánh giá hoạt động kiểm lỗi

- Xác định xem đã đạt tiêu chí thành công và để hoàn thành kiểm thử chưa

Nhiệm vụ

- Kiểm tra sản phẩm thực tế so với kế hoạch

- Đóng các báo cáo về sự cố hoặc ghi chép các thay đổi cho bất cứ vấn đề nào còn đang mở

Các kỹ thuật được dùng cho mỗi kiểu kiểm thử trong project:

 Kiểm thử tích hợp (Integration Testing)

 Kiểm thử hệ thống (System Testing)

 Kiểm thử độ chấp thuận (Acceptance Testing)

 Kiểm thử chức năng của người dùng (Functionality Testing)

 Kiểm thử hồi qui (Regression Testing)

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

 Kiểm thử việc phục hồi sau lỗi (Failover and Recovery Testing)

 Kiểm thử việc kiểm soát an ninh và truy xuất (Security and Access Control Testing)

 Kiểm thử việc cấu hình và cài đặt (Configuration and Installation Testing)

 Kiểm thử đặc biệt (Ad-hoc Testing)

 Kiểm thử hiệu suất (Performance Testing)

Hình 1-4 Sơ đồ các cấp độ kiểm thử

1 6.1 Kiểm thử đơn vị – Unit test

Kiểm thử đơn vị hỗ trợ tìm lỗi nhanh hơn, giúp thiết kế tốt hơn, giảm chi phí Kiểm thử đơn vị đƣợc chia ra làm 4 loại chính:

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

kết quả kiểm thử Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau

đó

Unit Test thường do lập trình viên thực hiện Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit.Ví dụ: chuỗi các lệnh sau điều kiện If và nằm giữa then else là một nhánh Thực

tế việc chọn lựa các nhánh để đơn giản hóa việc kiểm thử và quét hết Unit đòi hỏi phải

có kỹ thuật, đôi khi phải dùng thuật toán để chọn lựa

Cùng với các mục kiểm thử khác, Unit Test cũng đòi hỏi phải chuẩn bị trước các

ca kiểm thử (Test case) hoặc kịch bản kiểm thử (Test script), trong đó chỉ định rõ dữ liệu

đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn Các Test case và Test script này nên được giữ lại để tái sử dụng

1.6.2 Kiểm thử tích hợp – Intergration Test

Kiểm thử tích hợp đảm bảo tích hợp các chức năng, các module tuân theo thiết

kế của sản phẩm, đảm bảo giao tiếp, liên kết giữa các chức năng module hoạt động được, đúng theo yêu cầu

Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng Hai mục tiêu chính của Integration Test:

- Phát hiện lỗi giao tiếp xảy ra giữa các Unit

- Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test)

Trong Unit Test, lập trình viên cố gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit Có một số phép kiểm thử đơn giản trên giao tiếp giữa Unit với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ thật sự

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

được kiểm tra đầy đủ khi các Unit tích hợp với nhau trong khi thực hiện Integration Test

Trừ một số ít ngoại lệ, Integration Test chỉ nên thực hiện trên những Unit đã được kiểm tra cẩn thận trước đó bằng Unit Test, và tất cả các lỗi mức Unit đã được sửa chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các giao tiếp giả lập thì không cần phải thực hiện Integration Test nữa Thực tế việc tích hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác

Một chiến lược cần quan tâm trong Integration Test là nên tích hợp dần từng Unit Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kể

Có 4 loại kiểm thử trong Integration Test:

- Kiểm thử cấu trúc (Structure Test): Tương tự White Box Test, kiểm thử cấu

trúc nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng

và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chẳng hạn các câu lệnh và nhánh bên trong

- Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm thử

chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu

kỹ thuật

- Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ

thống

- Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ thống

1.6.3 Kiểm thử hệ thống – System Test

a Mục đích của Kiểm thử hệ thống

+ Nhằm đảm bảo chức năng, các đặc tính của sản phẩm được đúng và đủ của

sản phẩm phầm mềm đó

+ Môi trường thực hiện gần giống với môi trường người dùng cuối

Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không

System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống

Điểm khác nhau then chốt giữa Integration Test và System Test là System Test chú trọng các hành vi và lỗi trên toàn hệ thống, còn Integration Test chú trọng sự giao tiếp giữa các đơn thể hoặc đối tượng khi chúng làm việc cùng nhau Thông thường ta phải thực hiện Unit Test và Integration Test để bảo đảm mọi Unit và sự tương tác giữa chúng hoạt động chính xác trước khi thực hiện System Test

Sau khi hoàn thành Integration Test, một hệ thống phần mềm đã được hình thành cùng với các thành phần đã được kiểm tra đầy đủ Tại thời điểm này, lập trình viên hoặc kiểm thử viên bắt đầu kiểm thử phần mềm như một hệ thống hoàn chỉnh Việc lập kế hoạch cho System Test nên bắt đầu từ giai đoạn hình thành và phân tích các yêu cầu System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối

cùng kiểm thử chấp nhận sản phẩm (Acceptance Test) hoặc dùng thử (Alpha/Beta Test)

Đòi hỏi nhiều công sức, thời gian và tính chính xác, khách quan, System Test thường được thực hiện bởi một nhóm kiểm thử viên hoàn toàn độc lập với nhóm phát triển dự

án Bản thân System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm:

Kiểm thử chức năng (Functional Test): Bảo đảm các hành vi của hệ thống thỏa mãn

đúng yêu cầu thiết kế

Việc kiểm thử chức năng chú trọng đến 2 phần chính là kiểm thử giao diện người dùng (User interface) và kiểm thử luồng nghiệp vụ (Bussiness Flow Testing)

b) Kiểm thử giao diện người sử dụng

Kiểm thử giao diện người sử dụng gọi tắt kiểm thử giao diện là việc kiểm tra các tương tác của người dùng với phần mềm Mục tiêu của kiểm thử giao diện là để đảm bảo rằng giao diện người dùng cung cấp cho người sử dụng cách truy cập và sử dụng các chức năng của hệ thống một cách thích hợp Ngoài ra, kiểm thử giao diện còn để đảm bảo rằng các đối tượng trên giao diện giống như thiết kế và phù hợp với tổ chức hoặc chuyên ngành

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Bảng 1-1 Kiểm thử giao diện người sử dụng

Việc sử dụng thông qua mục tiêu kiểm thử phản ánh đúng các chức năng và yêu cầu nghiệp vụ, bao gồm màn hình đến màn hình, trường đến trường và sử dụng các phương pháp truy cập (phím tabs, di chuột,

tổ hợp phím)

Các đối tượng và thuộc tính màn hình như menus, size, posittion, state

Cách thức thực hiện Tạo ra và chỉnh sửa kịch bản kiểm thử cho mỗi màn

hình để kiểm tra việc sử dụng đúng cách và tình trạng các đối tượng cho mỗi màn hình và đối tượng của ứng dụng

Điều kiện hoàn thành

- Kiểm thử hiệu năng (Performance Test): Bảo đảm tối ưu việc phân bổ tài nguyên

hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn

- Kiểm thử khả năng chịu tải (Stress Test hay Load Test): Bảo đảm hệ thống vận

hành đúng dưới áp lực cao (ví dụ nhiều người truy xuất cùng lúc) Stress Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường như đang giao dịch thì ngắt kết nối (xuất hiện nhiều trong kiểm tra thiết bị như POS, ATM )

- Kiểm thử cấu hình (Configuration Test)

- Kiểm thử bảo mật (Security Test): Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và

của hệ thống

- Kiểm thử khả năng phục hồi (Recovery Test): Bảo đảm hệ thống có khả năng

khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến

Nhìn từ quan điểm người dùng, các cấp độ kiểm thử trên rất quan trọng: Chúng bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào

1.6.4 Kiểm thử chấp nhận sản phẩm – Acceptance Test

Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng

thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện) Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng)

Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng,

thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát

triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong

môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa

Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm

đã trải qua tất cả các kiểm thử trước đó Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng Ví dụ đôi khi một phần mềm xuất sắc vượt qua các phép kiểm thử về chức năng thực hiện bởi nhóm thực hiện dự án, nhưng khách hàng khi kiểm thử sau cùng vẫn thất vọng vì bố cục màn hình nghèo nàn, thao tác không

tự nhiên, không theo tập quán sử dụng của khách hàng v.v

Kết luận

Kiểm thử phần mềm là một ngành mới, có rất nhiều những quan điểm, khái niệm về kiểm thử đã được đưa ra Việc xác định và nắm chắc nội dung cơ bản về kiểm thử là nền tảng để tìm hiểu và có những hướng phát triển rộng hơn, sâu hơn Chương 1 đã giới thiệu những kiến thức cơ bản nhất về kiểm thử phần mềm, xác định được tầm quan trọng và đưa ra những mặt còn hạn chế của việc kiểm thử

1.6.5 Một số cấp độ kiểm thử khác

Ngoài các cấp độ trên, còn một số cấp độ kiểm thử khác như:

- Kiểm thử hồi quy – Regression Testing

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Kiểm thử tính đúng – Correctness testing

- Các phương pháp kiểm thử con người

Quy tắc 2: Lập trình viên nên tránh tự kiểm tra chương trình của mình

Quy tắc 3: Nhóm lập trình không nên kiểm thử chương trình của chính họ

Quy tắc 4: Kiểm tra thấu đáo mọi kết quả của mỗi kiểm tra

Quy tắc 5: Các ca kiểm thử phải được viết cho các trạng thái đầu vào không hợp lệ và không mong muốn, cũng như cho các đầu vào hợp lệ và mong muốn

Quy tắc 6: Khảo sát một chương trình để xem liệu chương trình có thực hiện cái mà nó cần thực hiện chỉ là một phần, phần còn lại là xem liệu chương trình có thực hiện cái mà

nó không cần phải thực hiện hay không

Quy tắc 7: Tránh các ca kiểm thử bâng quơ trừ khi chương trình thực sự là một chương trình bâng quơ

Quy tắc 8: Không dự kiến kết quả của kiểm thử theo giả thiết ngầm là không tìm thấy lỗi

Quy tắc 9: Xác suất tồn tại lỗi trong một đoạn chương trình là tương ứng với số lỗi đã tìm thấy trong đoạn đó

Quy tắc 10: Kiểm thử là một nhiệm vụ cực kỳ sáng tạo và có tính thử thách trí tuệ

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

CHƯƠNG 2: CÁC KỸ THUẬT KIỂM THỬ HỘP ĐEN

2.1 Giới thiệu

Kiểm thử hộp đen là một kỹ thuật kiểm thử động nổi bật nhất, quan trọng và cần thiết nhất Kỹ thuật này thích hợp cho mọi mức độ kiểm thử từ kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, hay kiểm thử độ chấp nhận của người dùng Đây là chiến lược kiểm thử theo góc nhìn từ ngoài vào, người tham gia kiểm thử khi dùng kỹ thuật này không cần có kiến thức về mã nguồn hay giải thuật được dùng Có nhiều kỹ thuật kiểm thử hộp đen đã và đang được phát triển, công nhận mang lại hiệu quả cho việc kiểm thử, chương 2 sẽ trình bày 8 kỹ thuật cơ bản, bao gồm: Kỹ thuật phân lớp tương đương, kỹ thuật phân tích giá trị biên, kỹ thuật dùng bảng quyết định, kỹ thuật kiểm thử n bộ, kỹ thuật dùng lược đồ trạng thái, kỹ thuật dùng use case, kỹ thuật dùng

đồ thị nhân quả và kỹ thuật đoán lỗi Đây là 8 kỹ thuật luôn luôn được sử dụng trong suốt quá trình kiểm thử phần mềm

2.2 Quy trình kiểm thử hộp đen tổng quát

Hình 2-1 Quy trình kiểm thử hộp đen tổng quát Testcase (trường hợp kiểm thử) là một tập hợp các giá trị nhập, các điều kiện tiên quyết thực thi, các kết quả mong đợi và các điều kiện kết thúc, được xây dựng cho mục đích hoặc điều kiện kiểm thử riêng biệt, như thực hiện một đường dẫn chương trình riêng hoặc để kiểm tra lại có đúng với một yêu cầu cụ thể hay không (Trích “Hướng dẫn phương pháp xác định chi phí kiểm thử chất lượng phần mềm”

Kèm theo Công văn số 3787 /BTTT-THH ngày 26/12/2014 của Bộ Thông tin và Truyền thông) testcase mô tả một dữ liệu gồm:

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

- Đầu vào (input)

- Hành động (action)

- Sự kiện (event)

- Một kết quả mong đợi (expected result)

Để xác định một chức năng của ứng dụng phần mềm hoạt động đúng hay không Một testcase có thể có các phần đặc thù khác nhau như mã testcase, tên testcase, các bước thực hiện, mục tiêu kiểm thử, các điều kiện kiểm thử, các yêu cầu dữ liệu vào và các kết quả mong đợi Mức chi tiết có thể được định nghĩa khác nhau dựa vào ngữ cảnh của dự án và quy mô của công ty sản xuất phần mềm

Một testcase được cho là hiệu quả:

- Testcase hiệu quả là testcase mà tìm thấy bug

- Tìm được nhiều bug khó

- Chỉ ra những điểm ban đầu mà khi thực hiện test không tìm ra vấn đề

- Tuân theo đúng các con số thống kê bug

- Theo dõi các lỗi theo các trường hợp đã được tìm thấy

- Đáp ứng được các kỹ thuật kiểm thử

Vì chiến lược kiểm thử hộp đen thích hợp cho mọi mức độ kiểm thử nên nhiều người đã nghiên cứu tìm hiểu và đưa ra nhiều kỹ thuật kiểm thử khác nhau Nắm vững các kỹ thuật cơ bản là yêu cầu tiên quyết của một người thực hiện công việc kiểm thử phần mềm

2.3 Equivalence Partitioning – Kỹ thuật phân lớp tương đương

Tinh thần của kỹ thuật này là cố gắng phân các testcase ra thành nhiều nhóm khác nhau Các test case trong mỗi nhóm sẽ kích hoạt thành phần phần mềm thực hiện cùng một hành vi Mỗi nhóm testcase thỏa mãn tiêu chuẩn trên được gọi là một lớp tương đương

Chỉ cần xác định một testcase đại diện cho nhóm và dùng testcase này để kiểm thử,

từ đó giảm được rất nhiều testcase cần định nghĩa và kiểm thử nhưng chất lượng kiểm thử không bị giảm sút Điều này dựa vào các kỳ vọng sau:

- Nếu một testcase trong lớp tương đương nào đó gây lỗi thì các testcase trong lớp này cũng sẽ gây lỗi như vậy

- Nếu một testcase trong lớp tương đương nào đó không gây lỗi thì các testcase trong lớp này cũng sẽ không gây lỗi

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Việc xác định các lớp tương đương đầu vào cần:

- Dựa vào các điều kiện vào/ra trong đặc tính kỹ thuật/mô tả kỹ thuật

- Định nghĩa các lớp tương đương đại diện các testcase chứa các giá trị đầu vào hợp lệ (valid) và không hợp lệ (invalid)

- Dựa vào chuẩn đoán (heuristics) và chuyên gia

Xét bài toán kiểm thử chức năng đăng nhập vào phần mềm Thi đua khen thưởng với yêu cầu “tên đăng nhập” là ô text chỉ cho phép người dùng nhập vào số ký tự từ 6-20

Hình 2-2 Giao diện đăng nhập hệ thống

Á p dụng kỹ thuật phân lớp tương đương, dữ liệu cho “tên đăng nhập” sẽ được phân thành 3 lớp:

- Nhập vào số ký tự thuộc khoảng [6-20] ký tự

- Nhập vào số ký tự < 6

- Nhập vào số ký tự >20

- Nhập vào ký tự không phải là chữ và để trống không nhập gì

 Có 4 test case

ết kế test case kiểm thử cho yêu cầu trên:

Test case 1: Nhập giá trị từ 6 → 20 ký tự => pass

Test case 2: Nhập giá trị < 6 ký tự => hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6

=> 20 ký tự”

Test case 3: Nhập giá trị > 20 ký tự => hiển thị lỗi “Bạn chỉ được phép nhập chuỗi từ 6

=> 20 ký tự”

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Test case 4: Để trống không nhập gì => hiển thị lỗi “Chưa điền tên đăng nhập”

2 4 Boundary Value Analysis – Kỹ thuật phân tích giá trị biên

Không phải bài toán nào cũng đều có thể áp dụng kỹ thuật phân lớp tương đương, bởi có thể bị thiếu lỗi ở biên nếu chỉ chọn giá trị ở khoảng giữa của miền tương đương Kinh nghiệm trong cuộc sống đời thường cũng như trong lập trình các giải thuật lặp cho

chúng ta biết rằng lỗi thường nằm ở biên của một khoảng liên tục nào đó

Kiểm thử giá trị biên là một trong những kỹ thuật được áp dụng phổ biến nhất trong kiểm thử hộp đen Chúng ta sẽ coi một chương trình là một hàm toán học với đầu vào của chương trình tương ứng với các tham số của hàm và đầu ra của chương trình là giá trị trả về của hàm Vì hàm toán học là ánh xạ từ miền xác định của hàm đến miền giá trị của hàm Chúng ta sẽ tập trung vào các giá trị biên và cạnh biên của hai miền đầu vào và đầu ra này của hàm để xây dựng các ca kiểm thử Khi chúng ta dùng biên đầu ra tức là chúng ta cho các kết quả mong đợi nằm ở trên biên và cạnh biên đầu ra bao gồm: [biên nhỏ, biên lớn, biên nhỏ -1, biên lớn + 1]

Á p dụng cho bài toán đăng nhập vào phần mềm Thi đua khen thưởng (Mục 2.3), số

ký tự cho kiểm tra “tên đăng nhập” thỏa mãn từ 6 đến 20 ký tự Ta sẽ có các trường hợp kiểm thử giá trị biên sau:

- Tên đăng nhập = 6 ký tự => Pass

- Tên đăng nhập = 20 ký tự => Pass

- Tên đăng nhập = 5 ký tự => Fail

- Tên đăng nhập = 21 ký tự => Fail

2.5 Decision Tables – Kỹ thuật sử dụng bảng quyết định

Kỹ thuật kiểm thử phân lớp tương đương và kiểm thử dựa vào phân tích giá trị biên thích hợp cho các hàm có các biến đầu vào không có quan hệ ràng buộc với nhau Kỹ thuật kiểm thử sử dụng bảng quyết định phù hợp cho các thành phần phần mềm có các hành vi khác nhau dựa trên tính chất của bộ giá trị đầu vào

Kiểm thử sử dụng bảng quyết định là phương pháp chính xác nhất trong các kỹ thuật kiểm thử chức năng Bảng quyết định là phương pháp hiệu quả để mô tả các sự kiện, hành vi sẽ xảy ra khi một số điều kiện thỏa mãn

Là công cụ rất hữu ích để đặc tả các yêu cầu phần mềm / bảng thiết kế hệ thống phần mềm Miêu tả các quy tắc nghiệp vụ phức tạp mà phần mềm phải thực hiện dưới dạng

dễ đọc và dễ kiểm soát Cấu trúc của một bảng điều kiện có dạng:

Đồ án tốt nghiệp chuyên ngành Tin học Trắc địa

Hình 2-3 Cấu trúc bảng quyết định

- Trong đó:

- Condition 1 tới condition n miêu tả điều kiện dữ liệu nhập khác nhau có thể có

- Rule mô tả giá trị điều kiện nhập: T (true) / F (false), Y (yes) / N (no)

- Action 1 tới action n miêu tả n hoạt động khác nhau mà hệ thống có thể thực hiện phụ thuộc vào tổ hợp điều kiện dữ liệu nhập vào Mỗi cột miêu tả một luật cụ thể:

tổ hợp điều kiện nhập cụ thể và các hoạt động cụ thể cần thực hiện.Các hoạt động cần thực hiện không phụ thuộc vào thứ tự các điều kiện nhập, nó chỉ phụ thuộc vào giá trị các điều kiện nhập.Để xác định các ca kiểm thử dựa vào bảng quyết định, ta dịch các điều kiện thành các đầu vào và các hành động thành các đầu ra Đôi khi các điều kiện sẽ được xác định các lớp tương đương của đầu vào và các hành động tương ứng ở các mô- đun xử lý chức năng đang kiểm thử

Ví dụ: Á p dụng kỹ thuật sử dụng bảng quyết định để xây dựng các trường hợp kiểm thử cho bài toán với đề là:

Nếu bạn có thẻ đường sắt over 60s thì được giảm giá 34% trên tất cả các vé bạn mua.Nếu bạn đi cùng trẻ em (dưới 16 tuổi), thì bạn sẽ được giảm 50% nến bạn có thẻ family rail card, ngược lại bạn sẽ được giảm 15% Bản chỉ được sử dụng một loại thẻ đường sắt