Testing là gì

Là quá trình thực hiện một chương trình (hay một

phần của một chương trình) để tìm ra lỗi
Là 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ác
hàng đã thấy được hệ thống mới đã thoả mãn yêu
cầu đề ra chưa
Test phần mềm là vấn đề kỹ thuật thách thức
hơn cả việc xây dựng phần mềm
Tầm quan trọng của nó đối với
ngành phần mềm
 Một phần mềm được làm ra không ai có thể đảm bảo nó
không có lỗi
 Testing sẽ tìm và phát hiện lỗi (mang tính ứng dụng
hoặc thậm chí mang tính công nghệ) với mục đích cuối
cùng là bảo đảm sản phẩm đến tay người dùng phải là
tốt nhất, nhanh nhất, ổn định nhát
 Hoạch định chiến lược nghiên cứu và ứng dụng, đảm bảo
sp làm ra đạt tiêu chí và kỹ thuật đề ra
 Ghi nhận các ý kiến, đề xuất hoặc báo cáo hỏng hóc từ
người dùng
Các phương pháp testing
 Black box test
 White box test
Black-box Test – Khái niệm
 Black box test: hay còn gọi là test hộp đen
 Test dựa trên hoạt động của chức năng,
không đòi hỏi kiến thức về các mã phần mềm
hoặc cấu trúc
 Phương pháp này quan tâm tới việc thực hiện
các chức năng (hành vi), dữ liệu đầu vào và
kết quả đầu ra ra sao  fải chuẩn bị và sử
dụng các khả năng có thể xảy ra của dữ liệu
Input
Black-box Test – Phương pháp
 Để thực hiện phương pháp này cần dựa
trên:
 Yêu cầu của phần mềm
 Các trạng thái
 Các trường hợp sử dụng (use case)
 Kiểm tra các giá trị biên
 Phân lớp tương đương
 Test cú pháp
 Test luồng dữ liệu (dữ liệu được lấy từ đặc tả
yêu cầu)
White box Test – Khái niệm
 Quan tâm tới cấu trúc và logic bên trong của
đoạn mã.  cần có kiến thức về cấu trúc
phần mềm
 Được định nghĩa bởi:
 Programming style
 Control method
 Language
 Database design
 Coding details
White box Test – Kỹ thuật
 Test cấu trúc
 Test nhánh
 Luồng dữ liệu test
 Test điều kiện nhánh
 Test điều kiện nhánh tích hợp
 Test các điều kiện thay đổi
Các giai đoạn test
Software Test Planning Phase
Development Phases Install
Software V&V Test Execution Phase
Project Plan Plan

Acceptance Acceptance
Requirements Demonstration Demonstration
Spec Plan

System Test
Plan System
Test

Architectural Integration
Design Spec Test Plan Integration
Test

Detailed Unit Test

Design Spec Plan Unit
Test

Code
Các giai đoạn test
 Unit Test
 Intergration Test
 System Test
 Acceptance Test
Unit Test – Khái niệm
 Một Unit là thành phần nhỏ nhất của phần
mềm, như là: Function, Procedure, Class,
Method
 Là kỹ thuật kiểm nghiệm các hoạt động của
mọi chi tiết mã với một quy trình tách biệt với
QT PTPM giúp phát hiện sai sót kịp thời trước
khi đưa ra test
Unit Test – Đặc điểm
 Test ở mức thấp nhất
 Sử dụng phương pháp test hộp trắng
 Kiểm tra độc lập từng thành phần
 Thường được thực hiện bởi lập trình viên
 Có giá trị khi phát hiện các vấn đề tiềm ẩn
hoặc lỗi kỹ thuật
Intergration test – Khái niệm
 Là test kết hợp các thành phần của một ứng
dụng và kiểm tra như một ứng dụng đã hoàn
thành
 Mục đích
 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ỏ
và cuối cùng là nguyên hệ thống hoàn chỉnh
 Intergration test - Type
 Kiểm tra cấu trúc (structure): Tương tự White
Box Test, chú trọng đến hoạt động của các
thành phần cấu trúc nội tại của chương trình
 Kiểm tra chức năng (functional): Tương tự
Black Box Test, chỉ khảo sát chức năng của
chương trình theo yêu cầu kỹ thuật
 Kiểm tra hiệu năng (performance): Kiểm tra
vận hành của hệ thống
 Kiểm tra khả năng chịu tải (stress): Kiểm tra
