1.7K 77 26

Đã đăng vào thg 3 15, 2021 3:37 SA 24 phút đọc

2.8K

Tìm hiểu về Static testing

1. Static testing là gì?

Static testing là một kỹ thuật kiểm thử phần mềm để tìm kiếm lỗi trong phần mềm/ ứng dụng mà không 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.

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

2. Tại sao Static testing là cần thiết

Kiểm tra tĩnh cho phép phát hiện sớm các khuyết tật trước khi thực hiện kiểm tra động (ví dụ: trong các yêu cầu hoặc đánh giá thông số kỹ thuật thiết kế, sàng lọc tồn đọng sản phẩm, v.v.).
Các khiếm khuyết được phát hiện sớm thường rẻ hơn nhiều so với các khiếm khuyết được tìm thấy sau đó trong vòng đời, đặc biệt là so với các khiếm khuyết được tìm thấy sau khi phần mềm được triển khai và sử dụng tích cực
Tăng năng suất phát triển (ví dụ: do thiết kế được cải tiến, mã dễ bảo trì hơn)
Giảm chi phí và thời gian phát triển
Giảm chi phí và thời gian thử nghiệm
Xác định các khuyết tật không dễ tìm thấy bằng thử nghiệm động
Phát hiện và sửa chữa các khuyết tật hiệu quả hơn và trước khi thực hiện thử nghiệm động

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

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

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

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

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

5.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 kỹ thuật review thường dùng:

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

Informal Reviews:

Mục đích chính: Phát hiện lỗi tiềm năng không dự vào 1 process chính thức nào
Review meeting: Led by author
Performed by: 1 đồng nghiệp của tác giả hoặc nhiều người hơn
Result: có thể được ghi lại
Use of checklist: có thể có hoặc không

Walkthrough:

Mục đích chính: tìm lỗi, cải thiện sản phẩm phần mềm, xem xét các triển khai thay thế, đánh giá sự phù hợp với các thông số kỹ thuật. Cá nhân có thể có hoặc không chuẩn bị trước khi review.
Review meeting: có, dẫn dắt bởi tác giả của sản phẩm phần mềm
Scribe: bắt buộc
Use of checklist: có thể có hoặc không
Result: Logs những lỗi tiềm năng và review reports có thể được tiến hành. Có thể thay đổi trong thực tế từ informal đến formal

Technical review:

Mục đích chính: đạt được sự đồng thuận, phát hiện lỗi tiềm năng
Reviewer: nên là những đồng nghiệp kỹ thuật của tác giả và chuyên gia về kỹ thuật .Cá nhân được yêu cầu chuẩn bị trước khi review
Review meeting: có thể có or không, lý tưởng được led bởi 1 điều hành viên được đào tạo (không phải là author)
Scribe: bắt buộc, lý tưởng không phải là tác giả
Use of checklist: có thể có hoặc không
Result: Logs những lỗi tiềm năng và review reports có thể được tiến hành

Inspection review:

Mục đích chính: phát hiện lỗi tiềm năng, ngăn chặn lỗi tương tự trong tương lai Thực hiện theo 1 quy trình xác định với đầu ra được ghi lại chính thức: dựa vào các luật và checklist Cá nhân được yêu cầu chuẩn bị trước khi review.Các roles trong buổi review phải được xác định rõ ràng
Review meeting: có, được led bởi 1 điều hành viên được đào tạo (không phải là tác giả)
Reviewer: là đồng nghiệp của tác giả or chuyên gia trong các lĩnh vực khác liên quan đến sản phẩm
Specified: tiêu chí đầu vào và đầu ra được sử dụng
Scribe: bắt buộc
Result: logs các lỗi tiềm năng và review process có thể được tiến hành

5. Các kỹ thuật dùng trong 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

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

Kỹ thuật Review Adhoc là một phương pháp đánh giá tài liệu hoặc mã nguồn một cách không hệ thống và không theo quy trình cụ thể. Dưới đây là một ví dụ về việc áp dụng kỹ thuật Review Adhoc:

