Câu hỏi: SWT301 - Phần 4: Kỹ thuật thiết kế ca kiểm thử

Đáp án đúng: "Pole Coverage". Độ phủ logic (logic coverage) là nhóm tiêu chí hộp trắng đo mức các cấu trúc logic của chương trình đã được thực thi. Các dạng chuẩn gồm độ phủ câu lệnh, độ phủ nhánh hay quyết định, độ phủ điều kiện, độ phủ kết hợp điều kiện và độ phủ đường đi. Không có tiêu chí nào gọi là pole coverage, nên đây là dạng không hợp lệ. "Statement Coverage" (độ phủ câu lệnh) là dạng cơ bản nhất, đo tỉ lệ câu lệnh đã chạy. "Condition Coverage" (độ phủ điều kiện) yêu cầu mỗi điều kiện đơn trong một biểu thức quyết định nhận cả giá trị đúng và sai. "Path Coverage" (độ phủ đường đi) yêu cầu thực thi mọi đường đi qua chương trình, là tiêu chí mạnh nhất trong nhóm nhưng thường không khả thi đầy đủ khi có vòng lặp. Cả ba đều là dạng hợp lệ nên không phải đáp án.

Đáp án đúng: "Business scenarios". Use case (ca sử dụng) mô tả tương tác giữa tác nhân (actor) và hệ thống để hoàn thành một mục tiêu nghiệp vụ, gồm luồng chính, luồng thay thế và luồng ngoại lệ; kiểm thử dựa trên use case vì vậy rất hữu ích để kiểm các kịch bản nghiệp vụ, luồng quy trình từ đầu đến cuối, thường ở cấp kiểm thử hệ thống và chấp nhận, và hay phát hiện lỗi ở chỗ các thành phần phối hợp với nhau. "Performance testing" là kiểm thử phi chức năng về tốc độ, tải, tài nguyên; use case có thể cung cấp kịch bản tải nhưng bản thân nó không đo hiệu năng. "Unit testing" kiểm từng thành phần riêng lẻ, quá nhỏ so với một use case trải qua nhiều thành phần. "Static testing" là xem xét sản phẩm mà không chạy mã, trong khi kiểm thử theo use case là kiểm thử động, thực thi kịch bản trên hệ thống.

Một phần mềm ứng dụng thường bao gồm nhiều tính năng và chức năng khác nhau. Để đảm bảo rằng phần mềm hoạt động đúng như mong đợi, các nhà phát triển cần thực hiện các thử nghiệm để kiểm tra tính năng và chức năng của phần mềm. Một tập hợp các thử nghiệm được gọi là "A" bao gồm các thử nghiệm trường hợp (test case) để kiểm tra tính năng và chức năng của phần mềm từ đầu đến cuối. Các thử nghiệm trường hợp này giúp đảm bảo rằng phần mềm hoạt động đúng và không có lỗi. Vì vậy, "A" bao gồm các thử nghiệm trường hợp (test case) để kiểm tra tính năng và chức năng của phần mềm.

Chức năng kiểm tra khám phá (Exploratory Testing) thường được thực hiện khi cần kiểm tra một ứng dụng một cách linh hoạt và thích nghi với những phát hiện mới. Điều này đặc biệt hữu ích khi ứng dụng đang trong giai đoạn phát triển và cần phải thay đổi nhanh chóng để đáp ứng các yêu cầu mới. Trong quá trình kiểm tra khám phá, tester sẽ tự do khám phá ứng dụng, tìm kiếm các lỗi và vấn đề, và sau đó báo cáo lại cho đội phát triển. Điều này cho phép đội phát triển có thể nhanh chóng sửa lỗi và cải thiện ứng dụng.

Khi sử dụng chiến lược kiểm thử lỗi (error guessing), bạn đang thực hiện loại kiểm thử nào? Lỗi guessing là một phương pháp kiểm thử dựa trên kinh nghiệm và kiến thức của người kiểm thử. Nó liên quan đến việc sử dụng kiến thức và kinh nghiệm của người kiểm thử để đoán và phát hiện các lỗi tiềm ẩn trong sản phẩm. Người kiểm thử sẽ sử dụng kiến thức của mình để đoán các trường hợp kiểm thử có thể dẫn đến lỗi và thực hiện kiểm thử để xác minh. Điều này đòi hỏi người kiểm thử phải có kiến thức sâu về sản phẩm và khả năng phân tích để đoán các lỗi tiềm ẩn. Vì vậy, khi sử dụng lỗi guessing, bạn đang thực hiện kiểm thử dựa trên kinh nghiệm và kiến thức của mình.

