Software Testing - SWT301

Quality Assurance (QA) là quá trình so sánh chất lượng sản phẩm với các tiêu chuẩn ứng dụng và thực hiện hành động khi phát hiện ra sự không đáp ứng. Quá trình này giúp đảm bảo rằng sản phẩm đáp ứng các yêu cầu và tiêu chuẩn đã được xác định trước. QA thường bao gồm các bước như xác định tiêu chuẩn chất lượng, kiểm tra và đánh giá sản phẩm, phát hiện và xử lý các vấn đề không đáp ứng, và thực hiện các biện pháp cải thiện chất lượng. Mục tiêu của QA là đảm bảo rằng sản phẩm đáp ứng các tiêu chuẩn chất lượng và đáp ứng nhu cầu của khách hàng. Quá trình này giúp xây dựng niềm tin và uy tín của doanh nghiệp, đồng thời giúp giảm thiểu rủi ro và tăng cường hiệu suất sản xuất. Trong thực tế, QA được áp dụng rộng rãi trong nhiều lĩnh vực như sản xuất, xây dựng, y tế, và công nghệ thông tin.

Verification trong thuật toán và kỹ thuật phần mềm là quá trình kiểm tra và xác minh rằng sản phẩm hoặc phần mềm được xây dựng đúng cách và đáp ứng các yêu cầu chức năng và kỹ thuật. Nó liên quan đến việc đảm bảo rằng sản phẩm hoặc phần mềm hoạt động đúng như dự kiến và không có lỗi. Câu hỏi 'Are we building the product right?' (Chúng ta đang xây dựng sản phẩm đúng cách không?) là một cách thể hiện trực quan của quá trình verification. Nó hỏi rằng liệu chúng ta có đang xây dựng sản phẩm đúng cách hay không, hay liệu chúng ta chỉ đang xây dựng sản phẩm mà không biết liệu nó có đáp ứng các yêu cầu chức năng và kỹ thuật hay không. Quá trình verification thường bao gồm các bước như kiểm tra mã nguồn, kiểm tra chức năng, kiểm tra hiệu suất và kiểm tra bảo mật.

Cyclomatic complexity là một thước đo được sử dụng để đánh giá độ phức tạp của mã nguồn. Nó được định nghĩa là số lượng đường đi khác nhau trong một đoạn mã. Mỗi lần sử dụng một điều kiện kiểm tra (if, else, switch, v.v.) sẽ tăng lên một đơn vị cyclomatic complexity. Điều này có nghĩa là mỗi lần thêm một điều kiện kiểm tra, độ phức tạp của mã sẽ tăng lên một đơn vị. Vì vậy, số lượng kiểm tra cần thiết để kiểm tra tất cả các điều khiển trạng thái sẽ bằng cyclomatic complexity.

Non-functional tests là loại kiểm thử không tập trung vào chức năng cụ thể của hệ thống, mà thay vào đó tập trung vào các thuộc tính khác như hiệu suất, độ tin cậy, bảo mật, v.v. Có nhiều loại non-functional tests khác nhau, bao gồm: - **Performance**: Kiểm thử hiệu suất nhằm đánh giá khả năng xử lý của hệ thống, bao gồm tốc độ, dung lượng, v.v. - **Security**: Kiểm thử bảo mật nhằm đánh giá khả năng bảo vệ của hệ thống trước các cuộc tấn công, bao gồm bảo mật dữ liệu, bảo mật giao tiếp, v.v. - **Usability**: Kiểm thử khả năng sử dụng nhằm đánh giá khả năng dễ sử dụng của hệ thống, bao gồm giao diện người dùng, hướng dẫn sử dụng, v.v. Tuy nhiên, **State-Transition** không phải là một loại non-functional test. Thay vào đó, nó là một loại kiểm thử chức năng, cụ thể là kiểm thử trạng thái chuyển đổi. Kiểm thử trạng thái chuyển đổi nhằm đánh giá khả năng chuyển đổi giữa các trạng thái khác nhau của hệ thống, bao gồm các trạng thái ban đầu, trạng thái trung gian và trạng thái kết thúc. Vì vậy, đáp án đúng là **State-Transition**.

Chọn công cụ phù hợp là một phần quan trọng của quy trình phát triển phần mềm. Nguyên tắc chính cho việc chọn công cụ là đánh giá công cụ dựa trên các yêu cầu rõ ràng và tiêu chí khách quan. Điều này giúp đảm bảo rằng công cụ được chọn phù hợp với nhu cầu và mục tiêu của dự án. Việc đánh giá công cụ dựa trên các yêu cầu rõ ràng và tiêu chí khách quan giúp giảm thiểu khả năng chọn công cụ không phù hợp, từ đó tiết kiệm thời gian và nguồn lực. Ngoài ra, việc đánh giá công cụ dựa trên các yêu cầu rõ ràng và tiêu chí khách quan cũng giúp đảm bảo rằng công cụ được chọn có thể đáp ứng được các yêu cầu và mục tiêu của dự án một cách hiệu quả.

User Acceptance Testing (UAT) là một phần quan trọng của quy trình phát triển phần mềm, đảm bảo rằng sản phẩm đáp ứng được yêu cầu và kỳ vọng của người dùng. Các đặc điểm chính của UAT bao gồm: sử dụng các công cụ kiểm tra tự động hóa, thực hiện kiểm tra bởi người dùng, kiểm tra theo các tiêu chí chấp nhận và tích hợp hệ thống với tài liệu người dùng. Tuy nhiên, không phải tất cả các lựa chọn đều là đặc điểm của UAT. Sử dụng các công cụ kiểm tra tự động hóa không phải là một đặc điểm chính của UAT, vì UAT thường tập trung vào việc kiểm tra và xác minh rằng sản phẩm đáp ứng được yêu cầu và kỳ vọng của người dùng, chứ không phải là sử dụng các công cụ tự động hóa để thực hiện kiểm tra.

Test Plan document là một phần quan trọng của Test Documentation Standard, nó mô tả kế hoạch và quy trình kiểm thử phần mềm. Các thành phần chính của Test Plan document bao gồm: - Test items (i.e. software versions): Đây là phiên bản phần mềm được kiểm thử. - What is not to be tested: Đây là danh sách các phần không được kiểm thử. - Test environments: Đây là môi trường kiểm thử, bao gồm cả phần cứng và phần mềm. Tuy nhiên, Quality plans không phải là một phần của Test Plan document. Quality plans là một tài liệu riêng biệt, mô tả kế hoạch chất lượng phần mềm, bao gồm cả các yêu cầu chất lượng, quy trình kiểm thử và các biện pháp khắc phục khi xảy ra lỗi. Do đó, đáp án đúng là Quality plans.

Static testing là một phương pháp kiểm thử phần mềm không cần thực hiện trên hệ thống đã được triển khai. Nó bao gồm các kỹ thuật như kiểm tra mã nguồn, kiểm tra thiết kế, kiểm tra tài liệu và kiểm tra quy trình. Trong số các kỹ thuật trên, Inspections, Walkthrough và Data flow analysis đều là các kỹ thuật kiểm thử tĩnh. Inspections là quá trình kiểm tra kỹ lưỡng và chi tiết về mã nguồn, Walkthrough là quá trình kiểm tra và đánh giá mã nguồn bằng cách đi qua từng đoạn mã, và Data flow analysis là quá trình kiểm tra luồng dữ liệu trong mã nguồn. Error guessing, mặt khác, là một kỹ thuật kiểm thử động, nơi mà kiểm thử viên sử dụng kinh nghiệm và kiến thức của mình để đoán ra các lỗi tiềm ẩn trong mã nguồn. Vì vậy, Error guessing không phải là một kỹ thuật kiểm thử tĩnh.

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.

Trong lĩnh vực phần mềm, các đặc điểm (characteristics) thường được sử dụng để mô tả các tính chất quan trọng của phần mềm. Các đặc điểm này giúp đánh giá và cải thiện chất lượng của phần mềm. Có bốn đặc điểm chính của phần mềm: Reliability, Usability, Maintainability và Scalability. Trong đó: - Reliability (Đảm bảo): Là khả năng của phần mềm hoạt động đúng và không bị lỗi trong một khoảng thời gian nhất định. - Usability (Sử dụng): Là khả năng của phần mềm dễ sử dụng và dễ hiểu cho người dùng. - Maintainability (Sửa chữa): Là khả năng của phần mềm dễ sửa chữa và cập nhật khi cần thiết. - Scalability (Kích thước): Là khả năng của phần mềm có thể mở rộng hoặc giảm kích thước khi cần thiết. Tuy nhiên, trong danh sách các đặc điểm được đề cập, có một đặc điểm không phải là đặc điểm chính của phần mềm, đó là Development cost (Chi phí phát triển). Chi phí phát triển là một yếu tố quan trọng trong quá trình phát triển phần mềm, nhưng nó không phải là một đặc điểm chính của phần mềm. Chi phí phát triển có thể ảnh hưởng đến chất lượng và hiệu suất của phần mềm, nhưng nó không thể thay thế cho các đặc điểm chính như Reliability, Usability, Maintainability và Scalability.

