Bài giảng Đảm bảo và kiểm soát chất lượng phần mềm: Chương 2 - Nguyễn Mạnh Tuấn

Chương 2 trình bày các yếu tố cơ bản trong kiểm soát chất lượng phần mềm. Nội dung chính được trình bày trong chương này gồm có: Quy trình phát triển phần mềm, tại sao phải kiểm thử (testing) phần mềm? Testing là gì? Những nguyên lý tổng quát trong kiểm thử, quy trình kiểm thử cơ bản, các kiểu kiểm thử.

ĐẢM BẢO VÀ KIỂM SOÁT

CHẤT LƯỢNG

HCM – 10/2012

Chương 2:

Các yếu tố cơ bản trong

kiểm soát chất lượng

phần mềm

Quy trình phát triển phần mềm

Làm sao đi được tới ROME du lịch một chuyến

nhỉ?

Quy trình phát triển phần mềm

Quy trình phát triển phần mềm

Phân tích

Thiết kế Lập trình Kiểm thử

1

4

giai đoạn phải trải qua khi

thực hiện việc sản xuất phần

mềm.

Tại sao phải kiểm thử (testing)

Những hậu quả do lỗi phần

mềm gây ra

 Bị tan tành sau 40 giây cất cánh, bị thiệt

hại khoảng ½ tỉ USD

 Nguyên nhân: bị lỗi về xử dụng số thực

Do chuyển đổi từ 64bit integer sang 16 bit integer có dấu => bị tràn số

 Bị biến mất ngay khi bắt đầu, bị thiệt hại

khoảng 125 triệu USD

 Nguyên nhân: dùng sai đơn vị trong

chương trình

Tại sao phải kiểm thử (testing)

phần mềm?

 “Lỗi phần mềm là chuyện hiển nhiên của cuộc

sống Chúng ta dù cố gắng đến mức nào thì

thực tế là ngay cả những lập trình viên xuất

sắc nhất cũng không có thể lúc nào cũng viết

được những đoạn mã không có lỗi Tính trung

bình, ngay cả một lập trình viên loại tốt thì

cũng có từ 1 đến 3 lỗi trên 100 dòng lệnh

Người ta ước lượng rằng việc Testing để tìm ra

các lỗi này chiếm phân nửa khối lượng công

việc phải làm để có được một phần mềm hoạt

động được”

