Techmaster Việt Nam - Học là có việc

Trong quá trình thực hiện công việc kiểm thử phần mềm, chúng ta gặp phải vô số các khái niệm khác nhau. Các khái niệm này có thể đã quen thuộc với nhiều người, nhưng cũng có rất nhiều khái niệm mà chúng ta lạ lẫm và chưa từng nghe thấy.

Kiểm thử phần mềm (Software Testing)

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm ra lỗi. Kiểm thử phần mềm đảm bảo sản phẩm phần mềm đáp ứng chính xác, đầy đủ và đúng theo yêu cầu của khách hàng, yêu cầu của sản phẩm đề đã đặt ra. Kiểm thử phần mềm cũng cung cấp mục tiêu, cái nhìn độc lập về phần mềm, điều này cho phép việc đánh giá và hiểu rõ các rủi ro khi thực thi phần mềm. Kiểm thử phần mềm tạo điều kiện cho bạn tận dụng tối đa tư duy đánh giá và sáng tạo để bạn có thể phát hiện ra những điểm mà người khác chưa nhìn thấy.

Kiểm thử hộp đen (Black Box Testing)

Kiểm thử hộp đen là 1 phương pháp kiểm thử mà tester sẽ chỉ xem xét đến đầu vào và đầu ra của chương trình mà không quan tâm code bên trong được viết ra sao. Tester thực hiện kiểm thử dựa hoàn toàn vào đặc tả yêu cầu. Mục đích của kiểm thử hộp đen là tìm ra các lỗi ở giao diện, chức năng của phần mềm. Các trường hợp kiểm thử sẽ được xây dựng xung quanh đó.

Kiểm thử hộp trắng (White Box Testing)

Kiểm thử hộp trắng là phương pháp kiểm thử mà cấu trúc thuật toán của chương trình được đưa vào xem xét. Các trường hợp kiểm thử được thiết kế dựa vào cấu trúc mã hoặc cách làm việc của chương trình. Người kiểm thử truy cập vào mã nguồn của chương trình để kiểm tra nó.

Kiểm thử đơn vị (Unit Test)

Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất. Kiểm thử thực hiện trên các hàm hay thành phần riêng lẻ. Đây là một công việc mà để thực hiện được nó thì người kiểm thử sẽ phải hiểu biết về code, về chương trình, các hàm... Nếu bạn đang lo lắng vì bạn không có nhiều kiến thức về code thì không sao cả, vì bạn sẽ không phải thực hiện bước kiểm thử này, lập trình viên sẽ làm nó trước khi giao cho bạn.

Mục đích của việc thực hiện kiểm thử đơn vị là cô lập từng thành phần của chương trình và chứng minh các bộ phận riêng lẻ chính xác về các yêu cầu chức năng.

Kiểm thử tích hợp (IntegrationTesting)

Như chúng ta đã biết, một phần mềm được tạo ra sẽ bao gồm rất nhiều module trong đó, để chắc chắn rằng phần mềm hoạt động tốt thì chúng ta cần phải gom các module lại với nhau

để kiểm tra sự giao tiếp giữa các module cũng như bản thân từng thành phần từng module... Kiểm thử tích hợp bao gồm hai mục tiêu chính là : Phát hiện lỗi giao tiếp xảy ra giữa các Unit Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ và cuối cùng là 1 hệ thống hoàn chỉnh để chuẩn bị cho bước kiểm thử hệ thống.

Kiểm thử hệ thống (System test)

Kiểm thử một hệ thống đã được tích hợp hoàn chỉnh để xác minh rằng nó đáp ứng được yêu cầu Kiểm thử hệ thống thuộc loại kiểm thử hộp đen. Kiểm thử hệ thống tập trung nhiều hơn vào các chức năng của hệ thống. Kiểm tra cả chức năng và giao diện, các hành vi của hệ thống 1 cách hoàn chỉnh, đáp ứng với yêu cầu.

Kiểm thử chấp nhận (Acceptance test)

Trong kiểu kiểm thử này, phần mềm sẽ được thực hiện kiểm tra từ người dùng để tìm ra nếu phần mềm phù hợp với sự mong đợi của người dùng và thực hiện đúng như mong đợi. Trong giai đoạn test này, tester có thể cũng thực hiện hoặc khách hàng có các tester của riêng họ để thực hiện. Có 2 loại kiểm thử chấp nhận đó là kiểm thử Alpha và kiểm thử Beta:

