1. Testing là gì
Là quá trình thực hiện một chương trình (hay một phần của một chương trình) để tìm ra lỗi
Là pha quan trọng trong quá trình phát triển hệ thống giúp cho người xây dựng hệ thống và khác hàng đã thấy được hệ thống mới đã thoả mãn yêu cầu đề ra chưa
Test phần mềm là vấn đề kỹ thuật thách thức hơn cả việc xây dựng phần mềm

2. Tầm quan trọng của nó đối với ngành phần mềm
Một phần mềm được làm ra không ai có thể đảm bảo nó không có lỗi
Testing sẽ tìm và phát hiện lỗi (mang tính ứng dụng hoặc thậm chí mang tính công nghệ) với mục đích cuối cùng là bảo đảm sản phẩm đến tay người dùng phải là tốt nhất, nhanh nhất, ổn định nhát
Hoạch định chiến lược nghiên cứu và ứng dụng, đảm bảo sp làm ra đạt tiêu chí và kỹ thuật đề ra
Ghi nhận các ý kiến, đề xuất hoặc báo cáo hỏng hóc từ người dùng

3. Các phương pháp testing
Black box test
White box test

4. Black-box Test – Khái niệm
Black box test: hay còn gọi là test hộp đen
Test dựa trên hoạt động của chức năng, không đòi hỏi kiến thức về các mã phần mềm hoặc cấu trúc
Phương pháp này quan tâm tới việc thực hiện các chức năng (hành vi), dữ liệu đầu vào và kết quả đầu ra ra sao  fải chuẩn bị và sử dụng các khả năng có thể xảy ra của dữ liệu Input

5. Black-box Test – Phương pháp
Để thực hiện phương pháp này cần dựa trên:
Yêu cầu của phần mềm
Các trạng thái
Các trường hợp sử dụng (use case)
Kiểm tra các giá trị biên
Phân lớp tương đương
Test cú pháp
Test luồng dữ liệu (dữ liệu được lấy từ đặc tả yêu cầu)

6. White box Test – Khái niệm
Quan tâm tới cấu trúc và logic bên trong của đoạn mã.  cần có kiến thức về cấu trúc phần mềm
Được định nghĩa bởi:
Programming style
Control method
Language
Database design
Coding details

7. White box Test – Kỹ thuật
Test cấu trúc
Test nhánh
Luồng dữ liệu test
Test điều kiện nhánh
Test điều kiện nhánh tích hợp
Test các điều kiện thay đổi

8. Các giai đoạn test Code Software Development Phases
Software V&V
Plan
System Test
Integration
Test Plan
Unit Test
Acceptance
Demonstration
Software
Development Phases
Test Planning Phase
Test Execution Phase
Project Plan
Requirements
Spec
Architectural
Design Spec
Code
System
Test
Install
Unit
Detailed

9. Các giai đoạn test Unit Test Intergration Test System Test
Acceptance Test

10. Unit Test – Khái niệm
Một Unit là thành phần nhỏ nhất của phần mềm, như là: Function, Procedure, Class, Method
Là kỹ thuật kiểm nghiệm các hoạt động của mọi chi tiết mã với một quy trình tách biệt với QT PTPM giúp phát hiện sai sót kịp thời trước khi đưa ra test

11. Unit Test – Đặc điểm Test ở mức thấp nhất
Sử dụng phương pháp test hộp trắng
Kiểm tra độc lập từng thành phần
Thường được thực hiện bởi lập trình viên
Có giá trị khi phát hiện các vấn đề tiềm ẩn hoặc lỗi kỹ thuật

12. Intergration test – Khái niệm
Là test kết hợp các thành phần của một ứng dụng và kiểm tra như một ứng dụng đã hoàn thành
Mục đích
Phát hiện lỗi giao tiếp xảy ra giữa các Unit
Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ và cuối cùng là nguyên hệ thống hoàn chỉnh

13. Intergration test - Type
Kiểm tra cấu trúc (structure): Tương tự White Box Test, chú trọng đến hoạt động của các thành phần cấu trúc nội tại của chương trình
Kiểm tra chức năng (functional): Tương tự Black Box Test, chỉ khảo sát chức năng của chương trình theo yêu cầu kỹ thuật
Kiểm tra hiệu năng (performance): Kiểm tra vận hành của hệ thống
Kiểm tra khả năng chịu tải (stress): Kiểm tra giới hạn của hệ thống

