Kiểm thử phần mềm: Các kỹ thuật tĩnh (Static techniques)

Tiếp tục series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Để tiếp nối nội dung từ bài viết Kiểm thử phần mềm: Các loại kiểm thử (Test types) và kiểm thử bảo trì , trong bài viết lần này, mình sẽ giới thiệu Các kỹ thuật tĩnh (Static techniques)

Kĩ thuật kiểm thử tĩnh (Static testing) cung cấp một phương pháp để cải thiện chất lượng và năng suất của quá trình phát triển phần mềm. Mục đích cốt lõi của kiểm thử tĩnh là để cải thiện chất lượng sản phẩm bằng cách trợ giúp các kĩ sư sớm nhận biết và sửa chữa những lỗi sai của chính họ ngay từ những giai đoạn đầu tiên trong quá trình phát triển phần mềm. Mặc dù kiểm thử tĩnh không giải quyết được hết tất cả các vấn đề nhưng nó có hiệu quả to lớn nhờ có có những yếu tố cấu thành khá ấn tượng. Kiểm thử tĩnh không phải một "phép màu" và nó cũng không thể được xem là một phương pháp thay thế cho Kiểm thử động (Dynamic testing), nhưng tất cả các tổ chức liên quan tới phát triển phần mềm nên coi việc sử dụng kĩ thuật rà soát đánh giá (review) cho tất cả những thành phần chính trong công việc của họ bao gồm yêu cầu (requirements), thiết kế (design), thực hiện (implementation), kiểm thử (testing) và bảo trì (maintenance).

Qua chương 1 và chương 2, chúng ta đã biết mục đích của kiểm thử là: đánh giá, tìm ra những lỗi sai và chất lượng sản phẩm. Kiểm thử chia thành 2 loại: Kiểm thử tĩnh (Static) và kiểm thử động (Dynamic).

I. Khái niệm, phân loại

1. Khái niệm

Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà không thực hiện phần mềm. Điều này ngược với thử nghiệm động. Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu.

• Chủ yếu là kiểm tra cú pháp của code và/hoặc review code (kiểm tra xem code có được viết theo đúng tiêu chuẩn code. Ví dụ cách đặt tên hàm tên biến, cách sử dụng hàm chung đã đưa ra hay chưa) hoặc tài liệu để tìm lỗi bằng cách thủ công. Đây là loại kiểm thử được thực hiện bởi DEV (những người lập trình), làm việc một cách độc lập.

• Lỗi được phát hiện ở giai đoạn phát triển này là ít tốn kém để sửa chữa hơn so với lỗi phát hiện được ở các giai đoạn sau này trong các quy trình phát triển phần mềm.

2. Phân loại

• Đánh giá thủ công (Review manually)
• Dùng công cụ hỗ trợ (Automated Analysis by Tool).

II. Đánh giá (Review)

1. Quy trình

Quy trình Formal review sẽ có 6 bước:

• Lập kế hoạch - Planning
• Bắt đầu - Kick-off
• Chuẩn bị - Preparation
• Họp đánh giá - Review meeting
• Làm lại - Rework
• Follow-up

Giai đoạn 1: Lập kế hoạch

Đây là giai đoạn đầu tiên, quan trọng của quá trình kiểm tra. Ở giai đoạn đầu tiên, chúng ta cần thực hiện các hành động sau:

• Xác định tiêu chuẩn review
• Chọn nhận sự
• Phân bổ vai trò cho từng người
• Xác định tiêu chuẩn đầu ra và đầu vào cho các loại formal review( vd: inspections)
• Chọn các phần của document để review
• Kiểm tra tiêu chuẩn đầu vào

Giai đoạn 2: Bắt đầu

• Mục đích của việc thực hiện buổi họp là để thống nhất quan điểm về tài liệu và thời gian tiến hành.

• Các mối quan hệ giữa tài liệu được review và tài liệu nguồn (source) sẽ được giải thích, đặc biệt khi con số tài liệu liên quan lại lớn.

• Có thể đưa ra thảo luận việc phân chia vai trò, tốc độ kiểm tra, phạm vi kiểm tra, quy trình và những câu hỏi khác ...

Giai đoạn 3: Chuẩn bị

• Những người tham gia review sẽ làm việc biệt lập với nhau sử dụng những tài liệu, quy trình, quy định và checklist liên quan. Người review chịu trách nhiệm phát hiện defect sau đó đặt câu hỏi hay nhận xét dựa trên những hiểu biết cuả bản thân và theo đúng nhiệm vụ. Tất cả các vấn đề được nêu ra đều được ghi chép lại sử dụng các biểu mẫu khai báo. Những lỗi chính tả cũng sẽ được ghi lại trong tài liệu nhưng sẽ không được nhắc đến trong buổi họp.

