Luận văn thạc sĩ về nghiên cứu kiểm thử bao phủ phần mềm

Luận văn phân tích kiểm thử bao phủ phần mềm trong luận văn thạc sĩ, vận dụng lý thuyết vững chắc, đề xuất giải pháp sáng tạo cho công nghệ

• Tác giả: Ngô Thùy Linh
• Người hướng dẫn: PGS. Nguyễn Văn Vỵ
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Nghiên Cứu Kiểm Thử Bao Phủ Phần Mềm Và Ứng Dụng
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2010
• Địa điểm: Hà Nội

Mục lục chi tiết

• LỜI CẢM ƠN
• LỜI CAM ĐOAN
• 11. MỞ ĐẦU
• 1. CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM
• 2. CHƯƠNG II: KIỂM THỬ PHẦN MỀM HƯỚNG ĐỐI TƯỢNG
• 3. CHƯƠNG III: KIỂM THỬ BAO PHỦ PHẦN MỀM
• 4. CHƯƠNG IV: MÁY TRẠNG THÁI VÀ KIỂM THỬ BAO PHỦ MÁY TRẠNG THÁI
• KẾT LUẬN VÀ TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng quan về kiểm thử phần mềm

Kiểm thử phần mềm là một hoạt động quan trọng trong quy trình phát triển phần mềm, nhằm đảm bảo chất lượng sản phẩm cuối cùng. Kiểm thử phần mềm không chỉ giúp phát hiện lỗi mà còn đánh giá độ tin cậy của phần mềm. Theo một nghiên cứu, lỗi phần mềm thường xuất phát từ nhiều nguyên nhân, bao gồm sai sót trong đặc tả, thiết kế và lập trình. Việc kiểm thử giúp giảm thiểu chi phí sửa lỗi, đặc biệt là trong các giai đoạn đầu của phát triển phần mềm. Để thực hiện kiểm thử hiệu quả, cần có kế hoạch chi tiết cho từng ca kiểm thử, bao gồm các thông tin như tên mô đun, dữ liệu vào và ra. Một ca kiểm thử thành công là ca phát hiện ra lỗi chưa được phát hiện. Đánh giá phần mềm là một phần không thể thiếu trong quy trình này.

1.1 Khái niệm về lỗi phần mềm

Lỗi phần mềm được định nghĩa là sự không phù hợp giữa chương trình và đặc tả của nó. Các loại lỗi có thể bao gồm việc phần mềm không thực hiện đúng chức năng đã được chỉ định, hoặc thực hiện những chức năng không được phép. Theo Glen Mayers, kiểm thử phần mềm là quá trình vận hành chương trình để tìm ra lỗi. Việc phát hiện lỗi sớm trong quy trình phát triển phần mềm có thể tiết kiệm chi phí và thời gian cho các giai đoạn sau. Do đó, việc xây dựng các ca kiểm thử từ sớm là rất quan trọng.

1.2 Các mức kiểm thử phần mềm

Có bốn mức kiểm thử phần mềm cơ bản: kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống và kiểm thử chấp nhận. Mỗi mức kiểm thử có mục tiêu và phương pháp riêng. Kiểm thử đơn vị tập trung vào việc kiểm tra từng thành phần nhỏ nhất của phần mềm, trong khi kiểm thử tích hợp kiểm tra sự tương tác giữa các thành phần. Kiểm thử hệ thống đánh giá toàn bộ hệ thống sau khi đã tích hợp, và kiểm thử chấp nhận xác định xem phần mềm có đáp ứng yêu cầu của người dùng hay không. Việc tổ chức kiểm thử theo các mức này giúp phát hiện lỗi hiệu quả hơn.

II. Kiểm thử phần mềm hướng đối tượng

Kiểm thử phần mềm hướng đối tượng (OOP) có những đặc thù riêng so với kiểm thử phần mềm truyền thống. Trong OOP, các đối tượng và lớp là những thành phần chính, và việc kiểm thử cần tập trung vào các phương thức và thuộc tính của chúng. Phương pháp kiểm thử trong OOP thường bao gồm kiểm thử đơn vị cho từng lớp, kiểm thử tích hợp cho các đối tượng tương tác, và kiểm thử hệ thống cho toàn bộ ứng dụng. Việc áp dụng các kỹ thuật như kiểm thử hộp đen và hộp trắng giúp phát hiện lỗi hiệu quả hơn. Đặc biệt, việc kiểm thử các trạng thái và chuyển trạng thái của đối tượng là rất quan trọng trong OOP.

