Cong Nghe Phan Mem - Chuong9

Chương 9
Chất lượng phần mềm & đảm bảo chất lượng

9.1 Sự quan trọng của chất lượng phần mềm
9.2 Kiểm thử phần mềm
9.3 Kiểm thử trong khi phát triển
9.4 Kiểm thử trước khi phân phối
9.5 Kiểm thử bởi người dung
9.6 Kết chương
Khoa Khoa học & Kỹ thuật Máy tính Môn : Công nghệ phần mềm
Trường ĐH Bách Khoa Tp.HCM Chương 9 : Chất lượng phần mềm & đảm bảo chất lượng
© 2010 Slide 1
9.1 Sự quan trọng của chất lượng phần mềm
© 2010 Slide 2
1
Định nghĩa về chất lượng phần mềm
 (ISO) định nghĩa chất lượng như tổng hòa các tính chất của sản
phẩm liên quan đến khả năng của nó để thỏa mãn các yêu cầu
đặt ra (ISO8042:1994) hay mức độ mà tập các tính chất hoàn
thành các yêu cầu (ISO9000:2000).
 Tương thích với yêu cầu có nghĩa là qui trình và sản phẩm của dự
án thỏa mãn các đặc tả đề ra.
 phù hợp cho sử dụng có nghĩa là sản phẩm có thể được dùng y
như nó được kỳ vọng.
 Các khía cạnh chất lượng :
 sản phẩm : được phân phối tới khách hàng
 qui trình : tạo ra sản phẩm phần mềm
 tài nguyên : (cả sản phẩm lẫn qui trình đều cần tài nguyên)
© 2010 Slide 3
Chất lượng qui trình & chất lượng sản phẩm

 Chất lượng có thể có nghĩa là sự chênh lệch giữa rất tốt và rất tệ.
 Airbus A400M Atlas bị nổ vào năm 2015, 4 người chết.
© 2010 Slide 4
2
Chất lượng qui trình & chất lượng sản phẩm
“Hộp đen chứng thực rằng không có
lỗi cấu trúc, nhưng chúng ta có vấn
đề chất lượng nghiêm trọng trong
khâu lắp ráp cuối cùng.”
“…hoặc 1 điểm yếu trong thủ tục

kiểm thử máy bay trước khi chúng
bay, hoặc 1 vấn đề mà là kết quả từ
sự hiện thực các thủ tục này.”
© 2010 Slide 5
Vấn đề qui trình hay vấn đề sản phẩm

8/2016: lỗ hổng an ninh với Bitcoin làm mất 72 triệu Usd trên thị
trường
© 2010 Slide 6
3
Các thuộc tính chất lượng
© 2010 Slide 7
Mô hình chất lượng phần mềm
© 2010 Slide 8
4
9.2 Kiểm thử phần mềm
 Kiểm thử được mong đợi để chỉ ra rằng phần mềm thực hiện
những gì được mong đợi và khám phá các lỗi phần mềm trước khi
nó được phân phối để sử dụng.
 Có thể phô bày sự hiện diện của lỗi, chứ không phải sự vắng mặt
các lỗi.
 Kiểm thử là 1 phần của qui trình V & V tổng quát hơn, qui trình
này còn bao gồm các kỹ thuật thẩm định tĩnh.
© 2010 Slide 9
Các mục tiêu của kiểm thử

 để giải thích cho người phát triển và khách hàng rằng phần mềm
thỏa các yêu cầu của nó.
 validation testing
 để khám phá các tình huống mà ở đó hành vi phần mềm không
đúng, không mong muốn hay không tương thích với các đặc tả
của nó.
 defect testing
© 2010 Slide 10
5
Đảm bảo chất lượng
© 2010 Slide 11
Tâm lý kiểm thử

 Chương trình là con đẻ của người lập trình.
 cố gắng tìm lỗi trong chương trình của mình giống như cố
gắng tìm lỗi của con mình.
 tốt nhất là để người khác thực hiện kiểm thử phần mềm do
mình viết ra.
 người kiểm thử phải chuyên nghiệp, có nhiều kinh nghiệm và kỹ
năng.
 nó giúp đở nếu họ có trí nhớ tồi tệ.
© 2010 Slide 12
6
Tâm lý kiểm thử
 kiểm thử phụ thuộc nhiều vào mục tiêu là gì.
 Myers nói :
 nếu mục tiêu của bạn là chỉ ra sự vắng mặt các lỗi, bạn sẽ
không khám phá nhiều thứ.
 nếu bạn đang có gắng chỉ ra chương trình chạy đúng, tiềm
