ISTQB – Chương 3 – Static techniques (Kỹ thuật tĩnh) – Mục 3.1

Các kỹ thuật kiểm thử tĩnh cung cấp một cách thức mạnh mẽ giúp cải thiện chất lượng và năng suất phát triển phần mềm. Chương này mô tả các kỹ thuật kiểm thử tĩnh, bao gồm các đánh giá và cung cấp tổng quan về cách chúng được tiến hành. Mục tiêu cơ bản của kiểm thử tĩnh là cải thiện chất lượng của các sản phẩm phần mềm bằng cách hỗ trợ các kỹ sư nhận ra và sửa lỗi sớm trong quá trình phát triển phần mềm.

Mặc dù kỹ thuật kiểm thử tĩnh sẽ không giải quyết được tất cả các vấn đề, nhưng chúng cực kỳ hiệu quả. Kỹ thuật tĩnh có thể cải thiện cả chất lượng và năng suất nhờ các yếu tố ấn tượng.

Kiểm thử tĩnh không phải là phép thuật và không nên được coi là sự thay thế cho kiểm thử động, nhưng tất cả các tổ chức phần mềm nên cân nhắc sử dụng việc rà soát trong tất cả các khía cạnh chính của công việc, bao gồm các yêu cầu, thiết kế, triển khai, kiểm thử và bảo trì. Các công cụ phân tích tĩnh thực hiện kiểm thử một cách tự động, ví dụ: trên mã (on code).

RÀ SOÁT VÀ QUY TRÌNH KIỂM THỬ

Các nội dung có thể xuất hiện trong đề thi

  1. Nhận biết các sản phẩm công việc phần mềm có thể được kiểm thử bởi các kỹ thuật tĩnh. (K1)
  2. Mô tả tầm quan trọng và giá trị của việc xem xét các kỹ thuật tĩnh để đánh giá các sản phẩm công việc phần mềm. (K2)
  3. Giải thích sự khác biệt giữa kỹ thuật tĩnh và kỹ thuật động. (K2)

Trong Chương 1, một số thuật ngữ về kiểm thử đã được trình bày. Ngoài ra, kiểm thử chính bản thân nó cũng đã được định nghĩa. Định nghĩa  về kiểm thử tĩnh được lặp lại ở đây như một phương tiện để giải thích hai loại kiểm thử chính.

Định nghĩa về kiểm thử vạch ra các mục tiêu liên quan đến đánh giá, bộc lộ các khiếm khuyết (defect) và chất lượng. Như đã chỉ ra trong định nghĩa, hai phương pháp có thể được sử dụng để đạt được các mục tiêu này là kiểm thử tĩnh (static testing) và kiểm thử động (dynamic testing).

Với các phương pháp kiểm thử động, phần mềm được thực thi bằng cách sử dụng một tập hợp các giá trị đầu vào và đầu ra, sau đó được kiểm thử và so sánh với kết quả mong đợi. Trong quá trình kiểm thử tĩnh, các sản phẩm công việc phần mềm được kiểm thử thủ công, hoặc bằng bộ công cụ, nhưng KHÔNG được thực thi. Do đó, kiểm thử động chỉ có thể được áp dụng cho mã phần mềm. Thực thi động được áp dụng như một kỹ thuật để phát hiện lỗi và xác định các thuộc tính chất lượng của mã. Tùy chọn kiểm thử này không áp dụng cho phần lớn các sản phẩm công việc phần mềm.

Trong số các câu hỏi phát sinh là: Làm thế nào có thể đánh giá hoặc phân tích một tài liệu yêu cầu, tài liệu thiết kế, kế hoạch kiểm thử hay hướng dẫn sử dụng? Làm thế nào có thể kiểm tra trước mã nguồn một cách hiệu quả trước khi thực thi?

Một kỹ thuật mạnh mẽ có thể được sử dụng là kiểm thử tĩnh, ví dụ: rà soát (reviews). Về nguyên tắc, tất cả các sản phẩm công việc phần mềm đều có thể được kiểm thử bằng các kỹ thuật rà soát.

