Câu hỏi: SWT301 - Tổng hợp câu hỏi ôn tập

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.

Để tìm ra sự không phù hợp trong các lựa chọn, chúng ta cần hiểu rõ chức năng của từng loại công cụ. Công cụ chuẩn bị dữ liệu thử nghiệm (Test data preparation tools) thường được sử dụng để tạo hoặc chỉnh sửa dữ liệu thử nghiệm. Công cụ thiết kế thử nghiệm (Test design tools) giúp tạo ra các đầu vào thử nghiệm. Công cụ quản lý yêu cầu (Requirement management tools) hỗ trợ việc theo dõi các thử nghiệm riêng lẻ. Công cụ quản lý cấu hình (Configuration management tools) giúp kiểm tra sự nhất quán. Tuy nhiên, trong các lựa chọn, 'Manipulate Data bases' không phải là chức năng chính của công cụ chuẩn bị dữ liệu thử nghiệm. Thay vào đó, nó thường liên quan đến việc tạo hoặc chỉnh sửa cơ sở dữ liệu. Do đó, 'Manipulate Data bases' là sự không phù hợp trong các lựa chọn.

Các loại trả lời là i. Cơ sở hạ tầng ghi lại và tái tạo là ít có khả năng được sử dụng để Đáp án: - Performance testing (kiểm tra hiệu suất) - Recovery testing (kiểm tra phục hồi) - GUI testing (kiểm tra giao diện người dùng) - User requirements (yêu cầu người dùng) Câu trả lời đúng là Performance testing. Giải thích: Cơ sở hạ tầng ghi lại và tái tạo thường được sử dụng để tái tạo lại các tình huống thử nghiệm phức tạp, chẳng hạn như kiểm tra giao diện người dùng hoặc kiểm tra phục hồi. Tuy nhiên, chúng không phù hợp để kiểm tra hiệu suất, vì hiệu suất thường liên quan đến việc đo lường tốc độ và hiệu quả của hệ thống trong thời gian dài, và cơ sở hạ tầng ghi lại và tái tạo không thể tái tạo lại toàn bộ quá trình thời gian dài này.

Để phát hiện mã không thể đạt được (unreachable code), chúng ta nên sử dụng công cụ phân tích tĩnh (static analysis tool). Công cụ này có khả năng phân tích mã nguồn mà không cần thực hiện chạy thử nghiệm (runtime). Nó có thể phát hiện các đoạn mã không thể đạt được, cũng như các vấn đề khác như lặp vô hạn, lỗi null pointer, v.v. Ngoài ra, công cụ phân tích tĩnh cũng có thể giúp phát hiện các vấn đề về bảo mật, như việc sử dụng các hàm có thể bị khai thác để thực hiện tấn công, v.v. Vì vậy, sử dụng công cụ phân tích tĩnh là cách tốt nhất để phát hiện mã không thể đạt được.

Để xác định loại trả lời đúng, chúng ta cần hiểu rõ về các công cụ được đề cập. Công cụ phân tích động (Dynamic analysis tool) là một công cụ được sử dụng để theo dõi và phân tích hành vi của chương trình trong thời gian chạy. Nó có thể giúp phát hiện các vấn đề như memory leaks và unassigned pointers. Công cụ phân tích tĩnh (Static Analysis tool) được sử dụng để phân tích mã nguồn của chương trình mà không cần chạy nó. Nó có thể giúp phát hiện các vấn đề như syntax và logic, nhưng không thể phát hiện các vấn đề về memory leaks và unassigned pointers. Công cụ bảo trì (Maintenance tool) và công cụ cấu hình (Configuration tool) không liên quan đến việc phát hiện memory leaks và unassigned pointers. Vì vậy, công cụ phân tích động (Dynamic analysis tool) là công cụ phù hợp để test flag memory leaks và unassigned pointers.

Các công cụ phân tích tĩnh có thể phát hiện các loại 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 chưa đượ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'. Các công cụ phân tích tĩnh có thể phát hiện các lỗi này bằng cách phân tích mã nguồn mà không cần thực thi nó. Điều này giúp phát hiện các lỗi tiềm ẩn và cải thiện chất lượng mã nguồn. Các lỗi không được sử dụng, lỗ hổng bảo mật và vi phạm tiêu chuẩn lập trình đều có thể được phát hiện bằng cách phân tích mã nguồn. Đồng thời, các công cụ phân tích tĩnh cũng có thể phát hiện các hàm và thủ tục chưa được gọi, giúp phát hiện các lỗi tiềm ẩn khác.

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.

