Test Types

Duy Văn | 20/12/2024

  1. Unit Test, Integration Test, System Test và Acceptance Test
  2. Static Test vs Dynamic Test
    1. Static Test
    2. Dynamic Test
  3. Functional Test và Non-functional Test
    1. Functional Test
    2. Non-fucntional Test
  4. Test On Bugs
  5. Ad-hoc Test

Một vấn đề mà các Tester gặp phải đấy chính là hệ thống các kiểu Test, vì thực tế mà nói có rất nhiều từ ngữ kiểu dạng như “_ Test”, “Smoke Test”, “Stress Test”, rồi lại “Static Test”, “Dynamic Test”. Rất khó để có thể có một hệ thống phân loại cụ thể vì thực tế nhiều cái trong số các loại hình kiểm thử không liên quan đến nhau. Ví dụ như sẽ không ai hỏi “Retest có phải Functional Test không?” vì chúng nó không thật sự liên quan.

Trong bài viết này mình sẽ làm rõ toàn bộ các khái niệm liên quan đến các kiểu kiểm thử

Unit Test, Integration Test, System Test và Acceptance Test

Cũng kết thúc bằng từ “_Test” nhưng chúng nó không phải là một loại hình kiểm thử, mà như ở bài Testing Levels mình đã nói, 4 khái niệm này là Test Levels, tức là các cấp độ của kiểm thử.

Liên đới chúng nó để hiểu chúng nó như các Test Type về cơ bản là làm được, ví dụ:

Unit Testlà hoạt động kiểm thử các đơn vị của sản phẩm phần mềm từ khâu thiết kế, code. Unit Test sẽ test khả năng vận hành của các hàm, các class,… Thực hiện bởi developer, tester cũng có thể làm
Integration Testlà kiểm thử khả năng hoạt động của các đơn vị của sản phẩm, các modules hay sub-systems khi chúng nó được đặt vào tích hợp với nhau. Mục tiêu chính của Integration Test là kiểm tra các lỗi liên quan đến giao diện kết nối. Cũng thường thực hiện bởi developer, cũng có thể thực hiện bởi tester
System Testlà kiểm thử chính sản phẩm phần mềm, một bản build hoàn chỉnh của các tính năng cần kiểm thử. Mục tiêu là xác minh tính chính xác của sản phẩm theo các yêu cầu đã được đặt ra (SRS), bao gồm cả chức năng và phi chức năng. Thực hiện bởi tester là chính.
UAT - Acceptance Testlà kiểm thử sản phẩm hoàn chỉnh được bàn giao từ phía đội phát triển tới cho khách hàng / người dùng. Thực hiện bởi người dùng cuối, nhằm xác minh toàn bộ các yêu cầu đã được đặt ra ở phía khách hàng.

Static Test vs Dynamic Test

Chắc chắn bạn đã nghe tới “Static Test” và “Dynamic Test”, khái niệm này sẽ nằm riêng ở chiều không gian của nó, không liên quan gì tới mấy Test Level ở trên hết, mà nó nhắm tới việc lý giải hoạt động kiểm thử dựa trên đối tượng được kiểm thử nói chung.

Nếu các Test Levels khác nhau ở đối tượng được kiểm thử về mặt kỹ thuật, thì Static Test và Dynamic Test sẽ làm rõ đối tượng kiểm thử một cách khái quát hơn, nhưng nó cũng sẽ không bao trùm các Test Levels đâu.

Static Test

Static Test hiểu nôm na là thực hiện kiểm thử trên các giấy tờ, docs, artifacts của sản phẩm phần mềm và phát hiện ra lỗi (errors) từ khâu ý tưởng mà không cần thực hiện chạy sản phẩm

Ví dụ như một công việc của tester đó là đọc requirements và đồng thời tìm các vấn đề như sai logic, phi thực tế, không rõ ràng, mông lung,… Thì đây chính là Static Test
Một ví dụ khác chính là khi các dev tìm lỗi trong code bằng mắt, tìm các lỗi về logic, về thuật toán chưa tối ưu,… mà không cần thực sự chạy code, thì đây cũng là Static Test

