SWT301 Software Testing – Bộ ôn tập thi lại số 3 (60 câu)

Đáp án đúng: A. Khi thời gian và nguồn lực có hạn, kiểm thử phải được ưu tiên theo rủi ro. Hai định hướng đúng là kiểm thử những vùng trọng yếu nhất với quy trình nghiệp vụ (1) và những vùng có khả năng chứa nhiều lỗi nhất (2) - nguyên lý "defect clustering" cho biết lỗi thường dồn vào một số ít mô-đun. Định hướng (3), kiểm thử những chức năng dễ nhất, là sai vì nó tiêu tốn công sức vào phần ít rủi ro và bỏ sót phần nguy hiểm. Vì vậy 1 và 2 đúng, 3 sai, tức phương án A; các phương án còn lại hoặc công nhận (3) hoặc phủ nhận (1), (2) nên đều không đạt.

Khi so sánh việc kiểm tra phần mềm được phát triển bởi nhà thầu bên ngoài nước bạn và nhà thầu bên trong nước bạn, có một số điểm khác biệt quan trọng cần xem xét. Đầu tiên, việc kiểm tra phần mềm được phát triển bởi nhà thầu bên ngoài nước bạn có thể gặp phải những thách thức liên quan đến ngôn ngữ và văn hóa. Điều này có thể dẫn đến sự hiểu lầm và sai sót trong quá trình kiểm tra. Mặt khác, việc kiểm tra phần mềm được phát triển bởi nhà thầu bên trong nước bạn có thể giúp bạn kiểm soát tốt hơn về mặt ngôn ngữ và văn hóa, từ đó đảm bảo rằng phần mềm đáp ứng được nhu cầu của người dùng.

PDCA là một phương pháp quản lý chất lượng được sử dụng rộng rãi trong nhiều lĩnh vực, bao gồm sản xuất, dịch vụ và quản lý. PDCA là viết tắt của Plan, Do, Check, Act, có nghĩa là Lập kế hoạch, Thực hiện, Kiểm tra, Hành động. Phương pháp này được phát triển bởi Walter A. Shewhart vào năm 1931 và sau đó được phổ biến bởi W. Edwards Deming vào những năm 1950. PDCA là một vòng tròn liên tục, bắt đầu từ việc lập kế hoạch (Plan) để thực hiện một hành động hoặc dự án. Sau đó, hành động được thực hiện (Do) và sau đó được kiểm tra (Check) để xác định xem nó đã đạt được mục tiêu hay chưa. Nếu mục tiêu chưa đạt được, sẽ có hành động cần được thực hiện (Act) để điều chỉnh và cải thiện. Phương pháp PDCA giúp các tổ chức và cá nhân có thể liên tục cải thiện và phát triển, bằng cách: * Lập kế hoạch rõ ràng và cụ thể * Thực hiện kế hoạch một cách có trách nhiệm * Kiểm tra và đánh giá kết quả * Hành động để điều chỉnh và cải thiện PDCA là một phương pháp quản lý chất lượng hiệu quả, giúp các tổ chức và cá nhân có thể đạt được mục tiêu và cải thiện liên tục.

Đáp án đúng: C. Kiểm thử chỉ nên dừng khi các tiêu chí hoàn thành (test completion criteria / exit criteria) đã được thoả mãn, bởi đó là thước đo khách quan đã thống nhất từ khi lập kế hoạch. Hết thời gian (A) hay chạy xong toàn bộ ca kiểm thử đã lập (B) chỉ là điều kiện hành chính, không nói lên chất lượng sản phẩm. Không tìm thấy lỗi nào (D) càng nguy hiểm vì có thể do bộ ca kiểm thử yếu chứ không phải phần mềm tốt - kiểm thử không chứng minh được sự vắng mặt của lỗi.

Đáp án đúng: A. Tiêu chí đầu ra (exit criteria) được đặt ra ngay trong kế hoạch kiểm thử để xác định khi nào một MỨC kiểm thử được coi là hoàn tất, thường gồm mức độ bao phủ đạt được, số lỗi còn mở, rủi ro tồn đọng và chi phí. Phương án B chỉ nói tới việc một phép kiểm thử đơn lẻ chạy xong, đó là chuyện thực thi chứ không phải tiêu chí đầu ra của cả mức kiểm thử; phương án C nói về vòng đời sản phẩm (khi nào ngừng sử dụng hệ thống); phương án D là việc so sánh kết quả thực tế với kết quả mong đợi, tức tiêu chí đạt/không đạt của một ca kiểm thử.

