Tìm hiểu về kiểm thử phần mềm tự động và ứng dụng

Dù biết công tác kiểm thử, đảm bảo chất lượng giữ vai trò quantrọng trong việc mang lại tỷ lệ thành công của các dự án phần mềm song không phảicông ty nào cũng có đủ chuyên môn và điều k

LỜI NÓI ĐẦU

Cùng với sự phát triển nhanh chóng của ngành gia công phần mềm,ngành kiểm thử phần mềm tại Việt Nam cũng đang có những bước phát triển vượtbậc với hàng loạt các đơn hàng kiểm thử phần mềm từ những tập đoàn công nghệthông tin (CNTT ) hàng đầu trên toàn thế giới Thực tế cho thấy, số lượng đơn vịđào tạo chuyên sâu, các tester chuyên nghiệp về kiểm thử phần mềm không nhiều,chưa thể đáp ứng được các dự án doanh nghiệp Nếu xét theo chuẩn quốc tế, tỷ lệlập trình viên và tester là 1:3 (cứ 3 lập trình viên thì có 1 tester), đôi khi tỷ lệ này là1:1 với những dự án đặc thù; thì tại Việt Nam, tỷ lệ ứng với công việc tester chỉ rơivào khoảng 1:5 Dù biết công tác kiểm thử, đảm bảo chất lượng giữ vai trò quantrọng trong việc mang lại tỷ lệ thành công của các dự án phần mềm song không phảicông ty nào cũng có đủ chuyên môn và điều kiện cho phép để thực hiện quy trìnhnày Tuy nhiên với những lợi thế cạnh tranh như: nguồn nhân lực rẻ có sẵn trình độ

ký thuật; đầu tư phát triển cơ sở hạ tầng nhanh; môi trường đầu tư an toàn; chấtlượng dịch vụ nổi trội và tỷ lệ thay đổi nhân sự thấp… Việt Nam có thể hi vọng vàtin tưởng vào khả năng trở thành đối tác kinh doanh đầy tiềm năng và hấp dẫn trongngành kiểm thử Do đó, kiểm thử phần mềm hiện đang là một trong những ngànhnghề hấp dẫn nhất trong lĩnh vực CNTT tại Việt Nam hiện nay Theo thông tin đượccác diễn giả chia sẻ tại hội nghị kiểm định phần mềm quốc tê(Vistacon) diễn ra tạithành phố Hồ Chí Minh đến hết ngày 26-4-2012, Việt Nam liên tục được tổ chức

AT Kearney (UK) đánh giá là 10 điểm đến hàng đầu về kiểm thử phần mềm trên thếgiới

Ngày nay, tự động hóa được ứng dụng ở rất nhiều lĩnh vực, mục đích thườngrất đa dạng và tùy theo nhu cầu đặc thù của từng lĩnh vực, tuy nhiên điểm chungnhất vẫn là giảm nhân lực, thời gian và sai sót Ngành công nghệ thông tin mà cụthể là phát triển phần mềm cũng không ngoại lệ Như chúng ta biết, để tạo ra sảnphẩm công nghệ thông tin hay phần mềm có chất lượng thì hoạt động kiểm thửphần mềm đóng vai trò rất quan trọng, trong khi đó hoạt động này lại tiêu tốn và

chiếm tỷ trọng khá lớn công sức và thời gian trong một dự án Do vậy, nhu cầu tựđộng hoá quy trình kiểm thử phần mềm cũng được đặt ra Qua thực tế cho thấy, việc

áp dụng kiểm thử tự động hợp lý sẽ mang lại thành công cho hoạt động kiểm thửphần mềm Kiểm thử tự động giúp giảm bớt công sức thực hiện, tăng độ tin cậy,giảm sự nhàm chán và rèn luyện kỹ năng lập trình cho cán bộ kiểm thử

Năm 2006 IBM cho ra đời sản phẩm The 2007 developerWorks SoftwareEvaluation Kt (SEK) for Windows, đây là một trong số nhiều phần mềm dùng choviệc kiểm thử SEK bao gồm 6 Tool và công cụ Rational Functional Tester nằmtrong số đó, đây là công cụ kiểm thử chức năng của phần mềm, một công cụ kiểmthử hồi quy tiên tiến, được tự động hóa cho Tester và người phát triển GUI

Bất kỳ một tổ chức nào cũng có một sự tin cậy của riêng mình vào việc pháttriển của những trình ứng dụng để phục vụ cho những việc cần thiết như đáp ứngđược chức năng của khách hàng đưa ra, để cho khách hàng tỏ ra hài lòng về chấtlượng của những trình ứng dụng và những đòi hỏi về những chức năng, điều kiệnđược đáp ứng đầy đủ và không xảy ra sự tùy tiện trong sản phẩm Một thành phầnchủ yếu cho sự thành công này là tính hiệu quả, quy trình ứng dụng đã hoàn thànhđến mức độ nào, đó là sự phù hợp thích đáng hay là vượt ra khỏi những mong đợitrong đề án Lịch trình làm việc không đúng, thường xuyên thay đổi những vấn đềchung của chương trình ứng dụng IBM Rational Functional Tester được xây dựngtrên những vấn đề này

Đây chính là lý do thúc đẩy em thực hiện đề tài “Tìm hiểu về kiểm thử phầnmềm tự động và ứng dụng” làm đồ án tốt nghiệp Mục đích của đề tài là tìm hiểu

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

Mục tiêu chính của đề tài là nghiên cứu giai đoạn nào cần áp dụng công cụkiểm thử tự động, các yếu tố nào cần kiểm thử chức năng

Đồ án được hoàn thành dưới sự chỉ bảo tận tình của Th.S Đỗ Thị Tâm –Giảng viên khoa Công Nghệ Thông Tin, Trường Đại học Công Nghiệp Hà Nội.Ngoài ra, để có các kiến thức để hoàn thành đồ án này, em cũng xin cảm ơn tới cácgiảng viên của Khoa Công Nghệ Thông Tin, Trường Đại Học Công Nghiệp Hà Nội

đã tận tình giảng dạy em trong quá trình học tại trường Tuy đã hoàn thiện song đồ

án này vẫn sẽ có những thiếu sót Em hi vọng sẽ nhận được sự đóng góp ý kiến củacác thầy cô và các bạn để đồ án này được hoàn thiện hơn

Sinh viên thực hiện

Võ Thị Thanh Sang

TÓM TẮT ĐỒ ÁN

Đề tài “Tìm hiểu về kiểm thử phần mềm tự động và ứng dụng”

Đồ án này cung cấp các lý thuyết về kiểm thử phần mềm, kiểm thử phầnmềm tự động và ứng dụng kiểm thử tự động trong việc kiểm thử phần mềm với mụcđích:

- Tìm hiểu về lý thuyết kiểm thử phần mềm.

- Tìm hiểu phương pháp xây dựng các tài liệu: test plan, test case.

- Nghiên cứu về kiểm thử tự động

- Ứng dụng.

MỤC LỤC

LỜI NÓI ĐẦU 1

TÓM TẮT ĐỒ ÁN 3

Danh sách các hình vẽ 7

Danh sách các bảng biểu 7

MỞ ĐẦU 8

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM 9

1.1 Các khái niệm cơ bản về kiểm thử 9

1.1.1 Khái niệm phần mềm 9

1.1.2 Lỗi phần mềm 9

1.1.3 Kiểm thử phần mềm 15

1.1.4 Các giai đoạn trong quá trình kiểm thử 16

1.1.5 Chiến lược của kiểm thử phần mềm 17

1.1.6 Những thành phần của một kế hoạch kiểm thử 18

1.1.7 Những điểm cần tập trung kiểm thử trước nhất nếu không có đủ thời gian .19

1.1.8 Các tiêu chí đánh giá kiểm thử 19

1.1.9 Các nguyên tắc kiểm thử 19

1.2 Mục tiêu của kiểm thử 20

1.3 Vai trò của kiểm thử 20

1.4 Phân loại kiểm thử 20

1.5 Các trường hợp kiểm thử và dữ liệu kiểm thử 24

1.6 Phương pháp xây dựng các tài liệu kiểm thử 25

1.6.1 Test plan 25

1.6.2 Test case 26

CHƯƠNG II: NGHIÊN CỨU VỀ KIỂM THỬ TỰ ĐỘNG 35

1.1 Khái quát về kiểm thử tự động 35

1.2 Nguyên tắc của kiểm thử tự động 36

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

1.3.1 Quá trình kiểm thử trong quá trình phát triển phần mềm nói chung.39 1.3.2 Một số những vấn đề được quan tâm nhiều nhất khi thực hiện kiểm thử tự động 42

