Câu hỏi: SWT301 - Phần 3: Kỹ thuật kiểm thử tĩnh và rà soát

Phương pháp kiểm thử tĩnh và động là hai kỹ thuật kiểm thử khác nhau trong lập trình. Phương pháp kiểm thử tĩnh không liên quan đến việc thực thi mã, trong khi phương pháp kiểm thử động lại liên quan đến việc thực thi mã. Điều này có nghĩa là kiểm thử tĩnh được thực hiện trước khi mã được thực thi, trong khi kiểm thử động được thực hiện sau khi mã được thực thi. Kiểm thử tĩnh bao gồm các kỹ thuật như phân tích mã, kiểm tra mã, và đánh giá mã, trong khi kiểm thử động bao gồm các kỹ thuật như kiểm thử đơn vị, kiểm thử tích hợp, và kiểm thử hệ thống. Mỗi phương pháp có ưu và nhược điểm riêng, và được sử dụng trong các giai đoạn khác nhau của quá trình phát triển phần mềm.

Các đánh giá hỗ trợ đảm bảo chất lượng phần mềm bằng cách cung cấp một cách để kiểm tra tuân thủ các tiêu chuẩn. Điều này có nghĩa là các đánh giá giúp xác định xem phần mềm có đáp ứng các yêu cầu và tiêu chuẩn đã được thiết lập hay không. Các đánh giá cũng giúp xác định các vấn đề và lỗi trong phần mềm, từ đó giúp các nhà phát triển cải thiện và hoàn thiện phần mềm. Ngoài ra, các đánh giá còn giúp xây dựng niềm tin với khách hàng và người dùng, bởi họ có thể thấy được chất lượng và độ tin cậy của phần mềm.

Các đánh giá kỹ thuật khác với đánh giá không chính thức ở chỗ chúng tuân theo một quy trình được định nghĩa và được dẫn dắt bởi một người điều hành được đào tạo. Trong các đánh giá kỹ thuật, người điều hành sẽ đảm bảo rằng quá trình đánh giá được thực hiện một cách công bằng và có hệ thống. Họ sẽ hướng dẫn các thành viên tham gia đánh giá và đảm bảo rằng tất cả các ý kiến đều được lắng nghe và xem xét. Điều này giúp đảm bảo rằng các đánh giá kỹ thuật là một quá trình nghiêm túc và có hệ thống, giúp cải thiện chất lượng của sản phẩm.

Quá trình đánh giá sản phẩm công việc là một phần quan trọng trong chuỗi hoạt động của một dự án. Trong quá trình này, các thành viên tham gia đánh giá và thảo luận về sản phẩm công việc đã được tạo ra. Các hoạt động chính của quá trình đánh giá sản phẩm công việc bao gồm: xác định mục tiêu và yêu cầu của sản phẩm, đánh giá chất lượng và hiệu suất của sản phẩm, xác định điểm mạnh và điểm yếu của sản phẩm, đề xuất cải tiến và sửa lỗi, và xác định kế hoạch triển khai sản phẩm. Các hoạt động này giúp đảm bảo rằng sản phẩm công việc đáp ứng được yêu cầu và mục tiêu của dự án, đồng thời giúp cải thiện chất lượng và hiệu suất của sản phẩm.

Các công cụ phân tích tĩnh là một phần quan trọng trong quy trình phát triển phần mềm. Chúng giúp kiểm tra mã nguồn trước khi thực thi, nhằm đảm bảo rằng mã nguồn tuân thủ các tiêu chuẩn lập trình và tránh các lỗi tiềm ẩn. Một trong những đặc điểm chính của các công cụ phân tích tĩnh là khả năng kiểm tra các tiêu chuẩn lập trình. Điều này bao gồm việc kiểm tra mã nguồn để đảm bảo rằng nó tuân thủ các quy tắc lập trình, tránh các lỗi syntax và đảm bảo rằng mã nguồn được viết một cách rõ ràng và dễ đọc. Việc kiểm tra các tiêu chuẩn lập trình giúp cải thiện chất lượng mã nguồn và giảm thiểu thời gian phát triển.