Bản chất của Static Test chính là phát hiện errors / sai sót do con người, nó chưa trở thành “bugs” ở trong sản phẩn phần mềm. Chính vì thế nói Static Test nghiêng về “phòng ngừa” bug hơn là tìm bug.

Bình thường defects và bugs được hiểu là một, nhưng mình muốn làm rõ bản chất 2 thằng có sự khác nhau
Bugs chỉ các lỗi xuất hiện trong sản phẩm phần mềm
Defects chỉ các lỗi xuất hiện trong ý tưởng, thiết kế, documents,… Nên Static Test chính là phát hiện Defects

Dynamic Test

Dynamic Test là hoạt động kiểm thử với đối tượng là các sản phẩm có thể vận hành, tester sẽ cho chạy sản phẩm rồi tìm bugs.

Ví dụ như System Test chính là bao gồm các hoạt động kiểm thử cần phải vận hành sản phẩm phần mềm, nên nói rằng System Test chính là một dạng của Dynamic Test thì không sai.
Hay như Unit Test, các dev sẽ phải test các hàm, function, class bằng cách chạy chúng qua các test case đã được viết, thì đây cũng là Dynamic Test

Bản chất của Dynamic Test là tìm các bugs đã xuất hiện ở trong sản phẩm phần mềm, nó thiên về “tìm” bugs hơn là “phòng ngừa”. Tính phòng ngừa của Dynamic Test la khi đã tìm được bug và sửa thì sẽ ngăn chặn được bug tiến vào các bước sâu hơn của quy trình phát triển, đồng thời giúp lấy được các insight cần thiết để không tái phát bug trong tương lai.

Ở đây chúng ta có 2 khái niệm nhỏ hơn ở Dynamic Test là Blackbox Test và Whitebox Test, khái niệm sẽ đi kèm Blackbox Test Designing Technique và Whitebox Test Designing Technique mà mình sẽ nói ở bài Design Techniques

  • Blackbox Test: là hoạt động kiểm thử mà tester không cần quan tâm sản phẩm vận hành thế nào, không cần quan tâm đến bên trong tính năng mà đánh giá qua kết quả đầu vào và đầu ra. Hay nôm na là nhìn Input và Output, có thể ở dạng kết quả hoặc hành vi của sản phẩm

  • Whitebox Test: là hoạt động kiểm thử mà tester cần biết rõ nội dung vận hành của đối tượng kiểm thử để đánh giá, thường áp dụng cho các sản phẩm làm việc dạng code nên áp dụng chính ở Unit Test, Integration Test

    • Statement Testing: kiểm tra tính chính xác khi chạy tất cả các dòng code
    • Decision/Branch Testing: kiểm tra tính chính xác khi chạy tất cả các nhánh của code

Functional Test và Non-functional Test

Như mìn đã từng nói qua về hai hoạt động kiểm thử này, chúng liên quan mật thiết đến Functional requirement - yêu cầu chức năng và Non-functional requirement - yêu cầu phi chức năng của sản phẩm phần mềm.

Functional Test

Functional Test là hoạt động kiểm thử nhằm xác minh tính chính xác trong hành vi của sản phẩm theo các yêu cầu chức năng (functional requirement). Nói cách khác thì chúng ta sẽ thực hiện kiểm thử tất cả các chức năng theo yêu cầu của sản phẩm, xem có đúng yêu cầu hay không, nôm na là kiểm tra sản phẩm có thể làm gì

Một số Test Types con thuộc functional test bao gồm:

Smoke TestHoạt động kiểm thử nhằm xác minh các tính năng chính, cơ bản và quan trọng nhất của sản phẩm phần mềm. Nếu Smoke Test fail thì không cần phải thực hiện kiểm thử sâu hơn vào chi tiết
Sanity TestHoạt động kiểm thử nhắm tới những module cụ thể, đi sâu nhằm xác định xem module hay tính năng cụ thể có hoạt động chính xác hay không khi có một thay đổi nhỏ hoặc bug fix nhỏ
Exploratory TestHoạt động kiểm thử mang tính tự do, tester đi vào và sử dụng phần mềm không theo kịch bản cụ thể, sử dụng cảm quan và kinh nghiệm để tìm bugs. Bình thường thì nội dung của Exploratory Test sẽ được thực hiện không đụng hàng với các test case đã được viết
UI TestKiểm thử UI/UX của sản phẩm, xem xét về giao diện, tương tác của người dùng với sản phẩm