thức của bạn sẽ tạo các test case an toàn.
 nếu mục tiêu của bạn là chỉ ra sự tồn tại của lỗi, bạn sẽ khám
phá số lượng lớn các lỗi.
 kiểm thử là qui trình thi hành phần mềm với mong muốn tìm các
lỗi của nó (G. Myers).
© 2010 Slide 13
Mô hình nhập/xuất của kiểm thử
© 2010 Slide 14
7
Phân biệt kiểm tra tĩnh với kiểm thử động
 Kiểm tra tĩnh
 liên quan đến việc phân tích sự miêu tả phần mềm tĩnh để
khám phát các lỗi.
 có thể được bổ sung bởi việc phân tích mã nguồn và tài liệu
dựa trên tiện ích.
 kiểm thử phần mềm :
 liên quan đến việc thi hành và quan sát hành vi phần mềm
 phần mềm được thi hành với dữ liệu kiểm thử rồi quan sát
hành vi hoạt động của nó.
© 2010 Slide 15
© 2010 Slide 16
8
NASA's Java PathFinder (JPF for short) is an instrumented JVM that
provides a state model checker. It runs your program by trying all
potential execution paths through it, checking properties as it goes to
detect problems like deadlocks or unhandled exceptions.
© 2010 Slide 17
Phân biệt Kiểm tra tĩnh với kiểm thử động
© 2010 Slide 18
9
Mô hình của qui trình kiểm thử phần mềm
© 2010 Slide 19
Các công đoạn kiểm thử

 kiểm thử trong khi phát triển phần mềm
 phần mềm được kiểm thử trong khi đang được phát triển để
khám phá các lỗi hay sai sót.
 kiểm thử trước khi phân phối
 1 đội kiểm thử riêng biệt sẽ kiểm thử version hoàn chỉnh của
phần mềm trước khi phân phối cho người dùng.
 kiểm thử bởi người dùng
 người dùng sẽ kiểm thử phần mềm trong ngữ cảnh sử dụng
của họ.
© 2010 Slide 20
10
9.3 Kiểm thử trong khi phát triển
được thực hiện bởi đội ngũ phát triển phần mềm.
 kiểm thử đơn vị :
 kiểm thử từng đơn vị nhỏ nhất sau khi coding (hàm, class)
 tập trung kiểm thử chức năng của đơn vị.
 kiểm thử thành phần :
 nhiều đơn vị nhỏ được tích hợp để tạo thành thành phần phức
hợp.
 tập trung việc kiểm thử giao diện của thành phần.
 kiểm thử tổng thể phần mềm :
 sau khi các thành phần được tích hợp, ta kiểm thử phần mềm
như 1 thể thống nhất.
 tập trung vào kiểm thử việc giao tiếp giữa các thành phần.
© 2010 Slide 21
Kiểm thử đơn vị

 kiểm thử đơn vị là hoạt động kiểm thử từng thành phần nhỏ 1
cách riêng biệt và rời rạc.
 nó là qui trình kiểm thử các thiếu sót.
 đơn vị có thể là :
 hàm hay tác vụ trong đối tượng.
 class với nhiều thuộc tính và tác vụ.
 thành phần phức hợp với giao diện để truy xuất các chức
năng của nó.
© 2010 Slide 22
11
Kiểm thử đơn vị : hộp trắng/hộp đen
from
requirements Compare actual output
with require output
from
requirements
Confirm expected
& key design
behaviour
elements
Gray-box: mix of black- and white-box testing
© 2010 Slide 23
for (i=0; i<numrows; i++)

for (j=0; j<numcols; j++);
pixels++;
int minval(int *A, int n) {

int currmin;
for (int i=0; i<n; i++)

if (A[i] < currmin)
currmin = A[i];
return currmin;
}
© 2010 Slide 24
12
switch (i) {
case 1:
do_something(1); break;
case 2:
case 3:
case 4:
default:
break;
}
© 2010 Slide 25
© 2010 Slide 26
13
Kiểm thử giao tiếp
Phát hiện các sai sót bởi vì :
 các lỗi giao tiếp.
 hay giả định sai về giao tiếp.
Các kiểu giao tiếp :
 giao tiếp tham số
 giao tiếp bộ nhớ dung chung.
 giao tiếp thủ tục
 giao tiếp truyền thông báo.
© 2010 Slide 27
Kiểm thử hộp trắng

 phủ các lệnh
 phú các rẽ nhánh
 phủ các đường thi hành
© 2010 Slide 28
14
Kiểm thử tự động
 bất kỳ khi nào có thể, kiểm thử đơn vị nên được tự động hóa.
 dùng 1 framework tự động hóa việc kiểm thử (như JUnit).