1.4 So sánh kiểm thử tự động và kiểm thử thủ công 45

CHƯƠNG III: KIỂM THỬ CHỨC NĂNG 47

1.1 Tổng quan về kiểm thử chức năng 47

1.2 Các bước cơ bản thực hiện kiểm thử chức năng 51

1.3 Các mức kiểm thử chức năng và cấu trúc 51

1.4 Các kỹ thuật kiểm thử chức năng 51

1.5 Viết kịch bản kiểm thử chức năng 53

1.5.1 Giao diện 53

1.5.2 Chức năng 53

1.5.3 An toàn thông tin 54

CHƯƠNG IV: NGHIÊN CỨU PHẦN MỀM SEK CỦA IBM VÀ CÔNG CỤ KIỂM THỬ RATIONAL FUNTIONAL TESTER 55

1.1 Nghiên cứu phần mềm SEK của IBM 55

1.2 Giới thiệu về công cụ IBM Rational Funtional Tester 56

1.3 Những lợi ích khi sử dụng công cụ IBM Rational Funtional Tester 57

1.4 Những chiến lược để sử dụng là Statement 58

1.5 Rational Funtional Tester với đội phát triển 59

1.6 Compliance (Quy trình nghiệp vụ) 60

1.7 Điều kiện để sử dụng công cụ 60

CHƯƠNG V: ỨNG DỤNG 62

1.1 Tạo Usecase kiểm thử, điều kiện đầu vào và kết quả mong đợi 62

1.1.1 Chức năng Login 62

1.1.2 Chức năng thêm/sửa 62

1.2 Thực hiện kiểm thử với công cụ IBM Rational Tester 65

1.1.1 Chức năng Login 65

1.1.2 Chức năng thêm/sửa khách hang 67

1.1.3 Chức năng lập phiếu xuất 68

1.1.4 Viết báo cáo 69

CHƯƠNG VI: KẾT LUẬN 70

1.1 Những vấn đề đạt được 70

1.2 Ưu và nhược điểm của công cụ 70

1.2.1 Nhược điểm 70

1.2.2 Ưu điểm 71

1.3 Hướng phát triển 75

PHỤ LỤC A 76

1.1 Những yêu cầu về cài đặt 76

1.2 Hệ thống hệ điều hành 76

1.3 Những phần mềm yêu cầu thêm 77

1.4 Kế hoạch của việc cài đặt 77

1.5 Cài đặt Rational Functional Tester bằng phần mềm download 79

PHỤ LỤC B 84

1.1 Chức năng của những biểu tượng trên thanh Toolbar 84

1.2 Tổng quan Funtional Tester Project 85

1.3 Cách tạo một Project đơn giản 86

1.4 Create a data-Driven test (Tạo kiểm thử Data-Driven) 87

TÀI LIỆU THAM KHẢO 89

Danh sách các hình vẽ

Hình 1.1.Quá trình bắt lỗi 10

Hình 1.2 Bốn giai đoạn trong quá trình kiểm thử 16

Bảng 1.1 Bảng tổng hợp nội dung các mức kiểm thử 17

Hình 1.3 Vòng đời của kiểm nghiệm (kiểm thử) 17

Hình 1.4 Tiến trình kiểm thử phần mềm 18

Bảng 1.2 Bảng phân lớp tương đương của chức năng Thêm Sinh Viên 29

Bảng 1.3 Các giá trị biên của chức năng Thêm Sinh Viên 30

Bảng 1.4 Các quy tắc xây dựng đồ thị nhân – quả 31

Bảng 2.1 Nguyên tắc kiểm thử tự động 36

Hình 2.1 Tối ưu hóa trong kiểm thử tự động 38

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

Hình 2.3 Cách thức kiểm thử tự động 39

Hình 2.4 Tính toán ROI trong giai đoạn lập kế hoạch 40

Hình 2.5 Kiểm thử tự động trong giai đoạn Design trong quy trình kiểm thử 41

Hình 2.6 Mô hình đội kiểm thử và chức năng 42

Hình 2.7 Thiết kế bộ kiểm thử 44

Hình 2.8 Thiết kế chu trình kiểm thử 45

Bảng 2.2 So sánh ưu nhược điểm giữa kiểm thử tự động và thủ công 46

Hình 2.9 So sánh ưu nhược điểm giữa kiểm thử tự động và thủ công 46

Danh sách các bảng biể Bảng 1.1 Bảng tổng hợp nội dung các mức kiểm thử 17

Bảng 1.2 Bảng phân lớp tương đương của chức năng Thêm Sinh Viên 29

Bảng 1.3 Các giá trị biên của chức năng Thêm Sinh Viên 30

Bảng 1.4 Các quy tắc xây dựng đồ thị nhân – quả 31

Bảng 2.1 Nguyên tắc kiểm thử tự động 36

Bảng 2.2 So sánh ưu nhược điểm giữa kiểm thử tự động và thủ công 46

MỞ ĐẦU

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

Mục tiêu chính của đề tài là giới thiệu các vấn đề trong kiểm thử, tìm hiểugiai đoạn nào cần áp dụng công cụ kiểm thử tự động, các yếu tố nào cần kiểm thửchức năng và đi sâu vào nghiên cứu các tính năng cơ bản của công cụ IBM RationalFunctional Tester, đưa ra tài liệu hướng dẫn cài đặt, sử dụng công cụ một cách đơngiản và hiệu quả

Đối tượng và phạm vi nghiên cứu: Đồ án nghiên cứu lý thuyết kiểm thử

phần mềm; bên cạnh đó nghiên cứu công cụ kiểm thử tự động và các tính năng cơbản của Tool Rational Functional Tester

Phương pháp nghiên cứu: Nghiên cứu tổng quan về kiểm thử phần mềm,

các kỹ thuật kiểm thử, nghiên cứu công cụ kiểm thử phần mềm tự động RationalFucional tester và ứng dụng vào một chương trình ứng dụng cụ thể

Với mục tiêu đặt ra như vậy, những nội dung và kết quả nghiên cứu chínhcủa đồ án được trình bày trong các chương như sau:

Chương 1: Tổng quan về kiểm thử: Chương này giới thiệu về quá trình kiểmthử, những khái niệm, những thuật ngữ, vấn đề liên quan đến kiểm thử, những môhình kiểm thử và các loại kiểm thử thông dụng hiện nay

Chương 2: Nghiên cứu kiểm thử phần mềm tự động

Chương 3: Nghiên cứu về phần mềm SEK của IBM và công cụ kiểm thửIBM Rational Functional Tester

Chương 4: Nghiên cứu

Phần kết luận đưa ra những đánh giá về những kết quả đạt được và thảo luận

về huớng nghiên cứu tiếp của đồ án

Trong quá trình thực hiện đồ án, do thời gian cũng như trình độ còn cónhững hạn chế nhất định nên không thể tránh khỏi những sai sót Rất mong nhậnđược sự góp ý của các thầy, cô giáo và các bạn để đồ án hoàn thiện hơn Em xinchân thành cảm ơn sự hướng dẫn, và giúp đỡ tận tình của cô giáo Th.S Đỗ Thị Tâm

- Giảng viên khoa Công Nghệ Thông Tin, Trường Đại học Công Nghiệp Hà Nội đãgiúp đỡ em trong quá trình học tập cũng như trong quá trình làm đồ án

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM1.1 Các khái niệm cơ bản về kiểm thử

1.1.1 Khái niệm phần mềm

Phần mềm là một (bộ) chương trình được cài đặt trên máy tính nhằm thựchiện một nhiệm vụ tương đối độc lập nhằm phục vụ cho một ứng dụng cụ thể việcquản lý họat động của máy tính hoặc áp dụng máy tính trong các họat động kinh tế,quốc phòng, văn hóa, giáo dục, giải trí,…

1.1.2 Lỗi phần mềm

Có rất nhiều định nghĩa khác nhau về lỗi phần mềm, nhưng nhìn chung, cóthể phát biểu một cách tổng quát: “Lỗi phần mềm là sự không khớp giữa chươngtrình và đặc tả của nó.”

Dựa vào định nghĩa, chúng ta có thể thấy lỗi phần mềm xuất hiện theo badạng sau:

• Sai: Sản phẩm được xây dựng khác với đặc tả

• Thiếu: Một yêu cầu đã được đặc tả nhưng lại không có trong sảnphẩm được xây dựng

• Thừa: Một yêu cầu được đưa vào sản phẩm mà không có trong đặc tả.Cũng có trường hợp yêu cầu này có thể là một thuộc tính sẽ được người dùngchấp nhận nhưng khác với đặc tả nên vẫn coi là có lỗi

