SWT301 Software Testing – Bộ ôn tập cuối kỳ số 1 (60 câu)

Kết quả mong đợi của một thử nghiệm được định nghĩa là những gì xảy ra khi một thử nghiệm được thực hiện. Nó là kết quả cuối cùng của quá trình thử nghiệm, bao gồm cả dữ liệu đầu vào và dữ liệu đầu ra. Kết quả của một thử nghiệm thường được thể hiện dưới dạng số liệu, hình ảnh hoặc các thông tin khác. Để xác định kết quả mong đợi của một thử nghiệm, người ta thường sử dụng các phương pháp như mô hình hóa, phân tích dữ liệu và đánh giá. Kết quả của một thử nghiệm có thể được sử dụng để đánh giá hiệu suất của một hệ thống, sản phẩm hoặc quy trình. Nó cũng có thể được sử dụng để xác định nguyên nhân của một vấn đề và tìm ra giải pháp.

Trong quá trình kiểm thử, có bốn quá trình cơ bản được xác định là: Planning and control, Test case development, Test execution và Test closure activities. Planning and control liên quan đến việc lập kế hoạch và kiểm soát quá trình kiểm thử, bao gồm việc xác định mục tiêu, phạm vi và thời gian kiểm thử. Test case development liên quan đến việc tạo ra các trường hợp kiểm thử để kiểm tra sản phẩm. Test execution liên quan đến việc thực hiện các trường hợp kiểm thử đã được tạo ra. Test closure activities liên quan đến việc đóng gói và báo cáo kết quả kiểm thử. Analysis and design là một phần của quá trình phát triển sản phẩm, không phải là một quá trình kiểm thử cơ bản. Vì vậy, Analysis and design không phải là một quá trình kiểm thử cơ bản.

Các trường hợp kiểm thử được tạo từ các trường hợp sử dụng thường được sử dụng để phát hiện các lỗi trong quá trình luồng làm việc trong môi trường thực tế của hệ thống. Điều này có nghĩa là các trường hợp kiểm thử này được tạo dựa trên cách người dùng thực tế sẽ tương tác với hệ thống, giúp phát hiện các lỗi và vấn đề trong quá trình sử dụng thực tế. Điều này giúp đảm bảo rằng hệ thống hoạt động đúng cách và đáp ứng được nhu cầu của người dùng.

Để theo dõi tiến độ kiểm thử, có nhiều yếu tố quan trọng cần xem xét. Đầu tiên, phần trăm thực thi các trường hợp kiểm thử (i) giúp chúng ta đánh giá hiệu suất và tốc độ thực hiện các trường hợp kiểm thử. Thứ hai, phần trăm công việc đã hoàn thành trong việc chuẩn bị môi trường kiểm thử (ii) cho chúng ta biết tiến độ của dự án. Thứ ba, thông tin về lỗi, chẳng hạn như mật độ lỗi, số lỗi đã tìm thấy và sửa chữa (iii) giúp chúng ta đánh giá chất lượng sản phẩm. Cuối cùng, kích thước của đội kiểm thử và kỹ năng của kỹ sư (iv) cũng rất quan trọng vì nó ảnh hưởng đến hiệu suất và chất lượng của quá trình kiểm thử.

Khi chọn phương pháp kiểm thử, yếu tố quan trọng nhất là khả năng có sẵn của công cụ hỗ trợ các kỹ thuật đề xuất. Điều này có nghĩa là nếu bạn muốn sử dụng một kỹ thuật kiểm thử mới, bạn cần có sẵn các công cụ cần thiết để thực hiện nó. Ví dụ, nếu bạn muốn sử dụng kỹ thuật kiểm thử tự động, bạn cần có sẵn các công cụ như IDE, trình biên dịch, v.v. Nếu bạn không có sẵn các công cụ này, bạn sẽ gặp khó khăn trong việc thực hiện kỹ thuật kiểm thử đó. Vì vậy, khả năng có sẵn của công cụ hỗ trợ là yếu tố quan trọng nhất khi chọn phương pháp kiểm thử.