giới hạn của hệ thống
Intergration test - Plan
 Cần được thực hiện tương đương với giai
đoạn thiết kế kiến trúc
 Thứ tự tích hợp được xác định theo thứ tự
xây dựng
 Các thành phần hoàn thành đúng thời hạn
 Phát triển các thành phần và test tích hợp được
thực hiện song song
Intergration - Guidelines
 Mỗi thành phần sẽ được tích hợp 1 lần
(tích hợp theo hướng tăng dần
Baseline 0: test thành phần
Baseline 1: 2 thành phần
Baseline 2: 3 thành phần)
 Tích hợp từng mục nhỏ của từng thành phần
tại một thời điểm
 Các thành phần chính hoặc thành phần có
khả năng nhiều lỗi
 Kết hợp các thành phần liên quan đơn giản
Intergration-Approaches
 Top-down
 Bottom-down
 Big-bang
Intergration-Approaches
 Top-Down
 Các module cấp trên được kiểm thử
trước a
Baselines:
 baseline 0: component a b c
 baseline 1: a+b
 baseline 2: a+b+c d e f g
 baseline 3: a+b+c+d
 Etc… h i j k l m

n o
Intergration-Approaches
 Ưu điểm Top-down
 Phát hiện sớm các lỗi thiết kế
 Có phiên bản hoạt động sớm
 Nhược điểm
 Khó có thể mô phỏng được các chức
năng của module cấp thấp phức tạp
 Không kiểm thử đầy đủ các chức năng
Intergration-Approaches
 Bottom-up
 a trước
Các module cấp thấp được kiểm tra
 Baselines: b c
 baseline 0: component
 baseline 1: n + i d e f g
 baseline 2: n + i + o
 baseline 3: n + i + oh + i j k l m
d
 Etc.
n o
Intergration-Approaches
 Ưu điểm Bottom-up
 Thuận tiện cho phát triển các mô đun
thứ cấp dùng lại được
 Nhược điểm
 Phát hiện chậm các lỗi thiết kế
 Chậm có phiên bản thực hiện được của
hệ thống
Intergration-Approaches
 Big-bang
 Tất cả các module được kết hợp trong 1
bước
 Là phương pháp tích hợp thông thường
 Là phương pháp ít hiệu quả nhất
 Hạn chế dùng Big-bang
• Rất khó tìm ra nguồn gốc của vấn đề
• Không biết nơi nào để xem xét
• Không ngoại trừ recommended cho các hệ
thống rất nhỏ
System test – Khái niệm
 Là kiểm tra thiết kế và toàn bộ hệ thống (sau
khi tích hợp) có thỏa mãn yêu cầu đặt ra hay
không
 Là Black box test
 Được thực hiện độc lập bởi một nhóm test
(test hệ thống)
System test – Khái niệm
 Về chức năng, thỏa mãn:
 Requirements-based testing
• Các yêu cầu là điều kiện đầu tiên cho việc test
• Phân tích rủi ro để xác định thành phần quan
trọng nhất
 Business process-based testing
• Người sử dụng mong đợi: cái gì được sử dụng
thường xuyên và quan trọng nhất cho việc kinh
doanh
• Thực hiện các giao dịch kinh doanh qtrọng
System test – Khái niệm
 Yêu cầu phi chức năng:
 Usability
 Security
 Storage
 Volume
 Configuration/installation
 Reliability/qualities
 Back-up/recovery
 Performance, load, stress
 Functional
Acceptance test
 Được thực hiện sau giai đoạn System test, do
khách hàng thực hiện (hoặc ủy quyền cho
một nhóm thứ 3 thực hiện)
 Mục đích: chứng minh phần mềm thỏa mãn
tất cả các yêu cầu của khách hàng
 Đối với những PM bán rộng rãi trên thị
trường, cần thực hiện: Alpha test và Beta
Test
Acceptance test
 Alpha test: người sử dụng kiểm tra phần
mềm ngay tại nơi PTPM, lập trình viên ghi
nhận lỗi hoặc phản hồi và lên kế hoạch sửa
chữa
 Beta test: PM được gửi tới cho người sử dụng
để kiểm tra ngay trong môi trường thực, lỗi,
hoặc phản hồi cũng sẽ gửi ngược lại cho lập
trình viên để sửa
Process Test

Test
Planning

Test
Specification

Test
Reporting
Đầu vào/ đầu ra cho testing
 Đầu vào
 Yêu cầu của khách hàng, các tiêu chuẩn
 Các yêu cầu thay đổi
 SRS
 Tài liệu thiết kế (ADD, DDD)
 Chương trình
 Đầu ra
 Tài liệu: test plan, test case và procedures
 List lỗi
 Báo cáo test
 Test Plan Khái niệm
 Mô tả các module cần kiểm tra, phương pháp
kiểm tra (black box hoặc white box)
 Xác định các yêu cầu dựa trên các yêu cầu
người dùng
 Xác định chiến lược test: test type, stage, tools
 Xác định nguồn lực và trách nhiệm, xác định hệ
thống (phần cứng, phần mềm)
 Xác định những yêu tố, module quan trọng
Test Plan-Hoạt động
 Phạm vi test: Trạng thái và loại test?
 Xác định yêu cầu cho test: Test sẽ làm gì?
 Xác định chiến lược test: Thực hiện như thế nào?
 Xác định nguồn lực và môi trường
 Lập lịch trình Test.
 Tổng hợp thông tin, lập kế hoạch Test
 Xem xét và thông qua kế hoạch Test.
 Tiêu chuẩn hoàn thành.
 Công cụ sẽ sử dụng để Test
 Đánh giá rủi ro và lập mức độ rủi ro cho các yêu cầu.
 Chuyển giao test.
Test Plan – Nội dung
1. Định nghĩa tài liệu 9. Phân chia công việc cần test
2. Giới thiệu 10. Các task vụ cần thực hiện test
3. Test các mục nhỏ 11. Môi trường cần thực hiện
4. Các đặc trưng cần test 12. Phân công người chịu trách
5. Đưa ra các phương pháp nhiệm cho các task vụ
6. Đưa ra các tiêu chuẩn đánh 13. Nhân công và việc đào tạo
giá một mục là pass hay fail 14. Lịch biểu
7. Lập kế hoạch cho các tiêu 15. Rủi ro và các sự việc xảy ra
chuẩn bị dừng lại và các yêu khách quan
cầu được bắt đầu lại 16. Phê duyệt và chuyển giao sản
phẩm.
Test Specification
 Test design
 Cải tiến phương pháp test
 Xác định các vấn đề (feature) cần phải cover khi
thực hiện test
 Xác định các test case
 Đặc tả rõ các tiêu chuẩn nào pass/ fail cho mỗi
vấn đề (feature) đưa ra
Test Specification
 Test case
 Tài liệu các giá trị input thực tế và kết quả mong đợi
cho mỗi test case được thực hiện.
 Định nghĩa các ràng buộc dựa trên các thủ tục test.
 Việc định nghĩa các test case là độc lập với việc thiết
kế test để có thể sử dụng lại một cách đễ dàng.
 Test procedure
 Định nghĩa tất cả các bước thực hiện test
• Chạy hệ thống
• Thực hiện các testcase
 Đưa ra các chỉ dẫn
Test Design-Nội dung
 Định nghĩa tài liệu test
 Các vấn đề cần được test
 Các phương pháp yêu cầu
 Định nghĩa các trường hợp test
 Tiêu chuẩn đánh giá các tiêu chuẩn pass/fail
Test case, Procedure – Nội dung
 Test case
 Định nghĩa tài liệu test
 Test items
 Đặc tả các dữ liệu input
 Đặc tả dữ liệu out put
 Môi trường
 Các yêu cầu đặc biệt
 Test Procedure
 Định nghĩa tài liệu
 Mục đích
 Các yêu cầu đặc biệt
 Procedure steps (thực hiện từng hiện)
Test Report
 Test Item Transmittal Report
 Định dạng phần mềm được chuyển giao tới các nhóm test độc lập.
 Sử dụng trong trường hợp mà các mẫu ban đầu của việc test được
đưa ra.
 Test Log
 Sử dụng cho những người tham gia vào việc quản lý các kết
quả tes
 Mục đích là ghi lại những gì xảy ra trong suốt quá trình
test.
 Test Incident Report
 Mô tả một vài sự kiện xuất hiện trong suốt quá trình test
mà trong đó mong muốn được phát triển xa hơn.
 Ví dụ như:
Thiết bị, công cụ lỗi
Các sự kiện, phần không được rõ ràng, chính xác.
Các bất thường xảy ra.
Test Log, Test Incident – Nội dung
 Test Log
 Định nghĩa tài liệu
 Mô tả
 Các sự kiện và hoạt động (Activity and event
entries)
 Test Incident
 Document identifier
 Summary
 Incident description
 Impact
Test Report – Nội dung
 Định nghĩa các tài liệu
 Tổng kết
 Chỉ ra các mâu thuẫn, thay đổi
 Đánh giá một cách toàn diện
 Tóm tắt sơ lược kết quả
 Ước lượng/Tổng kết các hoạt động
 Phê chuẩn.
KT viết TC hiệu quả
Một testcase được cho là hiệu quả:
 Test case hiệu quả là test case mà tìm thấy bug.
 Tìm được nhiều bug khó.
 Chỉ ra được những điểm ban đầu mà khi thực
hiện test không tìm ra vấn đề
 Tuân theo đúng các con số thống kê bug
 Theo dõi các lỗi theo các trường hợp đã được tìm
thấy
KT viết TC hiệu quả
For each identified requirement; define test cases.

Requirement #1 Test Cases

For Req. #1

Requirement #2 Test Cases

For Req. #2

Requirement #3
KT viết TC hiệu quả
 Equivalence class partitioning
 Control flow testing
 Data flow testing
 Transaction testing
 Domain testing
 Loop testing
 Syntax testing
 Finite state machine testing
 Load and stress testing
Equivalence class partitioning
 Xác định một nhóm các yêu cầu hệ thống, functions,
behaviors
 Phân các testcase vào các class. Mỗi class là một
nhóm các testcase tương tự nhau
 Trong mỗi class chọn test chỉ một vài testcase
 Phân các test case theo nhóm các TestCase cùng loại,
gọi là class hay lớp các TestCase
 Các class lại có thể xếp vào 2 nhóm
 Positive tests (clean tests)
• Test dựa trên defined requirements
• Test những trường hợp, hoàn cảnh sử dụng thông
thường
 Negative tests (dirty tests)
• Test nhằm tìm ra lỗi
• Test những trường hợp, hoàn cảnh sử dụng đặc biệt,
bất thường (như invalid input, vượt giá trị biên, chịu
stress)
Control Flow
 Là kỹ thuật test căn bản
 Sử dụng luồng xử lý để thiết lập các phương
pháp test
 Là sơ đồ mô hình hóa hành vi của hệ thống,
(không mô tả các câu lệnh trong code)
 Áp dụng được cho hầu hết các phần mềm, có
hiệu quả
 Áp dụng được trong mọi testing stages
 Mỗi rẽ nhánh trong luồng xử lý là 1 TestCase
Control Flow Testing Strategy -
Summary
 Kiểm tra các mô hình system or sub-system
 Định nghĩa đối tượng
 Định nghĩa các mối quan hệ
 Indetify the weights
 Identify paths through the model to cover objects
 Identify paths through the model to cover links
 Each path is a test case
 Đưa ra các điều kiện đầu vào và kết quả mong đợi cho
mỗi testcase
Data Follow
 Áp dụng cho các hệ thống “data-intensive”, ví dụ:
 HT sản sinh báo cáo, thống kê
 HT có tính toán thay đổi số liệu
 Phương pháp xây dựng testcase:
 Lập sơ đồ luồng dữ liệu (data flow)
 Lần theo từng đường dẫn trong sơ đồ
• Bắt đầu từ node output
• Lần ngược lại tới khi gặp node input
 Phân tích các TestCase theo sơ đồ mô hình luồng dữ
liệu
Transaction testing
 Áp dụng cho các hệ thống xử lý giao dịch
(như đặt vé máy bay, đặt phòng khách sạn)
 Sử dụng mô hình xử lý của hệ thống, chú
trọng đến điểm bắt đầu, điểm kết thúc của
từng xử lý, chú trọng tới hành đợi (queu)
 Tương tự như data flow, nhưng bao gồm các
khái niệm:
 Birth:nó bắt đầu khi nào
 Death:hoàn thành khi nào
 Queues: tuần tự các giao dịch đợi đến lượt
Transaction Flow Testing Strategy
Phân loại TC theo loại các giao dịch, chú trọng việc xác
định điểm khởi đầu, kết thúc và hàng đợi các điểm giao
dịch cần xử lý
 Xác định tất cả các loại giao dịch.
 Xác định nguồn gốc và điểm kết thúc cho mỗi loại
