Bài giảng kiểm thử phần mềm

Đồ án 2 Kiểm thử với QTP 30% • Hãy lựa chọn một ứng dụng nền web trên internet hoặc phần mềm tự viết trước đó và chọn 4-5 chức năng chính của nó để kiểm thử chức năng bằng Quick Test Pro

KIỂM THỬ PHẦN MỀM SOFTWARE TESTING

PGS TS Trần Cao Đệ

Năm 2014

Bộ môn Kỹ thuật Phần mềm

Giới thiệu môn học

Nội dung môn học

• Chương 1: Tổng quan về kiểm thử phần mềm

• Chương 2: Căn bản về kiểm thử phần mềm

• Chương 3: Thiết kế các trường hợp kiểm thử

• Chương 4: Các công cụ kiểm thử

• Chương 5: Kế hoạch kiểm thử và tài liệu kiểm thử

Lịch học Kiểm thử PM HK 2 năm 2013 – 14

Ngày Tuần Nội dung Phòng yêu cầu phải nộp để chấm điểm

8-Aug-14 1 LT: Giới thiệu môn học + Chia nhóm đồ án 303/C1

19-Sep-14 7 LT: Báo cáo kiểm thử đơn vị với JUNIT 303/C1

KHÔNG nộp báo cáo, chỉ demo kiểm thử tại lớp, chấm 10%

Một số qui định

• Đồ án: điểm theo nhóm

– Không có đăng kí nhóm: 0 điểm đồ án

– Không tham gia đồ án: 0 điểm đồ án

– Không nộp báo cáo viết/viết không đúng yêu cầu: không chấm điểm thực hành đồ án

• Thi :

– Vắng quá 20% giờ LT: cấm thi

– Thi trắc nghiệm: mang theo viết chì 2B

– Ghi/tô sai SBD: -1 điểm bài thi

– Không ghi/tô Mã đề: 0 điểm thi

Mẫu phiếu trắc nghiệm

Qui định về thang điểm

Đồ án 1

KT đơn vị với JUNIT (10%)

Viết phần mềm bằng Java có giao diện đồ họa :

- nhận vào một số nguyên không âm rồi hiển thị cách đọc số đó ví dụ:

0 không, … 9 chín, 10 mười, 11 mười một,…,15 mười lăm, 19 mười chín, 20 hai mươi, 25 hai mươi lăm, 100 một trăm, 101 một trăm

lẻ 1 hoặc một trăm linh một, 05 một trăm lẻ năm

- viết tài liệu gồm tất cả các ca kiểm thử

- Cài đặt để kiểm thử tất cả các ca kiểm thử đó trong JUNIT

- Chạy chương trình và kết xuất ra một file excel / text kết quả chạy chương trình với đầu vào từ 1 đến n (n nhập vào), ví dụ cho

n=1000 thì chương trình sẽ chạy và xuất kết quả từ 0 đến 1000 mỗi số là một dòng kết quả Không cần kiểm thử phần này!

- Viết module hỗ trợ test bằng cách đọc file dạng text chứa các số cần test, mỗi số trên 1 dòng, xuất kết quả vào một file text, mỗi số cùng kết quả trên một dòng Không cần kiểm thử phần này!

Đồ án 2 Kiểm thử với QTP (30%)

• Hãy lựa chọn một ứng dụng nền web (trên internet hoặc phần mềm

tự viết trước đó) và chọn 4-5 chức năng chính của nó để kiểm thử chức năng bằng Quick Test Pro Trong quá trình test phải dùng

những kỹ thuật chính của QTP: ghi action (recorder), dùng data

table, dùng check point các kiểu dữ liệu khác nhau một cách đa

dạng nhất có thể, có thể can thiệp vào code hoặc repository

• Yêu cầu cụ thể về bài nộp

– Viết mô tả rõ từng chức năng cần test: giao diện, đầu vào, đầu ra, ràng buộc, yêu cầu của người dùng có liên quan đến xử lí