2.1 Khái niệm kiểm thử hướng đối tượng

Kiểm thử hướng đối tượng là quá trình kiểm tra các đối tượng và lớp trong phần mềm. Mục tiêu là đảm bảo rằng các phương thức hoạt động đúng và các thuộc tính được quản lý chính xác. Việc kiểm thử này không chỉ giúp phát hiện lỗi mà còn đảm bảo rằng các đối tượng tương tác với nhau một cách chính xác. Các kỹ thuật kiểm thử như kiểm thử hộp đen và hộp trắng được áp dụng để đánh giá chức năng và cấu trúc của các đối tượng.

2.2 Quy trình kiểm thử hướng đối tượng

Quy trình kiểm thử hướng đối tượng bao gồm các bước từ việc lập kế hoạch kiểm thử, thiết kế ca kiểm thử, thực hiện kiểm thử và đánh giá kết quả. Mỗi bước cần được thực hiện một cách cẩn thận để đảm bảo rằng tất cả các khía cạnh của phần mềm đều được kiểm tra. Việc sử dụng các công cụ hỗ trợ kiểm thử cũng rất quan trọng để tự động hóa quy trình và nâng cao hiệu quả kiểm thử.

III. Kiểm thử bao phủ phần mềm

Kiểm thử bao phủ phần mềm là một phương pháp đánh giá mức độ mà các ca kiểm thử đã kiểm tra các phần của mã nguồn. Mục tiêu chính là đảm bảo rằng tất cả các nhánh và đường đi trong mã đều được kiểm tra. Công cụ kiểm thử bao phủ giúp xác định các phần của mã chưa được kiểm tra, từ đó cải thiện chất lượng phần mềm. Việc đạt được mức độ bao phủ cao không chỉ giúp phát hiện lỗi mà còn tăng cường độ tin cậy của phần mềm. Các phương pháp như kiểm thử bao phủ dòng lệnh và bao phủ nhánh là những kỹ thuật phổ biến trong lĩnh vực này.

3.1 Các phương pháp kiểm thử bao phủ

Có nhiều phương pháp kiểm thử bao phủ khác nhau, bao gồm kiểm thử bao phủ dòng lệnh, bao phủ nhánh và bao phủ điều kiện. Mỗi phương pháp có ưu điểm và nhược điểm riêng. Kiểm thử bao phủ dòng lệnh tập trung vào việc đảm bảo rằng tất cả các dòng mã đều được thực thi, trong khi bao phủ nhánh kiểm tra tất cả các nhánh trong mã. Việc áp dụng các phương pháp này giúp phát hiện lỗi hiệu quả hơn và đảm bảo rằng phần mềm hoạt động đúng như mong đợi.

3.2 Công cụ phân tích mức độ bao phủ

Các công cụ phân tích mức độ bao phủ phần mềm rất quan trọng trong việc đánh giá hiệu quả của các ca kiểm thử. Những công cụ này giúp xác định các phần của mã chưa được kiểm tra và cung cấp thông tin chi tiết về mức độ bao phủ. Việc sử dụng các công cụ này không chỉ giúp tiết kiệm thời gian mà còn nâng cao chất lượng kiểm thử. Các công cụ phổ biến bao gồm JaCoCo, Cobertura và Emma, mỗi công cụ có những tính năng riêng biệt hỗ trợ cho việc kiểm thử bao phủ.

IV. Máy trạng thái và kiểm thử bao phủ máy trạng thái

Máy trạng thái là một mô hình quan trọng trong phát triển phần mềm, đặc biệt là trong các ứng dụng phức tạp. Kiểm thử bao phủ máy trạng thái tập trung vào việc kiểm tra các trạng thái và chuyển trạng thái của hệ thống. Việc xây dựng các ca kiểm thử cho máy trạng thái giúp đảm bảo rằng tất cả các trạng thái đều được kiểm tra và các chuyển trạng thái hoạt động đúng. Kỹ thuật kiểm thử này không chỉ giúp phát hiện lỗi mà còn đảm bảo rằng phần mềm hoạt động mượt mà trong các tình huống khác nhau.

4.1 Khái niệm máy trạng thái

Máy trạng thái là một mô hình trừu tượng mô tả các trạng thái của một hệ thống và các chuyển trạng thái giữa chúng. Mỗi trạng thái đại diện cho một điều kiện cụ thể của hệ thống, và các chuyển trạng thái cho thấy sự thay đổi từ trạng thái này sang trạng thái khác. Việc hiểu rõ về máy trạng thái là rất quan trọng trong việc thiết kế và kiểm thử phần mềm, đặc biệt là trong các ứng dụng phức tạp.

4.2 Kiểm thử bao phủ máy trạng thái

Kiểm thử bao phủ máy trạng thái là quá trình kiểm tra tất cả các trạng thái và chuyển trạng thái của hệ thống. Mục tiêu là đảm bảo rằng mọi trạng thái đều được kiểm tra và các chuyển trạng thái hoạt động đúng. Việc xây dựng các ca kiểm thử cho máy trạng thái giúp phát hiện lỗi và đảm bảo rằng phần mềm hoạt động đúng trong các tình huống khác nhau. Kỹ thuật này rất hữu ích trong việc phát triển các ứng dụng phức tạp, nơi mà các trạng thái và chuyển trạng thái có thể ảnh hưởng lớn đến hiệu suất và độ tin cậy của hệ thống.

Nội dung chính

Tổng quan nghiên cứu

Trong bối cảnh phát triển nhanh chóng của Công nghệ thông tin (CNTT) và Công nghệ phần mềm, việc đảm bảo chất lượng phần mềm ngày càng trở nên cấp thiết. Theo ước tính, chi phí kiểm thử phần mềm chiếm khoảng 40% tổng chi phí phát triển sản phẩm phần mềm lần đầu, trong đó việc phát hiện và sửa lỗi càng sớm càng giảm thiểu thiệt hại tài chính. Tuy nhiên, do độ phức tạp ngày càng tăng và giới hạn về thời gian, nguồn lực, việc kiểm thử phần mềm không thể đảm bảo phát hiện hết lỗi tiềm ẩn. Vấn đề đặt ra là làm thế nào để đánh giá hiệu quả kiểm thử và quyết định thời điểm dừng kiểm thử một cách hợp lý.

Luận văn tập trung nghiên cứu kiểm thử bao phủ phần mềm, đặc biệt trong phần mềm hướng đối tượng và ứng dụng máy trạng thái hữu hạn. Mục tiêu chính là phát triển các công cụ và phương pháp đánh giá độ bao phủ kiểm thử nhằm hỗ trợ quá trình kiểm thử hiệu quả hơn, giảm thiểu chi phí và nâng cao chất lượng phần mềm. Phạm vi nghiên cứu bao gồm lý thuyết kiểm thử phần mềm, kiểm thử hướng đối tượng, các phương pháp đo bao phủ truyền thống và mở rộng, cùng với thử nghiệm kiểm thử bao phủ trên mô hình máy trạng thái hữu hạn cho bài toán cầu thang máy.

Nghiên cứu có ý nghĩa thực tiễn lớn trong việc hoàn thiện các phương pháp kiểm thử, cung cấp công cụ đánh giá độ bao phủ kiểm thử, từ đó giúp các nhà phát triển và kiểm thử phần mềm đưa ra quyết định chính xác về việc tiếp tục hay dừng kiểm thử, đảm bảo chất lượng sản phẩm cuối cùng.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Luận văn dựa trên các lý thuyết và mô hình sau:

• Kiểm thử phần mềm truyền thống và hướng đối tượng: Bao gồm các mức kiểm thử (đơn vị, tích hợp, hệ thống, chấp nhận), các phương pháp kiểm thử hộp trắng, hộp đen, và hộp xám. Đặc biệt nhấn mạnh kiểm thử phần mềm hướng đối tượng với các đặc tính đóng gói, kế thừa, đa hình.

• Kiểm thử bao phủ phần mềm: Các độ đo bao phủ truyền thống như bao phủ câu lệnh, bao phủ nhánh, bao phủ điều kiện, bao phủ đường đi. Mở rộng sang bao phủ phạm vi kế thừa, bao phủ dựa trên trạng thái nhằm phù hợp với đặc tính phần mềm hướng đối tượng.

• Mô hình máy trạng thái hữu hạn (FSM): Được sử dụng để mô tả các hệ thống có trạng thái khác nhau trong quá trình vận hành, như cầu thang máy, bộ khóa an toàn. Máy trạng thái gồm tập trạng thái, tập đầu vào, hàm chuyển trạng thái, trạng thái bắt đầu và trạng thái kết thúc.