Non-fucntional Test

Non-functional test là hoạt động kiểm thử nhằm xác minh tính chính xác của sản phẩm phần mềm theo yêu cầu phi chức năng (Non-functional requirement). Cũng sẽ đi kiểm thử sản phẩm phần mềm nhưng ở các nội dung liên quan đến khả năng vận hành thay vì là tính năng như hiệu năng, hiệu suất, an ninh, … Nó sẽ đánh giá được sản phẩm phần mềm hoạt động thế nào, tốt đến đâu

Một số Test Types con thuộc non-functional test bao gồm:

Usability TestKiểm thử khả năng sử dụng phần mềm từ góc độ người dùng, cách sử dụng, cách tương tác, thân thiện với người dùng
Accessibility TestKiểm thử khả năng sử dụng phần mềm từ góc độ người khuyết tật, như màu sắc, font chữ, kích thước, …Hoặc trong các tình huống không thường xuyên đối với người dùng bình thường, ví dụ test khả năng nhìn được của UI dưới ánh sáng mặt trời khi đi đường
Performance TestKiểm thử hiệu năng của sản phẩm phần mềm
Performance Test: Load TestKiểm thử hiệu năng của sản phẩm ở các mức độ tải khác nhau.
Mức độ tải ở đây có thể hiểu là chịu tải của máy chủ tại một thời điểm do số lượng người dùng truy cập, số lượng request, số lượng dữ liệu,v.v…
Performance Test: Stress TestKiểm thử hiệu năng của sản phẩm ở mức tải cao, nhắm tới kiểm tra sự ổn định và khả năng chịu tải của sản phẩm, thường sẽ chạy cho tới khi sập hệ thống hoặc xuất hiện các hành vi bất thường
Performance Test: Endurance TestKiểm thử hiệu năng của sản phẩm ở các mức tải nhất định trong khoảng thời gian vận hành dài, tập trung vào tính ổn định của sản phẩm
Performance Test: Volumn TestKiểm thử khả năng xử lý dữ liệu với khối lượng lớn của sản phẩm, nhiều khi các phần mềm sẽ xử lý tốt dữ liệu đâu vào với khối lượng nhỏ, nhưng lớn sẽ gặp vấn đề do tối ưu và kiểm soát tài nguyên không tốt
Security TestKiểm thử an ninh của sản phẩm phần mềm, rất đặc thù nên thường được thực hiện bởi các chuyên gia an ninh

Test On Bugs

Có một ngạch Test Type riêng, sinh ra để kiểm thử nhằm xác minh tính chính xác của sản phẩm phần mềm khi trải qua các hoạt động debug

Regression Test

Regression Test là hoạt động kiểm thử nhằm xác minh tính chính xác của cả sản phẩm sau khi các bugs đã được sửa để đảm bảo các thay đổi được đưa vào không tạo ra thêm bug ở các chức năng khác trong sản phẩm phần mềm.

Nói một cách đơn giản thì, nhiều khi dev sửa lỗi A nhưng thay đổi để sửa lỗi A lại tạo ra lỗi B, hay tệ hơn là C, D, E, F,… Regression Test sẽ giúp phát hiện các bug phát sinh này

Regression Test sẽ được thực hiện bằng cách chạy lại toàn bộ các test case đã được viết, bao gồm cả những case đã pass và các case fail

Bug được phát hiện trong Regression Test sẽ được log mới, chúng ta sẽ không quay về undo pha sửa bug cũ, cái đấy phụ thuộc vào bên dev họ quyết định xử lý vấn đề thế nào

Re-test / Confirmation Test

Re-test hay Confirmation Test là hoạt động kiểm thử để xác định xem bugs đã log từ trước, chuyển cho dev sửa đã thật sự được sửa hay chưa. Nó sẽ được thực hiện sau khi dev thông báo bug đã được fix.

