Đề Tài : Kiểm Thử Phần Mềm doc

* Các hoạt động kiểm thử phải được tích hợp vào tiến trình phát triển phần mềm... Kiểm thử tĩnh Static testing* Kiểm thử tĩnh cũng có thể được tự động hóa thông qua phần mềm bao gồm các

BÁO CÁO MÔN H C ỌC

Kỹ Nghệ Phần Mềm

Đ Tài : ề Tài : Kiểm Thử Phần Mềm

Nhóm 12 – D6LT CNTT5

1 Nuyễn Văn Phấn

2 Nguyễn Thanh Hải

3 Đinh Xuân Hải

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC ĐIỆN LỰC Khoa Công Nghệ Thông Tin

ĐỀ TÀI KIỂM THỬ PHẦN

MỀM

Lý do chọn đề tài là: Theo chương trình

đào tạo,mà những giáo trình có cách gọi khác nhau đói với các khái niệm về kiểm thử phần mềm,phương pháp,chiến

lược,hình thức.

N i Dung đ tài tìm hi u ội Dung đề tài tìm hiểu ề Tài : ểu

* Chủ yếu phân tích các khái niệm về

Tài li u tham kh o ệu tham khảo ảo

Để thực hiện được báo cáo tìm hiểu này, nhóm chúng tôi đã tìm hiểu và tham khảo trên các tài liệu như sau:

Giáo trình Kỹ Nghệ Phần Mềm.

Các bài viết, thảo luận về kiểm thử trên website

http://www Tailieu.vn /

I Tổng quát về kiểm thử phần mềm

1. Khái niệm kiểm thử phần mềm là

gì?

2. Mục đích của việc kiểm thử.

3. Một số nguyên tắc trong kiểm thử.

1.1.Khái niệm kiểm thử

phần mềm là gì?

- Kiểm thử phần mềm có nhiều cách định nghĩa khác nhau Nhưng đều bao hàm hai nội dung cơ bản là: phát hiện lỗi và đánh giá chất lượng của phần

mềm.

- Định nghĩa của Myers: “ Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi sai ”.

1.2 Mục đích của việc kiểm thử phân mềm

* Kiểm thử thiếu sót:

- Để khám phá lỗi sai hay thiếu sót trong phần mềm mà do đó phần mềm tiến hành xử lý không đúng hay không tuân thủ theo đặc tả của nó

- Một test thành công là một test làm cho

hệ thống thi hành của phần mềm không đúng và do đó lộ ra thiếu sót,hai sai

1.2 Mục đích của kiểm thử

* Kiểm thử hợp lệ:

- Để trình diễn cho lập trình viên và khách hàng biết rằng phần mềm này thỏa mãn yêu cầu của nó.

- Một test thành công nếu nó chỉ ra

rằng hệ thống hoạt động như ý muốn

mà phần mềm đó tiến hành.

1.3 Một số nguyên tắc trong kiểm thử

* Kiểm thử phải được lập kế hoạch đõ dàng

* Một ca kiểm thử phải có kết quả mong muốn

* Các ca kiểm thử nên được thiết kế cho

cả những dữ liệu vào hợp lệ và không hợp lệ

* Một ca kiểm thử tốt là ca kiểm thử có khả năng cao phát hiện những lỗi sai

1.3 Một số nguyên tắc kiểm thử

* Kiểm thử nên được thực hiện bởi một nhóm độc lập với nhóm phát triển.

* Ép các kết quả tính toán phải hoặc là quá lớn hoặc là quá nhỏ Kết quả kiểm thử phải được kiểm tra một cách cẩn thận.

* Các hoạt động kiểm thử phải được tích hợp vào tiến trình phát triển phần mềm.

II.Các hình thức kiểm thử phần mềm

1 Theo Tổ chức thẩm định về KTPM quốc

tế-ISTBQ) có hai hình thức là:

1.1 Kiểm thử tĩnh 1.2 Kiểm thử động

2 Theo khái niệm thông thường có ba hình thức

là:

2.1 Kiểm thử hộp đen 2.2 Kiểm thử hộp trắng.

2.3 Kiểm thử hộp xám.

3 Các giai đoạn kiểm thử.

2.1.1 Kiểm thử tĩnh (Static testing)

* Kiểm thử tĩnh là một hình thức của kiểm thử phần

mềm mà phần mềm không được sử dụng Nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúng đắn của mã lệnh (code), thuật toán hay tài liệu

* Chủ yếu kiểm tra cú pháp của code: kiểm tra xem

code có được viết theo đúng tiêu chuẩn code; hoặc tài liệu để tìm lỗi bằng cách thủ công (sử dụng giấy, bút để kiểm tra logic, lần từng chi tiết

mà không cần chạy chương trình)

2.1.1 Kiểm thử tĩnh (Static testing)

* Kiểm thử tĩnh cũng có thể được tự động

hóa thông qua phần mềm bao gồm các

chương trình phân tích bởi một thông

dịch viên hoặc một trình biên dịch khẳng

định tính hợp lệ về cú pháp của chương

trình được viết.

