Đề 12 – Bài tập, đề thi trắc nghiệm online Kiểm thử phần mềm

Mục tiêu chính của quản lý cấu hình kiểm thử là đảm bảo tính nhất quán và khả năng tái tạo của môi trường kiểm thử. Điều này bao gồm việc quản lý các phiên bản phần mềm, môi trường phần cứng, dữ liệu kiểm thử, công cụ kiểm thử, và các tài liệu liên quan. Tính nhất quán và khả năng tái tạo là rất quan trọng để đảm bảo kết quả kiểm thử đáng tin cậy và có thể so sánh được qua thời gian. Các lựa chọn khác là các mục tiêu phụ hoặc không liên quan trực tiếp.

Kiểm thử chấp nhận (Acceptance testing), đặc biệt là Kiểm thử chấp nhận của người dùng (UAT), thường được thực hiện bởi người dùng cuối hoặc khách hàng để xác minh rằng phần mềm đáp ứng nhu cầu và mong đợi của họ trong môi trường thực tế. Mục đích là để khách hàng chấp nhận sản phẩm trước khi phát hành chính thức.

Độ bao phủ mã (Code coverage) là một chỉ số đo lường phần trăm dòng mã nguồn đã được thực thi bởi bộ kiểm thử. Nó giúp đánh giá mức độ kiểm thử của mã và xác định các khu vực có thể chưa được kiểm thử đầy đủ. Các loại độ bao phủ khác tập trung vào chức năng, quyết định hoặc yêu cầu.

Kiểm thử phi chức năng (Non-functional testing) tập trung vào các khía cạnh của phần mềm không liên quan trực tiếp đến chức năng, mà là các thuộc tính như hiệu suất, bảo mật, khả năng sử dụng, độ tin cậy, v.v. Kiểm thử chức năng xác minh các chức năng hoạt động đúng như mong đợi.

Giai đoạn đầu tiên trong Quy trình kiểm thử phần mềm (STLC) thường là Phân tích yêu cầu (Requirements Analysis). Trong giai đoạn này, nhóm kiểm thử hiểu rõ các yêu cầu của phần mềm để từ đó xây dựng kế hoạch và kịch bản kiểm thử phù hợp. Lập kế hoạch kiểm thử thường diễn ra sau khi đã hiểu rõ yêu cầu.

Kiểm thử hồi quy (Regression testing) được thực hiện sau khi có bất kỳ thay đổi nào trong phần mềm, như sửa lỗi hoặc thêm chức năng mới, để đảm bảo rằng những thay đổi này không gây ra lỗi mới hoặc làm hỏng các chức năng hiện có. Nó giúp đảm bảo tính ổn định của phần mềm sau các thay đổi.

Sự khác biệt chính giữa Verification và Validation là: Verification (Xác minh) tập trung vào việc kiểm tra `chúng ta có xây dựng sản phẩm đúng cách không?`, tức là quá trình xây dựng có tuân thủ đặc tả và thiết kế không. Validation (Thẩm định) tập trung vào việc kiểm tra `chúng ta có xây dựng đúng sản phẩm không?`, tức là sản phẩm có đáp ứng nhu cầu và mong đợi của người dùng hay không. Lựa chọn 2 và 3 mô tả đúng một phần nhưng không phải là sự khác biệt chính, lựa chọn 4 sai vì đây là hai khái niệm khác nhau.

Lợi ích chính của tự động hóa kiểm thử là giảm thời gian và chi phí kiểm thử, đồng thời tăng độ chính xác và nhất quán trong quá trình kiểm thử, đặc biệt là cho các kiểm thử hồi quy lặp đi lặp lại. Tuy nhiên, tự động hóa không thể loại bỏ hoàn toàn kiểm thử thủ công, không đảm bảo 100% độ bao phủ mã, và không thay thế vai trò của người kiểm thử mà hỗ trợ họ hiệu quả hơn.

Trong phương pháp Agile, kiểm thử được thực hiện liên tục và lặp đi lặp lại trong suốt mỗi Sprint. Kiểm thử Agile nhấn mạnh việc kiểm thử sớm và thường xuyên, tích hợp kiểm thử vào quy trình phát triển để đảm bảo chất lượng phần mềm được duy trì trong suốt quá trình phát triển. Không chỉ nhóm kiểm thử mà cả các thành viên khác trong nhóm Agile cũng tham gia vào hoạt động kiểm thử.

Thông tin QUAN TRỌNG NHẤT trong báo cáo lỗi (Bug report) để giúp nhà phát triển sửa lỗi là `Các bước tái hiện lỗi′ (Steps to reproduce). Nếu nhà phát triển không thể tái hiện lỗi, họ sẽ rất khó khăn trong việc xác định nguyên nhân và sửa chữa. Các thông tin khác như mức độ nghiêm trọng, môi trường kiểm thử cũng quan trọng, nhưng các bước tái hiện lỗi là yếu tố then chốt để sửa lỗi hiệu quả. Đề xuất cách sửa lỗi thường không phải là trách nhiệm của người kiểm thử.

Kiểm thử khả năng sử dụng (Usability testing) là loại kiểm thử chuyên biệt tập trung vào việc đánh giá trải nghiệm người dùng (UX) và khả năng sử dụng (Usability) của phần mềm. Mục tiêu là để xác định các vấn đề liên quan đến giao diện người dùng, tính dễ học, hiệu quả, hiệu suất và sự hài lòng của người dùng. Các loại kiểm thử khác tập trung vào chức năng, hiệu năng hoặc bảo mật.

Phương pháp `Đoán lỗi′ (Error guessing) là một kỹ thuật kiểm thử hộp đen (Black-box testing) dựa trên kinh nghiệm, trực giác và kiến thức của người kiểm thử về các lỗi có thể xảy ra trong phần mềm. Người kiểm thử sử dụng kinh nghiệm của mình để đoán xem các lỗi có thể ẩn náu ở đâu và thiết kế các ca kiểm thử để phát hiện chúng. Đây không phải là kỹ thuật tự động, hộp trắng hay liên quan đến hiệu năng.

Kiểm thử khói (Smoke testing) là một loại kiểm thử ban đầu, nhanh chóng, được thực hiện sau mỗi build mới để xác minh rằng các chức năng cốt lõi của phần mềm hoạt động bình thường. Mục đích chính là để `thổi khói′ và xem hệ thống có `bốc cháy′ không, tức là có lỗi nghiêm trọng nào ngăn cản việc kiểm thử sâu hơn không. Nó không tập trung vào kiểm thử chi tiết, hiệu năng hay chịu tải.

Kiểm thử tải (Load testing) mô phỏng việc nhiều người dùng truy cập hệ thống đồng thời để đánh giá hiệu suất của hệ thống dưới tải trọng dự kiến. Kiểm thử độ bền kiểm tra hiệu suất trong thời gian dài, kiểm thử ứng suất đẩy hệ thống đến giới hạn, và kiểm thử khả năng mở rộng đánh giá khả năng mở rộng của hệ thống.

Ca kiểm thử (Test case) là tài liệu mô tả chi tiết các bước cụ thể cần thực hiện để kiểm thử một tính năng, chức năng hoặc yêu cầu cụ thể của phần mềm. Nó bao gồm các điều kiện tiên quyết, dữ liệu đầu vào, các bước thực hiện và kết quả mong đợi. Kế hoạch kiểm thử vạch ra chiến lược kiểm thử tổng thể, báo cáo kiểm thử tổng kết kết quả kiểm thử, và ma trận truy vết yêu cầu theo dõi mối quan hệ giữa yêu cầu và kiểm thử.

Phân tích giá trị biên (Boundary Value Analysis) là kỹ thuật kiểm thử hộp đen tập trung vào việc kiểm tra các giá trị đầu vào ở biên của các lớp tương đương, vì lỗi thường xảy ra ở những điểm này. Phân vùng tương đương chia dữ liệu đầu vào thành các lớp hợp lệ và không hợp lệ, nhưng phân tích giá trị biên đi sâu hơn bằng cách tập trung vào biên của các lớp này.

Kiểm thử xâm nhập (Penetration testing), hay còn gọi là pentesting, là một kỹ thuật kiểm thử bảo mật mô phỏng các cuộc tấn công thực tế từ bên ngoài để xác định và khai thác các lỗ hổng bảo mật trong hệ thống. Mục đích là để đánh giá khả năng phòng thủ của hệ thống và tìm ra các điểm yếu trước khi tin tặc thực sự tấn công. Các lựa chọn khác không phải là kỹ thuật kiểm thử bảo mật chuyên biệt cho mục đích này.

Mục tiêu chính của kiểm thử phần mềm là xác định và báo cáo càng nhiều lỗi càng tốt để có thể sửa chữa chúng trước khi phát hành sản phẩm, từ đó nâng cao chất lượng phần mềm. Mặc dù các lựa chọn khác là những khía cạnh liên quan, nhưng việc `tìm càng nhiều lỗi càng tốt′ là mục tiêu cốt lõi nhất.

Kiểm thử dịch vụ web (Web Service Testing) là phương pháp kiểm thử chuyên biệt thường được sử dụng để kiểm thử API (Application Programming Interface). API thường được xây dựng dưới dạng dịch vụ web, do đó các công cụ và kỹ thuật kiểm thử dịch vụ web rất phù hợp để kiểm tra chức năng, hiệu suất và bảo mật của API. Các lựa chọn khác không trực tiếp tập trung vào kiểm thử API.

Kiểm thử đột biến (Mutation testing) là một loại kiểm thử hộp trắng (White-box testing) vì nó liên quan đến việc sửa đổi mã nguồn (tạo ra các `đột biến′) để kiểm tra hiệu quả của bộ kiểm thử trong việc phát hiện lỗi. Nó đánh giá chất lượng của bộ kiểm thử bằng cách xem liệu nó có thể phát hiện các thay đổi nhỏ trong mã hay không.

