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

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

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

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

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

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

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

Các giai đoạn test 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

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

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

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

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

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

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

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

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

Intergration-Approaches Top-Down Các module cấp trên được kiểm thử trước 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

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

Intergration-Approaches Bottom-up 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

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

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

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

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

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

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

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

Process Test Test Planning Specification Reporting

Đầ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

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

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

Test Plan – Nội dung Đị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.

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

Test Specification Test case 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

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

Test case, Procedure – Nội dung Đị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)

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.

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

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

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

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

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

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

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

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

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

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

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

Domain test 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

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

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

Syntax Testing Rất hữu ích cho Test 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ỉ Email Số điện thoại Mailing addresses

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

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

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

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

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

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