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

Test Conditions là một phần quan trọng trong quy trình kiểm thử phần mềm. Chúng được sử dụng để xác định các tình huống hoặc điều kiện mà phần mềm cần phải đáp ứng. Để tạo ra Test Conditions, chúng ta cần phải tham khảo các tài liệu liên quan, chẳng hạn như Specifications (đặc tả sản phẩm) hoặc Test Cases (kịch bản kiểm thử). Tuy nhiên, Test Conditions không được tạo ra trực tiếp từ Test Cases hoặc Test Data. Thay vào đó, chúng được tạo ra dựa trên các yêu cầu và đặc tả sản phẩm được nêu trong Specifications. Điều này cho phép chúng ta xác định rõ ràng các điều kiện mà phần mềm cần phải đáp ứng và đảm bảo rằng phần mềm hoạt động đúng như mong đợi. Vì vậy, đáp án đúng cho câu hỏi này là Specifications.

Trong quá trình kiểm thử, có bốn quá trình cơ bản được xác định là: Planning and control, Test case development, Test execution và Test closure activities. Planning and control liên quan đến việc lập kế hoạch và kiểm soát quá trình kiểm thử, bao gồm việc xác định mục tiêu, phạm vi và thời gian kiểm thử. Test case development liên quan đến việc tạo ra các trường hợp kiểm thử để kiểm tra sản phẩm. Test execution liên quan đến việc thực hiện các trường hợp kiểm thử đã được tạo ra. Test closure activities liên quan đến việc đóng gói và báo cáo kết quả kiểm thử. Analysis and design là một phần của quá trình phát triển sản phẩm, không phải là một quá trình kiểm thử cơ bản. Vì vậy, Analysis and design không phải là một quá trình kiểm thử cơ bản.

Bắt đầu thiết kế thử nghiệm trong giai đoạn định nghĩa yêu cầu là rất quan trọng để đạt được các mục tiêu thử nghiệm sau. Khi thiết kế thử nghiệm được bắt đầu từ giai đoạn định nghĩa yêu cầu, nó cho phép các nhà phát triển hiểu rõ hơn về yêu cầu của hệ thống và xác định được các trường hợp thử nghiệm quan trọng. Điều này giúp tăng cường sự tự tin vào hệ thống và đảm bảo rằng hệ thống hoạt động đúng như mong đợi. Ngoài ra, thiết kế thử nghiệm trong giai đoạn định nghĩa yêu cầu cũng giúp giảm thiểu các lỗi trong hệ thống và đảm bảo rằng hệ thống được hoàn thiện một cách đầy đủ.

Một thử nghiệm hồi quy (regression test) là một loại thử nghiệm được sử dụng để xác minh rằng các phần của phần mềm chưa được thay đổi vẫn hoạt động bình thường sau khi thực hiện các thay đổi. Mục đích chính của thử nghiệm hồi quy là đảm bảo rằng các phần của phần mềm chưa được thay đổi không bị ảnh hưởng bởi các thay đổi mới. Điều này giúp đảm bảo rằng phần mềm vẫn hoạt động đúng và không có bất kỳ lỗi nào. Thử nghiệm hồi quy thường được thực hiện tự động và được chạy thường xuyên để đảm bảo rằng phần mềm luôn hoạt động tốt.

Để một trường hợp kiểm thử hiệu quả, điều quan trọng nhất là nó phải được thiết kế để phát hiện lỗi nếu có. Điều này có nghĩa là trường hợp kiểm thử phải được tạo ra để kiểm tra xem sản phẩm hoặc phần mềm có hoạt động đúng như mong đợi hay không. Nếu trường hợp kiểm thử không được thiết kế để phát hiện lỗi, thì nó sẽ không thể giúp chúng ta xác định được vấn đề và sửa chữa chúng. Vì vậy, việc thiết kế trường hợp kiểm thử để phát hiện lỗi là bước quan trọng đầu tiên trong quá trình kiểm thử.

