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

Các tài xế (drivers) là công cụ được sử dụng để kiểm soát và vận hành phần mềm đang được kiểm thử. Họ đóng vai trò quan trọng trong việc tương tác với phần mềm và thực hiện các hành động cụ thể để kiểm tra tính đúng đắn của nó. Ví dụ, một tài xế có thể được sử dụng để tương tác với một ứng dụng web, nhập dữ liệu, nhấp vào các nút và kiểm tra phản hồi của ứng dụng. Mục đích của việc sử dụng tài xế là để mô phỏng các hành động của người dùng thực và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.

Mô tả về tiêu chuẩn kiểm tra thành phần trong việc đánh giá khả năng trả lời của một hệ thống. Tiêu chuẩn này được sử dụng để xác định các yêu cầu và quy trình kiểm tra để đảm bảo hệ thống đáp ứng được các yêu cầu chức năng và hiệu suất. Trong các lựa chọn trên, tiêu chuẩn IEEE 829 là tiêu chuẩn được sử dụng rộng rãi nhất trong lĩnh vực kiểm thử phần mềm. Tiêu chuẩn này cung cấp các hướng dẫn chi tiết về quy trình kiểm thử, bao gồm việc xác định yêu cầu kiểm thử, thiết kế kiểm thử, thực hiện kiểm thử và đánh giá kết quả kiểm thử. IEEE 610 là tiêu chuẩn về từ vựng và định nghĩa trong lĩnh vực công nghệ thông tin, không liên quan trực tiếp đến kiểm thử phần mềm. BS7925-1 và BS7925-2 là tiêu chuẩn về kiểm thử phần mềm của Anh, nhưng không được sử dụng rộng rãi như IEEE 829.

Đáp án đúng: B. Độ tin cậy (reliability) là xác suất phần mềm hoạt động không phát sinh sự cố trong một khoảng thời gian và điều kiện xác định. Vì vậy hệ thống tin cậy là hệ thống ÍT có khả năng gây ra hỏng hóc (failure) khi vận hành. Cần phân biệt fault (lỗi nằm trong mã) với failure (biểu hiện sai khi chạy): một hệ thống vẫn có thể chứa nhiều fault ở những nhánh hiếm khi được thực thi mà vẫn rất tin cậy, nên phương án C "gần như không còn lỗi" không phải định nghĩa của độ tin cậy. Phương án A nói về tiến độ dự án và phương án D nói về mức độ hài lòng của người dùng, đều là thuộc tính khác.

Về cấu trúc báo cáo sự cố, tiêu chuẩn IEEE 829 cho tài liệu kiểm thử phần mềm (Standard for Software Test Documentation IEEE 829) đề cập đến một phần quan trọng. Cụ thể, tiêu chuẩn này định nghĩa cấu trúc của báo cáo sự cố (incident report) và gọi nó là 'Báo cáo sự cố kiểm thử' (Test Incident Report). Điều này cho thấy tầm quan trọng của việc lập báo cáo sự cố trong quá trình kiểm thử phần mềm để đảm bảo rằng mọi sự cố đều được ghi nhận và xử lý một cách đầy đủ.

Khi tăng cường chất lượng phần mềm thông qua các phương pháp phát triển tốt hơn, sẽ ảnh hưởng đến thời gian cần thiết cho quá trình kiểm thử (phases kiểm thử). Việc áp dụng các phương pháp phát triển tốt hơn sẽ giúp giảm thiểu số lượng lỗi trong phần mềm, từ đó giảm thời gian cần thiết cho quá trình kiểm thử. Điều này là vì các lỗi thường được phát hiện và sửa chữa trong quá trình phát triển, thay vì phải chờ đến giai đoạn kiểm thử. Vì vậy, việc tăng cường chất lượng phần mềm thông qua các phương pháp phát triển tốt hơn sẽ giúp giảm thời gian cần thiết cho quá trình kiểm thử.