Đáp án đúng: C. Không thể kiểm thử vét cạn, nên câu hỏi "kiểm thử bao nhiêu là đủ" không có đáp số cố định: mức độ đủ phụ thuộc vào rủi ro của ngành nghề, các ràng buộc hợp đồng và những yêu cầu đặc thù của sản phẩm. Phần mềm y tế hay hàng không đòi hỏi mức kiểm thử khác hẳn một ứng dụng giải trí. Phương án A quá bi quan vì câu hỏi vẫn trả lời được khi đặt trong bối cảnh rủi ro cụ thể; phương án B ngược lại, quá lạc quan; phương án D chỉ nêu một yếu tố nhỏ, mức trưởng thành của đội phát triển không phải căn cứ chính để xác định khối lượng kiểm thử.

Đáp án đúng: E. Tiêu chí hoàn thành kiểm thử (test completion criteria, còn gọi là exit criteria) được đưa vào kế hoạch kiểm thử để trả lời câu hỏi KHI NÀO DỪNG kiểm thử: đạt bao nhiêu phần trăm bao phủ, còn bao nhiêu lỗi mức nghiêm trọng, rủi ro tồn đọng ở mức nào. Nhờ đó việc dừng kiểm thử là một quyết định có căn cứ chứ không phải vì hết thời gian hay hết tiền. Phương án A chỉ nói tới việc một phép kiểm thử chạy xong; B là mục tiêu của việc rà soát đặc tả ca kiểm thử; C thuộc kỹ thuật thiết kế dữ liệu đầu vào; D nói về hoàn thành khâu lập kế hoạch, không phải khâu kiểm thử.

Đáp án đúng: B. Độ tin cậy (reliability) là xác suất phần mềm hoạt động không phát sinh sự cố trong một khoảng thời gian và điều kiện xác định. Vì vậy hệ thống tin cậy là hệ thống ÍT có khả năng gây ra hỏng hóc (failure) khi vận hành. Cần phân biệt fault (lỗi nằm trong mã) với failure (biểu hiện sai khi chạy): một hệ thống vẫn có thể chứa nhiều fault ở những nhánh hiếm khi được thực thi mà vẫn rất tin cậy, nên phương án C "gần như không còn lỗi" không phải định nghĩa của độ tin cậy. Phương án A nói về tiến độ dự án và phương án D nói về mức độ hài lòng của người dùng, đều là thuộc tính khác.

Đáp án đúng: C. Bảo mật, hiệu năng, độ tin cậy và tính khả dụng đều là các thuộc tính CHẤT LƯỢNG, mô tả hệ thống hoạt động TỐT ĐẾN MỨC NÀO chứ không phải hệ thống làm được gì. Việc đánh giá chúng thuộc phạm vi kiểm thử phi chức năng. Kiểm thử chức năng (B) chỉ kiểm tra hệ thống có thực hiện đúng các chức năng đặc tả hay không; tích hợp hệ thống (A) là một mức kiểm thử, quan tâm tới giao tiếp giữa các hệ thống; kiểm thử yêu cầu (D) không phải một loại kiểm thử tiêu chuẩn theo cách phân loại chức năng - phi chức năng - cấu trúc - liên quan đến thay đổi.

Khi phát hiện và sửa lỗi trong phần mềm, việc retest (lặp lại kiểm tra) để xác nhận rằng lỗi gốc đã được loại bỏ thành công là rất quan trọng. Điều này được gọi là kiểm tra xác nhận (Confirmation testing). Kiểm tra xác nhận là một phần quan trọng của quy trình kiểm tra phần mềm và giúp đảm bảo rằng phần mềm đã được sửa lỗi một cách chính xác và hiệu quả. Trong quá trình kiểm tra xác nhận, các kỹ sư kiểm tra sẽ lặp lại các thử nghiệm đã được thực hiện trước đó để xác nhận rằng lỗi đã được loại bỏ và phần mềm hoạt động đúng như mong đợi. Nếu lỗi vẫn còn tồn tại, các kỹ sư sẽ phải sửa lỗi lại và lặp lại quá trình kiểm tra xác nhận cho đến khi lỗi được loại bỏ hoàn toàn. Kiểm tra xác nhận giúp đảm bảo rằng phần mềm đã được kiểm tra một cách đầy đủ và hiệu quả, giảm thiểu rủi ro lỗi và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.

