BÀI GIẢNG KIỂM THỬ PHẦN MỀM

Các khái niệm cơ bản về kiểm thử phần mềm Quy trình kiểm thử phần mềmKế hoạch kiểm thử phần mềm Nguyên tắc kiểm thử phần mềm 5. Chiến thuật kiểm thử phần mềm Các phương pháp kiểm thử phần mềm Chiến lược kiểm thử phần mềm.

Nhóm 4

Nguyễn Hồng Liễu Trần Diệu Linh Trần Thị Linh

Phạm Thị Như Quỳnh Nguyễn Minh Thư Nguyễn Thị Thu Dịu

Chương 6: Kiểm Thử Phần Mềm

1. Các khái niệm cơ bản về kiểm thử phần mềm

2. Quy trình kiểm thử phần mềmKế hoạch kiểm thử phần mềm

I CÁC KHÁI NIỆM CƠ BẢN VỀ KIỂM THỬ PHẦN

MỀM

 Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm đó có đúng với đặc tả không và thực hiện trong môi trường như mong đợi không.

2 Khái niệm

- Mục đích của kiểm thử phần mềm là tìm ra lỗi chưa được phát hiện, tìm một cách sớm nhất và đảm bảo rằng lỗi đã được sửa mà kiểm thử phần mềm không làm công việc chẩn đoán nguyên nhân gây ra lỗi đã được phát hiện và sửa lỗi.

2 Khái niệm

- Mục tiêu của KTPM là thiết kế tài liệu kiểm thử một cách có hệ thống và thực hiện nó sao cho có hiệu quả nhưng tiết kiệm được thời gian, công sức và chi phí.

2 Khái niệm

3 Chất lượng phần mềm

 Đặc tả định hướng theo những yêu cầu của khách hàng( như tính hiệu quả, tính bảo mật,

…) và những yêu cầu của chính tổ chức phát triển phần mềm

 Một số yêu cầu về chất lượng rất khó chỉ ra rõ ràng

 Những đặc tả phần mềm thường không đầy đủ và hay mâu thuẫn

II QUY TRÌNH KIỂM THỬ PHẦN MỀM

1.1 QUY TRÌNH KIỂM THỬ PHẦN MỀM LÀ GÌ?

- Là chuỗi các hoạt động được tiến hành để thực hiện việc kiểm thử

- Có rất nhiều quy trình kiểm thử phần mềm khác nhau như: mô hình chữ V, mô hình thác nước, mô hình xoắn ốc…hoặc có thể là mô hình kết hợp những mô hình trên

1.2 LÍ DO THỰC HIỆN QUY TRÌNH KIỂM THỬ PHẦN MỀM

Cần làm rõ vai trò và trách nhiệm của việc kiểm thử phần mềm

Cần làm rõ các công đoạn, các bước kiểm thử

Cần phải hiểu và phân biệt các tính chất kiểm thử (tại sao phải kiểm thử), các bước kiểm thử và các kĩ thuật kiểm thử (kiểm thử bằng cách nào)

1.3 AI LIÊN QUAN ĐẾN VIỆC KIỂM THỬ PHẦN MỀM?

Tạo môi trường thử nghiệm

Viết các TH thử nghiệm

Thực hiện các tập lệnh kiểm tra

Phân tích kết quả báo cáo lỗi

Thực hiện kiểm tra hồi quy

Thử nghiệm thoát

Xác định chiến lược

kiểm thửLập kế hoạch kiểm thử

Chuẩn bị môi trường kiểm thử: Hệ điều hành (win 7, win 8, linux, IOS…), Trình duyệt

(IE, Safari, Opera…), thiết bị (Moblie, tablet, deskop…)

Viết testcase cho các trường hợp sẽ test bao gồm cả 3 trường hợp: True, Fail và

không xác định kết quảTiến hành thực thi các Case trong testcase/test scrips để thực hiện việc kiểm thửPhân tích kết quả đã test để tìm hiểu nguyên nhân gây bugTest quy hồi sau khi bug đã được fixedKết thúc kiểm thử cần báo cáo hoặc ghi lại các kinh nghiệm đã gặp phải trong quá

trình test

KHI NÀO NÊN DỪNG KIỂM THỬ

Một vài yếu tố để xác định việc dừng kiểm thử:

Đáp ứng yêu cầu của khách hàng

Hoàn thành toàn bộ kịch bản kiểm thử và đóng hết lỗi

