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

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?
1.3.3 Kết luận
-
Không thể có câu trả lời chính xác mang tính công
thức cho vấn đề trên.
-
Vấn đề này có thể thỏa hiệp, dựa vào kinh nghiệm cụ
thể trong từng dự án, từng phần mềm vẫn là điều
then chốt.
-
Đ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ý.
3.1.5 Domain testing – vùng
-
Áp dụng cho loại hệ thống xử lý nhiều vùng giá trị của
biến.
-

Phân loại các TEST CASE theo vùng giá trị của biến,
đặc biệt chú trọng các TEST CASE quanh biên ranh
giới, nơi hệ thống có những xử lý khác nhau so với
các giá trị biến khác.
3.1.6 Loop testing – Vòng lặp
-
Áp dụng trong whitebox testing: quan tâm đến vòng
lặp trong code.
-
Áp dụng trong backbox testing: quan tâm đến vòng
lặp trong hành vi của hệ thống.
-
Phân loại các TEST CASE theo số giá trị đặc biệt lần
rẽ nhánh các vòng lặp.
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
-
Load testing:
Test hệ thống ở trạng thái chịu tải lớn (thực hiện
nhiều xử lý).
-
Ví dụ:

Có nhiều client cùng lúc truy cập

Có nhiều giao dịch cùng một lúc

Xử lý file rất lớn

Xử lý cùng lúc nhiều file
3.1.10 Stress testing
-
Stress testing: test hệ thống ở trạng thái vận hành
trong điều kiện bất thường.
-
Ví dụ:

Thiếu bộ nhớ

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

-
Những vùng quan trọng nhất của phần mềm
-
Những vùng phần mềm hay được dùng nhất
-
Những vùng có đặc trưng riêng, khác biệt hẳn với các
vùng khác của phần mềm
-
Những vùng phần mềm dễ bị ảnh hưởng nhất của các
thay đổi vừa có (khi regression 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)