Kiến thức cơ bản về Kiểm thử tĩnh

Khi nói đến kiểm thử, thông thường người ta nghĩ rằng đó là quá trình thực thi phần mềm và kiểm tra kết quả. Tuy nhiên, trên thực tế, kiểm thử còn bao gồm các công việc như review các sản phẩm đầu ra như yêu cầu, câu chuyện người dùng, mã nguồn hoặc phân tích tĩnh mã nguồn.

Để phân biệt rõ ràng các loại kiểm thử này, quá trình kiểm thử thông thường khi thực thi phần mềm và kiểm tra kết quả được gọi là “kiểm thử động”, trong khi review và phân tích tĩnh được gọi là “kiểm thử tĩnh”.

Dưới đây là giải thích cơ bản về kiểm thử tĩnh. Khác với kiểm thử động, kiểm thử tĩnh không yêu cầu chạy code hoặc xác nhận hoạt động của nó. Cụ thể, có hai phương pháp là “review”, nơi con người kiểm tra nội dung của sản phẩm đầu ra, và “phân tích tĩnh”, sử dụng các công cụ để phân tích và đánh giá mã nguồn hoặc sản phẩm đầu ra. Điểm đặc trưng là cả hai phương pháp này đều không cần chạy code thực tế để đánh giá.

Kiểm thử tĩnh được ứng dụng rộng rãi không chỉ trong các hệ thống yêu cầu độ an toàn cao như cơ sở hạ tầng xã hội, giao thông và y tế mà còn trong nhiều lĩnh vực khác nhau. Ví dụ, không chỉ giới hạn trong phát triển phần mềm, phương pháp “xác nhận mà không cần thao tác đối tượng” còn xuất hiện gần gũi trong cuộc sống hàng ngày.

Một ví dụ quen thuộc là việc chuẩn bị chuyển nhà. Khi chuyển nhà, bạn cần chuẩn bị trước nhiều việc như làm thủ tục với cơ quan hành chính, thay đổi dịch vụ tiện ích sinh hoạt và liên hệ với công ty chuyển nhà. Trong quá trình này, nếu bạn sử dụng danh sách kiểm tra (checklist), bạn có thể đảm bảo không bỏ sót những việc cần làm. Hơn nữa, nếu lập danh sách với sự tư vấn từ người có kinh nghiệm chuyển nhà, bạn có thể chuẩn bị hiệu quả hơn rất nhiều.

Các sản phẩm đầu ra có thể được kiểm tra bằng kiểm thử tĩnh

Trong quá trình phát triển phần mềm, mọi sản phẩm đầu ra đều có thể trở thành đối tượng của kiểm thử tĩnh (bao gồm review hoặc phân tích tĩnh, hoặc cả hai). Dưới đây là một số ví dụ về các đối tượng của kiểm thử tĩnh:

・Tài liệu đặc tả (yêu cầu kinh doanh, yêu cầu chức năng, yêu cầu bảo mật, v.v.)

・Epic, câu chuyện người dùng, tiêu chí chấp nhận

・Kiến trúc và tài liệu thiết kế

・Mã nguồn (code)

・Tài liệu liên quan đến kiểm thử (kế hoạch kiểm thử, trường hợp kiểm thử, quy trình kiểm thử, kịch bản kiểm thử tự động, v.v.)

・Hướng dẫn sử dụng

・Trang web

・Kế hoạch dự án, lịch trình, ngân sách

Như các ví dụ trên, mọi sản phẩm đầu ra mà con người có thể đọc và hiểu được hoặc các công cụ có thể phân tích để phát hiện mâu thuẫn hoặc lỗi đều là đối tượng của kiểm thử tĩnh.

Việc review tập trung vào các sản phẩm đầu ra mà con người có thể đọc hiểu được, chẳng hạn như tài liệu đặc tả, kế hoạch hoặc hướng dẫn sử dụng. Trong khi đó, phân tích tĩnh áp dụng cho các sản phẩm đầu ra có cấu trúc hình thức, chẳng hạn như mã nguồn hoặc mô hình, sử dụng công cụ để đánh giá hiệu quả. Ví dụ, phân tích tĩnh có thể kiểm tra mã nguồn dựa trên quy ước lập trình để giảm thiểu lỗi.

Ngoài ra, các tài liệu được viết bằng ngôn ngữ tự nhiên như tài liệu thiết kế cũng có thể được phân tích bằng cách sử dụng nhận diện ngôn ngữ hoặc phân tích cú pháp để phát hiện lỗi chính tả, ngữ pháp và các biểu đạt mơ hồ.

Lợi ích của kiểm thử tĩnh

Kiểm thử tĩnh có thể được thực hiện ở nhiều giai đoạn khác nhau trong vòng đời phát triển phần mềm. Đặc biệt, các hoạt động review và phân tích tĩnh được thực hiện trước kiểm thử động rất hiệu quả vì giúp phát hiện lỗi ngay từ giai đoạn đầu. Các lỗi được phát hiện ở giai đoạn này thường dễ dàng tìm ra giải pháp khắc phục và có thể xử lý với chi phí thấp.

Ngược lại, các lỗi được phát hiện ở giai đoạn sau của vòng đời thông qua kiểm thử động thường xảy ra trong các điều kiện phức tạp, khiến việc xác định nguyên nhân và sửa chữa trở nên khó khăn hơn. Thêm vào đó, kiểm thử động yêu cầu phải xây dựng môi trường kiểm thử và triển khai các thành phần cần kiểm tra, do đó tốn nhiều công sức chuẩn bị hơn so với kiểm thử tĩnh.

Với kiểm thử tĩnh, việc phát hiện lỗi không cần thực thi mã mà chỉ cần các sản phẩm đầu ra đã được tài liệu hóa. Điều này giúp kiểm thử tĩnh có thể xác định lỗi sớm và hiệu quả ngay từ những giai đoạn đầu của dự án.

Những lợi ích chính của kiểm thử tĩnh:

　・Phát hiện và sửa lỗi hiệu quả trước khi kiểm thử động

　・Phát hiện các lỗi khó tìm thấy bằng kiểm thử động

　・Ngăn chặn lỗi từ giai đoạn yêu cầu và thiết kế, làm rõ các mâu thuẫn, sự mơ hồ, thiếu sót, không chính xác, hoặc dư thừa trong yêu cầu

　・Cải thiện thiết kế và khả năng bảo trì

　・Giảm chi phí và thời gian phát triển

　・Tăng cường giao tiếp giữa các thành viên trong nhóm

　・Yếu tố cần thiết để tăng hiệu quả kiểm thử tĩnh

Để tăng hiệu quả kiểm thử tĩnh, cần hiểu rõ cấu trúc bên trong của phần mềm để thực hiện các đánh giá hiệu quả hơn, giúp xác định nhiều lỗi hơn. Tuy nhiên, kết quả của việc review phụ thuộc vào kiến thức của người tham gia và các công cụ hỗ trợ như danh sách kiểm tra hoặc kinh nghiệm thực tế. Việc lựa chọn người kiểm tra có kinh nghiệm và sử dụng các danh sách kiểm tra (checklist) được xây dựng dựa trên cơ sở tri thức (knowledge base) là cách hiệu quả để tối ưu hóa quy trình kiểm thử tĩnh.

Sự khác biệt giữa kiểm thử tĩnh và kiểm thử động

Kiểm thử tĩnh và kiểm thử động đều nhằm mục đích đánh giá chất lượng sản phẩm đầu ra và xác định sớm các lỗi. Tuy nhiên, mỗi phương pháp lại tập trung vào các loại lỗi khác nhau và có thể bổ sung lẫn nhau để tối ưu hóa hiệu quả.

Để làm rõ sự khác biệt, hãy xem xét một ví dụ: trong thiết kế máy móc chính xác, khoảng hở gọi là “backlash” (khe hở bánh răng) là yếu tố cần thiết. Nếu một kỹ sư thiết kế không biết về backlash và tạo ra bản vẽ không có khe hở, máy móc sẽ không thể hoạt động. Tuy nhiên, nếu người xem xét bản vẽ nhận ra lỗi này nhờ kiến thức về backlash, họ có thể chỉ ra sai sót. Đây là ví dụ của việc phát hiện lỗi qua kiểm thử tĩnh.
Ngược lại, để xác định lượng backlash tối ưu, cần vận hành thực tế máy móc để kiểm tra. Đây là ví dụ về việc phát hiện sự cố qua kiểm thử động.

Đặc điểm chính của kiểm thử tĩnh và kiểm thử động.

　・Kiểm thử tĩnh:

　　▫ Nhằm trực tiếp phát hiện lỗi trong sản phẩm đầu ra như tài liệu, thiết kế, hoặc mã nguồn mà không cần thực thi phần mềm.

　　▫ Hiệu quả hơn về chi phí trong việc phát hiện lỗi so với kiểm thử động.

　　▫ Giúp nhận diện các lỗi logic, mâu thuẫn, hoặc sai sót trong giai đoạn đầu mà không cần điều kiện thực thi cụ thể.

　・Kiểm thử động:

　　▫ Thích hợp để kiểm tra hiệu suất, độ ổn định, và hành vi thực tế của phần mềm trong các kịch bản thực thi.

　　▫ Thông qua các cử động thực tế để kiểm chứng hành vi từ bên ngoài

Các lỗi dễ phát hiện trong kiểm thử tĩnh

・Lỗi yêu cầu: mâu thuẫn, mơ hồ, sự thiếu sót, không chính xác, dư thừa trong yêu cầu 

・Lỗi thiết kế: thuật toán không hiệu quả, kết nối cao, kết hợp thấp

・Lỗi mã nguồn: biến chưa được định nghĩa hoặc không sử dụng, mã không thể đạt tới, mã trùng lặp

・Lệch chuẩn: vi phạm quy tắc mã hóa

・Lỗi giao diện: sử dụng đơn vị khác nhau giữa các hệ thống

・Lỗ hổng bảo mật: tràn bộ đệm, v.v.

・Thiếu sót trong cơ sở kiểm thử: thiếu test case đối với các tiêu chí chấp nhận

Những lỗi này có thể được phát hiện sớm thông qua kiểm thử tĩnh, giúp giảm đáng kể chi phí sửa chữa trong giai đoạn phát triển muộn hoặc khi triển khai vào môi trường sản xuất. Hơn nữa, kiểm thử tĩnh cũng rất hữu ích trong việc tái sử dụng phần mềm và cải thiện tính bảo trì. Việc kiểm tra tính hợp lý của mô-đun hóa và đảm bảo rằng không có lỗi mới bị đưa vào khi tái sử dụng phần mềm là công việc chủ yếu của kiểm thử tĩnh.

Kết hợp kiểm thử tĩnh và kiểm thử động giúp cải thiện chất lượng phần mềm và đồng thời giảm chi phí.Khi nói đến kiểm thử, thông thường người ta nghĩ rằng đó là quá trình thực thi phần mềm và kiểm tra kết quả. Tuy nhiên, trên thực tế, kiểm thử còn bao gồm các công việc như review các sản phẩm đầu ra như yêu cầu, câu chuyện người dùng, mã nguồn hoặc phân tích tĩnh mã nguồn.

※Bài tập kiểm tra:

https://exam-site.briswell-vn.com/startTest/jstqb-7-vn