Các khái niệm chính bao gồm: kiểm thử hộp trắng, kiểm thử hộp đen, kiểm thử tích hợp hướng đối tượng (OOIT), bao phủ câu lệnh, bao phủ nhánh, bao phủ phạm vi kế thừa, máy trạng thái hữu hạn.

Phương pháp nghiên cứu

Nghiên cứu sử dụng phương pháp kết hợp lý thuyết và thực nghiệm:

• Nguồn dữ liệu: Tổng hợp từ tài liệu chuyên ngành, các công trình nghiên cứu về kiểm thử phần mềm, kiểm thử hướng đối tượng, kiểm thử bao phủ và máy trạng thái hữu hạn. Dữ liệu thực nghiệm được thu thập từ chương trình thử nghiệm kiểm thử bao phủ trên mô hình máy trạng thái hữu hạn cho bài toán cầu thang máy.

• Phương pháp phân tích: Phân tích các phương pháp kiểm thử truyền thống và hướng đối tượng, đánh giá các độ đo bao phủ phần mềm, xây dựng mô hình kiểm thử dựa trên máy trạng thái hữu hạn. Sử dụng các công cụ phân tích bao phủ như GCOV, EclEmma, Cobertura để đo lường mức độ bao phủ.

• Timeline nghiên cứu: Nghiên cứu được thực hiện trong năm 2010 tại Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội, với các giai đoạn: tổng quan lý thuyết, xây dựng mô hình kiểm thử, phát triển chương trình thử nghiệm, thu thập và phân tích kết quả, đề xuất giải pháp.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

1. Độ bao phủ kiểm thử truyền thống chưa đủ cho phần mềm hướng đối tượng: Các độ đo bao phủ câu lệnh và nhánh truyền thống không thể đánh giá đầy đủ các đặc tính như đa hình và đóng gói. Ví dụ, bao phủ câu lệnh có thể đạt 100% nhưng vẫn tồn tại lỗi do các nhánh điều kiện phức tạp chưa được kiểm thử.

2. Bao phủ phạm vi kế thừa và dựa trên trạng thái là cần thiết: Việc mở rộng độ đo bao phủ truyền thống sang bao phủ phạm vi kế thừa giúp đánh giá hiệu quả kiểm thử các phương thức kế thừa trong lớp con. Bao phủ dựa trên trạng thái giúp kiểm thử các hành vi phụ thuộc trạng thái của đối tượng, như trong mô hình máy trạng thái hữu hạn.

3. Ứng dụng máy trạng thái hữu hạn trong kiểm thử bao phủ hiệu quả: Thử nghiệm trên bài toán cầu thang máy cho thấy việc sử dụng máy trạng thái hữu hạn giúp xác định đầy đủ các trạng thái và chuyển trạng thái cần kiểm thử, từ đó tạo ra các ca kiểm thử tự động và vét cạn. Ví dụ, sơ đồ chuyển trạng thái cho nút thang máy gồm 4 tầng được mô hình hóa chi tiết, đảm bảo bao phủ toàn bộ trạng thái và chuyển trạng thái.

4. Công cụ phân tích bao phủ hỗ trợ đắc lực cho kiểm thử: Các công cụ như EclEmma và Cobertura giúp tự động hóa việc đo lường độ bao phủ, cung cấp báo cáo chi tiết về các phần mã chưa được kiểm thử, từ đó giúp tối ưu hóa bộ ca kiểm thử.

Thảo luận kết quả

Nguyên nhân chính khiến các độ đo truyền thống không đủ là do đặc tính phức tạp của phần mềm hướng đối tượng, trong đó các phương thức kế thừa và hành vi phụ thuộc trạng thái không thể được đánh giá chỉ qua câu lệnh hay nhánh. Việc áp dụng bao phủ phạm vi kế thừa và dựa trên trạng thái giúp khắc phục hạn chế này, đồng thời phù hợp với mô hình phát triển phần mềm hướng đối tượng.

So sánh với các nghiên cứu trước đây, kết quả nghiên cứu này khẳng định tính hiệu quả của mô hình máy trạng thái hữu hạn trong kiểm thử bao phủ, nhất là với các hệ thống có trạng thái phức tạp như cầu thang máy, bộ khóa an toàn. Việc sử dụng các công cụ phân tích bao phủ cũng được đánh giá cao trong việc giảm thiểu công sức và tăng độ chính xác của kiểm thử.

Dữ liệu có thể được trình bày qua biểu đồ bao phủ trạng thái và chuyển trạng thái, bảng báo cáo tỷ lệ phần trăm bao phủ câu lệnh, nhánh và phạm vi kế thừa, giúp trực quan hóa hiệu quả kiểm thử.