Trong mô hình chữ V (V-model), giai đoạn kiểm thử hệ thống (System testing) tương ứng với giai đoạn Thiết kế kiến trúc (Architectural design). Mô hình chữ V thể hiện mối quan hệ song song giữa các giai đoạn phát triển và kiểm thử, trong đó mỗi giai đoạn kiểm thử tương ứng với một giai đoạn phát triển cụ thể. Kiểm thử hệ thống xác minh rằng toàn bộ hệ thống hoạt động đúng theo thiết kế kiến trúc.

Kiểm thử cặp đôi (Pair testing) là một kỹ thuật trong đó hai người kiểm thử cùng làm việc trên cùng một ca kiểm thử, thường là một người thực hiện kiểm thử (Tester) và một người quan sát và ghi chú (Observer). Mục đích là để tận dụng kiến thức và kinh nghiệm của cả hai người, tăng khả năng phát hiện lỗi và cải thiện chất lượng kiểm thử.

Quyết định dừng kiểm thử phần mềm nên dựa trên các tiêu chí dừng kiểm thử (Exit criteria) đã được xác định trước trong kế hoạch kiểm thử. Các tiêu chí này có thể bao gồm mức độ bao phủ mã, số lượng lỗi còn lại, mức độ rủi ro chấp nhận được, hoặc thời gian và ngân sách. Mặc dù các lựa chọn khác có thể là yếu tố ảnh hưởng, nhưng việc tuân thủ tiêu chí dừng đã định là cách tiếp cận chuyên nghiệp và có kế hoạch nhất.

Kiểm thử hộp đen (Black-box testing) còn được gọi là kiểm thử chức năng (Functional testing) vì nó tập trung vào việc kiểm tra chức năng của phần mềm mà không cần biết cấu trúc bên trong của nó. Người kiểm thử chỉ quan tâm đến đầu vào và đầu ra của hệ thống.

Nguyên tắc `Kiểm thử sớm′ (Early testing) nhấn mạnh việc bắt đầu các hoạt động kiểm thử càng sớm càng tốt trong vòng đời phát triển phần mềm, lý tưởng là ngay từ giai đoạn phân tích yêu cầu. Mục đích là để phát hiện lỗi sớm, giảm chi phí sửa lỗi và nâng cao chất lượng phần mềm. Các lựa chọn khác đi ngược lại nguyên tắc này hoặc không phải là trọng tâm của nó.

Trong kiểm thử hiệu năng, `điểm nghẽn′ (bottleneck) đề cập đến thành phần hoặc tài nguyên hệ thống gây ra giới hạn hoặc suy giảm hiệu năng tổng thể của hệ thống. Việc xác định và giải quyết điểm nghẽn là quan trọng để cải thiện hiệu suất hệ thống. Các lựa chọn khác liên quan đến hậu quả hoặc biểu hiện của điểm nghẽn, nhưng không phải là định nghĩa chính xác về điểm nghẽn.

Kiểm thử hộp trắng (White-box testing) cần thiết khi cần kiểm tra chi tiết cấu trúc bên trong và luồng dữ liệu của mã nguồn. Kiểm tra luồng dữ liệu bên trong một hàm phức tạp đòi hỏi phải hiểu rõ logic và cấu trúc mã, do đó phù hợp với kiểm thử hộp trắng. Các lựa chọn khác thường được kiểm thử bằng phương pháp hộp đen.

Mối quan hệ giữa Error, Fault và Failure thường được định nghĩa như sau: Error (Lỗi) là hành động sai lầm của con người (ví dụ, lập trình viên mắc lỗi). Fault (Sai sót∕Lỗi trong code) là kết quả của Error, là một khuyết điểm trong mã nguồn. Failure (Thất bại) là sự sai lệch so với mong đợi khi phần mềm được thực thi, và nó có thể là biểu hiện của một hoặc nhiều Fault. Lựa chọn 2 mô tả chính xác mối quan hệ nhân quả này.

Kiểm thử đơn vị (Unit testing) tập trung vào việc kiểm tra các đơn vị hoặc thành phần nhỏ nhất của phần mềm một cách độc lập, ví dụ như các hàm, phương thức hoặc lớp. Các loại kiểm thử khác kiểm tra ở mức độ tích hợp hoặc toàn hệ thống.

Nhược điểm chính của kiểm thử thủ công so với tự động là dễ mắc lỗi do con người, đặc biệt là khi thực hiện các tác vụ lặp đi lặp lại. Ngoài ra, kiểm thử hồi quy bằng tay tốn rất nhiều thời gian và chi phí. Kiểm thử tự động khắc phục được những nhược điểm này. Các lựa chọn khác không phải là nhược điểm chính hoặc không đúng.