Ôn tập thi lại SWT301 Summer 2024

Fault Masking là một kỹ thuật trong kiểm thử phần mềm, liên quan đến việc che giấu hoặc ẩn đi lỗi trong hệ thống. Trong câu hỏi này, chúng ta đang được hỏi về định nghĩa của Fault Masking. Câu trả lời đúng là "Error condition hiding another error condition", có nghĩa là việc che giấu một lỗi khác. Điều này có thể xảy ra khi một lỗi được ẩn đi bởi một lỗi khác, khiến cho lỗi ban đầu không được phát hiện. Ví dụ, một lỗi về dữ liệu có thể được che giấu bởi một lỗi về giao diện người dùng. Fault Masking có thể xảy ra do nhiều nguyên nhân, bao gồm cả lỗi của nhà phát triển và lỗi của người kiểm thử. Tuy nhiên, mục tiêu của Fault Masking là để đảm bảo rằng hệ thống hoạt động đúng và không bị lỗi.

Hệ thống quản lý yêu cầu (Requirements Management Tools) là công cụ giúp lưu trữ các tuyên bố yêu cầu, kiểm tra tính nhất quán và cho phép sắp xếp ưu tiên các yêu cầu. Đồng thời, nó cho phép từng thử nghiệm riêng biệt có thể được theo dõi đến các yêu cầu, chức năng và tính năng. Hệ thống này giúp đảm bảo rằng các yêu cầu được quản lý một cách hiệu quả và chính xác, từ đó giúp giảm thiểu các sai sót trong quá trình phát triển phần mềm.

Thực tế, việc quản lý và cung cấp một thư viện được kiểm soát chứa tất cả các mặt hàng cấu hình được gọi là "Configuration Control". Điều này bao gồm việc quản lý và theo dõi các thay đổi đối với các mặt hàng cấu hình, đảm bảo rằng tất cả các phiên bản mới được kiểm tra và phê duyệt trước khi được triển khai. Configuration Control giúp đảm bảo rằng các mặt hàng cấu hình được quản lý một cách hiệu quả và giảm thiểu rủi ro khi triển khai các thay đổi.

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 loại trả lời là i. Cơ sở hạ tầng ghi lại và tái tạo là ít có khả năng được sử dụng để Đáp án: - Performance testing (kiểm tra hiệu suất) - Recovery testing (kiểm tra phục hồi) - GUI testing (kiểm tra giao diện người dùng) - User requirements (yêu cầu người dùng) Câu trả lời đúng là Performance testing. Giải thích: Cơ sở hạ tầng ghi lại và tái tạo thường được sử dụng để tái tạo lại các tình huống thử nghiệm phức tạp, chẳng hạn như kiểm tra giao diện người dùng hoặc kiểm tra phục hồi. Tuy nhiên, chúng không phù hợp để kiểm tra hiệu suất, vì hiệu suất thường liên quan đến việc đo lường tốc độ và hiệu quả của hệ thống trong thời gian dài, và cơ sở hạ tầng ghi lại và tái tạo không thể tái tạo lại toàn bộ quá trình thời gian dài này.

Khi chọn và triển khai công cụ kiểm thử, có một số hoạt động quan trọng cần được thực hiện. Trước hết, cần phải xác định mục tiêu và yêu cầu của dự án, bao gồm cả các yêu cầu về tính hiệu suất, độ tin cậy và khả năng mở rộng của công cụ kiểm thử. Sau đó, cần phải đánh giá và so sánh các công cụ kiểm thử khác nhau để chọn ra công cụ phù hợp nhất với nhu cầu của dự án. Ngoài ra, cần phải xem xét các yếu tố như chi phí, tính dễ sử dụng và khả năng tích hợp với các hệ thống khác. Cuối cùng, cần phải lập kế hoạch và triển khai công cụ kiểm thử một cách hiệu quả, bao gồm cả việc đào tạo nhân viên và thiết lập quy trình kiểm thử.

