So sánh black box white box testing

Trong phần này, mình sẽ hướng dẫn các bạn các phân biệt các loại testing cũng như giải thích các thuật ngữ trong ngành testing. Cuối bài, chúng ta tổng kết lại qua một câu chuyện nho nhỏ nhé.

Series gồm 3 phần:

• Phần 1: Tại sao lập trình viên cần biết về testing?
• Phần 2: Thuật ngữ chuyên ngành testing và các loại testing
• Phần 3: Công việc thường ngày của tester. Automation test có gì hot?

Đủ loại testing hầm bà lằng

Khi mới tìm hiểu về testing, các bạn sẽ dễ cảm thấy “tẩu hoả nhập ma” vì được nghe rất nhiều dạng testing như: Black-box white box, unit test, manual test, automation test v…v

Trong tầm hiểu biết của mình, những cái tên này chỉ nhằm giúp ta phân loại test mà thôi. Ta có thể phân loại testing dựa theo nguyên lý testing (test như thế nào), cách chạy test, và thứ mà chúng ta cần test.

White-box/Black-box – Test như thế nào

• White-box: White-box tức là hộp trắng, hộp trong suốt. Test kiểu white box tức là chúng ta test khi biết source code, biết về cấu trúc của hệ thống. Test kiểu này giúp chúng ta kiểm tra code chạy có chính xác hay không.
• Black-box: Black-box tức là hộp đen. Test kiểu black box tức là ta test khi không biết gì về code hay cấu trúc bên trong của hệ thống. Ta kiểm tra hệ thống dưới góc nhìn của người dùng. Dựa vào input (đầu vào) và output (đầu ra) để biết hệ thống hoạt động đúng hay không.

Manual/Automation – Chạy test bằng cách nào

• Manual Test: Ta chạy code hoặc thực hiện test bằng cơm (tức là dùng sức người), sau đó kiểm tra kết quả xem có đúng hay không.
• Automation Test: Trái ngược với Manual là Automation tức là tự động. Với Automation Test, ta viết code để thực hiện việc test. Code sẽ chạy chương trình, nhập thông tin vào, sau đó so sánh đầu ra của chương trình với kết quả. Cuối cùng xuất ra báo cáo.

Mỗi cách đều có ưu nhược điểm riêng, mình sẽ nói rõ hơn ở phần sau nha. Có điều vì Automation Test khó hơn nên lương của Automation QC engineer thường cao hơn hihi.

Unit/Integration/System… – Test cái gì

