Mẫu thử có thể được phát sinh ngẫu nhiên hoặc không ngẫu nhiên, tự động hoặc không tự động.
Cách thử chương trình bằng mẫu thử: Thử tính đúng đắn
So kết quả thu được với kết quả chờ đợi
Nếu trong quá trình thử phức tạp, yêu cầu chương trình in các giá trị trung gian
Kiểm tra giá trị trung gian Kiểm tra vệt chương trình
Thử hiệu năng: các mẫu thử phải đủ lớn và có thể thử nghiệm trong một thời gian dài.
CHƯƠNG 6 – LẬP TRÌNH CHẠY THỬ VÀ BẢO TRÌ BÀI 1. LẬP TRÌNH, GHÉP NỐI CÁC CHƯƠNG TRÌNH 6.1. TỔ CHỨC LẬP TRÌNH VÀ GHÉP NỐI HỆ THỐNG
6.1.1. Các công việc chuẩn bị trước khi tiến hành lập trình
Trước khi bắt tay vào giai đoạn lập trình, các chuyên gia quản lý dự án phải trả lời các câu hỏi sau:
• Kết quả rà xét lại thiết kế có yêu cầu phải làm lại một phần nào đó trong hệ thống không? Nếu có, phải sắp xếp thời gian một cách phù hợp và không nên bắt đầu lập trình khi chưa giải quyết ổn thoả mọi chuyện.
• Các nguồn nhân lực, vật lực và thông tin, cũng như là các lập trình viên lúc nào cũng sẵn sàng và dự an sẽ kết thúc đúng theo kỳ hạn. Khi có thay đổi nhân sự vì bất cứ lý do gì, cần phải lượng trình năng suất công việc của người mới đến thay thế để có thể trù liệu trước mọi chuyện đáp ứng được hạn định đã đặt ra. Bởi lẽ trong các công ty với các điều kiện làm việc như nhau, một chuyên gia lập trình giỏi có thể làm việc với năng suất gấp 8 lần người có trình độ trung bình.
• Mọi người đã được đào tạo chưa? Chẳng hạn, khi bắt tay vào công việc, các lập trình viên phải biết rõ về hệ điều hành, ngôn ngữ lập trình và các công cụ lập trình sẽ được sử dụng. Họ còn phải làm quen với ứng dụng mà người sử dụng đặt hàng cũng như bài toán cần giải quyết. Một điều quan trọng là phải cung cấp tài liệu đầy đủ đề các lập trình viên biết rõ về tài liệu yêu cầu và đặt tả chức năng.
• Mô trường lập trình dành cho các thành viên trong dự án đó được chuẩn bị tốt, đáp ứng các yêu cầu của công việc không? Kinh nghiệm triển khai thực tiễn đã chứng tỏ rằng nên chọn những phần mềm và công cụ lập trình dễ sử dụng. Các máy tính dùng để phát triển công việc của dự án phải đáp ứng được yêu cầu: trả lời nhanh (tốc độ cao), dung lượng bộ nhớ đủ lớn, có độ tin cậy cao và cung cấp đủ khi cần thiết. Một điểm quan trọng khác là phải đảm bảo các thiết bị vẫn đang được nhà sản xuất bảo hành, các tài liệu về phần mềm phát triển vẫn đang được cập nhật thường xuyên. Trong thời gian thực hiện dự án phải luôn đảm bảo hệ thống không bị gián đoạn.
6.1.2. Các bước lập trình, ghép nối và chạy thử
Kinh nghiệm xây dựng các hệ tin học cỡ lớn chỉ ra rằng không nên và không thể xây dựng một chương trình giải quyết được tất cả mọi việc. Trong những trường hợp như vậy, cách làm phân chia hệ thống thành các module nhỏ hơn thường tỏ ra hợp lý. Sau đó người ta tiến hành ráp nối các module một cách nhịp nhàng. Các nhà quản lý dự án phải đặt kế hoạch một cách rõ ràng, đưa ra thứ tự ghép nối các module sẽ được lập trình theo thứ tự tích hợp vào hệ thống. Kế hoạch này được gọi là kế hoạch kiểm thử hệ thống.
Các bước sau đây (bước 2 ÷ bước 9) chỉ liên quan tới một module của hệ thống mà thôi.
Bước 2. Thiết kế các module
Ở bước này, các lập trình viên nhận bản đặc tả thiết kế được bàn giao lại từ giai đoạn thiết kế (do kết quả của việc thiết kế mức tổng thể và mức trung gian). Công việc ở đây là tiếp tục chia nhỏ thành các mức thấp hơn cho đến khi đạt tới các công việc “sơ cấp” theo nghĩa có thể lập trình được ngay bằng một ngôn ngữ lập trình nào đó. Quá trình này được gọi là quá trình thiết kế các module hay thiết kế mức dưới.
Câu hỏi đặt ra. Quá trình thiết kế hệ thống sẽ dừng lại ở mức chi tiết như thế nào và khi nào bắt tay vào thiết kế chi tiết từng module?
Câu trả lời. Quá trình thiết kế hệ thống nhằm chia nhỏ các module tới mức người lập trình có thể bắt đầu công việc của mình nghĩa là các đặc tả về dữ liệu và theo tác đủ rõ ràng và tường minh để có thể mã hoá thông qua một ngôn ngữ lập trình nào đó. Hơn nữa, mức độ chi tiết hoá tuỳ thuộc vào từng dự án một hay từng phần trong hệ thống, thậm chí cả quan niệm của người lập trình đảm nhận phần việc được giao.
Cần phải xem xét các yếu tố như:
• Nếu chia nhỏ các module là yêu cầu cấp thiết nhằm đáp ứng các đặc tính có độ ưu tiên cao như thời gian trả lời, giao diện hệ thống thân thiện cũng như tính tương hợp trong quá trình xử lý, thì người thiết kế có thể làm tới mức chi tiết sâu hơn.
• Mức độ chi tiết trong thiết kế có thể được ghi lại trong hợp đồng. Các dự án tầm cỡ cơ quan chính phủ, các Bộ, Ngành thường quy định rõ số mức thiết kế cần phải tuân thủ.
• Nếu lập trình viên không tham gia trong quá trình thiết kế, nên giả định là các thiết kế đó nhằm phục vụ cho các lập trình viên ở trình độ trung bình tức là làm rõ các
chi tiết tới mức một lập trình viên hạng trung có thể hiểu và cài đặt được theo ý đồ thiết kế.
Chú ý: Cần phải nhấn mạnh rằng các lập trình viên thường không thích nhận được bản thiết kế quá chi tiêts tới mức lập trình chỉ còn là phát biểu lại hay dịch các mệnh đề tiếng Anh sang một ngôn ngữ lập trình nào đó.
Bước 3: Rà soát thiết kế module
Cũng như đối với các thiết kế ở mức trên và mức giữa, cần phải cân nhắc các điểm lợi/hại khi tiến hành thiết kế ở các mức dưới. Do vậy cần phải rà soát lại thiết kế của từng module trước khi lập trình. Công việc này nên tổ chhức gọn nhẹ. Chỉ cần bản thên lập trình viên, người phụ trách trực tiếp và có thể là một lập trình viên cùng tham dự. Mục đích của việc rà soát lại thiết kế module là đảm bảo rằng đưa ra được một thiết kế tốt nhất có thể có được sao cho mọi chức năng đã được đề cập đến và tất cả mọi trục trặc đã được lường trước.
Bước 4: Đặt kế hoạch kiểm thử module
Lập trình viên phải lập kế hoạch kiểm thử module và dữ liệu trước khi bắt tay vào lập trình. Kế hoạch kiểm thử sau khi lập trình phải được xem xét. Trong kế hoạch này chỉ cần tập trung vào những "kiểm thử" đối với các phần khó nhất trong hệ thống. Người phụ trách dự án có thể tham gia rà soát kế hoạch kiểm thử cùng với rà soát thiết kế module. Theo kinh nghiệm, nên kết hợp 2 khâu này cùng một lúc.
Bước 5: Lập trình các module
Các tiêu chuẩn, các đòi hỏi đối với quá trình lập trình đã được trình bầy rõ trong giai đoạn thiết kế hệ thống (xem phần tài liệu kỹ thuật).
Các cách tiếp cận khác nhau trong triển khai lập trình:
• Cách tiếp cận cấu trúc
• Cách tiếp cận hướng đối tượng
Các tư tưởng lớn trong lập trình có cấu trúc là:
• Phân chia các công việc thành các module nhỏ. Mỗi module đảm nhận 1 chức năng riêng biệt nào đó, khoảng 100dòng mã lệnh thực hiện (không quá 2 trang văn bản chương trình).
• Càng ít biến tổng thể càng tốt
• Các lệnh cầu trúc được dùng là: tuần tự, if... then... else, case..., while... do..., repeat...until..., call....Tránh dùng lệnh go to.
Bước 6: Kiểm thử module:
Lập trình viên tiến hành kiểm thử module sau khi chọn một phạm vi bài toán phù hợp với cùng một số liệu thử - thông tin vào sao cho quá trình thực hiện phải đi qua các nhánh xử lý chính trong module và quan sát kết quả nhận được.
Kinh nghiệm thực tế cho thấy nên tổ chức kiểm thử module theo giai đoạn. Giai đoạn 1 gọi là kiểm thử "hộp trắng" theo nghĩa người lập trình biết rõ cái gì diễn ra bên trong module và đưa ra các dữ liệu kiểm thhử đi qua tất cả các nhành lôgic trong chương trình. Giai đoạn 2 là kiểm thử "hộp đen”. Người lập trình bỏ qua mà không cần biết nội bộ của module, các dữ liệu kiểm thử được đưa ra theo trình tự và tần xuất như trong sử dụng thực tế.
Ở giai đoạn này, cần phải chú ý và tránh được những lỗi đơn giản nhất (chẳng hạn lỗi gõ sai phím, lỗi sử dụng chuột,...).
Bước 7: Kiểm thử các mức tích hợp thấp nhất:
Nếu như một module nào đó gọi tới một vài module khác, thì lập trình viên có thể tích hợp chúng lại ngay sau khi đã hoàn tất công việc với từng module và tiến hành kiểm thử tất cả các module khi chúng phối hợp làm việc với nhau. Ngay cả khi lập trình viên không phải là người viết các module con này, anh ta vẫn phải kiểm thử các lỗi gọi tới chúng và kết quả trả lại. Cách tốt nhất để làm là tạo ra các "cuống chương trình" (program stub) thay cho việc sử dụng thực tế module này. Một cuống chương trình chỉ gồm 4 dòng lệnh, nhằm mô tả đã nhận được tín hiệu điều khiển từ chương trình mẹ, đưa ra các tham số nhận được, và chuyền điều khiển lên mưc trên cùng với một số tham số ra (nếu cần thiết).
Bước 8: Lưu giữ các kết quả kiểm thử. Đệ trình các module đã hoàn tất để tích hợp
Các kết quả kiểm thử module còn được dùng về sau để xây dựng các thống kê về lỗi, nguyên nhân và chi phí để sửa. Người phụ trách dự án phải chịu trách nhiệm tích hợp các module khi các hệ thống thông tin cần xây dựng thuộc loại cỡ nhỏ và trung bình. Để trợ giúp công việc quản lý, có thể sử dụng phần mềm quản lý mã chương trình (Code
Management System) nhằm quản lý cấu hình, lưu giữ các thông tin về các phiên bản, những thay đổi lên mã chương trình nguồn (có thể xem phần nói về các công cụ trợ giúp công nghệ phần mềm – Computer Aided Software Engineering (CASE).
Bước 9: Bắt tay vào soạn thảo tài liệu cho người sử dụng
Có thể tổ chức biên soạn các tài liệu cho người sử dụng ngay sau khi hoàn tất kiểm thử module, độc lập với chuyện lập trình viên có tham gia trực tiếp trong nhóm biên soạn hay không.
6.2. CÁC CÔNG CỤ TRỢ GIÚP LẬP TRÌNH VÀ CÀI ĐẶT
Các công cụ trợ giúp lập trình (Programing CASE Tools) nhằm trợ giúp các lập trình viên tự động hoá trong một chừng mực nào đó các công đoạn trong quá trình lập trình.
a. Ngôn ngữ lập trình:
Các ngôn ngữ lập trình và chương trình dịch đóng một vai trò rất quan trọng. Nếu các thành phần này khá đơn giản, hoàn toàn thích hợp với các ứng dụng, lập trình viên có thể học rất nhanh, sử dụng thành thạo các cấu trúc lệnh và lập trình mà không cần tốn quá nhiều công sức. Hơn nữa, các chương trình dịch làm việc khá nhanh, các thông báo lỗi đầy đủ và rõ ràng.
Ngoài ra các chương trình dịch còn phải đảm bảo các trình tiện ích sau:
b. Bộ soạn thảo
Đưa ra những dạng mẫu đối với các câu lệnh, người sử dụng chỉ cần điền thêm các biến.
Chẳng hạn, để trợ giúp lập trình bằng PASCAL, hệ soạn thảo đưa ra khuôn dạng sau:
FOR % {biến - điều khiển}% : = % {bthức} % {TO/DOWN TO}% % {bthức} % DO % {câu lệnh} %
END;
Người sử dụng chỉ cần điền vào các biến, các biểu thức và câu lệnh dưới sự trợ giúp của bộ soạn thảo. Bộ soạn thảo có thể gọi tới chương trình dịch. Nếu có lỗi khi dịch, bộ soạn thảo sẽ quay trở lại cùng với thông báo lỗi tại dòng mã chương trình nguồn đã gây ra lỗi.
c. Bỗ gỡ lỗi
Nhằm giúp người lập trình phát hiện và sửa lỗi nhờ các can thiệp sâu vào quá trình thực hiện chương trình: dừng quá trình thực hiện, dõi vết và thực hiện từng bước các dòng lệnh. Các chương trình gỡ lỗi hiệu quả còn cho phép tạo và hiển thị giá trị các biến ở bất kỳ một thời điểm nào.
d. Hệ quản lý mã chương trình nguồn (Code Management System) viết tắt là QLCT
Hệ quản lý mã chương trình nguồn đôi lúc còn được gọi là hệ quản lý cấu hình (Configuration Manager). Hệ quản lý dạng này có ý nghĩa to lớn trong quá trình lập trình, nó lưu giữ tất cả các nguồn thông tin về chương trình: ai cập nhật gì và những đụng độ khi có 2 người muốn cập nhật cùng một module nào đó. Hệ QLCT còn cung cấp các công cụ để lưu giữ các thay đổi lên các module, phục hồi các phiên bản của nó.
Hệ QLCT có thể xử lý các tệp ASCII, do đó nó không chỉ hiệu quả khi dõi viết các chương trình nguồn, mà còn dùng để lưu trữ các tệp tư liệu, các tệp dữ liệu kiểm thử ở dạng văn bản cũng như các tệp tạo dựng hệ thống. Chẳng hạn tại hãng sản xuất phần cứng, phần mềm DEC thường có 20-30 phiên bản hệ điều hành, mỗi hệ khác nhau một chút tuỳ thuộc vào hàng trăm những hoán đổi hay kết hợp các điểm mạnh về phần cứng và phần mềm. Thực tiễn chứng tỏ rằng các hệ QLCT đặc biệt cần thiết khi dõi vết tất cả các phiên bản của hệ thống chương trình.
e. Hệ quản lý các module (Module Management System), viết tắt là QLMĐ Hệ quản lý các module thường được để tự động hoá quá trình dịch và kết nối, hay xây dựng hệ thống. Nó cho phép xây dựng lại những phần bị thay đổi tính từ lần đầu xây dựng gần nhất. Hệ QLMĐ còn dùng để chạy tự động một tệp các dữ liệu kiểm thử. Có thể thấy rằng hệ QLMĐ còn dùng để chạy tự động một tệp các phiên bản của hệ thống: ráp nối các chương trình nguồn, ảnh và tất cả những tư liệu trong một phiên bản. Hệ QLMĐ có thể làm việc phối hợp với hệ QLCT (toàn bộ các chương trình nguồn, tệp văn bản và tệp câu lệnh cần chạy hệ QLMĐ có thể lưu trữ lại).
f. Hệ quản lý các kiểm thử (Test Manager) viết tắt của QLKT
Hệ loại này được dùng để tự động hoá việc kiểm thử hệ thống. Để sử dụng hiệu quả hệ QLKT, phải xác định tệp các kiểm thử cần chạy cùng với các thông tin ra mong muốn. Hệ QLKT sẽ chạy với các dữ liệu kiểm thử và thông báo cho lập trình viên nếu kết quả khác với kết quả mong muốn.
BÀI 2. LẬP CÁC TÀI LIỆU HƯỚNG DẪN SỬ DỤNG 6.1. TÀI LIỆU HƯỚNG DẪN SỬ DỤNG
Tài liệu này có thể do người lập trình, hay một chuyên viên kỹ thuật, thậm chí là người sử dụng biên soạn. Cần phải nhắc lại là các đặc tả chức năng trong giai đoạn phân tích, thiết kế đã phải có những mô tả chi tiết về các thực đơn, bố trí màn hình, các trình bày và những giao diện khác. Trong tài liệu này không nên trình bày dông dài. Để có một tài liệu hướng dẫn sử dụng tốt, nên chia thành các phần phù hợp với từng đối tượng người sử dụng có chuyên môn khác nhau. Tài liệu phải trình bày theo trình tự người sử dụng sẽ vận hành, khai thác hệ thống, bởi lẽ nó sẽ thuận tiện cho người sử dụng làm việc với hệ. Một thứ tự trình bày hay được sử dụng trong các tài liệu là thứ tự logic các chức năng trong cây thực đơn câu lệnh từ trên xuống dưới, từ trái sang phải.
Ở cuối tài liệu nên có phần tra cứu nhanh các lệnh, các thực đơn, và các thông báo theo thứ tự từ điển.
6.2. TÀI LIỆU HƯỚNG DẪN BẢO TRÌ
Một trong những yêu cầu cơ bản đối với công việc quản lý trong giai đoạn này