Bài Giảng Kiểm Thử Phần Mềm

KIỂM THỬ PHẦN MỀM 2021 KIỂM THỬ PHẦN MỀM NỘI DUNG Tổng quan kiểm thử phần mềm Quy trình và kế hoạch Các cấp độ KT Phương pháp Kỹ thuật Quản lý việc kiểm thử Công cụ Nhập môn lập trình 2014 TỔNG QUAN.

Tổng quan kiểm thử phần mềm Quy trình và kế hoạch

Các cấp độ KT

Phương pháp & Kỹ thuật

Quản lý việc kiểm thử

Công cụ

Kiểm thử là gì?

Vì sao phải kiểm thử Nguyên tắc

Khía cạnh tâm lý học Các khái niệm

ANSI/IEEE 1059

Beizer

VÌ SAO PHẢI TEST

“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 kiểm tra để 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

BUG

BUG

BUG

• Bug ngân hàng ở Mỹ lộ 823 tài khoản,

920.000.000$

VAI TRÒ CỦA KIỂM THỬ

VAI TRÒ CỦA KIỂM THỬ

VAI TRÒ CỦA KIỂM THỬ

KIỂM THỬ BAO NHIÊU LÀ ĐỦ?

Các hoạt động của việc kiểm thử

• Lên kế hoạch và xử lý

• Lựa chọn các điều kiện kiểm thử

• Thiết kế các trường hợp kiểm thử (testcase)

• Kiểm tra kết quả

• Đánh giá các tiêu chuẩn hoàn thành

• Báo cáo quá trình kiểm thử

• Hoàn thành các hoạt động kiểm kết thúc kiểm thử sau một giai đoạn kiểm thử đã hoàn thành

NGUYÊN TẮC

• KT chỉ ra sự hiện diện của những khiếm khuyết, không chỉ ra được là PM không có khiếm khuyết

• KT toàn bộ (Exhaustive testing) là không thể

• Kiểm thử càng sớm càng tiết kiệm được thời gian

và tiền bạc

• Sự tập trung của các lỗi

• Pesticide paradox

• KT phụ thuộc vào ngữ cảnh

KHÍA CẠNH TÂM LÝ HỌC

• Tính độc lập

• Đoán lỗi

• KT thường được cọi là 1 hành động phá hoại?

• Test leader và tester cần có kỹ năng giao tiếp tốt đểtruyền đạt thông tin thực tế về lỗi, tiến độ và rủi ro

• Khách quan, tập trung vào thực tế mà ko có sự thùghét cá nhận

• Mục tiêu chung là giúp hệ thống đạt chất lượng tốt

• Failure: là kết quả của một lỗi xuất hiện làm cho

chương trình không hoạt động được hay hoạt động nhưng cho kết quả không như mong đợi

• Phán xét kiểm thử (test oracle)

Đánh giá kết quả của kiểm thử

- tự động: chương trình

- thủ công: con người

CÁC KHÁI NIỆM

• Verification: là quy trình xác định xem sản phẩm của một công đoạn trong quy trình phát triển phần mềm có thỏa mãn các yêu cầu đặt ra trong công đoạn trước haykhông?(Ta có đang xây dựng đúng sản phẩm mà được đăc tả không?)

• Xác minh quan tâm tới việc ngăn chặn lỗi giữa các công đoạn

• Xác minh thường là hoạt động kỹ thuật và nó có sử

• dụng các kiến thức về các yêu cầu, các đặc tả rời rạc của phần mềm

• Các hoạt động của xác minh bao gồm: Kiểm thử

• (Testing) và Rà soát loại (Review)

CÁC KHÁI NIỆM

VALIDATION

• Là tiến trình nhằm chỉ ra toàn bộ hệ thống đã phát triển xong phù hợp với tài liệu mô tả yêu cầu

• Là quá trình kiểm chứng chúng ta xây dựng phầm mềm có đúng theo yêu cầu khách hàng không?

• Chỉ quan tâm đến sản phẩm cuối cùng không còn lỗi

Mô hình thác nước

Chia quá trình phát triển PM thành những giai đoạn tuần tự Mỗi giai đoạn có 1 mục đích nhất định

Kết quả giai đoạn này sẽ là đầu vào cho giai đoạn sau

