Bảng Liệt Kê Các Lớp Tương Đương Của Chương Trình Nhập Điểm


Sau khi hoàn thành kiểm thử, các kết quả kiểm thử cần được xem xét để xác định chúng có phù hợp với các kết quả dự kiến không.

7.3.5. Đánh giá kết quả kiểm thử (Test Result)

1) Đánh giá tỷ lệ kiểm thử của Tình huống kiểm thử

Mục đích: Xác định tỷ lệ kiểm thử của tình huống kiểm thử dựa trên yêu cầu có đạt hay không.

Để đánh giá tỷ lệ kiểm thử của tình huống kiểm thử, cần xác định:

- Tỷ lệ giữa các tình huống kiểm thử được thực hiện và tổng số các tình huống kiểm thử đựơc đề ra.

- Tỷ lệ các các tình huống kiểm thử được thực hiện thành công.

2) Đánh giá tỷ lệ Code được kiểm thử

Mục đích: Xác định độ tỷ lệ code được kiểm thử có đạt yêu cầu hay không.

Để đánh giá độ tỷ lệ code được kiểm thử, cần xác định: Tỷ lệ giữa số dòng code được kiểm thử và tổng số dòng code dự định kiểm thử.

3) Phân tích lỗi Mục đích:

- Phân tích nguyên nhân, mức độ ảnh hưởng của lỗi và đề xuất hành động xử lý thích hợp.

- Lập báo cáo kết quả kiểm thử.

Các chỉ tiêu lỗi (thường được biểu diễn dưới dạng biểu đồ):

- Mức độ ảnh hưởng của lỗi - số lỗi được biểu diễn dưới dạng hàm của một hoặc hai thuộc tính lỗi (tình trạng hoặc mức độ ảnh hưởng).

- Xu thế của lỗi: Số lỗi được biểu diễn dưới dạng hàm theo thời gian.

- Thời gian khắc phục lỗi: Số lỗi được biểu diễn dưới dạng hàm của độ dài thời gian mà lỗi ở trong một trạng thái nhất định (chờ test, error, pending, tested, accepted...)

- Xác định tiêu chí hoàn thành kiểm thử có được thoả mãn hay không.

4) Cấu trúc chung của Test report

Bao gồm: Test plan, tên người thực hiện, ngày thực hiện, môi trường kiểm thử, bảng mô tả module/chức năng/test case và kết quả, kết luận, đề xuất (nếu có)

7.4. Chiến lược kiểm thử phần mềm

Có hai kiểu chiến lược kiểm thử. Kiểu thứ nhất liên quan logic được kiểm thử thế nào trong ứng dụng. Chiến lược kiểm thử logic có thể là black-box hoặc white-box. Chiến lược kiểm thử black-box cho ràng module của chương trình hoặc hệ thống liên quan tới đầu vào và đầu ra. Các chi tiết logic chi tiết được che dấu và không cần phân tích. Chiến lược black-box có tính hướng dữ liệu. White-box hướng tới việc cho rằng logic đặc trưng là quan trọng và cần phải kiểm thử. White-box đánh giá một vài hoặc


tất cả mặt logic để kiểm thử được tính đúng đắn của chức năng. White-box hướng về logic - giải thuật.

Kiểu thứ hai liên quan tới việc kiểm thử được tiến hành thế nào, không quan tâm chiến lược kiểm thử logic. Nó là top-down hoặc bottom-up. Top-down coi chương trình chính là quan trọng nhất nên cần phải phát triển và kiểm thử trước và tiếp tục trong quá trình phát triển. Bottom-up cho rằng các module và chương trình riêng sẽ được phát triển hoàn toàn như standalone. Vậy chúng được kiểm thử riêng rẽ sau đó được kết hợp thành kiểm thử tổ hợp.

7.4.1. Kiểm thử Black-box

1) Ý tưởng

Hình 7 3 Kiểm thử Black box Hệ thống phần mềm là một công cụ hỗ trợ để 1

Hình 7.3. Kiểm thử Black-box

Hệ thống phần mềm là một công cụ hỗ trợ để thực hiện các công việc chuyên môn của người sử dụng trên máy tính. Ví dụ phần mềm quản lý giáo vụ trường phổ thông hỗ trợ các nghiệp vụ: quản lý hồ sơ học sinh, kết quả học tập, tính điểm trung bình, …; phần mềm quản lý bán hàng hỗ trợ các nghiệp vụ: lập chứng từ hóa đơn bán hàng, đơn đặt hàng, tính doanh thu, in báo cáo,…

