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

Trong quá trình phát triển phần mềm, đánh giá (review) đóng vai trò quan trọng trong việc đảm bảo chất lượng sản phẩm. Một trong những lợi ích chính của việc thực hiện đánh giá là xác định các lỗi (đặc biệt là lỗi logic) sớm, từ đó giảm thiểu chi phí tái tạo (rework costs). Khi các lỗi được phát hiện và sửa chữa ngay từ ban đầu, nó giúp giảm thiểu thời gian và chi phí cần thiết để sửa chữa, đồng thời cải thiện độ tin cậy và hiệu suất của sản phẩm. Ngoài ra, việc đánh giá cũng giúp các nhà phát triển hiểu rõ hơn về yêu cầu của khách hàng và cải thiện khả năng giao tiếp trong nhóm.

Để đánh giá độ chính xác của các câu hỏi trên, chúng ta cần xem xét các trường hợp thử nghiệm cần thiết để đạt được sự bao phủ tối thiểu về câu lệnh và quyết định/kiểm tra điều kiện. Câu lệnh được cung cấp là một đoạn mã với hai câu lệnh IF và một câu lệnh PRINT. Để đạt được sự bao phủ tối thiểu về câu lệnh, chúng ta cần ít nhất một trường hợp thử nghiệm để thực hiện cả hai câu lệnh IF và câu lệnh PRINT. Điều này có nghĩa là chúng ta cần ít nhất một trường hợp thử nghiệm để đạt được sự bao phủ tối thiểu về câu lệnh. Đối với sự bao phủ tối thiểu về quyết định/kiểm tra điều kiện, chúng ta cần ít nhất hai trường hợp thử nghiệm: một trường hợp thử nghiệm để kiểm tra điều kiện IF A+B > 50 và một trường hợp thử nghiệm để kiểm tra điều kiện IF B > 20. Vì vậy, để đạt được sự bao phủ tối thiểu về cả câu lệnh và quyết định/kiểm tra điều kiện, chúng ta cần ít nhất một trường hợp thử nghiệm cho câu lệnh và hai trường hợp thử nghiệm cho quyết định/kiểm tra điều kiện.

Quá trình đánh giá chính thức thông thường bao gồm năm bước chính. Để xác định trình tự đúng, chúng ta cần xem xét từng bước một. Bước đầu tiên là Planning, đây là bước lập kế hoạch cho quá trình đánh giá. Sau đó, bước tiếp theo là Individual review, đây là bước đánh giá cá nhân. Tiếp theo là Initiate review, đây là bước khởi động quá trình đánh giá. Sau đó là Issue communication & Analysis, đây là bước truyền thông và phân tích vấn đề. Cuối cùng là Fixing & Reporting, đây là bước sửa chữa và báo cáo. Vì vậy, trình tự đúng là Planning -> Individual review -> Initiate review -> Issue communication & Analysis -> Fixing & Reporting.

Mục tiêu chính của kiểm thử tĩnh là đánh giá chất lượng phần mềm mà không cần thực hiện kiểm thử chức năng. Kiểm thử tĩnh bao gồm việc xem xét các tài liệu và mã nguồn của phần mềm mà không cần thực hiện kiểm thử chức năng. Điều này giúp phát hiện các lỗi và sai sót trong mã nguồn và tài liệu trước khi phần mềm được triển khai. Kiểm thử tĩnh giúp đảm bảo rằng phần mềm được xây dựng dựa trên các yêu cầu và yêu cầu chức năng chính xác, từ đó giúp giảm thiểu các lỗi và sai sót trong phần mềm.

Quá trình đánh giá sản phẩm công việc (Work Product Review) là một phần quan trọng trong quản lý chất lượng sản phẩm. Dưới đây là một số bước chính trong quá trình này: Khởi động đánh giá - Chọn người đánh giá - Đánh giá cá nhân - Phân tích và giải quyết vấn đề - Chỉnh sửa lại. Quá trình này giúp đảm bảo rằng sản phẩm công việc đáp ứng các yêu cầu và tiêu chuẩn chất lượng.

Trong một đánh giá chính thức, các vai trò sau đây thường được tham gia: - Nhà phát triển (Developer): chịu trách nhiệm về chất lượng và hiệu suất của sản phẩm. - Người điều hành (Moderator): đảm bảo quá trình đánh giá diễn ra suôn sẻ và công bằng. - Lãnh đạo đánh giá (Review leader): chịu trách nhiệm tổng thể về quá trình đánh giá và đảm bảo các tiêu chí đánh giá được thực hiện. - Đánh giá viên (Reviewer): đánh giá sản phẩm dựa trên các tiêu chí đã được xác định. - Kỹ sư kiểm thử (Tester): kiểm tra sản phẩm để đảm bảo nó hoạt động đúng như mong đợi. Vậy, các vai trò trong một đánh giá chính thức bao gồm: Nhà phát triển, Người điều hành, Lãnh đạo đánh giá, Đánh giá viên và Kỹ sư kiểm thử.