Đề xuất và khuyến nghị

1. Áp dụng bao phủ phạm vi kế thừa và dựa trên trạng thái trong kiểm thử phần mềm hướng đối tượng: Các nhà phát triển và kiểm thử nên tích hợp các độ đo này vào quy trình kiểm thử để đảm bảo phát hiện lỗi đa hình và trạng thái phụ thuộc. Thời gian áp dụng: ngay trong các dự án phát triển phần mềm hướng đối tượng.

2. Sử dụng mô hình máy trạng thái hữu hạn để thiết kế ca kiểm thử cho các hệ thống trạng thái phức tạp: Đặc biệt với các ứng dụng như cầu thang máy, thiết bị điều khiển, nên xây dựng mô hình FSM để tạo ca kiểm thử tự động, giảm thiểu lỗi bỏ sót. Chủ thể thực hiện: nhóm phát triển và kiểm thử phần mềm.

3. Triển khai công cụ phân tích bao phủ tự động như EclEmma, Cobertura trong quy trình kiểm thử: Giúp đo lường chính xác mức độ bao phủ, phát hiện các phần mã chưa được kiểm thử, từ đó tối ưu bộ ca kiểm thử. Thời gian: áp dụng trong giai đoạn kiểm thử tích hợp và hệ thống.

4. Đào tạo kỹ năng kiểm thử dựa trên mô hình và phân tích bao phủ cho đội ngũ kiểm thử viên: Nâng cao năng lực sử dụng các phương pháp kiểm thử hiện đại, hiểu rõ đặc tính phần mềm hướng đối tượng và máy trạng thái. Chủ thể: các tổ chức đào tạo, doanh nghiệp phát triển phần mềm.

Đối tượng nên tham khảo luận văn

1. Nhà phát triển phần mềm hướng đối tượng: Nắm bắt các phương pháp kiểm thử bao phủ phù hợp, áp dụng mô hình máy trạng thái để thiết kế ca kiểm thử hiệu quả, giảm thiểu lỗi trong sản phẩm.

2. Kiểm thử viên và quản lý kiểm thử: Hiểu rõ các độ đo bao phủ truyền thống và mở rộng, sử dụng công cụ phân tích bao phủ để đánh giá chất lượng kiểm thử, tối ưu nguồn lực kiểm thử.

3. Giảng viên và sinh viên ngành Công nghệ thông tin, Công nghệ phần mềm: Là tài liệu tham khảo chuyên sâu về kiểm thử phần mềm hướng đối tượng, kiểm thử bao phủ và ứng dụng máy trạng thái hữu hạn trong kiểm thử.

4. Doanh nghiệp phát triển phần mềm và tổ chức đảm bảo chất lượng phần mềm (SQA): Áp dụng các giải pháp kiểm thử bao phủ tiên tiến để nâng cao chất lượng sản phẩm, giảm thiểu rủi ro do lỗi phần mềm gây ra.

Câu hỏi thường gặp

1. Kiểm thử bao phủ phần mềm là gì và tại sao quan trọng?
   Kiểm thử bao phủ phần mềm đo lường tỷ lệ phần trăm mã nguồn được thực thi trong quá trình kiểm thử, giúp đánh giá mức độ hoàn thiện của bộ ca kiểm thử. Nó quan trọng vì giúp phát hiện các phần mã chưa được kiểm thử, từ đó giảm thiểu lỗi còn sót.

2. Phân biệt kiểm thử hộp trắng và hộp đen như thế nào?
   Kiểm thử hộp trắng dựa trên cấu trúc bên trong mã nguồn, kiểm tra câu lệnh, nhánh, luồng điều khiển; trong khi kiểm thử hộp đen tập trung vào chức năng, đầu vào và đầu ra mà không quan tâm đến cấu trúc bên trong.

3. Tại sao kiểm thử phần mềm hướng đối tượng khó hơn phần mềm truyền thống?
   Do đặc tính đóng gói, kế thừa, đa hình và tương tác phức tạp giữa các đối tượng, không có kiến trúc phân cấp rõ ràng, khiến việc xác định phạm vi và thứ tự kiểm thử tích hợp trở nên phức tạp hơn.

