Cac ky thuat kiem thu phan mem

Để tiếp nối phần 1 “các kỹ thuật kiểm thử phần mềm” (tham khảo link http://66.42.54.143/cac-ky-thuat-kiem-thu-phan-mem/ ). Phần 2 này mình sẽ tiếp tục giới thiệu thêm về 3 kỹ thuật kiểm thử khác.

Decision Table Testing (Bảng quyết định)

Một câu hỏi đặt ra là: Chúng ta sẽ áp dụng kỹ thuật kiểm thử nào cho trường hợp kiểm tra logic nghiệp vụ với nhiều điều kiện đầu vào? Khi đó 2 kỹ thuật Phân lớp tương đương và Phân lớp giá trị biên có còn đáp ứng được yêu cầu bài toán?
Do đó chúng ta sẽ cùng nhau đi tìm hiểu thêm một số kỹ thuật kiểm thử hộp đen khác. Đầu tiên là Kỹ thuật Decision Table Testing (Bảng quyết định).Chúng ta sẽ đề cập đến các nội dung dưới đây:

  • Decision Table Testing là gì?
  • Cách tạo bảng quyết định
  • Xác định các bước khi tạo Bảng quyết định
  • Ưu/nhược điểm

Kiểm thử Bảng quyết định là một kỹ thuật kiểm thử phần mềm, được sử dụng để kiểm tra hành vi của hệ thống cho trường hợp kết hợp nhiều yếu tố đầu vào khác nhau.Nơi mà Nguyên nhân và Ảnh hưởng được thu thập để tạo ra phạm vi kiểm tra tốt hơn.

  • Cách tạo bảng quyết định

Chúng ta có ví dụ về màn hình Login với trường Email và Password, bảng quyết định sẽ được tạo ra:

Desicion Table

Chú thích: T – Email và Pass đúng, F – Email và Pass không đúng
Lưu ý: Sau khi tạo xong bảng quyết định nên kiểm tra lại xem các case đã cover được hay chưa
Từ đó ta sẽ có các case kiểm thử
– Case 1: Email và Password đều đúng, login page thành công
– Case 2: Email và Password sai, hiển thị message ”Please enter email”
– Case 3: Email đúng và Password sai, hiển thị message ”Please enter password”
– Case 4: Email sai và Password đúng, hiển thị message “Please enter email”

  • Các bước để tạo Bảng quyết định

B1: Xác định cụ thể các chức năng sử dụng Bảng quyết định
B2: Xác định các trạng thái, sau đó chia chúng thành các tập con và xử lý từng tập con một
B3: Xác định sự kết hợp của True và False

  • Ưu/Nhược điểm

1. Ưu điểm
– Bất kỳ case nào có nghiệp vụ, logic phức tạp được thể hiện bằng sơ đồ cũng sẽ dễ hình dung hơn
– Cung cấp sự tự tin và nhanh chóng về các case kiểm thử
– Cách tạo đơn giản và dễ hiểu
– Trong trường hợp kiểm thử thay đổi có thể dễ dàng tạo lại
2. Nhược điểm
– Trường hợp data đầu vào có quá nhiều điều kiện thì việc xử lý kỹ thuật là không khả quan
– Tiếp theo chúng ta sẽ cũng nhau đi tìm hiểu thêm một kỹ thuật nữa,được sử dụng khá nhiều “Kỹ thuật chuyển đổi trạng thái”

State Transition Testing(Kỹ thuật chuyển đổi trạng thái)

Kỹ thuật chuyển đổi trạng thái là kỹ thuật động, được áp dụng cho trường hợp hệ thống có hữu hạn (có giới hạn nhất định) trạng thái và các trạng thái được điều chỉnh bởi các quy tắc của hệ thống.
Để hiểu rõ hơn chúng ta hãy cùng xem ví dụ sau:
Ví dụ như trường hợp rút thẻ ATM
State-Transition-Diagram
Step 1: Login Screen nếu Password đúng sẽ chuyển qua trạng thái Access(login thành công màn hình account của tài khoản), nếu sai thử lại lần 2
Step 2: Login lần 2 đúng chuyển qua trạng thái Access, nếu sai thử lại lần 3
Step 3: Login lần 3 đúng chuyển qua trạng thái Access, nếu sai se bị Locked và thẻ sẽ bị nuốt.
Ta sẽ có các case tương ứng
State-Transition-Diagram_1
– Case 1: S1->S2->S6 (nhập lần 1 đúng password)
– Case 2: S1->S2->S3->S6 (nhập lần 1 không đúng password)
– Case 3: S1->S2->S3->S4->S6(nhập lần 2 không đúng password)
– Case 4: S1->S2->S3->S4->S5(nhập lần 3 không đúng password)

  • Ưu/Nhược điểm: Kỹ thuật này sẽ giúp chúng ta có cái nhìn tường minh về quá trình chuyển đổi trạng thái của hệ thống. Tuy nhiên không áp dụng được đối với trường hợp các trạng thái ko chuyển đổi một cách tuần tự.

Error Guessing(Kỹ thuật Đoán lỗi)

Kỹ thuật Đoán lỗi là kỹ thuật tìm ra lỗi dựa trên kinh nghiệm của tester. Hay có thể hiểu Tester sẽ kết hợp giữa phân tích và kinh nghiệm của mình để dự đoán khu vực có khả năng xảy ra lỗi.
Khác biệt lớn nhất so với kỹ thuật kiểm thử khác ở chỗ kỹ thuật này dựa trên trải nghiệm của người kiểm thử từ các dự án/nghiệp vụ đã từng trải qua để dự đoán lỗi. Vì vậy kỹ thuật này sẽ không tuân thủ bất kỳ quy tắc cụ thể nào.
Ví dụ như người kiểm thử dự đoán rằng trang login sẽ bị lỗi, họ sẽ đưa ra nhiều phương án kết hợp các dữ liệu khác nhau để kiểm tra chức năng login.

    • Ưu/nhược điểm: Có thể nói kỹ thuật này sẽ bù đắp cho sự không đầy đủ của kỹ thuật phân lớp tương đương và phân tích giá trị biên. Tuy nhiên nó đòi hỏi người kiểm thử có tay nghề cao và nhiều kinh nghiệm.
    • Nguyên tắc thực hiện kỹ thuật
      • Ghi nhớ các khu vực đã từng xảy ra lỗi. Có thể là một lỗi thú vị nào mà ít người để ý đến hay lỗi nào hay một số lỗi phổ biến hay xảy ra bạn có thể note lại.
      • Nâng cao hiểu biết về kỹ thuật: kiểm tra cách viết code như mảng (array), vòng lặp (if/else)…
      • Hiểu kỹ về nghiệp vụ hệ thống bạn test
      • Có thể tìm lỗi trong các yêu cầu, thiết kế của khách hàng…
    • Ngoài ra còn một phương pháp Graph-Based Testing Methods (Phương pháp kiểm tra dựa trên đồ thị), phương pháp này ít được sử dụng do đó mình xin phép không để cập đến trong bài viết này. Các bạn có thể tham khảo tại link https://www.softwaretestinghelp.com/black-box-testing/

Kết luận

  • Để bộ test case của bạn hoàn hảo, bạn cần lựa chọn phương pháp kiểm thử phù hợp. Việc kiểm thử giúp cung cấp phần mềm, ứng dụng có chất lượng tốt nhất, đảm bảo ít bug nhất trước khi đưa đến tay người sử dụng.

Tài liệu tham khảo

  • Ngoài ra các bạn có thể tham khảo hướng dẫn chi tiết các kỹ thuật kiểm thử phần mềm qua video

  • https://www.softwaretestinghelp.com/black-box-testing/

Bài viết không thể tránh khỏi có sai sót, rất mong nhận được góp ý từ phía quý bạn đọc. Hãy nhớ theo dõi ITMS Coaching để đón nhận các bài tiếp theo các bạn nhé! Many Thanks.

Xem thêm:

Quy trình kiểm thử phần mềm (Software Testing Life Cycle)

Tổng hợp quy trình kiểm thử website

API Testing với POSTMAN

Leave a Reply

Your email address will not be published. Required fields are marked *