Nhập môn Công nghệ phần mềm: Chương 3

Ki m th Ph n m m – S o ftware Te s ting

ử

ể

Chi n l

ầ ng 3: Ch c ki m th ph n m m ử

ề ươ ể

ề

ầ

ế ượ

ầ ươ

ế ư ạ

ng Tr n Hy Hi n, L Khoa CNTT, ĐH S ph m TpHCM

• Kiểm tra mức đơn vị (Unit Testing) • Kiểm tra tích hợp (Integration Testing) • Kiểm tra mức hệ thống (System Testing) • Kiểm tra chấp nhận sản phẩm

(Acceptance Testing)

• Kiểm tra hồi qui (Regression Testing)

N i dung ộ

ể ị

Unit Test là gì?

Nh ng L i ích t

ữ

ợ

ừ

Assert, Mock Object, TDD

Công c cho Unit Test

ụ

Demo công cụ

3.1 Ki m th đ n v - Unit ử ơ Te s t

• Unit Test là kỹ thuật kiểm nghiệm các

hoạt động của mọi đơn vị mã nguồn (unit of code) với một quy trình tách biệt với quy trình phát triển phần mềm, giúp phát hiện sai sót kịp thời.

• Unit Test là một phần mã nguồn dùng để

kiểm tra một phần mã nguồn khác.

• Unit Test là kỹ thuật quan trọng trong Test

Driven Development.

Unit Te s t là gì?

• Unit Test là phương pháp bổ sung cho các

phương pháp kiểm thử khác, giúp phát hiện lỗi từ sớm, ngay từ ý tưởng thiết kế (reviews code, walkthroughs…)

• Unit Test được viết bởi Developers. Test “White

Box”, “Black-Box” trong quá trình PTPM.

Các Khái Ni m: ệ

§ Unit of Code : M i đ n v mã ngu n có th là

individual

ỗ ơ

ể

ồ

ị

program, function, Procedure, class, methods…

§ White-Box, Black-Box :

Unit Te s t là gì?

Unit Test có 3 trạng thái: § Fail (trạng thái lỗi) § Ignore (tạm ngừng thực hiện) § Pas s (trạng thái làm việc đúng)

Unit Te s t là gì?

Mỗi Unit Test đều được tiết kế theo trình tự: • Thiết lập các điều kiện cần thiết: khởi tạo các đối

tượng.

• Xác định tài nguyên cần thiết, xây dựng các dữ

liệu giả...

• Triệu gọi các phương thức cần kiểm tra. • Kiểm tra sự hoạt động đúng đắn của các

phương thức.

• Dọn dẹp tài nguyên sau khi kết thúc kiểm tra.

Th c hi n UT nh th nào? ư ế ự ệ

How to write a Unit Tes t?

§ Tự động kiểm tra trạng thái (Pass/False/Ignore). § Đầy đủ (phủ hết các trường hợp). § Tái sử dụng được. § Tính độc lập (very important). § Theo chuẩn code. § Khả năng thực thi nhanh. § Đơn giản để thực hiện.

Unit Testing Still Not Mainstream

http://www.telerikwatch.com/2008_05_01_archive.html

My Unit Te s t is good?

Đảm bảo chất lượng từng Unit trong phần mềm. Phát hiện lỗi sớm và chỉnh sửa kịp thời. Giảm chi phí bảo trì và kiểm thử. Dễ tích hợp. Tài liệu hóa. Giúp Thiết Kế.

L i íc h t Unit Te s t ợ ừ

•

AS S ERT

–

là một macro dùng để phát hiện lỗi của phần mềm trong quá trình phát triển bằng cách thực thi biểu thức trong assert.

ể

ữ

ệ

ữ ộ

ữ

i l p Dùng assert() đ phát hi n ra nh ng bugs do nh ng ng ườ ậ trình vì vô tình mà gây ra : g i m t hàm v i nh ng tham s ố ớ ọ , s d ng sai thu t toán, v.v… không h p l ậ