14. Intergration test - Plan
Cần được thực hiện tương đương với giai đoạn thiết kế kiến trúc
Thứ tự tích hợp được xác định theo thứ tự xây dựng
Các thành phần hoàn thành đúng thời hạn
Phát triển các thành phần và test tích hợp được thực hiện song song

15. Intergration - Guidelines
Mỗi thành phần sẽ được tích hợp 1 lần
(tích hợp theo hướng tăng dần
Baseline 0: test thành phần
Baseline 1: 2 thành phần
Baseline 2: 3 thành phần)
Tích hợp từng mục nhỏ của từng thành phần tại một thời điểm
Các thành phần chính hoặc thành phần có khả năng nhiều lỗi
Kết hợp các thành phần liên quan đơn giản

16. Intergration-Approaches
Top-down
Bottom-down
Big-bang

17. Intergration-Approaches
Top-Down
Các module cấp trên được kiểm thử trước
Baselines:
baseline 0: component a
baseline 1: a + b
baseline 2: a + b + c
baseline 3: a + b + c + d
Etc… a b c d e f g h i j k l m n o a b c d e f g h i j

18. Intergration-Approaches
Ưu điểm Top-down
Phát hiện sớm các lỗi thiết kế
Có phiên bản hoạt động sớm
Nhược điểm
Khó có thể mô phỏng được các chức năng của module cấp thấp phức tạp
Không kiểm thử đầy đủ các chức năng

19. Intergration-Approaches
Bottom-up
Các module cấp thấp được kiểm tra trước a b c d e f g h i j k l m n o a b c d
Baselines:
baseline 0: component
baseline 1: n + i
baseline 2: n + i + o
baseline 3: n + i + o + d
Etc. e f g h i j

20. Intergration-Approaches
Ưu điểm Bottom-up
Thuận tiện cho phát triển các mô đun thứ cấp dùng lại được
Nhược điểm
Phát hiện chậm các lỗi thiết kế
Chậm có phiên bản thực hiện được của hệ thống

21. Intergration-Approaches
Big-bang
Tất cả các module được kết hợp trong 1 bước
Là phương pháp tích hợp thông thường
Là phương pháp ít hiệu quả nhất
Hạn chế dùng Big-bang
Rất khó tìm ra nguồn gốc của vấn đề
Không biết nơi nào để xem xét
Không ngoại trừ recommended cho các hệ thống rất nhỏ

22. System test – Khái niệm
Là kiểm tra thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không
Là Black box test
Được thực hiện độc lập bởi một nhóm test (test hệ thống)

23. System test – Khái niệm Về chức năng, thỏa mãn:
Requirements-based testing
Các yêu cầu là điều kiện đầu tiên cho việc test
Phân tích rủi ro để xác định thành phần quan trọng nhất
Business process-based testing
Người sử dụng mong đợi: cái gì được sử dụng thường xuyên và quan trọng nhất cho việc kinh doanh
Thực hiện các giao dịch kinh doanh qtrọng

24. System test – Khái niệm Yêu cầu phi chức năng: Usability Security
Storage
Volume
Configuration/installation
Reliability/qualities
Back-up/recovery
Performance, load, stress
Functional

25. Acceptance test
Được thực hiện sau giai đoạn System test, do khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ 3 thực hiện)
Mục đích: chứng minh phần mềm thỏa mãn tất cả các yêu cầu của khách hàng
Đối với những PM bán rộng rãi trên thị trường, cần thực hiện: Alpha test và Beta Test

26. Acceptance test
Alpha test: người sử dụng kiểm tra phần mềm ngay tại nơi PTPM, lập trình viên ghi nhận lỗi hoặc phản hồi và lên kế hoạch sửa chữa
Beta test: PM được gửi tới cho người sử dụng để kiểm tra ngay trong môi trường thực, lỗi, hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa

27. Process Test
Test
Planning
Specification
Reporting

28. Đầu vào/ đầu ra cho testing
Yêu cầu của khách hàng, các tiêu chuẩn
Các yêu cầu thay đổi
SRS
Tài liệu thiết kế (ADD, DDD)
Chương trình
Đầu ra
Tài liệu: test plan, test case và procedures
List lỗi
Báo cáo test

