Kiểm tra và các chiến luợc kiểm tra phần mềm

Kiểm tra Black-box

Kiểm tra hộp đen, black-box, coi xử lý kết quả như là minh chứng bởi dữ liệu. Khái niệm kiểm tra là black-box 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: Mục đích của phương pháp này là 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. Nguyên tắc là 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ântíchcựcbiê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. Ví dụ: miền giá trị của tháng là 1 – 12 và ngoài là 0 và

13. Thì 4 kiểm tra ứng với bốn trường hợp sẽ được kiểm tra phân tích cực biên thường xuyên được dùng tại các mức modul để xác định các mục dữ liệu đặc trưng cho testing.

 Đoánlỗ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. Ví dụ, chia 0, nếu modul có phép chia, nên dùng phép chia 0. Vì dựa trên trực giác, nên phép thử này khó tìm hết các lỗi.

Một nhược điểm của phân hoạch cân bằng và phân tích cực biên là tổ hợp của các miền hợp không được xác định. Để bổ sung, người ta dùng sơ đồ nguyên nhân – kết quả (Cause – Effect Graphing). Sơ đồ nguyên nhân – kết quả chỉ ra các đầu ra và thông tin di chuyển như là hệ quả và các đầu vào gây ra hệ quả trên. Các ký hiệu

graphic xác định tương tác, lựa chọn, logic và các điều kiện tương đương. Một vòng đại diện một dãy các thao tác không có điểm quyết định hoặc điều khiển. Mỗi dòng biểu diễn một lớp cân bằng của dữ liệu và các điều kiện sử dụng nó. Mỗi lần graph được thực hiện thì ít nhất một giá trị có nghĩa và một không có nghĩa cho mỗi tập được thử.

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

Logic test có thể được chi tiết đến mức lệnh. Trong khi thực hiện của mọi lệnh là mục đích đáng khen ngợi, nó có thể không kiểm tra tất cả các điều kiện thuộc chương trình. Ví dụ, ít nhất 2 kiểm tra cho một kiểm tra 2 điều kiện (1 đúng và 1 sai). Cố gắng kiểm tra tất cả các điều kiện lẽ dĩ nhiên là không thể thực hiện được về thực tiễn. Ví dụ trong 1 module có 10 thao tác qua 4 vòng lặp thì có 5,5 triệu trường hợp kiểm tra. Do đó phải có phương pháp lựa chọn.

Logic kiểm tra 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. Kỹ thuật chứng minh tính đúng đắn của chương trình được đề cập ở 6.4.

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.

Phương pháp này được phát triển tại IBM đầu những năm 1980 bởi Mills, Dyer, Linger. Các đặc tả hình thức được dùng và việc kiểm tra thủ công được tiến hành bởi các đội kiểm tra. Các chương trình khó đọc sẽ được viết lại và kiểm tra hoàn toàn trên giấy.

Cleanroom testing là kỹ thuật kiểm tra toán học hình thức và hội ý

(walkthrough). Mục đích là phân tích mọi module thành các chức năng và liên kết. Các phép kiểm tra chức năng dùng kỹ thuật toán học, các kiểm tra liên kết sử dụng thuyết tập hợp.

Sau khi thực hiện kiểm tra (verification), đội kiểm tra độc lập sẽ dịch và thực hiện mã. Dữ liệu kiểm tra được dịch bởi các phân tích đặc tả chức năng và được thực hiện thể hiện các tỷ lệ xác suất của dữ liệu được giả định cho hệ thống thực. Thêm vào các dữ liệu chuẩn thì các loại lỗi nghiêm trọng được tạo để kiểm tra ứng dụng.

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.

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. Trong các ứng dụng tương tác, thường là bộ điều khiển màn hình được kiểm tra đầu tiên. Người dùng có thể kiểm tra sự điều khiển thông qua màn hình với các phát triển tạo mẫu.

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ó. Trong kiểm tra bottom-up, toàn bộ khối là đơn vị để đánh giá. 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.

Phối hợp các kiểm tra trong một chiến lược: mục đích của các nhà kiểm tra là tìm ra sự cân bằng của các chiến lược cho phép họ chứng minh được ứng dụng chạy tốt mà tối thiểu hoá chi phí máy tính và nhân lực. Sử dụng duy nhất một chiến lược là rất nguy hiểm. Không có cái nào là duy nhất đúng. Nếu chỉ có white-box thì tài nguyên nhân lực và máy là rất tốn kém, nếu chỉ có black-box các vấn đề logic đặc trưng có thể chưa được khám phá.