Câu hỏi: SWT301 - Tổng hợp câu hỏi ôn tập

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.

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.

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

Sara, loại kiểm tra nào sau đây là một loại kiểm tra?

Khi thực hiện quản lý cấu hình, các thủ tục cần được triển khai vào giai đoạn đánh giá các tiêu chí kết thúc (exit criteria). Điều này giúp đảm bảo rằng toàn bộ quá trình kiểm thử đã được thực hiện một cách đầy đủ và chính xác. Trong giai đoạn này, các thủ tục quản lý cấu hình sẽ giúp xác định xem liệu các yêu cầu đã được đáp ứng hay chưa, và liệu các kết quả kiểm thử đã đạt được các tiêu chí kết thúc hay chưa. Việc triển khai các thủ tục quản lý cấu hình vào giai đoạn này cũng giúp giảm thiểu các rủi ro và đảm bảo rằng các kết quả kiểm thử được chính xác và đáng tin cậy.

Công cụ quản lý yêu cầu là công cụ lưu trữ các tuyên bố về yêu cầu, kiểm tra tính nhất quán và cho phép ưu tiên các yêu cầu và cho phép các thử nghiệm riêng lẻ có thể theo dõi được đến các yêu cầu, chức năng và tính năng. Công cụ này giúp đảm bảo rằng các yêu cầu được thống nhất và dễ dàng theo dõi trong suốt quá trình phát triển sản phẩm. Nó cũng giúp xác định và ưu tiên các yêu cầu quan trọng nhất, từ đó giúp tối ưu hóa quá trình phát triển và giảm thiểu rủi ro.

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.

Vòng đời của một lỗi (bug) thường được mô tả theo bốn trạng thái chính. Trước tiên, lỗi được mở (Open), khi đó nó được phát hiện và báo cáo. Sau đó, lỗi được gán (Assigned) cho một người phát triển để sửa chữa. Khi người phát triển đã sửa lỗi, trạng thái lỗi sẽ được chuyển sang sửa lỗi (Fixed). Cuối cùng, lỗi được đóng (Closed) khi người dùng xác nhận rằng lỗi đã được sửa chữa thành công. Việc quản lý vòng đời của lỗi giúp đảm bảo rằng lỗi được xử lý một cách hiệu quả và kịp thời.

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

Khi một phần mềm đã được cấp giấy phép, bạn sẽ thực hiện các kiểm tra sau. Trước hết, bạn cần xác định giấy phép đã cấp cho phần mềm có phải là giấy phép mở (Open-source) hay không. Nếu là giấy phép mở, bạn sẽ kiểm tra xem phần mềm có tuân thủ các điều khoản của giấy phép hay không. Điều này bao gồm việc kiểm tra xem phần mềm có được sử dụng miễn phí hay không, có được chia sẻ mã nguồn hay không, và có được sử dụng cho mục đích thương mại hay không. Ngoài ra, bạn cũng cần kiểm tra xem phần mềm có chứa bất kỳ mã độc (malware) nào hay không. Nếu phần mềm không phải là giấy phép mở, bạn sẽ kiểm tra xem phần mềm có được sử dụng hợp pháp hay không, và có được sử dụng cho mục đích thương mại hay không. Cuối cùng, bạn sẽ kiểm tra xem phần mềm có tuân thủ các quy định về bảo mật và bảo vệ thông tin cá nhân hay không.

Các lỗi TF (Faults) được người dùng phát hiện thường là do các nguyên nhân sau: Trước hết, nguyên nhân chính là do phần mềm và quá trình kiểm thử không tốt. Điều này có thể dẫn đến việc lỗi không được phát hiện trong quá trình kiểm thử, từ đó gây ra lỗi khi phần mềm được triển khai. Ngoài ra, một số lỗi TF còn do sự kết hợp của nhiều yếu tố, bao gồm cả yếu tố may mắn. Tuy nhiên, trong thực tế, yếu tố may mắn không phải là nguyên nhân chính gây ra lỗi TF. Vì vậy, để giảm thiểu số lượng lỗi TF, chúng ta cần phải tập trung vào việc phát triển và kiểm thử phần mềm một cách tốt hơn.

Câu hỏi này yêu cầu bạn chọn định nghĩa tốt nhất cho khái niệm Testing. Có bốn lựa chọn khác nhau. Lựa chọn đầu tiên cho rằng mục tiêu của testing là chứng minh chương trình hoạt động. Lựa chọn thứ hai cho rằng mục tiêu của testing là chứng minh chương trình không có lỗi. Lựa chọn thứ ba cho rằng mục tiêu của testing là chứng minh chương trình thực hiện đúng chức năng. Lựa chọn thứ tư cho rằng testing là việc thực thi phần mềm để tìm kiếm lỗi. Trong bốn lựa chọn này, lựa chọn thứ tư là định nghĩa tốt nhất cho khái niệm Testing vì nó tập trung vào việc tìm kiếm lỗi trong phần mềm.

Mục tiêu của một tester phần mềm là tìm kiếm lỗi, tìm kiếm chúng càng sớm càng tốt và đảm bảo chúng được sửa chữa. Điều này giúp tiết kiệm thời gian và chi phí cho quá trình phát triển phần mềm. Khi lỗi được tìm thấy và sửa chữa sớm, nó sẽ giúp cải thiện chất lượng phần mềm và giảm thiểu rủi ro khi đưa sản phẩm ra thị trường. Vì vậy, mục tiêu của một tester phần mềm là tìm kiếm lỗi và đảm bảo chúng được sửa chữa một cách hiệu quả.