* Có thể được sử dụng bởi những người lập

trình làm việc một cách độc lập với nhau.

2.1.2 Kiểm thử động

* Là hình thức kiểm thử phần mềm thông

qua việc dùng máy chạy chương trình

đó để kiểm tra trạng thái tác động của chương trình

* Kiểm thử động bao gồm: làm việc với

phần mềm,bằng cách nhập dư liệu đấu vào để kiểm tra xem có hợp lệ không

* Trong kiểm thử động thì phần mềm phải

thực sự được biên dịch và chạy

2.2.1 Kiểm thử hộp đen (Black box testing)

* Các kỹ thuật kiểm thử chức năng.

* Dữ liệu kiểm thử phần mềm, bao gồm:

- Đặc tả yêu cầu (trong giai đoạn kiểm thử hệ thống)

- Đặc tả thiết kế (trong giai đoạn kiểm thử tích hợp)

- Đặc tả chi tiết mô đun (trong giai đoạn kiểm thử đơn vị)

2.2.1 Kiểm thử hộp đen (Black box testing)

* Tester không cần phải có kiến thức về ngôn ngữ

lập trình, các hệ QT.CSDL,…

* Tester thao tác các chức năng của hệ thống như là

người sử dụng hệ thống.

2.2.1 Kiểm thử hộp đen (Black box testing)

* Các hình kiểm thử hộp đen thông dụng:

- Kiểm thử giao diện (Interface testing)

- Kiểm thử khả năng (Release testing)

- Kiểm thử Alpha, Kiểm thử Beta, …

2.2.1 Kiểm thử hộp đen (Black box testing)

* Để kiểm thử hộp đen, các Tester sử dụng các

phương pháp sau đây:

- Phân lớp tương đương (Equivalence partitioning).

- Phân tích giá trị biên (Boundary value analysis).

- Kiểm thử tất cả các cặp (All-pairs testing).

- Kiểm thử Fuzz (Fuzz testing).

- Ma trận dấu vết (Traceability matrix).

- Kiểm thử thăm dò (Exploratory testing).

- Kiểm thử dựa vào đặc tả / chức năng

(Specification-base testing).

2.2.2 Kiểm thử hộp trắng (White box testing)

* kỹ thuật kiểm thử cấu trúc.

* Kiểm tra tính logic và cấu trúc của mã nguồn.

• Kiểm tra tất cả các trường hợp có thể xảy ra

trong mã nguồn

• Tester cần có kiến thức về ngôn ngữ lập trình,

môi trường phát triển phần mềm, các hệ QT.CSDL,…

2.2.2 Kiểm thử hộp trắng (White box testing)

* Các hình kiểm thử hộp trắng thông dụng:

- Kiểm thử bộ phận (Component testing)

- Kiểm thử lớp đối tượng (Object class testing)

II.2.2 Kiểm thử hộp trắng (White box testing)

Ví dụ minh họa kiểm thử bộ phận:

II.2.2 Kiểm thử hộp trắng (White box testing)

Ví dụ minh họa kiểm thử bộ phận:

2.2.2 Kiểm thử hộp trắng (White box testing)

* Để thực hiện kiểm thử hộp trắng, các Tester sử

dụng các phương pháp sau:

- Bao phủ mã lệnh (Code coverage).

- Gán lỗi (Fault injection methods).

- Kiểm thử hoán chuyển (Mutation testing methods).

- Kiểm thử tĩnh (Fuzz testing).