ợ ệ ử ụ

As s e rt, Moc k Objec t, TDD

• Là một đối tượng ảo mô phỏng các tính chất và hành vi giống hệt như đối tượng thực, được dùng để kiểm tra tính đúng đắn của một đơn vị chương trình.

• Đơn giản hơn đối tượng thực nhưng vẫn giữ được sự

tương tác với các đối tượng khác. – Đảm bảo công việc kiểm nghiệm không bị gián đoạn . – Giúp tiếp cận hướng đối tượng tốt hơn – Giúp phát hiện interface cần tách ở một số lớp. – Dễ dàng cho việc kiểm nghiệm. Thay vì gọi các đối tượng thực vận hành nặng nề, chúng ta có thể gọi các MO đơn giản hơn để kiểm tra nhanh liên kết giữa các thủ tục, công việc kiểm nghiệm có thể tiến hành nhanh hơn.

Moc k Objec t

• TDD là một chiến lược phát triển sử dụng kỹ thuật UT theo nguyên tắc tạo ra các công đoạn kiểm nghiệm trước khi xây dựng mã.

Te s t Drive n De ve lopme nt

L i íc h Te s t Drive n De ve lopme nt

ợ

• Định hình ý tưởng thiết kế hơn là kiểm nghiệm

mã chương trình.

• Lập trình đôi. • Định hướng cho nhóm thiết kế vận dụng tốt các

phương pháp hướng đối tượng. ü Loosely-Coupled. ü Highly-Cohesive.

• Mã chất lượng và an toàn, tập trung hơn, giảm phân mảnh mã và giảm rủi ro xảy ra ngoài dự kiến.

Công c c ho Unit Te s t ụ

• Toàn hệ thống xem như là tập các hệ thống con được xác định trong suốt quá trình thiết kế hệ thống và đối tượng.

• Chiến lược kiểm là thứ tự mà các hệ thống con

được chọn để kiểm và tích hợp. – Tích hợp Big bang – Tích hợp từ dưới lên – Tích hợp từ trên xuống – Kiểm thử Sandwich – Biến dạng các cách trên

• Dùng cách phân rã hệ thống từ bản thiết kế

3.2 Ki m th tíc h h p ử ợ ể

ẫ ể ợ ớ

cách thực thi dưới 1 giao diện.

• Giao diện cho thành phần không hoàn

chỉnh, chưa biết hay không thể xài suốt quá trình kiểm.

Dùng m u trung gian c ho phé p ki m tíc h h p s m • Dùng mẫu trung gian để cung cấp nhiều

Seat Implementation

VIP

Seat Interface (in Vehicle Subsystem)

Real Seat

Stub Code

Simulated Seat (SA/RT)

Ví d : Phân c p 3 l p ụ ớ ấ

A

Layer I

Layer II

D

C

B

Layer III

G

F

E

• Kiểm thử big bang (big bang te s ting) là một chiến lược kiểm thử hệ thống tiến hành một lần duy nhất khi đã phát triển toàn bộ các mô đun và tích hợp thành một phần mềm hoàn chỉnh.

• Phương pháp này vẫn thường được tiến

hành khi phát triển các phần mềm có kích thước nhỏ.

3.2.1 Ki m th big bang ử ể

3.2.1 Ki m th Big-Bang ử ể

Unit Test A

Đ ng c ! ố

ừ

Unit Test B

Unit Test C

System Test

Unit Test D

Unit Test E

Unit Test F

• Là quá trình tích hợp và kiểm thử với các

mô đun ở mức độ thấp trước.

• Thông thường người ta không thuần túy kiểm thử tất cả các mô đun ở tầng dưới cùng mà nhóm các mô đun này thành các nhóm chức năng, tích hợp và kiểm thử chúng theo từng nhóm.

• Tiến hành tích hợp và kiểm thử một số

mô đun cấp trên trước

i lên 3.2.2 Ki m th d ể ử ướ