Có nhiều rủi ro khi quản lý lịch trình dự án của bạn bằng mô hình tin cậy thống kê. Một số trong số đó bao gồm: Đầu tiên, các nhà kiểm thử có thể dành nhiều năng lượng vào giai đoạn đầu của sản phẩm để tìm kiếm lỗi hơn là chuẩn bị cho việc thực hiện phần còn lại của dự án một cách hiệu quả hơn. Thứ hai, các nhà quản lý có thể không nhận ra rằng nỗ lực kiểm thử không hiệu quả, muộn trong dự án, vì họ dự đoán tỷ lệ tìm kiếm lỗi thấp, vì vậy tỷ lệ thấp đạt được không gây ra sự chú ý cho họ. Cuối cùng, mô hình này có thể tăng áp lực cuối dự án lên các nhà kiểm thử để không tìm thấy lỗi hoặc không báo cáo lỗi. Tất cả các lý do trên đều có thể xảy ra khi sử dụng mô hình tin cậy thống kê để quản lý lịch trình dự án.

Phương pháp kiểm tra được sử dụng để xác minh rằng hệ thống có thể hoạt động đúng khi giới hạn nội bộ của chương trình hoặc hệ thống đã được vượt quá là Stress Testing. Stress Testing là một loại thử nghiệm được thiết kế để đánh giá khả năng chịu đựng của hệ thống khi nó được đặt dưới áp lực cao. Điều này có thể bao gồm việc gửi một lượng lớn dữ liệu vào hệ thống, tạo ra một lượng lớn yêu cầu đồng thời hoặc thử nghiệm hệ thống với các dữ liệu không bình thường. Mục tiêu của Stress Testing là xác minh rằng hệ thống có thể hoạt động đúng ngay cả khi nó được đặt dưới áp lực cao và có thể xử lý được các yêu cầu mà không bị lỗi hoặc gián đoạn.

Maintenance releases và các trung tâm hỗ trợ kỹ thuật là những ví dụ về chi phí chất lượng nào? Chi phí chất lượng là những chi phí mà doanh nghiệp bỏ ra để đảm bảo chất lượng sản phẩm hoặc dịch vụ của mình. Trong đó, chi phí ngăn ngừa (Prevention) là những chi phí mà doanh nghiệp bỏ ra để ngăn ngừa các vấn đề chất lượng xảy ra. Maintenance releases và các trung tâm hỗ trợ kỹ thuật là những ví dụ về chi phí ngăn ngừa vì chúng giúp doanh nghiệp sửa lỗi và cải thiện chất lượng sản phẩm hoặc dịch vụ của mình. Điều này giúp doanh nghiệp tránh được các vấn đề chất lượng và giảm thiểu chi phí sửa lỗi sau này.

Reviewing test Basis là một phần quan trọng trong quá trình phân tích và thiết kế thử nghiệm. Quá trình này giúp đảm bảo rằng các yêu cầu thử nghiệm được xác định rõ ràng và chính xác. Trong quá trình này, các chuyên gia thử nghiệm sẽ xem xét lại các yêu cầu thử nghiệm để đảm bảo rằng chúng phù hợp với mục tiêu và phạm vi thử nghiệm. Họ cũng sẽ xác định các trường hợp thử nghiệm và các yêu cầu thử nghiệm chi tiết hơn. Quá trình này giúp đảm bảo rằng các thử nghiệm được thực hiện một cách hiệu quả và chính xác.

Nếu một thí sinh được cho một bài kiểm tra 40 câu hỏi, cần đạt 25 điểm để đạt yêu cầu (61%) và cần đạt 80% để đạt điểm danh dự. Để tìm lớp tương đương, chúng ta cần xác định các điểm số mà thí sinh đạt được để đạt được điểm danh dự và điểm yêu cầu. Lớp tương đương là tập hợp các điểm số mà thí sinh đạt được để đạt được điểm danh dự hoặc điểm yêu cầu. Trong trường hợp này, các điểm số 23, 24 và 25 là lớp tương đương vì thí sinh đạt được 61% điểm số trong cả ba trường hợp này.