Kiểm thử động và kiểm thử tĩnh là các phương pháp bổ sung cho nhau, vì chúng có xu hướng tìm ra các loại lỗi khác nhau một cách hiệu quả. Các loại lỗi dễ tìm thấy hơn trong quá trình kiểm thử tĩnh là:

  • Sai lệch so với tiêu chuẩn,
  • Thiếu yêu cầu, lỗi thiết kế,
  • Mã không thể bảo trì, và
  • Thông số kỹ thuật giao diện không nhất quán.

Lưu ý rằng trái ngược với kiểm thử động, kiểm thử tĩnh tìm ra lỗi khiếm khuyết(defects) hơn là lỗi thất bại (failures).

Ngoài việc tìm ra lỗi khiếm khuyết (defect), mục tiêu của rà soát cũng thường là thông tin, truyền thông và giáo dục, theo đó những người tham gia tìm hiểu về nội dung của các sản phẩm công việc phần mềm để giúp họ hiểu được vai trò của công việc và lập kế hoạch cho các giai đoạn phát triển trong tương lai.

Rà soát thường đại diện cho các mốc quan trọng của dự án và hỗ trợ việc thiết lập đường cơ sở cho một sản phẩm phần mềm. Loại và số lượng lỗi được tìm thấy trong quá trình rà soát cũng có thể giúp người kiểm thử tập trung vào công việc kiểm thử của họ và chọn các lớp kiểm thử hiệu quả. Trong một số trường hợp, khách hàng/người dùng tham dự cuộc họp rà soát và cung cấp phản hồi cho nhóm phát triển, vì vậy rà soát cũng là một phương tiện giao tiếp giữa khách hàng/người dùng.

Các nghiên cứu đã chỉ ra rằng nhờ rà soát, có thể đạt được sự gia tăng đáng kể về năng suất và chất lượng sản phẩm [Gilb và Graham, 1993], [van Veenendaal, 1999]. Giảm số lượng lỗi sớm trong vòng đời sản phẩm cũng có nghĩa là phải dành ít thời gian hơn cho việc kiểm thử và bảo trì.

Tóm lại, việc sử dụng kiểm thử tĩnh, ví dụ: rà soát (reviews), về các sản phẩm công việc phần mềm có nhiều ưu điểm khác nhau:

  • Vì kiểm thử tĩnh có thể bắt đầu sớm trong vòng đời nên có thể giúp đưa ra phản hồi sớm về các vấn đề chất lượng, ví dụ: xác nhận sớm các yêu cầu của người dùng chứ không chỉ ở trong kiểm thử chấp nhận.
  • Bằng cách phát hiện lỗi ở giai đoạn đầu, chi phí để sửa chữa thường tương đối thấp và do đó có thể đạt được sự cải tiến tương đối về chất lượng của sản phẩm phần mềm.
  • Do nỗ lực phải làm lại giảm đáng kể nên năng suất phát triển số liệu có khả năng tăng lên.
  • Việc đánh giá theo nhóm có thêm lợi thế là có sự trao đổi thông tin giữa những người tham gia.
  • Kiểm thử tĩnh góp phần nâng cao nhận thức về các vấn đề chất lượng.

Tóm lại, kiểm thử tĩnh là một phương pháp rất phù hợp để cải thiện chất lượng sản phẩm công việc phần mềm. Điều này chủ yếu được áp dụng cho chính bản thân các sản phẩm được rà soát, nhưng điều quan trọng nữa là, việc cải thiện chất lượng không phải đạt được một lần mà là có tính chất cấu trúc hơn.

Phản hồi từ quy trình kiểm thử tĩnh đến quy trình phát triển cho phép cải tiến quy trình, hỗ trợ tránh các lỗi tương tự mắc phải trong tương lai.

Bản gốc Tiếng Anh các bạn có thể Tải về Tại đây.

Ezami

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *