WorksheetsKiểm Thử Phần Mềm
Total questions: 91
Worksheet time: 48mins
Mục tiêu chính của kiểm thử phần mềm là gì?
Đảm bảo phần mềm chạy nhanh
Phát hiện lỗi, đảm bảo phần mềm đáp ứng yêu cầu
Thiết kế phần mềm đẹp
Đảm bảo phần mềm miễn phí
Kiểm thử (Testing) khác gì với Gỡ lỗi (Debugging)?
Testing là phát hiện lỗi, Debugging là xác định và sửa lỗi
Cả hai đều giống nhau
Debugging là kiểm tra test case
Testing là sửa lỗi, Debugging là thực thi phần mềm
Vì sao kiểm thử phần mềm không thể tìm ra hết mọi lỗi?
Tester thiếu kinh nghiệm
Số lượng test case là vô hạn, giới hạn tài nguyên
Phần mềm đơn giản
Không cần kiểm thử
Nguyên nhân phổ biến gây lỗi phần mềm KHÔNG BAO GỒM:
Sai sót trong thiết kế
Lỗi lập trình
Tài liệu yêu cầu rõ ràng
Giao tiếp không hiệu quả
Đâu KHÔNG phải nguyên tắc kiểm thử phần mềm?
Kiểm thử toàn diện là không thể
Tester nên tự viết code sản phẩm
Kiểm thử nên thực hiện càng sớm càng tốt
Tập trung vào khu vực rủi ro
Lý do nên kiểm thử sớm là gì?
Để tăng chi phí sửa lỗi
Để phát hiện lỗi ở giai đoạn đầu, tiết kiệm chi phí
Để tăng số lượng lỗi
Để có nhiều người tham gia kiểm thử
Vai trò của Tester trong phát triển phần mềm là:
Chỉ tìm lỗi
Đánh giá, xác thực phần mềm, báo lỗi, góp ý quy trình
Viết code
Thiết kế giao diện
Nếu phát hiện lỗi nhưng không tái hiện lại được, bạn nên:
Bỏ qua
Ghi nhận chi tiết, báo cáo lỗi, thử lại nhiều môi trường
Xoá phần mềm
Không báo lỗi
Khi nào nên kiểm thử tự động?
Khi kiểm thử giao diện
Khi kiểm thử hồi quy, lặp lại nhiều lần
Khi mới có sản phẩm
Khi không cần kiểm thử
Làm sao để kiểm thử phần mềm hiệu quả?
Không cần kế hoạch kiểm thử
Kết hợp tự động & thủ công, môi trường phù hợp, kiểm thử liên tục
Không cần đào tạo tester
Bỏ qua kiểm thử hồi quy
Các giai đoạn chính trong SDLC là:
Phân tích yêu cầu - Thiết kế - Lập trình - Kiểm thử - Triển khai - Bảo trì
Lập trình -
Các giai đoạn chính trong SDLC là:
Phân tích yêu cầu - Thiết kế - Lập trình - Kiểm thử - Triển khai - Bảo trì
Lập trình - Báo cáo - Xây dựng
Thiết kế - Đóng gói - Bán hàng
Chỉ lập trình
Ưu điểm của mô hình Waterfall là:
Linh hoạt thay đổi liên tục
Quy trình rõ ràng, dễ quản lý
Khó theo dõi tiến độ
Không có ưu điểm
Điểm khác biệt nổi bật của Agile so với truyền thống là:
Có thể thay đổi yêu cầu trong quá trình phát triển
Không cần kiểm thử
Waterfall linh hoạt hơn
Agile không làm việc nhóm
Tại sao kiểm thử phần mềm xuất hiện ở nhiều giai đoạn SDLC?
Chỉ kiểm thử 1 lần
Đảm bảo phát hiện lỗi sớm, giảm chi phí
Để kiểm tra tài liệu
Tăng chi phí phát triển
Mô hình phù hợp nhất cho dự án yêu cầu thay đổi thường xuyên là:
Waterfall
V-model
Agile
Big Bang
Để tester hiệu quả trong Agile cần:
Tham gia từ đầu, phối hợp, tự động hóa test case, review
Chỉ viết test case sau khi có sản phẩm
Chỉ báo cáo lỗi
Không cần test case
Chiến lược kiểm thử dự án thương mại điện tử nên gồm:
Chỉ kiểm thử giao diện
Lập kế hoạch, kết hợp kiểm thử thủ công & tự động, kiểm thử liên tục
Không cần môi trường kiểm thử
Chỉ kiểm thử bảo mật
Quy trình kiểm thử phần mềm KHÔNG BAO GỒM bước nào?
Lập kế hoạch kiểm thử
Thiết kế test case
Thiết lập môi trường kiểm thử
Mua phần mềm
Ai chịu trách nhiệm lập Test Plan?
Developer
Test Manager/QA Manager
User
Product Owner
Tài liệu nào ghi tiêu chí dừng kiểm thử?
Test Plan/Test Strategy
User Manual
Source Code
Requirements Document
Trong nhóm kiểm thử, vai trò của Test Lead là:
Viết code
Điều phối đội kiểm thử, giám sát tiến độ
Chỉ báo lỗi
Thiết kế cơ sở dữ liệu
Nếu có thay đổi yêu cầu khi đã lên kế hoạch kiểm thử, bạn làm gì?
Bỏ qua
Đánh giá tác động, cập nhật tài liệu test, thông báo các bên liên quan
Không cần cập nhật
Chỉ cập nhật khi test case lỗi
hoạch kiểm thử, bạn làm gì?
Bỏ qua
Đánh giá tác động, cập nhật tài liệu test, thông báo các bên liên quan
Không cần cập nhật
Chỉ cập nhật khi test case lỗi
Chỉ số đo lường hiệu quả kiểm thử KHÔNG BAO GỒM:
Tỷ lệ bao phủ test case
Số lỗi phát hiện
Số lượng tester
Thời gian xử lý lỗi
Các mức kiểm thử phần mềm gồm:
Unit, Integration, System, UAT
UAT, GUI Testing, Load Testing
Integration, Coding, Debugging
None of above
Unit Testing chủ yếu do ai thực hiện?
User
Developer
Test Lead
Khách hàng
So sánh Alpha và Beta Testing, đâu là điểm đúng?
Alpha do user thực hiện
Beta do tester nội bộ
Beta do người dùng thực tế kiểm thử ngoài nội bộ
Alpha kiểm thử môi trường ngoài công ty
Trong kiểm thử tích hợp, Stubs dùng khi nào?
Khi thiếu module phía dưới
Khi thiếu module phía trên
Khi thiếu toàn bộ hệ thống
Khi test GUI
Kỹ thuật kiểm thử tích hợp Big Bang là:
Tích hợp từng module một
Tích hợp đồng loạt tất cả các module rồi kiểm thử toàn hệ thống
Chỉ test đơn lẻ
Không kiểm thử
Kiểm thử chức năng (Functional Testing) khác gì kiểm thử phi chức năng (Non-functional Testing)?
Kiểm tra chức năng vs kiểm tra hiệu suất, bảo mật
Đều giống nhau
Chỉ kiểm tra giao diện
Non-functional chỉ kiểm tra code
Kiểm thử hiệu năng (Performance Testing) gồm kỹ thuật nào?
Load, Stress, Spike, Volume, Soak Testing
Decision Table Testing
UAT
GUI Testing
Khi nào cần kiểm thử lại (Re-testing)?
Khi phát hiện lỗi mới
Sau khi đã sửa lỗi
Khi thay đổi tester
Khi hết deadline
Ví dụ nào là kiểm thử bảo mật?
Nhập chuỗi độc hại vào form để kiểm tra chống SQL Injection
Test giao diện đẹp
Test load 100 user
Kiểm tra hiệu suất
Kiểm thử hộp trắng là:
Kiểm thử dựa vào mã nguồn, luồng điều khiển bên trong
Chỉ kiểm thử giao diện
Không cần biết code
Kiểm thử qua user
Statement Coverage là gì?
Statement Coverage là gì?
Đo lường % số câu lệnh được thực thi qua test case
Đo hiệu suất phần mềm
Đo số tester
Đo lỗi logic
Branch Coverage là:
Đảm bảo kiểm thử đủ các nhánh điều kiện
Đo lường tài liệu
Kiểm thử GUI
Kiểm thử trải nghiệm
Cyclomatic Complexity dùng để:
Đo độ phức tạp code, xác định số test case tối thiểu
Đo tài liệu
Đo số bug
Đo hiệu suất
Kiểm thử hộp đen là gì?
Kiểm thử dựa yêu cầu và chức năng, không cần biết cấu trúc bên trong
Tester phải biết lập trình
Chỉ kiểm thử giao diện
Chỉ kiểm tra tài liệu
Phân vùng tương đương (Equivalence Partitioning) là:
Phân chia đầu vào thành nhóm tương đương để kiểm thử đại diện
Đo hiệu năng
Test GUI
Đo số tester
Phân tích giá trị biên (Boundary Value Analysis) kiểm thử:
Giá trị ở ranh giới, gần ranh giới, ngoài ranh giới đầu vào
Chỉ kiểm tra giá trị trung bình
Đo hiệu suất
Không kiểm thử ranh giới
Kỹ thuật bảng quyết định (Decision Table) dùng khi nào?
Khi có nhiều tổ hợp điều kiện và kết quả
Chỉ có 1 điều kiện
Test GUI
Test performance
State Transition Testing kiểm thử:
Các trạng thái hệ thống và chuyển đổi giữa các trạng thái
Đo lỗi bảo mật
Đo hiệu suất
Chỉ kiểm thử giao diện
Test case là gì?
Tập hợp điều kiện tiên quyết, bước thực hiện, kết quả mong đợi để kiểm thử một chức năng
Đo hiệu suất
Kịch bản kiểm thử tự động
Tài liệu quản lý lỗi
Yếu tố nào KHÔNG quyết định chất lượng test case?
Đầy đủ
Rõ ràng
Tốn thời gian
Độc lập
Nguyên tắc viết test case tối ưu là:
Mỗi test case kiểm tra một chức năng riêng biệt, rõ ràng, dễ bảo trì
Viết càng dài càng tốt
Test case phụ thuộc lẫn nhau
Không cần ghi kết quả mong đợi
Test design kiểm thử chức năng đăng nhập nên kiểm tra gì?
Tính hợp lệ username/password, cơ chế khóa tài khoản, thông báo lỗi
Giao diện đẹp
Test design kiểm thử chức năng đăng nhập nên kiểm tra gì?
Tính hợp lệ username/password, cơ chế khóa tài khoản, thông báo lỗi
Giao diện đẹp
Độ bảo mật mạng
Tài liệu hướng dẫn sử dụng
Lỗi phần mềm là gì?
Sự sai lệch giữa kết quả thực tế và mong đợi
Là phần mềm tốt
Đo hiệu suất
Đo code đẹp
Vòng đời lỗi phần mềm gồm trạng thái nào?
New - Assigned - Fixed - Retest - Closed
Tạo mới - Viết code - Xoá
Đánh giá tài liệu
Không có trạng thái
Phân biệt Severity và Priority của lỗi:
Severity là mức độ nghiêm trọng, Priority là mức ưu tiên sửa lỗi
Đều là một
Chỉ dành cho tester
Đo hiệu suất
Thành phần báo cáo lỗi KHÔNG BAO GỒM:
Tiêu đề lỗi
Ảnh chụp màn hình (nếu cần)
Đánh giá marketing
Mô tả lỗi
Test Report cần tạo khi nào?
Sau mỗi chu kỳ kiểm thử quan trọng hoặc trước khi đưa sản phẩm vào triển khai
Sau khi test xong 1 ngày
Khi không còn lỗi
Khi muốn báo cáo
Một công ty phát hiện tỷ lệ bug lặp lại sau khi "fix" vẫn cao. Đâu là giải pháp kiểm thử phù hợp?
Chỉ kiểm thử tính năng mới
Tăng kiểm thử hồi quy và cải thiện quy trình xác nhận lỗi đã fix
Dừng kiểm thử thủ công
Không cần kiểm thử nữa
Khi nhận được phản hồi người dùng về lỗi khó tái hiện trên môi trường sản xuất, bạn nên ưu tiên điều gì?
Gửi lỗi cho nhóm dev mà không điều tra
Thu thập log, chi tiết bước tái hiện, điều kiện môi trường và trao đổi với dev
Tự sửa lỗi
Đợi lần sau test lại
Một tester khi test một hệ thống ngân hàng phát hiện giao dịch chuyển khoản thành công nhưng số dư không bị trừ. Đây là loại lỗi gì?
Lỗi giao diện
Lỗi nghiệp vụ (logic)
Lỗi hiệu suất
Lỗi bảo mật
Khi thực hiện kiểm thử hiệu năng một trang web bán hàng vào dịp Tết, chỉ số nào sau đây nên ưu tiên theo dõi?
Số lượng bug đã fix
Thời gian phản hồi, tỉ lệ request thành công, CPU, RAM, bandwidth
Số lượng tester tham gia
Tên người mua hàng
Khi kiểm thử đăng nhập hệ thống, trường hợp nào sau đây nên kiểm thử để tăng tính an toàn bảo mật?
Nhập đúng username, password
Nhập script độc hại vào trường username/password để kiểm tra tấn công SQL Injection
Đăng nhập từ 1 thiết bị duy nhất
Đăng nhập lúc nửa đêm
Nếu trong một sprint Agile, team dev liên tục thay đổi yêu cầu, tester cần làm gì để đảm bảo test case luôn đúng?
Không cập nhật test case
Cập nhật test case ngay khi có thay đổi, phối hợp chặt chẽ với dev và PO
Đợi đến cuối sprint mới cập nhật
Không cần test case
Một khách hàng phàn nàn tốc độ tải trang web quá chậm vào giờ cao điểm. Bạn nên đề xuất kiểm thử nào?
Kiểm thử thủ công tính năng đăng nhập
Load testing và Stress testing vào các khung giờ cao điểm
Chỉ kiểm thử bảo mật
Test tính năng trên máy dev
Khi test chức năng chuyển tiền trên app banking, trường hợp nào là kiểm thử giá trị biên?
Chuyển số tiền tối thiểu được phép, chuyển số tiền tối đa được phép
Chuyển số tiền trung bình
Chuyển số tiền ngẫu nhiên
Chuyển cho người nhận bất kỳ
Đối với một hệ thống cần đảm bảo tính toàn vẹn dữ liệu khi mất điện đột ngột, loại kiểm thử nào là phù hợp?
Recovery Testing
Usability Testing
A/B Testing
GUI Testing
Một dự án yêu cầu bảo mật cao, khi test chức năng đổi mật khẩu, trường hợp nào sau đây cần kiểm thử thêm?
Cho phép mật khẩu đơn giản
Không kiểm tra session
Kiểm thử timeout, kiểm tra gửi OTP, kiểm tra thay đổi ở nhiều session cùng lúc
Chỉ kiểm tra trường hợp đúng
Bạn là tester chính cho ứng dụng quản lý nhà hàng. Khi test chức năng đặt bàn, test case nào sau đây là hợp lý nhất cho "test case âm"?
Đặt bàn cho thời gian đã qua
Đặt bàn giờ cao điểm
Đặt bàn đúng giờ
Đặt bàn cho khách VIP
Trong quy trình báo lỗi, thông tin nào sau đây KHÔNG cần thiết phải có?
Bước tái hiện lỗi
Thông tin môi trường kiểm thử
Tên bạn gái tester
Ảnh màn hình lỗi (nếu có)
Trong quy trình báo lỗi, thông tin nào sau đây KHÔNG cần thiết phải có?
Bước tái hiện lỗi
Thông tin môi trường kiểm thử
Tên bạn gái tester
Ảnh màn hình lỗi (nếu có)
Hệ thống e-commerce phát sinh lỗi khi cùng lúc nhiều người cùng đặt hàng một sản phẩm còn 1 chiếc, cách kiểm thử nào hợp lý nhất?
Kiểm thử cạnh tranh (Concurrency Testing)
Usability Testing
A/B Testing
Documentation Testing
Khi phát triển một app giao đồ ăn, câu nào sau đây là functional test?
Đặt món thành công khi đủ tiền
Ứng dụng tải trang dưới 2 giây
Độ ổn định server khi có 5000 user
Tỷ lệ click vào banner quảng cáo
Trong thực tế, khi test ứng dụng có quy trình nhiều bước liên tục (checkout, nhập thông tin, xác nhận, thanh toán), kiểm thử nào nên ưu tiên tự động hóa?
Các bước lặp đi lặp lại, hồi quy, quy trình checkout chuẩn
Chỉ kiểm thử giao diện
Kiểm thử A/B
Kiểm thử bảo mật
Cho đoạn mã sau: if (a > 0): print("A") print("B") Số test case tối thiểu cần để đảm bảo statement coverage là:
1
2
3
4
Cho đoạn mã: if (x > 10): print("A") else: print("B") Để đảm bảo branch coverage, cần tối thiểu bao nhiêu test case?
1
2
3
4
Cho đoạn code: if (y % 2 == 0): print("Even") print("End") Để đảm bảo statement coverage, cần tối thiểu bao nhiêu test case?
1
2
3
0
Cho đoạn code: if (a > 5 and b > 5): print("Big") Để đảm bảo condition coverage, cần tối thiểu bao nhiêu test case?
2
3
4
1
Cho code: if (a > 0): print("Positive") else: print("Non-positive") print("Done") Số test case tối thiểu để đảm bảo branch coverage là:
1
2
3
4
Cho hàm: def check(n): if n > 0: print("A") if n % 2 == 0: print("B") Số test case tối thiểu để đảm bảo statement coverage?
1
2
3
4
Cho đoạn code: if (a > 0 or b > 0): print("OK") Để đảm bảo condition coverage, cần tối thiểu bao nhiêu test case?
2
3
4
1
Đoạn code: if x > 5: if y > 5: print("A") else: print("B") else: print("C") Cyclomatic Complexity của đoạn code trên là:
2
3
4
5
Cyclomatic Complexity của đoạn code trên là:
2
3
4
5
Số test case tối thiểu để đảm bảo decision coverage là:
2
3
1
4
Số test case tối thiểu để đảm bảo condition coverage là:
2
3
4
1
Để bao phủ nhánh (branch coverage), cần tối thiểu bao nhiêu test case?
1
2
3
4
Test case nào dưới đây đảm bảo bao phủ đầy đủ câu lệnh (statement coverage)?
n = 4
n = 5
n = 4 và n = 5
Không cần test
Số đường đi độc lập (Cyclomatic Complexity) của hàm trên là:
2
3
4
5
Để đảm bảo bao phủ điều kiện (condition coverage), tổ hợp giá trị (a, b) nào sau đây là KHÔNG ĐỦ?
(1, 1), (0, 1), (1, 0), (0, 0)
(1, 1), (0, 0)
(1, 0), (0, 1), (0, 0)
(1, 1), (1, 0), (0, 1)
Đâu là bộ test case theo Boundary Value Analysis?
age = 17, 18, 60, 61
age = 18, 60
age = 17, 61
age = 20, 40, 59
Số test case tối thiểu đảm bảo statement coverage là:
1
2
3
4
Để bao phủ tất cả các nhánh, bộ test case phù hợp là:
a=1, b=2 và a=3, b=3
a=2, b=1 và a=3, b=3
a=2, b=1; a=3, b=3; a=1, b=2
a=2, b=2
Bộ giá trị biên theo kỹ thuật kiểm thử biên là:
9_999_999; 10_000_000; 500_000_000; 500_000_001
10_000_000; 20_000_000; 300_000_000
9_000_000; 100_000_000
10_000_000; 500_000_000
Số test case tối thiểu cần để bao phủ đầy đủ các nhánh là:
2
3
4
5
Số test case tối thiểu để đảm bảo condition coverage?
1
2
3
4