29. Test Plan Khái niệm
Mô tả các module cần kiểm tra, phương pháp kiểm tra (black box hoặc white box)
Xác định các yêu cầu dựa trên các yêu cầu người dùng
Xác định chiến lược test: test type, stage, tools
Xác định nguồn lực và trách nhiệm, xác định hệ thống (phần cứng, phần mềm)
Xác định những yêu tố, module quan trọng

30. Test Plan-Hoạt động Phạm vi test: Trạng thái và loại test?
Xác định yêu cầu cho test: Test sẽ làm gì?
Xác định chiến lược test: Thực hiện như thế nào?
Xác định nguồn lực và môi trường
Lập lịch trình Test.
Tổng hợp thông tin, lập kế hoạch Test
Xem xét và thông qua kế hoạch Test.
Tiêu chuẩn hoàn thành.
Công cụ sẽ sử dụng để Test
Đánh giá rủi ro và lập mức độ rủi ro cho các yêu cầu.
Chuyển giao test.

31. Test Plan – Nội dung Định nghĩa tài liệu Giới thiệu Test các mục nhỏ
Các đặc trưng cần test
Đưa ra các phương pháp
Đưa ra các tiêu chuẩn đánh giá một mục là pass hay fail
Lập kế hoạch cho các tiêu chuẩn bị dừng lại và các yêu cầu được bắt đầu lại
Phân chia công việc cần test
Các task vụ cần thực hiện test
Môi trường cần thực hiện
Phân công người chịu trách nhiệm cho các task vụ
Nhân công và việc đào tạo
Lịch biểu
Rủi ro và các sự việc xảy ra khách quan
Phê duyệt và chuyển giao sản phẩm.

32. Test Specification Test design Cải tiến phương pháp test
Xác định các vấn đề (feature) cần phải cover khi thực hiện test
Xác định các test case
Đặc tả rõ các tiêu chuẩn nào pass/ fail cho mỗi vấn đề (feature) đưa ra

33. Test Specification Test case Test procedure
Tài liệu các giá trị input thực tế và kết quả mong đợi cho mỗi test case được thực hiện.
Định nghĩa các ràng buộc dựa trên các thủ tục test.
Việc định nghĩa các test case là độc lập với việc thiết kế test để có thể sử dụng lại một cách đễ dàng.
Test procedure
Định nghĩa tất cả các bước thực hiện test
Chạy hệ thống
Thực hiện các testcase
Đưa ra các chỉ dẫn

34. Test Design-Nội dung Định nghĩa tài liệu test Các vấn đề cần được test
Các phương pháp yêu cầu
Định nghĩa các trường hợp test
Tiêu chuẩn đánh giá các tiêu chuẩn pass/fail

35. Test case, Procedure – Nội dung
Định nghĩa tài liệu test
Test items
Đặc tả các dữ liệu input
Đặc tả dữ liệu out put
Môi trường
Các yêu cầu đặc biệt
Test Procedure
Định nghĩa tài liệu
Mục đích
Procedure steps (thực hiện từng hiện)

36. Test Report Test Item Transmittal Report Test Log Test Incident Report
Định dạng phần mềm được chuyển giao tới các nhóm test độc lập.
Sử dụng trong trường hợp mà các mẫu ban đầu của việc test được đưa ra.
Test Log
Sử dụng cho những người tham gia vào việc quản lý các kết quả tes
Mục đích là ghi lại những gì xảy ra trong suốt quá trình test.
Test Incident Report
Mô tả một vài sự kiện xuất hiện trong suốt quá trình test mà trong đó mong muốn được phát triển xa hơn.
Ví dụ như:
Thiết bị, công cụ lỗi
Các sự kiện, phần không được rõ ràng, chính xác.
Các bất thường xảy ra.

37. Test Log, Test Incident – Nội dung
Định nghĩa tài liệu
Mô tả
Các sự kiện và hoạt động (Activity and event entries)
Test Incident
Document identifier
Summary
Incident description
Impact

38. Test Report – Nội dung Định nghĩa các tài liệu Tổng kết
Chỉ ra các mâu thuẫn, thay đổi
Đánh giá một cách toàn diện
Tóm tắt sơ lược kết quả
Ước lượng/Tổng kết các hoạt động
Phê chuẩn.