• Số lượng trang cần kiểm tra mỗi giờ chỉ nên ở khoảng 5-10 trang/giờ.

• Nên sử dụng checklist trong giai đoạn này giúp việc review trở nên hiệu quả và đầy đủ hơn.

Giai đoạn 4: Họp đánh giá

Buổi họp bao gồm những phần sau: giai đoạn khai thác thông tin, giai đoạn thảo luận và giai đoạn đưa ra
quyết định.

• Giai đoạn khai thác thông tin: Chuẩn bị (Xác định) các lỗi sẽ đưa ra thảo luận. Lưu ý không thảo luận trong giai đoạn này. và ghi chép lại các lỗi đó
• Giai đoạn thảo luận: Thảo luận các lỗi đã đưa ra ở giai đoạn khai thác thông tin: liệu một vấn đề nào đó có phải là lỗi (defect) hay không? Đánh giá mức độ nghiêm trọng của lỗi...
• Giai đoạn đưa ra quyết định: những người tham gia phải đưa ra quyết định về tài liệu đang được đánh giá.

Giai đoạn 5: Làm lại

• Dựa trên kết quả của những defect đã được tìm ra, tác giả sẽ dần dần từng bước chỉnh sửa cập nhật tài liệu.

• Những thay đổi được thực hiện trên tài liệu nên được xác định tại bước follow-up. Vì vậy, tác giả cần trình bày chỉ ra nơi những thay đổi đã được thực hiện. Ví dụ sử dụng các chức năng “Track changes” của các phần mềm xử lí văn bản.

Giai đoạn 6: Follow-up

• Kiểm tra đảm bảo rằng tác giả đã thực hiện thay đổi trên tất cả các lỗi được báo cáo
• Thu thập một số các số liệu đo lường tại mỗi bước của quy trình để kiểm soát và tối ưu quy trình review

2. Vai trò, trách nhiệm của các thành phần tham gia review

• Moderator: Dẫn dắt/điều phối các buổi họp review, thực hiện các task: lên kế hoạch, thực hiện họp, follow sau khi họp để đảm bảo kiểm soát chất lượng đầu vào đầu ra của quy trình đánh giá. Ngoài ra, Moderator sẽ sắp xếp các cuộc họp, phổ biến tài liệu trước khi họp, đào tạo các thành viên khác trong nhóm, và lưu trữ dữ liệu được thu thập.
• Tác giả (Author): là người viết tài liệu. Tác giả có trách nhiệm chỉnh sửa các lỗi tìm được trong tài liệu, luôn tìm hiểu để nâng cao chất lượng tài liệu
• Người đánh giá (Reviewers): là các cá nhân có kiến thức về kỹ thuật hoặc nghiệp vụ, tham gia vào chuẩn bị, xác định và mô tả lỗi. (Nên chọn người đánh giá ở các vai trò khác nhau)
• Người viết (Scribe hay recorder): là người ghi chép lại tất cả các issues, vấn đề, điểm mở trong từng buổi review, từng giai đoạn review. Việc sử dụng checklist hoặc xem các sản phẩm có liên quan giúp review hiệu quả hơn, phát hiện nhiều lỗi hơn.
• Các nhà lãnh đạo (Manager): Là người quyết định có thực hiện review hay không, phân bổ thời gian trong lịch trình của dự án và xác định mục tiêu của quy trình đánh giá đã được đá ứng hay chưa, quan tâm đến các buổi đào tạo mà người tham gia yêu cầu.

3. Các yếu tố ảnh hưởng đến sự thành công của các quy trình đánh giá

• Tìm được Moderator có thể dẫn dắt tất cả các giai đoạn của dự án, Moderator cần có chuyên môn, sự nhiệt tình và tư duy thực tế để hướng dẫn, dẫn dắt người tham gia, quyền hạn của Moderator phải rõ ràng
• Khi tổ chức review phải có mục đích rõ ràng
• Mời đúng những người cần tham gia vào review
• Tester là người rất có giá trị khi tham gia vào review
• Không cố giấu các lỗi được tìm thấy
• Vấn đề rắc rối về con người và khía cạnh tâm lý cần được giải quyết
• Review được thực hiện trong bầu không khí tin tưởng, kết quả của nó không được dùng để đánh giá những người tham gia.
• Các kỹ thuật review được dung phù hợp để đạt được mục đích
• Checklist hoặc vai trò được sử dụng nếu phù hợp sẽ tăng hiệu quả tìm ra lỗi
• Cần thực hiện đào tạo về kỹ thuật review đặc biệt là các kỹ thuật chính thống như inspection
• Sự hỗ trợ của lãnh đạo rất quan trọng để có quy trình review tốt (bố trí đủ thời gian cho hoạt động review trong dự án) Nhấn mạnh vào việc học và cải tiến quy trình