Giả sử bạn là một thành viên trong đội phát triển phần mềm và bạn nhận nhiệm vụ đánh giá một tài liệu yêu cầu (requirement document) mới được viết bởi một thành viên khác trong đội. Bạn quyết định áp dụng kỹ thuật Review Adhoc để kiểm tra tài liệu này trước khi nó được chuyển đến bước tiếp theo của quy trình phát triển.

Bạn tiến hành đọc và xem xét tài liệu yêu cầu và thực hiện các bước sau:

Đánh giá cú pháp và ngữ pháp: Kiểm tra xem tài liệu yêu cầu tuân thủ các quy ước về cú pháp và ngữ pháp ngôn ngữ viết tài liệu.
Xác định tính chính xác và đầy đủ: Đảm bảo rằng tài liệu yêu cầu đưa ra các thông tin chính xác và đầy đủ để hiểu và triển khai yêu cầu phần mềm.
Phát hiện lỗi logic và mâu thuẫn: Tìm kiếm các lỗi logic, mâu thuẫn hoặc thông tin không chính xác trong tài liệu yêu cầu. Ví dụ, kiểm tra xem có yêu cầu trái ngược nhau không hoặc có rõ ràng và chính xác không.
Đưa ra phản hồi và ghi chú: Ghi chú các lỗi, phát hiện và ý kiến trong quá trình đọc tài liệu yêu cầu. Đưa ra phản hồi và góp ý xây dựng để cải thiện tài liệu.
Thảo luận và trao đổi ý kiến: Nếu có, tham gia vào cuộc thảo luận và trao đổi ý kiến với tác giả tài liệu và các thành viên khác của đội phát triển. Cung cấp giải thích, lời khuyên và các đề xuất để sửa chữa các vấn đề tìm thấy.
Gửi lại tài liệu đã đánh giá: Sau khi hoàn thành quá trình đánh giá, gửi lại tài liệu đã được đánh giá cho tác giả hoặc người phụ trách để thực hiện các bước tiếp theo, như sửa lỗi hoặc thực hiện các thay đổi cần thiết.

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

3.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 Kỹ thuật Scenarios and Dry Runs là một phương pháp kiểm thử phần mềm bằng cách tạo ra các tình huống và thực hiện các thử nghiệm thử để đánh giá hệ thống. Dưới đây là một ví dụ về việc áp dụng kỹ thuật Scenarios and Dry Runs:

Giả sử bạn đang làm việc trên một dự án phát triển ứng dụng di động và bạn muốn kiểm tra tính năng đăng nhập trong ứng dụng. Bạn quyết định sử dụng kỹ thuật Scenarios and Dry Runs để kiểm tra tính năng này trước khi triển khai vào môi trường thực tế.

Bạn thực hiện các bước sau:

Xác định các tình huống kiểm thử: Tạo ra một danh sách các tình huống kiểm thử có thể xảy ra trong quá trình đăng nhập. Ví dụ: đăng nhập thành công với thông tin đăng nhập hợp lệ, đăng nhập không thành công với mật khẩu sai, đăng nhập không thành công với tên người dùng không tồn tại, v.v.
Xác định các bước thực hiện: Định rõ các bước cần thực hiện để tạo ra môi trường và thực hiện các tình huống kiểm thử. Ví dụ: mở ứng dụng, nhập thông tin đăng nhập, nhấn nút đăng nhập, kiểm tra kết quả đăng nhập.
Thực hiện dry runs: Thực hiện các bước thực hiện được xác định trước mà không thực sự tạo ra kết quả. Đây được gọi là dry runs vì nó không ảnh hưởng đến hệ thống thực tế. Trong quá trình này, bạn sẽ kiểm tra xem liệu các bước thực hiện có đúng không và xác định các điểm mấu chốt có thể xảy ra lỗi hoặc vấn đề.
Ghi lại kết quả và phân loại lỗi: Ghi lại kết quả của mỗi dry run và xác định các lỗi hoặc vấn đề tìm thấy trong quá trình thực hiện. Phân loại chúng theo mức độ ưu tiên và ảnh hưởng đến hệ thống.
Đưa ra phản hồi và sửa lỗi: Dựa trên kết quả và phân loại lỗi, đưa ra phản hồi cho nhóm phát triển và thực hiện các biện pháp sửa lỗi và cải thiện tính năng đăng nhập.
Thực hiện lại tình huống kiểm thử: Sau khi sửa lỗi, thực hiện lại các tình huống kiểm thử để xác minh rằng các lỗi đã được khắc phục và tính năng hoạt động như mong đợi.