a Vòng đời của lỗi

Một lỗi trong phần mềm là một cái gì đó gây ra cho phần mềm chạytheo cách mà nó không nhất quán với những yêu cầu hay sự cần thiết củakhách hang hay những chuẩn liên quan Để có phần mềm chất lượng cao,sản phẩm cuối cùng nên có có vài lỗi có thể

 Một lỗi được tìm thấy và phải được ghi lại trong DMS(Document management system) bởi một nhân viên Lỗi đượcvào trong DMS với trạng thái “Error” và thông tin khác

 Lãnh đạo dự án phải xem xét lại dữ liệu của một lỗi (như dạnglỗi, ngồi gốc, tính nguy hại,…), sửa nó và giao cho người sửalỗi Thông thường thành viên được giao là tác giả cảu văn bảnhay đoạn mã nguồn mà lỗi được tìm thấy trong đó Trạng tháicủa lỗi được thay đổi thành “Assigned”

 Sau khi sửa lỗi, tác giả đổi trạng thái lỗi thành “Pending”

 Người kiểm thử kiểm thử lại lỗi chưa giải quyết và cập nhậttrạng thái thành “Tested” nếu lỗi được sửa một cách hài longhay thành “Error”

 Nếu một lỗi với trạng thái “Error” có thể được chấp nhận màkhông có một hành động hiệu chỉnh nào, lãnh đạo dự án cầnđổi trạng thái thành “Accepted”.

Vòng đời của lỗi được mô hình hóa trong flowchart sau đây:

Hình 1.1.Quá trình bắt lỗi

b Lỗi dữ liệu

Thông tin quan trọng của lỗi bao gồm:

Tùy chọn

1 Project Code Dự án hay sản phẩm bị mắc một lỗi B

10 QC activity Dạng của hoạt động QC như là xem lại, kiểm

tra…

B

11 Stage injected Phạm vi hoạt động trong dự án xác định vòng

đời mà từ đó lỗi được gây ra

T

12 Process origin Tên hay mà nguồn của đoạn phần mềm mà trong

đó lỗi là nguồn gốc

B

14 Creator Người phát hiện lỗi, người kiểm thử hay người

xem lại

B

15 Create date Ngày ghi lại lỗi trong dữ liệu lỗi B

16 Assigned to Người chịu trách nhiệm sửa lỗi, thường là tác

giả

T

17 Due date Hạn chót mà việc sửa lỗi phải hoàn thành T

18 Work product Trong sản phẩm mà lỗi được tìm thấy B

19 Module Phần của sản phẩm mà lỗi được tìm thấy trong

22 Reference Tài liệu tham khảo hay miêu tả về lỗi T

23 History Thông tin về lỗi Tất cả những phần như hiệu

chỉnh,… của lỗi đực thể hiện

T

Những yêu cầu đầu vào không được hiểu rõ.

Feature missing Một phần của đặc tính hay đặc tính không hoàn

thành

Coding logic Kỹ năng kỹ thuật, đánh giá dữ liệu… hay những lý

do khác không được xác định như là vấn đề viếtcode

Business logic Không theo luồng công việc

2 User Interface Lỗi trong giao diện, bố cục

3 Performance Tốc độ xử lý chậm hay lỗi hệ thống do cấu hình;

vấn đề bộ nhớ

4 Design issue Thiết kế được chỉ rõ liên quan vấn đề

5 Coding standard Vấn đề với chuẩn viết mã nguồn

6

Document Lỗi phát hiện trong khi xem lại văn bản Kế hoạch

dự án, SRS (Software requirements specification),

kế hoạch kiểm thử,…liên quan tới chuẩn văn bản(mẫu, phiên bản, header/footer,…)

Vấn đề với đặc quyền người dùng, vấn đề bảo mật

9 Portability Mã nguồn không độc lập với platform

10 Other Không như những dạng trên

11 Tools Lỗi gây ra bởi sử dụng công cụ

d Lỗi nguy hại

T

T Dạng nguy hại Giải thích

1 Fatal Lỗi không cho người dùng sử dụng tiếp tục sử

dụng hệ thống, có lẽ hệ thống bị tấn công

2 Serious Hệ thống không thể làm việc tốt

3 Medium Lỗi này không ngăn người dùng sử dụng xử lý

nhưng gây ra sự bất tiện

4 Cosmetic Một lỗi mà không có cách nào ảnh hưởng đến

hiệu năng của sản phẩm Nó có lẽ là một lỗi ngữpháp

e Trạng thái lỗi

Một lỗi có một vài trạng thái sau đây trong vòng đời của nó:

T

1 ERROR Lỗi không được sửa hay sửa nhưng khống được

hài lòng như mong muốn

2 ASSIGNED Lỗi được xem lại và được giao sửa nó

3 PENDING Lỗi được sửa xong và được kiểm thử lại

4 TESTED Lỗi được sửa một cách hài long như mong

muốn

5 ACCEPTED Lỗi không được sửa một cách hài lòng như

mong muốn nhưng nó được chấp nhận bởi sựnhượng bộ của tác giả hay khách hàng

6 CANCELLED Nó không là một lỗi hay lỗi được loại bỏ bởi

những hành động với sửa lỗi

f Xử lý nguồn gốc

Xử lý nguồn gốc: Là xử lý mà trong nó bị nhiễm lỗi Xác định rằng

những phân tích yêu cầu của xử lý này là của một lỗi Nó được đánh giá từ

độ tự nhiên của lỗi và những thông tin khá về lỗi

2 Requirements 02-QT Giả định không đúng; đặc tả giao diện

không hoàn hảo; luồng xử lý không rõrang; yêu cầu không có đặc tả, nhậpnhằng, không hoàn hảo.

3

Design 03-QT Yêu cầu không được thực thu đầy đủ;

logic vấn đề; vaassn đề liên quan đếnchuẩn

4 Coding 04-QT Vấn đề với viết code, logic, xử lý dữ

liệu, vào/ra

5 Deployment 05-QT Sự triển khai kế hoạch không thích hợp,

giải pháp; những vấn đề môi trường

6 Customer

support

06-QT Kế hoạch hỗ trợ không rõ ràng

7

Test 07-QT Sự cố gắng không thích hợp hay lịch

biểu cho kiểm thử; sự không hảo củayêu cầu kiểm thử hay vạch kế hoạch;kiểm thử case sai; kiểm thử dữ liệuthích hợp không xác định; tiêu chuẩnkiểm thử không thích hợp

kế hoạch CM (ConfigurationManagement)còn thiếu

g Ưu tiên lỗi

Tác giả có thể dựa vào ưu tiên lỗi để sửa nó

1 Immediately Lỗi phải được sửa ngay lập tức

2 High priority Lỗi nên được ddwua lên mức chú ý cao

hơn

3 Normal priority

4 Low priority

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

Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xácđịnh xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trườngnhư mong đợi hay không

Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm mộtcách sớm nhất và đảm bảo rằng lỗi đã được sửa, mà kiểm thử phần mềm không làmcông việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi

Mục tiêu của kiểm thử phần mềm là thiết kế tài liệu kiểm thử một cách có hệthống và thực hiện nó sao cho có hiệu quả, nhưng tiết kiệm được thời gian, côngsức và chi phí

 Kiểm thử thành công là phát hiện ra lỗi, kiểm thử không phát hiện ra lỗi làkiểm thử dở (Sue A.Conger- The New Software Engineering)

1.1.4 Các giai đoạn trong quá trình kiểm thử

Giai đoạn kiểm thử là quá trình kiểm tra sản phẩm phần mềm để tìm kiếmlỗi Quy trình kiểm thử phần mềm được chia thành 4 giai đoạn:

 Kiểm thử đơn vị ( Unit Testing )

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

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

 Kiểm thử chấp nhận ( Acceptance Testing )

Hình 1.2 Bốn giai đoạn trong quá trình kiểm thử

Khi kiểm thử, nếu các lỗi được phát hiện tại bất kì mức nào, chúng đòi hỏichương trình phải gỡ lỗi và hiệu chỉnh cho chính xác, sau đó cần kiểm thử lại, tức làcần được lặp lại những kiểm thử nào đó ở mức trước Trong quy trình này, thông tinlỗi gặp phải hay mức độ tin cậy đạt được của chương trình ở mỗi giai đoạn sau đềuđược phản hồi về giai đoạn trước của tiến trình Vì vậy, tiến trình kiểm thử là tiếntrình lặp

Hệ thống phầnmềm, môitrường thực

Cơ sở đối

sánh

Thiết kế chitiết