Câu hỏi trắc nghiệm này liên quan đến các nguyên tắc kiểm thử (testing principle) trong lĩnh vực phát triển phần mềm. Các nguyên tắc kiểm thử là những nguyên tắc cơ bản giúp đảm bảo chất lượng của phần mềm thông qua quá trình kiểm thử. - Early testing: Nguyên tắc này cho rằng nên thực hiện kiểm thử càng sớm càng tốt trong quá trình phát triển phần mềm. Điều này giúp phát hiện và sửa lỗi sớm, giảm thiểu chi phí và thời gian phát triển. - Defect clustering: Nguyên tắc này cho rằng các lỗi thường tập trung vào một số khu vực hoặc module cụ thể của phần mềm. Điều này giúp các nhà phát triển tập trung vào những khu vực này để cải thiện chất lượng phần mềm. - Pesticide paradox: Nguyên tắc này cho rằng việc lặp lại các kiểm thử đã được thực hiện trước đó có thể không hiệu quả trong việc phát hiện lỗi mới. Điều này có thể dẫn đến việc các nhà phát triển trở nên lười biếng trong việc thực hiện kiểm thử. - Exhaustive testing: Nguyên tắc này cho rằng nên thực hiện kiểm thử toàn bộ phần mềm để đảm bảo rằng nó hoạt động chính xác và không có lỗi. Tuy nhiên, việc thực hiện kiểm thử toàn bộ phần mềm là không thể trong thực tế do số lượng các trường hợp kiểm thử có thể xảy ra là vô cùng lớn. Vì vậy, đáp án đúng là "Exhaustive testing". Nguyên tắc này không phải là một nguyên tắc kiểm thử thực sự, mà là một mục tiêu không thể đạt được trong thực tế.

Một tester đen hộp (black box tester) là một chuyên gia kiểm thử phần mềm không cần biết về cấu trúc hoặc mã nguồn của hệ thống. Họ chỉ tập trung vào việc kiểm thử các chức năng và yêu cầu của hệ thống. Vì vậy, không cần thiết phải hiểu được mã nguồn của hệ thống. Thay vào đó, họ sẽ dựa vào các tài liệu chức năng hoặc yêu cầu của hệ thống để thực hiện kiểm thử. Điều này giúp họ có thể kiểm thử hệ thống một cách độc lập và không bị ảnh hưởng bởi các chi tiết kỹ thuật của hệ thống.

Test Plan là một tài liệu quan trọng trong quy trình kiểm thử phần mềm, nó xác định các yêu cầu và mục tiêu của quá trình kiểm thử. Các thành phần chính của Test Plan bao gồm: - Features to be tested: Đây là danh sách các tính năng hoặc yêu cầu cần được kiểm thử. - Environmental needs: Đây là danh sách các yêu cầu về môi trường cần thiết để thực hiện kiểm thử, bao gồm cả phần cứng và phần mềm. - Suspension criteria: Đây là danh sách các điều kiện cần thiết để dừng lại hoặc tạm dừng quá trình kiểm thử. - Expected results: Đây là danh sách các kết quả mong đợi từ quá trình kiểm thử, nhưng nó không phải là một phần của Test Plan. Expected results thường được mô tả trong các tài liệu khác như Test Cases hoặc Test Scripts, chứ không phải là một phần của Test Plan. Test Plan tập trung vào việc xác định các yêu cầu và mục tiêu của quá trình kiểm thử, trong khi Expected results là kết quả mong đợi từ quá trình kiểm thử. Vì vậy, đáp án đúng là "Expected results".