A

• VD:

B

F

K

C

G

D

E

H

I

Nhóm ch c n ng

ứ

ă

i lên 3.2.2 Ki m th d ể ử ướ

A

Layer I

D

C

B

Layer II

Test E

G

F

E

Layer III

Test B, E, F

Test F

Test C

Test A, B, C, D, E, F, G

Test D,G

Test G

• Kiểm thử dưới lên có một số ưu điểm:

– Tránh phải tạo các stub phức tạp hay tạo các

kết quả nhân tạo

– 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 của phương pháp bottom-up:

– 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

i lên 3.2.2 Ki m th d ể ử ướ

t cho các h th ng phân rã theo

ố

ệ ố

• Không t ứ

ọ

ấ

ử ệ ố

ụ

• H u d ng đ tích h p cho các h th ng ợ

ệ ố

ể

ướ ờ

ch c năng: – Ki m th h th ng con quan tr ng nh t sau ể cùng ữ sau: ng đ i t – Các h th ng h ố ượ – Các h th ng th i gian th c ự – Các h th ng có yêu c u vi c th c thi nghiêm ệ ầ

ệ ố ệ ố ệ ố

ự

ng tặ

Khi nào c n dùng c hi n l d i lê n ầ c t ế ượ ừ ướ

• Kiểm thử trên xuống tiến hành kiểm thử với các mô đun ở mức cao trước, các mô đun mức thấp được tạm thời phát triển với các chức năng hạn chế.

• Thông thường, để sớm có một phiên bản thực hiện người ta thường tích hợp theo một nhánh cho đến các mô đun cấp thấp nhất.

3.2.3 Ki m th trê n xu ng ử ố ể

• VD:

3.2.3 Ki m th trê n xu ng ử ố ể

A

B

F

G

C

D

E

3.2.3 Ki m th trê n xu ng ử ố ể

A

Layer I

D

C

B

Layer II

G

F

E

Layer III

Test A

Test A, B, C, D

Test A, B, C, D, E, F, G

Layer I

Layer I + II

All Layers

• Ưu điểm của kiểm thử trên xuống

– 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 của kiểm thử trên xuống

– Khó có thể mô phỏng được các chức năng

của mô đun cấp thấp phức tạp

– Không kiểm thử đầy đủ các chức năng • Trên thực tế người ta thường tìm cách phối hợp hai chiến lược này, gọi là s andwich te s ting

u đi m Ki m th trê n xu ng Ư ử ố ể ể

ố ể

i d ng

ể ượ

ị

ướ ạ

ch c năng h th ng (yêu c u ch c năng)

ứ

ầ

• Vi

t c ấ ả

đi u ki n có th x y ra đ

ứ t stubs có th khó: Stubs ph i cho phép t ế ề

ả c ki m. ể

ượ

ng r t l n stubs, đ c bi

ệ ố ể ể ả ố ượ

ấ ớ

ệ • Có th c n s l ể ầ ấ

ặ ề

t n u ệ ế ng ươ

ứ

ấ ủ

i pháp đ tránh quá nhi u stubs:

Đi u ề

l p th p nh t c a h th ng ch a nhi u ph ệ ố ớ pháp. • M t gi ộ ỉ

ố

c khi tr n các t ng.

ề trên xu ng. ướ

ể c t ủ

ệ ố

ể

ộ

ầ trên xu ng có đi u

ả ch nh chi n l ế ượ ừ – Ki m m i t ng c a h th ng tr ỗ ầ – Khuy t đi m c a ki m th t ủ ể

ử ừ

ề

ế

ể ch nh: C hai, stubs và drivers đ u c n.

ố ầ

ề

ả

ỉ

Khi nào c n dùng ầ ki m th t ử ừ • Test cases có th đ trê n xu ng c đ nh nghĩa d

ớ

