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

Để đánh giá độ chính xác của mã nguồn, chúng ta cần xác định số lượng thử nghiệm tối thiểu để đạt được sự bao phủ đầy đủ về câu lệnh và nhánh. Mã nguồn được cung cấp là một đoạn mã pseudo-code với các câu lệnh và điều kiện logic. Để đạt được sự bao phủ đầy đủ về câu lệnh, chúng ta cần thực hiện ít nhất 2 thử nghiệm. Thử nghiệm đầu tiên sẽ đọc giá trị của A và B, sau đó thực hiện câu lệnh IF A-B > 50. Thử nghiệm thứ hai sẽ đọc giá trị của B và thực hiện câu lệnh IF B > 10. Để đạt được sự bao phủ đầy đủ về nhánh, chúng ta cần thực hiện thêm 1 thử nghiệm nữa. Thử nghiệm này sẽ đọc giá trị của A và B, sau đó thực hiện cả hai câu lệnh IF A-B > 50 và IF B > 10. Vì vậy, số lượng thử nghiệm tối thiểu để đạt được sự bao phủ đầy đủ về câu lệnh và nhánh là 2 thử nghiệm cho câu lệnh và 2 thử nghiệm cho nhánh.

Kỹ thuật hộp trắng có mục tiêu chính là đảm bảo mỗi một trong các chi nhánh có thể xảy ra từ mỗi điểm quyết định được thực thi ít nhất một lần. Điều này giúp đảm bảo rằng mã nguồn được kiểm tra một cách đầy đủ và chính xác. Kỹ thuật này được gọi là Branch coverage testing. Nó tập trung vào việc đảm bảo rằng mỗi một quyết định trong mã nguồn đều được kiểm tra một cách đầy đủ, giúp giảm thiểu khả năng xảy ra lỗi.

Vì trường password yêu cầu tối thiểu 8 ký tự và tối đa 12 ký tự, nên các giá trị biên bao gồm 7 ký tự và 13 ký tự. 7 ký tự là giá trị biên thấp nhất vì nó nhỏ hơn 8 ký tự, trong khi 13 ký tự là giá trị biên cao nhất vì nó lớn hơn 12 ký tự. Các giá trị 8 ký tự và 10 ký tự không phải là giá trị biên vì chúng nằm trong khoảng giá trị cho phép.

Kịch bản lý tưởng để sử dụng thử nghiệm khám phá (Exploratory Testing) là khi có thời gian hạn chế và không có các yêu cầu chi tiết. Trong trường hợp này, người kiểm thử không có hướng dẫn cụ thể để thực hiện các thử nghiệm, vì vậy họ phải tự mình khám phá và tìm hiểu về sản phẩm để xác định các lỗi và vấn đề. Điều này đòi hỏi sự sáng tạo, kỹ năng phân tích và khả năng tư duy logic của người kiểm thử. Họ phải tự mình quyết định các trường hợp thử nghiệm, các bước thực hiện và các yếu tố cần kiểm tra. Mục tiêu của thử nghiệm khám phá là tìm ra các lỗi và vấn đề mà các phương pháp thử nghiệm khác có thể bỏ qua.

Decision coverage là một phần quan trọng trong white-box testing. Nó đảm bảo rằng tất cả các nhánh trong điểm quyết định của chương trình đều được thực thi. Điều này giúp phát hiện ra các lỗi hoặc vấn đề tiềm ẩn trong mã nguồn. Khi tất cả các nhánh được thực thi, chúng ta có thể tin tưởng rằng chương trình sẽ hoạt động chính xác và không có lỗi logic. Việc đảm bảo decision coverage giúp cải thiện chất lượng của sản phẩm và giảm thiểu rủi ro khi phát hành. Nó cũng giúp phát hiện ra các vấn đề về bảo mật và đảm bảo rằng chương trình tuân thủ các quy định và tiêu chuẩn.

Các công cụ phân tích tĩnh là một phần quan trọng trong quy trình phát triển phần mềm. Chúng giúp kiểm tra mã nguồn trước khi thực thi, nhằm đảm bảo rằng mã nguồn tuân thủ các tiêu chuẩn lập trình và tránh các lỗi tiềm ẩn. Một trong những đặc điểm chính của các công cụ phân tích tĩnh là khả năng kiểm tra các tiêu chuẩn lập trình. Điều này bao gồm việc kiểm tra mã nguồn để đảm bảo rằng nó tuân thủ các quy tắc lập trình, tránh các lỗi syntax và đảm bảo rằng mã nguồn được viết một cách rõ ràng và dễ đọc. Việc kiểm tra các tiêu chuẩn lập trình giúp cải thiện chất lượng mã nguồn và giảm thiểu thời gian phát triển.

Trong quá trình kiểm thử, có một số mức độ kiểm thử khác nhau. Mức độ kiểm thử mà bạn sẽ kiểm tra các lỗi trong giao diện và tương tác giữa các thành phần tích hợp được gọi là kiểm thử tích hợp. Kiểm thử tích hợp là mức độ kiểm thử cao hơn kiểm thử thành phần, nhưng thấp hơn kiểm thử hệ thống. Mục tiêu chính của kiểm thử tích hợp là đảm bảo rằng các thành phần được tích hợp một cách chính xác và hoạt động như dự kiến. Điều này bao gồm việc kiểm tra giao diện và tương tác giữa các thành phần, cũng như đảm bảo rằng các thành phần hoạt động một cách độc lập và không ảnh hưởng đến nhau.

