Kiểm thử phần mềm: Các kỹ thuật thiết kế kiểm thử (Phần 2).

Tiếp tục series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Tiếp nối bài viết trước Kiểm thử phần mềm: Các kỹ thuật thiết kế kiểm thử (Phần 1). bài viết lần này mình sẽ giới thiệu với các bạn Các loại kỹ thuật thiết kế kiểm thử - Kiểm thử hộp đen (Black box).

1. Giới thiệu.

Có nhiều loại kỹ thuật kiểm thử phần mềm mỗi loại đều có điểm mạnh điểm yếu riêng. Mỗi kỹ thuật đều có điểm mạnh khi tìm ra các loại lỗi cụ thể và tương đối kém khi tìm ra một loại khác. Kiểm thử được thực hiện ở các giai đoạn khác nhau của vòng đời phát triển phần mềm sẽ tìm ra các loại lỗi khác nhau, kiểm thử thành phần có nhiều khả năng tìm thấy các lỗi logic trong việc mã hóa hơn so với các lỗi bên thiết kế hệ thống.

Có 2 loại kỹ thuật chính là kiểm thử tĩnh và kiểm thử động, các kỹ thuật tĩnh đã giới thiệu ở chương 3 rồi còn các kỹ thuật động được chia thành 3 loại khác nhau: dựa trên chi tiết kỹ thuật-specification-based (Hộp đen còn được gọi là kỹ thuật hành vi), dựa trên cấu trúc- structure-based (Hộp trắng hoặc kỹ thuật thuộc về kiến trúc) và dựa trên kinh nghiệm- experience-based.

2. Kỹ thuật dựa trên các đặc tả kỹ thuật (kỹ thuật hộp đen-Blackbox).

Kiểm tra hộp đen (Black box testing) là một phương pháp kiểm thử phần mềm mà việc kiểm tra các chức năng của một ứng dụng không cần quan tâm vào cấu trúc nội bộ hoặc hoạt động của nó. Mục đích chính của kiểm tra hộp đen chỉ là để xem phần mềm có hoạt động như dự kiến trong tài liệu yêu cầu và liệu nó có đáp ứng được sự mong đợi của người dùng hay không.

Đặc điểm

• Đây là kiểu kiểm thử thành phần phần mềm và chỉ dựa vào các thông tin đặc tả về yêu cầu, chức năng của các thành phần phần mềm tương ứng.
• Việc kiểm thử được thực hiện bên ngoài, không liên quan đến lập trình viên hay các nhà phát triển phần mềm. Vì thế người kiểm thử cũng không cần thiết phải biết về cấu trúc bên trong của phần mềm cũng như các kiến thức về lập trình.
• Mức test này thường yêu cầu các tester phải viết test case đầy đủ trước khi test; Các bước tiến hành test khá đơn giản, chỉ cần thực hiện theo các mô tả trong test case, thực hiện nhập dữ liệu vào, đợi kết quả trả về và so sánh với kết quả dự kiến trong test case.

Trong phần này, chúng ta sẽ làm quen với các thuật ngữ: phân tích giá trị biên(boundary value analysis) , kiểm thử bảng quyết định (decision table testing), phân vùng tương đương(equivalence partitioning), kiểm tra chuyển tiếp trạng thái(state transition testing) và kiểm tra ca sử dụnguse case testing.
Có 4 kỹ thuật dựa trên các đặc tả kỹ thuật:

• Phân vùng tương đương (equivalence partitioning)
• Phân tích giá trị biên(boundary value analysis)
• Bảng quyết định (decision tables)
• Kiểm thử chuyển đổi trạng thái (state transition testing).

2.1. Phân vùng tương đương(equivalence partitioning).

Phân vùng tương đương: là phương pháp kiểm thử hộp đen chia miền đầu và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ử. Tất cả các giá trị trong một vùng tương đương sẽ cho một kết quả đầu ra giống nhau. Vì vậy chúng ta có thể test một giá trị đại diện trong vùng tương đương.
Thiết kế test case bằng phân vùng tương đương tiến hành theo hai bước: xác định các lớp tương đương, xác định các trường hợp kiểm thử.

• Xác định lớp tương đương:
• Lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu vào và chia nó thành 2 hay nhiều nhóm.
• Điều kiện đầu vào: vùng tương đương hợp lệ và vùng tương đương không hợp lệ.
  Vùng tương đương hợp lệ: là mô tả các đầu vào hợp lệ của chương trình, vùng tương đương không hợp lệ: là mô tả các trạng thái của chương trình như sai, thiếu…
• Nguyên tắc xác định vùng tương đương:
  • Nếu điều kiện đầu vào định rõ giới hạn của một mảng thì chia vùng tương đương thành 3 tình huống: xác định một vùng tương đương hợp lệ, 2 vùng tương đương không hợp lệ.
  • Nếu điều kiện đầu vào chỉ định là một tập giá trị thì chia vùng tương đương thành 2 tình huống: một vùng hợp lệ và một vùng không hợp lệ.
  • Nếu điều kiện đầu vào xác định là một kiểu đúng sai thì chia vùng tương đương thành 2 tình huống: một vùng hợp lệ và một vùng không hợp lệ.

Ví dụ: Thiết kế test case nhập vào ô textbox số tiền chỉ cho nhập ký tự là số với độ dài trong khoảng [0-10]

Dựa vào yêu cầu bài toán ta có thể có các lớp tương đương(phân vùng) sau:
Phân vùng 1: Nhập giá trị hợp lệ từ 0=> 10 ký tự
Phân vùng 2: Nhập giá trị không hợp lệ < 0 ký tự
Phân vùng 3: Nhập giá trị không hợp lệ > 10 ký tự
Phân vùng 4: Trường hợp để trống không nhập gì hay nhập ký tự không phải dạng số

Sau khi áp dụng phân vùng tương đương có thể chọn được các ca kiểm thử (test case) sau:
Case 1: Nhập giá trị từ 0 => 10 (có thể chỉ nhập số 5)=> pass
Case 2: Nhập giá trị < 0 (có thể chỉ nhập số -5) => hiển thị lỗi
Case 3: Nhập giá trị > 10 => hiển thị lỗi
Case 4: Để trống không nhập gì hay nhập ký tự không phải dạng số => hiển thị lỗi

• Ưu điểm:
  • Do mỗi vùng tương đương chỉ cần test trên các phần tử đại diện nên số lượng testcase được giảm đi khá nhiều nhờ đó mà thời gian thực hiện test cũng giảm đáng kể.
  • Toàn bộ yêu cầu của hệ thống được kiểm thử chính xác.
  • Các tester có thể không cần phải là biết về IT
• Nhược điểm:
  • Có thể bị sót lỗi ở những giá trị biên.
  • Dữ liệu đầu vào yêu cầu một khối lượng mẫu (sample) khá lớn.
  • Khó viết kịch bản kiểm thử do cần xác định tất cả các yếu tố đầu vào, và thiếu cả thời gian cho việc tập hợp này.

2.2. Phân tích giá trị biên(Boundary value analysis (BVA)).

Đây là phương pháp test mà chúng ta sẽ test tất cả các giá trị ở vùng biên của dữ liệu vào và dữ liệu ra. Nếu dữ liệu đầu vào được sử dụng là trong giới hạn giá trị biên, nó được cho là Positive testing. Nếu dữ liệu đầu vào được sử dụng là ngoài giới hạn giá trị biên, nó được cho là Negative testing.

Phân tích giá trị biên sẽ chọn các giá trị:

• Giá trị nhỏ nhất

• Giá trị ngay trên giá trị nhỏ nhất

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

• Giá trị ngay dưới giá trị lớn nhất

• Giá trị lớn nhất

• Ưu điểm:
  Thay vì phải test hết toàn bộ các giá trị trong từng vùng tương đương, kỹ thuật phân tích giá trị biên tập trung vào việc kiểm thử các giá trị biên của miền giá trị đầu vào để thiết kế test case do “lỗi thường tiềm ẩn tại các ngõ ngách và tập hợp tại biên”. Tiết kiệm thời gian thiết kế test case và thực hiện test.

• Nhược điểm: Phương pháp này chỉ hiệu quả trong trường hợp số đầu vào (input variables) độc lập với nhau và mỗi đối số đều có một miền giá trị hữu hạn.