– Viết các ca kiểm thử cho từng chức năng tương ứng với tài liệu mô tả chức năng ở trên

– Demo và báo cáo cách cài đặt để kiểm thử từng chức năng và kết quả test

– Demo vào buổi báo cáo

Tài liệu tham khảo

• Guide to Advanced Software testing (ebook)

• Giáo trình KTPM, Trần Cao Đệ, 2012, bán tại thư viện Khoa CNTT&TT

Download tai lieu + slides

www.cit.ctu.edu.vn/~tcde

KIỂM THỬ PHẦN MỀM SOFTWARE TESTING

PGS TS Trần Cao Đệ

Năm 2014

Bộ môn Kỹ thuật Phần mềm

Chương 1:

Tổng quan về kiểm thử phần mềm

PGS TS Trần Cao Đệ

Năm 2014

Khái niệm kiểm thử phần mềm

• Testing is the process of executing a program with the intention of finding errors (Myers)

– Mục đích của kiểm thử

• Nhằm phát hiện lỗi phần mềm

• Chứng tỏ phần mềm thực hiện đúng các chức năng mong đợi

• Nhằm xác lập độ tin cậy của cái mà chương trình muốn thực hiện

– Một kiểm thử tốt phải kiểm tra được những hành

vi bất thường của chương trình

• Testing can show the presence of bugs but

never their absence (Dijkstra)

Các mức độ kiểm thử

• Kiểm thử đơn vị (Unit Testing)

• Kiểm thử tích hợp (Integration Testing)

• Kiểm thử hệ thống (System testing)

• Kiểm thử chấp nhận (Acceptance Testing)

Kiểm thử đơn vị

• Một đơn vị là một thành phần nhỏ nhất của phần mềm có thể kiểm tra được

– Functions, Procedures, Classes, và Methods có thể xem là “đơn vị”

Nội dung kiểm thử đơn vị

• Giải thuật và logic

• Cấu trúc dữ liệu

• Giao diện (Interfaces)

• Các nhánh độc lập (Independent paths)

• Giá trị biên, điều kiện biên

• Bẫy lỗi và kiểm soát lỗi (Error handling)

Qui trình kiểm thử đơn vị

Qui trình kiểm thử

Kiểm thử đơn vị trong tiến trình phần mềm

Kiểm thử tích hợp

• Kiểm thử tích hợp là kiểm thử một tổ hợp các thành phần của một phần mềm (tạo thành một chức năng đầy đủ)

– Tập trung vào việc làm thế nào để các thành

phần (đơn vị) làm việc với nhau

• Kiểm thử tích hợp nhằm:

– Phát hiện lỗi xảy ra trong giao diện giữa các

thành phần đơn vị

– Lắp ráp các đơn vị riêng rẽ vào một hệ thống con

và vào một hệ thống hoàn chỉnh cuối cùng

– Thực hiện sau khi hoàn tất kiểm thử hệ thống

• Phần mềm phải được thực thi trong thế giới thực của

nó (phần mềm, phần cứng)

• Nếu phần mềm phát triển cho một thị trường lớn thì kiểm thử chấp nhận gồm hai bước:

– Alpha test: trên máy của nhà phát triển

– Beta test: người dùng install và dùng thử trong thế giới thực

Mô hình kiểm thử hình chử V

Kiểm thử hồi qui (Regression testing )

• Kiểm thử lại trên một phiên bản mới

– Kiểm tra tính đúng đắn sau khi thực hiện một số thay đổi trên phần mềm (đã kiểm thử thành công) – Đảm bảo code mới thêm/sửa không đưa ra lỗi

mới

Chính sách kiểm thử

• Vét cạn các trường hợp có thể chỉ ra chương trình sạch lỗi Tuy nhiên vét cạn là không thể

• Chính sách kiểm thử xác định cách thức tiếp cận để kiểm thử có hệ thống và bao quát, cần test :

– Tất cả các chức năng truy cập được từ menu

– Tổ hợp các chức năng truy cập được trên cùng menu

– Khi có input từ người dùng, phải test với dữ liệu đúng và với dữ liệu sai

documents from that time She discovers sources in various US university libraries and downloads copies of some of these

However, for one document, she needs to have confirmation

from her university that she is a genuine student and that use is for non-commercial purposes The student then uses the facility

in LIBSYS that can request such permission and registers her request If granted, the document will be downloaded to the

registered library‟s server and printed for her She receives a

message from LIBSYS telling her that she will receive an e-mail message when the printed document is available for collection

Các chiến lược…

1 Test the login mechanism using correct and incorrect

logins to check that valid users are accepted and

invalid users are rejected

2 Test the search facility using different queries against

known sources to check that the search mechanism

is actually finding documents

3 Test the system presentation facility to check that

information about documents is displayed properly

4 Test the mechanism to request permission for

downloading

5 Test the e-mail response indicating that the

downloaded document is available

Nguyên tắc (Testing guidelines)

• Chọn các dữ liệu test để lộ ra lỗi

– Chọn đầu vào làm cho hệ thống sinh ra các thông báo lỗi

– Thiết kế input sao cho tràn buffer, tràn số,…

– Lặp lại cùng input vài lần

– Chọn dữ liệu vào làm sinh ra output sai

– Chọn dữ liệu vào làm sinh tính toán quá lớn hoặc quá nhỏ

Loại kiểm thử (Testing types)

• Kiểm thử chuần mực (Benchmark test)

so sánh hiệu năng của một đối tượng cần test với một

chuẩn mực đã biết

• Kiểm thử cấu hình (Configuration test)

Kiểm tra đối tượng cần test với các cấu hình phần

mềm/cứng khác nhau

• Kiểm thử chức năng (Functional test)

Kiểm tra đối tượng cần test với hoạt động đúng như mong đợi

• Kiểm thử cài đặt (Installation test)

Kiểm tra đối tượng cần test được cài đặt thành công với các cấu hình khác nhau, trong môi trường khác nhau và trong các điều kiện khác nhau (ví dụ thiếu không gian đĩa)

Loại kiểm thử (tt)

• Kiểm thử tính toàn vẹn (Integrity test)

Kiểm tra tính tin cậy, chắc chắn và sức chịu đựng lỗi trong khi thực thi

• Kiểm thử tải (Load test)

Kiểm tra khả năng chấp nhận của đối tượng cần test trong các điều kiện vận hành khác nhau như: số user, số transaction với cùng một cấu hình

• Kiểm thử hiệu năng (Performance test)

Kiểm tra khả năng chấp nhận của đối tượng cần test với các cấu hình khác nhau với cùng điểu kiện vận hành

• Stress test

Kiểm tra khả năng chấp nhận của đối tượng cần test trong các điều kiện bình thường và bất thường (ví dụ không đủ nguồn lực,

số user cực kỳ cao)

– Nhu cầu của project

– Nhu cầu của khách hàng

– Các cải tiến cho tương lai

specifications

events

Kiểm thử hộp trắng

• Kiểm thử hộp trắng:

– Khảo sát cấu trúc điều khiển /logic chương trình

• Thường dùng với kiểm thử đơn vị

• Thực hiện bởi người phát triển kiêm tester

• Mục tiêu là kiểm tra thành phần (đơn vị) bằng cách khảo sát tất cả các đường đi/nhánh

chương trình

1-2-3-4-11

10-4-11

1-2-3-4-5-6-7-8-9-

1-2-3-4-5-6-10-4-11

1-2-3-4-5-4-11

Thiet ke test case

• X=[1,2,4]  X=[1,2,4]

• X=[1,2]  X=[1,2]

Verification vs Validation

• Kiểm tra (Verification) đảm bảo hệ thống thỏa các

chuẩn, các qui trình, qui định của tổ chức dựa trên xét duyệt hoặc các phương pháp không thực thi (non-

executable)

– Verification trả lời “ Did we build the system right? ”

