ươ

ử

ầ

Ph

ể ng pháp Ki m th  ph n  m mề

BM CNPM – Khoa CNTT –  HVKTQS 10/2012

Outline

ể

ử

ử

ợ ng h p th

ệ  Khái ni m ki m th ử ươ ng pháp th  Ph ế ế ườ ậ ỹ t k  tr  K  thu t thi ử ươ ng pháp th  các môđun  Ph

Khái ni mệ

ả

ầ

ễ

ự

ụ

ử ẩ

ề ể

ằ

ể ả ườ ấ

ề ị ự ị ng chúng d  đ nh s  đ ợ ườ i có l ả ủ

ụ

ề

ẩ

ầ

ị

ủ

ể

ế

ề

ả

ầ

ả

ệ ề

ủ

ề

ầ

ộ

ạ ộ  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 c tri n khai nh m cung  ề ữ i ích liên quan nh ng thông tin v   c p cho ng ấ ượ ng  c a  s n  ph m  hay  d ch  v   ph n  m m  ch t  l ề ầ ử ụ ấ 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.

ầ

ử

ầ

ể Lý do c n ki m th  ph n  m mề

ố

ư

ượ

 Mong mu n thu đ

ề c ph n m m nh  là m t  ạ ộ

ớ ấ ạ

ỗ i

ạ

ể

ố

t cho su t quá trình phát tri n ế

ử

ể

ứ

ể

ổ

ổ

ng t

ưở  V i ph n m m  nh h ế

3 d n 4 l n t ng chi phí khác

ộ

ộ ầ ộ ệ ố ầ ử ph n t  trong m t h  th ng ho t đ ng l n. ả ả ế ạ  H n ch  chi phí ph i tr  cho các th t b i do l gây ra sau này ố ế  Có k  ho ch t ọ ầ  T m quan tr ng. Ki m th  chi m:   40% t ng công s c phát tri n ể ờ  >=30% t ng th i gian phát tri n ạ ớ ề ả ầ ớ i sinh m ng chi  ầ ổ ể ấ ừ phí có th  g p t ạ i c ng l

ụ

ể

ử

M c tiêu ki m th

ụ  3 m c tiêu

ộ ươ i.

ậ ộ

ệ ể ộ ỗ

ế

ế

ộ

ồ

ờ

ra khi m khuy t, đ ng th i

i làm l

ượ ử ộ ứ ể i là m t ca ki m th  làm l ỗ ể ng trình đ  tìm ra l ể ử ử ố ử t là ca ki m th  có  t k  các ca ki m th . M t ca ki m th  t ượ ư ệ i ch a đ c phát hi n ử ể ợ ể i. M t ca ki m th   t k  các ca ki m th  th ng l ộ ỗ i còn ộ ấ c ít nh t m t l ử ắ  ra đ

ể ử  Ki m th  là m t quá trình v n hành ch ể ế ế  Thi ấ xác su t cao trong vi c tìm ra m t l ế ế  Nghiên c u thi ộ ợ ắ th ng l ệ ượ ư c phát hi n ch a đ ử ắ ợ ể  M t ca ki m th  th ng l ụ ợ i ích ph : i các l ứ ỏ ằ ệ ươ ứ ề ầ ớ r ng các ch c năng ph m m m làm vi c t ng  ng v i

ỏ ự  các yêu c u th c thi là phù h p

ộ ạ mang l ứ  ch ng t ặ ả đ c t ,  ứ  ch ng t  có thêm các ch  s  đ  tin c y ph n m m và các ch  s  v  ch t

ỉ ố ề ợ ề ấ ầ

ầ l

ượ ể ử ể ứ ế ệ c vi c không có khi m khuy t,

ầ ỉ ố ộ ậ ề ng ph n m m nói chung  Ki m th  không th  ch ng minh đ ứ ể ằ ỉ ượ ế ữ ề ệ ế ầ ế 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 ề ượ ầ  Ph n m m đ ườ ạ ể ể i l rãi đ  ng ử

ượ

ầ

c ph n

ể ề

ể

ể

ử i phát tri n không tham gia ki m th c công b  m t cách r ng   ki m th ứ ể  Ki m th  có th  ch ng minh đ ế ế m m không có khi m khuy t ử ỗ không tìm ra l

ử  Phép ki m th  thành công là ki m th   i nào ử ộ ầ

ỉ ầ

ể  Ch  c n ki m th  m t l n

Basic Concepts in Testing Theory

ể

ế

ử ự

ươ

ạ

Lý thuy t ki m th  d a trên các n i dung:  ng trình

ệ  Phát hi n khuy t t ế ế t k  test case t  Thi

ộ ế ậ t qua quá trình ch y ch ồ ừ  các ngu n khác nhau: requirement  specification, source code, and input and output domains  of programs

ộ ậ

ự

ừ

 L a ch n m t t p con các test case t

ộ  toàn b  input

ế ượ ự

ữ ệ

ể

ọ

ọ domain ệ

ả  Tình hi u qu  trong chi n l

c l a ch n d  li u ki m

thử

ượ

ử ụ

ố ớ ầ

ủ ủ

c s  d ng trong khi testing  Test oracles đ ữ ệ ộ ư  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

Failure, Error, Fault and Defect

 Failure

  A failure is said to occur whenever the external behavior of a system

 Error

  An error is a state of the system.   An error state could lead to a failure in the absence of any corrective

does not conform to that prescribed in the system specification

 Fault

 A fault is the adjudged cause of an error

 Defect

 It is synonymous of fault  It a.k.a. bug

action by the system

ắ ủ

ể

ệ

ử

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

c phát hi n vào cu i giai

ầ ớ

ố ớ

ả

ạ ể

 Ki m th  hoàn thành là khó kh  thi đ i v i ph n l n

i nào ch a đ ử ể đo n ki m th ” ử ệ ố

ủ

ươ

ớ

các h  th ng ữ ệ  Vùng d  li u inputs c a ch

ng trình quá l n

 Valid inputs  Invalid inputs

ế ế

ữ ệ

ử

ứ

ể

ề

ấ

t k  các d  li u ki m th  hoàn thành là v n đ  ph c

 Thi t pạ

ề ạ

ả

ườ

ử ệ ố

ể

ạ

ấ  Khó kh  thi v n đ  t o môi tr

ng đ  ch y th  h  th ng

Adequacy of Testing

 Reality:  New  test  cases,  in  addition  to  the  planned  test  cases,  are

designed while performing testing. Let the test set be T.

 If a test set T does not reveal any more faults, we face a dilemma:

 P is fault­free. OR  T is not good enough to reveal (more) faults.

 Need for evaluating the adequacy (i.e. goodness) of T.  Some ad hoc stopping criteria

 Allocated time for testing is over.  It is time to release the product.  Test cases no more reveal faults.

ớ ạ

ủ

ể

ử

Gi

i h n c a ki m th

ử  Testing can reveal the presence of faults, but not their absence: Ki m th

ả ằ

ể ả

ư

ươ

ể

ệ ỗ

i, nh ng không th  đ m b o r ng ch

ể ng trình không có

có th  phát hi n l iỗ l ữ ệ

ủ ậ ổ ế  Nh n xét n i ti ng c a Dijkstra

 D  li u ki m th  th

ể ử ườ ầ ấ ữ ệ ậ ộ ỏ ỉ ng ch  là m t ph n r t nh  trong t p d  li u

ố ậ

ả ủ

ớ ậ

ữ ệ

ệ

ề

ỏ

 Testing v i t p d  li u test nh  gây ra m i b n tâm v  tính hi u qu  c a

ể

ử ki m th .

ệ

ớ ậ

input

ỗ ầ

ươ

ủ

ươ

ả ng trình không th  ki m th  (

ỏ ớ test oracle.  ả ượ ụ ễ ng trình không ph i nhi m v  d  dàng. ử non­testable programs).

