Tổng quan về Static Testing- Kiểm thử tĩnh phần mềm

kiểm thử tĩnh phần mềm là gì? Những công dụng mà kiểm thử tĩnh phần mềm mang lại là gì? Hãy cùng theo dõi bài viết dưới đây về kiểm thử tĩnh phần mềm để biết thêm thông tin chi tiết và cụ thể về vấn đề này.

kiểm thử tĩnh phần mềm

1. Static testing là gì?

• Ngược lại với dymanic testing (kiểm thử động), kiểm thử động yêu cầu phải chạy phần mềm để test. Còn kiểm thử tĩnh là kĩ thuật kiểm tra các tài liệu (review) và tự động phân tích cú pháp (static analysis) của code hoặc các tài liệu của dự án mà không cần chạy chương trình.
• Cả 2 kĩ thuật của kiểm thử tĩnh đều thực hiện đánh giá code và các work product khác mà không cần thực hiện chạy code.
• Static analysis là quan trọng cho hệ thống đòi hỏi tiêu chí an toàn cao, ví dụ như các phần mềm về hàng không, y khoa...
• Những work product có thể được kiểm tra bởi kiểm thử tĩnh:
  • Đặc tả yêu cầu: requirements, functional requirements, security requirements
  • User stories, acceptance criteria (tiêu chí chấp nhận)
  • Code
  • Tài liệu thiết kế và kiến trúc...
• Review áp dụng cho bất kì work product mà người tham gia cần phải đọc và hiểu
• Static analysis có thể được áp dụng hiệu quả cho bất kì work product nào có cấu trúc tiêu chuẩn (thông thường như code hoặc models), với mỗi work product mà có công cụ phân tích tĩnh phù hợp. Static analysis thậm chí có thể áp dụng với những tool đánh giá work product với ngôn ngữ tự nhiên giống như requirement (ví dụ như kiểm tra chính tả, cú pháp...)

2. Lợi ích của static testing

• Kĩ thuật kiểm thử tĩnh cung cấp rất nhiều lợi ích. Khi áp dụng sớm vào vòng đời phát triển phần mềm, kiểm thử tĩnh có khả năng xác định sớm những defect trước khi thực hiện kiểm thử động (ví dụ các defect trong quá trình review tài liệu requirement, design...)
• Các defect được phát hiện sớm thì chi phí để remove sẽ rẻ hơn nhiều so với việc tìm thấy muộn trong vòng đời phát triển phần mềm, đặc biệt khi so với chi phí bỏ ra khi các defect được phát hiện sau khi phần mềm được deployed và được đưa vào sử dụng.
• Cụ thể các lợi ích của static testing bao gồm:
  • Phát hiện và sửa lỗi hiệu quả hơn trước khi thực hiện kiểm thử động
  • Ngăn chặn những defect trong thiết kế và code bằng cách phát hiện ra sự mâu thuẫn, mơ hồ, thiếu sót, không chính xác.
  • Xác định những defect mà không dễ dàng phát hiện bởi kiểm thử động
  • Tăng hiệu suất phát triển: ví dụ do thiết kế được cải tiến, code dễ bảo trì
  • Giảm thời gian và chi phí phát triển
  • Giảm thời gian và chi phí test

3. Chi tiết về Static testing

Static testing – Được thực hiện mà không phải thực thi code

Từ yêu cầu phía bên trên, thì các coder của chúng ta sẽ phải viết code để làm sao đáp ứng được yêu cầu của người dùng là bấm vào nút mở thì cửa mở và bấm vào nút đóng thì cửa đóng, ví dụ một giả lập như sau:

buttonPressed(){
  if ( Button ==up)
     UpMovement
  else
     DownMovement
}

Static testing sẽ làm gì ở đây, thì đó chính là kiểm tra xem đoạn code mà các coder viết có đúng, có đáp ứng được yêu cầu đó hay không, hoặc có bao phủ được một số các trường hợp cơ bản cần phải có hay không… Static testing sẽ kiểm tra đến từng dòng code, kiểm tra tính logic cũng như việc thực thi được yêu cầu đặt ra. Ở ví dụ trên là ví dụ đơn giản và dòng code mô phỏng thì khá là dễ hình dung cũng như kiểm tra, còn đối với các bài toán thực tế thì nó sẽ rắc rối hơn, yêu cầu kết hợp rất nhiều các điều kiện và các cách xử lý khác nhau, có những hàm, function dài đến cả mấy chục dòng thì việc kiểm tra không phải là đơn giản như ví dụ trên nữa :))

Static testing – Được thực hiện ở giai đoạn Verification (Giai đoạn xác minh)

Giả sử một quy trình sơ bộ để xây dựng sản phẩm như sau:

Từ User Requirement >> System requirement >> Global design >> Detail design >> Implementation

Ở giai đoạn đầu, khi mà ta mới chỉ có các tài liệu yêu cầu, thiết kế mà chưa tiến hành viết code hay thực thi thì việc kiểm thử động là chưa khả thi, vì vậy mà việc sử dụng Static testing trên các tài liệu yêu cầu, hay các bản thiết kế ở giai đoạn này sẽ là phương án phù hợp và hiệu quả.

Góp phần tiết kiệm chi phí cho sản phẩm

Nói Static testing góp phần tiết kiệm chi phí cho sản phẩm là như thế nào? Có nghĩa là những lỗi được tìm ra ở static testing sẽ mất ít chi phí và sửa chữa hơn. Ví dụ như ở trên, tại giai đoạn Verification, từ tài liệu mô tả yêu cầu người dùng, ta có tài liệu mô tả hệ thống, rồi đến các bản thiết kế tổng thể, chi tiết nếu thực hiện tốt static testing sẽ tìm ra được những vấn đề, lỗi (nếu có) được mô tả hoặc thiết kế chưa đúng với yêu cầu của người dùng thì việc sửa chữa cập nhật tài liệu ngay từ những bước đầu này sẽ mất ít chi phí hơn là việc mãi đến giai đoạn Validation mới tìm được ra vấn đề thì sẽ tốn nhiều chi phí không đáng có hơn. Do đó giúp tiết kiệm chi phí cho sản phẩm.

Static testing thực hiện trên các luồng nghiệp vụ, và hoạt động review code.

4. 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

5. 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.

Bài viết trên là những thông tin chi tiết và cụ thể về kiểm thử tĩnh phần mềm. Nếu có những thắc mắc liên quan đến kiểm thử tĩnh phần mềm hãy liên hệ Công ty Luật ACC để được tư vấn và hỗ trợ về vấn đề này.