BÀI THUYẾT TRÌNH NHẬP MÔN CÔNG NGHỆ PHẦN MỀM Chủ đề Testing Software

2 .QUI TRÌNH PHÁT TRIỂN PHẦN MỀM VÀ VỊ TRÍ CỦA TESTING  Trong các qui trình phát triển phần mềm truyền thống, testing được thực hiện song song cùng với mỗi giai đoạn phát triển, tạo nê

SINH VIÊN:

1. Thới Ngọc Quốc Duẫn 09520482

2. Sầm Viết Anh Khoa 09520137

3. Lộ Ngọc Thạch 09520657

BÀI THUYẾT TRÌNH NHẬP MÔN CÔNG NGHỆ PHẦN MỀM

Chủ đề: Testing Software

1 TEST PHẦN MỀM

1.1 Định nghĩa

Test phần mềm là quá trình vận hành thử

nghiệm một chương trình, một hệ thống phần mềm với mục đích tìm ra lỗi

1.2 Vai trò

- Testing để tìm ra lỗi, ghi nhận các thông tin

về lỗi, nhưng không sửa lỗi

- Testing giúp kiểm định phần mềm, đảm bảo rằng phần mềm “đủ tốt” với độ rủi ro “thấp nhất” có thể

 1.3 Test thế nào cho đủ

Test thế nào cho

đủ???

1.3.1 Vấn đề

 Càng test càng tìm ra thêm lỗi, nhất là với các

hệ thống lớn

 Vấn đề không phải là với việc test như vậy tất

cả các lỗi đã được tìm ra chưa, mà ở chỗ phần mềm như vậy có đủ “tốt” để ngừng test

không

 Đây là một quyết định mang tính “kinh tế”

 Và là một trong những vấn đề khó nhất của

testing

1.3.2 Tìm câu trả lời

 Khả năng tìm được thêm lỗi nếu tiếp tục test?

 Chi phí cận biên về thời gian và nhân lực nếu tiếp tục test?

 Khả năng NSD gặp phải các lỗi còn lại?

 Ảnh hưởng, hậu quả những lỗi đó với NSD?

 Điều quan trọng là cần biết ưu tiên test, biết dành thời gian và nguồn lực cho

2 QUI TRÌNH PHÁT TRIỂN PHẦN MỀM VÀ

VỊ TRÍ CỦA TESTING

 Trong các qui trình phát triển phần mềm truyền thống, testing được thực hiện

song song cùng với mỗi giai đoạn phát

triển, tạo nên mô hình chữ V Mô hình

này phản ánh sự cần thiết việc lập kế

hoạch và chuẩn bị sớm cho test

 Trong mô hình này, mỗi giai đoạn phát

triển được liên kết tương ứng với một

giai đoạn test

2.1 Mô hình chữ V đối với qui trình test

 Như các giai đoạn phát triển cụ thể,

từng giai đoạn test cũng cần phải được lập kế hoạch và chuẩn bị (thiết kế sơ

bộ)

 Ở một số công ty, Tester không đảm

nhận Unit test

 Nhiều dự án không có tài liệu hỗ trợ

(Requirements Spec., Project Plan…) Qui trình test phải biến đổi linh hoạt theo

2.2 Các giai đoạn test (Testing Phases)

 Unit là phần nhỏ nhất của mã nguồn (source

code) có thể được biên dịch, liên kết và load

(compiled, linked, và loaded)

 Unit testing được thực hiện bởi Lập trình viên (Developers)

 Sử dụng phương pháp test hộp trắng (White box testing)

2.2.1 Unit Testing

2.2.2 Intergration Testing – Test tích hợp

 Software Integration là quá trình hợp nhất

các unit đơn lẻ vào thành một hệ thống (hoặc một tiểu hệ thống)

 Integration testing là test các liên kết giữa

các unit thành phần

 Integration testing đòi hỏi các module phải được unit test trước

2.2.3 System Testing – Test hệ thống

 Thực hiện khi integration đã được hoàn tất

 Sử dụng phương pháp test hộp đen (Black box testing)

 Test dựa trên yêu cầu hệ thống

