Chỉ số code (code metrics)
Như đã nêu, khi thực hiện phân tích mã tĩnh, thông thường thông tin được được tính toán về các thuộc tính cấu trúc của mã, chẳng hạn như tần suất nhận xét, độ sâu, độ phức tạp và sốlượng dòng code.
Thông tin này có thể được tính toán không chỉ trong thiết kế và code được tạo ra mà còn được tính toán khi các thay đổi được thực hiện trong hệ thống, để xem liệu rằng thiết kế hoặc code có trở nên lớn hơn, phức tạp hơn, khó hiểu hơn và khó duy trì hơn không hiểu. Các phép đo cũng giúp việc quyết định trong sốcác lựa chọn thay thế thiết kế, đặc biệt là khi thiết kế lại các phần của code hiện có.
Có nhiều loại thước đo cấu trúc khác nhau, mỗi loại cho biết điều gì đó về nỗ lực cần thiết để viết code ngay từ đầu (để hiểu code khi thực hiện thay đổi hoặc để kiểm thử mã bằng các công cụ hoặc kỹ thuật cụ thể).
Các lập trình viên có kinh nghiệm biết rằng 20% code sẽ gây ra 80% vấn đề và phân tích độ phức tạp giúp tìm ra 20% cực kỳ quan trọng đó, liên quan đến nguyên tắc phân cụm lỗi như đã giải thích trong Chương 1.
Chỉ số độ phức tạp (Complexity) xác định rủi ro cao, các vùng phức tạp.
Chỉ số độ phức tạp theo chu kỳ (cyclomatic complexity) dựa trên số lượng quyết định trong một chương trình. Điều quan trọng đối với người kiểm thử vì nó cung cấp dấu hiệu về số lượng bài kiểm thử cần thiết (bao gồm cả rà soát) để tránh các lỗi trên thực tế. Nói cách khác, vùng code được xác định phức tạp hơn là những ứng cử viên cho việc rà soát và bài kiểm thử động bổ sung. Mặc dù có nhiều cách để tính toán độ phức tạp chu trình, cách dễ nhất là tính tổng số câu lệnh quyết định nhị phân (ví dụ: if, while, for, v.v.) và sau đó cộng thêm 1 vào. Định nghĩa chính thức hơn về các quy tắc tính toán được cung cấp trong bảng thuật ngữ (the glossary).
Dưới đây là một chương trình đơn giản làm ví dụ:
Luồng điều khiển được tạo từ chương trình sẽ giống như Hình 3.2.
Luồng điều khiển hiển thị bảy nút (hình) và tám cạnh (đường), do đó, sử dụng công thức chính thức, độ phức tạp của chu trình là 8 – 7 + 2 = 3. Trong trường hợp này, không có biểu đồ nào được gọi hoặc chương trình con.
Ngoài ra, có thể tính toán độ phức tạp của chu trình bằng cách sử dụng quy tắc điểm quyết định. Vì có hai điểm quyết định nên độ phức tạp của chu trình là 2 + 1 = 3.
Cấu trúc code
Có nhiều loại đo chỉ số cấu trúc khác nhau, mỗi loại cho biết điều gì đó về nỗ lực cần thiết để viết code ngay từ đầu, để hiểu code khi thực hiện thay đổi hoặc để kiểm thử code bằng cách sử dụng các công cụ hoặc kỹ thuật cụ thể. Người ta thường cho rằng một mô-đun lớn mất nhiều thời gian hơn để xác định, thiết kế, viết code và kiểm thử so với một mô-đun nhỏ hơn. Nhưng trên thực tế, cấu trúc của code đóng một vai trò quan trọng.
Một số khía cạnh của cấu trúc code để cân nhắc:
- Cấu trúc luồng điều khiển
- Cấu trúc luồng dữ liệu
- Cấu trúc dữ liệu.
Cấu trúc luồng điều khiển giải quyết trình tự mà trong đó các hướng dẫn được thực hiện. Khía cạnh cấu trúc này phản ánh sự lặp đi lặp lại và vòng lặp trong thiết kế của một chương trình. Nếu chỉ có kích thước của một chương trình được đo lường, không có thông tin nào được cung cấp về việc tần suất một hướng dẫn được thực hiện khi nó được chạy. Phân tích luồng điều khiển cũng có thể được được sử dụng để xác định code không thể truy cập (đã chết). Trong thực tế, nhiều chỉ số code liên quan đến cấu trúc luồng điều khiển, ví dụ: số lượng cấp độ lồng nhau hoặc độ phức tạp chu trình.
Cấu trúc luồng dữ liệu đi theo dấu vết của mục dữ liệu khi nó được truy cập và sửa đổi trong code. Nhiều lần, các giao dịch được áp dụng cho dữ liệu phức tạp hơn các hướng dẫn thực hiện chúng. Do đó, bằng cách sử dụng các phép đo luồng dữ liệu, dữ liệu sẽ hoạt động như thế nào khi chúng được chuyển đổi bởi chương trình. Lỗi có thể được tìm thấy thông qua việc tham chiếu biến giá trị với một giá trị không xác định và các biến mà chưa bao giờ được sử dụng.
Cấu trúc dữ liệu đề cập đến việc tổ chức bản thân dữ liệu, độc lập với chương trình. Khi dữ liệu được sắp xếp dưới dạng danh sách, hàng đợi, ngăn xếp hoặc cấu trúc được xác định rõ khác, các thuật toán để tạo, sửa đổi hoặc xóa chúng cũng có nhiều khả năng được xác định rõ hơn. Như vậy, cấu trúc dữ liệu cung cấp nhiều thông tin về việc khó khăn trong việc viết chương trình để xử lý dữ liệu và trong việc thiết kế các ca kiểm thử để chỉ ra tính đúng đắn của chương trình. Nghĩa là, đôi khi một chương trình phức tạp vì nó có cấu trúc dữ liệu phức tạp, chứ không phải vì kiểm soát phức tạp hoặc luồng dữ liệu.
Điều quan trọng đối với tester là phải biết rằng các biện pháp phân tích tĩnh được đề cập ở trên có thể được sử dụng làm tín hiệu cảnh báo sớm về mức độ tốt của code khi nó được hoàn thành.
Tóm lại, giá trị của phân tích tĩnh đặc biệt dành cho:
- Phát hiện sớm các lỗi trước khi thực hiện kiểm thử;
- Cảnh báo sớm về các khía cạnh đáng ngờ của code, thiết kế hoặc yêu cầu;
- Xác định các lỗi không dễ tìm thấy trong kiểm thử động;
- Cải thiện khả năng bảo trì code và thiết kế do các kỹ sư làm việc theo các tiêu chuẩn và quy tắc được lập thành văn bản;
- Ngăn ngừa lỗi, với điều kiện là các kỹ sư sẵn sàng học hỏi từ lỗi của họ và thực hành cải tiến liên tục.
Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây
