Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
TESTING OVERVIEW
Người trình bày: Tô Lan Phương
Phòng: PQA
Tài liệu đào tạo nội bộ 2
Mục tiêu
Mục đích và vị trí của testing trong toàn bộ chu trình phát triển phần mềm.
Vai trò của các tester và nhóm tester độc lập
Qui trình test.
Các giai đoạn test.
Các phương pháp, kỹ thuật test trong từng giai đoạn test được áp dụng.
Vòng đời của 1 lỗi.
Bugs tracking (sử dụng testtrackpro).
Các tài liệu test cần có.
Sau buổi seminar này, các thành viên tham dự cùng nắm được:
Tài liệu đào tạo nội bộ 3
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 4
Testing là gì?
1. Mục đích của testing
Testing là quá trình chạy thử một chương trình nhằm tìm ra lỗi.
Khi nào ta nói: “Lỗi!”?
Tài liệu đào tạo nội bộ 5
Mục đích của Testing?
Để tìm lỗi!
Testing có thể chứng minh sự có mặt của lỗi, nhưng không thể chứng minh được điều gì?
Testing không thể chứng minh sự vắng mặt của lỗi!
1. Mục đích của testing (tiếp)
Tài liệu đào tạo nội bộ 6
Vậy test để làm gì?
Để chứng minh phần mềm hoạt động được?
Để chứng minh phần mềm không hoạt động?
Không để chứng minh điều gì cả, chỉ để làm giảm khả năng phần mềm không hoạt động tới mức chấp nhận được?
Testing không phải là việc làm đơn giản. Testing là một nghề đòi hỏi trí tuệ, nhằm đem lại: Một phần mềm ít rủi ro
Mà không tốn quá nhiều công sức cho việc test
1. Mục đích của testing (tiếp)
Tài liệu đào tạo nội bộ 7
Đặc điểm của testing?
Phải giả định là có lỗi!
Lấy mục tiêu là lỗi phần mềm, chứ không phải là chỉ ra phần mềm đang hoạt động đúng.
Không bao giờ chứng tỏ được rằng phần mềm không còn lỗi.
Bản thân việc test không nâng cao chất lượng phần mềm. Để nâng cao chất lượng phần mềm, cần phát triển tốt hơn, thay vì test nhiều hơn!
1. Mục đích của testing (tiếp)
Tài liệu đào tạo nội bộ 8
Cái khó của testing là gì?
Là biết khi nào thì dừng lại!
Là quyết định thực hiện những test case nào cho hiệu quả!
Thuật ngữ: Test case: là một tập hợp các giá trị đầu vào, các điều kiện thực hiện,
và các kết quả mong muốn; nhằm test phần mềm.
Test case hiệu quả: là test case khi thực hiện thì đem lại lỗi!
1. Mục đích của testing (tiếp)
Tài liệu đào tạo nội bộ 9
Tóm tắt nội dung 1
Testing là săn tìm lỗi.
Testing là để đảm bảo phần mềm “đủ tốt”, với ràng buộc công sức test không quá lớn, và nhiều ràng buộc khác.
Tester phải biết tưởng tượng, chọn lọc, sắp xếp các test case,…
Làm Tester là một nghề đầy thách thức.
Tài liệu đào tạo nội bộ 10
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 11
2. Mô hình chữ VSoftware
Development Phases
Test Planning Phase Test Execution Phase
Software V&V
Plan
System Test
Plan
Integration
Test Plan
Unit Test
Plan
Acceptance
Demonstration
Plan
Project Plan
Requirements
Spec
Architectural
Design Spec
Code
System
Test
Acceptance
Demonstration
Integration
Test
Install
Unit
Test
Detailed
Design Spec
Theo “Strategies for Effective Software Testing”, Jessee Ring, Software Quality First liên kết với Alliant, tháng 8/2004
Tài liệu đào tạo nội bộ 12
2. Mô hình chữ V (tiếp)
Testing, cũng như bất kỳ việc gì khác:
Phải bắt đầu bằng xác định mục tiêu
Phải có kế hoạch.
Tester nên được tham gia/thông tin về phần mềm ngay từ đầu.
Test plan được lập càng sớm càng tốt.
Sẽ là quá muộn nếu lập test plan khi phần mềm đã ra lò.
Tài liệu đào tạo nội bộ 13
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 14
3. Vai trò của các tester
3.1. Vai trò của nhóm tester độc lập
3.2. Tổ chức nhóm tester theo dự án
3.3. Vai trò của test leader
3.4. Vai trò của tester thành viên
Tài liệu đào tạo nội bộ 15
3.1. Vai trò của nhóm tester độc lập
Tự test code của mình: không hiệu quả!
Tester cần được độc lập với nhóm phát triển.
Tester cần được quản lý theo “ngành dọc”
Nhóm tester độc lập: Tổ chức, bố trí testers cho các dự án.
Độc lập báo cáo về chất lượng và mức độ hoàn thành các phần mềm.
Trao đổi kinh nghiệm, bồi dưỡng kỹ thuật testing cho các thành viên trong nhóm
Tài liệu đào tạo nội bộ 16
3.2. Tổ chức nhóm tester theo dự án
Các role test trong một dự án: Test leader: làm test plan, test evaluation report, phân công
tester
Test designer: thiết kế test cases, sắp xếp thứ tự test
Test worker: thực hiện test, làm test result report.
Số tester trong một dự án: >=1
Thực tế các role “test designer” và “test worker” thường do cùng một người đảm nhận, gọi chung là “tester”
Tài liệu đào tạo nội bộ 17
3.3. Vai trò của test leader
Lead nhóm tester của dự án: Giao việc và giám sát công việc cho các tester
Đảm bảo các test cases giao cho các tester được thiết kế đúng, được thực hiện đủ
Đảm bảo tất cả các lỗi được ghi vào phần mềm ghi lỗi
Đảm bảo tất cả các lỗi developer báo fixed phải được test lại.
Hỗ trợ chuyên môn cho các tester
Đảm bảo việc test được thực hiện đúng kế hoạch, đúng tiến độ, với đủ các tài liệu test cần thiết
Review các lỗi, hỗ trợ và thúc giục team lead cho fix lỗi theo đúng yêu cầu.
Chịu trách nhiệm báo cáo về sản phẩm được test
Báo cáo công việc của nhóm lên trưởng nhóm testers.
Tài liệu đào tạo nội bộ 18
3.4. Vai trò của tester
Thiết kế test cases và phân mức ưu tiên thực hiện chúng
Thực hiện các test cases
Ghi lỗi, theo dõi lỗi, trực tiếp trao đổi về lỗi với developer
Làm báo cáo về các test cases được giao
Hỗ trợ test leader chuẩn bị kế hoạch test
Hỗ trợ test leader làm các nhiệm vụ khác nếu cần
Tài liệu đào tạo nội bộ 19
Tóm tắt nội dung 3
“Độc lập” là yếu tố quan trọng để đảm bảo testing thành công
Testing là một chuyên môn cần được cập nhật thường xuyên
Test leader là một vị trí đòi hỏi tầm bao quát cao
Tester là công việc đòi hỏi nhiều tố chất tốt.
Tài liệu đào tạo nội bộ 20
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 21
4. Các khái niệm phân loại test
4.1. Testing approaches: các phương pháp test
4.2. Testing stages: các giai đoạn test
4.3. Testing techniques: các kỹ thuật test
Tài liệu đào tạo nội bộ 22
4.1. Testing approaches
White box testing – test hộp trắng Còn gọi là structural testing
Test dựa trên cấu trúc của code
Black box testing – test hộp đen Còn gọi là functional testing,
behavioural testing
Test không quan tâm đến code, test dựa trên hành vi của hệ thống
INPUT
OUTPUT
INPUT
OUTPUT
Tài liệu đào tạo nội bộ 23
4.2. Testing stages
Code
Developers
Independent
Test Group
Unit TestingIntegration
Testing System Testing
Tài liệu đào tạo nội bộ 24
4.2. Testing stages (tiếp)
Unit testing Unit là phần nhỏ nhất có thể được compiled, linked, và
loaded
Unit testing được thực hiện bởi Developer
Sử dụng phương pháp test hộp trắng
Tài liệu đào tạo nội bộ 25
4.2. Testing stages (tiếp)
Integration 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
Có 3 cách intergration: top-down, bottom-up, big-bang. Tương ứng là các cách test.
Tài liệu đào tạo nội bộ 26
4.2. Testing stages (tiếp)
Integration testing –test tích hợp Integration testing đòi
hỏi các module phải được unit test trước.
Nếu có nhiều lỗi lẽ ra phải tìm thấy từ Unit testing, thì ngừng Integration testing, trả module nhiều lỗi về cho developer.
Module
or subsystem
Module
or subsystem
Send a parameter
Acknowledge
Action:
Display
message
Tài liệu đào tạo nội bộ 27
4.2. Testing stages (tiếp)
System testing Khi integration đã được hoàn tất
Sử dụng phương pháp test hộp đen
Test dựa trên requirements
Là sân của nhóm tester độc lập
Cần có một cơ chế để nhập inputs và quan sát reponses của hệ thống, ví dụ như GUI.
Tài liệu đào tạo nội bộ 28
4.2. Testing stages (tiếp)
Requirements cho System testing: System Requirements Specification
Interface Specifications
Users Guide
Use Cases
Customers
Domain Experts
Bug Data
Re-engineering
Tài liệu đào tạo nội bộ 29
4.2. Testing stages (tiếp)
Acceptance test Nên được gọi là Acceptance Demonstration thay cho
Acceptance Test
Để chứng minh phần mềm đã đủ sẵn sàng để bàn giao cho khách hàng
Khi tất cả các testing stages khác đã được hoàn tất
Dựa trên cơ sở là toàn bộ hay một phần của 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.
Tài liệu đào tạo nội bộ 30
4.2. Testing stages (tiếp)
Regression testing Nhằm tìm lỗi trong các phần “unchanged” của một software
có các phần khác “changed”
Khi bảo trì hay nâng cấp phần mềm lên version mới
Khi tích hợp các phần của một phần mềm
Software System
After Modification
Actual bug distribution after
modifications are made.
Regression
bug
Tài liệu đào tạo nội bộ 31
4.3. Testing techniques
4.3.1. Equivalence class partitioning
4.3.2. Control flow testing
4.3.3. Data flow testing
4.3.4. Transaction testing
4.3.5. Domain testing
4.3.6. Loop testing
4.3.7. Syntax testing
4.3.8. State machine testing
4.3.9. Load and stress testing
Tài liệu đào tạo nội bộ 32
4.3. Testing techniques
4.3.1. - Equivalence class partitioning: Phân các test cases vào các class. Mỗi class là một nhóm các test cases
tương tự nhau
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 của cùng một class
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 quá trị biên, chịu stress,…)
Tài liệu đào tạo nội bộ 33
4.3. Testing techniques (tiếp)
4.3.1. Equivalence class partitioning: ví dụ
Example program:
Begin
Read (AAAAAAAAAA)
End
What are the equivalence classes?
Tài liệu đào tạo nội bộ 34
4.3. Testing techniques (tiếp)
4.3.1. Equivalence class partitioning: ví dụ
Equivalence classes for “positive” tests: All 10 inputs consist of the same character in upper case, repeated
for each letter of the alphabet.
ALL 10 inputs consist of the same character in lower case, repeated for each letter of the alphabet.
All 10 inputs are different, mixed case.
Test Cases: TC01 - Input: AAAAAAAAAA
TC26 - Input: ZZZZZZZZZZ
TC28 - Input: aaaaaaaaaa
TC53 - Input: zzzzzzzzzz
TC54 - aBcDeFgHi
TC55 - IhGfEdCbA
Tài liệu đào tạo nội bộ 35
4.3. Testing techniques (tiếp)
4.3.1. Equivalence class partitioning: ví dụ (tiếp)
Equivalence classes for “negative” tests: All 10 inputs are numeric.
Mixed numeric and alphabetic inputs.
Embedded blanks
Input consists of one valid character.
Input consists of one invalid character.
Input includes special characters (*, & %, etc.)
Input consists of 11 characters.
What would be a correct output for these cases?
Tài liệu đào tạo nội bộ 36
4.3.1. Equivalence class partitioning: Exercises Bạn phải test một kênh quản lý phòng họp:
Cho một cơ quan có nhiều phòng họp, to nhỏ khác nhau
NSD đăng ký sử dụng phòng: chọn phòng, nhập ngày giờ họp
Nếu có conflict thì chương trình đưa ra cảnh báo và gợi ý cho NSD.
Một số class phải test?
Về nhà: Trình bày một yêu cầu test trong phần mềm bạn đang phải test
Bạn sẽ phân chia các test cases thành các class như thế nào?
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 37
4.3.2. Control flow testing
Là một kỹ thuật testing căn bản
Sử dụng sơ đồ luồng xử lý (control flow graph)
Đó 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
Áp dụng được cho hầu hết các phần mềm, và có hiệu quả
Áp dụng được trong mọi testing stages
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 38
4.3.2. Control flow testing
Sơ đồ luồng xử lýProcess 1
Process 2
?Yes
No
Process 3
More
Processing
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 39
4.3.2. Control flow testing: Exercise
Hãy lập sơ đồ mô phỏng hành vi của một hệ thống/kênh bạn cần test
Hãy lập sơ đồ mô phỏng hành vi của một tiểu hệ thống/chức năng trong hệ thống đó
Hãy lập sơ đồ luồng xử lý đối với một form item cần test.
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 40
4.3.3. Data flow testing: Áp dụng cho các hệ thống “data-intensive”
Ví dụ các hệ thống sản sinh báo cáo, thống kê.
Ví dụ các hệ thống có tính toán thay đổi số liệu.
Phương pháp xây dựng test case: Lập sơ đồ luồng dữ liệu (Data flow diagram)
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
Ta đã được một test case
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 41
4.3.4. 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àng đợi (queue)
4.3.5. Domain testing: Áp dụng cho các xử lý mà có xác định phạm vi (range) giá trị dữ
liệu
Chú trọng test các giá trị biên on và off
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 42
4.3.6. Loop testing: Á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
Ví dụ khi hệ thống phải tìm ra tất cả các bản ghi thoả 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 test case sau là đủ:
0 lần, 1 lần, 2 lần qua vòng lặp
X lần (X: số ngẫu nhiên, giữ khoảng 0 và Max)
Max -1, Max, Max+1 lần
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 43
4.3.7. Syntax testing: Là kỹ thuật dùng để:
Test các câu lệnh (commands)
Test việc xử lý các trường phải tuân theo một định dạng xác định
Ví dụ về syntax: Ngày tháng
Địa chỉ email
Công thức toán học do NSD định nghĩa
…
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 44
4.3.7. Syntax testing: trình tự thực hiện Phân tích, nắm rõ qui tắc syntax
Thiết kế các positive test cases, sử dụng kỹ thuật Equivalence class partitioning
Thiết kế các negative test Mỗi lần làm sai một phần tử trong syntax
Thực hiện test
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 45
4.3.7. State machine testing Áp dụng khi:
Test các “menu driven application”
Test các hệ thống thiết kế bằng phương pháp hướng đối tượng
Test bất cứ hệ thống nào có sơ đồ chuyển đổi trạng thái (state)
Ví dụ về trạng thái: Account sử dụng Portal chưa có hiệu lực (inactive account)
Account sử dụng Portal có hiệu lực (active account)
Đặc trưng của trạng thái: Ở mỗi trạng thái, có một số hành động được phép thực hiện và một số khác thì không.
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 46
4.3.8. State machine testing: phương pháp 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 test cases nhằm cố chuyển đổi trạng thái một cách bất hợp lệ
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 47
4.3.9. Load & Stress Testing Load testing: bắt hệ thống phả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
Stress testing: bắt hệ thống 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
Database server down
4.3. Testing techniques (tiếp)
Tài liệu đào tạo nội bộ 48
Tóm tắt nội dung 4
Testing approaches: white box & black box Independent testing hiện chỉ làm black box testing.
Testing stages: unit integration system acceptance, và regression. Developer testing và indepedent testing cần bổ trợ nhau
Testing types: gắn với các quality dimension quen thuộc nhất, là: function testing, securiry testing, usability testing, installation testing. cần sớm bổ sung thêm load testing & stress testing
Testing techniques: Để test một hệ thống cần kết hợp sử dụng nhiều testing techniques Quyết định sử dụng những techniques nào là nhiệm vụ quan trọng của test design
Tài liệu đào tạo nội bộ 49
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 50
5. Mô tả và phân loại lỗi
Làm gì ngay sau khi tìm thấy lỗi? Lặp lại một lần nữa các thao tác dẫn đến bug
Tìm cách tổng quát hoá trường hợp dẫn đến bug. Xét xem liệu còn những thao tác nào khác dẫn cũng dẫn bug?
Tìm ra các thao tác tối thiểu dẫn đến bug
Để ý xem dữ liệu test , cấu hình (settings) hay các option hiện tại có gì đặc biệt?
Xét xem liệu bug này có thể dẫn đến các hậu quả gì khác?
Tìm lướt xem bug này đã từng được ghi hay chưa?
Tài liệu đào tạo nội bộ 51
5. Mô tả và phân loại lỗi (tiếp)
Mô tả lỗi Yêu cầu chung
Mô tả thật rõ ràng những bước tối thiểu để sinh lại bug.
Không ôm đồm: mỗi bản ghi mô tả bug chỉ bao gồm một bug. Trong trường hợp tìm ra nhiều bug đồng thời, hãy tạo ra nhiều bản mô tả riêng biệt, ngay cả khi những bug đó có quan hệ với nhau. Điều này sẽ giúp việc nhận, xử lý và theo dõi bug được dễ dàng hơn.
Không dùng nhiều từ tiếng Việt không dấu, không dùng các từ ngữ khó hiểu hoặc dễ gây nhầm lẫn.
Đảm bảo rằng những người khác sẽ dễ dàng hiểu được bug.
Tài liệu đào tạo nội bộ 52
5. Mô tả và phân loại lỗi (tiếp)
Mô tả lỗi (tiếp) Các mục thông tin chi tiết
Summary: Vị trí của nơi xảy ra bug trong phần mềm, kèm sau là test comment.
Type: Kiểu lỗi, bao gồm:
Not set
Crash – data loss
Crash – not data loss
Incorrect functionality
Cosmetic
Feature request
Recommend
Tài liệu đào tạo nội bộ 53
5. Mô tả và phân loại lỗi (tiếp)
Phân loại lỗi Theo mức độ ưu tiên (priority)
Not set
Critical
Hight
Medium
Low
Future release
Recomment
Theo mức độ ảnh hưởng (severity) Program break
Incomplete
Unfriendly
Cosmetic
Tài liệu đào tạo nội bộ 54
Tóm tắt nội dung 5
Type Priority Severity
Crash (data loss + not data loss)
Critical Program break
Incorrect functionality Hight Not expected/ Incomplete
Cosmetic Hight/ Medium/ Low Unfriendly/ Incomplete/ Interface
Feature request Medium/ Low incomplete
Tài liệu đào tạo nội bộ 55
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 56
6. Vòng đời của một lỗi
Open
Fixed
Rejected
ClosedRejected
- Closed
Suspend
- Mũi tên màu ghi dành cho các developer.
- Mũi tên màu đỏ dành cho các tester.
Tài liệu đào tạo nội bộ 57
6. Vòng đời của một lỗi trong TestTrackPro
Open
Assign
Estimate
Fix
Needs Verification
Release to testing
Save & Assign
Verify
Closed
Need Customer to verify
Release to Customer to
testing
Customer verify defect
Pass Fail
Closed ReOpen
Tài liệu đào tạo nội bộ 58
6. Vòng đời của một lỗi được áp dụng
Open
Assign
Estimate
Fix
Verify
Closed
ReOpen
Pass
Tài liệu đào tạo nội bộ 59
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 60
7. Lập test cases từ use case
7.1. Mô tả requirement bằng use case
7.2. Lập test cases từ use case
Tài liệu đào tạo nội bộ 61
7.1. Mô tả Rqm bằng use case
Khái niệm use case:
Một Use case là tập hợp của một loạt các cảnh kịch về việc sử dụng hệ thống
Mỗi cảnh kịch mô tả một chuỗi các sự kiện
Mỗi một chuỗi này sẽ được kích hoạt bởi một người nào đó, một hệ thống khác hay là một phần trang thiết bị nào đó
Những thực thể kích hoạt nên các chuỗi sự kiện như thế được gọi là các Tác Nhân (Actor)
Tài liệu đào tạo nội bộ 62
Sự cần thiết phải có use case:
Use Case là một công cụ xuất sắc để khuyến khích những người dùng tiềm năng nói về hệ thống từ hướng nhìn của họ
Use case tạo nên một lời mô tả rõ ràng và nhất quán về việc hệ thống cần phải làm gì
Có thể đơn giản hóa việc thay đổi và mở rộng hệ thống qua việc thay đổi và mở rộng mô hình Use Case, sau đó chỉ theo dõi riêng những Use Case đã bị thay đổi cùng những hiệu ứng của chúng trong thiết kế hệ thống và xây dựng hệ thống
7.1. Mô tả Rqm bằng use case (tiếp)
Tài liệu đào tạo nội bộ 63
7.2. Lập test cases từ use case
Mô hình luồng các sự kiện trong một use case
Tài liệu đào tạo nội bộ 64
7.2. Lập test cases từ use case (tiếp)
Các bước lập test case từ use case
Tìm ra các “path” của các luồng sự kiện trong use case. Mỗi path như này được gọi là một scenario
Chỉ ra điều kiện xảy ra mỗi scenario
Mô tả điều kiện, trình tự diễn ra trong mỗi scenario và kết quả mong muốn.
Tài liệu đào tạo nội bộ 65
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 66
8. Thực hiện test
8.1. Các bước chuẩn bị test
8.2. Phân tích dữ liệu giả định
8.3. Khái niệm Test chay
8.4. Test thế nào cho đủ
Tài liệu đào tạo nội bộ 67
8.1. Các bước chuẩn bị test
Phân tích requirements
Lập các kế hoạch test
Lập testing checklist
Mô tả các test case phức tạp
Theo dõi các thay đổi
Tài liệu đào tạo nội bộ 68
8.2. Phân tích dữ liệu giả định
Lập test procedure cho nhiều test case
Sử dụng Excel
Tài liệu đào tạo nội bộ 69
8.3. Khái niệm Test chay
Test chay là gì?
Khi nào chấp nhận test chay?
Làm gì để test chay có hiệu quả?
Tài liệu đào tạo nội bộ 70
Khái niệm test chay
Test không có tài liệu đầu vào
Test nhằm phát hiện và sửa lỗi được chút nào hay chút ấy
8.3. Khái niệm Test chay (tiếp)
Tài liệu đào tạo nội bộ 71
Khi nào chấp nhận test chay?
Dự án quá gấp, không đủ thời gian cho nhóm phát triển lập tài liệu
Requirements không thể được xác lập rõ ràng
8.3. Khái niệm Test chay (tiếp)
Tài liệu đào tạo nội bộ 72
Làm gì để test chay có hiệu quả?
Tích cực, mau chóng trao đổi với nhóm phát triển để nắm bắt được bài toán
Tham khảo các sản phẩm tương tự, nếu có thể.
Thống nhất với nhóm phát triển danh sách những vùng trọng tâm cần test
Tranh thủ tiếp xúc với khách hàng, làm sáng tỏ những nghi vấn về yêu cầu, nghiệp vụ
Lập checklist cho việc test, nếu kịp
8.3. Khái niệm Test chay (tiếp)
Tài liệu đào tạo nội bộ 73
Làm gì để test chay có hiệu quả?
Tập trung test với cường độ cao
Thường xuyên review Mức độ khẩn cấp của các lỗi.
Làm các báo cáo ngắn và linh hoạt về tình trạng lỗi để thúc đẩy tiến độ fix lỗi.
Tranh thủ xây dựng và tận dụng các testing checklist sẵn có
8.3. Khái niệm Test chay (tiếp)
Tài liệu đào tạo nội bộ 74
8.4. Test thế nào cho đủ
Câu hỏi:
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à liệu tất cả các lỗi đã được tìm ra chưa, mà là liệu phần mềm đã đủ “tốt” để ngừng test hay chưa?
Đó là một quyết định có tính “kinh tế”.
Và là một trong những vấn đề khó nhất của testing.
Tài liệu đào tạo nội bộ 75
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 của việc đó?
Khả năng NSD đụng phải các bug còn sót?
Hậu quả những bug đó với NSD?
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 76
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
Kinh nghiệm và cảm nhận cụ thể trong từng dự án, từng phần mềm vẫn là điều then chốt
Tuy nhiên cần biết cần dành thời gian và nguồn lực cho những test nào trước, theo các cách sau
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 77
Ưu tiên phân bổ nguồn lực cho: Danh sách “where to focus testing”:
Những vùng quan trọng nhất của phần mềm 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 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 change vừa có (khi
regression test). 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.
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 78
Ư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 busines cycle của hệ thống.
Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax, theo standards và user friendly.
Số 3: security testing, installation testing, …
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 79
Chọn lọc các test case hiệu quả:
Dùng kỹ thuật Equivalence class partitioning, chỉ lấy một vài test case đại diện cho từng class là đủ.
Dùng kỹ thuật Domain testing, chỉ lấy một số giá trị on và off là đủ.
Dùng kỹ thuật Loop testing, thì chỉ một số test case cho các trường hợp đi qua vòng lặp 0 lần, 1 lần, 2 lần, x lần và số lần tối đa ± 1 là đủ.
…
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 80
Chọn lọc các test case hiệu quả (tiếp):
Tính mức ưu tiên cho mỗi test case bằng cách xây dựng “Test Coverage matrix” “Test Coverage matrix” map từng test case vào từng software feature
Cần ưu tiên những test case có liên quan đến nhiều feature nhất.
Thống kê hiệu quả của mỗi test case qua thời gian Thu thập số liệu về số lỗi mà mỗi test case đem lại theo từng loại phần mềm,
từng khoảng thời gian
Đào thải dần những test case đã “hao mòn hiệu quả”, tìm các test case mới thay thế.
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 81
Đánh giá xác suất lỗi còn tiềm ẩn:
Dựng đồ thị biếu diễn số lượng lỗi đã tìm thấy trong mỗi đơn vị thời gian có thể tạo cho mỗi loại bug một đồ thị dạng này, ví dụ tạo một đồ thị dạng này
cho loại lỗi về Security – High Priority)
Đồ thị đi xuống một cách tương đối ổn định, đạt một tần suất lỗi/đơn vị thời gian tương đối thấp là dấu hiệu tốt.
Dựng đồ thị thống kế số lỗi tìm thấy trong mỗi phiên bản đã release của phần mềm Đồ thị đi xuống một cách tương đối ổn định là dấu hiệu tốt
So sánh với mức xác suất còn lỗi sau khi release có thể chấp nhận Mức này được xác định một cách định tính, từ nhiều yếu tố mang tính business
8.4. Test thế nào cho đủ (tiếp)
Tài liệu đào tạo nội bộ 82
Nội dung
1. Testing overview.
2. Mô hình chữ V.
3. Vai trò của các tester.
4. Các khái niệm phân loại test.
5. Mô tả và phân loại lỗi (sử dụng TestTrackPro).
6. Vòng đời của lỗi.
7. Cách lập các testcase từ các usecase.
8. Thực hiện test và test thế nào cho đủ.
9. Các tài liệu test cần có.
Tài liệu đào tạo nội bộ 83
9. Các tài liệu test
Qui trình test Tài liệu test
Test Planning
Test Specification
Test Reporting
Test Execution
Test Plan
Test Design Spec Test Design SpecTest
Design Spec
Test Case Spec Test Proc. Spec
Test Log
Test Evaluation
report
Test Result
Tài liệu đào tạo nội bộ 84
9.1. Test Plan
Test Plan là gì? Là tài liệu chỉ ra test cái gì, theo phương pháp nào, khi nào, bởi ai.
Tại sao phải làm Test plan? Thảo luận: “plan” để làm gì?
Ai làm Test plan? Project Test Leader!
Khi nào làm Test plan? Càng sớm càng tốt, ngay từ khi nhóm dự án có Project Plan và
Requirements Spec.
Quá muộn nếu làm Test plan khi cần bắt đầu thực hiện test.
Tài liệu đào tạo nội bộ 85
9.1. Test Plan (tiếp)
Nội dung căn bản của Test Plan (1) Giới thiệu tài liệu
Sơ lược hệ thống cần test và: Các nhiệm vụ (mission) test trọng tâm
Các định hướng (motivator) để test
Các item cần test
Chiến lược test Dùng phương pháp gì?
Có các testing stages nào?
Chọn những loại test nào?
Sử dụng những kỹ thuật test nào?
Sử dụng những công cụ nào?
Tài liệu đào tạo nội bộ 86
9.1. Test Plan (tiếp)
Nội dung căn bản của Test Plan (2)
Các tài liệu, báo cáo test
Các vai trò, trách nhiệm của nhóm test
Tổ chức nhân sự và đào tạo
Tiến độ dự kiến
Tài liệu đào tạo nội bộ 87
9.2. Test Design Spec
Test Design Spec là gì? Là tài liệu chi tiết hoá các chiến lược test đã được chỉ ra trong test
plan.
Ai làm Test design spec? Test Leader hoặc Tester.
Khi nào cần và khi nào làm design spec? Cần khi dự án đòi hỏi phạm vi test rộng, có nhiều test case phức
tạp, cần có hướng dẫn chi tiết về kỹ thuật test.
Làm khi đã có test plan và bắt đầu tạo test cases.
Tài liệu đào tạo nội bộ 88
9.2. Test Design Spec (tiếp)
Nội dung căn bản của test design spec
Giới thiệu tài liệu
Tinh chỉnh, phát triển, chi tiết hoá chiến lược test Đặc biệt là trình bày rõ về các kỹ thuật test và các kinh nghiệm test sẽ sử dụng.
Liệt kê các test case cần có (mã và mô tả vắn tắt trường hợp test)
Tài liệu đào tạo nội bộ 89
9.2.1. Test Case Spec
Test case Spec là gì?
Là tài liệu trình bày về các test case sẽ được thực hiện.
Ai làm Test case spec?
Tester
Khi nào làm Test case spec?
Làm khi đã có test plan.
Trước khi bắt tay vào test.
Tài liệu đào tạo nội bộ 90
Nội dung căn bản của Test case spec
Giới thiệu tài liệu
Phân nhóm và trình bày các test case. Thông tin về mỗi test case: Mục đích thực hiện
Các bước thực hiện
Điều kiện trước khi thực hiện
Kết quả mong muốn
Dữ liệu test (nếu cầbn)
9.2.1. Test Case Spec (tiếp)
Tài liệu đào tạo nội bộ 91
9.2.2. Test Procedure Spec
Test procedure spec là gì?
Là tài liệu hướng dẫn chi tiết về các bước thực hiện một hoặc một số test case
Ai làm Test procedure spec?
Tester
Khi nào làm Test procedure spec?
Khi đã thiết kế các test case.
Trước khi bắt tay vào test.
Tài liệu đào tạo nội bộ 92
9.3. Test Report
9.3.1. Test log
9.3.2. Test Result Report
9.3.3. Test Release Report
Tài liệu đào tạo nội bộ 93
9.3.1. Test Log
Test log là gì?
Là tài liệu ghi lại theo trật tự thời gian những sự kiện test đã được thực hiện và kết quả.
Ai làm Test log?
Tester
Khi nào làm Test log?
Trong khi thực hiện test.
Tài liệu đào tạo nội bộ 94
9.3.2. Test Result Report
Test result report là gì? Là tài liệu báo cáo kết quả thực hiện test.
Ai làm Test result report? Tester
Khi nào làm Test result report? Sau khi thực hiện test xong một test item.
Sau khi test được một khoảng thời gian nào đó.
Sau khi test xong một lượt của toàn hệ thống hay một tiểu hệ thống.
Khi cần cung cấp thông tin cho người quản lý dự án
Khi Test leader yêu cầu
Tài liệu đào tạo nội bộ 95
Nội dung căn bản của Test result report Giới thiệu tài liệu
Giới thiệu các test item mục tiêu
Các test case dự kiến thực hiện
Các test case đã thực hiện
Kết quả chi tiết của việc thực hiện từng test case
Thống kê tỉ lệ test case được thực hiện và tỉ lệ pass của các test case.
Đưa ra các change request
Ghi chú về các hiện tượng cần theo dõi thêm
9.3.2. Test Result Report (tiếp)
Tài liệu đào tạo nội bộ 96
9.3.3. Test Release Report
Test release report là gì?
Là tài liệu báo cáo kết quả test của sản phẩm, đánh giá chất lượng sản phẩm đã đủ tốt để release hay chưa?
Ai làm Test release report?
Test leader
Khi nào làm Test release report?
Khi ngừng test một bản sản phẩm
Khi cần kết luận sản phẩm có thể được release hay chưa?
Tài liệu đào tạo nội bộ 97
Nội dung căn bản của Test Release Report Giới thiệu tài liệu
Giới thiệu hệ thống được test
Khái quát về kết quả test: Đánh giá chung về hệ thống được test, kết luận release hoặc không.
Đánh giá ảnh hường của môi trường kiểm tra
Các nhận xét khuyến nghị
Kết quả test chi tiết
Các phụ lục: thống kê số lỗi, số test case được thực hiện,…
9.3.3. Test Release Report (tiếp)
Tài liệu đào tạo nội bộ 98
Tóm tắt nội dung 9
Test
Plan/Design
Test Report
• Báo cáo kết quả test thực sự, đối chiếu với test plan.
• Đưa ra đánh giá, kết luận về độ tin cậy của chất lượng sản phẩm.
• Cho biết kế hoạch test đã được thực hiện trọn vẹn hay chưa.
• Xác định môi trường và các test cases sẽ thực hiện.
• Chỉ ra khối lượng test sẽ thực hiện.
• Giúp xác định được khi nào “test xong”.
Hỏi và Đáp
Tài liệu đào tạo nội bộ 100
Tài liệu tham khảo
Tài liệu tham khảo sử dụng
Introduction To Software Testing And Quality Assurance, http://tejasconsulting.com/courses
Software Testing Strategies, by Jessee Ring
Testing roles and responsibilities, by Jesse Chen
Tài liệu Bạn nên đọc
<books, articles, web sites related to the course>
Tài liệu đào tạo nội bộ 101
Thank You