CHƯƠNG 4. KIỂM THỬ VÀ CHUYỂN KHAI HỆ THỐNG
4.2. Triển khai hệ thống
4.1. Kiểm thử phần mềm
4.2.1. Lập kế hoạch cài đặt
4.1.1. Khái niệm kiểm thử
4.2.2. Biến đổi dữ liệu
4.1.2. Quy trình kiểm thử
4.2.3. Đào tạo người sử dụng
4.1.3. Thiết kế ca kiểm thử
4.2.4. Biên soạn tài liệu hệ thống
4.2.5. Bảo trì phần mềm
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
161
4.1.1. Khái niệm
§ Kiểm thử là tiến trình xem xét, kiểm tra lại đặc tả, phân tích, thiết kế và mã hoá nhằm phát hiện lỗi phần mềm: xác minh phần mềm có đúng đặc tả, thiết kế; có đáp ứng nhu cầu người dùng; có hoạt động hiệu quả không (không thực hiện bất cứ thứ gì không mong muốn).
§ Kiểm thử thành công khi phát hiện ra lỗi, kiểm thử không
phát hiện ra lỗi là kiểm thử dở.
4.1.1. Khái niệm
§ Hai mục đích chính của hoạt động kiểm thử:
— Kiểm tra xem phần mềm làm ra có đúng đặc tả (yêu cầu, phân tích, thiết
kế) hay không.
§ Đây chính là 2 hoạt động cốt yếu để đảm bảo chất lượng phần mềm,
diễn ra trong suốt quá trình phát triển phần mềm.
— Kiểm tra xem phần mềm có đáp ứng yêu cầu người dùng hay không.
Các mức kiểm thử
§ Phân loại theo mức độ chi tiết của các thành phần hợp thành
hệ thống — Kiểm thử đơn vị (Unit testing): mỗi mô đun — Kiểm thử tích hợp( Integration Testing) : nhiều mô đun/ hệ con — Kiểm thử hệ thống (System Testing) : phần cứng/ phần mềm, yêu
cầu hệ thống
hệ thống
— Kiểm thử chấp nhận( Acceptance Testing) : yêu cầu người dùng
The V-model of development
Service
Requirement specification
System Specification
Acceptance test
Acceptance test plan
System design
System integration test
System integration test plan
Detail design
Syb-system integration test
Syb-system integration test plan
Module, unit code and test
Kiểm thử đơn vị
§ Unit Testing là việc kiểm thử ở mức độ thấp nhất là các phương thức (Method), hàm (Function), lớp (Class) trong mã nguồn. Nhằm đảm bảo các thành phần trên hoạt động đúng như yêu cầu;
trong quá trình mã hóa (Coding, Implement);
§ Việc kiểm tra ở mức độ này thường do chính các lập trình viên (Developer) thực hiện
kiểm thử (Test-Driven Development):
§ Một mô hình thường được ứng dụng với Unit Testing là Phát triển theo định hướng
— Các Unit Test viết trước dựa theo yêu cầu kết quả trả về ban đầu là sai (False);
— Mã nguồn sẽ được viết sau và được kiểm tra tự động bằng các Unit Test;
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
166
— Việc phát triển được hoàn thành khi các Unit Test trả về kết quả đúng (True).
Kiểm thử đơn vị
§ Người tiến hành kiểm thử thông thường là người lập trình mô đun đó hoặc lập trình viên cùng
§ Kiểm thử riêng biệt từng đơn vị phần mềm;
§ Số lượng nhiều nhưng đơn giản;
§ Xuyên suốt thời gian lập trình và cả chu kỳ phần mềm;
§
nhóm;
§ Thường là được thực hiện bới nhà phát triển trước khi các môđun được tích hợp với các mô đun
Là mức thấp nhất trong tiến trình kiểm thử, thường là áp dụng phương pháp kiểm thử hộp trắng;
§ Kết quả của kiểm thử đơn vị thường tìm ra khoảng 20% lỗi trong tất cả cá lỗi của dự án.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
167
khác;
Kiểm thử tích hợp
§ Là một kỹ thuật có tính hệ thống để xây dựng cấu trúc chương trình ngay khi đang tiến hành kiểm thử để phát hiện sai liên kết với giao diện.
§ Phải kiểm thử tích hợp vì:
— Dữ liệu có thể bị mất khi đi qua một giao diện;
— Một mô đun có thể có một hiệu ứng bất lợi vô tình lên các mô đun khác;
muốn;
— Các chức năng phụ khi kết hợp lại có thể không sinh ra chức năng chính mong
được;
— Các điều không chính xác riêng rẽ có thể bị phóng đại đến mức không chấp nhận
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
168
— Các cấu trúc dữ liệu toàn cục có thể để lộ ra các vấn đề…
Kiểm thử tích hợp (t)
§ Thường sử dung phương pháp kiểm thử gia tăng (Incremental integration testing), thực hiện kiểm thử bằng cách nối dần các mô đun có liên quan logic và kiểm tra chức năng thích hợp.
— Top-down integration:
khung tổng thể của hệ thống được phát triển trước
•
các thành phần được thêm vào dần.
•
— Bottom-up integration:
tích hợp các thành phần cung cấp các dịch vụ chung trước, e.g., dịch vụ mạng, cơ sở dữ liệu
•
Tích hợp dần các thành phần chức năng
•
Kiểm thử tích hợp ( t)
§ Chương trình giả : không thực hiện toàn bộ logic lập trình của mô
đun phần mềm, chỉ mô phỏng giao tiếp dữ liệu — Driver: Gọi mô đun để được kiểm thử — Stub: Được gọi bởi mô đun kiểm thử
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
170
Kiểm thử hệ thống
§ Là mức độ kiểm thử toàn bộ các chức năng của hệ thống, bao gồm
tất cả các thành phần tương tác với nhau, và hoạt động trong môi
trường giống như môi trường thực tế như hệ điều hành, cơ sở dữ liệu,
kết nối mạng, khả năng tương thích với các phần mềm khác, …
§ Kiểm thử hệ thống cũng chú ý đến vấn đề bảo mật, thân thiện, khả
năng đáp ứng, tốc độ thực hiện của hệ thống phần mềm.
9/5/22
Bộ môn Công nghệ thông tin - Bài giảng điện tử 2020
171
Kiểm thử chấp nhận
triển.
§ Mức độ này được thực hiện bởi phía người dùng với một nhóm độc lập với nhóm phát
cầu của người dùng đã đề ra hay không? Có thể triển khai cho công việc thực tế của
người dùng hay không;
§ Mục đích của giai đoạn này là kiểm tra, đánh giá phần mềm có đáp ứng được các yêu
mở ra giai đoạn triển khai, bảo trì và nâng cấp phần mềm.
§ Việc được người dùng chấp nhận sẽ đánh dấu cho sự kết thúc của giai đoạn phát triển,
§ Các loại kiểm thử chấp nhận sản phẩm:
— Kiểm thử Alpha (Alpha Testing): Do người dùng thực hiện;Trong môi trường được quản lý. — Kiểm thử Beta (Beta Testing): Do người dùng thực hiện; Trong môi trường thực.
4.1.2. Quy trình kiểm thử
Bắt đầu
Kế hoạch kiểm thử
Lập kế hoạch Kiểm thử
Thiết kế Kiểm thử
Mẫu kiểm thử Các thủ tục kiểm
Cài đặt và chuẩn bị Kiểm thử
Mã nguồn kiểm thử Dữ liệu kiểm thử Môi trường
Kiểm thử đơn vị
Xem xét và Đánh giá kết quả Kiểm thử
Báo cáo kết quả kiểm thử , đề xuất giải pháp
Lỗi Biên bản kiểm thử
Kiểm thử tích hợp- hệ thống- chấp nhận
Tổng hợp, báo cáo
Hồ sơ báo cáo tổng hợp kiểm thử
Kết thúc
4.1.3. Thiết kế ca kiểm thử
§ Một phép thử được gọi là thành công nếu nó phát hiện ra khiếm khuyết của phần mềm. Kiểm thử chỉ chứng minh được sự tồn tại của lỗi trong hệ thống chứ không chứng minh được hệ thống không có lỗi. Một phép kiểm thử (ca kiểm thử) bao gồm: — tên của mô đun kiểm thử — dữ liệu vào — dữ liệu ra mong muốn (kết quả đúng) — dữ liệu ra thực tế (khi đã tiến hành kiểm thử)
§ Các ca kiểm thử nên được thiết kế khi chúng ta tạo các tài liệu phân tích và
thiết kế, chứ không phải là khi đã viết xong mã nguồn.
4.1.3. Thiết kế ca kiểm thử
§ Tạo ra bộ kiểm thử hiệu quả
§ Hai cách tiếp cận:
đương)
— Phân nhóm dữ liệu đầu vào (equivalence partitions – phân hoạch tương
trong mô đun)
— Xác định các đường đi trong mô đun (path testing – kiểm thử theo đường đi
Phân nhóm dữ liệu đầu vào
§ Dữ liệu vào, ra được phân chia theo nhóm/lớp.
§ Mỗi nhóm/lớp là một phân hoạch/miền tương đương
§ Hành vi của hệ thống là như nhau khi sử dụng các thành viên trong
cùng nhóm.
§ Các trường hợp kiểm thử nên được lựa chọn từ các thành viên trong
nhóm.
Phân nhóm dữ liệu đầu vào
Phân nhóm dữ liệu đầu vào
Xác định các đường đi trong mô đun
§ Mọi đường thực hiện của chương trình được kiểm thử ít
nhất một lần
§ Đồ thị luồng chương trình (program flow graph)
— Nodes: các quyết định, rẽ nhánh
— Arcs: các luồng điều khiển.
program flow graph
Các đường đi trong chương trình được kiểm thử
§ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14 § 1, 2, 3, 4, 5, 14 § 1, 2, 3, 4, 5, 6, 7, 11, 12, 5, … § 1, 2, 3, 4, 6, 7, 2, 11, 13, 5, … § Các ca kiểm thử nên chứa tất cả các đường đi cần kiểm thử § Công cụ hỗ trợ: dynamic program analyser
4.2. Triển khai hệ thống
Quy trình
Cài đặt
Biến đổi dữ liệu
Huấn luyện
Cài đặt
Biên soạn tài liệu về hệ thống
4.2. Triển khai hệ thống
§ Từ HTTT cũ sang HTTT mới, cần phải:
— Chuyển đổi phần cứng — Chuyển đổi phần mềm — Chuyển đổi cơ sở dữ liệu — Chuyển đổi công nghệ quản lý — Chuyển đổi hệ thống biểu mẫu (thông dụng) — Chuyển đổi các phương pháp truyền đạt thông tin — Chuyển đổi các phương thức lưu trữ dữ liệu, thông tin — Chuyển đổi tác phong của lãnh đạo và các nhân viên
183
4.2.1. Cài đặt hệ thống
§ Trong quá trình lập kế hoạch cài đặt, việc chuyển đổi kỹ thuật tương đối đơn giản. Tuy nhiên, việc chuyển đổi về con người tương đối phức tạp và kéo dài do sức ỳ và tâm lý ngại thay đổi của người sử dụng.
èVì vậy, phải lập kế hoạch chuyển đổi tỷ mỷ, bao quát tất cả các lĩnh
vực của hệ thống thông tin.
184
4.2.1.1. Lắp đặt phần cứng và hệ thống mạng
Lập dự trù về thiết bị: § Dự kiến:
(Online
— Khối lượng dữ liệu lưu trữ — Các dạng làm việc với máy tính (máy đơn, máy mạng), xử lý trực tuyến
— Số lượng người dùng tối thiểu và tối đa của hệ thống — Khối lượng thông tin cần thu thập — Khối lượng thông tin cần kết xuất, cần in ra giấy — Thiết bị ngoại vi đặc biệt như: Scanner, máy vẽ, máy cắt
§ Điều kiện mua và lắp đặt:
— Nên chọn nhà cung cấp nào, chi phí vận chuyển. — Mua nguyên bộ, mua rời — Sơ đồ lắp đặt mức sơ bộ.
185
4.2.1.2. Phương pháp cài đặt hệ thống
§ Sử dụng một trong 4 phương pháp — Phương pháp chuyển đổi trực tiếp — Phương pháp hoạt động song song — Phương pháp chuyển đổi từng bước thí điểm — Phương pháp chuyển đổi bộ phận
186
Chuyển đổi trực tiếp
§ Sử dụng phương pháp này chúng ta cần tính đến các yếu tố
sau : — Mức độ gắn bó của các thành viên với hệ thống mới — Mức độ mạo hiểm của hệ thống xử lý mới sẽ cao vì hệ thống mới có
thể có lỗi dẫn đến việc hệ thống ngừng hoạt động.
— Phải kiểm tra chặt chẽ phần cứng và phần mềm của hệ thống mới. — Chỉ nên áp dụng đối với các hệ thống thông tin không lớn lắm với
độ phức tạp vừa phải.
187
Chuyển đổi trực tiếp
§ Phương pháp này chỉ nên áp dụng trong các trường hợp thật sự
cần thiết. Các thao tác cần tiến hành: — Kiểm tra hệ thống một cách thật chặt chẽ — Trù tính khả năng khôi phục lại dữ liệu — Chuẩn bị thật kỹ lưỡng cho từng giai đoạn cài đặt hệ thống — Chuẩn bị phương án xử lý thủ công phòng trường hợp xấu nhất vẫn có
thể duy trì hoạt động của hệ thống.
— Huấn luyện chu đáo tất cả những người tham gia vào hệ thống — Có khả năng hỗ trợ đầy đủ các phương tiện như điện, đĩa từ ...
188
Hoạt động song song
§ Hoạt động song song cả hai hệ thống cũ và mới. Phương pháp
này cho mức độ rủi ro ít hơn, nhưng đòi hỏi nguồn tài chính cao. Các công việc cần tiến hành: — Xác định chu kỳ hoạt động song song — Xác định các thủ tục so sánh — Kiểm tra để tin chắc rằng đã có sự so sánh — Sắp xếp nhân sự — Thời gian hoạt động song song làm sao là ngắn nhất — Cả hai hệ thống cùng chạy trên phần cứng đã định một cách thận trọng
189
Chuyển đổi từng bước thí điểm
§ Đây là phương pháp trung gian của hai phương pháp trên. Các bước
cần thực hiện: — Đánh giá lựa chọn bộ phận nào làm thí điểm để áp dụng hệ thống xử lý
thông tin mới theo phương pháp trực tiếp hay song song.
— Kiểm tra xem hệ thống mới áp dụng vào các bộ phận này có được không. — Tiến hành sửa đổi. — Nhận xét so sánh.
190
Chuyển đổi bộ phận
§ Chọn ra một vài bộ phận có chức năng quan trọng có ảnh hưởng
đến cả hệ thống để tiến hành tin học hoá.
§ Sau đó đưa bộ phận đã thiết kế vào ứng dụng ngay, các bộ phận khác
thì vẫn hoạt động như cũ. Vừa làm vừa rút kinh nghiệm cho các bộ
phận còn lại
191
4.2.2. Biến đổi dữ liệu
§ Dữ liệu giữa hai hệ thống cũ và mới thường không tương thích với nhau về phương thức lưu trữ cũng như quy cách truy cập. Do đó rất dễ dẫn đến sai sót khi biến đổi dữ liệu.
Qúa trình biến đổi dữ liệu: § Xác định khối lượng và chất lượng của dữ liệu (độ chính xác, tính
đầy đủ và thứ tự).
§ Làm ổn định một bản dữ liệu và tổ chức những thay đổi cho phù
hợp.
192
4.2.2. Biến đổi dữ liệu
Qúa trình biến đổi dữ liệu: § Tổ chức và đào tạo đội ngũ thực hiện công việc biến đổi dữ
liệu.
§ Lập lịch thời gian của quá trình biến đổi dữ liệu. § Bắt đầu quá trình biến đổi dữ liệu dưới sự chỉ đạo thống nhất.
193
4.2.2. Biến đổi dữ liệu
§ Thực hiện những thay đổi
trong các tệp dữ liệu. Nếu trong hệ thống cũ có các tệp dữ liệu thì tốt nhất tổ chức biến đổi các tệp dữ liệu này trước, sau đó mới đến các tệp mới chuyển từ phương thức tổ chức thủ công sang.
§ Thực hiện bước kiểm chứng lần cuối cùng để đảm bảo các tệp dữ liệu đã biến đổi phù hợp với các yêu cầu của hệ thống quản lý mới.
194
4.2.3. Đào tạo người sử dụng
§ Lý do và và mục tiêu đào tạo:
— Giảm thời gian đi học các lớp chính quy về vấn đề liên quan — Cung cấp những kỹ xảo nghề nghiệp — Giảm tối thiểu các giám sát cần có — Tăng tính năng động của nhân sự — Đảm bảo sự hoạt động an toàn của hệ thống khi vắng cán bộ chủ chốt — Giảm sự dư thừa — Giảm chi phí — Tăng mức độ thích nghi với hệ thống mới và con người có thể hoạt
động trong hệ thống một cách hiệu quả
195
4.2.3. Đào tạo người sử dụng
§ Đối tượng đào tạo
§ Các lĩnh vực huấn luyện
— Những người sử dụng và cung cấp thông tin trong hệ thống.
— Giới thiệu tổng quan về hệ thống: hệ thống đang làm gì và những gì hệ thống có thể làm được, tương lai của hệ thống, những khía cạnh quản lý có tác động đến hệ thống.
sử dụng các thiết bị lưu trữ thứ cấp
— Làm quen với máy móc thiết bị : • Cung cấp các khái niệm cơ sở • Tham quan máy móc, thiết bị • Tư vấn về vấn đề chọn nhà cung cấp, cài đặt • Thực hành các kỹ xảo chuyên môn như sử dụng chương trình xử lý văn bản, quản lý và
— Thực hành các thao tác mới, làm quen hệ thống biểu mẫu mới, các thủ tục tra cứu tài liệu.
196
4.2.3. Đào tạo người sử dụng
Kế hoạch đào tạo: — Nhận biết về nhu cầu :
§
• Xác định các nhu cầu của công việc • Mức độ hoàn thiện cần đạt tới • Trình độ hiện thời của học viên
— Xác định các mục tiêu — Chuẩn bị các chuyên đề đào tạo:
• Chương trình đào tạo • Bố trí giảng viên • Lên thời khoá biểu đào tạo
— Kiểm tra và đánh giá kết quả đào tạo
197
4.2.4. Biên soạn tài liệu hệ thống
§ Một phần mềm khi được chuyển giao cho phía khách hàng (người sử
dụng) thường kèm theo 2 loại tài liệu sau: — Tài liệu hướng dẫn sử dụng, thông tin được thu thập từ các nguồn khác
nhau bao gồm các báo cáo xác định vấn đề, nghiên cứu tính thức thi, đề xuất hệ thống và
— Tài liệu kỹ thuật cho người lập trình và bảo trì hệ thống.
198
4.2.5. Bảo trì phần mềm
§ Là pha cuối cùng của vòng đời hệ thống § Các hoạt động cần thực hiện
— Quản lý hoạt động bảo trì — Chuẩn hóa hoạt động bảo trì (IEEE 840-1992)
199
Hoạt động bảo trì phần mềm
§ Các công việc cần thực hiện:
— Hiểu kĩ yêu cầu bảo trì — Phân loại yêu cầu: sửa đổi hay nâng cấp? — Thiết kế các sửa đổi được yêu cầu — Kế hoạch chuyển đổi từ thiết kế cũ — Đánh giá các ảnh hưởng của sửa đổi lên ứng dụng — Triển khai các sửa đổi — Thực hiện các kiểm thử đơn vị cho các phần thay đổi — Tiến hành kiểm thử tăng dần, thực hiện kiểm thử hệ thống với các khả
năng mới
— Cập nhật các tài liệu cấu hình, yêu cầu, thiết kế và
kiểm thử.
200
