CÁC MỨC ĐỘ KIỂM THỬ (TEST LEVELS)

Khi kiểm thử hệ thống, môi trường để kiểm thử phải được thiết lập càng giống như môi trường thực tế càng tốt để tối thiểu hóa những rủi ro và giả lập số lượng người dùng giống với thực tế để mang lại một hệ thống phần mềm tốt nhất cho khách hàng.

1. Kiểm thử đơn vị (Component testing)

Component testing, còn được gọi là Unit testing, ở mức kiểm thử này thường do Developer phụ trách, họ sẽ đi kiểm tra các module, các hàm, các phương thức, các lớp,… mà họ viết ra nhằm gia tăng sự tin cậy cho các chức năng mà mình viết.

Kiểm thử đơn vị nằm trong phạm vi của Kiểm thử hộp trắng, tức là kiểm tra code bên trong của một chức năng hoặc hệ thống để xem chức năng hoặc hệ thống đó được viết đúng chuẩn code hay chưa, đoạn code đó khi chạy hiệu năng có tốt hay không, có nhanh hay không, có tốn tài nguyên hay không,..

Trong kiểm thử đơn vị có 2 khái niệm là Stub và Driver.:

– Stub: Khi cần kiểm tra phương thức A, nhưng phương thức A lại cần dữ liệu từ phương thức B, mà phương thức B lại chưa được viết. Trong trường hợp này ta có thể giả lập một phương thức B để có dữ kiện giúp chúng ta kiểm thử phương thức A, khi đó phương thức giả lập B sẽ gọi là Stub. Ví dụ: Khi cần kiểm thử chức năng đăng ký môn học nhưng phương thức kiểm tra điều kiện tiên quyết lại chưa được viết thì ta có thể giả lập phương thức kiểm tra điều kiện tiên quyết để có dữ liệu giúp kiểm thử chức năng đăng ký môn học, khi đó phương thức giả lập đó gọi là Stub.

– Driver: ngược lại với Stub, khi chúng ta cần kiểm thử Module B hoặc phương thức B nhưng cần phải qua Module A hoặc phương thức A mới kiểm thử được B, khi đó ta có thể giả lập Module hoặc phương thức A để ta có thể vào kiểm thử được B, lúc đó phương thức giả lập A gọi là Driver. Ví dụ: Khi cần kiểm thử chức năng đăng ký môn học nhưng chức năng đăng ký tài khoản lại chưa được viết thì ta có thể giả lập một phương thức đăng ký tài khoản để có dữ liệu sinh viên giúp ta vào kiểm thử chức năng đăng ký môn học, khi đó phương thức giả lập đăng ký tài khoản gọi là Driver.


2. Kiểm thử tích hợp

Kiểm thử tích hợp là kiểm thử sự tương tác giữa các chức năng với nhau trong hệ thống, ví dụ: sau khi đã unit test chức năng đăng nhập và chức năng đăng ký thì ta có thể tiến hành kiểm thử tích hợp của 2 chức năng này để xem chúng có tương tác tốt với nhau không, sau khi đăng ký thành công thì ta có thể tiến hành đăng nhập bằng tài khoản đã đăng ký xem có thực hiện được không.

Một ví dụ khác: Sau khi unit test cho các chức năng con trong chức năng đăng ký môn học như đăng nhập, đăng ký tài khoản, kiểm tra điều kiện tiên quyết, kiểm tra học phí,.. thì ta kiểm tra sự tích hợp giữa các chức năng này bằng cách tiến hành đăng ký một môn học để xem sự tương tác giữa các chức năng này có thực hiện được không, có trơn tru không, có bị mất liên kết chỗ nào không,…

Khi kiểm thử tích hợp ta có thể áp dụng theo nhiều hướng như sau:

– Big-Bang

– Phương thức Top-down.

– Phương thức Bottom-Up

– Phương thức gia tăng chức năng.

3. Kiểm thử hệ thống

Kiểm thử hệ thống là kiểm thử một hệ thống đã hoàn thành, đã tích hợp đầy đủ các chức năng nhằm kiểm tra xem hệ thống phần mềm đó có đáp ứng đầy đủ các yêu cầu chức năng theo bản đặc tả yêu cầu phần mềm (SRS) hay không.

Kiểm thử hệ thống thuộc phạm vi Kiểm thử hộp đen (tức là Tester chỉ quan tâm đầu vào và kết quả mong đợi ở đầu ra mà không cần kiểm tra code bên trong được viết như thế nào).

Kiểm thử hệ thống bao gồm kiểm thử chức năng và kiểm thử phi chức năng.

Khi kiểm thử hệ thống, môi trường để kiểm thử phải được thiết lập càng giống như môi trường thực tế càng tốt để tối thiểu hóa những rủi ro, ví dụ: phiên bản Windows, phiên bản trình duyệt web, phiên bản Android, iOS, phiên bản Server,… và giả lập số lượng người dùng giống với thực tế để mang lại một hệ thống phần mềm tốt nhất cho khách hàng. 

4. Kiểm thử chấp nhận

Kiểm thử chấp nhận là kiểm tra xem hệ thống có đáp ứng đúng nhu cầu và mong đợi của khách hàng hay không.

Kiểm thử chấp nhận thường là trách nhiệm của người dùng hoặc khách hàng. Trong kiểm thử hệ thống, khách hàng sẽ kiểm tra xem phần mềm được viết có hoạt động đúng như mong đợi của mình không, có đảm bảo tính tiện dụng, hiệu suất hoạt động có như mong đợi không, có bảo mật tốt hay không,….

Tìm lỗi không phải là trọng tâm chính trong kiểm thử chấp nhận, vì việc tìm lỗi đã được đội Developer và Tester thực hiện trong các giai đoạn kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống rồi.

Acception testing (kiểm thử chấp nhận) còn được gọi là Alpha testing.

Một số vấn đề khi kiểm thử chấp nhận thường quan tâm như:

– Kiểm thử chức năng sao lưu/phục hồi.

– Kiểm thử khả năng phục hồi sau thảm họa, ví dụ: động đất, thiên tai, mất điện, hư server,…

– Kiểm thử chức năng phân quyền.

– Kiểm thử khả năng bảo trì của hệ thống.

– Kiểm thử các lỗ hổng bảo mật.


Mr. Phước Phan
PLT SOLUTIONS