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 2). 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 trắng(White box) và kiểm thử dựa trên kinh nghiệm.

1. Các kỹ thuật dựa trên cấu trúc/kiến trúc của hệ thống (Kiểm thử hộp trắng-Blackbox).

Kiểm thử hộp trắng là loại thử nghiệm được thực hiện để kiểm tra cấu trúc code. Loại thử nghiệm này đòi hỏi người test phải có kiến thức về code. Do đó, phần lớn là do các lập trình viên, nhà phát triển phần mềm thực hiện.

Đặc điểm

• Kiểm thử hộp trắng quan tâm đến việc hệ thống vận hành như thế nào chứ không phải chứ năng của hệ thống. Vì nó dựa vào những thuật toán cụ thể, vào những cấu trúc dữ liệu bên trong của thành phần phần mềm.
• Trong kỹ thuật kiểm thử này, đòi hỏi người tester phải có kiến thức và kỹ năng nhất định về ngôn ngữ lập trình được dùng, hiểu thuật toán trong phần mềm, để có thể hiểu được chi tiết về đoạn code cần kiểm thử .
• Mức test này thường yêu cầu các tester phải viết test case đầy đủ các nhánh trong code; khi test, sẽ set điều kiện và data để chạy vào đủ tất cả các nhánh trong thuật toán, đảm bảo thực hiện đầy đủ.

Kiểm thử hộp trắng được dùng để đo độ bao phủ( coverage ) và kiểm thử thiết kế(Design test).
Bao phủ kiểm thử(test coverage ) là tỉ lệ (tính theo %) test case đã được thực hiện trên tổng số test case cần thiết cho phần mềm. Nếu tỉ lệ này càng cao thì phần mềm càng được test kỹ. Mặc dù việc đảm bảo phần mềm có test coverage là 100% nhưng không có nghĩa là 100% các trường hợp được kiểm thử. Độ bao phủ được tính bằng công thức sau:

Có nghĩa là độ bao phủ = Số item bao phủ được thực hiện/ Tổng số item bao phủ * 100%

Có 2 loại điều kiện bao phủ cơ bản: Bao phủ code(Code coverage), Bao phủ chức năng(function coverage).

• Code coverage Là phương pháp thống kê dựa vào số lương code được kiểm tra. Trong code coverage có thể phần chia thành các loại sau:
• Bao phủ dòng lệnh(Statement coverage)
• Bao phủ các nhánh (Branch/Decision coverage)
• Bao phủ điều kiện (Condition coverage)
• Bao phủ đường dẫn (Path coverage)

Kiểm thử hộp trắng có 2 hoạt động chính: kiểm thử luồng điều khiển(control flow testing) và kiểm thử luồng dữ liệu(data flow testing).

• Kiểm thử luồng điều khiển: là một chiến lược trong kiểm thử cấu trúc nó sử dụng luồng điều khiển của chương trình như một mô hình. Nó dựa vào việc lựa chọn một tập các đường dẫn kiểm tra thông qua chương trình. Tập các đường dẫn đã chọn được sử dụng để đạt được một số đo nhất định của việc kiểm thử cẩn thận.
• Kiểm thử luồng dữ liệu: là một nhóm các chiến lược kiểm tử dựa trên việc chọn các đường dẫn thông qua luồng điều khiển của chương trình để khám phá chuỗi các sự kiện liên quan đến trạng thái của các biến hoặc các đối tượng dữ liệu. Kiểm tra Dataflow tập trung vào các điểm mà tại đó các biến nhận giá trị và các điểm mà tại đó các giá trị này được sử dụng.
• Ưu điểm
• Test có thể bắt đầu ở giai đoạn sớm hơn, không cần phải chờ đợi cho GUI để có thể test
• Test kỹ càng hơn, có thể bao phủ hầu hết các đường dẫn
• Thích hợp trong việc tìm kiếm lỗi và các vấn đề trong mã lệnh
• Cho phép tìm kiếm các lỗi ẩn bên trong
• Các lập trình viên có thể tự kiểm tra
• Giúp tối ưu việc mã hoá
• Do yêu cầu kiến thức cấu trúc bên trong của phần mềm, nên việc kiểm soát lỗi tối đa nhất.
• Nhược điểm
• Vì các bài kiểm tra rất phức tạp, đòi hỏi phải có các nguồn lực có tay nghề cao, với kiến thức sâu rộng về lập trình và thực hiện.
• Maintenance test script có thể là một gánh nặng nếu thể hiện thay đổi quá thường xuyên.
• Vì phương pháp thử nghiệm này liên quan chặt chẽ với ứng dụng đang được test, nên các công cụ để phục vụ cho mọi loại triển khai / nền tảng có thể không sẵn có.