Đáp án đúng: D. Kiểm thử hệ thống (system testing) tiến hành trên toàn bộ hệ thống đã tích hợp, kiểm tra mọi yêu cầu chức năng, thông tin, cấu trúc và chất lượng, và dùng một bộ ca kiểm thử đã định trước để chứng minh với ban quản lý rằng hệ thống đáp ứng đặc tả. Kiểm thử tích hợp (B) chỉ tập trung vào giao tiếp giữa các thành phần; kiểm thử chấp nhận người dùng (C) do người dùng thực hiện theo tiêu chí chấp nhận của họ, sau kiểm thử hệ thống; còn kiểm thử thẩm định (A) là khái niệm rộng, trả lời câu hỏi có xây dựng đúng sản phẩm hay không chứ không phải một mức kiểm thử cụ thể như mô tả trong đề.

Đáp án đúng: C. Chi phí sửa một lỗi tăng theo cấp số nhân khi lỗi được phát hiện muộn vì lỗi đó đã bị "xây" vào ngày càng nhiều sản phẩm trung gian: tài liệu thiết kế, mã nguồn, ca kiểm thử, dữ liệu kiểm thử và cả những phần đã dựa trên nó. Sửa lỗi lúc này kéo theo sửa toàn bộ chuỗi sản phẩm ấy rồi kiểm thử hồi quy lại. Phương án A và B nêu những nguyên nhân ngoại vi (tài liệu kém, lương tăng) chỉ có tác động thứ yếu; phương án D bị loại vì C đã nêu đúng nguyên nhân cốt lõi.

Validation là quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Nó giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng, hiệu suất và chất lượng mong muốn. Trong quá trình phát triển sản phẩm, validation giúp kiểm tra rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn, giúp giảm thiểu các lỗi và sai sót. Điều này giúp đảm bảo rằng sản phẩm cuối cùng được xây dựng là đúng và đáp ứng được các yêu cầu của khách hàng. Validation không chỉ giúp kiểm tra chất lượng sản phẩm mà còn giúp kiểm tra rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Nó giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng, hiệu suất và chất lượng mong muốn. Điều này giúp giảm thiểu các lỗi và sai sót trong quá trình phát triển sản phẩm. Trong khi đó, các lựa chọn khác không chính xác. Lựa chọn i nói rằng validation giúp kiểm tra chất lượng sản phẩm, nhưng điều này không hoàn toàn chính xác. Validation không chỉ giúp kiểm tra chất lượng sản phẩm mà còn giúp kiểm tra rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Lựa chọn iii nói rằng validation giúp phát triển sản phẩm, nhưng điều này không chính xác. Validation là quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn, không phải là quá trình phát triển sản phẩm. Lựa chọn iv nói rằng validation giúp theo dõi công cụ bị hao mòn và lỗi thời, nhưng điều này không liên quan đến validation. Validation chỉ liên quan đến quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Tóm lại, validation là quá trình kiểm tra và xác minh rằng sản phẩm đã được xây dựng đúng theo yêu cầu và tiêu chuẩn. Nó giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu chức năng, hiệu suất và chất lượng mong muốn. Lựa chọn ii là đúng, còn các lựa chọn khác không chính xác.

Đáp án đúng: D. Phát biểu SAI là "kiểm thử thành phần không liên quan tới kiểm thử hồi quy": khi một thành phần được sửa, chính ở mức thành phần người ta phải chạy lại các ca kiểm thử cũ để bảo đảm thay đổi không phá vỡ hành vi đã đúng - đó là kiểm thử hồi quy ở mức đơn vị, thường được tự động hoá. Các phát biểu còn lại đều đúng: kiểm thử thành phần thường do chính đội phát triển thực hiện (A), còn được gọi là kiểm thử đơn vị, kiểm thử mô-đun hay kiểm thử cô lập (B), và cũng cần được lập kế hoạch với tiêu chí hoàn thành rõ ràng (C).

Đáp án đúng: A. Theo thuật ngữ chuẩn, failure (hỏng hóc) là biểu hiện hành vi sai của chương trình khi thực thi, do một fault (lỗi trong mã) gây ra, và fault lại bắt nguồn từ error (sai sót của con người). Vì vậy failure gắn với hành vi chạy sai chứ không gắn với thời điểm tìm thấy lỗi. Các phương án B, C, D đều định nghĩa theo mốc thời gian phát hiện - trước khi phát hành, sau khi phát hành hay trong pha thiết kế - nên nhầm giữa khái niệm failure với cách phân loại lỗi theo giai đoạn.