ể ể

Ch

ươ

ả ữ ệ  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 đ ầ  Xác đ nh đ u ra c a ch  Có nh ng ch ươ  Không có test oracle cho ch

c so sánh v i  ệ

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

ả ủ ị ể ể ữ ử ế ng trình không th  ki m th  n u: ng trình. ắ ầ ấ ị

Test Planning and Design

ứ ố ể ự

ự ẵ

ượ

ự ổ

ch c t

ệ t đ  th c hi n các test

c s  s n sàng và s  t ấ

 M c đích là có đ  M t test plan cung c p:

ẽ ượ

ả

ế

ụ ộ  Framework ộ ậ

ợ

ưở

ự ệ

ng, s  ki n hay hoàn c nh mà trong đó các test s  đ

c ti n hành

ạ ộ

ặ

ứ ầ

 M t t p h p các ý t ạ  Ph m vi ề ộ ủ  Mi n ho c m c đ  c a các ho t đ ng test ế ề t v  yêu c u tài nguyên ầ

ế t

 Chi ti ỗ ự  N  l c c n thi ệ ị 

ự

ệ

L ch th c hi n các công vi c

ị

ồ  nhi u ngu n khác nhau

c xác đ nh t

 Ngân sách ụ ỗ

ử ượ ế ế

ừ ế ợ

ề ủ

ử

ư

ệ

ầ

t k  nh  là k t h p c a các thành ph n th  nghi m

ứ ạ

ể ạ

ớ

ơ

ể ủ  M c tiêu c a ki m th  đ ượ  M i test case đ c thi ọ c g i là test steps) ế ợ ượ c k t h p v i nhau đ  t o nên các test ph c t p h n

ượ modul (đ Test steps đ

ể

ử

Chính sách ki m th

ể

ủ ớ

ươ

ỗ

ủ

ỉ có l

ử ầ  Ch  có ki m th  đ y đ  m i làm ch ể ử

ng trình không  ả ượ

ế

ể

ử c s

ể ự

ọ

ử ầ i. Tuy nhiên ki m th  đ y đ  là không kh  thi ị ữ ệ ậ c truy c p qua các menus ph i đ

ậ  Chính sách ki m th  xác đ nh cách ti p c n đ ụ d ng đ  l a ch n các d  li u system tests: ượ  T t c  các ch c năng đ

ả ượ ứ c

 S  k t h p c a các ch c năng đ

ủ ứ ượ ậ ượ c truy c p qua menu nên đ c

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

ứ ợ ệ ậ ợ ệ ấ ả ử ể ki m th ; ự ế ợ ử ể ki m th ; ấ ả ớ ả v i c  input h p l và không h p l ữ ệ .

ể

ử

Qui trình ki m th

ể

ầ

ề

ầ

ả

ầ  yêu c u ph n m m, b n

ượ  Hai l p đ  (1) C u hình ph n m m:

ử ế c cung c p cho ti n trình ki m th : ặ ả B n Đ c t ố

ế ế

thi

t k , ch ể

ử

ế

ể

 (2) C u hình ki m th :

ấ ề ả ươ ng trình g c ử K  ho ch và th  t c ki m th , các công  ủ ụ ử

ử ự ị

ể

ế

ớ ấ ặ ả Đ c t ạ ấ ả ự ụ ể c  ki m th  d  đ nh dùng, các ca ki m th  cùng k t qu  d   ki n.ế

Cấu hình phần mềm

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

Kiểm thử

Gỡ lỗi

Mô hình độ tin cậy

Đánh giá

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

Cấu hình kiểm thử

ể

ử

Qui trình ki m th

 Ki m th  đ

ế ể ấ ả ử ượ c đánh giá b ng

ằ ỡ ỗ ắ ầ ả ự ế ả ượ ệ ỗ ế c ti n hành và t ớ ế i b t đ u ệ i, vi c g  l

ế t c  các k t qu  đ cách so sánh v i k t qu  d  ki n. Khi phát hi n l đ

 Ti n trình g  l

ệ ộ

ự

ữ

ế

ợ

ỉ

ự ạ

t đ  0.01% gi a k t qu  trông đ i và th c t

ể i có th

ả ử

ữ

ẩ

ệ ậ ị ờ ườ ự ế ượ c th i gian nên vi c l p l ch i th ng không d  ki n đ

ấ ượ ng và

ẳ ậ

ế ế

ử

ế

ổ

ấ ượ

ộ ng và đ

ể

ầ

ậ

ể ử ượ ậ c thu th p và đánh giá thì ch t l ượ ầ c kh ng đ nh.  ầ ọ tin c y là đáng ng  và c n ki m th  thêm. ề ứ

ử ầ

ượ c ti n hành.  ế ỡ ỗ ử ở ể ki m th  tr  nên khó khăn. ỗ ụ  Ví d : 1 l i ch  ra s  sai bi ờ ấ , 1 ngày hay 1 tháng đ  chu n đoán và s a ch a. m t 1 gi ế  Khi các k t qu  ki m th  đ ầ đ  tin c y ph n m m d n đ ặ ị i nghiêm tr ng yêu c u s a đ i th t k  thì ch t l

ế ườ ư ả ể ề ộ ả ỗ  N u hay g p ph i l ờ  M t khác, n u các ch c năng ph n m m d

ề

ậ

c

ứ

ọ

ng nh  làm vi c đúng và  ậ ế l

ế

ử ư ằ ẩ ệ ể ấ i v n còn  n núp

ể  ra l ắ ệ

ệ ặ ộ ễ ử ả ể ỗ ặ i g p ph i là d  s a thì có th  rút ra m t trong hai k t lu n: ậ ộ ượ ấ ầ ấ ượ ng và đ  tin c y ph n m m ch p nh n đ (1) Ch t l ộ ỗ ữ ươ ử ể i nghiêm tr ng.   ra nh ng l ng x ng đ  làm l (2) Ki m th  không t ỗ ộ ể i nào thì có th  hoài nghi r ng c u   N u vi c ki m th  không làm l ử ỗ ẫ ề ượ ẽ ị ứ ườ ầ hình ki m th  ch a đ trong ph n m m và s  b  phát hi n b i ng ể c cân nh c đúng m c, các l ở i dùng.

Testing Levels

ầ ộ ậ ng trình đ c l p;

 Component testing (Unit testing) ừ ử ể  Ki m th  các t ng thành ph n ch ườ  Thông th ầ

ể

ng đây là trách nhi m c a các thành viên phát tri n các  ợ ạ ừ ộ ố ườ ệ ố ự ỳ ươ ủ ng h p h  th ng c c k  quan

ọ

 System testing

ượ ạ ừ ủ ệ ể ệ thành ph n (ngo i tr  m t s  tr tr ng);  Tests đ c t o ra t kinh nghi m c a các thành viên phát tri n.

 Ki m th  các nhóm thành ph n ch

ể ươ ầ ớ ng trình đ ợ c tích h p v i

ử ể ạ ặ ượ ệ ố nhau đ  t o ra các h  th ng ho c h  th ng con;

ộ ộ ể ủ

 Là trách nhi m c a m t đ i ki m th  đ c l p; ự c t o ra d a trên đ c t  Tests đ

ệ ượ ạ ặ ả ệ ố ệ ố ử ộ ậ  h  th ng.

Phân chia giai đ anọ

Component testing

System testing

Software developer

Independent testing team

System testing

ầ

ể  Liên quan đ n vi c tích h p các thành ph n đ

ặ

ệ ạ t o ra h  th ng ho c h  th ng con.

ế ệ ố ự

ợ ệ ố ủ

 Có th  có s  tham gia c a khách hàng trong

ể ạ giai đo n này.

 Hai phases:

ộ ể

 Integration testing – Đ i ki m th  c n truy c p

ế

ồ

ư

ử ầ ượ ệ ố đ n mã ngu n h  th ng. H  th ng đ ớ ầ nh  các thành ph n đ

ậ ử ể c ki m th   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.

Integration testing

ế

ệ

ừ

 Liên quan đ n vi c xây d ng h  th ng t

ủ

các  ấ

ề

ệ ố ử ể ợ

vi c tích h p.

ệ ố

ư

 Phát tri n b  khung c a h  th ng và đ a vào đó các

ộ ầ ươ thành ph n t

ự ể ầ thành ph n c a nó và ki m th  đ  tìm các v n  ừ ệ ể đ  có th  phát sinh t  Top­down integration ủ ể ứ ng  ng.  Bottom­up integration ợ

ạ ầ

 Tích h p các thành ph n h  t ng sau đó là các thành

ứ ả

ị

ỗ

ệ ố i, h  th ng

 Đ  đ n gi n hóa vi c tìm ra v  trí l ợ

ệ ầ

ượ

ầ

ầ ầ ph n ch c năng chính. ể ơ nên đ

c tích h p d n d n.

Incremental integration testing

A

T1

T1

A

T1

T2

A

B

T2

T2

T3

B

T3

B

C

T3

T4

C

T4

D

T5

Test sequence 1

Test sequence 2

Test sequence 3

ủ Testing approaches c a integration testing

 Architectural validation

ố ơ

ể

ệ

ỗ

t h n đ  phát hi n ra các l

i

 Top­down integration testing t ệ ố

ế

ki n trúc h  th ng.  System demonstration

ộ ự

ễ

ệ ố

ạ

ạ

ạ

ớ

 Top­down integration testing cho phép m t s  trình di n  i giai đo n s m trong quy trình phát

ữ h u h n h  th ng t tri n.ể

 Test implementation ơ

ườ

ễ

ớ

 Th

ng d  dàng h n v i bottom­up integration testing.

ế

ậ

ổ

 Là v n đ  đ i v i c  hai cách ti p c n. Code b  sung có

ể ự

ệ

 Test observation ấ ể ượ th  đ

ề ố ớ ả ầ c yêu c u đ  th c hi n các tests.

Release testing

ệ ố

ể

ả

ẽ ử ộ  Là quá trình ki m th  m t phiên b n h  th ng s

đ

c bàn giao cho khách hàng.

ượ ụ

ủ

ấ

ề ự

ự ự  M c tiêu chính là là tăng s  t ợ ể

ệ ố

ủ

ớ

ầ

ủ

ươ

ườ

ử ụ ng s  d ng ph

ng pháp black­

tin c a nhà cung c p  (nhà phát tri n) v  s  phù h p c a h  th ng v i các  yêu c u c a nó.  Release testing th ặ ỉ ự

ặ ả ệ ố ầ

ế ề ệ

ệ ố

ượ

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.

Testing levels (detailed) Testing levels (detailed)

ươ

ộ ậ

ủ ụ

ư

ươ

ơ

ng trình đ c l p nh  các th  t c, hàm, ph

ng

 Unit testing ử ộ

ể ứ

ị  Ki m th  các đ n v  ch ẽ th c m t cách riêng r

ơ

ố

ị

ươ

 Ki m th  vi c ghép n i các đ n v  ch

ng trình

ể ử ệ  System testing

ộ ả ể

ử ộ

ư

ứ

ả

ồ

 Bao g m m t d i ki m th  r ng nh  tính ch c năng, kh  năng ch u t

ị ả i

 Acceptance testing

ề ệ ố

ỳ ọ

ủ

ữ

ể

ạ

 Khách hàng ki m tra nh ng k  v ng c a mình v  h  th ng  Hai lo i acceptance testing

 UAT (User acceptance testing)  BAT (Business Acceptance Testing)

ứ

ủ

ồ

ệ ố ệ ố

ợ ượ

ứ

ư

ẽ

 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

Integration testing

Testing levels (ti p)ế

Performance testing

ộ

 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.ậ

ấ

ệ

ế

ng liên quan đ n  ể ộ

ạ

ạ

ệ ậ ả

ị ả ể ự

ệ

ố

ườ  Các tests hi u su t th ế vi c l p k  ho ch cho m t lo t các bài ki m  ầ ệ ế i tăng d n cho đ n khi h   tra kh  năng ch u t ữ ượ c n a. th ng không th  th c hi n đ

Stress testing

ử

ệ

ả

i c a nó.  ế ậ

ệ ố ả i th

ị ả ủ ượ t quá kh  năng ch u t ệ ng giúp phát hi n các khuy t t

t

 Là các th  nghi m h  th ng v ử ườ ệ Vi c th  nghi m quá t ệ ố c a h  th ng.

ệ ủ ậ

ấ

ệ ố

ề ư ạ ủ

ệ ố

ỏ

ị

ớ ạ

ấ

ậ

ấ

ự ấ i h n m t

ụ ữ ệ

ệ ố

ố ớ

 T p trung vào v n đ  h  h i c a h  th ng. Không có h  th ng  ể ể Stress testing ki m tra s  m t mát  nào không th  không h ng.  ữ ệ ượ ể d ch v  và d  li u không th  ch p nh n đ c (gi ụ ị mát d  li u và d ch v ). ệ ặ  Stress testing đ c bi ệ ố ữ

ụ

ổ

ả

ạ

ộ

ị

ọ t quan tr ng đ i v i các h  th ng phân  ư ễ ị ụ tán là nh ng h  th ng d  b  s p đ  nhanh chóng, ví d  nh   i. m t m ng khi b  quá t

What is a Test Case?

 Test Case là m t c p  ệ ố 

ộ ặ

ả

ữ ụ ạ

 Outcome ch  ph  thu c vào input hi n t

ệ ạ i

ố ớ  Đ i v i nh ng h  th ng State­less (phi tr ng thái): (ví d  compiler là  ộ ệ ố m t h  th ng)  Test cases r t đ n gi n ộ

ấ ơ ỉ ụ ệ ố

ố ớ ư ữ ụ ạ

ể

ả

ơ

ộ

ồ

ộ

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

ụ

ả

ạ

ộ

ệ ạ ủ

ệ ố

ệ ạ

i c a h  th ng và input hi n t

i

 Outcome ph  thu c c  vào tr ng thái hi n t  ATM example:

< check balance, $500.00 >,

 < withdraw, “amount?” >,  < $200.00, “$200.00” >,   < check balance, $300.00 >

Đ i v i nh ng h  th ng có tr ng thái State­oriented: Ví d  nh  máy  ATM

Test case design

ế

ệ

ế ế

 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  ế ậ ể t. th m đ nh và ki m tra khuy t t ế ế ế

ậ

t k  test case:

 M t s  cách ti p c n khi thi ấ

ụ ộ ậ ị ẩ ộ ố ự ự

ầ

ớ

 D a vào c u trúc (Structural testing).  D a trên yêu c u (Requirements­based testing);  Phân l p (Partition testing);

Structural testing

 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

Test da ta

Tests

Derives

Component code

Test outputs

Binary search ­ equiv. partitions

 Pre­conditions satisfied, key element in array.  Pre­conditions satisfied, key element not in

array.

 Pre­conditions unsatisfied, key element in array.  Pre­conditions unsatisfied, key element not in array.  Input array has a single value.  Input array has an even number of values.  Input array has an odd number of values.

Binary search equiv. partitions

Equivalence class boundaries

Elements < Mid

Elements > Mid

Mid-point

Binary search ­ test cases

Binary search flow graph

1

2

3

4

bottom > top bottom > top

while bottom <= top

5

6

elemArray [mid] != key

7

11

elemArray [mid] < key

elemArray [mid] > key

elemArray [mid] = key

8

12

13

9

14

10

Black­box testing

ọ

ử

ể

ả

 Black­box testing còn g i là  ươ  Ki m th  ch

ạ ng trình qua k t qu  ch y Examines the program

functional testing ế 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ó

ệ ở ấ

ệ

ệ  c p giao di n bên ngoài h

c th c hi n

ư ế

ượ ng pháp đ ầ th ng (không c n bi

ấ ượ

ệ

ề

ả

ở

ế  Đ c th c hi n b i m t nhóm đ m b o ch t l

ự ệ ố t bên trong h  th ng nh  th  nào) ầ ả ộ ng ph n m m

ươ  Ph ố ượ riêng bi

ự tệ

Black­box testing (ti p)ế

ậ ủ

ỹ

Các k  thu t c a Black­box testing

Requirements based testing

 A general principle of requirements

engineering is that requirements should  be testable.

 Requirements­based testing is a

validation testing technique where you  consider each requirement and derive a  set of tests for that requirement.

LIBSYS requirements

LIBSYS tests (cid:0)

(cid:0)

(cid:0)

Initiate user search for searches for items that are known to be present and known not to be present, where the set of databases includes 1 database. Initiate user searches for items that are known to be present and known not to be present, where the set of databases includes 2 databases Initiate user searches for items that are known to be present and known not to be present where the set of databases includes more than 2 databases.

(cid:0) Select one database from the set of databases and initiate user searches for items that are known to be present and known not to be present.

(cid:0) Select more than one database from the set of databases

and initiate searches for items that are known to be present and known not to be present.

Partition testing

 Input data and output results often fall

into different classes where all members  of a class are related.

 Each of these classes is an equivalence  partition or domain where the program  behaves in an equivalent way for each  class member.

 Test cases should be chosen from each

partition.

Equivalence partitioning

Invalid inputs

Valid inputs

System

Outputs

Equivalence partitions

3

11

4

7

10

Less than 4

Between 4 and 1 0

More than 1 0

Number of input v alues

9999

100000

10000

50000

99999

Less than 1 0000

Between 1 0000 and 99999

More than 99999

Input v alues

Search routine specification

procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;

Pre-condition

-- the sequence has at least one element T’FIRST <= T’LAST

Post-condition

-- the element is found and is referenced by L ( Found and T (L) = Key)

or

-- the element is not in the array ( not Found and not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))

Search routine ­ input  partitions

 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

Path testing

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

Independent paths

 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14  1, 2, 3, 4, 5, 14  1, 2, 3, 4, 5, 6, 7, 11, 12, 5, …  1, 2, 3, 4, 6, 7, 2, 11, 13, 5, …  Test cases should be derived so that all

of these paths are executed

 A dynamic program analyser may be  used to check that paths have been  executed

Test automation

 Testing is an expensive process phase. Testing

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

 Systems such as Junit support the automatic

execution of tests.

 Most testing workbenches are open systems

because testing needs are organisation­specific.  They are sometimes difficult to integrate with closed

design and analysis workbenches.

A testing workbench

Specification

Test da ta generator

Test da ta

Oracle

Source code

Test mana ger

Test r esults

Dynamic analyser

Program being tested

Test predictions

Simulator

Execution report

File comparator

Repor t generator

Test results report

Testing workbench adaptation

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

Key points

 Testing can show the presence of faults in a system;

it cannot prove there are no remaining faults.

 Component developers are responsible for  component testing; system testing is the  responsibility of a separate team.

 Integration testing is testing increments of the

system; release testing involves testing a system to  be released to a customer.

 Use experience and guidelines to design test cases

in defect testing.

Key points

 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,  i d ch:

3. NXB Giáo d c, Hà N i, 1997 (Ng Ngô Trung Vi

ỹ ụ t).ệ

 R.  Pressman,  Software  Engineering:  A  Practioner’s  Approach.  5th  Ed.,  McGraw­Hill,  2001. Chapters 17, 18.

 I.  Sommerville,  Software  Engineering.  5th

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