• Kết hợp từ trên xuống và từ dưới lên • H th ng xe m nh có 3 l p: ư ệ ố – Lớp mục tiêu ở giữa – Lớp trên – Lớp dưới – Kiểm thử tập trung vào lớp giữa

• Nếu có hơn 3 lớp thì lớp giữa là lớp nào?

– Mẹo: Cố gắng cực tiểu hoá số stubs và drivers

3.2.4 Ki m th Sandwic h ử ể

A

Layer I

Chi n l c Sandwic h ế ượ

D

C

B

Layer II

G

F

E

Layer III

Test E

Test B, E, F

Test F

Bottom Layer Tests

Test A, B, C, D, E, F, G

Test D,G

Test G

Test A,B,C, D

Test A

Top Layer Tests

• Thực hiện song song lớp Trên và Dưới. • Không kiểm các lớp con riêng lẻ kỹ trước

khi tích hợp.

• Giải pháp: Điều chỉnh chiến lược

sandwich

Khi nào dùng Sandwic h

c ỉ ề ế ượ

– Lớp giữa với drivers và stubs – Lớp trên với stubs – Lớp dưới với drivers • Kiểm song song:

– Tầng trên truy xuất tầng giữa (lớp trên thay drivers) – Tầng giữa truy xuất tầng dưới (lớp dưới thay stubs)

Đi u c h nh c hi n l Sandwic h • Kiểm song song:

Đi u c h nh c hi n l

c S andwic h

ế ượ

ề

ỉ

Double Test I

A

Layer I

Test B

D

C

B

Layer II

Test E

G

F

E

Layer III

Triple Test I

Test B, E, F

Triple Test I

Double Test II

Test F

Test D

Test A, B, C, D, E, F, G

Test D,G

Double Test II

Test G

Test A,C

Test A

Test C

Double Test I

ậ ị ể

L p l c h ki m Sandwic h: Ví dụ

SystemTests

Triple Tests

Double Tests

Unit Tests

Các b ướ

ấ

ọ

c ki m tíc h h p ể

ử

ể

ấ

các h s

ồ ơ của test cases

ữ

ể 1. Dựa trên chiến lược tích hợp, ch n m t thành ph n ầ để ộ kiểm. Kiểm đơn vị tất cả các lớp trong thành phần.

ự ắ

7. Lặp các bước 1 đến 7 cho đến khi toàn hệ thống được kiểm.

ứ

ử

ể

Mục tiêu nguyên thuỷ của kiểm tích hợp là xác định lỗi trong c u hình thành ph n hi n hành. ấ

ệ

ầ

2. Đặt thành phần được chọn vào với nhau; thực hiện bất cứ s s p đ t s b ặ ơ ộ cần thiết để kiểm thử tích hợp chức năng (drivers, stubs) 3. Thực hiện ki m th ch c năng: Định nghĩa test cases thuộc tất cả uses cases với thành phần được chọn.

ợ 4. Thực hiện ki m c u trúc: Định nghĩa test cases thuộc thành phần được chọn. 5. Thi hành ki m th công s u t. 6. Gi và các hoạt động kiểm thử.

Chi n l

c tích h p nào nên dùng?

ế ượ

ợ

• Các yếu tố xem xét

– Các thành phần ở tầng

–

trên thường quan trọng và không thể xem thường vào giai đoạn cuối của việc kiểm thử. Dò tìm các lỗi thiết kế được hoãn lại ở cuối giai đoạn kiểm thử.

– Khối lượng stubs &drivers – Xác định các phần quan trọng trong hệ thống – Khả năng phần cứng – Khả năng các thành phần – Sắp xếp các mối quan tâm

• Hướng từ trên xuống

• Hướng từ dưới lên

– Test cases có thể được

định nghĩa theo các chức năng đang xét.

– Phù hợp cho các phương pháp thiết kế hướng đối tượng.

– Cần duy trì tính đúng đắn

của test stubs

– Các giao diện driver kiểm thử phải khớp các giao diện thành phần.

– Viết stubs có thể khó khăn.

• Kiểm thử chức năng • Kiểm thử cấu trúc • Kiểm thử hiệu suất • Kiểm thử chấp nhận • Kiểm thử cài đặt

3.3 Ki m th h th ng ử ệ ố ể

Ảnh hưởng của yêu cầu đối với kiểm thử hệ thống:

– Yêu cầu càng tường minh, càng dễ kiểm thử. – Chất lượng use cases xác định độ dễ của

kiểm thử chức năng.

– Chất lượng việc phân rã các hệ thống con xác

định độ dễ của kiểm cấu trúc.

– Chất lượng các yêu cầu phi chức năng và các ràng buộc xác định độ dễ của kiểm thử hiệu suất:

3.3 Ki m th h th ng ử ệ ố ể

ố

ớ ể

ắ

ộ

• Gi ng v i ki m h p tr ng. • Mục tiêu: Phủ tất cả các đường trong thiết

kế hệ thống – Thử tất cả các tham số đầu vào và đầu ra của

thành phần.

– Thử tất cả các thành phần và tất cả lời gọi

hàm (mỗi thành phần được gọi ít nhất 1 lần và mọi thành phần được gọi bởi tất cả các nơi có thể gọi.)

– Dùng kiểm thử điều kiện và lặp như trong unit

testing.

Ki m th c u trúc ử ấ ể

Ki m c h c năng ứ ể

.

ố

ộ

Gi ng nh ki m h p đen ư ể • Mục tiêu: Kiểm chức năng của hệ thống • Test cases được thiết kế từ tài liệu phân

tích yêu cầu (tốt hơn là: tài liệu hướng dẫn sử dụng) và tập trung vào các yêu cầu xung quanh và các chức năng cơ bản (use . cases)

• Hệ thống được xử lý như hộp đen. • Unit test cases có thể tái sử dụng, nhưng người dùng cuối hướng đến test cases mới cũng được.

• Timing testing

• Stress Testing

– Evaluate response times and time to perform a function

• Environmental test

– Stress limits of system (maximum # of users, peak demands, extended operation)

– Test tolerances for heat,

• Volume testing

humidity, motion, portability

– Test what happens if large amounts

• Quality testing

of data are handled • Configuration testing

– Test reliability, maintain- ability & availability of the system

– Test the various software and

• Recovery testing

hardware configurations

– Tests system’s response to

• Compatibility test

– Test backward compatibility with

presence of errors or loss of data.

existing systems

• Human factors testing

• Security testing

– Tests user interface with user

– Try to violate security requirements

Ki m th năng s u t ấ ử ể

ể

ử

i h n.

ớ ạ

ợ

ả

ng

Te s t Cas e s c ho ki m th năng s u tấ • Đ a h th ng đã tích h p vào đúng gi ư ệ ố • M c tiêu: C g ng phá h th ng con ụ • Ki m tra h th ng x lý th nào khi quá t i. ử ể • Th th t ử ứ ự

ố ắ ệ ố ế ệ ố thi hành khác th ườ

– Gọi receive() trước send()

• Ki m tra ph n ng c a h th ng tr

ủ ệ ố

c kh i ố

ướ

ng d li u l n

ả ứ ữ ệ ớ

ể l ượ – Nếu hệ thống có thể kiểm soát 1000 mục, thử 1001

• Xé t th i gian th c hi n trong các us e cas e ệ

ự

mục. ờ

khác nhau

• Alpha te s t:

• Mục tiêu: Hệ thống sẵn

sàng sử dụng – Khách hàng thực hiện – Có thể thực hiện ở giai

đoạn tích hợp

– Khách hàng kiểm ngay tại nơi viết phần mềm. – Lập trình viên sẵn sàng fix bugs khi tìm thấy.

• Be ta te s t:

– Lập trình viên không kiểm thử ở giai đoạn này.

– Khách hàng xài thử – Phần mềm đang ở trong

môi trường thực

– Khách hàng tiềm năng có thể không hài lòng

• Phần lớn các bugs trong phần mềm do khách hàng tìm thấy sau khi hệ thống đưa vào sử dụng. Vì vậy có 2 loại kiểm ở giai đoạn này:

Ac c e ptanc e Te s ting

ử ố

Thi

ế ậ

t l p các m c tiêu ki m ụ

ể

Thi

t k test cases

ế ế

t test cases

ế

Ki m test cases

ể

Th c thi the tests

ự

Đánh giá các k t qu ki m

ả ể

ế

Thay đ i h th ng

ổ ệ ố

Th c hi n ki m h i qui

ự

ệ

ể

ồ

Ki m th c ó chu kì s ng riêng ể c a nóủ

Đ i Te s t ộ

Professional Tester

too familiar with code

Programmer

Analyst

System Designer

User

Test Team

Configuration Management Specialist

• Mục tiêu

– Xác nhận từ phía ngườisửdụng

• Điềukiện

– Kiểm tra hồi hệ thống và hồi quy hoàn tất – Người Quản lý cấu hình – Test data – Tài liệuhướng dẫncuối cùng đã sẵn sàng – Đã xét các thủ tục kiểm thử – Điều kiện thoát – Các thủ tục đặc biệt – Tiêu chuẩn chấp nhận phải được lập tài liệu

• Acceptance Testing • Người chịu trách nhiệm

3.4. Ki m tra c h p nh n ể ấ ậ

• Kỳ vọng:

– Xác nhận từ phía ngườ isử dụng – Kiểm tra thực thi được đánh giá lại – Kéo dài thời gian – Hướng dẫn cho người kiểm thử – Các yêu cầu không có khả năng kiểm thử – Rà soát bởi người tài trợ và NSD – Kế hoạch cho việc hiện thực

3.4. Ki m tra c h p nh n ể ấ ậ

• Regres s ion Tes t

3.5 Ki m tra h i quy ồ ể

• Tiến trình kiểm tra lại PM sau khi đã sửa

chữa chương trình.

• Regression test có thể thực hiện tại mọi

mức kiểm tra.

3.5. Ki m tra h i qui ồ ể

• Mục đích: – Định vị lỗi – Gia tăng tin cậy tính đúng chương trình – Bảo đảm chất lượng – Bảo đảm hoạt động liên tục – Kiểm tra tính đúng đắn của “phần mới” – Đảm bảo các phần không được sửa thực

hiện vẫn đúng.

3.5. Ki m tra h i qui ồ ể

• Một PM đang phát triển khi kiểm tra nó

chạy tốt các chức năng A, B và C.

• Thay đổi code của chức năng C:

– Nếu chỉ kiểm tra chức năng C thì chưa đủ, cần phải kiểm tra lại tất cả các chức năng khác liên quan đến chức năng C (A, B).

– Lý do là khi C thay đổi, nó có thể sẽ làm A và

B không còn làm việc đúng nữa.

3.5. Ki m tra h i qui – Ví d ồ ể ụ

• Rất tốn nhiều thời gian và công sức. • Không được phép bỏ qua vì có thể dẫn

đến tình trạng phát sinh hoặc tái xuất hiện những lỗi nghiêm trọng, mặc dù ta “tưởng rằng” những lỗi đó hoặc không có hoặc đã được kiểm tra và sửa chữa rồi.

3.5. Ki m tra h i qui ồ ể

• Kiểm thử vẩn là ma thuật, nhưng có nhiều

luật và mẹo có thể dùng được.

• Kiểm thử bao gồm unit testing, integration

testing và system testing

• Các mẫu thiết kế (Design Patterns) có thể

được dùng để kiểm tích hợp.

• Kiểm thử có chu kì sống riêng của nó.

Tóm t tắ

• Bài giảng này tham khảo và hiệu chỉnh từ: – Slide Kiểm định Phần mềm, Nguy n Qu c

ễ

ố