Hoạt động nào trong quá trình thử nghiệm cơ bản tạo ra bộ thử nghiệm để thực hiện thử nghiệm một cách hiệu quả? Trong quá trình thử nghiệm cơ bản, có bốn hoạt động chính: Planning và Control, Analysis và Design, Implementation và Execution, Test Closure. Trong đó, Analysis và Design là hoạt động tạo ra bộ thử nghiệm để thực hiện thử nghiệm một cách hiệu quả. Hoạt động này bao gồm việc phân tích yêu cầu của sản phẩm, thiết kế bộ thử nghiệm và xác định các trường hợp thử nghiệm cần thực hiện.

Các phương pháp trả lời được sử dụng trong các bàn làm việc cá nhân để sản xuất các sản phẩm đầu ra đúng. Các phương pháp này giúp đảm bảo rằng các sản phẩm đầu ra được tạo ra một cách chính xác và hiệu quả. Ví dụ, các công cụ và kỹ thuật được sử dụng để thực hiện các tác vụ cụ thể, trong khi các thủ tục và tiêu chuẩn được sử dụng để đảm bảo rằng các tác vụ được thực hiện theo đúng quy trình. Các quá trình và kiểm tra được sử dụng để đảm bảo rằng các sản phẩm đầu ra đáp ứng các yêu cầu và tiêu chuẩn. Cuối cùng, các đánh giá và cập nhật được sử dụng để đánh giá và cải thiện các phương pháp trả lời.

Khi một người đang thống trị cuộc họp cải tiến quy trình phần mềm, người dẫn cuộc họp cần sử dụng các kỹ thuật phù hợp để khuyến khích các thành viên khác tham gia thảo luận. Kỹ thuật phù hợp trong trường hợp này là chuyển chủ đề sang vấn đề mà người đó không có ý kiến mạnh mẽ. Điều này cho phép người dẫn cuộc họp tạo cơ hội cho các thành viên khác thể hiện ý kiến của mình, đồng thời giúp ngăn chặn việc một người duy trì quyền kiểm soát cuộc họp. Bằng cách chuyển chủ đề, người dẫn cuộc họp có thể tạo ra một môi trường thảo luận tích cực và đa dạng, nơi mà mọi người đều có cơ hội thể hiện ý kiến của mình.

Phương pháp phòng ngừa và phản ứng trong kiểm thử là hai cách tiếp cận khác nhau trong việc phát hiện lỗi trong phần mềm. Phương pháp phòng ngừa là việc thiết kế và thực hiện kiểm thử ngay từ đầu của quá trình phát triển phần mềm, nhằm phát hiện và sửa lỗi ngay khi còn nhỏ. Trong khi đó, phương pháp phản ứng là việc thiết kế và thực hiện kiểm thử sau khi phần mềm đã được sản xuất, thường là sau khi nhận được phản hồi từ người dùng hoặc trong quá trình kiểm tra lại phần mềm. Điều này cho thấy, phương pháp phòng ngừa là thiết kế kiểm thử sớm, trong khi phương pháp phản ứng là thiết kế kiểm thử sau khi phần mềm đã được sản xuất.

Khái niệm kiểm thử hoàn chỉnh được định nghĩa là quá trình kiểm thử mà trong đó bạn đã kiểm tra tất cả các câu lệnh, nhánh và sự kết hợp của các nhánh trong chương trình. Điều này có nghĩa là bạn đã kiểm tra tất cả các khả năng có thể xảy ra trong chương trình và đảm bảo rằng chương trình hoạt động đúng như mong đợi. Kiểm thử hoàn chỉnh không chỉ đơn giản là kiểm tra mọi thứ mà còn bao gồm cả việc kiểm tra các trường hợp ngoại lệ, các lỗi có thể xảy ra và các điều kiện đặc biệt. Mục tiêu của kiểm thử hoàn chỉnh là đảm bảo rằng chương trình ổn định, hiệu suất cao và đáp ứng được các yêu cầu của người dùng.

