Uploaded byempite
4,668 views

automated+software+testing+tools.pdf

Embed presentation

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

More Related Content

PDF
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتي
byملزمتي
 
PDF
SEO by Ali Pour Zahmatkesh/ AUT University project
byAli Pour Zahmatkesh
 
PDF
swimming- آموزش_شنا
byFarid Kamali
 
PDF
Scrum.guide%20 %20 pr
bytsa000
 
PDF
A survey on applications of social networks in marketing
byzohreh izadpanah
 
PDF
دستورالعمل تعیین مستمر تلفات انرژی
byعباس بني اسدي مقدم
 
PDF
Six thinking hats
byMohammad Hassan Adjigol
 
PDF
challenges of Top management audit
byReza Seifollahy
 
اطلس خرائط الجغرافيا للشهادة الثانوية 2017 - موقع ملزمتي
byملزمتي
 
SEO by Ali Pour Zahmatkesh/ AUT University project
byAli Pour Zahmatkesh
 
swimming- آموزش_شنا
byFarid Kamali
 
Scrum.guide%20 %20 pr
bytsa000
 
A survey on applications of social networks in marketing
byzohreh izadpanah
 
دستورالعمل تعیین مستمر تلفات انرژی
byعباس بني اسدي مقدم
 
Six thinking hats
byMohammad Hassan Adjigol
 
challenges of Top management audit
byReza Seifollahy
 

Similar to automated+software+testing+tools.pdf

PDF
Mohamady zahedy c#
bydanesh_fd
 
PDF
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
byWeb Standards School
 
PDF
راهکارهای طراحی نرم افزار ها محب الله امان
byMuhibullah Aman
 
PPTX
Software Test
byHossein Fani
 
PPTX
مهندسی نرم‌افزار - تضمین کیفیت نرم‌افزار
byseyed abolfazl sherafat
 
PPTX
پیری و جوان سازی نرم افزار
bySoroush Salehi
 
PPTX
مهندسی نرم افزار - مهندسی سیستم و تحلیل نیازها - Software Engineering - Syste...
byHamzeh Roustaei
 
PPTX
مقدمه ای بر F#
byShahriar Yazdipour
 
PPT
ATM
byghazaleh.banijamali
 
PDF
Aktioos
byguestbcf931
 
PDF
مهاجرت به متن باز در شرکت توزیع برق مشهد
byعباس بني اسدي مقدم
 
PDF
چارچوب متن باز جهت توسعه سیستم های نرم افزاری
byعباس بني اسدي مقدم
 
PDF
قلاب سازی در تحلیل بدافزارهاHooking in Malware Analysis
byM Mehdi Ahmadian
 
PPTX
Testing software: black box and white box testing
byAli Daniyal
 
PDF
ابر باز و آینده رایانش ابری
byNasser Ghanemzadeh
 
PDF
Software Fault Avoidance in Implementation
byMorteza Zakeri
 
ODP
Os security zconf 2012
bymdf092
 
PDF
نرم‌افزارهای بازمتن، الزامات و راه‌کارهای مهاجرت
byNasser Ghanemzadeh
 
PDF
Interview guidline elias shirouyeh
byilia6328
 
PPTX
(Cloud Softwars)SaaS Pricing Strategy
byzohreh izadpanah
 
Mohamady zahedy c#
bydanesh_fd
 
توسعه نرم‌افزارهای مقیاس‌پذیر بر اساس معماری ریزسرویسها (Microservices) و اجر...
byWeb Standards School
 
راهکارهای طراحی نرم افزار ها محب الله امان
byMuhibullah Aman
 
Software Test
byHossein Fani
 
مهندسی نرم‌افزار - تضمین کیفیت نرم‌افزار
byseyed abolfazl sherafat
 
پیری و جوان سازی نرم افزار
bySoroush Salehi
 
مهندسی نرم افزار - مهندسی سیستم و تحلیل نیازها - Software Engineering - Syste...
byHamzeh Roustaei
 
مقدمه ای بر F#
byShahriar Yazdipour
 
ATM
byghazaleh.banijamali
 
Aktioos
byguestbcf931
 
مهاجرت به متن باز در شرکت توزیع برق مشهد
byعباس بني اسدي مقدم
 
چارچوب متن باز جهت توسعه سیستم های نرم افزاری
byعباس بني اسدي مقدم
 
قلاب سازی در تحلیل بدافزارهاHooking in Malware Analysis
byM Mehdi Ahmadian
 
Testing software: black box and white box testing
byAli Daniyal
 
ابر باز و آینده رایانش ابری
byNasser Ghanemzadeh
 
Software Fault Avoidance in Implementation
byMorteza Zakeri
 
Os security zconf 2012
bymdf092
 
نرم‌افزارهای بازمتن، الزامات و راه‌کارهای مهاجرت
byNasser Ghanemzadeh
 
Interview guidline elias shirouyeh
byilia6328
 
(Cloud Softwars)SaaS Pricing Strategy
byzohreh izadpanah
 

More from empite

PDF
best-of-smashing-magazine.pdf
byempite
 
PPT
Pediatric-Cardiology-101.ppt
byempite
 
PDF
13+M+002+Yohan+Prasanga.pdf
byempite
 
PDF
pdf
byempite
 
PDF
2013+Calendar.pdf
byempite
 
PPT
1+-+Intro+and+Histo+Grays.ppt
byempite
 
DOCX
AppDevelopmentProposal.docx
byempite
 
DOCX
AppDevelopmentProposal.docx
byempite
 
DOCX
AppDevelopmentProposal.docx
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
PDF
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
best-of-smashing-magazine.pdf
byempite
 
Pediatric-Cardiology-101.ppt
byempite
 
13+M+002+Yohan+Prasanga.pdf
byempite
 
pdf
byempite
 
2013+Calendar.pdf
byempite
 
1+-+Intro+and+Histo+Grays.ppt
byempite
 
AppDevelopmentProposal.docx
byempite
 
AppDevelopmentProposal.docx
byempite
 
AppDevelopmentProposal.docx
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 
Adobe_Dreamweaver_CS5.5_Studio_Techniques.pdf
byempite
 

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