Các phương pháp trả lời là IL. Phương pháp nào không phải là nguyên tắc kiểm thử là: Trong kiểm thử phần mềm, có nhiều nguyên tắc được áp dụng để đảm bảo chất lượng của sản phẩm. Các nguyên tắc này bao gồm Early testing (Kiểm thử sớm), Defect clustering (Tập trung lỗi), Pesticide paradox (Paradox thuốc trừ sâu) và Exhaustive testing (Kiểm thử đầy đủ). Tuy nhiên, trong số các phương pháp này, Exhaustive testing không phải là một nguyên tắc kiểm thử. Nguyên tắc này đề cập đến việc kiểm thử tất cả các khả năng của sản phẩm, điều này không thể thực hiện được trong thực tế do số lượng khả năng quá lớn. Nguyên tắc kiểm thử thực sự bao gồm Early testing, Defect clustering và Pesticide paradox. Early testing đề cập đến việc kiểm thử sớm trong quá trình phát triển phần mềm để phát hiện và sửa lỗi sớm. Defect clustering đề cập đến việc tập trung lỗi vào các khu vực cụ thể của sản phẩm. Pesticide paradox đề cập đến việc việc kiểm thử trở nên hiệu quả hơn khi sử dụng các công cụ và kỹ thuật kiểm thử khác nhau.

Khi thiết kế thử nghiệm sớm trong chu kỳ sống của sản phẩm, lợi ích chính là ngăn chặn các lỗi được đưa vào mã nguồn. Việc này giúp giảm thiểu đáng kể số lượng lỗi cần phải sửa chữa trong quá trình thử nghiệm sau này. Thiết kế thử nghiệm sớm cũng cho phép phát hiện và sửa chữa các lỗi ngay từ đầu, giúp tiết kiệm thời gian và công sức trong quá trình thử nghiệm. Ngoài ra, thiết kế thử nghiệm sớm còn giúp đảm bảo rằng sản phẩm đáp ứng được các yêu cầu và tiêu chuẩn của khách hàng, từ đó tăng cường độ tin cậy và chất lượng của sản phẩm.

Có nhiều loại kiểm thử trong quá trình phát triển phần mềm. Kiểm thử thành phần (Component testing) và kiểm thử hệ thống (System testing) là hai loại kiểm thử quan trọng. Kiểm thử thành phần thường được thực hiện bằng cách kiểm thử hộp đen (Black box), trong khi kiểm thử hệ thống thường được thực hiện bằng cách kiểm thử hộp trắng (White box). Điều này có nghĩa là kiểm thử thành phần tập trung vào việc kiểm thử các thành phần riêng lẻ của phần mềm, trong khi kiểm thử hệ thống tập trung vào việc kiểm thử toàn bộ hệ thống phần mềm. Ngoài ra, nếu bạn tìm thấy nhiều lỗi trong quá trình kiểm thử, điều đó không có nghĩa là phần mềm không tốt. Thay vào đó, nó có nghĩa là phần mềm cần được cải thiện thêm. Tương tự, số lượng lỗi ít hơn không phải là dấu hiệu tốt nhất cho quá trình kiểm thử. Điều quan trọng là phải chạy nhiều thử nghiệm để đảm bảo phần mềm hoạt động đúng cách. Vì vậy, câu trả lời đúng là "The fewer bugs you find, the better your testing was" không hoàn toàn chính xác.

Phân tích thử nghiệm phần mềm thường chiếm khoảng 5-10% chi phí phát triển phần mềm. Điều này có thể khác nhau tùy thuộc vào quy mô dự án và mức độ phức tạp của phần mềm. Tuy nhiên, trong nhiều trường hợp, việc thử nghiệm phần mềm được coi là một phần quan trọng của quá trình phát triển phần mềm và thường chiếm một tỷ lệ nhỏ so với tổng chi phí phát triển. Việc thử nghiệm phần mềm giúp đảm bảo chất lượng phần mềm, phát hiện và sửa lỗi sớm, từ đó tiết kiệm thời gian và chi phí trong dài hạn.

Kỹ thuật thiết kế thử nghiệm có thể được định nghĩa theo nhiều cách khác nhau. Một trong những cách phổ biến nhất là kỹ thuật chọn thử nghiệm. Kỹ thuật này liên quan đến việc chọn các trường hợp thử nghiệm phù hợp để kiểm tra phần mềm. Điều này giúp đảm bảo rằng phần mềm hoạt động đúng và không có lỗi. Ngoài ra, kỹ thuật này còn giúp tiết kiệm thời gian và nguồn lực trong quá trình thử nghiệm. Nói cách khác, kỹ thuật chọn thử nghiệm là một phần quan trọng của quá trình thiết kế thử nghiệm, giúp đảm bảo rằng phần mềm được kiểm tra một cách hiệu quả và chính xác.

