Đề ôn · SWT301

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

59 câu · Thi lại · Summer 2025

59câu trong đề
SWT301môn

Câu hỏi của đề

15/59 câuCòn 44
AWe are looking for errors and fixing them.
BWe are looking for defects in the product and thus are critical of it.
CWe are looking for the difference between the system and the requirement.
DWe are looking for the mistakes of the requirement.
Lời giải
Khi chúng ta kiểm tra hoặc đánh giá một sản phẩm, mục tiêu chính là tìm kiếm các lỗi hoặc khuyết tật trong sản phẩm. Điều này có nghĩa là chúng ta sẽ đánh giá sản phẩm một cách nghiêm ngặt và tìm kiếm các điểm yếu hoặc vấn đề cần cải thiện. Việc này giúp chúng ta hiểu rõ hơn về sản phẩm và có thể đưa ra các đề xuất hoặc giải pháp để khắc phục các lỗi hoặc khuyết tật đó. Mục tiêu của việc kiểm tra hoặc đánh giá sản phẩm là đảm bảo rằng sản phẩm đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra.
Mở trang câu hỏi này →
AAmistake made by a developer.
BA defect in the software that is found during testing.
CAn incorrect behavior of the system in operation.
DA missed requirement during design.
Lời giải
Trong ngữ cảnh của kiểm thử, từ 'failure' thường được hiểu là một lỗi hoặc một điểm yếu trong phần mềm được phát hiện trong quá trình kiểm thử. Nó không chỉ giới hạn ở một lỗi được tạo ra bởi nhà phát triển, mà còn bao gồm cả những điểm yếu hoặc lỗi trong thiết kế phần mềm. Lỗi này có thể được phát hiện trong quá trình kiểm thử đơn vị, kiểm thử tích hợp hoặc kiểm thử hệ thống. Khi một lỗi được phát hiện, nó sẽ được coi là một trường hợp 'failure' và sẽ được xử lý để đảm bảo rằng phần mềm hoạt động đúng và đáp ứng được các yêu cầu của người dùng.
Mở trang câu hỏi này →
ATests by the person who wrote the item under test.
BTests by a person from a different organizational group, such as an independent test team.
CTests by another person within the same team, such as another programmer.
DTests by the person who wrote the source code.
Lời giải
Mô tả về câu trả lời đúng và sai trong câu hỏi này là như sau: Câu trả lời đúng là 'Tests by a person from a different organizational group, such as an independent test team.' Câu trả lời sai là 'Tests by the person who wrote the item under test.', 'Tests by another person within the same team, such as another programmer.', và 'Tests by the person who wrote the source code.' Vì trong quá trình kiểm thử độc lập, người kiểm thử độc lập không phải là người viết mã nguồn hoặc người trong cùng nhóm, mà là một cá nhân độc lập từ nhóm khác.
Mở trang câu hỏi này →
AItis irrelevant since all testing follows the same standard.
BItis critical as testing approaches should vary based on the specific context.
CIt suggests that testing should always follow the same international standards.
DContext is only important in large, complex systems.
Lời giải
Trong nguyên tắc kiểm thử, ngữ cảnh đóng vai trò quan trọng. Nó chỉ ra rằng các phương pháp kiểm thử nên thay đổi dựa trên ngữ cảnh cụ thể. Điều này có nghĩa là, khi kiểm thử một sản phẩm hoặc hệ thống, chúng ta cần xem xét ngữ cảnh mà sản phẩm hoặc hệ thống đó sẽ được sử dụng. Ví dụ, một ứng dụng di động có thể cần được kiểm thử trên các thiết bị di động khác nhau, trong khi một ứng dụng web có thể cần được kiểm thử trên các trình duyệt khác nhau. Ngữ cảnh giúp chúng ta xác định các yêu cầu và điều kiện kiểm thử cụ thể, từ đó đảm bảo rằng sản phẩm hoặc hệ thống đáp ứng được nhu cầu của người dùng.
Mở trang câu hỏi này →
ATesting can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.
BTesting activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
CFinding and fixing defects does not help if the system built is unusable and does not fulfill the users' needs and expectations.
DTesting is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.
Lời giải
Kết quả kiểm thử cho thấy sự hiện diện của các lỗi. Kiểm thử có thể cho thấy các lỗi đang tồn tại, nhưng không thể chứng minh rằng không có lỗi nào. Kiểm thử giảm khả năng có các lỗi chưa được phát hiện còn tồn tại trong phần mềm, nhưng ngay cả khi không tìm thấy lỗi nào, nó không phải là bằng chứng về sự chính xác. Kiểm thử không thể chứng minh rằng phần mềm hoàn toàn không có lỗi, nhưng nó có thể giúp giảm thiểu số lượng lỗi còn tồn tại. Điều này có nghĩa là, ngay cả khi phần mềm đã được kiểm thử kỹ lưỡng, vẫn có thể có các lỗi chưa được phát hiện. Vì vậy, kiểm thử không phải là một công cụ để chứng minh sự chính xác của phần mềm, mà là một công cụ để giảm thiểu số lượng lỗi và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.
Mở trang câu hỏi này →
APerformance-related defects
BDefects in user interface design
CMissing requirements or design defects
DRuntime errors and exceptions
Lời giải
Trong quá trình kiểm thử tĩnh (static testing), các loại lỗi thường được phát hiện hiệu quả hơn so với kiểm thử động (dynamic testing) là những lỗi liên quan đến yêu cầu hoặc thiết kế. Điều này bao gồm các lỗi như yêu cầu không đầy đủ, thiết kế không phù hợp, hoặc các lỗi khác liên quan đến yêu cầu hoặc thiết kế của hệ thống. Kiểm thử tĩnh cho phép các chuyên gia kiểm thử có thể xem xét và đánh giá yêu cầu, thiết kế và mã nguồn của hệ thống mà không cần phải thực hiện các thử nghiệm thực tế. Điều này giúp phát hiện các lỗi liên quan đến yêu cầu hoặc thiết kế một cách hiệu quả hơn.
Mở trang câu hỏi này →
ATo increase software complexity
BTo identify defects in software
CTo reduce software features
DTo speed up software development
Lời giải
Mục đích chính của việc kiểm thử phần mềm là xác định các lỗi trong phần mềm. Khi phần mềm được phát triển, các lỗi thường không được phát hiện ngay lập tức. Kiểm thử phần mềm giúp phát hiện ra các lỗi này, từ đó giúp nhà phát triển sửa lỗi và cải thiện chất lượng phần mềm. Việc kiểm thử phần mềm cũng giúp đảm bảo rằng phần mềm hoạt động đúng như mong đợi, giảm thiểu rủi ro khi triển khai phần mềm vào sản xuất.
Mở trang câu hỏi này →
8How much testing is enough?4 lựa chọn
AExhaustive testing is possible.
BTesting everything (all combinations of inputs and preconditions).
CWe use risks and priorities to focus testing efforts.
DFull testing.
Lời giải
Câu hỏi này hỏi về mức độ đủ của việc kiểm thử. Có ba lựa chọn: Kiểm thử đầy đủ là có thể, Kiểm thử mọi thứ (tất cả các kết hợp của đầu vào và điều kiện tiền đề), Sử dụng rủi ro và ưu tiên để tập trung vào nỗ lực kiểm thử. Tuy nhiên, trong thực tế, kiểm thử đầy đủ không phải lúc nào cũng có thể thực hiện được do chi phí và thời gian cao. Vì vậy, lựa chọn đúng là Sử dụng rủi ro và ưu tiên để tập trung vào nỗ lực kiểm thử. Điều này có nghĩa là chúng ta sẽ tập trung vào các trường hợp kiểm thử quan trọng nhất dựa trên mức độ rủi ro và ưu tiên của chúng. Điều này giúp chúng ta tối ưu hóa thời gian và nguồn lực cho việc kiểm thử.
Mở trang câu hỏi này →
AIt enhances the efficiency of the development and testing processes.
BIt may lead to misunderstandings and reduced software quality.
CIt improves the independence of the testing function.
DIt has no effect as long as testing is done independently.
Lời giải
Khi giao tiếp giữa các tester và nhà phát triển không tốt, có thể dẫn đến hiểu lầm và giảm chất lượng phần mềm. Điều này xảy ra khi các tester và nhà phát triển không thể hiểu rõ được yêu cầu và mục tiêu của nhau, dẫn đến việc phát triển phần mềm không đúng như mong đợi. Ngoài ra, giao tiếp kém cũng có thể dẫn đến việc chậm trễ trong quá trình phát triển và thử nghiệm, gây ra sự lãng phí thời gian và nguồn lực. Vì vậy, giao tiếp hiệu quả giữa các tester và nhà phát triển là rất quan trọng để đảm bảo chất lượng phần mềm và giảm thiểu các vấn đề phát sinh.
Mở trang câu hỏi này →
AFostering mutual respect between roles.
BEnsuring clear objectives for testing.
CFeedback belittles the coder with errors found.
DEncouraging collaboration on defect resolution.
Lời giải
Để giảm thiểu xung đột tâm lý giữa các tester và developer, chúng ta có thể áp dụng các chiến lược sau đây. Trước hết, chúng ta cần tạo ra một môi trường làm việc tích cực, nơi mà cả tester và developer đều được tôn trọng và đánh giá cao. Điều này có thể được thực hiện thông qua việc tạo ra một văn hóa làm việc thân thiện và tôn trọng lẫn nhau. Thứ hai, chúng ta cần đảm bảo rằng mục tiêu và yêu cầu của quá trình kiểm thử được rõ ràng và dễ hiểu. Điều này sẽ giúp giảm thiểu sự nhầm lẫn và xung đột giữa các bên. Cuối cùng, chúng ta cần khuyến khích sự hợp tác và làm việc cùng nhau trong việc giải quyết các lỗi và vấn đề. Điều này sẽ giúp tăng cường sự hiểu biết và tôn trọng lẫn nhau giữa các tester và developer.
Mở trang câu hỏi này →
ATesting the database and data processing
BEnsuring that software modules work together
CChecking that the system is ready for live deployment
DEvaluating user satisfaction with the product
Lời giải
Integration testing là một phần quan trọng trong quá trình kiểm thử phần mềm. Mục tiêu chính của việc kiểm thử tích hợp là đảm bảo rằng các mô-đun phần mềm hoạt động cùng nhau một cách trơn tru và hiệu quả. Điều này bao gồm việc kiểm tra giao tiếp giữa các mô-đun, đảm bảo rằng dữ liệu được truyền và nhận đúng cách, và kiểm tra rằng hệ thống có thể xử lý các yêu cầu phức tạp một cách chính xác. Việc kiểm thử tích hợp giúp phát hiện ra các lỗi và vấn đề tiềm ẩn trong hệ thống, từ đó giúp cải thiện chất lượng và độ tin cậy của phần mềm.
Mở trang câu hỏi này →
AStress testing examines system performance under peak loads, while load testing focuses on typical conditions
BStress testing is concerned with usability under stress, while load testing measures performance thresholds
CStress testing evaluates system behavior beyond normal operational capacity, while load testing verifies normal usage conditions
Lời giải
Stress testing và load testing đều là các phương pháp kiểm tra hiệu suất của hệ thống, nhưng chúng phục vụ cho các mục đích khác nhau. Stress testing tập trung vào việc kiểm tra hệ thống khi nó hoạt động ở mức tải cao, vượt quá khả năng hoạt động bình thường. Điều này giúp xác định giới hạn chịu tải của hệ thống và đảm bảo rằng nó có thể xử lý được các tình huống khẩn cấp. Ngược lại, load testing tập trung vào việc kiểm tra hệ thống khi nó hoạt động ở mức tải bình thường, giúp xác định xem hệ thống có thể xử lý được các yêu cầu thông thường hay không. Tóm lại, stress testing là một phương pháp kiểm tra hiệu suất của hệ thống ở mức tải cao, trong khi load testing là một phương pháp kiểm tra hiệu suất của hệ thống ở mức tải bình thường.
Mở trang câu hỏi này →
AIt eliminates the need for testing.
BIt integrates testing throughout the development phases.
CItis less costly and time-consuming compared to other models.
DIt focuses on post-development testing only.
Lời giải
V-model trong phát triển phần mềm là một mô hình giúp tích hợp kiểm thử vào các giai đoạn phát triển. Ưu điểm chính của V-model là nó cho phép kiểm thử được thực hiện đồng thời với các giai đoạn phát triển khác nhau, từ thiết kế đến triển khai và bảo trì. Điều này giúp phát hiện và sửa lỗi sớm, giảm thiểu chi phí và thời gian phát triển. Ngoài ra, V-model cũng giúp đảm bảo chất lượng của sản phẩm phần mềm và cải thiện hiệu suất của đội ngũ phát triển. Nhờ đó, V-model trở thành một trong những mô hình phát triển phần mềm phổ biến và được sử dụng rộng rãi.
Mở trang câu hỏi này →
ATo test the entire system as a whole
BTo test individual units or components in isolation
CTo validate the software against user requirements
DTo perform performance testing
Lời giải
Unit testing trong phát triển phần mềm có mục đích kiểm tra từng đơn vị hoặc thành phần riêng biệt. Điều này giúp đảm bảo rằng từng phần của hệ thống hoạt động chính xác và độc lập. Quá trình này giúp phát hiện ra lỗi sớm và hiệu quả hơn so với việc kiểm tra toàn bộ hệ thống. Unit testing cũng giúp cải thiện độ tin cậy và ổn định của hệ thống, đồng thời giảm thiểu thời gian và chi phí cần thiết để phát triển và bảo trì phần mềm. Nó cũng giúp cho các nhà phát triển có thể dễ dàng sửa lỗi và cập nhật phần mềm mà không ảnh hưởng đến các thành phần khác.
Mở trang câu hỏi này →
AItis always performed after functional testing.
BIt focuses on how well the system performs certain actions.
CItis concerned solely with what the system does.
DIt does not include performance testing.
Lời giải
Non-functional testing là một loại kiểm thử phần mềm tập trung vào các tính chất không liên quan trực tiếp đến chức năng của hệ thống. Điều này bao gồm các yếu tố như hiệu suất, độ tin cậy, khả năng chịu tải, bảo mật và tương thích. Non-functional testing giúp đảm bảo rằng hệ thống hoạt động một cách ổn định và hiệu quả trong các tình huống khác nhau. Ví dụ, hiệu suất của hệ thống có thể được kiểm thử bằng cách đo thời gian tải dữ liệu hoặc thực hiện các tác vụ phức tạp. Độ tin cậy có thể được kiểm thử bằng cách đánh giá khả năng hệ thống hoạt động mà không gặp lỗi trong thời gian dài. Khả năng chịu tải có thể được kiểm thử bằng cách đo khả năng hệ thống xử lý số lượng lớn dữ liệu hoặc người dùng. Mục tiêu của non-functional testing là đảm bảo rằng hệ thống đáp ứng các yêu cầu về hiệu suất, độ tin cậy và khả năng chịu tải.
Mở trang câu hỏi này →