Trong quá trình thực hiện kiểm tra bảo trì, các phương pháp được áp dụng bao gồm cả Breadth Test và Depth Test. Breadth Test là phương pháp kiểm tra toàn bộ phạm vi của sản phẩm hoặc hệ thống, nhằm đảm bảo rằng tất cả các tính năng và chức năng đều hoạt động đúng cách. Depth Test là phương pháp kiểm tra chi tiết từng tính năng hoặc chức năng cụ thể, nhằm đảm bảo rằng chúng hoạt động chính xác và hiệu quả. Việc áp dụng cả hai phương pháp này giúp đảm bảo rằng sản phẩm hoặc hệ thống được bảo trì một cách toàn diện và hiệu quả.

Strategy tích hợp là một phần quan trọng trong quản lý dự án. Có nhiều phương pháp tích hợp khác nhau, bao gồm cả Design based, Big-bang, Bottom-up và Top-down. Tuy nhiên, Design based không phải là một phương pháp tích hợp. Thay vào đó, nó là một phương pháp thiết kế, được sử dụng để tạo ra một bản thiết kế chi tiết cho dự án trước khi bắt đầu triển khai. Big-bang, Bottom-up và Top-down là các phương pháp tích hợp khác nhau, mỗi phương pháp đều có ưu và nhược điểm riêng. Big-bang là một phương pháp tích hợp toàn diện, trong đó tất cả các phần của dự án được tích hợp cùng một lúc. Bottom-up là một phương pháp tích hợp từ dưới lên, trong đó các phần nhỏ của dự án được tích hợp trước và sau đó được kết hợp lại. Top-down là một phương pháp tích hợp từ trên xuống, trong đó các phần lớn của dự án được tích hợp trước và sau đó được chia nhỏ hơn.

Khi phát hiện ra một lỗi trong phần mềm và sửa lỗi đó thì phần mềm cần được thử nghiệm lại để xác nhận rằng lỗi gốc đã được loại bỏ thành công. Điều này được gọi là "xác nhận thử nghiệm". Xác nhận thử nghiệm là một phần quan trọng trong quy trình thử nghiệm phần mềm, giúp đảm bảo rằng phần mềm đã được sửa lỗi một cách hiệu quả và không còn tồn tại lỗi nào khác.

Các công cụ và kỹ thuật được sử dụng trong từng bàn làm việc để tạo ra sản phẩm đầu ra đúng. Trong môi trường làm việc, các công cụ và kỹ thuật đóng vai trò quan trọng trong việc đảm bảo chất lượng và hiệu suất công việc. Chúng giúp nhân viên thực hiện các nhiệm vụ một cách hiệu quả và chính xác. Ví dụ, trong một xưởng sản xuất, các công cụ như máy móc, thiết bị và dụng cụ được sử dụng để tạo ra sản phẩm cuối cùng. Cùng với đó, các kỹ thuật như quy trình sản xuất, kiểm tra chất lượng và bảo trì cũng được áp dụng để đảm bảo sản phẩm đạt tiêu chuẩn.

Mục tiêu thoát (Exit Criteria) có thể bao gồm các yếu tố sau: i. Các chỉ số độ sâu, như độ bao phủ của mã nguồn, tính năng hoặc rủi ro. ii. Các ước tính mật độ lỗi hoặc các chỉ số độ tin cậy. iii. Rủi ro còn lại, chẳng hạn như lỗi chưa được sửa chữa hoặc thiếu độ bao phủ trong một số khu vực. iv. Xác minh môi trường thử nghiệm. Mục tiêu thoát là các tiêu chí để xác định khi nào một dự án hoặc giai đoạn đã đạt được mức độ hoàn thiện mong muốn. Các mục tiêu thoát thường được thiết lập dựa trên các yếu tố như độ bao phủ của mã nguồn, mật độ lỗi và rủi ro còn lại. Trong câu hỏi này, câu trả lời đúng là "iv là đúng và (i, ii, iii) là sai". Điều này có nghĩa là xác minh môi trường thử nghiệm là một phần quan trọng của mục tiêu thoát, trong khi các yếu tố khác không phải là một phần của mục tiêu thoát.

