Ôn tập thi lại SWT301 Summer 2024

Các loại kiểm tra trả lời bao gồm Contract và regulation testing là một phần của kiểm tra System testing. Trong quá trình kiểm tra System testing, các nhà phát triển sẽ kiểm tra toàn bộ hệ thống để đảm bảo rằng nó hoạt động đúng như mong đợi. Kiểm tra Contract và regulation testing là một phần quan trọng của quá trình này, giúp đảm bảo rằng hệ thống tuân thủ các hợp đồng và quy định đã được thiết lập.

Đáp án đúng: E. Tiêu chí hoàn thành kiểm thử (test completion criteria, còn gọi là exit criteria) được đưa vào kế hoạch kiểm thử để trả lời câu hỏi KHI NÀO DỪNG kiểm thử: đạt bao nhiêu phần trăm bao phủ, còn bao nhiêu lỗi mức nghiêm trọng, rủi ro tồn đọng ở mức nào. Nhờ đó việc dừng kiểm thử là một quyết định có căn cứ chứ không phải vì hết thời gian hay hết tiền. Phương án A chỉ nói tới việc một phép kiểm thử chạy xong; B là mục tiêu của việc rà soát đặc tả ca kiểm thử; C thuộc kỹ thuật thiết kế dữ liệu đầu vào; D nói về hoàn thành khâu lập kế hoạch, không phải khâu kiểm thử.

Khi thực hiện kiểm thử, việc dừng kiểm thử phụ thuộc vào nhiều yếu tố. Trước hết, nếu tất cả các thử nghiệm đã được thực hiện và không còn thử nghiệm nào cần thực hiện nữa, thì việc kiểm thử có thể được dừng lại. Tuy nhiên, nếu thời gian đã hết và không thể thực hiện thêm thử nghiệm, thì việc kiểm thử cũng cần được dừng lại. Ngoài ra, nếu tất cả các lỗi đã được sửa chữa chính xác và hệ thống đã được kiểm thử đầy đủ, thì việc kiểm thử cũng có thể được dừng lại. Tuy nhiên, điều quan trọng là phải xem xét đến mức độ rủi ro của hệ thống đang được kiểm thử. Nếu hệ thống có mức độ rủi ro cao, thì việc kiểm thử cần được tiếp tục cho đến khi đảm bảo rằng hệ thống đã được kiểm thử đầy đủ và an toàn.

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.

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.

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.

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 đủ.

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.

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.

Integration testing in the large là một phương pháp kiểm thử phần mềm liên quan đến việc kiểm thử hệ thống khi kết hợp với các hệ thống khác. Điều này bao gồm việc kiểm thử các hệ thống độc lập để đảm bảo chúng hoạt động đúng khi được kết hợp với nhau. Phương pháp này thường được sử dụng để kiểm thử các hệ thống phức tạp, bao gồm cả các hệ thống có nhiều thành phần và các hệ thống được kết hợp với các hệ thống khác. Mục tiêu của phương pháp này là đảm bảo rằng các hệ thống được kết hợp hoạt động đúng và không có lỗi khi được sử dụng trong môi trường thực tế. Phương pháp này thường được sử dụng trong các dự án phần mềm lớn và phức tạp, nơi mà việc kiểm thử từng thành phần riêng lẻ không đủ để đảm bảo chất lượng của hệ thống.

Mức độ rủi ro của một sự kiện bất lợi được xác định bởi hai yếu tố chính: khả năng xảy ra sự kiện (likelihood) và tác động của sự kiện (impact). Khả năng xảy ra sự kiện đề cập đến xác suất xảy ra sự kiện, trong khi tác động của sự kiện đề cập đến mức độ ảnh hưởng của sự kiện nếu nó xảy ra. Ví dụ, một sự kiện có khả năng xảy ra cao nhưng tác động thấp có thể không được coi là rủi ro cao. Ngược lại, một sự kiện có khả năng xảy ra thấp nhưng tác động cao có thể được coi là rủi ro cao. Do đó, mức độ rủi ro của một sự kiện được xác định bởi sự kết hợp của hai yếu tố này.

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.

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

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.