Re-test sẽ chỉ chạy lại test case hoặc nhóm test case mà liên quan đến bug đã được log. Một lưu ý nhỏ rằng nhiều khi sẽ có những test case fail do cùng một bug.

Balance Of Regression Test And Re-test

Như đã nói, Regression Test sẽ cho chạy lại tất cả các test case và Re-test sẽ chỉ chạy lại các case fail do bug. Vậy nên xét về khối lượng thì Regression sẽ rất nặng (nếu chưa chuyển sang auto)

Ví dụ có 100 Bugs, Dev sẽ có nhiệm vụ sửa hết chỗ 100 bugs này, vậy khi nào làm Regression Test và khi nào Re-test nếu mỗi tuần dev sửa hết 20 bugs?

Chúng ta sẽ phân tích như sau:

  • Thứ nhất, chắc chắn sẽ phải chạy 100 lần Re-test với mỗi lần là test case fail do 100 bug này
  • Thứ hai, số lần Regression cũng từ đấy có thể lên đến 100 lần hoặc hơn do có thể phát sinh bug, hoặc cũng có thể chỉ là 1 lần nếu may mắn dev fix hết 100 bugs mà không phát sinh bug mới
  • Thứ ba, tuỳ deadline của dự án, ví dụ như cần 5 tuần để sửa hết 100 bugs nhưng cứ mỗi tuần phải cho một bản build để push lên production vì sản phẩm đã go live

Vậy thì kết luận như sau:

  • Với 100 bugs, chắc chắn phải chạy retest sau mỗi tuần cho 20 bugs được sửa trong tuần đó
  • Trước mỗi khâu đưa lên production thì chạy regression test để tìm bug mới phát sinh, nếu bug này critical thì có khả năng phải hoãn việc đưa lên production hoặc rollback sản phẩm
  • Nếu hoàn toàn không có khâu đưa lên production thì cần cân đối giữa số lần chạy regression và re-test, có thể chạy re-test sau mỗi 2 tuần và chạy regression ở cuối, đây là một lựa chọn chấp nhận được.

Ad-hoc Test

Chắc bạn từng thấy mấy bài đăng @viral trên thread mà tester ngồi ấn hay gõ loạn xạ trên điện thoại, thì đấy là một hình thức ad-hoc test.

Ad-hoc Test là một thể loại Test gần như không có kế hoạch, không có kịch bản, không có test case, không có gì hết, ngồi ấn linh tinh sử dụng cảm quan và kiến thức ngoài. Nó sẽ khác Experienced Base Testing mà mình sẽ nói trong bài Design Techniques

Thì ad-hoc test thường hay gọi chung với Monkey Test, tức là như con khỉ, nó sẽ lấy một cái tư duy nguồn rằng người dùng có thể đang cố phá sản phẩm bằng cách đưa vào các input bất kỳ, cường độ cao.

Lý do tại sao Ad-hoc test lại được thực hiện là vì ở một số dòng dự án, nhất là ở các sản phẩm được phát triển sử dụng framework, thư viện, công nghệ mới, thì bản thân các framework này tiềm tàng những bug thuộc về chính chúng nó, và sẽ xuất hiện ở tất cả các sản phẩm được xây dựng trên nó. Các hình thức test bài bản chắc chắn sẽ không thể bắt được các lỗi này do bản thân Framework nằm ngoài phạm vi kiểm thử của Test Plan.

Một ví dụ của ad-hoc test có thể là ngồi tab lung tung vào màn hình ứng dụng. Hay thực hiện input thật dài, thât lâu và random vào ô điền username, v.v…
Một ví dụ thực tế là khi Windows 2000 được phát triển bởi Microsoft, nó là sản phẩm rất mới và tiềm ẩn rất nhiều lỗi ngẫu nhiên, một trong số đó là khi các kỹ sư của Microsoft đặt tên file dài, thì Windows sẽ không thể xử lý được, và nó sẽ crash.

Ad-hoc test nếu tìm ra bug thì sẽ log bug và khi đó mới quay ngược lại tạo test case