SlideShare une entreprise Scribd logo

automated+software+testing+tools.pdf

•
•
E
empite
1  sur  51
Télécharger pour lire hors ligne
‫داﻧﺸﮑﺪهي ﻣﻬﻨﺪﺳﯽ‬ ‫ﮔﺮوه ﻣﻬﻨﺪﺳﯽ ﮐﺎﻣﭙﯿﻮﺗﺮ- ﻧﺮماﻓﺰار‬ ‫ﺑﺮرﺳﯽ اﺑﺰارﻫﺎي ﺗﺴﺖ ﺧﻮدﮐﺎر ﻧﺮماﻓﺰار‬ ‫ﺗﻬﯿﻪ ﮐﻨﻨﺪه: ﮔﺮوه ﺗﺨﺼﺼﯽ آزﻣﺎﯾﺸﮕﺎه ﻓﻨﺎوري وب‬ ‫آﺑﺎن 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‬‬
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf
automated+software+testing+tools.pdf

Recommandé

A survey on applications of social networks in marketing
A survey on applications of social networks in marketingA survey on applications of social networks in marketing
A survey on applications of social networks in marketingzohreh izadpanah
 
swimming- آموزش_شنا
swimming- آموزش_شناswimming- آموزش_شنا
swimming- آموزش_شناFarid Kamali
 
SEO by Ali Pour Zahmatkesh/ AUT University project
SEO by Ali Pour Zahmatkesh/ AUT University projectSEO by Ali Pour Zahmatkesh/ AUT University project
SEO by Ali Pour Zahmatkesh/ AUT University projectAli Pour Zahmatkesh
 
دستورالعمل تعیین مستمر تلفات انرژی
دستورالعمل تعیین مستمر تلفات انرژیدستورالعمل تعیین مستمر تلفات انرژی
دستورالعمل تعیین مستمر تلفات انرژیعباس بني اسدي مقدم
 
challenges of Top management audit
challenges of Top management auditchallenges of Top management audit
challenges of Top management auditReza Seifollahy
 
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتي
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتياطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتي
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتيملزمتي
 
Six thinking hats
Six thinking hatsSix thinking hats
Six thinking hatsMohammad Hassan Adjigol
 
Scrum.guide%20 %20 pr
Scrum.guide%20 %20 prScrum.guide%20 %20 pr
Scrum.guide%20 %20 prtsa000
 

Recommandé

A survey on applications of social networks in marketing
A survey on applications of social networks in marketingA survey on applications of social networks in marketing
A survey on applications of social networks in marketingzohreh izadpanah
 
swimming- آموزش_شنا
swimming- آموزش_شناswimming- آموزش_شنا
swimming- آموزش_شناFarid Kamali
 
SEO by Ali Pour Zahmatkesh/ AUT University project
SEO by Ali Pour Zahmatkesh/ AUT University projectSEO by Ali Pour Zahmatkesh/ AUT University project
SEO by Ali Pour Zahmatkesh/ AUT University projectAli Pour Zahmatkesh
 
دستورالعمل تعیین مستمر تلفات انرژی
دستورالعمل تعیین مستمر تلفات انرژیدستورالعمل تعیین مستمر تلفات انرژی
دستورالعمل تعیین مستمر تلفات انرژیعباس بني اسدي مقدم
 
challenges of Top management audit
challenges of Top management auditchallenges of Top management audit
challenges of Top management auditReza Seifollahy
 
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتي
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتياطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتي
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتيملزمتي
 
Six thinking hats
Six thinking hatsSix thinking hats
Six thinking hatsMohammad Hassan Adjigol
 
Scrum.guide%20 %20 pr
Scrum.guide%20 %20 prScrum.guide%20 %20 pr
Scrum.guide%20 %20 prtsa000
 
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24ebrahimnejad64
 
Scrum.guide فارسی
Scrum.guide فارسیScrum.guide فارسی
Scrum.guide فارسیMahdi Mohammadi
 
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمارپاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمارFarid Kamali
 
5647 14626902-gd6
5647 14626902-gd65647 14626902-gd6
5647 14626902-gd6hamide3
 
Ddos dos
Ddos dosDdos dos
Ddos dosarichoana
 