Ý tưởng của phương pháp kiểm thử Black-box (hộp đen):

- Chỉ quan tâm đến đầu ra và đầu vào

- Không quan tâm đến các xử lý

- Các xử lý được che dấu và không cần phân tích

- Không cần quan tâm đến cấu trúc, thiết kế, lập trình của chương trình. Do đó, người kiểm thử (Tester):

- Kiểm thử hệ thống dựa trên bản đặc tả yêu cầu và chức năng


- Không cần phải có kiến thức về

+ Ngôn ngữ lập trình

+ Môi trường phát triển phần mềm (IDE)

+ Các hệ quản trị cơ sở dữ liệu (SQL Server, Oracle, B2,…)

- Thao tác các chức năng của hệ thống như là một người sử dụng hệ thống.

2) Các phương pháp kiểm thử Black-box

a. Phân hoạch cân bằng (Equivalence Partitioning-EP)

- Là một phương pháp kiểm thử hộp đen phân chia tập dữ liệu đầu vào của một chương trình thành lớp các dữ liệu từ đó có các trường hợp kiểm thử có thể suy dẫn ra.

- Mục đích:

+ Tối thiểu các trường hợp kiểm thử cho trước

+ Không phải thực hiện nhiều trường hợp kiểm thử mới tìm ra lỗi

+ Xác định một trường hợp kiểm thử làm lộ ra một lớp lỗi để làm giảm tổng số các trường hợp kiểm thử phải thiết kế

+ Thực hiện trên tập dữ liệu đầu vào

- Các bước thực hiện:

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

+ Xác định các trường hợp kiểm thử

- Các lớp tương đương được định nghĩa theo các nguyên tắc sau:

+ 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ệ. Chẳng hạn, nếu đầu vào x nằm trong khoảng [0,100], lớp hợp lệ là 0 <= x <= 100, các lớp không hợp lệ là x < 0 và x > 100.

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

+ 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, nếu đầu vào x=5, thì lớp hợp lệ là x= 5, các lớp không hợp lệ là x <5 và x >5.

+ Nếu điều kiện đầu vào là Boolean, 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ệ tương ứng với hai trạng thái true và false.

Ngoài ra, một nguyên tắc thứ năm được bổ sung là sử dụng khả năng phán đoán, kinh nghiệm và trực giác của người kiểm thử.

Bảng 7.2. Bảng liệt kê các lớp tương đương


Điều kiện

EP hợp lệ

EP không hợp lệ




Có thể bạn quan tâm!

Xem toàn bộ 305 trang tài liệu này.

- Xác định các trường hợp kiểm thử

+ Gán một giá trị duy nhất cho mỗi lớp tương đương.


+ Đến khi tất cả các lớp tương đương hợp lệ được phủ bởi các trường hợp kiểm thử thì viết một trường hợp kiểm thử mới phủ nhiều nhất có thể các lớp tương đương hợp lệ chưa được phủ.

+ Đến khi tất cả các lớp tương đương không hợp lệ được phủ bởi các trường hợp kiểm thử thì hãy viết các trường hợp kiểm thử mới sao cho mỗi trường hợp kiểm thử mới chỉ phủ duy nhất một lớp tương đương không hợp lệ chưa được phủ.

Ví dụ 1:Xét một chương trình nhập điểm của sinh viên. Biết rằng mã sinh viên phải là các ký số, tên sinh viên gồm các ký tự chữ cái và không rỗng, giới tính có hai giá trị “M” hoặc “F”, điểm của sinh viên phải là số có giá trị từ 0 đến 100. Hãy lập bảng liệt kê các lớp tương tương.

Bảng 7.3. Bảng liệt kê các lớp tương đương của chương trình nhập điểm


Điều kiện

EP hợp lệ

không hợp lệ

Mã sinh viên

Các ký số

Không phải là các ký số

Tên sinh viên

Các ký tự chữ cái

Không rỗng

Không phảichữ cái

Rỗng

Giới tính

“M”

“F”

Không phải “M” hoặc “F”

Điểm

Số

≥ 0

≤ 100

Không phải số

< 0

>100

Ví dụ 2: Một Textbox chỉ cho phép nhập số nguyên từ 1 đến 100. Để kiểm tra tính đúng đắn của việc nhập dữ liệu, cần xây dựng ít nhất bao nhiêu trường hợp kiểm thử.

Có 3 trường hợp xẩy ra:

