24/05/2018, 21:57

Test và kiểm tra

Có 2 hướng tiếp cận cơ bản khi kiểm thử phần mềm là: test – to – pass và test – to – fail . Khi bạn test – to – pass , bạn thực sự chỉ đảm bảo được rằng phần mềm thực hiện được các chức năng tối thiểu. Bạn đừng cố thúc đẩy những khả năng ...

Có 2 hướng tiếp cận cơ bản khi kiểm thử phần mềm là: test – to – passtest – to – fail. Khi bạn test – to – pass, bạn thực sự chỉ đảm bảo được rằng phần mềm thực hiện được các chức năng tối thiểu. Bạn đừng cố thúc đẩy những khả năng của nó. Bạn không biết rằng bạn có thể làm hỏng nó. Bạn xem xét nó với một kid gloves, áp dụng những testcase đơn giản nhất và rõ ràng nhất.

Bạn có thể đang nghĩ rằng, nếu như mục đích của bạn là tìm ra lỗi, tại sao bạn lại lựa chọn test – to – pass? Bạn có nghĩ rằng bạn muốn tìm lỗi bằng một vài phương tiện có khả năng thực hiện được không? Câu trả lời là không.

Hãy nghĩ về sự tương đồng với một bản thiết kế xe car mới (hình 4.1). Bạn được giao nhiệm vụ kiểm tra phiên bản đầu tiên mà bạn thì chưa từng lái xe bao giờ. Có lẽ bạn sẽ lái nó với tốc độ lớn nhất mà nó đạt được. Và có thể bạn sẽ bị đâm và chết. Với một chiếc xe car mới, có thể có tất cả các loại lỗi mà nó bộc lộ ra khi lái với tốc độ dưới mức bình thường. Có lẽ là những cái lốp xe có kích cỡ không đúng, hoặc những cái phanh không tương xứng, hoặc là bộ máy quá lớn. Bạn có thể phát hiện ra những vấn đề này và sửa chúng trước khi tung ra thị trường.

Sử dụng test – to – pass để khám phá lỗi trước khi test – to – fail

Chú ý: Khi thiết kế và chạy các test case, luôn luôn phải chạy trường hợp test – to – pass trước. Đây là điều quan trọng để kiểm tra những chức năng cơ bản của phần mềm trước khi bạn lún sâu vào nó. Bạn có thể sẽ phải ngạc nhiên về cái cách mà bạn tìm thấy rất nhiều lỗi khi sử dụng phần mềm một cách thông thường.

Sau khi bạn kiểm tra những chức năng cơ bản, lúc này, bạn hãy kiểm tra những trường hợp lắt léo, bí ẩn, và cố gắng để bắt các lỗi. Thiết kế và chạy các test case với mục đích duy nhất là tìm ra lỗi thì được gọi là testing – to – fail hoặc error – forcing. Bạn sẽ được tìm hiểu trong bài này. Trường hợp test – to – fail thường không dễ dàng xuất hiện. Thường thì nhìn chúng cũng giống như các trường hợp test – to – pass, nhưng chúng được lựa chọn để thăm dò những điểm yếu phổ biến trong phần mềm.

CÁC THÔNG ĐIỆP VỀ LỖI: TEST – TO – PASS HOẶC TEST – TO – FAIL:

Một lớp các test case phổ biến cố gắng để bắt các lỗi. Các trường hợp này thực sự là nằm giữa 2 trường hợp test – to – pass và test – to – fail. Có lẽ bản đặc tả đã mô tả chắc chắn rằng với điều kiện đầu vào như vậy sẽ đưa ra kết quả là một thông báo lỗi. Dường như nó cũng rõ ràng như trường hợp test – to – pass. Nhưng bạn cũng sẽ bắt được một lỗi, vì vậy nó có thể được gọi là test - to – fail. Cuối cùng, có thể gọi theo cả 2 cách đều được.

Đừng lo lắng về sự tương phản này. Cái quan trọng là cố gắng để bắt được lỗi và xây dựng các test case về các vấn đề chưa từng được xem xét tới.