بالاخره این بوم مدل کسب و کار چیست
بالاخره این بوم مدل کسب و کار چیستبالاخره این بوم مدل کسب و کار چیست
بالاخره این بوم مدل کسب و کار چیستNasser Ghanemzadeh
 
دليل البحث العلمى .pdf
دليل البحث العلمى .pdfدليل البحث العلمى .pdf
دليل البحث العلمى .pdfAboul Ella Hassanien
 
گروه
گروهگروه
گروهEsmat Hajvahedi
 
گروه
گروهگروه
گروهEsmat Hajvahedi
 
Annual 2
Annual 2Annual 2
Annual 2guest940e41
 
Jobb farsi
Jobb farsiJobb farsi
Jobb farsiCenterpartiet
 
Steam trap
Steam trapSteam trap
Steam trapAmir Razmi
 
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخدوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخMajid Babaie, MBA, PMP
 
امنیت داده ها در کارت های هوشمند
امنیت داده ها در کارت های هوشمند امنیت داده ها در کارت های هوشمند
امنیت داده ها در کارت های هوشمند پایگاه CIO.IR
 
Help
HelpHelp
HelpEng. QaSeMy
 
Login e-magazine No.10
Login e-magazine No.10Login e-magazine No.10
Login e-magazine No.10Login e-Magazine
 
05 business model patterns
05 business model patterns05 business model patterns
05 business model patternsMahdi Nasseri
 
Yari legal calculation software 12-3-1389
Yari legal calculation software 12-3-1389Yari legal calculation software 12-3-1389
Yari legal calculation software 12-3-1389karamhossein
 
Organizational culture
Organizational cultureOrganizational culture
Organizational cultureEsmat Hajvahedi
 
چتر کمکی من ، دوست من
چتر کمکی من ، دوست منچتر کمکی من ، دوست من
چتر کمکی من ، دوست منArash Payamyar
 
13+M+002+Yohan+Prasanga.pdf
13+M+002+Yohan+Prasanga.pdf13+M+002+Yohan+Prasanga.pdf
13+M+002+Yohan+Prasanga.pdfempite
 
pdf
pdfpdf
pdfempite
 

Contenu connexe

Similaire à automated+software+testing+tools.pdf

دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24ebrahimnejad64
 
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمارپاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمارFarid Kamali
 
5647 14626902-gd6
5647 14626902-gd65647 14626902-gd6
5647 14626902-gd6hamide3
 
بالاخره این بوم مدل کسب و کار چیست
بالاخره این بوم مدل کسب و کار چیستبالاخره این بوم مدل کسب و کار چیست
بالاخره این بوم مدل کسب و کار چیستNasser Ghanemzadeh
 
دليل البحث العلمى .pdf
دليل البحث العلمى .pdfدليل البحث العلمى .pdf
دليل البحث العلمى .pdfAboul Ella Hassanien
 
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخدوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخMajid Babaie, MBA, PMP
 
امنیت داده ها در کارت های هوشمند
امنیت داده ها در کارت های هوشمند امنیت داده ها در کارت های هوشمند
امنیت داده ها در کارت های هوشمند پایگاه CIO.IR
 
05 business model patterns
05 business model patterns05 business model patterns
05 business model patternsMahdi Nasseri
 
Yari legal calculation software 12-3-1389
Yari legal calculation software 12-3-1389Yari legal calculation software 12-3-1389
Yari legal calculation software 12-3-1389karamhossein
 
چتر کمکی من ، دوست من
چتر کمکی من ، دوست منچتر کمکی من ، دوست من
چتر کمکی من ، دوست منArash Payamyar
 

Similaire à automated+software+testing+tools.pdf (20)

دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
دامنه نوسان باشد یا نباشد؟ بورس 24 bourse24
 
Scrum.guide فارسی
Scrum.guide فارسیScrum.guide فارسی
Scrum.guide فارسی
 
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمارپاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
پاوان موكت آسانا (حركات گرم كننده) سری اول تمرینات یوگا برای افراد بیمار
 
5647 14626902-gd6
5647 14626902-gd65647 14626902-gd6
5647 14626902-gd6
 
Ddos dos
Ddos dosDdos dos
Ddos dos
 
بالاخره این بوم مدل کسب و کار چیست
بالاخره این بوم مدل کسب و کار چیستبالاخره این بوم مدل کسب و کار چیست
بالاخره این بوم مدل کسب و کار چیست
 