Static testing là một phương pháp kiểm thử phần mềm mà trong đó các sản phẩm phần mềm được kiểm tra bằng cách sử dụng các công cụ hoặc thủ công mà không cần thực hiện việc chạy chương trình. Phương pháp này giúp phát hiện các lỗi và đánh giá các tính chất chất lượng của mã nguồn mà không cần thực hiện việc chạy chương trình. Các kỹ thuật thường được sử dụng trong static testing bao gồm kiểm tra mã nguồn, phân tích mã nguồn, và sử dụng các công cụ kiểm thử tự động. Mục đích của static testing là giúp phát hiện các lỗi và cải thiện chất lượng của phần mềm trước khi nó được triển khai.

Các loại kiểm tra có liên quan đến việc đánh giá chất lượng phần mềm. Trong đó, kiểm tra tĩnh (static test) là một loại kiểm tra không cần phải chạy chương trình. Nó giúp phát hiện ra các lỗi trong mã nguồn trước khi chương trình được thực thi. Một trong những phương pháp kiểm tra tĩnh phổ biến là kiểm tra mã nguồn bằng mắt (code inspection). Điều này giúp phát hiện ra các lỗi logic, lỗi syntax và các vấn đề khác trong mã nguồn mà không cần phải chạy chương trình. Vì vậy, trong các lựa chọn trên, kiểm tra mã nguồn bằng mắt (code inspection) là một phương pháp kiểm tra tĩnh.

Mục đích của đánh giá không chính thức là quá trình thảo luận, đưa ra quyết định và giải quyết các vấn đề kỹ thuật. Quá trình này giúp các thành viên trong nhóm hoặc tổ chức chia sẻ ý kiến, kinh nghiệm và kiến thức của mình. Thông qua việc thảo luận, họ có thể tìm ra các giải pháp hiệu quả hơn cho các vấn đề phức tạp. Đánh giá không chính thức cũng giúp xây dựng mối quan hệ và tăng cường sự hợp tác trong nhóm. Nói cách khác, mục đích của đánh giá không chính thức là tạo ra một môi trường học hỏi và phát triển, nơi mọi người có thể chia sẻ và học hỏi từ nhau.

Trong quá trình đánh giá chính thức, người ghi chép lại tất cả các vấn đề, vấn đề và điểm mở được xác định là người ghi chép. Họ chịu trách nhiệm thu thập và ghi lại thông tin, đảm bảo rằng tất cả các vấn đề và điểm mở được ghi lại một cách chính xác và đầy đủ. Người ghi chép đóng vai trò quan trọng trong việc đảm bảo rằng tất cả các vấn đề và điểm mở được xem xét và giải quyết một cách hiệu quả.

Người chịu trách nhiệm dẫn dắt quá trình xem xét tài liệu, lên kế hoạch cho quá trình xem xét, điều hành cuộc họp và theo dõi sau cuộc họp được gọi làModerator. Họ là người có vai trò quan trọng trong việc đảm bảo quá trình xem xét diễn ra một cách hiệu quả và có kết quả tốt. Họ sẽ lên kế hoạch cho cuộc họp, mời các thành viên tham gia, điều hành cuộc họp và theo dõi tiến độ sau cuộc họp. Mục tiêu của họ là đảm bảo rằng tài liệu được xem xét một cách kỹ lưỡng và có kết quả tốt.

Walk Through là một phương pháp đánh giá hiệu suất và chất lượng công việc. Để xác định Key Characteristics của Walk Through, chúng ta cần xem xét các lựa chọn sau. Lựa chọn đầu tiên, Scenario, Dry Run, Peer Group, là một trong những đặc điểm chính của Walk Through. Scenario đề cập đến việc mô tả một tình huống cụ thể để đánh giá hiệu suất công việc. Dry Run là quá trình thử nghiệm và kiểm tra trước khi thực hiện công việc. Peer Group là quá trình đánh giá và thảo luận giữa các thành viên trong nhóm. Tất cả các yếu tố này đều đóng vai trò quan trọng trong việc đảm bảo chất lượng và hiệu suất công việc.

