Câu 1: Các chiến lược Test phần mềm

1. Kiểm tra Black-box

- coi xử lý kết quả như là minh chứng bởi dữ liệu.

- không quan tâm logic.

- Khuynh hướng này hiệu quả đối với các modul chức năng đơn và các hệ thống cấp cao.

- Ba phương pháp chính là:

·          Phân hoạch cân bằng:

o         Mục đích của phương pháp: tối thiểu các trường hợp kiểm tra cho trước, các mục dữ liệu vào được chia thành các nhóm dữ liệu có vai trò cân bằng nhau, mỗi nhóm đại diện cho một tập dữ liệu.

o         Nguyên tắc: bằng cách kiểm tra triệt để một mục của mỗi tập hợp, chúng ta có thể chấp nhận tất cả các mục tương đương khác của tập hợp đó cũng sẽ được kiểm tra một cách kỹ càng.

·          Phân tích cực biên: Phân tích giá trị cực biên là một dạng nghiêm ngặt của phân hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị nào trong tập cân bằng.

·          Đoán lỗi: Dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia có thể dễ dàng kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất.

2. White-box testing

Có ba loại kiểm tra hộp trắng là kiểm tra logic - logic test, chứng minh toán học - mathematical proof và Cleanroom testing.

1. Logic test

- chi tiết đến mức lệnh.

- nhìn vào mỗi quyết định trong module và sản sinh các dữ liệu để tạo tất cả các kết quả ra có thể.

 - Có một vấn đề với logic test tại mức này là chúng không test tình trạng của module đối với đặc tả. Nếu kiểm tra được phát triển dựa trên đặc tả, mà đặc tả được dịch khác nhau bởi người lập trình thì kiểm tra sẽ không đúng. Giải pháp là đòi hỏi đặc tả chương trình đủ chi tiết và logic. Điều này có thể phù hợp với ngôn ngữ thế hệ 1 và 2.

Các kiểm tra nhiều điều kiện tạo mỗi kết quả ra của tiêu chuẩn đa quyết định và nhiều điểm vào module. Các kiểm tra đòi hỏi việc phân tích xác định được bên quyết định đa tiêu chuẩn. Nếu các biên được xác định không chính xác, thì kiểm tra không hiệu quả. Khi được thiết kế phù hợp, test logic đa điều kiện có thể tối thiểu hoá các trường hợp kiểm tra để kiểm tra nhiều nhất các điều kiện. Sự sử dụng kỹ thuật này đòi hỏi luyện tập và kỹ năng.

2. Chứng minh bằng toán học

Một phương pháp theo cách tiếp cận giảm thiếu sót về 0 là áp dụng suy diễn toán học cho đòi hỏi logic, chứng minh tính đúng đắn của chương trình.

Phương pháp này đòi hỏi đặc tả ngôn ngữ dạng hình thức.

3. Cleanroom testing

Cleanroom testing là mở rộng của phương pháp chứng minh bằng toán học.

 Lý thuyết của kỹ thuật này là bằng cách ngăn chặn các lỗi tại các đầu vào của quá trình xử lý, giá thành sẽ giảm, độ tin cậy tăng lên và tiệm cận tới không có lỗi.

Bất lợi của phương pháp này bắt buộc là đòi hỏi kỹ năng cao về: toán, thống kê, logic và ngôn ngữ đặc tả hình thức.

3.  Kiểm tra top-down

Phương pháp kiểm tra top-down cần một mã ngoài, được hiểu như là một bộ khung để gắn các chức năng gốc, các modul, và các phần khác của ứng dụng. Bộ khung này thường bắt đầu với ngôn ngữ điều khiển công việc và logic chính của ứng dụng. Logic chính được kiểm tra và lập khung theo các hệ thống phân rã. Đầu tiên chỉ có các thủ tục thiết yếu và các logic điều khiển được kiểm tra.

Khi các module thiết yếu nhất đã được kiểm tra và chạy tốt thì mã của các modul ít quan trọng hơn sẽ được gắn vào khung và tiếp tục kiểm tra.

 Về lý thuyết thì, top-down sẽ tìm thấy các lỗi thiết kế sớm hơn trong kiểm tra thao tác (testing process) hơn các khuynh hướng khác.

 Phương pháp này ít hiệu quả trong việc cải thiện chất lượng của các phần mềm chuyển giao vì bản chất tương tác của kiểm tra.

Kiểm tra top-down dễ dàng hỗ trợ giao diện người dùng và thiết kế màn hình.

4.  Kiểm tra bottom-up

Nguyên tắc của bottom-up là kiểm tra mọi thay đổi tại module có thể ảnh hưởng tới chức năng của nó.

Tất cả các module được mã hoá và kiểm tra riêng rẽ.

Các trường hợp kiểm tra: các trường hợp kiểm tra là dữ liệu vào được tạo để thể hiện từng khối và toàn bộ hệ thống thoả mãn tất cả các yêu cầu thiết kế.

Mỗi trường hợp kiểm tra nên được phát triển để kiểm tra nghiệm các đòi hỏi thiết kế đặc trưng, thiết kế chức năng, hoặc mã đã được thoả mãn. Hơn nữa các trường hợp kiểm tra cần dự đoán các output.

Mỗi đơn nguyên của ứng dụng (Ví dụ: module, subroutine, program, utility,...) phải được kiểm tra với ít nhất hai trường hợp kiểm tra: một trường hợp chạy tốt và một trường hợp không chạy. Trong trường hợp chạy sai hệ phải đưa được thông báo, quay lại (rollback) được trạng thái ban đầu của giao dịch.

Để chắc chắn rằng các trường hợp được toàn diện nhất, người ta thường dùng ma trận. Chúng được dùng cho:

·          Kiểm tra đơn khối để định nhánh logic, điều kiện logic, các phần dữ liệu hoặc biên dữ liệu để kiểm tra trên cơ sở đặc tả chương trình.

·          Kiểm tra tổ hợp để định ra yêu cầu về dữ liệu và quan hệ trong số các tương tác.

·          Kiểm tra hệ thống để xác định yêu cầu về người dùng và hệ thống từ các yêu cầu chức năng và các yêu cầu chấp nhận.

Tốt nhất là phối hợp các kiểm tra trong một chiến lược.