Kiểm thử Alpha: là loại kiểm thử nội bộ . Tức là phần mềm sẽ được 1 đội kiểm thử độc lập hoặc do khách hàng thực hiện tại nơi sản xuất phần mềm.

Kiểm thử Beta: là loại kiểm thử mà khách hàng thực hiện kiểm thử ở chính môi trường của họ. Loại kiểm thử này được thực hiện sau kiểm thử Alpha.

Kiểm thử chức năng (Functional testing)

Kiểm thử chức năng là một loại kiểm thử hộp đen (black box) và các trường hợp kiểm thử của nó được dựa trên đặc tả của ứng dụng phần mềm/thành phần đang test. Các chức năng được test bằng cách nhập vào các giá trị nhập và kiểm tra kết quả đầu ra, và ít quan tâm đến cấu trúc bên trong của ứng dụng (không giống như kiểm thử hộp trắng - white-box testing). Có thể hiểu 1 cách đơn giản, kiểm thử chức năng là xác nhận tất cả các chức năng của hệ thống. Nó đánh giá ứng dụng và xác nhận liệu ứng dụng có đang hoạt động theo yêu cầu hay không.

Test cấu hình (Shakeout Testing)

Kiểu kiểm thử này cơ bản là kiểu kiểm thử về khả năng của hệ thống mạng, kết nối dữ liệu và sự tương tác của các module. Thông thường thì kiểu test này là do nhóm quản lý cấu hình chuẩn bị thiết lập các môi trường test thực sự. Họ cũng kiểm tra xem liệu các thành phần

chính của phần mềm có hoạt động bất thường không. Kiểu kiểm thử này thực hiện trước khi tiến hành thực hiện trong môi trường test. Sau khi test shakeout, bước kế tiếp là test smoke (kiểu test được thực hiện bởi tester sau khi biên dịch, được tiến hành trong môi trường test).

Smoke Testing

Smoke Testing là quá trình để kiểm tra liệu bản build có ổn định hay không? Để xem bản build có đủ ổn định để thực hiện test chi tiết hay không (trong trường hợp bản build không ổn định, lỗi luôn chức năng chính hoặc build bị lỗi thì trả lại Dev, yêu cầu sửa luôn). Hay kiểm tra các tính năng quan trọng có đang hoạt động hay không. Nó là 1 bài test hồi quy nhỏ đơn giản và nhanh của các chức năng chính, cho thấy sản phẩm đã sẵn sàng cho việc test hay chưa.

Adhoc Testing

Thuật ngữ Adhoc testing là phương pháp kiểm thử dạng Black box test mà không theo cách thông thường. Với quy trình test thông thường là phải có tài liệu yêu cầu, kế hoạch test (test plan), kịch bản kiểm thử. Kiểu test này không theo bất cứ loại kỹ thuật test nào để tạo test case.

Monkey Testing

Monkey testing được định nghĩa rất ngắn gọn: là một phương pháp kiểm thử với đầu vào ngẫu nhiên, không theo test case hay một chiến lược test nào. Trong Monkey testing thì các tester (đôi khi cả developer nữa ) được coi như là 1 con khỉ vậy. Bạn thử nghĩ mà xem, nếu 1 con khỉ mà sử dụng máy tính thì nó sẽ làm những gì nhỉ? Tuy loài khỉ rất thông minh nhưng khi cho nó sử dụng máy tính, nó sẽ thực hiện những hành động bất kỳ trên hệ thống , điều mà chính nó cũng không thể hiểu được. Nó cũng giống như khi tester thực hiện monkey testing, họ sẽ áp dụng các kịch bản kiểm thử ngẫu nhiên trên hệ thống để tìm ra lỗi mà không cần xác định trước. Trong 1 số trường hợp, Monkey testing chỉ dành cho Unit Testing hoặc GUI Testing (Kiểm thử giao diện người dùng)

Kiểm thử hiệu suất (Performance Testing)

Trong loại test này, ứng dụng được test dựa vào sức nặng như sự phức tạp của giá trị, độ dài của đầu vào, độ dài của các câu truy vấn... Loại test này kiểm tra bớt phần tải (stress/load) của ứng dụng có thể được chắc chắn hơn.

Kiểm thử hồi quy (Regression Testing)