Các công cụ phân tích tĩnh có thể phát hiện các loại lỗi sau: i. Biến không bao giờ được sử dụng. ii. Các lỗ hổng bảo mật. iii. Vi phạm tiêu chuẩn lập trình. iv. Các hàm và thủ tục chưa được gọi. Trong các lựa chọn trên, câu trả lời đúng là: '1, ii, iii, iv là đúng'. Các công cụ phân tích tĩnh có thể phát hiện các lỗi này bằng cách phân tích mã nguồn mà không cần thực thi nó. Điều này giúp phát hiện các lỗi tiềm ẩn và cải thiện chất lượng mã nguồn. Các lỗi không được sử dụng, lỗ hổng bảo mật và vi phạm tiêu chuẩn lập trình đều có thể được phát hiện bằng cách phân tích mã nguồn. Đồng thời, các công cụ phân tích tĩnh cũng có thể phát hiện các hàm và thủ tục chưa được gọi, giúp phát hiện các lỗi tiềm ẩn khác.

Các công cụ phân tích tĩnh có thể phát hiện các lỗi sau: i. Biến không bao giờ được sử dụng. ii. Các lỗ hổng bảo mật. iii. Vi phạm tiêu chuẩn lập trình. iv. Các hàm và thủ tục không được gọi. Trong các lựa chọn trên, câu trả lời đúng là "1, ii, iii, iv là đúng" vì các công cụ phân tích tĩnh có thể phát hiện tất cả các lỗi này. Các công cụ này có thể giúp phát hiện các vấn đề tiềm ẩn trong mã nguồn, bao gồm cả các biến không được sử dụng, các lỗ hổng bảo mật và vi phạm tiêu chuẩn lập trình. Điều này giúp các nhà phát triển cải thiện chất lượng mã nguồn và giảm thiểu các vấn đề bảo mật.

Đáp án đúng: "Error guessing". Đoán lỗi (error guessing) là kỹ thuật kiểm thử động dựa trên kinh nghiệm: người kiểm thử dự đoán chỗ phần mềm hay sai rồi thiết kế ca kiểm thử để chạy chương trình nhắm vào chỗ đó, nên nó không phải kỹ thuật tĩnh. Kiểm thử tĩnh (static testing) đánh giá sản phẩm mà không thực thi mã, gồm rà soát và phân tích tĩnh. "Walkthrough" là duyệt qua do tác giả dẫn dắt, một loại rà soát nên là kỹ thuật tĩnh. "Inspections" là thanh tra, loại rà soát chính thức nhất, cũng là kỹ thuật tĩnh. "Data flow analysis" là phân tích luồng dữ liệu, thường do công cụ phân tích tĩnh thực hiện trên mã nguồn để tìm biến dùng trước khi gán hay gán mà không dùng, không cần chạy chương trình nên cũng thuộc nhóm tĩnh.

Các cuộc kiểm tra có thể tìm thấy tất cả các lựa chọn sau, trừ khi nào đó. Các cuộc kiểm tra có thể phát hiện các biến không được định nghĩa trong mã, các lỗi chính tả và ngữ pháp trong tài liệu, các yêu cầu đã bị bỏ qua từ các tài liệu thiết kế. Tuy nhiên, chúng không thể tìm thấy được mức độ bao phủ của mã. Mức độ bao phủ của mã không thể được kiểm tra bằng các cuộc kiểm tra, mà phải được thực hiện thông qua các phương pháp khác như chạy thử nghiệm, phân tích tĩnh và phân tích động. Các phương pháp này có thể giúp xác định được mức độ bao phủ của mã và phát hiện các khu vực chưa được kiểm tra.

Đáp án đúng: "ii,iii,iv are correct and i is incorrect". ISTQB Foundation liệt kê các yếu tố thành công của review gồm: mỗi buổi review có mục tiêu rõ ràng được xác định trước, đúng người tham gia, khuyết tật tìm được được hoan nghênh và nêu một cách khách quan, có sự ủng hộ của ban quản lý cho quy trình review, và chú trọng việc học hỏi, cải tiến quy trình. Vì vậy mục ii, iii, iv đúng, còn mục i nói review "không có mục tiêu định trước" là ngược với yếu tố thành công nên sai. "iii , i , iv is correct and ii is incorrect" sai vì coi mục i là đúng và bác mục ii, trong khi thái độ khách quan với lỗi chính là điều kiện cốt lõi. "i , iii , iv , ii is in correct" sai vì phủ nhận cả ba yếu tố đúng. "ii is correct" chỉ nhận một mục, bỏ sót sự ủng hộ của ban quản lý và việc chú trọng học hỏi.