Kỹ thuật Scenarios and Dry Runs giúp bạn kiểm tra tính năng trong môi trường kiểm thử một cách chặt chẽ và xác định các vấn đề sớm trong quá trình phát triển, giúp tăng cường chất lượng và đáng tin cậy của ứng dụng.

4.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. Kỹ thuật Perspective-based là một phương pháp kiểm thử phần mềm dựa trên quan điểm và góc nhìn của các thành viên trong nhóm kiểm thử. Dưới đây là một ví dụ về việc áp dụng kỹ thuật Perspective-based:

Giả sử bạn đang làm việc trên một dự án phát triển một ứng dụng thương mại điện tử. Bạn muốn đảm bảo rằng giao diện người dùng (UI) của ứng dụng được thiết kế và triển khai đúng theo yêu cầu và mong muốn của khách hàng.

Bạn quyết định áp dụng kỹ thuật Perspective-based để kiểm tra UI của ứng dụng và bao gồm các thành viên có quan điểm và góc nhìn khác nhau:

Người dùng cuối: Một thành viên trong nhóm kiểm thử đại diện cho người dùng cuối sẽ xem xét giao diện và đánh giá tính dễ sử dụng, trực quan và thân thiện của nó. Họ sẽ kiểm tra cách thức tương tác, tiện ích, sắp xếp và truy cập thông tin.
Nhà phân tích yêu cầu: Thành viên nhóm này sẽ xem xét giao diện từ góc độ của yêu cầu khách hàng. Họ sẽ kiểm tra xem giao diện đã đáp ứng đúng các yêu cầu và mong muốn của khách hàng hay không. Điều này có thể bao gồm kiểm tra các chức năng, quy trình và luồng làm việc trong giao diện.
Nhà thiết kế UX/UI: Thành viên này sẽ đánh giá giao diện từ góc độ thiết kế và trải nghiệm người dùng. Họ sẽ xem xét các yếu tố như màu sắc, đồ họa, bố cục, sự phù hợp với thương hiệu, và tạo ra đánh giá về tính hợp lý và hấp dẫn của giao diện.
Nhà phát triển: Thành viên này sẽ xem xét khả năng triển khai và tính khả thi của giao diện từ góc độ kỹ thuật. Họ sẽ kiểm tra việc triển khai các yêu cầu kỹ thuật, tính tương thích đa nền tảng, hiệu suất và khả năng mở rộng của giao diện.

Mỗi thành viên trong nhóm sẽ xem xét giao diện từ góc nhìn của mình và đưa ra phản hồi, đánh giá, và đề xuất cải thiện. Các góp ý sẽ được thảo luận và đưa vào quá trình cải tiến giao diện. Qua đó, kỹ thuật Perspective-based giúp đảm bảo rằng giao diện người dùng được đánh giá từ nhiều quan điểm khác nhau và đáp ứng tốt các yêu cầu và mong muốn của khách hàng.

5. 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.Những 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,..

Join group để học hỏi, chia sẻ thêm kiến thức về kiểm thử nhé, mình có chữa đề istqb foundation trên group: https://www.facebook.com/groups/itester

Follow và Upvote để mình có thêm động lực viết bài Tài liệu tham khảo: