Kiểm thử là một trong những công đoạn không thể thiếu trong phát triển phần mềm. Mặc dù kiểm thử thủ công vẫn còn được áp dụng rộng rãi, tuy nhiên nó lại có thể tốn nhiều thời gian và công sức, đặc biệt đối với các dự án Agile hiện tại với các tính năng được bổ sung sau mỗi vòng phát triển. Do đó, trang bị cho mình kiến thức về kiểm thử tự động là một điều không thể thiếu đặc biệt là đối với các tester muốn nâng cao khả năng, hoặc developer đang có ý tưởng áp dụng cho dự án của mình.
Một số lợi ích có thể kể đến của kiểm thử tự động là:
- Giúp tiết kiệm tiền bạc và thời gian: nhất là trong giai đoạn bảo trì của các dự án lớn. Mỗi tuần chúng ta phải thực hiện regression test từ 1 đến 2 lần với số lượng test case rất lớn trong 1 đến 2 ngày. ĐIều này gần như không thể thực hiện bằng cách thủ công, trong khi với kiểm thử tự động chúng ta hoàn toàn có thể với nguồn nhân lực vô cùng khiêm tốn.
- Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test case với độ chính xác cao hơn.
- Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử tự động, chúng ta có thể thực thi số lượng lớn test case trong một thời gian ngắn. Nên độ bao phủ của nó rất cao. Điều này giúp chúng ta tăng độ bao phủ trong giai đoạn regression test .
- Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất.
Trong meetup tháng 12 này, diễn giả Phạm Tiến Hùng - VNPTDATA sẽ chia sẻ với các bạn về kiểm thử tự động cùng với 2 công cụ kiểm thử tự động là Selenium và Katalon Studio, phù hợp áp dụng cho những team với tester chưa có nhiều kỹ năng về lập trình hoặc đã có kỹ năng.
Thông tin diễn giả: Phạm Tiến Hùng - Teamlead, VNPT DATA.
Nội dung:
1. Giới thiệu về kiểm thử tự động
2. Bắt đầu với kiểm thử tự động
3. Giới thiệu công cụ kiểm thử tự động
Kiểm thử là một trong những công đoạn không thể thiếu trong phát triển phần mềm. Mặc dù kiểm thử thủ công vẫn còn được áp dụng rộng rãi, tuy nhiên nó lại có thể tốn nhiều thời gian và công sức, đặc biệt đối với các dự án Agile hiện tại với các tính năng được bổ sung sau mỗi vòng phát triển. Do đó, trang bị cho mình kiến thức về kiểm thử tự động là một điều không thể thiếu đặc biệt là đối với các tester muốn nâng cao khả năng, hoặc developer đang có ý tưởng áp dụng cho dự án của mình.
Một số lợi ích có thể kể đến của kiểm thử tự động là:
- Giúp tiết kiệm tiền bạc và thời gian: nhất là trong giai đoạn bảo trì của các dự án lớn. Mỗi tuần chúng ta phải thực hiện regression test từ 1 đến 2 lần với số lượng test case rất lớn trong 1 đến 2 ngày. ĐIều này gần như không thể thực hiện bằng cách thủ công, trong khi với kiểm thử tự động chúng ta hoàn toàn có thể với nguồn nhân lực vô cùng khiêm tốn.
- Chính xác hơn: Nhờ độ ổn định cao, kiểm thử tự động có thể thực thi các test case với độ chính xác cao hơn.
- Độ bao phủ cao: Như đã nói ở trên, khi sử dụng kiểm thử tự động, chúng ta có thể thực thi số lượng lớn test case trong một thời gian ngắn. Nên độ bao phủ của nó rất cao. Điều này giúp chúng ta tăng độ bao phủ trong giai đoạn regression test .
- Hoàn thành các công việc mà con người không thể làm được: Nếu chúng ta muốn thực thi load test, performance test, thì kiểm thử tự động là cách duy nhất.
Trong meetup tháng 12 này, diễn giả Phạm Tiến Hùng - VNPTDATA sẽ chia sẻ với các bạn về kiểm thử tự động cùng với 2 công cụ kiểm thử tự động là Selenium và Katalon Studio, phù hợp áp dụng cho những team với tester chưa có nhiều kỹ năng về lập trình hoặc đã có kỹ năng.
Thông tin diễn giả: Phạm Tiến Hùng - Teamlead, VNPT DATA.
Nội dung:
1. Giới thiệu về kiểm thử tự động
2. Bắt đầu với kiểm thử tự động
3. Giới thiệu công cụ kiểm thử tự động
Nhận viết luận văn đại học, thạc sĩ trọn gói, chất lượng, LH ZALO=>0909232620
Tham khảo dịch vụ, bảng giá tại: https://vietbaitotnghiep.com/dich-vu-viet-thue-luan-van
Download luận văn đồ án tốt nghiệp ngành công nghệ thông tin với đề tài: Kiểm thử phần mềm trên thiết bị di động và ứng dụng phần mềm Appium Studio cho ứng dụng trên IOS, cho các bạn làm luận văn tham khảo
Kiểm chứng phần mềm
Quy trình làm phần mềm
Quy trình xây dựng Test Plan
------------------------------------------------------------------------
Programer C++
Training C/C++, Java
Game Mobile (Android - iOS - Winphone)
Info: https://www.facebook.com/hoclaptrinh.it
------------------------------------------------------------------------
This document provides instructions and questions for a 50 question, 37.5 minute sample exam for the CAST Certified Associate in Software Testing certification. The exam covers topics such as software testing techniques, metrics, defect management, quality assurance, and Agile methodologies. It tests knowledge in areas like test planning, automation, risk analysis, and new technologies including virtualization, the Internet of Things, and DevOps.
The test manager decided to review and update the test policy and procedures for a new project managing hospital pharmacy inventories using software previously used for library management. Different industries have different risks and quality requirements, which impacts the test process.
A QA manager of a startup needs a low-cost incident management tool to implement within a week. Managing incidents through emails and phone calls would be the best low-cost option.
Age groups for a welcome screen on a software system are 0-12, 13-18, and over 18. The boundary values representing these groups are -1, 0, 12, 13, 18, and 19.
The document contains questions about software testing concepts and techniques. It asks about risk analysis in testing, suitable testing techniques for computerized elevators, integration testing approaches, goals of performance testing tools, goals of risk management, outcomes that increase software quality, characteristics of different test types like system and acceptance testing, objectives of defect reports, test case generation alignment with risk analysis, tasks of a test leader, black box testing techniques, inspection processes, test case generation for equivalence classes, coverage criteria, non-functional testing characteristics, tools for test results and reports, entry level tester tasks, coverage for state transition tests, characteristics of experience based techniques, boundary value analysis, missing details in an incident report, test cases required for statement and branch coverage
Nhận viết luận văn đại học, thạc sĩ trọn gói, chất lượng, LH ZALO=>0909232620
Tham khảo dịch vụ, bảng giá tại: https://vietbaitotnghiep.com/dich-vu-viet-thue-luan-van
Download luận văn đồ án tốt nghiệp ngành công nghệ thông tin với đề tài: Kiểm thử phần mềm trên thiết bị di động và ứng dụng phần mềm Appium Studio cho ứng dụng trên IOS, cho các bạn làm luận văn tham khảo
Kiểm chứng phần mềm
Quy trình làm phần mềm
Quy trình xây dựng Test Plan
------------------------------------------------------------------------
Programer C++
Training C/C++, Java
Game Mobile (Android - iOS - Winphone)
Info: https://www.facebook.com/hoclaptrinh.it
------------------------------------------------------------------------
This document provides instructions and questions for a 50 question, 37.5 minute sample exam for the CAST Certified Associate in Software Testing certification. The exam covers topics such as software testing techniques, metrics, defect management, quality assurance, and Agile methodologies. It tests knowledge in areas like test planning, automation, risk analysis, and new technologies including virtualization, the Internet of Things, and DevOps.
The test manager decided to review and update the test policy and procedures for a new project managing hospital pharmacy inventories using software previously used for library management. Different industries have different risks and quality requirements, which impacts the test process.
A QA manager of a startup needs a low-cost incident management tool to implement within a week. Managing incidents through emails and phone calls would be the best low-cost option.
Age groups for a welcome screen on a software system are 0-12, 13-18, and over 18. The boundary values representing these groups are -1, 0, 12, 13, 18, and 19.
The document contains questions about software testing concepts and techniques. It asks about risk analysis in testing, suitable testing techniques for computerized elevators, integration testing approaches, goals of performance testing tools, goals of risk management, outcomes that increase software quality, characteristics of different test types like system and acceptance testing, objectives of defect reports, test case generation alignment with risk analysis, tasks of a test leader, black box testing techniques, inspection processes, test case generation for equivalence classes, coverage criteria, non-functional testing characteristics, tools for test results and reports, entry level tester tasks, coverage for state transition tests, characteristics of experience based techniques, boundary value analysis, missing details in an incident report, test cases required for statement and branch coverage
2014/07/07 Software Testing - Truong Anh Hoang Vu Hung Nguyen
Topics:
1. Sharing experience on software testings
2. Automation testing for web application
3. Testing techniques: Tips and tricks (for webapp)
4. How to plan testing, how to write effective test cases so that we can find more bugs
5. What is BDD and how to apply it software testing
6. The importance of developer testing (testing by developers)
Contents
Kỹ thuật kiểm thử - tips & tricks
- Hộp đen - tester
- Hộp trắng - developer testing
- Kiểm thử đơn vị - automation, developer testing
Kiểm thử web - webapp
- Demo
- Kinh nghiệm tự động với selenium - tips, automation,
Phát triển theo hành vi - BDD
- Giới thiệu BDD (behaviour driven development)
- Demo behat
Test planning is the process of defining and documenting the strategy to verify that a product meets its requirements. A test plan should be created by quality management and answer questions like how, who, what, how long, and test coverage level required. According to IEEE standards, a test plan includes items like test plan identifier, introduction, features to be tested, approach, pass/fail criteria, responsibilities, and schedule. A test design specification describes features to be tested and specifies test scenarios/cases to provide software testing. Test design techniques include static techniques like reviews and dynamic techniques like structure-based, experience-based, and specification-based approaches. Choosing the right technique depends on factors like tester knowledge, expected defects, test objectives,
The document discusses the history and development of a new technology called blockchain. Blockchain was originally developed for the digital currency Bitcoin as a way to record transactions in a secure, decentralized manner without the need for a central authority. It has since been applied to other uses like digital identity, banking, and more due to its ability to securely and immutably store data and transactions.
Ebook Big Step Toeic 1 được chia sẻ bởi website tuhoctoeic.edu.vn.
Mọi chi tiết xin liên hệ :
TT ANH NGỮ BALO ENGLISH
Web: http://baloenglish.vn/
http://tuhoctoeic.edu.vn
Mail: baloenglish@gmail.com
Facebook: https://www.facebook.com/BaloEnglish
Địa chỉ: 207/49 đường 3/2, P11, Q10, TP.HCM.
Website: http://amasuite-reviews.info/wp/
Amasuite Reviews tell you what could Amasuite help you to promote your products and increase your passive income dramatically in a very short time. Check it out to get more information and receive huge bonus worth over $1400. Volume is limited. So quickly before expired.
This document outlines the schedule and objectives for a 5-day training seminar on web services with JAX-WS and JAX-RS given in Athens, Greece in February 2016. The seminar objectives are to teach how to use Java web service stacks, provide updates on modern Java technology, offer proven patterns from real projects, and propose new tools. Each day covers 3-4 topics, with both theory and hands-on lab exercises. Day 1 covers SOAP web services and clients. Day 2 focuses on JAX-WS services. Day 3 is on REST and JAX-RS. Day 4 addresses error handling and security. Day 5 covers performance, testing, and high availability.
The document provides advice and reflections on life and strategy. It encourages focusing on global society, maintaining balance, and surrounding oneself with helpful friends and family. It also recommends practicing laughter, saying yes to opportunities, following your heart, making decisions based on needs rather than trends, and constantly learning through training and openness to change.
Nhận viết luận văn đại học, thạc sĩ trọn gói, chất lượng, LH ZALO=>0909232620
Tham khảo dịch vụ, bảng giá tại: https://baocaothuctap.net
Download luận văn tóm tắt ngành khoa học máy tính với đề tài: Xây dựng công cụ sinh dữ liệu thử tự động cho chương trình Java, cho các bạn làm luận văn tham khảo
Giải Ngân Hàng Đảm Bảo Chất Lượng Phần Mềm PTIT SQA PTIT Để tránh trường hợp mua bán bất hợp pháp và lừa đảo file pdf cho sinh viên PTIT. Sân chơi giới trẻ đã tổng hợp, bổ sung các tài liệu cần thiết cho các con vợ! Hãy like, share để ủng hộ chúng tôi! #ptit #sqa
1. Testing ở Vietsoftware
Tác giả: Dương Thị Minh
Version: 1.0
Last Update: 02/04/2005
Người hướng dẫn: Dương Thị Minh
QA Engineer
04-06/04/2005
2. Nội dung khoá học
Giới thiệu
0,5
II. Các kỹ
năng thực
hành
4
I. Nhập môn
testing
III. Testing
checklists
1,5
Kiểm tra lý
thuyết
1
Kiểm tra
1
IV. Kỹ năng cá
nhân
1
1
3. Mụ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ó?
4. Nội dung phần I
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
5. I.1. Mục đích của testing
Testing là gì?
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!”?
6. I.1. Mục đích của testing
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!
7. I.1. Mục đích của testing
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
8. I.1. Mục đích của testing
Đặc điểm 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!
9. I.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!
10. Tó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.
12. Nội dung phần I
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
13. I.2. Mô hình chữ V
Software
Development Phases
Test Planning Phase
Test Execution Phase
Software V&V
Plan
Project Plan
Install
Acceptance
Demonstration
Acceptance
Demonstration
Plan
Requirements
Spec
System Test
Plan
Architectural
Design Spec
Detailed
Design Spec
Integration
Test Plan
Unit Test
Plan
System
Test
Integration
Test
Unit
Test
Code
Theo “Strategies for Effective Software Testing”, Jessee Ring, Software Quality First liên kết với Alliant, tháng 8 2004
14. I.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.
15. Nội dung phần I
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
16. I.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
17. I.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
18. Supplementary
Slide
Independent Testing - Considerations
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
19. Supplementary
Slide
Independent Test Group - Evaluation
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
20. Supplementary
Slide
Independent Testing – Time Usage
Independent Test Group – Time Usage
50% digging
25% test
design &
execution
25% Other
Source: Software Testing Techniques, Boris Beizer
21. I.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”
22. I.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.
23. I.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
24. Tó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.
26. Nội dung phần I
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
27. I.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
28. I.4 > I.4.1. Testing approaches
INPUT
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
OUTPUT
29. I.4 > I.4.2. Testing stages
Unit Testing
Code
Developers
Independent
Test Group
Integration
Testing
System Testing
30. I.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
31. I.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.
32. I.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.
Send a parameter
Action:
Display
message
Acknowledge
Module
or subsystem
Module
or subsystem
33. I.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.
34. I.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
35. I.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.
36. I.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
Regression
bug
Software System
After Modification
Actual bug distribution after
modifications are made.
37. I.4 > I.4.3. Testing types
Quality dimensions
Testing types
Stages applied
Function test
Security test
Volume test
•
Functionality
•
Usability test
System
testing
•
Integrity test
Structure test
Stress test
System
testing
•
•
All stages
All stages
Usability
Reliabilty
•
•
38. I.4 > I.4.3. Testing types
Quality dimensions
Performance
Testing types
•
•
•
•
Supportability
•
•
Benchmark test
Contention test
Load test
Performance
profile
Configuration test
Installation test
Stages applied
System testing
System testing
39. I.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
40. I.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,…)
41. I.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?
42. I.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
43. I.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?
44. I.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?
45. I.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
46. I.4 > I.4.4. Testing techniques
I.4.4.2. Control flow testing
Process 1
Sơ đồ luồng xử lý
?
Yes
No
Process 2
More
Processing
Process 3
47. I.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.
48. I.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
49. I.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
50. I.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
51. I.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
…
52. I.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
53. I.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.
54. I.4 > I.4.4. Testing techniques
I.4.4.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ệ
55. I.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
56. Tó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
58. Nội dung phần I
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
59. 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.
60. 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?
61. 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
62. 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.
63. 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, …
64. 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à đủ.
…
65. 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ế.
66. 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
68. Nội dung phần I
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
69. I.6. Các tài liệu test
Qui trình test
Tài liệu test
Test Plan
Test Planning
Test Specification
Test Design Spec
Test Design Spec
Test Case Spec
Test
Design Spec
Test Proc. Spec
Test Execution
Test Log
Test Reporting
Test Result
Test Evaluation
report
70. I.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.
71. I.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?
72. I.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
74. I.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.
75. I.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)
76. I.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.
77. I.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)
78. I.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.
79. I.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.
80. I.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
81. I.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
82. I.6 > Test Result Report
Mẫu Test Result Report
83. I.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?
84. I.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,…
85. I.6 > Test Release Report
Mẫu Test Release Report
86. Tóm tắt I.6
• Xác định môi trường và các test cases
sẽ thực hiện.
Test
Plan/Design
• Chỉ ra khối lượng test sẽ thực hiện.
• Giúp xác định được khi nào “test
xong”.
• Báo cáo kết quả test thực sự, đối
chiếu với test plan.
Test Report
• Đư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.
88. 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>
90. Testing ở Vietsoftware – phần II
Tác giả: Dương Thị Minh
Version: 1.0
Last Update: 12/04/2005
Người hướng dẫn: Dương Thị Minh
QA Engineer
13, 15/04/2005
91. Nội dung khoá học
Giới thiệu
0,5
II. Các kỹ
năng thực
hành
4
I. Nhập môn
testing
III. Testing
checklists
1,5
Kiểm tra lý
thuyết
1
Kiểm tra
1
IV. Kỹ năng cá
nhân
1
1
92. Mụ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?
93. Nội dung phần II
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
94. II.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)
95. Thự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ả
96. Thự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
97. Thự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.
98. Thự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:
99. Thự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.”
100. Thự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.
101. Nội dung phần II
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
102. II.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ê
104. II.2 > Vòng đời của một lỗi
Open
Fixed
Rejected
Closed
Rejected
- Closed
Suspend
105. II.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ê
106. Nội dung phần II
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
107. II.3. Lập test cases từ use case
Mô tả requirement bằng use case
Lập test cases từ use case
108. II.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)
109. II.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
110. II.3 > Lập test cases từ use case
Mô hình luồng các sự kiện trong một use case
111. II.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.
112. Nội dung phần II
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
113. II.4. Phân tích dữ liệu giả định
Lập test procedure cho nhiều test case
Sử dụng Excel
114. Thự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: ..ExercisesDLgiadinh.xls
115. Nội dung phần II
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
116. II.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ả?
117. II.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
118. II.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
119. II.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
120. II.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ó
121. Nội dung phần II
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
122. II.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
123. Nội dung phần II
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
124. 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
126. 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>