39. KT viết TC hiệu quả Một testcase được cho là hiệu quả:
Test case hiệu quả là test case mà tìm thấy bug.
Tìm được nhiều bug khó.
Chỉ ra được những điểm ban đầu mà khi thực hiện test không tìm ra vấn đề
Tuân theo đúng các con số thống kê bug
Theo dõi các lỗi theo các trường hợp đã được tìm thấy

40. For each identified requirement; define test cases.
KT viết TC hiệu quả
For each identified requirement; define test cases.
Test Cases
For Req. #1
Requirement #1
Test Cases
For Req. #2
Requirement #2
Requirement #3

41. KT viết TC hiệu quả Equivalence class partitioning
Control flow testing
Data flow testing
Transaction testing
Domain testing
Loop testing
Syntax testing
Finite state machine testing
Load and stress testing

42. Equivalence class partitioning
Xác định một nhóm các yêu cầu hệ thống, functions, behaviors
Phân các testcase vào các class. Mỗi class là một nhóm các testcase tương tự nhau
Trong mỗi class chọn test chỉ một vài testcase
Phân các test case theo nhóm các TestCase cùng loại, gọi là class hay lớp các TestCase
Các class lại có thể xếp vào 2 nhóm
Positive tests (clean tests)
Test dựa trên defined requirements
Test những trường hợp, hoàn cảnh sử dụng thông thường
Negative tests (dirty tests)
Test nhằm tìm ra lỗi
Test những trường hợp, hoàn cảnh sử dụng đặc biệt, bất thường (như invalid input, vượt giá trị biên, chịu stress)

43. Control Flow Là kỹ thuật test căn bản
Sử dụng luồng xử lý để thiết lập các phương pháp test
Là sơ đồ mô hình hóa hành vi của hệ thống, (không mô tả các câu lệnh trong code)
Áp dụng được cho hầu hết các phần mềm, có hiệu quả
Áp dụng được trong mọi testing stages
Mỗi rẽ nhánh trong luồng xử lý là 1 TestCase

44. Control Flow Testing Strategy - Summary
Kiểm tra các mô hình system or sub-system
Định nghĩa đối tượng
Định nghĩa các mối quan hệ
Indetify the weights
Identify paths through the model to cover objects
Identify paths through the model to cover links
Each path is a test case
Đưa ra các điều kiện đầu vào và kết quả mong đợi cho mỗi testcase

45. Data Follow Áp dụng cho các hệ thống “data-intensive”, ví dụ:
HT sản sinh báo cáo, thống kê
HT có tính toán thay đổi số liệu
Phương pháp xây dựng testcase:
Lập sơ đồ luồng dữ liệu (data flow)
Lần theo từng đường dẫn trong sơ đồ
Bắt đầu từ node output
Lần ngược lại tới khi gặp node input
Phân tích các TestCase theo sơ đồ mô hình luồng dữ liệu

46. Transaction testing
Áp dụng cho các hệ thống xử lý giao dịch (như đặt vé máy bay, đặt phòng khách sạn)
Sử dụng mô hình xử lý của hệ thống, chú trọng đến điểm bắt đầu, điểm kết thúc của từng xử lý, chú trọng tới hành đợi (queu)
Tương tự như data flow, nhưng bao gồm các khái niệm:
Birth:nó bắt đầu khi nào
Death:hoàn thành khi nào
Queues: tuần tự các giao dịch đợi đến lượt

47. Transaction Flow Testing Strategy
Phân loại TC theo loại các giao dịch, chú trọng việc xác
định điểm khởi đầu, kết thúc và hàng đợi các điểm giao
dịch cần xử lý
Xác định tất cả các loại giao dịch.
Xác định nguồn gốc và điểm kết thúc cho mỗi loại giao dịch.
Xác định queues (nơi mà các giao dịch chờ đợi để được xử lý)
Xác định các thành phần (nhưng không nhất thiết phải phù hợp với các thành phần phần mềm)
Xây dựng mô hình
Xác định hướng đi (paths)

48. Domain test Testing Technique
Áp dụng cho các xử lý mà có xác định phạm vi giá trị dữ liệu
Chú trọng test các giá trị biên On, Off
Tìm ra những nơi mà phần mềm cho giá trị khác nhau -- Phân loại TC theo vùng giá trị của biến, đặc biệt chú trọng các TC quanh biên ranh giới, nơi hệ thống có những xử lý khác nhau so với các giá trị biến khác
Testing Technique
Tìm các giá trị biên độc lập
Kiểm tra một điểm trên biên và độc đáo
Chọn “off point” một giá trị gần với giá trị biên

