Bài giảng Bộ môn Công nghệ phần mềm - Bài 8: Phương pháp kiểm thử

Bài 8 - Phương pháp kiểm thử. Bài giảng cung cấp các kiến thức thuộc bộ môn công nghệ phần mềm như: Khái niệm kiểm thử, phương pháp thử, kỹ thuật thiết kế trường hợp thử, phương pháp thử các môđun... Mời các bạn cùng tham khảo.

Ph ươ ng pháp Ki m th  ph n  ể ử ầ

BM CNPM – Khoa CNTT – 

HVKTQS 10/2012

Khái ni m ệ

 Ki m th  ph n m m là ho t đ ng kh o sát th c ti n  ể ử ầ ề ạ ộ ả ự ễ

s n  ph m  hay  d ch  v   ph n  m m  trong  đúng  môi  ả ẩ ị ụ ầ ề

tr ườ ng chúng d  đ nh s  đ ự ị ẽ ượ c tri n khai nh m cung  ể ằ

c p cho ng ấ ườ i có l i ích liên quan nh ng thông tin v   ợ ữ ề

ch t  l ấ ượ ng  c a  s n  ph m  hay  d ch  v   ph n  m m  ủ ả ẩ ị ụ ầ ề

y. M c đích c a ki m th  ph n m m là tìm ra các 

ấ ụ ủ ể ử ầ ề

l i hay khi m khuy t ph n m m nh m đ m b o hi u  ỗ ế ế ầ ề ằ ả ả ệ

qu   ho t  đ ng  t i  u  c a  ph n  m m  trong  nhi u  ả ạ ộ ố ư ủ ầ ề ề ngành khác nhau.

 Có k  ho ch t t cho su t quá trình phát tri n ế ạ ố ố ể

 T m quan tr ng. Ki m th  chi m: ầ ọ ể ử ế

M c tiêu ki m th ụ ể ử

 3 m c tiêu ụ

 Ki m th  là m t quá trình v n hành chể ử ộ ậ ương trình đ  tìm ra l i.ể ỗ

 Thi t k  các ca ki m th  M t ca ki m th  t t là ca ki m th  có ế ế ể ử ộ ể ử ố ể ửxác su t cao trong vi c tìm ra m t l i ch a đấ ệ ộ ỗ ư ược phát hi nệ

 Nghiên c u thi t k  các ca ki m th  th ng l i. M t ca ki m th  ứ ế ế ể ử ắ ợ ộ ể ử

th ng l i là m t ca ki m th  làm l  ra đắ ợ ộ ể ử ộ ược ít nh t m t l i còn ấ ộ ỗ

ch a đư ược phát hi nệ

 M t ca ki m th  th ng l i làm l  ra khi m khuy t, đ ng th i  ộ ể ử ắ ợ ộ ế ế ồ ờ

mang l i các l i ích ph : ạ ợ ụ

 ch ng t  r ng các ch c năng ph m m m làm vi c tứ ỏ ằ ứ ầ ề ệ ương  ng v i ứ ớ

đ c t , ặ ả

 ch ng t  các yêu c u th c thi là phù h pứ ỏ ầ ự ợ

 có thêm các ch  s  đ  tin c y ph n m m và các ch  s  v  ch t ỉ ố ộ ậ ầ ề ỉ ố ề ấ

lượng ph n m m nói chungầ ề

 Ki m th  không th  ch ng minh để ử ể ứ ược vi c không có khi m khuy t, ệ ế ế

nó ch  có th  ch ng minh r ng khi m khuy t ph n m m hi n h uỉ ể ứ ằ ế ế ầ ề ệ ữ

Quan ni m sai ệ

 Ng ườ i phát tri n không tham gia ki m th ể ể ử

 Ph n m m đ ầ ề ượ c công b  m t cách r ng  ố ộ ộ rãi đ  ng ể ườ ạ ể i l  ki m th ử

Lý thuy t ki m th  d a trên các n i dung:  ế ể ử ự ộ

 Phát hi n khuy t t t qua quá trình ch y ch ệ ế ậ ạ ươ ng trình

 Thi t k  test case t  các ngu n khác nhau: requirement  ế ế ừ ồ specification, source code, and input and output domains 

 Test oracles đ ượ c s  d ng trong khi testing ử ụ

 Có đ   u tiên đ i v i các d  li u test cases ộ ư ố ớ ữ ệ

 Phân tích tính đ y đ  c a các test cases ầ ủ ủ

Nguyên t c c a vi c hoàn thành ki m th ắ ủ ệ ể ử

 Ki m th  hoàn thành hay ki m th  đ y đ  nghĩa là ể ử ể ử ầ ủ

 “Không có l i nào ch a đ ỗ ư ượ c phát hi n vào cu i giai  ệ ố

 Testing v i t p d  li u test nh  ít hi u qu ớ ậ ữ ệ ỏ ệ ả

 K t qu  c a m i l n test ph i đế ả ủ ỗ ầ ả ược so sánh v i ớ test oracle. 

 Xác đ nh đ u ra c a ch ị ầ ủ ươ ng trình không ph i nhi m v  d  dàng ả ệ ụ ễ

 Có nh ng ch ữ ươ ng trình không th  ki m th  ( ể ể ử non­testable programs). 

Ch ươ ng trình không th  ki m th  n u: ể ể ử ế

 Không có test oracle cho ch ươ ng trình.

 R t khó xác đ nh đ u ra đúng đ n.ấ ị ầ ắ

 Mi n ho c m c đ  c a các ho t đ ng test ề ặ ứ ộ ủ ạ ộ

 Chi ti t v  yêu c u tài nguyên ế ề ầ

 N  l c c n thi t ỗ ự ầ ế

 L ch th c hi n các công vi c ị ự ệ ệ

 Ngân sách

 M c tiêu c a ki m th  đ ụ ủ ể ử ượ c xác đ nh t  nhi u ngu n khác nhau ị ừ ề ồ

 M i test case đ ỗ ượ c thi t k  nh  là k t h p c a các thành ph n th  nghi m  ế ế ư ế ợ ủ ầ ử ệ modul (đ ượ c g i là test steps) ọ

 Test steps đ ượ c k t h p v i nhau đ  t o nên các test ph c t p h n ế ợ ớ ể ạ ứ ạ ơ

Chính sách ki m th ể ử

 Ch  có ki m th  đ y đ  m i làm ch ỉ ể ử ầ ủ ớ ươ ng trình không 

có l i. Tuy nhiên ki m th  đ y đ  là không kh  thi ỗ ể ử ầ ủ ả

 Chính sách ki m th  xác đ nh cách ti p c n đ ể ử ị ế ậ ượ c s   ử

d ng đ  l a ch n các d  li u system tests: ụ ể ự ọ ữ ệ

 T t c  các ch c năng đấ ả ứ ược truy c p qua các menus ph i đậ ả ược 

ki m th ;ể ử

 S  k t h p c a các ch c năng đự ế ợ ủ ứ ược truy c p qua menu nên đậ ược 

ki m th ;ể ử

 T t c  các ch c năng c n nh p d  li u input ph i đấ ả ứ ầ ậ ữ ệ ả ược ki m th  ể ử

v i c  input h p l  và không h p l ớ ả ợ ệ ợ ệ

Qui trình ki m th ể ử

 Hai l p đ ớ ượ c cung c p cho ti n trình ki m th : ấ ế ể ử

 (1) C u hình ph n m m:  ấ ầ ề B n Đ c t  yêu c u ph n m m, b n  ả ặ ả ầ ầ ề ả

Đ c t  thi t k , ch ng trình g c ặ ả ế ế ươ ố

 (2) C u hình ki m th :  ấ ể ử K  ho ch và th  t c ki m th , các công  ế ạ ủ ụ ể ử

c  ki m th  d  đ nh dùng, các ca ki m th  cùng k t qu  d   ụ ể ử ự ị ể ử ế ả ự

Phần mềm chỉnh sửa

Độ tin cậy dự đoán

 Ví d : 1 l i ch  ra s  sai bi t đ  0.01% gi a k t qu  trông đ i và th c t i có th   ụ ỗ ỉ ự ệ ộ ữ ế ả ợ ự ạ ể

m t 1 gi , 1 ngày hay 1 tháng đ  chu n đoán và s a ch a ấ ờ ể ẩ ử ữ

 Khi các k t qu  ki m th  đế ả ể ử ược thu th p và đánh giá thì ch t lậ ấ ượng và 

đ  tin c y ph n m m d n độ ậ ầ ề ầ ược kh ng đ nh. ẳ ị

 N u hay g p ph i l i nghiêm tr ng yêu c u s a đ i th t k  thì ch t l ế ặ ả ỗ ọ ầ ử ổ ế ế ấ ượ ng và đ   ộ tin c y là đáng ng  và c n ki m th  thêm ậ ờ ầ ể ử

 M t khác, n u các ch c năng ph n m m dặ ế ứ ầ ề ường nh  làm vi c đúng và ư ệ

l i g p ph i là d  s a thì có th  rút ra m t trong hai k t lu n:ỗ ặ ả ễ ử ể ộ ế ậ

 (1) Ch t l ấ ượ ng và đ  tin c y ph n m m ch p nh n đ ộ ậ ầ ề ấ ậ ượ c

 (2) Ki m th  không t ể ử ươ ng x ng đ  làm l  ra nh ng l i nghiêm tr ng.  ứ ể ộ ữ ỗ ọ

 N u vi c ki m th  không làm l  ra l i nào thì có th  hoài nghi r ng c u ế ệ ể ử ộ ỗ ể ằ ấhình ki m th  ch a để ử ư ược cân nh c đúng m c, các l i v n còn  n núp ắ ứ ỗ ẫ ẩtrong ph n m m và s  b  phát hi n b i ngầ ề ẽ ị ệ ở ười dùng

 Là trách nhi m c a m t đ i ki m th  đ c l p;ệ ủ ộ ộ ể ử ộ ậ

 Tests đượ ạc t o ra d a trên đ c t  h  th ng.ự ặ ả ệ ố

Phân chia giai đ an ọ

Component

Software developer Independent testing team

 Integration testing – Đ i ki m th  c n truy c p  ộ ể ử ầ ậ

đ n mã ngu n h  th ng. H  th ng đ ế ồ ệ ố ệ ố ượ c ki m th   ể ử

nh  các thành ph n đ ư ầ ượ c tích h p v i nhau ợ ớ

 Release testing – Đ i ki m th  ki m th  h  th ng  ộ ể ử ể ử ệ ố

nh  m t h p đen ư ộ ộ

T3 T2 T1

 Là v n đ  đ i v i c  hai cách ti p c n. Code b  sung có  ấ ề ố ớ ả ế ậ ổ

th  đ ể ượ c yêu c u đ  th c hi n các tests ầ ể ự ệ

 Release testing th ườ ng s  d ng ph ử ụ ươ ng pháp black­ box ho c functional testing ặ

 Ch  d a trên đ c t  h  th ng; ỉ ự ặ ả ệ ố

 Các Testers không c n bi t v  vi c h  th ng đ ầ ế ề ệ ệ ố ượ c hi n  ệ

th c nh  th  nào ự ư ế

 UAT: H  th ng đáp  ng các tiêu chí c a h p đ ng ệ ố ứ ủ ợ ồ

 BAT: H  th ng ch a, nh ng s  đáp  ng đ ệ ố ư ư ẽ ứ ượ c user acceptance test

Testing levels (ti p) ế

 M t ph n c a release testing có th  liên  ộ ầ ủ ể

quan đ n vi c ki m th  các tính ch t quan  ế ệ ể ử ấ

tr ng c a h  th ng nh  hi u su t và đ  tin  ọ ủ ệ ố ư ệ ấ ộ

c y ậ

 Các tests hi u su t th ệ ấ ườ ng liên quan đ n  ế

vi c l p k  ho ch cho m t lo t các bài ki m  ệ ậ ế ạ ộ ạ ể tra kh  năng ch u t i tăng d n cho đ n khi h   ả ị ả ầ ế ệ

th ng không th  th c hi n đ ố ể ự ệ ượ c n a ữ

 Là các th  nghi m h  th ng v ử ệ ệ ố ượ t quá kh  năng ch u t i c a nó.  ả ị ả ủ

Vi c th  nghi m quá t i th ệ ử ệ ả ườ ng giúp phát hi n các khuy t t t  ệ ế ậ

 Outcome ch  ph  thu c vào input hi n t i ỉ ụ ộ ệ ạ

  Đ i v i nh ng h  th ng có tr ng thái State­oriented: Ví d  nh  máy ố ớ ữ ệ ố ạ ụ ưATM 

 Test cases không đ n gi n. M t test case có th  bao g m m t chu i  ơ ả ộ ể ồ ộ ỗ

 Liên quan đ n vi c thi t k  các test cases  ế ệ ế ế (inputs và outputs) đ  ki m th  h  th ng ể ể ử ệ ố

 M c đích c a thi t k  test case là đ  t o ra  ụ ủ ế ế ể ạ

m t t p h p các bài test có hi u qu  trong  ộ ậ ợ ệ ả

 Sometime called  white­box testing

 Derivation of test cases according to  program structure. Knowledge of the  program is used to identify additional  test cases.

 Objective is to exercise all program 

statements (not all path combinations).

Structural testing

Testoutputs

Test da ta

DerivesTests

Mid-pointElements < Mid Elements > Mid

Equivalence class boundaries

Binary search ­ test cases

 Black­box testing còn g i là  ọ functional testing

 Ki m th  ch ể ử ươ ng trình qua k t qu  ch y Examines the program  ế ả ạ that is accessible from outside

 Nh p input cho ch ậ ươ ng trình và quan sát k t qu  đ u ra  ế ả ầ

Applies the input to a program and observe the externally visible  outcome

 Có th  áp d ng đ  ki m th  c  ch ể ụ ể ể ử ả ươ ng trình cũng nh  t ng  ư ừ

đ n v  c a nó ơ ị ủ

 Ph ươ ng pháp đ ượ c th c hi n   c p giao di n bên ngoài h   ự ệ ở ấ ệ ệ

th ng (không c n bi t bên trong h  th ng nh  th  nào) ố ầ ế ệ ố ư ế

 Đ ượ c th c hi n b i m t nhóm đ m b o ch t l ự ệ ở ộ ả ả ấ ượ ng ph n m m  ầ ề riêng bi t ệ

Black­box testing (ti p) ế

Các k  thu t c a Black­box testing ỹ ậ ủ

LIBSYS requirements

Initiate user search for searches for items that are known to

be present and known not to be present, where the set ofdatabases includes 1 database

Initiate user searches for items that are known to be presentand known not to be present, where the set of databasesincludes 2 databases

Initiate user searches for items that are known to be presentand known not to be present where the set of databasesincludes more than 2 databases

Select one database from the set of databases and initiateuser searches for items that are known to be present andknown not to be present

Select more than one database from the set of databasesand initiate searches for items that are known to be presentand known not to be present

 Test cases should be chosen from each  partition.

Between 10000 and 99999 Less than 1 0000 More than 99999

9999

10000 50000

100000 99999

Input v alues

Between 4 and 1 0 Less than 4 More than 1 0

3

4 7

11 10

Number of input v alues

procedure Search (Key : ELEM ; T: SEQ of ELEM;

Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

the element is not in the array

( not Found and

 Inputs which conform to the pre­

conditions.

 Inputs where a pre­condition does not  hold.

 Inputs where the key element is a 

member of 

the array.

 Inputs where the key element is not a  member of the array.

Search routine ­ input 

partitions

Search routine ­ input  partitions

 The objective of path testing is to 

ensure that the set of test cases is such  that each path through the program is  executed at least once.

 The starting point for path testing is a 

program flow graph that shows nodes  representing program decisions and 

arcs representing the flow of control.

 Statements with conditions are 

therefore nodes in the flow graph.

 Testing is an expensive process phase. Testing 

workbenches provide a range of tools to reduce the  time required and total testing costs.

File comparator

Test results report

 Scripts may be developed for user 

interface simulators and patterns for test  data generators.

 Test outputs may have to be prepared  manually for comparison.

 Special­purpose file comparators may 

be developed.

 Equivalence partitioning is a way of discovering test  cases ­ all cases in a partition should behave in the  same way.

 Structural analysis relies on analysing a program and  deriving tests from this analysis.

 Test automation reduces testing costs by supporting  the test process with a range of software tools.

Tài li u tham kh o ệ ả

 R. Pressman, K  ngh  ph n m m. T p 1, 2,  ỹ ệ ầ ề ậ

3. NXB Giáo d c, Hà N i, 1997 (Ng ụ ộ ườ ị i d ch:  Ngô Trung Vi t) ệ

Practioner’s  Approach.  5th  Ed.,  McGraw­Hill, 

2001. Chapters 17, 18.

Ed., Addison­Wesley, 1995. Chapter 20.