© 2010 Slide 29
Kiểm thử hệ thống

 tập trung kiểm thử các tương tác giữa các thành phần.
 kiểm thử hệ thống kiểm tra xem các thành phần có tương thích
nhau, có tương tác đúng và truyền dữ liệu đúng ở thời điểm
đúng xuyên qua giao tiếp của chúng không ?
 và cũng kiểm tra hành vi nổi bật của phần mềm.
© 2010 Slide 30
15
Kiểm thử hệ thống (tổng thể phần mềm)
Volume
 Subject product to large amounts of input.
Usability
 Measure user reaction (e.g., score 1-10).
Performance
 Measure speed under various circumstances.
Configuration
 Configure to various hardware / software
Compatibility
 with other designated applications
Reliability / Availability
 Measure up-time over extended period.
© 2010 Slide 31
kiểm thử hệ thống (tổng thể phần mềm)

Security
 Subject to compromise attempts.
Resource usage
 Measure usage of RAM and disk space etc.
Install-ability
 Install under various circumstances.
Recoverability
 Force activities that take the application down.
Serviceability
 Service application under various situations.
Load / Stress
 Subject to extreme data & event traffic
© 2010 Slide 32
16
Kiểm thử use-case
 Các use-case được phát triển để nhận dạng các tương tác giữa
phần mềm với môi trường xung quanh, do đó chúng có thể được
dùng làm cơ sở để kiểm thử hệ thống phần mềm.
 mỗi use-case thường liên quan đến nhiều thành phần chức năng
của phần mềm, do đó kiểm thử use-case sẽ kích hoạt các tương
tác giữa các thành phần này và có thể phơi bày lỗi hay sai sót.
 lược đồ trình tự kết hợp với use-case sẽ miêu tả các thành phần
và các tương tác cần được test.
© 2010 Slide 33
9.3 Phát triển phần mềm hướng kiểm thử

xen kẻ việc viết code và kiểm thử code đó
 lợi ích của việc phát triển code hướng kiểm thử :
• phủ Code
• kiểm thử hồi qui (Regression)
• gở rối đơn giản hóa.
• lập tài liệu phần mềm
© 2010 Slide 34
17
Kiểm thử hồi quy
 kiểm thử hồi quy là kiểm tra xem các thay đổi có làm hư các đoạn
code cũ đã chạy tốt không.
 sẽ tốt hơn nếu kiểm thử hồi quy được kiểm thử tự động.
 tất cả test-case được kiểm thử lại mỗi lần có sự thay đổi trong phần
mềm.
 các test-case phải kiểm thử thành công trước khi sự thay đổi được
chấp thuận.
© 2010 Slide 35
9.4 Kiểm thử trước khi phân phối

 Ta mong muốn kiểm thử phần mềm trước khi nó được dùng bên
ngoài đội phát triển.
 mục tiêu chính : để thuyết phục rằng phần mềm đủ tốt cho việc
dùng nó.
• chỉ ra rằng phần mềm có các chức năng, hiệu năng, độ đáng tin
cậy được đặc tả, và rằng nó không thất bại trong khi được dùng
bình thường.
 thường dùng kỹ thuật kiểm thử hộp đen để kiểm thử trước khi
phân phối.
• định nghĩa test-case dựa chính yếu vào đặc tả phần mềm.
 nó là 1 dạng kiểm thử hệ thống.
© 2010 Slide 36
18
Kiểm thử dựa trên các yêu cầu phần mềm
 liên quan đến việc xem xét từng yêu cầu riêng biệt và phát triển
các test-case cho riêng mỗi yêu cầu.
 Thí dụ : các yêu cầu của phần mềm Mentcare :
• If a patient is known to be allergic to any particular medication,
then prescription of that medication shall result in a warning
message being issued to the system user.
• Set up a patient record with no known allergies. Prescribe
medication for allergies that are known to exist. Check that a
warning message is not issued by the system.
• Set up a patient record with a known allergy. Prescribe the
medication to that the patient is allergic to, and check that the
warning is issued by the system.
© 2010 Slide 37
Kiểm thử dựa trên các yêu cầu phần mềm

 Thí dụ : các yêu cầu của phần mềm Mentcare (tt) :
• Set up a patient record in which allergies to two or more drugs
are recorded. Prescribe both of these drugs separately and
check that the correct warning for each drug is issued.
• Prescribe two drugs that the patient is allergic to. Check that
two warnings are correctly issued.
• Prescribe a drug that issues a warning and overrule that
warning. Check that the system requires the user to provide
information explaining why the warning was overruled.
© 2010 Slide 38
19
Kiểm thử hiệu suất
 một phần của kiểm thử trước phân phối có thể liên quan đến việc
