D) CÁC CÁCH BIỂU DIỄN CỦA MÔ HÌNH PHÂN TÍCH
f. Đặc tả giao diện đối tượng
7.5. CÔNG CỤ KIỂM THỬ TỰ ĐỘNG
Kiểm thử là một giai đoạn tốn kém và được nghiên cứu nhiều nhất trong tiến trình phần mềm. Do đó, công cụ kiểm thử là một trong những công cụ hỗ trợ việc phát triển phần mềm đầu tiên ra đời. Những công cụ này giúp giảm đáng kể thời gian và công sức cho kiểm thử.
Có thể tìm hiểu qua về một cách tiếp cận để kiểm thử tự động, như JUnit, được sử dụng để kiểm thử hồi quy. JUnit là một tập các lớp Java mà người sử dụng có thể mở rộng để tạo ra một môi trường kiểm thử tự động. Mỗi kiểm thử độc lập được thực hiện như một đối tượng và một người kiểm thử chạy tất cả các trường hợp kiểm thử. Các trường hợp kiểm thử nên được viết để chỉ ra rằng các hệ thống được kiểm thử sẽ vận hành như mong muốn.
Một môi trường kiểm thử (workbench testing) là một tập các công cụ được tích hợp hỗ trợ cho tiến trình kiểm thử. Hình 7.16 chỉ ra một số công cụ có thể được tích hợp trong môi trường kiểm thử.
Hình 7.16. Mô hình một công cụ tích hợp kiểm thử
1. Bộ phận quản lý kiểm thử quản lý việc thực thi các trường hợp kiểm thử của chương trình. Quản lý kiểm thử lưu vết dữ liệu kiểm thử, kết quả mong muốn và các chức năng trong chương trình đã được kiểm thử. JUnit là một ví dụ về người quản lý kiểm thử.
2. Bộ sinh dữ liệu kiểm thử: sinh ra các dữ liệu kiểm thử cho việc kiểm thử chương trình. Điều này có thể được hoàn thành bởi việc lựa chọn dữ liệu từ cơ sở dữ liệu hoặc bằng việc sử dụng các mẫu (pattern) để sinh ra dữ liệu ngẫu nhiên.
3. Hệ tiên đoán (Oracle): sinh ra những phán đoán về kết quả mong đợi. Các hệ tiên đoán cũng có thể là các phiên bản chương trình trước đó hoặc các hệ thống bản mẫu (prototype). Kiểm thử quay lui liên quan tới việc chạy hướng dẫn và chương trình để được kiểm thử song song. Những điểm khác nhau của kết quả đầu ra sẽ được lưu ý.
4. Bộ so sánh file (File comparator) so sánh kết quả của các kịch bản kiểm thử chương trình với những kết quả kiểm thử trước đó và báo cáo về những khác biệt. Việc so sánh được sử dụng trong kiểm thử hồi quy, khi kết quả của các phiên bản khác nhau được so sánh.
5. Bộ sinh báo cáo (Report generator): cung cấp báo cáo và sinh ra các tiện ích cho kết quả kiểm thử.
6. Bộ phận phân tích (Dynamic analyzer): thêm mã nguồn vào chương trình để đếm số lần thực thi mỗi câu lệnh. Sau khi kiểm thử, sinh ra bản tổng kết để chỉ ra câu lệnh nào được thực hiện thường xuyên nhất.
Mã nguồn chương trình Phân tích động Báo cáo thực thi Người quản lý kiểm thử Chương trình được kiểm thử Mô phỏng
Sinh dữ liệu kiểm thử
Hệ tiên đoán
Bộ so sánh file Bộ sinh báo
cáo Chương trình được kiểm thử Chương trình được kiểm thử Chương trình
được kiểm thử được kiểm thử Chương trình
Chương trình được kiểm thử
1. Các công cụ mới có thể được thêm vào để kiểm thử các đặc trưng của mộtứng dụng cụ thể, một số công cụ hiện có có thể không được dùng tới.
2. Các kịch bản có thể được viết cho việc mô phỏng giao diện người dùng và các mẫu (patterns) được xác định cho bộ sinh dữ liệu kiểm thử. Các định dạng cho báo cáo đôi khi cũng phải khai báo.
3. Tập hợp kết quả kiểm thử mong muốn có thể phải so sánh thủ công nếu không có các phiên bản chương trình trước đó có thể dùng như một hệ tiên đoán.
4. Bộ so sánh tệp tin có thể phải viết thêm vào việc mô tả các cấu trúc của kết quả kiểm thử trong tệp tin.
Để tạo ra một bộ công cụ kiểm thử toàn diện đòi hỏi một lượng lớn thời gian và công sức. Do đó, các Workbench hoàn chỉnh (như trong hình 7.16) chỉ được sử dụng khi phát triển các hệ thống lớn. Đó là những hệ thống mà chi phí cho việc kiểm thử có thể chiếm tới 50% tổng chi phí phát triển sản phẩm. Vì thế, nó chỉ hiệu quả để đầu tư cho công cụ chất lượng cao CASE hỗ trợ việc kiểm thử. Tuy nhiên, vì cáchệ thống khác nhau đòi hỏi sự hỗ trợ của các loại kiểm thử khác nhau nên đôi khicác công cụ kiểm thử có sẵnkhông đáp ứng được tất cả các yêu cầu.
CÂU HỎI ÔN TẬP
1. Trình bày các khái niệm cơ bản trong kiểm thử.
2. Trong quá trình kiểm thử hệ thống, người ta có thể sử dụng các hình thức kiểm thử nào?
3. Hãy xây dựng các kịch bản kiểm thử cho chức năng rút tiền từ một máy ATM của hệ thống
ngân hàng.
4. Xây dựng các kịch bản kiểm thử phân vùng cho chương trình tìm ước chung lớn nhất của hai số UCLN (a, b).
5. Xây dựng kịch bản kiểm thử đường cho chương trình giải phương trình bậc hai:
Chương 8: BẢO TRÌ PHẦN MỀM VÀ QUẢN LÝ THAY ĐỔI
Bảo trì là giai đoạncuối cùng trong chu trình phát triển phầnmềm. Các chương trình máy tính luôn thay đổi do nhu cầu mở rộng, sửa lỗi, tối ưu hoá, yêu cầu người dùng phát sinh, môi trường vận hành của hệ thống thay đổi... Theo thống kê thì bảo trì chiếm đến 70% toàn bộ công sức bỏ ra cho một dự án phần mềm. Do vậy, bảo trì là một hoạt động phức tạp nhưng nó lại là vô cùng cần thiết trong chu trình sống của sản phẩm phần mềmđể đảm bảo rằngphần mềm luôn
đáp ứng được yêu cầu củangười sử dụng.
Do nhu cầu phát triển của các hệthống thông tin, rất hiếm hay không muốn nói là không thể có một hệthống thông tin không có sự thay đổi trong suốt chu trình sống của nó. Để duy trì tính đúngđắn, trậttự trong giai đoạn bảo trì thì quản lý sự thay đổi phần mềmlà một hoạt động cần thiết.
Chương này giới thiệu về các hoạt động bảo trì và các loại bảo trì phần mềm. Một số đặc trưng cơ bản của các hoạt động bảo trì, từ đó sinh viên có thể hiểu được các bước cơ bản khi bảo trì, những khó khăn trong quá trình bảo trì các hệ thống phần mềm. Phần cuối của chương giới thiệu về các hình thức bảo trì và hoạt động quản lý thay đổi trong tiến trình bảo trì phần mềm.