tìm hiểu về nghề tester

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

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 – 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

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

Software V&V Plan

System Test Plan

Integration Test Plan

Acceptance Demonstration Plan

Software

Development Phases Test Planning Phase

Test Execution Phase Project Plan

Requirements Spec

Architectural Design Spec

System Test

Acceptance Demonstration

Integration Test

Install

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

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

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

 Phát hiện sớm các lỗi thiết kế

 Có phiên bản hoạt động sớ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

 Thuận tiện cho phát triển các mô đun

thứ cấp dùng lại được

 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

 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:

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

Test Specification

Test Reporting

Đầu vào/ đầu ra cho testing

 Đầu vào

 Yêu cầu của khách hàng, các tiêu chuẩn

 Các yêu cầu thay đổi

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

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.

Test Plan – Nội dung

một mục là pass hay fail

chuẩn bị dừng lại và các yêu

cầu được bắt đầu lại

nhiệm cho các task vụ

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

 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

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

 Các yêu cầu đặc biệt

 Procedure steps (thực hiện từng hiện)

Test Report

 Test Item Transmittal Report

 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.

Test Log, Test Incident – Nội dung

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

KT viết TC hiệu quả

For each identified requirement; define test cases.

Test Cases For Req #1 Requirement #1

For Req #2

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

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 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ý

Domain test

 Á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

Loops – Test Cases To Use

 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

 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 đó

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

State Machine Testing

 Là một chiến lược test khá hoàn hảo

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

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

khác của phần mềm

vừa có (khi regression test)

lệ trước, các trường hợp không hợp lệ sau)

bussines cycle của hệ thống.