Functional testing và Structural testing là hai loại thử nghiệm phổ biến trong lĩnh vực kiểm thử phần mềm. Functional testing tập trung vào việc kiểm tra các chức năng cụ thể của phần mềm, chẳng hạn như nhập liệu, xuất dữ liệu, tính toán, v.v. Mục tiêu của việc kiểm tra chức năng là đảm bảo rằng phần mềm hoạt động đúng như mong đợi. Structural testing, còn được gọi là kiểm thử cấu trúc, tập trung vào việc kiểm tra các thành phần cấu trúc của phần mềm, chẳng hạn như các hàm, các lớp, các phương thức, v.v. Mục tiêu của việc kiểm tra cấu trúc là đảm bảo rằng phần mềm được xây dựng theo các nguyên tắc tốt nhất và không có lỗi logic. Tuy nhiên, cả hai loại thử nghiệm này đều có hạn chế. Functional testing chỉ kiểm tra các chức năng cụ thể, nhưng không kiểm tra được các trường hợp ngoại lệ hoặc các tình huống không mong đợi. Structural testing chỉ kiểm tra các thành phần cấu trúc, nhưng không kiểm tra được các chức năng cụ thể. Vì vậy, cả Functional testing và Structural testing đều không thể mô phỏng được các tình huống thực tế trong thế giới thực. Để mô phỏng được các tình huống thực tế, cần phải thực hiện các thử nghiệm khác như User Acceptance Testing (UAT), Performance Testing, v.v. Tóm lại, cả Functional testing và Structural testing đều không thể mô phỏng được các tình huống thực tế trong thế giới thực.

Trong quá trình đánh giá sản phẩm, có một số nguyên tắc quan trọng cần tuân thủ để đảm bảo tính khách quan và hiệu quả của đánh giá. Tuy nhiên, có một nguyên tắc không nên được tuân thủ trong đánh giá sản phẩm, đó là nguyên tắc "Tất cả thành viên trong đội ngũ đánh giá đều chịu trách nhiệm về kết quả đánh giá". Nguyên tắc này không nên được tuân thủ vì nó có thể dẫn đến sự không công bằng và thiếu minh bạch trong quá trình đánh giá. Khi tất cả thành viên trong đội ngũ đánh giá đều chịu trách nhiệm về kết quả đánh giá, có thể xảy ra tình huống mà một thành viên trong đội ngũ đánh giá có thể ảnh hưởng đến kết quả đánh giá của cả đội ngũ, điều này có thể dẫn đến sự không công bằng và thiếu minh bạch. Ngoài ra, nguyên tắc này cũng có thể dẫn đến sự thiếu trách nhiệm và không chịu trách nhiệm của các thành viên trong đội ngũ đánh giá, vì họ có thể nghĩ rằng họ không phải chịu trách nhiệm về kết quả đánh giá. Vì vậy, nguyên tắc "Tất cả thành viên trong đội ngũ đánh giá đều chịu trách nhiệm về kết quả đánh giá" không nên được tuân thủ trong đánh giá sản phẩm.

Quá trình quản lý lỗi (Defect Management process) là một phần quan trọng của quản lý dự án. Nó bao gồm các hoạt động như phòng ngừa lỗi (Defect prevention), xác định lỗi (Defect identification), phân tích lỗi (Defect analysis), và khắc phục lỗi (Defect correction). Tuy nhiên, Deliverable base-lining không phải là một phần của quá trình quản lý lỗi. Deliverable base-lining là một hoạt động liên quan đến quản lý sản phẩm, nơi mà các sản phẩm được xác định và định hình trước khi bắt đầu dự án. Nó giúp đảm bảo rằng các sản phẩm được phát triển đáp ứng được yêu cầu và tiêu chuẩn của dự án. Vì vậy, Deliverable base-lining không phải là một phần của quá trình quản lý lỗi.

Khi một kết quả mong đợi không được chỉ định, điều quan trọng cần xem xét là cách chúng ta có thể xác định xem thử nghiệm đã thành công hay không. Nếu không có kết quả mong đợi, chúng ta không thể biết được liệu thử nghiệm đã đạt được mục tiêu hay không. Điều này có thể dẫn đến khó khăn trong việc xác định xem thử nghiệm đã thành công hay không, vì chúng ta không có tiêu chuẩn để đánh giá kết quả. Trong trường hợp này, câu trả lời đúng là "It may be difficult to determine if the test has passed or failed" vì nó phản ánh chính xác vấn đề này.