Một trường hợp lỗi xảy ra khi nhiều người dùng truy cập vào hệ thống. Điều này có nghĩa là một yêu cầu không chức năng quan trọng đã không được chỉ định và kiểm tra. Trong khi các yêu cầu chức năng thường tập trung vào các tính năng và chức năng của hệ thống, các yêu cầu không chức năng lại tập trung vào các tính chất của hệ thống như hiệu suất, độ tin cậy, khả năng mở rộng, bảo mật, v.v. Trong trường hợp này, trường hợp lỗi xảy ra khi nhiều người dùng truy cập vào hệ thống là một yêu cầu không chức năng quan trọng mà không được chỉ định và kiểm tra. Điều này có thể dẫn đến hệ thống không thể xử lý được số lượng người dùng lớn, gây ra sự cố và ảnh hưởng đến hiệu suất của hệ thống.

Sự cố hệ thống thường xảy ra trong giai đoạn nào? Trong quá trình phát triển phần mềm, giai đoạn yêu cầu (Requirements Phase) là giai đoạn quan trọng và dễ xảy ra sự cố. Đây là giai đoạn nơi các yêu cầu và mục tiêu của dự án được xác định. Nếu không thực hiện đúng, giai đoạn này có thể dẫn đến sự cố hệ thống sau này. Các yêu cầu không rõ ràng, không đầy đủ hoặc không chính xác có thể gây ra sự cố trong giai đoạn thiết kế và phát triển. Do đó, giai đoạn yêu cầu là giai đoạn dễ xảy ra sự cố hệ thống.

Khái niệm re-testing và regression testing thường được sử dụng trong lĩnh vực kiểm thử phần mềm. Re-testing là quá trình chạy lại các thử nghiệm đã thực hiện trước đó để đảm bảo rằng các vấn đề đã được sửa chữa. Trong khi đó, regression testing là quá trình kiểm tra lại các phần mềm đã được sửa chữa để đảm bảo rằng các thay đổi không gây ra các tác động phụ không mong muốn. Cụ thể, re-testing là chạy lại các thử nghiệm một lần nữa, trong khi regression testing tìm kiếm các tác động phụ không mong muốn. Điều này cho thấy rằng re-testing và regression testing có mục đích và phạm vi khác nhau trong quá trình kiểm thử phần mềm.

Mục tiêu thoát (Exit criteria) là một phần quan trọng trong quá trình kiểm thử phần mềm. Nó xác định điều kiện để kết thúc kiểm thử và đảm bảo rằng phần mềm đã đạt được yêu cầu. Một số nhiệm vụ chính của mục tiêu thoát bao gồm: kiểm tra nhật ký kiểm thử so với mục tiêu thoát đã được chỉ định trong kế hoạch kiểm thử, ghi lại kết quả thực hiện kiểm thử, đánh giá xem có cần thêm kiểm thử hay không. Tuy nhiên, viết báo cáo tóm tắt kiểm thử cho các bên liên quan không phải là một nhiệm vụ chính của mục tiêu thoát. Mục tiêu thoát được thiết kế để xác định khi nào kiểm thử nên kết thúc, chứ không phải để tạo ra báo cáo cho các bên liên quan.

Mỗi giai đoạn trong vòng đời phát triển phần mềm cần được khớp với vòng đời kiểm thử như sau: - Giai đoạn thu thập yêu cầu kinh doanh (Business requirements) nên được kiểm thử bằng các bài kiểm thử chấp nhận (Acceptance tests). - Giai đoạn thiết kế tổng quan (High-level design) nên được kiểm thử bằng các bài kiểm thử tích hợp (Integration tests). - Giai đoạn thiết kế chi tiết (Low-level design) nên được kiểm thử bằng các bài kiểm thử đơn vị (Unit tests). - Giai đoạn viết mã (Code) nên được kiểm thử bằng các bài kiểm thử đơn vị (Unit tests). Vậy đáp án đúng là: Integration tests i-c, ii-a, iii-d, iv-b.

Đáp án đúng: A. Khi thời gian và nguồn lực có hạn, kiểm thử phải được ưu tiên theo rủi ro. Hai định hướng đúng là kiểm thử những vùng trọng yếu nhất với quy trình nghiệp vụ (1) và những vùng có khả năng chứa nhiều lỗi nhất (2) - nguyên lý "defect clustering" cho biết lỗi thường dồn vào một số ít mô-đun. Định hướng (3), kiểm thử những chức năng dễ nhất, là sai vì nó tiêu tốn công sức vào phần ít rủi ro và bỏ sót phần nguy hiểm. Vì vậy 1 và 2 đúng, 3 sai, tức phương án A; các phương án còn lại hoặc công nhận (3) hoặc phủ nhận (1), (2) nên đều không đạt.

Đáp án đúng: C. Kiểm thử chỉ nên dừng khi các tiêu chí hoàn thành (test completion criteria / exit criteria) đã được thoả mãn, bởi đó là thước đo khách quan đã thống nhất từ khi lập kế hoạch. Hết thời gian (A) hay chạy xong toàn bộ ca kiểm thử đã lập (B) chỉ là điều kiện hành chính, không nói lên chất lượng sản phẩm. Không tìm thấy lỗi nào (D) càng nguy hiểm vì có thể do bộ ca kiểm thử yếu chứ không phải phần mềm tốt - kiểm thử không chứng minh được sự vắng mặt của lỗi.