Lựa chọn các test case là một nhiệm vụ vô cùng quan trọng mà một tester phải thực hiện và equivalence partitioning, đôi khi được gọi là equivalence classing, có nghĩa là cái mà chúng ta phải làm. Equivalence partitioning là quá trình làm giảm số lượng các test case nhưng vẫn đảm bảo đạt được hiệu quả tương đương như khi kiểm thử với số lượng các test case cũ.

Hãy nhớ lại ví dụ về Windows calculator ở phần trước. Bạn không thể kiểm tra được tất cả các trường hợp với các cặp số. Equivalence partitioning cung cấp một phương tiện có hệ thống cho việc lựa chọn những giá trị quan trọng và bỏ qua những cái không cần thiết.

Ví dụ, Nếu bạn không biết gì hơn về Equivalence partitioning, bạn sẽ nghĩ rằng nếu kiểm tra trường hợp 1+1, 1+2, 1+3 và 1+4 thì bạn cũng cần kiểm tra trường hợp 1+5 và 1+6? Bạn có thừa nhận về cách kiểm an toàn như vậy không?

Còn về 1+99999999999999999999999999999999 (số lớn nhất bạn có thể gõ vào) thì sao? Có phải test case này chỉ khác một chút so với những những trường hợp khác, có thể nó thuộc lớp khác, một Equivalence partition khác? Nếu bạn có quyền lựa chọn, bạn sẽ chọn trường hợp này hay 1+13?

Bạn hãy nhìn và sẵn sàng suy nghĩ giống như một tester!

Chú ý: Một lớp tương đương (equivalence class) hoặc một phân vùng tương đương (equivalence partition) là một tập các test case kiểm tra những trường hợp tương tự nhau hoặc để khám phá ra những lỗi tương tự nhau.

Sự khác nhau giữa 1+99999999999999999999999999999999 và 1+13 là gì? Trường hợp 1+13 là một phép cộng chuẩn, đơn giản, cũng giống như 1+5 hay 1+329. Tuy nhiên, 1+99999999999999999999999999999999 là trường hợp sắc bén hơn. Nếu bạn nhập vào một số lớn nhất có thể, và sau đó cộng thêm 1 vào nó. Điều này có thể dẫn đến một lỗi. Những trường hợp dữ liệu đạt ngưỡng như vậy được đưa vào một phân vùng duy nhất (unique partition), khác với các phân vùng thông thường chứa các số theo quy tắc nào đó.

Chú ý: Khi tìm kiếm những equivalence partition, hãy nghĩ cách để nhóm những dữ liệu đầu vào tương tự nhau, dữ liệu đầu ra tương tự nhau, và những điều khiển tương tự của phần mềm. Những nhóm này sẽ là một equivalence partition của bạn

Hãy xem một vài ví dụ dưới đây:

  • Trong trường hợp cộng một cặp số, có sự khác nhau giữa việc kiểm tra 1+13 và 1+99999999999999999999999999999999. Có thể gọi nó là một gut feeling, nhưng dường như các trường hợp này chứa đầy rủi ro. Gut feeling này là đúng. Chương trình phải xem xét việc cộng 1 với số lớn nhất hơn khác gì so với việc cộng 2 số nhỏ. Cần xem xét xem nó có bị tràn bộ nhớ không? Hai trường hợp, mà phần mềm có cách điều khiển khác nhau, nằm trong 2 equivalence partition khác nhau.
    • Nếu bạn có một chút kinh nghiệm lập trình, bạn có thể nghĩ ra một số trường hợp đặc biệt mà có thể khiến phần mềm phải hoạt động khác đi. Nếu bạn không phải là một lập trình viên thì cũng đừng lo lắng, bạn sẽ được tìm hiểu những kỹ thuật rất đơn giản và có thể áp dụng chúng mà không cần phải hiểu về code.
  • Hình 4.3 miêu tả menu Edit của Calculator được lựa chọn để thực hiện thao tác copy paste. Có 5 cách để thực hiện mỗi chức năng này. Để copy, bạn hãy click vào mục copy của menu, gõ c hoặc C khi menu được hiển thị, hoặc nhấn Ctrl+c hoặc Ctrl+C. Với mỗi dữ liệu vào, phần mềm sẽ copy số hiện tại vào clipboard, và thự thi yêu cầu, sau đó, dữ liệu được đưa ra đều như nhau với các trường hợp.
    • Nếu công việc của bạn là kiểm tra lệnh copy, bạn có thể phân chia 5 cách thực hiện lệnh này thành 3 lớp: click vào item này trên menu, gõ c, hoặc Ctrl+c. Bạn sẽ tin tưởng hơn với chất lượng phần mềm và biết được rằng chức năng copy làm việc rất hợp lý. Thậm chí là bạn phân chia chúng thành một phân vùng đơn giản, có thể là Ctrl+c.