Trong lĩnh vực kiểm thử phần mềm, có một số nguyên tắc quan trọng cần lưu ý. Trước hết, về nguyên tắc kiểm thử phần mềm, có hai loại kiểm thử chính: kiểm thử đen (black box) và kiểm thử trắng (white box). Kiểm thử đen liên quan đến việc kiểm tra phần mềm mà không biết về mã nguồn, trong khi kiểm thử trắng liên quan đến việc kiểm tra phần mềm dựa trên kiến thức về mã nguồn. Trong câu hỏi, câu trả lời đúng là "Nếu bạn tìm thấy nhiều lỗi trong quá trình kiểm thử, bạn không nên quá tự tin về chất lượng phần mềm". Điều này có nghĩa là nếu bạn tìm thấy nhiều lỗi trong quá trình kiểm thử, điều đó có thể cho thấy rằng phần mềm chưa được kiểm tra kỹ lưỡng hoặc chưa được thử nghiệm đầy đủ. Vì vậy, bạn không nên quá tự tin về chất lượng phần mềm mà không có sự kiểm tra và thử nghiệm đầy đủ.

Static analysis là một kỹ thuật kiểm tra mã nguồn mà không cần thực thi mã đó. Nó giúp phát hiện các lỗi và vấn đề trong mã nguồn mà không cần chạy chương trình. Static analysis có thể được thực hiện bằng cách sử dụng các công cụ và công nghệ khác nhau, chẳng hạn như linter, kiểm tra mã nguồn, và phân tích mã nguồn. Một trong những lợi ích chính của static analysis là nó có thể tìm thấy các lỗi và vấn đề mà khó phát hiện bằng cách kiểm tra động (dynamic testing). Kiểm tra động là một kỹ thuật kiểm tra mã nguồn bằng cách thực thi chương trình và quan sát hành vi của nó. Tuy nhiên, kiểm tra động có thể không phát hiện được các lỗi và vấn đề mà không thể được tái tạo hoặc không thể được phát hiện bằng cách kiểm tra mã nguồn. Static analysis có thể được sử dụng để phát hiện các lỗi và vấn đề trong mã nguồn, chẳng hạn như: - Lỗi logic: Static analysis có thể giúp phát hiện các lỗi logic trong mã nguồn, chẳng hạn như các lỗi trong điều kiện if-else hoặc các lỗi trong việc sử dụng các biến. - Lỗi syntax: Static analysis có thể giúp phát hiện các lỗi syntax trong mã nguồn, chẳng hạn như các lỗi trong việc sử dụng các ký tự đặc biệt hoặc các lỗi trong việc khai báo các biến. - Lỗi bảo mật: Static analysis có thể giúp phát hiện các lỗi bảo mật trong mã nguồn, chẳng hạn như các lỗi trong việc sử dụng các hàm bảo mật hoặc các lỗi trong việc xử lý các dữ liệu nhạy cảm. Tóm lại, static analysis là một kỹ thuật kiểm tra mã nguồn mà không cần thực thi mã đó. Nó giúp phát hiện các lỗi và vấn đề trong mã nguồn mà không cần chạy chương trình và có thể tìm thấy các lỗi và vấn đề mà khó phát hiện bằng cách kiểm tra động.

Quá trình kiểm thử phần mềm được tổ chức theo một thứ tự nhất định để đảm bảo hiệu quả và hiệu suất cao. Thứ tự thông thường của các hoạt động trong kiểm thử phần mềm là: Unit, Integration, System, Validation. - Unit testing: Đây là giai đoạn đầu tiên trong quá trình kiểm thử phần mềm, nơi các đơn vị nhỏ nhất của phần mềm được kiểm tra để đảm bảo chúng hoạt động đúng như mong đợi. - Integration testing: Sau khi hoàn thành unit testing, các đơn vị được tích hợp lại với nhau để kiểm tra xem chúng có hoạt động đúng khi kết hợp với nhau hay không. - System testing: Ở giai đoạn này, toàn bộ hệ thống phần mềm được kiểm tra để đảm bảo nó hoạt động đúng và đáp ứng được các yêu cầu của khách hàng. - Validation: Cuối cùng, quá trình kiểm thử phần mềm được hoàn thiện bằng giai đoạn validation, nơi phần mềm được kiểm tra để đảm bảo nó đáp ứng được các yêu cầu và tiêu chuẩn của khách hàng. Thứ tự này giúp đảm bảo rằng phần mềm được kiểm tra một cách toàn diện và hiệu quả, từ đơn vị nhỏ nhất đến toàn bộ hệ thống.