Các cuộc kiểm tra có thể tìm thấy tất cả các lựa chọn sau, trừ khi nào đó. Các cuộc kiểm tra có thể phát hiện các biến không được định nghĩa trong mã, các lỗi chính tả và ngữ pháp trong tài liệu, các yêu cầu đã bị bỏ qua từ các tài liệu thiết kế. Tuy nhiên, chúng không thể tìm thấy được mức độ bao phủ của mã. Mức độ bao phủ của mã không thể được kiểm tra bằng các cuộc kiểm tra, mà phải được thực hiện thông qua các phương pháp khác như chạy thử nghiệm, phân tích tĩnh và phân tích động. Các phương pháp này có thể giúp xác định được mức độ bao phủ của mã và phát hiện các khu vực chưa được kiểm tra.

Kỹ thuật kiểm thử tĩnh là một phần quan trọng trong quá trình kiểm thử phần mềm. Trong đó, các kỹ thuật như Error guessing, Walkthrough, và Inspections đều là các kỹ thuật kiểm thử tĩnh. Error guessing là kỹ thuật dựa trên kinh nghiệm và kiến thức của kiểm thử viên để đoán lỗi có thể xảy ra. Walkthrough là kỹ thuật kiểm thử tĩnh bằng cách đi qua mã nguồn và kiểm tra các đoạn mã có thể gây ra lỗi. Inspections là kỹ thuật kiểm thử tĩnh bằng cách xem xét và đánh giá mã nguồn để tìm kiếm các lỗi. Tuy nhiên, Data flow analysis là một kỹ thuật kiểm thử tĩnh khác, nhưng nó không phải là một trong những kỹ thuật được liệt kê ở trên. Vì vậy, câu trả lời đúng là Data flow analysis.

Regression testing nên được thực hiện trong các trường hợp sau: Mỗi tuần, Sau khi phần mềm đã thay đổi, Nhiều nhất có thể, Khi môi trường đã thay đổi, Khi người quản lý dự án cho phép. Mỗi một trong những trường hợp trên đều có lý do hợp lý để thực hiện regression testing. Ví dụ, nếu phần mềm đã thay đổi, thì cần phải kiểm tra lại để đảm bảo rằng những thay đổi đó không ảnh hưởng đến các chức năng hiện có. Nếu môi trường đã thay đổi, thì cũng cần phải kiểm tra lại để đảm bảo rằng phần mềm vẫn hoạt động đúng như mong đợi. Việc thực hiện regression testing thường xuyên sẽ giúp phát hiện ra các lỗi sớm và giảm thiểu thời gian và chi phí để sửa lỗi.

Khái niệm mức độ nghiêm trọng (severity) và mức độ ưu tiên (priority) trong kiểm thử phần mềm thường được nhầm lẫn với nhau. Tuy nhiên, chúng có ý nghĩa khác nhau. Mức độ nghiêm trọng của một lỗi (defect) ám chỉ tầm quan trọng của nó đối với người dùng cuối, trong khi mức độ ưu tiên của một lỗi phản ánh tác động của nó lên đội ngũ phát triển. Ví dụ, một lỗi nghiêm trọng có thể không ảnh hưởng đến trải nghiệm người dùng, nhưng lại gây khó khăn cho đội ngũ phát triển. Ngược lại, một lỗi có mức độ ưu tiên cao có thể không nghiêm trọng, nhưng lại cần được sửa chữa ngay lập tức để tránh ảnh hưởng đến kế hoạch phát triển. Do đó, việc hiểu rõ sự khác biệt giữa mức độ nghiêm trọng và mức độ ưu tiên là rất quan trọng để đảm bảo rằng các lỗi được sửa chữa một cách hiệu quả và kịp thời.