Static testing trong phát triển phần mềm giúp kiểm tra mã nguồn trước khi thực hiện các hoạt động khác. Nó giúp giảm thiểu các lỗi và cải thiện chất lượng phần mềm. Tuy nhiên, một trong những lợi ích không chính xác của static testing là cải thiện giao tiếp giữa các thành viên trong đội ngũ trong quá trình tham gia các đánh giá. Thực tế, static testing không trực tiếp cải thiện giao tiếp giữa các thành viên trong đội ngũ. Thay vào đó, nó giúp giảm thiểu các lỗi và cải thiện chất lượng phần mềm, từ đó giúp đội ngũ phát triển phần mềm làm việc hiệu quả hơn.

Một walkthrough là một quá trình đánh giá kỹ lưỡng và chi tiết về một sản phẩm, dự án hoặc quy trình. Mục đích chính của walkthrough là giáo dục người tham gia và thu thập phản hồi. Quá trình này giúp người tham gia hiểu rõ hơn về sản phẩm, dự án hoặc quy trình, đồng thời có cơ hội đóng góp ý kiến và đề xuất cải thiện. Thông qua walkthrough, người tham gia có thể nhận được thông tin chi tiết về các tính năng, chức năng, và quy trình hoạt động của sản phẩm, dự án hoặc quy trình. Điều này giúp người tham gia có thể đưa ra ý kiến và đề xuất một cách có căn cứ và hiệu quả.

Để xác định ứng dụng đáp ứng được các yêu cầu kinh doanh, chúng ta cần thực hiện các bài kiểm tra ở mức nào? Câu trả lời đúng là Acceptance testing. Acceptance testing là quá trình kiểm tra cuối cùng để xác minh ứng dụng đáp ứng được các yêu cầu kinh doanh và các yêu cầu chức năng. Quá trình này thường được thực hiện bởi người dùng cuối hoặc người quản lý dự án. Trong Acceptance testing, các yêu cầu kinh doanh sẽ được kiểm tra một cách chi tiết để đảm bảo rằng ứng dụng đáp ứng được tất cả các yêu cầu. Điều này giúp đảm bảo rằng ứng dụng sẽ hoạt động đúng và đáp ứng được nhu cầu của người dùng.

Integration testing (thử nghiệm tích hợp) là một loại thử nghiệm phần mềm được sử dụng để kiểm tra các giao diện giữa các thành phần, tương tác giữa các phần khác nhau của hệ thống như hệ điều hành, hệ thống tệp và phần cứng hoặc giao diện giữa các hệ thống. Mục tiêu của thử nghiệm tích hợp là đảm bảo rằng các thành phần khác nhau của hệ thống hoạt động đúng và tương tác với nhau một cách chính xác. Điều này giúp phát hiện ra các lỗi và sai sót trong hệ thống và đảm bảo rằng hệ thống hoạt động một cách ổn định và hiệu quả. Thử nghiệm tích hợp thường được thực hiện sau khi các thành phần riêng lẻ đã được thử nghiệm và chứng minh là hoạt động đúng.

So sánh giữa usability testing và performance testing là một phần quan trọng trong việc đánh giá chất lượng của một hệ thống. Usability testing tập trung vào tính dễ sử dụng của hệ thống, tức là hệ thống có dễ dàng sử dụng và hiểu được không. Trong khi đó, performance testing đo lường khả năng hoạt động của hệ thống, bao gồm tốc độ tải, dung lượng lưu trữ và khả năng xử lý. Điều này có nghĩa là usability testing nhằm mục đích cải thiện trải nghiệm người dùng, trong khi performance testing nhằm mục đích đảm bảo hệ thống có thể hoạt động một cách ổn định và hiệu quả. Vì vậy, hai loại thử nghiệm này có mục tiêu và phạm vi khác nhau.

Mức độ kiểm tra tập trung vào các đơn vị hoặc thành phần riêng lẻ. Trong quá trình phát triển phần mềm, việc kiểm tra từng thành phần nhỏ (đơn vị) là rất quan trọng. Điều này giúp đảm bảo rằng mỗi thành phần nhỏ đều hoạt động đúng và không có lỗi. Mục tiêu của kiểm tra đơn vị là xác định xem từng thành phần nhỏ có đáp ứng yêu cầu hay không. Nói cách khác, kiểm tra đơn vị là quá trình kiểm tra từng phần nhỏ của hệ thống để đảm bảo rằng nó hoạt động chính xác và không có lỗi.