kiểm thử các phẩm chất rõ nét của phần mềm như hiệu suất, tính
tin cậy.
 Các test-case phải phản ánh profile của việc dùng phần mềm.
 thường là 1 chuỗi các kiểm thử
• tải được gia tăng đều đặn cho đến khi hiệu suất phần mềm trở
nên không thể chấp nhận.
 Kiểm thử độ căng thẳng
• là 1 dạng kiểm thử hiệu suất mà ở đó phần mềm được chạy quá
tải có chủ đích để kiểm thử hành vi thất bại của nó.
© 2010 Slide 39
9.5 Kiểm thử bởi người dùng

 Giai đoạn mà người dùng hay khách hàng cung cấp dữ liệu nhập
và lời khuyên về kiểm thử phần mềm.
 Kiểm thử bởi người dùng rất thiết yếu, ngay cả khi kiểm thử hệ
thống và kiểm thử trước phân phối đã được thực hiện đầy đủ.
 Các kiểu kiểm thử bởi người dùng :
• kiểm thử Alpha
• kiểm thử Beta
• kiểm thử độ chấp thuận
© 2010 Slide 40
20
Các bước trong qui trình kiểm thử độ chấp thuận
bởi người dùng
 Định nghĩa tiêu chí chấp thuận

 Kế hoạch việc kiểm thử độ chấp thuận.
 rút ra được các test-case độ chấp thuận.
 chạy các test-case độ chấp thuận.
 Thương lượng các kết quả kiểm thử.
 Loại bỏ/chấp nhận phần mềm.
© 2010 Slide 41
Các tiêu chí dừng kiểm thử

 hoàn tất phương pháp luận kiểm thử xác định.
 phần trăm ước lượng của phủ cho mỗi loại lỗi.
 tốc độ phát hiện lỗi.
 tổng số lỗi tìm được.
 ?
© 2010 Slide 42
21
9.6 Kết chương
 Kiểm thử chỉ có thể chỉ ra sự tồn tại của lỗi, nó không thể chứng
minh rằng phần mềm hết lỗi.
 Kiểm thử trong khi phát triển phần mềm : do đội phát triển.
 Kiểm thử trong khi phát triển phần mềm bao gồm kiểm thử đơn
vị, kiểm thử thành phần và kiểm thử toàn phần mềm.
 Khi kiểm thử phần mềm : cố gắng ngắt phần mềm bằng cách
dùng các hướng dẫn và kinh nghiệm.
 bất kỳ khi nào có thể, ta nên viết các test tự động hóa.
 phát triển Test-first : viết các tests trước khi viết code.
 kiểm thử theo kịch bản liên quan đến việc sáng chế 1 kịch bản sử
dụng điển hình và dùng kịch bản này để tạo ra các test-case.
 kiểm thử độ chấp thuận : qui trình kiểm thử bởi người dùng =>
xem phần mềm đủ tốt để triển khai và dùng trong môi trường
hoạt động thật không.
© 2010 Slide 43
22

Cong Nghe Phan Mem - Chuong9

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cong Nghe Phan Mem - Chuong9

Uploaded by

Copyright:

Available Formats

Chương 9

Chất lượng phần mềm & đảm bảo chất lượng

9.1 Sự quan trọng của chất lượng phần mềm

Chất lượng qui trình & chất lượng sản phẩm

“…hoặc 1 điểm yếu trong thủ tục

Vấn đề qui trình hay vấn đề sản phẩm

Mô hình chất lượng phần mềm

Các mục tiêu của kiểm thử

Tâm lý kiểm thử

Mô hình nhập/xuất của kiểm thử

Phân biệt kiểm tra tĩnh với kiểm thử động

Phân biệt Kiểm tra tĩnh với kiểm thử động

Các công đoạn kiểm thử

Kiểm thử đơn vị

Gray-box: mix of black- and white-box testing

Kiểm thử đơn vị : hộp trắng/hộp đen

for (i=0; i<numrows; i++)

int minval(int *A, int n) {

for (int i=0; i<n; i++)

Kiểm thử đơn vị : hộp trắng/hộp đen

Kiểm thử hộp trắng

Kiểm thử hệ thống

 và cũng kiểm tra hành vi nổi bật của phần mềm.

kiểm thử hệ thống (tổng thể phần mềm)

9.3 Phát triển phần mềm hướng kiểm thử

9.4 Kiểm thử trước khi phân phối

Kiểm thử dựa trên các yêu cầu phần mềm

9.5 Kiểm thử bởi người dùng

 Định nghĩa tiêu chí chấp thuận

Các tiêu chí dừng kiểm thử

You might also like