Bài giảng Công nghệ phần mềm - Bài 4: Quản lý chất lượng phần mềm - Lê Nguyễn Tuấn Thành

Công nghệ Phần mềm
Quản lý chất lượng phần mềm
Giảng viên: Lê NguyễnTuấnThành
Email: thanhlnt@tlu.edu.vn
Bộ Môn Công Nghệ Phần Mềm – Khoa CNTT
Trường Đại Học Thủy Lợi
Nội dung
2
} Quản lý chất lượng
} Chất lượng phần mềm
} Các hoạt động đảm bảo chất lượng phần mềm
} Kiểm thử phần mềm
} Bảo trì phần mềm
1. Quản lý Chất lượng
Quality Management
3
Mục tiêu
4
} Giới thiệu quy trình quản lý chất lượng và các hoạt
động quản lý chất lượng chính.
} Giải thích vai trò của các tiêu chuẩn trong quản lý
chất lượng
} Giải thích các khái niệm về thước đo phần mềm,
thước đo dự báo và thước đo kiểm soát
} Giải thích cách đo lường có thể được sử dụng trong
đánh giá chất lượng phần mềm và những hạn chế
của các phép đo phần mềm
Chủ đề đề cập
(Topics covered)
5
} Quy trình và chất lượng sản phẩm
} Đảm bảo chất lượng và tiêu chuẩn
} Lập kế hoạch chất lượng
} Kiểm soát chất lượng
Quản lý Chất lượng Phần mềm
(Software quality management)
6
} Liên quan đến việc đảm bảo đạt được mức độ yêu
cầu về chất lượng trong một sản phẩm phần mềm.
} Liên quan đến việc định nghĩa các tiêu chuẩn chất
lượng phù hợp và các thủ tục và đảm bảo rằng
những điều này được tuân thủ.
} Hướng tới xây dựng một ‘văn hóa chất lượng’, nơi
chất lượng được coi là trách nhiệm của mọi người.
Chất lượng là gì?
7
} Chất lượng, theo cách đơn giản, có nghĩa là một
sản phẩm phải đáp ứng các đặc tả của nó.
} Một số vấn đề đối với các hệ thống phần mềm:
} Có sự khác biệt giữa yêu cầu chất lượng của khách hàng
(hiệu quả, độ tin cậy, v.v.) và yêu cầu về chất lượng của
nhà phát triển (khả năng bảo trì, khả năng sử dụng lại,
v.v.)
} Một số yêu cầu về chất lượng rất khó xác định một cách
rõ ràng
} Đặc tả phần mềm thường không đầy đủ và thường không
nhất quán.
Hoạt động Quản lý Chất lượng
(Quality management activities)
8
} Đảm bảo chất lượng (Quality assurance)
} Thiết lập quy trình và tiêu chuẩn tổ chức cho chất lượng.
} Lập kế hoạch chất lượng (Quality planning)
} Chọn các thủ tục và tiêu chuẩn có thể áp dụng cho một
dự án cụ thể và thay đổi chúng khi có yêu cầu.
} Kiểm soát chất lượng (Quality control)
} Đảm bảo rằng các quy trình và tiêu chuẩn được tuân sau
bởi nhóm phát triển phần mềm.
Quản lý chất lượng nên tách biệt với quản lý dự án 
để đảm bảo sự độc lập.
Quản lý Chất lượng và Phát triển Phần mềm
(Quality management and software development)
9
Quy trình và Chất lượng Sản phẩm
(Process and product quality)
10
} Chất lượng của một sản phẩm được phát triển bị
ảnh hưởng bởi chất lượng của quá trình sản xuất.
Chất lượng dựa trên Quy trình (1/2)
(Process-based quality)
11
} Có một liên kết minh bạch (straightforward) giữa quy
trình và sản phẩm trong hàng hoá sản xuất.
} Điều này phức tạp hơn với phần mềm bởi vì:
} Việc áp dụng các kỹ năng và kinh nghiệm cá nhân đặc
biệt quan trọng trong phát triển phần mềm;
} Các yếu tố bên ngoài như tính mới của ứng dụng hoặc
sự cần thiết của lịch trình phát triển nhanh có thể làm
giảm chất lượng sản phẩm.
} Cần phải chú ý không áp đặt các tiêu chuẩn quy
trình không phù hợp - điều này có thể làm giảm chứ
không phải cải thiện chất lượng sản phẩm.
Chất lượng dựa trên Quy trình (2/2)
(Process-based quality)
12
Đảm bảo Chất lượng và Tiêu chuẩn
(Quality assurance and standards)
13
} Tiêu chuẩn là chìa khóa để quản lý chất lượng có hiệu
quả.
} Đóng gói các kinh nghiệm thực tiễn tốt nhất - tránh lặp lại những sai
lầm trong quá khứ.
} Là một khung làm việc cho các quy trình đảm bảo chất lượng -
bao gồm việc kiểm tra sự tuân thủ các tiêu chuẩn.
} Cung cấp sự liên tục - nhân viên mới có thể hiểu được tổ chức
bằng cách hiểu các tiêu chuẩn đang được sử dụng.
} Đó có thể là tiêu chuẩn quốc tế, quốc gia, tổ chức hoặc dự án.
} Tiêu chuẩn sản phẩm định nghĩa các đặc tính mà tất cả
các thành phần nên biểu thị
} VD: một phong cách lập trình phổ biến.
} Tiêu chuẩn quy trình định nghĩa cách thức ban hành quy
trình phần mềm.
Tiêu chuẩn Sản phẩm và Quy trình
(Product and process standards)
14
Tiêu chuẩn sản phẩm Tiêu chuẩn quy trình
Mẫu duyệt lại thiết kế
(Design review form)
Hướng dẫn duyệt lại thiết kế
(Design review conduct)
Cấu trúc tài liệu yêu cầu Nộp hồ sơ lên CM
Định dạng tiêu đề phương 
thức
Quy trình phát hành phiên bản
Phong cách lập trình Java Quy trình phê duyệt kế hoạch dự
án
Định dạng kế hoạch dự án Quá trình kiểm soát thay đổi
Mẫu yêu cầu thay đổi Quy trình ghi chép kiểm thử
ISO 9000
15
} Một bộ tiêu chuẩn quốc tế về quản lý chất lượng.
} Có thể áp dụng cho một khoảng các tổ chức từ sản
xuất đến ngành công nghiệp dịch vụ.
} ISO 9001 có thể áp dụng cho các tổ chức thiết kế, phát
triển và duy trì sản phẩm.
} Một mô hình chung của quy trình chất lượng phải được
khởi tạo cho mỗi tổ chức sử dụng tiêu chuẩn.
ISO 9001
16
Trách nhiệm quản lý Hệ thống chất lương
Kiểm soát các sản phẩm không phù hợp Kiểm soát thiết kế
(Design control)
Xử lý, lưu trữ, đóng gói và phân phối Thu mua 
(Purchasing)
Các sản phẩm do người mua cung cấp Xác định và truy xuất nguồn gốc sản 
phẩm
Kiểm soát quy trình
(Process control)
Kiểm tra và kiểm thử
(Inspection and testing)
Thiết bị kiểm tra và kiểm thử Trạng thái kiểm tra và kiểm thử
Xem xét hợp đồng 
(Contract review)
Hành động khắc phục
(Corrective action)
Kiểm soát tài liệu
(Document control)
Hồ sơ chất lượng
(Quality records)
Kiểm toán chất lượng nội bộ Đào tạo (Training)
Phục vụ (Servicing) Kỹ thuật thống kê
Chứng nhận ISO 9000
(ISO 9000 certification)
17
} Các tiêu chuẩn và quy trình chất lượng phải được
ghi chép trong một cuốn cẩm nang chất lượng tổ
chức.
} Một cơ quan bên ngoài có thể chứng nhận rằng tài
liệu hướng dẫn chất lượng của tổ chức tuân theo
tiêu chuẩn ISO 9000.
} Một số khách hàng yêu cầu các nhà cung cấp được
chứng nhận ISO 9000 mặc dù sự cần thiết phải linh
hoạt ở đây ngày càng được công nhận.
ISO 9000 và Quản lý Chất lượng
(ISO 9000 and Quality management)
18
Tiêu chuẩn Tài liệu hóa
(Documentation standards)
19
} Đặc biệt quan trọng - tài liệu là sự biểu hiện hữu hình của
phần mềm.
} Tiêu chuẩn quy trình tài liệu
} Liên quan đến cách thức phát triển, xác thực và duy trì
các tài liệu.
} Tiêu chuẩn tài liệu
} Liên quan đến nội dung, cấu trúc, và sự xuất hiện tài liệu
} Tiêu chuẩn trao đổi tài liệu
} Liên quan đến tính tương thích của tài liệu điện tử.
Quy trình Tài liệu hóa
(Documentation process)
20
Lập kế hoạch Chất lượng
(Quality planning)
21
} Kế hoạch chất lượng đưa ra các chất lượng sản
phẩm mong muốn và cách chúng được đánh giá và
định nghĩa các thuộc tính chất lượng quan trọng
nhất.
} Nên định nghĩa quá trình đánh giá chất lượng.
} Nên đặt ra các tiêu chuẩn tổ chức nên được áp dụng và,
nơi cần thiết, xác định các tiêu chuẩn mới được sử dụng.
Kế hoạch Chất lượng
(Quality plans)
22
} Cấu trúc kế hoạch chất lượng:
} Giới thiệu sản phẩm
} Các kế hoạch sản phẩm
} Miêu tả quy trình
} Các mục tiêu chất lượng
} Rủi ro và quản lý rủi ro
Các thuộc tính Chất lượng Phần mềm
(Software quality attributes)
23
An toàn
(Safety)
Có thể hiểu được
(Understandability)
Tính di động
(Portability)
Bảo mật
(Security)
Khả năng kiểm tra
(Testability)
Tính khả dụng
(Usability)
Độ tin cậy
(Reliability)
Tính tương thích
(Adaptability)
Khả năng tái sử
dụng
(Reusability)
Khả năng phục hồi
(Resilience)
Tính mô-đun
(Modularity)
Hiệu quả
(Efficiency)
Độ bền
(Robustness)
Độ phức tạp
(Complexity)
Khả năng học
(Learnability)
Kiểm soát Chất lượng
(Quality control)
24
} Liên quan việc kiểm tra quy trình phát triển phần
mềm để đảm bảo rằng các quy trình và tiêu chuẩn
đang được tuân thủ.
} Có hai phương pháp để kiểm soát chất lượng
} Duyệt/Rà soát lại chất lượng (Quality reviews);
} Đánh giá phần mềm và đo lường phần mềm tự động
Soát lại Chất lượng (1/2)
(Quality reviews)
25
} Là phương pháp chính để xác thực chất lượng của 
một quy trình hoặc một sản phẩm.
} Một nhóm sẽ kiểm tra một phần hoặc toàn bộ quy 
trình (mã chương trình, thiết kế, đặc tả, kế hoạch kiểm 
thử, tiêu chuẩn, v.v.) hoặc hệ thống và tài liệu của nó 
để tìm ra các vấn đề tiềm ẩn.
Soát lại Chất lượng (2/2)
(Quality reviews)
26
} Có nhiều kiểu soát lại khác nhau với các mục tiêu khác
nhau:
} Kiểm tra để loại bỏ khiếm khuyết (sản phẩm): Để phát
hiện các lỗi chi tiết trong các yêu cầu, thiết kế hoặc mã
chương trình. Một danh sách kiểm tra các lỗi có thể có sẽ
điều khiển việc soát lại này.
} Soát lại về đánh giá tiến độ (sản phẩm và quy trình):
Cung cấp thông tin để quản lý về tiến độ chung của dự
án. Đây là việc soát lại cả quy trình và sản phẩm và liên
quan đến chi phí, kế hoạch và lịch trình.
} Soát lại chất lượng (sản phẩm và tiêu chuẩn): Thực hiện
phân tích kỹ thuật các thành phần hoặc tài liệu sản phẩm
để tìm ra sự không khớp giữa đặc tả và thiết kế thành
phần, đoạn mã hoặc tài liệu và đảm bảo rằng các tiêu
chuẩn chất lượng đã định nghĩa được tuân thủ.
Kết quả của việc soát lại
(Review results)
27
} Nhận xét trong quá trình soát lại được phân loại
thành:
} Không cần có hành động gì thêm. Không yêu cầu thay
đổi phần mềm hoặc tài liệu;
} Tham khảo để sửa chữa. Người thiết kế hoặc lập trình
nên sửa các lỗi đã xác định;
} Xem lại thiết kế tổng thể. Vấn đề được xác định trong
việc soát lại ảnh hưởng đến các bộ phận khác của thiết
kế. Một vài phán quyết tổng thể phải được đưa ra về
cách hiệu quả nhất về chi phí để giải quyết vấn đề;
} Các lỗi yêu cầu và đặc tả có thể phải được chuyển
tới khách hàng.
Thước đo và Đo lường Phần mềm
(Software measurement and metrics)
28
} Đo lường phần mềm liên quan đến việc tìm ra một
giá trị bằng số cho một thuộc tính của sản phẩm
phần mềm hoặc quy trình.
} Cho phép so sánh khách quan giữa các kỹ thuật và quy trình
khác nhau.
Thước đo Phần mềm
(Software metric)
29
} Là bất kỳ loại phép đo nào liên quan đến hệ thống
phần mềm, quy trình hoặc tài liệu liên quan
} Số dòng mã trong chương trình, chỉ số Fog, số ngày
người/ngày cần thiết để phát triển một thành phần.
} Cho phép lượng hóa phần mềm và quy trình phần mềm.
} Có thể được sử dụng để dự đoán các thuộc tính của sản
phẩm hoặc để kiểm soát quy trình phần mềm.
} Thước đo sản phẩm có thể được sử dụng cho các
dự đoán chung hoặc để xác định các thành phần bất
thường.
Thước đo Dự báo và Kiểm soát
(Predictor and control metrics)
30
Thuộc tính Bên trong và Bên ngoài
(Internal and external attributes)
31
Quy trình Đo lường
(Measurement process)
32
} Một quy trình đo lường phần mềm có thể là một
phần của quá trình kiểm soát chất lượng.
} Dữ liệu thu thập được trong quá trình này cần được
duy trì như là một nguồn lực tổ chức.
} Một khi cơ sở dữ liệu đo lường đã được thiết lập, sự
so sánh giữa các dự án trở nên khả thi.
Quy trình Đo lường Sản phẩm
(Product measurement process)
33
Thước đo Sản phẩm
(Product metrics)
34
} Một thước đo chất lượng nên là chỉ số dự báo về 
chất lượng sản phẩm.
} Phân loại thước đo sản phẩm:
} Thước đo động được thu thập bằng các phép đo được 
thực hiện với một chương trình đang chạy: giúp đánh giá 
hiệu quả và độ tin cậy.
} Thước đo tĩnh được thu thập bằng các phép đo được 
tạo ra từ các biểu diễn của hệ thống: giúp đánh giá mức 
độ phức tạp, tính dễ hiểu và khả năng bảo trì.
Thước đo Sản phẩm Phần mềm
(Software product metrics)
35
TĐ phần mềm 
(Software metric) Miêu tả
Fan-in/Fan-out Fan-in là thước đo số chức năng hoặc phương thức gọi một hàm hoặc
phương thức khác (X). Fan-out là số chức năng được gọi bởi hàm X. Một
giá trị cao của fan-in có nghĩa là X liên kết chặt chẽ với phần còn lại của
thiết kế và sự thay đổi với X sẽ có ảnh hưởng rộng. Một giá trị cao của fan-
out gợi ý rằng độ phức tạp tổng thể của X có thể cao bởi vì sự phức tạp
của logic kiểm soát cần thiết để phối hợp các thành phần được gọi.
Chiều dài đoạn mã
(Length of code)
Đây là thước đo về kích thước của một chương trình. Nói chung, kích
thước đoạn mã của một thành phần càng lớn thì thành phần đó càng phức
tạp và dễ bị lỗi. Độ dài đoạn mã đã được chứng minh là một trong những
thước đo đáng tin cậy nhất để dự đoán sai sót trong các thành phần.
Độ phức tạp chu kỳ
(Cyclomatic complexity)
Đây là một thước đo của độ phức tạp kiểm soát của một chương trình. Độ
phức tạp kiểm soát này có thể liên quan đến tính dễ hiểu của chương trình.
Chiều dài của định danh
(Length of identifiers)
Đây là thước đo độ dài trung bình của các định danh khác biệt trong một
chương trình. Định danh càng dài thì chúng càng có ý nghĩa và do đó
chương trình càng dễ hiểu hơn.
Độ sâu của các lệnh
lồng có điều kiện
Đây là thước đo độ sâu của việc lồng các mệnh đề if trong một chương
trình. Mệnh đề if lồng nhau sâu thì sẽ khó hiểu và dễ tiềm ẩn lỗi.
Chỉ số Fog
(Fog index)
Đây là thước đo độ dài trung bình của các từ và câu trong tài liệu. Giá trị
của chỉ số Fog càng cao, tài liệu đó càng khó hiểu.
Thước đo Hướng đối tượng
(Object-oriented metrics)
36
TĐ hướng đối tượng 
(Software metric) Miêu tả
Độ sâu của cây thừa kế Điều này thể hiện số lượng các mức rời rạc trong cây thừa kế nơi lớp con kế
thừa các thuộc tính và hành động (phương pháp) từ lớp cha. Cây kế thừa
càng sâu, thiết kế càng phức tạp.
Phương thức fan-in / 
fan-out
Điều này liên quan trực tiếp đến fan-in và fan-out như được mô tả ở trên và
có ý nghĩa cơ bản giống nhau. Tuy nhiên, có thể phân biệt giữa các lời gọi từ
các phương thức khác bên trong đối tượng và các lời gọi từ các phương thức
bên ngoài.
Phương thức trọng số 
cho lớp
Đây là số lượng phương thức bao gồm trong một lớp, được tính trọng số bởi
độ phức tạp của mỗi phương thức. Do đó, một phương thức đơn giản có thể
có độ phức tạp là 1 và một phương pháp lớn và phức tạp có giá trị cao hơn.
Giá trị thước đo càng lớn, lớp đối tượng càng phức tạp. Các đối tượng phức
tạp nhiều khả năng sẽ khó hiểu hơn. Chúng có thể không liên kết hợp lý nên
không thể sử dụng lại hiệu quả như các lớp cha trong một cây thừa kế.
Số lượng thao tác ghi 
đè
(Overriding operations)
Đây là số lượng các thao tác trong một lớp cha được ghi đè trong một lớp
con. Một giá trị cao cho thấy lớp cha được sử dụng có thể không phải là lớp
cha thích hợp cho lớp con.
Tóm tắt những điểm chính
(Key points)
37
} Quản lý chất lượng phần mềm liên quan đến việc đảm
bảo rằng phần mềm đáp ứng các tiêu chuẩn được yêu
cầu.
} Các thủ tục đảm bảo chất lượng cần được ghi lại trong
sổ tay chất lượng tổ chức.
} Tiêu chuẩn phần mềm là một đóng gói của những thực
hành tốt nhất.
} Soát lại là cách tiếp cận được sử dụng rộng rãi nhất để
đánh giá chất lượng phần mềm.
} Đo lường phần mềm thu thập thông tin về cả quy trình
phần mềm và sản phẩm phần mềm.
} Thước đo chất lượng sản phẩm nên được sử dụng để
xác định các thành phần có khả năng gây ra vấn đề.
} Không có thước đo phần mềm được chuẩn hóa và áp
dụng phổ quát.
2. Kie"m thử Pha&n me&m
Software Testing
38
Mục tiêu
39
} Miêu tả các nguyên tắc của kiểm thử thành phần và kiểm
thử hệ thống
} Thảo luận về sự khác biệt giữa kiểm thử xác thực và
kiểm thử khiếm khuyết
} Miêu tả chiến lược tạo ra các trường hợp kiểm thử
hệ thống
} Hiểu được các đặc tính cơ bản của công cụ được
sử dụng cho tự động hóa kiểm thử
Chủ đề Đề cập
(Topics covered)
40
} Kiểm thử thành phần (component testing)
} Kiểm thử hệ thống (sys ...  bại. Kiểm
thử áp lực kiểm tra sự mất mát không thể chấp nhận
được của dịch vụ hoặc dữ liệu.
} Kiểm thử áp lực đặc biệt có liên quan đến các hệ
thống phân tán có thể có sự xuống cấp nghiêm trọng
khi hệ thống mạng trở nên quá tải.
2.3. Kiểm thử Thành phần
(Component testing)
54
} Kiểm thử thành phần hoặc đơn vị là quá trình kiểm
tra những thành phần riêng lẻ theo cách cô lập.
} Đó là một quy trình kiểm thử khiếm khuyết.
} Thành phần có thể là:
} Các chức năng hoặc phương thức riêng lẻ trong một đối
tượng;
} Các lớp đối tượng với một số thuộc tính và phương thức;
} Các thành phần phức hợp với các giao diện được định
nghĩa được sử dụng để truy cập các chức năng của
chúng.
Kiểm thử Lớp đối tượng
(Object class testing)
55
} Kiểm thử hoàn toàn phạm vi bao trùm của một lớp liên
quan:
} Kiểm tra tất cả các hoạt động liên quan đến một đối
tượng;
} Thiết lập và thẩm tra tất cả các thuộc tính của đối tượng;
} Thử nghiệm các đối tượng trong tất cả các trạng thái có
thể.
} Kế thừa làm cho việc thiết kế kiểm thử lớp đối tượng
trở nên khó khăn hơn vì thông tin được kiểm tra
không được khoanh vùng.
Giao diện Đối tượng Trạm thời tiết
(Weather station object interface)
56
Kiểm thử Trạm thời tiết
(Weather station testing)
57
} Cần định nghĩa các trường hợp thử nghiệm cho các
hàm thành viên: reportWeather(), calibrate(), test(), startup()
và shutdown().
} Sử dụng một mô hình trạng thái, xác định trình tự
của quá trình chuyển đổi trạng thái để được kiểm tra
và trình tự sự kiện gây ra những chuyển tiếp này.
} Ví dụ:
Waiting -> Calibrating ->Testing ->Transmitting ->Waiting
Kie"m thử Giao diện
(Interface testing)
58
} Mục đích là để phát hiện lỗi giao diện hoặc những giả định
không hợp lệ về giao diện.
} Đặc biệt quan trọng đối với sự phát triển hướng đối tượng khi
các đối tượng được định nghĩa bởi các giao diện của chúng.
Các kiểu Giao diện
(Interface types)
59
} Giao diện tham số (Parameter interfaces)
} Dữ liệu được truyền từ thủ tục này sang thủ tục khác.
} Giao diện bộ nhớ chia sẻ (Shared memory interfaces)
} Khối bộ nhớ được chia sẻ giữa các thủ tục hoặc các
hàm.
} Giao diện thủ tục (Procedural interfaces)
} Hệ thống con đóng gói một tập hợp các thủ tục được gọi
bởi các hệ thống con khác.
} Giao diện truyền thông điệp (Message passing
interfaces)
} Các hệ thống con yêu cầu dịch vụ từ các hệ thống con khác
Lỗi giao diện
(Interface errors)
60
} Sử dụng sai giao diện (Interface misuse)
} Một thành phần gọi một thành phần khác và gây ra lỗi 
trong việc sử dụng giao diện của nó, ví dụ: các thông số 
được đặt sai thứ tự.
} Hiểu sai giao diện (Interface misunderstanding)
} Một thành phần gọi các giả định được gắn về hành vi của 
thành phần được gọi mà không chính xác.
} Lỗi thời gian (Timing errors)
} Thành phần được gọi và thành phần gọi hoạt động với 
tốc độ khác nhau và thông tin không cập nhật được truy 
cập.
Hướng dẫn Kiểm thử Giao diện
(Interface testing guidelines)
61
} Kiểm thử thiết kế sao cho các tham số của một thủ
tục được gọi ở các đầu cực trong các khoảng của
chúng.
} Luôn luôn kiểm tra các tham số con trỏ với các con trỏ
null.
} Kiểm thử thiết kế để khiến các thành phần thực thi
thất bại.
} Sử dụng kiểm thử áp lứcj trong các hệ thống truyền
thông điệp.
} Trong các hệ thống bộ nhớ chia sẻ, thay đổi thứ tự
các thành phần được kích hoạt.
2.4. Thiết kế Testcase
62
} Liên quan đến thiết kế các trường hợp thử nghiệm
(đầu vào và đầu ra) được sử dụng để kiểm tra hệ
thống.
} Mục tiêu của thiết kế trường hợp thử nghiệm là tạo
ra một bộ các bài kiểm tra có hiệu quả trong việc
kiểm tra xác thực và khiếm khuyết.
} Các hướng thiết kế:
} Kiểm thử dựa trên yêu cầu;
} Kiểm thử phân vùng (Partition testing);
} Kiểm thử cấu trúc (Structural testing).
Kiểm thử dựa trên Yêu cầu
(Requirements based testing)
63
} Một nguyên tắc chung của kỹ thuật yêu cầu là các yêu
cầu nên có thể kiểm thử.
} Kiểm thử dựa trên yêu cầu là một kỹ thuật kiểm thử
xác thực khi bạn xem xét từng yêu cầu và lấy ra một
bộ kiểm thử cho yêu cầu đó.
VD: Các Yêu cầu của LIBSYS
(LIBSYS requirements)
64
} Người dùng có thể tìm kiếm hoặc tất cả các bộ cơ
sở dữ liệu ban đầu hoặc một tập hợp con.
} Hệ thống sẽ cung cấp những góc nhìn thích hợp cho
người dùng để đọc các tài liệu trong kho tài liệu.
} Mọi đơn hàng sẽ được cấp một số nhận dạng duy
nhất (ORDER_ID) mà người dùng có thể sao chép
vào khu vực lưu trữ vĩnh viễn của tài khoản.
VD: Các Kiểm thử của LIBSYS
(LIBSYS tests)
65
} Khởi tạo tìm kiếm người dùng để tìm kiếm các mục được
biết trước là có sẵn và không có sẵn, với bộ cơ sở dữ
liệu bao gồm 1 cơ sở dữ liệu.
} Khởi tạo tìm kiếm người dùng để tìm kiếm các mục được
biết trước là có sẵn và không có sẵn, với bộ cơ sở dữ
liệu bao gồm 2 cơ sở dữ liệu.
} Khởi tạo tìm kiếm người dùng để tìm kiếm các mục được
biết trước là có sẵn và không có sẵn, với bộ cơ sở dữ
liệu bao gồm nhiều hơn 2 cơ sở dữ liệu.
} Chọn 1 cơ sở dữ liệu từ bộ cơ sở dữ liệu và khởi tạo tìm
kiếm người dùng cho các mục được biết trước là có sẵn
và không có sẵn.
} Chọn nhiều hơn 1 cơ sở dữ liệu từ bộ cơ sở dữ liệu và
khởi tạo tìm kiếm các mục được biết trước là có mặt và
không có mặt.
Kie"m thử Phân vùng 
(Partition testing)
66
} Dữ liệu đầu vào và kết quả đầu ra thường rơi vào
các lớp khác nhau, trong đó tất cả các thành viên
của một lớp có liên quan với nhau.
} Mỗi lớp này là một phân vùng hoặc miền tương
đương mà chương trình ứng xử theo cách tương
đương cho mỗi thành viên của lớp.
} Các trường hợp kiểm tra nên được chọn từ mỗi
phân vùng.
Phân vùng Tương đương
(Equivalence partitioning)
67
Những Phân vùng Tương đương
(Equivalence partitions)
68
Kiểm thử Cấu trúc (1/2)
(Structural testing)
69
} Đôi khi được gọi là kiểm thử hộp trắng (white-box
testing)
} Phát sinh các trường hợp kiểm tra theo cấu trúc
chương trình.
} Kiến thức về chương trình được sử dụng để xác
định các trường hợp thử nghiệm bổ sung.
} Mục tiêu là thực hiện tất cả các câu lệnh chương
trình (không phải là kết hợp của tất cả các đường
đi).
Kiểm thử Cấu trúc (2/2)
(Structural testing)
70
2.5. Tự động hóa Kiểm thử
(Test automation)
71
} Kiểm thử là một giai đoạn quy trình tốn kém.
} Các khung kiểm thử (testing workbenches) cung cấp
một loạt các công cụ để giảm thời gian cần thiết và
tổng chi phí kiểm thử.
} Các hệ thống như JUnit hỗ trợ thực hiện tự động
các bài kiểm thử.
} Hầu hết các workbench kiểm thử là các hệ thống mở
vì nhu cầu kiểm thử là đặc thù của tổ chức.
} Đôi khi rất khó để tích hợp với thiết kế khép kín và
phân tích các workbench .
Workbench Kiểm thử
72
Thích ứng Workbench Kiểm thử
73
} Các kịch bản có thể được phát triển cho các trình
mô phỏng giao diện người dùng và các mẫu cho bộ
tạo dữ liệu kiểm thử.
} Kết quả kiểm thử có thể phải được chuẩn bị bằng
tay để so sánh.
} Các bộ so sánh tập tin mục đích đặc biệt có thể
được phát triển.
Tóm tắt những điểm chính
(Key points)
74
} Kiểm thử có thể cho thấy sự hiện diện của lỗi trong một hệ thống; nó
không thể chứng minh rằng không tồn tại các lỗi khác.
} Các nhà phát triển thành phần chịu trách nhiệm kiểm thử thành phần;
Kiểm thử hệ thống là trách nhiệm của một nhóm riêng biệt.
} Kiểm thử tích hợp là kiểm tra gia số của hệ thống; Kiểm thử phát
hành liên quan đến việc kiểm thử một hệ thống được phát hành cho
khách hàng.
} Sử dụng kinh nghiệm và các hướng dẫn để thiết kế trường hợp thử
nghiệm trong kiểm tra khiếm khuyết.
} Kiểm thử giao diện được thiết kế để phát hiện các khiếm khuyết
trong giao diện của các thành phần phức hợp.
} Phân vùng tương đương là một cách để khám phá các trường hợp
thử nghiệm - tất cả các trường hợp trong một phân vùng sẽ hành xử
theo cùng một cách.
} Phân tích cấu trúc dựa vào phân tích một chương trình và sinh ra
các bài kiểm tra từ phân tích này.
} Kiểm thử tự động giảm chi phí kiểm thử bằng cách hỗ trợ quá trình
kiểm thử với một loạt các công cụ phần mềm.
3. Bảo trì Phần mềm
Software maintenance
75
Mục tiêu
76
} Giải thích tại sao sự thay đổi là điều không tránh
khỏi nếu các hệ thống phần mềm vẫn còn muốn hữu
ích
} Thảo luận về các yếu tố chi phí bảo trì và duy trì phần
mềm
} Miêu tả các quá trình liên quan đến sự tiến hóa phần
mềm
} Thảo luận cách tiếp cận để đánh giá các chiến lược
tiến hóa cho các hệ thống kế thừa (legacy systems)
Chủ đề đề cập
(Topics covered)
77
} Động lực tiến hóa của chương trình
} Bảo trì phần mềm
} Các quá trình tiến hóa
} Tiến hóa hệ thống kế thừa
Sự thay đo$ i của pha(n me(m
(Software change)
78
} Thay đổi phần mềm là không thể tránh khỏi
} Các yêu cầu mới xuất hiện khi sử dụng phần mềm;
} Môi trường kinh doanh thay đổi;
} Nhiều lỗi phải được sửa chữa;
} Máy tính và thiết bị mới được thêm vào hệ thống;
} Hiệu suất hoặc độ tin cậy của hệ thống có thể phải được
cải thiện.
} Một vấn đề quan trọng đối với các tổ chức là thực
hiện và quản lý sự thay đổi đối với các hệ thống
phần mềm hiện có của họ.
Tầm quan trọng của sự tiến hóa
(Importance of evolution)
79
} Các tổ chức đầu tư rất lớn vào hệ thống phần mềm
của họ - chúng là những tài sản kinh doanh quan
trọng.
} Để duy trì giá trị của các tài sản này cho doanh
nghiệp, chúng phải được thay đổi và cập nhật.
} Phần lớn ngân sách phần mềm trong các công ty
lớn được dành cho việc tiến hóa phần mềm hiện tại
thay vì phát triển phần mềm mới.
Mô hình xoắn ốc của sự tiến hóa
(Spiral model of evolution)
80
Động lực tiến hóa của chương trình
(Program evolution dynamics)
81
} Động lực tiến hoá của chương trình là nghiên cứu
về những quá trình thay đổi của hệ thống.
} Sau nhiều nghiên cứu thực nghiệm, Lehman và
Belady đã đề xuất một số "luật" áp dụng cho tất cả
các hệ thống khi chúng tiến hóa.
} Những luật của Lehman dường như thường áp dụng
cho các hệ thống lớn được thiết kế riêng bởi các tổ
chức lớn.
Những luật của Lehman
(Lehman’s laws)
82
Luật Miêu tả
Thay đổi liên tục
(Continuing change)
Một chương trình được sử dụng trong một môi trường thực tế nhất thiết phải
thay đổi hoặc trở nên dần dần ít hữu ích trong môi trường đó.
Tăng độ phức tạp
(Increasing complexity)
Khi một chương trình tiến hóa thay đổi, cấu trúc của nó có xu hướng trở nên
phức tạp hơn. Các nguồn lực bổ sung phải được dành cho việc bảo tồn và
đơn giản hóa cấu trúc.
Tiến hóa của chương 
trình lớn
Tiến hóa của chương trình là một quá trình tự điều chỉnh. Các thuộc tính hệ
thống như kích thước, thời gian giữa các bản phát hành và số lượng lỗi
được báo cáo là xấp xỉ bất biến cho mỗi lần phát hành hệ thống.
Ổn định tổ chức
(Organisational stability)
Trong suốt vòng đời của chương trình, tốc độ phát triển của nó là xấp xỉ
không đổi và không phụ thuộc vào các nguồn lực dành cho việc phát triển hệ
thống.
Bảo tồn sự quen thuộc Trong suốt vòng đời của một hệ thống, sự thay đổi gia tăng trong mỗi bản
phát hành là xấp xỉ không đổi.
Tăng trưởng liên tục
(Continuing growth)
Các chức năng được cung cấp bởi các hệ thống phải liên tục tăng để duy trì
sự hài lòng của người dùng.
Suy giảm chất lượng
(Declining quality)
Chất lượng của các hệ thống dường như sẽ bị suy giảm trừ khi chúng thích
nghi với những thay đổi trong môi trường hoạt động của chúng.
Hệ thống phản hồi
(Feedback system)
Các quy trình tiến hóa kết hợp nhiều hệ thống phản hồi đa vòng, đa tác tử,
và bạn phải quan tâm đến chúng để đạt được cải tiến đáng kể về sản phẩm.
Bảo trì phần mềm
(Software maintenance)
83
} Sửa đổi một chương trình sau khi nó đã được đưa
vào sử dụng.
} Việc bảo trì thường không liên quan đến những thay
đổi lớn đối với kiến trúc của hệ thống.
} Thay đổi được thực hiện bằng cách sửa đổi các
thành phần hiện có và thêm các thành phần mới vào
hệ thống.
Bảo trì là không the$ tránh khỏi
(Maintenance is inevitable)
84
} Các yêu cầu của hệ thống có thể sẽ thay đổi trong
khi hệ thống đang được phát triển vì môi trường thay
đổi. Do đó, một hệ thống phân phối sẽ không đáp
ứng các yêu cầu của nó!
} Các hệ thống được kết hợp chặt chẽ với môi trường
của chúng. Khi một hệ thống được cài đặt trong môi
trường, nó sẽ thay đổi môi trường đó và do đó thay
đổi các yêu cầu của hệ thống.
} Hệ thống PHẢI được bảo trì nếu chúng muốn vẫn
còn hữu ích trong một môi trường.
Các loại bảo trì
(Types of maintenance)
85
} Bảo trì sửa chữa lỗi phần mềm
} Thay đổi một hệ thống để sửa chữa thiếu sót trong cách
đáp ứng các yêu cầu của nó.
} Bảo trì để thích nghi phần mềm với một môi trường
hoạt động khác
} Thay đổi một hệ thống để nó hoạt động trong một môi
trường khác (máy tính, hệ điều hành, v.v.) với môi trường
triển khai ban đầu.
} Bảo trì để bổ sung hoặc sửa đổi chức năng của hệ
thống
} Sửa đổi hệ thống để đáp ứng các yêu cầu mới.
Phân phối nỗ lực 3 loại bảo trì
(Distribution of maintenance effort)
86
Chi phí bảo trì
(Maintenance costs)
87
} Thông thường lớn hơn chi phí phát triển (2 * đến
100 * tùy thuộc vào ứng dụng).
} Bị ảnh hưởng bởi cả yếu tố kỹ thuật và phi kỹ thuật.
} Tăng khi phần mềm được bảo trì. Bảo trì làm hỏng
cấu trúc phần mềm nên lần bảo trì sau này sẽ càng
khó khăn hơn.
} Phần mềm có tuổi thọ cao có thể có chi phí hỗ trợ
cao (ví dụ: ngôn ngữ, trình biên dịch cũ v.v.).
Chi phí phát triển / bảo trì
(Development/maintenance costs)
88
Các yếu tố chi phí bảo trì
(Maintenance cost factors)
89
} Sự ổn định của nhóm (Team stability)
} Chi phí bảo trì sẽ giảm xuống nếu cùng nhân viên liên quan
đến chúng trong một khoảng thời gian.
} Trách nhiệm hợp đồng (Contractual responsibility)
} Các nhà phát triển của một hệ thống có thể không có trách
nhiệm hợp đồng để bảo trì nên không có động lực để thiết kế
cho sự thay đổi trong tương lai.
} Kỹ năng nhân viên (Staff skills)
} Nhân viên bảo trì thường thiếu kinh nghiệm và có kiến thức
miền giới hạn.
} Tuổi thọ và cấu trúc chương trình (Program age and
structure)
} Khi các chương trình có tuổi thọ cao, cấu trúc của chúng bị suy
thoái và chúng trở nên khó hiểu và thay đổi.
Dự báo bảo trì (1/2)
(Maintenance prediction)
90
} Dự báo bảo trì liên quan đến việc đánh giá những
phần nào của hệ thống có thể gây ra vấn đề và có
chi phí bảo trì cao
} Thay đổi chấp nhận phụ thuộc vào khả năng bảo trì của
các thành phần bị ảnh hưởng bởi sự thay đổi;
} Thực hiện thay đổi làm suy giảm hệ thống và giảm khả
năng bảo trì;
} Chi phí bảo trì phụ thuộc vào số lượng thay đổi và chi phí
thay đổi phụ thuộc vào khả năng bảo trì.
Dự báo bảo trì (2/2)
(Maintenance prediction)
91
Tóm tắt những điểm chính
(Key points)
92
} Phát triển và tiến hóa phần mềm phải là một quá trình
lặp.
} Luật Lehman mô tả một số hiểu biết sâu sắc trong sự
tiến hóa của hệ thống.
} Ba loại bảo trì là sửa lỗi, thay đổi phần mềm với một
môi trường mới và thực hiện các yêu cầu mới.
} Đối với các hệ thống tùy chỉnh, chi phí bảo trì
thường vượt quá chi phí phát triển.
Tài liệu Tham khảo
93
} Giáo trình chính: Software Engineering, Ian
Sommerville, 8th Edition, 2007
} Tham khảo:
} Object-Oriented Software Engineering Practical Software
Development using UML and Java, Lloseng.com,
Lethbridge/Laganièr, 2001
} Kỹ nghệ Phần mềm, TS Lê Văn Phùng, Nhà xuất bản
thông tin và truyền thông, 2014
} Bài giảng & Tài liệu của môn Nhập Môn Công Nghệ Phần Mềm,
PhạmThị Quỳnh