49. Loop Test Nói về việc lặp trong cấu trúc, or white box, testing
Áp dụng trong Black box test: quan tâm đến vòng lặp trong hành vi của hệ thống chứ không quan tâm đến vòng lặp trong code
Phân loại các TC theo số giá trị từng lần rẽ nhánh các vòng lặp
Ví dụ: khi hệ thống fari tìm ra tất cả các bản ghi thỏa mãn một tiêu chí tìm kiếm nào đó
Giả sử khả năng hệ thống có thể hỗ trợ tối đa Max vòng lặp, chỉ cần chọn thực hiện những testcase sau là đủ:
- 0 lần, 1 lần, 2 lần qua vòng lặp
- X lần,
- Max-1, Max, Max + 1 lần

50. Loops – Test Cases To Use
Thực hiện vòng lặp 0 lần
Lặp 1 lần
Lặp 2 lần
Một số đặc trưng các lần lặp
Thực hiện việc test lặp với số lượng maxium-1 lần
Thực hiện việc test lặp với maxium lần
Thực hiện với maxium + 1 lần lặp

51. Syntax Testing Rất hữu ích cho Test Ví dụ: Các câu lệnh có sẵn
Các trường thực thể có cấu trúc khuôn dạng, định dạng trước hoặc theo một quy định nào đó
Ví dụ:
Ngày tháng
Địa chỉ
Số điện thoại
Mailing addresses

52. Syntax Testing - Technique
Thiết kế các Test case xác thực rõ ràng (dữ liệu valid)bằng cách sử dụng kỹ thuật phân lớp tương đương.
Thiết kế các testcase tiêu cực (negative)với lớp dữ liệu Invalid
Thực hiện các Test Case

53. State Machine Testing Là một chiến lược test khá hoàn hảo Áp dụng khi:
Các ứng dụng được thực hiện qua nhiều các trạng thái khác nhau
Hệ thống được thiết kế sử dụng phương pháp hướng đối tượng
Một vài phần mềm có lược đồ chuyển trạng thái
State C
State A
State B
State D

54. State machine : phương pháp
Các TC được phân loại từ việc lập các biểu đồ
chuyển trạng thái của hệ thống
Vẽ một sơ đồ chuyển đổi trạng thái cho đối tượng cần test
Positive tests: thiết kế test cases cho từng lần chuyển đổi trạng thái
Negative tests: thiết kế các testcases nhằm cố chuyển đổi trạng thái một cách bất hợp lý

55. Load testing
Tùy thuộc vào từng loại hệ thống – bắt hệ thống phải chịu tải lớn.
Số lượng lớn các giao dịch cần thực hiện.
Các file lớn.
Số lượng lớn các file.
Số lượng lớn các client cùng truy nhập.
Các vận hành lặp đi lặp.
Thực hiện việc này yêu cầu một số tool tự động.

56. Stress Test Bắt hệ thống hoạt động trong điều kiện bất thường:
Dung lượng bộ nhớ bị giới hạn.
Mạng lưới hệ thống:Hoạt động với một số lượng nhỏ các node.
Kết nối mạng bị ngắt khi đang vận hành.
Kết nối CSDL bị ngắt khi đang vận hành.

57. Ưu tiên test Danh sách các ưu tiên test - “where to focus testing”
Những vùng quan trọng nhất của phần mềm
Những vùng phần mềm hay được dùng nhất
Những vùng có đặc trưng riêng, khác biệt hẳn với các vùng khác của phần mềm
Những vùng phần mềm dễ bị ảnh hưởng nhất của các thay đổi vừa có (khi regression test)
Những lỗi dễ xảy ra nhất
Những lỗi (người dùng) dễ nhìn thấy nhất
Những loại lỗi khó fix nhất
Những loại lỗi mà tester biết rõ nhất
Những loại lối mà tester biết lờ mờ nhất
Positive test trước, negative test sau (test các trường hợp hợp lệ trước, các trường hợp không hợp lệ sau)
Ưu tiên sắp xếp test theo quality dimension
Số 1: thường là Function testing, và phải bao quát được bussines cycle của hệ thống.
Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax, theo standards và user friendly.