Kỹ thuật phân vùng tương đương (Equivalence partitioning) là một phương pháp kiểm thử phần mềm sử dụng các nhóm tương đương để phân chia các giá trị đầu vào thành các phần nhỏ hơn. Mục tiêu của kỹ thuật này là xác định các giá trị đầu vào quan trọng và phân vùng chúng thành các nhóm tương đương để kiểm thử. Kỹ thuật này giúp phát hiện ra các lỗi và sai sót trong phần mềm bằng cách kiểm thử các giá trị đầu vào khác nhau và xác định xem phần mềm có hoạt động đúng hay không. Ví dụ, khi kiểm thử một ứng dụng đăng ký tài khoản, kỹ thuật phân vùng tương đương có thể được sử dụng để phân chia các giá trị đầu vào của người dùng thành các nhóm tương đương, chẳng hạn như các giá trị đầu vào hợp lệ và không hợp lệ. Điều này giúp phát hiện ra các lỗi và sai sót trong ứng dụng và đảm bảo rằng nó hoạt động đúng.

Để đánh giá độ chính xác của các câu hỏi trên, chúng ta cần xem xét các trường hợp thử nghiệm cần thiết để đạt được sự bao phủ tối thiểu về câu lệnh và quyết định/kiểm tra điều kiện. Câu lệnh được cung cấp là một đoạn mã với hai câu lệnh IF và một câu lệnh PRINT. Để đạt được sự bao phủ tối thiểu về câu lệnh, chúng ta cần ít nhất một trường hợp thử nghiệm để thực hiện cả hai câu lệnh IF và câu lệnh PRINT. Điều này có nghĩa là chúng ta cần ít nhất một trường hợp thử nghiệm để đạt được sự bao phủ tối thiểu về câu lệnh. Đối với sự bao phủ tối thiểu về quyết định/kiểm tra điều kiện, chúng ta cần ít nhất hai trường hợp thử nghiệm: một trường hợp thử nghiệm để kiểm tra điều kiện IF A+B > 50 và một trường hợp thử nghiệm để kiểm tra điều kiện IF B > 20. Vì vậy, để đạt được sự bao phủ tối thiểu về cả câu lệnh và quyết định/kiểm tra điều kiện, chúng ta cần ít nhất một trường hợp thử nghiệm cho câu lệnh và hai trường hợp thử nghiệm cho quyết định/kiểm tra điều kiện.

Boundary Value Analysis (BVA) là một phương pháp mở rộng của kỹ thuật nào? Để trả lời câu hỏi này, chúng ta cần hiểu rõ về các kỹ thuật kiểm thử khác nhau. Equivalence Partitioning (EP) là kỹ thuật phân chia dữ liệu thành các phần tương đương, giúp chúng ta kiểm thử các giá trị dữ liệu khác nhau. State Transition Testing (STT) là kỹ thuật kiểm thử các trạng thái chuyển tiếp của hệ thống. Decision Table Testing (DTT) là kỹ thuật kiểm thử dựa trên bảng quyết định, giúp chúng ta kiểm thử các trường hợp khác nhau. Use Case Testing (UCT) là kỹ thuật kiểm thử dựa trên các trường hợp sử dụng, giúp chúng ta kiểm thử các yêu cầu của hệ thống. Boundary Value Analysis (BVA) là kỹ thuật mở rộng của Decision Table Testing (DTT), giúp chúng ta kiểm thử các giá trị dữ liệu ở ranh giới của các phần tương đương.

Chuyển đổi trạng thái là một kỹ thuật kiểm thử được sử dụng để kiểm tra các trạng thái khác nhau của một ứng dụng dựa trên các điều kiện đầu vào khác nhau. Mục tiêu chính của chuyển đổi trạng thái là xác định các trạng thái khác nhau của ứng dụng và kiểm tra xem ứng dụng có chuyển đổi từ trạng thái này sang trạng thái khác một cách chính xác hay không. Điều này giúp đảm bảo rằng ứng dụng hoạt động đúng và không có lỗi khi người dùng tương tác với nó. Ví dụ, khi người dùng đăng nhập vào ứng dụng, ứng dụng sẽ chuyển đổi từ trạng thái không đăng nhập sang trạng thái đã đăng nhập. Chuyển đổi trạng thái giúp kiểm thử viên xác định các trường hợp kiểm thử quan trọng và đảm bảo rằng ứng dụng hoạt động đúng trong các tình huống khác nhau.

