Bài giảng "Software quality assurance: Verification" cung cấp cho người học các kiến thức: Cách làm phần mềm, nhìn từ SE, mô hình phát triển phần mềm, hổ trợ thay đổi trong cách làm phần mềm, mô hình làm mẫu thử,... Mời các bạn cùng tham khảo.
AMBIENT/
Chủ đề:
Nội dung Text: Bài giảng Software quality assurance: Verification - Nguyễn Anh Hào
- 1
SW Quality Assurance
04. Verification
(kiểm soát cách làm)
Nguyễn Anh Hào
Khoa CNTT2
Học viện CNBCVT – Cs Tp.HCM
- 2 A.Cách làm phần mềm, nhìn từ SE
Yêu cầu Yêu cầu
1
•Cách làm phải •Phối hợp các
được chi tiết bước như thế 2
thành từng bước nào để tạo ra
để kiểm soát. phần mềm ? 3
Phần mềm Phần mềm
1. Cách làm có gây ra errors, faults ? hạn chế
bằng cách nào ?
2. Sản phẩm có thỏa mãn yêu cầu ?
- Mô hình phát triễn PM
Mô hình phát triễn phần mềm là một khuông mẫu cho
một tập hợp các công đoạn (từng bước) liên kết nhau để
hướng dẫn cho người phát triễn xác định được cách làm
ra phần mềm (kế hoạch) có kiểm soát (hạn chế sai sót).
Phần mềm không dùng một lần; nó phải được sử dụng
lâu dài, và phải phát triễn theo yêu cầu của người sử
dụng, đo đó cách làm PM phải hổ trợ cho các thay đổi *
lên PM.
Như vậy, có 2 mục tiêu chính mà các mô hình hướng
đến:
1. Chuyễn giao PM đạt chất lượng (thoả mãn yêu cầu)
2. Tạo điều kiện thuận lợi cho phần mềm phát triễn liên tục
sau khi chuyển giao (ie, làm thêm, không làm lại)
- * Hổ trợ thay đổi trong cách làm PM
Sự thay đổi của PM là sự sửa đổi trên các phiên bản ấn
phẩm của phần mềm (bản đặc tả yêu cầu, thiết kế, mã
nguồn,…)
Quá trình phát triễn PM thực chất là quá trình nhận biết
và thực hiện các thay đổi cần thiết cho các ấn phẩm
đang sử dụng; trong đó, một dự định thay đổi cần được
xem xét từ nhiều khía cạnh để hướng đến chất lượng, ví
dụ:
1. Nó gây ra sự khác biệt gì so với mong đợi ? (ie, vai trò)
2. Nó có đáng làm hay không ? (lợi ích/thiệt hại)
3. Nó được hiện thực vào PM như thế nào ? (khó hay dể)
Sự xem xét để thực hiện các thay đổi đưa đến nhu cầu
trao đổi thông tin để chia sẽ kiến thức hoặc kinh
nghiệm, và cần có công nghệ (công cụ) hổ trợ . Các mô
hình làm phần mềm hướng đến hổ trợ sử dụng các loại
nguồn lực này.
- 1970 Mô hình thác nước (tuyến tính)
(Users) Có ấn phẩm sau từng
công đoạn do người
phát triễn tạo ra và
(Developers) chuyển giao.
Khảo sát
Người sử dụng chỉ tiếp
cận được với ấn phẩm
Phân tích
cuối cùng sau khi nó đã
được làm theo yêu cầu
Thiết kế
ban đầu.
Hiện thực
kiểm thử
Sửa lại (rework)
Bảo trì (Users)
- 1960 Mô hình làm mẫu thử (mô hình lặp)
Yêu cầu Tạo mẫu
(User) (Developer)
Mẫu
ban
Mẫu đã cải tiến
đầu
Người sử dụng điều kiểm thử mẫu Cải tiến mẫu
khiển quá trình phát (User) (Developer)
triễn mẫu, dựa trên yêu Mẫu
cầu và kết quả thực hoàn
hiện yêu cầu (mẫu). chỉnh Yêu cầu cải tiến mẫu
Ứng dụng
Mô hình không yêu cầu mẫu
tạo ra các bản đặc tả
cho PM để bảo trì sau
này.
- 1986 Mô hình xoắn ốc (mô hình tiến hóa)
Planning
Customer Risks
Lập kế hoạch
Communication
Yêu cầu & các
thay đổi Ước lượng rủi ro
Tạo mẫu thử
Kiểm tra
Đánh giá
Xây dựng Thiết kế
Customer
Design
Evaluation
Cài đặt
Construction
- Đặc điểm của mô hình xoắn ốc
Kết hợp giữa thác nước và làm mẫu thử
Mô hình thác nước: Hổ trợ nhóm người phát triễn
hệ thống cùng làm việc chung với nhau trên các
tài liệu đặc tả.
Mô hình mẫu thử: người sử dụng tham gia tư vấn
& kiểm tra cho quá trình phát triễn sản phẩm.
Hổ trợ cho nhận thức từ bản chất đến chi tiết (từ
bất biến đến tùy biến)
Cho phép cập nhật ấn phẩm của mỗi công đoạn
ở chu kỳ trước, thay vì phải tạo mới
Cho phép tiếp tục phát triễn phần mềm trong giai
đoạn ứng dụng.
- 2000~ Mô hình hợp nhất (UP/RUP)
2003 Tài liệu chuyển giao
từ chu kỳ trước
Introduction to RUP. pdf
- 10 Các giai đoạn của mô hình UP/RUP
Có 4 giai đoạn chính để tạo ra 1 phiên bản PM
Inception : xác định vai trò của PM
Elaboration: đặc tả chi tiết (yêu cầu) cho PM
Construction: thiết kế giải pháp & hiện thực PM
Transistion : chuyển giao sử dụng phiên bản đã làm
Mỗi giai đoạn gồm có một vài chu kỳ phát triễn
Mỗi chu kỳ là một chuổi hành động củng cố cho những
đặc tả về PM bằng cách liên kết chúng với thực tế.
Mỗi chu kỳ có thể dùng mô hình thác nước/mẫu
thử/hướng đối tượng,… ; kết thúc bằng một mẫu thử
(hoặc phần mềm) cho những người sử dụng (hoặc
stack-holders) cùng nhau đánh giá hoặc sử dụng.
- 11 Các luồng công việc trong UP/RUP
UP có 2 loại luồng công việc (work-flow): tạo
ấn phẩm (6 luồng đầu) và hổ trợ tạo ấn phẩm
(3 luồng cuối).
Mỗi luồng công việc là một chuỗi hành động
nhận thức, hiệu chỉnh, xây dựng và chuyễn
giao cho mỗi công đoạn làm phần mềm (6
luồng đầu), hoặc hổ trợ (3 luồng cuối)
Mỗi luồng công việc không nằm gọn trong một giai
đoạn, mà nó trãi rộng suốt quá trình phát triễn 1
version hoặc sản phẩm
Mỗi chu kỳ phát triễn sẽ hổ trợ cho chu kỳ sau bằng
cách bổ sung thêm nhận định mới hoặc hiệu chỉnh
nhận định củ qua 9 luồng công việc trong RUP.
- 12 Đặc điểm của UP/RUP
UP là sự cải tiến linh hoạt của mô hình xoắn ốc
4 giai đoạn hổ trợ từ nhận thức đến thực tiễn
9 luồng công việc cùng phát triễn // qua mỗi chu kỳ
Dựa trên tiếp cận hướng đối tượng
Môhình này giúp nhận thức sớm được nhiều
vấn đề phát triễn hệ thống để chuẩn bị trước
Bằng cách phân tích nguyên nhân-hậu quả của từng
vấn đề thực tế và minh họa giải pháp bằng mẫu thử
để xem xét (trực quan), từ đó rút ra nhận định mới để
điều khiển chu kỳ kế tiếp.
Ví dụ: trong chu kỳ khởi động (khảo sát hiện trạng),
mô hình yêu cầu làm demo để stack-holders nhìn ra
được các vấn đề về thiết kế, cài đặt, vận hành,… sẽ
phải giải quyết trong tương lai, để chuẩn bị trước.
- 13 B. Verification (kiểm soát cách làm)
Mỗi bước thực hiện trong mô hình phát triễn
phải tạo ra được ấn phẩm đúng theo yêu cầu.
Ấn phẩm không đúng là ấn phẩm:
Không thoả mãn hết yêu cầu (hoặc mong muốn)
Có chứa vài mâu thuẩn với yêu cầu (lỗi)
Không hiện thực được thành sản phẩm
Dođó, SE đưa ra 2 hành động để đảm bảo cho
ấn phẩm đúng:
Xem xét cách làm để tin rằng nó đúng (chứng
minh cho cách làm là đúng, verification)
Xem xét sản phẩm để tin rằng nó thoả mãn cho
nhu cầu sử dụng (validation)
- 14 Verification & Validation
Verification: “Are we building the product right ?”
Implementation against its specifications is correct ?
Validation: “Are we building the right product?”
The expected functions or features are present ?
GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE.PDF
- 15 Ví dụ về các hành động V&V
1. Verification (chứng minh cho cách làm)
Xem xét mẫu thử để dẫn ra các đặc tả
Xem xét mối quan hệ giữa các tài liệu phân tích,
thiết kế và mã nguồn, để khẳng định rằng PM sẽ
thoả mãn các yêu cầu ban đầu.
2. Validation (chứng minh cho sản phẩm)
Xem xét mẫu thử minh hoạ cho yêu cầu để phát
hiện thiếu sót trong tài liệu đặc tả yêu cầu (yêu
cầu bị thiếu so với mong muốn).
Đối chiếu khả năng của PM so với yêu cầu đã
được cam kết, để phát hiện lỗi của sản phẩm PM
(kiểm thử).
- 16 Verification vs Validation
Criteria Verification Validation
DefinitionThe process of evaluating work-products The process of evaluating software during
(not the actual final product) of a or at the end of the development process to
development phase to determine whether determine whether it satisfies specified
they meet the specified requirements for business requirements.
that phase.
ObjectiveTo ensure that the product is being built To ensure that the product actually meets
according to the requirements and design the user’s needs, and that the specifications
specifications. In other words, to ensure were correct in the first place. In other
that work products meet their specified words, to demonstrate that the product
requirements. fulfills its intended use when placed in its
intended environment.
EvaluationPlans, Requirement Specs, Design Specs, The actual product/software.
Code, Test Cases
Activities•Reviews •Testing
•Walkthroughs
•Inspections
softwaretestingfundamentals.com
- 17 Verification & Validation: đặc tính
1. Phản biện cho cách làm: khẳng định cách làm
không đúng (verification) hoặc sản phẩm đã bị
khuyết điểm (validation).
2. Các hành động kiểm thử (validation) cũng phải
được bảo đảm là đúng (verification).
Vd: việc tạo ra test-case & test-plan phải được
chứng minh là đúng (verification) trước khi kiểm
thử (validation).
3. Có 4 đặc tính chất lượng: Completeness,
Consistency, Feasibility, Testability.
- 18 1.Completeness: tính hoàn chỉnh
Nội dung thực hiện V&V phải thỏa mãn đầy đủ
cho vấn đề đã biết.
Tính coverage trong tracing.
Đây là phần biện luận của cách làm: Xem xét
tất cả các tình huống cần giải quyết.
Những lỗi không hoàn chỉnh trong bản thiết kế:
• Tham chiếu đến hàm, tham số không tồn tại
• Thiếu chức năng xử lý cho yêu cầu
• Thiếu hổ trợ cho kiểm thử (test case, …)
GUIDELINES FOR VERIFYING AND VALIDATING SOFTWARE.PDF
- 19 Nhắc lại: SE: traceabiliy
Coverage
Coverage
Derivation analysis
Impact analysis
Derivation
Impact
- 20 SE:Traceability
Yêu cầu đối với PM được thể hiện thành đặc tả
cho PM ngày càng chi tiết ở 2 khía cạnh: đặc tả
cho sản phẩm, và đặc tả cho yêu cầu (chi tiết
thành các test-cases).
Quá trình này được xem xét từ 3 khía cạnh:
1. Toàn diện (coverage): các đặc tả được đưa ra ở
mức thấp có diễn tả trọn vẹn đặc tả ở mức cao;
và mỗi đặc tả có được test đầy đủ ?
2. Tác động (impact): sự phát sinh hoặc thay đổi
một đặc tả sẽ làm thay đổi những đặc tả nào ở
mức chi tiết hơn ?
• Để loại bỏ đặc tả dư thừa
3. Dẫn xuất (derivation): một đặc tả ở mức thấp có
thực sự cần thiết cho một đặc tả nào đó ở mức
cao ? và tại sao nó lại ở mức này ?
Thêm vào BST
Báo xấu
Download
Vui lòng tải xuống để xem tài liệu đầy đủ