Hoàn thành kiểm thử các chức năng và đạt được mức độ, tiêu chí hoàn thành kiểm thử

Tỉ lệ lỗi giảm và không còn các lỗi có độ ưu tiên cao

Hết ngân sách dành cho kiểm thử

Quyết định của quản lý

III KẾ HOẠCH KIỂM THỬ

III

KẾ HOẠCH KIỂM THỬ

5 Các hoạt động chính trong việc xây

1 Định nghĩa

Kế hoạch kiểm thử thường được để trong 1 file và chứa các kết quả của các hoạt động sau:

Nhận dạng các chiến lược được dùng để kiểm tra và đảm bảo rằng sản phẩm thỏa mãn đặc tả thiết kế phần mềm và các yêu cầu khác về phần mềm.

Định nghĩa các mục tiêu và phạm vi của nỗ lực kiểm thử.

Nhận dạng phương pháp luận mà đội kiểm thử sẽ dùng để thực hiện công việc kiểm thử.

Nhận dạng phần cứng, phần mềm và các tiện ích cần cho kiểm thử

Nhận dạng các tính chất và các chức năng sẽ được kiểm thử

Xác định các hệ số rủi ro gây nguy hại cho việc kiểm thử

Lập lịch kiểm thử và phân phối công việc cho mỗi thành viên tham gia.

Test Manager hoặc Test Leader sẽ xây dựng kế hoạch kiểm thử.

Tập hợp và tổ chức các thông tin kiểm thử cần thiết

Cung cấp thông tin về quy trình kiểm thử sẽ xảy ra trong tổ chức kiểm thử

Cho mỗi thành viên trong đội kiểm thử có hướng đi đúng

Gán các trách nhiệm rõ ràng cụ thể cho mỗi thành viên đội kiểm thử

Có lịch biểu làm việc rõ ràng và các thành viên có thể làm việc với nhau tốt

2 Nhu cầu cần phải có kế hoạch kiểm thử

3 Kế hoạch kiểm thử

 Phạm vi/mục tiêu kiểm thử

 Các chiến lược được dùng

 Các tài nguyên phần cứng và phần mềm phục vụ kiểm thử

 Các nhu cầu về nhân viên và huấn luyện nhân viên

 Các tính chất cần được kiểm thử

 Các rủi ro và sự cố bất ngờ

 Lịch kiểm thử cụ thể

 Các kênh thông tin liên lạc

 Cấu hình cho từng phần tử như kế hoạch kiểm thử, testcase, thủ tục kiểm thử

 Môi trường kiểm thử

 Tiêu chí đầu vào và tiêu chí dừng kiểm thử

 Các kết quả phân phối

4 Quy trình xây dựng kế hoạch kiểm thử

Bắt đầu dự án

Soạn kế hoạch kiểm tra

Xác định các yếu tố rủi ro Xác định các tính năng và chức năng để kiểm tra

Xác định tài nguyên bắt buộc Xác định phương pháp kiểm nghiệm

Xác định phạm vi kiểm tra

và mục tiêu Thiết lập lịch kiểm tra

Xem lại kế hoạch kiểm tra

Làm lại

Kế hoạch kiểm tra đã phê duyệt

Yes No

 Định nghĩa mục đích, phạm vi, chiến lược, cách tiếp cận, các điều kiện chuyển, các rủi ro, kế hoạch giảm nhẹ và tiêu chí chấp thuận

 Định nghĩa cách thức thiết lập môi trường và các tài nguyên được dùng cho việc kiểm thử

 Thiết lập cơ chế theo dõi lỗi phát hiện

 Chuẩn bị ma trận theo dõi bao phủ mọi yêu cầu phần mềm

 Báo cáo trạng thái kiểm thử

 Phát hành leo thang

5 Các hoạt động chính trong việc xây dựng kế hoạch kiểm thử

 Mục đích và phạm vi kiểm thử

Đặc tả mục đích của tài liệu về kế hoạch kiểm thử

Cung cấp vắn tắt về phạm vi mà project được hỗ trợ như platform, loại database, hay

danh sách vắn tắt về các loại project con trong project kiểm thử

6 Các hoạt động chính kế hoạch kiểm thử

 Cách tiếp cận và các chiến lược được dùng

Đặc tả về phương pháp luận kiểm thử sẽ được dùng để thực hiện kiểm thử

Ví dụ: Tổng quan về phương pháp tiếp cận quy trình kiểm thử cho dự án ABC 

Xem lại tài liệu dự án

và tham gia vào các

bài tập lập kế hoạch

dự án

Thiết kế phương pháp thử nghiệm

Xác định yêu cầu kiểm

tra

Tạo kế hoạch thử nghiệm

Thiết kế và xây dựng thử

nghiệm Thực hiện kế hoạch Tạo báo cáo chứng nhận

Đề cập các cấp độ kiểm thử cần thực hiện Các kỹ thuật được dùng cho mỗi kiểu kiểm thử trong project:

Kiểm thử tích hợp (Integration Testing)

Kiểm thử hệ thống (System Testing)

Kiểm thử độ chấp thuận (Acceptant Testing)

Kiểm thử chức năng của người dùng (Functionality Testing)

Kiểm thử hồi quy (Regresstion Testing)

Kiểm thử việc phục hồi sau lỗi (Failover and Recovery Testing)

Kiểm thử việc kiểm soát an ninh và truy xuất (Security and Access Control Testing)

Kiểm thử việc cấu hình và cài đặt (Configuration and Installation Testing)

Kiểm thử đặc biệt

Kiểm thử hiệu xuất (Performance Testing)

 Các tính chất cần được kiểm thử

 Danh sách các tính chất của phần mềm cần được kiểm thử, đây là catalog chưa tất cả các testcase (bao gồm chỉ số testcase, tiêu đề testcase) cũng như tất cả các trạng thái cơ bản.

 Các tính chất không cần được kiểm thử

 Danh sách các vùng phần mềm được loại trừ khỏi kiểm thử, cũng như các testcase đã được định nghĩa nhưng không cần kiểm thử.

 Rủi ro và các sự cố bất ngờ

 Danh sách tất cả rủi ro có thể xảy ra trong chu kì kiểm thử

 Phương pháp mà ta cần thực hiện để tối thiểu hóa hay sống chung với rủi ro.

 Tiêu chí đình chỉ và phục hồi kiểm thử

 Tiêu chí đình chỉ kiểm thử là các điều kiện mà nếu thỏa mãn thì kiểm thử sẽ dừng lại

 Tiêu chí phục hồi là những điều kiện được đòi hỏi để tiếp tục việc kiểm thử đã được ngừng trước đó.

 Môi trường kiểm thử

Đặc tả đầy đủ về các môi trường kiểm thử, bao gồm đặc tả phần cứng, phần mềm, mạng, database, hệ điều hành và các thuộc tính môi trường khác ảnh hưởng đến kiểm thử

Các yêu cầu mà phần mềm phải được kiểm thử dưới các môi trường xác định

Số lỗi tối thiểu ở các cấp an ninh và ưu tiên khác nhau, số phủ kiểm thử tối thiểu

Ký kết và đồng thuận của các bên liên quan

 Nhân sự

Vai trò và trách nhiệm từng người :

Danh sách các vai trò xác định của các thành viên đội kiểm thử trong hoạt động kiểm thử.

Các trách nhiệm của từng vai trò.

Công tác huấn luyện.

Danh sách các huấn luyện cần thiết cho các QC

 Các tiện ích phục vụ kiểm thử

Danh sách tất cả các tiện ích cần dùng trong suốt chu kỳ kiểm thử.

Với project kiểm thử tự ₫ộng, các tiện ích cần ₫ược liệt kê với chỉ số version cùng thông tin license.

 Các kết quả phân phối

Danh sách tất cả tài liệu hay artifacts dự ₫ịnh phân phối nội bộ sau khi mỗi cột mốc kết thúc hay sau khi project kết thúc.

IV NGUYÊN TẮC KIỂM THỬ PHẦN MỀM

NGUYÊN TẮC KIỂM THỬ PHẦN MỀM

Nguyên tắc 1: Kiểm thử chỉ ra sự hiện diện của lỗi

Kiểm thử có thể chỉ ra có mặt của lỗi, nhưng không thể chứng minh rằng sản phẩm không có lỗi. 

Nghĩa là sản phẩm luôn có lỗi cho dù có kiểm thử nhiều bao nhiêu

Do đó, điều quan trọng là chúng ta phải thiết kế các trường hợp kiểm thử (test case) sao cho có thể tìm được càng nhiều lỗi càng tốt

Nguyên tắc 2: Kiểm thử toàn bộ, đầy đủ là không thể

Kiểm thử toàn bộ (kết hợp tất cả các yếu tố đầu vào và điều kiện tiên quyết) là không khả thi trừ những trường hợp nhỏ và đơn giản Thay vì kiểm thử đầy đủ, nên sử dụng những đánh giá rủi ro và nỗ lực để ưu tiên tập trung kiểm thử

Nguyên tắc 3: Cần bắt đầu giai đoạn kiểm thử càng sớm càng tốt

Hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong chu trình phát triển mềm và cần được tập trung vào các mục tiêu xác định

Nguyên tắc 4: Sự tập trung của lỗi

 Nguyên tắc tổ gián: chỗ nào có 1 vài con gián => xung quanh sẽ có cả tổ gián  chỗ nào có một vài bug

thì xung quanh chỗ đó sẽ có nhiều bug

 Nguyên tắc 80/20: 20% chức năng quan trọng trong một chương trình có thể gây ra đến 80% tổng số

bug phát hiện được trong chương trình đó

 Kiểm thử đầy đủ là không thể: cần phải phân tích + tính toán mức độ ưu tiên để quyết định tập trung

vào test chỗ nào

Nguyên tắc 5: Nghịch lý thuốc trừ sâu

Khi sử dụng một loại thuốc trừ sâu mãi thì sâu sẽ bị nhờn thuốc nên phải thay đổi loại thuốc khác

⇒ Dùng đi dùng lại một bộ kịch bản kiểm thử thì sẽ đến lúc không thể tìm ra lỗi mới nữa

⇒ Các bộ kịch bản kiểm thử phải được thường xuyên xem xét và cập nhật, phù hợp với từng thành phần

khác nhau của phần mềm, mang lại khả năng tìm thấy lỗi lớn nhất

Nguyên tắc 6: Kiểm thử theo các ngữ cảnh độc lập

Tuy vào loại cũng như bản chất của ứng dụng mà chúng ta sẽ áp dụng những phương thức, kỹ thuật, cũng như loại kiểm thử khác nhau

Nguyên tắc 7: Sự sai lầm về việc không có lỗi

Việc tìm và sửa lỗi là không có ý nghĩa nếu hệ thống được xây dựng xong nhưng không thể dùng được hoặc không đáp ứng được nhu cầu và sự mong đợi của người dùng

V CHIẾN THUẬT KIỂM NGHIỆM PHẦN MỀM PHỔ BIẾN

Chiến thuật kiểm nghiệm phần mềm phổ biến

- Bắt đầu tại từng module rồi tích hợp lớn dần đến toàn bộ hệ thống

- Các kỹ thuật khác nhau được sử dụng thích hợp tại các giai đoạn khác

Thiết kế chi tiết

Lập trình Rà soát mã

Test đơn vị

Test tích hợp

Test

hệ thống

Test chấp nhận

VI CÁC PHƯƠNG PHÁP VÀ CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM

Khái niệm:

Kiểm thử tĩnh là một hình thức của kiểm thử phần mềm mà không thực hiện phần mềm

Điều này ngược với thử nghiệm động

Thường thì nó không kiểm thử chi tiết mà chủ yếu kiểm tra tính đúng đắn của code (mã lệnh), thuật toán hay tài liệu.

Kiểm thử tĩnh

Chủ yếu là kiểm tra cú pháp của code và hoặc review code hoặc tài liệu để tìm lỗi bằng cách thủ công Đây là loại kiểm thử được thực hiện bởi DEV, làm việc một cách độc lập.

Lỗi được phát hiện ở giai đoạn phát triển này là ít tốn kém để sửa chữa hơn so với lỗi phát hiện được ở

các giai đoạn sau này trong các quy trình phát triển phần mềm

Kiểm thử tĩnh

Kiểm thử động

Khái niệm:

Kiểm thử động là phương pháp kiểm thử phần mềm thông qua việc dùng máy chạy chương trình để điều tra trạng thái từng động tác của chương trình.

Kiểm thử động bao gồm 2 kỹ thuật:

+ Kiểm thử hộp đen

+ Kiểm thử hộp trắng

Kiểm thử động

Kiểm thử hộp đen

Định nghĩa:

Là phương pháp test dựa trên đầu vào và đầu ra của chương trình để test mà không quan tâm tới code bên trong được viết ra sao Tester xem phần mềm như là một hộp đen.

Người kiểm thử không quan tâm đến cấu trúc bên trong của chương trình.

Chỉ quan tâm đến dữ liệu đầu vào (Input) và DL đầu ra (Output) sau khi được xử lý.