Chức năng thử nghiệm khám phá đòi hỏi kỹ năng cơ bản từ một người kiểm thử là khả năng lập trình và sử dụng công cụ tự động hóa. Điều này cho phép họ tự động hóa các thử nghiệm và tăng cường hiệu suất thử nghiệm. Người kiểm thử có kỹ năng lập trình và sử dụng công cụ tự động hóa có thể tạo ra các thử nghiệm tự động hóa để thực hiện các thử nghiệm lặp đi lặp lại, giảm thiểu thời gian và tăng cường độ chính xác của thử nghiệm. Ngoài ra, họ cũng có thể sử dụng các công cụ tự động hóa để thực hiện các thử nghiệm phức tạp và khó khăn.

Trong kỹ thuật đoán lỗi (error guessing), người kiểm thử chủ yếu dựa vào kinh nghiệm, trực giác và kiến thức về lĩnh vực để xác định các lỗi tiềm ẩn. Điều này đòi hỏi người kiểm thử phải có kiến thức sâu về sản phẩm hoặc hệ thống đang được kiểm tra. Họ sử dụng kinh nghiệm và kiến thức này để dự đoán các lỗi có thể xảy ra và tạo ra các kịch bản kiểm thử phù hợp. Kỹ thuật đoán lỗi thường được sử dụng khi không có tài liệu kỹ thuật hoặc yêu cầu rõ ràng, hoặc khi cần kiểm tra các chức năng phức tạp.

Để thiết kế thử nghiệm sử dụng phương pháp Phân chia tương đương (Equivalence Partitioning) cho hàm tính giảm giá dựa trên độ tuổi của khách hàng, chúng ta cần xác định các khoảng độ tuổi khác nhau và giảm giá tương ứng. Các khoảng độ tuổi và giảm giá có thể được xác định như sau: - Độ tuổi từ 1-12 năm: giảm giá 50% - Độ tuổi từ 13-64 năm: giảm giá 20% - Độ tuổi từ 65 tuổi trở lên: giảm giá 30% Bằng cách phân chia độ tuổi của khách hàng thành các khoảng khác nhau, chúng ta có thể tạo ra các thử nghiệm để kiểm tra tính chính xác của hàm tính giảm giá.

Kỹ thuật kiểm thử dựa trên yêu cầu (specification-based testing) là một phương pháp kiểm thử phần mềm nhằm đánh giá và xác minh rằng phần mềm đáp ứng các yêu cầu chức năng và không gian trạng thái đã được xác định trước đó. Mục đích chính của kỹ thuật này là để đánh giá hành vi của hệ thống từ góc độ bên ngoài, tức là kiểm thử phần mềm dựa trên các yêu cầu chức năng và không gian trạng thái đã được xác định trước đó. Điều này giúp đảm bảo rằng phần mềm hoạt động đúng như mong đợi và đáp ứng các yêu cầu của người dùng.

Decision coverage là một phần quan trọng trong white-box testing. Nó đảm bảo rằng tất cả các nhánh trong điểm quyết định của chương trình đều được thực thi. Điều này giúp phát hiện ra các lỗi hoặc vấn đề tiềm ẩn trong mã nguồn. Khi tất cả các nhánh được thực thi, chúng ta có thể tin tưởng rằng chương trình sẽ hoạt động chính xác và không có lỗi logic. Việc đảm bảo decision coverage giúp cải thiện chất lượng của sản phẩm và giảm thiểu rủi ro khi phát hành. Nó cũng giúp phát hiện ra các vấn đề về bảo mật và đảm bảo rằng chương trình tuân thủ các quy định và tiêu chuẩn.

