Kiểm thử điều kiện là một kỹ thuật kiểm thử cấu trúc điều khiển mà những tiêu chuẩn dùng để thiết kế test-case

Kiểm thử luồng dữ liệu (Data Flow Testing) là một phương pháp kiểm thử cấu trúc (white-box testing) tập trung vào việc theo dõi luồng dữ liệu của các biến trong chương trình. Nó chọn các đường dẫn kiểm tra dựa trên vị trí định nghĩa và sử dụng các biến. Các tiêu chuẩn thiết kế test case trong kiểm thử luồng dữ liệu tập trung vào việc đảm bảo rằng mọi định nghĩa của một biến đều được sử dụng, và mọi cách sử dụng một biến đều xuất phát từ một định nghĩa hợp lệ.

* A. Dựa vào kiểm thử đường cơ bản: Kiểm thử đường cơ bản (Basis Path Testing) là một kỹ thuật kiểm thử cấu trúc khác, tập trung vào việc bao phủ tất cả các đường dẫn độc lập trong đồ thị luồng điều khiển. Mặc dù có liên quan đến kiểm thử cấu trúc, nó không phải là tiêu chuẩn chính để thiết kế test case trong kiểm thử luồng dữ liệu.
* B. Thử thách điều kiện logic trong module phần mềm: Kiểm thử điều kiện (Condition Testing) tập trung vào việc kiểm tra các điều kiện logic trong chương trình, đảm bảo rằng tất cả các kết quả có thể xảy ra đều được kiểm tra. Nó không phải là trọng tâm chính của kiểm thử luồng dữ liệu.
* C. Chọn những đường dẫn kiểm tra dựa vào những vị trí và dùng những biến: Đây là đáp án chính xác. Kiểm thử luồng dữ liệu tập trung vào việc xác định các đường dẫn trong chương trình mà dữ liệu (giá trị của biến) di chuyển từ điểm định nghĩa đến điểm sử dụng.
* D. Tập trung vào việc kiểm thử việc giá trị những cấu trúc lặp: Kiểm thử cấu trúc lặp (Loop Testing) tập trung vào việc kiểm tra các vòng lặp trong chương trình, đảm bảo rằng chúng hoạt động chính xác trong các điều kiện khác nhau (ví dụ: không lặp, lặp một lần, lặp nhiều lần). Mặc dù vòng lặp có thể liên quan đến luồng dữ liệu, đây không phải là tiêu chuẩn thiết kế test case chính trong kiểm thử luồng dữ liệu.

Kiểm thử tích hợp bottom-up bắt đầu bằng việc kiểm thử các module ở mức thấp nhất, sau đó tích hợp chúng lại thành các cụm lớn hơn và kiểm thử tiếp. Ưu điểm chính của phương pháp này là không cần viết các stub (nhánh) để mô phỏng các module cấp thấp hơn, vì chúng đã được phát triển và kiểm thử. Các driver (trình điều khiển) vẫn cần thiết để mô phỏng các module cấp cao hơn.

* A. Những điểm quyết định chính được kiểm thử sớm: Sai. Kiểm thử bottom-up tập trung vào các module cấp thấp trước, các điểm quyết định chính thường nằm ở các module cấp cao hơn, do đó không được kiểm thử sớm.
* B. Không có những driver cần được viết: Sai. Trong kiểm thử bottom-up, driver vẫn cần thiết để mô phỏng các module cấp cao hơn (module gọi).
* C. Không có những stub (nhánh) cần phải viết: Đúng. Đây là ưu điểm chính của bottom-up. Vì kiểm thử bắt đầu từ các module cấp thấp nhất, không cần stub để mô phỏng các module cấp thấp hơn.
* D. Không đòi hỏi kiểm thử hồi quy (regression): Sai. Kiểm thử hồi quy vẫn cần thiết để đảm bảo các thay đổi không ảnh hưởng đến các chức năng đã có.

Vậy đáp án đúng là C.

Mô hình phát triển dựa trên thành phần (Component-Based Development - CBD) là một phương pháp tiếp cận phát triển phần mềm tập trung vào việc xây dựng hệ thống từ các thành phần phần mềm độc lập, có thể tái sử dụng. Các thành phần này thường được phát triển dựa trên các kỹ thuật hỗ trợ đối tượng (Object-Oriented techniques) để đảm bảo tính đóng gói, tính kế thừa và tính đa hình, giúp cho việc tái sử dụng và bảo trì dễ dàng hơn.

* Phương án 1: Sai. Mô hình phát triển dựa trên thành phần không chỉ giới hạn cho thiết kế phần cứng máy tính. Nó được sử dụng rộng rãi trong phát triển phần mềm nói chung.
* Phương án 2: Sai. Một trong những mục tiêu chính của mô hình này là hỗ trợ phát triển và sử dụng lại các thành phần.
* Phương án 3: Đúng. Mô hình này tận dụng các kỹ thuật hỗ trợ đối tượng để xây dựng các thành phần phần mềm có khả năng tái sử dụng cao.
* Phương án 4: Sai. Các độ đo phần mềm vẫn có thể được áp dụng để định chi phí và đánh giá hiệu quả của các thành phần phần mềm.

Kỹ thuật FAST (Facilitated Application Specification Techniques) là một phương pháp tiếp cận hợp tác, trong đó nhà phát triển và khách hàng cùng nhau làm việc để xác định và phát triển một tập hợp các yêu cầu ban đầu cho phần mềm. Mục tiêu là tạo ra một sự hiểu biết chung về phạm vi và mục tiêu của dự án, giảm thiểu rủi ro hiểu lầm và đảm bảo rằng phần mềm cuối cùng đáp ứng được nhu cầu của khách hàng.

Phương án 1 không chính xác vì FAST không chỉ tập trung vào việc xây dựng nguyên mẫu nhanh chóng, mà còn đảm bảo rằng nguyên mẫu đó dựa trên các yêu cầu đã được thống nhất.

Phương án 2 không chính xác vì học công việc lẫn nhau là một phần của quy trình, nhưng không phải là mục tiêu chính.

Phương án 4 không chính xác vì FAST tập trung vào các yêu cầu ban đầu, chứ không phải là đặc tả kỹ thuật chi tiết.

Phương án 3 chính xác vì nó mô tả đúng mục đích của FAST, đó là sự hợp tác giữa nhà phát triển và khách hàng để xác định các yêu cầu ban đầu.

Mô hình thiết kế tập trung vào việc hiện thực hóa các yêu cầu của dự án, bao gồm kiến trúc, dữ liệu và giao diện. Phạm vi dự án là một yếu tố xác định giới hạn của dự án, nhưng không trực tiếp liên quan đến việc thiết kế các thành phần bên trong dự án. Do đó, mô hình thiết kế không trực tiếp quan tâm đến phạm vi dự án, mà quan tâm đến việc làm thế nào để đáp ứng các yêu cầu trong phạm vi đó.

* Kiến trúc: Mô hình thiết kế phải tuân thủ kiến trúc tổng thể của hệ thống.
* Dữ liệu: Mô hình thiết kế phải xác định cấu trúc và cách thức lưu trữ dữ liệu.
* Giao diện: Mô hình thiết kế phải định nghĩa giao diện người dùng và các giao diện khác.
* Phạm vi dự án: Phạm vi dự án xác định những gì cần được xây dựng, nhưng mô hình thiết kế tập trung vào cách xây dựng những thứ đó.