(Software Testing Techniques, Second Edition,

by Boris Beizer, Van Nostrand Reinhold, 1990,

Nguyên nhân các khiếm khuyết

Con người tạo ra lỗi

… Hệ quả là xuất hiện khiếm khuyết

… hệ thống thực hiện

Nguyên nhân các khiếm khuyết

 Dòng mã, hệ thống, phần mềm, tài liệu

• Dư thừa

• Thiếu xót

công việc sai xót -> thực hiện không

Nguyên nhân các khiếm khuyết

Triết lý của việc kiểm thử

phần mềm với ý định tìm kiếm các lỗi

của nó

trình cố gắng tìm kiếm các lỗi của phần

mềm theo tinh thần "hủy diệt".

Testing phần mềm là gì?

 Mục tiêu

 Tìm khiếm khuyết

 Ngăn ngừa khiếm khuyết

 Chứng minh được phần mềm hoạt động đúng như đã thiết kế

 Chứng minh được phần mềm đáp ứng yêu

cầu của user

 Góp phần chứng minh chất lượng của phần mềm

 Tăng tin tưởng mức chất lượng và thông

tin cung cấp

Phần mềm đáp ứng yêu cầu

của user

Phần mềm đáp ứng yêu cầu

của user

Khác biệt giữa Gỡ rối(Debug)

 Xác định nguyên nhân và sửa chữa mã lỗi

 Testing lại khiếm khuyết có được sửa

đúng

 Developers

Triết lý của việc Testing

Những nguyên lý tổng quát

trong testing

 Những nguyên lý này được đúc kết thông qua quá trình phát triển và qua các hướng dẫn tổng quát nhất cho việc testing

 Có 7+ nguyên lý chính

 Testing để khơi bày các lỗi ra ngoài

 Không thể vét cạn hết các trường hợp

 Testing sớm

 Gom nhóm các khiếm khuyết

 Nghịch lý thuốc trừ sâu (Pesticide paradox)

 Phụ thuộc ngữ cảnh

 Ảo tưởng “không lỗi” (Absence-of-errors

fallacy)

Testing để khơi bày các lỗi ra

ngoài

Testing có thể khơi bày các lỗi ra ngoài, nhưng không chứng minh được chương trình hết lỗi

Testing để giảm khả năng để xót lỗi lại

trong chương trình

Không thể vét cạn hết các

trường hợp

Hê thống có

20 màn hình

Trung bình: 10 fields / screen

2 types input / field (date as Jan 3 or 3/1) (number as integer or decimal) Around 100 possible values

Số lượng test cho toàn bộ:

20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests

Nếu 1 giây/test => 8000 phút = 133 giờ = 17.7 ngày

Trung bình 4 menu

3 lựa chọn/ menu

Không thể vét cạn hết các

trường hợp

Số lượng test cho trường hợp lỗi:

chữ thường, chữ hoa, số, ký tự đặt biệt thì ta cần 50 mũ 20 lần giá trị

Nhiều nhất là 20

ký tự

Không thể vét cạn hết các

trường hợp

Vì thời gian testing luôn có giới hạn

 Việc quyết định bao nhiêu là đủ nên dựa

vào:

• Bảng miêu tả các rủi ro: Rủi ro kỹ thuật, nghiệp

vụ, dự án

• Các ràng buộc về thời gian lẫn ngân sách

• Những yêu cầu đặc biệt của khách hàng

 Qua đó giúp xác định:

• Những phần nào nên test trước

• Những phần nào nên tập trung

• Những phần nào sẽ không test (trong thời gian

Testing sớm

Nên bắt đầu sớm nhất có thể trong chu

kỳ phát triển

 Việc phát hiện lỗi quá trễ thường sẽ tốn

nhiều chi phí hơn để khắc phục:

• Chịu áp lực về thời gian

• Phải testing lại phần lớn những chức năng để

ổn định trước đó

 Giúp nắm rõ về các yêu cầu của hệ thống

để có những bước chuẩn bị môi trườnghay kế hoạch đào tạo (training) tốt hơn

Gom nhóm các khiếm khuyết

khiếm khuyết của hệ thống

nguyên nhân từ 20% các chức năng

 ⇒ cô lập và testing những chức năng khả nghi nhất

Nghịch lý thuốc trừ sâu (Pesticide paradox)

Lặp lại cùng mẫu testing:

 Không tìm thấy khiếm khuyết mới

lại đều đặn

được viết lại để có thể kiếm được nhữnglỗi tiềm ẩn mới

 Không phải tất cả phần mềm đều có cùng cấp độ rủi ro và không phải tất cả những khiếm khuyết đều có chung mức độ tàn phá

Ảo tưởng “không lỗi”

Những nguyên lý khác

module riêng biệt rồi sau đó tích hợp các module lại.

tham gia vào quá trình phát triển phần mềm.

nhưng không phải xuất hiện theo thứ tự nhất định.

Triết lý của việc Testing

Qui trình kiểm thử phần mềm

Lập kế

hoạch test

Thiết kế test

So sánh kết quả

Chuẩn bị dữ liệu test

Chạy ứng dụng với bộ dữ liệu test

Test Results

Test Data Test Case

Test plan

Chuẩn bị

Test

Phân tích kết quả

Lập kế hoạch

Các hoạt động kiểm thử

Construction Thử nghiệm

Construction Lập trình

Testing (thử nghiệm)

Initiation (khởi động)

Test sẽ dùng để thực hiện công việc

Test

cho việc Test

cho mỗi thành viên tham gia

Kế hoạch Test

Giới thiệu

 Mục đích

 Thông tin chung

 Tài liệu liên quan

 Phạm vi test

 Liệt kê các rủi ro

Phân tích thiết kế Test-Case

 Mỗi testcase chứa các thông tin cần thiết

để Test thành phần phần mềm theo 1 mục tiêu xác định Thường testcase gồm bộ 3

thông tin:

 Tập dữ liệu đầu vào

 Trạng thái của thành phần phầm mềm

 Tập kết quả kỳ vọng

Phân tích thiết kế Test-Case

 Test hộp đen (Black box testing)

 Test hộp trắng (White box testing)

output

Phân tích thiết kế Test-Case

kiến trúc, thiết kế, giao tiếp (interface),

Phân tích thiết kế Test-Case

Thực hiện Test

 Testers sẽ được bố trí công việc bởi Test

Leader để thi hành Testing

 Lập thứ tự ưu tiên các testcase

 Thi hành Testing theo từng testcase bằng tay hay tự động

 Thực hiện Testing đặc biệt (ad-hoc)

 Thực hiện kịch bản Testing mà không được định nghĩa trong testcase

 Testing lại các lỗi đã được sửa

 Tester sẽ tạo các báo cáo về lỗi trong suốt

quá trình kiểm lỗi và theo dõi chúng cho đến

Thực hiện Test

Nhận bản build thực hiện Test

Đóng lỗi

Yes

No

Đệ trình/ Re-Open Lỗi đến tracking system (*)

No

Yes

Phân cho Tester

Xem xét lại bởi Test Lead, Dev Lead, PM Lỗi trong hệ thống

No

Yes

Không rõ lỗi?

Phân ngược lại Tester

để thêm thông tin

Đánh giá - Lập báo cáo

Tạo các báo cáo lỗi

các yêu cầu thay đổi

lường hoạt động Testing

Testing

công và hoàn thành Testing chưa

Hoạt động kết thúc Testing

 Dự án bị hủy (Cancel)

 Milestone được hoàn thành

Hoạt động kết thúc Testing

 Kiểm tra công việc đã phân theo kế hoạch

và tất cả các khiếm khuyết đã được giải quyết

 Hoàn tất và cất giữ các Testware (các

scripts, môi trường Testing, hạ tầng) để sử dụng sau này

 Bàn giao testware đến tổ chức bảo trì

 Phân tích bài học học được

Các kiểu kiểm thử

Testing Type

 Kiểm thử Chức năng - Function Test

 Kiểm thử Phi chức năng - Non-Functional Test

 Kiểm thử Hồi quy - Regression Test

Kiểm thử chức năng

Function Test

ứng được mô tả rõ ràng trong các tài liệu:

diện đẹp, xấu, dễ sử dụng hay không, thời gian xử

lý nhanh hay chậm,

hướng:

• Bản mô tả tóm lược những chức năng cần Test hay không cần Test

Kiểm tra Phi chức năng

 Tính bảo mật/an toàn (Security)

 Tính tin cậy (Reability)

 Tính hoàn thiện (Maturity)

 Khả năng chịu lỗi (Fault tolerant)

 Khả năng phục hồi (Recoverability)

 Tính hiệu quả (Efficiency)

 Thời gian xử lý (Time behavior)

 Sử dụng tài nguyên (Utilization)

 Khả năng bảo trì (Maintainability)

 Khả năng phân tích (Analysability)

 Khả năng thay đổi được (Changeability)

 Tính ổn định (Stability)

 Khả năng kiểm thử được (Testability)

 Tính khả chuyển (Portability)

 Khả năng thích nghi (Adaptability)

 Khả năng cài đặt (Installability)

 Khả năng chung sống (Co-existence)

Kiểm thử hồi quy

Regression Test

phần mềm sẽ thay đổi:

 Các đường dẫn luồng dữ liệu mới

 Các thay đổi có thể gây nên các vấn đề với các chức năng đã làm việc hoàn hảo trước đó

Kiểm thử hồi qui là việc thực hiện lại

một số tập con các kiểm thử đã được

thực hiện trước đó để đảm bảo rằng các thay đổi mới không sinh ra những hiệu ứng không mong muốn

Kiểm thử hồi quy

Regression Test

 Kiểm thử hồi quy có thể thực hiện thủ công,

bằng cách thực hiện lại tập con tất cả các

trường hợp kiểm thử hoặc có thể thực hiện tự động

 Bộ kiểm thử hồi quy (tập con các kiểm

thử sẽ được thực thi) gồm ba lớp các

trường hợp kiểm thử khác nhau:

 Một mẫu đại diện của các kiểm thử sẽ thực

hiện tất cả các chức năng chính của phần mềm

 Các trường hợp kiểm thử bổ sung tập trung vào các chức năng phần mềm có khả năng bị tác động khi có sự thay đổi

 Các kiểm thử tập trung vào các thành phần mới

Kiểm thử hồi quy

Regression Test

các chức năng A, B và C.

• Nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng

C (A, B).

• Lý do là khi C thay đổi, nó có thể sẽ làm A và B không còn làm việc đúng nữa.

phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi.

ĐẢM BẢO VÀ KIỂM SOÁT

CHẤT LƯỢNG

Bài tập

phần lớn các trường hợp của màn hình bên dưới

với chi phí thấp nhất và hiệu quả có thể chấp nhận được

Bài tập

 2) Viết 1 kế hoạch Test theo mẫu cho 1 dự án

cụ thể

 3) Viết những test case sau cho màn hình

login theo mẫu test case ở slide 36:

Chương tiếp theo