Software Testing - SWT301

Poor software characteristics là những đặc điểm không tốt của phần mềm. Điều này có thể bao gồm các yếu tố như độ phức tạp cao, khó bảo trì, không linh hoạt, không tương thích với các hệ thống khác, v.v. Những đặc điểm này có thể gây ra các rủi ro cho cả dự án (project risks) và sản phẩm (product risks). Dự án rủi ro (project risks) có thể bao gồm các vấn đề như thời gian phát triển kéo dài, chi phí cao, thiếu nhân lực, v.v. Sản phẩm rủi ro (product risks) có thể bao gồm các vấn đề như không đáp ứng được yêu cầu của khách hàng, không tương thích với các hệ thống khác, v.v. Vì vậy, poor software characteristics có thể gây ra cả dự án rủi ro và sản phẩm rủi ro.

Use cases là một kỹ thuật được sử dụng để mô tả các tình huống thực tế mà một hệ thống hoặc ứng dụng sẽ được sử dụng. Mục đích của use cases là để xác định các yêu cầu chức năng của hệ thống và đảm bảo rằng nó đáp ứng được nhu cầu của người dùng. Trong quá trình phát triển phần mềm, use cases có thể được sử dụng để thử nghiệm các kịch bản kinh doanh khác nhau, giúp xác định xem hệ thống có đáp ứng được các yêu cầu của người dùng hay không. Điều này bao gồm việc mô tả các hành động của người dùng, các yêu cầu của hệ thống và các kết quả mong đợi. Use cases có thể được sử dụng để thử nghiệm các tình huống khác nhau, chẳng hạn như việc đăng ký tài khoản, thanh toán hóa đơn, hoặc truy cập thông tin cá nhân. Bằng cách sử dụng use cases, các nhà phát triển có thể đảm bảo rằng hệ thống của họ đáp ứng được nhu cầu của người dùng và cung cấp trải nghiệm người dùng tốt hơn.

Các công cụ phân tích tĩnh (static analysis tools) thường được sử dụng bởi cả các nhà thử nghiệm (testers) và các nhà phát triển (developers). Các công cụ này giúp phân tích mã nguồn của ứng dụng hoặc hệ thống để phát hiện ra các lỗi, lỗ hổng bảo mật, và các vấn đề khác mà không cần thực hiện các thử nghiệm hoặc chạy ứng dụng. Các nhà thử nghiệm có thể sử dụng các công cụ phân tích tĩnh để xác định các vấn đề tiềm ẩn trong mã nguồn trước khi ứng dụng được triển khai, trong khi các nhà phát triển có thể sử dụng chúng để cải thiện chất lượng mã nguồn và ngăn chặn các vấn đề trước khi chúng xảy ra. Vì vậy, đáp án đúng là "Testers and Developers".

Alpha testing và System testing thường được thực hiện tại phòng thí nghiệm hoặc môi trường kiểm thử được kiểm soát. Trong khi đó, Field testing được thực hiện tại địa điểm thực tế, nơi mà sản phẩm hoặc hệ thống sẽ được sử dụng. Điều này cho phép kiểm thử viên đánh giá sản phẩm hoặc hệ thống trong môi trường thực tế, bao gồm các yếu tố như thời tiết, thiết bị và người dùng. Field testing giúp xác định các vấn đề và cải thiện sản phẩm hoặc hệ thống trước khi nó được triển khai rộng rãi. Performance testing là một loại kiểm thử khác, tập trung vào việc đánh giá hiệu suất của sản phẩm hoặc hệ thống. Nó không phải là một loại kiểm thử được thực hiện tại địa điểm thực tế.

Câu hỏi này liên quan đến các khái niệm trong quản lý dự án và quy trình làm việc. Trong các workbench, các quy trình và tiêu chuẩn được sử dụng để đảm bảo rằng các sản phẩm đầu ra được sản xuất đúng cách. Các quy trình và tiêu chuẩn này bao gồm các bước cụ thể và các tiêu chí để đánh giá chất lượng của sản phẩm. Chúng giúp đảm bảo rằng các sản phẩm được sản xuất một cách đồng nhất và đáp ứng các yêu cầu của dự án. Các công cụ và kỹ thuật, mặc dù quan trọng, không phải là các yếu tố chính trong việc sản xuất các sản phẩm đầu ra. Các quy trình và tiêu chuẩn là nền tảng của việc sản xuất các sản phẩm đầu ra, vì chúng cung cấp hướng dẫn và tiêu chí để thực hiện các công việc.