Khi đánh giá một sản phẩm phần mềm, mục tiêu chính là xác định các lỗi hoặc sai sót trong sản phẩm đó. Điều này bao gồm việc kiểm tra các tài liệu, mã nguồn và các sản phẩm khác liên quan đến phần mềm để đảm bảo chúng đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra. Mục tiêu này giúp phát hiện ra các vấn đề tiềm ẩn và cải thiện chất lượng của phần mềm. Việc xác định các lỗi hoặc sai sót cũng giúp cho việc sửa chữa và cải thiện phần mềm trở nên hiệu quả hơn.

Đáp án đúng: "i,ii,iii are true and iv is false.". Theo ISTQB, một cuộc rà soát hình thức (formal review) có các vai trò: quản lý (manager) quyết định thực hiện rà soát, cấp thời gian và nguồn lực; người điều phối (moderator) dẫn dắt quy trình và chủ trì cuộc họp; tác giả (author) của tài liệu; người rà soát (reviewer) tìm lỗi; người ghi chép (scribe, recorder) ghi lại lỗi và vấn đề. Vì vậy i, ii, iii đều đúng, còn trợ lý quản lý (assistant manager) không phải vai trò được định nghĩa trong rà soát nên iv sai. "i,ii,iii,iv are true" sai vì nhận cả trợ lý quản lý. "ii,iii,iv are true and i is false." sai vì loại quản lý, trong khi quản lý là vai trò chính thức quyết định và cấp nguồn lực cho rà soát. "i,iv are true and ii, iii are false." sai nặng nhất vì bác cả người điều phối lẫn người ghi chép, hai vai trò cốt lõi của cuộc họp rà soát.

Đáp án đúng: "i,v,iv,ii,iii,vi". Quy trình review chính thức theo ISTQB Foundation gồm sáu bước theo thứ tự: lập kế hoạch (planning) chọn người, vai trò và tiêu chí; khởi động (kick-off) phát tài liệu, giải thích mục tiêu; chuẩn bị cá nhân (individual preparation) từng người tự đọc và ghi lỗi; họp review (review meeting) thảo luận, ghi nhận kết quả; làm lại (rework) tác giả sửa lỗi; theo dõi (follow-up) moderator kiểm tra việc sửa và tiêu chí kết thúc. Ứng với ký hiệu là i, v, iv, ii, iii, vi. "i,ii,iii,iv,v,vi" chỉ giữ thứ tự liệt kê, đặt họp review trước cả khởi động và chuẩn bị. "vi,i,ii,iii,iv,v" đặt theo dõi lên đầu, trong khi chưa có gì để theo dõi. "i,ii,iii,v,iv,vi" đặt khởi động và chuẩn bị cá nhân sau khi đã họp và làm lại, ngược với logic phải chuẩn bị trước khi họp.

Đáp án đúng gồm hai ý: "Static analysis need not be performed before imperative code is executed" và "Static analysis can find faults that are hard to find with dynamic testing.". Phân tích tĩnh (static analysis) là việc công cụ khảo sát mã nguồn hoặc mô hình mà không chạy chương trình; vì không phụ thuộc vào việc chạy, nó có thể làm trước, song song hay sau khi mã được thực thi chứ không bắt buộc phải xong trước, và nó tìm được những lỗi mà kiểm thử động khó chạm tới như biến dùng trước khi gán giá trị, mã không bao giờ chạy tới, vi phạm chuẩn lập trình, lỗ hổng bảo mật hay độ phức tạp quá cao. "Compiling code is not a form of static analysis" sai vì trình biên dịch chính là một dạng phân tích tĩnh: nó kiểm tra cú pháp, kiểu dữ liệu, biến chưa khai báo mà không chạy chương trình. Phát biểu "Extensive statistical analysis will not be needed if white- Box testing is to be performed." sai vì kiểm thử hộp trắng là kiểm thử động, chạy mã để đo độ phủ, nên không thay được việc phân tích mã khi không chạy; hai cách bổ sung cho nhau chứ không loại trừ nhau.