2. Kỹ thuật dựa trên kinh nghiệm (EXPERIENCE-BASED TECHNIQUES)

Có 4 kỹ thuật dựa trên kinh nghiệm: Đoán lỗi(Error guessing), Kiểm thử thăm dò(Exploratory testing), kiểm thử dựa trên checklist(Checklist based testing), (Attack testing). Nhưng ở bài viết này mình chỉ giới thiệu 2 kỹ thuật: Đoán lỗi(Error guessing), Kiểm thử thăm dò(Exploratory testing)

2.1. Đoán lỗi(Error guessing).

Đoán lỗi(error guessing) là một phương pháp kiểm thử, trong đó các trường hợp kiểm thử được sử dụng để tìm lỗi trong các phần mềm dựa vào kinh nghiệm trong các lần kiểm thử trước của người kiểm thử (tester). Việc đoán lỗi thành công phụ thuộc rất nhiều vào kỹ năng của người kiểm thử, một người kiểm thử giỏi có thể biết được nơi nào có nhiều lỗi tiềm ẩn.

Đoán Lỗi không có quy tắc rõ ràng để kiểm thử, test case có thể được thiết kế tùy thuộc vào tình hình, hoặc hoặc luồng công việc trong các tài liệu mô tả chức năng hoặc khi một lỗi không mong muốn / không được mô tả trong tài liệu được tìm thấy trong khi hoạt động kiểm thử. các điều kiện điển hình để kiểm thử bao gồm chia cho số 0, để trống đầu vào, file rỗng và kiểu dữ liệu sai.

Các yếu tố được sử dụng để đoán lỗi:

• Kinh nghiệm từ những lần kiểm thử trước.
• Những khuyết thiếu (defect) trước.
• Xem lại những trường hợp đã kiểm thử.
• Giao diện người dùng.
• Kết quả của những lần test trước.
• Dựa vào những báo cáo về rủi ro của hệ thống hoặc của phần mềm.
• Dựa vào các loại dữ liệu được sử dụng để test.

Mặc dù, đoán lỗi là một trong những kỹ thuật chính trong kiểm thử nhưng không bao quát đầy đủ được hệ thống, cũng không thể đảm bảo hệ thống đạt được chất lượng như mong đợi. Do vậy nên kết hợp với các kỹ thuật khác để mang lại hiệu quả tốt hơn.

2.2. Kiểm thử thăm dò(Exploratory testing).

Đối với kiểm thử thông thường, theo kịch bản có sẵn, bạn sẽ thiết kế test case trước, sau đó tiến hành thực hiện kiểm thử. Ngược lại, kiểm thử thăm dò là việc thực hiện đồng thời thiết kế và thực hiện kiểm thử.

Kiểm thử thăm dò bao gồm tất cả các việc như: phát hiện lỗi, điều tra lỗi, sự hiểu biết về ứng dụng. Điều này chú trọng vào sự tự do cá nhân và trách nhiệm của từng nhân viên. Test cases có thể không được tạo hoàn chỉnh nhưng người thực hiện vẫn có thể kiểm tra hệ thống một cách nhanh chóng. Họ có thể ghi lại ngắn gọn những gì mình cần làm trước khi thực hiện kiểm thử. Kiểm thử thăm dò tập trung nhiều hơn vào việc thực hiện kiểm thử hơn là tạo test cases.

Kiểm thử thăm dò :

• Không phải là kiểm thử ngẫu nhiên nhưng nó là kiểm thử mang tính bột phát với mục đích tìm được các lỗi.
• Có cấu trúc và chặt chẽ.
• Dễ dàng quản lý.
• Không phải là một kĩ thuật nhưng là một phương pháp tiếp cận. Những hành động bạn thực hiện tiếp theo được điều chỉnh bởi những gì bạn đang làm.

Một khía cạnh quan trọng của kiểm thử thăm dò là học hỏi: học hỏi người kiểm thử về phần mềm, cách sử dụng, điểm mạnh và điểm yếu của hệ thống. kiểm thử thăm dò là dò xét, tìm hiểu về phần mềm, hệ thống làm những gì và không làm những gì, những bộ phận nào làm việc và bộ phận nào không làm việc. Người kiểm thử liên tục liên tục đưa ra quyết định về những vấn đề kiểm tra tiếp theo và nơi để chi tiêu thời gian.