Thiết kế chi tiết,kiến trúc, đặc tả

Thiết kế kiếntrúc, đặc tả phần

Đặc tả yêu cầuphần mềm

chức năng mềm

Phương

pháp

Hộp trắng( Hộp đen )

Hộp đen, hộptrắng

Nhóm kiểm thử

Bảng 1.1 Bảng tổng hợp nội dung các mức kiểm thử

Hình 1.3 Vòng đời của kiểm nghiệm (kiểm thử)

1.1.5 Chiến lược của kiểm thử phần mềm

Chiến lược kiểm thử phần mềm là sự tích hợp các kỹ thuật thiết kế, các phépthử tạo thành một dãy các bước để hướng dẫn quá trình kiểm thử phần mềm thànhcông Nó mô tả các bước trong quá trình kiểm thử Vì thế, bất kỳ chiến lược kiểmthử nào cũng phải tích hợp được:

- Thiết kế các ca kiểm thử

- Tạo dữ liệu thử:

 Kiểm thử với tất cả các dữ liệu vào là cần thiết

 Chọn tập các dữ liệu thử đại diện từ miền dữ liệu vào dựa trêncác tiêu chuẩn chọn dữ liệu thử

- Thực thi chương trình trên dữ liệu thử gồm : cung cấp, thực thi và ghinhận kết quả

- Quan sát kết quả kiểm thử :

 Thực hiện trong hoặc sau khi thực thi

So sánh kết quả thực tế với kết quả mong đợi

Hình 1.4 Tiến trình kiểm thử phần mềm

Chiến lược kiểm thử phần mềm phải đủ mềm dẻo tùy theo cách tiếp cận sángtạo của người thực hiện Nhưng với tư cách là một tiến trình trong dự án , nó cũngphải đủ chặt chẽ để hỗ trợ các kế hoạch và phương thức quản lý

Một chiến lược kiểm thử phải thích ứng với từng mức kiểm thử : các kiểmthử mức thấp (xác minh từng khúc mã nguồn xem có thực thi đúng đắn không), vàcác kiểm thử mức cao ( thẩm định các chức năng hệ thống có đáp ứng yêu cầukhách hàng hay không)

Có nhiều chiến lược kiểm thử phần mềm khác nhau như: Kiểm thử từ trênxuống, kiểm thử từ dưới lên, kiểm thử vụ nổ lớn, kiểm thử hồi quy… Các chiếnlược kiểm thử khác nhau có thể tìm ra các loại lỗi khác nhau Vì thế, không thể tậptrung vào một chiến lược kiểm thử mà bỏ qua các loại khác Các mức của quá trìnhkiểm thử cần được thực hiện tuần tự và bổ sung cho nhau nhằm tìm ra từng loại lỗivới các phương pháp thích hợp

1.1.6 Những thành phần của một kế hoạch kiểm thử

 Đầu vào để lập lên kế hoạch kiểm thử: Kế hoạch của dự án, đặc tả yêucầu của phần mềm, người lập kế hoạch test, người tham gia test, thờigian test, phạm vi test, kinh phí giành cho việc test, công cụ test

 Người lập kế hoạch kiểm thử thường là trưởng nhóm test có kinhnghiệm dựa vào các yêu cầu của phần mềm mà đưa ra phạm vi testcho phù hợp với trình độ người test, thời gian, chi phí Khi đưa raphạm vi rồi thì làm tốt phạm vi đó thì coi như đạt yêu cầu theo kếhoạch test đưa ra

 Các công việc cần thực hiện là đầu ra của kế hoạch kiểm thử:

 Nghiên cứu tài liệu dự án (phân tích, thiết kế), tìm hiểu công cụtest cho kiểu test đã đặt ra

 Thiết kế test case theo phạm vi test

 Thực hiện kiểm tra phần mềm theo nội dung test case

 Báo lỗi khi phát hiện được.

 Viết báo cáo kết quả test sau khi thực hiện xong

1.1.7 Những điểm cần tập trung kiểm thử trước nhất nếu không có đủ thời

gian.

 Những chức năng quan trong nhất (mục đích) của dự án

 Những chức năng được người dung xem nhiều nhất

 Những chức năng có thể ảnh hưởng nhiều nhất đến độ an toàn

 Những chức năng có thể ảnh hưởng nhiều nhất đến tài chính

 Những phần quan trọng nhất đối với người dùng,

 Những phần có code phức tạp nhất

 Những thành phần được code bội vã hoặc áp lực nhất

 Những phần tương tự hoặc liên quan những dự án trước và đã gây lỗi

 Những phần tương tự hoặc liên quan những dự án trước và tốn nhiềuchi phí bảo trì

 Những phần mà yêu cầu thiết kế không rõ ràng

1.1.8 Các tiêu chí đánh giá kiểm thử

Tiêu chí đánh giá kiểm thử là đo độ bao phủ và chất lượng của kiểm thử

 Sự bao phu của kiểm thử là một tiêu chí quan trọng trong tiến trìnhkiểm thử, nó phải bao phủ toàn bộ các yêu cầu cần kiểm thử và cáctrường hợp kiểm thử hay toàn bộ chương trình

 Chất lượn của kiểm thử là một tiêu chí quan trong để đánh giá độ tincậy, tính hiệu năng, sự ổn định của chương trình Chất lượng của kiểmthử phụ thuộc vào việc đánh giá, phân tích để phát hiện ra lỗi củachương trình trong suốt tiến trình kiểm thử

1.1.9 Các nguyên tắc kiểm thử

- Lập trình viên không nên thực hiện kiểm thử trên phần mềm mà mình đãviết

- Cần phải kiểm tra các chức năng mà phần mềm không thực hiện

- Tránh việc kiểm thử phần mềm với giả định rằng sẽ không có lỗi nào tìmthấy

- Trường hợp kiểm thử ( Test case) phải được định nghĩa kết quả đầu ra rõràng

- Trường hợp kiểm thử phải được lưu trữ và thực thi lại mỗi khi có sự thayđổi xảy ra trong hệ thống

1.2 Mục tiêu của kiểm thử

Việc kiểm thử nhằm thực hiện hai mục tiêu:

 Bằng việc kiểm thử sẽ tìm ra được những lỗi trong phần mềm (Myers,1979) và thiết lập chất lượng của phần mềm (Hetzel, 1988)

 Việc kiểm thử thành công khi bạn tìm được ít nhất một lỗi, và đưa ra

sự đánh giá với độ tin cậy lớn

1.3 Vai trò của kiểm thử

 Testing để tìm ra lỗi, ghi nhận các thông tin về lỗi, nhưng không sửalỗi

 Testing giúp kiểm định phần mềm, đẩm bảo rằng phần mềm “đủ tốt”với độ rủi ro “thấp nhất” có thể

1.4 Phân loại kiểm thử

Ta thực hiện phân loại kiểm thử dựa vào các yếu tố: mục đích kiểm thử, chiếnlược kiểm thử, phương pháp kiểm thử và kỹ thuật kiểm thử

a Các kiểu kiểm thử không có sự phân loại cụ thể rõ ràng mà nó phụ thuộcvào chính mục đích của công việc kiểm thử trong từng giai đoạn cụ thểnào đó, có thể kể ra như là:

 Test cấp đơn vị (Unit testing): Là kiểu test kiểm tra code xem liệuchức năng nó đang thực hiện có đúng cách hay không theo như yêucầu

 Kiểm thử unit ứng dụng ở mức mô đun Thường là được thựchiện bởi nhà phát triến trước khi các mô đung được tích hợpvới các mô đun khác

 Kiểm thử Unit là mức thấp nhất trong tiến trình kiểm thử,thường là áp dụng phương pháp kiểm thử hộp trắng

 Kết quả của kiểm thử Unit thường tìm ra khoảng 20% lỗi trongtất cả các lỗi của dự án

 Test cấu hình (Shakeout testing): Kiểu test này cơ bản là kiểu test vềkhả năng của hệ thông mạng, kết nối dữ liệu và sự tương tác của cácmodul Thông thường thì kiểu test này do nhóm quản lý cấu hìnhchuẩn bị thiết lập các môi trường test thực sự Họ cũng test xem liệucác thành phần chính của phần mềm có hoạt động bất thường không,Kiểu test này thực hiện trước khi tiến hành thực hiện trong môi trườngtest Sau khi test Shakeout, bước kế tiếp là test smoke

 Test sơ lược (Smoke testing (ad-hoc testing)): Là kiểu test được thựchiện khi phần code được biên dịch mới chỉ được chuẩn bị tiến hànhtrong môi trường test Kiểu này cơ bản giống kiểu ad hoc để kiểm trađại khái để chắc chắn rằng các chức năng chính có bị bất thường haykhông? Nó mở đầu cho quá trình test bởi Tester QA Sau khi test

