Các nội dung sẽ có trong bài thi ISTQB Foundation (CTFL)
- Mô tả mục tiêu của phân tích tĩnh và so sánh với kiểm thử động. (K2)
- Biết được các lỗi điển hình được xác định bằng phân tích tĩnh và so sánh chúng với các đánh giá và kiểm thử động. (K1)
- Liệt kê được lợi ích điển hình của việc phân tích tĩnh. (K1)
- Liệt kê các lỗi về thiết kế và mã (code) điển hình có thể được xác định bằng các công cụ phân tích tĩnh. (K1)
Có nhiều việc phải làm khi kiểm thử sản phẩm phần mềm mà không thực sự chạy hệ thống. Ví dụ, như đã thấy trong phần trước rằng, có thể rà soát cẩn thận các yêu cầu, thiết kế, mã nguồn, kế hoạch kiểm thử, v.v. để tìm lỗi và khắc phục chúng trước khi giao sản phẩm cho khách hàng. Trong phần này, tập trung vào một loại kiểm thử tĩnh khác, trong đó kiểm thử cẩn thận các yêu cầu, thiết kế và mã, thường là với sự hỗ trợ của các công cụ tự động để tìm ra các lỗi bổ sung trước khi mã nguồn thực sự được chạy. Như vậy, cái được gọi là phân tích tĩnh (static analysis) chỉ là một hình thức kiểm thử khác của công việc kiểm thử.
Phân tích tĩnh là kiểm tra các yêu cầu, thiết kế và mã khác với kiểm thử động truyền thống theo một số cách quan trọng:
- Phân tích tĩnh được thực hiện trên các tài liệu yêu cầu, thiết kế hoặc mã mà không thực sự thực thi phần mềm đang được kiểm thử.
- Phân tích tĩnh được thực hiện một cách lý tưởng trước các loại rà soát chính thức được thảo luận trong Mục 3.2.
- Phân tích tĩnh không liên quan đến các thuộc tính động của yêu cầu, thiết kế và mã, chẳng hạn như phạm vi kiểm thử.
- Mục tiêu của phân tích tĩnh là tìm ra các lỗi, cho dù chúng có thể gây ra lỗi hay không. Cũng giống như đánh giá, phân tích tĩnh tìm ra lỗi khiếm khuyết (defects) hơn là lỗi thất bại (failures).
Để phân tích tĩnh, có nhiều công cụ và hầu hết chúng tập trung vào mã phần mềm. Các công cụ phân tích tĩnh thường được các nhà phát triển sử dụng trước (và đôi khi là trong) quá trình kiểm thử thành phần và kiểm thử tích hợp cũng như bởi các nhà thiết kế trong quá trình lập trình phần mềm.
Các công cụ có thể hiển thị không chỉ các thuộc tính cấu trúc (số liệu mã), chẳng hạn như độ phức tạp hoặc số chu kỳ và kiểm tra các tiêu chuẩn mã hóa, mà còn mô tả đồ họa về luồng điều khiển của luồng dữ liệu, mối quan hệ dữ liệu và số lượng đường dẫn riêng biệt từ dòng mã này sang dòng mã khác. Ngay cả trình biên dịch (compiler) cũng có thể được coi là một công cụ phân tích tĩnh, vì nó xây dựng một bảng biểu tượng, chỉ ra cách sử dụng không chính xác và kiểm tra sự không tuân thủ các quy ước ngôn ngữ mã hóa (cú pháp).
Một trong những lý do để sử dụng phân tích tĩnh (tiêu chuẩn mã hóa và những thứ tương tự) có liên quan đến đặc điểm của chính ngôn ngữ lập trình.
Người ta có thể nghĩ rằng các ngôn ngữ này an toàn để sử dụng, bởi vì ít nhất ủy ban tiêu chuẩn biết các vấn đề nằm ở đâu. Nhưng điều này có thể sẽ là sai.
Bổ sung vào các lỗ hổng do quá trình tiêu chuẩn hóa để lại, mặc dù được xác định rõ ràng, các lập trình viên vẫn tiếp tục báo cáo các tính năng của ngôn ngữ, dẫn đến các chế độ lỗi dễ nhận biết. Vào cuối những năm 1990, khoảng 700 sự cố bổ sung này đã được xác định trong tiêu chuẩn C. Rõ ràng là có tồn tại các kiểu lỗi như vậy. Có thể chứng minh rằng chúng thường thoát khỏi sự giám sát kỹ lưỡng của kiểm thử động thông thường, mà sau đó xuất hiện ở sản phẩm thương mại. Những vấn đề này có thể được tìm thấy bằng cách sử dụng các công cụ phân tích tĩnh để phát hiện chúng. Trên thực tế, nhiều trong số 700 chế độ lỗi được báo cáo trong tiêu chuẩn C có thể được phát hiện theo cách này! Trong một chương trình C điển hình, có trung bình khoảng tám lỗi như vậy trên 1000 dòng mã nguồn; chúng được nhúng trong mã được phát hành, chỉ chờ để khiến mã bị lỗi [Hatton, 1997].
Kiểm thử động đơn giản là không phát hiện ra chúng. C không phải là thủ phạm ở đây; bài tập này có thể được thực hiện cho các ngôn ngữ khác với kết quả tương tự.
Tất cả các ngôn ngữ lập trình đều có vấn đề và lập trình viên không thể cho rằng chúng được bảo vệ chống lại các vấn đề đó. Và không có gì trong quá trình tiêu chuẩn hóa ngôn ngữ quốc tế hiện tại sẽ ngăn cản điều này xảy ra trong tương lai.
Các tính năng khác nhau của các công cụ phân tích tĩnh được thảo luận bên dưới, đặc biệt tập trung vào các công cụ phân tích mã tĩnh vì đây là những công cụ phổ biến nhất trong thực tế hàng ngày. Lưu ý rằng các công cụ phân tích tĩnh phân tích mã phần mềm, cũng như đầu ra được tạo như HTML và XML.
Tiêu chuẩn lập trình
Kiểm tra việc tuân thủ các tiêu chuẩn lập trình chắc chắn là tính năng nổi tiếng nhất trong tất cả các tính năng. Hành động đầu tiên được thực hiện là xác định hoặc áp dụng một tiêu chuẩn lập trình.
Thông thường, một tiêu chuẩn lập trình bao gồm một bộ quy tắc lập trình (ví dụ: “Luôn kiểm tra giá trị biên trên một mảng khi sao chép vào mảng đó”), quy ước đặt tên (ví dụ: “Các lớp nên bắt đầu bằng chữ C viết hoa”) và đặc tả bố cục (ví dụ: “Thụt lề 4 dấu cách”). Đó là khuyến cáo rằng các tiêu chuẩn hiện có được thông qua. Ưu điểm chính của việc này là nó tiết kiệm rất nhiều công sức. Một lý do bổ sung để áp dụng phương pháp này là nếu bạn sử dụng một tiêu chuẩn lập trình nổi tiếng thì có thể sẽ có các công cụ kiểm tra hỗ trợ tiêu chuẩn này.
Nó thậm chí có thể được đặt theo cách khác: mua một bộ phân tích mã tĩnh và tuyên bố (một lựa chọn) các quy tắc trong đó làm tiêu chuẩn lập trình. Nếu không có những công cụ như vậy, việc thực thi tiêu chuẩn lập trình trong một tổ chức có thể sẽ thất bại.
Có ba nguyên nhân chính dẫn đến điều này: số lượng quy tắc trong một tiêu chuẩn viết mã thường quá lớn nên không ai có thể nhớ hết; một số quy tắc nhạy cảm theo ngữ cảnh yêu cầu đánh giá một số tệp rất khó kiểm tra bởi con người; và nếu mọi người dành thời gian kiểm tra các tiêu chuẩn lập trình trong các bài rà soát, điều đó sẽ khiến họ mất tập trung vào các lỗi khác mà họ có thể tìm thấy, khiến quá trình rà soát trở nên kém hiệu quả hơn.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