Khi triển khai giải pháp ngân hàng trực tuyến, việc kiểm thử là một phần quan trọng để đảm bảo tính ổn định và hiệu suất của hệ thống. Trong đó, có bốn loại kiểm thử được đề cập trong câu hỏi: kiểm thử tích hợp hệ thống, kiểm thử chức năng, kiểm thử không chức năng và kiểm thử yêu cầu. Kiểm thử chức năng là quá trình kiểm tra xem các tính năng của hệ thống có hoạt động đúng như mong đợi hay không, bao gồm cả việc kiểm tra các giao dịch, thanh toán và quản lý tài khoản. Điều này giúp đảm bảo rằng hệ thống có thể xử lý các yêu cầu của khách hàng một cách chính xác và hiệu quả.

Các công cụ phân tích tĩnh có thể phát hiện các lỗi sau: i. Biến không bao giờ được sử dụng. ii. Các lỗ hổng bảo mật. iii. Vi phạm tiêu chuẩn lập trình. iv. Các hàm và thủ tục không được gọi. Trong các lựa chọn trên, câu trả lời đúng là "1, ii, iii, iv là đúng" vì các công cụ phân tích tĩnh có thể phát hiện tất cả các lỗi này. Các công cụ này có thể giúp phát hiện các vấn đề tiềm ẩn trong mã nguồn, bao gồm cả các biến không được sử dụng, các lỗ hổng bảo mật và vi phạm tiêu chuẩn lập trình. Điều này giúp các nhà phát triển cải thiện chất lượng mã nguồn và giảm thiểu các vấn đề bảo mật.

Khi mua một công cụ kiểm thử mới, nó nên được sử dụng đầu tiên bởi một nhóm nhỏ để thiết lập cách sử dụng tốt nhất công cụ đó. Điều này giúp nhóm nhỏ này có thể tìm hiểu và khám phá các tính năng của công cụ, từ đó họ có thể thiết lập các quy trình và thủ tục sử dụng công cụ một cách hiệu quả. Sau đó, họ có thể hướng dẫn và đào tạo các thành viên khác trong nhóm về cách sử dụng công cụ. Việc này giúp tiết kiệm thời gian và công sức cho cả nhóm, đồng thời đảm bảo rằng công cụ được sử dụng một cách hiệu quả và đúng mục đích.

Mã code không thể tiếp cận thường được phát hiện tốt nhất bằng cách sử dụng công cụ kiểm tra bao phủ. Công cụ kiểm tra bao phủ là một công cụ giúp xác định phần mã code nào đã được thực hiện trong quá trình kiểm thử. Nó giúp phát hiện ra các phần code không được thực hiện, bao gồm cả code không thể tiếp cận. Code không thể tiếp cận là code được viết nhưng không bao giờ được thực hiện trong quá trình chạy chương trình. Nó có thể do nhiều lý do khác nhau, chẳng hạn như vị trí code nằm ngoài phạm vi kiểm thử, hoặc code bị lỗi và không thể thực hiện được. Công cụ kiểm tra bao phủ giúp phát hiện ra code không thể tiếp cận và giúp nhà phát triển sửa lỗi và hoàn thiện code.

Khi so sánh việc kiểm tra phần mềm được phát triển bởi nhà thầu bên ngoài nước bạn và nhà thầu bên trong nước bạn, có một số điểm khác biệt quan trọng cần xem xét. Đầu tiên, việc kiểm tra phần mềm được phát triển bởi nhà thầu bên ngoài nước bạn có thể gặp phải những thách thức liên quan đến ngôn ngữ và văn hóa. Điều này có thể dẫn đến sự hiểu lầm và sai sót trong quá trình kiểm tra. Mặt khác, việc kiểm tra phần mềm được phát triển bởi nhà thầu bên trong nước bạn có thể giúp bạn kiểm soát tốt hơn về mặt ngôn ngữ và văn hóa, từ đó đảm bảo rằng phần mềm đáp ứng được nhu cầu của người dùng.

Khi chọn công cụ, có một số nguyên tắc quan trọng cần tuân thủ. Trong số các lựa chọn trên, nguyên tắc không chính xác là "Hiểu rõ về công nghệ được sử dụng bởi các đối thủ cạnh tranh". Nguyên tắc này không phải là một trong những nguyên tắc chính cho việc chọn công cụ. Nguyên tắc chính bao gồm việc đánh giá công cụ dựa trên các yêu cầu và tiêu chí rõ ràng, ước tính tỷ lệ lợi ích và chi phí, và đánh giá độ chín muồi của tổ chức. Việc hiểu rõ về công nghệ của đối thủ cạnh tranh có thể hữu ích trong một số trường hợp, nhưng nó không phải là một trong những nguyên tắc cơ bản cho việc chọn công cụ.

Tính chất phần mềm không tốt thường bao gồm cả rủi ro dự án và rủi ro sản phẩm. Rủi ro dự án liên quan đến các vấn đề phát sinh trong quá trình triển khai dự án, chẳng hạn như vượt quá ngân sách, chậm tiến độ, hoặc không đáp ứng yêu cầu khách hàng. Rủi ro sản phẩm liên quan đến chất lượng của sản phẩm phần mềm, chẳng hạn như lỗi, không tương thích, hoặc không đáp ứng yêu cầu kỹ thuật. Vì vậy, lựa chọn đúng là cả rủi ro dự án và rủi ro sản phẩm.

Vấn đề này liên quan đến quản lý và kiểm soát các thành phần cấu hình trong một thư viện được kiểm soát. Thư viện này chứa tất cả các cấu hình vật thể. Để trả lời câu hỏi này, chúng ta cần hiểu các khái niệm liên quan. Configuration Control là quá trình kiểm soát và quản lý các thay đổi đối với các thành phần cấu hình. Status Accounting là quá trình theo dõi và cập nhật trạng thái của các thành phần cấu hình. Configuration Identification là quá trình xác định và phân loại các thành phần cấu hình. Trong trường hợp này, câu trả lời đúng là Configuration Control vì nó liên quan đến việc cung cấp và quản lý một thư viện được kiểm soát chứa tất cả các thành phần cấu hình.

Kể từ khi User Acceptance Testing (UAT) được thực hiện, có một số đặc điểm quan trọng cần lưu ý. Đầu tiên, UAT sử dụng các công cụ thực thi thử nghiệm tự động. Thứ hai, UAT được thực hiện bởi người dùng. Thứ ba, UAT được thực hiện dựa trên các tiêu chí thử nghiệm chấp nhận. Tuy nhiên, có một đặc điểm không phải là đặc điểm của UAT. Đó là tích hợp hệ thống với tài liệu người dùng. Trong thực tế, UAT không liên quan đến việc tích hợp hệ thống với tài liệu người dùng. Thay vào đó, UAT tập trung vào việc đảm bảo rằng hệ thống đáp ứng các yêu cầu của người dùng và đáp ứng các tiêu chí chấp nhận.

Pha yêu cầu là một phần quan trọng trong vòng đời phát triển phần mềm. Mục đích chính của pha này là để hiểu rõ được nhu cầu của người dùng và xác định rõ yêu cầu của dự án. Điều này giúp cho các nhà phát triển có thể xây dựng được sản phẩm đáp ứng được nhu cầu của người dùng. Trong pha yêu cầu, các nhà phát triển sẽ thu thập thông tin từ người dùng, phân tích và xác định rõ yêu cầu của dự án. Qua đó, họ có thể xây dựng được kế hoạch phát triển phần mềm phù hợp và hiệu quả.