smoke, các tester sẽ thực hiện test khả năng thực thi của các chươngtrình.

 Test chức năng (Functional testing): Là kiểu test liệu mỗi và mọi chứcnăng của ứng dụng đó đang làm việc có như yêu cầu tài liệu nó làkiểu test mà 80% công việc test được thực hiện Trong kiểu test nàythì các testcase được thực thi

 Test tích hợp (Integration testing): Là kiểu test kiểm tra liệu tất cả cácmodul là được kết hợp hoặc chưa kết hợp lại cùng với nhau thực hiệncông việc có đạt được kết quả như tài liệu yêu cầu đã đượ xác định(do mỗi lập trình viên thực hiện trên các modul khác nhau Khi họhoàn thành đoạn code của họ, nhóm quản lý cấu hình ráp chúng lạivới nhau và chuẩn bị biên dịch Các tester cần chắc chắn rằng cácmodule này bây giờ đã được kết hợp và làm việc theo như yêu cầu –tức là phải test theo như yêu cầu)

 Test hồi quy (Regression testing): Khi một chức năng mới được thêmvào phần mềm, chúng ta cần chắc chắn rằng phần chức năng mớiđược thêm vào không phá hỏng các phần khác của ứng dụng Hoặckhi lỗi đã được chỉnh sửa, chúng ta cần chắc chắn rằng lỗi chỉnh sửakhông phá hỏng các phần khác của ứng dụng Để test điều này chúng

ta thực hiện test lặp đi lặp lại gọi là test hồi quy

 Thực hiện kiểm thử hồi quy thông thường mất rất nhiều nỗi lực

cố gắng Vì thế, kiểm thử hồi quy có thể được thực hiện saumột giai đoạn Tuy nhiên, kiểm thử hồi quy phải được thựchiện khi:

- Tổng số những yêu cầu thay đổi xảy ra từ bản cơ sở cuốicùng với kiểm thử hồi quy lớn hơn 10% tổng số những yêucầu trong cơ sở đó

- Tỉ lệ tổng số lỗi được phát hiện sau kiểm thử kiểm nhận haykhông trong tháo tác chia tổng số man-months của dự ánlớn hơn 1

Với những dự án bảo trì, khởi động cho kiểm thử hồi quy phảiđược xác định trong kế hoạch kiểm thử Leader kiểm thử phải xácđịnh khi nào đội dự án kiểm soát kiểm thử hồi quy và phạm vi kiểmthử hồi quy Lập biểu của kiểm thử hồi quy phải được xác định tronglập biểu của dự án

 Test hệ thống (System testing): Khi tester hoàn thành công việc test(các tester test ứng dụng trong các môi trường test, nghĩa là họ test với

dữ liệu test, không test trên dữ liệu thật), ứng dụng (phần mềm) phải

được test trên môi trường thật Nó nghĩa là gì, tức là kể từ khi cáctester test với dữ liệu test, chúng ta phải chắc chắn rằng ứng dụng làmviệc tốt trong môi trường thật Trong môi trường test, một vài điềukhông thể test hoặc thao tác giả Tất cả sẽ khác nhau và cơ sở dữ liệukhác nhau, một số thao tác có thể không làm việc như mong đợi khiứng dụng được chuyển từ môi trương test sang môi trường sản phẩm.

 Test tải dữ liệu (Load testing): Là kiểu test kiểm tra thời gian đáp lạingười dùng với số lượng người dùng bất kỳ trong một ngữ cảnh nào

đó của một ứng dụng tại cùng một thời điểm

 Test tải trọng (Stress testing): Là kiểu test kiểm tra thời gian đáp lạingười dùng với ứng số lượng người dùng bất ký trong nhiều ngữ cảnhkhác nhau của một ứng dụng tại một thời điểm

 Test hiệu suất (Performance testing): Trong loại test này dựa vào sứcnặng như sự phức tạp của giá trị, độ dài đầu vào, độ dài của câu truyvấn… Loại test này kiểm tra bớt phần tải (Stress/load) của ứng dụng

có thể được chắc chắn hơn

 Test chấp nhận từ người sử dụng (User acceptance testing): Trongkiểu test này, phần mềm sẽ được thực hiện kiểm tra từ người dùng đểtìm ra nếu phần mềm phù hợp với sự mong đợi của người dùng vwfthực hiện đúng như mong đợi Trong thời gian test này, tester có thểcũng thực hiện hoặc khách hàng có các tester của riêng họ để thựchiện

 Test hộp đen (Black box testing): Là kiểu test mà tester thực hiệnkhông chú ý đến code (hoặc là một hình thức test mà ứng dụng đangtest được xem như một hộp đen và hành vi bên trong của chương trìnhhoàn toàn được bỏ qua Việc test xảy ra dựa trên các đặc tả bên ngoài.Cũng hiểu như test hành vi, chỉ hành vi bên ngoài của ứng dụng làđược đánh giá và phân tích)

 Các kỹ thuật thường dùng:

- Lược đồ nguyên nhân kết quả

- Phân đoạn tương đương

- Phân tích giá trị biên

 Test hộp trắng (White bõ testing): Là test mà các tester tìm kiếm lỗitrong code, sử dụng các đặc tả chi tiết

 Bao gồm các chỉ dẫn bao quát, bao gồm toàn bộ các câu lệnhđiều kiện đơn, các điều kiện, đa điều kiện

 Kiểm thử hộp trắng là một thiết kế kiểm thử sử dụng cấu trúccủa thiết lế chi tiết Sử dụng thiết kế chi tiết người dử dụng cóthể đẩm bảo rằng:

- Bảo đảm rằng tất cả các đường dẫn độc lập ở bên trong

mô đun đều được thử tối thiếu một lần

- Thử nghiệm tất cả các trường hợp logic trong các câu lệnhđiều kiện

- Thực hiện tất cả các vòng lặp tới giá trị biên của chúng

- Thử nghiệm tất cả các giá trị biên bên trong đảm bảochúng hợp lệ

 Test Alpha (Alpha testing): Trong lại test này, các người dùng đượcmời đến điểm tập trung đề xuất ý kiến, nơi mà họ sẽ sử dụng chươngtrình và người phát triển chú ý mỗi thông tin liên quan hoặc hànhdộng được đặt ra bởi người dùng Bất kỳ hành vi bất thường nào của

hệ thống cũng pahir được ghi nhận và chỉnh sửa bởi người phát triển

 Test Beta (Beta testing): Trong loại test này, phần mềm được phân bổnhư một phiên bản thử nghiệm(sử dụng thử) để người dùng kiểm traứng dụng tại nơi làm việc của họ Người sử dụng sẽ quan sát phầnmềm, trong trường hợp nếu có bất kỳ lỗi xảy ra thì nó được báo cáođến người phát triển

 Test bảo mật(Security test): Phần test này pahir rà soát, tìm những lỗhổng của hệ thống mà từ những lỗ hổng đó hacker có thể xâm nhập,phá hỏng hoặc làm sai lệch hệ thống -> yêu cầu của loại test này đòihỏi tester phải có 1 kiếm thức nhất định về Security Đối với laoij testnày nên kết hợp hài hào giữa test manual và auto

b Dựa vào chiến lược kiểm thử ta có thể phân chia kiểm thử thành hai loại:Kiểm thử thủ công và kiểm thử tự động

 Kiểm thử thủ công là Tester làm mọi thứ bằng tay, từ viết test caseđến thực hiện test, mọi thao tác như nhập điều kiện đầu vào, thực hiệnmột số sự kiện khác như click nút và quan sát kết quả thực tế, sau đó

so sánh kết quả thực tế với kết quả mong muốn trong test case, điền

kết quả test Mọi thứ hoàn toàn bằng tay.

 Kiểm thử tự động là quá trình thực hiện một các tự động các bướctrong một kịch bản kiểm thử Kiểm thử tự động bằng một công cụnhắm rút ngắn thời gian kiểm thử

Chúng ta sẽ tìm hiểu rõ hơn về kiểm thử tự động ở chương tiếp theo

c Theo phương pháp tiến hành kiểm thử ta chia kiểm thử làm hai loại:Kiểm thử tĩnh và kiểm thử động

 Kiểm thử tĩnh là một hình thức của kiểm thẻ phần mềm mà phần mềmkhông được sử dụng thực sự Điều này ngược với kiểm thử tự động.Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đứngdắn của code, thuật toán hay tài liệu.

 Kiểm thử động là một hình thức kiểm thử phần mềm chạy mã lậptrình thực tế trong các tình huống, diễn ra khi bản thân chương trình