4. Máy trạng thái hữu hạn giúp gì trong kiểm thử phần mềm?
   Máy trạng thái hữu hạn mô hình hóa các trạng thái và chuyển trạng thái của hệ thống, giúp thiết kế ca kiểm thử bao phủ toàn bộ các trạng thái và chuyển đổi, đặc biệt hiệu quả với các hệ thống có trạng thái phức tạp như cầu thang máy.

5. Các công cụ phân tích bao phủ phổ biến hiện nay là gì?
   Các công cụ như GCOV, EclEmma, Cobertura được sử dụng rộng rãi để tự động đo lường độ bao phủ câu lệnh, nhánh và cung cấp báo cáo chi tiết, hỗ trợ tối ưu hóa bộ ca kiểm thử.

Kết luận

• Kiểm thử bao phủ phần mềm là yếu tố then chốt trong đảm bảo chất lượng phần mềm, đặc biệt với phần mềm hướng đối tượng có tính phức tạp cao.
• Mở rộng các độ đo bao phủ truyền thống sang bao phủ phạm vi kế thừa và dựa trên trạng thái giúp đánh giá hiệu quả kiểm thử đa hình và trạng thái phụ thuộc.
• Mô hình máy trạng thái hữu hạn là công cụ hữu hiệu để thiết kế ca kiểm thử tự động, đảm bảo vét cạn các trạng thái và chuyển trạng thái trong hệ thống.
• Công cụ phân tích bao phủ tự động như EclEmma, Cobertura hỗ trợ đắc lực trong việc đo lường và tối ưu bộ ca kiểm thử.
• Các bước tiếp theo bao gồm triển khai áp dụng các phương pháp và công cụ này trong thực tế phát triển phần mềm, đồng thời đào tạo nâng cao năng lực kiểm thử viên.

Hành động ngay hôm nay: Các nhà phát triển và kiểm thử phần mềm nên tích hợp kiểm thử bao phủ mở rộng và mô hình máy trạng thái vào quy trình làm việc để nâng cao chất lượng sản phẩm và giảm thiểu rủi ro do lỗi phần mềm.

Trích đoạn nội dung tài liệu

Chương I: Tổng quan về kiểm thử phần mềm: Chương này cho một cái nhìn tổng quan về kiểm thử phần mềm: các khái niệm cơ bản về kiểm thử phần mềm, các chiến lược và quy tắc trong kiểm thử, các phương pháp kiểm thử phần mềm tiêu biểu. Chương II: Kiểm thử phần mềm hướng đối tượng: Chương này trình bày khái quát về lập trình hướng đối tượng, khái niệm kiểm thử hướng đối tượng và tiến trình kiểm thử hướng đối tượng. Chương III: Kiểm thử bao phủ phần mềm: Trong chương này, đi tìm trình bày về kiểm thử bao phủ phần mềm, các phương pháp bao phủ phần mềm và các công cụ phân tích mức độ bao phủ phần mềm. Chương IV: Máy trạng thái và kiểm thử bao phủ máy trạng thái: Trong chương này trình bày khái lược về máy trạng thái và kiểm thử bao phủ máy trạng thái, xây dựng một chương trình thử nghiệm tiến hành kiểm thử phủ các trạng thái và các chuyển trạng thái cho bài toán cầu thang máy.

Cuối cùng là kết luận và tài liệu tham khảo. z 3 CHƢƠNG 1: TỔNG QUAN VỀ KIỂM THỬ PHẦN MỀM Như chúng ta biết, mục tiêu của đảm bào chất lượng phần mềm (SQA) là sản xuất ra các phần mềm có chất lượng cao, đáp ứng được nhu cầu từ phía khách hàng, nhà sản xuất, và cả những người phát triển. Một trong các hoạt động quan trọng của SQA là kiểm thử phần mềm (software testing). Kiểm thử phần mềm là yếu tố quyết định của SQA và khâu điển hình của rà soát đặc tả thiết kế và lập mã.

Việc phát triển hệ thống phần mềm bao gồm hàng loạt các hoạt động sản xuất, mà ở đó cơ hội để con người đưa vào phần mềm những sai lầm là rất lớn. Lỗi có thế bắt đầu xuất hiện từ lúc khởi đầu xác định mục tiêu cho phần mềm: có thể được xác định sai hay không hoàn chỉnh, cũng như các giai đoạn thiết kế và phát triển về sau. Phần mềm được kiểm thử sẽ hạn chế chi phí chi trả cho các thất bại do lỗi gây ra và đồng thời có kế hoạch nâng cao chất lượng của phần mềm cho suốt quá trình phát triển. Khái niệm về lỗi phần mềm Có rất nhiều định nghĩa khác nhau, tựu chung, nói một cách tổng quát là: “ Lỗi phần mềm là sự không phù hợp giữa chương trình và đặc tả của nó” [Cem&90].