Để giảm thiểu xung đột tâm lý giữa các tester và developer, chúng ta có thể áp dụng các chiến lược sau đây. Trước hết, chúng ta cần tạo ra một môi trường làm việc tích cực, nơi mà cả tester và developer đều được tôn trọng và đánh giá cao. Điều này có thể được thực hiện thông qua việc tạo ra một văn hóa làm việc thân thiện và tôn trọng lẫn nhau. Thứ hai, chúng ta cần đảm bảo rằng mục tiêu và yêu cầu của quá trình kiểm thử được rõ ràng và dễ hiểu. Điều này sẽ giúp giảm thiểu sự nhầm lẫn và xung đột giữa các bên. Cuối cùng, chúng ta cần khuyến khích sự hợp tác và làm việc cùng nhau trong việc giải quyết các lỗi và vấn đề. Điều này sẽ giúp tăng cường sự hiểu biết và tôn trọng lẫn nhau giữa các tester và developer.

Kết quả kiểm thử cho thấy sự hiện diện của các lỗi. Kiểm thử có thể cho thấy các lỗi đang tồn tại, nhưng không thể chứng minh rằng không có lỗi nào. Kiểm thử giảm khả năng có các lỗi chưa được phát hiện còn tồn tại trong phần mềm, nhưng ngay cả khi không tìm thấy lỗi nào, nó không phải là bằng chứng về sự chính xác. Kiểm thử không thể chứng minh rằng phần mềm hoàn toàn không có lỗi, nhưng nó có thể giúp giảm thiểu số lượng lỗi còn tồn tại. Điều này có nghĩa là, ngay cả khi phần mềm đã được kiểm thử kỹ lưỡng, vẫn có thể có các lỗi chưa được phát hiện. Vì vậy, kiểm thử không phải là một công cụ để chứng minh sự chính xác của phần mềm, mà là một công cụ để giảm thiểu số lượng lỗi và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.

Mô tả về câu trả lời đúng và sai trong câu hỏi này là như sau: Câu trả lời đúng là 'Tests by a person from a different organizational group, such as an independent test team.' Câu trả lời sai là 'Tests by the person who wrote the item under test.', 'Tests by another person within the same team, such as another programmer.', và 'Tests by the person who wrote the source code.' Vì trong quá trình kiểm thử độc lập, người kiểm thử độc lập không phải là người viết mã nguồn hoặc người trong cùng nhóm, mà là một cá nhân độc lập từ nhóm khác.

Khi chúng ta kiểm tra hoặc đánh giá một sản phẩm, mục tiêu chính là tìm kiếm các lỗi hoặc khuyết tật trong sản phẩm. Điều này có nghĩa là chúng ta sẽ đánh giá sản phẩm một cách nghiêm ngặt và tìm kiếm các điểm yếu hoặc vấn đề cần cải thiện. Việc này giúp chúng ta hiểu rõ hơn về sản phẩm và có thể đưa ra các đề xuất hoặc giải pháp để khắc phục các lỗi hoặc khuyết tật đó. Mục tiêu của việc kiểm tra hoặc đánh giá sản phẩm là đảm bảo rằng sản phẩm đáp ứng được các yêu cầu và tiêu chuẩn đã được đặt ra.

Các công cụ thực thi thử nghiệm giúp giảm thiểu thời gian và công sức cần thiết để chạy thử nghiệm lặp lại. Điều này là do các công cụ này cho phép tự động hóa quá trình chạy thử nghiệm, giúp giảm thiểu khả năng con người gây ra lỗi. Ngoài ra, các công cụ này cũng giúp dễ dàng theo dõi và phân tích kết quả thử nghiệm, giúp phát hiện vấn đề nhanh chóng hơn. Vì vậy, việc chạy thử nghiệm lặp lại trở nên dễ dàng hơn nhiều so với trước đây.

Khi sử dụng các kịch bản dựa trên dữ liệu trong tự động hóa thử nghiệm, một lợi ích quan trọng là chúng giúp tách biệt dữ liệu thử nghiệm khỏi kịch bản, từ đó tăng cường tính linh hoạt. Điều này có nghĩa là bạn có thể dễ dàng thay đổi dữ liệu thử nghiệm mà không cần phải chỉnh sửa kịch bản. Ngoài ra, việc tách biệt dữ liệu và kịch bản cũng giúp giảm thiểu sự phụ thuộc vào dữ liệu cụ thể trong kịch bản, từ đó làm cho kịch bản trở nên linh hoạt hơn. Điều này đặc biệt hữu ích khi bạn cần thử nghiệm với nhiều bộ dữ liệu khác nhau. Tóm lại, sử dụng kịch bản dựa trên dữ liệu trong tự động hóa thử nghiệm giúp tăng cường tính linh hoạt và giảm thiểu sự phụ thuộc vào dữ liệu cụ thể.