đó đang được sử dụng Kiểm thử động có thể bắt đầu trước khichươ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ệt hoặc Module

d Dựa vào kỹ thuật kiểm thử ta có thể phân chia kiểm thử thành ba loại:Kiểm thử hộp đen, kiểm thử hộp trắng và kiểm thử hộp xám.Trong baphương pháp trên, hai phương pháp phổ biến để chọn ra một tập dữ liệukiểm thử một cách thông minh

 Phương pháp hộp đen

 Phương pháp hộp trắng

Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể

Do đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnhcủa cả hai phương pháp trên Mỗi phương pháp lại có những chiến lược pháthiện và tiếp cận lỗi khác nhau

1.5 Các trường hợp kiểm thử và dữ liệu kiểm thử

 Kiểm tra các toán tử ở mức giá trị thông thường

 Kiểm tra với các giá trị giới hạn

 Kiểm tra với ngoài vùng giá trị

 Kiểm tra các lỗi ở trong vòng lặp

 Kiểm tra các kết thúc không bình thương trong vòng lặp

 Kiểm tra các kết thúc không bình thường trong đệ quy

 Kiểm tra tất cả các cấu trúc dữ kiệu được truy nhập bởi hàm

 Kiểm tra tất cả các loại file được truy nhập bởi hàm thành viên

 Kiểm tra tất cả các lỗi điều kiện

 Kiểm tra tính hiệu quả của kiểm thử nếu thấy cần thiết

 Đảm bảo rằng mọi câu lệnh đều được thực hiện

 Đảm bảo rằng mọi câu lệnh điều kiện đều thực hiện ở tất cả cácnhánh

1.6 Phương pháp xây dựng các tài liệu kiểm thử

1.6.1 Test plan

Test plan là gì?

Kế hoạch kiểm thử phần mềm (test plan) là một tài liệu mô tả các mục tiêu,phạm vi, phương pháp tiếp cận và tập trung vào quá trình kiểm thử phần mềm Quá

trình chuẩn bị test plan là cách hữu ích để suy nghĩ về những điều cần thiết để xácnhận khả năng chấp nhận một sản phẩm phần mềm Các tài liệu đã hoàn thành sẽgiúp mọi người bên ngoài nhóm kiểm thử hiểu được 'tại sao?' và 'như thế nào?' đểchấp nhận sản phẩm Nó cần phải đầy đủ để dùng được nhưng không cần quá hoànhảo vì không ai ngoài nhóm kiểm thử sẽ đọc nó Sau đây là một số nội dung có thể

có trong một test plan, tùy thuộc vào từng dự án cụ thể:

- Tiêu đề

- Định nghĩa phiên bản của phần mềm (phiên bản bàn giao).

- Lưu lại quá trình hiệu chỉnh tài liệu như: tác giả, ngày cập nhật,

người duyệt

- Mục lục.

- Mục đích của tài liệu, giới thiệu chung.

- Mục tiêu của chi phí kiểm thử (test).

- Giới thiệu tổng quan về sản phẩm.

- Danh sách tài liệu liên quan như tài liệu đặc tả yêu cầu, tài liệu

thiết kế, các kế hoạch test khác,

- Các tiêu chuẩn thích hợp, các yêu cầu hợp lệ.

- Nguồn gốc của các sự thay đổi.

- Phân tích rủi ro của dự án.

- Các vấn đề ưu tiên và tập trung kiểm thử.

- Phạm vi và giới hạn kiểm thử

- Kiểm thử tự động - giải thích và tổng quan

- Các công cụ kiểm thử được sử sụng, bao gồm các phiên bản, bản

sửa lỗi, v.v

- Các qui trình bảo trì và quản lý phiên bản của kịch bản kiểm thử/

mã kiểm thử

- Theo dõi và giải quyết vấn đề - Các công cụ và quy trình

- Các thước đo về sản phẩm kiểm thử được sử dụng

- Báo cáo các yêu cầu và khả năng bàn giao.

- Điều kiện đầu vào và đầu ra của phần mềm.

- Giai đoạn và điều kiện kiểm thử ban đầu.

- Điều kiện dừng kiểm thử và kiểm thử lại.

- Sự bố trí nhân sự.

- Những người cần đào tạo trước khi tham gia.

- Nơi kiểm thử.

- Các tổ chức kiểm thử bên ngoài sẽ sử dụng tài liệu: mục đích,

trách nhiệm, khả năng hoàn thành, người liên hệ và các vấn đề hợptác của họ

- Các vấn đề về: phân loại, bảo mật và bản quyền của phần mềm, tài

Một test case có thể có các phần đặc thù khác nhau như mã test case, tên testcase, mục tiêu test, các điều kiện test, các yêu cầu dữ liệu đầu vào (data input), cácbước thực hiện và các kết quả mong đợi Mức chi tiết có thể được định nghĩa khácnhau 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

Thiết kế test – case trong kiểm thử phần mềm là quá trình xây dựng các phươngpháp kiểm thử có thể phát hiện lỗi của phần mềm để xây dựng phần mềm đạt tiêuchuẩn

c Quy trình thiết kế test case

Một trong những lý do quan trọng nhất trong kiểm thử chương trình là thiết kế

và tạo ra các ca kiểm thử - các Test case có hiệu quả Với những ràng buộc về thờigian và chi phí đã cho, thì vấn đề then chốt của kiểm thử trở thành:

Tập con nào của tất cả ca kiểm thử có thể có khả năng tìm ra nhiều lỗi nhất?

Thông thường, phương pháp kém hiệu quả nhất là kiểm tra tất cả đầu vàongẫu nhiên – quá trình kiểm thử một chương trình bằng việc chọn ngẫu nhiên mộttập con các giá trị đầu vào có thể Tập hợp các ca kiểm thử được chọn ngẫu nhiên

có rất ít cơ hội là tập hợp tối ưu hay gần tối ưu Hai phương pháp phổ biến để chọn

ra một tập dữ liệu kiểm thử một cách thông minh

1 Phương pháp hộp đen

2 Phương pháp hộp trắng

Để kiểm thử hộp đen và kiểm thử hộp trắng một cách thấu đáo là không thể

Do đó, một chiến lược kiểm thử hợp lý là chiến lược có thể kết hợp sức mạnh của

cả hai phương pháp trên Mỗi phương pháp lại có những chiến lược phát hiện vàtiếp cận lỗi khác nhau.

Những chiến lược kết hợp đó bao gồm:

1 Phân lớp tương đương

2 Phân tích giá trị biên

3 Đồ thị nguyên nhân – kết quả

1 Bao phủ câu lệnh

2 Bao phủ quyết định

3 Bao phủ điều kiện

4 Bao phủ điều kiện – quyết định

5 Bao phủ đa điều kiện

Mỗi phương pháp có những ưu điểm cũng như khuyết điểm riêng, do đó để

có được tập các ca kiểm thử tối ưu, chúng ta cần kết hợp hầu hết các phương pháp.Quy trình thiết kế các ca kiểm thử sẽ bắt đầu bằng việc phát triển các ca kiểm thử sửdụng phương pháp hộp đen và sau đó phát triển bổ sung các ca kiểm thử cần thiếtvới phương pháp hộp trắng

Tuy nhiên trong phạm vi của bản báo cáo này tôi xin phép được trình bày kĩ

hơn về cách xây dựng test case bằng phương pháp hộp đen.

- Phân lớp tương đương – Equivalence Patitioning

Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầuvào của một chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử Thiết kế ca kiểm thử cho phân lớp tương đương dựa trên sự đánh giá về cáclớp tương đương với một điều kiện vào Lớp tương đương biểu thị cho tập các trạngthái hợp lệ hay không hợp lệ đối với điều kiện vào

Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước:

(1) Xác định các lớp tương đương(2) Xác định các ca kiểm thử

- Xác định các lớp tương đương

Các lớp tương đương được xác định bằng bằng cách lấy mỗi trạng thái đầuvào (thường là 1 câu hay 1 cụm từ trong đặc tả) và phân chia nó thành 2 hay nhiềunhóm

Một mẫu cho việc liệt kê các lớp tương đương:

Điều kiện bên ngoài Các lớp tương đương

hợp lệ

Các lớp tương đươngkhông hợp lệ

Chú ý: là hai kiểu lớp tương đương được xác định: lớp tương đương hợp lệ mô tả

các đầu vào hợp lệ của chương trình, và lớp tương đương không hợp lệ mô tả tất cảcác trạng thái có thể khác của điều kiện (ví dụ, các giá trị đầu vào không đúng) Với