Để đánh giá hiệu quả của quá trình kiểm thử, chúng ta cần thực hiện một số nhiệm vụ quan trọng. Trong đó, đo lường và phân tích kết quả là một trong những nhiệm vụ chính của việc triển khai và thực hiện kiểm thử. Quá trình này giúp chúng ta xác định được những điểm mạnh và điểm yếu của sản phẩm, từ đó có thể đưa ra những quyết định chính xác để cải thiện nó. Việc đo lường và phân tích kết quả cũng giúp chúng ta xác định được những khu vực cần cải thiện và có thể đề xuất những giải pháp phù hợp để khắc phục những vấn đề đó.

Kỹ thuật kiểm tra loại câu trả lời là il thường được áp dụng trong quá trình kiểm tra thành phần là kiểm tra câu và nhánh. Kỹ thuật này liên quan đến việc kiểm tra từng câu lệnh và nhánh điều khiển trong mã nguồn để đảm bảo chúng hoạt động đúng như mong đợi. Điều này giúp phát hiện ra các lỗi logic và đảm bảo rằng mã nguồn được viết một cách chính xác. Trong quá trình kiểm tra thành phần, việc kiểm tra câu và nhánh là một phần quan trọng để đảm bảo chất lượng của sản phẩm. Nó giúp phát hiện ra các lỗi sớm và tiết kiệm thời gian và nguồn lực trong quá trình phát triển.

Khi chọn phương pháp thử nghiệm, yếu tố quan trọng nhất là sự 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à trước khi quyết định sử dụng một phương pháp thử nghiệm nào đó, bạn cần phải xem xét xem có đủ công cụ, phần mềm và thiết bị cần thiết để hỗ trợ quá trình thử nghiệm hay không. Nếu không có đủ công cụ hỗ trợ, việc triển khai phương pháp thử nghiệm có thể trở nên khó khăn và tốn kém. Vì vậy, việc đánh giá sự có sẵn của công cụ hỗ trợ là bước quan trọng đầu tiên khi chọn phương pháp thử nghiệm.

Lập kế hoạch kiểm thử có các nhiệm vụ chính sau đây. Nhiệm vụ đầu tiên là xác định mục tiêu kiểm thử, bao gồm việc xác định yêu cầu của sản phẩm, xác định các trường hợp sử dụng và xác định các yêu cầu về hiệu suất. Nhiệm vụ thứ hai là lập kế hoạch kiểm thử chi tiết, bao gồm việc xác định các trường hợp kiểm thử, xác định các dữ liệu kiểm thử và xác định các công cụ kiểm thử. Nhiệm vụ thứ ba là lập kế hoạch kiểm thử thực hiện, bao gồm việc xác định các bước kiểm thử, xác định các yêu cầu về môi trường kiểm thử và xác định các yêu cầu về thời gian kiểm thử. Nhiệm vụ thứ tư là đánh giá và cải thiện kế hoạch kiểm thử, bao gồm việc đánh giá hiệu quả của kế hoạch kiểm thử và xác định các điểm cần cải thiện. Theo đó, nhiệm vụ i và nhiệm vụ iv là đúng và nhiệm vụ iii là sai.

Hoạt động đóng gói thử nghiệm là một phần quan trọng của chu trình phát triển phần mềm. Trong hoạt động này, các kỹ sư phần mềm sẽ thực hiện các bước để đảm bảo rằng sản phẩm đã được kiểm tra và thử nghiệm một cách đầy đủ. Các hoạt động đóng gói thử nghiệm bao gồm: - i. Xác định các yêu cầu đóng gói thử nghiệm: Đây là bước đầu tiên trong hoạt động đóng gói thử nghiệm, trong đó các kỹ sư phần mềm sẽ xác định các yêu cầu cần thiết để đóng gói sản phẩm. - ii. Xây dựng kế hoạch đóng gói thử nghiệm: Sau khi xác định các yêu cầu đóng gói thử nghiệm, các kỹ sư phần mềm sẽ xây dựng kế hoạch để thực hiện các hoạt động đóng gói thử nghiệm. - iii. Thực hiện hoạt động đóng gói thử nghiệm: Đây là bước thực hiện các hoạt động đóng gói thử nghiệm theo kế hoạch đã xây dựng. - iv. Đánh giá và cải thiện hoạt động đóng gói thử nghiệm: Cuối cùng, các kỹ sư phần mềm sẽ đánh giá và cải thiện hoạt động đóng gói thử nghiệm để đảm bảo rằng sản phẩm đã được kiểm tra và thử nghiệm một cách đầy đủ. Vì vậy, câu trả lời đúng là "i, ii, iv are true và iii là false".

Quá trình bắt đầu từ các mô-đun cuối cùng được gọi là tích hợp từ trên xuống. Trong quá trình này, các mô-đun cuối cùng được tích hợp vào các mô-đun cao hơn để tạo thành một hệ thống phức tạp hơn. Điều này thường được sử dụng trong các hệ thống lớn và phức tạp, nơi mà các mô-đun cuối cùng cần được tích hợp vào các mô-đun cao hơn để tạo thành một hệ thống toàn diện. Ví dụ, trong một hệ thống tự động hóa, các mô-đun cuối cùng như cảm biến và động cơ cần được tích hợp vào các mô-đun cao hơn như hệ thống điều khiển và giao tiếp để tạo thành một hệ thống tự động hóa toàn diện.

Các loại kiểm tra có liên quan đến việc đánh giá chất lượng phần mềm. Trong đó, kiểm tra tĩnh (static test) là một loại kiểm tra không cần phải chạy chương trình. Nó giúp phát hiện ra các lỗi trong mã nguồn trước khi chương trình được thực thi. Một trong những phương pháp kiểm tra tĩnh phổ biến là kiểm tra mã nguồn bằng mắt (code inspection). Điều này giúp phát hiện ra các lỗi logic, lỗi syntax và các vấn đề khác trong mã nguồn mà không cần phải chạy chương trình. Vì vậy, trong các lựa chọn trên, kiểm tra mã nguồn bằng mắt (code inspection) là một phương pháp kiểm tra tĩnh.

Mục đích của đánh giá không chính thức là quá trình thảo luận, đưa ra quyết định và giải quyết các vấn đề kỹ thuật. Quá trình này giúp các thành viên trong nhóm hoặc tổ chức chia sẻ ý kiến, kinh nghiệm và kiến thức của mình. Thông qua việc thảo luận, họ có thể tìm ra các giải pháp hiệu quả hơn cho các vấn đề phức tạp. Đánh giá không chính thức cũng giúp xây dựng mối quan hệ và tăng cường sự hợp tác trong nhóm. Nói cách khác, mục đích của đánh giá không chính thức là tạo ra một môi trường học hỏi và phát triển, nơi mọi người có thể chia sẻ và học hỏi từ nhau.

Trong quá trình đánh giá chính thức, người ghi chép lại tất cả các vấn đề, vấn đề và điểm mở được xác định là người ghi chép. Họ chịu trách nhiệm thu thập và ghi lại thông tin, đảm bảo rằng tất cả các vấn đề và điểm mở được ghi lại một cách chính xác và đầy đủ. Người ghi chép đóng vai trò quan trọng trong việc đảm bảo rằng tất cả các vấn đề và điểm mở được xem xét và giải quyết một cách hiệu quả.

Người chịu trách nhiệm dẫn dắt quá trình xem xét tài liệu, lên kế hoạch cho quá trình xem xét, điều hành cuộc họp và theo dõi sau cuộc họp được gọi làModerator. Họ là người có vai trò quan trọng trong việc đảm bảo quá trình xem xét diễn ra một cách hiệu quả và có kết quả tốt. Họ sẽ lên kế hoạch cho cuộc họp, mời các thành viên tham gia, điều hành cuộc họp và theo dõi tiến độ sau cuộc họp. Mục tiêu của họ là đảm bảo rằng tài liệu được xem xét một cách kỹ lưỡng và có kết quả tốt.