Mô hình thác nước

• Ưu điểm

- Các giai đoạn được định nghĩa, đầu vào rõ ràng 

dễ phân công

- Quá trình phát triển đơn giản  dự án ít thay đổi

- Giảm thiểu các lỗi mắc phải trong giai đoạn thiết kế

• Khuyết điểm

- Tốn nhiều thời gian để thực hiện

- Sữa lỗi tốn nhiều chi phí (đặc biệt là lỗi trong giai

đoạn đầu)

Mô hình chữ V

Mô hình chữ V

• ƯU ĐIỂM

– Các pha tương thích nhau, hỗ trợ cho nhau

– Khuyến thích các hoạt động liên quan đến kế

MÔ HÌNH SCRUM-AGILE

KT TRONG MÔ HINH SCRUM

Sơ đồ tổ chức phổ biến của đội kiểm thử

QUY TRÌNH KIỂM THỬ

QUY TRÌNH KIỂM THỬ

• Phân tích yêu cầu

nghiệp vụ của hệ thống, tài liệu báo cáo tính khả thi,

phân tích rủi ro của việc kiểm thử phần mềm

QUY TRÌNH KIỂM THỬ

• Thiết kế kịch bản

– Đầu vào là test plan

– Review tài liệu

– Viết test case/ check list

– Chuẩn bị data test

– Review test case/ check list

=>test design, test case, check list, test data, test

automation script

QUY TRÌNH KIỂM THỬ

• Thiết lập môi trường

– Đầu vào: test plan, test case, test data

– Phụ thuộc vào đặc thù của PM và yêu cầu của KH – VD: dựng server, mạng, …

QUY TRÌNH KIỂM THỬ

• Thực hiện

– Đầu vào: test plan, test design, test case, check list, test data, test automation script

– Thực thi test case

– Đưa các bug lên hệ thống quản lý lỗi để theo dõi

– Re-test

– KT hồi qui

– Theo dõi và phân tích tiến độ

– Lập báo cáo

Quy trình thực hiện

Quy trình xử lý lỗi

QUY TRÌNH KIỂM THỬ

• Kết thúc

– Đầu vào là tất cả các tài liệu, báo cáo có liên quan

– Thực hiện tổng kết, báo cáo kết quả về việc thực thi test case

– Đánh giá các tiêu chí hoàn thành

– Thảo luận tất cả những điểm tốt, điểm chưa tốt và rút ra bài học kinh nghiệm

Các hoạt động chính trong giai đoạn kết thúc KT

1 Kiểm tra các sản phẩm thực tế được bàn giao so với kế hoạch Đảm bảo

các lỗi được giải quyết hay có kế hoạch giải quyết cho các lần bàn giao sau

2 Đóng các báo cáo về sự cố hoặc ghi chép các thay đổi cho bất cứ vấn đề

6 Phân tích các bài học để xác định những điểm cần thay đổi cho dự án sau

7 Sử dụng các thông tin thu thập được để cải tiến công việc kiểm thử một

cách định kỳ.

yêu cầu người sử dụng, tiêu chí

được chấp nhận, thiết kế chi tiết

(nếu có), những ràng buộc của

khách hàng

– Xác đinh những gì cần phải test

Test lead, Tester,

Tài liệu yêu cầu

Danh sách các yêu cầu cần test, gồm cả chức

năng và phi chức năng

Xác định phương thức, loại kiểm

thử cần thực hiện, tiêu chí đầu ra

Test lead

Phương thức kiểm thử, tiêu chí đầu

KẾ HOẠCH

Hành động Người thực

hiện Đầu vào Đầu ra

Xác định nguồn lực và môi trường thực hiện

dự án phầm mềm

Danh sách tài nguyên

Khi xác định được tài

nguyên, nhân lực

Bảng thời gian cụ thể cho từng giai đoạn kiểm thử

KẾ HOẠCH

Hành động Người thực

hiện Đầu vào Đầu ra

Đánh giá kế hoạch

Trưởng dự án sẽ cùng những người liên quan

tham gia đánh giá xem bản kể hoạch kiểm

thử có phù hợp với yêu cầu của dự án chưa

Nếu chưa thì test lead sẽ phải thực hiện sửa