Chỉ tập trung vào kiểm tra chức năng của phần mềm.

Kiểm thử hộp đen

Kiểm thử viên không hiểu về mã lệnh nhưng có thể tìm ra lỗi mà DEV không phát hiện ra.

Dựa theo các tài liệu đặc tả, tài liệu phân tích thiết kế để thực hiện test

Kiểm thử hộp đen thường do các Tester thực hiện.

Kiểm thử hộp đen

Hoạt động kiểm thử hộp đen

Kiểm thử hộp trắng

Định nghĩa:

Kiểm thử hộp trắng dựa vào thuật toán, cấu trúc code bên trong của chương trình với mục

đích đảm bảo rằng tất cả các câu lệnh và điều kiện sẽ được thực hiện ít nhất một lần

Khi thiết kế test case và test, các tester truy cập thẳng vào bên trong source code, cấu trúc và

thuật toán của chương trình để xác định xem đơn vị phần mềm thực hiện như thế nào

Người kiểm thử hộp trắng phải có kỹ năng nhất định để thông hiểu chi tiết về đoạn code cần

kiểm thử

Kỹ thuật này chủ yếu dược dùng để kiểm thử mức đơn vị

Hoạt động kiểm thử hộp trắng

Có những lỗi xảy ra trong quá trình gõ bàn phím, hiểu sai cú pháp của ngôn ngữ lập trình chưa đúng nên bắt buộc phải kiểm thử hộp trắng.

Kỹ thuật kiểm thử hộp trắng thường được các DEV thực hiện trong quá trình viết code ở giai

đoạn kiểm thử mức đơn vị luôn

Hoạt động kiểm thử hộp trắng

Trong kỹ thuật này, chúng ta chia không gian thử nghiệm dựa vào cáu trúc của đơn vị cần kiểm

tra

Hoạt động kiểm thử hộp trắng

Kiểm tra giao tiếp của đơn vị là để đảm bảo dòng thông tin vào ra đơn vị luôn đúng (đúng giá trị, khớp kiểu, …).

Kiểm tra dữ liệu cụ bộ để đảm bảo dữ liệu được lưu trữ trong đơn vị toàn vẹn trong suốt quá trình thuật giải được thực hiện.

Kiểm tra các điều kiện biên của các câu lệnh if, vòng lặp để đảm bảo đơn vị luôn chạy đúng tại các biên này

Kiểm tra các con đường thực hiện để đảm bảo mọi con đường thực hiện phải đi qua ít nhất 1 lần.

Con đường thực hiện của 1 đơn vị chương trình là 1 dãy có thứ tự các câu lệnh bên trong đơn vị sẽ được thực hiện khi

kich hoạt đơn vị.

Hoạt động kiểm thử hộp trắng

Kiểm thử hộp xám

Định nghĩa:

Gray Box Testing là một phương pháp kiểm thử phần mềm được kết hợp giữa kỹ thuật kiểm thử Black Box (hộp đen) và White Box (hộp trắng) Trong Kiểm thử Hộp xám, cấu trúc bên trong sản phẩm chỉ được biết một phần.

Ưu điểm, nhược điểm của kiểm thử hộp đen và kiểm thử hộp trắng

Gồm 4 chiến lược:

1. Kiểm thử Đơn Vị - Unit Test

2. Kiểm thử Tích Hợp - Integration Test

3. Kiểm thử Hệ Thống - System Test

4. Kiểm thử Chấp Nhận - Acceptance test

2 CHIẾN LƯỢC KIỂM THỬ PHẦN MỀM

2.1 Kiểm thử Đơn Vị

 Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất Kiểm thử thực hiện trên các hàm hay thành phần riêng lẻ.

 Đơn vị: Là thành phần nhỏ nhất của phần mềm có thể kiểm thử được

Ví dụ: Các hàm, lớp, thủ tục, phương thức.

 Mục đích: Cô lập từng thành phần của chương trình và chứng minh các bộ phận riêng lẻ chính xác về các yêu cầu chức năng.

2.2 Kiểm thử Tích Hợp

Tích hợp các mô đun và kiểm thử chúng dưới một thể thống nhất.

Các đơn vị phần mềm được tích hợp dần thành các mô đun, hệ con cuối cùng là thành hệ thống

hoàn chỉnh.

Một số lỗi giao diện điển hình:

- Sử dụng sai giao diện

- Hiểu nhầm về giao diện

- Xung đột