Mục tiêu của phần tóm tắt trong báo cáo sự cố là cung cấp thông tin tổng quan về sự cố, bao gồm cả mô tả và tác động. Điều này giúp người đọc hiểu rõ về sự cố và có thể đưa ra quyết định phù hợp. Ngoài ra, việc mô tả các bước lặp lại để tái tạo sự cố cũng rất quan trọng, vì nó cho phép người đọc hiểu rõ về nguyên nhân của sự cố và có thể thực hiện các biện pháp khắc phục. Các thông tin này thường được bao gồm trong phần tóm tắt của báo cáo sự cố.

Quản lý sự cố hiệu quả là một phần quan trọng trong việc đảm bảo chất lượng và độ tin cậy của phần mềm. Một trong những lợi ích chính của quản lý sự cố hiệu quả là cải thiện sự hài lòng của khách hàng. Khi các sự cố được xử lý nhanh chóng và hiệu quả, khách hàng sẽ cảm thấy được quan tâm và được hỗ trợ tốt hơn. Điều này có thể dẫn đến sự hài lòng cao hơn và tăng cường độ trung thành của khách hàng. Ngoài ra, quản lý sự cố hiệu quả cũng giúp giảm thiểu thời gian và chi phí cần thiết để giải quyết các vấn đề, từ đó cải thiện hiệu suất và độ tin cậy của phần mềm.

Khi giao tiếp giữa các tester và nhà phát triển không tốt, có thể dẫn đến hiểu lầm và giảm chất lượng phần mềm. Điều này xảy ra khi các tester và nhà phát triển không thể hiểu rõ được yêu cầu và mục tiêu của nhau, dẫn đến việc phát triển phần mềm không đúng như mong đợi. Ngoài ra, giao tiếp kém cũng có thể dẫn đến việc chậm trễ trong quá trình phát triển và thử nghiệm, gây ra sự lãng phí thời gian và nguồn lực. Vì vậy, giao tiếp hiệu quả giữa các tester và nhà phát triển là rất quan trọng để đảm bảo chất lượng phần mềm và giảm thiểu các vấn đề phát sinh.

Người quản lý thử nghiệm thường đảm nhiệm các nhiệm vụ liên quan đến việc tổng hợp và báo cáo kết quả thử nghiệm. Họ sẽ sử dụng thông tin thu thập được trong quá trình thử nghiệm để viết báo cáo tóm tắt thử nghiệm. Điều này bao gồm việc tổng hợp và phân tích kết quả thử nghiệm, cũng như việc xác định các vấn đề và lỗi cần được giải quyết. Người quản lý thử nghiệm cũng có thể tham gia vào việc đánh giá và cải thiện quy trình thử nghiệm để đảm bảo rằng nó hiệu quả và chính xác.

Để cấu trúc một đội kiểm thử cho dự án yêu cầu kiến thức chuyên sâu về quy trình kinh doanh và thực thi kỹ thuật, chúng ta cần cân nhắc kỹ lưỡng. Chọn phương án 'Combine business experts with technical testers' là lựa chọn tốt nhất vì nó kết hợp giữa chuyên gia kinh doanh và kiểm thử viên kỹ thuật. Điều này giúp đội kiểm thử có thể hiểu rõ về quy trình kinh doanh và thực thi kỹ thuật, từ đó tạo ra các kịch bản kiểm thử hiệu quả và chính xác. Phương án này cũng giúp giảm thiểu sai sót và đảm bảo chất lượng sản phẩm cuối cùng.

Quá trình đánh giá sản phẩm công việc là một phần quan trọng trong chuỗi hoạt động của một dự án. Trong quá trình này, các thành viên tham gia đánh giá và thảo luận về sản phẩm công việc đã được tạo ra. Các hoạt động chính của quá trình đánh giá sản phẩm công việc bao gồm: xác định mục tiêu và yêu cầu của sản phẩm, đánh giá chất lượng và hiệu suất của sản phẩm, xác định điểm mạnh và điểm yếu của sản phẩm, đề xuất cải tiến và sửa lỗi, và xác định kế hoạch triển khai sản phẩm. Các hoạt động này giúp đảm bảo rằng sản phẩm công việc đáp ứng được yêu cầu và mục tiêu của dự án, đồng thời giúp cải thiện chất lượng và hiệu suất của sản phẩm.

Rủi ro dựa trên kiểm thử là một phương pháp kiểm thử giúp tối ưu hóa việc kiểm tra bằng cách tập trung vào các khu vực có rủi ro cao. Điều này giúp đảm bảo rằng các khu vực quan trọng nhất của ứng dụng được kiểm tra kỹ lưỡng, giảm thiểu khả năng xảy ra lỗi. Bằng cách tập trung vào các khu vực có rủi ro cao, kiểm thử rủi ro dựa trên giúp tối ưu hóa việc kiểm tra, giảm thiểu thời gian và nguồn lực cần thiết để thực hiện kiểm thử. Điều này cũng giúp đảm bảo rằng các lỗi quan trọng được phát hiện và sửa chữa trước khi ứng dụng được phát hành.