Một cách định nghĩa khác về lỗi phần mềm đó là: − Phần mềm không làm những gì đã được đặc tả cho nó. − Phần mềm làm những thứ mà đặc tả chỉ ra không nên làm − Phần mềm làm những thứ mà đặc tả sản phẩm không đề cập đến − Phần mềm khó hiểu, khó sử dụng, chậm, hoặc là người dùng cuối cùng đánh giá là không đúng điều mong muốn. “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ì ngay cả những lập trình viên xuất sắc nhất cũng không có thể viết được ngay những đoạn mã không có lỗi.

Tính trung bình, một lập trình viên loại tốt thì cũng mắ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 thử để 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” [Beiz90]. Nguyên nhân có lỗi phần mềm Khác với cảm nhận thông thường, lỗi xuất hiện nhiều nhất không phải do lập trình. Nhiều nghiên cứu đã được thực hiện trong các dựa án nhỏ đến các dự án lớn và kết quả luôn giống nhau.

Số lỗi do đặc tả gây ra là nhiều nhất. Trong nhiều trường hợp, đặc tả không được viết ra. Các nguyên nhân khác có thể do đặc tả không đủ cẩn thận, dễ bị thay đổi, hoặc do chưa phối hợp tốt trong toàn nhóm phát triển. Sự thay đổi của khách hàng cũng là nguyên nhân dễ gây lỗi.

Khách hàng thay đổi yêu cầu không cần quan tâm đến những tác động sau khi thay đổi yêu cầu: phải thiết kế lại, lập lại kế hoạch, làm lại những việc đã hoàn thành. Nguồn lỗi gây ra lớn thứ hai là do thiết kế. Đó là nền tảng mà lập trình viên dựa vào để triển khai mã nguồn. Lỗi do lập trình gây ra là nguyên nhân thứ ba, và cũng là điều dễ hiểu, vì ai cũng có thể mắc lỗi.

Thời kỳ đầu, phát triển phần mềm có nghĩa là lập trình, đó là công việc rất nặng nhọc, lỗi do lập trình gây ra là chủ yếu. Ngày nay công việc lập trình chỉ là một phần việc của quá trình phát triển phần mềm. Mặc dù dược sự hỗ trợ của nhiều công cụ lập trình tiên tiến, việc lập trình đã trở nên nhẹ nhàng hơn, nhưng độ phức tạp của phần mềm ngày nay lớn. Do đó, lỗi do lập trình vẫn còn, tuy có ít hơn so với đặc tả hay thiết kế, nhưng nguyên nhân để lập trình tạo ra lỗi thì nhiều hơn.

Chi phí cho việc sửa lỗi Theo thống kê của IBM, GTE, TRW -1976 thì giá của mỗi sai lầm là:  Trong giai đoạn phân tích: 200 $  Trong giai đoạn thiết kế: 500 $  Trong khi kiểm tra chương trình: 1 200 $  Trong giai đoạn kiểm thử và bảo trì: 5 000 $  Khi đã đưa vào hoạt động: 15 000 $ Có thể thấy rằng, kiểm thử phần mềm là hoạt động có chi phí đắt thứ hai, ước tính chiếm khoảng 40% tổng chi phí của toàn bộ quá trình phát triển một sản phẩm phần mềm lần đầu. Kiểm thử và sửa lỗi được thực hiện tại bất kỳ giai z 5 đoạn nào của vòng đời phát triển. Tuy nhiên, chi phí cho việc tìm và sửa lỗi tăng một cách đáng kể theo quá trình phát triển. Khái niệm về kiểm thử phần mềm Kiểm thử phần mềm thường đồng nghĩa với việc tìm ra lỗi chưa được phát hiện.

Kiểm thử phần mềm là quá trình thực hiện một hệ thống phần mềm để xác định xem nó có đúng với đặc tả hay yêu cầu của người dùng không trong một môi trường mong đợi. 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 một cách sớm nhất có thể và đảm bảo rằng lỗi đã được sửa; nhưng bản thân kiểm thử không làm công việc chuẩn đoán nguyên nhân gây ra lỗi và sửa lỗi. Để kiểm thử cần lập kế hoạch cho mỗi lần (một ca) kiểm thử Một ca kiểm thử thường bao gồm:  tên của mô đun kiểm thử  dữ liệu vào  các bước thực hiện  dữ liệu ra mong muốn (đúng)  dữ liệu ra thực tế (khi đã tiến hành kiểm thử ) Các ca kiểm thử nên được thiết kế ngay khi tạo ra các tài liệu phân tích và thiết kế, không phải chờ đến khi đã viết xong mã nguồn. Một ca kiểm thử được gọi là thành công nếu nó phát hiện ra một khiếm khuyết của phần mềm.