1 đầu vào hay điều kiện bên ngoài đã cho, để xác định các lớp tương đương có thể

áp dụng tập các nguyên tắc dưới đây:

1 Nếu điều kiện đầu vào xác định một khoảng giá trị [a,b], thì phân hoạch

thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ

2 Nếu điều kiện đầu vào yêu cầu một giá trị xác định, phân hoạch thành một

lớp tương đương hợp lệ và hai lớp tương đương không hợp lệ Chẳng hạn,

3 Nếu điều kiện đầu vào xác định một phần tử của tập hợp, thì phân hoạch

thành một lớp tương đương hợp lệ và một lớp tương đương không hợp lệ

- Xác định các ca kiểm thử

Với các lớp tương đương xác định được ở bước trên, bước thứ hai là sử dụngcác lớp tương đương đó để xác định các ca kiểm thử Quá trình này như sau:

1 Gán 1 số duy nhất cho mỗi lớp tương đương

2 Đến khi tất cả các lớp tương đương hợp lệ được bao phủ bởi các trườnghợp kiểm thử thì viết một trường hợp kiểm thử mới sao cho mỗi trường

hợp mới phủ nhiều nhất có thể các lớp tương đương hợp lệ chưa được

Ví dụ: Xét các lớp tương đương của giá trị đầu vào của chức năng thêm sinh viên

trong phần mềm Quản Lý Sinh Viên

Đầu vào Lớp giá trị tương đương

Độ dài số ký tự nhỏ hơn 10

Không phải là chữ cáiRỗng

Độ dài số ký tự lớn hơn 10

Các ký tự chữ cáiKhông rỗng

Độ dài số ký tự nhỏ hơn 15

Không phải số

Độ dài số ký tự lớn hơn 15SDT cố định Ký tự số

Độ dài số ký tự nhỏ hơn 15

Không phải số

Độ dài số ký tự lớn hơn 15Địa chỉ Độ dài số ký tự nhỏ hơn 128 Độ dài số ký tự lớn hơn 128Địa chỉ liên hệ Độ dài số ký tự nhỏ hơn 128 Độ dài số ký tự lớn hơn 128

Bảng 1.2 Bảng phân lớp tương đương của chức năng Thêm Sinh Viên

- Phân tích giá trị biên – Boundary Value Analysis

Các ca kiểm thử mà khảo sát tỷ mỷ các điều kiện biên có tỷ lệ phần trăm caohơn các ca kiểm thử khác

Các điều kiện biên là những điều kiện mà các tình huống ngay tại, trên và dướicác cạnh của các lớp tương đương đầu vào và các lớp tương đương đầu ra

Phân tích giá trị biên yêu cầu óc sáng tạo và lượng chuyên môn nhất định Tuynhiên, có một số quy tắc chung như sau:

1 Nếu điều kiện đầu vào xác định một khoảng giá trị giữa a và b, cáctrường hợp kiểm thử sẽ được thiết kế với giá trị a và b, và các giá trịsát trên và sát dưới a và b

2 Nếu một điều kiện đầu vào xác định một số các giá trị, các trường hợpkiểm thử sẽ được phát triển để thực hiện tại các giá trị cực đại, cựctiểu

3 Các giá trị sát trên và dưới giá trị cực đại, cực tiểu cũng được kiểmthử

4 Nguyên tắc 1 và 2 được áp dụng cho các điều kiện đầu ra.

5 Nếu cấu trúc dữ liệu chương trình bên trong được qui định cácbiên ,tập trung thiết kế trường hợp kiểm thử để thực thi cấu trúc dữliệu tại biên của nó

Bảng 1.3 Các giá trị biên của chức năng Thêm Sinh Viên

- Đồ thị nguyên nhân – kết quả - Cause & Effect Graphing

Một yếu điểm của phân tích giá trị biên và phân lớp tương đương là chúngkhông khảo sát sự kết hợp của các trường hợp đầu vào Việc kiểm tra sự kết hợpđầu vào không phải là một nhiệm vụ đơn giản bởi vì nếu bạn phân lớp tương đươngcác trạng thái đầu vào, thì số lượng sự kết hợp thường là rất lớn Nếu bạn không cócách lựa chọn có hệ thống một tập con các trạng thái đầu vào, có thể bạn sẽ chọn ramột tập tùy hứng các điều kiện, điều này có thể dẫn tới việc kiểm thử không có hiệuquả

Đồ thị nguyên nhân – kết quả hỗ trợ trong việc lựa chọn một cách có hệthống tập các ca kiểm thử có hiệu quả cao Nó có tác động có lợi ảnh hưởng tớiviệc chỉ ra tình trạng chưa đầy đủ và nhập nhằng trong đặc tả Nó cung cấp cả cáchbiểu diễn chính xác cho các điều kiện logic và hành động tương ứng

Quá trình dưới đây để tạo đồ thị

1 Tất cả các nguyên nhân (các đầu vào) và các kết quả (các đầu ra) đượcliệt kê dựa trên đặc tả và được định danh cho mỗi nhân - quả.

2 Các quan hệ giữa các nguyên nhân (các đầu vào) và các kết quả (cácđầu ra) được biểu diễn trong đồ thị làm rõ ràng các quan hệ logic

3 Từ đồ thị tạo ra bảng quyết định biểu diễn các quan hệ giữa nguyênnhân và kết quả Dữ liệu kiểm thử được sinh ra dựa trên các quy tắctrong các bảng này

Bảng 1.4 Các quy tắc xây dựng đồ thị nhân – quả

Ví dụ: Chức năng tra cứu điểm thi của phần mềm quản lý sinh viên hỗ trợ giáo vụtra cứu điểm theo 4 điều kiện:

a: Tra theo lớp

b: Tra theo môn học

c: Tra theo mã sinh viên

d: Hoặc tra theo tên sinh viên

Việc tra cứu điểm thi có thể kết hợp các điều kiện hoặc sử dụng một điểu kiện để

e: tìm thấy 1 hoặc nhiều sinh viên thõa mãn

g: hoặc không tìm thấy

Từ các dữ liệu trên ta có một số đồ thị nhân quả sau:

31

a b

c

or

a b

e

and

a d

e

and

Từ đồ thị nhân quả ta sẽ tạo được bảngquyết định với dạng:

Tên bảng Quy tắc

Tên bảng: cho biết tên logic Quy tắc: đánh số để phân biệt các quy tắc

quyết dịnh logic

Các dòng điều kiện: Mỗi dòng gồm các

điều kiện để tạo quyết định cho chương trình

e

and

b c

: Không có xử lý được thực hiện

…

Đây là bảng hỗ trợ quyết định của chức năng tra cứu điểm thi để viết test case trong phần sau của tài liệu

(**) Các ô không được chọn trên mục điều kiện tương ứng với ‘N=No’ trong bảng hỗ trợ quyết định

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 2

0

Điều kiện

Lý thuyết Bật Thực hành Bật Tất cả Bật y y y y y y y y y y y y y y y y y y y Y

Môn <>Trống

Không tồn tại y y Trống y y y y y y y

Tên sinh viên

<>Trống Tồn tại y y y y y y y y

Không tồn tại x y Trống y y y y y y y

Lớp <>Trống

Không tồn tại y y Trống y y y y y y y

Mã sinh viên

Trống y y y y y y y Thao tác Lọc x x x x x x x x x x x x x x x x x x x X

Nhập lại Kết quả hiển

thị

Chỉ hiển thị kết quả liên quan x x x x x x x x x x x x x X Hiển thị danh sách trống x x x x x

CHƯƠNG II: NGHIÊN CỨU VỀ KIỂM THỬ TỰ ĐỘNG

1.1 Khái quát về kiểm thử tự động

Kiểm thử phần mềm tốn nhiều chi phí nhân công, thời gian Trong một số dự án,chi phí kiểm thử phần mềm chiếm 50% tổng giá trị của dự án Nếu cần ứng dụng antoàn hơn, chi phí kiểm thử còn cao hơn nữa

Do đó một trong các mục tiêu của kiểm thử là tự động hóa nhiều, nhớ đó màgiảm thiểu chi phí, giảm lỗi, giúp việc kiểm thử hồi quy dễ dàng và nhanh chónghơn Đặc biệt là kiểm thử hiệu năng và tải trong ví dụ với hàng ngàn người cùngtruy cập một lúc thì việc con người trực tiếp tham gia kiểm thử là không thể

Tự động hóa việc kiểm thử là dùng phần mềm điều kiển việc thi hành kiểm thử,