• Ưu điểm:
• Phương pháp này không yêu cầu chuẩn bị cho quá trình test như là việc chúng ta không có tài liệu cho hoạt động kiểm thử.
• Thời gian trong quá trình test được tiết kiệm do tất cả các nhiệm vụ test được làm cùng một lúc như là quá trình test, thiết kế kịch bản kiểm thử và thực hiện các kịch bản kiểm thử.
• Nhân viên kiểm thử (QA) có thể báo cáo nhiều vấn đề do yêu cầu không đầy đủ hoặc tài liệu yêu cầu còn thiếu.
• Nhược điểm:
• Vài vấn đề không thể được khai thác trong kiểu test này.
• Có xem xét lại các kế hoạch kiểm tra và thiết kế testcase/kịch bản test trong khi quá trình test có xảy ra vấn đề.
• Những nhân viên kiểm thử (QA) cần phải nhớ kịch bản test - những gì đang thực hiện test bởi vì nếu có lỗi được tìm thấy, tester (QA) sẽ “report a bug” với các bước thích hợp để tái hiện lại nó, với các lỗi khó tái hiện cần phải mô tả các bước một cách thích hợp để thực hiện một cách chính xác lỗi mà anh ta đã báo cáo đặc biệt là với các lỗi mới được tìm thấy.

3. Chọn kỹ thuật kiểm thử.

Trong phần cuối cùng này, chúng ta đi xem xét các yếu tố đưa ra các quyết định về từng kỹ thuật và khi nào thì sử dụng.

Các yếu tố nội bộ ảnh hưởng đến các quyết định sử dụng kỹ thuật nào là thích hợp:

• Các mô hình được sử dụng: khi sử dụng các kỹ thuật kiểm thử dựa trên mô hình, các mô hình có sẵn( tức là được phát triển, sử dụng trong quá trình thực thi, thiết kế và đặc tả kỹ thuật trong hệ thống) sẽ ảnh hưởng đến phạm vi những kỹ thuật kiểm thử nào có thể được sử dụng.
• Các kinh nghiệm, kiến thức của người kiểm thử: có bao nhiêu người kiểm thử biết về hệ thống và về các kỹ thuật kiểm thử sẽ ảnh hưởng rõ ràng đến việc chọn lựa kỹ thuật kiểm thử của mỗi người.
• Các lỗi có khả năng xảy ra: dựa vào kinh nghiệm của người kiểm thử để chọn kỹ thuật sử dung.
• Các mục tiêu kiểm thử
• Tài liệu
• Mô hình vòng đời của hệ thống: mô hình vòng đời nối tiếp thích hợp hơn với các kỹ thuật chính thức, còn mô hình vòng đời lặp thích hợp hơn với phương pháp kiểm thử thăm dò.

Các yếu tố bên ngoài ảnh hưởng đến các quyết định sử dụng kỹ thuật nào là thích hợp:

• Rủi ro: rủi ro càng lớn ( ví dụ như các hệ thống quan trọng vấn đề an toàn, bảo mật) thì nhu cầu kiểm thử kỹ hơn, chính thức hơn.
• Các yêu cầu về hợp đồng của khách hàng: đôi khi trong các hợp đồng có chỉ định các kỹ thuật kiểm thử cụ thể để sử dụng.
• Loại hệ thống: loại hệ thống ( như: đồ họa, tài chính, ..) sẽ ảnh hưởng đến việc lựa chọn kỹ thuật, ví dụ: một ứng dụng tài chính sẽ liên quan đến nhiều tính toán sẽ được hưởng lợi việc phân tích giá trị biên.
• Các yêu cầu điều chỉnh: một số ngành có các hướng dẫn hoặc tiêu chuẩn cho sự điều chỉnh mà ảnh hưởng đến các kỹ thuật kiểm thử được sử dụng.
• Thời gian và ngân sách: khi có nhiều thời gian chúng ta có thể lựa chọn nhiều kỹ thuật kiểm thử hơn nhưng khi thời gian bị giới hạn thì các kỹ thuật cũng được chọn kỹ lưỡng, lựa chọn những kỹ thuật nào có khả năng tìm ra những lỗi quan trọng nhất.

Kết thúc chương 4 tại đây ở bài viết sau mình sẽ giới thiệu chương tiếp theo chương 5: Quản lý kiểm thử (Phần 1)