Đề tài kiểm thử tích hợp

Mục tiêu là đề kiểm thử các bộ phận và xây dựng một cầu trúc chương trình đã được kiểm thử chính tả khi thiết kế Thường có xu hướng cô gắng thực hiện tích hợp không theo trình tự từng b

TRƯỜNG ĐẠI HỌC PHƯƠNG ĐÔNG

KHOA CONG NGHE THONG TIN VA TRUYEN THONG

KIEM THU TICH HOP

Giáo viên hướng dan: ThS/TS Va Thi Thương

Sinh viên thực hiện: Phan Mạnh Đức — 521100138

Nguyễn Văn Hệ - 521100145 Nguyễn Trung Hiếu — 521100146

Mục Lục

2.1 TOP-DOWN INTERGRATION (KIEM THU TICH HOP TU TREN XUONG DUG)) 8 2.2 BOTTOM-UP INTERGRATION (KIEM THU TiCH HGP TU DUGI LÊN! 11 2.3 REGRESSION TESTING (KIEM THU HOI QUY)

2.4 KIEM THU TICH HOP BIG BANG

CHUGNG 3: DEMO CHUGNG TRINH

3.1 GIGI THIEU VE NET VA NUNIT

a) NET Framework

b) NUnit va Tam Quan Trong cia Kiém Thit

c) Ly Do Chon NET va NUnit

3.2 CHƯƠNG TRÌNH QUAN LY THONG TIN SINH VIÊN

3.5 Kết quả kiểm thử

Trong ngảnh kỹ nghệ phần mềm, năm 1979, có một quy tắc nỗi tiếng là:

“Trong một dự án lập trình điển hình, thì xấp xỉ 50% thời gian và hơn 50% tổng chỉ

phí được sử dụng trong kiểm thử các chương trình hay hệ thống đã được phát triển" Và cho đến nay, sau gần một phần 3 thế kỷ, quy tắc đó vẫn còn đùng Đã có

rất nhiều ngôn ngữ, hệ thống phát triển mới với các công cụ tích hợp cho các lập

trình viên sử đụng phát triển ngày cảng linh động Nhưng kiểm thử vẫn đóng vai trò

hết sức quan trọng trong bất kỳ dự án phát triển phần mềm nào

Rất nhiều các giáo sư, giảng viên đã từng than phiền rằng: “Sinh viên của chúng ta tốt nghiệp và đi làm mà không có được những kiến thực thực tế cần thiết

về cách đê kiêm thử một chương trình Hơn nữa, chúng ta hiểm khi có được những lời khuyên bổ ích để cung cấp trong các khóa học mở đầu về cách một sinh viên nên làm về kiểm thử và gỡ lỗi các bài tập của họ"

Các tác giả của cuốn sách nối tiếng "The Art of Software Testing" - Nghệ thuật kiểm thử phần mềm, Glenford J Myers, Tom Badgett, Todd M Thomas, Corey Sandler da khang dinh trong cuén sach cua minh rang: "Hau hét cac thành

phan quan trong trong các thủ thuật của một nhà kiểm thử chương trình là kiến thức

về cách đề viết các ca kiểm thứ có hiệu quả" Việc kiêm thử phần mềm thật sự quan trọng trong “đây chuyền" sản xuất phần mềm Đây cũng chính là lý do đề nhóm em nghiên cứu về đề tài này, và chính xác hơn là về kiếm thứ tích hợp mà chúng em sẽ trình bày đưới đây Do còn nhiều khó khăn trong việc thu thập và địch tài liệu nên chúng em sẽ còn nhiều thiêu sót trong khi trình bày, vậy kính mong cô giáo xem xét

và giup dé thém cho chung em

CHUONG 1: TONG QUAN VE KIEM THU TICH HOP

1.1 KIEM THU TICH HOP

Một nhân viên mới chập chững bước vào giới phần mềm có thể sẽ đặt ra một câu

hỏi sau khi tất cả các Mô đun đã được kiêm thứ “Nếu tất cả các Mô đun đều đề riêng

lẻ, tại sao bạn lại nghi ngờ rằng chúng sẽ phát huy tác dụng khi được đặt cùng nhau?"

Tất nhiên, vấn đề là ở chỗ đưa chúng vào một giao diện “cùng nhau" Bạn có thé bi

mắt dữ liệu trong giao diện; mô đun nảy vô ý có những ảnh hướng tiêu cực tới mô đun

khác; các chức năng con khi kết hợp cùng với nhau có thê không tạo ra được chức

nang mong muốn; sự sai lệch ở mức có thê chấp nhận được bị phóng lên thành mức

không thế chấp nhận được, cấu trúc dữ liệu toàn cầu có thé gặp phải nhiều vấn dé That

không may là danh sách này còn rất là dài

Hinh 1: Quan hé gitta cdc giai doan Phat trién phan mém với Kiểm thie phan

mem

Có một phương pháp kiểm thử có hệ thống để xây đựng cấu trúc chương trình

trong khi đó tiến hành các bài kiêm thử đề phát hiện ra lỗi liên quan đến lập giao diện

Mục tiêu là đề kiểm thử các bộ phận và xây dựng một cầu trúc chương trình đã được

kiểm thử chính tả khi thiết kế

Thường có xu hướng cô gắng thực hiện tích hợp không theo trình tự từng bước;

có nghĩa là để xây dựng một chương trình sử dụng phương pháp tiếp cận "tức thời đột

ngột", Tất cả các bộ phan duoc két hợp trước với nhau Toàn bộ chương trình được

kiểm thử dưới dạng tông thê Kết quả là thường xảy ra sự lộn xộn! Bạn gặp phải hàng

4

loạt lỗi Việc sửa lỗi là rất khó vì việc cô lập các nguyên nhân rất phức tạp do chương trinh quá rộng

Một khi đã sửa được các lỗi này, các lỗi khác sẽ lại xuất hiện và quá trình cứ tiếp

diễn liên tục như thể

Tích hợp theo trình tự từng bước mâu thuẫn với phương pháp tiếp cận "tức thời" Chương trình được thiết lập và kiểm thử trong các gia lượng nhỏ, nơi dễ tách và sửa lỗi hơn; giao diện có khả năng được kiêm thử toàn bộ hơn; và có thê áp dụng một

phương pháp kiêm thứ có hệ thống

Phương pháp kiếm thử được nói đến ở đây là phương pháp kiểm thử tích hợp

1.2 DAC DIEM CUA KIEM THU TICH HOP

— Là một kiểu kiêm thứ cao cấp hơn kiêm thử đơn vị (Unit testing) nhung lai được xếp thấp hơn kiểm thử hệ thống (System testine) và kiếm thử người dung (User Acceptance Testing)

— Được thực hiện sau kiểm thứ đơn vị nhưng trước kiêm thử hệ thống

— _ Thường xuyên phát hiện được lỗ hồng cũng như các lỗi của hệ thông

—_ Có thể áp dụng cho việc phát triển tự do

Các Unit và component đơn gián l

Intergration Test Các nhóm Unit

Greta eee Toàn bộ hệ |

1.3 TRƯỜNG HỢP SỬ DỤNG KIEM THU TICH HOP

—_ Khi hệ thống là rất lớn (“500K + LOC")

—_ Khi hệ thống là cả phần mềm và phần cứng Toàn bộ hệ thống Toàn bộ hệ thống

nhìn từ phía khách hàng

—_ Khi có quá nhiều lỗi trong giai đoạn kiểm thử hệ thông và kiểm thử người dùng

—_ Khi bạn có quá nhiều các tương tác giữa các phần mềm

— Khi hệ thống thiết kế là một hệ thống thời gian thực

— Khi ban có yêu cầu cao hơn về hệ thống của mình

1.4 MUC TIEU CUA KIEM THU TICH HOP

Phát hiện lỗi xảy ra giữa các Unit

Tích hợp các Unit thành các hệ thông nhỏ (subsyetem) và cuối cùng là nguyên

hệ thống hoàn chỉnh (system) chuẩn bị cho kiêm thử ở múc hệ thông (system testing) Trong kiểm thử đơn vị các lập trình viên cô gắng phát hiện lỗi liên quan đến chức năng và cấu trúc nội tại của Unit Có một số phép kiểm thử đơn giản trên giao

tiếp với các thành phần liên quan khác, tuy nhiên mọi giao tiếp liên quan đến Unit chỉ

thật sự kiểm tra đầy đủ khi các Unit kết hợp với nhau trong khi thực hiện kiểm thử tích hợp

Trừ một số ít ngoại lệ, kiểm thử tích hợp chỉ nên thự hiện trên các Unit đã được kiểm tra cần thận trước đó bằng kiểm thử đơn vị, và tất cả các lỗi mức Unit đã được sửa chữa Một số người hiểu sai rằng Unit một khi đã qua giai đoạn Unit Test với các

giao tiếp giả lập thì không cần phải thực hiện Intepration Test nữa Thực tế việc tích

hợp giữa các Unit dẫn đến những tình huống hoàn toàn khác Một chiến lược cần quan tam trong Integration Test là nên tích hợp dần từng Unit Một Unit tại một thời điểm được tích hợp vào một nhóm các Unit khác đã tích hợp trước đó và đã hoàn tất các đợt Integration Test trước đó Lúc này, ta chỉ cần kiểm thử giao tiếp của Unit mới thêm vào với hệ thống các Unit đã tích hợp trước đó, điều này sẽ làm cho số lượng can kiểm thử giảm đi rất nhiều, và sai sót sẽ giảm đáng kẻ

Có 4 loại kiém thir trong Integration Test:

— Kiém thir cau tric (Structure Test): Tương tự White Box Test, kiếm thử cấu trúc nhằm bảo đảm các thành phần bên trone của một chương trình chạy đúng và chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình chắng hạn các câu lệnh và nhánh bên trong

—_ Kiểm thử chức năng (Functional Test): Tương tự Black Box Test, kiểm thứ chức năng chỉ chú trọng đến chức năng của chương trình, mà không quan tâm đến cấu trúc bên trong, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật

—_ Kiểm thử hiệu năng (Performance Test): Kiểm thử việc vận hành của hệ thống

— Kiểm thử khả năng chịu tải (Stress Test): Kiểm thử các giới hạn của hệ

1.5 CAC BUOC KIEM THU TICH HOP KIEM TRA TICH HỢP

Buéc 1: Thiét lap kế hoạch kiêm thử

Bước 2: Thiết lập các bài và đữ liệu kiếm thử

Bước 3: Tạo các tập lệnh đề thực hiện các bài kiểm thứ nếu có thê

Bước 4: Một khi tất cả các bộ phan đã được tích hợp, thực hiện các bài kiêm thử Bước 5: Và lỗi nếu có và kiếm thử mã

Bước 6: Lặp lại quy trình kiểm thử cho đến khi tất cả các bộ phận đã được tích

hợp thành công

Í Phầnmềm đã Ì (Kế hoạch kiểm \ ( Sơ đổ phát Ì ( Các tiêu chuẩn để được `

được phát triên tra trién người đùng chấp nhận

Hình 3: Các bước kiểm thứ tích hợp kiêm tra tích hợp

1.6 KẺ HOẠCH KIEM TRA

Nó mô tả một trong các yêu tô sau:

— Các bài kiêm tra sẽ được tiên hành như thê nào

— Danh sách các đôi tượng cần được kiêm tra

— Vai tro va trach nhiệm

— Yéu cau tién quyét dé bat dau kiém tra

— Kiểm tra môi trường

—_ Giả thuyết

—_ Làm gi sau khi kiểm tra thành công

—_ Làm gì khi kiểm tra không thành công

1.7 CACH VIET MOT BAI KIEM TRA TICH HOP

Một bài kiểm thứ đơn giản miêu tả chính xác bài kiêm tra sẽ được thực hiện như

thế nào Các bài kiểm thử tích hợp tập trung vào dòng lưu chuyên đữ liệu thông tin kiểm soát từ một bộ phân sang một bộ phận khác

Vì thế các bài kiêm thử tích hợp phải tập trung vào những tình huống trong đó một bộ phận được gọi ra từ một bộ phận khác Tương tự toàn bộ chức năng áp dụng phải được kiếm thử đề đảm bảo rằng các áp dụng phát huy tác dụng khi các bộ phận khác nhau được đặt cùng nhau

Các bài kiểm thứ tích hợp được đưa vào thành một nhóm từ một bộ các bài kiếm thử tích hợp Mỗi bộ có thể tập trung vào một đối tượng khác nhau Nói cách khác, các

bộ kiểm thử khác nhau có thê được tạo ra để tập trung vào các lĩnh vực áp dụng khác nhau

Như đã nêu phía trước, một nhóm kiểm thứ có thể được tạo ra đề thực hiện các

bài kiểm tra Vì thế các bài kiểm thử phải càng chỉ tiết cảng tốt Bảng ví dụ bài kiêm

thử:

ID bai : : - : | Thanh

F Mô tả bài kiêm | Dữ liệu | Kêt quả mong | Kêt qua| - ae

kiém - B - ~ công/không | Ghi chú

- thử đâu vào | đợi thực - -

1.8 LAM VIEC DE HUONG TOI MOT BAI KIEM TRA TICH HOP HIEU QUA

Có rất nhiều yếu tổ ảnh hưởng đến kiểm tra tích hợp phần mềm và kiểm tra phần mềm:

1) Quản lý cầu trúc phần mềm: Do kiểm thử tích hợp tập trung vào việc tích hợp các bộ phận và các bộ phận có thê được xây dụng bằng những người phát triển khác nhau và thậm chí bởi những nhóm phát triên khác nhau, điều quan trọng là phiên bản các bộ phận được kiểm tra Điều này nghe có vẻ rất là cơ bản, nhưng vấn đề lớn nhất

gặp phải là tích hợp phiên phản các bộ phận chính xác Kiểm tra tích hợp có thê thực

hiện sau vài lần lặp lại và và lỗi mà các bộ phân có thé thay đổi Vì thế, điều quan trong là một chính sách quản lý cấu trúc phần mềm (SCM) phai co san Chung ta phải

có khả năng tìm các bộ phận và các phiên bản của chúng Vì thể mỗi khi ta tích hợp các bộ phận ứng dụng, chúng ta biết chính xác phiên bản này sẽ đi vào quá trình xây dựng

2) Qúa trình xây dựng tự động nếu cần thiết: sẽ có rất nhiều lỗi do phiên bản không chính xác các bộ phận được gửi cho quá trình xây dựng hoặc thiều một số bộ phận Nêu có thé, viết một tập lệnh để tích hợp và triển khai các bộ phan Điều nảy sẽ

giảm các lỗi thủ công

3) Tài liệu: xắp xếp tài liệu quá trinh tích hợp xây dựng để loại bỏ các lỗi do bỏ

qua hoặc không nhìn thấy Người chịu trách nhiệm tích hợp các phần mềm có thể quên

chạy tập lệnh yêu cầu và quá trình kiêm thử tích hợp sẽ không cho kết quả chính xác 4) Tìm kiếm lỗi: Kiếm thử tích hợp sẽ mất hướng nếu không phát hiện chính xác

lỗi Mỗi lỗi phải được ghi lại vả tìm kiếm Thông tin phải chỉ rõ cách và lỗi Đây là

thông tin vô giả Nó có thể giúp hỗ trợ quá trình tích hợp và thực hiện trong tương lai Trong các phần sau đây trình bày một số phương pháp kiêm thử tích hợp khác nhau

CHƯƠNG 2: CÁC PHƯƠNG PHÁP KIEM THU TICH HỢP

2.1 TOP-DOWN INTERGRATION (KIEM THU TICH HOP TU TREN XUONG DUOD

Kiểm thử tích hợp từ trên xuống đưới là một phương pháp gia lượng áp dụng cho việc xây dựng cấu trúc chương trình Các mô đun được tích hợp bằng cách di chuyên theo chiều hướng xuống theo trình tự kiểm soát cấp bậc, bắt đầu bằng mô đun điều khiển chính (chương trình chính) Các mô đun phụ (và các mô đun sau cùng) đến mô đun điều khiển chính được phép lại thành một cầu trúc hoặc là theo lối nhanh nhất hoặc lâu nhat (depth-first or bread-first manner)

Hinh 4: Kiém thứ từ trên xuống Xem hình 2, tích hợp depth-ñrst sẽ tích hợp tất cả các bộ phận vào một đường điều khiến của cấu trúc Việc lựa chọn con đường là rất mơ hồ va phụ thuộc vào đặc điểm ứng dụng cụ thể Ví đụ, lựa chọn đường theo chiều tay trái, các bộ phận MI, M2,

M5 sẽ được tích hợp trước tiếp đó M8 hoặc (nếu cần chức năng phù hợp của M2) M6

sẽ được tích hợp Sau đó, phương pháp điều khiến bàn tay phải và trung tâm sẽ được xay dung Breadth-first integration két hyp tat cả các bộ phận bồ sung trực tiếp ở mỗi mức độ, chuyên qua cấu trúc theo phương ngang Từ hình vẽ, các bộ phận M2, M3, và M4 (thay cho S4) sẽ được tích hợp trước Mức điều khiến tiếp theo, và cứ tiếp tục như

thế

Quá trình tích hợp được thực hiện trong 5 bước:

10

— Mô đun điều khiển chính được sử dụng làm bộ điều khiến kiểm thứ và các mô đun tiếp theo bô sung cho tất cả các bộ phận bô sung trực tiếp cho mô đun điều khiển

chinh

- Tuy thuộc vào phương pháp tích hợp được chọn (vi du depth or breadth first), các

mô đun bổ sung tiếp theo được thay thế theo trình tự với các bộ phận thực

—_ Các bài kiểm thử sẽ được tiến hành khi mỗi mô đun được tích hợp

— Khi hoàn thành từng bài kiểm thử một, các bộ phan tiếp theo sẽ được thay thế bởi

bộ phận thực Kiểm thử hồi quy (phần V) có thể được tiến hành để đảm bảo

không xảy ra lỗi mới

Quá trinh tiếp tục từ bước thứ hai cho đến khi toàn bộ cấu trúc chương trình được xây dựng

Các bước tích hợp theo hướng từ trên xuống kiếm thử các điểm điều khiến hoặc quyết định chính ở phần đầu quá trình kiểm thử trong một câu trúc chương trình được với hệ số rõ ràng, việc đưa ra quyết định sẽ diễn ra ở các bậc cao hơn theo trình tự và

vì thế được bắt gặp đầu tiên Nếu tồn tại các vấn đề điều khiến chính, việc phát hiện ra sớm là vô cùng cần thiết Nếu chọn phương pháp tích hợp đepthfirst, có thế tiến hành

và trình bày một chức năng hoàn chỉnh của phần mềm Ví dụ, piả sử một cấu trúc chuyên giao trong đó có một chuỗi các đầu vào tương tác với nhau được yêu cầu, thực hiện và hợp thức hóa qua một đường đền Đường đến có thể được tích hợp theo cách

từ trên xuống dưới Tất cả các đầu vào xử lý (để chuyên đi sau này) có thê được thể hiện trước khi các yếu tố khác của cấu trúc đã được tích hợp Việc thê hiện ngay từ đầu

khả năng mang chức năng là rất có ích đối với người phát triển và khách hảng

Phương pháp từ trên xuống có vẻ không phức tạp, nhưng trên thực tế, có thể này sinh các vấn đề logic Một trong những vấn đề thường gặp xảy ra khi xử lý ở mức thấp theo thứ tự được yêu cầu đề kiểm thử ở các mức cao hơn Các mô đun phụ thay thế các

mô đun mức thấp ở giai đoạn đầu của quá trình kiểm thử từ trên xuống Vì thế, không

có bất kì đữ liệu đáng kế nào có thê chuyên lên trên trong cấu trúc chương trình Người

kiểm thử sẽ đứng giữa 3 lựa chọn:

— Hoãn các bài kiểm thử lại cho đến khi các mô đun phụ được thay thế bằng mô đun thực

—_ Phát triển các mô đun phụ thực hiện các chức năng hạn chế thức đây mô đun thực

—_ Tích hợp phần mềm từ dưới lên trên

11

Phương pháp đầu tiên (hoãn các bải kiểm thử lại cho đến khi các mô đun phụ

được thay thế bằng mô đun thực) làm cho chúng ta mất điều khiến giữa các bài kiêm thử cụ thê và sự kết hợp các mô đun cụ thể Việc nảy có thê dẫn tới khó khăn trong việc xác định nguyên nhân gây lỗi và có xu hướng vì phạm bản chất giới hạn của phương pháp từ trên xuống Phương pháp thứ 2 có thê phát huy tác đụng nhưng có thế dẫn đến tình trạng phải thực hiện thêm nhiều bước nữa, vì các mô đun phụ trở nên ngay cảng phức tạp Phương pháp thứ 3, gọi là kiếm thử từ dưới lên, được trình bày trong phan tiếp theo

Ví dụ: Khi cần xây dựng một hệ thống quản lý bản hàng điện tử có mô hình như hình dưới đây:

Kiem trahang | | | Lập phiêu đặt Kiêm tra phiêu Lập báo cáo

trong kho hang bảo hành doanh thu

- Lập hoá đơn | Kiem tra chat | | [ Lập phiêu báo Báo cáo TB

lượng hàng hành FˆÌ đã bán

Lập hoá đơn Báo cáo TB

tôn kho

Thanh toán Thông báo từ

Đâu tiên khi muốn xây đựng hệ thống ta phải xây dựng các chức năng chính của

hệ thống như chức năng quản lý bán hàng, quản lý nhập hàng, quản lý bảo hành, báo cáo thông kê Sau đó mới có thể xây dựng tiếp các chức năng con khác sau

Ta có lập một sơ đỗ tích hợp các chức năng của hệ thống quản lý bán hàng như

12

QL Bán Hàng

| Kiém tra hang Lap hoa Giao hang Thanh toan Thông báo từ

| trong kho đơn chôi xuât

— Việc phát hiện lỗi đễ đàng hơn

— _ Có khả năng thực hiện tích hợp từ trên xuống từ sớm

—_ Các module quan trọng được ưu tiên kiểm thử; lỗi thiết kế quan trọng có thê được tìm thấy và sửa chữa đầu tiên

Nhược điểm:

—_ Cần nhiều Stub

—_ Các module ở mức thấp hơn không được kiếm thử đầy đủ

2.2 BOTTOM-UP INTERGRATION (KIÊM THỬ TÍCH HỢP TỪ DƯỚI LÊN)

Kiểm thử tích hợp từ dưới lên, như tên gọi của nó, bắt đầu xây dựng và kiếm thử bằng các mô đun nguyên tử (có nghĩa là các bộ phận ở mức thấp nhất trong cấu trúc chương trình) Do các bộ phận được tích hợp từ dưới lên, việc xử lý yêu cầu đối với các bộ phận bô sung cho một mức cho trước luôn có sẵn và loại bỏ yêu cầu cần các mô dun bé sung

Phương pháp tích hợp từ dưới lên có thê được tiến hành theo các bước sau:

— Các bộ phận ở mức thấp được kết hợp với nhau thành một nhóm thực hiện chức

—_ Các Driver được loại bỏ và nhóm được kết hợp di chuyên lên trên trong cầu trúc

chương trỉnh

Tích hợp tiên hành theo các bước trình bày trong hình 3 Các bộ phận được kết

hợp đề hình thành nhóm l1, 2 và 3 Mỗi nhóm được kiếm thử bằng driver (trình bảy

dưới dạng block nét đứt) Các bộ phận trong nhóm 1 va 2 bé sung cho Ma Drivers D1

và D2 được loại bỏ và nhóm được lập s1ao diện trực tiếp cho Ma Tuong ty, driver D3 cho nhóm 3 được loại bỏ trước khi tích hợp bằng mô đun Mb Ca Ma và Mb sẽ được tích hợp bằng bộ phận Mc, và cứ như thế

Hình 5: Kiểm thử từ dưới lên

Khi tích hợp di chuyên lên phía trên, yêu cầu tách các driver kiêm thử giảm dân

Thực tế, nếu 2 mức trên củng của câu trúc chương trình được tích hợp từ trên xuống,

số lượng driver có thê giảm đi và quá trình tích hợp của nhóm sẽ đơn giản hơn nhiều

Vi dụ Xây dựng hệ thống quản lý thư viện :

Khi thư viên của nhà trường có phòng lưu trữ sách thì sẽ có nhu cầu có một phòng ban quản lý các đầu sách, số lượng cùng loại, tình trạng của sách trong thư viện thì sẽ phải thành lập một phòng quản lý sách Sách của nhà trường lại có khả năng cho sinh viên trong trường mượn để có thê học tập và ngiên cứu nên củng với phòng quản

lý sách các yêu câu mượn sách tạo lên một phòng mượn sách Sau khi nghiên cứu xong sách sinh viên lại có nhu cầu trả sách đề có thê mượn sách khác và bộ phận quản

lý trả sách được thành lập Dựa vào các thành phần đã nêu trên nhà trường có thể thành lập một thư viện sách với các chức năng quản lý sách, cho mượn sách tủy vào yêu

14