Trong các loại công cụ so sánh trong kiểm thử phần mềm, công cụ so sánh thường được liên kết với các chức năng giám sát hiệu suất và giám sát. Công cụ này giúp kiểm tra hiệu suất của phần mềm và đảm bảo rằng nó hoạt động đúng như mong đợi. Nó cũng giúp phát hiện ra các vấn đề hiệu suất và cung cấp thông tin để cải thiện hiệu suất của phần mềm. Công cụ so sánh thường được sử dụng trong giai đoạn kiểm thử hiệu suất và giám sát để đảm bảo rằng phần mềm hoạt động ổn định và hiệu quả.

Thực tế, việc quản lý và cung cấp một thư viện được kiểm soát chứa tất cả các mặt hàng cấu hình được gọi là "Configuration Control". Điều này bao gồm việc quản lý và theo dõi các thay đổi đối với các mặt hàng cấu hình, đảm bảo rằng tất cả các phiên bản mới được kiểm tra và phê duyệt trước khi được triển khai. Configuration Control giúp đảm bảo rằng các mặt hàng cấu hình được quản lý một cách hiệu quả và giảm thiểu rủi ro khi triển khai các thay đổi.

Khái niệm kiểm thử hoàn chỉnh được định nghĩa là quá trình kiểm thử mà trong đó bạn đã kiểm tra tất cả các câu lệnh, nhánh và sự kết hợp của các nhánh trong chương trình. Điều này có nghĩa là bạn đã kiểm tra tất cả các khả năng có thể xảy ra trong chương trình và đảm bảo rằng chương trình hoạt động đúng như mong đợi. Kiểm thử hoàn chỉnh không chỉ đơn giản là kiểm tra mọi thứ mà còn bao gồm cả việc kiểm tra các trường hợp ngoại lệ, các lỗi có thể xảy ra và các điều kiện đặc biệt. Mục tiêu của kiểm thử hoàn chỉnh là đảm bảo rằng chương trình ổn định, hiệu suất cao và đáp ứng được các yêu cầu của người dùng.

Khi nói về sự không thể hoàn toàn kiểm tra một chương trình, có một số hậu quả quan trọng mà chúng ta cần phải xem xét. Thứ nhất, chúng ta không thể chắc chắn rằng chương trình của mình là hoàn toàn không có lỗi. Điều này có nghĩa là, dù chúng ta đã kiểm tra và thử nghiệm chương trình một cách kỹ lưỡng, vẫn có thể tồn tại những lỗi mà chúng ta chưa phát hiện ra. Thứ hai, không có điểm dừng chắc chắn cho quá trình kiểm tra, điều này có thể khiến một số quản lý sử dụng nó như lý do để yêu cầu ít kiểm tra hơn. Cuối cùng, chúng ta không có cách dễ dàng để xác định những nhiệm vụ kiểm tra nào luôn cần thiết, vì mỗi nhiệm vụ đều tốn thời gian và có thể được sử dụng cho những nhiệm vụ quan trọng khác.

Phương pháp kiểm thử chức năng có thể được thực hiện ở tất cả các mức độ kiểm thử. Điều này bao gồm kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận. Mục đích của kiểm thử chức năng là đảm bảo rằng sản phẩm hoặc hệ thống đáp ứng các yêu cầu chức năng và yêu cầu của người dùng. Kiểm thử chức năng có thể được thực hiện ở tất cả các mức độ kiểm thử vì nó giúp xác định và sửa lỗi chức năng sớm trong quá trình phát triển sản phẩm. Điều này giúp tiết kiệm thời gian và chi phí trong dài hạn.

Phương pháp phòng ngừa và phản ứng trong kiểm thử là hai cách tiếp cận khác nhau trong việc phát hiện lỗi trong phần mềm. Phương pháp phòng ngừa là việc thiết kế và thực hiện kiểm thử ngay từ đầu của quá trình phát triển phần mềm, nhằm phát hiện và sửa lỗi ngay khi còn nhỏ. Trong khi đó, phương pháp phản ứng là việc thiết kế và thực hiện kiểm thử sau khi phần mềm đã được sản xuất, thường là sau khi nhận được phản hồi từ người dùng hoặc trong quá trình kiểm tra lại phần mềm. Điều này cho thấy, phương pháp phòng ngừa là thiết kế kiểm thử sớm, trong khi phương pháp phản ứng là thiết kế kiểm thử sau khi phần mềm đã được sản xuất.

Hệ thống quản lý yêu cầu (Requirements Management Tools) là công cụ giúp lưu trữ các tuyên bố yêu cầu, kiểm tra tính nhất quán và cho phép sắp xếp ưu tiên các yêu cầu. Đồng thời, nó cho phép từng thử nghiệm riêng biệt có thể được theo dõi đến các yêu cầu, chức năng và tính năng. Hệ thống này giúp đảm bảo rằng các yêu cầu được quản lý một cách hiệu quả và chính xác, từ đó giúp giảm thiểu các sai sót trong quá trình phát triển phần mềm.

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.

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ả.