- Kiểm thử giao diện lập trình ứng dụng (API testing-

2.2.3 Kiểm thử hộp xám (Gray box testing)

* Là hình thức mới hình thành và đòi hỏi trình độ cao.

* Là kiểu trung gian giữa kiểm thử hộp đen và kiểm

thử hộp trắng, trong đó tester phải vận dụng các kiến thức về thuật toán, cấu trúc bên trong chương trình,như của hộp trắng nhưng để thiết kế test case theo hương người sử dụng hoặc có test case như của hộp đen.

2.3 Các giai đoạn của kiểm thử

3.3.1 Kiểm thử đơn vị (Unit

testing)

* Kiểm thử mỗi đơn vị phần mềm (mođun), sử

dụng kỹ thuật kiểm thử hộp đen,như dữ liệu thử được tạo ra dựa trên tài liêu thiết kế phân mềm, sử dụng cả kiểm thử hộp trắng và kiểm thử tĩnh và thường được thực hiện trên phần cứng.

* Kiểm thử đơn vị do lập trình viên thực hiện

nên đòi hỏi kiểm tra viên có kiến thức thiết kế

và code của chương trình để đảm bảo chương trình được xử lý chính xác.

2.3.1 Kiểm thử đơn vị (Unit

testing)

* Test tương đối mất tời gian nhưng đem

lại hiệu quả về mặt chất lượng do các lỗi lặt vặt và nhỏ lẻ của function được loại bỏ từ sớm trong giai đoạn Test và khi bàn giao cho Tester thì Tester sẽ tập trung tìm kiếm được nhiều lỗi nguy hiểm hơn

2.3.2 Ki m th tích h p ểu ử tích hợp ợp

(Integration Testing)

* Là giai đoạn Test tích hợp với hình thức Black Box.

* Ở giai đoạn này Tester tiếp nhận các chức năng,

module đã lập trình xong, thực hiện kiểm thử ở mức đơn vị thấp nhất có thể (ví dụ: 1 chức năng Thêm mới ở 1 module danh sách sinh viên, ) và tích hợp lên một mức độ cao hơn.

* Các kỹ năng Phân tích và Phân loại mức đơn vị

2.3.2 Ki m th tích h p ểu ử tích hợp ợp

* Có 4 loại kiểm tra trong Integration

Test:

- Kiểm tra cấu trúc: Tương tự White Box

Test (kiểm tra nhằm bảo đảm các thành phần bên trong của một chương trình chạy đúng)

2.3.2 Ki m th tích h p ểu ử tích hợp ợp

(Integration Testing)

- Kiểm tra chức năng (functional): Tương tự

Black Box Test (kiểm tra chỉ chú trọng đến chức năng của chương trình, không quan tâm đến cấu trúc bên trong).

- Kiểm tra hiệu năng (performance): Kiểm

tra việc vận hành của hệ thống.

- Kiểm tra khả năng chịu tải (stress): Kiểm

tra các giới hạn của hệ thống.

2.3.3 Ki m th h th ng ểu ử tích hợp ệu tham khảo ống

(System Testing)

* Là giai đoạn Test tổng thể cả hệ

thống sau khi đã test từng bộ

phận.

* Chứng minh thực hiện đúng mong

đợi của người sử dụng

* Chỉ sử dụng kiểm thử hộp đen

2.3.3 Ki m th h th ng ểu ử tích hợp ệu tham khảo ống

(System Testing)

 Hệ thống Test lại gồm nhiều loại kiểm tra

khác nhau, trong đó phổ biến nhất gồm:

- Kiểm tra chức năng (Functional Test): bảo

đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế.

- Kiểm tra khả năng vận hành (Performance

Test): bảo đảm tối ưu việc phân bổ tài nguyên hệ thống (ví dụ bộ nhớ) nhằm đạt các chỉ tiêu như thời gian xử lý của hệ thống.

2.3.3 Ki m th h th ng ểu ử tích hợp ệu tham khảo ống

(System Testing)

- Kiểm tra khả năng chịu tải (Stress Test

hay Load Test): bảo đảm hệ thống vận hành đúng dưới áp lực cao khi có nhiều người truy cập Hệ thống Test tập trung vào các trạng thái tới hạn, các "điểm chết", các tình huống bất thường

- Kiểm tra cấu hình (Configuration Test)

- Kiểm tra khả năng bảo mật (Security

2.3.3 Ki m th h th ng ểu ử tích hợp ệu tham khảo ống

(System Testing)

- Kiểm tra khả năng phục hồi

(Recovery Test): bảo đảm hệ thống

có khả năng khôi phục trạng thái ổn định trước đó về dư liệu.

2.3.3 Ki m th h th ng ểu ử tích hợp ệu tham khảo ống

(System Testing)

* Lưu ý không nhất thiết phải thực hiện tất cả các loại

kiểm tra nêu trên Tùy yêu cầu của phần mềm mà chọn loại kiểm tra cho phù hợp

* Nhìn từ quan điểm của người dùng thì các kiểm tra

trên rất quan trọng: để bảo đảm hệ thống đủ khả năng làm việc trong môi trường thực.

* Stress Test hay Performance Test và Security Test

thường được thực hiện ở giai đoạn này

2.3.4 Ki m th ch p nh n ểu ử tích hợp ấp nhận ận

(Acceptance Testing)

* Mục đích của Acceptance Test là

2.3.4 Ki m th ch p nh n ểu ử tích hợp ấp nhận ận

(Acceptance Testing)

- Alpha Test: là giai đoạn Acceptance

Test, trong đó người đóng vai trò thực hiện là các Khách hàng tiềm năng hoặc người đóng vai trò người

sử dụng nhưng với số lượng ít và làm việc trực tiếp với đơn vị sản xuất ra phần mềm đó để sửa lỗi (nếu có).

2.3.4 Ki m th ch p nh n ểu ử tích hợp ấp nhận ận

(Acceptance Testing)

- Beta Test là giai đoạn Acceptance Test

sau khi thực hiện xong Alpha Test:

Sau khi test với số lượng khách hàng tiềm năng trước, các công ty sản xuất phần mềm mass sẽ tung ra thị trường cho người dùng sử dụng thử nghiệm và lấy ý kiến phản hồi từ người sử dụng

2.3.5 Các giai đoạn kiểm thử

* Kiểm thử hồi quy (Regression

Testing).

* Kiểm thử tính đúng (Correctness

Testing).

*** L i k t*** ời kết*** ết***

Chúng em nhóm 12 Lớp CNTT6

Đ6LT Xin chân thành cảm ơn thầy

giáo Trần Đức Lưu đã trực tiếp

giảng dạy và hướng dẫn chúng em

thực hiện đề tài này