STATIC TESTING – KIỂM THỬ TĨNH

1. Static Testing là gì?

Static testing là hoạt động kiểm tra thủ công (hoặc sử dụng công cụ) các sản phẩm phần mềm mà không cần thực thi code. Khác với Dynamic testing đó là kỹ thuật cần thực thi code. Kiểm thử tĩnh được thực hiện để tránh lỗi sớm trong giai đoạn đầu phát triển phần mềm, nó cũng dễ dàng xác định lỗi và giải quyết lỗi. Nó còn giúp tìm kiếm lỗi mà có thể không tìm thấy ở Dynamic testing.

Static testing có thể thực hiện mà không cần máy tính vì sản phẩm được kiểm tra mà không cần thực thi. Hầu hết các kỹ thuật kiểm tra tĩnh được sử dụng để kiểm tra bất kỳ dạng tài liệu nào, bao gồm source code, design, models hoặc các tài liệu đặc tả.

Có 2 loại chính của kỹ thuật kiểm thử tĩnh là:

Kiểm thử thủ công hay còn gọi là các hoạt động review.

Kiểm thử tự động là sử dụng các tool để phân tích.

Kiểm tra tĩnh có thể được thực hiện trên các tài liệu làm việc như yêu cầu kỹ thuật (requirement), tài liệu thiết kế (documents) , mã nguồn (Source code), kế hoạch kiểm tra (Test plan), kịch bản thử nghiệm (test script) và các trường hợp thử nghiệm (test case) , nội dung trang web

2. Lợi ích của Static Testing

Vì Static testing được thực hiện sớm nên nó đưa ra các phản hồi về chất lượng của sản phẩm một cách nhanh chóng.
Các khiếm khuyết được tìm thấy ở giai đoạn đầu nên giảm chi phí và thời gian phát triển.
Năng suất công việc có khả năng cao hơn vì effort cho việc chỉnh sửa, làm lại thấp hơn.
Giảm chi phí và thời gian thực hiện kiểm thử
Giảm tổn chi phí chất lượng trong suốt vòng đời phần mềm, do ít lỗi hơn trong vòng đời sau hoặc sau khi sản phẩm đã đưa vào vận hành.
Cải thiện việc giao tiếp giữa các thành viên trong team thông qua quá trình thảo luận, đánh giá.

3. Quy trình thực hiện Static Testing

Quy trình review gồm 5 hoạt động chính:

Planning
Initiate review
Individual review
Issue communication and analysis
Fixing and report

Planning

Xác định scope, bao gồm mục đích của review, những tài liệu or 1 phần tài liệu để review, và các đặc điểm chất lượng để đánh giá
Ước lượng effort và khung thời gian
Xác định các đặc điểm review như là loại review với roles, activities, và checklist
Lựa chọn người để tham gia review và phân bổ vai trò
Xác định tiêu chí đầu vào và đầu ra cho mỗi loại formal review
Kiểm tra tiêu chí đầu vào được đáp ứng

Initiate review

Phân phối sản phẩm làm việc và vật liệu khác như là form log issue, checklists, và liên quan đến sản phẩm làm việc
Giải thích về scope, mục tiêu, process, roles, và sản phẩm đến những thành viên tham gia
Trả lời cho bất kỳ câu hỏi nào mà thành viên có thể có trong buổi review

Individual review

Review tất cả or 1 phần sản phẩm
Ghi lại những lỗi tiềm năng, recommendations và question

Issue communication and analysis

Truyền đạt các lỗi tiền năng đã được xác định
Phân tích lỗi tiềm năng, chỉ định quyền sở hữu và trạng thái cho nó
Đánh giá và ghi lại các đặc tính chất lượng
Đánh giá lại các phát hiện được tìm thấy với tiêu chí đầu ra để ra quyết định review

Fixing and report

Tạo report lỗi
Fix lỗi tìm thấy
Thông báo lỗi cho mọi người
Ghi lại, update lại trạng thái của lỗi
Tập hợp số liệu (những loại formals review)
Kiểm tra tiêu chí đầu ra được đáp ứng
Chấp nhận sản phẩm khi tiêu chí đầu ra đạt được

4. Static Testing bao gồm những loại nào?

Testing review là gì?

Review trong static testing là 1 quy trình hay 1 cuộc họp được tiến hành để tìm kiếm những lỗi tiềm năng trong thiết kế hoặc chương trình bất kỳ. Một ý nghĩa khác của review là tất cả các thành viên trong nhóm đều biết tiến độ của project và đôi khi sự đa dạng về suy nghĩ có thể dẫn đến những đề xuất tuyệt vời.

Các thành phần tham gia review:

Moderator: Thực hiện kiểm tra đầu vào, theo dõi làm lại, huấn luyện thành viên của team, lên lịch trình meeting
Author: Chịu trách nhiệm fix những lỗi được tìm thấy và cải thiện chất lượng tài liệu
Scribe: Ghi lại những vấn đề xảy ra, log bug và tham dự review meeting
Reviewer: Kiểm tra tài liệu xem có defect và thanh tra
Manager: Quyết định thực hiện review và đảm bảo mục tiêu được đáp ứng

Inspection: Ở đây mục đích chính là tìm ra các khiếm khuyết. Việc kiểm tra được thực hiện bởi người kiểm duyệt. Đây là loại đánh giá thông thường có một danh sách kiểm tra được chuẩn bị để kiểm tra xem tài lài liệu công việc hoàn thành tới đâu.

Walk-through: Trong loại kỹ thuật này, Leader mở một cuộc họp để giải thích sản phẩm. Những người tham gia có thể đặt ra những câu hỏi nếu chưa hiểu và ghi chú lại, phục vụ cho việc hoàn thành công việc.