2.3. Bảng quyết định (Decision tables )

Bảng quyết định sử dụng mô hình các quan hệ logic giữa nguyên nhân và kết quả cho các thành phần. 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.
Sử dụng bảng quyết định trong thiết kế kiểm thử bao gồm các bước sau:

• Xác định một chức năng phù hợp hoặc hệ thống con mà có sự kết hợp của các yếu tố đầu vào

Chúng ta đi xem xét ví dụ: ứng dụng vay tiền, có thể nhập số tiền trả nợ hàng tháng hoặc số năm muốn vay (thời hạn của khoản vay). Nếu nhập vào cả hai, hệ thống sẽ tạo sự thỏa hiệp giữa hai vấn đề nếu chúng xung đột. Hai điều kiện là số tiền trả hàng tháng và thời hạn vay, vì vậy ta đặt chúng trong một bảng.

Bảng 4.1. Xác định các điều kiện.

• Xác định tất cả các kết hợp các điều kiện.
  Phải tính toán bao nhiêu cột trong bảng số lượng các cột phụ thuộc vào các điều kiện và số lượng các lựa chọn thay thế cho mối điều kiện. Nếu có 2 điều kiện và từng điều kiện có thể là đúng hoặc sai cần 4 cột = 2^2
  

Bảng 4.2. Kết hợp các điều kiện

• Xác định kết quả chính xác cho mỗi sự kết hợp. Trong ví dụ này chúng ta có thể nhập vào một hoặc cả hai trường, mỗi sự kết hợp là một quy luật
  

Bảng 4.3. Bảng quyết định với sự kết hợp của các điều kiện và kết quả.

• Xác định những case bị thiếu sót.
  Trong ví dụ này chúng ta có thể thấy được trường hợp nếu khách hàng không nhập thông tin ở một trong hai trường thì sẽ xảy ra điều gì.

Bảng 4.4. Bảng quyết định với kết quả bổ sung.

• Thực hiện thay đổi điều kiện: không cho phép nhập cả 2 điều kiện trên cùng lúc. Kết quả của bảng sẽ thay đổi, thông báo lỗi nếu cả 2 điều kiện được nhập vào.
  

Bảng 4.5. Bảng quyết định với sự thay đổi kết quả.

• Mỗi hành động xảy ra cho mỗi sự kết hợp các điều kiện, chúng ta có thể liệt kê các hành động trong ô thành một hàng. Nhưng đối với những kết hợp có nhiều kết quả nên hiển thị thành từng hàng riêng biệt.
  

Bảng 4.6. Bảng quyết định trên một hàng.

• Bước cuối cùng là viết các test case cho các trường hợp kết hợp điều kiện từ kết quả của các bảng điều kiện trên.

2.4. Kiểm thử chuyển đổi trạng thái(State transition testing)

Kiểm thử chuyển đổi trạng thái được sử dụng khi một số khía cạnh của hệ thống được mô tả trong máy hữu hạn các trạng thái(finite state machine). Có thể hiểu là các hệ thống có thể nằm trong số (hữu hạn) các trạng thái và sự chuyển tiếp từ trạng thái này sang trạng thái khác được xác định bởi các quy tắc máy. Một hệ thống trạng thái hữu hạn thường được biểu diễn dưới dạng sơ đồ trạng thái (state diagram).

Một mô hình chuyển đổi trạng thái có 4 phần cơ bản sau:

• Các trạng thái mà phần mềm có thể giữ (đóng/mở hoặc không đủ số dư, tài khoản hết hạn…).
• Sự chuyển từ trạng thái này sang trạng thái khác( không phải tất cả quy trình chuyển đổi đều được cho phép).
• Các sự kiện gây ra sự chuyển đổi ( đóng file hoặc rút tiền).
• Kết quả của các hành động từ quá trình chuyển đổi ( thông báo lỗi hoặc đưa tiền mặt )

Chú ý rằng trong một trạng thái một sự kiện chỉ có thể gây ra một hành động duy nhất. Tuy nhiên cùng với sự kiện đó mà xảy ra ở trạng thái khác sẽ cho ra các hành động khác và trạng thái kết thúc khác nhau.

