• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
automated+software+testing+tools.pdf
 

automated+software+testing+tools.pdf

on

  • 1,686 views

 

Statistics

Views

Total Views
1,686
Views on SlideShare
1,642
Embed Views
44

Actions

Likes
0
Downloads
43
Comments
0

1 Embed 44

http://localhost 44

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    automated+software+testing+tools.pdf automated+software+testing+tools.pdf Document Transcript

    • ‫داﻧﺸﮑﺪهي ﻣﻬﻨﺪﺳﯽ‬ ‫ﮔﺮوه ﻣﻬﻨﺪﺳﯽ ﮐﺎﻣﭙﯿﻮﺗﺮ- ﻧﺮماﻓﺰار‬‫ﺑﺮرﺳﯽ اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار‬‫ﺗﻬﯿﻪ ﮐﻨﻨﺪه: ﮔﺮوه ﺗﺨﺼﺼﯽ آزﻣﺎﯾﺸﮕﺎه ﻓﻨﺎوري وب‬ ‫آﺑﺎن 7831‬
    • ‫‪II‬‬ ‫ﭘﯿﺸﮕﻔﺘﺎر‬‫ﭘﯿﭽﯿﺪﮔﯽ و اﻧﺪازهي ﻧﺮماﻓﺰارﻫﺎي ﮐﺎﻣﭙﯿﻮﺗﺮي ﻫﻤﻮاره رو ﺑﻪ اﻓﺰاﯾﺶ اﺳﺖ. ﻫﺮ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاري ﻣﺨﺎﻃﺒـﺎن‬‫ﺧﺎﺻﯽ دارد. ﺑﺮاي ﻣﺜﺎل ﯾﮏ ﻧﺮماﻓﺰار ﺑﺎﻧﮑﯽ ﻣﺨﺎﻃﺒـﺎﻧﯽ ﮐـﺎﻣﻼً ﻣﺘﻔـﺎوت از ﻣﺨﺎﻃﺒـﺎن ﯾـﮏ ﻧـﺮماﻓـﺰار ﺑـﺎزي‬‫ﮐﺎﻣﭙﯿﻮﺗﺮي دارد. ﺑﻨﺎﺑﺮاﯾﻦ، زﻣﺎﻧﯿﮑﻪ ﺳﺎزﻣﺎﻧﯽ ﯾﮏ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاري را ﻣﯽﻧﻮﯾـﺴﺪ ﯾـﺎ ﺧﺮﯾـﺪاري ﻣـﯽﮐﻨـﺪ،‬‫ﻣﻨﻄﻘﺎً ﺑﺎﯾﺪ اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﮐﻨﺪ ﮐﻪ آﯾﺎ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاري ﺑﺮاي ﮐﺎرﺑﺮان او، ﻣﺨﺎﻃﺒﺎن او، ﺧﺮﯾﺪاران، و ﺳﺎﯾﺮ‬‫ذﯾﻨﻔﻌﺎن ﻗﺎﺑﻞ ﭘﺬﯾﺮش ﻫﺴﺖ ﯾﺎ ﻧﻪ. ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪ ﺗﻼش ﺑﺮاي اﯾﻦ ﮔﻮﻧﻪ ارزﯾﺎﺑﯽ ﻫﺎﺳـﺖ. ﺑـﻪ ﻋﺒـﺎرت‬‫دﯾﮕﺮ ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪ اﻣﺘﺤﺎن ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي ﺑﺮاي ﮐﺸﻒ ﺧﻄﺎﻫﺎ و ﺗﻀﻤﯿﻦ اﯾﻨﮑﻪ ﻧﯿﺎزﻣﻨﺪيﻫـﺎي‬ ‫ﻣﻮﺟﻮد را ﺑﺮآورده ﻣﯽﮐﻨﺪ و ﺑﺎ ﺳﺨﺖاﻓﺰار ﻣﺸﺘﺮي ﺳﺎزﮔﺎر اﺳﺖ.‬‫اﻣﺮوزه ﺳﺎزﻣﺎنﻫﺎي ﻧﺮماﻓﺰاري زﻣﺎن و ﻣﻨﺎﺑﻊ زﯾﺎدي را در ﺗﺤﻠﯿﻞ و ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻـﺮف ﻣـﯽﮐﻨﻨـﺪ. از ﻧﻈـﺮ‬‫ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻧﻮﺷﺘﻦ ﮐﺪﻫﺎي ﺗﺴﺖ، ﺑﻪ ﺧﻮدي ﺧﻮد، ﻣﺜﻞ ﺗﻮﺳﻌﻪ ﺧﻮد ﻣﺤﺼﻮل وﻗﺖ ﮔﯿﺮ و ﮔﺮان اﺳﺖ.‬‫ﺑﻨﺎﺑﺮاﯾﻦ راهﺣﻠﯽ ﺑﺮاي ﺧﻮدﮐﺎر ﮐﺮدن ﺗﺴﺖ ﻧﺮم اﻓﺰار ﻏﯿﺮﻗﺎﺑﻞ اﺟﺘﻨﺎب اﺳﺖ. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﻧﺴﺒﺖ ﺑﻪ‬‫ﺗﺴﺖ دﺳﺘﯽ ﺑﺮﺗﺮيﻫﺎي زﯾﺎدي دارد. در ﺟﺎﻣﻌﻪ اﻣﺮوزي ﭘﺮوژهﻫﺎي ﻧﺮماﻓﺰاري ﭘﯿﭽﯿﺪه ﻫﺴﺘﻨﺪ و ﺑـﺮاي ﺣـﻞ‬‫ﻣﺴﺎﺋﻞ ﭘﯿﭽﯿﺪه ﻃﺮاﺣﯽ ﻣﯽﺷﻮﻧﺪ. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﺑﺎﻋﺚ ﻣﯽ ﺷﻮد ﮐﻪ ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن زﻣﺎن ﺑﯿـﺸﺘﺮي‬‫ﺑﺮاي ﺗﻤﺮﮐﺰ ﺑﺮروي دﯾﮕﺮ ﺟﻨﺒﻪﻫﺎ داﺷﺘﻪ ﺑﺎﺷﻨﺪ و ﺑﺘﻮاﻧﻨﺪ ﺧﻄﺎﻫﺎي ﻧـﺮماﻓـﺰار را ﺑـﻪ ﺻـﻮرت ﻣـﺆﺛﺮﺗﺮي رﻓـﻊ‬‫ﻧﻤﺎﯾﻨﺪ. ﻋﻼوه ﺑﺮاﯾﻦ، ازآﻧﺠﺎﯾﯽ ﮐﻪ ﺗﺴﺖﻫﺎ را ﻣﯽﺗﻮان در ﻫﺮ زﻣﺎن و ﺑﻪ ﻫﺮ ﺗﻌﺪاد دﻓﻌﺎﺗﯽ اﺟﺮا ﮐﺮد، ﻣﯽﺗـﻮان‬‫از ﺗﺴﺖﻫﺎي ﻗﺒﻠﯽ اﺳﺘﻔﺎدهي ﻣﺠﺪد ﻧﻤﻮد. و ﺑﻪ اﯾﻦ ﺗﺮﺗﯿﺐ ﮐﺎراﯾﯽ ﺗﺴﺖ را اﻓﺰاﯾﺶ و زﻣﺎن ﺗـﺴﺖ را ﮐـﺎﻫﺶ‬ ‫داد. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﻧﺮماﻓﺰار زﺣﻤﺖ و ﭘﯿﭽﯿﺪﮔﯽ اﻧﺠﺎم ﺗﺴﺖ را ﮐﺎﻫﺶ ﻣﯽدﻫﺪ.‬‫در اﯾﻦ ﻣﺘﻦ ﭘﺲ از اراﺋﻪي ﻣﻘﺪﻣﺎﺗﯽ در ﻣﻮرد ﺗﺴﺖ ﻧﺮماﻓﺰار و اﻫﻤﯿـﺖ ﺧﻮدﮐﺎرﺳـﺎزي ﺗـﺴﺖ ﻧـﺮماﻓـﺰار، ﺑـﻪ‬ ‫ﻣﻌﺮﻓﯽ و ﺑﺮرﺳﯽ وﯾﮋﮔﯽﻫﺎي اﺑﺰارﻫﺎي ﻣﺘﺪاول ﺗﺴﺖ ﻧﺮماﻓﺰار ﭘﺮداﺧﺘﻪ ﺷﺪه اﺳﺖ.‬
    • ‫‪III‬‬ ‫ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ‬ ‫.............................................................. 1‬ ‫-1ﻣﻘﺪﻣﻪاي ﺑﺮ ﻓﺮاﯾﻨﺪ ﺗﺴﺖ ﻧﺮماﻓﺰار‬ ‫اﻫﺪاف ﺗﺴﺖ ............................................................................................... 2‬ ‫اﺻﻮل ﺗﺴﺖ ................................................................ ................................ 3‬ ‫................................ ..................................... 5‬ ‫2- اﻧﻮاع، روشﻫﺎ و ﺳﻄﻮح ﺗﺴﺖ‬ ‫اﻧﻮاع ﺗﺴﺖ ................................................................................................. 5‬ ‫ﺗﺴﺖ ﻋﻤﻠﮑﺮد ........................................................................................................ 5‬ ‫ﺗﺴﺖ اﺳﺘﺮس ........................................................................................................ 5‬ ‫ﺗﺴﺖ ﺑﺎر ............................................................................................................... 6‬ ‫ﺗﺴﺖ اﮐﺘﺸﺎﻓﯽ ................................ ....................................................................... 7‬ ‫ﺗﺴﺖ رﮔﺮﺳﯿﻮن ...................................................................................................... 7‬ ‫ﺗﺴﺖ ﻗﺎﺑﻠﯿﺖ اﺳﺘﻔﺎده ............................................................................................... 8‬ ‫ﺗﺴﺖ اﻣﻨﯿﺖ .......................................................................................................... 8‬ ‫ﺗﺴﺖ ﭘﻮﺷﺶ ......................................................................................................... 9‬ ‫روشﻫﺎي ﺗﺴﺖ ......................................................................................... 01‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه ................................................................................................... 01‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ .................................................................................................. 11‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ............................................................................................ 31‬ ‫ﺗﺴﺖ ﺳﯿﺴﺘﻤﻬﺎي ﻣﺒﺘﻨﯽ ﺑﺮوب ................................ ........................................ 31‬ ‫ﺳﻄﻮح ﻣﺨﺘﻠﻒ ﺗﺴﺖ ................................................................................... 51‬ ‫ﺗﺴﺖ واﺣﺪ ........................................................................................................... 51‬ ‫ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ ................................................................ .................................... 61‬ ‫ﺗﺴﺖ ﺳﯿﺴﺘﻢ ....................................................................................................... 71‬ ‫ﺗﺴﺖ ﭘﺬﯾﺮش ........................................................................................................ 71‬ ‫................................ ............................................. 81‬ ‫-3ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ‬ ‫................................................................. 12‬ ‫4-اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار‬ ‫‪21 .................................................................................................. xUnit‬‬ ‫‪21 ................................................................................................................ JUnit‬‬ ‫‪24 ...................................................................... ................................ HTTPUnit‬‬ ‫‪26 ..................................................................................................... HTMLUnit‬‬
    • IV 28 ............................ ................................ ................................ Selenium 28 ................................................................................................ Selenium IDE 29 .......................................................................... Selenium Remote Control 30 ............................... ................................................................ EMMA 34 .................................................... Testing Framework based on .NET 36 ............................................. ................................ .NET CodeDOM ‫ﻓﻀﺎي ﻧﺎم‬ 37 .................................................................... Push To Test Test Maker 39 ..................................................................................................... ‫ﺗﺴﺖ و ﺗﺼﺤﯿﺢ‬ 40 .................................................................................................. Test network 40 ..................................................................................... Test Maker Monitor 41 .............................................................................................. iMacros 43 ........... ................................................................ ‫5- ﭼﺸﻢاﻧﺪاز و ﻧﺘﯿﺠﻪﮔﯿﺮي‬ 46.................................................................. ................................ ‫6- ﻣﺮاﺟﻊ‬
    • ‫‪V‬‬ ‫ﻓﻬﺮﺳﺖ ﺷﮑﻞﻫﺎ‬‫ﺷﮑﻞ 4-1- ‪29 ................. ................................................................ Selenium IDE‬‬‫ﺷﮑﻞ 4-2- ﻗﺎﻟﺐ ‪ HTML‬ﺑﺮاي ‪33 .................................................................. EMMA‬‬
    • ‫١‬ ‫ﻣﻘﺪﻣﻪاي ﺑﺮ ﻓﺮاﯾﻨﺪ ﺗﺴﺖ ﻧﺮماﻓﺰار‬ ‫1-‬‫ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪي اﺳﺖ ﮐﻪ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﮐﺎﻣﭙﯿﻮﺗﺮي را ﻣﺸﺨﺺ ﻣـﯽﮐﻨـﺪ. ﺗـﺴﺖ ﻧـﺮماﻓـﺰار ﺷـﺎﻣﻞ‬‫ﻓﺮاﯾﻨﺪ اﺟﺮاي ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﻫﺪف ﯾﺎﻓﺘﻦ ﺑﺎگﻫﺎي ﻧﺮماﻓﺰاري اﺳﺖ، اﻣﺎ ﻣﺤﺪود ﺑﻪ آن ﻧﯿـﺴﺖ.ﮐﯿﻔﯿـﺖ ﻣﻄﻠـﻖ‬‫ﻧﯿﺴﺖ، ﺑﻠﮑﻪ ﺑﺮاي اﻓﺮاد ﻣﺨﺘﻠﻒ ﻧﺴﺒﯽ اﺳﺖ. ﺑﺎ اﯾﻦ ﺗﺼﻮر، ﺗﺴﺖ ﮐﺮدن ﻫﺮﮔﺰ ﻧﻤﯽﺗﻮاﻧﺪ ﺻﺤﺖ ﻧـﺮماﻓﺰارﻫـﺎي‬‫ﮐﺎﻣﭙﯿﻮﺗﺮي دﻟﺨﻮاه را ﺑﻪ ﻃﻮر ﮐﺎﻣﻞ اﺛﺒﺎت ﮐﻨﺪ. ﯾﮏ ﻧﮑﺘﻪ ﻣﻬﻢ اﯾﻨﺴﺖ ﮐﻪ ﺗﺴﺖ ﻧﺮماﻓﺰار، ﺑﺎﯾﺪ از ﻧﻘﻄﻪ ﻧﻈﺮات‬‫ﻣﺨﺘﻠﻔﯽ از ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﻟﺤﺎظ ﺷﻮد، ﮐﻪ ﺑﺎ ﻫﻤﻪ ﺣﻮزهﻫﺎي ﻓﺮاﯾﻨﺪ ﺗﺠﺎري ﻫﻤﺮاه ﺑﺎﺷـﺪ ﻧـﻪ ﻓﻘـﻂ‬ ‫ﺣﻮزه ﻫﺎي ﺗﺴﺖ.‬‫ﺗﺴﺖ ﻧﺮماﻓﺰار ﻣﻤﮑﻦ اﺳﺖ ﺑﻪ ﻋﻨﻮان ﯾﮏ ﻗﺴﻤﺖ ﻣﻬﻢ از ﻓﺮاﯾﻨﺪ ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿـﺖ ﻧـﺮماﻓـﺰار ﺗﻠﻘـﯽ ﺷـﻮد. در‬‫ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﻣﺘﺨﺼﺼﺎن ﻓﺮاﯾﻨﺪ ﻧﺮماﻓﺰار و دﯾﺪﮔﺎه وﺳﯿﻊﺗﺮي روي ﻧﺮماﻓـﺰار و ﺗﻮﺳـﻌﻪ آن دارﻧـﺪ.‬‫آﻧﻬﺎ ﻓﺮاﯾﻨﺪ ﻣﻬﻨﺪﺳﯽ ﻧﺮماﻓﺰار را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﻨﺪ و آن را ﺑﺮاي ﮐﺎﻫﺶ ﻣﯿﺰان ﺧﻄﺎﻫﺎي ﻣﻨﺠـﺮ ﺑـﻪ ﺷﮑـﺴﺖ،‬‫ﺗﻐﯿﯿﺮ ﻣﯽدﻫﻨﺪ. ﻋﻨﺼﺮ ﺗﻌﯿﯿﻦ ﮐﻨﻨﺪه ﻣﯿﺰان ﺷﮑﺴﺖ ﻗﺎﺑﻞ ﻗﺒﻮل، ﻣﺎﻫﯿﺖ ﻧﺮماﻓﺰار اﺳـﺖ. ﺑـﺎزي وﯾـﺪﺋﻮﯾﯽ ﮐـﻪ‬‫ﺑﺮاي ﺷﺒﯿﻪ ﺳﺎزي ﭘﺮواز ﯾﮏ ﻫﻮاﭘﯿﻤﺎ ﻃﺮاﺣﯽ ﺷﺪه، ﻣﻨﻄﻘﺎً ﺑﺎﯾﺪ ﻧﺴﺒﺖ ﺑﻪ ﻧﺮماﻓﺰاري ﮐﻪ ﺑﺮاي ﮐﻨﺘﺮل ﯾﮏ ﺧﻂ‬ ‫ﭘﺮواز واﻗﻌﯽ ﺑﻪ ﮐﺎر ﻣﯽرود ، ﺗﺤﻤﻞ ﺷﮑﺴﺖ ﺑﯿﺸﺘﺮي داﺷﺘﻪ ﺑﺎﺷﺪ.‬‫ﺷﮑﺴﺖ ﻧﺮماﻓﺰار از ﻃﺮﯾﻖ ﻓﺮاﯾﻨﺪﻫﺎي زﯾﺮ رخ ﻣﯽدﻫﺪ. ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ ﯾﮏ ﺧﻄﺎﯾﯽ را اﻧﺠﺎم ﻣـﯽدﻫـﺪ ﮐـﻪ‬‫ﻣﻨﺠﺮ ﺑﻪ ﯾﮏ ﺷﮑﺴﺖ در ﮐﺪ ﻣﻨﺒﻊ ﻧﺮماﻓﺰار ﻣﯽﺷﻮد. اﮔﺮ اﯾﻦ ﺧﻄﺎ ﮐﺎﻣﭙﺎﯾﻞ و اﺟﺮا ﺷـﻮد، در ﻣﻮﻗﻌﯿـﺖ ﻫـﺎي‬‫ﺧﺎﺻﯽ ﺳﯿﺴﺘﻢ ﻧﺘﺎﯾﺞ ﻧﺎدرﺳﺘﯽ ﺗﻮﻟﯿﺪ ﻣﯽﮐﻨﺪ ﮐﻪ ﻣﻨﺠﺮ ﺑﻪ ﺷﮑﺴﺖ ﻣﯽﺷﻮد. ﻟﺰوﻣﺎً ﻫﻤﻪ ﺧﻄـﺎ ﻫـﺎ ﻣﻨﺠـﺮ ﺑـﻪ‬‫ﺷﮑﺴﺖ ﻧﻤﯽﺷﻮﻧﺪ. ﺑﺮاي ﻣﺜﺎل ﺧﻄﺎﻫﺎ در ﮐﺪﻫﺎﯾﯽ ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﻫﺮﮔﺰ ﺑﻪ اﺟﺮاي آﻧﻬﺎ ﻧﻤﯽرﺳﺪ1. ﻫﺮﮔﺰ ﻣﻨﺠﺮ ﺑﻪ‬‫ﺷﮑﺴﺖ ﻧﺨﻮاﻫﺪ ﺷﺪ. ﯾﮏ ﺧﻄﺎ زﻣﺎﻧﯽ ﻣﻨﺠﺮ ﺑﻪ ﺷﮑﺴﺖ ﻣﯽﺷﻮد، ﮐﻪ ﻣﺤﯿﻂ ﺗﻐﯿﯿﺮ ﻣـﯽﮐﻨـﺪ. ﻣﺜـﺎﻟﯽ از اﯾـﻦ‬ ‫1 ‪dead code‬‬
    • ‫٢‬‫ﺗﻐﯿﯿﺮات در ﻣﺤﯿﻂ ﺷﺎﻣﻞ ﻧﺮماﻓﺰارﻫﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ در ﯾﮏ ﭘﻠﺘﻔﺮم ﺟﺪﯾﺪ ﺳﺨﺖ اﻓﺰاري ﯾـﺎ ﻧـﺮماﻓـﺰاري، ﯾـﺎ‬ ‫ﺗﻐﯿﯿﺮات در دادهﻫﺎي ﻣﻨﺒﻊ، ﯾﺎ ﺗﻌﺎﻣﻼت ﺑﺎ ﻧﺮماﻓﺰارﻫﺎي ﻣﺘﻔﺎوت اﺟﺮا ﻣﯽﺷﻮﻧﺪ.]1-10‪[Kan‬‬‫روﺷﻬﺎي ﻣﺨﺘﻠﻔﯽ ﺑﺮاي ﺗﺴﺖ ﻧﺮماﻓﺰار وﺟﻮد دارد . دوﺑﺎره ﺑﺮرﺳﯽ ﮐﺮدن و اﻣﺘﺤﺎﻧﺎت ﺳﺨﺖ و ﻣﻬﻢ ، ﺗﺴﺘﻬﺎي‬‫اﺳﺘﺎﺗﯿﮏ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮﻧﺪ، در ﺣﺎﻟﯿﮑﻪ اﺟﺮاي واﻗﻌﯽ ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﯾﮏ ﻣﺠﻤﻮﻋﻪ ﺗﺴﺖ داده ﺷﺪه در ﻣﺮﺣﻠﻪ ﺧﺎﺻﯽ‬ ‫از ﻓﺮاﯾﻨﺪ ﺗﻮﺳﻌﻪ، ﺗﺴﺖ ﭘﻮﯾﺎ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد.‬ ‫اﻫﺪاف ﺗﺴﺖ‬‫"ﮔﻠﻦ ﻣﺎﯾﺰر" درﺑﺎره ﻧﺮماﻓﺰار ﭼﻨﺪ ﻗﺎﻋﺪه را ﺑﯿﺎن ﻣﯽ ﮐﻨﺪ ﮐﻪ ﺑﻪ ﺧﻮﺑﯽ ﺑﻪ ﻋﻨﻮان اﻫﺪاف ﺗﺴﺖ ﻋﻤﻞ ﻣﯽ ﮐﻨﺪ.‬ ‫‪ ‬ﺗﺴﺖ ﻓﺮآﯾﻨﺪ اﺟﺮاي ﺑﺮﻧﺎﻣﻪ ﺑﻪ ﻗﺼﺪ ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎﺳﺖ.‬ ‫‪ ‬ﻣﻮرد ﺗﺴﺖ ﺧﻮب، ﻣﻮردي اﺳﺖ ﮐﻪ اﺣﺘﻤﺎل ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎي ﮐﺸﻒ ﺷﺪه در آن، ﺑﺎﻻ ﺑﺎﺷﺪ.‬ ‫‪ ‬ﺗﺴﺖ ﻣﻮﻓﻖ، ﺗﺴﺘﯽ اﺳﺖ ﮐﻪ ﺧﻄﺎﻫﺎي ﮐﺸﻒ ﻧﺸﺪه را ﮐﺸﻒ ﻣﯽ ﮐﻨﺪ.‬‫اﻫﺪاف ﺑﺎﻻ ﻧﺸﺎﻧﮕﺮ ﯾﮏ ﺗﻐﯿﯿﺮ دﯾﺪﮔﺎه زﯾﺒﺎ ﻫﺴﺘﻨﺪ، و ﺑﺮﺧﻼف اﯾﻦ دﯾﺪﮔﺎه ﻋﺎﻣﯿﺎﻧﻪ ﮐﻪ ﺗﺴﺖ ﻣﻮﻓـﻖ، ﺗـﺴﺖي‬‫اﺳﺖ ﮐﻪ در آن ﺧﻄﺎﯾﯽ ﯾﺎﻓﺘﻪ ﻧﺸﻮد. اﮔﺮ ﺗﺴﺖ ﺑﺎ ﻣﻮﻓﻘﯿﺖ اﺟﺮا ﺷﻮد )ﻣﻄـﺎﺑﻖ اﻫـﺪاف ذﮐـﺮ ﺷـﺪه در ﺑـﺎﻻ(،‬‫ﺧﻄﺎﻫﺎي ﻧﺮماﻓﺰار را ﺑﺮ ﻣﻼ ﺧﻮاﻫﺪ ﻧﻤﻮد. ﺑﻪ ﻋﻨﻮان ﻣﺰﯾﺖ دوم، ﺗﺴﺖ ﻧﺸﺎن ﻣﯽ دﻫﺪ ﮐﻪ ﻋﻤﻠﮑﺮدﻫﺎي ﻧﺮماﻓﺰار‬‫ﻇﺎﻫﺮا" ﻣﻄﺎﺑﻖ ﻣﺸﺨﺼﻪ ﮐﺎر ﻣﯽ ﮐﻨﻨﺪ، و ﺧﻮاﺳﺘﻪ ﻫﺎي رﻓﺘﺎري و ﮐﺎراﯾﯽ ﻇﺎﻫﺮا" ﺑﺮآورده ﺷﺪه اﻧﺪ. ﺑﻪ ﻋﻼوه،‬‫داده ﻫﺎي ﺟﻤﻊ آوري ﺷﺪه ﺑﻪ ﻣﻮازات اﻧﺠﺎم ﺗﺴﺖ، ﺷﺎﺧﺺ ﺧﻮﺑﯽ از ﻗﺎﺑﻠﯿﺖ اﻃﻤﯿﻨﺎن ﻧﺮماﻓﺰار و ﺷﺎﺧﺼﯽ از‬‫ﮐﻠﯿ‪‬ﺖ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﺑﻪ دﺳﺖ ﻣﯽ دﻫﻨﺪ. وﻟﯽ ﺗﺴﺖ ﻧﻤﯽ ﺗﻮاﻧﺪ ﻧﺒﻮد ﺧﻄﺎﻫﺎ و ﻧﻘﺎﯾﺺ را ﺛﺎﺑـﺖ ﮐﻨـﺪ. ﺑﻠﮑـﻪ‬ ‫ﻓﻘﻂ ﻣﯽ ﺗﻮاﻧﺪ ﻧﺸﺎن دﻫﺪ ﮐﻪ ﺧﻄﺎﻫﺎ و ﻧﻘﺎﯾﺺ وﺟﻮد دارﻧﺪ.‬
    • ‫٣‬ ‫اﺻﻮل ﺗﺴﺖ‬‫ﻣﻬﻨﺪس ﻧﺮماﻓﺰار ﭘﯿﺶ از اﻋﻤﺎل روش ﻫﺎ در ﺧﺼﻮص ﻣﻮارد ﺗﺴﺖ ﻣﺆﺛﺮ، ﺑﺎﯾﺪ اﺻـﻮل ﭘﺎﯾـﻪ اي را ﮐـﻪ ﺗـﺴﺖ‬‫ﻧﺮماﻓﺰار را ﻫﺪاﯾﺖ ﻣﯽ ﮐﻨﻨﺪ، درك ﮐﻨﺪ. "دﯾﻮﯾﺲ" ﻣﺠﻤﻮﻋﻪ اي از اﺻﻮل ﭘﯿﺸﻨﻬﺎد ﻣﯽ ﮐﻨﺪ، ﮐﻪ در اﯾﻨﺠـﺎ از‬ ‫آﻧﻬﺎ اﺳﺘﻔﺎده ﺧﻮاﻫﯿﻢ ﮐﺮد:‬‫‪ ‬ﻫﻤﻪ ﺗﺴﺖ ﻫﺎ ﺑﺎﯾﺪ ﺗﺎ ﺣﺪ ﺧﻮاﺳﺘﻪ ﻫﺎي ﻣﺸﺘﺮي ﻗﺎﺑﻞ ردﯾﺎﺑﯽ ﺑﺎﺷﻨﺪ. ﭼﻨﺎﻧﮑﻪ دﯾﺪﯾﻢ، ﻫﺪف ﺗﺴﺖ‬‫ﻧﺮماﻓﺰار، ﮐﺸﻒ ﺧﻄﺎﻫﺎ اﺳﺖ. ﯾﻌﻨﯽ اﮐﺜﺮ ﻧﻘﺎﯾﺺ ﺷﺪﯾﺪ )از دﯾﺪﮔﺎه ﻣﺸﺘﺮي( آﻧﻬﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎﻋﺚ‬ ‫ﻣﯽ ﺷﻮﻧﺪ ﺑﺮﻧﺎﻣﻪ ﻧﺘﻮاﻧﺪ ﺧﻮاﺳﺘﻪ ﻫﺎي ﺧﻮد را ﺑﺮآورده ﮐﻨﺪ.‬‫‪ ‬ﺗﺴﺖ ﺑﺎﯾﺪ ﻣﺪت ﻫﺎ ﻗﺒﻞ از ﺷﺮوع ﺗﺴﺖ، ﻃﺮح رﯾﺰي ﺷﻮد. ﻃﺮح رﯾﺰي ﺗﺴﺖ ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ‬‫ﻣﺤﺾ ﮐﺎﻣﻞ ﺷﺪن ﻣﺪل ﺧﻮاﺳﺘﻪ ﻫﺎ آﻏﺎز ﺷﻮد. ﺗﻌﺮﯾﻒ ﻣﺸﺮوح ﻣﻮارد ﺗﺴﺖ ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ ﻣﺤﺾ‬‫ﻣﻨﺴﺠﻢ ﺷﺪن ﻣﺪل ﻃﺮاﺣﯽ آﻏﺎز ﺷﻮد. ﺑﻨﺎﺑﺮاﯾﻦ، ﻫﻤﻪ ﺗﺴﺖ ﻫﺎ را ﻣﯽ ﺗﻮان ﭘﯿﺶ از ﺗﻮﻟﯿﺪ ﻫﺮ ﮔﻮﻧﻪ‬ ‫ﮐﺪ، ﺑﺮﻧﺎﻣﻪ رﯾﺰي و ﻃﺮاﺣﯽ ﮐﺮد.‬‫‪ ‬اﺻﻞ "ﭘﺎرﺗﻮ" در ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻﺪق ﻣﯽ ﮐﻨﺪ. ﺑﻪ ﻋﺒﺎرت ﺳﺎده، اﺻﻞ "ﭘﺎرﺗﻮ" ﺑﯿﺎن ﻣﯽ ﮐﻨﺪ‬‫ﮐﻪ 08 درﺻﺪ ﻫﻤﻪ ﺧﻄﺎﻫﺎي ﮐﺸﻒ ﺷﺪه ﻃﯽ ﺗﺴﺖ، اﺣﺘﻤﺎﻻ" در 02 درﺻﺪ ﻫﻤﻪ ﻣﺆﻟﻔﻪ ﻫﺎ ﺑﺮﻧﺎﻣﻪ‬ ‫ﻗﺎﺑﻞ ﮐﺸﻒ ﻫﺴﺘﻨﺪ. ﻣﺴﺌﻠﻪ، ﺟﺪا ﺳﺎزي ﻣﺆﻟﻔﻪ ﻫﺎي ﻣﻈﻨﻮن و آزﻣﻮدن ﮐﺎﻣﻞ آﻧﻬﺎﺳﺖ.‬‫‪ ‬ﺗﺴﺖ ﺑﺎﯾﺪ در اﺑﻌﺎد ﮐﻮﭼﮏ آﻏﺎز ﺷﻮد و ﺑﻪ اﺑﻌﺎد ﺑﺰرﮔﺘﺮ ﮔﺴﺘﺮش ﯾﺎﺑﺪ. اوﻟﯿﻦ ﺗﺴﺖ ﻫﺎ ﺑﺮروي‬‫ﻫﺮ ﯾﮏ از ﻣﺆﻟﻔﻪ ﻫﺎ اﻧﺠﺎم ﻣﯽ ﺷﻮﻧﺪ. ﺑﺎ ﭘﯿﺸﺮﻓﺖ ﺗﺴﺖ، ﺧﻄﺎﻫﺎي ﻣﺠﻤﻮﻋﻪ اي از ﻣﺆﻟﻔﻪ ﻫﺎي ﻣﺠﺘﻤﻊ‬ ‫و ﺳﭙﺲ ﮐﻞ ﺳﯿﺴﺘﻢ ﯾﺎﻓﺖ ﻣﯽ ﺷﻮد.‬‫‪ ‬ﺗﺴﺖ ﮐﺎﻣﻞ اﻣﮑﺎن ﭘﺬﯾﺮ ﻧﯿﺴﺖ. ﺗﻌﺪاد ﻣﺴﯿﺮﻫﺎي ﻣﻤﮑﻦ ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﻣﺘﻮﺳﻂ ﻧﯿﺰ زﯾﺎد اﺳﺖ. ﻟﺬا،‬‫اﺟﺮاي ﻫﺮ ﺗﺮﮐﯿﺒﯽ از ﻣﺴﯿﺮﻫﺎ اﻣﮑﺎن ﭘﺬﯾﺮ ﻧﯿﺴﺖ. وﻟﯽ اﯾﻦ اﻣﮑﺎن وﺟﻮد دارد ﮐﻪ ﺑﺮﻧﺎﻣﻪ را در ﺣﺪ‬ ‫ﮐﻔﺎﯾﺖ ﭘﻮﺷﺶ دﻫﯿﻢ.‬
    • ‫٤‬‫‪ ‬ﺑﺮاي آﻧﮑﻪ ﺗﺴﺖ ﺑﯿﺸﺘﺮﯾﻦ ﺑﺎزدﻫﯽ را داﺷﺘﻪ ﺑﺎﺷﺪ، ﺑﺎﯾﺪ ﺗﻮﺳﻂ ﯾﮏ ﺷﺨﺺ ﺛﺎﻟﺚ ﺑﯽ ﻃﺮف‬‫اﻧﺠﺎم ﺷﻮد. ﻣﻨﻈﻮر از ﺑﯿﺸﺘﺮﯾﻦ ﺑﺎزدﻫﯽ آن اﺳﺖ ﮐﻪ ﺧﻄﺎﻫﺎ را ﺑﺎ اﺣﺘﻤﺎل ﺑﯿﺸﺘﺮي ﺑﯿﺎﺑﺪ. ﺑﻪ دﻻﯾﻠﯽ‬‫ﮐﻪ ﻗﺒﻼ" در ﻫﻤﯿﻦ ﻓﺼﻞ ذﮐﺮ ﺷﺪ، ﻣﻬﻨﺪس ﻧﺮماﻓﺰاري ﮐﻪ ﺳﯿﺴﺘﻢ را اﯾﺠﺎد ﮐﺮده اﺳﺖ، ﺑﻬﺘﺮﯾﻦ‬ ‫ﮐﺴﯽ ﻧﯿﺴﺖ ﮐﻪ ﺑﺎﯾﺪ ﻫﻤﻪ ﺗﺴﺖ ﻫﺎ را اﻧﺠﺎم دﻫﺪ.‬
    • ‫٥‬ ‫اﻧﻮاع، روشﻫﺎ و ﺳﻄﻮح ﺗﺴﺖ‬ ‫2-‬ ‫اﻧﻮاع ﺗﺴﺖ‬‫ﺗﺴﺖﻫﺎي ﻣﺘﻨﻮﻋﯽ را ﻣﯽ ﺗﻮان ﺑﺮ روي ﺳﯿﺴﺘﻢ ﻫﺎ اﻋﻤﺎل ﻧﻤﻮد ﺗﺎ آﻧﺎن را از ﺟﻨﺒﻪ ﻫﺎي ﻣﺨﺘﻠﻒ ﻣﻮرد ﺗﺴﺖ و‬ ‫ﺗﺴﺖ ﻗﺮار داد. در اﯾﻦ ﺑﺨﺶ ﺑﻪ اﯾﻦ ﺗﺴﺖ ﻫﺎ اﺷﺎره ﻣﯽ ﺷﻮد وﻫﺮﯾﮏ را ﻣﺨﺘﺼﺮا ﺗﻮﺿﯿﺢ ﻣﯽ دﻫﯿﻢ.‬ ‫ﺗﺴﺖ ﻋﻤﻠﮑﺮد‬‫در اﯾﻦ ﻧﻮع ﺗﺴﺖ ، ﻧﺮماﻓﺰار ﺗﺴﺖ ﻣﯿﺸﻮد ﺗﺎ از ﻟﺤﺎظ درﺳﺘﯽ ﻋﻤﻠﮑﺮد ﺑﺮرﺳﯽ ﺷﻮد . ﺗﺴﺘﻬﺎ ﻧﻮﺷﺘﻪ ﻣﯿﺸﻮﻧﺪ ﺗﺎ‬‫ﺑﺒﯿﻨﻨﺪ ﮐﻪ اﯾﺎ ﻧﺮماﻓﺰار ﻫﻤﺎن ﮔﻮﻧﻪ ﮐﻪ اﻧﺘﻈﺎر ﻣﯿﺮود ﻋﻤﻞ ﻣﯿﮑﻨﺪ. اﮔﺮ ﭼﻪ ﺗﺴﺖ ﻋﻤﻠﮑـﺮد ﻣﻌﻤـﻮﻻً در اﻧﺘﻬـﺎي‬‫ﻓﺮاﯾﻨﺪ ﺗﻮﺳﻌﻪ اﻧﺠﺎم ﻣﯿﺸﻮد وﻟﯽ ﻣﯿﺘﻮاﻧﺪ –و ﺑﺎﯾﺪ – ﺳﺮﯾﻌﺘﺮ اﻏﺎز ﺷﻮد . ﮐﺎﻣﭙﻮﻧﻨﺖ ﻫـﺎ و ﻓﺮاﯾﻨـﺪ ﻫـﺎي ﻣﺠـﺰا‬ ‫ﻣﯿﺘﻮاﻧﻨﺪ ﺧﯿﻠﯽ ﺳﺮﯾﻌﺘﺮ اﻧﺠﺎم ﺷﻮﻧﺪ ، ﺣﺘﯽ زودﺗﺮ از اﯾﻨﮑﻪ ﺑﺘﻮان ﺗﺴﺖ ﻋﻤﻠﮑﺮد را روي ﺳﯿﺴﺘﻢ اﻧﺠﺎم داد .‬ ‫ﺗﺴﺖ اﺳﺘﺮس‬‫ﺑﺮﻧﺎﻣﻪ در ﻣﻘﺎﺑﻞ ﺑﺎر ﺳﻨﮕﯿﻦ ﻣﺜﻞ ﻣﻘﺎدﯾﺮ ﻋﺪدي ﭘﯿﭽﯿﺪه ، ﻣﻘﺎدﯾﺮ زﯾـﺎدي ورودي و ﻣﻘـﺎدﯾﺮ زﯾـﺎدي ﭘـﺮس و‬‫ﺟﻮ2 اﻣﺘﺤﺎن ﻣﯿﺸﻮد . ﮐﻪ ﻣﯿﺰان ﺑﺎري ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﻣﯿﺘﻮاﻧﺪ ان را ﺗﺤﻤﻞ ﮐﻨﺪ را ﺑﺮرﺳﯽ ﻣﯿﮑﻨﺪ . ﻫﺪف ﻃﺮاﺣـﯽ‬‫ﻣﺤﯿﻄﯽ اﺳﺖ ﮐﻪ ﻣﺨﺮب ﺗﺮ از ﻣﺤﯿﻄﯽ ﮐﻪ ﺑﺮﻧﺎﻣﻪ در دﻧﯿﺎي واﻗﻌﯽ و در ﺷﺮاﯾﻂ ﻧﺮﻣﺎل ﺑـﺎ ان روﺑـﺮو ﻣﯿـﺸﻮد‬‫.اﯾﻦ ﻣﺴﺌﻠﻪ ﺳﺨﺖ ﺗﺮﯾﻦ و ﭘﯿﭽﯿﺪه ﺗﺮﯾﻦ ﻣﻘﻮﻟﻪ از ﺗﺴﺖ اﺳﺖ ﮐﻪ ﺑﺎﯾﺪ اﻧﺠﺎم ﺷﻮد و اﺣﺘﯿﺎج ﺑـﻪ ﺗـﻼش ﺗـﻮأم‬‫ﻫﻤﻪ ﺗﯿﻢ ﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ دارد . ﯾﮏ ﻣﺤﯿﻂ ﺗﺴﺖ ﺑـﺎ ﭼﻨـﺪﯾﻦ اﯾـﺴﺘﮕﺎه ﺗـﺴﺖ اﯾﺠـﺎد ﻣﯿـﺸﻮد و در ﻫـﺮ‬‫اﯾﺴﺘﮕﺎه ﯾﮏ اﺳﮑﺮﯾﭙﺖ ﺳﯿﺴﺘﻢ را ﺗﺴﺖ ﻣﯿﮑﻨﺪ .اﯾﻦ اﺳﮑﺮﯾﭙﺘﻬﺎ رو ﺑﻪ رﺷﺪ ﻫﺴﺘﻨﺪ و اﯾﺴﺘﮕﺎه ﻫﺎ ﻧﯿﺰ ﺑﺘـﺪرﯾﺞ‬‫اﻓﺰاﯾﺶ ﻣﯽﯾﺎﺑﻨﺪ و ﻫﻤﻪ ﺑﺼﻮرت ﻫﻤﺰﻣﺎن روي ﺳﯿﺴﺘﻢ ﻓﺸﺎر ﻣﯽاورﻧﺪ ﺗﺎ ﺳﯿﺴﺘﻢ ﻣﺘﻮﻗـﻒ ﺷـﻮد .ﺳﯿـﺴﺘﻢ را‬‫2‬ ‫‪query‬‬
    • ‫٦‬‫ﺗﻌﻤﯿﺮ ﻣﯿﮑﻨﻨﺪ و ﺗﺴﺖ اﺳﺘﺮس دوﺑﺎره اﻧﺠﺎم ﻣﯿﺸﻮد ﺗﺎ ﺳﯿﺴﺘﻢ ﺑﻪ ﺣﺪي از اﺳﺘﺮس ﺑﺮﺳﺪ ﮐـﻪ ﺑـﺎﻻﺗﺮ از ﺣـﺪ‬‫ﻣﻮرد اﻧﺘﻈﺎر ﻣﺸﺘﺮي ﺑﺎﺷﺪ . ﺷﺮاﯾﻂ رﻗﺎﺑﺖ 3 و رﺧﻨﻪ ﻫﺎي ﺣﺎﻓﻈﻪ 4 در ﺗﺴﺖ اﺳﺘﺮس ﭘﯿﺪا ﻣﯿﺸﻮﻧﺪ . ﺷﺮاﯾﻂ‬‫رﻗﺎﺑﺖ ﺗﻌﺎرﺿﯽ ﺑﯿﻦ ﺣﺪاﻗﻞ دو اﯾﺴﺘﮕﺎه ﺗﺴﺖ اﺳﺖ و ﻫﺮ ﺗﺴﺖ زﻣﺎﻧﯿﮑﻪ ﺑﻪ ﺗﻨﻬﺎﯾﯽ ﮐﺎر ﮐﻨﺪ ﺑﻪ درﺳـﺘﯽ ﮐـﺎر‬‫ﻣﯿﮑﻨﺪ .اﻣﺎ زﻣﺎﻧﯿﮑﻪ دو ﺗﺴﺖ ﺑﻪ ﺻﻮرت ﻣﻮازي ﮐﺎر ﮐﻨﻨﺪ ، ﯾﮑﯽ ﯾﺎ ﻫﺮ دو ﺗـﺴﺖ ﺷﮑـﺴﺖ ﻣﯿﺨﻮرﻧـﺪ . و اﯾـﻦ‬‫ﻣﻌﻤﻮﻻً ﺑﻪ ﺧﺎﻃﺮ ﯾﮏ ﻗﻔﻞ اﺳﺖ ﮐﻪ ﺑﻪ درﺳﺘﯽ ﻣﺪﯾﺮﯾﺖ ﻧﺸﺪه اﺳﺖ . ﯾﮏ رﺧﻨﻪ ﺣﺎﻓﻈﻪ زﻣﺎﻧﯽ رخ ﻣﯿﺪﻫﺪ ﮐﻪ‬‫ﯾﮏ ﺗﺴﺖ ، ﺣﺎﻓﻈﻪ ﺗﺨﺼﯿﺺ ﯾﺎﻓﺘﻪ را رﻫﺎ ﻣﯿﮑﻨﺪ و ﺑﻪ درﺳﺘﯽ ﺣﺎﻓﻈﻪ را ﺑﺮ ﻧﻤﯿﮕﺮداﻧﺪ . ﺑﻪ ﻧﻈﺮ ﺗﺴﺖ درﺳﺖ‬‫ﮐﺎر ﻣﯿﮑﻨﺪ ، اﻣﺎ ﺑﻌﺪ از ﻣﺪﺗﯽ اﺟﺮاي ﺗﺴﺖ ﺣﺎﻓﻈـﻪ در دﺳـﺘﺮس ﮐـﺎﻫﺶ ﭘﯿـﺪا ﻣﯿﮑﻨـﺪ و ﺳﯿـﺴﺘﻢ ﺷﮑـﺴﺖ‬ ‫ﻣﯿﺨﻮرد .‬ ‫ﺗﺴﺖ ﺑﺎر‬‫ﺑﺮﻧﺎﻣﻪ در ﻣﻘﺎﺑﻞ ﺑﺎر زﯾﺎد ﯾﺎ ورودي ﻫﺎ ﺗﺴﺖ ﻣﯿﺸﻮد ﻣﺜﻞ ﺗﺴﺖ وب ﺳﺎﯾﺘﻬﺎ ﺑﺮاي ﯾﺎﻓﺘﻦ ﻧﻘﺎﻃﯽ ﮐﻪ در ان ﻧﻘﺎط‬‫وب ﺳﺎﯾﺖ ﯾﺎ ﺑﺮﻧﺎﻣﻪ ﺷﮑﺴﺖ ﻣﯿﺨﻮرد و ﯾﺎ ﻧﻘﺎﻃﯽ ﮐﻪ در اﻧﻬﺎ ﮐﺎراﯾﯽ وب ﺳﺎﯾﺖ ﮐﺎ ﻫﺶ ﭘﯿﺪا ﻣﯿﮑﻨﺪ . ﺗـﺴﺖ‬‫ﺑﺎر در ﺳﻄﺢ ﺑﺎر از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷﺪه اي اﻧﺠﺎم ﻣﯿﺸﻮد،.‪ Error! Reference source not found‬ﻣﻌﻤـﻮﻻً‬‫ﺑﺎﻻﺗﺮﯾﻦ ﺑﺎري ﮐﻪ ﺳﯿﺴﺘﻢ ﻣﯿﺘﻮاﻧﺪ ﺑﭙﺬﯾﺮد، در ﺣﺎﻟﯿﮑﻪ ﻫﻨﻮز ﺑﻪ درﺳﺘﯽ ﮐﺎر ﻣﯿﮑﻨﺪ . ﺗﻮﺟﻪ ﮐﻨﯿﺪ ﮐﻪ ﺗﺴﺖ ﺑﺎر‬‫ﻧﻤﯽﺧﻮاﻫﺪ ﺳﯿﺴﺘﻢ را ﺑﺎ ﻓﺸﺎر اوردن از ﭘﺎ در اورد . اﻣﺎ ﻣﯿﺨﻮاﻫﺪ ﺳﯿﺴﺘﻢ را ﺑﻄﻮر ﭘﯿﻮﺳﺘﻪ زﯾﺮ ﺑﺎر ﻧﮕـﻪ دارد‬‫.در ﻣﻔﻬﻮم ﺗﺴﺖ ﺑﺎر ، ﺑﺎﯾﺪ ﻣﺠﻤﻮﻋﻪ داده ﻫﺎي زﯾﺎدي ﺑﺮاي ﺗﺴﺖ در دﺳﺘﺮس داﺷـﺘﻪ ﺑﺎﺷـﯿﻢ . ﺑﺎﮔﻬـﺎ ﻇﻬـﻮر‬‫ﻧﻤﯿﮑﻨﻨﺪ ﻣﮕﺮ اﯾﻨﮑﻪ ﺷﻤﺎ ﺑـﺎ ﻣﻮﺟﻮدﯾﺘﻬـﺎ ي ﺧﯿﻠـﯽ ﺑـﺰرگ ﻣﺜـﻞ ﻫـﺰاران ﮐـﺎرﺑﺮ در اﻧﺒـﺎر داده ﻫـﺎﯾﯽ ﻣﺜـﻞ‬‫‪ LDAP,NIS , Active directory‬ﮐﺎر ﮐﻨﯿﺪ و....ﺗﺴﺖ ﮐﻨﻨﺪ ﮔﺎن ﺑﻪ اﺑﺰار ﻫﺎي اﺗﻮﻣـﺎت ﺑـﺮاي اﯾﺠـﺎد اﯾـﻦ‬ ‫ﻣﺠﻤﻮﻋﻪ داده ﻫﺎي ﺑﺰرگ دارﻧﺪ .اﻣﺎ ﺧﻮﺷﺒﺨﺘﻨﻪ ﺑﺎ ﻫﺮ زﺑﺎن اﺳﮑﺮﯾﭙﺖ ﻧﻮﯾﺴﯽ ﻣﯿﺘﻮان اﯾﻦ ﮐﺎر را اﻧﺠﺎم داد .‬‫3‬ ‫‪Race condition‬‬‫4‬ ‫‪memory leaks‬‬
    • ‫٧‬ ‫ﺗﺴﺖ اﮐﺘﺸﺎﻓﯽ‬‫ﻣﺸﺎﺑﻪ ﺗﺴﺖ ﺑﺎﻟﺒﺪاﻫﻪ اﺳﺖ و ﺑﺮاي ﯾﺎدﮔﯿﺮي و ﮐﻨﮑﺎش ﻧﺮماﻓﺰار ﺻﻮرت ﻣﯿﮕﯿﺮد . وﯾﮏ روش ﻗـﻮي و ﺟﺎﻟـﺐ‬‫ﺑﺮاي ﺗﺴﺖ اﺳﺖ . در ﺑﻌﻀﯽ ﻣﻮاﻗﻊ ﻣﻤﮑﻨﻪ ﺗﺎ ﺣﺪودي ﻗﻮي ﺗﺮ از زﺑﺎنﻫﺎي اﺳـﮑﺮﯾﭙﺖ ﻧﻮﯾـﺴﯽ ﺑـﺮاي ﺗـﺴﺖ‬ ‫ﺑﺎﺷﺪ .‬ ‫ﺗﺴﺖ رﮔﺮﺳﯿﻮن‬‫ﺑﻌﺪ از ﺗﻐﯿﯿﺮ ﻧﺮماﻓﺰار ، ﺟﻪ ﺑﺮاي ﺗﻐﯿﯿﺮ در ﻋﻤﻠﮑﺮد ﯾﺎ ﺑﺮاي ﺗﺼﺤﯿﺢ ﯾﮏ ﺧﻄﺎ ، ﯾﮏ ﺗـﺴﺖ رﮔﺮاﺳـﯿﻮن ﺗﻤـﺎم‬‫ﺗﺴﺘﻬﺎﯾﯽ ﮐﻪ ﻗﺒﻼً ﻧﺮماﻓﺰار اﻧﻬﺎ را ﺑﺎ ﻣﻮﻓﻘﯿﺖ اﻧﺠﺎم داده را دوﺑﺎره اﺟﺮا ﻣﯿﮑﻨﺪ ﺗﺎ اﻃﻤﯿﻨـﺎن ﺣﺎﺻـﻞ ﮐﻨـﺪ ﮐـﻪ‬‫ﻧﺮماﻓﺰار ﺗﺼﺎدﻓﺎً در ﻋﻤﻠﮑﺮد ﻫﺎي ﻗﺒﻠﯽ دﭼﺎر ﺧﻄﺎ ﻧﺸﺪه اﺳﺖ .ﺗﺴﺖ رﮔﺮاﺳـﯿﻮن ﻣﯿﺘﻮاﻧـﺪ در ﻫـﯿﭻ ﯾـﺎ ﻫﻤـﻪ‬‫ﺳﻄﻮح ﻗﺒﻠﯽ ﺻﻮرت ﺑﮕﯿﺮد . اﯾﻦ ﺗﺴﺘﻬﺎي رﮔﺮاﺳﯿﻮن اﮐﺜﺮاً اﺗﻮﻣﺎت ﺷﺪه اﻧﺪ .اﻧـﻮاع ﺧـﺎص ﺗـﺮي از ﺗـﺴﺘﻬﺎي‬‫رﮔﺮاﺳﯿﻮن ﺑﺎ ﻋﻨﻮان ﺗﺴﺖ ﺳﻼﻣﺖ 5 ﺷﻨﺎﺧﺘﻪ ﺷﺪه اﻧﺪ و زﻣﺎﻧﯿﮑﻪ ﻣﺎ ﻣﯽﺧﻮاﻫﯿﻢ ﺳﺮﯾﻌﺎً رﻓﺘﺎر ﻋﺠﯿﺐ ﺳﯿﺴﺘﻢ‬ ‫را ﺑﺮرﺳﯽ ﮐﻨﯿﻢ . و ﯾﺎ ﺗﺴﺖ دود 6 زﻣﺎﻧﯿﮑﻪ ﻋﻤﻠﮑﺮد ﻫﺎي اﺑﺘﺪاﯾﯽ ﭼﮏ ﻣﯿﺸﻮﻧﺪ .‬‫ﺗﺴﺖ رﮔﺮاﺳﯿﻮن ﻧﻮﻋﯽ ﺗﺴﺖ ﮐﻪ ﺗﻤﺮﮐـﺰ روي ﺗـﺴﺖ ﻣﺠـﺪد ﺑﻌـﺪ از اﻋﻤـﺎل ﺗﻐﯿﯿـﺮات اﺳـﺖ . در ﺗـﺴﺘﻬﺎي‬‫رﮔﺮاﺳﯿﻮن ﻗﺪﯾﻤﯽ، ﯾﮏ ﺗﺴﺖ دوﺑﺎره ﺗﮑﺮار ﻣﯽﺷﺪ . اﻣﺎ در ﺗﺴﺘﻬﺎي رﮔﺮاﺳﯿﻮن رﯾﺴﮏ ﮔﺮا ، ﻣﺎ ﻧﻮاﺣﯽ ﻗﺒﻠﯽ‬‫را ﻣﺜﻞ ﻗﺒﻞ ﺗﺴﺖ ﻣﯿﮑﻨﯿﻢ اﻣﺎ از ﺗﺴﺘﻬﺎي ﻣﺘﻔﺎوﺗﯽ ﮐﻪ ﺑـﻪ ﺗـﺪرﯾﺞ ﭘﯿﭽﯿـﺪه ﺗـﺮ ﻣﯿـﺸﻮﻧﺪ اﺳـﺘﻔﺎده ﻣﯿﮑﻨـﯿﻢ‬ ‫.ﺗﺴﺘﻬﺎي رﮔﺮاﺳﯿﻮن ﻗﺪﯾﻤﯽ ﻣﻌﻤﻮﻻً ﺗﺎ ﺣﺪودي اﺗﻮﻣﺎت ﺑﻮدﻧﺪ .‬ ‫ﺗﺴﺖ رﮔﺮاﺳﯿﻮن ﻣﯿﺨﻮاﻫﺪ دو رﯾﺴﮏ را ﮐﺎﻫﺶ دﻫﺪ :‬ ‫ﺗﻐﯿﯿﺮي ﮐﻪ ﻣﯿﺒﺎﯾﺴﺖ ﯾﮏ ﺧﻄﺎ را ازﺑﯿﻦ ﻣﯿﺒﺮد ، ﺷﮑﺴﺖ ﻣﯿﺨﻮرد .‬‫ﺑﻌﻀﯽ ﺗﻐﯿﯿﺮات اﺛﺮ ﺟﺎﻧﺒﯽ دارﻧﺪ ، اﮔﺮ ﺗﺼﺤﯿﺢ ﻧﮑﻨﯿﺪ ﺧﻄﺎي ﻗﺒﻠﯽ ﺑﺎﻗﯽ ﻣﯽﻣﺎﻧﺪ و اﮔﺮ ﺗﺼﺤﯿﺢ ﮐﻨﯿﺪ ﺧﻄـﺎي‬ ‫ﺟﺪﯾﺪ اﯾﺠﺎد ﻣﯿﺸﻮد .‬‫5‬ ‫‪sanity testing‬‬‫6‬ ‫‪smoke testing‬‬
    • ‫٨‬ ‫ﺗﺴﺖ ﻗﺎﺑﻠﯿﺖ اﺳﺘﻔﺎده‬‫اﯾﻦ ﻧﻮع ﺗﺴﺖ ﺗﻨﻬﺎ در ﻣﻮاردي اﻧﺠﺎم ﻣﯿﺸﻮد ﮐﻪ راﺑﻂ ﮐﺎرﺑﺮ 7 ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﺧﯿﻠﯽ ﻣﻬﻢ ﺑﺎﺷﺪ و ﺑﺎﯾﺪ ﺑﺮاي ﻫـﺮ‬‫ﮐﺎرﺑﺮ، ﺧﺎص ﺑﺎﺷﺪ . ﺗﺴﺖ ﻗﺎﺑﻠﯿﺖ اﺳﺘﻔﺎده ، ﻓﺮاﯾﻨﺪ ﮐﺎر ﮐﺮدن ﻣﺴﺘﻘﯿﻢ ﯾﺎ ﻏﯿﺮ ﻣﺴﺘﻘﯿﻢ ﺑﺎ ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﺑﺮاي‬‫ﺷﻨﺎﺧﺖ اﯾﻨﮑﻪ ﭼﮕﻮﻧﻪ ﻫﺮ ﮐﺎرﺑﺮ ﯾﮏ ﺑﺴﺘﻪ ﻧﺮماﻓﺰاري را اﺣﺴﺎس ﻣﯿﮑﻨﺪ و ﭼﮕﻮﻧﻪ ﺑﺎ ان ﺗﻌﺎﻣـﻞ ﻣﯿﮑﻨـﺪ .اﯾـﻦ‬ ‫ﻓﺮاﯾﻨﺪ ﻧﻘﺎط ﻗﻮت و ﺿﻌﻒ ﺑﺮﻧﺎﻣﻪ را ﺑﺮاي ﮐﺎرﺑﺮان ﮐﺸﻒ ﻣﯿﮑﻨﺪ .‬‫ﺑﻨﺎﺑﺮ اﯾﻦ ﻫﺪف اﯾﻦ ﺗﺴﺖ، ﺷﻨﺎﺳﺎﯾﯽ ﻣﺸﮑﻼت ﻣﺮﺑﻮط ﺑﻪ ﻃﺮز اﺳﺘﻔﺎده ﺳﯿﺴﺘﻢ از دﯾﺪ ﮐﺎرﺑﺮان ﻣـﯽﺑﺎﺷـﺪ. در‬‫اﻧﺠﺎم اﯾﻦ ﺗﺴﺖ ﻓﺎﮐﺘﻮرﻫﺎي اﻧﺴﺎﻧﯽ ﮐﻪ ﻋﻤﺪﺗﺎ ‪ subjective‬ﻣﯽﺑﺎﺷﻨﺪ، ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﻣـﯽﮔﯿﺮﻧـﺪ و ﺑﻬﻤـﯿﻦ‬‫ﻋﻠﺖ اﻧﺠﺎم اﯾﻦ ﻧﻮع ﺗﺴﺖ ﻣﻌﻤﻮﻻ ﮐﺎر ﭘﯿﭽﯿﺪه اي اﺳﺖ ﮐﻪ در ﺑﺴﯿﺎري ﻗﺴﻤﺘﻬﺎي آن اﻣﮑـﺎن ﺧﻮدﮐﺎرﺳـﺎزي‬ ‫ﺗﺴﺖ ﻣﻮﺟﻮد ﻧﻤﯽﺑﺎﺷﺪ.]40‪[Mye79] [Mye‬‬ ‫ﺗﺴﺖ اﻣﻨﯿﺖ‬‫ﻃﺮاﺣﯽ و ﺗﺴﺖ ﺳﯿﺴﺘﻢﻫﺎي ﻧﺮماﻓﺰاري ﺑﺮاي اﻃﻤﯿﻨﺎن از اﯾﻤﻦ و ﻣﻄﻤﺌﻦ ﺑﻮدن ﺳﯿﺴﺘﻢ، ﻣـﺴﺄﻟﻪاي اﺳﺎﺳـﯽ‬‫اﺳﺖ ﮐﻪ ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن ﻧﺮماﻓﺰار و ﻣﺘﺨﺼﺼﺎن ﺗﺴﺖ ﺑﺎ آن ﻣﻮاﺟﻪ ﻫﺴﺘﻨﺪ. اﺧﯿﺮاً ﻣﺴﺄﻟﻪي اﯾﻤﻨﯽ و ﻣﻄﻤﺌﻦ‬‫ﺑﻮدن ﺑﻪ ﺧﺎﻃﺮ ازدﯾﺎد ﺑﺮﻧﺎﻣﻪﻫﺎي ﮐﺎرﺑﺮدي ﺗﺠﺎري ﺑﺮاي اﺳﺘﻔﺎده روي اﯾﻨﺘﺮﻧﺖ اﻫﻤﯿﺖ ﻣﺎزادي ﯾﺎﻓﺘـﻪ اﺳـﺖ.‬‫اﮔﺮ ﮐﺎرﺑﺮان اﯾﻨﺘﺮﻧﺖ اﻋﺘﻘﺎد داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﮐﻪ اﻃﻼﻋﺎت ﺷﺨﺼﯽ آﻧﻬﺎ اﯾﻤﻦ ﻧﯿﺴﺖ و ﺑﺮاي اﻓﺮاد ﻏﯿﺮﻣﺠﺎزي ﮐﻪ‬‫ﺑﺎ اﺳﺘﻔﺎده از اﯾﻨﺘﺮﻧﺖ آﺳﯿﺐ ﻣﯽرﺳﺎﻧﻨﺪ ﻗﺎﺑﻞ دﺳﺘﺮﺳﯽ اﺳـﺖ، آﯾﻨـﺪهي ﺗﺠـﺎرت اﻟﮑﺘﺮوﻧﯿﮑـﯽ ﺑـﻪ ﻣﺨـﺎﻃﺮه‬‫ﻣﯽاﻓﺘﺪ. ﺗﺴﺖ اﻣﻨﯿﺖ وﯾﮋﮔﯽﻫﺎﯾﯽ از ﺳﯿﺴﺘﻢ ﮐﻪ ﺑﻪ دردﺳﺘﺮس ﺑﻮدن، ﯾﮑﭙﺎرﭼﮕﯽ و ﻣﺤﺮﻣﺎﻧﻪ ﺑﻮدن داده ﻫﺎ و‬‫ﺧﺪﻣﺎت ﺳﯿﺴﺘﻢ ﻣﺮﺗﺒﻂ اﺳﺖ را ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﺪ. ﮐﺎرﺑﺮان/ﻣﺸﺘﺮﯾﺎن ﺑﺎﯾﺪ ﺗﻮﺳﻂ اﯾﻦ ﻣﻮﺿﻮع ﺗﺮﻏﯿﺐ ﺷﻮﻧﺪ ﮐﻪ‬‫ﻧﯿﺎزﻫﺎي اﻣﻨﯿﺘﯽ آﻧﺎن در زﻣﺎن ﺗﻌﯿﯿﻦ ﻧﯿﺎزﻣﻨﺪيﻫﺎ ﮐﺎﻣﻼً ﻣﺸﺨﺺ اﺳﺖ، و ﺑﻨـﺎﺑﺮاﯾﻦ ﻣـﺴﺎﺋﻞ اﻣﻨﯿﺘـﯽ ﺗﻮﺳـﻂ‬ ‫ﻃﺮاﺣﺎن و آزﻣﺎﯾﻨﺪﮔﺎن ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﻣﯽﮔﯿﺮد. ]30‪[BUR‬‬‫7‬ ‫‪User interface‬‬
    • ‫٩‬‫ﻫﺪف ﺗﺴﺖ اﻣﻨﯿﺖ ﺑﺮرﺳﯽ ﮐﺎراﯾﯽ ﻣﮑﺎﻧﯿﺰمﻫﺎي دﻓـﺎﻋﯽ ﺳﯿـﺴﺘﻢ وب در ﻣﻘﺎﺑـﻞ دﺳﺘﺮﺳـﯽﻫـﺎي ﻧـﺎﻣﻄﻠﻮب‬‫ﮐﺎرﺑﺮان ﺑﺪون ﻣﺠﻮز و ﺣﻔﻆ ﻣﻨﺎﺑﻊ ﺳﯿﺴﺘﻢ در ﻣﻘﺎﺑﻞ ﮐـﺎرﺑﺮان ﻧﺎﺷﺎﯾـﺴﺖ، و ﻫﻤﭽﻨـﯿﻦ دادن دﺳﺘﺮﺳـﯽ ﺑـﻪ‬‫ﮐﺎرﺑﺮاﻧﯽ ﮐﻪ ﻣﺠﻮز دارﻧﺪ، ﻣﯽﺑﺎﺷﺪ. آﺳﯿﺐﭘﺬﯾﺮيﻫﺎي ﺳﯿﺴﺘﻢ ﮐﻪ ﺑﺮ روي اﻣﻨﯿﺖ ﺳﯿـﺴﺘﻢ ﺗـﺄﺛﯿﺮ ﻣـﯽﮔـﺬارد‬‫ﻣﻤﮑﻦ اﺳﺖ ﻣﻨﺸﺄ در ﮐﺪ ﺑﺮﻧﺎﻣﻪ داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﯾﺎ در ﮐﺎﻣﭙﻮﻧﻨﺖﻫﺎي ﺳﺨﺖاﻓﺰاري، ﻧﺮماﻓﺰاري ﯾﺎ ﻣﯿـﺎناﻓـﺰاري‬‫ﺳﯿﺴﺘﻢ. ﻫﺮدوي ﻣﺤﯿﻂ اﺟﺮا و ﻫﻤﭽﻨﯿﻦ ﺑﺮﻧﺎﻣﻪ ﻣﻤﮑﻦ اﺳﺖ در ﻧﻘﺺﻫﺎي اﻣﻨﯿﺘﯽ دﺧﯿـﻞ ﺑﺎﺷـﻨﺪ. در ﻣـﻮرد‬‫ﻧﺮماﻓﺰار ﻫﺎي ﻣﺒﺘﻨﯽ ﺑﺮ وب ﭘﯿﺎده ﺳﺎزيﻫﺎ و ﺗﮑﻨﻮﻟﻮژيﻫﺎي اﺟﺮاﯾﯽ ﻧـﺎﻫﻤﮕﻦ ﻫﻤـﺮاه ﺑـﺎ ﺗﻌـﺪاد ﺑـﺴﯿﺎر زﯾـﺎد‬‫ﮐﺎرﺑﺮان و ﻫﻤﭽﻨﯿﻦ اﻣﮑﺎن دﺳﺘﺮﺳﯽ آﻧﺎن از ﻫﺮ ﺟﺎﯾﯽ، اﯾﻦ ﺑﺮﻧﺎﻣﻪ ﻫـﺎ را از ﺑﺮﻧﺎﻣـﻪﻫـﺎي ﮐـﺎرﺑﺮدي ﻣﻌﻤـﻮﻟﯽ‬ ‫آﺳﯿﺐﭘﺬﯾﺮﺗﺮ ﺗﺴﺖ اﻣﻨﯿﺖ آﻧﻬﺎ را ﺳﺨﺖﺗﺮ ﻣﯽﺳﺎزد.‬‫ﺷﺶ ﻣﻔﻬﻮم اﺳﺎﺳﯽ اﻣﻨﯿﺖ ﮐﻪ ﺑﺎﯾﺪ در ﺗﺴﺖ اﻣﻨﯿﺖ ﭘﻮﺷﺶ داده ﺷﻮد ﺑﻪ اﯾـﻦ ﺷـﺮحاﻧـﺪ: ﻣﺤﺮﻣﺎﻧـﻪ ﺑـﻮدن،‬ ‫ﺟﺎﻣﻌﯿﺖ، ﺗﺼﺪﯾﻖ ﻫﻮﯾﺖ8، ﻣﺠﻮز دادن9، در دﺳﺘﺮس ﺑﻮدن و ﻋﺪم اﻧﮑﺎر.‬ ‫ﺗﺴﺖ ﭘﻮﺷﺶ‬‫ﺗﺴﺖ ﭘﻮﺷﺶ ﺑﻪ دو دﺳﺘﻪ ﮐﻠﯽ ﭘﻮﺷﺶ ﻋﺒﺎرات 01 و ﭘﻮﺷﺶ اﻧﺸﻌﺎﺑﺎت 11 ﻣﯽ ﺗﻮان ﺗﻘـﺴﯿﻢ ﻧﻤـﻮد. در ﺗـﺴﺖ‬‫ﭘﻮﺷﺶ ﻋﺒﺎرات، ﮐﺪ ﻃﻮري اﺟﺮا ﻣﯿﺸﻮد ﮐﻪ ﻫﺮ ﻋﺒﺎرﺗﯽ از ﺑﺮﻧﺎﻣﻪ ﺣﺪاﻗﻞ ﯾﮑﺒﺎر اﺟﺮا ﺷﻮد و اﯾﻦ ﺑﺎﻋﺚ ﻣﯿﺸﻮد‬ ‫ﺑﻔﻬﻤﯿﻢ ﻫﻤﻪ ﺟﻤﻼت ﺑﺪون اﺛﺮ ﺟﺎﻧﺒﯽ اﺟﺮا ﻣﯿﺸﻮﻧﺪ.‬‫از آﻧﺠﺎﺋﯿﮑﻪ ﻫﯿﭻ ﺑﺮﻧﺎﻣﻪ ﻧﺮماﻓﺰاري ﻧﻤﯿﺘﻮاﻧﺪ در ﻣﺪ ﭘﯿﻮﺳﺘﻪ اي از ﮐﺪ اﺟﺮا ﺷﻮد، در ﺑﻌﻀﯽ از ﻧﻘﺎط ﻧﯿﺎز اﺳﺖ‬‫ﮐﻪ ﺑﺮاي ﯾﮏ ﻋﻤﻠﮑﺮد ﺧﺎص ﺑﻪ ﻧﻘﻄﻪ اي ﺧﺎرج از ﮐﺪ اﻧﺸﻌﺎب ﮐﻨﯿﻢ. ﺗﺴﺖ ﭘﻮﺷﺎﻧﺪن اﻧﺸﻌﺎﺑﺎت ﮐﻤﮏ ﻣﯿﮑﻨـﺪ‬‫ﮐﻪ ﻫﻤﻪ اﻧﺸﻌﺎﺑﺎت در ﮐﺪ را ارزﯾﺎﺑﯽ ﮐﻨﯿﻢ و اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﮐﻨﯿﻢ ﮐﻪ ﻫﯿﭻ اﻧﺸﻌﺎﺑﯽ در ﮐﺪ ﻣﻨﺠﺮ ﺑـﻪ رﻓﺘـﺎر‬ ‫ﻏﯿﺮ ﻧﺮﻣﺎل در ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي ﻧﻤﯿﺸﻮد.‬‫8‬ ‫‪Authentication‬‬‫9‬ ‫‪Authorization‬‬‫01‬ ‫‪statement coverage‬‬‫11‬ ‫‪Branch Coverage‬‬
    • ‫٠١‬ ‫روشﻫﺎي ﺗﺴﺖ‬‫ﻃﺮاﺣﯽ ﺗﺴﺖﻫﺎﯾﯽ ﺑﺮاي ﻧﺮماﻓﺰار و ﻫﺮ ﻣﺤﺼﻮل ﻣﻬﻨﺪﺳﯽ دﯾﮕﺮ، ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ اﻧﺪازه ﻃﺮاﺣﯽ ﺧـﻮد ﻣﺤـﺼﻮل‬‫اوﻟﯿﻪ دﺷﻮار ﺑﺎﺷﺪ. ﺑﺎ اﯾﻦ ﺣﺎل ﺑﻪ دﻻﯾﻠﯽ ﮐﻪ ﭘﯿﺶ از اﯾﻦ ﺑﺤﺚ ﺷﺪ، ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻏﺎﻟﺒﺎ" ﺑـﺎ ﺗـﺴﺖ ﺑـﻪ‬‫ﻋﻨﻮان ﻣﻮارد ﺗﺴﺖ در ﺣﺎل ﺗﻮﺳﻌﻪ اي رﻓﺘﺎر ﻣﯽ ﮐﻨﻨﺪ، ﮐﻪ ﻣﻤﮑﻦ اﺳﺖ درﺳﺖ ﺑﻪ ﻧﻈﺮ آﯾﻨﺪ، وﻟـﯽ از ﮐﺎﻣـﻞ‬‫ﺑﻮدن آﻧﻬﺎ ﭼﻨﺪان اﻃﻤﯿﻨﺎﻧﯽ ﻧﺒﺎﺷﺪ. ﺑﺎ ﺑﺨﺎﻃﺮ داﺷﺘﻦ اﻫﺪاف ﺗﺴﺖ، ﺑﺎﯾﺪ ﺗﺴﺖ ﻫـﺎﯾﯽ را ﻃﺮاﺣـﯽ ﮐﻨـﯿﻢ ﮐـﻪ‬‫اﺣﺘﻤﺎل ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎ در ﺣﺪاﻗﻞ زﻣﺎن، ﺑﯿﺸﺘﺮ ﺑﺎﺷﺪ. ﻫﺮ ﻣﺤﺼﻮل ﻣﻬﻨﺪﺳﯽ )و اﮐﺜﺮ ﭼﯿﺰﻫﺎي دﯾﮕـﺮ( را ﻣـﯽ‬ ‫ﺗﻮان ﺑﻪ ﯾﮑﯽ از دو روش آزﻣﺎﯾﺶ ﮐﺮد:‬‫ﺑﺎ داﻧﺴﺘﻦ ﻋﻤﻠﮑﺮد ﺧﺎﺻﯽ ﮐﻪ ﻧﺮم اﻓﺰار ﺑﺮاي اﻧﺠﺎم آن ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ، ﻣﯽ ﺗﻮان ﺗـﺴﺖ ﻫـﺎﯾﯽ ﻃﺮاﺣـﯽ‬‫ﮐﺮد ﮐﻪ ﻧﺸﺎن ﻣﯽ دﻫﻨﺪ ﻫﺮ ﻋﻤﻠﮑﺮد ﺑﻪ ﻃﻮر ﮐﺎﻣﻞ درﺳﺖ اﺳﺖ، و در ﻋﯿﻦ ﺣﺎل، در ﻫﺮ ﻋﻤﻠﮑـﺮد ﺑـﻪ دﻧﺒـﺎل‬ ‫ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎ ﻫﺴﺘﻨﺪ.‬‫ﺑﺎ داﻧﺴﺘﻦ ﻃﺮز ﮐﺎر داﺧﻠﯽ ﻣﺤﺼﻮل، ﻣﯽ ﺗﻮان ﺗﺴﺖ ﻫﺎﯾﯽ ﺗﺮﺗﯿﺐ داد ﮐﻪ اﻃﻤﯿﻨﺎن دﻫﻨﺪ ﻫﻤﻪ ﭼﯿﺰ ﺟﻔـﺖ و‬‫ﺟﻮر اﺳﺖ. ﯾﻌﻨﯽ، ﻋﻤﻠﯿﺎت داﺧﻠﯽ ﻃﺒﻖ ﻣﺸﺨﺼﻪ اﺟﺮا ﻣﯽ ﺷﻮﻧﺪ و ﺑﺎ ﻫﻤﻪ ﻣﺆﻟﻔﻪ ﻫﺎي داﺧﻠﯽ ﺑﻪ ﻃﻮر ﻣﻨﺎﺳﺐ‬ ‫ﺗﻤﺮﯾﻦ ﺷﺪه اﺳﺖ.‬‫روش اول را ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه و دوﻣﯽ را ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻣﯽ ﻧﺎﻣﻨﺪ. در ﺳﺎﻟﻬﺎي اﺧﯿﺮ ﯾﮏ روش ﺑﯿﻨﺎﺑﯿﻨﯽ‬‫ﻫﻢ ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﮔﺮﻓﺘﻪ اﺳﺖ ﮐﻪ در ﻣﻮاﻗﻌﯽ ﮐﻪ دﺳﺘﺮﺳﯽ ﺑﻪ ﺑﺮﺧﯽ از ﻣﻮﻟﻔﻪ ﻫﺎي داﺧﻠـﯽ ﻧـﺮماﻓـﺰار ﻫـﺎ‬‫دارﯾﻢ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﯽ ﮔﯿﺮد. ﯾﻪ اﯾﻦ روس ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻣـﯽ ﮔﻮﯾﻨـﺪ. در اﯾـﻦ ﺑﺨـﺶ اﯾـﻦ‬ ‫روﺷﻬﺎ را ﺑﻪ ﺗﻔﺼﺒﯿﻞ ﺷﺮح ﻣﯽ دﻫﯿﻢ.‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه‬‫اﯾﻦ ﻧﻮع از ﺗﺴﺖ ﺑﺎ ﻧﺮماﻓﺰار ﺑﻪ ﻋﻨﻮان ﯾﮏ ﺟﻌﺒﻪ ﺳﯿﺎه ﺑﺮﺧﻮرد ﻣﯿﮑﻨﻨﺪ ﮐﻪ ﻫﯿﭻ درﮐـﯽ از رﻓﺘـﺎر داﺧﻠـﯽ ان‬‫وﺟﻮد ﻧﺪارد . ﻫﺪف ان ﺗﺴﺖ ﮐﺮدن ﻋﻤﻠﮑﺮد ﻧﺮماﻓﺰار ﻣﻄﺎﺑﻖ ﺑﺎ ﻧﯿﺎزﻣﻨﺪﯾﻬﺎﺳﺖ ، ﺗـﺎ ﺑﺒﯿﻨـﺪ ﮐـﻪ ﺗـﺎ ﭼـﻪ ﺣـﺪ‬
    • ‫١١‬‫ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ذﮐﺮ ﺷﺪه ﺑﺮاورده ﻣﯿﺸﻮﻧﺪ.ﺑﻨﺎﺑﺮاﯾﻦ ﻃﺮاح ﺗﺴﺖ داده ﻫـﺎ را وارد ﻣﯿﮑﻨـﺪ و ﺧﺮوﺟـﯽ را از ﺷـﯽ؛‬‫ﺗﺴﺖ ﻣﯽﺑﯿﻨﺪ.ﺑﺮاي اﯾﻦ ﺳﻄﺢ از اﺟﺮاي ﺗﺴﺖ ، ﻧﯿﺎز اﺳﺖ ﺗﺎ ﻃﺮاح ﺗﺴﺖ ، ﻣﻮارد ﺗﺴﺖ ﻃﺮاﺣـﯽ ﺷـﺪه را ﺑـﻪ‬‫ﺗﺴﺖ ﮐﻨﻨﺪه ،ﮐﺴﯽ ﮐﻪ ﺑﺎﯾﺪ ﺑﺮرﺳﯽ ﮐﻨﺪ ﮐﻪ اﯾﺎ ﺑﺮاي ﯾﮏ ورودي ﺧﺎص ، ﻣﻘﺪار ﺧﺮوﺟﯽ ﯾﺎ رﻓﺘـﺎر ﺳﯿـﺴﺘﻢ ،‬‫ﻣﻨﻄﺒﻖ ﺑﺮ اﻧﭽﻪ ﻣﻮرد اﻧﺘﻈﺎر اﺳﺖ و در ﻣﻮرد ﺗﺴﺖ ذﮐﺮ ﺷﺪه ﻫﺴﺖ ﯾﺎ ﻧﻪ .ﺑﺮاي ﻃﺮاﺣـﯽ ﻣـﻮارد ﺗـﺴﺖ ﯾـﮏ‬‫دﯾﺪﮔﺎه ﺧﺎرﺟﯽ از ﺳﯿﺴﺘﻢ ﻣﯿﮕﯿﺮد و اﯾﻦ ﻧﻮع ﺗﺴﺘﻬﺎ ﻣﯿﺘﻮاﻧﻨﺪ ﻋﻤﻠﮑﺮدي 21 ﯾﺎ ﻏﯿﺮ ﻋﻤﻠﮑﺮدي31 ﺑﺎﺷﻨﺪ ﮐـﻪ‬‫ﻣﻌﻤﻮﻻً ﻋﻤﻠﮑﺮدي ﻋﻤﻞ ﻣﯿﮑﻨﻨﺪ . ﻃﺮاﺣﺎن ﺗﺴﺖ ورودﯾﻬﺎي ﻣﻌﺘﺒﺮ و ﻏﯿﺮ ﻣﻌﺘﺒﺮ را اﻧﺘﺨﺎب ﻣﯿﮑﻨﻨﺪ و ﺧﺮوﺟﯽ‬ ‫درﺳﺖ را اﻧﺘﺨﺎب ﻣﯿﮑﻨﻨﺪ . و ﻫﯿﭻ داﻧﺸﯽ از ﺳﺎﺧﺘﺎر داﺧﻠﯽ ﺷﯽء در دﺳﺘﺮس ﻧﯿﺴﺖ.]50‪[PRE‬‬‫اﯾﻦ روش از ﻃﺮاﺣﯽ ﺗﺴﺖ در ﻫﻤﻪ ﻣﺮاﺣﻞ از ﺗﺴﺖ ﻧﺮماﻓـﺰار ﻗﺎﺑـﻞ اﺳـﺘﻔﺎده اﺳـﺖ . ﺗـﺴﺖ واﺣـﺪ و ﺗـﺴﺖ‬‫ﯾﮑﭙﺎرﭼﮕﯽ و ﺗﺴﺖ ﻋﻤﻠﮑﺮد و ﺗﺴﺖ ﺳﯿﺴﺘﻢ و ﺗﺴﺖ ﭘﺬﯾﺮش .ﺑﺎﻻﺗﺮﯾﻦ ﺳﻄﺢ و ﺑﺎﻟﻄﺒﻊ ﺑﺰرﮔﺘﺮﯾﻦ و ﭘﯿﭽﯿـﺪه‬‫ﺗﺮﯾﻦ ﺟﻌﺒﻪ ﺑﺎﯾﺪ ﺑﺼﻮرت ﺟﻌﺒﻪ ﺳﯿﺎه ﺻﻮرت ﮔﯿﺮد ﺗﺎ ﺳﺎده ﺗﺮ ﺷﻮد.ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه ﮐﻪ ﺗـﺴﺖ رﻓﺘـﺎري ﻧﯿـﺰ‬‫ﻧﺎﻣﯿﺪه ﻣﯿﺸﻮد روي ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻋﻤﻠﮑﺮدي ﻧﺮماﻓﺰار ﺗﻤﺮﮐﺰ ﻣﯿﮑﻨﺪ.ﺗﺴﺖ ﺟﻌﺒﻪ ﺳـﯿﺎه اﺳـﺖ ﮐـﻪ ﻣﻬﻨﺪﺳـﺎن‬‫ﻧﺮماﻓﺰار را ﻗﺎدر ﻣﯿﮑﻨﺪ ﺗﺎ ﻣﺠﻤﻮﻋﻪ اي از ﺷﺮاﯾﻂ ورودي را ﻣﺸﺘﻖ ﮐﻨﻨـﺪ ﮐـﻪ ﺗـﺎ ﮐـﺎﻣﻼً ﻫﻤـﻪ ﻧﯿﺎزﻣﻨـﺪﯾﻬﺎي‬‫ﻋﻤﻠﮑﺮدي ﺑﺮﻧﺎﻣﻪ را ﻣﻮرد ﺑﺮرﺳﯽ ﻗﺮار دﻫﻨﺪ.ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎ ه ﯾﮏ ﺟﺎﯾﮕﺰﯾﻦ ﺑﺮاي ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻧﯿﺴﺖ‬‫ﺑﻠﮑﻪ ﯾﮏ روش ﻣﮑﻤﻞ ﮐﻪ ﯾﮏ ﮐﻼس ﻣﺘﻔﺎوﺗﯽ از ﺧﻄﺎ ﻫﺎ را ﻧﺴﺒﺖ ﺑﻪ روﺷﻬﺎي ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﭘﻮﺷﺶ ﻣﯿﺪﻫﺪ.‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ‬‫زﻣﺎﻧﯽ ﻣﻤﮑﻦ اﺳﺖ ﮐﻪ ﺗﺴﺖ ﮐﻨﻨﺪه ﺑﻪ ﺳﺎﺧﺘﺎر داده ﻫﺎي داﺧﻠﯽ و ﮐﺪ و اﻟﮕﻮرﯾﺘﻢ ﻫﺎ دﺳﺘﺮﺳﯽ دارد.روﺷﻬﺎي‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﺷﺎﻣﻞ اﯾﺠﺎد ﺗﺴﺘﻬﺎﯾﯽ اﺳﺖ ﮐﻪ ﺑﻌﻀﯽ از ﻣﻌﯿﺎرﻫﺎي ﭘﻮﺷﺶ ﮐﺪ41 را ﺑـﺮاورده ﻣﯿﮑﻨﻨـﺪ .‬‫ﺑﺮاي ﻣﺜﺎل ﻃﺮاح ﺗﺴﺖ ﻣﯿﺘﻮاﻧﺪ ﺗﺴﺘﻬﺎﯾﯽ را ﻃﺮاﺣﯽ ﮐﻨﺪ ﮐﻪ ﺑﺎﻋﺚ ﺷﻮد ﻫﻤﻪ ﻋﺒﺎرات ﺑﺮﻧﺎﻣﻪ ﺣﺎﻗﻞ ﯾﮑﺒﺎر اﺟﺮا‬‫21‬ ‫‪functional‬‬‫31‬ ‫‪non functional‬‬‫41‬ ‫‪code coverage‬‬
    • ‫٢١‬‫ﺷﻮﻧﺪ.ﺳﺎﯾﺮ ﻣﺜﺎﻟﻬﺎي ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻋﺒﺎرﺗﻨﺪ از ﺗﺴﺖ ﺟﻬﺶ 51 و روﺷﻬﺎي ﺗﺰرﯾـﻖ ﺧﻄـﺎ 61 . ﺗـﺴﺘﻬﺎي‬ ‫ﺟﻌﺒﻪ ﺳﻔﯿﺪ ، ﻫﻤﻪ ﺗﺴﺘﻬﺎي اﺳﺘﺎﺗﯿﮏ را ﺷﺎﻣﻞ ﻣﯿﺸﻮﻧﺪ.]50‪[PRE‬‬‫روﺷﻬﺎي ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻣﯿﺘﻮاﻧﻨﺪ ﺑﺮاي ارزﯾﺎﺑﯽ ﮐﺎﻣﻞ ﺑﻮدن ﯾﮏ ﻣﺠﻤﻮﻋﻪ ﺗﺴﺖ - ﮐﻪ ﺑﺎ روﺷـﻬﺎي ﺗـﺴﺖ‬‫ﺟﻌﺒﻪ ﺳﯿﺎه اﯾﺠﺎد ﺷﺪه اﻧﺪ-ﻧﯿﺰ ﺑﻪ ﮐﺎر رود.اﯾﻦ ﺑﻪ ﺗﯿﻢ ﻧﺮماﻓﺰاري اﺟﺎزه ﻣﯿﺪﻫﺪ ﮐﻪ ﻗـﺴﻤﺘﻬﺎﯾﯽ از ﺳﯿـﺴﺘﻢ را‬‫ارزﯾﺎﺑﯽ ﮐﻨﻨﺪ ﮐﻪ ﮐﻤﺘﺮ ﺗﺴﺖ ﺷﺪه اﻧﺪ و اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﺷﻮد ﮐﻪ ﻧﻘﺎط ﻋﻤﻠﮑـﺮد ﺧﯿﻠـﯽ ﻣﻬـﻢ ﺗـﺴﺖ ﺷـﺪه‬‫اﻧﺪ.دو ﻓﺮم ﻣﻌﻤﻮل از ﭘﻮﺷﺶ ﮐﺪ ﻋﺒﺎرﺗﻨﺪ از ، ﭘﻮﺷﺶ ﺗﺎﺑﻊ ، ﮐـﻪ روي ﺗﻮاﺑـﻊ اﺟـﺮا ﺷـﺪه ﮔـﺰارش ﻣﯿﺪﻫـﺪ و‬‫ﭘﻮﺷﺶ ﺟﻤﻼت ، ﮐﻪ روي ﺗﻌﺪاد ﺧﻄﻮط اﺟﺮا ﺷﺪه ﺑﺮاي ﺗﮑﻤﯿﻞ ﺗـﺴﺖ ﮔـﺰارش ﻣﯿﺪﻫـﺪ.از اﯾـﻦ دو ﻣﻌﯿـﺎر‬‫ﭘﻮﺷﺎﯾﯽ ﺣﺎﺻﻞ ﻣﯽﺷﻮد. ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻫﻤﭽﻨﯿﻦ ﻣﻤﮑﻦ اﺳﺖ ﺷﺎﻣﻞ ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ﺑـﺮاي ﻣـﺸﺨﺺ‬ ‫ﮐﺮدن ﻣﺜﻼً ﻣﻘﺎدﯾﺮ ﻣﺮزي ﺑﻪ ﮐﺎر رود.‬‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻣﺰاﯾﺎﯾﯽ دارد از ﺟﻤﻠﻪ: ﭼﻮن ﻻزﻣﻪ ان داﻧﺴﺘﻦ ﺳﺎﺧﺘﺎر داﺧﻠﯽ ﮐﺪ اﺳﺖ ﻓﻬﻤﯿـﺪن اﯾﻨﮑـﻪ‬‫ﭼﻪ ﻧﻮع از داده ﻫﺎي ورودي و ﺧﺮوﺟﯽ ﺑﺮاي ﺗﺴﺖ ﮐﺎراﺗﺮ ﺑﺮﻧﺎﻣﻪ ﻣﻨﺎﺳﺐ اﺳﺖ، آﺳﺎﻧﺘﺮ ﻣﯽﺷﻮد. ﻣﺰﯾﺖ دﯾﮕـﺮ‬‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ آﻧﺴﺖ ﮐﻪ ﺑﻪ ﺑﻬﯿﻨﻪ ﺳﺎزي ﮐﺪ ﻧﯿﺰ ﮐﻤﮏ ﻣﯽﮐﻨﺪ. ﺑﻪ ﭘﺎك ﮐﺮدن ﺧﻄﻮط اﺿـﺎﻓﯽ ﮐـﺪ ﻧﯿـﺰ‬ ‫ﮐﻤﮏ ﻣﯽﮐﻨﺪ. اﯾﻦ ﺧﻄﻮط اﺿﺎﻓﯽ ﻣﻤﮑﻦ اﺳﺖ ﻣﻨﺠﺮﺑﻪ ﺧﻄﺎﻫﺎي ﭘﻨﻬﺎن ﺷﻮﻧﺪ.‬‫ﻣﻌﺎﯾﺐ ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﺷﺎﻣﻞ ﻣﻮارد زﯾﺮ ﻣﯽﺷﻮﻧﺪ: ﭼﻮن اﮔﺎﻫﯽ و ﻣﻬـﺎرت از ﮐـﺪ و ﺳـﺎﺧﺘﺎر داﺧﻠـﯽ ﻧﯿـﺎز‬‫اﺳﺖ، ﯾﮏ ﺗﺴﺖ ﮐﻨﻨﺪه ﻣﺎﻫﺮ ﻧﯿﺎز اﺳﺖ ﺗﺎ اﯾﻦ ﻧﻮع ﺗﺴﺖ را اﻧﺠﺎم دﻫﺪ ﮐﻪ ﺑﺎﻋـﺚ اﻓـﺰاﯾﺶ ﻫﺰﯾﻨـﻪ ﻣـﯽﺷـﻮد.‬‫ﺑﺮرﺳﯽ ﻫﺮ ﻗﻄﻌﻪ از ﮐﺪ و ﺑﺪﻧﺒﺎل ﺧﻄﺎﻫﺎي ﭘﻨﻬﺎن ﮔﺸﺘﻦ ﺗﻘﺮﯾﺒﺎً ﻏﯿﺮ ﻣﻤﮑﻦ اﺳﺖ و ﻫﻤﭽﻨﯿﻦ ﻣﻤﮑـﻦ اﺳـﺖ‬ ‫ﻣﻨﺠﺮﺑﻪ ﻣﺸﮑﻼﺗﯽ ﺷﻮد ﮐﻪ ﺑﺎﻋﺚ ﺷﮑﺴﺖ ﺑﺮﻧﺎﻣﻪ ﻣﯽﺷﻮﻧﺪ.‬‫51‬ ‫‪mutation testing‬‬‫61‬ ‫‪fault injection‬‬
    • ‫٣١‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي‬‫در ﺳﺎلﻫﺎي اﺧﯿﺮ ﻋﺒﺎرت ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻧﯿﺰ ﺑﻪ اﺳﺘﻔﺎده ﻣﻌﻤﻮل اﺿﺎﻓﻪ ﺷﺪه اﺳـﺖ. ﮐـﻪ ﺑـﻪ ﻣﻌﻨـﺎي‬‫داﺷﺘﻦ دﺳﺘﺮﺳﯽ ﺑﻪ ﺳﺎﺧﺘﻤﺎن داده ﻫﺎي داﺧﻠﯽ و اﻟﮕﻮرﯾﺘﻤﻬﺎ ﺑﺮاي اﯾﻨﮑﻪ ﺑﺘـﻮاﻧﯿﻢ ﻣـﻮارد ﺗـﺴﺖ را ﻃﺮاﺣـﯽ‬ ‫ﮐﻨﯿﻢ و در ﺳﻤﺖ ﮐﺎرﺑﺮ ﯾﺎ در ﺳﻄﺢ ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه اﺳﺘﻔﺎده ﮐﻨﯿﻢ.‬‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻣﺨﺼﻮﺻﺎً در ﻣﻮاﻗﻌﯽ ﮐﻪ ﻣﯿﺨﻮاﻫﯿﻢ ﺗﺴﺖ رﮔﺮﺳﯿﻮن را ﺑﯿﻦ دو ﻣﺎژول از ﮐﺪ ﮐـﻪ ﺑـﻪ‬‫وﺳﯿﻠﻪ دو ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ ﻣﺨﺘﻠﻒ ﻧﻮﺷﺘﻪ ﺷﺪه– و ﻓﻘﻂ اﯾﻨﺘﺮﻓﯿﺲ ﻫﺎ ﺑﺮاي ﺗﺴﺖ در دﺳﺘﺮس ﻫﺴﺘﻨﺪ -ﺑﻪ ﮐـﺎر‬ ‫ﻣﯿﺮود .‬ ‫ﺗﺴﺖ ﺳﯿﺴﺘﻤﻬﺎي ﻣﺒﺘﻨﯽ ﺑﺮوب‬‫وﯾﮋﮔﯿﻬﺎي ﺧﺎص ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب ﺑﻄﻮر ﻣﺴﺘﻘﯿﻢ ﺑﺮ ﻣﻮﺿﻮع ﺗﺴﺖ اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ ﺗـﺎﺛﯿﺮ ﻣـﯽﮔﺬارﻧـﺪ.‬‫ﻧﺘﯿﺠﻪ اﯾﻦ وﯾﮋﮔﯿﻬﺎ و ﭘﯿﭽﯿﺪﮔﯿﻬﺎ آن اﺳﺖ ﮐﻪ روﺷﻬﺎ و اﺑﺰارﻫﺎ و ﻣـﺪﻟﻬﺎي راﯾـﺞ ﺑـﺮاي ﺗـﺴﺖ ﻧـﺮماﻓﺰارﻫـﺎي‬‫ﻣﺘﺪاول، ﻣﻌﻤﻮﻻ ﺑﺮاي ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، ﮐﺎﻓﯽ ﻧﻤﯽﺑﺎﺷﻨﺪ. ﺑﺮﺧﯽ از اﯾﻦ روﺷﻬﺎ ﻧﯿﺎزﻣﻨﺪ ﺗﻐﯿﯿـﺮ و‬‫ﺗﻄﺒﯿﻖ ﺑﺎ ﻣﺤﯿﻂ وب ﻣﯽﺑﺎﺷﻨﺪ و ﺑﺮﺧﯽ ﻧﯿﺰ ﺑﮑﻠﯽ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻧﻤﯽﺑﺎﺷﻨﺪ. ﻫﻤﭽﻨﯿﻦ ﺑـﺮاي ﺗـﺴﺖ ﺑﺮﺧـﯽ از‬ ‫ﻣﻮارد، ﻧﯿﺎزﻣﻨﺪ روﺷﻬﺎ و ﻣﺪﻟﻬﺎي ﺟﺪﯾﺪ ﮐﻪ ﻣﺨﺼﻮص ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ ﻣﯽﺑﺎﺷﻨﺪ، ﻫﺴﺘﯿﻢ.‬‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﯾﻨﮑﻪ در ﺗﻮﺳﻌﻪ ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب، ﻣﻌﻤﻮﻻً از ﻣﺪل ﺗﻮﺳﻌﻪ ﺳﺮﯾﻊ )‪ (RAD‬اﺳﺘﻔﺎده ﻣﯽﺷـﻮد،‬‫ﻓﺮﺻﺖ ﮐﻤﺘﺮي ﺑﺮاي ﺗﺴﺖ ﺳﯿﺴﺘﻢ در اﺧﺘﯿﺎر ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن ﻣﯽﺑﺎﺷﺪ. ﻫﻤﭽﻨﯿﻦ ﺑﺮﺧﯽ ﻣﻮارد ﻧﻈﯿﺮ ﺗـﺴﺖ‬‫ﻣﻘﯿﺎس ﭘﺬﯾﺮي، ﻣﻤﮑﻦ اﺳﺖ ﺑﻄﻮر دﻗﯿﻖ ﻗﺎﺑﻞ اﺟﺮا ﻧﺒﺎﺷﻨﺪ ﯾﺎ ﻫﺰﯾﻨﻪ اﺟﺮاي آﻧﻬﺎ زﯾﺎد ﺑﺎﺷﺪ. در ﻧﺘﯿﺠﻪ ﺑﻪ ﻧﻈﺮ‬‫ﻣﯽرﺳﺪ ﮐﻪ ﺑﺮاي ﺑﺮﺧﯽ اﻧﻮاع ﺗﺴﺖ، ﻻزم اﺳﺖ ﮐﻪ ﺳﯿﺴﺘﻢ اﺑﺘﺪا ﺑﻄﻮر ﮐﺎﻣﻞ زﯾـﺮ ﺑـﺎر ﺑـﺮود و در ﺗﻌﺎﻣـﻞ ﺑـﺎ‬ ‫ﮐﺎرﺑﺮان واﻗﻌﯽ ﮐﻪ رﻓﺘﺎرﻫﺎﯾﺸﺎن ﻟﺰوﻣﺎ ﻗﺎﺑﻞ ﭘﯿﺶ ﺑﯿﻨﯽ ﻧﯿﺴﺖ، ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﮔﯿﺮد.‬‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺣﺴﺎﺳﯿﺖ زﯾﺎد ﻧﺴﺒﺖ ﺑﻪ زﻣﺎن ﺗﻮﺳﻌﻪ اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ، ﻫﻤﭽﻨﯿﻦ ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ اﯾﻨﮑـﻪ ﺗﺮﮐﯿﺒـﺎت‬‫ﻣﺘﻌﺪدي از ﻣﺮورﮔﺮﻫﺎ، ﺳﯿﺴﺘﻢ ﻋﺎﻣﻠﻬﺎ، و ﻣﺤﯿﻄﻬﺎي اﺟﺮا وﺟﻮد دارد، اﮔﺮ ﺑﺨﻮاﻫﯿﻢ ﯾﮏ ﺳﯿـﺴﺘﻢ را در ﺑﺮاﺑـﺮ‬‫ﺗﻤﺎم اﯾﻦ ﺗﺮﮐﯿﺒﺎت ﻣﻮرد ﺗﺴﺖ ﻗﺮار دﻫﯿﻢ، ﻧﯿﺎز ﺑﻪ ﺧﻮدﮐﺎرﺳﺎزي رواﻟﻬﺎي ﺗﺴﺖ ﺑﻪ ﺷﮑﻞ ﭼﺸﻤﮕﯿﺮي، اﻓﺰاﯾﺶ‬
    • ‫٤١‬‫ﻣﯽﯾﺎﺑﺪ. ﻫﻤﭽﻨﯿﻦ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﯾﻨﮑﻪ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب داﺋﻤﺎً در ﺣﺎل ﺗﻐﯿﯿـﺮ و ﺑﺮوزرﺳـﺎﻧﯽ ﻣـﯽﺑﺎﺷـﻨﺪ،‬‫ﻗﺎﺑﻠﯿﺖ اﺟﺮاي ﻣﺠﺪد ﺗﺴﺖ ﻫﺎ ﺑﻄﻮر ﺧﻮدﮐﺎر، ﺑﺴﯿﺎر ﻣﻮرد ﻧﯿﺎز ﻣﯽﺑﺎﺷﺪ. ﺑﺪﯾﻦ ﺗﺮﺗﯿﺐ ﻣﯽﺗﻮان ﭘـﺲ از اﻧﺠـﺎم‬‫ﺣﺠﻢ ﻣﻨﺎﺳﺒﯽ از ﺗﻐﯿﯿﺮات ﺑﺮ روي ﺳﯿﺴﺘﻢ، دوﺑﺎره ﺗﺴﺖ ﻫﺎ را ﺑﻄﻮر ﺧﻮدﮐﺎر ﺑﺮ روي ﺳﯿـﺴﺘﻢ اﻧﺠـﺎم داد. در‬‫ﻣﻮرد ﺳﯿﺴﺘﻢ ﻫﺎي ﻣﺘﺪاول، ﻣﻌﻤﻮﻻً ﭘﺲ از اراﺋﻪ ﺳﯿﺴﺘﻢ ﺑﻪ ﺑﺎزار و ﻣﺸﺘﺮﯾﺎن، ﺗﻐﯿﯿﺮات ﺳﯿﺴﺘﻢ ﺧﯿﻠﯽ ﻣﺤﺪود‬‫اﺗﻔﺎق ﻣﯽاﻓﺘﺪ و در ﻓﻮاﺻﻞ زﻣﺎﻧﯽ ﻣﺘﻔﺎوت، ﻧﺴﺨﻪ ﻫﺎي ﺟﺪﯾﺪ ﻧﺮماﻓـﺰار ﯾـﺎ وﺻـﻠﻪ ﻫـﺎي اﻣﻨﯿﺘـﯽ آن، ﺗﻮزﯾـﻊ‬‫ﻣﯽﺷﻮﻧﺪ در ﻧﺘﯿﺠﻪ ﻧﺮخ ﺗﻐﯿﯿﺮات ﺑﺴﯿﺎر ﭘﺎﯾﯿﻦ اﺳﺖ. اﻣﺎ در ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، ﭼـﻮن ﺳﯿـﺴﺘﻢ ﺑـﺮ روي‬‫ﺳﺮور ﻧﺼﺐ ﻣﯽﺷﻮد و از ﻃﺮﯾﻖ ﺷﺒﮑﻪ ﻗﺎﺑﻞ دﺳﺘﺮس اﺳﺖ، اﯾﻦ اﻣﮑـﺎن وﺟـﻮد دارد ﮐـﻪ ﻃﺮاﺣـﺎن ﺳﯿـﺴﺘﻢ،‬ ‫ﺑﺮاﺣﺘﯽ و ﺑﻄﻮر ﻣﺪاوم ﺳﯿﺴﺘﻢ را ﺑﺮوزرﺳﺎﻧﯽ ﻧﻤﺎﯾﻨﺪ و ﺗﻐﯿﯿﺮات ﻻزم را اﻋﻤﺎل ﻧﻤﺎﯾﻨﺪ.‬‫ﯾﮑﯽ از ﻣﺴﺎﺋﻞ ﻣﻬﻢ در ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب آن اﺳﺖ ﮐﻪ ﻫﻨﻮز ﻣﻌﯿﺎرﻫﺎي دﻗﯿـﻖ و ﻗﺎﺑـﻞ اﻋﺘﻤـﺎد و‬ ‫ﻣﻮرد ﺗﻮاﻓﻖ، ﺑﺮاي ﺗﺴﺖ اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ، ﻣﻌﺮﻓﯽ ﻧﺸﺪه اﺳﺖ.‬‫ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، در ﻃﻮل زﻣﺎن ﺑﺴﯿﺎر ﺗﻐﯿﯿﺮ ﮐﺮده اﻧﺪ. ﺳﯿﺴﺘﻢ ﻫﺎي اوﻟﯿﻪ، ﺷـﺎﻣﻞ ﺻـﻔﺤﺎت اﯾـﺴﺘﺎي‬‫‪ HTML‬ﺑﻮدﻧﺪ. اﻣﺎ ﺳﯿﺴﺘﻤﻬﺎي اﻣﺮوزي، ﺷﺎﻣﻞ ﺻﻔﺤﺎت ﭘﻮﯾﺎ ﺑﺎ ﺗﺮﮐﯿﺒﯽ از ﺗﮑﻨﻮﻟـﻮژي ﻫـﺎي ﻣﺘﻔـﺎوت، ﻧﻈﯿـﺮ‬‫‪ XML ،JSP ،ASP ،PHP‬و ‪ JDBC‬ﻣﯽﺑﺎﺷﻨﺪ. ﻣﻮاردي ﻧﻈﯿﺮ ﻗﺎﻟﺐﻫﺎي ﭼﻨﺪرﺳﺎﻧﻪاي ﺟﺪﯾﺪ، و ﯾﺎ ﺗﮑﻨﻮﻟﻮژي‬‫‪ ،AJAX‬اﻓﺰاﯾﺶ اﺟﺰاي ﻣﺨﺘﻠﻔﯽ ﮐﻪ در ﻃﺮاﺣﯽ ﺳﯿﺴﺘﻢ دﺧﯿﻞ ﻫﺴﺘﻨﺪ، ﻫﻤﻪ و ﻫﻤـﻪ ﺑـﻪ ﭘﯿﭽﯿـﺪه و ﭘﻮﯾـﺎﺗﺮ‬ ‫ﺷﺪن اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ ﻣﻨﺠﺮ ﺷﺪه اﻧﺪ.‬‫ﻫﺪف اﺻﻠﯽ ﺗﺴﺖ ﯾﮏ ﺳﯿﺴﺘﻢ ﺗﺤﺖ وب، اﺟﺮاي آن ﺳﯿﺴﺘﻢ ﺑﻪ ﻣﻨﻈﻮر ﮐـﺸﻒ ﺧﺮاﺑـﯽ ﻫـﺎ و ﺧﻄﺎﻫـﺎي آن‬‫ﻣﯽﺑﺎﺷﺪ. ﺧﺮاﺑﯽ )‪ ،(failure‬ﺑﻪ ﯾﮏ ﻧﺎﺗﻮاﻧﯽ ﻣﺸﺨﺺ ﺳﯿﺴﺘﻢ در اﺟﺮاي ﯾﮏ وﻇﯿﻔﻪ از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷـﺪه ﺑـﺮ‬‫اﺳﺎس ﻣﻌﯿﺎرﻫﺎي ﺗﻌﺮﯾﻒ ﺷﺪه، ﻣﯽﺑﺎﺷﺪ. ﺑﺮﺧﯽ ﺧﺮاﺑﯽ ﻫﺎ ﻣﺮﺑﻮط ﺑﻪ ﺧﻄﺎﻫـﺎي ﻋﺎﻣـﻞ اﻧـﺴﺎﻧﯽ در ﻃﺮاﺣـﯽ و‬‫ﭘﯿﺎده ﺳﺎزي ﺳﯿﺴﺘﻢ ﻣﯽﺑﺎﺷﻨﺪ. اﻣﺎ ﺑﺮﺧﯽ ﺧﺮاﺑﯽ ﻫﺎ ﻧﯿﺰ ﻣﺮﺑﻮط ﺑﻪ ﻣﺤﯿﻂ اﺟﺮا، ﻣﺜﻼ ﺑﺎﮔﻬﺎي ﻧﺮماﻓﺰار ﻣﺮورﮔﺮ‬‫ﯾﺎ ﻣﺸﮑﻼت ﺷﺒﮑﻪ، ﻣﺮﺑﻮط ﻣﯽﺷﻮﻧﺪ و ﻣﻨﺸﺎ ﻣﺸﮑﻞ، ﻃﺮاﺣﺎن ﺳﯿﺴﺘﻢ ﻧﻤﯽﺑﺎﺷﻨﺪ. در ﻧﺘﯿﺠﻪ ﺑـﺮاي ﺗـﺸﺨﯿﺺ‬ ‫اﻧﻮاع ﻣﺨﺘﻠﻒ ﺧﺮاﺑﯽ ﻫﺎ، اﻧﻮاع ﻣﺘﻔﺎوت ﺗﺴﺖ ﻣﻮرد ﻧﯿﺎز ﻣﯽﺑﺎﺷﺪ.‬
    • ‫٥١‬‫ﺑﻄﻮر اﺳﺎﺳﯽ، ﻣﺤﯿﻂ اﺟﺮا، ﺑﺮ ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻏﯿﺮ ﻋﻤﻠﯿﺎﺗﯽ ﺳﯿﺴﺘﻢ، ﻧﻈﯿﺮ ﻣﻘﯿﺎس ﭘﺬﯾﺮي، ﺛﺒـﺎت، و ﺳـﺎزﮔﺎري‬‫ﺳﯿﺴﺘﻢ، ﺗﺎﺛﯿﺮﻣﯽﮔﺬارد و ﻧﻪ ﺑﺮ ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻋﻤﻠﯿﺎﺗﯽ ﺳﯿـﺴﺘﻢ، ﯾﻌﻨـﯽ ﺗﻄﺒﯿـﻖ ﺑـﯿﻦ آﻧﭽـﻪ ﺳﯿـﺴﺘﻢ اﻧﺠـﺎم‬‫ﻣﯽدﻫﺪ و آﻧﭽﻪ ﺑﺎﯾﺪ اﻧﺠﺎم دﻫﺪ. در ﻧﺘﯿﺠﻪ ﻣﻌﻤﻮﻻً ﺳﯿﺴﺘﻢ ﻣﺴﺌﻮل ارﺿﺎي ﻧﯿﺎزﻫﺎي ﻋﻤﻠﯿﺎﺗﯽ، و ﻣﺤﯿﻂ اﺟـﺮا‬‫ﻣﺴﺌﻮل ارﺿﺎي ﻧﯿﺎزﻫﺎي ﻏﯿﺮﻋﻤﻠﯿﺎﺗﯽ ﻣﯽﺑﺎﺷﺪ، اﻟﺒﺘﻪ ﺗﻔﮑﯿﮏ ﮐﺎﻣﻞ ﺑﯿﻦ اﯾﻦ دو ﻣﻮرد وﺟﻮد ﻧﺪارد. اﻣﺎ ﻣﯽﺗﻮان‬ ‫ﮔﻔﺖ ﮐﻪ ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب را ﻣﯽﺗﻮان از دو دﯾﺪﮔﺎه ﺑﺮرﺳﯽ ﻧﻤﻮد:‬‫1. از دﯾﺪﮔﺎه اول، ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻋﻤﻠﯿﺎﺗﯽ ﺳﯿﺴﺘﻢ ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ. ﯾﻌﻨﯽ ﻋﻤﻠﮑﺮد ﺳﯿﺴﺘﻢ در‬‫ﻣﻘﺎﯾﺴﻪ ﺑﺎ آﻧﭽﻪ ﮐﻪ ﺑﺎﯾﺪ اﻧﺠﺎم دﻫﺪ، ﯾﻌﻨﯽ ﻣﻨﻄﻖ ﺳﯿﺴﺘﻢ و وﻇﺎﯾﻒ ﺗﻌﺮﯾﻒ ﺷﺪه در ﻣﺴﺘﻨﺪات، ﻣﻮرد‬ ‫ﺗﺴﺖ ﻗﺮار ﻣﯽﮔﯿﺮد.‬ ‫2. از دﯾﺪﮔﺎه دوم، ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻏﯿﺮﻋﻤﻠﯿﺎﺗﯽ ﺳﯿﺴﺘﻢ ﻣﻮرد ارزﯾﺎﺑﯽ ﻗﺮارﻣﯽﮔﯿﺮﻧﺪ.‬‫ﻧﮑﺘﻪ ﻣﻬﻢ آن اﺳﺖ ﮐﻪ ﻫﺮ دو ﻧﻮع ﺗﺴﺖ ﺑﺎﯾﺪ ﺑﻄﻮر ﻣﻨﺎﺳﺐ اﺟﺮا ﺷﻮﻧﺪ و ﻧﻤﯽﺗﻮان ﯾﮑـﯽ از اﯾـﻦ دو ﻣـﻮرد را‬ ‫ﺟﺎﯾﮕﺰﯾﻦ دﯾﮕﺮي ﻧﻤﻮد. .‪Error! Reference source not found‬‬ ‫ﺳﻄﻮح ﻣﺨﺘﻠﻒ ﺗﺴﺖ‬ ‫ﺗﺴﺖ ﻧﺮماﻓﺰار در ﻓﺎزﻫﺎي ﻣﺘﻔﺎوت و در ﺳﻄﻮح ﻣﺨﺘﻠﻒ اﻧﺠﺎم ﻣﯽ ﭘﺬﯾﺮد. اﯾﻦ ﺳﻄﻮح ﻋﺒﺎرﺗﻨﺪ از:‬ ‫ﺗﺴﺖ واﺣﺪ‬‫ﯾﮑﯽ از ﻣﺮاﺣﻞ اوﻟﯿﻪ ﺗﺴﺖ ﯾﮏ ﺳﯿﺴﺘﻢ، ﺗﺴﺖ واﺣﺪ71، ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﻫﺮ ﯾﮏ از واﺣﺪﻫﺎ ﯾﺎ ﻣﺎژوﻟﻬﺎي ﺗـﺸﮑﯿﻞ‬‫دﻫﻨﺪه ﯾﮏ ﺑﺮﻧﺎﻣﻪ را ﺑﻄﻮر ﻣﺴﺘﻘﻞ، ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﻣﯽدﻫﺪ. ﻣﻌﻤﻮﻻ ﺗﺴﺖ واﺣﺪ ﺗﻮﺳﻂ ﺧﻮد ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾـﺴﺎن‬‫و ﺑﻪ ﻣﻮازات ﺗﻮﺳﻌﻪ ﺳﯿﺴﺘﻢ اﻧﺠﺎم ﻣﯽﺷﻮد. ﯾﻌﻨﯽ ﻫﺮ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﮐﻪ ﻣﺎژوﻟﯽ را ﺑﺮاي ﺳﯿﺴﺘﻢ ﻣـﯽﻧﻮﯾـﺴﺪ،‬‫ﺧﻮد، وﻇﯿﻔﻪ ﺗﺴﺖ آن ﻣﺎژول را ﻧﯿﺰ ﺑﻌﻬﺪه دارد و ﻧﯿﺎزي ﻧﯿﺴﺖ ﺗﺴﺖ آن ﻣﺎژول ﺑﻪ ﭘﺲ از ﺗﮑﻤﯿـﻞ ﺳﯿـﺴﺘﻢ‬ ‫ﻣﻮﮐﻮل ﺷﻮد.‬‫71‬ ‫‪Unit testing‬‬
    • ‫٦١‬‫ﻫﺪف از اﻧﺠﺎم ﺗﺴﺖ واﺣﺪ، اﻃﻤﯿﻨﺎن از درﺳﺘﯽ ﻋﻤﻠﮑﺮد واﺣﺪﻫﺎﯾﯽ اﺳﺖ ﮐﻪ ﭘـﺲ از ﺗﻮﺳـﻌﻪ، در ﻗـﺴﻤﺘﻬﺎي‬ ‫ﻣﺨﺘﻠﻒ ﺳﯿﺴﺘﻢ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﺧﻮاﻫﻨﺪ ﮔﺮﻓﺖ.‬‫ﺗﺴﺖ واﺣﺪ، ﻣﻌﻤﻮﻻ ﺟﺰء ﺗﺴﺘﻬﺎي ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﺑﻪ ﺣﺴﺎب آورده ﻣﯽﺷﻮد ﮐﻪ ﻧﯿﺎز ﺑـﻪ دﺳﺘﺮﺳـﯽ ﺑـﻪ ﺳـﺎﺧﺘﺎر‬ ‫دروﻧﯽ ﮐﺪ ﻣﻮرد ﺗﺴﺖ دارد.‬‫ﻻزم ﺑﻪ ذﮐﺮ اﺳﺖ ﮐﻪ ﻋﻠﯿﺮﻏﻢ اﻫﻤﯿﺖ ﺑﺴﯿﺎر زﯾﺎد ﺗﺴﺖ واﺣﺪ در ﻓﺮآﯾﻨﺪ ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓـﺰار، اﯾـﻦ ﻧـﻮع‬‫ﺗﺴﺖ ﻧﻤﯽﺗﻮاﻧﺪ ﺟﺎﯾﮕﺰﯾﻦ دﯾﮕﺮ اﻧﻮاع ﺗﺴﺖ ﺷﻮد. ﺑﻌﻨﻮان ﻣﺜﺎل، ﺑﺎ اﺳﺘﻔﺎده از ﺗﺴﺖ واﺣﺪ ﻧﻤـﯽﺗـﻮان ﮐﯿﻔﯿـﺖ‬‫راﺑﻂ ﮔﺮاﻓﯿﮑﯽ ﺳﯿﺴﺘﻢ را ارزﯾﺎﺑﯽ ﻧﻤﻮد ﯾـﺎ ﺗـﺴﺖ ﺑـﺎر را ﻧﻤـﯽﺗـﻮان ﺑـﺎ اﺳـﺘﻔﺎده از ﺗـﺴﺖ واﺣـﺪ اﻧﺠـﺎم داد‬ ‫]40‪.[Ham‬‬ ‫ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ‬‫ﻫﺪف از ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ ﺳﯿﺴﺘﻢ81، آن اﺳﺖ ﮐﻪ ﻣﻄﻤﺌﻦ ﺷﻮﯾﻢ اﺟﺰاي ﻣﺨﺘﻠﻒ ﺳﯿﺴﺘﻢ، در ﮐﻨﺎر ﯾﮑـﺪﯾﮕﺮ،‬‫ﺑﺨﻮﺑﯽ ﮐﺎر ﻣﯽﮐﻨﻨﺪ و ﺗﻌﺎﻣﻼت، ارﺗﺒﺎﻃﺎت و رد و ﺑﺪل ﮐﺮدن داده ﻫﺎ در ﺑـﯿﻦ ﻣﺎژوﻟﻬـﺎي ﻣﺨﺘﻠـﻒ ﺳﯿـﺴﺘﻢ،‬ ‫ﺑﺪرﺳﺘﯽ اﻧﺠﺎم ﻣﯽﺷﻮد و در ﻧﺘﯿﺠﻪ، ﮐﻞ ﺳﯿﺴﺘﻢ ﻋﻤﻠﮑﺮد ﺻﺤﯿﺤﯽ دارد.‬‫ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ را ﻣﯽﺗﻮان در ﺳﻄﻮح ﻣﺘﻔﺎوﺗﯽ اﻧﺠﺎم داد. ﻣـﺜﻼ، ﻣـﯽﺗـﻮان ﻫـﺮ ﯾـﮏ از ﻣﺎژوﻟﻬـﺎي اﺳﺎﺳـﯽ‬‫ﺳﯿﺴﺘﻢ را ﺑﻌﻨﻮان ﯾﮏ ﺳﯿﺴﺘﻢ در ﻧﻈﺮ ﮔﺮﻓﺖ )ﮐﻪ ﺧـﻮدش از اﺟـﺰاي ﮐـﻮﭼﮑﺘﺮي ﺗـﺸﮑﯿﻞ ﺷـﺪه( و ﺗـﺴﺖ‬‫ﯾﮑﭙﺎرﭼﮕﯽ را در ﻣﻮرد آن اﻧﺠﺎم داد. ﻫﻤﭽﻨﯿﻦ ﻣﯽﺗﻮان ﮐﻞ ﺳﯿﺴﺘﻢ را ﺑﻌﻨﻮان ﯾـﮏ ﺳﯿـﺴﺘﻢ واﺣـﺪ در ﻧﻈـﺮ‬ ‫ﮔﺮﻓﺘﻪ و آن را ﻣﻮرد ﺗﺴﺖ ﻗﺮار داد.‬‫ﻧﮑﺘﻪ ﻗﺎﺑﻞ ﺗﻮﺟﻪ آن اﺳﺖ ﮐﻪ ﻧﺒﺎﯾﺪ اﯾﻨﻄﻮر ﺗﺼﻮر ﺷﻮد ﮐﻪ اﻧﺠﺎم ﺗﺴﺖ واﺣﺪ ﺑﺮ روي ﻣﺎژوﻟﻬﺎي ﺳﯿﺴﺘﻢ، ﻣـﺎ را‬‫از اﻧﺠﺎم ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ ﺑﯽ ﻧﯿﺎز ﻣﯽﮐﻨﺪ. در واﻗﻊ ﻫﺮ دو ﻧﻮع ﺗﺴﺖ ﻣﺬﮐﻮر ﻻزم ﻣﯽﺑﺎﺷﻨﺪ و ﻫﺮ ﯾﮏ ﺗﻮاﻧﺎﯾﯽ‬‫ﺧﺎص ﺧﻮد را دارﻧﺪ. ﻧﻘﻄﻪ ﻣﻮرد ﺗﻮﺟﻪ ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ، ﻧﻘﺎط ﺗﻤﺎس و ﺗﻌﺎﻣﻞ ﻣﺎژوﻟﻬـﺎ ﺑـﺎ ﯾﮑـﺪﯾﮕﺮ اﺳـﺖ و‬‫81‬ ‫‪Integrity testing‬‬
    • ‫٧١‬‫ﻣﺎژوﻟﻬﺎ را در ﮐﻨﺎر ﯾﮑﺪﯾﮕﺮ و در ﺿﻤﻦ ﮐﺎر ﺑﺎ ﻫﻢ، ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﻣﯽدﻫﺪ، در ﺣﺎﻟﯿﮑﻪ ﺗﺴﺖ واﺣﺪ، ﻣﺎژوﻟﻬﺎ را‬ ‫ﺑﻄﻮر ﻣﺴﺘﻘﻞ و ﺟﺪا از ﺑﻘﯿﻪ اﺟﺰاي ﺳﯿﺴﺘﻢ ﻣﺪﻧﻈﺮ ﻗﺮار ﻣﯽدﻫﺪ. ]20‪[Chu05] [Cra‬‬ ‫ﺗﺴﺖ ﺳﯿﺴﺘﻢ‬‫ﯾﮏ ﺳﯿﺴﺘﻢ ﮐﺎﻣﻼً ﯾﮑﭙﺎرﭼﻪ را ﺗﺴﺖ ﻣﯽﮐﻨﺪ ﺗﺎ ﺑﺮرﺳﯽ ﮐﻨﺪ ﮐﻪ اﯾﺎ ﺗﻤﺎم ﻧﯿﺎزﻣﻨﺪﯾﻬﺎ ﺑﺮاورده ﻣﯽﺷﻮﻧﺪ ﯾـﺎ ﻧـﻪ.‬ ‫ﻗﺒﻞ از ﻋﺮﺿﻪ ﻧﺴﺨﻪ ﻧﻬﺎﯾﯽ ﯾﮏ ﻧﺮماﻓﺰار ، ﺗﺴﺘﻬﺎي اﻟﻔﺎ و ﺑﺘﺎ ﻧﯿﺰ ﻋﻼوه ﺑﺮ ﺗﺴﺘﻬﺎي ﻓﻮق اﻧﺠﺎم ﻣﯽﺷﻮﻧﺪ.‬‫ﺗﺴﺖ ﻋﻤﻠﮑﺮد ﺷﺒﯿﻪ ﺳﺎزي ﺷﺪه ﯾﺎ واﻗﻌﯽ ﺑﺎ ﻣﺸﺘﺮﯾﺎن ﯾﺎ ﮐﺎرﺑﺮان ﭘﺘﺎﻧﺴﯿﻞ ، ﯾﺎ ﯾﮏ ﺗـﯿﻢ ﺗـﺴﺖ ﻣـﺴﺘﻘﻞ در‬‫ﺳﺎﯾﺖ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﺎن .ﺗﺴﺖ اﻟﻔﺎ ﻣﻌﻤﻮﻻً ﺑﺮاي ﻧﺮماﻓﺰار ﻫﺎي ﺗﻮﻟﯿﺪ اﻧﺒﻮه ﺑﻪ ﻋﻨﻮان ﻧﻮﻋﯽ از ﺗﺴﺖ ﭘﺬﯾﺮش ﺑﮑـﺎر‬ ‫ﺑﺮده ﻣﯽﺷﻮد . و ﻗﺒﻞ از ﻣﺮﺣﻠﻪ ﺗﺴﺖ ﺑﺘﺎ ﺻﻮرت ﻣﯽﭘﺬﯾﺮد .‬‫ﻧﺴﺨﻪ ﻫﺎﯾﯽ از ﻧﺮماﻓﺰار ، ﮐﻪ ﻧﺴﺨﻪ ﻫﺎي ﺑﺘﺎ ﻧﺎﻣﯿﺪه ﻣﯿﺸﻮﻧﺪ ، ﺑﻪ ﻣﺨﺎﻃﺒﺎن ﻣﺤﺪودي در ﺧﺎرج از ﺗﯿﻢ ﺑﺮﻧﺎﻣﻪ‬‫ﻧﻮﯾﺴﺎن ﻋﺮﺿﻪ ﻣﯽﺷﻮد . ﻧﺮماﻓﺰار ﺑﻪ ﮔﺮوﻫﯽ از اﻓﺮاد ﻋﺮﺿﻪ ﻣﯿﺸﻮد ﺗﺎ ﺗﺴﺘﻬﺎي ﺑﯿﺸﺘﺮي اﻧﺠﺎم ﺷﻮد و اﻃﻤﯿﻨﺎن‬‫ﺣﺎﺻﻞ ﮐﻨﯿﻢ ﮐﻪ ﻧﺮماﻓﺰار ﺧﻄﺎ ﻫﺎ ﯾﺎ ﺑﺎﮔﻬﺎي ﮐﻤﯽدارد. ﮐﺎﻫﯽ اوﻗﺎت ﻧﺴﺨﻪ ﻫﺎي ﺑﺘﺎ ﺑﻪ ﻋﻤﻮم ﻋﺮﺿﻪ ﻣﯿﺸﻮد ﺗﺎ‬ ‫ﻣﯿﺰان ﺑﺎزﺧﻮرد ﻫﺎ اﻓﺰاﯾﺶ ﯾﺎﺑﺪ .‬ ‫ﺗﺴﺖ ﭘﺬﯾﺮش‬‫اﯾﻦ ﻧﻮع ﺗﺴﺖ ﺑﺮ اﺳﺎس ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻣﺴﺘﻨﺪ ﺷﺪه ﮐﺎرﺑﺮان ﺳﯿﺴﺘﻢ اﻧﺠﺎم ﻣﯽﺷﻮد و ﻫﺪف از اﻧﺠﺎم آن ﮐﺴﺐ‬‫اﻃﻤﯿﻨﺎن از ﺗﺎﻣﯿﻦ ﻧﯿﺎزﻫﺎي ﮐﺎرﺑﺮان ﺗﻮﺳﻂ ﺳﯿﺴﺘﻢ، ﻣﯽﺑﺎﺷﺪ. ﺑﻪ ﺑﯿﺎن دﯾﮕﺮ در اﯾﻦ ﻧﻮع ﺗـﺴﺖ ﻣـﯽﺧـﻮاﻫﯿﻢ‬‫ﻣﻄﻤﺌﻦ ﺷﻮﯾﻢ ﮐﻪ ﺳﯿﺴﺘﻢ ﺗﻮﻟﯿﺪ ﺷﺪه از دﯾﺪ ﮐﺎرﺑﺮان ﻗﺎﺑﻞ ﻗﺒﻮل اﺳﺖ ﯾﺎ ﺧﯿﺮ. ﺑﻬﻤﯿﻦ ﻋﻠﺖ ﺑﻬﺘﺮ اﺳﺖ اﻧﺠﺎم‬ ‫ﺗﺴﺖ ﺗﻮﺳﻂ ﺧﻮد ﮐﺎرﺑﺮان ﯾﺎ ﻧﻤﺎﯾﻨﺪﮔﺎن آﻧﻬﺎ و در ﻣﺤﯿﻂ و ﺷﺮاﯾﻂ واﻗﻌﯽ ﺻﻮرت ﮔﯿﺮد.]20‪[Chu05] [Cra‬‬‫در ﻧﻬﺎﯾﺖ ، ﺗﺴﺖ ﭘﺬﯾﺮش ﺗﻮﺳﻂ ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﯾﺎ ﻣﺸﺘﺮﯾﺎن اﻧﺠﺎم ﻣﯿﺸﻮد ﺗﺎ ﭘﺬﯾﺮش ﻣﺤﺼﻮل ﺻﻮرت ﺑﮕﯿـﺮد‬‫ﯾﺎ ﻧﻪ . ﺗﺴﺖ ﭘﺬﯾﺮش ﻣﻤﮑﻦ اﺳﺖ ﺑﻪ ﻋﻨﻮان ﺑﺨﺸﯽ از ﻓﺮاﯾﻨﺪ ، زﻣﺎﻧﯿﮑﻪ از ﯾﮏ ﻓﺎز ﺗﻮﺳﻌﻪ ﺑﻪ ﻓﺎز دﯾﮕﺮ ﻣﯿﺮوﯾﻢ‬ ‫ﻧﯿﺰ ﺻﻮرت ﮔﯿﺮد .‬
    • ‫٨١‬ ‫ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ‬ ‫3-‬‫اﻣﺮوزه ﺳﺎزﻣﺎنﻫﺎي ﻧﺮماﻓﺰاري زﻣﺎن و ﻣﻨﺎﺑﻊ زﯾﺎدي را در ﺗﺤﻠﯿﻞ و ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻـﺮف ﻣـﯽﮐﻨﻨـﺪ. از ﻧﻈـﺮ‬‫ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻧﻮﺷﺘﻦ ﮐﺪﻫﺎي ﺗﺴﺖ، ﺑﻪ ﺧﻮدي ﺧﻮد، ﻣﺜﻞ ﺗﻮﺳﻌﻪ ﺧﻮد ﻣﺤﺼﻮل وﻗﺖ ﮔﯿﺮ و ﮔﺮان اﺳﺖ.‬‫ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪ اﻣﺘﺤﺎن ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي ﺑﺮاي ﮐﺸﻒ ﺧﻄﺎﻫﺎ و ﺗﻀﻤﯿﻦ اﯾﻨﮑﻪ ﻧﯿﺎزﻣﻨﺪيﻫﺎي ﻣﻮﺟﻮد‬ ‫را ﺑﺮآورده ﻣﯽﮐﻨﺪ و ﺑﺎ ﺳﺨﺖاﻓﺰار ﻣﺸﺘﺮي ﺳﺎزﮔﺎر اﺳﺖ.‬‫ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﻧﺴﺒﺖ ﺑﻪ ﺗﺴﺖ دﺳـﺘﯽ ﺑﺮﺗـﺮيﻫـﺎي زﯾـﺎدي دارد. در ﺟﺎﻣﻌـﻪ اﻣـﺮوزي ﭘـﺮوژهﻫـﺎي‬‫ﻧﺮماﻓﺰاري ﭘﯿﭽﯿﺪه ﻫﺴﺘﻨﺪ و ﺑﺮاي ﺣﻞ ﻣﺴﺎﺋﻞ ﭘﯿﭽﯿﺪه ﻃﺮاﺣﯽ ﻣﯽﺷﻮﻧﺪ. ﺳﺎزﻧﺪﮔﺎن اﺑﺰارﻫﺎي ﺗﺴﺖ ﻧﺮماﻓـﺰار‬‫اﻏﻠﺐ ﻧﯿﺎز ﺑﻪ زﻣﺎن دارﻧﺪ ﺗﺎ درﺑﺎره ﯾﮏ ﻣﺴﺎﻟﻪ ﺧﺎص آﮔﺎﻫﯽ ﭘﯿﺪا ﮐﻨﻨﺪ و ﺑﺎ ﺗﮑﻨﻮﻟﻮژي ﻣﺮﺑـﻮط ﺑـﻪ آن ﻣـﺴﺎﻟﻪ‬‫آﺷﻨﺎ ﺷﻮﻧﺪ. ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺮاي رﺳﯿﺪن ﺑﻪ ﺿﺮب اﻻﺟﻞ ﺗﻌﯿﯿﻦ ﺷﺪه ﭘﺮوژه ، ﺗـﯿﻢ ﺗـﺴﺖ ﺑﺎﯾـﺪ ﯾـﮏ اﺑـﺰار ﺗـﺴﺖ‬‫ﺧﻮدﮐﺎر را اﯾﺠﺎد ﻧﻤﺎﯾﺪ ﮐﻪ ﺑﻪ ﻋﻨﻮان ﻣﮑﻤﻠﯽ ﺑﺮاي ﻓﺮآﯾﻨﺪ ﺗﺴﺖ ﻣﻮﺟﻮد ﻋﻤﻞ ﻧﻤﺎﯾﺪ . ﺑﺎ وﺟﻮد اﯾﻨﮑـﻪ ﻣﻤﮑـﻦ‬‫اﺳﺖ ﻫﺰﯾﻨﻪ اوﻟﯿﻪ اﺟﺮاي آن در ﺷﺮوع ﮐﺎر ﺳﻨﮕﯿﻦ ﺑﺎﺷﺪ اﻣﺎ در ﻃـﯽ ﻓﺮآﯾﻨـﺪ ﺗﻮﺳـﻌﻪ ، اﯾـﻦ ﻫﺰﯾﻨـﻪ ﺟﺒـﺮان‬‫ﺧﻮاﻫﺪ ﺷﺪ . ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﺑﺎﻋﺚ ﻣﯽ ﺷﻮد ﮐﻪ ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن زﻣﺎن ﺑﯿﺸﺘﺮي ﺑﺮاي ﺗﻤﺮﮐـﺰ ﺑـﺮروي‬‫دﯾﮕﺮ ﺟﻨﺒﻪﻫﺎ داﺷﺘﻪ ﺑﺎﺷﻨﺪ و ﺑﺘﻮاﻧﻨﺪ ﺧﻄﺎﻫﺎي ﻧﺮماﻓﺰار را ﺑﻪ ﺻﻮرت ﻣﺆﺛﺮﺗﺮي رﻓـﻊ ﻧﻤﺎﯾﻨـﺪ . ﻋـﻼوه ﺑـﺮاﯾﻦ،‬‫ازآﻧﺠﺎﯾﯽ ﮐﻪ ﺗﺴﺖﻫﺎ را ﻣﯽﺗﻮان در ﻫﺮ زﻣﺎن و ﺑﻪ ﻫﺮ ﺗﻌﺪاد دﻓﻌﺎﺗﯽ اﺟﺮا ﮐﺮد، ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن ﻗﺎدر ﺧﻮاﻫﻨﺪ‬‫ﺑﻮد ﺑﻪ ﺳﺎدﮔﯽ ﺧﻄﺎ را ﻣﺠﺪداً اﯾﺠﺎد ﮐﻨﻨﺪ ﺗﺎ ﻧﻘﺺ ﻣﻮﺟﻮد در ﮐﺪ ﻧـﺮماﻓـﺰار را ﺑﯿﺎﺑﻨـﺪ در ﺣﺎﻟﯿﮑـﻪ در ﺗـﺴﺖ‬‫دﺳﺘﯽ اﺟﺮاي ﻣﺠﺪد ﺧﻄﺎ ﺳﺨﺖ ﻣﯽ ﺑﺎﺷﺪ زﯾﺮا ﮔﺎﻫﯽ اوﻗﺎت ﻫﻨﮕﺎم اﻧﺠﺎم ﺗﺴﺖ دﺳﺘﯽ، ﻓﺮد ﺗﺴﺖﮔـﺮ ﺗﻤـﺎم‬ ‫ﻋﻤﻠﯿﺎﺗﯽ ﮐﻪ ﻃﯽ روال ﺗﺴﺖ ﮐﺮدن اﻧﺠﺎم داده اﺳﺖ را ﺑﺨﺎﻃﺮ ﻧﺪارد.‬
    • ‫٩١‬‫ﻫﻤﭽﻨﯿﻦ ﺑﺎﯾﺪ اﺷﺎره ﮐﺮد ﮐﻪ ﺑﺴﯿﺎري از ﺗﻼشﻫﺎ در زﻣﯿﻨﻪ ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﺑﻪ ﻧﺘﺎﯾﺞ ﻣﻮرد اﻧﺘﻈﺎر دﺳﺖ‬‫ﻧﯿﺎﻓﺘﻪاﻧﺪ. ﮔﺎﻫﯽ اوﻗﺎت در زﻣﯿﻨﻪ اﯾﺠﺎد و ﻧﮕﻬﺪاري ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﺳﺮﻣﺎﯾﻪﮔﺬاري ﻋﻈﯿﻤﯽ ﻣﯽﺷـﻮد اﻣـﺎ‬‫ﭘﺲ از ﺳﺎﺧﺖ ، ﺣﺘﯽ ﻫﺰﯾﻨﻪ ﺳﺮﻣﺎﯾﻪﮔﺬاري ﺷﺪه ﻗﺎﺑﻞ ﺟﺒﺮان ﻧﯿﺴﺖ . ﺑﺴﯿﺎر ﻣﻬﻢ اﺳﺖ ﮐﻪ ﯾﮏ ﺗﺤﻠﯿﻞ ﮐﺎﻣﻞ‬‫در ﻣﻮرد ﻫﺰﯾﻨﻪ و ﻣﻨﺎﻓﻊ ﺣﺎﺻﻞ از ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ دﺳـﺘﯽ ﻣـﻮرد ﻧﻈـﺮ ، اﻧﺠـﺎم ﺷـﻮد. اﻏﻠـﺐ، ﻣﻮﻓﻘﯿـﺖ‬‫ﻫﻨﮕﺎﻣﯽ ﺣﺎﺻﻞ ﻣﯽ ﺷﻮد ﮐﻪ ﺑﺮ روي ﭘﯿﺪا ﮐﺮدن ﻗﺴﻤﺘﻬﺎﯾﯽ از ﻧﺮماﻓﺰار ﮐﻪ ﺧﻮدﮐﺎرﺳﺎزي آﻧﻬـﺎ ﺳـﻮدﻣﻨﺪ ﺑـﻪ‬‫ﻧﻈﺮ ﻣﯽ رﺳﺪ ﻣﺘﻤﺮﮐﺰ ﺷﻮﯾﻢ و ﻧﻪ ﺑﺮ روي ﺧﻮدﮐﺎرﺳﺎزي ﮐﻞ ﻧﺮماﻓﺰار. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﻣﯽ ﺗﻮاﻧﺪ ﻫﺰﯾﻨﻪ و‬‫ﭘﯿﭽﯿﺪﮔﯽ زﯾﺎدي را ﺑﺮاي ﺗﯿﻢ ﺗﺴﺖﮔﺮ ﺑﻪ ﻫﻤﺮاه داﺷﺘﻪ ﺑﺎﺷﺪ و ﯾﺎ در ﺻـﻮرﺗﯿﮑﻪ ﺗﻮﺳـﻂ اﻓـﺮاد ﻣﻨﺎﺳـﺐ و در‬ ‫ﻣﻮاردي ﮐﻪ اﻧﺠﺎم آن ﻣﻮرد ﺗﺎﯾﯿﺪ اﺳﺖ اﻧﺠﺎم ﺷﻮد، ﻣﯽﺗﻮاﻧﺪ ﮐﻤﮏ ﻗﺎﺑﻞ ﺗﻮﺟﻬﯽ را ﺑﻪ اﯾﻦ ﺗﯿﻢ اراﺋﻪ دﻫﺪ.‬ ‫ﺑﻬﺘﺮاﺳﺖ زﻣﺎﻧﯽ ﺑﻪ ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﺑﭙﺮدازﯾﻢ ﮐﻪ ﺣﺪاﻗﻞ ﯾﮑﯽ از ﺷﺮاﯾﻂ زﯾﺮ در ﻣﻮرد ﭘﺮوژه ﻣﻬﯿﺎ ﺑﺎﺷﺪ :‬ ‫‪ Test case ‬ﻫﺎ و ﻣﺤﯿﻂ ﻫﺎي ﺗﺴﺖ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻣﺠﺪد ﺑﺎﺷﻨﺪ.‬ ‫‪ ‬ﻧﯿﺎز ﮐﻤﯽ ﺑﻪ داﻧﺶ ﻣﺤﯿﻄﯽ در ﺗﺴﺖﻫﺎ داﺷﺘﻪ ﺑﺎﺷﯿﻢ .‬ ‫‪ ‬ﺳﯿﺴﺘﻢﻫﺎ اﺳﺘﺎﻧﺪارد و ﻣﺴﺘﻘﻞ ﺑﺎﺷﻨﺪ.‬ ‫‪ ‬رﻣﺰﮔﺬاري و ﺗﺪوﯾﻦ ﻗﻮاﻧﯿﻦ91 اﺻﻠﯽﺗﺮﯾﻦ اﺳﺘﺎﻧﺪارد در ﻣﺪﯾﺮﯾﺖ داﻧﺶ ﺑﺎﺷﺪ.‬‫ﺑﺎﯾﺪ ﺗﻮﺟﻪ داﺷﺖ ﮐﻪ ﺗﺴﺖ ﺧﻮدﮐﺎر ﺑﻪ اﯾﻦ ﻣﻌﻨﺎ ﻧﯿﺴﺖ ﮐﻪ ﮐﻞ ﻓﺮآﯾﻨﺪ ﺗﺴﺖ ﻧﺮماﻓـﺰار ﺑـﻪ ﺻـﻮرت ﺧﻮدﮐـﺎر‬‫اﻧﺠﺎم ﻣﯽﺷﻮد. ﺑﻠﮑﻪ ﺑﻪ ﻣﻌﻨﺎي ﺗﺴﺖ ﻧﺮماﻓﺰار ﺑﺎ ﮐﻤﮏ ﮐﺎﻣﭙﯿﻮﺗﺮ اﺳﺖ. ﺑﻪ ﻃـﻮر ﺧﻼﺻـﻪ ﺗـﺴﺖ ﺧﻮدﮐـﺎر ﺑـﻪ‬‫ﻣﻌﻨﺎي ﺧﻮدﮐﺎرﺳﺎزي ﻓﺮآﯾﻨﺪ ﺗﺴﺖ دﺳﺘﯽ اﺳﺖ ﮐﻪ در ﺣﺎل ﺣﺎﺿﺮ اﺳﺘﻔﺎده ﻣﯽﺷﻮد. اﯾﻦ ﻋﻤﻞ ﻧﯿﺎز ﺑـﻪ ﯾـﮏ‬‫ﻓﺮآﯾﻨﺪ ﺗﺴﺖ دﺳﺘﯽ ﺳﺎﺧﺖ ﯾﺎﻓﺘﻪ دارد ﮐﻪ در ﺣﺎل ﺣﺎﺿﺮ در ﺳﺎزﻣﺎن ﯾﺎ ﺷﺮﮐﺖ ﻣﻮﺟﻮد ﻣﯽ ﺑﺎﺷﺪ. اﺳﺘﻔﺎده از‬‫ﺗﺴﺖ ﺧﻮدﮐﺎر ﭘﺮﻫﺰﯾﻨﻪ اﺳﺖ. ﺑﻪ ﮐﺎرﺑﺮدن ﺗﺴﺖ ﺧﻮدﮐﺎر ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﻧﯿﺴﺖ ﮐﻪ دﯾﮕﺮ ﻧﯿﺎزي ﺑﻪ ﺗﺴﺖ دﺳﺘﯽ‬‫ﻧﺪارﯾﻢ و ﯾﺎ ﻣﯽ ﺗﻮان ﺗﻌﺪاد اﻓﺮاد ﺗﯿﻢ ﺗﺴﺖ را ﮐﺎﻫﺶ داد ﺑﻠﮑﻪ ﺗﺴﺖ ﺧﻮدﮐﺎر ﻣﮑﻤﻠـﯽ ﺑـﺮاي ﻓﺮآﯾﻨـﺪ ﺗـﺴﺖ‬‫91 ‪codification‬‬
    • ‫٠٢‬‫ﻣﻮﺟﻮد ﻣﯽ ﺑﺎﺷﺪ . ﺗﻮﺳﻌﻪ ، ﺑﺎزﺑﯿﻨﯽ و ﻣﺴﺘﻨﺪ ﺳﺎزي ﯾﮏ ﻧﻤﻮﻧﻪ ﺗﺴﺖ02 ﺧﻮدﮐﺎر ﻣﯽ ﺗﻮاﻧﺪ ﺑﯿﻦ 3 ﺗﺎ 01 ﺑﺮاﺑﺮ‬‫ﺑﯿﺸﺘﺮ از اﯾﺠﺎد و اﺟﺮاي ﯾﮏ ﻧﻤﻮﻧﻪ ﺗﺴﺖ دﺳﺘﯽ زﻣﺎن ﺑﺮ ﺑﺎﺷﺪ ، ﺑﺨﺼﻮص اﮔـﺮ از روش ‪record/playback‬‬ ‫-ﮐﻪ در اﮐﺜﺮ اﺑﺰارﻫﺎي ﺗﺴﺖ وﺟﻮد دارد- ﺑﻪ ﻋﻨﻮان ﻣﺘﺪ اﺻﻠﯽ ﺗﺴﺖ ﺧﻮدﮐﺎر اﺳﺘﻔﺎده ﺷﻮد .‬‫02 ‪Test case‬‬
    • ‫١٢‬ ‫اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار‬ ‫4-‬‫ﺑﺮاي ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﻧﺮماﻓﺰار اﺑﺰارﻫﺎي ﮔﻮﻧﺎﮔﻮﻧﯽ ﻣﻮﺟﻮد اﺳﺖ. ﺑﺮﺧﯽ از اﯾـﻦ اﺑﺰارﻫـﺎ ﺗﺠـﺎري و ﺑﺮﺧـﯽ‬‫دﯾﮕﺮ ﻣﺘﻦ ﺑﺎز ﻫﺴﺘﻨﺪ. ﻫﺮ ﯾﮏ از اﯾﻦ اﺑﺰارﻫﺎ ﺑﺮاي ﯾﮏ ﯾﺎ ﭼﻨﺪ ﻧﻮع از ﺗﺴﺖ ﺑﻪ ﮐﺎر ﻣﯽرود. در اﯾﻦ ﻓـﺼﻞ ﺑـﻪ‬ ‫ﺗﻮﺿﯿﺢ اﺑﺰارﻫﺎي ﻣﻬﻢ ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار ﻣﯽﭘﺮدازﯾﻢ و وﯾﮋﮔﯽﻫﺎي ﻫﺮ ﯾﮏ را ﺑﯿﺎن ﻣﯽﮐﻨﯿﻢ.‬ ‫‪xUnit‬‬‫‪ Kent Beck‬در ﺳﺎل 7991، ‪ SUnit‬ﮐﻪ ﯾﮏ ﭼﺎرﭼﻮب ﺳﺎده ﺑﺮاي ﺗﺴﺖ واﺣﺪ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷـﺪه ﺑـﻪ‬‫زﺑﺎن ‪ Smalltalk‬ﻣﯽﺑﺎﺷﺪ را اراﺋﻪ ﻧﻤﻮد. ﭘﺲ از ﻣﺪﺗﯽ اﯾﻦ ﻣﺪل ﺗﻮﺳﻂ ‪ Kent Beck‬و ‪ ،Erich Gamma‬ﺑﺮاي‬‫زﺑﺎن ﺟﺎوا ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﮔﺮﻓﺖ و ‪ JUnit‬اﯾﺠﺎد ﺷﺪ ﮐـﻪ اﻣـﺮوزه ﺑﻌﻨـﻮان ﻣﻬـﻢﺗـﺮﯾﻦ اﺑـﺰار ﺗـﺴﺖ واﺣـﺪ‬‫ﺑﺮﻧﺎﻣﻪﻫﺎي ﺟﺎوا ﻣﻘﺒﻮﻟﯿﺖ ﺑﺴﯿﺎر زﯾﺎدي ﯾﺎﻓﺘﻪ اﺳﺖ. ﺳﺎﺧﺘﺎر ﻣﻮرد اﺳﺘﻔﺎده در اﯾﻦ دو اﺑﺰار، در ﻋﯿﻦ ﺳـﺎدﮔﯽ،‬‫از ﻗﺎﺑﻠﯿﺖ و ﮐﺎرآﯾﯽ ﺑﺎﻻﯾﯽ ﺑﺮﺧﻮردار ﺑﻮد. ﺑﻬﻤﯿﻦ ﻋﻠﺖ در ﻃﻮل زﻣﺎن، اﺑﺰارﻫﺎي ﻣـﺸﺎﺑﻬﯽ ﮐـﻪ از اﯾـﺪه ‪JUnit‬‬‫ﺑﺮاي زﺑﺎنﻫﺎي دﯾﮕﺮ اﺳﺘﻔﺎه ﻣﯽﻧﻤﺎﯾﻨﺪ ﻣﻌﺮﻓﯽ ﺷﺪﻧﺪ. اﻣﺮوزه اﺑﺰارﻫﺎي ﻣﺸﺎﺑﻬﯽ ﮐﻪ ﻫﻤـﻪ از ﺳـﺎﺧﺘﺎر و ﻣـﺪل‬‫ﻣﺸﺎﺑﻬﯽ ﺑﺮﺧﻮردارﻧﺪ ﺑﺮاي ﺗﺴﺖ واﺣﺪ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه ﺑﻪ زﺑﺎﻧﻬﺎي ﻣﺨﺘﻠﻒ، وﺟـﻮد دارﻧـﺪ ﮐـﻪ ﺑﻌﻠـﺖ‬‫ﺷﺒﺎﻫﺖ زﯾﺎد، ﻫﻤﻪ ﺗﺤﺖ ﻋﻨﻮان ﺧﺎﻧﻮاده ‪ xUnit‬ﻣﻮرد ارﺟﺎع ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ. ﺑﻌﻨﻮان ﭼﻨﺪ ﻋﻀﻮ از اﯾﻦ ﺧﺎﻧﻮاده،‬‫ﮐﻪ ﻫﻤﻪ ﻧﯿﺰ اﺑﺰارﻫﺎي ﻣﺘﻦ ﺑﺎز ﻣﯽﺑﺎﺷﻨﺪ، ﻣﯽﺗﻮان از ‪ CppUnit‬ﺑﺮاي زﺑـﺎن ‪ NUnit ،CPP‬ﺑـﺮاي زﺑـﺎنﻫـﺎي‬‫ﭘﻠﺘﻔﺮم .‪ PyUnit ،Net‬ﺑﺮاي ‪ VBUnit ،Python‬ﺑﺮاي وﯾﮋوال ﺑﯿﺴﯿﮏ، ‪ XMLUnit‬ﺑﺮاي اﺳـﻨﺎد ‪ XML‬ﻧـﺎم‬ ‫ﺑﺮد. .‪Error! Reference source not found‬‬‫ﯾﮑﯽ از ﻣﻮﻓﻖ ﺗﺮﯾﻦ اﻋﻀﺎي ﺧﺎﻧﻮاده ‪ ،xUnit‬اﺑﺰار ‪ JUint‬اﺳﺖ ﮐﻪ در ﻗﺴﻤﺖ ﺑﻪ اﺧﺘﺼﺎر ﻣـﻮرد ﻣﻌﺮﻓـﯽ ﻗـﺮار‬ ‫ﻣﯽﮔﯿﺮد.‬ ‫‪JUnit‬‬
    • ‫٢٢‬‫‪ ،21JUnit‬ﯾﮏ ﭼﺎرﭼﻮب ﻣﺘﻦ-ﺑﺎز ﺑﺮاي ﺗﺴﺖ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه ﺑﻪ زﺑﺎن ﺟﺎوا ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﺧﻮدش ﻧﯿـﺰ‬‫ﺑﻪ زﺑﺎن ﺟﺎوا و ﺗﻮﺳﻂ ‪ Erich Gamma‬و ‪ Kent Beck‬در ﺳﺎل 7991 ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ. در واﻗﻊ ‪ ،JUnit‬ﺑﺮ‬‫اﺳﺎس ﻃﺮﺣﯽ از ‪ Kent Beck‬ﺑﺎ ﻧﺎم ‪ ،SUnit‬ﮐﻪ ﯾﮏ ﭼﺎرﭼﻮب ﺗﺴﺖ ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه ﺑﻪ زﺑـﺎن‬‫‪ Smalltalk‬ﻣﯽﺑﺎﺷﺪ، ﺗﻮﺳﻌﻪ داده ﺷﺪه اﺳﺖ. ﻗﺎﺑﻠﯿﺖ و ﮐﺎراﯾﯽ ﺑﺎﻻ در ﻋﯿﻦ ﺳﺎدﮔﯽ، ﻣﻮﺟﺐ ﺷـﺪه اﺳـﺖ ﺗـﺎ‬‫‪ ،JUnit‬ﺑﻌﻨﻮان ﯾﮏ اﻟﮕﻮ ﻗﺮار ﮔﯿﺮد و ﭼﺎرﭼﻮبﻫﺎي ﻣﺸﺎﺑﻪ آن ﺑﺮاي زﺑﺎنﻫـﺎي ﺑﺮﻧﺎﻣـﻪ ﻧﻮﯾـﺴﯽ دﯾﮕـﺮ، ﻧﻈﯿـﺮ‬‫‪ Python ،Perl ،PHP ،Delphi ،Eiffel ،C# ،ASP‬و ‪ ،Visual Basic‬اﯾﺠ ـﺎد ﺷ ـﻮد. اﯾـﻦ ﭼ ـﺎرﭼﻮبﻫ ـﺎ در‬ ‫ـ‬ ‫ـ ـ‬ ‫ـ ـ‬‫ﻣﺠﻤﻮع ﺧﺎﻧﻮاده ‪ xUnit‬را ﺗﺸﮑﯿﻞ ﻣﯽدﻫﻨﺪ ﮐﻪ ﻫﻤﻪ از ﻧﻈﺮ ﺳﺎﺧﺘﺎر و ﻣﺪل ﮐﺎري ﻣﺸﺎﺑﻪ ﯾﮑﺪﯾﮕﺮ ﻣﯽﺑﺎﺷـﻨﺪ.‬‫‪ JUnit‬اﻣﺮوزه ﺑﻌﻨﻮان ﯾﮏ اﺳﺘﺎﻧﺪارد ﻏﯿﺮ رﺳﻤﯽ ﺑﺮاي اﻧﺠﺎم ﺗﺴﺖ واﺣﺪ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﺟـﺎوا ﻣﻄـﺮح اﺳـﺖ و از‬ ‫ﻣﻘﺒﻮﻟﯿﺖ ﺑﺴﯿﺎر ﺑﺎﻻﯾﯽ ﺑﺮﺧﻮردار اﺳﺖ.‬ ‫ﻓﺎﯾﻞﻫﺎي اﺟﺮاﯾﯽ و ﻫﻤﭽﻨﯿﻦ ﮐﺪﻫﺎي ‪ ،JUnit‬از ﻃﺮﯾﻖ ﺳﺎﯾﺖ رﺳﻤﯽ آن ﻗﺎﺑﻞ دﺳﺘﺮس ﻣﯽﺑﺎﺷﺪ.‬‫ﻋﻨﺼﺮ ﻣﺮﮐﺰي ‪ ،JUnit‬ﮐﻼس ‪ TestCase‬ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﺑﺎ اﺳﺘﻔﺎده از آن ﻣﯽﺗﻮاﻧﯿﻢ ﺗﺴﺖﻫـﺎي ﺧـﻮد را اﯾﺠـﺎد‬‫ﮐﻨﯿﻢ. اﯾﻦ ﮐﻼس ﺷﺎﻣﻞ ﻣﺘﺪﻫﺎﯾﯽ ﺑﺮاي اﯾﺠﺎد و اﺟﺮاي ﺗﺴﺖﻫﺎ ﻣﯽﺑﺎﺷﺪ. ﺑﻌﻨﻮان ﻣﺜﺎل ﻓﺮض ﮐﻨـﯿﻢ ﮐﻼﺳـﯽ‬‫دارﯾﻢ ﺑﺎ ﻧﺎم ‪ Circle‬ﮐﻪ داراي ﺗﻌﺪادي ﻓﯿﻠﺪ و ﻣﺘﺪ ﻣﯽﺑﺎﺷﺪ. اﮔﺮ ﺑﺨـﻮاﻫﯿﻢ ﺑـﺎ اﺳـﺘﻔﺎده از ‪ ،JUnit‬ﺑـﻪ اﻧﺠـﺎم‬‫ﺗﺴﺖ واﺣﺪ اﯾﻦ ﮐﻼس ﺑﭙﺮدازﯾﻢ، ﺑﺎﯾﺪ ﯾﮏ ﮐﻼس ﺗﺴﺖ ﭘﯿﺎدهﺳﺎزي ﻧﻤﺎﯾﯿﻢ ﮐـﻪ ﺗـﺴﺖﻫـﺎي ﻻزم را ﺑـﺮ روي‬‫ﮐﻼس ‪ Circle‬اﻧﺠﺎم ﻣﯽدﻫﺪ. در ﻧﺴﺨﻪﻫﺎي ﻗﺒﻞ از 0.4 ‪ ،JUnit‬ﺗﻨﻬﺎ ﯾﮏ راه ﺑﺮاي اﯾﻦ ﮐﺎر وﺟﻮد دارد. ﺑﺮاي‬‫اﯾﻦ ﮐﺎر ﺑﺎﯾﺪ ﯾﮏ ﮐﻼس ﺑﻨﻮﯾﺴﯿﻢ ﮐﻪ از ﮐﻼس ‪ TestCase‬ﻣﺸﺘﻖ ﺷـﻮد. ﺳـﭙﺲ در اﯾـﻦ ﮐـﻼس ﻣﺘـﺪﻫﺎﯾﯽ‬‫ﭘﯿﺎدهﺳﺎزي ﻣﯽﮐﻨﯿﻢ ﮐﻪ ﻫﺮ ﯾﮏ ﺑﻪ ﺗﺴﺖ ﯾﮑﯽ از وﯾﮋﮔﯽﻫﺎ ﯾﺎ رﻓﺘﺎرﻫﺎي ﮐﻼس ‪ Circle‬ﻣﯽﭘﺮدازﻧﺪ. در ﻧﻬﺎﯾﺖ‬‫ﺑﺮاي اﺟﺮاي ﺗﺴﺖ، ﺑﺎﯾﺪ اﯾﻦ ﮐﻼس را ﮐﺎﻣﭙﺎﯾﻞ ﻧﻤﻮده و آن را ﺑـﺮاي اﺟـﺮا ﺑـﻪ ‪ JUnit‬ﺑـﺪﻫﯿﻢ. ‪ ،JUnit‬ﺑﻄـﻮر‬‫ﺧﻮدﮐﺎر ﯾﮏ ﺷﯽء از اﯾﻦ ﮐﻼس اﯾﺠﺎد ﻣﯽﮐﻨﺪ و ﻫﺮ ﯾﮏ از ﻣﺘﺪﻫﺎي اﯾﻦ ﮐﻼس ﮐـﻪ ﻧـﺎﻣﺶ ﺑـﺎ ﻋﺒـﺎرت ‪test‬‬‫ﺷﺮوع ﻣﯽﺷﻮد را ﺑﻄﻮر ﺧﻮدﮐﺎر اﺟﺮا ﻣﯽﻧﻤﺎﯾﺪ. ﺑﻨﺎﺑﺮاﯾﻦ اﻓﺰودن ﺗـﺴﺖﻫـﺎي ﺟﺪﯾـﺪ، ﻓﻘـﻂ ﻧﯿﺎزﻣﻨـﺪ اﻓـﺰودن‬ ‫ﻣﺘﺪﻫﺎي ﺟﺪﯾﺪي ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﻧﺎﻣﺸﺎن ﺑﺎ ﻋﺒﺎرت ‪ test‬ﺷﺮوع ﻣﯽﺷﻮد.‬‫12‬ ‫‪http://www.junit.org‬‬
    • ‫٣٢‬‫در 0.4 ‪ ،JUnit‬روش دﯾﮕﺮي ﻧﯿﺰ ﻓﺮاﻫﻢ ﮔﺮدﯾﺪ ﮐﻪ ﺑﺮاﺳﺎس آن دﯾﮕﺮ ﻧﯿﺎزي ﻧﯿﺴﺖ ﮐـﻼس ﺗـﺴﺖ از ﮐـﻼس‬‫‪ TestCase‬ﻣﺸﺘﻖ ﺷﻮد. ﻫﻤﭽﻨﯿﻦ ﻧﯿﺎزي ﻧﯿﺴﺖ ﻧﺎم ﻣﺘﺪﻫﺎي ﺗﺴﺖ ﺑﺎ ﻋﺒﺎرت ‪ test‬ﺷﺮوع ﺷﻮد. در اﯾـﻦ روش‬‫ﮐﻪ ﻣﺒﺘﻨﯽ ﺑﺮ اﺳﺘﻔﺎده از ‪ annotation‬ﻫﺎي ﺟﺎوا )ﮐﻪ در 0.5 ‪ J2SE‬ﻣﻌﺮﻓﯽ ﮔﺮدﯾﺪ( ﻣﯽﺗﻮان ﻣﺘﺪﻫﺎي ﺗﺴﺖ را‬‫ﺑﺎ اﺳﺘﻔﺎده از ﺗﮓﻫﺎي ﺧﺎﺻﯽ ﻋﻼﻣﺖﮔﺬاري ﮐﺮد و آﻧﻬﺎ را ﺑﻪ ‪ JUnit‬ﺷﻨﺎﺳﺎﻧﺪ. در اداﻣﻪ ﺑﺤﺚ، ﻓﻘﻂ روش اول‬‫را ﻣﺪ ﻧﻈﺮ ﻗﺮار ﻣﯽدﻫﯿﻢ، زﯾﺮا در اﮐﺜﺮ ﻣﺘـﻮن و راﻫﻨﻤﺎﻫـﺎي ﻣﻮﺟـﻮد در وب، ﻫﻤﭽﻨـﯿﻦ در ﻧﻤﻮﻧـﻪ ﮐـﺪﻫﺎي‬ ‫ﻣﻮﺟﻮد، ﻋﻤﺪﺗﺎً از اﯾﻦ روش اﺳﺘﻔﺎده ﺷﺪه اﺳﺖ.‬‫ﺑﺮاي اﺟﺮاي ﺗﺴﺖ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه، از ﮐﻼﺳﻬﺎﯾﯽ ﮐﻪ ﺑﺪﯾﻦ ﻣﻨﻈـﻮر در ‪ JUnit‬ﻃﺮاﺣـﯽ ﺷـﺪه اﻧـﺪ اﺳـﺘﻔﺎده‬ ‫ﻣﯽﻧﻤﺎﯾﯿﻢ. ‪ ،JUnit‬دو ﮐﻼس ﺑﺮاي اﺟﺮاي ﺗﺴﺖ ﻫﺎ اراﺋﻪ ﻣﯽﮐﻨﺪ، ﮐﻪ ﺑﻪ آﻧﻬﺎ ‪ test runner‬ﻣﯽﮔﻮﯾﯿﻢ:‬ ‫اﺟﺮا ﮐﻨﻨﺪه ﺗﺴﺖ ﻣﺒﺘﻨﯽ ﺑﺮ ﻣﺘﻦ ﮐﻪ ﮐﻼس ‪ junit.textui.TestRunner‬ﻣﯽﺑﺎﺷﺪ.‬ ‫اﺟﺮاﮐﻨﻨﺪه ﺗﺴﺖ ﻣﺒﺘﻨﯽ ﺑﺮ ‪ Swing‬ﮐﻪ ﮐﻼس ‪ junit.swingui.TestRunner‬ﻣﯽﺑﺎﺷﺪ.‬‫ﻫﻤﺎﻧﻄﻮر ﮐﻪ ﭘﯿﺸﺘﺮ ﮔﻔﺘﻪ ﺷﺪ، ﮐﻼس ﺗﺴﺖ ﺑﺎﯾﺪ از ﮐﻼس ‪ TestCase‬ﻣﺸﺘﻖ ﺷﻮد، در ﻧﺘﯿﺠﻪ ﻣﺘـﺪﻫﺎﯾﯽ ﮐـﻪ‬‫در ﮐﻼس ‪ TestCase‬ﺗﻌﺮﯾﻒ ﺷﺪهاﻧﺪ ﺑﻪ ﮐﻼس ﺗﺴﺖ ﺑﻪ ارث ﻣﯽرﺳـﻨﺪ، ﻣﻬـﻢﺗـﺮﯾﻦ اﯾـﻦ ﻣﺘـﺪﻫﺎ، ﻣﺘـﺪﻫﺎي‬‫‪ assert‬ﻣﯽﺑﺎﺷﻨﺪ ﮐﻪ ﺑﺮاي ﺑﺮرﺳﯽ ﻧﺘﺎﯾﺞ ﺑﻪ ﮐﺎر ﻣﯽروﻧﺪ. ﻣﺜﻼ◌ ﻣﺘﺪ ‪ assertTrue‬ﺑﺮرﺳﯽ ﻣـﯽﮐﻨـﺪ ﮐـﻪ آﯾـﺎ‬ ‫ً‬‫ﻣﻘﺪار آرﮔﻮﻣﺎن آن ﺑﺮاﺑﺮ ‪ true‬اﺳﺖ ﯾﺎ ‪ .false‬اﮔﺮ ﻣﻘﺪار آن ﺑﺮاﺑﺮ ‪ true‬اﺳﺖ اﯾﻦ ﺑﻪ ﻣﻌﻨﺎي ﻣﻮﻓﻘﯿﺖ ﻣﺘﺪ ﺗﺴﺖ‬‫ﻣﯽﺑﺎﺷﺪ، در ﻏﯿﺮ اﯾﻨﺼﻮرت، ‪ ،JUnit‬اﯾﻦ ﻣﺴﺎﻟﻪ را ﺑﻌﻨﻮان ﺷﮑﺴﺖ ﻣﺘﺪ ﺗﺴﺖ ﮔﺰارش ﻣﯽﻧﻤﺎﯾـﺪ. ﺑﻨـﺎﺑﺮاﯾﻦ در‬‫ﻋﻤ ـﻞ، در ﭘﯿ ـﺎده ﺳ ـﺎزي ﻣﺘ ـﺪﻫﺎي ﺗ ـﺴﺖ، از ﻣﺘ ـﺪﻫﺎﯾﯽ ﻧﻈﯿ ـﺮ ‪،assertEquals ،assertFalse ،assertTrue‬‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫‪ assertNull ،assertNotNull‬و ﻣﺘﺪﻫﺎي دﯾﮕﺮ ﮐﻪ ﺑﺪﯾﻦ ﻣﻨﻈﻮر ﺗﻌﺮﯾﻒ ﺷﺪه اﻧﺪ اﺳﺘﻔﺎده ﻣﯽﻧﻤﺎﯾﯿﻢ.‬‫در ﻣﺠﻤﻮع، ‪ ،JUnit‬ﺑﺮاي اﻧﺠﺎم ﺗﺴﺖ واﺣﺪ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﺟﺎوا، اﺑﺰار ﺑﺴﯿﺎر ﻣﻨﺎﺳﺐ، ﻗﺪرﺗﻤﻨﺪ و در ﻋـﯿﻦ ﺣـﺎل‬‫ﺳﺎده ﻣﯽﺑﺎﺷﺪ. ﺑﺨﺼﻮص ﻧﺴﺨﻪ 0.4 آن ﺑﺴﯿﺎر ﺳﺎده ﺗﺮ و ﻏﻨﯽ ﺗﺮ از ﭘﯿﺶ ﻣﯽﺑﺎﺷﺪ و اﻣﮑﺎﻧﺎت ﺟﺪﯾﺪي اراﺋـﻪ‬‫ﻣﯽﮐﻨﺪ. ﺑﻌﻨﻮان ﻣﺜﺎل ﻣﯽﺗﻮان ﺑﺎ اﺳﺘﻔﺎده از ‪ annotation‬ﻫﺎي ﺟﺎوا، ﺗﻌﯿﯿﻦ ﮐﻨﯿﻢ ﮐﻪ ﻣﺘﺪﻫﺎي ﺗﺴﺖ ﺑـﻪ ﭼـﻪ‬ ‫ﺗﺮﺗﯿﺒﯽ اﺟﺮا ﺷﻮﻧﺪ، ﯾﺎ ﻫﺮ ﻣﺘﺪ ﭼﻨﺪ ﺑﺎر اﺟﺮا ﺷﻮد، ﯾﺎ اﯾﻨﮑﻪ ﻣﺜﻼً ﯾﮏ ﻣﺘﺪ ﺗﺤﺖ ﭼﻪ ﺷﺮاﯾﻄﯽ اﺟﺮا ﺷﻮد.‬
    • ‫٤٢‬‫ﻻزم ﺑﻪ ذﮐﺮ اﺳﺖ ﮐﻪ ‪ ،JUnit‬ﺑﺎ ﺗﻌﺪادي از ﻣﺤﯿﻂﻫﺎي ﺗﻮﺳﻌﻪ ﺑﺮﻧﺎﻣﻪﻫﺎي ﺟﺎوا ﻧﻈﯿـﺮ ‪ JBuilder ،Eclipse‬و‬‫‪ ،Intellij IDEA‬ﻧﯿﺰ ﯾﮑﭙﺎرﭼﻪ ﺷﺪه اﺳﺖ و اﻣﮑﺎن ﺗﺒﺎدل ﺑﺎ ‪ JUnit‬از درون اﯾـﻦ ﻧـﺮماﻓﺰارﻫـﺎ ﺑﺨـﻮﺑﯽ ﻓـﺮاﻫﻢ‬‫اﺳﺖ. ﻫﻤﭽﻨﯿﻦ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻘﺒﻮﻟﯿﺖ روزاﻓﺰون ﻣﺘﺪﻫﺎي ﺗﻮﺳﻌﻪ ﭼﺎﺑﮏ ﻧﺮماﻓﺰار )‪ ،(agile methods‬ﮐﻪ ﺗﻮﺟﻪ‬‫و ﺗﻤﺮﮐﺰ ﺑﯿﺸﺘﺮي ﺑﺮ ﻣﺴﺄﻟﻪ ﺗﺴﺖ دارﻧﺪ، اﻫﻤﯿﺖ و رواج ‪ ،JUnit‬رو ﺑﻪ اﻓﺰاﯾﺶ اﺳـﺖ. ‪Error! Reference‬‬ ‫.‪source not found‬‬ ‫‪HTTPUnit‬‬‫ﭘﺮوژه 22‪ httpunit‬در ﺳﺎل 0002 ﺗﻮﺳﻂ ‪ Ruse Gold‬ﺷﺮوع ﺷﺪ و اوﻟﯿﻦ ﭘـﺮوژه ﻣﺘﻤﺮﮐـﺰ در ﺣـﻮزه ﺗـﺴﺖ‬‫ﻧﺮماﻓﺰار اﺳﺖ. و ﯾﮏ ﭼﺎرﭼﻮب ﻣﻨﺒﻊ ﺑﺎز ﺗﺴﺖ ﻧﺮماﻓﺰار، ﺑﺮاي ﺗﺴﺖ وب ﺳﺎﯾﺖﻫﺎ ﺑـﺪون اﺳـﺘﻔﺎده از ﻣﺮورﮔـﺮ‬‫اﺳﺖ. در ‪ httpunit‬ﻣﯽﺗﻮان از ارﺳﺎل ﻓﺮمﻫﺎي ‪ http‬و اﺣﺮاز ﻫﻮﯾﺖ دﺳﺘﺮﺳﯽ ﺳﺎده ‪ http‬و ﺟﺎوا اﺳﮑﺮﯾﭙﺖ و‬‫ﮐﻮﮐﯽ و ...اﺳﺘﻔﺎده ﮐﺮد. ‪ httpunit‬ﺑﻪ زﺑﺎن ﺟﺎوا ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ و ﺑﻪ ﮐﺪﻫﺎي ﺗـﺴﺖ ﺟـﺎوا اﺟـﺎزه ﭘـﺮدازش‬‫ﺻﻔﺤﺎت ﺑﺎزﮔﺸﺘﯽ ﺑﺼﻮرت ﻣﺘﻦ ﯾﺎ ﮐﺎﻧﺘﯿﻨﺮﻫﺎﯾﯽ از ﻓﺮم ﻫﺎ و ﺟﺪاول ﻟﯿﻨﮏﻫﺎ وﯾﺎ ‪ XMLDOM‬را ﻣﯽدﻫـﺪ .‬‫‪ httpunit‬ﺑﺮاي اﺳﺘﻔﺎده ﺑﺎ ‪ junit‬ﺑﺴﯿﺎر ﻣﻨﺎﺳﺐ اﺳﺖ و ﻣﯽﺗﻮان ﺑﻪ ﺳﺎدﮔﯽ ﺗـﺴﺖ ﻫـﺎﯾﯽ ﻧﻮﺷـﺖ ﮐـﻪ رﻓﺘـﺎر‬‫ﻣﻨﺎﺳﺐ ﯾﮏ وب ﺳﺎﯾﺖ را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﻨﺪ. ‪ httpunit‬ﺑﻪ اﺗﻮﻣﺎﺗﯿﮏ ﮐﺮدن ﺗﺴﺖ ﺑﺮﻧﺎﻣﻪﻫﺎي وب ﺑﺴﯿﺎر ﮐﻤـﮏ‬ ‫ﻣﯽﮐﻨﺪ و ﺑﻪ ﻫﻤﯿﻦ دﻟﯿﻞ در ﺗﺴﺖ رﮔﺮاﺳﯿﻮن ﮐﻤﮏ ﺑﺴﯿﺎري ﻣﯽﻧﻤﺎﯾﺪ.‬‫‪ API‬ﻫﺎي ﻣﻮﺟﻮد در اﯾﻦ ﻧﺮماﻓﺰار ﺗﻌﺎﻣﻼت وب را در ﺳﻄﺢ ﭘﺎﺳﺦﻫﺎ و درﯾﺎﻓﺖﻫﺎي ‪ http‬ﻣﺪل ﻣﯽﮐﻨﺪ. ﻧﻤﻮﻧﻪ‬ ‫زﯾﺮ را ﺑﺒﯿﻨﯿﺪ:‬‫;)(‪WebConversation wc = new WebConversation‬‬‫;)"/‪WebResponse resp = wc.getResponse("http://www.google.com‬‬‫;)"‪WebLink link = resp.getLinkWith("About Google‬‬‫;)(‪link.click‬‬‫;)(‪WebResponse resp2 = wc.getCurrentPage‬‬‫22‬ ‫‪http://httpunit.sourceforge.net/index.html‬‬
    • ‫٥٢‬‫ﻫﻤ ـﺎن ﻃ ـﻮر ﮐ ـﻪ ﻣ ـﺸﺎﻫﺪه ﻣ ـﯽﺷ ـﻮد در ﮐ ـﺪ از ﮐ ـﻼسﻫ ـﺎي ‪ WebConversion‬و ‪ WebRequest‬و‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ ـ‬ ‫ـ ـ ـ‬ ‫ـ‬ ‫‪ WebResponse‬اﺳﺘﻔﺎده ﻣﯽﺷﻮد.‬‫ﭘﺎﯾﻪ ‪ httpunit‬ﮐﻼس ‪ webconversion‬اﺳﺖ، ﮐﻪ ﻣﮑﺎن ﺳﺎﯾﺘﯽ را ﮐﻪ ﻣﯽﺧﻮاﻫﯿﻢ ﺑﺮرﺳﯽ ﮐﻨﯿﻢ را ﻣﯽﮔﯿﺮد.‬ ‫ﺑﺮاي اﺳﺘﻔﺎه از آن، ﺑﺎﯾﺪ ﯾﮏ درﺧﻮاﺳﺖ اﯾﺠﺎد ﮐﺮده و از ‪ webconversion‬ﺗﻘﺎﺿﺎي ﭘﺎﺳﺦ ﻧﻤﻮد .‬ ‫ﻣﺜﻼً:‬‫;)(‪WebConversation wc = new WebConversation‬‬‫‪WebRequest req = new‬‬‫;) "‪GetMethodWebRequest("http://www.meterware.com/testpage.html‬‬‫‪WebResponse‬‬ ‫;) ‪resp = wc.getResponse( req‬‬‫ﺣﺎﻻ ﭘﺎﺳﺦ ﺑﺮﮔﺮداﻧﺪه ﺷﺪه را ﻣﯽﺗﻮان ﺑﺎ ﺗﺎﺑﻊ )(‪ gettext‬ﺑﻪ ﻋﻨﻮان ﻣﺘﻦ و ﯾـﺎ ﺑـﺼﻮرت ﯾـﮏ ‪ DOM‬از ﻃﺮﯾـﻖ‬ ‫ﺗﺎﺑﻊ )(‪ getDOM‬ﺑﺮرﺳﯽ ﮐﺮد.‬‫ﻣﺘﺄﺳﻔﺎﻧﻪ ، اﮔﺮ در ﺻﻔﺤﻪاي از ﻣﻘﺎدﯾﺮ زﯾﺎدي ﮐﺪﻫﺎي ﺟـﺎوا اﺳـﮑﺮﯾﭙﺖ اﺳـﺘﻔﺎده ﺷـﺪه ﺑﺎﺷـﺪ، ﻧﻤـﯽﺗـﻮان از‬ ‫‪ httpunit‬ﺑﺮاي ﺗﺴﺖ آن ﺻﻔﺤﻪ اﺳﺘﻔﺎده ﮐﺮد.‬‫ﺗﺴﺖ اﺗﻮﻣﺎت ﺑﺮاي ﺑﺮﻧﺎﻣﻪﻫﺎي ﺟﺎواي ‪ ، standalone‬ﭼﻪ روي ﺧﻂ ﻓﺮﻣﺎن اﺟﺮا ﺷﻮﻧﺪ و ﭼﻪ ﺑـﻪ ﻋﻨـﻮان ﯾـﮏ‬‫ﮐﺎﻣﭙﻮﻧﻨﺖ اﺳﺘﻔﺎده ﺷﻮﻧﺪ، ﺑﺎ اﺳﺘﻔﺎده از ‪ Junit‬اﺟﺮا ﻣﯽﺷﻮﻧﺪ. ﭼﻮن ﺑﺮﻗـﺮاري ارﺗﺒـﺎط در ﺑﺮﻧﺎﻣـﻪ ﻫـﺎي وب از‬‫ﻃﺮﯾﻖ ‪ http‬اﺳﺖ و ﻧﻪ از ﻃﺮﯾﻖ ﻓﺮاﺧﻮاﻧﯽ ﺗﻮاﺑﻊ ﺟﺎوا، ﺑﻨﺎﺑﺮاﯾﻦ ‪ Junit‬ﺑـﺮاي ﺗـﺴﺖ ﺑﺮﻧﺎﻣـﻪﻫـﺎي وب ﻣﻨﺎﺳـﺐ‬‫ﻧﯿﺴﺖ. در اﯾﻨﺠﺎ ‪ httpunit‬ﺑﻪ ﮐﻤﮏ ﻣﺎ ﻣﯽآﯾﺪ. اﯾﻦ اﺑﺰار ﺑﻪ ﻃﻮر راﯾﮕﺎن در دﺳـﺘﺮس اﺳـﺖ و اﻣﮑـﺎن ﺗـﺴﺖ‬ ‫ﺑﺮﻧﺎﻣﻪﻫﺎي وب را ﻓﺮاﻫﻢ ﻣﯽﮐﻨﺪ و در واﻗﻊ ﻣﮑﻤﻠﯽ ﺑﺮاي ‪ Junit‬اﺳﺖ.‬‫ﻣﯽﺗﻮاﻧﯿﺪ از ‪ httpunit‬ﺟﺪاﮔﺎﻧﻪ اﺳﺘﻔﺎده ﮐﻨﯿﺪ و ﯾﺎ اﯾﻨﮑﻪ ﺗﻮاﻧﺎﯾﯽﻫﺎي ﻫﺮ دو را ﺗﺮﮐﯿﺐ ﮐﻨﯿﺪ و از وﯾﮋﮔﯽﻫـﺎي‬‫‪ reporting , regression‬ﻣﻮﺟﻮد در ‪ junit‬ﻧﯿﺰ اﺳﺘﻔﺎده ﮐﻨﯿﺪ. ‪ httpunit‬ﺷﺎﻣﻞ ﮐﺪﻫﺎﯾﯽ ﺑﺮاي ﺷـﺒﯿﻪ ﺳـﺎزي‬‫ﻋﻤﻠﮑﺮد ﯾﮏ ﻣﺮورﮔﺮ، و ﻫﻤﭽﻨﯿﻦ ﭘﺸﺘﯿﺒﺎﻧﯽ ﺟﺰﺋﯽ از ‪ JavaScript‬اﺳﺖ. در اﺻﻞ ‪ httpunit‬ﯾﮏ ﮐﻼﯾﻨﺖ وب‬ ‫ﻗﺎﺑﻞ ﺑﺮﻧﺎﻣﻪرﯾﺰي اﺳﺖ.‬
    • ‫٦٢‬‫‪ Client API‬ﻫﺎي ﻣﻮﺟﻮد در ‪ httpunit‬اﯾﻦ اﻣﮑﺎن را ﺑﻪ ﺷﻤﺎ ﻣﯽدﻫﻨﺪ ﮐﻪ ﺗﺴﺖﻫﺎﯾﯽ ﺑﻨﻮﯾﺴﯿﺪ ﺗﺎ ﮐـﺎرﺑﺮي را‬‫ﮐﻪ ﺑﻪ ﯾﮏ ﺑﺮﻧﺎﻣﻪ وب از ﻃﺮﯾﻖ ﯾﮏ ﻣﺮورﮔﺮ دﺳﺘﺮﺳﯽ ﭘﯿﺪا ﻣﯽﮐﻨﺪ را، ﺷﺒﯿﻪ ﺳﺎزي ﮐﻨﯿﺪ. ‪ httpunit‬ﺧﯿﻠﯽ از‬‫ﻋﻤﻠﮑﺮدﻫﺎﯾﯽ را ﮐﻪ ﺷﻤﺎ از ﯾﮏ ﻣﺮورﮔﺮ اﻧﺘﻈﺎر دارﯾﺪ را ﭘﺸﺘﯿﺒﺎﻧﯽ ﻣﯽﮐﻨﺪ، از ﺟﻤﻠـﻪ ﻣـﺪﯾﺮﯾﺖ ﮐـﻮﮐﯽ ﺑـﺮاي‬‫‪ session‬ﻫﺎ و ارﺳﺎل ﻓﺮمﻫﺎ از ﻃﺮﯾﻖ ﻣﺘﺪﻫﺎي ‪ GET‬و ‪ POST‬و اﺣﺮاز ﻫﻮﯾﺖ و.... ﻣﯽﺗﻮان ﺑﻪ دﻧﺒـﺎل ﻋﻨـﺼﺮ‬‫ﺧﺎﺻﯽ روي ﺻﻔﺤﻪ، ﻟﯿﻨﮏ ﺑﻪ ﻟﯿﻨﮏ ﯾﺎ ﻓﺮم ﺑﻪ ﻓﺮم ﮔﺸﺖ و ﻣﻄﻤﺌﻦ ﺷﺪ ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﻧﺘﺎﯾﺞ درﺳﺘﯽ را ﺑﺮﮔﺮداﻧﺪه‬ ‫اﺳﺖ.‬ ‫دو روش اﺳﺎﺳﯽ ﺑﺮاي اﻧﺠﺎم ﺗﺴﺖﻫﺎي اﺗﻮﻣﺎت روي ﺑﺮﻧﺎﻣﻪﻫﺎي وب ﻋﺒﺎرﺗﻨﺪ از:‬ ‫‪ ‬از ﻃﺮﯾﻖ ﻣﺎﮐﺮوﻫﺎي ﺿﺒﻂ ﺷﺪه ﮐﻪ ﻣﯽﺗﻮاﻧﻨﺪ ﺗﮑﺮار ﺷﻮﻧﺪ‬ ‫‪ ‬از ﻃﺮﯾﻖ ‪ API‬ﻫﺎي ﻗﺎﺑﻞ ﺑﺮﻧﺎﻣﻪرﯾﺰي ﮐﻪ ﭘﺎﺳﺦﻫﺎي ‪ http‬را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﻨﺪ.‬‫روش اول اﺣﺘﯿﺎج ﺑﻪ ﺑﺎزﺑﯿﻨﯽﻫﺎي ﻣﺘﻨﺎوب دارد و ﮐﺎرﺑﺮد آن ﺳﺨﺖ اﺳﺖ. ﺑﺮاي ﯾﮏ ‪ API‬ﻗﺎﺑﻞ ﺑﺮﻧﺎﻣـﻪرﯾـﺰي،‬‫ﺑﺎﯾﺪ اﺟﺰاي ﻓﺎﯾﻞ ‪ HTML‬درﯾﺎﻓﺖ ﺷﺪه از وب ﺳﺮور را از ﻫﻢ ﺟﺪا ﮐﺮد و ﺳﻠﺴﻠﻪ ﻣﺮاﺗﺐ اﻟﻤﺎنﻫﺎي ‪HTML‬‬ ‫و ﻣﺤﺘﻮﯾﺎت ﻣﺘﻨﯽ را ﺗﺸﮑﯿﻞ داد. اﯾﻦ روش اﻧﻌﻄﺎف ﭘﺬﯾﺮﺗﺮي اﺳﺖ ﮐﻪ ‪ Httpunit‬ﺑﻪ ﮐﺎر ﻣﯽﺑﺮد.‬‫ﻧﻘﻄﻪ ﺿﻌﻒ روش دوم در ﻣﻘﺎﯾﺴﻪ ﺑﺎ روش اول زﻣﺎن ﻃﻮﻻﻧﯽ ﺑﺮاي اﯾﺠـﺎد ﺗـﺴﺖﻫـﺎ و ﻧﯿـﺎز ﺑـﻪ آﺷـﻨﺎﯾﯽ ﺑـﺎ‬‫روشﻫﺎي ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ اﺳﺖ. اﻣﺎ زﻣﺎن ‪ maintenance‬در روش دوم ﮐﻮﺗﺎهﺗﺮ اﺳﺖ زﯾﺮا ﺑﺎ ﺗﻐﯿﯿـﺮات ﮐﻮﭼـﮏ‬ ‫ﻧﯿﺎز ﺑﻪ ﺿﺒﻂ دوﺑﺎره ﻣﺎﮐﺮو ﻧﯿﺴﺖ.‬‫ﮐﻮﺗﺎﻫﯽ زﻣﺎن ‪ maintenance‬اﻫﻤﯿﺖ ﺑﯿﺸﺘﺮي دارد ﮐﻪ ﻃﻮﻻﻧﯽ ﺑﻮدن زﻣﺎن اﯾﺠﺎد ﺗﺴﺖ را ﮐﻢ رﻧﮓ ﻣﯽﮐﻨﺪ.‬‫ﻋﻼوه ﺑﺮ اﯾﻦ ﻋﯿﺐ دﯾﮕﺮي ﮐﻪ روش اول دارد اﯾﻨﺴﺖ ﮐﻪ ﻧﻤﯽﺗﻮاﻧﯿﻢ از روشﻫـﺎي ‪) XP‬روشﻫـﺎي ﺗـﺴﺖ از‬ ‫اﺑﺘﺪا( اﺳﺘﻔﺎده ﮐﻨﯿﻢ، ﭼﻮن ﺑﺎﯾﺪ ﯾﮏ ﺑﺮﻧﺎﻣﻪي در ﺣﺎل ﮐﺎر ﻣﻮﺟﻮد ﺑﺎﺷﺪ.‬ ‫‪HTMLUnit‬‬
    • ‫٧٢‬‫اﺑﺰار 32‪ HTMLUnit‬ﯾﮏ ﻣﺮورﮔﺮ اﺳﺖ ﮐﻪ ﺑﻪ زﺑﺎن ﺟﺎوا ﻧﻮﺷﺘﻪ ﺷﺪه و دﺳﺖﮐﺎري ﺳﻄﺢ ﺑﺎﻻي ﺻﻔﺤﺎت وب‬‫ﻣﺜﻞ ﺗﮑﻤﯿﻞ ﻓﺮمﻫﺎ و ﮐﻠﯿﮏ ﮐﺮدن اﺑﺮﻣﺘﻦ و دﺳﺘﺮﺳﯽ ﺑﻪ اﻟﻤﺎنﻫﺎي ﺧﺎﺻﯽ در ﺻﻔﺤﻪ را ﻣﻤﮑـﻦ ﻣـﯽﺳـﺎزد.‬‫ﻧﯿﺎزي ﻧﯿﺴﺖ ﺗﺎ درﺧﻮاﺳﺖﻫﺎي ﺳﻄﺢ ﭘﺎﯾﯿﻦ ‪ TCP/IP‬و ‪ HTTP‬را اﯾﺠﺎد ﮐﻨﯿﺪ، ﺑﻠﮑﻪ ﻓﻘـﻂ )‪getpage(URL‬‬‫را اﺟﺮا ﮐﻨﯿﺪ و اﺑﺮﻣﺘﻦ دﻟﺨﻮاه را ﭘﯿـﺪا ﮐﻨﯿـﺪ و ﺣـﺎﻻ ﺟﺎوااﺳـﮑﺮﯾﭙﺖ و ‪ ajax‬و ‪ html‬ﺑـﻪ ﺻـﻮرت اﺗﻮﻣﺎﺗﯿـﮏ‬‫ﭘـﺮدازش ﻣ ـﯽﺷـﻮﻧﺪ. اﺳـﺘﻔﺎده ﻣﻌﻤـﻮلﺗ ـﺮ از ‪ htmlunit‬در ﺧﻮدﮐﺎرﺳـﺎزي ﺗـﺴﺖ ﺻـﻔﺤﺎت وب )ﺣﺘـﯽ ﺑ ـﺎ‬ ‫ـ ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ ـ‬ ‫ـ‬ ‫ـ ـ‬ ‫ـ‬‫ﮐﺘﺎﺑﺨﺎﻧﻪﻫﺎي ﺑﺴﯿﺎر ﭘﯿﭽﯿﺪه ﺟﺎوا اﺳﮑﺮﯾﭙﺖ( اﺳﺖ. ﮔﺎﻫﯽ اوﻗﺎت ﻧﯿﺰ ﻣﯽﺗﻮان ﺑﺮاي ‪ webscraping‬و ﯾﺎ داﻧﻠﻮد‬‫ﻣﺤﺘﻮي وب ﺳﺎﯾﺖ اﺳﺘﻔﺎده ﮐﺮد. ‪ htmlunit‬اﺧﯿﺮاً ﭘـﺸﺘﯿﺒﺎﻧﯽ ﺧـﻮد را در زﻣﯿﻨـﻪ ‪ javascript‬اﻓـﺰاﯾﺶ داده‬‫اﺳﺖ. ‪ API‬ﻫﺎي ‪ htmlunit‬ﮐﻤﯽ از ‪ httpunit‬ﺳـﻄﺢ ﺑـﺎﻻﺗﺮ اﺳـﺖ و ﺗﻌـﺎﻣﻼت وب را ﺑـﺼﻮرت ﻣـﺴﺘﻨﺪات و‬ ‫اﯾﻨﺘﺮﻓﯿﺲﻫﺎﯾﯽ ﮐﻪ ﮐﺎرﺑﺮ ﺑﺎ آﻧﻬﺎ ﺗﻌﺎﻣﻞ ﻣﯽﮐﻨﺪ، ﻣﺪل ﻣﯽﮐﻨﺪ.‬‫;)(‪WebClient wc = new WebClient‬‬‫)‪HtmlPage page = (HtmlPage‬‬‫;)"‪wc.getPage("http://www.google.com‬‬‫;)"‪HtmlForm form = page.getFormByName("f‬‬‫)‪HtmlSubmitInput button = (HtmlSubmitInput‬‬‫;)"‪form.getInputByName("btnG‬‬‫;)(‪HtmlPage page2 = (HtmlPage) button.click‬‬‫ﻫﻤﺎن ﻃـﻮر ﮐـﻪ ﻣـﯽﺑﯿﻨﯿـﺪ ﮐـﺪ از ‪ webclient‬و ‪ page‬و ‪ link‬و ‪ form‬و ‪ button‬و... اﺳـﺘﻔﺎده ﻣـﯽﮐﻨـﺪ.‬‫ﺻﻔﺤﺎﺗﯽ ﮐﻪ از ‪ javascript‬ﺳﺎده اﺳﺘﻔﺎده ﮐﺮدهاﻧﺪ، زﻣﺎﻧﯿﮑﻪ ﺑﺎ ‪ httpunit‬ﺗﺴﺖ ﻣﯽﺷﻮﻧﺪ ﮐﺎر ﻣـﯽﮐﻨﻨـﺪ وﻟـﯽ‬‫ﺻﻔﺤﺎﺗﯽ ﮐﻪ از ﮐﺘﺎﺑﺨﺎﻧﻪﻫﺎي دﯾﮕﺮ ﺟﺎوااﺳﮑﺮﯾﭙﺖ اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ، ﻫﻨﮕﺎﻣﯿﮑﻪ ﺑﺎ ‪ httpunit‬ﺗﺴﺖ ﻣـﯽﺷـﻮﻧﺪ‬‫ﻣﻤﮑﻦ اﺳﺖ ﮐﺎر ﮐﻨﻨﺪ ﯾﺎ ﻧﮑﻨﻨﺪ. در واﻗﻊ ‪ htmlunit‬ﯾـﮏ ﻣﺮورﮔـﺮ ﺑـﺮاي ﺑﺮﻧﺎﻣـﻪﻫـﺎي ﺟﺎواﺳـﺖ و ﺻـﻔﺤﺎت‬‫‪ HTML‬را ﻣﺪل ﻣﯽﮐﻨﺪ و ‪ API‬ﻫﺎﯾﯽ را ﻋﺮﺿﻪ ﻣﯽﮐﻨﺪ ﮐﻪ ﺑﻪ ﺷـﻤﺎ اﺟـﺎزه ﻓﺮاﺧـﻮاﻧﯽ ﺻـﻔﺤﺎت و ﭘﺮﮐـﺮدن‬‫ﻓﺮمﻫﺎ و ﮐﻠﯿﮏ ﮐﺮدن روي ﻟﯿﻨﮏﻫﺎ و ... را دﻗﯿﻘﺎً ﻫﻤﺎن ﻃﻮر ﮐﻪ ﯾﮏ ﻣﺮورﮔﺮ ﻧﺮﻣﺎل ﻋﻤﻞ ﻣﯽﮐﻨﺪ، ﻣـﯽدﻫـﺪ.‬‫ﭘﺸﺘﯿﺒﺎﻧﯽ آن از ﺟﺎوا اﺳﮑﺮﯾﭙﺖ ﺧﻮب و رو ﺑﻪ ﭘﯿﺸﺮﻓﺖ اﺳﺖ و ﺗﻘﺮﯾﺒﺎً ﺑـﺎ ﮐﺘﺎﺑﺨﺎﻧـﻪﻫـﺎي ﭘﯿﭽﯿـﺪه ‪ ajax‬ﻧﯿـﺰ‬‫32‬ ‫‪http://www.sourceforge.net/projects/htmlunit‬‬
    • ‫٨٢‬‫ﻣﯽﺗﻮاﻧﺪ ﮐﺎر ﮐﻨﺪ و ﻣﯽﺗﻮاﻧﺪ ‪ Firefox‬و ‪ IE‬را ﺷﺒﯿﻪ ﺳﺎزي ﮐﻨﺪ. ﻣﻌﻤﻮﻻً ‪ httpunit‬ﻫﻤﺮاه ﺑـﺎ ﭼـﺎرﭼﻮبﻫـﺎي‬‫دﯾﮕﺮي ﻣﺜﻞ ‪ junit‬و ‪ testNG‬اﺳﺘﻔﺎده ﻣﯽﺷﻮد. از ‪ httpunit‬در اﺑﺰارﻫﺎي ﻣﻨﺒﻊ ﺑـﺎز ﻣﺜـﻞ ‪ canoowebtest‬و‬ ‫‪ JWebUnit‬و ‪ Webdriver‬و ...ﺑﻪ ﻋﻨﻮان ﻣﺮورﮔﺮ اﺳﺘﻔﺎده ﻣﯽﺷﻮد.‬ ‫وﯾﮋﮔﯿﻬﺎي‪: htmlunit‬‬ ‫ﭘﺸﺘﯿﺒﺎﻧﯽ از ﭘﺮوﺗﮑﻠﻬﺎي ‪ http‬و ‪https‬‬ ‫‪‬‬ ‫‪ ‬ﭘﺸﺘﯿﺒﺎﻧﯽ از ﮐﻮﮐﯽ ﻫﺎ‬ ‫ﭘﺸﺘﯿﺒﺎﻧﯽ از روﺷﻬﺎي ‪ GET‬و ‪POST‬‬ ‫‪‬‬ ‫ﭘﺸﺘﯿﺒﺎﻧﯽ از ‪proxy server‬‬ ‫‪‬‬ ‫ﭘﺸﺘﯿﺒﺎﻧﯽ از ‪[html] javascript‬‬ ‫‪‬‬ ‫‪Selenium‬‬‫‪ 24Selenium‬ﻣﺠﻤﻮﻋﻪاي از اﺑﺰارﻫﺎﺳﺖ ﺗﺎ در ﭘﻠﺘﻔﺮمﻫﺎي ﻣﺨﺘﻠﻒ ﺑﺘﻮاﻧﯿﺪ ﺗﺴﺖ ﺑﺮﻧﺎﻣـﻪﻫـﺎي وب را اﺗﻮﻣـﺎت‬‫ﮐﻨﯿﺪ و در ﻣﺮورﮔﺮﻫﺎ و ﺳﯿﺴﺘﻢ ﻋﺎﻣﻞﻫﺎي ﻣﺘﻔﺎوﺗﯽ اﺟﺮا ﻣﯽﺷﻮد ‪ htmlunit‬و ‪ httpunit‬رﻓﺘﺎر ﯾﮏ ﻣﺮورﮔﺮ را‬‫ﺗﻘﻠﯿﺪ ﻣﯽﮐﻨﻨﺪ وﻟﯽ ﺗﺴﺖﻫﺎي ‪ selenium‬دﻗﯿﻘﺎً روي ﯾﮏ ﻣﺮورﮔـﺮ واﻗﻌـﯽ اﺟـﺮا ﻣـﯽﺷـﻮﻧﺪ. ﮐـﺪﻫﺎي ﺟـﺎوا‬‫اﺳﮑﺮﯾﭙﺖ ﮐﻪ ‪ selenium‬ﺗﻮﻟﯿﺪ ﻣﯽﮐﻨﺪ در ﺣﯿﻦ ﺑﺮﻧﺎﻣﻪ در ﺣﺎل اﺟﺮا اﯾﺠﺎد ﻣﯽﺷـﻮﻧﺪ و ﺳـﭙﺲ دﻗﯿﻘـﺎً ﻣﺜـﻞ‬ ‫ﮐﺎرﺑﺮ ﺑﺎ ﺑﺮﻧﺎﻣﻪ ﺗﻌﺎﻣﻞ ﻣﯽﮐﻨﻨﺪ.‬ ‫‪Selenium IDE‬‬‫ﯾﮏ ‪ add-on‬روي ‪ firefox‬ﮐﻪ ﮐﻠﯿﮏ ﻫﺎ و ﺗﺎﯾﭗ ﻫﺎ و ﺳﺎﯾﺮ ﻋﻤﻠﯿﺎت را ﺿﺒﻂ ﻣﯽﮐﻨﺪ و ﺷـﻤﺎ ﻣـﯽﺗﻮاﻧﯿـﺪ در‬‫ﻣﺮورﮔﺮ آﻧﻬﺎ را دوﺑﺎره اﺟﺮا ﮐﻨﯿﺪ و ﯾﺎ اﺳﮑﺮﯾﭙﺖ اﯾﺠـﺎد ﺷـﺪه را وﯾـﺮاﯾﺶ ﮐﻨﯿـﺪ. ﺗﻮﺟـﻪ ﮐﻨﯿـﺪ ﮐـﻪ در ﺳـﺎﯾﺮ‬ ‫ﻣﺮورﮔﺮﻫﺎ از اﯾﻦ ﻧﺴﺨﻪ ﻧﻤﯽﺗﻮان اﺳﺘﻔﺎده ﮐﺮد.‬‫42‬ ‫‪http://www.testinggeek.com/selenium.asp‬‬
    • ‫٩٢‬ ‫ﺷﮑﻞ 4-1- ‪Selenium IDE‬‬ ‫‪Selenium Remote Control‬‬ ‫اﻧﺘﺨﺎب زﺑﺎن و ﻣﺮورﮔﺮ دﻟﺨﻮاه :‬‫ﺗﺴﺖﻫﺎ را روي ﻣﺮورﮔﺮﻫﺎ و ﭼﺎرﭼﻮبﻫﺎي ﻣﺨﺘﻠﻒ اﺟﺮا ﻣﯽﮐﻨﺪ و ﺗﺴﺖﻫﺎ را ﺑﻪ زﺑﺎن دﻟﺨـﻮاه ﻣـﯽﻧﻮﯾـﺴﺪ. و‬‫ﺑﺴﯿﺎر ﭘﯿﺸﺮﻓﺘﻪ ﺗﺮ از ﺑﺎﻻﯾﯽ اﺳﺖ و ﻗﺎدر اﺳﺖ ﮔﺴﺘﺮه وﺳﯿﻊ ﺗﺮي از ﺑﺮﻧﺎﻣﻪ ﻫﺎي وب را ﺗﺴﺖ ﮐﻨﺪ و ﻣﻘﯿـﺎس‬‫ﭘﺬﯾﺮﺗﺮ اﺳﺖ و ﻧﯿﺰ ﺑﺮاي آﻏﺎز ﺑﻪ ﮐﺎر ﮐﻤﯽ ﺑﻪ اﻃﻼﻋﺎت ﻓﻨﯽ ﻧﯿﺎز اﺳﺖ. در زﯾﺮ ﻧﻤﺎﯾﺶ ﺳﺎﺧﺘﺎري ﺳـﺎده ﺷـﺪه‬ ‫آن را ﻣﯽﺑﯿﻨﯿﺪ.‬ ‫‪Selenium RC‬از دو ﺑﺨﺶ ﺗﺸﮑﯿﻞ ﺷﺪه اﺳﺖ:‬‫‪ ‬ﯾﮏ ﺳﺮور ﮐﻪ ﺑﺼﻮرت ﺧﻮدﮐﺎر ﻣﺮورﮔﺮ را اﺟﺮا و ﯾﺎ ﺗﻤﺎم ﻣﯽﮐﻨﺪ و ﺑﺮاي درﺧﻮاﺳـﺖﻫـﺎي وب آﻧﻬـﺎ‬ ‫ﺑﺼﻮرت ﯾﮏ ‪ http proxy‬ﻋﻤﻞ ﻣﯽﮐﻨﺪ.‬ ‫‪ ‬ﮐﺘﺎﺑﺨﺎﻧﻪﻫﺎي ﮐﺎرﺑﺮ ﺑﺮاي زﺑﺎن ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ دﻟﺨﻮاه ﺷﻤﺎ‬
    • ‫٠٣‬‫ﺳﺮور ‪ selenium‬ﻣﺴﺘﻘﯿﻤﺎً ﺑـﻪ ﻣﺮورﮔـﺮ از ﻃﺮﯾـﻖ )‪ Ajax(xmlhttorequest‬ﻣﺘـﺼﻞ ﻣـﯽﺷـﻮد. ﻣـﯽﺗﻮاﻧﯿـﺪ‬‫ﻣﺴﺘﻘﯿﻤﺎً دﺳﺘﻮرات را ﺑﻪ ﺳﺮور ﺑﺎ اﺳﺘﻔﺎده از درﺧﻮاﺳﺖﻫﺎي ﺳﺎده ‪ HTTP GET/POST‬ﺑﻔﺮﺳـﺘﯿﺪ. ﺑـﻪ اﯾـﻦ‬‫ﻣﻌﻨﺎ ﮐﻪ از ﻫﺮ زﺑﺎن ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﮐﻪ ﻣﯽﺗﻮاﻧﺪ در ﺧﻮاﺳﺖﻫﺎي ‪ HTTP‬اﯾﺠﺎد ﮐﻨﺪ ﺗﺎ ﺗﺴﺖﻫﺎي ‪ selenium‬را‬‫روي ﻣﺮورﮔﺮ اﺗﻮﻣﺎت ﮐﻨﺪ، اﺳﺘﻔﺎده ﮐﻨﯿﺪ. ﺳﺮور ﺳﻠﻨﯿﻮم ﺑﻪ ﻋﻨﻮان ﯾﮏ ‪ http proxy‬ﺗﻨﻈـﯿﻢ ﺷـﺪه در ﺳـﻤﺖ‬‫ﮐﺎرﺑﺮ اﺳﺖ و ﺑﯿﻦ ﻣﺮورﮔﺮ و وب ﺳﺎﯾﺖ ﺷﻤﺎ ﻗﺮار ﻣﯽﮔﯿﺮد. ﺑﻪ اﯾﻦ ﺗﺮﺗﯿﺐ ﻗﺎدر ﺧﻮاﻫﯿﺪ ﺑﻮد ﯾـﮏ ﻣﺮورﮔـﺮ ﺑـﺎ‬ ‫ﻗﺎﺑﻠﯿﺖﻫﺎي ﺳﻠﻨﯿﻮم، ﺑﺮاي اﺟﺮاي ﺟﺎوا اﺳﮑﺮﯾﭙﺖ روي وب ﺳﺎﯾﺖﻫﺎ داﺷﺘﻪ ﺑﺎﺷﯿﺪ.‬ ‫ﺑﺎ ﺷﺮوع اﺟﺮاي ﯾﮏ ﻣﺠﻤﻮﻋﻪ ﺗﺴﺖ:‬ ‫‪ ‬ﮐﻼﯾﻨﺖ ﯾﺎ ﺑﺮﻧﺎﻣﻪ ﺷﻤﺎ ﺑﻪ ﺳﺮور ﺳﻠﻨﯿﻮم دﺳﺘﺮﺳﯽ دارد.‬‫‪ ‬ﺳﺮور ﺳﻠﻨﯿﻮم ﯾﮏ ﻣﺮورﮔﺮ را ﺑﺎ ‪ URL‬اﯾﺠﺎد ﻣﯿﮑﻨﺪ .ﮐﻪ ﺻﻔﺤﻪ وب ﻫﺴﺘﻪ ﺳـﻠﻨﯿﻮم را ﺑـﺎر ﺧﻮاﻫـﺪ‬ ‫ﮐﺮد.‬‫‪ ‬ﻫﺴﺘﻪ ﺳﻠﻨﯿﻮم اوﻟﯿﻦ دﺳﺘﻮر را از ﮐﻼﯾﻨﺖ ﯾﺎ ﺑﺮﻧﺎﻣﻪ ﺷﻤﺎ ﻣﯿﮕﯿﺮد )از ﻃﺮﯾﻖ ‪ httpproxy‬ﺗﻌﺒﯿﻪ ﺷـﺪه‬ ‫در ﺳﺮور ﺳﻠﻨﯿﻮم (‬ ‫ﻫﺴﺘﻪ ﺳﻠﻨﯿﻮم دﺳﺘﻮر را اﺟﺮا ﻣﯽﮐﻨﺪ؛ ﻣﺜﻼ ﺑﺎر ﮐﺮدن ﯾﮏ ﺻﻔﺤﻪ. ]‪[sel‬‬ ‫‪‬‬ ‫‪EMMA‬‬‫52‪ ،EMMA‬ﯾﮏ اﺑﺰار ﻣﺘﻦ ﺑﺎز ﺑﺮاي اﻧﺠﺎم ﺗﺴﺖ ﭘﻮﺷﺶ ﮐﺪ ﺑﺮ روي ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه ﺑـﻪ زﺑـﺎن ﺟـﺎوا‬‫ﻣﯽﺑﺎﺷﺪ. ﺑﺎ اﺳﺘﻔﺎده از آن ﻣﯽﺗﻮان ﺑﺮرﺳﯽ ﮐﺮد ﮐﻪ در ﺣﯿﻦ اﺟـﺮاي ﺑﺮﻧﺎﻣـﻪ، ﮐـﺪام دﺳـﺘﻮرات ﺑﺮﻧﺎﻣـﻪ اﺟـﺮا‬‫ﺷﺪهاﻧﺪ و ﭼﻪ ﻣﻘﺪاري از ﮐﺪﻫﺎي ﺑﺮﻧﺎﻣﻪ ﭘﻮﺷﺶ داده ﺷﺪهاﻧﺪ. ﺑﻌﻨﻮان ﻣﺜﺎل ﻣﯽﺗﻮان ﺑﺮرﺳﯽ ﮐـﺮد ﮐـﻪ ﮐـﺪام‬‫ﻣﺘﺪﻫﺎ اﺟﺮا ﻧﺸﺪه اﻧﺪ ﯾﺎ ﮐﺪام ﮐﻼﺳﻬﺎ اﺻﻼ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻧﮕﺮﻓﺘﻪ اﻧﺪ. ﻣﻬﻤﺘﺮﯾﻦ وﯾﮋﮔﯽ ‪ EMMA‬ﺳﺮﻋﺖ‬ ‫ﺑﺎﻻي آن ﻣﯽﺑﺎﺷﺪ.‬ ‫52/‪http://emma.sourceforge.net‬‬
    • ‫١٣‬‫روش ﮐﺎر ﺑﺪﯾﻦ ﺗﺮﺗﯿﺐ اﺳﺖ ﮐﻪ ﯾﮏ ﺑﺮﻧﺎﻣﻪ اﺟﺮاﯾﯽ را ﺑﻪ ‪ EMMA‬ﻣﯽدﻫـﯿﻢ. ‪ EMMA‬ﺑـﻪ اﺟـﺮاي ﺑﺮﻧﺎﻣـﻪ‬‫ﻣﯽ ﭘﺮدازد و ﭘﺲ از ﭘﺎﯾﺎن ﺑﺮﻧﺎﻣﻪ، ﮔﺰارﺷﻬﺎي ﻣﻨﺎﺳﺒﯽ در ﻗﺎﻟﺐ ﻓﺎﯾﻠﻬﺎي ﻣﺘﻨﯽ ﯾﺎ ﻓﺎﯾﻠﻬﺎي ‪ html‬ﯾﺎ ‪ xml‬اﯾﺠﺎد‬‫ﻣﯽﮐﻨﺪ ﮐﻪ ﺟﺎوي اﻃﻼﻋﺎت ﻣﻨﺎﺳﺒﯽ ﻣﯽﺑﺎﺷﻨﺪ و ﻣـﺸﺨﺺ ﻣـﯽﮐﻨﻨـﺪ ﮐـﻪ در ﺣـﯿﻦ اﺟـﺮاي ﺑﺮﻧﺎﻣـﻪ، ﮐـﺪام‬ ‫ﻗﺴﻤﺘﻬﺎي ﮐﺪ ﻣﻮرد اﺟﺮا ﻗﺮار ﮔﺮﻓﺘﻪ اﻧﺪ.‬‫ﻧﮑﺘﻪ ﻣﻬﻢ آن اﺳﺖ ﮐﻪ ﺑﺮاي اﺳﺘﻔﺎده از اﯾﻦ اﺑﺰار، ﻧﯿﺎزي ﻧﯿﺴﺖ ﻣﺘﻦ ﮐﺪ ﺑﺮﻧﺎﻣﻪ را در اﺧﺘﯿﺎر داﺷـﺘﻪ ﺑﺎﺷـﯿﻢ.‬‫ﻓﻘﻂ ﮐﺎﻓﯽ اﺳﺖ ﻓﺎﯾﻠﻬﺎي ‪ .class‬ﺑﺮﻧﺎﻣﻪ ﮐﻪ ﺣﺎوي ﺑﺎﯾﺖ ﮐﺪﻫﺎي ﺟﺎوا ﻣﯽﺑﺎﺷـﻨﺪ را ﺑـﻪ آن ﺑـﺪﻫﯿﻢ. ‪EMMA‬‬‫اﺑﺘﺪا ﮐﺪﻫﺎي ﺧﺎﺻﯽ را در ﻣﯿﺎن ﮐﺪﻫﺎي ﺑﺮﻧﺎﻣﻪ، درج ﻣﯽﮐﻨﺪ و ﺳﭙﺲ ﺑﻪ اﺟﺮاي ﺑﺮﻧﺎﻣﻪ ﻣﯽﭘﺮدازد و ﺳﭙﺲ ﺑﺎ‬ ‫اﺳﺘﻔﺎده از ﮐﺪﻫﺎﯾﯽ ﮐﻪ درج ﮐﺮده ﺑﻪ ﺗﺸﺨﯿﺺ دﺳﺘﻮراﺗﯽ ﮐﻪ اﺟﺮا ﻧﺸﺪه اﻧﺪ ﻣﯽﭘﺮدازد.‬‫‪ ،EMMA‬ﻣﯽﺗﻮاﻧﺪ ﻣﯿﺰان ﭘﻮﺷﺶ ﮐﻼﺳﻬﺎ، ﻣﺘﺪﻫﺎ، ﺧﻂ ﻫﺎ و ﺑﻼﮐﻬﺎي ﺑﺮﻧﺎﻣﻪ را ﮔـﺰارش ﻧﻤﺎﯾـﺪ. ﮔﺰارﺷـﻬﺎي‬‫ﺗﻮﻟﯿﺪ ﺷﺪه ﺑﺴﯿﺎر ﻣﻨﺎﺳﺐ و ﮔﻮﯾﺎ ﻣﯽﺑﺎﺷﻨﺪ و اﮔﺮ از ﻗﺎﻟـﺐ ‪ html‬ﺑﻌﻨـﻮان ﺳـﺎﺧﺘﺎر ﮔـﺰارش اﺳـﺘﻔﺎده ﻧﻤـﻮده‬‫ﺑﺎﺷﯿﻢ، اﻣﮑﺎن ﺟﺎﺑﺠﺎ ﺷﺪن ﺑﯿﻦ ﺻﻔﺤﺎت ﮔﺰارش ﺑﺎ اﺳﺘﻔﺎده از ﻟﯿﻨﮑﻬﺎﯾﯽ ﮐﻪ در اﯾﻦ ﺻﻔﺤﺎت درج ﺷـﺪه اﻧـﺪ،‬ ‫ﺑﺴﯿﺎر راﺣﺖ و ﮐﺎرآ ﻣﯽﺑﺎﺷﺪ.‬‫‪ EMMA‬ﻫﻢ ﻣﯽﺗﻮاﻧﺪ از ﻓﺎﯾﻠﻬﺎي ‪ .class‬ﺑﻌﻨـﻮان ورودي اﺳـﺘﻔﺎده ﻧﻤﺎﯾـﺪ و ﻫـﻢ ﻣـﯽﺗﻮاﻧـﺪ از ﻓﺎﯾﻠﻬـﺎي ‪.jar‬‬ ‫اﺳﺘﻔﺎده ﻧﻤﺎﯾﺪ.‬ ‫ﻻزم ﺑﻪ ذﮐﺮ اﺳﺖ ﮐﻪ ‪ ،EMMA‬ﺑﻄﻮر ﮐﺎﻣﻞ ﺑﻪ زﺑﺎن ﺟﺎوا ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ.‬ ‫ﺑﻌﻨﻮان ﻣﺜﺎل، ﺑﺮﻧﺎﻣﻪ زﯾﺮ را ﮐﻪ ﺷﺎﻣﻞ دو ﮐﻼس ‪ Circle‬و ‪ Test‬ﻣﯽﺑﺎﺷﺪ در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ.‬ ‫‪Circle.jva‬‬ ‫‪Test.java‬‬ ‫{ ‪public class Circle‬‬ ‫;‪private int r‬‬ ‫{ ‪public class Test‬‬ ‫{ )‪public Circle(int r‬‬ ‫][‪public static void main(String‬‬ ‫;)‪setR(r‬‬ ‫{ )‪args‬‬ ‫}‬ ‫;)01(‪Circle c = new Circle‬‬ ‫{ )‪public void setR(int r‬‬ ‫;‪if ( r < 0 ) r = -r‬‬ ‫}‬ ‫;‪this.r = r‬‬ ‫}‬ ‫}‬ ‫{ )(‪public int getR‬‬
    • ٣٢ return r; } }‫ ﻣﯽدﻫﯿﻢ ﺗﺎ ﺑﺮﻧﺎﻣﻪ را اﺟﺮا ﻧﻤﺎﯾﺪ و ﮔـﺰارش‬EMMA ‫ را ﺑﻪ‬Test.class ‫ﭘﺲ از ﮐﺎﻣﭙﺎﯾﻞ اﯾﻦ دو ﮐﻼس، ﻓﺎﯾﻞ‬‫ﻣﯿﺰان ﭘﻮﺷﺶ ﺑﺮﻧﺎﻣﻪ را ﺗﻮﻟﯿﺪ ﻧﻤﺎﯾﺪ. ﺑﻄﻮر ﭘﯿﺶ ﻓﺮض، ﮔﺰارش ﺗﻮﻟﯿﺪي در ﻗﺎﻟﺐ ﯾﮏ ﻓﺎﯾﻞ ﻣﺘﻨﯽ ﺳﺎده ﻧﻮﺷﺘﻪ‬ .‫ﻣﯽﺷﻮد. ﮐﻪ ﻧﻤﻮﻧﻪ آن در زﯾﺮ ﻧﻤﺎﯾﺶ داده ﺷﺪه اﺳﺖ‬ [EMMA v2.0.5312 report, generated Mon Jul 14 18:59:40 IRDT 2008]----------------------------------------------------------------------------- -- OVERALL COVERAGE SUMMARY: [class, %] [method, %] [block, %] [line, %] [name] 100% (2/2) 60% (3/5)! 67% (18/27)! 74% (7.4/10)! all classes OVERALL STATS SUMMARY: total packages: 1 total classes: 2 total methods: 5 total executable files: 2 total executable lines: 10 COVERAGE BREAKDOWN BY PACKAGE: [class, %] [method, %] [block, %] [line, %] [name] 100% (2/2) 60% (3/5)! 67% (18/27)! 74% (7.4/10)! default package----------------------------------------------------------------------------- --‫ اﯾﺠﺎد ﻧﻤﺎﯾﯿﻢ، ﻧﺘﯿﺠﻪ ﺷﺒﯿﻪ آن ﭼﯿـﺰي ﺧﻮاﻫـﺪ ﺑـﻮد ﮐـﻪ در ﺗـﺼﻮﯾﺮ زﯾـﺮ‬html ‫اﮔﺮ ﮔﺰارش را در ﻗﺎﻟﺐ ﻓﺎﯾﻞ‬ .‫ﻧﻤﺎﯾﺶ داده ﺷﺪه اﺳﺖ‬
    • ‫٣٣‬ ‫ﺷﮑﻞ 4-2- ﻗﺎﻟﺐ ‪ HTML‬ﺑﺮاي ‪EMMA‬‬‫در اﯾﻦ ﻣﺜﺎل، ﮔﺰارش ‪ EMMA‬ﺑﯿﺎن ﻣﯽﮐﻨﺪ ﮐﻪ از دو ﮐﻼس ﻣﻮﺟﻮد در ﺑﺮﻧﺎﻣﻪ، ﻫﺮ دو ﮐﻼس ﻣﻮرد اﺳﺘﻔﺎده‬‫ﻗﺮار ﮔﺮﻓﺘﻪ اﻧﺪ، اﻣﺎ از ﻣﺘﺪﻫﺎي ﻣﻮﺟﻮد در اﯾﻦ ﮐﻼﺳﻬﺎ، در ﻣﺠﻤﻮع 3 ﻣﺘﺪ از ﺑﯿﻦ 5 ﻣﺘﺪ ﻣﻮرد اﺳـﺘﻔﺎده ﻗـﺮار‬‫ﮔﺮﻓﺘﻪ اﻧﺪ. ﻻزم ﺑﻪ ﺗﻮﺿﯿﺢ اﺳﺖ ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﺑﺎ اﺟﺮاي ﻣﺘﺪ ‪ ،main‬اﺟﺮا ﻣﯽﺷﻮد و ﺳﭙﺲ ﺑﺮ اﺛﺮ اﯾﺠﺎد ﯾﮏ ﺷﯽء‬‫از ﮐﻼس ‪ ،Circle‬ﻣﺘﺪ ﺳﺎزﻧﺪه اﯾﻦ ﮐﻼس ﻓﺮاﺧﻮاﻧﯽ ﻣﯽﺷﻮد ﮐﻪ در درون آن ﻧﯿﺰ ﻣﺘﺪ ‪ setR‬ﻓﺮاﺧﻮاﻧﯽ ﺷـﺪه‬‫اﺳﺖ. ﺑﻨﺎﺑﺮاﯾﻦ در ﻣﺠﻤﻮع، 3 ﻣﺘﺪ اﺟﺮا ﺷﺪه اﻧﺪ. اﻣﺎ ﻋﻠﺖ اﯾﻨﮑﻪ ﭼـﺮا ‪ ،EMMA‬ﺗﻌـﺪاد ﻣﺘـﺪﻫﺎي ﻣﻮﺟـﻮد در‬‫ﺑﺮﻧﺎﻣﻪ را 5 ﻣﺘﺪ اﻋﻼم ﻣﯽﮐﻨﺪ، آن اﺳﺖ ﮐﻪ در ﺟﺎوا اﮔﺮ ﺑﺮاي ﯾﮏ ﮐـﻼس ﻣﺘـﺪ ﺳـﺎزﻧﺪه اي اﯾﺠـﺎد ﻧﮑﻨـﯿﻢ،‬‫ﮐﺎﻣﭙﺎﯾﻠﺮ ﺑﻄﻮر ﺧﻮدﮐﺎر، ﯾﮏ ﻣﺘﺪ ﺳﺎزﻧﺪه ﭘﯿﺶ ﻓﺮض ﺑﺮاي ﮐﻼس ﺗﻌﺮﯾﻒ ﻣﯽﮐﻨﺪ ﮐﻪ ﮐﺎر ﺧﺎﺻﯽ ﻫـﻢ اﻧﺠـﺎم‬‫ﻧﻤﯽدﻫﺪ. در ﻣﺜﺎل ﻓﻮق، در ﺗﻌﺮﯾﻒ ﮐﻼس ‪ ،Test‬ﻫﯿﭻ ﺳﺎزﻧﺪه اي ﺗﻌﺮﯾﻒ ﻧﮑﺮده اﯾﻢ. ﺑﻨﺎﺑﺮاﯾﻦ ﮐﺎﻣﭙـﺎﯾﻠﺮ ﯾـﮏ‬‫ﻣﺘﺪ ﺳﺎزﻧﺪه ﭘﯿﺶ ﻓﺮض ﺑﺮاي ﮐﻼس اﯾﺠﺎد ﮐﺮده اﺳﺖ و ‪ ،EMMA‬در ﺷﻤﺎرش ﻣﺘﺪﻫﺎ، آن ﻣﺘـﺪ را ﻫـﻢ ﺑـﻪ‬ ‫ﺣﺴﺎب آورده اﺳﺖ.‬‫ﻣﻮاردي ﻧﻈﯿﺮ ﻣﻮرد ﻓﻮق، )ﺗﻌﺪاد ﻣﺘﺪﻫﺎي ﺑﺮﻧﺎﻣﻪ(، ﻣﻤﮑﻦ اﺳﺖ ﺑﻌﻨـﻮان ‪ False Positive‬ﻫـﺎي ‪ EMMA‬ﺑـﻪ‬ ‫ﺣﺴﺎب آﯾﻨﺪ ﮐﻪ اﻟﺒﺘﻪ ﺑﺎ ﮐﻤﯽ دﻗﺖ ﻣﯽﺗﻮان ﺗﻮﺟﯿﻪ ﻓﻨﯽ آﻧﻬﺎ را ﻧﯿﺰ درك ﻧﻤﻮد.‬
    • ‫٤٣‬‫در ﻣﺠﻤﻮع، ‪ ،EMMA‬ﺑﻌﻨﻮان ﯾﮏ اﺑﺰار ﺑﺮاي ﺗﺴﺖ ﭘﻮﺷﺶ ﺑﺮﻧﺎﻣﻪ ﻫـﺎي ﺟـﺎوا اﺑـﺰار ﻣﻨﺎﺳـﺐ و ﻗﺪرﺗﻤﻨـﺪي‬ ‫ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﻣﺰﯾﺖ ﻣﻬﻢ آن، ﻋﺪم ﻧﯿﺎز ﺑﻪ ﻣﺘﻦ ﮐﺪ ﺑﺮﻧﺎﻣﻪ، و ﻫﻤﭽﻨﯿﻦ ﺳﺮﻋﺖ ﺑﺎﻻي آن ﻣﯽﺑﺎﺷﺪ. ]‪[emma‬‬ ‫‪Testing Framework based on .NET‬‬‫در اﯾﻦ ﭼﺎرﭼﻮب ﻫﺪف ﺗﻮﺳﻌﻪ ﯾﮏ اﺑﺰار ﺗﺴﺖ ﻧﺮماﻓﺰاري ﮐﺎﻣﻼً اﺗﻮﻣـﺎت ﺷـﺪه اﺳـﺖ. اﯾـﻦ اﺑـﺰار ‪test script‬‬‫ﻫﺎﯾﯽ ﺑﺮاي ﺗﺴﺖ واﺣﺪ )‪ ، (unit testing‬ﺗـﺴﺖ ﯾﮑﭙـﺎرﭼﮕﯽ )‪ (integration testing‬و ‪regression testing‬‬ ‫اﯾﺠﺎد ﻣﯽﮐﻨﺪ.‬‫اﺑﺰار ﺗﺴﺖ ﺑﺎﯾﺪ ﮐﺎرﻫﺎي ﺗﺴﺖ را، از ﺗﻮﻟﯿﺪ اﺳﮑﺮﯾﭙﺖﻫﺎي ﺗﺴﺖ، اﯾﺠﺎد ‪ test case‬ﻫﺎ، اﻋﻼم ﻧﺘﺎﯾﺞ ، و ﺗﺼﺤﯿﺢ‬ ‫ﺑﺎگﻫﺎ را اﻧﺠﺎم دﻫﺪ.‬‫ﻫﺪف در اﺑﺰار ﺗﺴﺘﯽ ﮐﻪ ﺑﺮ اﺳﺎس ‪ .NET Framework‬اﺳﺖ ،ﻧﺸﺎن دادن راﻫﯽ اﺳﺖ ﮐﻪ ﺑﺘﻮان ﯾـﮏ اﺑـﺰار‬‫ﺗﺴﺖ را ﺑﺼﻮرت اﺗﻮﻣﺎت اﯾﺠﺎد و ﺗﻮﺳﻌﻪ داد. ﻣﺮاﺣﻞ وﯾﺮاﯾﺶ داده ﻫﺎ ﮐﺎﻫﺶ ﻣﯽﯾﺎﺑﺪ و ﯾﮏ اﺳـﮑﺮﯾﭙﺖ ﺑـﺮاي‬‫ﺗﺴﺖ ﮐﻞ ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي اﯾﺠﺎد ﻣﯿﺸﻮد.و ﺷﻤﺎ ﻣﺠﺒﻮر ﻧﺨﻮاﻫﯿﺪ ﺑﻮد اﺳﮑﺮﯾﭙﺖ ﻫﺎي ﺗﺴﺖ را ﺑﺼﻮرت دﺳـﺘﯽ‬‫وﯾﺮاﯾﺶ و ﺧﻄﺎ ﯾﺎﺑﯽ ﮐﻨﯿﺪ. ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ ﺑﻪ ﺳﺎدﮔﯽ ﯾﮏ ﺑﺮﻧﺎﻣﻪ را ﻣﯿﭙﺬﯾﺮد و ﻧﺘﺎﯾﺞ ﺗـﺴﺖ را ﺑـﻪ ﺷـﻤﺎ ﺑـﺎز‬ ‫ﻣﯿﮕﺮداﻧﺪ.‬‫در ‪.NET Framework‬ﻣﯿﺘﻮان اﺑﺰار اﺗﻮﻣﺎت ﺗﺴﺖ ﺑﺴﯿﺎر ﻗﻮي ﺑﺮاي ﺗﺴﺖ ﯾﮏ ﻣﺤﺼﻮل ﭘﯿﭽﯿﺪه ﻧﺮماﻓﺰاري ﺑﺎ‬‫ﮐﻤﺘﺮﯾﻦ ﻣﯿﺰان دﺧﺎﻟﺖ اﻧﺴﺎن داﺷﺖ. اﮔﺮﭼﻪ زﺑﺎن ﺑﺤﺚ ﺷﺪه در اﯾﻨﺠﺎ #‪ C‬اﺳﺖ وﻟﯽ ﺑـﻪ ﻣﻌﻨـﺎي ﺗﻤﺠﯿـﺪ از‬‫ﻣﺤﺼﻮﻻت ﻣﺎﯾﮑﺮوﺳﺎﻓﺘﯽ و اﻧﺘﻘﺎد از ﺳﺎﯾﺮ ﻣﺤﯿﻂ ﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ و ‪ framework‬ﻫﺎ ﻧﯿﺴﺖ و ﻣﺘـﺪﻟﻮژي‬‫اراﺋﻪ ﺷﺪه در اﯾﻦ اﯾﻨﺠﺎ ﻗﺎﺑﻞ ﺗﻌﻤﯿﻢ ﺑﻪ ﺳﺎﯾﺮ ﻣﺤﯿﻂ ﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ و ‪ framework‬ﻫﺎ ﻧﯿﺰ ﻫﺴﺖ. ‪java‬و‬ ‫‪ .NET‬ﻣﺤﯿﻂ ﻫﺎي ﮐﺎﻣﻼ ﺷﯽ ﮔﺮا وﺑﺮاي ﺗﮑﻤﯿﻞ ﭘﺮوژه ﻫﺎي اﺑﺰار ﻫﺎي ﺗﺴﺖ اﺳﺖ.‬‫ﺑﺎ اﺑﺰارﻫﺎ ي اﺗﻮﻣﺎت ﺗﺴﺖ ﻧﺮماﻓﺰاري ﻓﺮاﻫﻢ ﺷﺪه در ‪ NETFramework‬ﻧﯿﺎزي ﺑﻪ ﻧﻮﺷﺘﻦ دﺳـﺘﯽ اﺳـﮑﺮﯾﭙﺖ‬ ‫ﻫﺎي ﺗﺴﺖ و ﯾﺎ ﺿﺒﻂ ﺳﻨﺎرﯾﻮ ﻫﺎي ﺗﺴﺖ ﻧﯿﺴﺖ و اﯾﻦ اﺑﺰار ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻣﺠﺪد اﺳﺖ .‬ ‫اﺑﺰار ﻣﻌﺮﻓﯽ ﺷﺪه در ‪ .net framework‬ﺑﺮاي اﺗﻮﻣﺎت ﮐﺮدن ﺗﺴﺖ ﻧﺮماﻓﺰار ﻗﺎﺑﻠﯿﺖ ﻫﺎي زﯾﺮ را دارد.‬
    • ‫٥٣‬ ‫ﺑﺼﻮرت دﯾﻨﺎﻣﯿﮏ اﺳﻤﺒﻠﯽ62 ﺗﺤﺖ ﺗﺴﺖ را ﯾﺎد ﻣﯿﮕﯿﺮد.‬ ‫ﺑﺼﻮرت دﯾﻨﺎﻣﯿﮏ ﮐﺎرﻫﺎي ﺳﺨﺖ و ﺧﺴﺘﻪ ﮐﻨﻨﺪه را اﻧﺠﺎم ﻣﯿﺪﻫﺪ.‬ ‫اﯾﺠﺎد و اﺟﺮاي ‪ test script‬ﻫﺎ ﺑﺼﻮرت ﺑﺮﻧﺎﻣﻪ رﯾﺰي ﺷﺪه‬ ‫راﺑﻂ ﻫﺎي اﺷﯿﺎي ‪ COM‬و ﺳﺎﯾﺮ ﮐﺎﻣﭙﻮﻧﻨﺘﻬﺎي ﻧﺮماﻓﺰاري را ﺑﺎ ﯾﮏ ﻣﺠﻤﻮﻋﻪ داده ﻣﺸﺨﺺ ﺗﺴﺖ ﻣﯿﮑﻨﺪ.‬ ‫ﺑﺮاي ﺗﺴﺖ ﺻﺤﺖ ﻧﺘﺎﯾﺞ ﺗﺴﺖ ﺑﻪ ﯾﮏ ﭘﺎﯾﮕﺎه داده دﺳﺘﺮﺳﯽ دارد.‬ ‫ﺑﻪ رﺟﯿﺴﺘﺮي وﯾﻨﺪوز ﺑﺮاي اﻃﻤﯿﻨﺎن از ﺻﺤﺖ ﻧﺘﺎﯾﺞ دﺳﺘﺮﺳﯽ دارد.‬‫ﺑﺎ ﺗﺮﮐﯿﺐ دو ﻓﻀﺎي ﻧﺎم ‪Reflection‬و ‪ CodeDom‬ﻗﺎدر ﺧﻮاﻫﯿﻢ ﺑﻮد ﻓﺮاﯾﻨﺪ ﺟﻤﻊ اوري اﻃﻼ ﻋﺎت و ﻧﻮﺷـﺘﻦ‬ ‫اﺳﮑﺮﯾﭙﺘﻬﺎي ﺗﺴﺖ را ﺑﺎ ﺣﺪاﻗﻞ دﺧﺎﻟﺖ اﻧﺴﺎﻧﯽ اﻧﺠﺎم دﻫﯿﻢ.‬‫ﻓﻀﺎي ﻧﺎم ‪ Reflection‬ﻣﯿﺘﻮاﻧﺪ ﯾﮏ اﺳﻤﺒﻠﯽ ﺧﺎص را ﺑﺎزﻧـﺸﺎﻧﯽ ﮐﻨـﺪ.و ان را ﺑـﻪ ﮐﻼﺳـﻬﺎ و ﺗﻮاﺑـﻊ ﻋـﻀﻮ و‬‫‪ property‬ﻫﺎ ﺗﺠﺰﯾﻪ ﻣﯿﮑﻨﺪ . ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺼﻮرت اﺗﻮﻣﺎﺗﯿﮏ ﻓﺮاﯾﻨﺪ ﺟﻤﻊ اوري اﻃﻼﻋﺎت را اﻧﺠﺎم ﻣﯿﺪﻫـﺪ.و اﯾـﻦ‬ ‫ﻓﺮاﯾﻨﺪ در واﻗﻊ ﻣﺸﺎﺑﻪ ﻓﺮاﯾﻨﺪ ﯾﺎدﮔﯿﺮي و ﺷﻨﺎﺧﺖ ﻣﻬﻨﺪﺳﺎن ﺗﺴﺖ از ﺑﺮﻧﺎﻣﻪ اﺳﺖ.‬‫ﻓﻀﺎي ﻧﺎم ‪ CodeDom‬ﻣﯿﺘﻮاﻧﺪ اﺳﮑﺮﯾﭙﺘﻬﺎي ﺗﺴﺖ را ﺑﺼﻮرت دﯾﻨﺎﻣﯿﮏ ﺑﺮ اﺳﺎس اﻃﻼﻋـﺎت ﺑﺪﺳـﺖ اﻣـﺪه از‬ ‫ﻓﺮاﯾﻨﺪ ﻓﻮق ﺑﻨﻮﯾﺴﺪ.‬‫ﭘﺮوژه ‪ automated test‬ﻧﯿﺎز ﺑﻪ ﻓﻀﺎﯾﯽ ﺑﺮاي ذﺧﯿﺮه داده ﻫﺎي ﻣﺮﺑﻮط ﺑﻪ ﺗﺴﺖ ﮐﺎﻣﭙﻮﻧﻨﺖ ﻫﺎ دارد.اﯾـﻦ داده‬‫ﻫﺎ ﺷﺎﻣﻞ ﻧﺎم ﮐﻼﺳﻬﺎي ﯾﮏ اﺳﻤﺒﻠﯽ،ﺳﺎزﻧﺪه ﻫﺎ،ﻧﺎم ﺳﺎﯾﺮ اﻋﻀﺎي ﮐﻼس ، ﻣﻘﺎدﯾﺮ ﭘﺎراﻣﺘﺮﻫﺎي ﺗﻮاﺑﻊ و ﺳـﺎزﻧﺪه‬‫ﻫﺎ ﺳﺖ.از ‪ xml , excel‬ﺑﺮاي ﻗﺎﺑﻠﯿﺖ وﯾﺮاﯾﺶ داده ﻫﺎ اﺳﺘﻔﺎده ﻣﯿﮑﻨﯿﻢ و ‪ MS Excel API‬ﻫﺎي ﻗﺎﺑﻞ ﺑﺮﻧﺎﻣﻪ‬‫رﯾﺰي اﻧﻌﻄﺎف ﭘﺬﯾﺮي زﯾﺎدي ﺑﺮاي ﺗﺴﺖ ﮐﻨﻨﺪﮔﺎن ﻓﺮاﻫﻢ ﻣﯿﮑﻨﺪ ﺗﺎ داده ﻫﺎي ﺗﺴﺖ را ﺳﺎزﻣﺎن دﻫﯽ ﮐﻨﻨـﺪ و‬‫ﻣﯿﺘﻮان ﺑﺮاي ﻧﻮﺷﺘﻦ اﺳﮑﺮﯾﭙﺘﻬﺎي ﺗﺴﺖ )ﮐﻪ داده ﻫﺎي ﺗﺴﺖ را ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﺗﺴﺖ ﻣﯿﮑﻨﻨﺪ( و ذﺧﯿﺮه ﻧﺘـﺎﯾﺞ‬ ‫ﺑﻪ ﮐﺎر ﺑﺮد. داده ﻫﺎي ﺗﺴﺖ و ﻧﺘﺎﯾﺞ ﺗﺴﺖ ﺑﺎ ‪ xml‬و ‪ excel‬ﻧﻤﺎﯾﺶ داده ﻣﯿﺸﻮﻧﺪ.‬‫‪، .EXE‬ﺑﺎ ﻧﺎم اﺳﻤﺒﻠﯽ ﺷﻨﺎﺧﺘﮫ ﻣﯿﺸﻮﻧﺪ.ﯾﮏ اﺳﻤﺒﻠﯽ ﻣﯿﺘﻮاﻧﺪ ﺷﺎﻣﻞ ﯾﮏ ﯾﺎ ﭼﻨﺪ ﻣﺎژول ﻣﺜﻞ ﻓﻀﺎھﺎی‬ ‫62 در دﻧﯿﺎی ‪ .NET‬ﺑﺮﻧﺎﻣﮫ ھﺎی ﻓﯿﺰﯾﮑﯽ ﮐﺎﻣﭙﺎﯾﻞ ﺷﺪه ﻣﺜﻞ ﻓﺎﯾﻠﮭﺎی ‪, .dll‬‬ ‫ﻧﺎم و ﯾﺎ ﮐﻼﺳﮭﺎ ﺑﺎﺷﻨﺪ.‬
    • ‫٦٣‬‫ﭘﺮوﻧﺪه ﻫﺎي ‪ xml‬ﺑﺮاي ذﺧﯿﺮه و ﺗﺒﺎدل داده ﻫﺎ ﯾﮏ اﺳﺘﺎﻧﺪارد ﻫﺴﺘﻨﺪ. ﺑـﺎ اﺿـﺎﻓﻪ ﮐـﺮدن ﯾﺎدداﺷـﺖ ﻫـﺎي‬‫ﻣﺴﺘﻨﺪ ﺳﺎزي ‪ xml‬در ﻣﺤﯿﻂ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ #‪ ، C‬ﻣﯿﺘﻮان ﯾﮏ ‪ help document‬درﺳﺖ ﮐﺮد.اﮔﺮ در ﻫﻨﮕﺎم‬ ‫ﻧﻮﺷﺘﻦ ﯾﮏ ﺗﺎﺑﻊ ﺑﺘﻮان ﯾﮏ ﻣﻮرد ﺗﺴﺖ ﻃﺮاﺣﯽ ﮐﺮد ﺑﺴﯿﺎر ﺧﻮب اﺳﺖ.‬‫در ﮐﻨﺎر ﺗﻮاﺑﻊ ﮐﻼس اﺳﻤﺒﻠﯽ ﺑﺮاي ﮐﺸﻒ ﻧﻮع در زﻣﺎن اﺟـﺮا ، ﻓـﻀﺎي ﻧـﺎم ‪ system.reflection‬ﺗـﺴﻬﯿﻼت‬‫دﯾﮕﺮي ﻧﯿﺰ ﻓﺮاﻫﻢ ﻣﯽآورد.ﺑﺎ ‪ Late binding‬ﻣﯿﺘـﻮان ﯾـﮏ ﻣﺘـﺪ را ﺑـﺎ ﭘﺎراﻣﺘﺮﻫـﺎي دﻟﺨـﻮاه در زﻣـﺎن اﺟـﺮا‬ ‫ﻓﺮاﺧﻮاﻧﯽ ﮐﺮد. ﺑﺎ ﺷﻨﺎﺳﺎﯾﯽ ﺣﻀﻮر ﯾﮏ ‪ ،type‬ﻣﯿﺘﻮان ﺑﺼﻮرت دﯾﻨﺎﻣﯿﮏ ﻫﺮ ﺗﺎﺑﻌﯽ را ﻓﺮاﺧﻮاﻧﯽ ﮐﺮد .‬ ‫ﻓﻀﺎي ﻧﺎم ‪.NET CodeDOM‬‬‫ﻫﺪف اﺻﻠﯽ ﺗﺴﺖ ﻧﺮماﻓﺰار ﻧﻮﺷﺘﻦ ‪TestScript‬اي اﺳﺖ ﮐﻪ ﺗﻤﺎﻣﯽ ﮐﻼسﻫﺎ، ﻣﺘﺪﻫﺎ و ﺧﺼﻮﺻﯿﺖﻫـﺎي ﯾـﮏ‬‫اﺳﻤﺒﻠﯽ را ﺗﺴﺖ ﻧﻤﺎﯾﺪ. ﻫﺴﺘﻪ ي اﺑﺰار ﺗﺴﺖ اﺗﻮﻣﺎﺗﯿﮏ ﻣﺎ ﻣﮑﺎﻧﯿﺰم ﺧﻮدﮐﺎري اﺳﺖ ﮐﻪ ﮐﺎرﻫﺎي زﯾـﺮ را اﻧﺠـﺎم‬ ‫ﻣﯽدﻫﺪ:‬ ‫ﯾﺎﻓﺘﻦ ﮐﻼسﻫﺎ، ﻣﺘﺪﻫﺎ و ﺧﺼﻮﺻﯿﺖﻫﺎ در اﺳﻤﺒﻠﯽ ﺗﺤﺖ ﺗﺴﺖ‬ ‫ﺗﻌﺮﯾﻒ ﻣﻮرد ﺗﺴﺖﻫﺎﯾﯽ ﻣﺒﺘﻨﯽ ﺑﺮ ﻣﺎﻫﯿﺖ اﺳﻤﺒﻠﯽ‬ ‫ﻧﻮﺷﺘﻦ ‪TestScript‬اي ﮐﻪ ﮐﺎر ﺗﺴﺖ را اﻧﺠﺎم ﻣﯽدﻫﺪ‬ ‫اﺟﺮاي ‪TestScript‬‬ ‫ﻧﻤﺎﯾﺶ ﻧﺘﺎﯾﺞ ﺗﺴﺖ‬ ‫اﺳﺘﻔﺎدهي ﻣﺠﺪد از اﺳﻤﺒﻠﯽ ‪ ،TestScript‬ﺑﺮاي ﺗﺴﺖ ‪ Regression‬و ‪Integration‬‬‫ﯾﮑﯽ از ﻣﻮارد اﺳﺘﻔﺎدهي ﻣﺮﺳﻮم ﻓﻀﺎي ﻧﺎم ‪ CodeDOM‬ﺑﺮاي اﯾﺠﺎد اﺗﻮﻣﺎﺗﯿـﮏ ﮐـﺪ ﻣﻨﺒـﻊ )اﺻـﻠﯽ ( اﺳـﺖ.‬‫ﻫﺪف اﯾﻦ ﺗﻮﻟﯿﺪﮐﻨﻨﺪهﻫﺎي ﮐﺪ اﯾﻦ اﺳﺖ ﮐﻪ ﮐﺎرﻫﺎي ﮐﺪﯾﻨﮓ را ﮐﻤﺘﺮ ﻧﻤﺎﯾﺪ. وﻗﺘﯽ اﯾﻦ ﺑﺮﻧﺎﻣﻪ اﺟﺮا ﻣﯽﺷـﻮد،‬ ‫ﻣﯽﺗﻮاﻧﺪ ﺑﺮﻧﺎﻣﻪي دﯾﮕﺮي را در ﮐﺴﺮي از ﺛﺎﻧﯿﻪ ﺗﻮﻟﯿﺪ ﮐﻨﺪ.‬
    • ‫٧٣‬‫ﻓﻀﺎي ﻧﺎم ‪ CodeDom‬ﻗﺎﺑﻠﯿﺖ ﺳﺎﺧﺖ ﺑﺮﻧﺎﻣﻪﻫﺎﯾﯽ را دارد ﮐﻪ در زﻣﺎن اﺟﺮا ﮐﺪﻫﺎﯾﯽ ﺑﻪ زﺑـﺎنﻫـﺎي ﻣﺨﺘﻠـﻒ‬‫ﺗﻮﻟﯿﺪ ﮐﻨﺪ. اﯾﻦ ﻓﻀﺎي ﻧﺎم داراي ‪ Type‬ﻫﺎﯾﯽ اﺳﺖ ﮐﻪ ﺳﺎﺧﺘﺎر ﺑﺮﻧﺎﻣﻪ را ﻣﺸﺨﺺ ﻣﯽﮐﻨﺪ و ﻣﺴﺘﻘﻞ از زﺑـﺎن‬‫ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﺟﺎري اﺳﺖ. زﺑﺎنﻫﺎي ﻣﻌﻤﻮﻟﯽ ﮐﻪ ‪ CodeDom‬ﺗﻮﻟﯿﺪ ﻣﯽﮐﻨـﺪ، ‪ C#.NET‬و ‪ VB.NET‬اﺳـﺖ.‬‫ﻋﻼوه ﺑﺮ اﯾﻦ ‪ CodeDom‬اﻧﻮاﻋﯽ را ﺑﺮاي ﮐﺎﻣﭙﺎﯾﻞ ﮐﺪ ﺑﺮﻧﺎﻣﻪ در زﻣﺎن اﺟﺮا دارد ﮐﻪ ﺑﺎ اﺳﺘﻔﺎده از آﻧﻬﺎ ﺗـﺴﺖ‬ ‫ﻧﺮماﻓﺰار را ﭘﺮدازﺷﯽ ﮐﺎﻣﻼً ﺧﻮدﮐﺎر ﻣﯽﮐﻨﯿﻢ.‬‫ﻓﻀﺎي ﻧﺎم ‪Source code ،CodeDom‬اي را ﺑﺮ اﺳﺎس ﯾﮏ ﻣﺪل واﺣﺪ اﯾﺠﺎد ﻣﯽﮐﻨﺪ. ﺑﻨﺎﺑﺮاﯾﻦ ‪Source code‬‬‫ﻣﯽﺗﻮاﻧﺪ ﺑﻪ ﻫﺮ زﺑﺎﻧﯽ ﮐﻪ ﻣﺸﺨﺼﺎت ‪ CodeDom‬را ﺣﻤﺎﯾﺖ ﻣﯽﮐﻨﺪ، ﺗﻮﻟﯿﺪ ﺷﻮد. اﯾﻦ ﻓﻀﺎي ﻧﺎم ﯾﮏ ﻧﻤـﺎﯾﺶ‬ ‫در ﻣﻮد ﺷﯽ ﮐﻪ ﻣﺴﺘﻘﻞ از زﺑﺎن اﺳﺖ، ﺑﺮاي ﺳﺎﺧﺘﺎر ﮐﺪي ﮐﻪ در ﺣﺎﻓﻈﻪ اﺳﺖ اراﺋﻪ ﻣﯽدﻫﺪ. ]‪[sybex‬‬ ‫‪Push To Test Test Maker‬‬‫‪ Push to test‬ﯾﮏ ﭼﺎرﭼﻮب ﮐﺪ ﺑﺎز ﺑﺮاي ﺧﻮدﮐﺎر ﺳﺎزي ﺗﺴﺖ ﺗﻮﺳﻂ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﺎن ﻧﺮماﻓﺰار و ﻣﺪﯾﺮان ‪ IT‬و‬‫ﺑﺎزرﺳﺎن ﮐﻨﺘﺮل ﮐﯿﻔﯿﺖ اﺳﺖ ﺗﺎ ﺑﺘﻮاﻧﻨﺪ ﺳﯿﺴﺘﻢ ﻫﺎي اﻃﻼﻋﺎﺗﯽ را ﺗﺴﺖ و ﮐﻨﺘـﺮل و ﻫـﺪاﯾﺖ ﮐﻨﻨـﺪ. ﺑﺮﻧﺎﻣـﻪ‬ ‫ﻧﻮﯾﺴﺎن ﺑﺮاي ﺗﺒﺪﯾﻞ ﺗﺴﺘﻬﺎي واﺣﺪ ﺑﻪ ﺗﺴﺖ ﻋﻤﻠﮑﺮد از ‪ push to test‬اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ.‬ ‫‪ Push to test‬ﯾﮏ ﻣﺤﯿﻂ ﻏﻨﯽ ﺑﺮاي اﯾﺠﺎد ﺗﺴﺖ ﻫﺎي واﺣﺪ اراﺋﻪ ﻣﯽدﻫﺪ. از ﺟﻤﻠﻪ :‬ ‫‪ ‬ﻣﺤﯿﻂ ﮔﺮاﻓﯿﮑﯽ راﺣﺖ ﺑﺮاي ﮐﺎرﺑﺮ اﯾﺠﺎد ﻣﯽﮐﻨﺪ.‬‫‪ ‬زﺑﺎنﻫﺎي اﺳﮑﺮﯾﭙﺖ ﻧﻮﯾﺴﯽ ﺷـﯽ ﮔـﺮا ﻣﺜـﻞ ‪ java , jython‬ﺑـﺮاي اﯾﺠـﺎد اﺳـﮑﺮﯾﭙﺘﻬﺎي ﺗـﺴﺖ،اراﺋﻪ‬ ‫ﻣﯽﮐﻨﺪ.‬‫‪ ‬ﮐﺘﺎﺑﺨﺎﻧﻪ اي ﻗﺎﺑﻞ ﮔﺴﺘﺮش از ‪ protocol handler‬ﻫﺎ . ﺷﺎﻣﻞ ﭘﯿﺎده ﺳـﺎزيﻫـﺎﯾﯽ ﻗﺎﺑـﻞ اﺳـﺘﻔﺎده از‬ ‫, ‪http , https , soap , rest , xml-rpc , smtp , pop3 , imap‬وب ﺳﺮوﯾﺴﻬﺎ .‬‫‪ ‬وﯾﺰارد ﻫﺎﯾﯽ ﺑﺮاي اﯾﺠﺎد ﯾﮏ ﻋﺎﻣﻞ ﺟﺪﯾﺪ، از ﺟﻤﻠﻪ ﻋﺎﻣﻞ ‪ recorder‬ﮐﻪ ﻣﯿﺘﻮاﻧـﺪ اﺳـﮑﺮﯾﭙﺖ ﺑـﺮاي‬ ‫ﺷﻤﺎ اﯾﺠﺎد ﮐﻨﺪ.‬
    • ‫٨٣‬ ‫‪ ‬ﮐﻨﺴﻮل ﺑﺮاي اﺟﺮاي ﻋﺎﻣﻞﻫﺎي ﺗﺴﺖ در ﯾﮏ ﻣﺤﯿﻂ ﺗﻮزﯾﻊ ﺷﺪه ﺗﺴﺖ.‬ ‫‪ ‬ﮐﺘﺎﺑﺨﺎﻧﻪاي از ﻋﺎﻣﻞﻫﺎي ﺗﺴﺖ ﻧﻤﻮﻧﻪ ﮐﺎﻣﻼً ﻋﻤﻠﯽ.‬‫وﯾﺰاردﻫﺎ و رﮐﻮردرﻫﺎﯾﯽ ﺑﺮاي اﯾﺠﺎد اﺗﻮﻣﺎﺗﯿﮏ ﺗﺴﺖﻫﺎ ﺑﺪون ﻧﻮﺷﺘﻦ ﮐـﺪﻫﺎي اﺳـﮑﺮﯾﭙﺖ ﺗـﺴﺖ وﺟـﻮد دارد.‬‫ﺑﺮاي ﺗﺴﺖﻫﺎﯾﯽ ﮐﻪ ﻧﯿﺎز ﺑﻪ اﺳﮑﺮﯾﭙﺖ ﻧﻮﯾﺴﯽ دارﻧﺪ، در ‪ push to test‬اﻣﮑﺎن اﺳﮑﺮﯾﭙﺖ ﻧﻮﯾﺴﯽ ﺑﺎ زﺑـﺎنﻫـﺎي‬‫ﻣﻬ ـﻢ از ﺟﻤﻠ ـﻪ …,‪ java, jython,Groovy, PHP,Ruby‬وﺟ ـﻮد دارد. ﻋ ـﻼوه ﺑ ـﺮ اﯾ ـﻦ از ﺳ ـﺮوﯾﺲﻫ ـﺎي‬ ‫ـ‬ ‫ـ‬ ‫ـ ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬ ‫ـ‬‫…,‪ SOA,webservice,ajax‬ﮐﻪ از ﭘﺮوﺗﮑﻞﻫﺎي ‪ http, https, soap, xml-rpc, telnet‬و ﭘﺮوﺗﮑﻞﻫﺎي اﯾﻤﯿﻞ‬‫اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ را، ﭘﺸﺘﯿﺒﺎﻧﯽ ﻣﯽﮐﻨﺪ. ﻣﺤﯿﻂ زﻣـﺎن اﺟـﺮاي ‪ push to test‬ﺑـﺼﻮرت ﺧﻮدﮐـﺎر ﺗـﺴﺖﻫـﺎي‬‫ﻋﻤﻠﮑﺮد واﺣﺪ را ﺑﻪ ﺗﺴﺖ ﺑﺎر و ﺗﺴﺖ ﻣﻘﯿﺎس ﭘﺬﯾﺮي وﺗـﺴﺖ ﮐـﺎراﯾﯽ و ﺗـﺴﺖ رﮔﺮاﺳـﯿﻮن و ﺗـﺴﺖ ﮐﻨﺘـﺮل‬ ‫ﺳﺮوﯾﺲ ﺗﺒﺪﯾﻞ ﻣﯽﮐﻨﺪ.‬‫ﺗﺴﺖﻫﺎﯾﯽ ﮐﻪ ﺑﻪ ﻋﻤﻠﮑﺮدﻫﺎﯾﯽ ﺑﺮاي ﺗﺴﺖ ﺑﺮﻧﺎﻣﻪﻫﺎي وب و وب ﺳﺮوﯾﺲﻫﺎي ‪ SOA‬و ﺳﯿﺴﺘﻢﻫﺎي ‪Email‬‬ ‫و ﺑﺮﻧﺎﻣﻪﻫﺎي ﺟﺎوا و ﺑﻘﯿﻪ ﻣﻨﺎﺳﺐ اﺳﺖ.‬‫ﺗﺴﺖ ﺑﺮﻧﺎﻣﻪ ﻫﺎي وب: در ﺑﺮﻧﺎﻣﻪ ﻫﺎي وب ﮐﺎرﺑﺮان ﺑﻪ ﻋﻤﻠﯿﺎﺗﯽ از ﻃﺮﯾﻖ ﻣﺮورﮔﺮ وب دﺳﺘﺮﺳﯽ دارﻧﺪ و در‬‫ﭼﺎرﭼﻮب ‪ push to test‬ﺗﮑﻨﻮﻟﻮژي ذﺧﯿﺮه و اﺟﺮاي ﻣﺠﺪد )‪(capture / playback‬ﺑﺮاي ﺗﺴﺖ اﯾﻦ ﺑﺮﻧﺎﻣﻪ ﻫـﺎ‬ ‫ﻋﺮﺿﻪ ﻣﯿﺸﻮد. ﺑﺮاي ﺑﺮﻧﺎﻣﻪ وب ‪ test agent‬ﯾﮏ ﮐﺎرﺑﺮ ﻣﺮورﮔﺮ وب اﺳﺖ.‬‫ﺗﺴﺖ وب ﺳﺮوﯾﺲ ﻫﺎ و )‪ : SOA(Service oriented architecture‬وب ﺳﺮوﯾﺲ ﻫﺎ و ‪ SOA‬ارﺗﺒﺎﻃﺎت‬‫‪ XML‬ﺑﯿﻦ ﺳﺮوﯾﺲ و ﺳﺮوﯾﺲ ﯾﺎ ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﺑﺮﻧﺎﻣﻪ را ﻋﺮﺿﻪ ﻣﯿﮑﻨﻨـﺪ. در ‪ push to test‬اﺑـﺰار ‪ soapUI‬زﺑـﺎن‬‫ﺗﻮﺻﯿﻒ ﯾﮏ وب ﺳﺮوﯾﺲ)‪ (WSDL‬را ﻣﯿﺨﻮاﻧﺪ و ﺗﺴﺖ ﻫﺎي واﺣﺪ و ﺗﺴﺖ ﻋﻤﻠﮑﺮد اﯾﺠﺎد ﻣﯿﮑﻨﺪ. ﺑـﺮاي وب‬‫ﺳﺮوﯾﺲ، ﺗﺴﺘﻬﺎ ﺑﻪ ﻧﻈﺮ ﺑﺮﻧﺎﻣﻪ ﯾﺎ ﺳﺮوري ﻫﺴﺘﻨﺪ ﮐﻪ درﺧﻮاﺳﺘﻬﺎ را اﯾﺠﺎد ﻣﯿﮑﻨﻨﺪ و ﻣﻨﺘﻈﺮ ﭘﺎﺳﺨﻬﺎ ﻣﯽﻣﺎﻧﻨﺪ.‬‫ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ‪ :email‬ﺳﯿﺴﺘﻢ ﻫﺎي ‪ email‬اﻣﮑﺎن دﺳﺘﺮﺳﯽ ﺑﻪ ﻣﮑﺎﻧﻬﺎي ذﺧﯿـﺮه ﺳـﺎزي ﭘﯿﺎﻣﻬـﺎي‬‫‪ email‬از ﻃﺮﯾﻖ ﻧﺮماﻓﺰار ﻫﺎي ‪ email client‬و ﭘﻮرﺗﺎل ﻫﺎي دﺳﺘﺮﺳـﯽ ﺑـﻪ ‪ email‬از ﻃﺮﯾـﻖ ﻣﺮورﮔـﺮ وب را‬‫ﻓﺮاﻫﻢ ﻣﯿﮑﻨﻨﺪ . در ‪ push to test‬ﺑﺮاي ارﺗﺒﺎط ﺑﺎ ﯾﮏ ﻣﮑﺎن ذﺧﯿﺮه ﺳﺎزي ﭘﯿﺎم از ‪ protocol handler‬ﻫـﺎي‬
    • ‫٩٣‬‫3‪ SMTP,IMAP,POP‬اﺳﺘﻔﺎده ﻣﯿﺸﻮد .و اﻟﺤﺎﻗﺎت ‪ MIME‬و رﻣﺰ ﻧﮕﺎري ‪ UTF‬و اﺣﺮاز ﻫﻮﯾﺖ را ﭘﺸﺘﯿﺒﺎﻧﯽ‬ ‫ﻣﯿﮑﻨﺪ .‬‫ﺗﺴﺖ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﺟﺎوا : در ‪ ، Push to test‬اﺳﮑﺮﯾﭙﺖ ﻫﺎي ‪، test agent‬ﻗﺎدرﻧﺪ ﻓﺮاﺧﻮاﻧﯽ ﻫﺎي ﺻـﺮﯾﺢ ﺑـﻪ‬ ‫ﺗﻮاﺑﻊ ﺑﺮﻧﺎﻣﻪ ﺟﺎواي ﺷﻤﺎ داﺷﺘﻪ ﺑﺎﺷﻨﺪ.‬ ‫ﺗﺴﺖ و ﺗﺼﺤﯿﺢ‬‫ﻣﺤﯿﻂ ﺗﺴﺘﯽ ﮐﻪ در ﺑﺨﺶ ﻫﺎي ﻗﺒﻠﯽ ﺗﻮﺻﯿﻒ ﺷﺪ ﭼﮕﻮﻧﮕﯽ اﺳﺘﻔﺎده از ﭼﺎرﭼﻮب و اﺑﺰار ﻫﺎي ﮐﻤﮑﯽ را ﺑﺮاي‬‫ﺳﺎﺧﺖ ﺗﺴﺘﻬﺎﯾﯽ ﮐﻪ رﮔﺮاﺳﯿﻮن و ﻋﻤﻠﮑﺮد و ﻣﻘﯿﺎس ﭘﺬﯾﺮي و ﮐﺎراﯾﯽ و ﻗﺎﺑﻠﯿﺖ اﻋﺘﻤﺎد را ﺑﺮرﺳـﯽ ﻣﯿﮑﻨﻨـﺪ ،‬‫ﺑﯿﺎن ﻣﯽﮐﺮد. ‪ push to test‬ﯾﮏ راه ﺣﻞ ﯾﮑﺘﺎ ﺑﺮاي ﺗﺴﺖ و ﺗﺼﺤﯿﺢ ﻋﻮاﻣﻠﯽ ﮐﻪ ﻣﺎﻧﻊ از رﺳـﯿﺪن ﺑـﻪ اﻫـﺪاف‬‫ﮐﺎراﯾﯽ و ﻋﻤﻠﮑﺮدي ﯾﮏ ﺳﯿﺴﺘﻢ ﻣﯽ ﺷﻮد را اراﺋﻪ ﻣﯽدﻫﺪ. ﺑﺮاي ﻣﺜﺎل ﺑﺎ اﺟﺮاي ﯾﮏ ﺳﻨﺎرﯾﻮي ﺗﺴﺖ ﻣﯿﺘـﻮان‬‫روي ﯾﮏ ﺳﯿﺴﺘﻢ ﺑﺎر اﯾﺠﺎد ﮐﺮد و ﭘﺎﯾﮕﺎه داده و ﺳﺮور ﺑﺮﻧﺎﻣﻪ را ﺑـﺎ اﺑـﺰار ﻫـﺎي ﻣﺎﻧﯿﺘﻮرﯾﻨـﮓ ﮐﻨﺘـﺮل ﮐـﺮد و‬ ‫ﻣﻮاردي ﮐﻪ ﺑﺎﻋﺚ ﮐﺎﻫﺶ ﮐﺎراﯾﯽ ﻣﯽﺷﻮد را ﺷﻨﺎﺳﺎﯾﯽ و ﺑﻬﺒﻮد ﺑﺨﺸﯿﺪ.‬‫در ﯾﮏ ﻣﺤﯿﻂ ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه ، ﺑﺎ درﺧﻮاﺳﺘﻬﺎي ﻣﺘﻮاﻟﯽ از ﺳﺮوﯾﺲ و ﻣـﺸﺎﻫﺪه ﻧﺘـﺎﯾﺞ ﻣـﯽﺗـﻮان روي آن‬‫ﺳﺮوﯾﺲ ﺑﺎر اﯾﺠﺎد ﮐﺮد. ﺗﺴﺖ ﻣﻘﯿﺎس ﭘﺬﯾﺮي ﺟﻌﺒﻪ ﺳﯿﺎه ﭘﺎﺳﺦﻫﺎي ﺳﺮوﯾﺲ را ﺑﺎ اﻓـﺰاﯾﺶ درﺧﻮاﺳـﺖﻫـﺎي‬ ‫ﻫﻤﺰﻣﺎن ﻧﻈﺎره ﻣﯽﮐﻨﺪ و ﺑﺮﻧﺎﻣﻪ را ﺑﺮاي ﯾﮏ ﻣﺤﯿﻂ واﻗﻌﯽ ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﺪ.‬‫‪ Push to test‬ﻫﻤﭽﻨﯿﻦ ﺑﺮاي ﺗﺴﺖﻫﺎي ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻧﯿﺰ ﻣﻨﺎﺳﺐ اﺳﺖ. از ﺳﺮوﯾﺴﯽ ﮐﻪ ﻣﯽﺧـﻮاﻫﯿﻢ آن‬‫را ﺗﺴﺖ ﮐﻨﯿﻢ اﻃﻼﻋﺎت داﺧﻠﯽ را ﭘﺮس و ﺟﻮ ﻣﯽﮐﻨﯿﻢ ﺗﺎ ﻣﺴﺎﺋﻞ ﻋﻤﻠﮑﺮدي و ﻣﻘﯿـﺎس ﭘـﺬﯾﺮي آن را ﮐـﺸﻒ‬‫ﮐﻨﯿﻢ . ﺳﺮوﯾﺲ ﺗﺤﺖ ﺗﺴﺖ اﻃﻼﻋﺎت وﺿﻌﯿﺖ را از ﻋﻤﻠﮑﺮد داﺧﻠﯽ ﻻﯾﻪﻫﺎي ﭘﺎﯾﮕﺎه داده و ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي از‬‫ﻣﺤﯿﻂ ﺳﺮوﯾﺲ اراﺋﻪ ﻣﯽﮐﻨﺪ. ﺑﺮاي ﻣﺜﺎل ﺑﻪ درﺧﻮاﺳﺖﻫﺎي اﺷﮑﺎلزداﯾﯽ ﺳﺮوﯾﺲ ﻣﺮﺑﻮط ﺑﻪ ﺑﮑﺎرﮔﯿﺮي , ‪cpu‬‬‫‪ I/O , memory‬و وﺿﻌﯿﺖﻫﺎي ﺗﺮاﮐﻨﺶﻫﺎ ﭘﺎﺳﺦ ﻣﯽدﻫﺪ. اﯾﻦ اﻃﻼﻋﺎت اﺿﺎﻓﯽ در ﺳﻪ ﻣﻘﻮﻟﻪ ﺑﺎﻋﺚ اﻓـﺰاﯾﺶ‬ ‫ﮐﺎراﯾﯽ ﻣﯽﺷﻮد.‬
    • ‫٠٤‬‫ﺑﺎ اﻧﺪازهﮔﯿﺮي ﺗﻮان ﻋﻤﻠﯿﺎﺗﯽ ‪ test agent‬ﻫﺎي ﺳﻤﺖ ﮐﺎرﺑﺮ ، آﻣﺎدﮔﯽ ﺳﯿﺴﺘﻢ ﺳﺮور ﺑﺮاي ﻣﺪﯾﺮﯾﺖ ﺟﻤﻌﯿـﺖ‬ ‫ﭘﯿﺶﺑﯿﻨﯽ ﺷﺪهاي از ﮐﺎرﺑﺮان را ﻧﺸﺎن ﻣﯽدﻫﺪ.‬‫ﺗﺮﮐﯿﺐ ﻋﻤﻠﯿﺎت ﻋﺎﻣﻞﻫﺎي ﺗﺴﺖ در ﺣﯿﻦ ﺗﺴﺖ ﺗﻐﯿﯿﺮ ﻣﯽﯾﺎﺑﻨﺪ ﺗﺎ رﺧﻨﻪﻫﺎ ﺷﻨﺎﺳﺎﯾﯽ ﺷﻮﻧﺪ و ﻣﻘﯿﺎس ﭘـﺬﯾﺮي‬ ‫ﺣﻞ ﺷﻮد.‬‫اﻧﺪازه ﮔﯿﺮي اﺳﺘﻔﺎده از ﭘﻬﻨﺎي ﺑﺎﻧﺪ ‪ I/O ،CPU‬و ﺣﺎﻓﻈﻪ ﻣﻌﯿﺎرﻫﺎي ﺑﺮﻧﺎﻣﻪرﯾﺰي ﺑﺮاي ﻇﺮﻓﯿـﺖ را ﺷﻨﺎﺳـﺎﯾﯽ‬ ‫ﻣﯽﮐﻨﺪ.‬ ‫‪Test network‬‬‫ﺑﺎ ‪ testnetwork‬ﺷﺮﮐﺖﻫﺎ ﻗﺎدرﻧﺪ ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺧﻮد را اﺗﻮﻣﺎت ﮐﻨﻨﺪ ﺗﺎ ﻋﻤﻠﯿـﺎﺗﯽ را ﮐـﻪ ﺑـﻪ درﺳـﺘﯽ‬‫اﻧﺠﺎم ﻣﯽﺷﻮﻧﺪ را، ﺑﺼﻮرت ﺧﻮدﮐﺎر، ﺑﺮرﺳﯽ ﮐﻨﻨﺪ ﺗ ﺎ ﺑﺎر اﺿﺎﻓﯽ را ﻣـﺪﯾﺮﯾﺖ ﮐﻨﻨـﺪ و ﻣﺘﻨﺎوﺑـﺎً ﺳﯿـﺴﺘﻢ ﻫـﺎ را‬ ‫ﮐﻨﺘﺮل ﮐﻨﻨﺪ ﺗﺎ دﭼﺎر ﻣﺸﮑﻞ ﻧﺸﻮﻧﺪ.‬ ‫‪ Test network‬روي ‪ testmaker‬ﺑﺎ اراﺋﻪ اﯾﻦ وﯾﮋﮔﯿﻬﺎ اﯾﺠﺎد ﻣﯿﺸﻮد.‬‫اﺟﺮاي ‪ agent‬ﻫﺎ ﺑﺎ ﻣﻘﯿﺎس ﺑﺰرﮔﺘـﺮ روي ﯾـﮏ ﻣﺎﺷـﯿﻦ . ﺑـﺮاي ﻣﺜـﺎل روي ﯾـﮏ ﺳﯿـﺴﺘﻢ ﭘﻨﺘﯿـﻮم ‪، 1GHz‬‬‫‪ testmaker‬ﻗﺎدر اﺳﺖ 1 ﺗﺎ 051 ﻋﺎﻣﻞ ﻫﻤﺰﻣﺎن را ﺷﺒﯿﻪ ﺳﺎزي ﮐﻨﺪ و ﻟﯽ ﺑﺎ ‪ testnetwork‬ﺣﺪود 00001 ﯾﺎ‬ ‫ﺑﯿﺸﺘﺮ را ﻣﯿﺘﻮان ﺷﺒﯿﻪ ﺳﺎزي ﮐﺮد .‬‫ﺑﺎ ﻣﻌﻤﺎري ‪ / testnode‬ﮐﻨﺴﻮل ‪ testnetwork‬ﻋﺎﻣﻞ ﻫﺎي ﺗﺴﺖ ﺑﻪ ﺳﺮورﻫﺎي ﮐﻮﭼﮑﯽ ﺗﺒـﺪﯾﻞ ﻣﯿـﺸﻮﻧﺪ ﮐـﻪ‬ ‫ﻣﯿﺘﻮاﻧﻨﺪ ﻋﻤﻠﯿﺎت را ﻣﺴﺘﻘﻼ ﻣﺪﯾﺮﯾﺖ ﮐﻨﻨﺪ.‬ ‫‪Test Maker Monitor‬‬‫ﯾﮏ اﺑﺰار ﮐﻤﮑﯽ اﺳﺖ ﺑﺮاي ﺑﺮرﺳﯽ آﻣﺎر ‪ CPU‬و ﺷﺒﮑﻪ و ﺣﺎﻓﻈﻪ ي ﺳﺮور ﺑﺮﻧﺎﻣﻪ وب اﺳﺖ. آﻣﺎر ﺟﻤـﻊآوري‬‫ﺷﺪه از ‪ monitor‬ﯾﮏ ﺗﺤﻠﯿﻞ رﯾﺸﻪاي در ﻧﻤﻮدارﻫﺎي اراﺋﻪ ﺷﺪه در ‪ push to test‬ﺑﺎ ﺑﺮﻗﺮاري ارﺗﺒﺎط ﺑﯿﻦ اﻣﺎر‬ ‫ﮐﺎراﯾﯽ و اﺳﺘﻔﺎده از ﻣﻨﺎﺑﻊ اراﺋﻪ ﻣﯽﮐﻨﺪ .‬
    • ‫١٤‬‫‪ Testmaker‬ﺷﺎﻣﻞ وﯾﺰاردﻫﺎ و ‪ recorder‬ﺑﺮاي آﺳﺎن ﮐﺮدن اﯾﺠﺎد ﺗﺴﺖ ﻫﺎﺳـﺖ. اﮔﺮﭼـﻪ اﯾﻨﻬـﺎ اﺑـﺰار ﻫـﺎي‬‫ﻗﻮياي در ﺟﺎي ﺧﻮدﺷﺎن ﻫﺴﺘﻨﺪ وﻟﯽ ﮐﺎر ﻫﺎي ﮐﻤﯽ را ﻣﯽﺗﻮاﻧﻨﺪ اﻧﺠﺎم دﻫﻨﺪ . ﺑـﺮا ي ﻣﺜـﺎل ﻓـﺮض ﮐﻨﯿـﺪ‬‫ﻣﯿﺨﻮاﻫﯿﺪ ﺗﺴﺘﯽ ﺑﻨﻮﯾﺴﯿﺪ ﮐﻪ ﻧﺘﺎﯾﺞ ﺑﺎزﮔﺸﺘﯽ از ﺳﺮور را ، ﻣﻄﺎﺑﻖ ﺑﺎ ﻣﻨﻄﻖ ﭘﯿﭽﯿـﺪه اي ﺗﺤﻠﯿـﻞ ﻣـﯽﮐﻨـﺪ و‬‫ﻋﻤﻞ ﻣﻨﺎﺳﺐ را ﺑﺮ اﺳﺎس ﻧﺘﺎﯾﺞ اﻧﺠﺎم ﻣﯽدﻫﺪ. در ﻣﻮﻗﻌﯿﺘﻬﺎﯾﯽ ﻣﺜﻞ اﯾﻦ ، ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد ﮐﻪ از ﻗﺎﺑﻠﯿﺘﻬﺎي‬ ‫اﺳﮑﺮﯾﭙﺖ ﻧﻮﯾﺴﯽ ﭘﻮﯾﺎي ‪ testmaker‬اﺳﺘﻔﺎده ﮐﻨﯿﺪ.‬ ‫‪iMacros‬‬‫72‪ ،iMacros‬ﮐﻪ ﻣﺨﻔﻒ ﻋﺒﺎرت ‪ internet macros‬ﻣﯽﺑﺎﺷﺪ، ﻣﺤﺼﻮل ﺷﺮﮐﺖ ‪ ،iOpus‬اﺳﺖ ﮐﻪ در اﺑﺘﺪا ﯾﮏ‬ ‫ﺗﯿﻢ ﻧﺮماﻓﺰاري آﻟﻤﺎﻧﯽ ﺑﻮد، و در ﺣﺎل ﺣﺎﺿﺮ در آﻣﺮﯾﮑﺎ و ﭼﻨﺪ ﮐﺸﻮر اروﭘﺎﯾﯽ و آﺳﯿﺎﯾﯽ، ﻣﺘﺨﺼﺼﺎﻧﯽ دارد.‬‫‪ iMacros‬اﺑﺰاري اﺳﺖ ﮐﻪ ﺑﺮاي ﺧﻮدﮐﺎرﺳﺎزي ﺗﻌﺎﻣﻼت ﮐﺎرﺑﺮان ﺑﺎ ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ.‬‫اﻧﮕﯿﺰه اﺻﻠﯽ اﯾﻦ ﺑﻮده اﺳﺖ ﮐﻪ ﮐﺎرﻫﺎﯾﯽ را ﮐﻪ ﮐﺎرﺑﺮان ﺑﻄﻮر ﺗﮑﺮاري و ﻣﮑﺮر اﻧﺠﺎم ﻣﯽدﻫﻨﺪ، ﺑـﺎ اﺳـﺘﻔﺎده از‬‫‪ iMacros‬ﺑﻄﻮر ﺧﻮدﮐﺎر اﻧﺠﺎم ﺷﻮد و در ﻧﺘﯿﺠﻪ در وﻗﺖ و اﻧﺮژي ﮐﺎرﺑﺮ ﺻﺮﻓﻪ ﺟﻮﯾﯽ ﺷﻮد. ﻣﺜﻼ ﮐﺎرﻣﻨﺪي ﮐﻪ‬‫ﻫﺮ روز ﺑﺎﯾﺪ ﺑﻪ ﭼﻨﺪ ﺳﯿﺴﺘﻢ ﺗﺤﺖ وب، وارد ﺷﻮد و ﮐﺎرﻫﺎي روﺗﯿﻨﯽ را اﻧﺠﺎم دﻫﺪ، ﻣﯽﺗﻮاﻧـﺪ ﺑـﺎ اﺳـﺘﻔﺎده از‬ ‫‪ ،iMacors‬ﺑﺨﺶ زﯾﺎدي از ﮐﺎرﻫﺎي ﺗﮑﺮاري ﺧﻮد را ﺑﻄﻮر ﺧﻮدﮐﺎر اﻧﺠﺎم دﻫﺪ.‬‫اﺳﺎس ﮐﺎر ‪ iMacros‬ﻣﺒﺘﻨﯽ ﺑﺮ ﻣﺪل ‪ capture/replay‬اﺳﺖ، ﯾﻌﻨﯽ ﮐﺎرﻫـﺎﯾﯽ ﮐـﻪ ﮐـﺎرﺑﺮ در ﻣﺮورﮔـﺮ اﻧﺠـﺎم‬‫ﻣﯽﻫﺪ را در ﻗﺎﻟﺐ ﯾﮑﺴﺮي ﻣﺎﮐﺮو ﺿﺒﻂ و ذﺧﯿﺮه ﻣﯽﻧﻤﺎﯾﺪ و ﺑﻌﺪ ﻗﺎﺑﻠﯿﺖ اﺟـﺮاي آن ﻣﺎﮐﺮوﻫـﺎ را در ﻣﺮورﮔـﺮ‬‫دارد. ﺑﺪﯾﻦ ﺗﺮﺗﯿﺐ، ﮐﺎرﺑﺮ ﻣﯽﺗﻮاﻧﺪ اﺑﺘﺪا ﺗﻌﺎﻣﻼت ﺧﻮد ﺑﺎ ﺳﯿـﺴﺘﻢ ﻣـﻮرد ﻧﻈـﺮ را ﺿـﺒﻂ ﻧﻤﺎﯾـﺪ، و ﺳـﭙﺲ ﺑـﺎ‬‫اﺳﺘﻔﺎده از ‪ ،iMacros‬اﯾﻦ ﺗﻌﺎﻣﻼت را ﺑﺎرﻫﺎ و ﺑﺎرﻫﺎ ﺑﻄﻮر ﺧﻮدﮐﺎر ﺗﮑﺮار ﻧﻤﺎﯾﺪ. ﻫﻤﯿﻦ ﻗﺎﺑﻠﯿﺖ ﺗﻌﺎﻣﻞ ﺧﻮدﮐـﺎر‬‫ﺑﺎ ﺻﻔﺤﺎت وب، ‪ iMacros‬را ﺑﻪ اﺑﺰاري ﻗﻮي ﺑﺮاي ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب ﺗﺒـﺪﯾﻞ ﮐـﺮده‬‫اﺳﺖ.. در ﺣﺎل ﺣﺎﺿﺮ ﮐﺎرﺑﺮان زﯾﺎدي در ﺳﺮاﺳﺮ ﺟﻬﺎن از ‪ iMacros‬ﺑﺮاي اﻧﺠﺎم ﺗﺴﺖ ﻫﺎي ﻣﺨﺘﻠﻒ ﺑـﺮ روي‬ ‫ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب ﺧﻮد اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ.‬‫72‪http://www.iopus.com‬‬
    • ‫٢٤‬‫ﻣﺎﮐﺮوﻫﺎ، ﻓﺎﯾﻠﻬﺎي ﻣﺘﻨﯽ ﺳﺎده اي ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﺴﺘﻘﻞ از ﭘﻠﺘﻔﺮم و ﻣﺮورﮔﺮ ﻣﯽﺑﺎﺷﻨﺪ. ﯾﻌﻨﯽ ﻣﺜﻼ ﻣﺎﮐﺮوﯾﯽ ﮐـﻪ‬ ‫در ﻣﺮورﮔﺮ ‪ IE‬اﯾﺠﺎد ﺷﺪه اﺳﺖ را ﻣﯽﺗﻮان در ﻣﺮورﮔﺮ ‪ Firefox‬اﺟﺮا ﮐﺮد.‬ ‫ﺑﺮﺧﯽ از ﮐﺎرﺑﺮدﻫﺎ و وﯾﮋﮔﯽ ﻫﺎي ‪ iMacors‬ﺑﺪﯾﻦ ﺗﺮﺗﯿﺐ اﺳﺖ:‬ ‫‪ ‬ﭘﺮﮐﺮدن ﻓﺮﻣﻬﺎي ﻣﻮﺟﻮد در ﺻﻔﺤﺎت وب، ﺑﻌﻨﻮان ﻣﺜﺎل ﻓﺮم ورود ﺑﻪ ﯾﮏ ﺳﺎﯾﺖ‬‫‪ ‬ﺗﺴﺖ ﻫﺎي ﻣﺨﺘﻠﻒ ﺑﺮ روي ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، ﻧﻈﯿﺮ ﺗﺴﺖ ﮐﺎرآﯾﯽ، ﺗﺴﺖ اﻣﻨﯿﺖ، ﺗﺴﺖ ﺑﺎر و‬ ‫اﺳﺘﺮس‬ ‫‪ ‬اﺳﺘﺨﺮاج داده ﻫﺎ از ﺻﻔﺤﺎت وب ﺑﻄﻮر ﺧﻮدﮐﺎر‬ ‫‪ Upload ‬ﮐﺮدن اﻃﻼﻋﺎت در ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب ﺑﻄﻮر ﺧﻮدﮐﺎر‬‫‪ ‬اﻣﮑﺎن اﺳﺘﻔﺎده از ﻣﺎﮐﺮوﻫﺎي ‪ iMacors‬در زﺑﺎﻧﻬﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﻧﻈﯿﺮ ‪ ،C# ،Java‬و ‪ PHP‬و‬ ‫‪Python‬‬ ‫‪ ‬اﻧﺠﺎم ﮐﺎرﻫﺎي ﺗﮑﺮاري در ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب، ﺑﻄﻮر ﺧﻮدﮐﺎر و ﺑﺪون ﻧﯿﺎز ﺑﻪ دﺧﺎﻟﺖ ﮐﺎرﺑﺮ‬‫‪ ‬اﻣﮑﺎن ذﺧﯿﺮه ﮐﻠﻤﺎت رﻣﺰ ﺑﻄﻮر ﻣﺤﺮﻣﺎﻧﻪ و اﻣﻦ، ﺑﺮاي اﻧﺠﺎم ﺗﻌﺎﻣﻼﺗﯽ ﮐﻪ ﺑﻪ ﮐﻠﻤﻪ رﻣﺰ ﮐﺎرﺑﺮ ﻧﯿﺎز‬ ‫دارﻧﺪ. ‪ iMacros‬از اﻟﮕﻮرﯾﺘﻢ رﻣﺰ ‪ AES‬ﺑﺎ ﻃﻮل ﮐﻠﯿﺪ 652 ﺑﯿﺖ اﺳﺘﻔﺎده ﻣﯽﻧﻤﺎﯾﺪ.‬ ‫‪ ‬ﺑﺮاي اﻧﺪازه ﮔﯿﺮي زﻣﺎن ﭘﺎﺳﺦ ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب و ارزﯾﺎﺑﯽ ﮐﺎراﯾﯽ اﯾﻦ ﺳﯿﺴﺘﻤﻬﺎ‬ ‫‪ ‬ﻗﺎﺑﻠﯿﺖ ﭘﺸﺘﯿﺒﺎﻧﯽ از ﺳﺎﯾﺘﻬﺎﯾﯽ ﮐﻪ از ‪ Flash‬ﯾﺎ ﺟﺎوا اﺳﮑﺮﯾﭙﺖ اﺳﺘﻔﺎده ﻣﯽﻧﻤﺎﯾﻨﺪ.‬‫‪ ،iMacros‬داراي ﺳﻪ ﻧﺴﺨﻪ اﺳﺖ ﮐﻪ در ﺳﺎﯾﺖ ﻣﺮﺑﻮﻃﻪ اﻣﮑﺎﻧﺎت آﻧﻬﺎ ﺑﺎ ﻫﻢ ﻣﻘﺎﯾﺴﻪ ﺷـﺪه اﺳـﺖ. ]‪[imacro‬‬ ‫]2‪[imacro‬‬‫ﻻزم ﺑﻪ ذﮐﺮ اﺳﺖ ﮐﻪ ‪ ،JUnit‬ﺑﺎ ﺗﻌﺪادي از ﻣﺤﯿﻂﻫﺎي ﺗﻮﺳﻌﻪ ﺑﺮﻧﺎﻣﻪﻫﺎي ﺟﺎوا ﻧﻈﯿـﺮ ‪ JBuilder ،Eclipse‬و‬‫‪ ،Intellij IDEA‬ﻧﯿﺰ ﯾﮑﭙﺎرﭼﻪ ﺷﺪه اﺳﺖ و اﻣﮑﺎن ﺗﺒﺎدل ﺑﺎ ‪ JUnit‬از درون اﯾـﻦ ﻧـﺮماﻓﺰارﻫـﺎ ﺑﺨـﻮﺑﯽ ﻓـﺮاﻫﻢ‬‫اﺳﺖ. ﻫﻤﭽﻨﯿﻦ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻘﺒﻮﻟﯿﺖ روزاﻓﺰون ﻣﺘﺪﻫﺎي ﺗﻮﺳﻌﻪ ﭼﺎﺑﮏ ﻧﺮماﻓﺰار )‪ ،(agile methods‬ﮐﻪ ﺗﻮﺟﻪ‬ ‫و ﺗﻤﺮﮐﺰ ﺑﯿﺸﺘﺮي ﺑﺮ ﻣﺴﺄﻟﻪ ﺗﺴﺖ دارﻧﺪ، اﻫﻤﯿﺖ و رواج ‪ ،JUnit‬رو ﺑﻪ اﻓﺰاﯾﺶ اﺳﺖ.‬
    • ‫٣٤‬ ‫ﭼﺸﻢاﻧﺪاز و ﻧﺘﯿﺠﻪﮔﯿﺮي‬ ‫5-‬‫ﺣﺠﻢ ﺑﺮﻧﺎﻣﻪﻫﺎي ﮐﺎرﺑﺮدي روز ﺑﻪ روز در ﺣﺎل اﻓﺰاﯾﺶ اﺳﺖ. اﻣﺮوزه ﺳﺎزﻣﺎنﻫﺎي ﻧﺮماﻓـﺰاري زﻣـﺎن و ﻣﻨـﺎﺑﻊ‬‫زﯾﺎدي را در ﺗﺤﻠﯿﻞ و ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻﺮف ﻣﯽﮐﻨﻨﺪ. از ﻧﻈﺮ ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻧﻮﺷـﺘﻦ ﮐـﺪﻫﺎي ﺗـﺴﺖ، ﺑـﻪ‬‫ﺧﻮدي ﺧﻮد، ﻣﺜﻞ ﺗﻮﺳﻌﻪ ﺧﻮد ﻣﺤﺼﻮل وﻗﺖ ﮔﯿﺮ و ﮔﺮان اﺳﺖ. ﺑﺎ اﻓﺰاﯾﺶ ﺣﺠـﻢ و ﭘﯿﭽﯿـﺪﮔﯽ ﻧـﺮماﻓﺰارﻫـﺎ،‬‫ﺗﺴﺖ ﮐﺮدن دﺳﺘﯽ آﻧﻬﺎ ﮐﺎري ﺑﺴﯿﺎر ﺳﻨﮕﯿﻦ و ﻃﺎﻗﺖ ﻓﺮﺳﺎ و ﮔﺎه ﻏﯿﺮ ﻣﻤﮑﻦ ﻣﯽﺷﻮد. ﺑﻨﺎﺑﺮاﯾﻦ ﺧﻮدﮐﺎرﺳﺎزي‬ ‫ﺗﺴﺖ راهﺣﻠﯽ اﺳﺖ ﮐﻪ ﮐﺎرﻫﺎي ﺳﻨﮕﯿﻦ و ﭘﺮزﺣﻤﺖ ﺗﺴﺖ را ﺳﺎده ﻣﯽﻧﻤﺎﯾﺪ.‬‫ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ زﻣﺎﻧﯽ ﻣﺆﺛﺮ اﺳﺖ ﮐﻪ ﺷﺮاﯾﻂ ﻧﺮماﻓﺰار ﺗﺤﺖ ﺗﺴﺖ ﻣﻨﺎﺳﺐ ﺑﺎﺷﺪ. ﺑﺎﯾﺪ ﺗﻮﺟـﻪ داﺷـﺖ ﮐـﻪ‬‫ﺗﺴﺖ ﺧﻮدﮐﺎر ﺑﻪ اﯾﻦ ﻣﻌﻨﺎ ﻧﯿﺴﺖ ﮐﻪ ﮐﻞ ﻓﺮآﯾﻨﺪ ﺗﺴﺖ ﻧﺮماﻓﺰار ﺑﻪ ﺻﻮرت ﺧﻮدﮐﺎر اﻧﺠﺎم ﻣﯽﺷﻮد. ﺑﻠﮑـﻪ ﺑـﻪ‬‫ﻣﻌﻨﺎي ﺗﺴﺖ ﻧﺮماﻓﺰار ﺑﺎ ﮐﻤﮏ ﮐﺎﻣﭙﯿﻮﺗﺮ اﺳﺖ. اﺳﺘﻔﺎده از ﺗﺴﺖ ﺧﻮدﮐﺎر ﭘﺮﻫﺰﯾﻨﻪ اﺳﺖ. ﺑﻪ ﮐـﺎرﺑﺮدن ﺗـﺴﺖ‬‫ﺧﻮدﮐﺎر ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﻧﯿﺴﺖ ﮐﻪ دﯾﮕﺮ ﻧﯿﺎزي ﺑﻪ ﺗﺴﺖ دﺳﺘﯽ ﻧﺪارﯾﻢ ﺑﻠﮑﻪ ﺗﺴﺖ ﺧﻮدﮐﺎر ﻣﮑﻤﻠﯽ ﺑﺮاي ﻓﺮآﯾﻨﺪ‬ ‫ﺗﺴﺖ ﻣﻮﺟﻮد ﻣﯽ ﺑﺎﺷﺪ.‬‫از اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻣﯽﺗﻮان ﺑﻪ ﺧﺎﻧﻮادهي ‪ xUnit‬اﺷﺎره ﻧﻤﻮد. در اﯾﻦ ﻣﺘﻦ ﺑﻪ ﻣﻌﺮﻓﯽ ‪ jUnit‬ﭘﺮداﺧﺘﯿﻢ‬‫ﮐﻪ اﻣﺮوزه ﺑﻌﻨﻮان ﻣﻬﻢﺗﺮﯾﻦ اﺑﺰار ﺗﺴﺖ واﺣﺪ ﺑﺮﻧﺎﻣﻪﻫﺎي ﺟﺎوا ﻣﻘﺒﻮﻟﯿﺖ ﺑﺴﯿﺎر زﯾـﺎدي ﯾﺎﻓﺘـﻪ اﺳـﺖ. ﺳـﺎﺧﺘﺎر‬‫ﻣﻮرد اﺳﺘﻔﺎده در اﯾﻦ اﺑﺰار، در ﻋﯿﻦ ﺳﺎدﮔﯽ، از ﻗﺎﺑﻠﯿﺖ و ﮐﺎرآﯾﯽ ﺑـﺎﻻﯾﯽ ﺑﺮﺧـﻮردار اﺳـﺖ. ﻋـﻀﻮ دﯾﮕـﺮ اﯾـﻦ‬‫ﺧﺎﻧﻮاده ‪ httpUnit‬اﺳﺖ ﮐﻪ ﯾﮏ ﭼﺎرﭼﻮب ﻣﻨﺒﻊ ﺑﺎز ﺗﺴﺖ ﻧﺮماﻓﺰار، ﺑﺮاي ﺗﺴﺖ وب ﺳﺎﯾﺖﻫﺎ ﺑﺪون اﺳﺘﻔﺎده از‬‫ﻣﺮورﮔﺮ اﺳﺖ. در ‪ httpunit‬ﻣﯽﺗﻮان از ارﺳﺎل ﻓﺮمﻫﺎي ‪ http‬و اﺣﺮاز ﻫﻮﯾـﺖ دﺳﺘﺮﺳـﯽ ﺳـﺎده ‪ http‬و ﺟـﺎوا‬‫اﺳﮑﺮﯾﭙﺖ و ﮐﻮﮐﯽ و ...اﺳﺘﻔﺎده ﮐﺮد. اﺑﺰار ‪ HTMLUnit‬ﻧﯿﺰ ﯾﮏ ﻣﺮورﮔﺮ اﺳﺖ ﮐﻪ ﺑﻪ زﺑﺎن ﺟﺎوا ﻧﻮﺷﺘﻪ ﺷﺪه و‬‫دﺳﺖﮐﺎري ﺳﻄﺢ ﺑﺎﻻي ﺻﻔﺤﺎت وب ﻣﺜﻞ ﺗﮑﻤﯿﻞ ﻓﺮمﻫﺎ و ﮐﻠﯿﮏ ﮐﺮدن اﺑﺮﻣﺘﻦ و دﺳﺘﺮﺳﯽ ﺑﻪ اﻟﻤـﺎنﻫـﺎي‬ ‫ﺧﺎﺻﯽ در ﺻﻔﺤﻪ را ﻣﻤﮑﻦ ﻣﯽﺳﺎزد.‬
    • ‫٤٤‬‫اﺑﺰار ﺗﺴﺖ ﺧﻮدﮐﺎر دﯾﮕﺮ ‪ Selenium‬اﺳﺖ ﮐﻪ ﻣﺠﻤﻮﻋﻪاي اﺳﺖ از اﺑﺰارﻫﺎ ﮐﻪ ﺗﺴﺖ اﺗﻮﻣﺎت ﺑﺮﻧﺎﻣﻪﻫﺎي وب را‬‫در ﭘﻠﺘﻔﺮمﻫﺎي ﻣﺨﺘﻠﻒ اﻣﮑﺎن ﭘﺬﯾﺮ ﻣﯽﮐﻨﺪ. ﺗﺴﺖﻫـﺎي ‪ selenium‬دﻗﯿﻘـﺎً روي ﯾـﮏ ﻣﺮورﮔـﺮ واﻗﻌـﯽ اﺟـﺮا‬‫ﻣﯽﺷﻮﻧﺪ. ﮐﺪﻫﺎي ﺟﺎوا اﺳﮑﺮﯾﭙﺖ ﮐﻪ ‪ selenium‬ﺗﻮﻟﯿﺪ ﻣﯽﮐﻨﺪ در ﺣﯿﻦ ﺑﺮﻧﺎﻣﻪ در ﺣﺎل اﺟﺮا اﯾﺠﺎد ﻣﯽﺷـﻮﻧﺪ‬ ‫و ﺳﭙﺲ دﻗﯿﻘﺎً ﻣﺜﻞ ﮐﺎرﺑﺮ ﺑﺎ ﺑﺮﻧﺎﻣﻪ ﺗﻌﺎﻣﻞ ﻣﯽﮐﻨﻨﺪ.‬‫‪ EMMA‬ﻧﯿﺰ ﯾﮏ اﺑﺰار ﻣﺘﻦ ﺑﺎز ﺑﺮاي اﻧﺠﺎم ﺗﺴﺖ ﭘﻮﺷﺶ ﮐﺪ ﺑﺮ روي ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه ﺑﻪ زﺑـﺎن ﺟـﺎوا‬‫ﻣﯽﺑﺎﺷﺪ. ﺑﺎ اﺳﺘﻔﺎده از آن ﻣﯽﺗﻮان ﺑﺮرﺳﯽ ﮐﺮد ﮐﻪ در ﺣﯿﻦ اﺟـﺮاي ﺑﺮﻧﺎﻣـﻪ، ﮐـﺪام دﺳـﺘﻮرات ﺑﺮﻧﺎﻣـﻪ اﺟـﺮا‬ ‫ﺷﺪهاﻧﺪ و ﭼﻪ ﻣﻘﺪاري از ﮐﺪﻫﺎي ﺑﺮﻧﺎﻣﻪ ﭘﻮﺷﺶ داده ﺷﺪهاﻧﺪ.‬‫ﭼﺎرﭼﻮﺑﯽ ﺑﺮاي ﺗﺴﺖ ﺧﻮدﮐﺎر ﺑﺮ ﻣﺒﻨﺎي ‪ .NET Framework‬ﮐﻪ ﺑﺎ اﺳﺘﻔﺎده از زﺑﺎن #‪ C‬ﭘﯿـﺎدهﺳـﺎزي ﺷـﺪه‬‫اﺳﺖ، ﻧﯿﺰ در اﯾﻦ ﻣﺘﻦ ﺑﺮرﺳﯽ ﺷﺪ. ﻫﺪف اﯾﻦ ﭼﺎرﭼﻮب ﺗﻮﺳﻌﻪ ﯾﮏ اﺑﺰار ﺗﺴﺖ ﻧﺮماﻓﺰاري ﮐﺎﻣﻼً اﺗﻮﻣﺎت ﺷﺪه‬‫اﺳﺖ. اﯾﻦ اﺑـﺰار ‪ test script‬ﻫـﺎﯾﯽ ﺑـﺮاي ﺗـﺴﺖ واﺣـﺪ )‪ ، (unit testing‬ﺗـﺴﺖ ﯾﮑﭙـﺎرﭼﮕﯽ ‪(integration‬‬ ‫)‪ testing‬و ‪ regression testing‬اﯾﺠﺎد ﻣﯽﮐﻨﺪ.‬‫‪ iMacros‬ﻧﯿﺰ اﺑﺰاري ﺗﺠﺎري ﺑﺮاي ﺧﻮدﮐﺎرﺳﺎزي ﺗﻌﺎﻣﻼت ﮐﺎرﺑﺮان ﺑﺎ ﺳﯿـﺴﺘﻤﻬﺎي ﺗﺤـﺖ وب اﺳـﺖ. اﻧﮕﯿـﺰه‬‫اﺻﻠﯽ اﯾﻦ ﺑﻮده اﺳﺖ ﮐﻪ ﮐﺎرﻫﺎﯾﯽ را ﮐﻪ ﮐـﺎرﺑﺮان ﺑﻄـﻮر ﺗﮑـﺮاري و ﻣﮑـﺮر اﻧﺠـﺎم ﻣـﯽدﻫﻨـﺪ، ﺑـﺎ اﺳـﺘﻔﺎده از‬ ‫‪ iMacros‬و ﺑﺎ ﻣﺪل ‪ capture/replay‬ﺑﻄﻮر ﺧﻮدﮐﺎر اﻧﺠﺎم ﺷﻮد.‬‫‪ Push to test‬ﯾﮏ ﭼﺎرﭼﻮب ﮐﺪ ﺑﺎز ﺑﺮاي ﺧﻮدﮐﺎر ﺳﺎزي ﺗﺴﺖ ﺑﻪ ﻣﻨﻈﻮر ﺑﺘﻮاﻧﻨﺪ ﺗـﺴﺖ و ﮐﻨﺘـﺮل و ﻫـﺪاﯾﺖ‬‫ﺳﯿﺴﺘﻢ ﻫﺎي اﻃﻼﻋﺎﺗﯽ ﻣﯽﺑﺎﺷﺪ. ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﺎن ﺑﺮاي ﺗﺒﺪﯾﻞ ﺗﺴﺖﻫﺎي واﺣﺪ ﺑﻪ ﺗﺴﺖ ﻋﻤﻠﮑـﺮد از ‪push to‬‬‫‪ test‬اﺳﺘﻔﺎده ﻣﯽﮐﻨﻨﺪ. ﻣﺤﯿﻂ زﻣﺎن اﺟﺮاي ‪ push to test‬ﺑﺼﻮرت ﺧﻮدﮐﺎر ﺗﺴﺖﻫﺎي ﻋﻤﻠﮑـﺮد واﺣـﺪ را ﺑـﻪ‬ ‫ﺗﺴﺖ ﺑﺎر و ﺗﺴﺖ ﻣﻘﯿﺎس ﭘﺬﯾﺮي وﺗﺴﺖ ﮐﺎراﯾﯽ و ﺗﺴﺖ رﮔﺮاﺳﯿﻮن و ﺗﺴﺖ ﮐﻨﺘﺮل ﺳﺮوﯾﺲ ﺗﺒﺪﯾﻞ ﻣﯽﮐﻨﺪ.‬‫ﭼﺎرﭼﻮبﻫﺎ و اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار ﺑﺴﯿﺎر ﻣﺘﻨﻮع ﻫﺴﺘﻨﺪ و ﻫﺮ ﯾـﮏ وﯾﮋﮔـﯽﻫـﺎي ﺧـﺎص ﺧـﻮد را‬‫داراﺳﺖ و ﺑﺮاي ﮐﺎرﺑﺮدﻫﺎي ﺧﺎﺻﯽ ﻧﯿﺰ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﯽﮔﯿﺮد. در اﯾﻦ ﺑﯿﻦ ﺟﺎي ﯾﮏ ﭼـﺎرﭼﻮب ﺗـﺴﺖ‬‫ﺧﻮدﮐﺎر ﺟﺎﻣﻊ ﮐﻪ ﻣﺠﻤﻮﻋﻪاي از اﺑﺰارﻫﺎي ﺧﻮب و ﮐﺎراي ﻣﻮﺟﻮد ﺑﺎﺷﺪ ﺧﺎﻟﯽ اﺳﺖ و ﻧﯿﺎز ﺑﻪ ﭼﻨﯿﻦ ﭼـﺎﭼﻮﺑﯽ‬
    • ‫٥٤‬‫ﺑﻪ وﺿﻮح ﻗﺎﺑﻞ درك اﺳﺖ. ﭼﺎرﭼﻮب ﭘﯿﺸﻨﻬﺎدي ﺷﺎﻣﻞ ﺗﺴﺖ ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ ﺑﻪ روش ﺟﻌﺒـﻪ ﺳـﯿﺎه اﺳـﺖ و‬‫ﺗﺄﮐﯿﺪ اﺻﻠﯽ آن ﺑﺮروي ﺗﺴﺖ ﻋﻤﻠﮑﺮد ﻧﺮم اﻓﺰار و ﻣﻘﺎﯾﺴﻪ آن ﺑﺎ ﻧﯿﺎزﻣﻨﺪيﻫﺎي ﺳﯿﺴﺘﻢ اﺳﺖ. ﻋﻼوه ﺑﺮاﯾﻦ در‬‫ﻣﺤﺼﻮل ﻧﻬﺎﯾﯽ، آزﻣﻮﻧﻬﺎي ﺟﻌﺒﻪ ﺳﯿﺎه دﯾﮕﺮي ﻫﻤﭽﻮن ﺗﺴﺖ اﺳﺘﺮس، ﺗﺴﺖ ﺑﺎر و ﺗﺴﺖ اﻣﻨﯿـﺖ ﻧﯿـﺰ ﭘـﯿﺶ‬‫ﺑﯿﻨﯽ ﺷﺪه اﺳﺖ. از ﻃﺮف دﯾﮕﺮ، در ﭼﺎرﭼﻮب ﭘﯿﺸﻨﻬﺎدي ﺑﺮاي ﺗﻮﻟﯿﺪ ﻣﺠﻤﻮﻋﻪ ﻣـﻮارد ﺗـﺴﺖ، ﭼﻨـﺪﯾﻦ روش‬‫ﭘﯿﺶ ﺑﯿﻨﯽ ﺷﺪه اﺳﺖ ﮐﻪ از ﺟﻤﻠﻪ آﻧﻬﺎ ﺗﻮﻟﯿﺪ ﻣﻮارد ﺗﺴﺖ از روي ﻣﺪل ﻧﺮم اﻓﺰار )ﻣﺎﻧﻨﺪ ﻣﺪل ‪ (UML‬و ﯾﺎ از‬‫روي ﮐﺪ ﻣﻨﺒﻊ ﻧﺮم اﻓﺰار اﺳﺖ. اﯾﻦ ﮐﺎر ﺑﻪ ﻣﻌﻨﺎي اﺳﺘﻔﺎده از اﺑﺰارﻫـﺎي ﺟﻌﺒـﻪ ﺳـﻔﯿﺪ ﻣـﯽ ﺑﺎﺷـﺪ. اﻣـﺎ ﭼـﻮن‬‫ﺗﺴﺖﻫﺎي اﺟﺮا ﺷﺪه ﺑﺮ روي ﺳﯿﺴﺘﻢ ﺗﺤﺖ آزﻣﻮن ﺑﺼﻮرت ﺟﻌﺒﻪ ﺳﯿﺎه ﻋﻤﻞ ﻣﯽ ﮐﻨﻨﺪ، در ﻣﺠﻤﻮع ﻣﯽ ﺗـﻮان‬‫ﮔﻔﺖ ﻣﺘﺪوﻟﻮژي آزﻣﻮن در اﯾﻦ ﭼﺎرﭼﻮب، روش ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي اﺳﺖ. ﭼﺮاﮐـﻪ ﮔﺮﭼـﻪ ﻧﯿـﺎزي ﺑـﻪ داﺷـﺘﻦ‬‫اﻃﻼﻋﺎت دﻗﯿﻖ از ﮐﺪ ﻣﻨﺒﻊ ﻧﺮم اﻓﺰار و ارﺗﺒﺎﻃﺎت داﺧﻠﯽ آن ﺑﺮاي اﻧﺠﺎم آزﻣﻮن ﻧﺪارﯾﻢ، اﻣﺎ دﺳﺘﺮﺳﯽ ﺑﻪ ﯾـﮏ‬‫ﻣﺪل ﮐﻠﯽ از ﻧﺮم اﻓﺰار )وﯾﺎ دﺳﺘﺮﺳﯽ ﺑﻪ ﺧﻮد ﮐﺪ ﻣﻨﺒﻊ ﺑﺮاي ﺑﺪﺳﺖ آوردن ﯾﮏ ﻣﺪل( ﺑﻪ ﻣﺎ در ﺗﻬﯿـﻪ ﻣـﻮارد‬ ‫ﺗﺴﺖ ﺟﺎﻣﻊﺗﺮ ﮐﻤﮏ ﻣﯽ ﻧﻤﺎﯾﺪ.‬
    • ٤٦ ‫ﻣﺮاﺟﻊ‬ -6[Ham04] Paul Hamill, Unit Test Frameworks, OReilly, 2004.[Kan01-1] Kaner, Cem; James Bach, Bret Pettichord (2001). Lessons Learned in Software Testing: A Context-Driven Approach. Wiley, 4. ISBN 0-471-08112-4.[Chu05] Huey–Der Chu, John E Dobson and I–Chiang Liu, FAST: A Framework for Automating Statistics–based Testing, 2005.[Cra02] Rick D. Craig, Stefan P. Jaskiel, Systematic Software Testing, Artech House Publications, 2002.[Ngu01] Hung Q. Nguyen, Testing Applications on the Web: Test Planning for Internet- Based Systems, Wiley, 2001.[Luc06] Giuseppe A. Di Lucca, Anna Rita Fasolino, Testing Web-based applications: The State of the Art and Future Trends, Information and Software Technology 48 (2006) 1172-1186.[Pre05] Pressman, R., Software Engineering: A practitioners guide, 6th edition, McGraw-Hill, 2005.[Mak07] Mikko Mäkinen, Model Based Approach to SoftwareTesting, May 22, 2007[Spr07] Sara E. Sprenkle, STRATEGIES FOR AUTOMATICALLY EXPOSING FAULTS IN WEB APPLICATIONS, summer 2007[Mas04] Vincent Massol, ted Husted, JUnit in Action, Manning, 2004.[imacro] http://www.iopus.com[emma] http://emma.sourceforge.net[sybex] Kanglin Li, Menqi Wu, Effective Software Test Automation: Developing an Automated Software Testing Tool, Sybex, 2004.[sel] C. Titus. B, G. Gheorghio, J.Huggins, "An Introduction to testing web application with twill and selenium" OReilly , June 11,2007[html] http://www.sourceforge.net/projects/htmlunit[imac2] "Imacro-manual",© 2001 - 2006 iOpus SoftwareGmbH