دليل البحث العلمى .pdf
دليل البحث العلمى .pdfدليل البحث العلمى .pdf
دليل البحث العلمى .pdf
 
گروه
گروهگروه
گروه
 
گروه
گروهگروه
گروه
 
Annual 2
Annual 2Annual 2
Annual 2
 
Jobb farsi
Jobb farsiJobb farsi
Jobb farsi
 
Steam trap
Steam trapSteam trap
Steam trap
 
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخدوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
دوطبقه سازی بزرگراه ها , تحقق یک رویاست یا واقعیتی تلخ
 
امنیت داده ها در کارت های هوشمند
امنیت داده ها در کارت های هوشمند امنیت داده ها در کارت های هوشمند
امنیت داده ها در کارت های هوشمند
 
Help
HelpHelp
Help
 
Login e-magazine No.10
Login e-magazine No.10Login e-magazine No.10
Login e-magazine No.10
 
05 business model patterns
05 business model patterns05 business model patterns
05 business model patterns
 
Yari legal calculation software 12-3-1389
Yari legal calculation software 12-3-1389Yari legal calculation software 12-3-1389
Yari legal calculation software 12-3-1389
 
Organizational culture
Organizational cultureOrganizational culture
Organizational culture
 
چتر کمکی من ، دوست من
چتر کمکی من ، دوست منچتر کمکی من ، دوست من
چتر کمکی من ، دوست من
 

Plus de empite

13+M+002+Yohan+Prasanga.pdf
13+M+002+Yohan+Prasanga.pdf13+M+002+Yohan+Prasanga.pdf
13+M+002+Yohan+Prasanga.pdfempite
 
2013+Calendar.pdf
2013+Calendar.pdf2013+Calendar.pdf
2013+Calendar.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
Pediatric-Cardiology-101.ppt
Pediatric-Cardiology-101.pptPediatric-Cardiology-101.ppt
Pediatric-Cardiology-101.pptempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfempite
 
1+-+Intro+and+Histo+Grays.ppt
1+-+Intro+and+Histo+Grays.ppt1+-+Intro+and+Histo+Grays.ppt
1+-+Intro+and+Histo+Grays.pptempite
 
best-of-smashing-magazine.pdf
best-of-smashing-magazine.pdfbest-of-smashing-magazine.pdf
best-of-smashing-magazine.pdfempite
 
AppDevelopmentProposal.docx
AppDevelopmentProposal.docxAppDevelopmentProposal.docx
AppDevelopmentProposal.docxempite
 
AppDevelopmentProposal.docx
AppDevelopmentProposal.docxAppDevelopmentProposal.docx
AppDevelopmentProposal.docxempite
 
AppDevelopmentProposal.docx
AppDevelopmentProposal.docxAppDevelopmentProposal.docx
AppDevelopmentProposal.docxempite
 

Plus de empite (20)

13+M+002+Yohan+Prasanga.pdf
13+M+002+Yohan+Prasanga.pdf13+M+002+Yohan+Prasanga.pdf
13+M+002+Yohan+Prasanga.pdf
 
pdf
pdfpdf
pdf
 
2013+Calendar.pdf
2013+Calendar.pdf2013+Calendar.pdf
2013+Calendar.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
Pediatric-Cardiology-101.ppt
Pediatric-Cardiology-101.pptPediatric-Cardiology-101.ppt
Pediatric-Cardiology-101.ppt
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdfAdobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
 
1+-+Intro+and+Histo+Grays.ppt
1+-+Intro+and+Histo+Grays.ppt1+-+Intro+and+Histo+Grays.ppt
1+-+Intro+and+Histo+Grays.ppt
 
best-of-smashing-magazine.pdf
best-of-smashing-magazine.pdfbest-of-smashing-magazine.pdf
best-of-smashing-magazine.pdf
 
AppDevelopmentProposal.docx
AppDevelopmentProposal.docxAppDevelopmentProposal.docx
AppDevelopmentProposal.docx
 
AppDevelopmentProposal.docx
AppDevelopmentProposal.docxAppDevelopmentProposal.docx
AppDevelopmentProposal.docx
 
AppDevelopmentProposal.docx
AppDevelopmentProposal.docxAppDevelopmentProposal.docx
AppDevelopmentProposal.docx
 

automated+software+testing+tools.pdf

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