NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Software Testing

Khái niệm kiểm thử phần mềmKiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh n

Lê Minh Cảnh Nguyễn Văn Đồng

Võ Ngọc Duy Bão

Software Testing

Nội dung:

I Khái niệm kiểm thử phần mềm

II Tiến trình kiểm thử phần mềm

III Các phương pháp kiểm thử

IV Chiến lược kiểm thử

V Các cấp độ kiểm thử phần mềm

VI Liên hệ ngành kiểm thử phân mềm ở Việt Nam

I Khái niệm kiểm thử phần mềm

Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó (Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software

Engineering Terminology)

Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi (Theo “The Art of Software Testing” – Nghệ thuật kiểm thử phần mềm)

I Khái niệm kiểm thử phần mềm

• Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là một tiến trình hay một tập hợp các tiến trình được thiết

kế để đảm bảo mã hóa máy tính thực hiện theo cái mà chúng đã được thiết kế để làm, và không thực hiện bất cứ thứ gì không mong muốn Đây là một pha quan trọng trong quá trình phát triển hệ thống, giúp cho người xây dựng hệ thống và khách

hàng thấy được hệ thống mới đã đáp ứng yêu cầu đặt ra hay

chưa?

II Tiến trình kiểm thử phần mềm

• Kiểm thử thành phần

• Kiểm thử các thành phần riêng biệt của chương trình

• Thường là trách nhiệm của người phát triển phần mềm

• Kiểm thử xuất phát từ kinh nghiệm của người phát triển phần mềm

Kiểm thử hệ thống

- Kiểm thử các nhóm thành phần tích hợp để tạo ra 1 hệ

thống hoặc 1 hệ thống phụ

- Là trách nhiệm của nhóm kiểm thử độc lập

- Kiểm thử dựa trên đặc tả hệ thống

II Tiến trình kiểm thử phần mềm

Component testing

System testing

Software developer Independent testing team

II Tiến trình kiểm thử phần mềm

Test case

Test data

Test results

Test reports

Design test cases

Prepare test data

Run program with test data

Compare results to test cases

III Các phương pháp kiểm thử

• Có 2 phương pháp kiểm thử chính là: kiểm thử tĩnh và kiểm thử động

1 Kiểm thử tĩnh

• Là phương pháp thử phần mềm đòi hỏi phải duyệt lại các yêu cầu và các đặc tả bằng tay, thông qua việc 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 Kiểu kiểm thử này thường được sử dụng bởi chuyên viên thiết kế người mà viết mã lệnh một mình

• Kiểm thử tĩnh cũng có thể được tự động hóa Nó sẽ thực hiện kiểm tra toàn bộ bao gồm các chương trình được

phân tích bởi một trình thông dịch hoặc biên dịch mà xác nhận tính hợp lệ về cú pháp của chương trình

liệu đầu ra có như mong muốn hay không Các phương pháp

kiểm thử động gồm có kiểm thử Unit – Unit Tests, Kiểm thử tích hợp – Intergration Tests, Kiểm thử hệ thống – System Tests, và Kiểm thử chấp nhận sản phẩm – Acceptance Tests.

IV Chiến lược kiểm thử

 1 Kiểm thử hộp đen – Black box testing

• Phương pháp kiểm thử Black box là nghiên cứu xem phần mềm như là một “hộp đen” – không biết gì về hoạt động bên trong của nó

IV Chiến lược kiểm thử

 1 Kiểm thử hộp đen – Black box testing

• .Phân lớp tương đương – Equivalence partitioning.

• Phân tích giá trị biên – Boundary value analysis.

• Kiểm thử mọi cặp – All-pairs testing.

• Kiểm thử fuzz – Fuzz testing

• Kiểm thử dựa trên mô hình – Model-based testing

• Ma trận dấu vết – Traceability matrix.

• Kiểm thử thăm dò – Exploratory testing.

• Kiểm thử dựa trên đặc tả – Specification-base testing.

IV Chiến lược kiểm thử

 1 Kiểm thử hộp đen – Black box testing

• Ưu, nhược điểm:

• Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi Sử

dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra

Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là

đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào.

• Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách

quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

IV Chiến lược kiểm thử

 2 Kiểm thử hộp trắng – White box testing

 Trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp

trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu

trúc bên trong của chương trình Chiến lược này xuất phát từ

dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật

bên trong chương trình (và cả mã lệnh thực hiện chúng)

IV Chiến lược kiểm thử

 2 Kiểm thử hộp trắng – White box testing

IV Chiến lược kiểm thử

 2 Kiểm thử hộp trắng – White box testing

 Các phương pháp kiểm thử hộp trắng:

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

 Bao phủ mã lệnh – Code coverage

 Các phương pháp gán lỗi – Fault injection

 Các phương pháp kiểm thử hoán chuyển – Mutation testing methods

 Kiểm thử tĩnh – Static testing

IV Chiến lược kiểm thử

 3 Kiểm thử hộp xám – Gray box testing

 Grey box testing (Viết theo Tiếng Mỹ: gray box testing) bao gồm các kiến thức về các thuật toán, cấu trúc bên trong của chương trình để thực hiện mục đích việc thiết kế các trường hợp test, nhưng việc test phải thực hiện như là người dùng

(suy nghĩ theo cách nghĩ của người dùng cuối), hoặc thiết kế ở mức black-box

 Grey box testing cũng có thể bao gồm kỹ thuật đảo ngược để xác định, ví dụ, các giá trị biên hoặc thông báo lỗi

V Các cấp độ kiểm thử phần mềm

• Các cấp độ kiểm thử phần mềm:

• Kiểm thử đơn vị – Unit test- Component testing

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

• Kiểm thử hệ thống – System Test

• Kiểm thử chấp nhận sản phẩm – Acceptance Test

V Các cấp độ kiểm thử phần mềm

• 1 Component testing

• Nền tảng kiểm tra:

• Các tài liệu mô tả chi tiết về component

• Thiết kế chi tiết

V Các cấp độ kiểm thử phần mềm

• 2 Kiểm thử tích hợp – Intergration Test

• Integration test kết hợp các thành phần của một ứng dụng và

kiểm thử như một ứng dụng đã hoàn thành Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng

• Hai mục tiêu chính của Integration Test:

• Phát hiện lỗi giao tiếp xảy ra giữa các Unit

• Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

• Các tiến trình công việc (Workflows)

• Các trường hợp sử dụng (Use cases)

Các mục tiêu kiểm tra chung:

• Việc thực thi database của Sub-system

• Cơ sở hạ tầng (phần cứng máy móc, mạng, )

• Giao tiếp (Interfaces)

V Các cấp độ kiểm thử phần mềm

• 2 Kiểm thử tích hợp – Intergration Test

V Các cấp độ kiểm thử phần mềm

• 3 Kiểm thử hệ thống – System Test

• Bao gồm các thành phần tích hợp để tạo ra 1 hệ thống hoặc 1 hệ thống phụ

• Có thể bao gồm việc kiểm thử 1 increment được giao cho khách hàng

• Hai giai đoạn:

- Kiểm thử tích hợp: nhóm kiểm thử có thể truy cập vào mã nguồn của hệ thống Hệ thống được kiểm thử là các thành phần được tích hợp

- Kiểm thử phát hành(release testing): nhóm kiểm thử kiểm thử hệ thống hoàn chỉnh sẽ được chuyển giao như một black-box

• Bảng mô tả chi tiết chức năng

• Các báo cáo phân tích rủi ro

Các mục tiêu kiểm tra chung:

• Các hướng dẫn vận hành và người dùng, hệ thống

• Cấu hình hệ thống

V Các cấp độ kiểm thử phần mềm

•4 Kiểm thử chấp nhận sản phẩm – Acceptance Test

• Nền tảng kiểm tra:

• Các yêu cầu người dùng (User requirements)

• Các yêu cầu hệ thống (System requirements)

• Các trường hợp sử dụng (Use cases)

• Các qui trình xử lý công việc (Business processes)

• Các báo cáo phân tích rủi ro (Risk analysis reports)

Các mục tiêu kiểm tra chung:

• Kiểm tra các qui trình xử lý công việc trên hệ thống đã được tích hợp đầy đủ nhất.

• Các qui trình hoạt động và bảo trì

• Các thủ tục người dùng (ví dụ: phân quyền dựa trên user login)

• Các form (ví dụ, các màn hình nhập liệu)

• Các Report (ví dụ các bản báo cáo như phiếu thu để in, báo cáo doanh thu…)

V Các cấp độ kiểm thử phần mềm

• 4 Kiểm thử chấp nhận sản phẩm – Acceptance Test

• Thông thường, sau giai đoạn System Test là Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ

ba thực hiện) Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách

hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng)

• Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt

VI Liên hệ ngành kiểm thử phân mềm ở

Việt Nam

• Ở Việt Nam, cứ 5 lập trình viên thì mới có 1 kỹ sư kiểm thử

phần mềm, trong khi đó, theo chuẩn quốc tế, con số này là 3:1

• Thực tế cho thấy số lượng đơn vị đào tạo chuyên sâu, các kỹ sư chuyên nghiệp về kiểm thử phần mềm ở Việt Nam không nhiều, chưa thể đáp ứng đủ cho các dự án doanh nghiệp

• "Nếu xét theo tiêu chuẩn quốc tế, tỷ lê giữa lập trình viên và kỹ

sư phần mềm là 1:3, đôi khi tỷ lệ này là 1:1 với những dự án

đặc thù nhưng tại Việt Nam, tỷ lệ này chỉ rơi vào khoảng 1:5", đại diện tập đoàn kiểm thử phần mềm Logigear cho biết

VI Liên hệ ngành kiểm thử phân mềm ở

Việt Nam

• Trong buổi họp báo công bố Hội nghị quốc tế về kiểm thử phần mềm chiều 14/7, Logigear phân tích thực trạng ở Việt Nam là dù biết các công tác kiểm thử giữ vai trò rất quan trọng trong việc mang lại thành công cho các dự án phần mềm nhưng không phải công ty nào cũng có

đủ chuyên môn và điều kiện để thực hiện.

• Tuy nhiên, tập đoàn kiểm thử phần mềm quốc tế này cũng khẳng định với những lợi thế về cạnh tranh như nhân lực rẻ lại có sẵn trình độ kỹ thuật, môi trường đầu tư an toàn, chất lượng dịch vụ nổi trội, tỉ lệ thay đổi nhân sự thấp Việt Nam hòn toàn có thể trở thành mội trường hấp dẫn trong ngành kiểm thử phần mềm.

VI Liên hệ ngành kiểm thử phân mềm ở Việt Nam

THE END