Tuy nhiên, các ca kiểm thử chỉ chứng minh được sự tồn tại của lỗi trong hệ thống chứ không chứng minh được hệ thống không có lỗi. Theo Glen Mayers [Myer79], kiểm thử phần mềm là quá trình vận hành chương trình để tìm ra lỗi. Một ca kiểm thử tốt là ca kiểm thử có xác suất cao tìm ra một lỗi chưa được phát hiện. Một ca kiểm thử thắng lợi là ca kiểm thử làm lộ ra được ít nhất một lỗi còn chưa được phát hiện.

Bài toán kiểm thử luôn được đặt ra là: tổ chức việc kiểm thử như thế nào để tìm ra lỗi nhiều nhất có thể và với chi phí bỏ ra là ít nhất. Giải quyết bài toán này quả là không đơn giản, do bản chất phức tạp của các hệ thống phần mềm. Trước hết việc kiểm thử được tổ chức theo nhiều mức z 6 tăng dần theo quy mô được phát triển của phần mềm và tương ứng với tiến trình phát triển. Với chiến lược này, người ta hy vọng rằng những mức sau là bổ sung cho mức trước trong việc tìm lỗi còn sót và những loại lỗi khác mà mức trước chưa có.

Trên mỗi mức, cần áp dụng các chiến lược, phương pháp và kỹ thuật khác nhau để có thể thực hiện số lần (ca) kiểm thử ít nhất mà vẫn bao quát được các phạm vi của phần mềm mà kiểm thử đặt ra. Những nôi dung này đã được phản ánh đầy đủ trong tài liệu[Vy&Ha08]. Tuy nhiên, do vẫn còn tồn lại các lỗi trong nhiều phần mềm đã kiểm thử; thêm nữa, cùng với sự tăng lên về quy mô và độ phức tạp của phần mềm, phần mềm còn được phát triển theo những cách thức mới, vì thế các phương pháp và công cụ kiểm thử tiếp tục được phát triển để nâng cao chất lượng phần mềm và giảm thiểu công sức bỏ ra cho kiểm thử. Các mức của kiểm thử phần mềm Thực tế, công việc kiểm thử phần mềm có nhiều mức khác nhau và có mối quan hệ chặt chẽ với các giai đoạn phát triển trong của một dự án phát triển phần mềm.1 là 4 mức độ cơ bản của kiểm thử phần mềm.

Bốn mức kiểm thử đó là:  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 xác đinh test chấp kế hoạch nhận yêu cầu kiểm thử chấp đặc tả hệ nhận test hệ thống kế thống hoạch kiểm thử thiết kế hệ thống test tích kiến trúc kế hoạch hợp kiểm thử thiết kế tích hợp test đơn chi tiết vị lập rà soát, phân trình tích mã Hình 1. Mô hình chữ V của quá trình kiểm thử z 7 Mô hình chữ V cho thấy, ngay trong quá trình phát triển, các yêu cầu và đặc tả kiểm thử đã được xây dựng làm cơ sở cho việc lập kế hoạch chi tiết để thực hiện các bước kiểm thử sau này. Kiểm thử mức đơn vị Để hiểu rõ về kiểm thử đơn vị, trước tiên ta cần làm rõ: thế nào là một đơn vị phần mềm? Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Theo định nghĩa này, các hàm (Function), các thủ tục (Procedure), các lớp (Class), hoặc các phương thức (Method) đều có thể được xem là đơn vị.

Vì đơn vị được chọn để kiểm thử thường có kích thước nhỏ và chức năng hoạt động đơn giản, nên dễ tổ chức, kiểm tra, ghi nhận và phân tích kết quả nhận được. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục lỗi đối với một đơn vị là tương đối đối dễ dàng. Một nguyên lý đúc kết từ thực tiễn là: thời gian tốn cho kiểm thử đơn vị sẽ được bù đắp bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó. Kiểm thử đơn vị thường do lập trình viên thực hiện.