giao dịch.
 Xác định queues (nơi mà các giao dịch chờ đợi để
được xử lý)
 Xác định các thành phần (nhưng không nhất thiết
phải phù hợp với các thành phần phần mềm)
 Xây dựng mô hình
 Xác định hướng đi (paths)
Domain test
 Áp dụng cho các xử lý mà có xác định phạm vi giá trị dữ
liệu
 Chú trọng test các giá trị biên On, Off
 Tìm ra những nơi mà phần mềm cho giá trị khác nhau --
 Phân loại TC theo vùng giá trị của biến, đặc biệt chú
trọng các TC 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
 Testing Technique
 Tìm các giá trị biên độc lập
 Kiểm tra một điểm trên biên và độc đáo
 Chọn “off point” một giá trị gần với giá trị biên
Loop Test
 Nói về việc lặp trong cấu trúc, or white box, testing
 Áp dụng trong Black box test: quan tâm đến vòng lặp
trong hành vi của hệ thống chứ không quan tâm đến
vòng lặp trong code
 Phân loại các TC theo số giá trị từng lần rẽ nhánh các
vòng lặp
Ví dụ: khi hệ thống fari tìm ra tất cả các bản ghi thỏa
mãn một tiêu chí tìm kiếm nào đó
Giả sử khả năng hệ thống có thể hỗ trợ tối đa Max
vòng lặp, chỉ cần chọn thực hiện những testcase sau
là đủ:
- 0 lần, 1 lần, 2 lần qua vòng lặp
- X lần,
- Max-1, Max, Max + 1 lần
Loops – Test Cases To Use
 Thực hiện vòng lặp 0 lần
 Lặp 1 lần
 Lặp 2 lần
 Một số đặc trưng các lần lặp
 Thực hiện việc test lặp với số lượng maxium-
1 lần
 Thực hiện việc test lặp với maxium lần
 Thực hiện với maxium + 1 lần lặp
Syntax Testing
 Rất hữu ích cho Test
 Các câu lệnh có sẵn
 Các trường thực thể có cấu trúc khuôn dạng,
định dạng trước hoặc theo một quy định nào đó
 Ví dụ:
 Ngày tháng
 Địa chỉ Email
 Số điện thoại
 Mailing addresses
Syntax Testing - Technique
 Thiết kế các Test case xác thực rõ ràng (dữ liệu
valid)bằng cách sử dụng kỹ thuật phân lớp
tương đương.
 Thiết kế các testcase tiêu cực (negative)với lớp
dữ liệu Invalid
 Thực hiện các Test Case
State Machine Testing
 Là một chiến lược test khá hoàn hảo
 Áp dụng khi:
 Các ứng dụng được thực hiện qua nhiều các trạng thái khác
nhau
 Hệ thống được thiết kế sử dụng phương pháp hướng đối
tượng
 Một vài phần mềm có lược đồ chuyển trạng thái

State B

State C
State A State D
State machine : phương pháp
Các TC được phân loại từ việc lập các biểu đồ
chuyển trạng thái của hệ thống
 Vẽ một sơ đồ chuyển đổi trạng thái cho đối

tượng cần test

 Positive tests: thiết kế test cases cho từng

lần chuyển đổi trạng thái

 Negative tests: thiết kế các testcases nhằm

cố chuyển đổi trạng thái một cách bất hợp lý

Load testing
 Tùy thuộc vào từng loại hệ thống – bắt hệ
thống phải chịu tải lớn.
 Số lượng lớn các giao dịch cần thực hiện.
 Các file lớn.
 Số lượng lớn các file.
 Số lượng lớn các client cùng truy nhập.
 Các vận hành lặp đi lặp.
 Thực hiện việc này yêu cầu một số tool tự
động.
Stress Test
Bắt hệ thống hoạt động trong điều kiện bất
thường:
 Dung lượng bộ nhớ bị giới hạn.
 Mạng lưới hệ thống:Hoạt động với một số
lượng nhỏ các node.
 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ành.
Ưu tiên test
 Danh sách các ưu tiên test - “where to focus testing”
 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)
 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)
 Ưu tiên sắp xếp test theo quality dimension
 Số 1: thường là Function testing, và phải bao quát được
bussines cycle của hệ thống.
 Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax,
theo standards và user friendly.