lại theo yêu cầu.

Test lead

Khi các yêu cầu bên trên

đã rõ ràng

Tài liệu Test Plan

Tạo base line:

Khi kế hoạch test đã được duyệt thì bản kế

hoạch này sẽ được đánh baseline và chuyển

vào thư mục baseline được tạo

Test lead

Khi đã xây dựng xong test plan

Tài liệu testplan được duyệt.

Test lead sẽ gửi thông báo qua mail tới toàn

QUY TRINH XÂY DỰNG KH KT

1 Giới thiệu

• Mục đích: Trình bày ngắn gọn về mục đích và tổ chức của tài liệu

• Các định nghĩa, từ viết tắt, thuật ngữ: cung cấp các định nghĩa của các thuật ngữ, từ viết tắt cần thiết để giải thích đúng các kế hoạch kiểm thử

• Tài liệu tham khảo: Liệt kê tất cả những tài liệu dùng để tạo ra bản kế hoạch

• Thông tin cơ bản: Mô tả ngắn gọn về dự án

• Phạm vi kiểm thử:

– Danh mục các giai đoạn kiểm thử

– Danh sách các loại hình kiểm thử

– Danh sách các giả định

– Các khiểm khuyết theo dự kiến

• Danh mục các rủi ro: Liệt kê các rủi ro có thể ảnh hưởng đến việc thiết kế hoặc thực thi các KT

• Nhu cầu đào tạo: Liệt kê các nhu cầu đào tạo của các thành viên trong nhóm để thực thi việc KT

2 Các tiêu chí chấp nhận

• Danh sách các tiêu chí nhằm xác định mức độ chấtlượng kiểm thử đủ để bàn giao cho khách hàng

hoặc đủ để sang pha tiếp theo

3 Yêu cầu cần KT

• Liệt kê các yêu cầu kiểm thử

– Yêu cầu chức năng

– Yêu cầu phi chức năng

• Liệt kê các đặc tính và chức năng không cần KT

• Công cụ kiểm thử: liệt kê đầy đủ các công cụ hỗ trợ kiễm thử

4 Chiến lược

Có 2 chiến lược kiểm thử cơ bản:

• Kiểm thử Big bang(kiểm thử vụ nổ lớn): là chiến lược kiểm thử tích hợp hệ thống một lần duy nhất để được module chức năng (hay hệ thống hoàn chỉnh)

• Kiểm thử gia tăng: chiến lược kiểm thử từ thấp tới cao,bao gồm 4 mức:

– Kiểm thử đơn vị

– Kiểm thử tích hợp

– Kiểm thử hệ thống

– Kiểm thử chấp nhận

– Nguồn lực hệ thống: liệt kê các phần mềm phần cứng

để đáp ứng cho việc kiểm thử

6 Test milestone

• Một milestone là một sự kiện, một thành tích KT quan trọng đạt được hay cần đạt được của dự án

• Mỗi cột mốc kiểm thử phải bao gồm ít nhất một hoạt động kiểm thử và đạt được một hoặc nhiều sản phẩm kiểm thử

KT UNIT

• Các vấn đề quan tâm trong UNIT test

– Sự hoàn chỉnh và đúng đắn của các chức năng

– Xử lý lỗi

– Kiểm tra giá trị đầu vào

– Tính đúng đắn của giá trị đầu ra

– Tối ưu thuật toán

LỢI ÍCH CỦA KT UNIT

• Giúp LTV điều chỉnh code sau này nhưng vẫn đảmbảo tinh đúng đắn của đơn vị

• KT các giai đoạn sau sẽ nhanh hơn

• Phát hiện bug sớm => ít tốn kinh phí hơn

Kỹ thuật áp dụng trong KT UNIT

KT Module

• Còn gọi là component testing

• Được thực hiện bởi tester

• Được thực hiện sau UNIT Testing

• Xác nhận các yêu cầu kiểm thử

Quy trình KT Module

• Mỗi module mã nguồn không phải là một chương

trình hoàn chỉnh và đôi khi phải gọi các module

chưa được kiểm thử khác => có thể phải thiết lập driver và/hoặc stub: phí tổn khá lớn (70%)

• Driver là một chương trình chính có nhiệm vụ

nhận dữ liệu kiểm thử, chuyển dữ liệu đó xuống chomodule để kiểm tra và in ra các kết quả kiểm tra

tương ứng

• Stub thay thế các module được gọi bởi module

Quy trình KT Module

Quy trình KT Module

Module Test Planning

Module Test Specification

Module Test Execution

Module Test Recording

BEGIN

• Có 2 phương án để KT Module

– Kiểm tra thành phần ở quy mô nhỏ (CTIS)

Kiểm thử các module chức năng độc, tách biệt với các thành phần khác.

– Kiểm tra thành phần ở dạng lớn (CTIL)

Được thực hiện mà không bị cô lập với các thành phần khác của phần mềm

KT Tích hợp

• Kiểm thử tích hợp nhằm nhận được một bộ phận

chức năng hay một hệ con tốt

• Là một kỹ thuật có tính hệ thống để xây dựng cấu trúc của chương trình

• Từ các module đã qua kiểm thử đơn vị, xây dựng cấu trúc chương trình đảm bảo tuân theo thiết kế

•

• Có hai cách tích hợp:

• Tích hợp từng bước Theo cách này có 3 chiến lược:

– Tích hợp từ dưới lên (bottom-up testing)

– Tích hợp từ trên xuống (top-down testing)

– Kết hợp 2 chiến lược trên (sandwich testing)

• Tích hợp đồng thời: kiểm thử vụ nổ lớn (big bang testing)

– Module kế tiếp phải được dùng trực tiếp bởi module

được kiểm thử rồi

– Vì có nhiều module cùng thỏa mãn điều kiện trên, nên

ta chọn module thực hiện nhiều hoạt động I/O trước.

– Rồi chọn module "critical", là module dùng thuật giải

KT top-down

KT top-down

• Testcase cho module A

– Ví dụ chỉ có B cung cấp thông tin cho A

• Sau khi kiểm thử xong module hiện hành, ta chọn

1 trong các Stub và thay thế nó bằng module thậtrồi kiểm thử module thật này

Ưu điểm của phương pháp top-down

• Phát hiện sớm các lỗi thiết kế: dễ dàng phát hiện các lỗi như phát triển nhầm, thiếu chức năng so với đặc tả, do đó làm giảm chi phí cho việc thiết kế và cài đặt lại

• Chương trình khung sườn sớm hình thành để demo

và tiếp thêm sức mạnh tinh thần cho những người phát triển phần mềm

Khuyết điểm của phương pháp top-down

• Tạo stub thường phức tạp

• Nếu module nhập/xuất xa với module cần test => rất khó cung cấp dữ liệu

KT bottom-up

• Bắt đầu từ 1 hay nhiều module lá : module mà

không gọi module nào khác

• Module kế tiếp phải dùng trực tiếp 1 hay nhiều

module được kiểm thử rồi

• Chọn module thực hiện nhiều hoạt động I/O trước

• Kế đến là module "critical“: module dùng thuật giảiphức tạp, tiềm ẩn nhiều lỗi

KT bottom-up

• Các module E, J, G, K, L

và I ₫ược kiểm thử trước

• Để kiểm thử 1 module,

ta phải viết driver

• Driver dễ tạo ra hơn

stub

KT bottom-up

• Nếu D và F là 2 module critical nhất, thì ta nên kiểm thử theo trình tự của hình vẽ dưới đây

Ưu điểm KT bottom-up

• Nếu các lỗi xảy ra có khuynh hướng nằm trong cácmodule mức thấp thì phương pháp bottom-up sẽgiúp phát hiện sớm chúng

• Việc tạo các điều kiện kiểm thử sẽ dễ dàng hơn

• Việc quan sát các kết quả kiểm thử cũng dễ dànghơn

Khuyết điểm KT bottom-up

• Phải viết các module driver, mặc dù việc viết các module này khá dễ dàng

• Chương trình khung sườn chưa tồn tại 1 thời gian dài cho đến khi module cuối cùng được tích hợp vào hệ thống

KT hệ thống

• Kiểm thử hệ thống:

– Tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống

– Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm

dụng bộ nhớ

– Đòi hỏi nhiều thời gian, công sức, thiết bị…

– Mục đích: kiểm thử thiết kế và toàn bộ hệ thống có thỏa