Hình 4.1. Cho một ví dụ về nhập mã PIN ở cây ATM. Các trạng thái được thể hiện ở dạng hình tròn. Các phiên chuyển đổi là các mũi tên. Các event là dòng text cạnh mũi tên:

Hình 4.1. Sơ đồ trạng thái của việc nhập mã PIN.

Từ sơ đồ trạng thái, tiến hành tạo test case bắt đầu từ việc xác định các kịch bản (scenario).

• Trường hợp 1: khi mà mã PIN được nhập đúng ngay ở lần đầu tiên.
• Trường hợp 2: nhập sai mã PIN ở cả lần 1, lần 2 và lần 3.
• Các trường hợp tiếp theo sẽ kiểm thử trường hợp với từng trạng thái ví dụ như nhập đúng ở lần đầu tiên, sai ở lần thứ 2 hoặc sai ở 2 lần đầu và đúng ở lần thứ 3. Một trạng thái có thể được nhìn nhận như một điều kiện test hoặc mỗi một phiên chuyển đổi sẽ được nhìn nhận như một điều kiện test.

Tiếp theo, Để xem có bao nhiêu tổng số kết hợp các trạng thái và quá trình chuyển đổi cả 2 trạng thái hợp lệ và không hợp lệ cần phải có một bảng trạng thái.

Hình 4.2. Ví dụ bảng trạng thái của nhập mã PIN.

Bảng 4.2 liệt kê các trạng thái trong cột thứ nhất, các đầu vào có thể ở hàng đầu. Nếu hệ thống đang ở trạng thái 1, inserting a card sẽ chuyển đổi sang trạng thái 2. Nếu đang ở trạng thái 2 và đã nhập Valid PIN sẽ chuyển sang trạng thái 6, Nếu đang ở trạng thái 2 và đã nhập Invalid PIN sẽ chuyển sang trạng thái 3.

2.5. Kiểm thử các trường hợp sử dụng(Use case testing).

Use case testing là một kỹ thuật xác định các test case mô tả từ đầu đến cuối hành vi của hệ thống từ góc nhìn của người sử dụng. Use case mô tả sự tương tác đặc trưng giữa người dùng bên ngoài (Actor) và hệ thống. Mỗi Use case sẽ mô tả cách thức người dùng tương tác với hệ thống để đạt được mục tiêu nào đó. Ngoài ra, Use case cũng xác định trình tự các bước mô tả mọi tương tác giữa người dùng và hệ thống.
Mô tả hoạt động của usecase thì người ta thường dùng Workflow hoặc mô hình activity, UML.
Các thành phần của use case:

• Tác nhân (Actor): Người dùng hoặc đối tượng nào đó tương tác với hệ thống.
• Brief description: Mô tả ngắn gọn giải thích các trường hợp
• Precondition: Là các điều kiện được thỏa mãn trước khi bắt đầu thực hiện
• Basic flow: là những luồng cơ bản trong hệ thống. Đó là luồng giao dịch được thực hiện bởi người dùng để hoàn thành mục đích của họ. Khi người dùng tương tác với hệ thống, vì đó là workflow bình thường nên sẽ không có bất kì lỗi nào xảy ra và người dùng sẽ nhận được đầu ra như mong đợi.
• Alternate flow: Ngoài workflow thông thường, hệ thống cũng có thể có workflow thay thế. Đây là tương tác ít phổ biến hơn được thực hiện bởi người dùng với hệ thống
• Exception flow: Là các luồng ngăn cản người dùng đạt được mục đích của họ
• Post conditions: Các điều kiện cần được kiểm tra sau khi hoàn thành.

Trong ví dụ nêu trên mỗi use case là một kịch bản scenario và phần mở rộng (thể hiện các kịch bản có thể không thành công). Đối với kiểm thử use case, có một kịch bản của kiểm thử thành công và một kiểm thử cho mỗi phần mở rộng

Hình 4.3. Một phần use case cho phần nhập mã PIN.

Trên đây là một số kỹ thuật thường được sử dụng trong kiểm thử dựa trên các đặc tả kỹ thuật (Black box).

Link bài viết tiếp theo Các kỹ thuật thiết kế kiểm thử (Phần 3).