Font size
WorksheetsKiểm Thử Phần Mềm
Total questions: 115
Worksheet time: 3600secs
Điều gì có thể xảy ra nếu không kiểm thử phần mềm?
Phần mềm luôn hoạt động ổn định
Không ảnh hưởng vì code đã được lập trình cẩn thận
Dễ phát sinh lỗi, gây mất uy tín và tổn thất tài chính
Chỉ gây lỗi nhỏ, không nghiêm trọng
Lỗi nào sau đây thường nghiêm trọng hơn?
Lỗi chính tả trong giao diện
Lỗi font chữ
Lỗi nút không căn giữa
Lỗi tính toán sai số tiền giao dịch
Phát biểu nào sau đây đúng về xác minh (verification)?
Kiểm tra phần mềm có đáp ứng nhu cầu người dùng không
Diễn ra sau khi triển khai sản phẩm
Là quá trình kiểm tra phần mềm có xây đúng theo yêu cầu kỹ thuật không
Là quá trình kiểm tra giao diện có đẹp không
"Build the right product" là nói về quy trình nào?
Documentation
Verification
Deployment
Validation
Khi nào nên thực hiện phê chuẩn (validation)?
Ngay sau khi viết tài liệu đặc tả
Khi mới bắt đầu lập trình
Khi đã có bản phần mềm chạy được
Trước khi viết mã
Kiểm thử phần mềm có thể gồm những hoạt động nào sau đây?
Chỉ bao gồm việc chạy chương trình
Review tài liệu, phân tích yêu cầu, viết và chạy test case
Viết code mới cho developer
Thiết kế giao diện phần mềm
Phát biểu nào đúng về "kiểm thử động" (dynamic testing)?
Là quá trình kiểm tra thiết kế không cần chạy phần mềm
Là quá trình review tài liệu đặc tả
Là quá trình chạy phần mềm để tìm lỗi trong lúc thực thi
Là quá trình tạo mockup cho khách hàng
Quan niệm sai lầm nào sau đây là phổ biến trong kiểm thử?
Kiểm thử bao gồm lập kế hoạch và theo dõi tiến độ
Kiểm thử cần quan tâm cảm nhận của người dùng
Kiểm thử chỉ là chạy test (execute test)
Tester nên viết báo cáo lỗi đầy đủ
Tại sao việc "verify" phần mềm thôi là chưa đủ?
Vì phần mềm có thể đúng nhưng vẫn không thân thiện người dùng
Vì verify là việc của developer
Vì test case thường sai
Vì khách hàng không quan tâm đến tính đúng đắn
Kiểm thử tĩnh thường bao gồm hoạt động nào?
Viết code
Phân tích yêu cầu, review code, đánh giá tài liệu
Chạy phần mềm trên môi trường thật
Mô phỏng người dùng nhập dữ liệu
Điều nào sau đây là đúng về Testing?
Là quá trình sửa lỗi trong phần mềm
Là quá trình tìm nguyên nhân gây ra lỗi
Có thể kích hoạt failure do defect gây ra
Chỉ được thực hiện sau khi phần mềm hoàn thành
Testing có thể bao gồm những hình thức nào sau đây?
Kiểm thử động và kiểm thử tĩnh
Kiểm thử thủ công và tự động
Kiểm thử hộp trắng và hộp đen
Kiểm thử đơn vị và kiểm thử tích hợp
Phát biểu nào sau đây là đúng về Debugging?
Là quá trình kiểm thử phần mềm tự động
Là quá trình tìm và loại bỏ nguyên nhân gây ra failure
Là cách phát hiện bug bằng kiểm thử tĩnh
Là phương pháp kiểm thử hộp đen
Các bước chính trong Debugging bao gồm:
Viết test case → Chạy test → Báo lỗi
Tái hiện lỗi → Chẩn đoán → Khắc phục
Thiết kế phần mềm → Kiểm thử → Sửa lỗi
Phân tích yêu cầu → Triển khai → Debug
Tại sao quá trình Testing không đủ để đảm bảo phần mềm không còn lỗi?
Vì Testing chỉ tập trung vào tính năng chính
Vì không thể kiểm tra hết tất cả tình huống có thể xảy ra
Vì Testing không thể kiểm tra phần mềm đã triển khai
Vì chỉ Debugging mới phát
lỗi?
Vì Testing chỉ tập trung vào tính năng chính
Vì không thể kiểm tra hết tất cả tình huống có thể xảy ra
Vì Testing không thể kiểm tra phần mềm đã triển khai
Vì chỉ Debugging mới phát hiện được lỗi
Phát biểu nào sau đây thể hiện rõ vai trò kết hợp giữa Testing và Debugging?
Testing là quá trình sửa lỗi, Debugging là quá trình phát hiện lỗi
Testing kiểm tra giao diện, Debugging kiểm tra hiệu năng
Testing giúp phát hiện lỗi, Debugging giúp xác định và khắc phục lỗi
Testing và Debugging là hai bước giống nhau trong phát triển phần mềm
Điều nào sau đây không phải là hậu quả có thể xảy ra khi phần mềm hoạt động sai?
Mất tiền bạc
Tăng doanh thu bất ngờ
Mất thời gian
Tổn hại đến danh tiếng doanh nghiệp
Tại sao kiểm thử phần mềm lại đặc biệt quan trọng trong các hệ thống như hàng không, y tế?
Vì phần mềm cần nhiều giao diện đồ họa
Vì chi phí phát triển rất cao
Vì lỗi phần mềm có thể gây thương tích hoặc tử vong
Vì không có mạng internet
Câu nào dưới đây đúng nhất về trải nghiệm người dùng với phần mềm?
Người dùng luôn hài lòng với mọi phần mềm.
Đa số người dùng không bao giờ gặp lỗi phần mềm.
Hầu hết mọi người đều từng gặp phải phần mềm không hoạt động như mong đợi.
Phần mềm hiện đại đã không còn lỗi.
Một lỗi định giá sản phẩm thành 0.01 đô la trên trang thương mại điện tử có thể dẫn đến:
Tăng sự tin tưởng từ khách hàng
Tạo nên trải nghiệm mới mẻ
Gây thiệt hại tài chính và mất uy tín thương hiệu
Không ảnh hưởng gì đến doanh nghiệp
Ý nào sau đây thể hiện mục tiêu cốt lõi của kiểm thử phần mềm?
Tăng lương cho lập trình viên
Kiểm tra cấu hình máy chủ
Giúp phần mềm chạy đúng như mong đợi và đảm bảo an toàn
Giảm thời gian viết tài liệu
Lập trình viên gõ nhầm công thức tính tổng là a - b thay vì a + b. Đây là ví dụ của:
Defect
Failure
Error
Root Cause
Một đoạn mã có lỗi sai logic nhưng chưa bao giờ gây ra sự cố khi chạy chương trình. Đây là:
Error
Defect
Failure
Root Cause
có lỗi sai logic nhưng chưa bao giờ gây ra sự cố khi chạy chương trình. Đây là:
Error
Defect
Failure
Root Cause
Người dùng nhấn nút "Đăng ký" nhưng hệ thống không phản hồi gì. Đây là ví dụ về:
Error
Defect
Root Cause
Failure
Việc thiếu hướng dẫn rõ ràng trong tài liệu yêu cầu dẫn đến lập trình viên hiểu sai. Đây được gọi là:
Failure
Root Cause
Defect
Error
Chọn phát biểu đúng nhất về mối quan hệ giữa các khái niệm:
Error gây ra Root Cause → Root Cause gây Defect
Failure gây Error → Error gây Defect
Error có thể gây ra Defect, Defect có thể gây ra Failure
Root Cause là một dạng Failure khó phát hiện
Lập trình viên đọc nhầm tài liệu đặc tả, nghĩ rằng hệ thống chỉ cần xử lý ngày sinh theo định dạng dd/mm/yyyy, trong khi thực tế cần hỗ trợ cả mm-dd-yyyy. Sau khi triển khai, khách hàng Mỹ không thể nhập đúng ngày. Điều nào sau đây là Error?
Việc hệ thống từ chối định dạng mm-dd-yyyy
Lỗi cú pháp trong mã nguồn
Việc lập trình viên hiểu sai yêu cầu từ tài liệu
Việc người dùng không thể đăng ký tài khoản
Một chức năng tính chiết khấu hiển thị sai số tiền khuyến mãi trên hóa đơn. Tester kiểm tra mã nguồn và phát hiện một đoạn công thức tính toán bị viết sai. Vậy Defect trong trường hợp này là gì?
Việc khách hàng nhìn thấy số tiền sai
Công thức bị viết sai trong mã nguồn
Hành vi tính toán sai trong runtime
Tester không phát hiện lỗi sớm hơn
Một ứng dụng ngân hàng cho phép chuyển tiền nhưng do một lỗi trong backend, số dư tài khoản không được cập nhật đúng sau khi giao dịch. Khách hàng nhìn thấy số dư sai. Đâu là Failure?
Lỗi trong mã xử lý transaction
Việc số dư hiển thị không đúng sau giao dịch
Backend không có kiểm tra logic
Việc lập trình viên quên test tính năng này
Sau khi phân tích kỹ một lỗi nghiêm trọng, nhóm phát hiện nguyên nhân gốc là do thiếu tài liệu mô tả quy trình nghiệp vụ. Điều nào sau đây là Root Cause?
Lỗi hiển thị giá sai trên website
Việc lập trình viên tự suy luận sai cách xử lý
Thiếu tài liệu nghiệp vụ ban đầu
Tester bỏ sót ca kiểm thử.
Điều nào sau đây là Root Cause?
Lỗi hiển thị giá sai trên website
Việc lập trình viên tự suy luận sai cách xử lý
Thiếu tài liệu nghiệp vụ ban đầu
Tester bỏ sót ca kiểm thử.
Chọn chuỗi diễn tiến nguyên nhân → hậu quả đúng trong một kịch bản lỗi phần mềm:
Root Cause → Error → Defect → Failure
Error → Root Cause → Failure → Defect
Defect → Error → Root Cause → Failure
Failure → Error → Defect → Root Cause
Trong mô hình thác nước, kiểm thử phần mềm thường diễn ra ở giai đoạn nào?
Trước khi thiết kế
Trong suốt quá trình phát triển
Gần cuối chu kỳ
Trước giai đoạn yêu cầu
Một trong những nhược điểm chính của mô hình thác nước là gì?
Không cần tài liệu
Không cần kiểm thử
Khó thay đổi và chi phí thay đổi cao
Không có thiết kế hệ thống
Thứ tự các giai đoạn trong mô hình thác nước là gì?
Design → Requirements → Deployment → Testing
Requirements → Design → Development → Testing → Deployment → Maintenance
Testing → Deployment → Design → Development
Requirements → Development → Testing → Maintenance → Design
Kiểm thử trong mô hình thác nước có đặc điểm nào sau đây?
Diễn ra liên tục trong suốt chu kỳ
Diễn ra song song với phát triển
Diễn ra sau khi sản phẩm đã triển khai
Diễn ra gần cuối chu kỳ phát triển
Giai đoạn nào trong mô hình thác nước là giai đoạn cuối cùng?
Testing
Deployment
Maintenance
Design
Mô hình thác nước phù hợp với loại dự án nào?
Dự án có yêu cầu linh hoạt, thay đổi thường xuyên
Dự án chưa xác định rõ mục tiêu
Dự án có yêu cầu rõ ràng và ít thay đổi
Dự án không cần bảo trì
Việc kiểm thử diễn ra muộn trong mô hình thác nước dẫn đến hệ quả gì?
Lỗi được phát hiện sớm và dễ sửa
Phản hồi nhanh từ người dùng
Lỗi được phát hiện muộn và khó khắc phục
Không ảnh hưởng đến quá trình phát triển
Trong mô hình thác nước, khi một giai đoạn hoàn thành thì:
Có thể quay lại giai đoạn trước bất cứ lúc nào
Chuyển sang giai đoạn tiếp theo
Không cần tài liệu bàn giao
Các giai đoạn diễn ra đồng thời
Một hạn chế của mô hình thác nước là gì?
Tốn ít thời gian phát triển
Dễ dàng tiếp nhận yêu cầu thay đổi
Không phù hợp với dự án có yêu cầu thay đổi linh hoạt
Không cần tài liệu thiết kế
Giai đoạn nào chịu trách nhiệm đảm bảo phần mềm hoạt động đúng yêu cầu?
Requirements
Design
Testing
Deployment
Mô hình chữ V nhấn mạnh điều gì trong quá trình phát triển phần mềm?
Kiểm thử chỉ thực hiện sau khi coding
Các hoạt động kiểm thử và phát triển diễn ra song song và liên kết trực tiếp
Thiết kế kiểm thử chỉ diễn ra sau triển khai
Không cần viết tài liệu thiết kế test
Giai đoạn "Business Requirement Specification" tương ứng với hoạt động kiểm thử nào?
Unit Testing
Integration Testing
Acceptance Testing
System Testing
Giai đoạn "Low level design" được kiểm thử bằng loại kiểm thử nào?
Acceptance Testing
Unit Testing
Integration Testing
Regression Testing
Mục tiêu chính của việc thiết kế test sớm trong mô hình chữ V là gì?
Giảm số lượng test case
Tăng độ phức tạp cho tester
Giảm chi phí fix lỗi và phòng ngừa lỗi
Hoãn kiểm thử đến cuối dự án
Giai đoạn nào bên phát triển tương ứng với "System Testing" trong kiểm thử?
Business Requirement Specification
System Requirement Specification
High level Design
Coding
Một trong những lợi ích của thiết kế test sớm là gì?
Phát hiện lỗi khi triển khai xong
Không cần viết test case
Phòng ngừa faults và giảm chi phí sửa lỗi
Tăng thời gian phát triển
"Integration Testing" được thiết kế song song với giai đoạn nào trong phát triển?
Low level design
High level design
System requirement specification
Business requirement specification
Trong mô hình chữ V, kiểm thử chấp nhận (Acceptance Testing) nhằm kiểm tra điều gì?
Kiểm tra đơn vị nhỏ nhất trong chương trình
Kiểm tra từng module riêng biệt
Đảm bảo hệ thống đáp ứng yêu cầu nghiệp vụ
Kiểm tra giao tiếp giữa các module
Tại sao mô hình chữ V thường được coi là cải tiến so với mô hình thác nước?
Cho phép kiểm thử diễn ra sau triển khai
Bỏ qua giai đoạn coding
Kết hợp song song giữa phát triển và kiểm thử ngay từ đầu
Chỉ tập trung vào phát triển phần mềm
Giai đoạn nào sau đây KHÔNG được mô tả trong mô hình chữ V?
Coding
Requirement Analysis
Maintenance
Acceptance Testing
Trong mô hình Agile-Scrum, Sprint thường kéo dài trong khoảng bao lâu?
1 - 2 giờ
1 - 4 ngày
1 - 4 tuần
1 - 4 tháng
Ai là người chịu trách nhiệm quản lý Product Backlog?
Scrum Master
Developer
Tester
Product Owner
Mục tiêu chính của buổi Daily Standup là gì?
Họp báo cáo lỗi cuối Sprint
Đánh giá hiệu suất làm việc
Thảo luận ngắn về tiến độ, vướng mắc và kế hoạch hôm nay
Kiểm tra kỹ thuật code
Khi nào kiểm thử được thực hiện trong Sprint?
Sau khi lập trình xong toàn bộ tính năng
Sau khi review code
Diễn ra song song với lập trình
Chỉ khi kết thúc Sprint
Buổi họp nào giúp nhóm nhìn lại cả Sprint để rút kinh nghiệm?
Sprint Review
Sprint Retrospective
Daily Standup
Backlog Grooming
Sprint Review dùng để làm gì?
Trình bày và nhận phản hồi từ PO và khách hàng
Viết test case
Dọn backlog
Phân chia task coding
Agile-Scrum KHÔNG coi trọng yếu tố nào dưới đây?
Giao tiếp nhóm
Tài liệu sản phẩm chi tiết
Phản hồi từ khách hàng
Làm việc liên tục
Điều nào sau đây KHÔNG đúng về vai trò của Tester trong Agile-Scrum?
Tester chỉ kiểm thử khi Dev hoàn tất
Tester tham gia ngay từ đầu Sprint
Tester báo cáo lỗi mỗi ngày tại Daily Standup
Tester tham gia demo tính năng
Việc sử dụng kiểm thử tự động trong Agile giúp gì?
Chỉ test UI
Giảm khả năng phát hiện lỗi
Rút ngắn thời gian kiểm thử và lặp lại dễ dàng
Không cần thiết vì đã có test thủ công
Sự tăng trưởng của sản phẩm trong mỗi vòng lặp (Sprint) thường biểu hiện qua:
Sự tăng trưởng của sản phẩm trong mỗi vòng lặp (Sprint) thường biểu hiện qua:
Thêm nhiều tài liệu kỹ thuật
Tăng số người trong nhóm
Thêm hoặc cải tiến tính năng nhỏ
Thêm thời gian phát triển
Mức độ kiểm thử là gì?
Là các bước viết test case
Là nhóm các hoạt động kiểm thử được tổ chức và quản lý cùng nhau
Là loại lỗi thường gặp khi test
Là thời gian kiểm thử trong dự án
Mức độ kiểm thử có mối liên hệ với yếu tố nào trong quy trình phát triển phần mềm?
Chi phí nhân sự
Kế hoạch marketing
Các giai đoạn tương ứng trong chu kỳ phát triển phần mềm
Giao tiếp trong nhóm
Mức độ kiểm thử nào được thực hiện đầu tiên trong chu kỳ phát triển?
System Testing
Acceptance Testing
Unit Testing
Integration Testing
Mức độ kiểm thử nào nhằm đảm bảo các thành phần nhỏ nhất hoạt động đúng?
Integration Testing
Acceptance Testing
System Testing
Unit Testing
Mức độ kiểm thử nào tập trung vào việc kiểm tra sự kết nối giữa các module?
System Testing
Unit Testing
Integration Testing
Acceptance Testing
Mục tiêu chính của System Testing là gì?
Kiểm tra logic đơn vị
Kiểm tra các chức năng của toàn bộ hệ thống
Kiểm tra giao diện
Kiểm tra hiệu suất
Mức độ kiểm thử nào thường do người dùng hoặc khách hàng thực hiện?
Unit Testing
Integration Testing
System Testing
Acceptance Testing
Mức độ kiểm thử nào có thể bao gồm kiểm tra yêu cầu nghiệp vụ?
Unit Testing
Acceptance Testing
Integration Testing
Regression Testing
Mối quan hệ giữa các mức độ kiểm thử thường thể hiện qua:
Dòng thời gian phát triển sản phẩm
Mô hình hình chóp từ thấp đến cao: Unit → Integration → System → Acceptance
Lập kế hoạch ngân sách
Số lượng tester tham gia
Việc tổ chức kiểm thử theo từng mức độ giúp:
Tăng thời gian kiểm thử
Tối ưu chi phí kiểm thử
Quản lý hiệu quả và đảm bảo chất lượng ở từng cấp
Giảm khối lượng công việc cho tester
Mục tiêu chính của kiểm thử đơn vị là gì?
Kiểm tra giao diện người dùng
Kiểm tra từng thành phần nhỏ, độc lập trong phần mềm
Kiểm tra tính năng hoàn chỉnh
Kiểm tra hiệu suất toàn hệ thống
Ai thường là người thực hiện kiểm thử đơn vị?
Tester
Product Owner
Lập trình viên
Người dùng cuối
Kiểm thử đơn vị thường được thực hiện ở đâu?
Trên môi trường staging
Trên máy khách
Trên môi trường sản xuất (production)
Trên môi trường phát triển (developer environment)
Kiểm thử đơn vị cần sự hỗ trợ của gì để thực hiện hiệu quả?
Tài liệu hướng dẫn sử dụng phần mềm
Framework kiểm thử đơn vị
Máy chủ thật
Báo cáo từ khách hàng
Một đặc điểm của kiểm thử đơn vị là:
Kiểm thử toàn bộ hệ thống cùng lúc
Không cần lập trình viên tham gia
Có thể kiểm thử từng hàm hoặc module riêng biệt
Chỉ thực hiện sau khi code hoàn thành
Unit Test thường có thể phát hiện lỗi gì?
Lỗi tích hợp giữa các hệ thống
Lỗi logic trong từng hàm, từng module nhỏ
Lỗi do thay đổi yêu cầu nghiệp vụ
Lỗi mạng hoặc thiết bị
Kiểm thử đơn vị còn có tên gọi khác là gì?
Regression Testing
Component Testing
System Testing
Integration Testing
Kiểm thử đơn vị thường diễn ra khi nào?
Sau khi kiểm thử chấp nhận
Sau khi client test
Ngay khi lập trình viên hoàn thành một chức năng nhỏ
Sau khi deploy bản chính thức
Lợi ích của kiểm thử đơn vị là gì?
Kiểm tra toàn bộ luồng nghiệp vụ
Tăng hiệu suất hệ thống
Giúp phát hiện lỗi sớm, tiết kiệm chi phí sửa lỗi
Giảm khối lượng công việc của QA
Unit test thường được viết bằng gì?
Ngôn ngữ tự nhiên
Công cụ quản lý dự án
Ngôn ngữ lập trình và framework hỗ trợ test
Excel
Kiểm thử tích hợp (Integration Testing) có mục tiêu chính là gì?
Kiểm tra hiệu suất hệ thống
Kiểm tra đơn vị mã nguồn nhỏ nhất
Kiểm tra sự kết hợp giữa các module hoặc hệ thống
Kiểm tra chấp nhận người dùng
Có bao nhiêu nhánh chính trong kiểm thử tích hợp?
1
2
3
Component Integration Testing là gì?
Kiểm thử chấp nhận yêu cầu khách hàng
Kiểm thử giữa hệ thống phần mềm và hệ thống bên ngoài
Kiểm thử tích hợp giữa các module nội bộ trong hệ thống
Kiểm thử đơn vị độc lập
System Integration Testing là gì?
Kiểm tra từng hàm nhỏ riêng biệt
Kiểm thử logic nghiệp vụ
Kiểm thử tích hợp hệ thống với các hệ thống bên ngoài (API, payment,...)
Kiểm thử chấp nhận sản phẩm
Một ví dụ điển hình của System Integration Testing là gì?
Kiểm tra kết nối giữa hàm A và B trong cùng module
Gọi API của cổng thanh toán để kiểm tra phản hồi
Kiểm thử bằng cách đọc tài liệu
Viết lại mã nguồn chương trình
Component Integration Testing thường được áp dụng khi:
Giao tiếp với hệ thống bên ngoài
Kiểm thử chấp nhận sản phẩm
Tích hợp các module nhỏ để kiểm tra tương tác bên trong
Đo hiệu suất hoạt động
Mục đích của Integration Testing là gì?
Kiểm tra từng component hoạt động độc lập
Đảm bảo các thành phần khi kết hợp với nhau vẫn hoạt động đúng
Loại bỏ hoàn toàn kiểm thử thủ công
Viết lại toàn bộ mã để tránh bug
Integration Testing thường diễn ra sau mức kiểm thử nào?
System Testing
Unit Testing
Acceptance Testing
Regression Testing
Đâu là công cụ phổ biến hỗ trợ Integration Testing cho API?
JUnit
Selenium
Postman
Figma
Lỗi phổ biến dễ phát hiện trong Integration Testing là:
Sai chính tả trong UI
Lỗi logic trong hàm riêng lẻ
Lỗi truyền dữ liệu giữa các module hoặc hệ thống
Lỗi của người dùng cuối
Điểm khác biệt giữa kiểm thử đơn vị và kiểm thử tích hợp là:
Kiểm thử đơn vị do tester thực hiện, kiểm thử tích hợp do dev thực hiện
Kiểm thử đơn vị tập trung vào từng chức năng nhỏ, kiểm thử tích hợp kiểm tra sự tương tác giữa các phần
Cả hai đều dùng cho việc kiểm tra UI
Kiểm thử đơn vị diễn ra sau kiểm thử tích hợp
Khi nào nên bắt đầu thực hiện kiểm thử tích hợp?
Khi toàn bộ hệ thống đã hoàn thiện
Ngay sau khi các đơn vị (unit) riêng biệt được kiểm thử xong
Sau khi kiểm thử chấp nhận
Khi khách hàng đã xác nhận yêu cầu
Điều nào sau đây là mục tiêu của kiểm thử tích hợp?
Đánh giá trải nghiệm người dùng
Đảm bảo các module kết nối và giao tiếp chính xác với nhau
Đảm bảo UI thân thiện
Đảm bảo yêu cầu nghiệp vụ được viết đúng
Một tester phát hiện lỗi khi hệ thống không truyền đúng dữ liệu từ module đăng nhập sang module giỏ hàng. Đây là lỗi thuộc mức kiểm thử nào?
Unit Testing
System Testing
Integration Testing
Acceptance Testing
System Integration Testing thường liên quan đến các yếu tố nào?
Kiểm tra logic tính toán nội bộ
Giao tiếp với hệ thống bên ngoài như API, cổng thanh toán
Giao diện người dùng
Viết unit test
Công cụ nào KHÔNG phù hợp với kiểm thử tích hợp hệ thống?
Postman
SOAP UI
JUnit
REST Assured
Component Integration Testing KHÔNG phù hợp để kiểm tra:
Giao tiếp giữa các module logic
Kết nối giữa hệ thống và ví điện tử Momo
Tương tác giữa chức năng đăng nhập và phân quyền
Gửi dữ liệu từ module giỏ hàng sang thanh toán
Một trong những rủi ro khi bỏ qua kiểm thử tích hợp là gì?
Giao diện không bắt mắt
Lỗi logic đơn giản
Hệ thống hoạt động riêng lẻ đúng nhưng không phối hợp được khi tích hợp
Tốn thời gian viết tài liệu
Mục đích của việc phân chia Integration Testing thành Component và System là:
Dễ phân công công việc cho lập trình viên
Chia nhỏ công đoạn để dễ làm
Tăng khả năng quản lý và kiểm soát phạm vi kiểm thử
Giảm số lượng test case cần viết
Trong thực tế, tester thực hiện System Integration Test thường cần kiến thức gì?
Viết UI
Thiết kế CSDL
Hiểu biết về hệ thống bên ngoài, cấu trúc API và kỹ năng debug log
Vẽ sơ đồ kiến trúc phần mềm
Integration Testing tập trung kiểm tra điều gì?
Giao diện người dùng
Logic nghi
Integration Testing tập trung kiểm tra điều gì?
Giao diện người dùng
Logic nghiệp vụ độc lập
Tương tác và luồng dữ liệu giữa các module/hệ thống
Tính bảo mật hệ thống
Integration Testing có thể được thực hiện bằng phương pháp nào sau đây?
Top-down, Bottom-up, Big bang
Waterfall, Agile, V-model
Manual, Automation, Static
UI Test, Smoke Test, A/B Test
Trong phương pháp Top-down Integration Testing, bạn sẽ kiểm thử theo thứ tự nào?
Từ các module chi tiết lên module chính
Từ giao diện chính xuống các module con
Kiểm thử toàn bộ cùng lúc
Bắt đầu từ unit test
Một rủi ro phổ biến khi không thực hiện Integration Testing đầy đủ là gì?
Không phát hiện lỗi UI
Không tương thích giữa các module hoặc hệ thống
Lỗi chính tả trong tài liệu
Giao diện người dùng thiếu màu sắc
Kiểm thử tích hợp thường cần sự hỗ trợ của gì?
Mock object, stub hoặc service giả lập
Giao diện thiết kế Figma
Môi trường production thật
Phần mềm chỉnh ảnh
Khi bạn kiểm tra hệ thống kết nối với ví điện tử (ZaloPay, MoMo…), bạn đang thực hiện loại kiểm thử nào?
Unit Testing
Component Integration Testing
System Integration Testing
Acceptance Testing
Một trong những khó khăn chính của System Integration Testing là:
Không cần nhiều dữ liệu
Dễ kiểm soát vì test trong môi trường offline
Phụ thuộc hệ thống bên ngoài nên khó mô phỏng lỗi
Không cần kế hoạch test rõ ràng
Integration Testing KHÔNG phù hợp để kiểm tra:
API giữa các hệ thống
Module giao tiếp với CSDL
Giao diện web tĩnh
Sự tương tác giữa các microservice
Điều gì xảy ra nếu không thực hiện Integration Testing mà chỉ kiểm thử riêng từng module?
Hệ thống chạy nhanh hơn
Lỗi giữa các module khó bị phát hiện sớm
Không cần viết test script
Dễ dàng deploy hơn