Kịch bản lý tưởng để sử dụng thử nghiệm khám phá (Exploratory Testing) là khi có thời gian hạn chế và không có các yêu cầu chi tiết. Trong trường hợp này, người kiểm thử không có hướng dẫn cụ thể để thực hiện các thử nghiệm, vì vậy họ phải tự mình khám phá và tìm hiểu về sản phẩm để xác định các lỗi và vấn đề. Điều này đòi hỏi sự sáng tạo, kỹ năng phân tích và khả năng tư duy logic của người kiểm thử. Họ phải tự mình quyết định các trường hợp thử nghiệm, các bước thực hiện và các yếu tố cần kiểm tra. Mục tiêu của thử nghiệm khám phá là tìm ra các lỗi và vấn đề mà các phương pháp thử nghiệm khác có thể bỏ qua.

Vì trường password yêu cầu tối thiểu 8 ký tự và tối đa 12 ký tự, nên các giá trị biên bao gồm 7 ký tự và 13 ký tự. 7 ký tự là giá trị biên thấp nhất vì nó nhỏ hơn 8 ký tự, trong khi 13 ký tự là giá trị biên cao nhất vì nó lớn hơn 12 ký tự. Các giá trị 8 ký tự và 10 ký tự không phải là giá trị biên vì chúng nằm trong khoảng giá trị cho phép.

Kỹ thuật hộp trắng có mục tiêu chính là đảm bảo mỗi một trong các chi nhánh có thể xảy ra từ mỗi điểm quyết định được thực thi ít nhất một lần. Điều này giúp đảm bảo rằng mã nguồn được kiểm tra một cách đầy đủ và chính xác. Kỹ thuật này được gọi là Branch coverage testing. Nó tập trung vào việc đảm bảo rằng mỗi một quyết định trong mã nguồn đều được kiểm tra một cách đầy đủ, giúp giảm thiểu khả năng xảy ra lỗi.

Kỹ thuật thiết kế thử nghiệm dựa trên kỹ năng, trực giác và kinh nghiệm của người kiểm thử được gọi là Experience-based testing. Điều này có nghĩa là người kiểm thử sử dụng kiến thức và kinh nghiệm của mình để xác định các trường hợp thử nghiệm và kiểm tra sản phẩm. Kỹ thuật này không dựa trên các yêu cầu chức năng hoặc đặc điểm kỹ thuật của sản phẩm, mà dựa trên sự hiểu biết và kinh nghiệm của người kiểm thử về cách sản phẩm hoạt động và có thể bị lỗi. Experience-based testing thường được sử dụng trong các trường hợp thử nghiệm khi yêu cầu chức năng hoặc đặc điểm kỹ thuật của sản phẩm không rõ ràng hoặc không đầy đủ.

Để đánh giá độ chính xác của mã nguồn, chúng ta cần xác định số lượng thử nghiệm tối thiểu để đạt được sự bao phủ đầy đủ về câu lệnh và nhánh. Mã nguồn được cung cấp là một đoạn mã pseudo-code với các câu lệnh và điều kiện logic. Để đạt được sự bao phủ đầy đủ về câu lệnh, chúng ta cần thực hiện ít nhất 2 thử nghiệm. Thử nghiệm đầu tiên sẽ đọc giá trị của A và B, sau đó thực hiện câu lệnh IF A-B > 50. Thử nghiệm thứ hai sẽ đọc giá trị của B và thực hiện câu lệnh IF B > 10. Để đạt được sự bao phủ đầy đủ về nhánh, chúng ta cần thực hiện thêm 1 thử nghiệm nữa. Thử nghiệm này sẽ đọc giá trị của A và B, sau đó thực hiện cả hai câu lệnh IF A-B > 50 và IF B > 10. Vì vậy, số lượng thử nghiệm tối thiểu để đạt được sự bao phủ đầy đủ về câu lệnh và nhánh là 2 thử nghiệm cho câu lệnh và 2 thử nghiệm cho nhánh.

Mục đích chính của việc kiểm tra use case là xác định các lỗi trong quá trình luân chuyển liên quan đến việc sử dụng hệ thống thông thường. Việc kiểm tra này giúp xác định các lỗi trong các trường hợp sử dụng điển hình của hệ thống, bao gồm cả các lỗi trong các quy trình và giao diện người dùng. Điều này giúp đảm bảo rằng hệ thống hoạt động đúng như mong đợi và đáp ứng được nhu cầu của người dùng. Việc kiểm tra use case thường được thực hiện sau khi hệ thống đã được thiết kế và phát triển, và trước khi hệ thống được triển khai.