Các công cụ và tự động hóa là những công nghệ quan trọng trong nhiều lĩnh vực, bao gồm sản xuất, xây dựng, y tế và nhiều hơn nữa. Các đặc điểm chính của công cụ và tự động hóa là sự kết hợp giữa tốc độ và hiệu suất, cũng như độ chính xác và độ chính xác. Tốc độ và hiệu suất giúp giảm thời gian và chi phí sản xuất, trong khi độ chính xác và độ chính xác giúp đảm bảo chất lượng sản phẩm và giảm thiểu sai sót. Ví dụ, trong sản xuất ô tô, các công cụ tự động hóa giúp tăng tốc độ sản xuất và giảm chi phí, trong khi đảm bảo độ chính xác và độ chính xác của từng bộ phận. Tương tự, trong y tế, các công cụ tự động hóa giúp tăng tốc độ và độ chính xác trong các thủ tục chẩn đoán và điều trị. Do đó, đáp án đúng là "Both Speed/efficiency and Accuracy/precision".

Trong quá trình đánh giá và xem xét một tài liệu, có thể có nhiều người tham gia và đóng vai trò khác nhau. Tuy nhiên, người đứng đầu quá trình đánh giá này được gọi là Moderator. Họ chịu trách nhiệm lập kế hoạch đánh giá, tổ chức cuộc họp và theo dõi tiến trình sau cuộc họp. Moderator đóng vai trò quan trọng trong việc đảm bảo rằng quá trình đánh giá được thực hiện một cách công bằng, hiệu quả và chính xác. Họ cũng có thể giúp giải quyết các vấn đề hoặc tranh chấp có thể phát sinh trong quá trình đánh giá. Ngoài ra, Moderator cũng có thể giúp đảm bảo rằng tất cả các bên liên quan đều được thông báo và tham gia vào quá trình đánh giá.

Integration Level Testing là một loại thử nghiệm được thực hiện để lộ ra các lỗi trong các giao diện và trong tương tác giữa các thành phần tích hợp. Đây là một bước quan trọng trong quá trình thử nghiệm phần mềm, giúp đảm bảo rằng các thành phần khác nhau trong hệ thống hoạt động một cách trơn tru và không có lỗi. Trong Integration Level Testing, các thành phần được tích hợp lại với nhau để tạo thành một hệ thống hoàn chỉnh, sau đó được thử nghiệm để kiểm tra xem chúng có hoạt động đúng như mong đợi hay không. Điều này giúp phát hiện ra các lỗi trong giao diện và tương tác giữa các thành phần, từ đó có thể sửa lỗi và cải thiện chất lượng của hệ thống. Ví dụ, nếu một hệ thống có ba thành phần A, B và C, và chúng cần tương tác với nhau để tạo thành một hệ thống hoàn chỉnh, thì Integration Level Testing sẽ bao gồm việc tích hợp các thành phần này lại với nhau và thử nghiệm hệ thống để kiểm tra xem chúng có hoạt động đúng như mong đợi hay không.

Load Testing là một loại thử nghiệm phần mềm được sử dụng để đánh giá khả năng chịu tải của hệ thống phần mềm. Trong quá trình này, người ta sẽ tạo ra các tải trọng khác nhau lên hệ thống để đo lường và đánh giá các hành vi hiệu suất của nó. Mục đích chính của Load Testing là để đảm bảo rằng hệ thống phần mềm có thể xử lý được số lượng lớn các yêu cầu đồng thời mà không bị quá tải hoặc chậm chạp. Điều này giúp người phát triển phần mềm xác định giới hạn của hệ thống và thực hiện các biện pháp để cải thiện hiệu suất của nó. Load Testing thường được thực hiện trên các hệ thống phần mềm lớn như các ứng dụng web, các hệ thống cơ sở dữ liệu, và các hệ thống mạng.