FPA (Function Point Analysis) là một phương pháp đo lường được sử dụng để ước tính kích thước của một hệ thống thông tin. Nó giúp đánh giá các yêu cầu chức năng của dự án và đo lường mức độ phức tạp của hệ thống. FPA tập trung vào việc đo lường các yêu cầu chức năng, bao gồm các yêu cầu nhập, yêu cầu xuất và các yêu cầu xử lý. Mục đích của FPA là cung cấp một cách đo lường khách quan và đáng tin cậy về kích thước của hệ thống, giúp các nhà phát triển dự án có thể lập kế hoạch và quản lý dự án một cách hiệu quả hơn.

Để phát hiện mã không thể đạt được (unreachable code), chúng ta nên sử dụng công cụ phân tích tĩnh (static analysis tool). Công cụ này có khả năng phân tích mã nguồn mà không cần thực hiện chạy thử nghiệm (runtime). Nó có thể phát hiện các đoạn mã không thể đạt được, cũng như các vấn đề khác như lặp vô hạn, lỗi null pointer, v.v. Ngoài ra, công cụ phân tích tĩnh cũng có thể giúp phát hiện các vấn đề về bảo mật, như việc sử dụng các hàm có thể bị khai thác để thực hiện tấn công, v.v. Vì vậy, sử dụng công cụ phân tích tĩnh là cách tốt nhất để phát hiện mã không thể đạt được.

Để xác định loại trả lời đúng, chúng ta cần hiểu rõ về các công cụ được đề cập. Công cụ phân tích động (Dynamic analysis tool) là một công cụ được sử dụng để theo dõi và phân tích hành vi của chương trình trong thời gian chạy. Nó có thể giúp phát hiện các vấn đề như memory leaks và unassigned pointers. Công cụ phân tích tĩnh (Static Analysis tool) được sử dụng để phân tích mã nguồn của chương trình mà không cần chạy nó. Nó có thể giúp phát hiện các vấn đề như syntax và logic, nhưng không thể phát hiện các vấn đề về memory leaks và unassigned pointers. Công cụ bảo trì (Maintenance tool) và công cụ cấu hình (Configuration tool) không liên quan đến việc phát hiện memory leaks và unassigned pointers. Vì vậy, công cụ phân tích động (Dynamic analysis tool) là công cụ phù hợp để test flag memory leaks và unassigned pointers.

Để tìm ra sự không phù hợp trong các lựa chọn, chúng ta cần hiểu rõ chức năng của từng loại công cụ. Công cụ chuẩn bị dữ liệu thử nghiệm (Test data preparation tools) thường được sử dụng để tạo hoặc chỉnh sửa dữ liệu thử nghiệm. Công cụ thiết kế thử nghiệm (Test design tools) giúp tạo ra các đầu vào thử nghiệm. Công cụ quản lý yêu cầu (Requirement management tools) hỗ trợ việc theo dõi các thử nghiệm riêng lẻ. Công cụ quản lý cấu hình (Configuration management tools) giúp kiểm tra sự nhất quán. Tuy nhiên, trong các lựa chọn, 'Manipulate Data bases' không phải là chức năng chính của công cụ chuẩn bị dữ liệu thử nghiệm. Thay vào đó, nó thường liên quan đến việc tạo hoặc chỉnh sửa cơ sở dữ liệu. Do đó, 'Manipulate Data bases' là sự không phù hợp trong các lựa chọn.

