01 tester training - overview
DESCRIPTION
TRANSCRIPT
Testing ở Vietsoftware Testing ở Vietsoftware
Tác giả: Dương Thị MinhTác giả: Dương Thị Minh
Version: 1.0 Version: 1.0 Last Update: 02/04/2005Last Update: 02/04/2005
Người hướng dẫn: Dương Thị MinhQA Engineer
04-06/04/2005
TRAINING MATERIALVSI Inc. 2
Nội dung khoá họcNội dung khoá học
Giới thiệu I. Nhập môntesting
Kiểm tra lý thuyết
II. Các kỹ năng thực hành
III. Testing checklists
Kiểm tra
0,5
14
1,5
1
1
IV. Kỹ năng cá nhân
1
TRAINING MATERIALVSI Inc. 3
Mục tiêu phần IMục tiêu phần I
Kết thúc phần I – Nhập môn testing – học viên sẽ trả lời được các câu hỏi sau:
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?
Phân biệt một số khái niệm quan trọng? Có thể tìm ra được hết lỗi? Những tài liệu test nào cần có?
TRAINING MATERIALVSI Inc. 4
I.1. Mục đích của testing I.2. Mô hình chữ V I.3. Vai trò của các tester I.4. Các khái niệm phân loại test I.5. Test thế nào cho đủ I.6. Các tài liệu test
Nội dung phần INội dung phần I
TRAINING MATERIALVSI Inc. 5
Testing là gì?
I.1. Mục đích của testingI.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!”?
TRAINING MATERIALVSI Inc. 6
Mục đích của Testing?
I.1. Mục đích của testingI.1. 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!
TRAINING MATERIALVSI Inc. 7
Vậy test để làm gì?
I.1. Mục đích của testingI.1. Mục đích của testing
Để 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
TRAINING MATERIALVSI Inc. 8
Đặc điểm của testing?
I.1. Mục đích của testingI.1. Mục đích của testing
Phải giả định là có lỗi! Lấy mục tiêu là break 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!
TRAINING MATERIALVSI Inc. 9
I.1. Mục đích của testingI.1. Mục đích của testing
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!
TRAINING MATERIALVSI Inc. 10
Tóm tắt I.1Tóm tắt I.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.
TRAINING MATERIALVSI Inc. 12
I.1. Mục đích của testing I.2. Mô hình chữ V I.3. Vai trò của các tester I.4. Các khái niệm phân loại test I.5. Test thế nào cho đủ I.6. Các tài liệu test
Nội dung phần INội dung phần I
TRAINING MATERIALVSI Inc. 13
I.2. Mô hình chữ VI.2. Mô hình chữ V
Software V&V Plan
System Test Plan
Integration Test Plan
Unit Test Plan
Acceptance Demonstration
Plan
Software Development Phases
Test Planning Phase
Test Execution PhaseProject Plan
Requirements Spec
Architectural Design Spec
Code
SystemTest
AcceptanceDemonstration
IntegrationTest
Install
UnitTest
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
TRAINING MATERIALVSI Inc. 14
I.2. Mô hình chữ VI.2. Mô hình chữ V
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ò.
Ở VSI: Tester không đảm nhận Unit test. Nhiều dự án không có Requirements Spec. Qui
trình test phải biến đổi linh hoạt theo.
TRAINING MATERIALVSI Inc. 15
I.1. Mục đích của testing I.2. Mô hình chữ V I.3. Vai trò của các tester I.4. Các khái niệm phân loại test I.5. Test thế nào cho đủ I.6. Các tài liệu test
Nội dung phần INội dung phần I
TRAINING MATERIALVSI Inc. 16
I.3. Vai trò của các testerI.3. Vai trò của các tester
I.3.1. Vai trò của nhóm tester độc lập I.3.2. Tổ chức nhóm tester theo dự án I.3.3. Vai trò của test leader I.3.4. Vai trò của tester thành viên
TRAINING MATERIALVSI Inc. 17
I.3 > I.3.1. Vai trò của nhóm tester độc lậpI.3 > I.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
TRAINING MATERIALVSI Inc. 18
Independent Testing - ConsiderationsIndependent Testing - Considerations
SupplementarySlide
The organization can demonstrate that independent testing of software is in place and contributing to improved quality.
The software testing organization participates in early life cycle reviews to assure testability of reviewed items.
The organization creates test plans early in software projects, in parallel with development activities.
Software project teams test software using customer-representative mechanisms, such as: a test lab or simulated environment.
The organization can show that software testing is analyzed to assure that it is customer-representative.
Testing effectiveness and efficiency are evaluated and tracked from multiple perspectives across the software development life cycle such as: SQA, field support, customer coverage, etc.
Source: Motorola Corporate Quality System Review Guidelines, November 1992
TRAINING MATERIALVSI Inc. 19
Independent Test Group - EvaluationIndependent Test Group - Evaluation
SupplementarySlide
Poor: Testing is performed randomly by developers. Only system or product testing may be done independently and it is very dependent on the experience of the developers.
Weak: A few software projects have begun to address testing in a disciplined manner, with early planning and ties to anticipated customer usage. Testing is still mostly ineffective.
Fair: An independent testing approach has been defined that provides early tester participation and customer analysis, but it is only partially implemented. Measurement of test effectiveness has started.
Marginally Qualified: A well defined concurrent independent testing program has become institutionalized. Customer-representative testing and careful testing analysis assure that testing is effective at containing and preventing errors.
Outstanding: The organization has recognized software testing as a professional discipline and is a leader in the testing process and technology. Independent testing is used proactively to prevent the introduction of problems throughout the software life cycle. Innovative or world class leadership is demonstrated in this area.
Source: Motorola Corporate Quality System Review Guidelines, November 1992
TRAINING MATERIALVSI Inc. 20
Independent Testing – Time UsageIndependent Testing – Time Usage
SupplementarySlide
50% digging 25% test design & execution
25% Other
Independent Test Group – Time Usage
Source: Software Testing Techniques, Boris Beizer
TRAINING MATERIALVSI Inc. 21
I.3 > I.3.2. Tổ chức nhóm tester theo dự ánI.3 > I.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”
TRAINING MATERIALVSI Inc. 22
I.3 > I.3.3. Vai trò của test leaderI.3 > I.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.
TRAINING MATERIALVSI Inc. 23
I.3 > I.3.3. Vai trò của testerI.3 > I.3.3. 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
TRAINING MATERIALVSI Inc. 24
Tóm tắt I.3Tóm tắt I.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.
TRAINING MATERIALVSI Inc. 26
I.1. Mục đích của testing I.2. Mô hình chữ V I.3. Vai trò của các tester I.4. Các khái niệm phân loại test I.5. Test thế nào cho đủ I.6. Các tài liệu test
Nội dung phần INội dung phần I
TRAINING MATERIALVSI Inc. 27
I.4. Các khái niệm phân loại testI.4. Các khái niệm phân loại test
I.4.1. Testing approaches: các phương pháp test
I.4.2. Testing stages: các giai đoạn test I.4.3. Testing types: các thể loại test I.4.4. Testing techniques: các kỹ thuật test
TRAINING MATERIALVSI Inc. 28
I.4 > I.4.1. Testing approachesI.4 > I.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
OUTPUTINPUT
OUTPUT
TRAINING MATERIALVSI Inc. 29
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
Code Developers
Independent Test Group
Unit TestingIntegration
Testing System Testing
TRAINING MATERIALVSI Inc. 30
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
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
TRAINING MATERIALVSI Inc. 31
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
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.
TRAINING MATERIALVSI Inc. 32
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
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
TRAINING MATERIALVSI Inc. 33
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
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.
TRAINING MATERIALVSI Inc. 34
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
Requirements cho System testing: System Requirements Specification Interface Specifications Users Guide Use Cases Customers Domain Experts Bug Data Re-engineering
TRAINING MATERIALVSI Inc. 35
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
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.
TRAINING MATERIALVSI Inc. 36
I.4 > I.4.2. Testing stagesI.4 > I.4.2. Testing stages
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 SystemAfter Modification
Actual bug distribution after modifications are made.
Regression bug
TRAINING MATERIALVSI Inc. 37
I.4 > I.4.3. Testing typesI.4 > I.4.3. Testing types
Quality dimensions Functionality
Usability
Reliabilty
Testing types• Function test• Security test• Volume test
• Usability test
• Integrity test• Structure test• Stress test
Stages applied All stages All stages
System testing
System testing
TRAINING MATERIALVSI Inc. 38
I.4 > I.4.3. Testing typesI.4 > I.4.3. Testing types
Quality dimensions Performance
Supportability
Testing types• Benchmark test• Contention test• Load test• Performance
profile
• Configuration test
• Installation test
Stages applied
System testing
System testing
TRAINING MATERIALVSI Inc. 39
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.1. Equivalence class partitioning I.4.4.2. Control flow testing I.4.4.3. Data flow testing I.4.4.4. Transaction testing I.4.4.5. Domain testing I.4.4.6. Loop testing I.4.4.7. Syntax testing I.4.4.8. State machine testing I.4.4.9. Load and stress testing
TRAINING MATERIALVSI Inc. 40
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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,…)
TRAINING MATERIALVSI Inc. 41
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.1. Equivalence class partitioning: ví dụ
Example program:
Begin Read
(AAAAAAAAAA) Print End
What are the equivalence classes?
TRAINING MATERIALVSI Inc. 42
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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
TRAINING MATERIALVSI Inc. 43
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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?
TRAINING MATERIALVSI Inc. 44
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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?
TRAINING MATERIALVSI Inc. 45
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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
TRAINING MATERIALVSI Inc. 46
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.2. Control flow testing Sơ đồ luồng xử lý
Process 1
Process 2
?Yes
No
Process 3
More Processing
TRAINING MATERIALVSI Inc. 47
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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.
TRAINING MATERIALVSI Inc. 48
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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
TRAINING MATERIALVSI Inc. 49
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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)
I.4.4.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
TRAINING MATERIALVSI Inc. 50
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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
TRAINING MATERIALVSI Inc. 51
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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• …
TRAINING MATERIALVSI Inc. 52
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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
TRAINING MATERIALVSI Inc. 53
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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.
TRAINING MATERIALVSI Inc. 54
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.8. State machine testing: phương phápVẽ một sơ đồ chuyển đổi trạng thái cho
đối tượng cần testPositive tests: thiết kế test cases cho từng
lần chuyển đổi trạng tháiNegative 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ệ
TRAINING MATERIALVSI Inc. 55
I.4 > I.4.4. Testing techniquesI.4 > I.4.4. Testing techniques
I.4.4.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
TRAINING MATERIALVSI Inc. 56
Tóm tắt I.4Tóm tắt I.4
Testing approaches: white box & black box Independent testing ở VSI 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, ở VSI, 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
TRAINING MATERIALVSI Inc. 58
I.1. Mục đích của testing I.2. Mô hình chữ V I.3. Vai trò của các tester I.4. Các khái niệm phân loại test I.5. Test thế nào cho đủ I.6. Các tài liệu test
Nội dung phần INội dung phần I
TRAINING MATERIALVSI Inc. 59
I.5. Test thế nào cho đủI.5. 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.
TRAINING MATERIALVSI Inc. 60
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
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?
TRAINING MATERIALVSI Inc. 61
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
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
TRAINING MATERIALVSI Inc. 62
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
Ư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.
TRAINING MATERIALVSI Inc. 63
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
Ư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, …
TRAINING MATERIALVSI Inc. 64
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
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à đủ.
…
TRAINING MATERIALVSI Inc. 65
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
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ế.
TRAINING MATERIALVSI Inc. 66
I.5. Test thế nào cho đủI.5. Test thế nào cho đủ
Đá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
TRAINING MATERIALVSI Inc. 68
I.1. Mục đích của testing I.2. Mô hình chữ V I.3. Vai trò của các tester I.4. Các khái niệm phân loại test I.5. Test thế nào cho đủ I.6. Các tài liệu test
Nội dung phần INội dung phần I
TRAINING MATERIALVSI Inc. 69
I.6. Các tài liệu testI.6. Các tài liệu test
Qui trình test
Test Planning
Test Specification
Test Reporting
Test Execution
Tài liệu test
Test Plan
Test Design Spec Test Design SpecTest
Design Spec
Test Case Spec Test Proc. Spec
Test Log
Test Evaluationreport
Test Result
TRAINING MATERIALVSI Inc. 70
I.6 > Test PlanI.6 > 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.
TRAINING MATERIALVSI Inc. 71
I.6 > Test PlanI.6 > Test Plan
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?
TRAINING MATERIALVSI Inc. 72
I.6 > Test PlanI.6 > Test Plan
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
TRAINING MATERIALVSI Inc. 74
I.6 > Test Design SpecI.6 > 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.
TRAINING MATERIALVSI Inc. 75
I.6 > Test Design SpecI.6 > Test Design Spec
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)
TRAINING MATERIALVSI Inc. 76
I.6 > Test Case SpecI.6 > 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.
TRAINING MATERIALVSI Inc. 77
I.6 > Test case specI.6 > Test case spec
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)
TRAINING MATERIALVSI Inc. 78
I.6 > Test Procedure SpecI.6 > 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.
TRAINING MATERIALVSI Inc. 79
I.6 > Test LogI.6 > 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.
TRAINING MATERIALVSI Inc. 80
I.6 > Test Result ReportI.6 > 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
TRAINING MATERIALVSI Inc. 81
I.6 > Test Result ReportI.6 > Test Result Report
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
TRAINING MATERIALVSI Inc. 82
I.6 > Test Result ReportI.6 > Test Result Report
Mẫu Test Result Report
TRAINING MATERIALVSI Inc. 83
I.6 > Test Release ReportI.6 > 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?
TRAINING MATERIALVSI Inc. 84
I.6 > Test Release ReportI.6 > Test Release Report
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,…
TRAINING MATERIALVSI Inc. 85
I.6 > Test Release ReportI.6 > Test Release Report
Mẫu Test Release Report
TRAINING MATERIALVSI Inc. 86
Tóm tắt I.6Tóm tắt I.6
TestPlan/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”.
TRAINING MATERIALVSI Inc. 88
Tài liệu tham khảoTài liệu tham khảo
Tài liệu tham khảo sử dụng Introduction To Software Testing And Quality Ass
urance, 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>
Testing ở Vietsoftware – phần II Testing ở Vietsoftware – phần II
Tác giả: Dương Thị MinhTác giả: Dương Thị Minh
Version: 1.0 Version: 1.0 Last Update: 12/04/2005Last Update: 12/04/2005
Người hướng dẫn: Dương Thị MinhQA Engineer
13, 15/04/2005
TRAINING MATERIALVSI Inc. 91
Nội dung khoá họcNội dung khoá học
Giới thiệu I. Nhập môntesting
Kiểm tra lý thuyết
II. Các kỹ năng thực hành
III. Testing checklists
Kiểm tra
0,5
14
1,5
1
1
IV. Kỹ năng cá nhân
1
TRAINING MATERIALVSI Inc. 92
Mục tiêu phần IIMục tiêu phần II
Kết thúc phần II – Các kỹ năng thực hành – học viên được rèn luyện: Mô tả và phân loại lỗi như thế nào? Sử dụng phần mềm ghi nhận và theo dõi lỗi (Trakium) ra sao? Lập các test case từ use case như thế nào? Khi một test case phải được thực hiện sau nhiều test case khác
có liên quan, thì làm thế nào để theo dõi chính xác luồng dữ liệu đã có để nhằm rút ra kết luận đúng về kết quả test case cuối cùng được thực hiện?
Làm thế nào để thực hiện test khi không có các tài liệu về phần mềm cần test, cũng không có tài liệu, kế hoạch test nào được chuẩn bị sẵn?
Nếu được tham gia dự án ngay từ giai đoạn lập requirements, tester nên làm gì?
Nên sắp xếp thứ tự test ra sao? Làm các test reports như nào?
TRAINING MATERIALVSI Inc. 93
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 94
II.1. Mô tả và phân loại lỗiII.1. Mô tả và phân loại lỗi
Làm gì ngay sau khi tìm thấy lỗi? Mô tả lỗi
Yêu cầu chung Các mục thông tin chi tiết
Phân loại lỗi Theo mức độ khẩn cấp (Priority) Theo mức độ ảnh hưởng (Severity)
TRAINING MATERIALVSI Inc. 95
Thực hành Mô tả và phân loại lỗiThực hành Mô tả và phân loại lỗi
Tình huống 1: Vào Quản lý
danh mục > Danh mục báo cáo
Hệ thống hiển thị danh sách tất cả các báo cáo hiện có
Click vào tiêu đề cột “Mẫu số báo cáo”
Thấy không có gì thay đổi cả
TRAINING MATERIALVSI Inc. 96
Thực hành Mô tả và phân loại lỗiThực hành Mô tả và phân loại lỗi
Tình huống 2: Vào Quản lý
danh mục > Danh mục báo cáo
Tạo mới một mẫu báo cáo:
Ngẫu nhiên nhập một tên báo cáo dài, nhấn Ghi lại.
Hệ thống báo lỗi
TRAINING MATERIALVSI Inc. 97
Thực hành Mô tả và phân loại lỗiThực hành Mô tả và phân loại lỗi
Tình huống 3: Qui tắc của hệ thống: Một NSD muốn cung cấp một báo
cáo mới thì phải:• Có quyền truy cập trang Cung cấp báo cáo• Thuộc một đơn vị có được gán quyền cung cấp một số báo
cáo• Mẫu báo cáo mà NSD định tạo mới phải đã được xác định kỳ
Đăng nhập hệ thống bằng một account hội đủ 02 điều kiện đầu, các báo cáo mà đơn vị của NSD này được gán là báo cáo A, báo cáo B, báo cáo C, báo cáo D
Vào form Quản lý báo cáo > Cung cấp thông tin báo cáo > Tạo mới
Thấy hệ thống báo lỗi: Bạn không thể Tạo mới báo cáo vì báo cáo A chưa được gán kỳ báo cáo.
TRAINING MATERIALVSI Inc. 98
Thực hành Mô tả và phân loại lỗiThực hành Mô tả và phân loại lỗi
Tình huống 4: Đăng nhập xong, thấy màn hình như sau:
TRAINING MATERIALVSI Inc. 99
Thực hành Mô tả và phân loại lỗiThực hành Mô tả và phân loại lỗi
Hãy Phát hiện vấn đề trong bản ghi lỗi sau: Tiêu đề: “Quản lý danh mục > Danh mục báo cáo > Tạo mới : Nên sửa
không cho phép hiển thị tên báo cáo quá dài.” Mô tả: “Hệ thống cho phép NSD nhập tên báo cáo quá dài, hiển thị toàn
bộ ký tự NSD đã nhập ==> Làm biến dạng cột " Tên báo cáo" trên màn hình hiển thị toàn bộ record. Hệ thống nên sửa không cho phép hiển thị tên báo cáo dài quá độ dài quy định.”
TRAINING MATERIALVSI Inc. 100
Thực hành Mô tả và phân loại lỗiThực hành Mô tả và phân loại lỗi
Hãy Phát hiện vấn đề trong bản ghi lỗi sau: Tiêu đề: Quản lý số liệu kế hoạch > Phân bổ, điều chỉnh kế
hoạch theo đơn vị > Chọn "Điều chỉnh" trong combobox > Điều chỉnh: Chưa xử lý được kiểu dữ liệu nhập vào.
Mô tả:Chưa xử lý được kiểu dữ liệu nhập vào. Giống như trong mục điều chỉnh của "Phân bổ và điều chỉnh theo chỉ tiêu". Trường hợp TEST:
1. Vào "Quản lý số liệu kế hoạch">"Phân bổ, điều chỉnh kế hoạch theo đơn vị">Chọn "Điều chỉnh".
2. Trên form Phân bổ, điều chỉnh theo đơn vị, gõ dữ liệu âm vào và ghi lại mà vẫn chấp nhận.
3. Tương tự gõ các ký tự đặc biệt vào thì hiện ra một trang lỗi.=>Cấn Check lại kiểu dữ liệu nhập vào.
TRAINING MATERIALVSI Inc. 101
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 102
II.2. Sử dụng TrakiumII.2. Sử dụng Trakium
Cài đặt Vòng đời của một lỗi và những NSD liên
quan Nhập lỗi mới Theo dõi danh sách lỗi Tìm kiếm lỗi Xem các báo cáo thống kê
TRAINING MATERIALVSI Inc. 103
II.2 > Cài đặt TrakiumII.2 > Cài đặt Trakium
Account
http://qaserver2000/trakium Trakium Client
Win98/2000
WinXP/2003
TRAINING MATERIALVSI Inc. 104
II.2 > Vòng đời của một lỗiII.2 > Vòng đời của một lỗi
Open
Fixed
Rejected
ClosedRejected - Closed
Suspend
TRAINING MATERIALVSI Inc. 105
II.2. Sử dụng TrakiumII.2. Sử dụng Trakium
Cài đặt Vòng đời của một lỗi và những NSD liên
quan Nhập lỗi mới Theo dõi danh sách lỗi Tìm kiếm lỗi Xem các báo cáo thống kê
TRAINING MATERIALVSI Inc. 106
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 107
II.3. Lập test cases từ use caseII.3. Lập test cases từ use case
Mô tả requirement bằng use case Lập test cases từ use case
TRAINING MATERIALVSI Inc. 108
II.3 > Mô tả Rqm bằng use caseII.3 > 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)
TRAINING MATERIALVSI Inc. 109
II.3 > Mô tả Rqm bằng use caseII.3 > Mô tả Rqm bằng use case
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
TRAINING MATERIALVSI Inc. 110
II.3 > Lập test cases từ use caseII.3 > Lập test cases từ use case
Mô hình luồng các sự kiện trong một use case
TRAINING MATERIALVSI Inc. 111
II.3 > Lập test cases từ use caseII.3 > Lập test cases từ use case
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.
TRAINING MATERIALVSI Inc. 112
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 113
II.4. Phân tích dữ liệu giả địnhII.4. Phân tích dữ liệu giả định
Lập test procedure cho nhiều test case Sử dụng Excel
TRAINING MATERIALVSI Inc. 114
Thực hành Phân tích DL giả địnhThực hành Phân tích DL giả định
Trở lại Bài tập tình huống 3 Hãy hình dung thứ tự các test case mà bạn sẽ
thực hiện? Thực hành với một hệ thống sinh ra các
bảng số liệu báo cáo: ..\Exercises\DLgiadinh.xls
TRAINING MATERIALVSI Inc. 115
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 116
II.5. Test chayII.5. Test chay
Test chay là gì? Khi nào chấp nhận test chay? Làm gì để test chay có hiệu quả?
TRAINING MATERIALVSI Inc. 117
II.5. Test chayII.5. Test chay
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
TRAINING MATERIALVSI Inc. 118
II.5. Test chayII.5. Test chay
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
TRAINING MATERIALVSI Inc. 119
II.5. Test chayII.5. Test chay
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
TRAINING MATERIALVSI Inc. 120
II.5. Test chayII.5. Test chay
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ó
TRAINING MATERIALVSI Inc. 121
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 122
II.6. Chuẩn bị test ngay từ đầuII.6. Chuẩn bị test ngay từ đầu
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
TRAINING MATERIALVSI Inc. 123
II.1. Mô tả và phân loại lỗi II.2. Sử dụng Trakium II.3. Lập các test case từ use case II.4. Phân tích dữ liệu giả định II.5. Test chay II.6. Chuẩn bị test ngay từ đầu dự án II.7. Lập các test reports
Nội dung phần IINội dung phần II
TRAINING MATERIALVSI Inc. 124
II.7. Lập các test report II.7. Lập các test report
Lập test result report cho từng phân hệ được test
Lập test evaluation report Lập các thông báo, report khác tuỳ nhu cầu
TRAINING MATERIALVSI Inc. 126
Tài liệu tham khảoTài liệu tham khảo
Tài liệu tham khảo sử dụng Introduction To Software Testing And Quality Ass
urance, 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>