Một phần mềm ứng dụng thường bao gồm nhiều tính năng và chức năng khác nhau. Để đảm bảo rằng phần mềm hoạt động đúng như mong đợi, các nhà phát triển cần thực hiện các thử nghiệm để kiểm tra tính năng và chức năng của phần mềm. Một tập hợp các thử nghiệm được gọi là "A" bao gồm các thử nghiệm trường hợp (test case) để kiểm tra tính năng và chức năng của phần mềm từ đầu đến cuối. Các thử nghiệm trường hợp này giúp đảm bảo rằng phần mềm hoạt động đúng và không có lỗi. Vì vậy, "A" bao gồm các thử nghiệm trường hợp (test case) để kiểm tra tính năng và chức năng của phần mềm.

Xác thực thử nghiệm là một bước quan trọng trong quy trình kiểm thử phần mềm. Mục đích của xác thực thử nghiệm là xác minh rằng các lỗi đã được sửa chữa và không có lỗi mới được tạo ra trong quá trình sửa chữa. Điều này có thể được thực hiện bằng cách thực hiện lại các thử nghiệm để xác nhận rằng lỗi đã được sửa chữa đúng cách. Ngoài ra, xác thực thử nghiệm còn giúp xác minh rằng các thay đổi trong phần mềm hoặc môi trường không gây ra các tác dụng phụ không mong muốn và hệ thống vẫn đáp ứng được các yêu cầu của nó.

Boundary Value Analysis (BVA) là một phương pháp mở rộng của kỹ thuật nào? Để trả lời câu hỏi này, chúng ta cần hiểu rõ về các kỹ thuật kiểm thử khác nhau. Equivalence Partitioning (EP) là kỹ thuật phân chia dữ liệu thành các phần tương đương, giúp chúng ta kiểm thử các giá trị dữ liệu khác nhau. State Transition Testing (STT) là kỹ thuật kiểm thử các trạng thái chuyển tiếp của hệ thống. Decision Table Testing (DTT) là kỹ thuật kiểm thử dựa trên bảng quyết định, giúp chúng ta kiểm thử các trường hợp khác nhau. Use Case Testing (UCT) là kỹ thuật kiểm thử dựa trên các trường hợp sử dụng, giúp chúng ta kiểm thử các yêu cầu của hệ thống. Boundary Value Analysis (BVA) là kỹ thuật mở rộng của Decision Table Testing (DTT), giúp chúng ta kiểm thử các giá trị dữ liệu ở ranh giới của các phần tương đương.

Hoạt động đóng test trong một dự án phần mềm có mục đích đánh giá và phân tích kết quả của quá trình kiểm thử. Mục đích chính là phân tích những gì đã được thực hiện và những gì có thể được cải thiện cho các dự án tương lai. Điều này giúp các nhà phát triển và quản lý dự án nhận ra những điểm mạnh và điểm yếu của quá trình kiểm thử, từ đó có thể điều chỉnh và cải thiện quy trình kiểm thử cho các dự án tiếp theo. Ngoài ra, hoạt động đóng test cũng giúp xác định những gì đã đạt được và những gì còn cần cải thiện, giúp cho việc lập kế hoạch và quản lý dự án trở nên hiệu quả hơn.

Thử nghiệm liên quan đến thay đổi bao gồm các loại thử nghiệm sau: Confirmation và regression testing. Confirmation testing là quá trình kiểm tra lại các yêu cầu chức năng đã được xác nhận trước đó để đảm bảo chúng vẫn hoạt động đúng sau khi thay đổi. Regression testing là quá trình kiểm tra lại các yêu cầu chức năng đã được xác nhận trước đó để đảm bảo chúng không bị ảnh hưởng bởi các thay đổi khác.

Vai trò quan trọng của phân tích tác động trong kiểm tra bảo trì là giúp xác định cách các thay đổi có thể ảnh hưởng đến các thành phần của hệ thống hiện có. Điều này bao gồm việc đánh giá tác động của các thay đổi đối với hiệu suất, tính ổn định và khả năng tương thích của hệ thống. Phân tích tác động giúp các kỹ sư bảo trì xác định các rủi ro tiềm ẩn và thực hiện các biện pháp phòng ngừa để tránh các vấn đề có thể xảy ra. Nó cũng giúp họ xác định các khu vực cần cải thiện và tối ưu hóa hệ thống để đảm bảo rằng nó hoạt động một cách hiệu quả và ổn định.

Kỹ thuật kiểm thử tĩnh (static testing) là một phương pháp kiểm thử phần mềm mà không cần thực hiện chương trình. Trong đó, kỹ thuật "Error guessing" là một phương pháp kiểm thử tĩnh phổ biến. Kỹ thuật này dựa trên kinh nghiệm và kiến thức của người kiểm thử để đoán lỗi tiềm ẩn trong mã nguồn. Người kiểm thử sẽ sử dụng kiến thức về lập trình, thiết kế và các nguyên tắc kiểm thử để tìm kiếm các lỗi tiềm ẩn trong mã nguồn. Kỹ thuật này giúp phát hiện các lỗi sớm và hiệu quả, giảm thiểu thời gian và chi phí phát triển phần mềm.

Các phần đánh giá, đi qua từng bước và kiểm tra là một phần của quá trình nào?