4. Phân loại đánh giá

Informal review

• Informal review là quá trình đánh giá mà không cần hồ sơ cuộc họp đang lưu trữ, cũng không cần ghi chép lại nội dung cuộc họp. Nó được thực hiện ở bất cứ 1 tài liệu nào.
• Informal review chủ yếu được thực hiện giữa 2 người ở bất kỳ đâu có thể là quán cà phê, căng-ten,...
• Lợi ích mà informal review mang lại:
• Không tốn kém
• Tiết kiệm thời gian
• Không yêu cầu đào tạo người tham gia
• Không cần tài liệu hay lưu trữ hồ sơ

Hướng dẫn (Walkthrough)

• Tác giả hướng dẫn, giải thích (chuyển giao kiến thức) với những người tham gia thông qua tài liệu và thông qua quá trình tư duy của họ để đạt được một sự hiểu biết chung và thu thập phản hồi liên quan đến chủ đề theo tài liệu.
• Các cuộc họp do các tác giả hướng dẫn, thường có người ghi chép riêng.
• Các kịch bản và chạy thử có thể được dùng để xác nhận nội dung.
• Việc chuẩn bị cuộc họp sẵn riêng cho người đánh giá là không bắt buộc.

Đánh giá kỹ thuật (Technical Review)

• Đánh giá kỹ thuật là một cuộc thảo luận tập trung vào việc đạt được sự đồng thuận nội dung kỹ thuật của một tài liệu.
• Được dẫn dắt bởi moderator hoặc người có kiến thức kỹ thuật với sự tham gia của các chuyên gia như: Thiết kế, người dùng chính...
• Cần chuẩn bị một Review Report bao gồm: danh sách các phát hiện defect, cách giải quyết...
• Mục đích chính: thảo luận, đưa ra quyết định, đánh giá sự thay thế, tìm defect, giải quyết vấn đề kỹ thuật và kiểm tra sự phù hợp của spec, plan, regulation và standards

Kiểm tra (Inspection)

• Được điều hành bởi moderator
• Sử dụng để xác định các vai trò trong quy trình.
• Xác định vai trò của từng người
• Xác định các tiêu chuẩn đầu vào và ra cho của sản phẩm phần mềm
• Cần có báo cáo kiểm tra bao gồm danh sách của các phát hiện defect,..
• Có Quy trình follow- up
• Mục đích chính: tìm kiếm defects
• Các số liệu được tập hợp và phân tích để tối ưu hóa quy trình

II. Phân tích tĩnh bằng công cụ

• Mục tiêu của static analysis by tool là để tìm ra lỗi trong code và mô hình phát triển phần mềm
• Static analysis được hiện bằng tool và không cần chạy code, chỉ ra các lỗi mà khó tìm được trong dynamic testing
• Giống nhw review , Static analysis tìm ra defects hơn là failures, dựa trên phân tích code (control flow, data flow)
• Giá trị của Static Analysis:
• Sớm phát hiện được defect trước khi chạy test
• Cảnh báo sớm về những khía cạnh đáng ngờ của code hoặc thiết kế bằng các tính toán số liệu, chẳng hạn như một độ đo sư phức tạp cao
• Xác định các defects không dễ dàng tìm được bởi dynamic testing
• Phát hiện phụ thuộc và không nhất quán trong các mô hình phần mềm như các links
• Cải thiện khả năng bảo trì của code và thiết kế
• Ngăn ngừa các defects
• Các loại lỗi điển hình được tìm thấy bởi Static Analysis:
• Tham chiếu tới một biến với một giá trị không xác định
• Giao tiếp không đồng nhất giữa các module và các thành phần
• Tìm ra các biến không được sử dụng hoặc kê khai không đúng
• Đoạn code không chạy đến ( hay đã chết)
• Thiếu và logic sai lầm ( vòng có khả năng vô hạn)
• Cấu trúc quá phức tạp
• Vi phạm tiêu chuẩn lập trình
• Lỗ hổng bảo mật
• Vi phạm cú pháp của mã và mô hình phần mềm

Static Analysis by tool thường được sử dụng bởi developer trước hoặc trong khi test component và test integration hoặc khi kiểm tra trong code với tool quản lý cấu hình, và bởi Designer trong mô hình hóa phần mềm.

Link bài viết tiếp theo Các kỹ thuật thiết kế kiểm thử (Phần 1).