Do đó để kiểm tra màn hình trên cần ít nhất 3 trường hợp Test case 5 55 2

Do đó, để kiểm tra màn hình trên cần ít nhất 3 trường hợp (Test case): -5, 55, 102 hoặc 0, 10, 1000, …

Tuy nhiên nếu ta nhập vào số thập phân (55.5) hay một ký tự không phải là số (abc) thì khi đó phải chia làm trường hợp như sau:

- Các số nguyên từ 1 đến 100

- Các số nguyên nhỏ hơn 1

- Các số nguyên lớn hơn 100

- Không phải số

- Số thập phân

Như vậy, việc phân hoạch cân bằng có đúng và đủ hay không là tùy thuộc vào kinh nghiệm của người kiểm thử.


Ví dụ 3: Cho một chương trình tìm số lớn nhất và nhỏ nhất trong 3 số. Để kiểm tra tính đúng đắn của màn hình, cần xây dựng ít nhất bao nhiêu trường hợp kiểm thử.

Hình 7 4 Chương trình tìm số lớn nhất và nhỏ nhất trong 3 số Các trường 3

Hình 7.4. Chương trình tìm số lớn nhất và nhỏ nhất trong 3 số

Các trường hợp xẩy ra:

- Trường hợp 1: a ≥ b ≥ c: Max=a, Min=c

- Trường hợp 2: a ≥ c ≥ b: Max=a, Min=b

- Trường hợp 3: b ≥ a ≥ c: Max=b, Min=c

- Trường hợp 4: b ≥ c ≥ a: Max=b, Min=a

- Trường hợp 5: c ≥ a ≥ b: Max=c, Min=b

- Trường hợp 6: c ≥ b ≥ a: Max=c, Min=a

Do đó, để kiểm tra màn hình trên cần ít nhất 6 trường hợp (Test case):

- Trường hợp 1: a = 5, b = 4, c = 2

- Trường hợp 2: a = 5 b = 2 c = 4

- Trường hợp 3: b = 5, a = 4, c = 2

- Trường hợp 4: b = 5, a = 2, c = 4

- Trường hợp 5: c = 5, a = 4, b = 2

- Trường hợp 6: c = 5, a = 2, b = 4

b. Phân tích cực biên (Boundary Value Analysis-BVA)

- Là kỹ thuật thiết kế các trường kiểm thử, bổ sung cho phân hoạch cân bằng. Thay vì chọn bất kỳ phần tử nào của lớp cân bằng, BVA lại kiểm thử tại cạnh của lớp.

- Mục đích: Kiểm thử các lỗi nằm ở biên vì một số lớn các lỗi thường nằm tại biên của cái vào hơn là bất kỳ giá trị nào trong tập cân bằng

- Cách thực hiện: Lựa chọn các giá trị cận để kiểm thử

- Nguyên tắc kiểm thử các dữ liệu vào gồm:

+ Giá trị nhỏ nhất

+ Giá trị gần kề lớn hơn giá trị nhỏ nhất

+ Giá trị bình thường

+ Giá trị gần kề nhỏ hơn giá trị lớn nhất

+ Giá trị lớn nhất


- Nguyên tắc chọn dữ liệu thử

+ Nếu dữ liệu vào thuộc một khoảng, chọn

• 2 giá trị biên

• 4 giá trị = giá trị biên ± sai số nhỏ nhất

+ Nếu giá trị vào thuộc danh sách các giá trị, chọn phần tử thứ nhất, phần tử thứ hai, phần tử kế cuối và phần tử cuối.

+ Nếu dữ liệu vào là điều kiện ràng buộc số giá trị, chọn số giá trị tối thiểu, số giá trị tối đa và một số các số giá trị không hợp lệ

+ Tự vận dụng khả năng và thực tế để chọn các giá trị biên cần kiểm thử

Bảng 7.4. Bảng liệt kê các giá trị cận để kiểm thử


Điều kiện

BVA hợp lệ

BVA không hợp lệ




Ví dụ 1: Một Textbox chỉ cho phép nhập số nguyên từ 1 đến 100. Để kiểm tra tính đúng đắn của việc nhập dữ liệu, cần xây dựng ít nhất bao nhiêu trường hợp kiểm thử.

Có 4 trường hợp xẩy ra:

Do đó để kiểm tra màn hình trên cần ít nhất 4 trường hợp Test case 4

Do đó, để kiểm tra màn hình trên cần ít nhất 4 trường hợp (Test case): 0,1,10,101