Peer reviews: Trong loại kiểm tra này, kiểm tra về kỹ thuật sẽ được kiểm tra 1 vòng. Việc này tiến hành để kiểm tra xem code được thực hiện theo đúng các thông số kỹ thuật và tiêu chuẩn hay không. Nói chung các kế hoạch kiểm tra, chiến lược kiểm thử và các tập lệnh kiểm tra được xem xét ở đây.

Inspection: Kỹ thuật kiểm tra tĩnh trong đó tài liệu được xem xét, nhận xét một cách không chính thức và đưa ra các ý kiến không chính thức.

5. Các kỹ thuật Static Testing

Có một số kỹ thuật xem xét có thể được áp dụng trong hoạt động xem xét riêng lẻ (tức là chuẩn bị riêng lẻ) để phát hiện ra các khiếm khuyết. Các kỹ thuật này có thể được sử dụng cho các loại đánh giá được mô tả ở trên. Hiệu quả tùy thuộc vào loại đánh giá được sử dụng.

Các kỹ thuật đánh giá thường áp dụng

Ad hoc
Checklist-based
Scenarios and dry runs
Perspective-based
Role-based

Review technique Adhoc

Người đánh giá được cung cấp ít hoặc không có hướng dẫn về cách thực hiện nhiệm vụ này.
Xem xét đặc biệt là một kỹ thuật thường được sử dụng, cần ít sự chuẩn bị
Kỹ thuật này phụ thuộc nhiều vào kỹ năng của người đánh giá và có thể dẫn đến nhiều vấn đề trùng lặp được báo cáo bởi những người đánh giá khác nhau.

Review Techniques: Checklist based

Là một kỹ thuật có hệ thống
Người đánh giá phát hiện các vấn đề dựa trên danh sách kiểm tra
Danh sách kiểm tra đánh giá bao gồm một tập hợp các câu hỏi dựa trên các khiếm khuyết tiềm ẩn, có thể rút ra từ kinh nghiệm.
Danh sách kiểm tra phải cụ thể cho loại sản phẩm công việc
Ưu điểm chính của kỹ thuật dựa trên danh sách kiểm tra là có hệ thống bao quát các dạng khuyết tật điển hình.
Không chỉ đơn giản tuân theo danh sách kiểm tra trong việc xem xét cá nhân, mà còn để tìm kiếm những khiếm khuyết bên ngoài danh sách kiểm tra.

Review Techniques: Scenarios and dry runs

Trong đánh giá dựa trên kịch bản, người đánh giá được cung cấp các hướng dẫn có cấu trúc về cách đọc qua sản phẩm công việc.
Đánh giá dựa trên kịch bản hỗ trợ người đánh giá thực hiện “chạy khô” trên sản phẩm làm việc dựa trên mức sử dụng dự kiến của sản phẩm công việc (ví dụ: các trường hợp sử dụng).
Các tình huống này cung cấp cho người đánh giá các hướng dẫn tốt hơn về cách xác định các các loại lỗi hơn các mục danh sách kiểm tra đơn giản.
Tuy nhiên, người đánh giá không nên bị bó buộc vào các tình huống đã được tài liệu hóa. Người đánh giá cũng nên tìm kiếm các khiếm khuyết bên ngoài các tình huống.

Review Techniques: Perspective-based

Người đánh giá đảm nhận các bên liên quan khác nhau quan điểm trong kiểm điểm cá nhân.
Quan điểm của các bên liên quan điển hình bao gồm người dùng cuối, tiếp thị, nhà thiết kế, người kiểm tra hoặc các hoạt động.
Sử dụng các quan điểm khác nhau của các bên liên quan dẫn đến đánh giá cá nhân sâu hơn với ít vấn đề trùng lặp hơn giữa những người đánh giá.
Ngoài ra, đọc theo quan điểm cũng yêu cầu người đánh giá cố gắng sử dụng sản phẩm công việc đang được xem xét để tạo ra sản phẩm mà họ sẽ thu được từ nó. Ví dụ: một người thử nghiệm sẽ cố gắng tạo các kiểm tra chấp nhận nháp nếu thực hiện đọc dựa trên quan điểm về đặc tả yêu cầu để xem liệu tất cả thông tin cần thiết đã được đưa vào chưa.
Đọc theo quan điểm,danh sách kiểm tra dự kiến sẽ được sử dụng.

Review Techniques: Role based

Đánh giá dựa trên vai trò là một kỹ thuật trong đó người đánh giá đánh giá sản phẩm công việc từ góc độ vai trò của từng bên liên quan.
Các vai trò điển hình bao gồm các kiểu người dùng cuối cụ thể (có kinh nghiệm, chưa có kinh nghiệm, cấp cao, cấp con, v.v.) và các vai trò cụ thể trong tổ chức (quản trị viên người dùng, quản trị viên hệ thống, người kiểm tra hiệu suất, v.v.).
Các nguyên tắc tương tự được áp dụng như trong đọc theo quan điểm vì các vai trò tương tự nhau.

6. Các lỗi chính được tìm thấy trong Static Testing

Sai lệch so với tiêu chuẩn
Code không được bảo trì
Lỗi trong design
Lỗi trong requirement
Thông số kỹ thuật không nhất quán
Thông thường, lỗi được phát hiện trong quá trình kiểm thử tĩnh là do lỗ hổng bảo mật, các biến không được khai báo, vi phạm ranh giới, vi phạm cú pháp, giao diện không nhất quán,..

Tài liệu tham khảo:

Syllabus 2018

https://www.guru99.com/testing-review.html