• Unit test: Test do lập trình viên như chúng ta viết, dùng để chạy thử code các class, module xem chúng có hoạt động đúng không. (Các bạn xem lại bài viết về Unit Test trong C# và Unit Test trong JavaScript nhé!)
• Integration test: Test những thành phần trong một hệ thống, xem cách chúng hoạt động, giao tiếp với nhau như thế nào
• System test: Test toàn bộ hệ thống, xem hệ thống có hoạt động đúng không, có bị lỗi hay crash không, có thiết kế đúng design không. (Hệ thống có do the thing right không?)
• Acceptance test: Test lần cuối để kiểm tra hệ thống có đúng yêu cầu của khách hàng hay không, có thiếu hay dư chức năng nào không. ( Hệ thống có do the right thing không?)

Một số kiểu test khác

Ngoài ra, còn một số loại testing ít phổ biến và khó phân loại như:

• Load testing: Test khả năng chịu tải của hệ thống
• Penetration Test: Test độ bảo mật của hệ thống, cái này cần kiến thức bảo mật nhiều hơn
• Smoke Test: Test kiểu đơn gỉản, gọn lẹ để xem hệ thống có bị hư gì không. Thuật ngữ này bắt nguồn từ ngành phần cứng, ta chạy thử phần cứng để xem có khói (smoke) bốc lên hay không. Nếu có tức là phần cứng bị cháy, chắc do mấy bác developer code nhầm hay mắc lộn mạch điện gì đó.

Khó phân loại hoàn toàn các kiểu test

Nói chung, các loại test thường chỉ là tên gọi mà người ta dựa vào đó để phân loại. Tuy nhiên, rất khó để hoàn toàn tách biệt các kiểu test:

• Unit test là do developer viết và chạy, nó là white-box testing.
• Integration test & system test là do QA/tester chạy, nó hơi lai lai giữa white-box và black-box.
• Acceptence test là do khách hàng chạy, nó hoàn toàn là black box.
• Penetration test có thể do một team bảo mật bên ngoài làm, họ sẽ chạy tool (automation test) để tìm lỗ hổng trước, sau đó bắt đầu tìm và test các lỗ hổng còn lại (manual test)

Do vậy, các bạn không cần phải phân loại quá chính xác, chỉ cần hiểu mỗi kiểu test làm cái gì, khi nào cần áp dụng kiểu test đó là được rồi.

Một số thuật ngữ chuyên môn trong testing

Tới đây thì các bạn cũng đã hiểu sơ sơ về các loại testing rồi, mình gom lại một số thuật ngữ chuyên môn trong ngành testing mà bài viết chưa nhắc đến nhé:

• Test plan: Bản kế hoạch test do sếp hoặc test leader chuẩn bị, thường chứa những nội dụng như: rõ test cái gì, những phần nào cần test, thời gian test là bao lâu, những ai sẽ tham gia hoạt động test, đầu ra cuối cùng là gì?
• Test case: Một trường hợp cần test. Tester sẽ dựa theo các thông tin trên test case (Đầu vào, các bước test, môi trường test, kết quả mong đợi) để thực hiện test; sau đó so sánh kết quả mong đợi với đầu ra của chương trình.
• Test suite: Một test suite là một bộ bao gồm nhiều test case liên quan với nhau.
• Test report: Bản report chứa kết quả toàn bộ quá trình test, có bao nhiêu test case fail, có bao nhiêu test case pass, tìm được bao nhiêu bug.
• Testing framework/testing platform: Công cụ giúp chúng ta viết test case, chạy các test case này một cách tự động và tổng hợp kết quả.

Áp dụng vào dự án thực tế

Bài viết này hơi nhiều lý thuyết nên có vẻ hơi khô khan. Để tổng kết lại những khái niệm trong bài một cách dễ hiểu dễ nhớ, chúng ta hãy cùng xem câu chuyện sau:

Lan là khách hàng, Sơn là dev, Tùng là tester. Lan muốn đặt sản phẩm là một trang web bán quần áo, có 2 thành phần chính là web bán hàng và web quản lý. Khi nhận được yêu cầu,Sơn sẽ bắt đầu thiết kế hệ thống, UI/UX và database, sau đó lao đầu vào code.Tùng sẽ lên kế hoạch những thứ cần test, gọi là test plan. Sau khi viết code các class, Sơn viết unit test trong C#. dùng testing platform NUnit để chạy unit test. Sau khi xong module web bán hàng, bắt đầu tới giai đoạn integration test. Sơn chạy white-box testing để xem code chạy ổn chưa, sau đó đưa cho Tùng. Tùng dựa theo các test case để test module bán hàng, sau đó tìm lỗi và báo lại cho Sơn sửa. Sau khi Sơn hoàn thành 2 module, Tùng thực hiện system testing để kiểm tra toàn bộ hệ thống có hoạt động đúng hay không. Sau đó, Tùng đưa sản phẩm đã hoàn thành cho Lan thực hiện acceptance test. Lan test để xem hệ thống có đủ những thứ Lan muón, có đầy đủ những chức năng như Lan yêu cần hay không! Cái kết bất ngờ: Do đây chỉ là dự án chấm điểm trên lớp, Lan không có tiền trả nên... xù nợ, không trả tiền cho Sơn và Tùng. Hai chàng developer và tester bị quịt tiền, buồn nên dắt nhau đi uống trà sữa rồi kéo nhau vào nhà nghỉ giải quyết nỗi buồn. Từ đó Sơn và Tùng hanh phúc bên nhau trọn đời!

Cái kết có hậu cho Sơn và Tùng

Tạm kết

Thông qua bài này, các bạn đã có đủ kiến thức cơ bản về ngành testing, các loại test cũng như các thuật ngữ chuyên ngành testing, đủ để chém gió với các bạn tester rồi đấy.

Ở phần cuối, mình sẽ kể rõ hơn về qui trình làm việc và công việc thường ngày của các bạn tester. Mình cũng sẽ cho các bạn thấy những thứ hay ho ta có thể làm thông qua automation test nhé.