Mỗi giá trị giới hạn đều nằm trong một phân vùng nào đó. Nếu chỉ sử dụng giá trị giới hạn thì ta cũng có thể kiểm thử luôn phân vùng đó. Tuy nhiên vấn đề đặt ra là nếu như giá trị đó sai thì nghĩa là giá trị giới hạn bị sai hay là cả phân vùng bị sai. Hơn nữa, nếu chỉ sử dụng giá trị giới hạn thì không đem lại sự tin tưởng cho người dùng vì chúng ta chỉ sử dụng những giá trị đặc biệt thay vì sử dụng giá trị thông thường. Vì vậy, cần phải kết hợp cả BVA và EP.

Ví dụ 2: Cho một chương trình nhập các thông tin của tài khoản khách hàng.

Hãy xây dựng các trường hợp kiểm thử cho các thông tin của khách hàng bằng 5


Hãy xây dựng các trường hợp kiểm thử cho các thông tin của khách hàng bằng phương pháp BVA và EP.

- Customer name:

+ Số lượng kí tự:

Kí tự hợp lệ Bất kỳ kí tự nào Account number Kí tự đầu tiên 6

+ Kí tự hợp lệ: Bất kỳ kí tự nào

- Account number

+ Kí tự đầu tiên: valid-non-zero, invalid-zero

+ Số lượng chữ số:

Loan amount Giá trị Bảng 7 5 Các trường hợp xảy ra với EP và BVA Điều kiện 7

- Loan amount: Giá trị

Bảng 7 5 Các trường hợp xảy ra với EP và BVA Điều kiện EP hợp lệ EP không 8

Bảng 7.5. Các trường hợp xảy ra với EP và BVA


Điều kiện

EP hợp lệ

EP không hợp lệ

BVA hợp lệ

BVA không hợp lệ

Customer name:

2-64 chars

<2 chars

>64 chars

2 chars

64 chars

1 char

65 chars

2 chars

Account number

6 digits

1st non-zero

<6 digits

>6 digits 1st digit=0

non- digit

6 digits

5 digits

7 digits

0 digit

Loan

500-9000

<500

500

499

amount


>9000

9000

9001



0





non-integer; null



Bảng 7.6. Các trường hợp kiểm thử với EP và BVA


Trường hợp kiểm thử

Miêu tả

Kết quả dự kiến


1

Name: John Smith Acc no:123456 Loan: 2500

Term: 3 years

Term: 3 years

Repayment: 79.86

Interest rate: 10%

Total paid: 2874.96


2

Name: AB

Acc no:100000 Loan: 500

Term: 1 year

Term: 1 year

Repayment: 44.80

Interest rate: 7.5%

Total paid: 537.60


c. Đoán lỗi (error guess)

- Mục đích: Kiểm tra các lỗi dễ xảy ra

- Cách thực hiện: Dựa trên cơ sở trực giác và kinh nghiệm, kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất

Ví dụ: Nhập số phần tử của mảng nhỏ hơn -1, phép chia cho 0

d. Sơ đồ nguyên nhân - kết quả (Cause – Effect Graphing-CEG)

Đồ thị nguyên nhân – kết quả là một phương pháp thiết kế trường hợp kiểm thử trên cơ sở đưa ra một sự mô tả súc tích các điều kiện logic và các hành vi kèm theo.

Đồ thị nguyên nhân - kết quả sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho thành phần phần mềm. Mỗi nguyên nhân được biểu diễn như một điều kiện (đúng hoặc sai) của một đầu vào, hoặc kết hợp các đầu vào. Mỗi kết quả được biểu diễn như là một biểu thức Bool biểu diễn một kết quả tương ứng cho những thành phần vừa thực hiện.

- Các bước hiện thực

+ Bước 1: Liệt kê các nguyên nhân và kết quả

+ Bước 2: Gán tên cho các nguyên nhân và kết quả

+ Bước 3: Xây dựng đồ thị nguyên nhân - kết quả

+ Bước 4: Chuyển đồ thị thành bảng quyết định

+ Bước 5: Chuyển các quy tắc của bảng quyết định thành các trường hợp kiểm

thử

Bảng 7.7. Các ký hiệu trong đồ thị nguyên nhân – kết quả

Hợp kiểm thử Bảng 7 7 Các ký hiệu trong đồ thị nguyên nhân – kết quả 9

Xem tất cả 305 trang.

Ngày đăng: 28/06/2022
Trang chủ Tài liệu miễn phí