Test hồi quy là test lại 1 chức năng đã được làm xong, đã được test xong rồi, đã hết lỗi nhưng do có sự sửa đổi 1 chức năng khác mà lại có ảnh hưởng đến nó, thì phải test 1 chức năng đã xong rồi thì gọi là test hồi quy. Ví dụ có 3 chức năng A B C đã hoàn thành, 3 chức năng này đều có mối quan hệ với nhau và chức năng A cần phải sửa đổi thêm về nghiệp vụ, và việc sửa chức năng A sẽ làm ảnh hưởng đến chức năng B, C và việc phải test lại chức năng B và C thì gọi là test hồi quy. Hoặc khi Developer sửa 1 chức năng mà chức năng này có làm ảnh hưởng đến chức năng đã xong rồi thì cũng phải thực hiện test lại chức năng đã xong rồi kia thì gọi là test hồi quy

Hoặc ngay cả khi re-test để đóng bug, mà thấy chức năng Developer sửa có thể làm ảnh hưởng đến 1 chức năng khác đã xong rồi thì tester cũng nên test hồi quy lại chức năng đó để tránh có lỗi tiềm ẩn.

Accessibility Testing

Là một loại kiểm thử dành cho các hệ thống được thiết kế cho người khuyết tật (khiếm thính, khiếm thị, thiểu năng tâm thần...), xác định khả năng tiếp cận và sử dụng của họ với ứng dụng. Ví dụ như các thiết lập Accessibility của smart phone: Text-to-Speech, "Magnification gestures"... Người khuyết tật thường sử dụng những tính năng hỗ trợ họ sử dụng các phần mềm. Loại test này có thể được thực hiện theo 2 cách là Manual và Automated.

Active Testing

Loại kiểm thử bao gồm việc đưa ra dữ liệu test và phân tích kết quả thực hiện. Nó thường được tiến hành bởi đội tester. Trong quá trình active testing, tester sẽ hình dung để dựng một mô hình của phần mềm để test, cái này sẽ được phát triển và làm hoàn thiện hơn các tương tác của nó với những phần mềm đang chạy.

Agile Testing

Kiểm thử Agile là việc kiểm thử phần mềm được thực hiện theo một số quy định của bản tuyên ngôn (Manifesto) Agile, xem việc phát triển phần mềm như là khách hàng của việc kiểm thử. Kiểm thử Agile thực hiện kiểm thử theo quan điểm của khách hàng càng sớm càng tốt, thử nghiệm sớm và thường xuyên ngay khi code vừa xong và đủ ổn định để test từ level

API Testing

API (Application Programming Interface): cho phép kết nối và trao đổi dữ liệu giữa hai hệ thống phần mềm riêng biệt. Một hệ thống phần mềm có thể nhúng các API bao gồm các hàm/thủ tục con (functions/sub-routines) mà có thể chạy bởi một hệ thống phần mềm khác.
Kiểm thử API khác hoàn toàn với kiểm thử GUI và các thành phần chủ yếu khác trong tầng business logic của kiến trúc phần mềm. Loại kiểm thử này không tập trung vào phần giao diện và thao tác giao diện của một ứng dụng. Thay vì sử dụng các đầu vào (bàn phím) và đầu ra tiêu chuẩn, trong kiểm thử API, bạn có thể sử dụng một phần mềm để gửi các yêu cầu đến API, nhận đầu ra và ghi lại phản hồi của hệ thống.

All-pairs Testing

All pair testing (Kiểm thử tất cả các cặp) hay còn gọi là pairwise testing, là một phương pháp test được thực hiện để kiểm thử các phần mềm sử dụng phương pháp tổ hợp. Đó là một phương pháp để kiểm tra tất cả các kết hợp rời rạc có thể có của các thông số liên quan, phương pháp test ít nhất sao cho chất lượng tốt nhất.

Basis Path Testing

Thuộc phương pháp kiểm thử hộp trắng (White box test) là kỹ thuật kiểm thử mà phần mềm được chia thành các lộ trình, đảm bảo các lộ trình độc lập qua một module mã sẽ được kiểm thử đầy đủ. (Được thực hiện bởi developer).

Xem tiếp 100 khái niệm về TEST - Phần 2! Cảm ơn các bạn đã theo dõi!

100 khái niệm về TEST - Phần 1