Có nhiều cách để thực hiện chức năng copy và tất cả đều đưa ra kết quả như nhau.

  • Ví dụ thứ 3, hãy xem xét khả năng đưa một file name vào hộp thoại Save As chuẩn (hình 4.4).

Ô Textbox File Name trong hộp thoại Save As minh họa cho một vài khả năng của equivalence partition

  • Một filename của Windows của thể chứa các ký tự, ngoại trừ / : * ? " < > và |. Các filename có thể có từ 1 đến 25 ký tự. Nếu bạn tạo ra các test case để kiểm thử trường hợp này, bạn sẽ có những equivalence partition với những ký tự hợp lý, ký tự không hợp lý, những cái tên với độ dài hợp lý, những cái tên quá ngắn hoặc những cái tên quá dài.

Hãy nhớ lại, mục đích của equivalence partitioning là làm giảm bớt số lượng các test case mà vẫn đảm bảo nó thỏa đáng yêu cầu kiểm thử. Bạn đang phải có trách nhiệm về sự rủi ro bởi vì bạn sẽ không kiểm thử tất cả mọi thứ, vì vậy mà bạn cần phải cẩn thận để lựa chọn cách phân chia lớp.

Chú ý: Nếu việc phân chia lớp vượt quá những cố gắng của bạn, những trường hợp bị loại trừ khỏi quá trình kiểm thử cũng có thể chứa lỗi. Nếu bạn là một người mới trong lĩnh vực kiểm thử, bạn hãy nhờ một người có nhiều kinh nghiệm hơn để họ duyệt lại những lớp tương đương mà bạn đề xuất.

Điểm quan trọng cuối cùng về equivalence partitioning là sự phân chia này mang tính chủ quan. Nó vừa mang tính khoa học vừa mang tính nghệ thuật. Hai tester kiểm thử một chương trình phức tạp thì chúng ta sẽ có 2 tập các partition khác nhau. Sau khi các phân vùng được phân chia đã được duyệt và mọi người đồng ý chấp nhận toàn bộ phần mềm đã được kiểm thử.

Luồng điều khiển là một kỹ thuật testing căn bản, sử dụng sơ đồ luồng xử lý (control flow graph). Đó là sơ đồ mô hình hoá hành vi của hệ thống, chứ không phải là sơ đồ mô tả các câu lệnh trong code. Áp dụng được cho hầu hết các phần mềm, và có hiệu quả. Và áp dụng được trong mọi giai đoạn (testing stages).

Sơ đồ luồng xử lý

  • Áp dụng cho các hệ thống “data-intensive”
  • Ví dụ các hệ thống sản sinh báo cáo, thống kê.
  • Ví dụ các hệ thống có tính toán thay đổi số liệu.
  • Phương pháp xây dựng test case:
  • Lập sơ đồ luồng dữ liệu (Data flow diagram)
  • Lần theo từng đường dẫn trong sơ đồ
  • Bắt đầu từ node output
  • Lần ngược lại tới khi gặp node input
  • Ta đã được một test case
  • Áp dụng cho các hệ thống xử lý giao dịch (như đặt vé máy bay, đặt phòng khách sạn, …)
  • Sử dụng mô hình xử lý của hệ thống, chú trọng đến điểm bắt đầu, điểm kết thúc của từng xử lý, chú trọng tới hàng đợi (queue)
0