KT hệ thống

• Khi nào có thể thực hiện KT hệ thống?

– Hệ thống cần kiểm thử đã hoàn thiện

– Kiểm thử tích hợp và đơn vị đã hoàn thành

– Sản phẩm được tích hợp đúng thiết kế

– Các tài liệu đặc tả đã là bản cuối cùng

– Các tài liệu hỗ trợ kiểm thử như test plan, test case đã hoàn thành

KT hệ thống

System Testing

Installation Testing Functionality

Testing

Interoperability Testing

Performance Testing

Load & Stability Reliability

Regression Testing

Document Testing

Security Testing

Usability Testing

Recoverability Testing

Phương pháp KT

Kỹ thuật KT

Phương pháp KT

• Hộp đen

• Hộp trắng

• Hộp

KT hộp đen

• Coi hệ thống là một hộp đen,

không thể thấy được cấu trúc

logic bên trong

• Tập trung vào các yêu cầu

chức năng của phần mềm

dựa trên các dữ liệu lấy từ đặc

tả

KT hộp đen

• Đặc trưng của KT hộp đen

– Kiểm tra xem PM có đủ chức năng chưa

– Các chức năng có đúng không

– Thực hiện các phép thử qua giao diện

• Một vài kỹ thuật được áp dụng trong KT hộp đen

– Phân vùng tương đương

– Phân tích giá trị biên

– Bảng hỗ trợ quyết định

Phân vùng tương đương

• Chia miền đầu vào của một chương trình thành cáclớp dữ liệu

• Lớp tương đương biểu thị cho tập các trạng thái hợp

lệ hay không hợp lệ đối với điều kiện vào

• Các lớp tương đương được xác định bằng cách lấymỗi trạng thái đầu vào (thường là 1 câu hay 1 cụm

từ trong đặc tả) và phân chia nó thành 2 hay nhiềunhóm

Phân vùng tương đương

• Ví dụ

Phân vùng tương đương

• Nguyên tắc xác định lớp tương đương

– Nếu điều kiện đầu vào định rõ giới hạn của một mảng, hoặc một giá trị xác định thì chia vùng tương đương

thành:

• Một lớp tương đương hợp lệ

• Hai lớp không hợp lệ

• Một lớp đặc biệt (nếu có)

Phân vùng tương đương

• Nguyên tắc xác định lớp tương đương

– Nếu điều kiện đầu vào chỉ định là một tập giá trị, hoặc xác định là một kiểu đúng sai thì chia vùng tương đương thành :

• Một lớp tương đương hợp lệ.

• Một lớp tương đương không hợp lệ.

• Một lớp đặc biệt (nếu có)

Phân vùng tương đương

• Ví dụ:Khi cấp số thẻ thành viên clb, 3 số đầu của

số thẻ phải nằm trong khoảng [111, 222], nếu sai

sẽ có thông báo yêu cầu nhập lại, 2 số cuối phải thuộc khoảng [11,99]

Phân vùng tương đương

• Đối với 2 số đầu:

– >= 11 và <= 99: hợp lệ

– 99: không hợp lệ

– Để trống : trường hợp đặc biệt thuộc không hợp lệ

Phân tích giá trị biên

• Tập trung phân tích các giá trị biên của miền dữ

liệu để xây dựng dữ liệu kiểm thử

• Nguyên tắc : đối với một biến, kiểm thử các dữ liệu vào gồm:

– Giá trị nhỏ nhất: min

– Giá trị gần kề lớn hơn giá trị nhỏ nhất: min+1

– Giá trị gần kề nhỏ hơn giá trị nhỏ nhất: min -1

– Giá trị lớn nhất : max

Phân tích giá trị biên

• Ví dụ phân tích giá trị biên của trường hợp sau: 20<= Nhiệt độ <=40

Phân tích giá trị biên

• Đối với 2 đầu vào x1, x2 có điều kiện x1∈ [a,b], x2∈[c,d]

Phân tích giá trị biên

• Ví dụ: Khi cấp số thẻ thành viên clb, 3 số đầu của

số thẻ phải nằm trong khoảng [111, 222], nếu sai

sẽ thông báo yêu cầu nhập lại, 2 số cuối phải thuộc khoảng [11,99]