so sánh kết quá có được với kết quả mong muốn, thiết lập các điều kiện đầu vào,các kiểm soát kiểm thử và các chức năng báo cáo kết quả…

Kiểm thử tự động là gì?

Kiểm thử tự động là quá trình thực hiện một cách tự đọng các bước trong mộtkịch bản kiểm thử Kiểm thử tự động bằng một công cụ nhằm rút ngắn thời giankiểm thử

Tại sao phải kiểm thử tự động?

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

 Giảm bớt công sức và thời gian thực hiện qua trình kiểm thử

 Tăng độ tin cậy

 Giảm sự nhàm chán cho tester

 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ử

Khi nào cần kiểm thử tự động?

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

Ví dụ khi thực hiện kiểm tra chức năng của một website Website này sẽđược kiểm tra với 6 môi trường gồm 3 trình duyệt và 2 hệ điều hành.Tình huống này đòi hỏi số lần kiểm tra tăng lên và lặp lại 6 lần so vớiviệc kiểm tra cho một môi trường cụ thể

 Kiểm tra hồi quy: Trong quá trình phát triển phần mềm, nhóm lập trìnhthường đưa ra nhiều phiên bản liên tiếp để kiểm tra Việc đưa ra cácphiên bản phần mềm có thể là hàng ngày, mỗi phiên bản bao gồm nhữngtính năng mới, hoặc tính năng cũ được sửa lỗi, nâng cấp Việc bổ sunghoặc sửa lỗi code ở phiên bản mới có thể làm cho những tính năng khác

đã kiểm tra tốt chạy sai mặc dù phần code không hề chỉnh sửa Để khắc

phục, kiểm thử viên không chỉ kiểm tra chức năng mới hoặc được sửa,

mà phải kiểm tra lại tất cả những tính năng đã kiểm tra tốt trước đó Điềunày khó khả thi về mặt thời gian nếu kiểm tra thủ công

 Kiểm tra khả năng vận hành phần mềm trong môi trường đặc biệt:

Nhằm đánh giá xem vận hành của phần mềm có thỏa mãn yêu cầu đặt

ra hay không Thông qua đó kiểm thử viên có thể xác định được các yếu

tố về phần cứng, phần mềm ảnh hưởng đến khả năng vận hành của phầnmềm Một số tình huống kiểm tra tiêu biểu thuộc loại này:

Đo tốc độ trung bình xử lý một yêu cầu của web server

Thiết lập 1000 yêu cầu, đồng thời gửi đến web server, kiểm tra tình huống

1000 người dùng truy xuất web cùng lúc

Xác định số yêu cầu tối đa được xử lý bởi web server hoặc xác định cấuhình máy thấp nhất mà tốc độ xử lý của phần mềm vẫn hoạt động ở mức cho phép

Việc kiểm tra thủ công cho những tình huống trên là cực khó, thậmchí “vô phương”

Hoạt động kiểm thử tự động nhằm mục đích kiểm tra, phát hiện những lỗi củaphần mềm trong những trường hợp đoán trước Nó thường được thực hiện sau khi

đã thiết kế xong các tình huống (test case) Tuy nhiên, không phải mọi trường hợpkiểm tra đều có thể hoặc cần thiết phải tự động hóa, trong tất cả test case thì kiểmthử viên phải đánh giá và chọn ra những test case nào phù hợp hoặc cần thiết để ápdụng kiểm thử tự động dựa trên những tiêu chí đã đề cập bên trên

1.2 Nguyên tắc của kiểm thử tự động

Thực sự là sai lầm khi nghĩ tự động là đơn giản chụp lại, ghi lại 1 tiến trìnhkiếm thử thủ công Thực tế, kiểm thử tự động có những điểm khác với kiểm thử thủcông Nó có những lỗi và khả năng dự đoán

Kiểm thử có thể cho thấy rằng phần mềm đang có lỗi, nhưng không thể chứngminh rằng phần mềm không có lỗi Kiểm thử làm giảm xác suất lỗi chưa tìm thấyvẫn còn trong phần mềm, thậm chí là không còn lỗi nào, nó không phải là bằngchứng của sự chính xác.

Nguyên tắc 2 – Kiểm thử mọi thứ là không thể

Kiểm thử mọi thứ (tất cả các tổ hợp của điều kiện input đầu vào) là không thểthực hiện được, trừ phi nó chỉ bao gồm một số trường hợp bình thường (ít trườnghợp tổ hợp thì có thể test toàn bộ được) Thay vì kiểm thử toàn bộ, việc phân tíchrủi ro và dựa trên sự mức độ ưu tiên chúng ta có thể tập trung việc kiểm thử vàomột số điểm cần thiết

Nguyên tắc 3 – Kiểm thử sớm

Để tìm được bug sớm, các hoạt động kiểm thử nên được bắt đầu càng sớm càngtốt trong qui trình phát triển (vòng đời phát triển) phần mềm hoặc hệ thống, và nêntập trung vào các hoạt động đã định trước

Nguyên tắc 4 – Sự tập trung của lỗi

Nỗ lực kiểm thử nên tập trung một cách cân đối vào mật độ lỗi dự kiến và lỗiphát hiện ra sau đó trong các mô-đun Một số ít các mô-đun thường chứa nhiều lỗikhông phát hiện ra trong lúc kiểm thử trước khi phát hành (release), hoặc chịu tráchnhiệm cho hầu hết các lỗi hoạt động của phần mềm

Nguyên tắc 5 – Nghịch lý thuốc trừ sâu

Nếu việc kiểm thử tương tự nhau được lặp đi lặp lại nhiều lần, thì cuối cùng sẽ

có một số trường hợp kiểm thử (ca kiểm thử - test case) sẽ không còn tìm thấy bất

kỳ lỗi nào mới Để khắc phục "nghịch lý thuốc trừ sâu" này, các trường hợp kiểmthử cần phải được xem xét và sửa đổi thường xuyên, và cần phải viết các test casemới và khác nhau để thực hiện nhiều phần khác nhau của phần mềm hoặc hệ thống

để tìm ra lỗi tiềm ẩn nhiều hơn nữa

Nguyên tắc này giống như việc trừ sâu trong nông nghiệp, nếu chúng ta cứ phunmột loại thuốc với nồng độ giống nhau trong một khoảng thời gian dài thì có một sốcon sâu sẽ quen dần và cuối cùng việc phun thuốc giống như là tắm chúng vậy (bịlờn thuốc) => lúc đó chúng ta không thể diệt sạch chúng được Do vậy, để diệt sạchsâu một cách hiệu quả, người ta thường thay đổi loại thuốc trừ sâu, mỗi loại chỉdùng trong khoảng thời gian ngắn

Nguyên tắc 6 – Kiểm thử theo các ngữ cảnh độc lập

Nguyên tắc này là việc testing phụ thuộc vào ngữ cảnh, test trong nhiều ngữcảnh khác nhau.

Để hiểu rõ hơn chúng ta xem ví dụ sau:

Ví dụ, cũng với một chương trình calculator có rất nhiều chức năng, nhưng:

- Nếu test chương trình này cho mẫu giáo thì chỉ cần test cộng trừ là OK

- Nếu test chương trình này cho cấp 2 thì cộng trừ nhân chia

- Nếu test chương trình này cho đại học thì tích phân, đạo hàm, v.v

Nguyên tắc 7 – Sự sai lầm về việc không có lỗi.

Việc tìm và sửa chữa lỗi sẽ không giúp được gì nếu hệ thống được xây dựngxong nhưng không thể dùng được và không đáp ứng được nhu cầu và sự mong đợicủa người dùng (Nghĩa là nếu sau khi code, test rồi fix bug, làm đủ tất cả cáctrường hợp và cuối cùng cho ra một sản phẩm không như mong đợi hoặc không đápứng được nhu cầu của khách hàng thì dự án phần mềm đó coi như thất bại mặc dù

đã được test xong)

Hình 2.1 Tối ưu hóa trong kiểm thử tự động

ROI ( viết tắt của cụm từ Automation Return-on-Investment ) là 1 chỉ số tínhtoán tự động đánh gia dựa trên lợi nhuận và chi phí đầu tư khi bắt đầu lập kế hoạchcho 1 dự án Mục đích để tiết kiệm chi phí, tăng hiệu quả và tăng chất lượng phầnmềm (rủi ro giảm).

ROI= Lợi nhuận−Chi phí đầu tư Chi phí đầu tư

+ Ví dụ:

Hình 2.4 Tính toán ROI trong giai đoạn lập kế hoạch

- Giai đoạn 2: Tiến trình trong giai đoạn này thường trải qua 4 bước trong tiến trình kiếm thử: