Ôn tập cuối kỳ SWT301 Summer 2024

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

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

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.

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

Để 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ử.

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.

Khi báo cáo lỗi phát hiện cho các nhà phát triển, các kiểm thử viên nên thể hiện sự tôn trọng và chuyên nghiệp. Điều này có nghĩa là họ nên trình bày các lỗi một cách rõ ràng, cụ thể và hữu ích. Họ nên tránh sử dụng ngôn ngữ tiêu cực hoặc gây phẫn nộ, mà thay vào đó, họ nên tập trung vào việc giải quyết vấn đề. Điều này sẽ giúp các nhà phát triển hiểu rõ hơn về lỗi và có thể giải quyết nó một cách hiệu quả hơn. Ngoài ra, các kiểm thử viên cũng nên tránh việc tranh cãi hoặc gây mâu thuẫn với các nhà phát triển, vì điều này có thể gây ra sự bất đồng và làm chậm quá trình phát triển.

Để xây dựng một kế hoạch kiểm tra, các đầu vào quan trọng được lấy từ kế hoạch dự án. Kế hoạch dự án cung cấp thông tin chi tiết về mục tiêu, phạm vi, thời gian và ngân sách của dự án. Điều này giúp cho việc xây dựng kế hoạch kiểm tra trở nên rõ ràng và hiệu quả hơn. Ngoài ra, kế hoạch dự án cũng cung cấp thông tin về các yêu cầu chức năng và không chức năng của dự án, giúp cho việc xác định các trường hợp kiểm tra trở nên dễ dàng hơn. Vì vậy, kế hoạch dự án là nguồn thông tin quan trọng để xây dựng kế hoạch kiểm tra.

Khi nào bạn nên dừng thử nghiệm? Trả lời này liên quan đến việc xác định điều kiện kết thúc thử nghiệm. Có một số yếu tố cần xem xét khi quyết định khi nào nên dừng thử nghiệm. Thứ nhất, bạn có thể dừng thử nghiệm khi đã tìm thấy số lượng lỗi được chỉ định. Tuy nhiên, phương pháp này có thể không hiệu quả vì nó không đảm bảo rằng tất cả các lỗi đã được phát hiện. Thứ hai, bạn có thể dừng thử nghiệm khi đã đạt được các tiêu chí hoàn thành thử nghiệm. Điều này có nghĩa là bạn đã thực hiện tất cả các bước cần thiết để đảm bảo rằng sản phẩm hoặc hệ thống đã được kiểm tra đầy đủ. Thứ ba, bạn có thể dừng thử nghiệm khi đã hoàn thành tất cả các thử nghiệm có ưu tiên cao và trung bình. Tuy nhiên, phương pháp này có thể không hiệu quả vì nó không đảm bảo rằng tất cả các thử nghiệm quan trọng đã được thực hiện. Cuối cùng, bạn có thể dừng thử nghiệm khi đã thực hiện tất cả các câu lệnh. Tuy nhiên, phương pháp này không phải lúc nào cũng khả thi vì nó có thể không thể thực hiện được trong một số trường hợp. Tóm lại, phương pháp tốt nhất để dừng thử nghiệm là khi đã đạt được các tiêu chí hoàn thành thử nghiệm.

Khi đánh giá một sản phẩm phần mềm, mục tiêu chính là xác định các lỗi hoặc sai sót trong sản phẩm đó. Điều này bao gồm việc kiểm tra các tài liệu, mã nguồn và các sản phẩm khác liên quan đến phần mềm để đảm bảo chúng đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra. Mục tiêu này giúp phát hiện ra các vấn đề tiềm ẩn và cải thiện chất lượng của phần mềm. Việc xác định các lỗi hoặc sai sót cũng giúp cho việc sửa chữa và cải thiện phần mềm trở nên hiệu quả hơn.

Để trả lời câu hỏi này, chúng ta cần xem xét các điều kiện và hành động liên quan đến việc nâng cấp phòng. Thứ nhất, chúng ta cần xác định loại thành viên và loại phòng mà khách hàng đang sở hữu. Trong trường hợp này, chúng ta có hai loại thành viên: thành viên Citibank và thành viên không phải là thành viên Citibank. Loại phòng cũng có hai loại: Silver và Platinum. Tiếp theo, chúng ta cần xem xét các hành động liên quan đến việc nâng cấp phòng. Đối với thành viên Citibank sở hữu phòng Silver, chúng ta không thể nâng cấp phòng. Đối với thành viên không phải là thành viên Citibank sở hữu phòng Platinum, chúng ta có thể nâng cấp phòng lên Gold. Đối với thành viên Citibank sở hữu phòng Platinum, chúng ta không thể nâng cấp phòng. Đối với thành viên không phải là thành viên Citibank sở hữu phòng Silver, chúng ta không thể nâng cấp phòng. Tóm lại, để trả lời câu hỏi này, chúng ta cần xem xét các điều kiện và hành động liên quan đến việc nâng cấp phòng và dựa trên đó đưa ra quyết định phù hợp.

Theo ISTQB Glossary, rủi ro liên quan đến những hậu quả tiêu cực có thể xảy ra. Trong quá trình kiểm thử, rủi ro thường được định nghĩa là những hậu quả tiêu cực có thể xảy ra trong quá trình kiểm thử hoặc sau khi kiểm thử. Điều này giúp cho các nhà kiểm thử có thể dự đoán và chuẩn bị cho những tình huống xấu có thể xảy ra. Ví dụ, rủi ro có thể bao gồm việc mất dữ liệu quan trọng, lỗi hệ thống hoặc chậm trễ trong quá trình triển khai. Việc nhận biết và đánh giá rủi ro là một phần quan trọng trong quá trình kiểm thử để đảm bảo rằng các sản phẩm hoặc dịch vụ được kiểm thử một cách đầy đủ và hiệu quả.

Một công cụ thực thi thử nghiệm thương mại điển hình có thể thực hiện tất cả các lựa chọn sau EXCEPT: Công cụ thực thi thử nghiệm thương mại điển hình thường được sử dụng để tự động hóa quá trình thử nghiệm, giúp giảm thời gian và tăng hiệu suất. Lựa chọn "Tạo ra đầu ra dự kiến" không phải là một chức năng cơ bản của công cụ thực thi thử nghiệm thương mại điển hình. Thay vào đó, công cụ này thường được sử dụng để thực hiện các chức năng như: - Lặp lại đầu vào theo một kịch bản lập trình sẵn - So sánh kết quả dự kiến với kết quả thực tế - Lưu trữ đầu vào thử nghiệm - Đọc giá trị thử nghiệm từ tệp dữ liệu Do đó, lựa chọn "Tạo ra đầu ra dự kiến" không phải là một chức năng cơ bản của công cụ thực thi thử nghiệm thương mại điển hình.

Một người có độ tuổi từ 1 đến 99, chúng ta cần sử dụng BVA (Binary Variable Association) để xác định giá trị phù hợp. BVA là một kỹ thuật thống kê giúp phân tích mối quan hệ giữa các biến số. Trong trường hợp này, chúng ta cần tìm giá trị phù hợp cho độ tuổi của người đó. Giá trị 0 không phải là độ tuổi hợp lệ, vì vậy chúng ta cần loại bỏ nó. Giá trị 100 không phải là độ tuổi hợp lệ, vì độ tuổi chỉ có thể từ 1 đến 99. Do đó, giá trị phù hợp cho độ tuổi của người đó là 1, 2, 99.

Sự chuyển giao tài liệu kiểm thử (SSSR Handover of Testware) là một phần của giai đoạn phân tích và thiết kế kiểm thử. Trong giai đoạn này, các kỹ sư kiểm thử sẽ phân tích yêu cầu của sản phẩm, xác định các trường hợp kiểm thử và thiết kế kế hoạch kiểm thử. Sự chuyển giao tài liệu kiểm thử là một phần quan trọng của giai đoạn này, vì nó giúp đảm bảo rằng tất cả các bên liên quan đều hiểu rõ về kế hoạch kiểm thử và tài liệu liên quan. Điều này giúp giảm thiểu sự nhầm lẫn và đảm bảo rằng kiểm thử được thực hiện một cách hiệu quả.

Để bắt đầu tìm kiếm một công cụ thử nghiệm mới, bạn cần phải xác định rõ nhu cầu và yêu cầu của mình. Điều này có nghĩa là bạn cần phải phân tích và xác định rõ những gì bạn cần từ một công cụ thử nghiệm. Bạn cần phải xem xét các yếu tố như tính năng, khả năng sử dụng, chi phí và khả năng tích hợp với các hệ thống khác. Bằng cách phân tích nhu cầu và yêu cầu của mình, bạn sẽ có thể tìm kiếm được một công cụ thử nghiệm phù hợp và hiệu quả. Điều này sẽ giúp bạn tiết kiệm thời gian và nguồn lực trong quá trình tìm kiếm và triển khai công cụ mới.

Để thiết kế thử nghiệm cho các lớp tương đương hợp lệ và biên giới hợp lệ, chúng ta cần xem xét các giá trị có thể xảy ra trong hệ thống kiểm soát tồn kho. Giá trị có thể là các số từ 10000 đến 99999. Trong các lựa chọn trên, chỉ có "10000, 99999" phù hợp với yêu cầu này vì nó bao gồm cả biên giới và lớp tương đương hợp lệ.

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.

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.