User Acceptance Testing (UAT) là một phần quan trọng trong quy trình phát triển phần mềm. Nó giúp đảm bảo rằng sản phẩm đáp ứng được yêu cầu và kỳ vọng của người dùng. Có một số đặc điểm của UAT, bao gồm việc sử dụng các công cụ thực thi thử nghiệm tự động, việc thử nghiệm được thực hiện bởi người dùng và việc thử nghiệm dựa trên các tiêu chí thử nghiệm được chấp nhận. Tuy nhiên, việc tích hợp hệ thống với tài liệu người dùng không phải là một đặc điểm của UAT. Thay vào đó, nó là một phần của quy trình phát triển phần mềm, giúp đảm bảo rằng hệ thống được triển khai và sử dụng một cách hiệu quả. Vì vậy, trong các lựa chọn trên, "Tích hợp hệ thống với tài liệu người dùng" không phải là một đặc điểm của UAT.

Một Test Lead / Leader có nhiều nhiệm vụ quan trọng trong quá trình kiểm thử phần mềm. Dưới đây là một số nhiệm vụ chính của họ: - Lập kế hoạch và quản lý dự án kiểm thử (i): Test Lead / Leader chịu trách nhiệm lập kế hoạch và quản lý dự án kiểm thử, bao gồm việc xác định mục tiêu, phạm vi và thời gian của dự án. - Xây dựng và quản lý đội ngũ kiểm thử (ii): Họ phải xây dựng và quản lý đội ngũ kiểm thử, bao gồm việc tuyển dụng, đào tạo và quản lý nhân viên. - Xác định và quản lý các yêu cầu kiểm thử (iii): Test Lead / Leader phải xác định và quản lý các yêu cầu kiểm thử, bao gồm việc xác định các trường hợp kiểm thử và các tiêu chí đánh giá. - Đánh giá và báo cáo kết quả kiểm thử (iv): Cuối cùng, họ phải đánh giá và báo cáo kết quả kiểm thử, bao gồm việc xác định các vấn đề và đề xuất các giải pháp. Vì vậy, câu trả lời đúng là "ili và iv là đúng và i và ii là sai".

Chất lượng phần mềm không liên quan đến việc trả lời câu hỏi này vì phần mềm chất lượng cao không nhất thiết phải có tính đúng đắn. Tuy nhiên, tính đúng đắn là một yếu tố quan trọng trong việc đảm bảo phần mềm hoạt động đúng như mong đợi. Tính khả dụng và tính tái sử dụng cũng là những yếu tố quan trọng trong việc đánh giá chất lượng phần mềm. Tính khả dụng liên quan đến khả năng sử dụng phần mềm một cách dễ dàng và hiệu quả, trong khi tính tái sử dụng liên quan đến khả năng sử dụng lại phần mềm trong các dự án khác. Tính khả dụng và tính tái sử dụng là những yếu tố quan trọng trong việc đảm bảo phần mềm có thể được sử dụng rộng rãi và hiệu quả.

Các loại mô hình trả lời là il là mô hình mô tả quá trình hoạt động của một phần mềm. Trong đó, mô hình dòng chảy quy trình (Process flow model) không thể được sử dụng trong thử nghiệm chức năng vì nó mô tả quá trình hoạt động của phần mềm mà không thể xác định được các chức năng cụ thể của phần mềm. Mô hình trạng thái giao dịch (State transaction model) và mô hình cấu trúc menu (Menu structure model) có thể được sử dụng trong thử nghiệm chức năng vì chúng mô tả các chức năng cụ thể của phần mềm. Mô hình mô tả bằng ngôn ngữ thông thường (Plain language specification model) cũng không thể được sử dụng trong thử nghiệm chức năng vì nó mô tả phần mềm bằng ngôn ngữ thông thường mà không thể xác định được các chức năng cụ thể của phần mềm.

Kiểm tra trường hợp sử dụng (Use Case Testing) thường được sử dụng để phát hiện các lỗi liên quan đến yêu cầu chức năng của hệ thống. Các lỗi này thường bao gồm các vấn đề về logic, quy trình và giao diện người dùng. Vì vậy, loại lỗi mà kiểm tra trường hợp sử dụng có khả năng phát hiện được nhất là các lỗi liên quan đến yêu cầu chức năng của hệ thống, bao gồm lỗi về logic (ii) và lỗi về giao diện người dùng (iii).