automated+software+testing+tools.pdf

3,661 views

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,661
On SlideShare
0
From Embeds
0
Number of Embeds
63
Actions
Shares
0
Downloads
205
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

automated+software+testing+tools.pdf

  1. 1. ‫داﻧﺸﮑﺪهي ﻣﻬﻨﺪﺳﯽ‬ ‫ﮔﺮوه ﻣﻬﻨﺪﺳﯽ ﮐﺎﻣﭙﯿﻮﺗﺮ- ﻧﺮماﻓﺰار‬‫ﺑﺮرﺳﯽ اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار‬‫ﺗﻬﯿﻪ ﮐﻨﻨﺪه: ﮔﺮوه ﺗﺨﺼﺼﯽ آزﻣﺎﯾﺸﮕﺎه ﻓﻨﺎوري وب‬ ‫آﺑﺎن 7831‬
  2. 2. ‫‪II‬‬ ‫ﭘﯿﺸﮕﻔﺘﺎر‬‫ﭘﯿﭽﯿﺪﮔﯽ و اﻧﺪازهي ﻧﺮماﻓﺰارﻫﺎي ﮐﺎﻣﭙﯿﻮﺗﺮي ﻫﻤﻮاره رو ﺑﻪ اﻓﺰاﯾﺶ اﺳﺖ. ﻫﺮ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاري ﻣﺨﺎﻃﺒـﺎن‬‫ﺧﺎﺻﯽ دارد. ﺑﺮاي ﻣﺜﺎل ﯾﮏ ﻧﺮماﻓﺰار ﺑﺎﻧﮑﯽ ﻣﺨﺎﻃﺒـﺎﻧﯽ ﮐـﺎﻣﻼً ﻣﺘﻔـﺎوت از ﻣﺨﺎﻃﺒـﺎن ﯾـﮏ ﻧـﺮماﻓـﺰار ﺑـﺎزي‬‫ﮐﺎﻣﭙﯿﻮﺗﺮي دارد. ﺑﻨﺎﺑﺮاﯾﻦ، زﻣﺎﻧﯿﮑﻪ ﺳﺎزﻣﺎﻧﯽ ﯾﮏ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاري را ﻣﯽﻧﻮﯾـﺴﺪ ﯾـﺎ ﺧﺮﯾـﺪاري ﻣـﯽﮐﻨـﺪ،‬‫ﻣﻨﻄﻘﺎً ﺑﺎﯾﺪ اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﮐﻨﺪ ﮐﻪ آﯾﺎ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاري ﺑﺮاي ﮐﺎرﺑﺮان او، ﻣﺨﺎﻃﺒﺎن او، ﺧﺮﯾﺪاران، و ﺳﺎﯾﺮ‬‫ذﯾﻨﻔﻌﺎن ﻗﺎﺑﻞ ﭘﺬﯾﺮش ﻫﺴﺖ ﯾﺎ ﻧﻪ. ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪ ﺗﻼش ﺑﺮاي اﯾﻦ ﮔﻮﻧﻪ ارزﯾﺎﺑﯽ ﻫﺎﺳـﺖ. ﺑـﻪ ﻋﺒـﺎرت‬‫دﯾﮕﺮ ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪ اﻣﺘﺤﺎن ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي ﺑﺮاي ﮐﺸﻒ ﺧﻄﺎﻫﺎ و ﺗﻀﻤﯿﻦ اﯾﻨﮑﻪ ﻧﯿﺎزﻣﻨﺪيﻫـﺎي‬ ‫ﻣﻮﺟﻮد را ﺑﺮآورده ﻣﯽﮐﻨﺪ و ﺑﺎ ﺳﺨﺖاﻓﺰار ﻣﺸﺘﺮي ﺳﺎزﮔﺎر اﺳﺖ.‬‫اﻣﺮوزه ﺳﺎزﻣﺎنﻫﺎي ﻧﺮماﻓﺰاري زﻣﺎن و ﻣﻨﺎﺑﻊ زﯾﺎدي را در ﺗﺤﻠﯿﻞ و ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻـﺮف ﻣـﯽﮐﻨﻨـﺪ. از ﻧﻈـﺮ‬‫ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻧﻮﺷﺘﻦ ﮐﺪﻫﺎي ﺗﺴﺖ، ﺑﻪ ﺧﻮدي ﺧﻮد، ﻣﺜﻞ ﺗﻮﺳﻌﻪ ﺧﻮد ﻣﺤﺼﻮل وﻗﺖ ﮔﯿﺮ و ﮔﺮان اﺳﺖ.‬‫ﺑﻨﺎﺑﺮاﯾﻦ راهﺣﻠﯽ ﺑﺮاي ﺧﻮدﮐﺎر ﮐﺮدن ﺗﺴﺖ ﻧﺮم اﻓﺰار ﻏﯿﺮﻗﺎﺑﻞ اﺟﺘﻨﺎب اﺳﺖ. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﻧﺴﺒﺖ ﺑﻪ‬‫ﺗﺴﺖ دﺳﺘﯽ ﺑﺮﺗﺮيﻫﺎي زﯾﺎدي دارد. در ﺟﺎﻣﻌﻪ اﻣﺮوزي ﭘﺮوژهﻫﺎي ﻧﺮماﻓﺰاري ﭘﯿﭽﯿﺪه ﻫﺴﺘﻨﺪ و ﺑـﺮاي ﺣـﻞ‬‫ﻣﺴﺎﺋﻞ ﭘﯿﭽﯿﺪه ﻃﺮاﺣﯽ ﻣﯽﺷﻮﻧﺪ. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﺑﺎﻋﺚ ﻣﯽ ﺷﻮد ﮐﻪ ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن زﻣﺎن ﺑﯿـﺸﺘﺮي‬‫ﺑﺮاي ﺗﻤﺮﮐﺰ ﺑﺮروي دﯾﮕﺮ ﺟﻨﺒﻪﻫﺎ داﺷﺘﻪ ﺑﺎﺷﻨﺪ و ﺑﺘﻮاﻧﻨﺪ ﺧﻄﺎﻫﺎي ﻧـﺮماﻓـﺰار را ﺑـﻪ ﺻـﻮرت ﻣـﺆﺛﺮﺗﺮي رﻓـﻊ‬‫ﻧﻤﺎﯾﻨﺪ. ﻋﻼوه ﺑﺮاﯾﻦ، ازآﻧﺠﺎﯾﯽ ﮐﻪ ﺗﺴﺖﻫﺎ را ﻣﯽﺗﻮان در ﻫﺮ زﻣﺎن و ﺑﻪ ﻫﺮ ﺗﻌﺪاد دﻓﻌﺎﺗﯽ اﺟﺮا ﮐﺮد، ﻣﯽﺗـﻮان‬‫از ﺗﺴﺖﻫﺎي ﻗﺒﻠﯽ اﺳﺘﻔﺎدهي ﻣﺠﺪد ﻧﻤﻮد. و ﺑﻪ اﯾﻦ ﺗﺮﺗﯿﺐ ﮐﺎراﯾﯽ ﺗﺴﺖ را اﻓﺰاﯾﺶ و زﻣﺎن ﺗـﺴﺖ را ﮐـﺎﻫﺶ‬ ‫داد. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﻧﺮماﻓﺰار زﺣﻤﺖ و ﭘﯿﭽﯿﺪﮔﯽ اﻧﺠﺎم ﺗﺴﺖ را ﮐﺎﻫﺶ ﻣﯽدﻫﺪ.‬‫در اﯾﻦ ﻣﺘﻦ ﭘﺲ از اراﺋﻪي ﻣﻘﺪﻣﺎﺗﯽ در ﻣﻮرد ﺗﺴﺖ ﻧﺮماﻓﺰار و اﻫﻤﯿـﺖ ﺧﻮدﮐﺎرﺳـﺎزي ﺗـﺴﺖ ﻧـﺮماﻓـﺰار، ﺑـﻪ‬ ‫ﻣﻌﺮﻓﯽ و ﺑﺮرﺳﯽ وﯾﮋﮔﯽﻫﺎي اﺑﺰارﻫﺎي ﻣﺘﺪاول ﺗﺴﺖ ﻧﺮماﻓﺰار ﭘﺮداﺧﺘﻪ ﺷﺪه اﺳﺖ.‬
  3. 3. ‫‪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‬‬
  4. 4. 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- ﻣﺮاﺟﻊ‬
  5. 5. ‫‪V‬‬ ‫ﻓﻬﺮﺳﺖ ﺷﮑﻞﻫﺎ‬‫ﺷﮑﻞ 4-1- ‪29 ................. ................................................................ Selenium IDE‬‬‫ﺷﮑﻞ 4-2- ﻗﺎﻟﺐ ‪ HTML‬ﺑﺮاي ‪33 .................................................................. EMMA‬‬
  6. 6. ‫١‬ ‫ﻣﻘﺪﻣﻪاي ﺑﺮ ﻓﺮاﯾﻨﺪ ﺗﺴﺖ ﻧﺮماﻓﺰار‬ ‫1-‬‫ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪي اﺳﺖ ﮐﻪ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﮐﺎﻣﭙﯿﻮﺗﺮي را ﻣﺸﺨﺺ ﻣـﯽﮐﻨـﺪ. ﺗـﺴﺖ ﻧـﺮماﻓـﺰار ﺷـﺎﻣﻞ‬‫ﻓﺮاﯾﻨﺪ اﺟﺮاي ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﻫﺪف ﯾﺎﻓﺘﻦ ﺑﺎگﻫﺎي ﻧﺮماﻓﺰاري اﺳﺖ، اﻣﺎ ﻣﺤﺪود ﺑﻪ آن ﻧﯿـﺴﺖ.ﮐﯿﻔﯿـﺖ ﻣﻄﻠـﻖ‬‫ﻧﯿﺴﺖ، ﺑﻠﮑﻪ ﺑﺮاي اﻓﺮاد ﻣﺨﺘﻠﻒ ﻧﺴﺒﯽ اﺳﺖ. ﺑﺎ اﯾﻦ ﺗﺼﻮر، ﺗﺴﺖ ﮐﺮدن ﻫﺮﮔﺰ ﻧﻤﯽﺗﻮاﻧﺪ ﺻﺤﺖ ﻧـﺮماﻓﺰارﻫـﺎي‬‫ﮐﺎﻣﭙﯿﻮﺗﺮي دﻟﺨﻮاه را ﺑﻪ ﻃﻮر ﮐﺎﻣﻞ اﺛﺒﺎت ﮐﻨﺪ. ﯾﮏ ﻧﮑﺘﻪ ﻣﻬﻢ اﯾﻨﺴﺖ ﮐﻪ ﺗﺴﺖ ﻧﺮماﻓﺰار، ﺑﺎﯾﺪ از ﻧﻘﻄﻪ ﻧﻈﺮات‬‫ﻣﺨﺘﻠﻔﯽ از ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﻟﺤﺎظ ﺷﻮد، ﮐﻪ ﺑﺎ ﻫﻤﻪ ﺣﻮزهﻫﺎي ﻓﺮاﯾﻨﺪ ﺗﺠﺎري ﻫﻤﺮاه ﺑﺎﺷـﺪ ﻧـﻪ ﻓﻘـﻂ‬ ‫ﺣﻮزه ﻫﺎي ﺗﺴﺖ.‬‫ﺗﺴﺖ ﻧﺮماﻓﺰار ﻣﻤﮑﻦ اﺳﺖ ﺑﻪ ﻋﻨﻮان ﯾﮏ ﻗﺴﻤﺖ ﻣﻬﻢ از ﻓﺮاﯾﻨﺪ ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿـﺖ ﻧـﺮماﻓـﺰار ﺗﻠﻘـﯽ ﺷـﻮد. در‬‫ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﻣﺘﺨﺼﺼﺎن ﻓﺮاﯾﻨﺪ ﻧﺮماﻓﺰار و دﯾﺪﮔﺎه وﺳﯿﻊﺗﺮي روي ﻧﺮماﻓـﺰار و ﺗﻮﺳـﻌﻪ آن دارﻧـﺪ.‬‫آﻧﻬﺎ ﻓﺮاﯾﻨﺪ ﻣﻬﻨﺪﺳﯽ ﻧﺮماﻓﺰار را ﺑﺮرﺳﯽ ﻣﯽﮐﻨﻨﺪ و آن را ﺑﺮاي ﮐﺎﻫﺶ ﻣﯿﺰان ﺧﻄﺎﻫﺎي ﻣﻨﺠـﺮ ﺑـﻪ ﺷﮑـﺴﺖ،‬‫ﺗﻐﯿﯿﺮ ﻣﯽدﻫﻨﺪ. ﻋﻨﺼﺮ ﺗﻌﯿﯿﻦ ﮐﻨﻨﺪه ﻣﯿﺰان ﺷﮑﺴﺖ ﻗﺎﺑﻞ ﻗﺒﻮل، ﻣﺎﻫﯿﺖ ﻧﺮماﻓﺰار اﺳـﺖ. ﺑـﺎزي وﯾـﺪﺋﻮﯾﯽ ﮐـﻪ‬‫ﺑﺮاي ﺷﺒﯿﻪ ﺳﺎزي ﭘﺮواز ﯾﮏ ﻫﻮاﭘﯿﻤﺎ ﻃﺮاﺣﯽ ﺷﺪه، ﻣﻨﻄﻘﺎً ﺑﺎﯾﺪ ﻧﺴﺒﺖ ﺑﻪ ﻧﺮماﻓﺰاري ﮐﻪ ﺑﺮاي ﮐﻨﺘﺮل ﯾﮏ ﺧﻂ‬ ‫ﭘﺮواز واﻗﻌﯽ ﺑﻪ ﮐﺎر ﻣﯽرود ، ﺗﺤﻤﻞ ﺷﮑﺴﺖ ﺑﯿﺸﺘﺮي داﺷﺘﻪ ﺑﺎﺷﺪ.‬‫ﺷﮑﺴﺖ ﻧﺮماﻓﺰار از ﻃﺮﯾﻖ ﻓﺮاﯾﻨﺪﻫﺎي زﯾﺮ رخ ﻣﯽدﻫﺪ. ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ ﯾﮏ ﺧﻄﺎﯾﯽ را اﻧﺠﺎم ﻣـﯽدﻫـﺪ ﮐـﻪ‬‫ﻣﻨﺠﺮ ﺑﻪ ﯾﮏ ﺷﮑﺴﺖ در ﮐﺪ ﻣﻨﺒﻊ ﻧﺮماﻓﺰار ﻣﯽﺷﻮد. اﮔﺮ اﯾﻦ ﺧﻄﺎ ﮐﺎﻣﭙﺎﯾﻞ و اﺟﺮا ﺷـﻮد، در ﻣﻮﻗﻌﯿـﺖ ﻫـﺎي‬‫ﺧﺎﺻﯽ ﺳﯿﺴﺘﻢ ﻧﺘﺎﯾﺞ ﻧﺎدرﺳﺘﯽ ﺗﻮﻟﯿﺪ ﻣﯽﮐﻨﺪ ﮐﻪ ﻣﻨﺠﺮ ﺑﻪ ﺷﮑﺴﺖ ﻣﯽﺷﻮد. ﻟﺰوﻣﺎً ﻫﻤﻪ ﺧﻄـﺎ ﻫـﺎ ﻣﻨﺠـﺮ ﺑـﻪ‬‫ﺷﮑﺴﺖ ﻧﻤﯽﺷﻮﻧﺪ. ﺑﺮاي ﻣﺜﺎل ﺧﻄﺎﻫﺎ در ﮐﺪﻫﺎﯾﯽ ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﻫﺮﮔﺰ ﺑﻪ اﺟﺮاي آﻧﻬﺎ ﻧﻤﯽرﺳﺪ1. ﻫﺮﮔﺰ ﻣﻨﺠﺮ ﺑﻪ‬‫ﺷﮑﺴﺖ ﻧﺨﻮاﻫﺪ ﺷﺪ. ﯾﮏ ﺧﻄﺎ زﻣﺎﻧﯽ ﻣﻨﺠﺮ ﺑﻪ ﺷﮑﺴﺖ ﻣﯽﺷﻮد، ﮐﻪ ﻣﺤﯿﻂ ﺗﻐﯿﯿﺮ ﻣـﯽﮐﻨـﺪ. ﻣﺜـﺎﻟﯽ از اﯾـﻦ‬ ‫1 ‪dead code‬‬
  7. 7. ‫٢‬‫ﺗﻐﯿﯿﺮات در ﻣﺤﯿﻂ ﺷﺎﻣﻞ ﻧﺮماﻓﺰارﻫﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ در ﯾﮏ ﭘﻠﺘﻔﺮم ﺟﺪﯾﺪ ﺳﺨﺖ اﻓﺰاري ﯾـﺎ ﻧـﺮماﻓـﺰاري، ﯾـﺎ‬ ‫ﺗﻐﯿﯿﺮات در دادهﻫﺎي ﻣﻨﺒﻊ، ﯾﺎ ﺗﻌﺎﻣﻼت ﺑﺎ ﻧﺮماﻓﺰارﻫﺎي ﻣﺘﻔﺎوت اﺟﺮا ﻣﯽﺷﻮﻧﺪ.]1-10‪[Kan‬‬‫روﺷﻬﺎي ﻣﺨﺘﻠﻔﯽ ﺑﺮاي ﺗﺴﺖ ﻧﺮماﻓﺰار وﺟﻮد دارد . دوﺑﺎره ﺑﺮرﺳﯽ ﮐﺮدن و اﻣﺘﺤﺎﻧﺎت ﺳﺨﺖ و ﻣﻬﻢ ، ﺗﺴﺘﻬﺎي‬‫اﺳﺘﺎﺗﯿﮏ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮﻧﺪ، در ﺣﺎﻟﯿﮑﻪ اﺟﺮاي واﻗﻌﯽ ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﯾﮏ ﻣﺠﻤﻮﻋﻪ ﺗﺴﺖ داده ﺷﺪه در ﻣﺮﺣﻠﻪ ﺧﺎﺻﯽ‬ ‫از ﻓﺮاﯾﻨﺪ ﺗﻮﺳﻌﻪ، ﺗﺴﺖ ﭘﻮﯾﺎ ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد.‬ ‫اﻫﺪاف ﺗﺴﺖ‬‫"ﮔﻠﻦ ﻣﺎﯾﺰر" درﺑﺎره ﻧﺮماﻓﺰار ﭼﻨﺪ ﻗﺎﻋﺪه را ﺑﯿﺎن ﻣﯽ ﮐﻨﺪ ﮐﻪ ﺑﻪ ﺧﻮﺑﯽ ﺑﻪ ﻋﻨﻮان اﻫﺪاف ﺗﺴﺖ ﻋﻤﻞ ﻣﯽ ﮐﻨﺪ.‬ ‫‪ ‬ﺗﺴﺖ ﻓﺮآﯾﻨﺪ اﺟﺮاي ﺑﺮﻧﺎﻣﻪ ﺑﻪ ﻗﺼﺪ ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎﺳﺖ.‬ ‫‪ ‬ﻣﻮرد ﺗﺴﺖ ﺧﻮب، ﻣﻮردي اﺳﺖ ﮐﻪ اﺣﺘﻤﺎل ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎي ﮐﺸﻒ ﺷﺪه در آن، ﺑﺎﻻ ﺑﺎﺷﺪ.‬ ‫‪ ‬ﺗﺴﺖ ﻣﻮﻓﻖ، ﺗﺴﺘﯽ اﺳﺖ ﮐﻪ ﺧﻄﺎﻫﺎي ﮐﺸﻒ ﻧﺸﺪه را ﮐﺸﻒ ﻣﯽ ﮐﻨﺪ.‬‫اﻫﺪاف ﺑﺎﻻ ﻧﺸﺎﻧﮕﺮ ﯾﮏ ﺗﻐﯿﯿﺮ دﯾﺪﮔﺎه زﯾﺒﺎ ﻫﺴﺘﻨﺪ، و ﺑﺮﺧﻼف اﯾﻦ دﯾﺪﮔﺎه ﻋﺎﻣﯿﺎﻧﻪ ﮐﻪ ﺗﺴﺖ ﻣﻮﻓـﻖ، ﺗـﺴﺖي‬‫اﺳﺖ ﮐﻪ در آن ﺧﻄﺎﯾﯽ ﯾﺎﻓﺘﻪ ﻧﺸﻮد. اﮔﺮ ﺗﺴﺖ ﺑﺎ ﻣﻮﻓﻘﯿﺖ اﺟﺮا ﺷﻮد )ﻣﻄـﺎﺑﻖ اﻫـﺪاف ذﮐـﺮ ﺷـﺪه در ﺑـﺎﻻ(،‬‫ﺧﻄﺎﻫﺎي ﻧﺮماﻓﺰار را ﺑﺮ ﻣﻼ ﺧﻮاﻫﺪ ﻧﻤﻮد. ﺑﻪ ﻋﻨﻮان ﻣﺰﯾﺖ دوم، ﺗﺴﺖ ﻧﺸﺎن ﻣﯽ دﻫﺪ ﮐﻪ ﻋﻤﻠﮑﺮدﻫﺎي ﻧﺮماﻓﺰار‬‫ﻇﺎﻫﺮا" ﻣﻄﺎﺑﻖ ﻣﺸﺨﺼﻪ ﮐﺎر ﻣﯽ ﮐﻨﻨﺪ، و ﺧﻮاﺳﺘﻪ ﻫﺎي رﻓﺘﺎري و ﮐﺎراﯾﯽ ﻇﺎﻫﺮا" ﺑﺮآورده ﺷﺪه اﻧﺪ. ﺑﻪ ﻋﻼوه،‬‫داده ﻫﺎي ﺟﻤﻊ آوري ﺷﺪه ﺑﻪ ﻣﻮازات اﻧﺠﺎم ﺗﺴﺖ، ﺷﺎﺧﺺ ﺧﻮﺑﯽ از ﻗﺎﺑﻠﯿﺖ اﻃﻤﯿﻨﺎن ﻧﺮماﻓﺰار و ﺷﺎﺧﺼﯽ از‬‫ﮐﻠﯿ‪‬ﺖ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار ﺑﻪ دﺳﺖ ﻣﯽ دﻫﻨﺪ. وﻟﯽ ﺗﺴﺖ ﻧﻤﯽ ﺗﻮاﻧﺪ ﻧﺒﻮد ﺧﻄﺎﻫﺎ و ﻧﻘﺎﯾﺺ را ﺛﺎﺑـﺖ ﮐﻨـﺪ. ﺑﻠﮑـﻪ‬ ‫ﻓﻘﻂ ﻣﯽ ﺗﻮاﻧﺪ ﻧﺸﺎن دﻫﺪ ﮐﻪ ﺧﻄﺎﻫﺎ و ﻧﻘﺎﯾﺺ وﺟﻮد دارﻧﺪ.‬
  8. 8. ‫٣‬ ‫اﺻﻮل ﺗﺴﺖ‬‫ﻣﻬﻨﺪس ﻧﺮماﻓﺰار ﭘﯿﺶ از اﻋﻤﺎل روش ﻫﺎ در ﺧﺼﻮص ﻣﻮارد ﺗﺴﺖ ﻣﺆﺛﺮ، ﺑﺎﯾﺪ اﺻـﻮل ﭘﺎﯾـﻪ اي را ﮐـﻪ ﺗـﺴﺖ‬‫ﻧﺮماﻓﺰار را ﻫﺪاﯾﺖ ﻣﯽ ﮐﻨﻨﺪ، درك ﮐﻨﺪ. "دﯾﻮﯾﺲ" ﻣﺠﻤﻮﻋﻪ اي از اﺻﻮل ﭘﯿﺸﻨﻬﺎد ﻣﯽ ﮐﻨﺪ، ﮐﻪ در اﯾﻨﺠـﺎ از‬ ‫آﻧﻬﺎ اﺳﺘﻔﺎده ﺧﻮاﻫﯿﻢ ﮐﺮد:‬‫‪ ‬ﻫﻤﻪ ﺗﺴﺖ ﻫﺎ ﺑﺎﯾﺪ ﺗﺎ ﺣﺪ ﺧﻮاﺳﺘﻪ ﻫﺎي ﻣﺸﺘﺮي ﻗﺎﺑﻞ ردﯾﺎﺑﯽ ﺑﺎﺷﻨﺪ. ﭼﻨﺎﻧﮑﻪ دﯾﺪﯾﻢ، ﻫﺪف ﺗﺴﺖ‬‫ﻧﺮماﻓﺰار، ﮐﺸﻒ ﺧﻄﺎﻫﺎ اﺳﺖ. ﯾﻌﻨﯽ اﮐﺜﺮ ﻧﻘﺎﯾﺺ ﺷﺪﯾﺪ )از دﯾﺪﮔﺎه ﻣﺸﺘﺮي( آﻧﻬﺎﯾﯽ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎﻋﺚ‬ ‫ﻣﯽ ﺷﻮﻧﺪ ﺑﺮﻧﺎﻣﻪ ﻧﺘﻮاﻧﺪ ﺧﻮاﺳﺘﻪ ﻫﺎي ﺧﻮد را ﺑﺮآورده ﮐﻨﺪ.‬‫‪ ‬ﺗﺴﺖ ﺑﺎﯾﺪ ﻣﺪت ﻫﺎ ﻗﺒﻞ از ﺷﺮوع ﺗﺴﺖ، ﻃﺮح رﯾﺰي ﺷﻮد. ﻃﺮح رﯾﺰي ﺗﺴﺖ ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ‬‫ﻣﺤﺾ ﮐﺎﻣﻞ ﺷﺪن ﻣﺪل ﺧﻮاﺳﺘﻪ ﻫﺎ آﻏﺎز ﺷﻮد. ﺗﻌﺮﯾﻒ ﻣﺸﺮوح ﻣﻮارد ﺗﺴﺖ ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ ﻣﺤﺾ‬‫ﻣﻨﺴﺠﻢ ﺷﺪن ﻣﺪل ﻃﺮاﺣﯽ آﻏﺎز ﺷﻮد. ﺑﻨﺎﺑﺮاﯾﻦ، ﻫﻤﻪ ﺗﺴﺖ ﻫﺎ را ﻣﯽ ﺗﻮان ﭘﯿﺶ از ﺗﻮﻟﯿﺪ ﻫﺮ ﮔﻮﻧﻪ‬ ‫ﮐﺪ، ﺑﺮﻧﺎﻣﻪ رﯾﺰي و ﻃﺮاﺣﯽ ﮐﺮد.‬‫‪ ‬اﺻﻞ "ﭘﺎرﺗﻮ" در ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻﺪق ﻣﯽ ﮐﻨﺪ. ﺑﻪ ﻋﺒﺎرت ﺳﺎده، اﺻﻞ "ﭘﺎرﺗﻮ" ﺑﯿﺎن ﻣﯽ ﮐﻨﺪ‬‫ﮐﻪ 08 درﺻﺪ ﻫﻤﻪ ﺧﻄﺎﻫﺎي ﮐﺸﻒ ﺷﺪه ﻃﯽ ﺗﺴﺖ، اﺣﺘﻤﺎﻻ" در 02 درﺻﺪ ﻫﻤﻪ ﻣﺆﻟﻔﻪ ﻫﺎ ﺑﺮﻧﺎﻣﻪ‬ ‫ﻗﺎﺑﻞ ﮐﺸﻒ ﻫﺴﺘﻨﺪ. ﻣﺴﺌﻠﻪ، ﺟﺪا ﺳﺎزي ﻣﺆﻟﻔﻪ ﻫﺎي ﻣﻈﻨﻮن و آزﻣﻮدن ﮐﺎﻣﻞ آﻧﻬﺎﺳﺖ.‬‫‪ ‬ﺗﺴﺖ ﺑﺎﯾﺪ در اﺑﻌﺎد ﮐﻮﭼﮏ آﻏﺎز ﺷﻮد و ﺑﻪ اﺑﻌﺎد ﺑﺰرﮔﺘﺮ ﮔﺴﺘﺮش ﯾﺎﺑﺪ. اوﻟﯿﻦ ﺗﺴﺖ ﻫﺎ ﺑﺮروي‬‫ﻫﺮ ﯾﮏ از ﻣﺆﻟﻔﻪ ﻫﺎ اﻧﺠﺎم ﻣﯽ ﺷﻮﻧﺪ. ﺑﺎ ﭘﯿﺸﺮﻓﺖ ﺗﺴﺖ، ﺧﻄﺎﻫﺎي ﻣﺠﻤﻮﻋﻪ اي از ﻣﺆﻟﻔﻪ ﻫﺎي ﻣﺠﺘﻤﻊ‬ ‫و ﺳﭙﺲ ﮐﻞ ﺳﯿﺴﺘﻢ ﯾﺎﻓﺖ ﻣﯽ ﺷﻮد.‬‫‪ ‬ﺗﺴﺖ ﮐﺎﻣﻞ اﻣﮑﺎن ﭘﺬﯾﺮ ﻧﯿﺴﺖ. ﺗﻌﺪاد ﻣﺴﯿﺮﻫﺎي ﻣﻤﮑﻦ ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﻣﺘﻮﺳﻂ ﻧﯿﺰ زﯾﺎد اﺳﺖ. ﻟﺬا،‬‫اﺟﺮاي ﻫﺮ ﺗﺮﮐﯿﺒﯽ از ﻣﺴﯿﺮﻫﺎ اﻣﮑﺎن ﭘﺬﯾﺮ ﻧﯿﺴﺖ. وﻟﯽ اﯾﻦ اﻣﮑﺎن وﺟﻮد دارد ﮐﻪ ﺑﺮﻧﺎﻣﻪ را در ﺣﺪ‬ ‫ﮐﻔﺎﯾﺖ ﭘﻮﺷﺶ دﻫﯿﻢ.‬
  9. 9. ‫٤‬‫‪ ‬ﺑﺮاي آﻧﮑﻪ ﺗﺴﺖ ﺑﯿﺸﺘﺮﯾﻦ ﺑﺎزدﻫﯽ را داﺷﺘﻪ ﺑﺎﺷﺪ، ﺑﺎﯾﺪ ﺗﻮﺳﻂ ﯾﮏ ﺷﺨﺺ ﺛﺎﻟﺚ ﺑﯽ ﻃﺮف‬‫اﻧﺠﺎم ﺷﻮد. ﻣﻨﻈﻮر از ﺑﯿﺸﺘﺮﯾﻦ ﺑﺎزدﻫﯽ آن اﺳﺖ ﮐﻪ ﺧﻄﺎﻫﺎ را ﺑﺎ اﺣﺘﻤﺎل ﺑﯿﺸﺘﺮي ﺑﯿﺎﺑﺪ. ﺑﻪ دﻻﯾﻠﯽ‬‫ﮐﻪ ﻗﺒﻼ" در ﻫﻤﯿﻦ ﻓﺼﻞ ذﮐﺮ ﺷﺪ، ﻣﻬﻨﺪس ﻧﺮماﻓﺰاري ﮐﻪ ﺳﯿﺴﺘﻢ را اﯾﺠﺎد ﮐﺮده اﺳﺖ، ﺑﻬﺘﺮﯾﻦ‬ ‫ﮐﺴﯽ ﻧﯿﺴﺖ ﮐﻪ ﺑﺎﯾﺪ ﻫﻤﻪ ﺗﺴﺖ ﻫﺎ را اﻧﺠﺎم دﻫﺪ.‬
  10. 10. ‫٥‬ ‫اﻧﻮاع، روشﻫﺎ و ﺳﻄﻮح ﺗﺴﺖ‬ ‫2-‬ ‫اﻧﻮاع ﺗﺴﺖ‬‫ﺗﺴﺖﻫﺎي ﻣﺘﻨﻮﻋﯽ را ﻣﯽ ﺗﻮان ﺑﺮ روي ﺳﯿﺴﺘﻢ ﻫﺎ اﻋﻤﺎل ﻧﻤﻮد ﺗﺎ آﻧﺎن را از ﺟﻨﺒﻪ ﻫﺎي ﻣﺨﺘﻠﻒ ﻣﻮرد ﺗﺴﺖ و‬ ‫ﺗﺴﺖ ﻗﺮار داد. در اﯾﻦ ﺑﺨﺶ ﺑﻪ اﯾﻦ ﺗﺴﺖ ﻫﺎ اﺷﺎره ﻣﯽ ﺷﻮد وﻫﺮﯾﮏ را ﻣﺨﺘﺼﺮا ﺗﻮﺿﯿﺢ ﻣﯽ دﻫﯿﻢ.‬ ‫ﺗﺴﺖ ﻋﻤﻠﮑﺮد‬‫در اﯾﻦ ﻧﻮع ﺗﺴﺖ ، ﻧﺮماﻓﺰار ﺗﺴﺖ ﻣﯿﺸﻮد ﺗﺎ از ﻟﺤﺎظ درﺳﺘﯽ ﻋﻤﻠﮑﺮد ﺑﺮرﺳﯽ ﺷﻮد . ﺗﺴﺘﻬﺎ ﻧﻮﺷﺘﻪ ﻣﯿﺸﻮﻧﺪ ﺗﺎ‬‫ﺑﺒﯿﻨﻨﺪ ﮐﻪ اﯾﺎ ﻧﺮماﻓﺰار ﻫﻤﺎن ﮔﻮﻧﻪ ﮐﻪ اﻧﺘﻈﺎر ﻣﯿﺮود ﻋﻤﻞ ﻣﯿﮑﻨﺪ. اﮔﺮ ﭼﻪ ﺗﺴﺖ ﻋﻤﻠﮑـﺮد ﻣﻌﻤـﻮﻻً در اﻧﺘﻬـﺎي‬‫ﻓﺮاﯾﻨﺪ ﺗﻮﺳﻌﻪ اﻧﺠﺎم ﻣﯿﺸﻮد وﻟﯽ ﻣﯿﺘﻮاﻧﺪ –و ﺑﺎﯾﺪ – ﺳﺮﯾﻌﺘﺮ اﻏﺎز ﺷﻮد . ﮐﺎﻣﭙﻮﻧﻨﺖ ﻫـﺎ و ﻓﺮاﯾﻨـﺪ ﻫـﺎي ﻣﺠـﺰا‬ ‫ﻣﯿﺘﻮاﻧﻨﺪ ﺧﯿﻠﯽ ﺳﺮﯾﻌﺘﺮ اﻧﺠﺎم ﺷﻮﻧﺪ ، ﺣﺘﯽ زودﺗﺮ از اﯾﻨﮑﻪ ﺑﺘﻮان ﺗﺴﺖ ﻋﻤﻠﮑﺮد را روي ﺳﯿﺴﺘﻢ اﻧﺠﺎم داد .‬ ‫ﺗﺴﺖ اﺳﺘﺮس‬‫ﺑﺮﻧﺎﻣﻪ در ﻣﻘﺎﺑﻞ ﺑﺎر ﺳﻨﮕﯿﻦ ﻣﺜﻞ ﻣﻘﺎدﯾﺮ ﻋﺪدي ﭘﯿﭽﯿﺪه ، ﻣﻘﺎدﯾﺮ زﯾـﺎدي ورودي و ﻣﻘـﺎدﯾﺮ زﯾـﺎدي ﭘـﺮس و‬‫ﺟﻮ2 اﻣﺘﺤﺎن ﻣﯿﺸﻮد . ﮐﻪ ﻣﯿﺰان ﺑﺎري ﮐﻪ ﺑﺮﻧﺎﻣﻪ ﻣﯿﺘﻮاﻧﺪ ان را ﺗﺤﻤﻞ ﮐﻨﺪ را ﺑﺮرﺳﯽ ﻣﯿﮑﻨﺪ . ﻫﺪف ﻃﺮاﺣـﯽ‬‫ﻣﺤﯿﻄﯽ اﺳﺖ ﮐﻪ ﻣﺨﺮب ﺗﺮ از ﻣﺤﯿﻄﯽ ﮐﻪ ﺑﺮﻧﺎﻣﻪ در دﻧﯿﺎي واﻗﻌﯽ و در ﺷﺮاﯾﻂ ﻧﺮﻣﺎل ﺑـﺎ ان روﺑـﺮو ﻣﯿـﺸﻮد‬‫.اﯾﻦ ﻣﺴﺌﻠﻪ ﺳﺨﺖ ﺗﺮﯾﻦ و ﭘﯿﭽﯿﺪه ﺗﺮﯾﻦ ﻣﻘﻮﻟﻪ از ﺗﺴﺖ اﺳﺖ ﮐﻪ ﺑﺎﯾﺪ اﻧﺠﺎم ﺷﻮد و اﺣﺘﯿﺎج ﺑـﻪ ﺗـﻼش ﺗـﻮأم‬‫ﻫﻤﻪ ﺗﯿﻢ ﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ دارد . ﯾﮏ ﻣﺤﯿﻂ ﺗﺴﺖ ﺑـﺎ ﭼﻨـﺪﯾﻦ اﯾـﺴﺘﮕﺎه ﺗـﺴﺖ اﯾﺠـﺎد ﻣﯿـﺸﻮد و در ﻫـﺮ‬‫اﯾﺴﺘﮕﺎه ﯾﮏ اﺳﮑﺮﯾﭙﺖ ﺳﯿﺴﺘﻢ را ﺗﺴﺖ ﻣﯿﮑﻨﺪ .اﯾﻦ اﺳﮑﺮﯾﭙﺘﻬﺎ رو ﺑﻪ رﺷﺪ ﻫﺴﺘﻨﺪ و اﯾﺴﺘﮕﺎه ﻫﺎ ﻧﯿﺰ ﺑﺘـﺪرﯾﺞ‬‫اﻓﺰاﯾﺶ ﻣﯽﯾﺎﺑﻨﺪ و ﻫﻤﻪ ﺑﺼﻮرت ﻫﻤﺰﻣﺎن روي ﺳﯿﺴﺘﻢ ﻓﺸﺎر ﻣﯽاورﻧﺪ ﺗﺎ ﺳﯿﺴﺘﻢ ﻣﺘﻮﻗـﻒ ﺷـﻮد .ﺳﯿـﺴﺘﻢ را‬‫2‬ ‫‪query‬‬
  11. 11. ‫٦‬‫ﺗﻌﻤﯿﺮ ﻣﯿﮑﻨﻨﺪ و ﺗﺴﺖ اﺳﺘﺮس دوﺑﺎره اﻧﺠﺎم ﻣﯿﺸﻮد ﺗﺎ ﺳﯿﺴﺘﻢ ﺑﻪ ﺣﺪي از اﺳﺘﺮس ﺑﺮﺳﺪ ﮐـﻪ ﺑـﺎﻻﺗﺮ از ﺣـﺪ‬‫ﻣﻮرد اﻧﺘﻈﺎر ﻣﺸﺘﺮي ﺑﺎﺷﺪ . ﺷﺮاﯾﻂ رﻗﺎﺑﺖ 3 و رﺧﻨﻪ ﻫﺎي ﺣﺎﻓﻈﻪ 4 در ﺗﺴﺖ اﺳﺘﺮس ﭘﯿﺪا ﻣﯿﺸﻮﻧﺪ . ﺷﺮاﯾﻂ‬‫رﻗﺎﺑﺖ ﺗﻌﺎرﺿﯽ ﺑﯿﻦ ﺣﺪاﻗﻞ دو اﯾﺴﺘﮕﺎه ﺗﺴﺖ اﺳﺖ و ﻫﺮ ﺗﺴﺖ زﻣﺎﻧﯿﮑﻪ ﺑﻪ ﺗﻨﻬﺎﯾﯽ ﮐﺎر ﮐﻨﺪ ﺑﻪ درﺳـﺘﯽ ﮐـﺎر‬‫ﻣﯿﮑﻨﺪ .اﻣﺎ زﻣﺎﻧﯿﮑﻪ دو ﺗﺴﺖ ﺑﻪ ﺻﻮرت ﻣﻮازي ﮐﺎر ﮐﻨﻨﺪ ، ﯾﮑﯽ ﯾﺎ ﻫﺮ دو ﺗـﺴﺖ ﺷﮑـﺴﺖ ﻣﯿﺨﻮرﻧـﺪ . و اﯾـﻦ‬‫ﻣﻌﻤﻮﻻً ﺑﻪ ﺧﺎﻃﺮ ﯾﮏ ﻗﻔﻞ اﺳﺖ ﮐﻪ ﺑﻪ درﺳﺘﯽ ﻣﺪﯾﺮﯾﺖ ﻧﺸﺪه اﺳﺖ . ﯾﮏ رﺧﻨﻪ ﺣﺎﻓﻈﻪ زﻣﺎﻧﯽ رخ ﻣﯿﺪﻫﺪ ﮐﻪ‬‫ﯾﮏ ﺗﺴﺖ ، ﺣﺎﻓﻈﻪ ﺗﺨﺼﯿﺺ ﯾﺎﻓﺘﻪ را رﻫﺎ ﻣﯿﮑﻨﺪ و ﺑﻪ درﺳﺘﯽ ﺣﺎﻓﻈﻪ را ﺑﺮ ﻧﻤﯿﮕﺮداﻧﺪ . ﺑﻪ ﻧﻈﺮ ﺗﺴﺖ درﺳﺖ‬‫ﮐﺎر ﻣﯿﮑﻨﺪ ، اﻣﺎ ﺑﻌﺪ از ﻣﺪﺗﯽ اﺟﺮاي ﺗﺴﺖ ﺣﺎﻓﻈـﻪ در دﺳـﺘﺮس ﮐـﺎﻫﺶ ﭘﯿـﺪا ﻣﯿﮑﻨـﺪ و ﺳﯿـﺴﺘﻢ ﺷﮑـﺴﺖ‬ ‫ﻣﯿﺨﻮرد .‬ ‫ﺗﺴﺖ ﺑﺎر‬‫ﺑﺮﻧﺎﻣﻪ در ﻣﻘﺎﺑﻞ ﺑﺎر زﯾﺎد ﯾﺎ ورودي ﻫﺎ ﺗﺴﺖ ﻣﯿﺸﻮد ﻣﺜﻞ ﺗﺴﺖ وب ﺳﺎﯾﺘﻬﺎ ﺑﺮاي ﯾﺎﻓﺘﻦ ﻧﻘﺎﻃﯽ ﮐﻪ در ان ﻧﻘﺎط‬‫وب ﺳﺎﯾﺖ ﯾﺎ ﺑﺮﻧﺎﻣﻪ ﺷﮑﺴﺖ ﻣﯿﺨﻮرد و ﯾﺎ ﻧﻘﺎﻃﯽ ﮐﻪ در اﻧﻬﺎ ﮐﺎراﯾﯽ وب ﺳﺎﯾﺖ ﮐﺎ ﻫﺶ ﭘﯿﺪا ﻣﯿﮑﻨﺪ . ﺗـﺴﺖ‬‫ﺑﺎر در ﺳﻄﺢ ﺑﺎر از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷﺪه اي اﻧﺠﺎم ﻣﯿﺸﻮد،.‪ Error! Reference source not found‬ﻣﻌﻤـﻮﻻً‬‫ﺑﺎﻻﺗﺮﯾﻦ ﺑﺎري ﮐﻪ ﺳﯿﺴﺘﻢ ﻣﯿﺘﻮاﻧﺪ ﺑﭙﺬﯾﺮد، در ﺣﺎﻟﯿﮑﻪ ﻫﻨﻮز ﺑﻪ درﺳﺘﯽ ﮐﺎر ﻣﯿﮑﻨﺪ . ﺗﻮﺟﻪ ﮐﻨﯿﺪ ﮐﻪ ﺗﺴﺖ ﺑﺎر‬‫ﻧﻤﯽﺧﻮاﻫﺪ ﺳﯿﺴﺘﻢ را ﺑﺎ ﻓﺸﺎر اوردن از ﭘﺎ در اورد . اﻣﺎ ﻣﯿﺨﻮاﻫﺪ ﺳﯿﺴﺘﻢ را ﺑﻄﻮر ﭘﯿﻮﺳﺘﻪ زﯾﺮ ﺑﺎر ﻧﮕـﻪ دارد‬‫.در ﻣﻔﻬﻮم ﺗﺴﺖ ﺑﺎر ، ﺑﺎﯾﺪ ﻣﺠﻤﻮﻋﻪ داده ﻫﺎي زﯾﺎدي ﺑﺮاي ﺗﺴﺖ در دﺳﺘﺮس داﺷـﺘﻪ ﺑﺎﺷـﯿﻢ . ﺑﺎﮔﻬـﺎ ﻇﻬـﻮر‬‫ﻧﻤﯿﮑﻨﻨﺪ ﻣﮕﺮ اﯾﻨﮑﻪ ﺷﻤﺎ ﺑـﺎ ﻣﻮﺟﻮدﯾﺘﻬـﺎ ي ﺧﯿﻠـﯽ ﺑـﺰرگ ﻣﺜـﻞ ﻫـﺰاران ﮐـﺎرﺑﺮ در اﻧﺒـﺎر داده ﻫـﺎﯾﯽ ﻣﺜـﻞ‬‫‪ LDAP,NIS , Active directory‬ﮐﺎر ﮐﻨﯿﺪ و....ﺗﺴﺖ ﮐﻨﻨﺪ ﮔﺎن ﺑﻪ اﺑﺰار ﻫﺎي اﺗﻮﻣـﺎت ﺑـﺮاي اﯾﺠـﺎد اﯾـﻦ‬ ‫ﻣﺠﻤﻮﻋﻪ داده ﻫﺎي ﺑﺰرگ دارﻧﺪ .اﻣﺎ ﺧﻮﺷﺒﺨﺘﻨﻪ ﺑﺎ ﻫﺮ زﺑﺎن اﺳﮑﺮﯾﭙﺖ ﻧﻮﯾﺴﯽ ﻣﯿﺘﻮان اﯾﻦ ﮐﺎر را اﻧﺠﺎم داد .‬‫3‬ ‫‪Race condition‬‬‫4‬ ‫‪memory leaks‬‬
  12. 12. ‫٧‬ ‫ﺗﺴﺖ اﮐﺘﺸﺎﻓﯽ‬‫ﻣﺸﺎﺑﻪ ﺗﺴﺖ ﺑﺎﻟﺒﺪاﻫﻪ اﺳﺖ و ﺑﺮاي ﯾﺎدﮔﯿﺮي و ﮐﻨﮑﺎش ﻧﺮماﻓﺰار ﺻﻮرت ﻣﯿﮕﯿﺮد . وﯾﮏ روش ﻗـﻮي و ﺟﺎﻟـﺐ‬‫ﺑﺮاي ﺗﺴﺖ اﺳﺖ . در ﺑﻌﻀﯽ ﻣﻮاﻗﻊ ﻣﻤﮑﻨﻪ ﺗﺎ ﺣﺪودي ﻗﻮي ﺗﺮ از زﺑﺎنﻫﺎي اﺳـﮑﺮﯾﭙﺖ ﻧﻮﯾـﺴﯽ ﺑـﺮاي ﺗـﺴﺖ‬ ‫ﺑﺎﺷﺪ .‬ ‫ﺗﺴﺖ رﮔﺮﺳﯿﻮن‬‫ﺑﻌﺪ از ﺗﻐﯿﯿﺮ ﻧﺮماﻓﺰار ، ﺟﻪ ﺑﺮاي ﺗﻐﯿﯿﺮ در ﻋﻤﻠﮑﺮد ﯾﺎ ﺑﺮاي ﺗﺼﺤﯿﺢ ﯾﮏ ﺧﻄﺎ ، ﯾﮏ ﺗـﺴﺖ رﮔﺮاﺳـﯿﻮن ﺗﻤـﺎم‬‫ﺗﺴﺘﻬﺎﯾﯽ ﮐﻪ ﻗﺒﻼً ﻧﺮماﻓﺰار اﻧﻬﺎ را ﺑﺎ ﻣﻮﻓﻘﯿﺖ اﻧﺠﺎم داده را دوﺑﺎره اﺟﺮا ﻣﯿﮑﻨﺪ ﺗﺎ اﻃﻤﯿﻨـﺎن ﺣﺎﺻـﻞ ﮐﻨـﺪ ﮐـﻪ‬‫ﻧﺮماﻓﺰار ﺗﺼﺎدﻓﺎً در ﻋﻤﻠﮑﺮد ﻫﺎي ﻗﺒﻠﯽ دﭼﺎر ﺧﻄﺎ ﻧﺸﺪه اﺳﺖ .ﺗﺴﺖ رﮔﺮاﺳـﯿﻮن ﻣﯿﺘﻮاﻧـﺪ در ﻫـﯿﭻ ﯾـﺎ ﻫﻤـﻪ‬‫ﺳﻄﻮح ﻗﺒﻠﯽ ﺻﻮرت ﺑﮕﯿﺮد . اﯾﻦ ﺗﺴﺘﻬﺎي رﮔﺮاﺳﯿﻮن اﮐﺜﺮاً اﺗﻮﻣﺎت ﺷﺪه اﻧﺪ .اﻧـﻮاع ﺧـﺎص ﺗـﺮي از ﺗـﺴﺘﻬﺎي‬‫رﮔﺮاﺳﯿﻮن ﺑﺎ ﻋﻨﻮان ﺗﺴﺖ ﺳﻼﻣﺖ 5 ﺷﻨﺎﺧﺘﻪ ﺷﺪه اﻧﺪ و زﻣﺎﻧﯿﮑﻪ ﻣﺎ ﻣﯽﺧﻮاﻫﯿﻢ ﺳﺮﯾﻌﺎً رﻓﺘﺎر ﻋﺠﯿﺐ ﺳﯿﺴﺘﻢ‬ ‫را ﺑﺮرﺳﯽ ﮐﻨﯿﻢ . و ﯾﺎ ﺗﺴﺖ دود 6 زﻣﺎﻧﯿﮑﻪ ﻋﻤﻠﮑﺮد ﻫﺎي اﺑﺘﺪاﯾﯽ ﭼﮏ ﻣﯿﺸﻮﻧﺪ .‬‫ﺗﺴﺖ رﮔﺮاﺳﯿﻮن ﻧﻮﻋﯽ ﺗﺴﺖ ﮐﻪ ﺗﻤﺮﮐـﺰ روي ﺗـﺴﺖ ﻣﺠـﺪد ﺑﻌـﺪ از اﻋﻤـﺎل ﺗﻐﯿﯿـﺮات اﺳـﺖ . در ﺗـﺴﺘﻬﺎي‬‫رﮔﺮاﺳﯿﻮن ﻗﺪﯾﻤﯽ، ﯾﮏ ﺗﺴﺖ دوﺑﺎره ﺗﮑﺮار ﻣﯽﺷﺪ . اﻣﺎ در ﺗﺴﺘﻬﺎي رﮔﺮاﺳﯿﻮن رﯾﺴﮏ ﮔﺮا ، ﻣﺎ ﻧﻮاﺣﯽ ﻗﺒﻠﯽ‬‫را ﻣﺜﻞ ﻗﺒﻞ ﺗﺴﺖ ﻣﯿﮑﻨﯿﻢ اﻣﺎ از ﺗﺴﺘﻬﺎي ﻣﺘﻔﺎوﺗﯽ ﮐﻪ ﺑـﻪ ﺗـﺪرﯾﺞ ﭘﯿﭽﯿـﺪه ﺗـﺮ ﻣﯿـﺸﻮﻧﺪ اﺳـﺘﻔﺎده ﻣﯿﮑﻨـﯿﻢ‬ ‫.ﺗﺴﺘﻬﺎي رﮔﺮاﺳﯿﻮن ﻗﺪﯾﻤﯽ ﻣﻌﻤﻮﻻً ﺗﺎ ﺣﺪودي اﺗﻮﻣﺎت ﺑﻮدﻧﺪ .‬ ‫ﺗﺴﺖ رﮔﺮاﺳﯿﻮن ﻣﯿﺨﻮاﻫﺪ دو رﯾﺴﮏ را ﮐﺎﻫﺶ دﻫﺪ :‬ ‫ﺗﻐﯿﯿﺮي ﮐﻪ ﻣﯿﺒﺎﯾﺴﺖ ﯾﮏ ﺧﻄﺎ را ازﺑﯿﻦ ﻣﯿﺒﺮد ، ﺷﮑﺴﺖ ﻣﯿﺨﻮرد .‬‫ﺑﻌﻀﯽ ﺗﻐﯿﯿﺮات اﺛﺮ ﺟﺎﻧﺒﯽ دارﻧﺪ ، اﮔﺮ ﺗﺼﺤﯿﺢ ﻧﮑﻨﯿﺪ ﺧﻄﺎي ﻗﺒﻠﯽ ﺑﺎﻗﯽ ﻣﯽﻣﺎﻧﺪ و اﮔﺮ ﺗﺼﺤﯿﺢ ﮐﻨﯿﺪ ﺧﻄـﺎي‬ ‫ﺟﺪﯾﺪ اﯾﺠﺎد ﻣﯿﺸﻮد .‬‫5‬ ‫‪sanity testing‬‬‫6‬ ‫‪smoke testing‬‬
  13. 13. ‫٨‬ ‫ﺗﺴﺖ ﻗﺎﺑﻠﯿﺖ اﺳﺘﻔﺎده‬‫اﯾﻦ ﻧﻮع ﺗﺴﺖ ﺗﻨﻬﺎ در ﻣﻮاردي اﻧﺠﺎم ﻣﯿﺸﻮد ﮐﻪ راﺑﻂ ﮐﺎرﺑﺮ 7 ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﺧﯿﻠﯽ ﻣﻬﻢ ﺑﺎﺷﺪ و ﺑﺎﯾﺪ ﺑﺮاي ﻫـﺮ‬‫ﮐﺎرﺑﺮ، ﺧﺎص ﺑﺎﺷﺪ . ﺗﺴﺖ ﻗﺎﺑﻠﯿﺖ اﺳﺘﻔﺎده ، ﻓﺮاﯾﻨﺪ ﮐﺎر ﮐﺮدن ﻣﺴﺘﻘﯿﻢ ﯾﺎ ﻏﯿﺮ ﻣﺴﺘﻘﯿﻢ ﺑﺎ ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﺑﺮاي‬‫ﺷﻨﺎﺧﺖ اﯾﻨﮑﻪ ﭼﮕﻮﻧﻪ ﻫﺮ ﮐﺎرﺑﺮ ﯾﮏ ﺑﺴﺘﻪ ﻧﺮماﻓﺰاري را اﺣﺴﺎس ﻣﯿﮑﻨﺪ و ﭼﮕﻮﻧﻪ ﺑﺎ ان ﺗﻌﺎﻣـﻞ ﻣﯿﮑﻨـﺪ .اﯾـﻦ‬ ‫ﻓﺮاﯾﻨﺪ ﻧﻘﺎط ﻗﻮت و ﺿﻌﻒ ﺑﺮﻧﺎﻣﻪ را ﺑﺮاي ﮐﺎرﺑﺮان ﮐﺸﻒ ﻣﯿﮑﻨﺪ .‬‫ﺑﻨﺎﺑﺮ اﯾﻦ ﻫﺪف اﯾﻦ ﺗﺴﺖ، ﺷﻨﺎﺳﺎﯾﯽ ﻣﺸﮑﻼت ﻣﺮﺑﻮط ﺑﻪ ﻃﺮز اﺳﺘﻔﺎده ﺳﯿﺴﺘﻢ از دﯾﺪ ﮐﺎرﺑﺮان ﻣـﯽﺑﺎﺷـﺪ. در‬‫اﻧﺠﺎم اﯾﻦ ﺗﺴﺖ ﻓﺎﮐﺘﻮرﻫﺎي اﻧﺴﺎﻧﯽ ﮐﻪ ﻋﻤﺪﺗﺎ ‪ subjective‬ﻣﯽﺑﺎﺷﻨﺪ، ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﻣـﯽﮔﯿﺮﻧـﺪ و ﺑﻬﻤـﯿﻦ‬‫ﻋﻠﺖ اﻧﺠﺎم اﯾﻦ ﻧﻮع ﺗﺴﺖ ﻣﻌﻤﻮﻻ ﮐﺎر ﭘﯿﭽﯿﺪه اي اﺳﺖ ﮐﻪ در ﺑﺴﯿﺎري ﻗﺴﻤﺘﻬﺎي آن اﻣﮑـﺎن ﺧﻮدﮐﺎرﺳـﺎزي‬ ‫ﺗﺴﺖ ﻣﻮﺟﻮد ﻧﻤﯽﺑﺎﺷﺪ.]40‪[Mye79] [Mye‬‬ ‫ﺗﺴﺖ اﻣﻨﯿﺖ‬‫ﻃﺮاﺣﯽ و ﺗﺴﺖ ﺳﯿﺴﺘﻢﻫﺎي ﻧﺮماﻓﺰاري ﺑﺮاي اﻃﻤﯿﻨﺎن از اﯾﻤﻦ و ﻣﻄﻤﺌﻦ ﺑﻮدن ﺳﯿﺴﺘﻢ، ﻣـﺴﺄﻟﻪاي اﺳﺎﺳـﯽ‬‫اﺳﺖ ﮐﻪ ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن ﻧﺮماﻓﺰار و ﻣﺘﺨﺼﺼﺎن ﺗﺴﺖ ﺑﺎ آن ﻣﻮاﺟﻪ ﻫﺴﺘﻨﺪ. اﺧﯿﺮاً ﻣﺴﺄﻟﻪي اﯾﻤﻨﯽ و ﻣﻄﻤﺌﻦ‬‫ﺑﻮدن ﺑﻪ ﺧﺎﻃﺮ ازدﯾﺎد ﺑﺮﻧﺎﻣﻪﻫﺎي ﮐﺎرﺑﺮدي ﺗﺠﺎري ﺑﺮاي اﺳﺘﻔﺎده روي اﯾﻨﺘﺮﻧﺖ اﻫﻤﯿﺖ ﻣﺎزادي ﯾﺎﻓﺘـﻪ اﺳـﺖ.‬‫اﮔﺮ ﮐﺎرﺑﺮان اﯾﻨﺘﺮﻧﺖ اﻋﺘﻘﺎد داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﮐﻪ اﻃﻼﻋﺎت ﺷﺨﺼﯽ آﻧﻬﺎ اﯾﻤﻦ ﻧﯿﺴﺖ و ﺑﺮاي اﻓﺮاد ﻏﯿﺮﻣﺠﺎزي ﮐﻪ‬‫ﺑﺎ اﺳﺘﻔﺎده از اﯾﻨﺘﺮﻧﺖ آﺳﯿﺐ ﻣﯽرﺳﺎﻧﻨﺪ ﻗﺎﺑﻞ دﺳﺘﺮﺳﯽ اﺳـﺖ، آﯾﻨـﺪهي ﺗﺠـﺎرت اﻟﮑﺘﺮوﻧﯿﮑـﯽ ﺑـﻪ ﻣﺨـﺎﻃﺮه‬‫ﻣﯽاﻓﺘﺪ. ﺗﺴﺖ اﻣﻨﯿﺖ وﯾﮋﮔﯽﻫﺎﯾﯽ از ﺳﯿﺴﺘﻢ ﮐﻪ ﺑﻪ دردﺳﺘﺮس ﺑﻮدن، ﯾﮑﭙﺎرﭼﮕﯽ و ﻣﺤﺮﻣﺎﻧﻪ ﺑﻮدن داده ﻫﺎ و‬‫ﺧﺪﻣﺎت ﺳﯿﺴﺘﻢ ﻣﺮﺗﺒﻂ اﺳﺖ را ارزﯾﺎﺑﯽ ﻣﯽﮐﻨﺪ. ﮐﺎرﺑﺮان/ﻣﺸﺘﺮﯾﺎن ﺑﺎﯾﺪ ﺗﻮﺳﻂ اﯾﻦ ﻣﻮﺿﻮع ﺗﺮﻏﯿﺐ ﺷﻮﻧﺪ ﮐﻪ‬‫ﻧﯿﺎزﻫﺎي اﻣﻨﯿﺘﯽ آﻧﺎن در زﻣﺎن ﺗﻌﯿﯿﻦ ﻧﯿﺎزﻣﻨﺪيﻫﺎ ﮐﺎﻣﻼً ﻣﺸﺨﺺ اﺳﺖ، و ﺑﻨـﺎﺑﺮاﯾﻦ ﻣـﺴﺎﺋﻞ اﻣﻨﯿﺘـﯽ ﺗﻮﺳـﻂ‬ ‫ﻃﺮاﺣﺎن و آزﻣﺎﯾﻨﺪﮔﺎن ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﻣﯽﮔﯿﺮد. ]30‪[BUR‬‬‫7‬ ‫‪User interface‬‬
  14. 14. ‫٩‬‫ﻫﺪف ﺗﺴﺖ اﻣﻨﯿﺖ ﺑﺮرﺳﯽ ﮐﺎراﯾﯽ ﻣﮑﺎﻧﯿﺰمﻫﺎي دﻓـﺎﻋﯽ ﺳﯿـﺴﺘﻢ وب در ﻣﻘﺎﺑـﻞ دﺳﺘﺮﺳـﯽﻫـﺎي ﻧـﺎﻣﻄﻠﻮب‬‫ﮐﺎرﺑﺮان ﺑﺪون ﻣﺠﻮز و ﺣﻔﻆ ﻣﻨﺎﺑﻊ ﺳﯿﺴﺘﻢ در ﻣﻘﺎﺑﻞ ﮐـﺎرﺑﺮان ﻧﺎﺷﺎﯾـﺴﺖ، و ﻫﻤﭽﻨـﯿﻦ دادن دﺳﺘﺮﺳـﯽ ﺑـﻪ‬‫ﮐﺎرﺑﺮاﻧﯽ ﮐﻪ ﻣﺠﻮز دارﻧﺪ، ﻣﯽﺑﺎﺷﺪ. آﺳﯿﺐﭘﺬﯾﺮيﻫﺎي ﺳﯿﺴﺘﻢ ﮐﻪ ﺑﺮ روي اﻣﻨﯿﺖ ﺳﯿـﺴﺘﻢ ﺗـﺄﺛﯿﺮ ﻣـﯽﮔـﺬارد‬‫ﻣﻤﮑﻦ اﺳﺖ ﻣﻨﺸﺄ در ﮐﺪ ﺑﺮﻧﺎﻣﻪ داﺷﺘﻪ ﺑﺎﺷﻨﺪ ﯾﺎ در ﮐﺎﻣﭙﻮﻧﻨﺖﻫﺎي ﺳﺨﺖاﻓﺰاري، ﻧﺮماﻓﺰاري ﯾﺎ ﻣﯿـﺎناﻓـﺰاري‬‫ﺳﯿﺴﺘﻢ. ﻫﺮدوي ﻣﺤﯿﻂ اﺟﺮا و ﻫﻤﭽﻨﯿﻦ ﺑﺮﻧﺎﻣﻪ ﻣﻤﮑﻦ اﺳﺖ در ﻧﻘﺺﻫﺎي اﻣﻨﯿﺘﯽ دﺧﯿـﻞ ﺑﺎﺷـﻨﺪ. در ﻣـﻮرد‬‫ﻧﺮماﻓﺰار ﻫﺎي ﻣﺒﺘﻨﯽ ﺑﺮ وب ﭘﯿﺎده ﺳﺎزيﻫﺎ و ﺗﮑﻨﻮﻟﻮژيﻫﺎي اﺟﺮاﯾﯽ ﻧـﺎﻫﻤﮕﻦ ﻫﻤـﺮاه ﺑـﺎ ﺗﻌـﺪاد ﺑـﺴﯿﺎر زﯾـﺎد‬‫ﮐﺎرﺑﺮان و ﻫﻤﭽﻨﯿﻦ اﻣﮑﺎن دﺳﺘﺮﺳﯽ آﻧﺎن از ﻫﺮ ﺟﺎﯾﯽ، اﯾﻦ ﺑﺮﻧﺎﻣﻪ ﻫـﺎ را از ﺑﺮﻧﺎﻣـﻪﻫـﺎي ﮐـﺎرﺑﺮدي ﻣﻌﻤـﻮﻟﯽ‬ ‫آﺳﯿﺐﭘﺬﯾﺮﺗﺮ ﺗﺴﺖ اﻣﻨﯿﺖ آﻧﻬﺎ را ﺳﺨﺖﺗﺮ ﻣﯽﺳﺎزد.‬‫ﺷﺶ ﻣﻔﻬﻮم اﺳﺎﺳﯽ اﻣﻨﯿﺖ ﮐﻪ ﺑﺎﯾﺪ در ﺗﺴﺖ اﻣﻨﯿﺖ ﭘﻮﺷﺶ داده ﺷﻮد ﺑﻪ اﯾـﻦ ﺷـﺮحاﻧـﺪ: ﻣﺤﺮﻣﺎﻧـﻪ ﺑـﻮدن،‬ ‫ﺟﺎﻣﻌﯿﺖ، ﺗﺼﺪﯾﻖ ﻫﻮﯾﺖ8، ﻣﺠﻮز دادن9، در دﺳﺘﺮس ﺑﻮدن و ﻋﺪم اﻧﮑﺎر.‬ ‫ﺗﺴﺖ ﭘﻮﺷﺶ‬‫ﺗﺴﺖ ﭘﻮﺷﺶ ﺑﻪ دو دﺳﺘﻪ ﮐﻠﯽ ﭘﻮﺷﺶ ﻋﺒﺎرات 01 و ﭘﻮﺷﺶ اﻧﺸﻌﺎﺑﺎت 11 ﻣﯽ ﺗﻮان ﺗﻘـﺴﯿﻢ ﻧﻤـﻮد. در ﺗـﺴﺖ‬‫ﭘﻮﺷﺶ ﻋﺒﺎرات، ﮐﺪ ﻃﻮري اﺟﺮا ﻣﯿﺸﻮد ﮐﻪ ﻫﺮ ﻋﺒﺎرﺗﯽ از ﺑﺮﻧﺎﻣﻪ ﺣﺪاﻗﻞ ﯾﮑﺒﺎر اﺟﺮا ﺷﻮد و اﯾﻦ ﺑﺎﻋﺚ ﻣﯿﺸﻮد‬ ‫ﺑﻔﻬﻤﯿﻢ ﻫﻤﻪ ﺟﻤﻼت ﺑﺪون اﺛﺮ ﺟﺎﻧﺒﯽ اﺟﺮا ﻣﯿﺸﻮﻧﺪ.‬‫از آﻧﺠﺎﺋﯿﮑﻪ ﻫﯿﭻ ﺑﺮﻧﺎﻣﻪ ﻧﺮماﻓﺰاري ﻧﻤﯿﺘﻮاﻧﺪ در ﻣﺪ ﭘﯿﻮﺳﺘﻪ اي از ﮐﺪ اﺟﺮا ﺷﻮد، در ﺑﻌﻀﯽ از ﻧﻘﺎط ﻧﯿﺎز اﺳﺖ‬‫ﮐﻪ ﺑﺮاي ﯾﮏ ﻋﻤﻠﮑﺮد ﺧﺎص ﺑﻪ ﻧﻘﻄﻪ اي ﺧﺎرج از ﮐﺪ اﻧﺸﻌﺎب ﮐﻨﯿﻢ. ﺗﺴﺖ ﭘﻮﺷﺎﻧﺪن اﻧﺸﻌﺎﺑﺎت ﮐﻤﮏ ﻣﯿﮑﻨـﺪ‬‫ﮐﻪ ﻫﻤﻪ اﻧﺸﻌﺎﺑﺎت در ﮐﺪ را ارزﯾﺎﺑﯽ ﮐﻨﯿﻢ و اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﮐﻨﯿﻢ ﮐﻪ ﻫﯿﭻ اﻧﺸﻌﺎﺑﯽ در ﮐﺪ ﻣﻨﺠﺮ ﺑـﻪ رﻓﺘـﺎر‬ ‫ﻏﯿﺮ ﻧﺮﻣﺎل در ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي ﻧﻤﯿﺸﻮد.‬‫8‬ ‫‪Authentication‬‬‫9‬ ‫‪Authorization‬‬‫01‬ ‫‪statement coverage‬‬‫11‬ ‫‪Branch Coverage‬‬
  15. 15. ‫٠١‬ ‫روشﻫﺎي ﺗﺴﺖ‬‫ﻃﺮاﺣﯽ ﺗﺴﺖﻫﺎﯾﯽ ﺑﺮاي ﻧﺮماﻓﺰار و ﻫﺮ ﻣﺤﺼﻮل ﻣﻬﻨﺪﺳﯽ دﯾﮕﺮ، ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ اﻧﺪازه ﻃﺮاﺣﯽ ﺧـﻮد ﻣﺤـﺼﻮل‬‫اوﻟﯿﻪ دﺷﻮار ﺑﺎﺷﺪ. ﺑﺎ اﯾﻦ ﺣﺎل ﺑﻪ دﻻﯾﻠﯽ ﮐﻪ ﭘﯿﺶ از اﯾﻦ ﺑﺤﺚ ﺷﺪ، ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻏﺎﻟﺒﺎ" ﺑـﺎ ﺗـﺴﺖ ﺑـﻪ‬‫ﻋﻨﻮان ﻣﻮارد ﺗﺴﺖ در ﺣﺎل ﺗﻮﺳﻌﻪ اي رﻓﺘﺎر ﻣﯽ ﮐﻨﻨﺪ، ﮐﻪ ﻣﻤﮑﻦ اﺳﺖ درﺳﺖ ﺑﻪ ﻧﻈﺮ آﯾﻨﺪ، وﻟـﯽ از ﮐﺎﻣـﻞ‬‫ﺑﻮدن آﻧﻬﺎ ﭼﻨﺪان اﻃﻤﯿﻨﺎﻧﯽ ﻧﺒﺎﺷﺪ. ﺑﺎ ﺑﺨﺎﻃﺮ داﺷﺘﻦ اﻫﺪاف ﺗﺴﺖ، ﺑﺎﯾﺪ ﺗﺴﺖ ﻫـﺎﯾﯽ را ﻃﺮاﺣـﯽ ﮐﻨـﯿﻢ ﮐـﻪ‬‫اﺣﺘﻤﺎل ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎ در ﺣﺪاﻗﻞ زﻣﺎن، ﺑﯿﺸﺘﺮ ﺑﺎﺷﺪ. ﻫﺮ ﻣﺤﺼﻮل ﻣﻬﻨﺪﺳﯽ )و اﮐﺜﺮ ﭼﯿﺰﻫﺎي دﯾﮕـﺮ( را ﻣـﯽ‬ ‫ﺗﻮان ﺑﻪ ﯾﮑﯽ از دو روش آزﻣﺎﯾﺶ ﮐﺮد:‬‫ﺑﺎ داﻧﺴﺘﻦ ﻋﻤﻠﮑﺮد ﺧﺎﺻﯽ ﮐﻪ ﻧﺮم اﻓﺰار ﺑﺮاي اﻧﺠﺎم آن ﻃﺮاﺣﯽ ﺷﺪه اﺳﺖ، ﻣﯽ ﺗﻮان ﺗـﺴﺖ ﻫـﺎﯾﯽ ﻃﺮاﺣـﯽ‬‫ﮐﺮد ﮐﻪ ﻧﺸﺎن ﻣﯽ دﻫﻨﺪ ﻫﺮ ﻋﻤﻠﮑﺮد ﺑﻪ ﻃﻮر ﮐﺎﻣﻞ درﺳﺖ اﺳﺖ، و در ﻋﯿﻦ ﺣﺎل، در ﻫﺮ ﻋﻤﻠﮑـﺮد ﺑـﻪ دﻧﺒـﺎل‬ ‫ﯾﺎﻓﺘﻦ ﺧﻄﺎﻫﺎ ﻫﺴﺘﻨﺪ.‬‫ﺑﺎ داﻧﺴﺘﻦ ﻃﺮز ﮐﺎر داﺧﻠﯽ ﻣﺤﺼﻮل، ﻣﯽ ﺗﻮان ﺗﺴﺖ ﻫﺎﯾﯽ ﺗﺮﺗﯿﺐ داد ﮐﻪ اﻃﻤﯿﻨﺎن دﻫﻨﺪ ﻫﻤﻪ ﭼﯿﺰ ﺟﻔـﺖ و‬‫ﺟﻮر اﺳﺖ. ﯾﻌﻨﯽ، ﻋﻤﻠﯿﺎت داﺧﻠﯽ ﻃﺒﻖ ﻣﺸﺨﺼﻪ اﺟﺮا ﻣﯽ ﺷﻮﻧﺪ و ﺑﺎ ﻫﻤﻪ ﻣﺆﻟﻔﻪ ﻫﺎي داﺧﻠﯽ ﺑﻪ ﻃﻮر ﻣﻨﺎﺳﺐ‬ ‫ﺗﻤﺮﯾﻦ ﺷﺪه اﺳﺖ.‬‫روش اول را ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه و دوﻣﯽ را ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻣﯽ ﻧﺎﻣﻨﺪ. در ﺳﺎﻟﻬﺎي اﺧﯿﺮ ﯾﮏ روش ﺑﯿﻨﺎﺑﯿﻨﯽ‬‫ﻫﻢ ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﮔﺮﻓﺘﻪ اﺳﺖ ﮐﻪ در ﻣﻮاﻗﻌﯽ ﮐﻪ دﺳﺘﺮﺳﯽ ﺑﻪ ﺑﺮﺧﯽ از ﻣﻮﻟﻔﻪ ﻫﺎي داﺧﻠـﯽ ﻧـﺮماﻓـﺰار ﻫـﺎ‬‫دارﯾﻢ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﯽ ﮔﯿﺮد. ﯾﻪ اﯾﻦ روس ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻣـﯽ ﮔﻮﯾﻨـﺪ. در اﯾـﻦ ﺑﺨـﺶ اﯾـﻦ‬ ‫روﺷﻬﺎ را ﺑﻪ ﺗﻔﺼﺒﯿﻞ ﺷﺮح ﻣﯽ دﻫﯿﻢ.‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه‬‫اﯾﻦ ﻧﻮع از ﺗﺴﺖ ﺑﺎ ﻧﺮماﻓﺰار ﺑﻪ ﻋﻨﻮان ﯾﮏ ﺟﻌﺒﻪ ﺳﯿﺎه ﺑﺮﺧﻮرد ﻣﯿﮑﻨﻨﺪ ﮐﻪ ﻫﯿﭻ درﮐـﯽ از رﻓﺘـﺎر داﺧﻠـﯽ ان‬‫وﺟﻮد ﻧﺪارد . ﻫﺪف ان ﺗﺴﺖ ﮐﺮدن ﻋﻤﻠﮑﺮد ﻧﺮماﻓﺰار ﻣﻄﺎﺑﻖ ﺑﺎ ﻧﯿﺎزﻣﻨﺪﯾﻬﺎﺳﺖ ، ﺗـﺎ ﺑﺒﯿﻨـﺪ ﮐـﻪ ﺗـﺎ ﭼـﻪ ﺣـﺪ‬
  16. 16. ‫١١‬‫ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ذﮐﺮ ﺷﺪه ﺑﺮاورده ﻣﯿﺸﻮﻧﺪ.ﺑﻨﺎﺑﺮاﯾﻦ ﻃﺮاح ﺗﺴﺖ داده ﻫـﺎ را وارد ﻣﯿﮑﻨـﺪ و ﺧﺮوﺟـﯽ را از ﺷـﯽ؛‬‫ﺗﺴﺖ ﻣﯽﺑﯿﻨﺪ.ﺑﺮاي اﯾﻦ ﺳﻄﺢ از اﺟﺮاي ﺗﺴﺖ ، ﻧﯿﺎز اﺳﺖ ﺗﺎ ﻃﺮاح ﺗﺴﺖ ، ﻣﻮارد ﺗﺴﺖ ﻃﺮاﺣـﯽ ﺷـﺪه را ﺑـﻪ‬‫ﺗﺴﺖ ﮐﻨﻨﺪه ،ﮐﺴﯽ ﮐﻪ ﺑﺎﯾﺪ ﺑﺮرﺳﯽ ﮐﻨﺪ ﮐﻪ اﯾﺎ ﺑﺮاي ﯾﮏ ورودي ﺧﺎص ، ﻣﻘﺪار ﺧﺮوﺟﯽ ﯾﺎ رﻓﺘـﺎر ﺳﯿـﺴﺘﻢ ،‬‫ﻣﻨﻄﺒﻖ ﺑﺮ اﻧﭽﻪ ﻣﻮرد اﻧﺘﻈﺎر اﺳﺖ و در ﻣﻮرد ﺗﺴﺖ ذﮐﺮ ﺷﺪه ﻫﺴﺖ ﯾﺎ ﻧﻪ .ﺑﺮاي ﻃﺮاﺣـﯽ ﻣـﻮارد ﺗـﺴﺖ ﯾـﮏ‬‫دﯾﺪﮔﺎه ﺧﺎرﺟﯽ از ﺳﯿﺴﺘﻢ ﻣﯿﮕﯿﺮد و اﯾﻦ ﻧﻮع ﺗﺴﺘﻬﺎ ﻣﯿﺘﻮاﻧﻨﺪ ﻋﻤﻠﮑﺮدي 21 ﯾﺎ ﻏﯿﺮ ﻋﻤﻠﮑﺮدي31 ﺑﺎﺷﻨﺪ ﮐـﻪ‬‫ﻣﻌﻤﻮﻻً ﻋﻤﻠﮑﺮدي ﻋﻤﻞ ﻣﯿﮑﻨﻨﺪ . ﻃﺮاﺣﺎن ﺗﺴﺖ ورودﯾﻬﺎي ﻣﻌﺘﺒﺮ و ﻏﯿﺮ ﻣﻌﺘﺒﺮ را اﻧﺘﺨﺎب ﻣﯿﮑﻨﻨﺪ و ﺧﺮوﺟﯽ‬ ‫درﺳﺖ را اﻧﺘﺨﺎب ﻣﯿﮑﻨﻨﺪ . و ﻫﯿﭻ داﻧﺸﯽ از ﺳﺎﺧﺘﺎر داﺧﻠﯽ ﺷﯽء در دﺳﺘﺮس ﻧﯿﺴﺖ.]50‪[PRE‬‬‫اﯾﻦ روش از ﻃﺮاﺣﯽ ﺗﺴﺖ در ﻫﻤﻪ ﻣﺮاﺣﻞ از ﺗﺴﺖ ﻧﺮماﻓـﺰار ﻗﺎﺑـﻞ اﺳـﺘﻔﺎده اﺳـﺖ . ﺗـﺴﺖ واﺣـﺪ و ﺗـﺴﺖ‬‫ﯾﮑﭙﺎرﭼﮕﯽ و ﺗﺴﺖ ﻋﻤﻠﮑﺮد و ﺗﺴﺖ ﺳﯿﺴﺘﻢ و ﺗﺴﺖ ﭘﺬﯾﺮش .ﺑﺎﻻﺗﺮﯾﻦ ﺳﻄﺢ و ﺑﺎﻟﻄﺒﻊ ﺑﺰرﮔﺘﺮﯾﻦ و ﭘﯿﭽﯿـﺪه‬‫ﺗﺮﯾﻦ ﺟﻌﺒﻪ ﺑﺎﯾﺪ ﺑﺼﻮرت ﺟﻌﺒﻪ ﺳﯿﺎه ﺻﻮرت ﮔﯿﺮد ﺗﺎ ﺳﺎده ﺗﺮ ﺷﻮد.ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه ﮐﻪ ﺗـﺴﺖ رﻓﺘـﺎري ﻧﯿـﺰ‬‫ﻧﺎﻣﯿﺪه ﻣﯿﺸﻮد روي ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻋﻤﻠﮑﺮدي ﻧﺮماﻓﺰار ﺗﻤﺮﮐﺰ ﻣﯿﮑﻨﺪ.ﺗﺴﺖ ﺟﻌﺒﻪ ﺳـﯿﺎه اﺳـﺖ ﮐـﻪ ﻣﻬﻨﺪﺳـﺎن‬‫ﻧﺮماﻓﺰار را ﻗﺎدر ﻣﯿﮑﻨﺪ ﺗﺎ ﻣﺠﻤﻮﻋﻪ اي از ﺷﺮاﯾﻂ ورودي را ﻣﺸﺘﻖ ﮐﻨﻨـﺪ ﮐـﻪ ﺗـﺎ ﮐـﺎﻣﻼً ﻫﻤـﻪ ﻧﯿﺎزﻣﻨـﺪﯾﻬﺎي‬‫ﻋﻤﻠﮑﺮدي ﺑﺮﻧﺎﻣﻪ را ﻣﻮرد ﺑﺮرﺳﯽ ﻗﺮار دﻫﻨﺪ.ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎ ه ﯾﮏ ﺟﺎﯾﮕﺰﯾﻦ ﺑﺮاي ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻧﯿﺴﺖ‬‫ﺑﻠﮑﻪ ﯾﮏ روش ﻣﮑﻤﻞ ﮐﻪ ﯾﮏ ﮐﻼس ﻣﺘﻔﺎوﺗﯽ از ﺧﻄﺎ ﻫﺎ را ﻧﺴﺒﺖ ﺑﻪ روﺷﻬﺎي ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﭘﻮﺷﺶ ﻣﯿﺪﻫﺪ.‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ‬‫زﻣﺎﻧﯽ ﻣﻤﮑﻦ اﺳﺖ ﮐﻪ ﺗﺴﺖ ﮐﻨﻨﺪه ﺑﻪ ﺳﺎﺧﺘﺎر داده ﻫﺎي داﺧﻠﯽ و ﮐﺪ و اﻟﮕﻮرﯾﺘﻢ ﻫﺎ دﺳﺘﺮﺳﯽ دارد.روﺷﻬﺎي‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﺷﺎﻣﻞ اﯾﺠﺎد ﺗﺴﺘﻬﺎﯾﯽ اﺳﺖ ﮐﻪ ﺑﻌﻀﯽ از ﻣﻌﯿﺎرﻫﺎي ﭘﻮﺷﺶ ﮐﺪ41 را ﺑـﺮاورده ﻣﯿﮑﻨﻨـﺪ .‬‫ﺑﺮاي ﻣﺜﺎل ﻃﺮاح ﺗﺴﺖ ﻣﯿﺘﻮاﻧﺪ ﺗﺴﺘﻬﺎﯾﯽ را ﻃﺮاﺣﯽ ﮐﻨﺪ ﮐﻪ ﺑﺎﻋﺚ ﺷﻮد ﻫﻤﻪ ﻋﺒﺎرات ﺑﺮﻧﺎﻣﻪ ﺣﺎﻗﻞ ﯾﮑﺒﺎر اﺟﺮا‬‫21‬ ‫‪functional‬‬‫31‬ ‫‪non functional‬‬‫41‬ ‫‪code coverage‬‬
  17. 17. ‫٢١‬‫ﺷﻮﻧﺪ.ﺳﺎﯾﺮ ﻣﺜﺎﻟﻬﺎي ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻋﺒﺎرﺗﻨﺪ از ﺗﺴﺖ ﺟﻬﺶ 51 و روﺷﻬﺎي ﺗﺰرﯾـﻖ ﺧﻄـﺎ 61 . ﺗـﺴﺘﻬﺎي‬ ‫ﺟﻌﺒﻪ ﺳﻔﯿﺪ ، ﻫﻤﻪ ﺗﺴﺘﻬﺎي اﺳﺘﺎﺗﯿﮏ را ﺷﺎﻣﻞ ﻣﯿﺸﻮﻧﺪ.]50‪[PRE‬‬‫روﺷﻬﺎي ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻣﯿﺘﻮاﻧﻨﺪ ﺑﺮاي ارزﯾﺎﺑﯽ ﮐﺎﻣﻞ ﺑﻮدن ﯾﮏ ﻣﺠﻤﻮﻋﻪ ﺗﺴﺖ - ﮐﻪ ﺑﺎ روﺷـﻬﺎي ﺗـﺴﺖ‬‫ﺟﻌﺒﻪ ﺳﯿﺎه اﯾﺠﺎد ﺷﺪه اﻧﺪ-ﻧﯿﺰ ﺑﻪ ﮐﺎر رود.اﯾﻦ ﺑﻪ ﺗﯿﻢ ﻧﺮماﻓﺰاري اﺟﺎزه ﻣﯿﺪﻫﺪ ﮐﻪ ﻗـﺴﻤﺘﻬﺎﯾﯽ از ﺳﯿـﺴﺘﻢ را‬‫ارزﯾﺎﺑﯽ ﮐﻨﻨﺪ ﮐﻪ ﮐﻤﺘﺮ ﺗﺴﺖ ﺷﺪه اﻧﺪ و اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﺷﻮد ﮐﻪ ﻧﻘﺎط ﻋﻤﻠﮑـﺮد ﺧﯿﻠـﯽ ﻣﻬـﻢ ﺗـﺴﺖ ﺷـﺪه‬‫اﻧﺪ.دو ﻓﺮم ﻣﻌﻤﻮل از ﭘﻮﺷﺶ ﮐﺪ ﻋﺒﺎرﺗﻨﺪ از ، ﭘﻮﺷﺶ ﺗﺎﺑﻊ ، ﮐـﻪ روي ﺗﻮاﺑـﻊ اﺟـﺮا ﺷـﺪه ﮔـﺰارش ﻣﯿﺪﻫـﺪ و‬‫ﭘﻮﺷﺶ ﺟﻤﻼت ، ﮐﻪ روي ﺗﻌﺪاد ﺧﻄﻮط اﺟﺮا ﺷﺪه ﺑﺮاي ﺗﮑﻤﯿﻞ ﺗـﺴﺖ ﮔـﺰارش ﻣﯿﺪﻫـﺪ.از اﯾـﻦ دو ﻣﻌﯿـﺎر‬‫ﭘﻮﺷﺎﯾﯽ ﺣﺎﺻﻞ ﻣﯽﺷﻮد. ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻫﻤﭽﻨﯿﻦ ﻣﻤﮑﻦ اﺳﺖ ﺷﺎﻣﻞ ﻣﻬﻨﺪﺳﯽ ﻣﻌﮑﻮس ﺑـﺮاي ﻣـﺸﺨﺺ‬ ‫ﮐﺮدن ﻣﺜﻼً ﻣﻘﺎدﯾﺮ ﻣﺮزي ﺑﻪ ﮐﺎر رود.‬‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﻣﺰاﯾﺎﯾﯽ دارد از ﺟﻤﻠﻪ: ﭼﻮن ﻻزﻣﻪ ان داﻧﺴﺘﻦ ﺳﺎﺧﺘﺎر داﺧﻠﯽ ﮐﺪ اﺳﺖ ﻓﻬﻤﯿـﺪن اﯾﻨﮑـﻪ‬‫ﭼﻪ ﻧﻮع از داده ﻫﺎي ورودي و ﺧﺮوﺟﯽ ﺑﺮاي ﺗﺴﺖ ﮐﺎراﺗﺮ ﺑﺮﻧﺎﻣﻪ ﻣﻨﺎﺳﺐ اﺳﺖ، آﺳﺎﻧﺘﺮ ﻣﯽﺷﻮد. ﻣﺰﯾﺖ دﯾﮕـﺮ‬‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ آﻧﺴﺖ ﮐﻪ ﺑﻪ ﺑﻬﯿﻨﻪ ﺳﺎزي ﮐﺪ ﻧﯿﺰ ﮐﻤﮏ ﻣﯽﮐﻨﺪ. ﺑﻪ ﭘﺎك ﮐﺮدن ﺧﻄﻮط اﺿـﺎﻓﯽ ﮐـﺪ ﻧﯿـﺰ‬ ‫ﮐﻤﮏ ﻣﯽﮐﻨﺪ. اﯾﻦ ﺧﻄﻮط اﺿﺎﻓﯽ ﻣﻤﮑﻦ اﺳﺖ ﻣﻨﺠﺮﺑﻪ ﺧﻄﺎﻫﺎي ﭘﻨﻬﺎن ﺷﻮﻧﺪ.‬‫ﻣﻌﺎﯾﺐ ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﺷﺎﻣﻞ ﻣﻮارد زﯾﺮ ﻣﯽﺷﻮﻧﺪ: ﭼﻮن اﮔﺎﻫﯽ و ﻣﻬـﺎرت از ﮐـﺪ و ﺳـﺎﺧﺘﺎر داﺧﻠـﯽ ﻧﯿـﺎز‬‫اﺳﺖ، ﯾﮏ ﺗﺴﺖ ﮐﻨﻨﺪه ﻣﺎﻫﺮ ﻧﯿﺎز اﺳﺖ ﺗﺎ اﯾﻦ ﻧﻮع ﺗﺴﺖ را اﻧﺠﺎم دﻫﺪ ﮐﻪ ﺑﺎﻋـﺚ اﻓـﺰاﯾﺶ ﻫﺰﯾﻨـﻪ ﻣـﯽﺷـﻮد.‬‫ﺑﺮرﺳﯽ ﻫﺮ ﻗﻄﻌﻪ از ﮐﺪ و ﺑﺪﻧﺒﺎل ﺧﻄﺎﻫﺎي ﭘﻨﻬﺎن ﮔﺸﺘﻦ ﺗﻘﺮﯾﺒﺎً ﻏﯿﺮ ﻣﻤﮑﻦ اﺳﺖ و ﻫﻤﭽﻨﯿﻦ ﻣﻤﮑـﻦ اﺳـﺖ‬ ‫ﻣﻨﺠﺮﺑﻪ ﻣﺸﮑﻼﺗﯽ ﺷﻮد ﮐﻪ ﺑﺎﻋﺚ ﺷﮑﺴﺖ ﺑﺮﻧﺎﻣﻪ ﻣﯽﺷﻮﻧﺪ.‬‫51‬ ‫‪mutation testing‬‬‫61‬ ‫‪fault injection‬‬
  18. 18. ‫٣١‬ ‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي‬‫در ﺳﺎلﻫﺎي اﺧﯿﺮ ﻋﺒﺎرت ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻧﯿﺰ ﺑﻪ اﺳﺘﻔﺎده ﻣﻌﻤﻮل اﺿﺎﻓﻪ ﺷﺪه اﺳـﺖ. ﮐـﻪ ﺑـﻪ ﻣﻌﻨـﺎي‬‫داﺷﺘﻦ دﺳﺘﺮﺳﯽ ﺑﻪ ﺳﺎﺧﺘﻤﺎن داده ﻫﺎي داﺧﻠﯽ و اﻟﮕﻮرﯾﺘﻤﻬﺎ ﺑﺮاي اﯾﻨﮑﻪ ﺑﺘـﻮاﻧﯿﻢ ﻣـﻮارد ﺗـﺴﺖ را ﻃﺮاﺣـﯽ‬ ‫ﮐﻨﯿﻢ و در ﺳﻤﺖ ﮐﺎرﺑﺮ ﯾﺎ در ﺳﻄﺢ ﺗﺴﺖ ﺟﻌﺒﻪ ﺳﯿﺎه اﺳﺘﻔﺎده ﮐﻨﯿﻢ.‬‫ﺗﺴﺖ ﺟﻌﺒﻪ ﺧﺎﮐﺴﺘﺮي ﻣﺨﺼﻮﺻﺎً در ﻣﻮاﻗﻌﯽ ﮐﻪ ﻣﯿﺨﻮاﻫﯿﻢ ﺗﺴﺖ رﮔﺮﺳﯿﻮن را ﺑﯿﻦ دو ﻣﺎژول از ﮐﺪ ﮐـﻪ ﺑـﻪ‬‫وﺳﯿﻠﻪ دو ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺲ ﻣﺨﺘﻠﻒ ﻧﻮﺷﺘﻪ ﺷﺪه– و ﻓﻘﻂ اﯾﻨﺘﺮﻓﯿﺲ ﻫﺎ ﺑﺮاي ﺗﺴﺖ در دﺳﺘﺮس ﻫﺴﺘﻨﺪ -ﺑﻪ ﮐـﺎر‬ ‫ﻣﯿﺮود .‬ ‫ﺗﺴﺖ ﺳﯿﺴﺘﻤﻬﺎي ﻣﺒﺘﻨﯽ ﺑﺮوب‬‫وﯾﮋﮔﯿﻬﺎي ﺧﺎص ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب ﺑﻄﻮر ﻣﺴﺘﻘﯿﻢ ﺑﺮ ﻣﻮﺿﻮع ﺗﺴﺖ اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ ﺗـﺎﺛﯿﺮ ﻣـﯽﮔﺬارﻧـﺪ.‬‫ﻧﺘﯿﺠﻪ اﯾﻦ وﯾﮋﮔﯿﻬﺎ و ﭘﯿﭽﯿﺪﮔﯿﻬﺎ آن اﺳﺖ ﮐﻪ روﺷﻬﺎ و اﺑﺰارﻫﺎ و ﻣـﺪﻟﻬﺎي راﯾـﺞ ﺑـﺮاي ﺗـﺴﺖ ﻧـﺮماﻓﺰارﻫـﺎي‬‫ﻣﺘﺪاول، ﻣﻌﻤﻮﻻ ﺑﺮاي ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، ﮐﺎﻓﯽ ﻧﻤﯽﺑﺎﺷﻨﺪ. ﺑﺮﺧﯽ از اﯾﻦ روﺷﻬﺎ ﻧﯿﺎزﻣﻨﺪ ﺗﻐﯿﯿـﺮ و‬‫ﺗﻄﺒﯿﻖ ﺑﺎ ﻣﺤﯿﻂ وب ﻣﯽﺑﺎﺷﻨﺪ و ﺑﺮﺧﯽ ﻧﯿﺰ ﺑﮑﻠﯽ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻧﻤﯽﺑﺎﺷﻨﺪ. ﻫﻤﭽﻨﯿﻦ ﺑـﺮاي ﺗـﺴﺖ ﺑﺮﺧـﯽ از‬ ‫ﻣﻮارد، ﻧﯿﺎزﻣﻨﺪ روﺷﻬﺎ و ﻣﺪﻟﻬﺎي ﺟﺪﯾﺪ ﮐﻪ ﻣﺨﺼﻮص ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ ﻣﯽﺑﺎﺷﻨﺪ، ﻫﺴﺘﯿﻢ.‬‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﯾﻨﮑﻪ در ﺗﻮﺳﻌﻪ ﺳﯿﺴﺘﻤﻬﺎي ﺗﺤﺖ وب، ﻣﻌﻤﻮﻻً از ﻣﺪل ﺗﻮﺳﻌﻪ ﺳﺮﯾﻊ )‪ (RAD‬اﺳﺘﻔﺎده ﻣﯽﺷـﻮد،‬‫ﻓﺮﺻﺖ ﮐﻤﺘﺮي ﺑﺮاي ﺗﺴﺖ ﺳﯿﺴﺘﻢ در اﺧﺘﯿﺎر ﺗﻮﺳﻌﻪ دﻫﻨﺪﮔﺎن ﻣﯽﺑﺎﺷﺪ. ﻫﻤﭽﻨﯿﻦ ﺑﺮﺧﯽ ﻣﻮارد ﻧﻈﯿﺮ ﺗـﺴﺖ‬‫ﻣﻘﯿﺎس ﭘﺬﯾﺮي، ﻣﻤﮑﻦ اﺳﺖ ﺑﻄﻮر دﻗﯿﻖ ﻗﺎﺑﻞ اﺟﺮا ﻧﺒﺎﺷﻨﺪ ﯾﺎ ﻫﺰﯾﻨﻪ اﺟﺮاي آﻧﻬﺎ زﯾﺎد ﺑﺎﺷﺪ. در ﻧﺘﯿﺠﻪ ﺑﻪ ﻧﻈﺮ‬‫ﻣﯽرﺳﺪ ﮐﻪ ﺑﺮاي ﺑﺮﺧﯽ اﻧﻮاع ﺗﺴﺖ، ﻻزم اﺳﺖ ﮐﻪ ﺳﯿﺴﺘﻢ اﺑﺘﺪا ﺑﻄﻮر ﮐﺎﻣﻞ زﯾـﺮ ﺑـﺎر ﺑـﺮود و در ﺗﻌﺎﻣـﻞ ﺑـﺎ‬ ‫ﮐﺎرﺑﺮان واﻗﻌﯽ ﮐﻪ رﻓﺘﺎرﻫﺎﯾﺸﺎن ﻟﺰوﻣﺎ ﻗﺎﺑﻞ ﭘﯿﺶ ﺑﯿﻨﯽ ﻧﯿﺴﺖ، ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﮔﯿﺮد.‬‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺣﺴﺎﺳﯿﺖ زﯾﺎد ﻧﺴﺒﺖ ﺑﻪ زﻣﺎن ﺗﻮﺳﻌﻪ اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ، ﻫﻤﭽﻨﯿﻦ ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ اﯾﻨﮑـﻪ ﺗﺮﮐﯿﺒـﺎت‬‫ﻣﺘﻌﺪدي از ﻣﺮورﮔﺮﻫﺎ، ﺳﯿﺴﺘﻢ ﻋﺎﻣﻠﻬﺎ، و ﻣﺤﯿﻄﻬﺎي اﺟﺮا وﺟﻮد دارد، اﮔﺮ ﺑﺨﻮاﻫﯿﻢ ﯾﮏ ﺳﯿـﺴﺘﻢ را در ﺑﺮاﺑـﺮ‬‫ﺗﻤﺎم اﯾﻦ ﺗﺮﮐﯿﺒﺎت ﻣﻮرد ﺗﺴﺖ ﻗﺮار دﻫﯿﻢ، ﻧﯿﺎز ﺑﻪ ﺧﻮدﮐﺎرﺳﺎزي رواﻟﻬﺎي ﺗﺴﺖ ﺑﻪ ﺷﮑﻞ ﭼﺸﻤﮕﯿﺮي، اﻓﺰاﯾﺶ‬
  19. 19. ‫٤١‬‫ﻣﯽﯾﺎﺑﺪ. ﻫﻤﭽﻨﯿﻦ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﯾﻨﮑﻪ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب داﺋﻤﺎً در ﺣﺎل ﺗﻐﯿﯿـﺮ و ﺑﺮوزرﺳـﺎﻧﯽ ﻣـﯽﺑﺎﺷـﻨﺪ،‬‫ﻗﺎﺑﻠﯿﺖ اﺟﺮاي ﻣﺠﺪد ﺗﺴﺖ ﻫﺎ ﺑﻄﻮر ﺧﻮدﮐﺎر، ﺑﺴﯿﺎر ﻣﻮرد ﻧﯿﺎز ﻣﯽﺑﺎﺷﺪ. ﺑﺪﯾﻦ ﺗﺮﺗﯿﺐ ﻣﯽﺗﻮان ﭘـﺲ از اﻧﺠـﺎم‬‫ﺣﺠﻢ ﻣﻨﺎﺳﺒﯽ از ﺗﻐﯿﯿﺮات ﺑﺮ روي ﺳﯿﺴﺘﻢ، دوﺑﺎره ﺗﺴﺖ ﻫﺎ را ﺑﻄﻮر ﺧﻮدﮐﺎر ﺑﺮ روي ﺳﯿـﺴﺘﻢ اﻧﺠـﺎم داد. در‬‫ﻣﻮرد ﺳﯿﺴﺘﻢ ﻫﺎي ﻣﺘﺪاول، ﻣﻌﻤﻮﻻً ﭘﺲ از اراﺋﻪ ﺳﯿﺴﺘﻢ ﺑﻪ ﺑﺎزار و ﻣﺸﺘﺮﯾﺎن، ﺗﻐﯿﯿﺮات ﺳﯿﺴﺘﻢ ﺧﯿﻠﯽ ﻣﺤﺪود‬‫اﺗﻔﺎق ﻣﯽاﻓﺘﺪ و در ﻓﻮاﺻﻞ زﻣﺎﻧﯽ ﻣﺘﻔﺎوت، ﻧﺴﺨﻪ ﻫﺎي ﺟﺪﯾﺪ ﻧﺮماﻓـﺰار ﯾـﺎ وﺻـﻠﻪ ﻫـﺎي اﻣﻨﯿﺘـﯽ آن، ﺗﻮزﯾـﻊ‬‫ﻣﯽﺷﻮﻧﺪ در ﻧﺘﯿﺠﻪ ﻧﺮخ ﺗﻐﯿﯿﺮات ﺑﺴﯿﺎر ﭘﺎﯾﯿﻦ اﺳﺖ. اﻣﺎ در ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، ﭼـﻮن ﺳﯿـﺴﺘﻢ ﺑـﺮ روي‬‫ﺳﺮور ﻧﺼﺐ ﻣﯽﺷﻮد و از ﻃﺮﯾﻖ ﺷﺒﮑﻪ ﻗﺎﺑﻞ دﺳﺘﺮس اﺳﺖ، اﯾﻦ اﻣﮑـﺎن وﺟـﻮد دارد ﮐـﻪ ﻃﺮاﺣـﺎن ﺳﯿـﺴﺘﻢ،‬ ‫ﺑﺮاﺣﺘﯽ و ﺑﻄﻮر ﻣﺪاوم ﺳﯿﺴﺘﻢ را ﺑﺮوزرﺳﺎﻧﯽ ﻧﻤﺎﯾﻨﺪ و ﺗﻐﯿﯿﺮات ﻻزم را اﻋﻤﺎل ﻧﻤﺎﯾﻨﺪ.‬‫ﯾﮑﯽ از ﻣﺴﺎﺋﻞ ﻣﻬﻢ در ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب آن اﺳﺖ ﮐﻪ ﻫﻨﻮز ﻣﻌﯿﺎرﻫﺎي دﻗﯿـﻖ و ﻗﺎﺑـﻞ اﻋﺘﻤـﺎد و‬ ‫ﻣﻮرد ﺗﻮاﻓﻖ، ﺑﺮاي ﺗﺴﺖ اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ، ﻣﻌﺮﻓﯽ ﻧﺸﺪه اﺳﺖ.‬‫ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب، در ﻃﻮل زﻣﺎن ﺑﺴﯿﺎر ﺗﻐﯿﯿﺮ ﮐﺮده اﻧﺪ. ﺳﯿﺴﺘﻢ ﻫﺎي اوﻟﯿﻪ، ﺷـﺎﻣﻞ ﺻـﻔﺤﺎت اﯾـﺴﺘﺎي‬‫‪ HTML‬ﺑﻮدﻧﺪ. اﻣﺎ ﺳﯿﺴﺘﻤﻬﺎي اﻣﺮوزي، ﺷﺎﻣﻞ ﺻﻔﺤﺎت ﭘﻮﯾﺎ ﺑﺎ ﺗﺮﮐﯿﺒﯽ از ﺗﮑﻨﻮﻟـﻮژي ﻫـﺎي ﻣﺘﻔـﺎوت، ﻧﻈﯿـﺮ‬‫‪ XML ،JSP ،ASP ،PHP‬و ‪ JDBC‬ﻣﯽﺑﺎﺷﻨﺪ. ﻣﻮاردي ﻧﻈﯿﺮ ﻗﺎﻟﺐﻫﺎي ﭼﻨﺪرﺳﺎﻧﻪاي ﺟﺪﯾﺪ، و ﯾﺎ ﺗﮑﻨﻮﻟﻮژي‬‫‪ ،AJAX‬اﻓﺰاﯾﺶ اﺟﺰاي ﻣﺨﺘﻠﻔﯽ ﮐﻪ در ﻃﺮاﺣﯽ ﺳﯿﺴﺘﻢ دﺧﯿﻞ ﻫﺴﺘﻨﺪ، ﻫﻤﻪ و ﻫﻤـﻪ ﺑـﻪ ﭘﯿﭽﯿـﺪه و ﭘﻮﯾـﺎﺗﺮ‬ ‫ﺷﺪن اﯾﻦ ﺳﯿﺴﺘﻢ ﻫﺎ ﻣﻨﺠﺮ ﺷﺪه اﻧﺪ.‬‫ﻫﺪف اﺻﻠﯽ ﺗﺴﺖ ﯾﮏ ﺳﯿﺴﺘﻢ ﺗﺤﺖ وب، اﺟﺮاي آن ﺳﯿﺴﺘﻢ ﺑﻪ ﻣﻨﻈﻮر ﮐـﺸﻒ ﺧﺮاﺑـﯽ ﻫـﺎ و ﺧﻄﺎﻫـﺎي آن‬‫ﻣﯽﺑﺎﺷﺪ. ﺧﺮاﺑﯽ )‪ ،(failure‬ﺑﻪ ﯾﮏ ﻧﺎﺗﻮاﻧﯽ ﻣﺸﺨﺺ ﺳﯿﺴﺘﻢ در اﺟﺮاي ﯾﮏ وﻇﯿﻔﻪ از ﭘﯿﺶ ﺗﻌﯿﯿﻦ ﺷـﺪه ﺑـﺮ‬‫اﺳﺎس ﻣﻌﯿﺎرﻫﺎي ﺗﻌﺮﯾﻒ ﺷﺪه، ﻣﯽﺑﺎﺷﺪ. ﺑﺮﺧﯽ ﺧﺮاﺑﯽ ﻫﺎ ﻣﺮﺑﻮط ﺑﻪ ﺧﻄﺎﻫـﺎي ﻋﺎﻣـﻞ اﻧـﺴﺎﻧﯽ در ﻃﺮاﺣـﯽ و‬‫ﭘﯿﺎده ﺳﺎزي ﺳﯿﺴﺘﻢ ﻣﯽﺑﺎﺷﻨﺪ. اﻣﺎ ﺑﺮﺧﯽ ﺧﺮاﺑﯽ ﻫﺎ ﻧﯿﺰ ﻣﺮﺑﻮط ﺑﻪ ﻣﺤﯿﻂ اﺟﺮا، ﻣﺜﻼ ﺑﺎﮔﻬﺎي ﻧﺮماﻓﺰار ﻣﺮورﮔﺮ‬‫ﯾﺎ ﻣﺸﮑﻼت ﺷﺒﮑﻪ، ﻣﺮﺑﻮط ﻣﯽﺷﻮﻧﺪ و ﻣﻨﺸﺎ ﻣﺸﮑﻞ، ﻃﺮاﺣﺎن ﺳﯿﺴﺘﻢ ﻧﻤﯽﺑﺎﺷﻨﺪ. در ﻧﺘﯿﺠﻪ ﺑـﺮاي ﺗـﺸﺨﯿﺺ‬ ‫اﻧﻮاع ﻣﺨﺘﻠﻒ ﺧﺮاﺑﯽ ﻫﺎ، اﻧﻮاع ﻣﺘﻔﺎوت ﺗﺴﺖ ﻣﻮرد ﻧﯿﺎز ﻣﯽﺑﺎﺷﺪ.‬
  20. 20. ‫٥١‬‫ﺑﻄﻮر اﺳﺎﺳﯽ، ﻣﺤﯿﻂ اﺟﺮا، ﺑﺮ ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻏﯿﺮ ﻋﻤﻠﯿﺎﺗﯽ ﺳﯿﺴﺘﻢ، ﻧﻈﯿﺮ ﻣﻘﯿﺎس ﭘﺬﯾﺮي، ﺛﺒـﺎت، و ﺳـﺎزﮔﺎري‬‫ﺳﯿﺴﺘﻢ، ﺗﺎﺛﯿﺮﻣﯽﮔﺬارد و ﻧﻪ ﺑﺮ ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻋﻤﻠﯿﺎﺗﯽ ﺳﯿـﺴﺘﻢ، ﯾﻌﻨـﯽ ﺗﻄﺒﯿـﻖ ﺑـﯿﻦ آﻧﭽـﻪ ﺳﯿـﺴﺘﻢ اﻧﺠـﺎم‬‫ﻣﯽدﻫﺪ و آﻧﭽﻪ ﺑﺎﯾﺪ اﻧﺠﺎم دﻫﺪ. در ﻧﺘﯿﺠﻪ ﻣﻌﻤﻮﻻً ﺳﯿﺴﺘﻢ ﻣﺴﺌﻮل ارﺿﺎي ﻧﯿﺎزﻫﺎي ﻋﻤﻠﯿﺎﺗﯽ، و ﻣﺤﯿﻂ اﺟـﺮا‬‫ﻣﺴﺌﻮل ارﺿﺎي ﻧﯿﺎزﻫﺎي ﻏﯿﺮﻋﻤﻠﯿﺎﺗﯽ ﻣﯽﺑﺎﺷﺪ، اﻟﺒﺘﻪ ﺗﻔﮑﯿﮏ ﮐﺎﻣﻞ ﺑﯿﻦ اﯾﻦ دو ﻣﻮرد وﺟﻮد ﻧﺪارد. اﻣﺎ ﻣﯽﺗﻮان‬ ‫ﮔﻔﺖ ﮐﻪ ﺗﺴﺖ ﺳﯿﺴﺘﻢ ﻫﺎي ﺗﺤﺖ وب را ﻣﯽﺗﻮان از دو دﯾﺪﮔﺎه ﺑﺮرﺳﯽ ﻧﻤﻮد:‬‫1. از دﯾﺪﮔﺎه اول، ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻋﻤﻠﯿﺎﺗﯽ ﺳﯿﺴﺘﻢ ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ. ﯾﻌﻨﯽ ﻋﻤﻠﮑﺮد ﺳﯿﺴﺘﻢ در‬‫ﻣﻘﺎﯾﺴﻪ ﺑﺎ آﻧﭽﻪ ﮐﻪ ﺑﺎﯾﺪ اﻧﺠﺎم دﻫﺪ، ﯾﻌﻨﯽ ﻣﻨﻄﻖ ﺳﯿﺴﺘﻢ و وﻇﺎﯾﻒ ﺗﻌﺮﯾﻒ ﺷﺪه در ﻣﺴﺘﻨﺪات، ﻣﻮرد‬ ‫ﺗﺴﺖ ﻗﺮار ﻣﯽﮔﯿﺮد.‬ ‫2. از دﯾﺪﮔﺎه دوم، ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻏﯿﺮﻋﻤﻠﯿﺎﺗﯽ ﺳﯿﺴﺘﻢ ﻣﻮرد ارزﯾﺎﺑﯽ ﻗﺮارﻣﯽﮔﯿﺮﻧﺪ.‬‫ﻧﮑﺘﻪ ﻣﻬﻢ آن اﺳﺖ ﮐﻪ ﻫﺮ دو ﻧﻮع ﺗﺴﺖ ﺑﺎﯾﺪ ﺑﻄﻮر ﻣﻨﺎﺳﺐ اﺟﺮا ﺷﻮﻧﺪ و ﻧﻤﯽﺗﻮان ﯾﮑـﯽ از اﯾـﻦ دو ﻣـﻮرد را‬ ‫ﺟﺎﯾﮕﺰﯾﻦ دﯾﮕﺮي ﻧﻤﻮد. .‪Error! Reference source not found‬‬ ‫ﺳﻄﻮح ﻣﺨﺘﻠﻒ ﺗﺴﺖ‬ ‫ﺗﺴﺖ ﻧﺮماﻓﺰار در ﻓﺎزﻫﺎي ﻣﺘﻔﺎوت و در ﺳﻄﻮح ﻣﺨﺘﻠﻒ اﻧﺠﺎم ﻣﯽ ﭘﺬﯾﺮد. اﯾﻦ ﺳﻄﻮح ﻋﺒﺎرﺗﻨﺪ از:‬ ‫ﺗﺴﺖ واﺣﺪ‬‫ﯾﮑﯽ از ﻣﺮاﺣﻞ اوﻟﯿﻪ ﺗﺴﺖ ﯾﮏ ﺳﯿﺴﺘﻢ، ﺗﺴﺖ واﺣﺪ71، ﻣﯽﺑﺎﺷﺪ ﮐﻪ ﻫﺮ ﯾﮏ از واﺣﺪﻫﺎ ﯾﺎ ﻣﺎژوﻟﻬﺎي ﺗـﺸﮑﯿﻞ‬‫دﻫﻨﺪه ﯾﮏ ﺑﺮﻧﺎﻣﻪ را ﺑﻄﻮر ﻣﺴﺘﻘﻞ، ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﻣﯽدﻫﺪ. ﻣﻌﻤﻮﻻ ﺗﺴﺖ واﺣﺪ ﺗﻮﺳﻂ ﺧﻮد ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾـﺴﺎن‬‫و ﺑﻪ ﻣﻮازات ﺗﻮﺳﻌﻪ ﺳﯿﺴﺘﻢ اﻧﺠﺎم ﻣﯽﺷﻮد. ﯾﻌﻨﯽ ﻫﺮ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﯽ ﮐﻪ ﻣﺎژوﻟﯽ را ﺑﺮاي ﺳﯿﺴﺘﻢ ﻣـﯽﻧﻮﯾـﺴﺪ،‬‫ﺧﻮد، وﻇﯿﻔﻪ ﺗﺴﺖ آن ﻣﺎژول را ﻧﯿﺰ ﺑﻌﻬﺪه دارد و ﻧﯿﺎزي ﻧﯿﺴﺖ ﺗﺴﺖ آن ﻣﺎژول ﺑﻪ ﭘﺲ از ﺗﮑﻤﯿـﻞ ﺳﯿـﺴﺘﻢ‬ ‫ﻣﻮﮐﻮل ﺷﻮد.‬‫71‬ ‫‪Unit testing‬‬
  21. 21. ‫٦١‬‫ﻫﺪف از اﻧﺠﺎم ﺗﺴﺖ واﺣﺪ، اﻃﻤﯿﻨﺎن از درﺳﺘﯽ ﻋﻤﻠﮑﺮد واﺣﺪﻫﺎﯾﯽ اﺳﺖ ﮐﻪ ﭘـﺲ از ﺗﻮﺳـﻌﻪ، در ﻗـﺴﻤﺘﻬﺎي‬ ‫ﻣﺨﺘﻠﻒ ﺳﯿﺴﺘﻢ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﺧﻮاﻫﻨﺪ ﮔﺮﻓﺖ.‬‫ﺗﺴﺖ واﺣﺪ، ﻣﻌﻤﻮﻻ ﺟﺰء ﺗﺴﺘﻬﺎي ﺟﻌﺒﻪ ﺳﻔﯿﺪ ﺑﻪ ﺣﺴﺎب آورده ﻣﯽﺷﻮد ﮐﻪ ﻧﯿﺎز ﺑـﻪ دﺳﺘﺮﺳـﯽ ﺑـﻪ ﺳـﺎﺧﺘﺎر‬ ‫دروﻧﯽ ﮐﺪ ﻣﻮرد ﺗﺴﺖ دارد.‬‫ﻻزم ﺑﻪ ذﮐﺮ اﺳﺖ ﮐﻪ ﻋﻠﯿﺮﻏﻢ اﻫﻤﯿﺖ ﺑﺴﯿﺎر زﯾﺎد ﺗﺴﺖ واﺣﺪ در ﻓﺮآﯾﻨﺪ ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓـﺰار، اﯾـﻦ ﻧـﻮع‬‫ﺗﺴﺖ ﻧﻤﯽﺗﻮاﻧﺪ ﺟﺎﯾﮕﺰﯾﻦ دﯾﮕﺮ اﻧﻮاع ﺗﺴﺖ ﺷﻮد. ﺑﻌﻨﻮان ﻣﺜﺎل، ﺑﺎ اﺳﺘﻔﺎده از ﺗﺴﺖ واﺣﺪ ﻧﻤـﯽﺗـﻮان ﮐﯿﻔﯿـﺖ‬‫راﺑﻂ ﮔﺮاﻓﯿﮑﯽ ﺳﯿﺴﺘﻢ را ارزﯾﺎﺑﯽ ﻧﻤﻮد ﯾـﺎ ﺗـﺴﺖ ﺑـﺎر را ﻧﻤـﯽﺗـﻮان ﺑـﺎ اﺳـﺘﻔﺎده از ﺗـﺴﺖ واﺣـﺪ اﻧﺠـﺎم داد‬ ‫]40‪.[Ham‬‬ ‫ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ‬‫ﻫﺪف از ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ ﺳﯿﺴﺘﻢ81، آن اﺳﺖ ﮐﻪ ﻣﻄﻤﺌﻦ ﺷﻮﯾﻢ اﺟﺰاي ﻣﺨﺘﻠﻒ ﺳﯿﺴﺘﻢ، در ﮐﻨﺎر ﯾﮑـﺪﯾﮕﺮ،‬‫ﺑﺨﻮﺑﯽ ﮐﺎر ﻣﯽﮐﻨﻨﺪ و ﺗﻌﺎﻣﻼت، ارﺗﺒﺎﻃﺎت و رد و ﺑﺪل ﮐﺮدن داده ﻫﺎ در ﺑـﯿﻦ ﻣﺎژوﻟﻬـﺎي ﻣﺨﺘﻠـﻒ ﺳﯿـﺴﺘﻢ،‬ ‫ﺑﺪرﺳﺘﯽ اﻧﺠﺎم ﻣﯽﺷﻮد و در ﻧﺘﯿﺠﻪ، ﮐﻞ ﺳﯿﺴﺘﻢ ﻋﻤﻠﮑﺮد ﺻﺤﯿﺤﯽ دارد.‬‫ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ را ﻣﯽﺗﻮان در ﺳﻄﻮح ﻣﺘﻔﺎوﺗﯽ اﻧﺠﺎم داد. ﻣـﺜﻼ، ﻣـﯽﺗـﻮان ﻫـﺮ ﯾـﮏ از ﻣﺎژوﻟﻬـﺎي اﺳﺎﺳـﯽ‬‫ﺳﯿﺴﺘﻢ را ﺑﻌﻨﻮان ﯾﮏ ﺳﯿﺴﺘﻢ در ﻧﻈﺮ ﮔﺮﻓﺖ )ﮐﻪ ﺧـﻮدش از اﺟـﺰاي ﮐـﻮﭼﮑﺘﺮي ﺗـﺸﮑﯿﻞ ﺷـﺪه( و ﺗـﺴﺖ‬‫ﯾﮑﭙﺎرﭼﮕﯽ را در ﻣﻮرد آن اﻧﺠﺎم داد. ﻫﻤﭽﻨﯿﻦ ﻣﯽﺗﻮان ﮐﻞ ﺳﯿﺴﺘﻢ را ﺑﻌﻨﻮان ﯾـﮏ ﺳﯿـﺴﺘﻢ واﺣـﺪ در ﻧﻈـﺮ‬ ‫ﮔﺮﻓﺘﻪ و آن را ﻣﻮرد ﺗﺴﺖ ﻗﺮار داد.‬‫ﻧﮑﺘﻪ ﻗﺎﺑﻞ ﺗﻮﺟﻪ آن اﺳﺖ ﮐﻪ ﻧﺒﺎﯾﺪ اﯾﻨﻄﻮر ﺗﺼﻮر ﺷﻮد ﮐﻪ اﻧﺠﺎم ﺗﺴﺖ واﺣﺪ ﺑﺮ روي ﻣﺎژوﻟﻬﺎي ﺳﯿﺴﺘﻢ، ﻣـﺎ را‬‫از اﻧﺠﺎم ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ ﺑﯽ ﻧﯿﺎز ﻣﯽﮐﻨﺪ. در واﻗﻊ ﻫﺮ دو ﻧﻮع ﺗﺴﺖ ﻣﺬﮐﻮر ﻻزم ﻣﯽﺑﺎﺷﻨﺪ و ﻫﺮ ﯾﮏ ﺗﻮاﻧﺎﯾﯽ‬‫ﺧﺎص ﺧﻮد را دارﻧﺪ. ﻧﻘﻄﻪ ﻣﻮرد ﺗﻮﺟﻪ ﺗﺴﺖ ﯾﮑﭙﺎرﭼﮕﯽ، ﻧﻘﺎط ﺗﻤﺎس و ﺗﻌﺎﻣﻞ ﻣﺎژوﻟﻬـﺎ ﺑـﺎ ﯾﮑـﺪﯾﮕﺮ اﺳـﺖ و‬‫81‬ ‫‪Integrity testing‬‬
  22. 22. ‫٧١‬‫ﻣﺎژوﻟﻬﺎ را در ﮐﻨﺎر ﯾﮑﺪﯾﮕﺮ و در ﺿﻤﻦ ﮐﺎر ﺑﺎ ﻫﻢ، ﻣﻮرد ﺗﺴﺖ ﻗﺮار ﻣﯽدﻫﺪ، در ﺣﺎﻟﯿﮑﻪ ﺗﺴﺖ واﺣﺪ، ﻣﺎژوﻟﻬﺎ را‬ ‫ﺑﻄﻮر ﻣﺴﺘﻘﻞ و ﺟﺪا از ﺑﻘﯿﻪ اﺟﺰاي ﺳﯿﺴﺘﻢ ﻣﺪﻧﻈﺮ ﻗﺮار ﻣﯽدﻫﺪ. ]20‪[Chu05] [Cra‬‬ ‫ﺗﺴﺖ ﺳﯿﺴﺘﻢ‬‫ﯾﮏ ﺳﯿﺴﺘﻢ ﮐﺎﻣﻼً ﯾﮑﭙﺎرﭼﻪ را ﺗﺴﺖ ﻣﯽﮐﻨﺪ ﺗﺎ ﺑﺮرﺳﯽ ﮐﻨﺪ ﮐﻪ اﯾﺎ ﺗﻤﺎم ﻧﯿﺎزﻣﻨﺪﯾﻬﺎ ﺑﺮاورده ﻣﯽﺷﻮﻧﺪ ﯾـﺎ ﻧـﻪ.‬ ‫ﻗﺒﻞ از ﻋﺮﺿﻪ ﻧﺴﺨﻪ ﻧﻬﺎﯾﯽ ﯾﮏ ﻧﺮماﻓﺰار ، ﺗﺴﺘﻬﺎي اﻟﻔﺎ و ﺑﺘﺎ ﻧﯿﺰ ﻋﻼوه ﺑﺮ ﺗﺴﺘﻬﺎي ﻓﻮق اﻧﺠﺎم ﻣﯽﺷﻮﻧﺪ.‬‫ﺗﺴﺖ ﻋﻤﻠﮑﺮد ﺷﺒﯿﻪ ﺳﺎزي ﺷﺪه ﯾﺎ واﻗﻌﯽ ﺑﺎ ﻣﺸﺘﺮﯾﺎن ﯾﺎ ﮐﺎرﺑﺮان ﭘﺘﺎﻧﺴﯿﻞ ، ﯾﺎ ﯾﮏ ﺗـﯿﻢ ﺗـﺴﺖ ﻣـﺴﺘﻘﻞ در‬‫ﺳﺎﯾﺖ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﺎن .ﺗﺴﺖ اﻟﻔﺎ ﻣﻌﻤﻮﻻً ﺑﺮاي ﻧﺮماﻓﺰار ﻫﺎي ﺗﻮﻟﯿﺪ اﻧﺒﻮه ﺑﻪ ﻋﻨﻮان ﻧﻮﻋﯽ از ﺗﺴﺖ ﭘﺬﯾﺮش ﺑﮑـﺎر‬ ‫ﺑﺮده ﻣﯽﺷﻮد . و ﻗﺒﻞ از ﻣﺮﺣﻠﻪ ﺗﺴﺖ ﺑﺘﺎ ﺻﻮرت ﻣﯽﭘﺬﯾﺮد .‬‫ﻧﺴﺨﻪ ﻫﺎﯾﯽ از ﻧﺮماﻓﺰار ، ﮐﻪ ﻧﺴﺨﻪ ﻫﺎي ﺑﺘﺎ ﻧﺎﻣﯿﺪه ﻣﯿﺸﻮﻧﺪ ، ﺑﻪ ﻣﺨﺎﻃﺒﺎن ﻣﺤﺪودي در ﺧﺎرج از ﺗﯿﻢ ﺑﺮﻧﺎﻣﻪ‬‫ﻧﻮﯾﺴﺎن ﻋﺮﺿﻪ ﻣﯽﺷﻮد . ﻧﺮماﻓﺰار ﺑﻪ ﮔﺮوﻫﯽ از اﻓﺮاد ﻋﺮﺿﻪ ﻣﯿﺸﻮد ﺗﺎ ﺗﺴﺘﻬﺎي ﺑﯿﺸﺘﺮي اﻧﺠﺎم ﺷﻮد و اﻃﻤﯿﻨﺎن‬‫ﺣﺎﺻﻞ ﮐﻨﯿﻢ ﮐﻪ ﻧﺮماﻓﺰار ﺧﻄﺎ ﻫﺎ ﯾﺎ ﺑﺎﮔﻬﺎي ﮐﻤﯽدارد. ﮐﺎﻫﯽ اوﻗﺎت ﻧﺴﺨﻪ ﻫﺎي ﺑﺘﺎ ﺑﻪ ﻋﻤﻮم ﻋﺮﺿﻪ ﻣﯿﺸﻮد ﺗﺎ‬ ‫ﻣﯿﺰان ﺑﺎزﺧﻮرد ﻫﺎ اﻓﺰاﯾﺶ ﯾﺎﺑﺪ .‬ ‫ﺗﺴﺖ ﭘﺬﯾﺮش‬‫اﯾﻦ ﻧﻮع ﺗﺴﺖ ﺑﺮ اﺳﺎس ﻧﯿﺎزﻣﻨﺪﯾﻬﺎي ﻣﺴﺘﻨﺪ ﺷﺪه ﮐﺎرﺑﺮان ﺳﯿﺴﺘﻢ اﻧﺠﺎم ﻣﯽﺷﻮد و ﻫﺪف از اﻧﺠﺎم آن ﮐﺴﺐ‬‫اﻃﻤﯿﻨﺎن از ﺗﺎﻣﯿﻦ ﻧﯿﺎزﻫﺎي ﮐﺎرﺑﺮان ﺗﻮﺳﻂ ﺳﯿﺴﺘﻢ، ﻣﯽﺑﺎﺷﺪ. ﺑﻪ ﺑﯿﺎن دﯾﮕﺮ در اﯾﻦ ﻧﻮع ﺗـﺴﺖ ﻣـﯽﺧـﻮاﻫﯿﻢ‬‫ﻣﻄﻤﺌﻦ ﺷﻮﯾﻢ ﮐﻪ ﺳﯿﺴﺘﻢ ﺗﻮﻟﯿﺪ ﺷﺪه از دﯾﺪ ﮐﺎرﺑﺮان ﻗﺎﺑﻞ ﻗﺒﻮل اﺳﺖ ﯾﺎ ﺧﯿﺮ. ﺑﻬﻤﯿﻦ ﻋﻠﺖ ﺑﻬﺘﺮ اﺳﺖ اﻧﺠﺎم‬ ‫ﺗﺴﺖ ﺗﻮﺳﻂ ﺧﻮد ﮐﺎرﺑﺮان ﯾﺎ ﻧﻤﺎﯾﻨﺪﮔﺎن آﻧﻬﺎ و در ﻣﺤﯿﻂ و ﺷﺮاﯾﻂ واﻗﻌﯽ ﺻﻮرت ﮔﯿﺮد.]20‪[Chu05] [Cra‬‬‫در ﻧﻬﺎﯾﺖ ، ﺗﺴﺖ ﭘﺬﯾﺮش ﺗﻮﺳﻂ ﮐﺎرﺑﺮان ﻧﻬﺎﯾﯽ ﯾﺎ ﻣﺸﺘﺮﯾﺎن اﻧﺠﺎم ﻣﯿﺸﻮد ﺗﺎ ﭘﺬﯾﺮش ﻣﺤﺼﻮل ﺻﻮرت ﺑﮕﯿـﺮد‬‫ﯾﺎ ﻧﻪ . ﺗﺴﺖ ﭘﺬﯾﺮش ﻣﻤﮑﻦ اﺳﺖ ﺑﻪ ﻋﻨﻮان ﺑﺨﺸﯽ از ﻓﺮاﯾﻨﺪ ، زﻣﺎﻧﯿﮑﻪ از ﯾﮏ ﻓﺎز ﺗﻮﺳﻌﻪ ﺑﻪ ﻓﺎز دﯾﮕﺮ ﻣﯿﺮوﯾﻢ‬ ‫ﻧﯿﺰ ﺻﻮرت ﮔﯿﺮد .‬
  23. 23. ‫٨١‬ ‫ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ‬ ‫3-‬‫اﻣﺮوزه ﺳﺎزﻣﺎنﻫﺎي ﻧﺮماﻓﺰاري زﻣﺎن و ﻣﻨﺎﺑﻊ زﯾﺎدي را در ﺗﺤﻠﯿﻞ و ﺗﺴﺖ ﻧﺮماﻓﺰار ﺻـﺮف ﻣـﯽﮐﻨﻨـﺪ. از ﻧﻈـﺮ‬‫ﻣﻬﻨﺪﺳﺎن ﻧﺮماﻓﺰار ﻧﻮﺷﺘﻦ ﮐﺪﻫﺎي ﺗﺴﺖ، ﺑﻪ ﺧﻮدي ﺧﻮد، ﻣﺜﻞ ﺗﻮﺳﻌﻪ ﺧﻮد ﻣﺤﺼﻮل وﻗﺖ ﮔﯿﺮ و ﮔﺮان اﺳﺖ.‬‫ﺗﺴﺖ ﻧﺮماﻓﺰار ﻓﺮاﯾﻨﺪ اﻣﺘﺤﺎن ﯾﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎرﺑﺮدي ﺑﺮاي ﮐﺸﻒ ﺧﻄﺎﻫﺎ و ﺗﻀﻤﯿﻦ اﯾﻨﮑﻪ ﻧﯿﺎزﻣﻨﺪيﻫﺎي ﻣﻮﺟﻮد‬ ‫را ﺑﺮآورده ﻣﯽﮐﻨﺪ و ﺑﺎ ﺳﺨﺖاﻓﺰار ﻣﺸﺘﺮي ﺳﺎزﮔﺎر اﺳﺖ.‬‫ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﻧﺴﺒﺖ ﺑﻪ ﺗﺴﺖ دﺳـﺘﯽ ﺑﺮﺗـﺮيﻫـﺎي زﯾـﺎدي دارد. در ﺟﺎﻣﻌـﻪ اﻣـﺮوزي ﭘـﺮوژهﻫـﺎي‬‫ﻧﺮماﻓﺰاري ﭘﯿﭽﯿﺪه ﻫﺴﺘﻨﺪ و ﺑﺮاي ﺣﻞ ﻣﺴﺎﺋﻞ ﭘﯿﭽﯿﺪه ﻃﺮاﺣﯽ ﻣﯽﺷﻮﻧﺪ. ﺳﺎزﻧﺪﮔﺎن اﺑﺰارﻫﺎي ﺗﺴﺖ ﻧﺮماﻓـﺰار‬‫اﻏﻠﺐ ﻧﯿﺎز ﺑﻪ زﻣﺎن دارﻧﺪ ﺗﺎ درﺑﺎره ﯾﮏ ﻣﺴﺎﻟﻪ ﺧﺎص آﮔﺎﻫﯽ ﭘﯿﺪا ﮐﻨﻨﺪ و ﺑﺎ ﺗﮑﻨﻮﻟﻮژي ﻣﺮﺑـﻮط ﺑـﻪ آن ﻣـﺴﺎﻟﻪ‬‫آﺷﻨﺎ ﺷﻮﻧﺪ. ﺑﻨﺎﺑﺮاﯾﻦ ﺑﺮاي رﺳﯿﺪن ﺑﻪ ﺿﺮب اﻻﺟﻞ ﺗﻌﯿﯿﻦ ﺷﺪه ﭘﺮوژه ، ﺗـﯿﻢ ﺗـﺴﺖ ﺑﺎﯾـﺪ ﯾـﮏ اﺑـﺰار ﺗـﺴﺖ‬‫ﺧﻮدﮐﺎر را اﯾﺠﺎد ﻧﻤﺎﯾﺪ ﮐﻪ ﺑﻪ ﻋﻨﻮان ﻣﮑﻤﻠﯽ ﺑﺮاي ﻓﺮآﯾﻨﺪ ﺗﺴﺖ ﻣﻮﺟﻮد ﻋﻤﻞ ﻧﻤﺎﯾﺪ . ﺑﺎ وﺟﻮد اﯾﻨﮑـﻪ ﻣﻤﮑـﻦ‬‫اﺳﺖ ﻫﺰﯾﻨﻪ اوﻟﯿﻪ اﺟﺮاي آن در ﺷﺮوع ﮐﺎر ﺳﻨﮕﯿﻦ ﺑﺎﺷﺪ اﻣﺎ در ﻃـﯽ ﻓﺮآﯾﻨـﺪ ﺗﻮﺳـﻌﻪ ، اﯾـﻦ ﻫﺰﯾﻨـﻪ ﺟﺒـﺮان‬‫ﺧﻮاﻫﺪ ﺷﺪ . ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﺑﺎﻋﺚ ﻣﯽ ﺷﻮد ﮐﻪ ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن زﻣﺎن ﺑﯿﺸﺘﺮي ﺑﺮاي ﺗﻤﺮﮐـﺰ ﺑـﺮروي‬‫دﯾﮕﺮ ﺟﻨﺒﻪﻫﺎ داﺷﺘﻪ ﺑﺎﺷﻨﺪ و ﺑﺘﻮاﻧﻨﺪ ﺧﻄﺎﻫﺎي ﻧﺮماﻓﺰار را ﺑﻪ ﺻﻮرت ﻣﺆﺛﺮﺗﺮي رﻓـﻊ ﻧﻤﺎﯾﻨـﺪ . ﻋـﻼوه ﺑـﺮاﯾﻦ،‬‫ازآﻧﺠﺎﯾﯽ ﮐﻪ ﺗﺴﺖﻫﺎ را ﻣﯽﺗﻮان در ﻫﺮ زﻣﺎن و ﺑﻪ ﻫﺮ ﺗﻌﺪاد دﻓﻌﺎﺗﯽ اﺟﺮا ﮐﺮد، ﺗﻮﺳﻌﻪدﻫﻨﺪﮔﺎن ﻗﺎدر ﺧﻮاﻫﻨﺪ‬‫ﺑﻮد ﺑﻪ ﺳﺎدﮔﯽ ﺧﻄﺎ را ﻣﺠﺪداً اﯾﺠﺎد ﮐﻨﻨﺪ ﺗﺎ ﻧﻘﺺ ﻣﻮﺟﻮد در ﮐﺪ ﻧـﺮماﻓـﺰار را ﺑﯿﺎﺑﻨـﺪ در ﺣﺎﻟﯿﮑـﻪ در ﺗـﺴﺖ‬‫دﺳﺘﯽ اﺟﺮاي ﻣﺠﺪد ﺧﻄﺎ ﺳﺨﺖ ﻣﯽ ﺑﺎﺷﺪ زﯾﺮا ﮔﺎﻫﯽ اوﻗﺎت ﻫﻨﮕﺎم اﻧﺠﺎم ﺗﺴﺖ دﺳﺘﯽ، ﻓﺮد ﺗﺴﺖﮔـﺮ ﺗﻤـﺎم‬ ‫ﻋﻤﻠﯿﺎﺗﯽ ﮐﻪ ﻃﯽ روال ﺗﺴﺖ ﮐﺮدن اﻧﺠﺎم داده اﺳﺖ را ﺑﺨﺎﻃﺮ ﻧﺪارد.‬
  24. 24. ‫٩١‬‫ﻫﻤﭽﻨﯿﻦ ﺑﺎﯾﺪ اﺷﺎره ﮐﺮد ﮐﻪ ﺑﺴﯿﺎري از ﺗﻼشﻫﺎ در زﻣﯿﻨﻪ ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖﻫﺎ ﺑﻪ ﻧﺘﺎﯾﺞ ﻣﻮرد اﻧﺘﻈﺎر دﺳﺖ‬‫ﻧﯿﺎﻓﺘﻪاﻧﺪ. ﮔﺎﻫﯽ اوﻗﺎت در زﻣﯿﻨﻪ اﯾﺠﺎد و ﻧﮕﻬﺪاري ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﺳﺮﻣﺎﯾﻪﮔﺬاري ﻋﻈﯿﻤﯽ ﻣﯽﺷـﻮد اﻣـﺎ‬‫ﭘﺲ از ﺳﺎﺧﺖ ، ﺣﺘﯽ ﻫﺰﯾﻨﻪ ﺳﺮﻣﺎﯾﻪﮔﺬاري ﺷﺪه ﻗﺎﺑﻞ ﺟﺒﺮان ﻧﯿﺴﺖ . ﺑﺴﯿﺎر ﻣﻬﻢ اﺳﺖ ﮐﻪ ﯾﮏ ﺗﺤﻠﯿﻞ ﮐﺎﻣﻞ‬‫در ﻣﻮرد ﻫﺰﯾﻨﻪ و ﻣﻨﺎﻓﻊ ﺣﺎﺻﻞ از ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ دﺳـﺘﯽ ﻣـﻮرد ﻧﻈـﺮ ، اﻧﺠـﺎم ﺷـﻮد. اﻏﻠـﺐ، ﻣﻮﻓﻘﯿـﺖ‬‫ﻫﻨﮕﺎﻣﯽ ﺣﺎﺻﻞ ﻣﯽ ﺷﻮد ﮐﻪ ﺑﺮ روي ﭘﯿﺪا ﮐﺮدن ﻗﺴﻤﺘﻬﺎﯾﯽ از ﻧﺮماﻓﺰار ﮐﻪ ﺧﻮدﮐﺎرﺳﺎزي آﻧﻬـﺎ ﺳـﻮدﻣﻨﺪ ﺑـﻪ‬‫ﻧﻈﺮ ﻣﯽ رﺳﺪ ﻣﺘﻤﺮﮐﺰ ﺷﻮﯾﻢ و ﻧﻪ ﺑﺮ روي ﺧﻮدﮐﺎرﺳﺎزي ﮐﻞ ﻧﺮماﻓﺰار. ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﻣﯽ ﺗﻮاﻧﺪ ﻫﺰﯾﻨﻪ و‬‫ﭘﯿﭽﯿﺪﮔﯽ زﯾﺎدي را ﺑﺮاي ﺗﯿﻢ ﺗﺴﺖﮔﺮ ﺑﻪ ﻫﻤﺮاه داﺷﺘﻪ ﺑﺎﺷﺪ و ﯾﺎ در ﺻـﻮرﺗﯿﮑﻪ ﺗﻮﺳـﻂ اﻓـﺮاد ﻣﻨﺎﺳـﺐ و در‬ ‫ﻣﻮاردي ﮐﻪ اﻧﺠﺎم آن ﻣﻮرد ﺗﺎﯾﯿﺪ اﺳﺖ اﻧﺠﺎم ﺷﻮد، ﻣﯽﺗﻮاﻧﺪ ﮐﻤﮏ ﻗﺎﺑﻞ ﺗﻮﺟﻬﯽ را ﺑﻪ اﯾﻦ ﺗﯿﻢ اراﺋﻪ دﻫﺪ.‬ ‫ﺑﻬﺘﺮاﺳﺖ زﻣﺎﻧﯽ ﺑﻪ ﺧﻮدﮐﺎرﺳﺎزي ﺗﺴﺖ ﺑﭙﺮدازﯾﻢ ﮐﻪ ﺣﺪاﻗﻞ ﯾﮑﯽ از ﺷﺮاﯾﻂ زﯾﺮ در ﻣﻮرد ﭘﺮوژه ﻣﻬﯿﺎ ﺑﺎﺷﺪ :‬ ‫‪ Test case ‬ﻫﺎ و ﻣﺤﯿﻂ ﻫﺎي ﺗﺴﺖ ﻗﺎﺑﻞ اﺳﺘﻔﺎده ﻣﺠﺪد ﺑﺎﺷﻨﺪ.‬ ‫‪ ‬ﻧﯿﺎز ﮐﻤﯽ ﺑﻪ داﻧﺶ ﻣﺤﯿﻄﯽ در ﺗﺴﺖﻫﺎ داﺷﺘﻪ ﺑﺎﺷﯿﻢ .‬ ‫‪ ‬ﺳﯿﺴﺘﻢﻫﺎ اﺳﺘﺎﻧﺪارد و ﻣﺴﺘﻘﻞ ﺑﺎﺷﻨﺪ.‬ ‫‪ ‬رﻣﺰﮔﺬاري و ﺗﺪوﯾﻦ ﻗﻮاﻧﯿﻦ91 اﺻﻠﯽﺗﺮﯾﻦ اﺳﺘﺎﻧﺪارد در ﻣﺪﯾﺮﯾﺖ داﻧﺶ ﺑﺎﺷﺪ.‬‫ﺑﺎﯾﺪ ﺗﻮﺟﻪ داﺷﺖ ﮐﻪ ﺗﺴﺖ ﺧﻮدﮐﺎر ﺑﻪ اﯾﻦ ﻣﻌﻨﺎ ﻧﯿﺴﺖ ﮐﻪ ﮐﻞ ﻓﺮآﯾﻨﺪ ﺗﺴﺖ ﻧﺮماﻓـﺰار ﺑـﻪ ﺻـﻮرت ﺧﻮدﮐـﺎر‬‫اﻧﺠﺎم ﻣﯽﺷﻮد. ﺑﻠﮑﻪ ﺑﻪ ﻣﻌﻨﺎي ﺗﺴﺖ ﻧﺮماﻓﺰار ﺑﺎ ﮐﻤﮏ ﮐﺎﻣﭙﯿﻮﺗﺮ اﺳﺖ. ﺑﻪ ﻃـﻮر ﺧﻼﺻـﻪ ﺗـﺴﺖ ﺧﻮدﮐـﺎر ﺑـﻪ‬‫ﻣﻌﻨﺎي ﺧﻮدﮐﺎرﺳﺎزي ﻓﺮآﯾﻨﺪ ﺗﺴﺖ دﺳﺘﯽ اﺳﺖ ﮐﻪ در ﺣﺎل ﺣﺎﺿﺮ اﺳﺘﻔﺎده ﻣﯽﺷﻮد. اﯾﻦ ﻋﻤﻞ ﻧﯿﺎز ﺑـﻪ ﯾـﮏ‬‫ﻓﺮآﯾﻨﺪ ﺗﺴﺖ دﺳﺘﯽ ﺳﺎﺧﺖ ﯾﺎﻓﺘﻪ دارد ﮐﻪ در ﺣﺎل ﺣﺎﺿﺮ در ﺳﺎزﻣﺎن ﯾﺎ ﺷﺮﮐﺖ ﻣﻮﺟﻮد ﻣﯽ ﺑﺎﺷﺪ. اﺳﺘﻔﺎده از‬‫ﺗﺴﺖ ﺧﻮدﮐﺎر ﭘﺮﻫﺰﯾﻨﻪ اﺳﺖ. ﺑﻪ ﮐﺎرﺑﺮدن ﺗﺴﺖ ﺧﻮدﮐﺎر ﺑﻪ اﯾﻦ ﻣﻌﻨﯽ ﻧﯿﺴﺖ ﮐﻪ دﯾﮕﺮ ﻧﯿﺎزي ﺑﻪ ﺗﺴﺖ دﺳﺘﯽ‬‫ﻧﺪارﯾﻢ و ﯾﺎ ﻣﯽ ﺗﻮان ﺗﻌﺪاد اﻓﺮاد ﺗﯿﻢ ﺗﺴﺖ را ﮐﺎﻫﺶ داد ﺑﻠﮑﻪ ﺗﺴﺖ ﺧﻮدﮐﺎر ﻣﮑﻤﻠـﯽ ﺑـﺮاي ﻓﺮآﯾﻨـﺪ ﺗـﺴﺖ‬‫91 ‪codification‬‬
  25. 25. ‫٠٢‬‫ﻣﻮﺟﻮد ﻣﯽ ﺑﺎﺷﺪ . ﺗﻮﺳﻌﻪ ، ﺑﺎزﺑﯿﻨﯽ و ﻣﺴﺘﻨﺪ ﺳﺎزي ﯾﮏ ﻧﻤﻮﻧﻪ ﺗﺴﺖ02 ﺧﻮدﮐﺎر ﻣﯽ ﺗﻮاﻧﺪ ﺑﯿﻦ 3 ﺗﺎ 01 ﺑﺮاﺑﺮ‬‫ﺑﯿﺸﺘﺮ از اﯾﺠﺎد و اﺟﺮاي ﯾﮏ ﻧﻤﻮﻧﻪ ﺗﺴﺖ دﺳﺘﯽ زﻣﺎن ﺑﺮ ﺑﺎﺷﺪ ، ﺑﺨﺼﻮص اﮔـﺮ از روش ‪record/playback‬‬ ‫-ﮐﻪ در اﮐﺜﺮ اﺑﺰارﻫﺎي ﺗﺴﺖ وﺟﻮد دارد- ﺑﻪ ﻋﻨﻮان ﻣﺘﺪ اﺻﻠﯽ ﺗﺴﺖ ﺧﻮدﮐﺎر اﺳﺘﻔﺎده ﺷﻮد .‬‫02 ‪Test case‬‬
  26. 26. ‫١٢‬ ‫اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار‬ ‫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‬‬
  27. 27. ‫٢٢‬‫‪ ،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‬‬
  28. 28. ‫٣٢‬‫در 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‬ﻫﺎي ﺟﺎوا، ﺗﻌﯿﯿﻦ ﮐﻨﯿﻢ ﮐﻪ ﻣﺘﺪﻫﺎي ﺗﺴﺖ ﺑـﻪ ﭼـﻪ‬ ‫ﺗﺮﺗﯿﺒﯽ اﺟﺮا ﺷﻮﻧﺪ، ﯾﺎ ﻫﺮ ﻣﺘﺪ ﭼﻨﺪ ﺑﺎر اﺟﺮا ﺷﻮد، ﯾﺎ اﯾﻨﮑﻪ ﻣﺜﻼً ﯾﮏ ﻣﺘﺪ ﺗﺤﺖ ﭼﻪ ﺷﺮاﯾﻄﯽ اﺟﺮا ﺷﻮد.‬
  29. 29. ‫٤٢‬‫ﻻزم ﺑﻪ ذﮐﺮ اﺳﺖ ﮐﻪ ‪ ،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‬‬
  30. 30. ‫٥٢‬‫ﻫﻤ ـﺎن ﻃ ـﻮر ﮐ ـﻪ ﻣ ـﺸﺎﻫﺪه ﻣ ـﯽﺷ ـﻮد در ﮐ ـﺪ از ﮐ ـﻼسﻫ ـﺎي ‪ 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‬ﺑﺮاي ﺗﺴﺖ آن ﺻﻔ

×