– Ví dụ : xét duyệt đặc tả, thiết kế, code (Walkthrough hoặc Inspection)

• Kiểm tra xác nhận (Validation) đảm bảo hệ thống vận hành đúng như mong đợi dựa vào chuỗi các test

– Validation trả lời: “ Did we build the right system ? ”

– Ví dụ: Unit Testing, Integrated testing, System testing,

User acceptance testing

Chu trình kiểm thử (Testing cycle)

1 Phần tích yêu cầu: kiểm thử phải bắt đầu từ giai đoạn đặc tả

phần mềm

2 Phân tích thiết kế : trong giai đoạn thiết kế, tester làm việc với

developper để xác định các đặc trưng cần test và test được cùng với các tham số cần thiết

3 Lập kế hoạch test: chọn chiến lược, lập kế hoạch, tạo ra các

yêu cầu test

4 Phát triển test: qui trình test, kịch bản test, Test Cases, Test

Scripts dùng để test

5 Thực hiện test: thực hiện test theo kế hoạch ghi nhận và báo

cáo lỗi cho bộ phận phát triển

6 Báo cáo test: sau khi hoàn tất test, tester làm các độ đo cần

thiết và làm báo cáo tổng kết về công việc test đồng thời xác định phần mềm có thề release được hay không (dựa vào

chuẩn)

7 Test lại sau khi sửa đổi

Lưu đồ công việc kiểm thử

Kế hoạch kiểm thử

• Xác định phạm vi công việc cần làm (test)

• Qui trình test: tài liệu xác định cách thức tiến hành mọi test

• Báo cáo Test (Report): tài liệu ghi nhận trạng thái của test khi thực hiện

Ước lượng công việc

• Cần trả lời các câu hỏi:

– Cần bao nhiêu test?

– Phát triển các test bao lâu?

– Thực hiện các test bao lâu?

– Cần bao nhiêu thời gian/người?

Chủ điểm cần đề cập trong KH test

– Ước lượng về test

– Cách phát triển test và kiểm chứng, chứng thực (không hình thức)

– Xét duyệt và chứng thực hình thức

– Tiêu chí hoàn thành test

Ví dụ về ước lượng

SRS

Reference

Estimated Number of Tests Required

Notes

4.1.1 3 2 positive and 1 negative test 4.1.2 2 2 automated tests

4.1.3 4 4 manual tests

4.1.4 5 1 boundary condition, 2 error

conditions, 2 usability tests

…

Total 165

Ví dụ về ước lượng (tt)

Estimated Number of Tests: 165

Average Test Development Time: 3.5 (person-hours/test)

Estimated Test Development Time:

577.5

(person-hours)

Validation Test Plan

Validation Test Plan (cont)

Fault, error and failure

• Software Fault : một sai sót (defect) tĩnh trong phần mềm

– Ví dụ: quên cấp phát ô nhớ cho con trỏ

• Software Error : một trạng thái sai (bên trong) thể hiện một sai sót nào đó trong phần mềm

– Ví dụ: truy xuất con trỏ chưa được cấp phát bộ nhớ

• Software Failure : một hành vi không đúng,

không mong đợi thể hiện ra bên ngoài

– Ví dụ: chương trình bị treo (do truy xuất con trỏ không được cấp phát bộ nhớ)

Testing Activities

Test tự động

• Các Test được thực thi tự động

• Bốn bước cho test tự động

– Phân tích các trường hợp test và thiết kế test

– Viết tập lệnh test (Test Scripts)

– Kiểm tra tập lệnh test

– Đóng gói và giao cho khách hàng

• Test tự động dùng chủ yếu:

– Test hồi qui mỗi khi dịch và tích hợp hệ thống (build)

– Hướng dữ liệu: dùng nhiều giá trị dữ liệu test cùng một hoạt động

– Test hiệu năng

– test Stress

– Load testing

– Special test, or customer required

– Tests required detailed information from application internals (e.g., SQL, GUI attributes)

• Ví dụ: Junit trợ giúp test các chương trình Java

Ví dụ một test script với Junit

/** Test of setName() method, of class Value */

String expected = "Y";

String actual = v1.getName( );

Assert.assertEquals( expected, actual ); }

Test and test again

Hết chương 1

CĂN BẢN VỀ KIỂM THỬ PHẦN MỀM SOFTWARE TESTING FUNDAMENTALS

PGS TS Trần Cao Đệ

Năm 2014

Bộ môn Kỹ thuật Phần mềm

KIỂM TRA ĐẶC TẢ

• Đặc tả là tài liệu text, không phải code

– Không thực thi được

– Kỹ thuật test tĩnh (static): đọc, xem xét, duyệt

– Không cần đi sâu vào tìm lỗi nhưng sẽ đi sâu vào các vấn đề cốt lõi, tổng quan; tránh chi tiết

• Kiểm tra đặc tả là nghiên cứu đặc tả và làm

cho đặc tả rõ hơn cái gì phần mềm phải làm

• Nghiên cứu: thuật ngữ, chuẩn (theo luật),

chuẩn kỹ thuật (công nghiệp), giao diện, an

toàn

KIỂM TRA ĐẶC TẢ (tt)

• Kiểm tra dựa vào phần mềm “tương tự”

– Scale: nhiều/ít chức năng/code hơn?

Kiểm thử dữ liệu

• Giá trị

• Điều kiện biên

• Các kiểu điều kiện biên: first, last, min, max

• Kiểm tra giá trị biên

• Điều kiện con

• Không thỏa, sai, không chính xác

Kiểm tra trạng thái

• Các dòng logic

• Kiểm tra fail

– Điều kiện hiếm

– Bad timing

– If … else If (không else)

• Truyền tham số sai

• Dữ liệu vào ra

• Lỗi khác: font, chuẩn (ASCII, Unicode)

Các test đặc biệt

Kiểm tra cấu hình

Kiểm tra khả năng tương thích

• Khả năng tương thích: giao tiếp & chia sẻ đúng đắn với soft khác

Kiểm tra ngôn ngữ nước ngoài

• Từ/ hình ảnh có nghĩa

• Kích thước từ  thiết kế lại giao diện

• Phím nóng

• Các kí tự mở rộng: a, ả, ã

• Thứ tự đọc: trái  phải, phải  trái

• Hãy để code độc lập với text

• Data format:

– Số 5.5; 5,5

– Tiền tệ

– Ngày tháng

Kiểm tra tính dùng được

Kiểm tra tài liệu

• Các tài liệu khớp nhau

• Chính tả, soạn thảo

• Hợp chuẩn

Kiểm tra an toàn phần mềm

• Secure product: bảo vệ tính riêng tư, toàn vẹn

và sẳn dùng về thông tin của người dùng

Kiểm tra tải (load/stress testing)

• Kiểm tra giới hạn khả năng của hệ thống

– Số truy cập đồng thời

– Lượng dữ liệu upload,…

• Dùng các scripts/ chương trình giả lập

• Viết bởi đội QA

• Kiểm tra chức năng

• Có thể chỉ ra

– Các chức năng ẩn

– Khả năng cực đại của hệ thống

– Thiếu vắng data hoặc dịch vụ

– Xác lập khả năng của hệ thống

• Các yêu cầu phi chức năng

Ví dụ

Must support 500 users Must support 500

simultaneous users

10 second response time [Average|Maximum|90th

percentile] response time must be X seconds

Must handle 1M hits per

day

Must handle peak load of

28 page requests per second

Hết chương 2

THIẾT KẾ CÁC TRƯỜNG HỢP KiỂM THỬ

TEST CASE DESIGN

PGS TS Trần Cao Đệ

Năm 2014

Bộ môn Kỹ thuật Phần mềm

Testing Activities

Tested Subsystem

Subsystem

Code

Functional Integration

Unit

Tested Subsystem

Requirements Analysis Document

System Design Document

Requirements Analysis Document

Subsystems