Software Testing - SWT301

Các kỹ thuật kiểm thử hộp đen là phương pháp kiểm thử mà không cần biết chi tiết về mã nguồn của ứng dụng. Trong đó, có một số kỹ thuật như phân vùng tương đương (Equivalence partition), bảng quyết định (Decision tables), và sơ đồ giao dịch (Transaction diagrams). Tuy nhiên, kỹ thuật kiểm thử quyết định (Decision testing) không phải là một kỹ thuật hộp đen. Kỹ thuật này đòi hỏi phải biết chi tiết về mã nguồn của ứng dụng và sử dụng các quyết định logic để kiểm thử. Vì vậy, trong các lựa chọn trên, kỹ thuật kiểm thử quyết định không phải là một kỹ thuật hộp đen.

Lỗi đoán (Error Guessing) là một kỹ thuật thử nghiệm được sử dụng để tạo ra các trường hợp thử nghiệm. Kỹ thuật này dựa trên khả năng của người thử nghiệm để đoán ra các lỗi tiềm ẩn trong hệ thống. Lỗi đoán thường được sử dụng như một phương pháp đầu tiên để tạo ra các trường hợp thử nghiệm, vì nó cho phép người thử nghiệm sử dụng kinh nghiệm và kiến thức của mình để xác định các khu vực tiềm ẩn của hệ thống. Điều này giúp người thử nghiệm tạo ra các trường hợp thử nghiệm hiệu quả và hiệu quả, đồng thời tiết kiệm thời gian và nguồn lực. Tuy nhiên, lỗi đoán cũng có thể được sử dụng sau khi áp dụng các kỹ thuật thử nghiệm chính thức khác, để kiểm tra và xác minh các trường hợp thử nghiệm đã được tạo ra.

Để trả lời câu hỏi này, chúng ta cần hiểu rõ về code được cung cấp và các khái niệm về coverage trong kiểm thử phần mềm. Code được cung cấp bao gồm một điều kiện IF-THEN-ELSE và một lệnh đọc giá trị D. Điều kiện IF-THEN-ELSE sẽ thực hiện một trong hai hành động: nếu A lớn hơn B thì C sẽ được tính bằng A trừ B, nếu không thì C sẽ được tính bằng A cộng B. Sau đó, nếu C bằng D thì sẽ in ra 'Error'. Để đạt được statement coverage, chúng ta cần chạy thử nghiệm để thực hiện tất cả các câu lệnh trong code. Điều này có nghĩa là chúng ta cần chạy thử nghiệm để thực hiện cả hai hành động trong điều kiện IF-THEN-ELSE và cả hai trường hợp của lệnh đọc giá trị D. Để đạt được branch coverage, chúng ta cần chạy thử nghiệm để thực hiện tất cả các nhánh trong code. Trong trường hợp này, có 3 nhánh: nhánh IF-THEN, nhánh IF-ELSE và nhánh ENIF. Vì vậy, để đạt được branch coverage, chúng ta cần chạy thử nghiệm để thực hiện tất cả 3 nhánh này.

Khi một người đang thống trị cuộc họp cải tiến quy trình phần mềm, người dẫn cuộc họp cần sử dụng các kỹ thuật phù hợp để khuyến khích các thành viên khác tham gia thảo luận. Kỹ thuật phù hợp trong trường hợp này là chuyển chủ đề sang vấn đề mà người đó không có ý kiến mạnh mẽ. Điều này cho phép người dẫn cuộc họp tạo cơ hội cho các thành viên khác thể hiện ý kiến của mình, đồng thời giúp ngăn chặn việc một người duy trì quyền kiểm soát cuộc họp. Bằng cách chuyển chủ đề, người dẫn cuộc họp có thể tạo ra một môi trường thảo luận tích cực và đa dạng, nơi mà mọi người đều có cơ hội thể hiện ý kiến của mình.

Kiểm tra trường hợp sử dụng (Use Case Testing) thường được sử dụng để phát hiện các lỗi liên quan đến yêu cầu chức năng của hệ thống. Các lỗi này thường bao gồm các vấn đề về logic, quy trình và giao diện người dùng. Vì vậy, loại lỗi mà kiểm tra trường hợp sử dụng có khả năng phát hiện được nhất là các lỗi liên quan đến yêu cầu chức năng của hệ thống, bao gồm lỗi về logic (ii) và lỗi về giao diện người dùng (iii).

Vấn đề này yêu cầu chúng ta xác định tập hợp các giá trị biên (boundary values) trong một chương trình xác thực trường số. Chương trình xác thực trường số theo các quy tắc sau: giá trị nhỏ hơn 10 bị từ chối, giá trị nằm trong khoảng từ 10 đến 21 được chấp nhận, giá trị lớn hơn hoặc bằng 22 bị từ chối. Để trả lời câu hỏi này, chúng ta cần tìm tập hợp các giá trị biên bao gồm cả giá trị nhỏ nhất, giá trị lớn nhất và các giá trị quan trọng khác trong khoảng xác định. Trong trường hợp này, giá trị nhỏ nhất là 9, giá trị lớn nhất là 22 và các giá trị quan trọng khác là 10 và 21. Vì vậy, tập hợp các giá trị biên bao gồm cả 9, 10, 21 và 22.

Các loại mô hình trả lời là il là mô hình mô tả quá trình hoạt động của một phần mềm. Trong đó, mô hình dòng chảy quy trình (Process flow model) không thể được sử dụng trong thử nghiệm chức năng vì nó mô tả quá trình hoạt động của phần mềm mà không thể xác định được các chức năng cụ thể của phần mềm. Mô hình trạng thái giao dịch (State transaction model) và mô hình cấu trúc menu (Menu structure model) có thể được sử dụng trong thử nghiệm chức năng vì chúng mô tả các chức năng cụ thể của phần mềm. Mô hình mô tả bằng ngôn ngữ thông thường (Plain language specification model) cũng không thể được sử dụng trong thử nghiệm chức năng vì nó mô tả phần mềm bằng ngôn ngữ thông thường mà không thể xác định được các chức năng cụ thể của phần mềm.

Câu hỏi này yêu cầu bạn chọn đáp án đúng cho các lựa chọn sau. Các lựa chọn bao gồm các bước trong một quá trình mua hàng trực tuyến. Bạn cần chọn đáp án đúng cho các bước này. Các bước bao gồm: đăng nhập, xem sản phẩm, thêm sản phẩm vào giỏ hàng, thanh toán và đăng xuất. Đáp án đúng sẽ bao gồm các bước này trong một trình tự hợp lý.

Chất lượng phần mềm không liên quan đến việc trả lời câu hỏi này vì phần mềm chất lượng cao không nhất thiết phải có tính đúng đắn. Tuy nhiên, tính đúng đắn là một yếu tố quan trọng trong việc đảm bảo phần mềm hoạt động đúng như mong đợi. Tính khả dụng và tính tái sử dụng cũng là những yếu tố quan trọng trong việc đánh giá chất lượng phần mềm. Tính khả dụng liên quan đến khả năng sử dụng phần mềm một cách dễ dàng và hiệu quả, trong khi tính tái sử dụng liên quan đến khả năng sử dụng lại phần mềm trong các dự án khác. Tính khả dụng và tính tái sử dụng là những yếu tố quan trọng trong việc đảm bảo phần mềm có thể được sử dụng rộng rãi và hiệu quả.

Việc triển khai thủ tục quản lý cấu hình nên được thực hiện khi đánh giá các tiêu chí kết thúc. Điều này cho phép đảm bảo rằng các thay đổi được thực hiện trong quá trình thử nghiệm không ảnh hưởng đến kết quả cuối cùng. Khi triển khai thủ tục quản lý cấu hình trong giai đoạn đánh giá các tiêu chí kết thúc, bạn có thể xác định và kiểm soát các thay đổi được thực hiện, từ đó đảm bảo rằng hệ thống hoặc sản phẩm thử nghiệm đáp ứng các yêu cầu và tiêu chuẩn đã được xác định.

Fault Masking là một kỹ thuật trong kiểm thử phần mềm, liên quan đến việc che giấu hoặc ẩn đi lỗi trong hệ thống. Trong câu hỏi này, chúng ta đang được hỏi về định nghĩa của Fault Masking. Câu trả lời đúng là "Error condition hiding another error condition", có nghĩa là việc che giấu một lỗi khác. Điều này có thể xảy ra khi một lỗi được ẩn đi bởi một lỗi khác, khiến cho lỗi ban đầu không được phát hiện. Ví dụ, một lỗi về dữ liệu có thể được che giấu bởi một lỗi về giao diện người dùng. Fault Masking có thể xảy ra do nhiều nguyên nhân, bao gồm cả lỗi của nhà phát triển và lỗi của người kiểm thử. Tuy nhiên, mục tiêu của Fault Masking là để đảm bảo rằng hệ thống hoạt động đúng và không bị lỗi.

Một Test Lead / Leader có nhiều nhiệm vụ quan trọng trong quá trình kiểm thử phần mềm. Dưới đây là một số nhiệm vụ chính của họ: - Lập kế hoạch và quản lý dự án kiểm thử (i): Test Lead / Leader chịu trách nhiệm lập kế hoạch và quản lý dự án kiểm thử, bao gồm việc xác định mục tiêu, phạm vi và thời gian của dự án. - Xây dựng và quản lý đội ngũ kiểm thử (ii): Họ phải xây dựng và quản lý đội ngũ kiểm thử, bao gồm việc tuyển dụng, đào tạo và quản lý nhân viên. - Xác định và quản lý các yêu cầu kiểm thử (iii): Test Lead / Leader phải xác định và quản lý các yêu cầu kiểm thử, bao gồm việc xác định các trường hợp kiểm thử và các tiêu chí đánh giá. - Đánh giá và báo cáo kết quả kiểm thử (iv): Cuối cùng, họ phải đánh giá và báo cáo kết quả kiểm thử, bao gồm việc xác định các vấn đề và đề xuất các giải pháp. Vì vậy, câu trả lời đúng là "ili và iv là đúng và i và ii là sai".

Trong tiêu chuẩn Test Documentation Standard, tài liệu Test Plan bao gồm các nội dung chính như danh sách các mục cần kiểm tra (test items), môi trường kiểm tra, kế hoạch chất lượng và lịch trình. Tuy nhiên, nội dung không được bao gồm trong tài liệu Test Plan là danh sách các mục không được kiểm tra (what is not to be tested). Điều này là vì mục đích của tài liệu Test Plan là xác định các yêu cầu và điều kiện cần thiết cho quá trình kiểm tra, chứ không phải là xác định các hạn chế hoặc ngoại lệ. Vì vậy, danh sách các mục không được kiểm tra thường được bao gồm trong tài liệu khác, chẳng hạn như tài liệu yêu cầu hoặc tài liệu quy trình.

FPA (Function Point Analysis) là một phương pháp đo lường được sử dụng để ước tính kích thước của một hệ thống thông tin. Nó giúp đánh giá các yêu cầu chức năng của dự án và đo lường mức độ phức tạp của hệ thống. FPA tập trung vào việc đo lường các yêu cầu chức năng, bao gồm các yêu cầu nhập, yêu cầu xuất và các yêu cầu xử lý. Mục đích của FPA là cung cấp một cách đo lường khách quan và đáng tin cậy về kích thước của hệ thống, giúp các nhà phát triển dự án có thể lập kế hoạch và quản lý dự án một cách hiệu quả hơn.

Một trong những lý do chính khiến các nhà phát triển gặp khó khăn khi kiểm tra công việc của mình là họ thiếu thông tin kỹ thuật. Thông tin kỹ thuật là tài liệu mô tả chi tiết về sản phẩm, bao gồm hướng dẫn sử dụng, tài liệu tham khảo và các thông tin liên quan khác. Khi thiếu thông tin kỹ thuật, các nhà phát triển khó có thể hiểu rõ về sản phẩm và kiểm tra nó một cách hiệu quả. Điều này dẫn đến việc kiểm tra không đầy đủ, gây ra các lỗi và vấn đề trong sản phẩm. Vì vậy, thông tin kỹ thuật là một phần quan trọng trong quy trình kiểm tra và phát triển phần mềm.

Các phương pháp trả lời được sử dụng trong các bàn làm việc cá nhân để sản xuất các sản phẩm đầu ra đúng. Các phương pháp này giúp đảm bảo rằng các sản phẩm đầu ra được tạo ra một cách chính xác và hiệu quả. Ví dụ, các công cụ và kỹ thuật được sử dụng để thực hiện các tác vụ cụ thể, trong khi các thủ tục và tiêu chuẩn được sử dụng để đảm bảo rằng các tác vụ được thực hiện theo đúng quy trình. Các quá trình và kiểm tra được sử dụng để đảm bảo rằng các sản phẩm đầu ra đáp ứng các yêu cầu và tiêu chuẩn. Cuối cùng, các đánh giá và cập nhật được sử dụng để đánh giá và cải thiện các phương pháp trả lời.

Test Plan là một tài liệu quan trọng trong quá trình kiểm thử phần mềm, giúp định hướng và quản lý quá trình kiểm thử. Trong Test Plan, có một số yếu tố quan trọng cần được xem xét. Các tính năng cần kiểm thử (Features to be tested) và yêu cầu môi trường (Environmental needs) là hai yếu tố quan trọng cần được xác định rõ ràng. Kết quả mong đợi (Expected results) cũng là một phần quan trọng của Test Plan, giúp kiểm thử viên xác định xem phần mềm đã đáp ứng được yêu cầu hay chưa. Tuy nhiên, tiêu chí dừng kiểm thử (Suspension criteria) không phải là một phần của Test Plan. Thay vào đó, nó thường được xác định trong các tài liệu khác như Test Case hoặc Test Report.

Hoạt động nào trong quá trình thử nghiệm cơ bản tạo ra bộ thử nghiệm để thực hiện thử nghiệm một cách hiệu quả? Trong quá trình thử nghiệm cơ bản, có bốn hoạt động chính: Planning và Control, Analysis và Design, Implementation và Execution, Test Closure. Trong đó, Analysis và Design là hoạt động tạo ra bộ thử nghiệm để thực hiện thử nghiệm một cách hiệu quả. Hoạt động này bao gồm việc phân tích yêu cầu của sản phẩm, thiết kế bộ thử nghiệm và xác định các trường hợp thử nghiệm cần thực hiện.

Khi chọn và triển khai công cụ kiểm thử, có một số hoạt động quan trọng cần được thực hiện. Trước hết, cần phải xác định mục tiêu và yêu cầu của dự án, bao gồm cả các yêu cầu về tính hiệu suất, độ tin cậy và khả năng mở rộng của công cụ kiểm thử. Sau đó, cần phải đánh giá và so sánh các công cụ kiểm thử khác nhau để chọn ra công cụ phù hợp nhất với nhu cầu của dự án. Ngoài ra, cần phải xem xét các yếu tố như chi phí, tính dễ sử dụng và khả năng tích hợp với các hệ thống khác. Cuối cùng, cần phải lập kế hoạch và triển khai công cụ kiểm thử một cách hiệu quả, bao gồm cả việc đào tạo nhân viên và thiết lập quy trình kiểm thử.

User Acceptance Testing (UAT) là một phần quan trọng trong quy trình phát triển phần mềm. Nó giúp đảm bảo rằng sản phẩm đáp ứng được yêu cầu và kỳ vọng của người dùng. Có một số đặc điểm của UAT, bao gồm việc sử dụng các công cụ thực thi thử nghiệm tự động, việc thử nghiệm được thực hiện bởi người dùng và việc thử nghiệm dựa trên các tiêu chí thử nghiệm được chấp nhận. Tuy nhiên, việc tích hợp hệ thống với tài liệu người dùng không phải là một đặc điểm của UAT. Thay vào đó, nó là một phần của quy trình phát triển phần mềm, giúp đảm bảo rằng hệ thống được triển khai và sử dụng một cách hiệu quả. Vì vậy, trong các lựa chọn trên, "Tích hợp hệ thống với tài liệu người dùng" không phải là một đặc điểm của UAT.