Bài giảng Đảm bảo chất lượng phần mềm: Kiểm soát cách làm - Nguyễn Anh Hào

SW Quality Assurance

1

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


A.Cách làm phần mềm, nhìn từ SE

2

u cầu

u cầu
1

•Cách làm phải
được chi tiết
thành từng bước
để kiểm sốt.
Phần mềm
1.
2.

•Phối hợp các

bước như thế
nào để tạo ra
phần mềm ?

2
3

Phần mềm

Cách làm có gây ra errors, faults ? hạn chế
bằng cách nào ?
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 số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.


Mơ hình thác nước (tuyến tính)

1970
(Users)

(Developers)

Khảo sát
Phân tích

Thiết kế

Có ấn phẩm sau từng
công đoạn do người
phát triễn tạo ra và
chuyển giao.
Người sử dụng chỉ tiếp
cận được với ấn phẩm
cuối cùng sau khi nó đã
được làm theo yêu cầu
ban đầu.

Hiện thực
Sửa lại (rework)

kiểm thử
Bảo trì

(Users)


1960

Mơ hình làm mẫu thử (mơ hình lặp)
u cầu

(User)

Tạo mẫu
(Developer)
Mẫu
ban
đầu

Người sử dụng điều
khiển quá trình phát
triễn mẫu, dựa trên yêu
cầu và kết quả thực
hiện u cầu (mẫu).
Mơ hình khơng u cầu
tạo ra các bản đặc tả
cho PM để bảo trì sau
này.

Mẫu đã cải tiến

kiểm thử mẫu
(User)
Mẫu
hoàn
chỉnh

Cải tiến mẫu
(Developer)

Yêu cầu cải tiến mẫu

Ứng dụng
mẫu


1986

Mơ hình xoắn ốc (mơ hình tiến hóa)
 Planning

 Customer
Communication

Lập kế hoạch

Yêu cầu & các
thay đổi

Kiểm tra
Đánh giá
 Customer
Evaluation

 Risks

Ước lượng rủi ro
Tạo mẫu thử
Xây dựng
Cài đặt

 Construction

Thiết kế
 Design


Đặ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~
2003

Mơ hình hợp nhất (UP/RUP)

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.


Các luồng cơng việc trong UP/RUP

11




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.


Đặc điểm của UP/RUP

12
 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 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


Ví dụ về các hành động V&V

15
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
Criteria

Verification vs Validation
Verification

Validation

DefinitionThe process of evaluating work-products
(not the actual final product) of a
development phase to determine whether
they meet the specified requirements for
that phase.

The process of evaluating software during

or at the end of the development process to
determine whether it satisfies specified
business requirements.

ObjectiveTo ensure that the product is being built
according to the requirements and design
specifications. In other words, to ensure
that work products meet their specified
requirements.

To ensure that the product actually meets
the user’s needs, and that the specifications
were correct in the first place. In other
words, to demonstrate that the product
fulfills its intended use when placed in its
intended environment.

EvaluationPlans, Requirement Specs, Design Specs, The actual product/software.
Code, Test Cases
•Testing
Activities•Reviews
•Walkthroughs
•Inspections

softwaretestingfundamentals.com


Verification & Validation: đặc tính

17

1.

2.

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).
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.


1.Completeness: tính hồn chỉnh

18


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 hồ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


Impact analysis

Coverage

Coverage

Nhắc lại: SE: traceabiliy

Derivation analysis

19

Derivation
Impact

SE:Traceability

20

 





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. Tồ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 ?


2.Consistency: tính nhất quán

21



Mỗi đặc tả trong các tài liệu ở các mức (phân
tích, thiết kế, hiện thực) được diễn tả và phân
biệt nhau một cách mạch lạc & nhất quán.
Mạch lạc: được liên kết với nhau giữa các mức,
không thừa, khơng thiếu
 Nhất qn: khơng có mâu thuẩn nhau trong
cùng 1 mức và giữa các mức




Tracing: impact & derive đưa các đặc tả vào
đúng mức của nó (derive) và loại bỏ đặc tả dư
thừa (impact) để dể tìm các đặc tả không nhất
quán.


3.Feasibility: tính khả thi

22


Là khả năng thực hiện được các yêu cầu (đặc
tả) trong thời hạn và kinh phí cho phép
Đối với verification: là khả năng chứng minh
được cho cách làm là khả thi.
 Đối với validation: là khả năng kiểm lỗi được
cho PM trong giới hạn thời gian và kinh phí.





Đặc tính này phụ thuộc vào nguồn lực thực tế:
Con người (users, devs,…), phương pháp, công
cụ, kinh nghiệm.
 Mức độ chắc chắn (hoặc độ tin cậy) của
phương pháp được chọn.



4. Testability: tính khả kiểm

23


Là khả năng hổ trợ của đặc tả (hoặc sản phẩm
PM) cho việc đánh giá đúng sai






Verification: cách làm có phương pháp để chứng
minh là đúng/sai hay khơng ?
Validation: sản phẩm có dể kiểm thử ?
ie, từ đặc tả, ta có thể áp dụng được các phương
pháp, kỹ thuật, công cụ đã biết để kết luận rằng

PM sẽ thỏa mãn u cầu hay khơng ?

Ví dụ về tính khả kiểm của đặc tả:





Đặc tả đến mức đủ chi tiết (để hiểu đúng ý)
Dựa trên phương pháp đã biết
Đo được (để thiết lập ngưỡng đạt/không đạt)
Kiểm thử được (có thể đưa ra được các test cases
đúng và đầy đủ)


Verification

24

Inputs = Requirement
specification

C

 Verification:

A

Outputs = Design
specification

B

xem xét mối quan hệ dẫn xuất từ
đặc tả của inputs (vd: requirement specs) sang
outputs (vd: design specs) để phát hiện sai sót.
 Cách làm đúng: mọi inputs đều đưa đến outputs
 Cách làm sai: output không nằm trong dự kiến
(A), output không thể dẫn ra được từ bất kỳ
input nào (B), input khơng có output (C).


Dự án: Verification

25



Còn gọi là kiểm thử phi thực thi
Là chuổi hành động cùng nhau xem xét tài liệu
về các ấn phẩm của phần mềm (bản thiết kế,
soure code,…) từ một nhóm chuyên gia, để
khẳng định rằng chúng đã được làm đúng
(hoặc cần phải hiệu chỉnh).
1. Code review ← 1 lập trình viên
2. Pair programming ← 2 lập trình viên
3. Review ← nhiều chuyên gia
a) Walk-through
b) Inspection