Test Cases là các trường hợp kiểm thử được nhóm lại thành các đơn vị có thể kiểm soát và lập kế hoạch được gọi là Test Suite. Test Suite là một tập hợp các Test Cases được nhóm lại để kiểm thử một phần hoặc toàn bộ của hệ thống. Mục đích của Test Suite là để kiểm thử các tính năng, chức năng hoặc yêu cầu cụ thể của hệ thống. Test Suite giúp giảm thiểu thời gian và công sức cần thiết để kiểm thử các Test Cases riêng lẻ, đồng thời cũng giúp đảm bảo rằng tất cả các Test Cases quan trọng đều được kiểm thử.

Câu hỏi này liên quan đến khái niệm quản lý và cung cấp thư viện điều khiển (Configuration Control) trong lĩnh vực quản lý cấu hình (Configuration Management). Thư viện điều khiển là một phần quan trọng của quá trình quản lý cấu hình, nơi tất cả các cấu hình quan trọng được lưu trữ và quản lý một cách hệ thống. Mục đích của thư viện điều khiển là cung cấp một nơi trung tâm để lưu trữ, quản lý và theo dõi tất cả các cấu hình quan trọng của một tổ chức hoặc dự án. Điều này giúp đảm bảo rằng các cấu hình được cập nhật và quản lý một cách chính xác, giảm thiểu khả năng xảy ra lỗi hoặc sai sót trong quá trình triển khai và vận hành hệ thống. Thư viện điều khiển cũng giúp cải thiện khả năng theo dõi và quản lý các thay đổi trong cấu hình, giúp tổ chức hoặc dự án có thể dễ dàng theo dõi và quản lý các thay đổi này. Ngoài ra, thư viện điều khiển còn giúp đảm bảo rằng các cấu hình được quản lý một cách an toàn và bảo mật, giảm thiểu khả năng xảy ra các vấn đề về bảo mật.

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.

Quá trình bắt đầu với các mô-đun cuối cùng được gọi là tích hợp từ dưới lên. Trong tích hợp từ dưới lên, các mô-đun cơ bản được xây dựng trước và sau đó được tích hợp lại thành các mô-đun phức tạp hơn. Điều này khác với tích hợp từ trên xuống, nơi các mô-đun phức tạp được xây dựng trước và sau đó được chia nhỏ thành các mô-đun cơ bản hơn. Tích hợp từ dưới lên thường được sử dụng trong các hệ thống phức tạp, nơi các mô-đun cơ bản cần được xây dựng trước để đảm bảo rằng chúng hoạt động chính xác và hiệu quả. Ví dụ, trong một hệ thống điều khiển tự động, các mô-đun cơ bản như cảm biến và động cơ cần được xây dựng trước để đảm bảo rằng chúng hoạt động chính xác và hiệu quả. Sau đó, các mô-đun này có thể được tích hợp lại thành các mô-đun phức tạp hơn như hệ thống điều khiển tự động. Tích hợp từ dưới lên giúp đảm bảo rằng các mô-đun cơ bản hoạt động chính xác và hiệu quả, và sau đó các mô-đun phức tạp hơn có thể được xây dựng dựa trên chúng.

Pha lập kế hoạch (Planning phase) trong một đánh giá chính thức (formal review) là giai đoạn quan trọng giúp đảm bảo rằng đánh giá được thực hiện một cách hiệu quả và chính xác. Trong giai đoạn này, các bên liên quan sẽ thảo luận và quyết định các bước cần thực hiện để đạt được mục tiêu của đánh giá. Một trong những bước quan trọng trong pha lập kế hoạch là việc chọn lựa và phân bổ vai trò cho các thành viên tham gia đánh giá. Điều này giúp đảm bảo rằng mỗi thành viên có trách nhiệm và quyền hạn rõ ràng trong quá trình đánh giá. Việc chọn lựa và phân bổ vai trò cũng giúp đảm bảo rằng đánh giá được thực hiện một cách khách quan và không bị ảnh hưởng bởi các yếu tố cá nhân. Ngoài ra, pha lập kế hoạch cũng giúp xác định mục tiêu và tiêu chí đánh giá, cũng như thời gian và nguồn lực cần thiết để thực hiện đánh giá.

IEEE 829 là tiêu chuẩn cho việc lập hồ sơ kiểm thử phần mềm, trong đó mô tả cấu trúc của báo cáo sự cố. Báo cáo sự cố được gọi là 'Test Incident Report'. Điều này có nghĩa là khi xảy ra một sự cố trong quá trình kiểm thử, người kiểm thử sẽ lập một báo cáo chi tiết về sự cố đó, bao gồm các thông tin như: mô tả sự cố, nguyên nhân, ảnh hưởng, giải pháp, v.v. Cấu trúc của báo cáo sự cố này được quy định trong tiêu chuẩn IEEE 829.

Một công cụ lưu trữ các tuyên bố về yêu cầu, kiểm tra sự nhất quán và cho phép các yêu cầu được ưu tiên và cho phép các thử nghiệm riêng lẻ có thể theo dõi được đến yêu cầu được gọi là công cụ quản lý yêu cầu. Công cụ này giúp các nhà phát triển và quản lý dự án theo dõi và quản lý các yêu cầu của dự án một cách hiệu quả. Nó cho phép các yêu cầu được lưu trữ, kiểm tra sự nhất quán và cho phép các yêu cầu được ưu tiên và theo dõi được đến các thử nghiệm riêng lẻ. Điều này giúp đảm bảo rằng các yêu cầu được thực hiện đúng và các thử nghiệm được thực hiện một cách hiệu quả.

Pha yêu cầu (Requirement phase) 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à xác định và thu thập các yêu cầu của người dùng, xác định phạm vi của dự án và xác định các yêu cầu kỹ thuật cần thiết để triển khai dự án. Trong pha này, các nhà phát triển sẽ làm việc với người dùng để hiểu rõ hơn về nhu cầu và mong muốn của họ, từ đó xác định các yêu cầu chính của dự án. Ngoài ra, pha yêu cầu cũng giúp xác định phạm vi của dự án, bao gồm các tính năng, chức năng và yêu cầu kỹ thuật cần được triển khai. Vì vậy, đáp án đúng là "All of the others", vì pha yêu cầu thực sự bao gồm cả việc hiểu nhu cầu của người dùng, xác định phạm vi của dự án và định nghĩa các yêu cầu kỹ thuật.

Để phát triển một kế hoạch thử nghiệm (test plan), các thông tin đầu vào quan trọng được lấy từ kế hoạch dự án (project plan). 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à nguồn lực của dự án, giúp cho việc lập kế hoạch thử nghiệm trở nên rõ ràng và hiệu quả hơn. Thông tin từ kế hoạch dự án giúp xác định các yêu cầu thử nghiệm, các trường hợp thử nghiệm và các tiêu chí đánh giá hiệu suất của dự án. Ngoài ra, kế hoạch dự án cũng cung cấp thông tin về các rủi ro tiềm ẩn và các biện pháp phòng ngừa, giúp cho việc lập kế hoạch thử nghiệm trở nên toàn diện hơn. Vì vậy, kế hoạch dự án là nguồn thông tin quan trọng và cần thiết cho việc phát triển kế hoạch thử nghiệm.

White Box Techniques là một phương pháp kiểm thử phần mềm tập trung vào việc kiểm tra mã nguồn của chương trình. Phương pháp này cho phép kiểm thử viên có kiến thức về cấu trúc và logic của chương trình, giúp họ xác định các trường hợp kiểm thử hiệu quả hơn. White Box Techniques bao gồm các kỹ thuật như kiểm thử cấu trúc (Structural Testing), kiểm thử dựa trên thiết kế (Design Based Testing), kiểm thử dựa trên kinh nghiệm (Experience Based Technique), nhưng không bao gồm kiểm thử đoán lỗi (Error Guessing Technique).

Trong quá trình phát triển phần mềm, việc sử dụng kết quả phân tích yêu cầu và mô tả yêu cầu như đầu vào để viết mã là một bước quan trọng. Điều này giúp đảm bảo rằng phần mềm đáp ứng được các yêu cầu của người dùng và đáp ứng được các tiêu chuẩn chất lượng. Trong trường hợp này, chúng ta đang nói về việc sử dụng kết quả phân tích yêu cầu và mô tả yêu cầu để viết các trường hợp kiểm thử chấp nhận người dùng (User Acceptance Test Cases). Các trường hợp kiểm thử chấp nhận người dùng là các trường hợp kiểm thử được viết dựa trên yêu cầu của người dùng và được sử dụng để kiểm tra xem phần mềm có đáp ứng được các yêu cầu của người dùng hay không. Điều này giúp đảm bảo rằng phần mềm đáp ứng được các yêu cầu của người dùng và đáp ứng được các tiêu chuẩn chất lượng.