(Requirements)

 System testing được thực hiện bởi Nhóm test

2.2.4 User Acceptance Testing

 Nên được gọi là Acceptance

Demonstration thay cho Acceptance Test.

 Để chứng minh phần mềm đã sẵn sàng

chuyển giao cho khách hàng.

 Khi tất cả các giai đoạn test khác đã được hoàn tất.

 Dựa trên cơ sở là toàn bộ hay một phần của tài liệu yêu cầu hệ thống (system

requirements)

 Các thủ tục test/demo phải được khách

hàng chấp nhận trước khi thực hiện để

nghiệm thu.

2.2.5 Installation Testing

 Test các bước thực hiện cài đặt dựa trên Tài liệu hướng dẫn cài đặt, chứng minh Tài liệu hướng dẫn cài đặt đã qui chuẩn để chuyển

giao khách hàng

 Installation testing được thực hiện bởi Nhóm test

3 CÁC PHƯƠNG PHÁP KỸ THUẬT TEST

 Phân các test cases theo nhóm các TEST CASE cùng loại, gọi là class hay lớp các TEST CASE

 Trong mỗi class chọn test chỉ một vài test case.

 Nên test nhiều class thay cho test nhiều test cases trong cùng một class.

3.1 Các kỹ thuật test

3.1.1 Equivalence class partitioning –

Phân lớp tương đương

3.1.2 Control flow testing – Luồng điều

khiển

 Phân loại các TEST CASE theo sơ đồ mô hình luồng xử lý (Đó là sơ đồ mô hình hoá hành vi của hệ thống, chứ không phải là sơ đồ mô tả các câu lệnh trong code)

 Mỗi rẽ nhánh trong luồng xử ký là 1 TEST

CASE

 Đây là 1 kỹ thuật test căn bản, áp dụng hiệu quả được cho hầu hết các hệ thống, áp dụng được cho mọi giai đoạn test

3.1.3 Data flow testing – Luồng dữ liệu

 Áp dụng cho loại hệ thống đòi hỏi và xử lý

nhiều dữ liệu (data-intensive)

 Phân loại các TEST CASE theo sơ đồ mô hình luồng dữ liệu

3.1.4 Transaction testing – Giao dịch

 Áp dụng cho các hệ thống xử lý giao dịch (các giao dịch trong ngân hàng, đặt vé máy bay,

đặt phòng khách sạn…)

 Phân loại TEST CASE theo loại các giao dịch, chú trọng việc xác định điểm khởi đầu, điểm kết thúc, và hàng đợi các điểm giao dịch cần

xử lý

xử lý khác nhau so với các giá trị biến khác.

3.1.7 Syntax testing – Cú pháp

 Áp dụng test các câu lệnh, các trường toán tử

có định dạng xác định

 Phân tích, nắm rõ các cú pháp để thiết kế các TEST CASE, sử dụng kỹ thuật phân lớp tương đương, và theo loại đúng hoặc sai cú pháp

3.1.8 State machine testing – Trạng thái

 Áp dụng cho loại hệ thống có đặc trưng

chuyển đổi trạng thái, các “menu driven

application” – Chương trình điều khiển bằng trình đơn, các hệ thống thiết kế bằng phương pháp hướng đối tượng

 Các TEST CASE được phân loại từ việc lập

các biểu đồ chuyển đổi trạng thái của hệ

thống, theo loại chuyển đổi trạng thái hợp lệ

và không hợp lệ

3.1.9 Load and stress testing

 Kết nối mạng bị ngắt khi đang vận hành

 Kết nối CSDL bị ngắt khi đang vận hà

3.2 Ưu tiên test

3.2.1 Danh sách các ưu tiên test -

“where to focus testing”

 Những lỗi dễ xảy ra nhất

 Những lỗi (người dùng) dễ nhìn thấy nhất

 Những loại lỗi khó fix nhất

 Những loại lỗi mà tester biết rõ nhất

 Những loại lối mà tester biết lờ mờ nhất

 Positive test trước, negative test sau (test các trường hợp hợp lệ trước, các trường hợp

không hợp lệ sau)

3.2.2 Ưu tiên sắp xếp test theo quality