第一篇：編輯測試用例方法感言

編輯測試用例方法感言

編輯測試用例方法感言、一個測試用例要寫到什么程度才比較好?、剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？

一個測試用例要寫到什么程度才比較好？

這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來

比較長阿，大家要有常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短到個月，然而測試通常都是在開發(fā)即將結(jié)束的時候才真正介入。測試就是個人負(fù)責(zé)。因此時間和人力資源對測試來說是完成測試工作的一個風(fēng)險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務(wù)，把握重點業(yè)務(wù)和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關(guān)系，測試用例都是先寫重點的業(yè)務(wù)，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風(fēng)險大的業(yè)務(wù)功能編寫測試用例。

由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白?？上宜诘墓?，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的bug通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在

測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細(xì)，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細(xì)的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。

第二個問題，剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？

我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術(shù)支持，產(chǎn)品的問題很多，導(dǎo)致技術(shù)支持工作很辛苦、很累。為了讓用戶買到的產(chǎn)

品的質(zhì)量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認(rèn)為不就是拿個鼠標(biāo)點來點去，誰都可以來做。為此，我經(jīng)常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。http://

現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學(xué)習(xí)寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴(yán)格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且

還很慢。沒有辦法，那時候沒有人指導(dǎo)我，全靠自己自學(xué)和領(lǐng)悟，所以那段日子很苦阿！多寫幾次后，就知道和領(lǐng)悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導(dǎo)怎么去執(zhí)行測試。還好，我有編程的經(jīng)驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務(wù)才能去寫測試用例，才能更好的去測試。這也是我一點一點的領(lǐng)悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

我的體會：、測試用例要根據(jù)測試大綱來編寫、測試用例也要分測試項進(jìn)行歸類，這樣比較好分析和閱讀。如：業(yè)務(wù)流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務(wù)流程和風(fēng)險高的地方。能分出測試優(yōu)先級別就最好了。、熟悉系統(tǒng)，對編寫測試用例很有幫助。、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。

今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。

第二篇：編寫測試用例方法心得體會

由安博測試空間技術(shù)中心http://004km.cn/提供

編寫測試用例方法心得體會

編寫背景：

一直以來都不太想把技術(shù)方面的文章寫出來給大家看，一個是怕寫作功底不好誤導(dǎo)哪些剛?cè)腴T的測試同行，自己的表達(dá)能力有限，另一方面怕有的同行拿出去炒作，再者測試網(wǎng)站論壇上關(guān)于測試用例的資料已經(jīng)實在是多。但是看到同行紛紛都在問我測試用例的問題，都很想知道我寫測試用例的心得體會。我就抱著試試看的心態(tài)寫寫吧，希望測試的老前輩看見了，可以給我多提提建議。

編寫測試用例方法心得體會

在我的個人郵箱和MSN上，通常同行都問我類似下面這樣的問題：

１、一個測試用例要寫到什么程度才比較好?

２、剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？

下面先來分析第一個問題吧：一個測試用例要寫到什么程度才比較好？

這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來比較長阿，大家要有耐心看才行哈。^_^ 在我測試工作中，碰上的測試類型我自己劃分成這么４種： ^

對項目、產(chǎn)品的測試，測試的時候通常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短４到５個月，然而測試通常都是在開發(fā)即將結(jié)束的時候才真正介入。測試就是１個人負(fù)責(zé)。因此時間和人力資源對測試來說是完成測試工作的一個風(fēng)險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務(wù)，把握重點業(yè)務(wù)和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關(guān)系，測試用例都是先寫重點的業(yè)務(wù)，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風(fēng)險大的業(yè)務(wù)功能編寫測試用例。由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白?？上宜诘墓?，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的ｂｕｇ通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細(xì)，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細(xì)的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。

第二個問題，剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？

我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術(shù)支持，產(chǎn)品的問題很多，導(dǎo)致技術(shù)支持工作很辛苦、很累。為了讓用戶買到的產(chǎn)品的質(zhì)量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認(rèn)為不就是拿個鼠標(biāo)點來點去，誰都可以來做。為此，我經(jīng)常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。

現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學(xué)習(xí)寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴(yán)格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。沒有辦法，那時候沒有人指導(dǎo)我，全靠自己自學(xué)和領(lǐng)悟，所以那段日子很苦阿！多寫幾次后，就知道和領(lǐng)悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導(dǎo)怎么去執(zhí)行測試。還好，我有編程的經(jīng)驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務(wù)才能去寫測試用例，才能更好的去測試。這也是我一點一點的領(lǐng)悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。

最后一個問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^ 你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？ 我的體會：

１、測試用例要根據(jù)測試大綱來編寫

２、測試用例也要分測試項進(jìn)行歸類，這樣比較好分析和閱讀。如：業(yè)務(wù)流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。

３、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務(wù)流程和風(fēng)險高的地方。能分出測試優(yōu)先級別就最好了。

４、熟悉系統(tǒng)，對編寫測試用例很有幫助。

５、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。

今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。

北京測試空間科技發(fā)展有限公司是注冊于北京市海淀區(qū)高新技術(shù)園的軟件企業(yè)，目前主要業(yè)務(wù)范圍包括軟件測試管理 工具研發(fā)、軟件測試項目外包和軟件測試專業(yè)技術(shù)人才培養(yǎng)及派遣。在軟件測試管理工具研發(fā)領(lǐng)域已成功開發(fā)具有

自主知識產(chǎn)權(quán)的STMP管理軟件。在軟件測試項目外包領(lǐng)域已建立廣泛的業(yè)務(wù)渠道，服務(wù)客戶包括北大軟件工程中心、東軟股份、海輝高科、用友軟件、萊博智科技、電子部5所、11所，航天704所、中國金融認(rèn)證管理中心、國安創(chuàng)想、清華同方、中軟融鑫、長峰科技等100余家企業(yè)，項目覆蓋行業(yè)包括軍工、航天、金融、通信等領(lǐng)域。由安博測試空間技術(shù)中心http://004km.cn/提供 地址：北京市海淀區(qū)學(xué)院路40號大唐電信測試空間樓 聯(lián)系電話：010-62303223 62303260 62303230

第三篇：編寫測試用例方法心得體會

編寫測試用例方法心得體會

編寫背景：

一直以來都不太想把技術(shù)方面的文章寫出來給大家看，一個是怕寫作功底不好誤導(dǎo)哪些剛?cè)腴T的測試同行，自己的表達(dá)能力有限，另一方面怕有的同行拿出去炒作，再者測試網(wǎng)站論壇上關(guān)于測試用例的資料已經(jīng)實在是多。但是看到同行紛紛都在問我測試用例的問題，都很想知道我寫測試用例的心得體會。我就抱著試試看的心態(tài)寫寫吧，希望測試的老前輩看見了，可以給我多提提建議。

編寫測試用例方法心得體會

在我的個人郵箱和MSN上，通常同行都問我類似下面這樣的問題：

１、一個測試用例要寫到什么程度才比較好?

２、剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

對于測試用例，而我目前正在思考的問題是：怎么寫出對公司有價值的測試用例，對公司來說，怎么測試才是最有價值的測試？

下面先來分析第一個問題吧：一個測試用例要寫到什么程度才比較好？

這個問題，沒有定語，沒有說是在什么樣的一個情況下，因此我這里只能就我工作中碰到的情況說說了。說起來比較長阿，大家要有耐心看才行哈。^_^ 在我測試工作中，碰上的測試類型我自己劃分成這么４種： ^

對項目、產(chǎn)品的測試，測試的時候通常要考慮這個項目的周期和測試資源。我所在的公司，通常項目開發(fā)時間都很短４到５個月，然而測試通常都是在開發(fā)即將結(jié)束的時候才真正介入。測試就是１個人負(fù)責(zé)。因此時間和人力資源對測試來說是完成測試工作的一個風(fēng)險。為此在這種情況下，我都是先熟悉系統(tǒng)的業(yè)務(wù)，把握重點業(yè)務(wù)和功能后，參考需求，把測試需求、測試計劃和測試大綱給制定好。由于時間關(guān)系，測試用例都是先寫重點的業(yè)務(wù)，也就是集成測試的測試用例。另外測試用例是根據(jù)測試大綱來的。通常都是先挑最重要的測試項和風(fēng)險大的業(yè)務(wù)功能編寫測試用例。由于測試用例是本人執(zhí)行，所以測試用例可以寫的簡單些，但是一定要開發(fā)人員能夠看明白?？上宜诘墓?，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的ｂｕｇ通常不是在寫測試用例的時候發(fā)現(xiàn)的，而是在測試軟件的過程中，我在家睡覺前的思考和回家的路上思考出來的。這就是手動測試的魅力，有些軟件的缺陷是在你使用軟件的一瞬間和思考的一剎那突然發(fā)現(xiàn)的。所以要我回答測試用例要寫到什么程度才比較好，我覺的只要你所寫的測試用例在你的公司能夠順利的執(zhí)行，不影響你的測試執(zhí)行工作就可以了。因為測試用例寫的太詳細(xì)，你要花費時間和人力成本，這樣出來的測試用例是最好的也是最貴的，一旦需求變更，也需要修改，這時你會發(fā)現(xiàn)這種詳細(xì)的測試用例是最不掙錢的。測試用例寫的太粗，別人看不懂，不能執(zhí)行，那你要花費你的時間去解釋，這就加大了測試的工作量。這也不是好的方法。

第二個問題，剛開始做測試的時候，你是怎么學(xué)習(xí)寫測試用例的？

我之所以選擇測試這個工作是因為：我畢業(yè)后，在第一家公司做技術(shù)支持，產(chǎn)品的問題很多，導(dǎo)致技術(shù)支持工作很辛苦、很累。為了讓用戶買到的產(chǎn)品的質(zhì)量是好的，我選擇了做測試，到了現(xiàn)在的公司。我剛做測試的時候，對測試一無所知，什么測試流程阿、文檔阿都不知道，公司的測試和管理也不規(guī)范。對測試，大家都認(rèn)為不就是拿個鼠標(biāo)點來點去，誰都可以來做。為此，我經(jīng)常上網(wǎng)查測試的資料，看看自己到底適合不適合做測試，測試到底是什么樣的一個職業(yè)，怎么去規(guī)劃自己的個人發(fā)展。其實要做好測試，真是不容易。不喜歡，真是不能做這個職業(yè)。

現(xiàn)在想想自己剛開始寫測試用例的時候，真是好笑。就像小孩子學(xué)習(xí)寫字一樣。先是在網(wǎng)上狂搜索了一把測試用例的模板，綜合了幾個，就形成了。我之所以不用公司原有的測試用例模板，是因為太不適用了。還好，公司沒有嚴(yán)格要求必須要那個模板，只要適用就行。模板找好了，可是寫就費勁了。對于剛做測試的新人，看似簡單的一個填表工作，要寫好真是不簡單。一開始寫的比較不自然，有些生搬硬套，而且還很慢。沒有辦法，那時候沒有人指導(dǎo)我，全靠自己自學(xué)和領(lǐng)悟，所以那段日子很苦阿！多寫幾次后，就知道和領(lǐng)悟了，測試用例要根據(jù)測試大綱來寫，測試大綱要根據(jù)測試計劃來寫。測試大綱更多的是把握住測試項的方向，而測試用例是指導(dǎo)怎么去執(zhí)行測試。還好，我有編程的經(jīng)驗，所以對我熟悉軟件幫了一個很大的忙。熟悉了軟件的業(yè)務(wù)才能去寫測試用例，才能更好的去測試。這也是我一點一點的領(lǐng)悟出來的。說了這么多，不知道這樣的回答是否是回答了這個問題。

最后一個問題了，我盡量少寫些，文字太多了大家看的也累，我寫的也累。嘿嘿。^_^

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標(biāo)準(zhǔn)嗎？

我的體會：

１、測試用例要根據(jù)測試大綱來編寫

２、測試用例也要分測試項進(jìn)行歸類，這樣比較好分析和閱讀。如：業(yè)務(wù)流程測試、安裝測試、功能測試、用戶友好性測試、兼容性測試、性能測試、安全性測試等等。

３、編寫測試用例要考慮各種情況，精力主要集中在軟件的主要業(yè)務(wù)流程和風(fēng)險高的地方。能分出測試優(yōu)先級別就最好了。

４、熟悉系統(tǒng)，對編寫測試用例很有幫助。

５、即使對測試很熟悉了，在時間非常緊的時候，編寫測試用例還是很有必要和好處的。

今天就想到那么些了，以后想到了在補充上了。我把我用的模板給你們粘貼一份上來，只能給你們做些參考，具體還是要看對你所在的公司適用不適用。測試項的歸類我就不列舉了，因為每個公司的都不太一樣。

第四篇：常見的軟件測試用例設(shè)計方法

常見的軟件測試用例設(shè)計方法有以下幾種：

一、等價類劃分

1）確定等價類

有效等價類代表對程序的有效輸入；無效等價類代表的是其他不正確的任何輸入。如果需要，我們還可以將一個等價類劃分為更小的一些等價類。

比如，規(guī)格說明規(guī)定了“請輸入書籍的數(shù)量（1~99）以及書籍的類型（硬皮、軟皮或活頁）”。它們對應(yīng)的等價類分別如下：

書籍?dāng)?shù)量

書籍類型

2）生成測試用例

1.為每個等價類設(shè)置編號。

2.編寫測試用例，盡可能多的覆蓋尚未被覆蓋的有效等價類。直到所有的有效等價類都被測試用例覆蓋。測試用例及其覆蓋的有效等價類如下：

3.編寫測試用例，覆蓋一個且僅一個尚未被覆蓋的無效等價類。直到所有的無效等價類都被測試用例所覆蓋。測試用例及其覆蓋的無效等價類如下：

用單個的測試用例覆蓋無效等價類，是因為有些輸入的錯誤檢查可能會屏蔽或取代其他輸入的錯誤檢查。比如②⑦，也許程序提示“非法的書籍?dāng)?shù)量”后，就不會執(zhí)行對書籍類型的檢查了。

二、邊界值分析

經(jīng)驗證明，考慮了邊界條件的測試用例比其他沒有考慮邊界條件的測試用例，具有更高的測試回報率。所謂邊界條件，是指輸入和輸出等價類中恰好處在邊界、或超過邊界、或在邊界以下的狀態(tài)。

上例中的書籍?dāng)?shù)量范圍是1~99，那么應(yīng)該針對0，1和99，100的情況分別設(shè)計測試用例。

從定義可以看出，等價劃分只關(guān)注輸入空間（輸入等價類）的不同，邊界值分析還需要從輸出空間（輸出等價類）設(shè)計測試用例。

舉例來說：

某個程序按月計算個人所得稅的速算扣除數(shù)，且最小金額是0，最大金額是13,505。使用邊界值分析法，應(yīng)該設(shè)計測試用例測試速算扣除數(shù)結(jié)果為0和13505的情況。此外，還應(yīng)觀察是否可能設(shè)計出導(dǎo)致速算扣除數(shù)為負(fù)數(shù)，或者超過13505的測試用例。

邊界值分析法和等價劃分重要的區(qū)別是，等價劃分是從等價類中挑選任意一個元素作為測試數(shù)據(jù)；邊界值分析法考察正處于等價劃分邊界或在邊界附近的狀態(tài)。

三、因果圖

邊界值分析和等價劃分的缺點是，未對輸入條件的組合情況、輸入條件之間的相互制約關(guān)系進(jìn)行分析。

1）因果圖的基本關(guān)系

?恒等（Identify）:若a為1，則b為1；否則b為0。

?非（NOT）:若a為1，則b為0；否則b為1。

?或（OR）:若a或b或c為1，則d為1；否則d為0。

?與（AND）:若a和b和c都為1，則d為1；否則d為0。

2）因果圖的約束條件

1、對于輸入條件的約束有E、I、O、R四種：

?異（E）:E必須總為真，而a、b最多只有一個為1。

?或（I）:I為真時，a、b和c中至少有一個必須為1。

?唯一（O）:a、b中，有且僅有一個必須為1。

?要求（R）:如果a為1，b也必須為1。

2、對于輸出結(jié)果的約束只有M一種：

屏蔽（M）:如果結(jié)果a為0，則b強制為0。

一、假設(shè)有一規(guī)格說明：

“第一列中的字符必須是‘A’或‘B’，第二列中的字符必須是一個數(shù)字。在這種情況下，對文件進(jìn)行更新。如果第一個字符不正確，產(chǎn)生提示信息X12。如果第二個字符不是數(shù)字，產(chǎn)生提示信息X13?！?/p>

（1）將規(guī)格說明分解為可執(zhí)行的片段，確定“因”和“果”，為每個“因”和“果”都賦予唯一的編號?！耙颉笔菞l件，是指一個明確的輸入條件等價類?！肮笔莿幼?，是指一個輸出或系統(tǒng)轉(zhuǎn)換（輸入對程序或系統(tǒng)狀態(tài)的延續(xù)影響）。

（2）分析規(guī)格說明的語義，轉(zhuǎn)換為因果圖。原因①和原因②不可能同時成立，為因果圖添加對應(yīng)的約束條件，得到右圖。

因果圖和添加了約束條件后的因果圖

（3）將因果圖轉(zhuǎn)換為判定表，每一列代表一個測試用例。

判定表

（4）將判定表中的列轉(zhuǎn)換為測試用例。

二、將因果圖轉(zhuǎn)換為判定表的思路（以上述的例子來說明）

1.選擇一個“果”作為當(dāng)前狀態(tài)。例：71。

2.對因果圖回溯，找出導(dǎo)致該“果”為1的所有因的組合（需要考慮到約束條件）。例：001，000。

3.在判定表中為每個“因”的組合生成一列。例：（列3）和（列4）。

4.對于每種“因”的組合，判斷所有其他“果”的狀態(tài)，并放置在對應(yīng)的每一列中。例：已得在001，000兩種組合下結(jié)點71的結(jié)果為1。判斷在“因”為001的組合下，得到70和72的結(jié)果為0。判斷在“因”為000的組合下，得到70的結(jié)果為0，72的結(jié)果為1。將“果”的狀態(tài)填入其對應(yīng)的列。

對因果圖進(jìn)行回溯時，需要做到以下考慮：

1.當(dāng)回溯經(jīng)過一個結(jié)果為1的OR結(jié)點時，不要將OR結(jié)點的1個以上的輸入同時設(shè)為1。

2.當(dāng)回溯經(jīng)過一個結(jié)果為0的AND結(jié)點時，應(yīng)列舉出導(dǎo)致該結(jié)果為0的所有輸入情況的組合。然而，當(dāng)該AND結(jié)點的一個輸入條件為0時，其他輸入有一個或更多的1，則不必考慮其他輸入為1的所有情況。

3.當(dāng)回溯經(jīng)過一個結(jié)果為0的AND結(jié)點時，所有輸入皆為0的這一種情況應(yīng)當(dāng)列舉出來。

找出因果圖中，所有導(dǎo)致輸出狀態(tài)為0的輸入條件

(1)根據(jù)上述第c)條思路，我們只需列出使得結(jié)點⑤和結(jié)點⑥皆為0的情況。結(jié)點①②③④的取值狀態(tài)為：

0，0，0，0（5=0，6=0）

(2)根據(jù)第b)條思路，對于結(jié)點⑤為1而結(jié)點⑥為0的情況，應(yīng)該列出導(dǎo)致⑥為0的所有輸入情況組合。同時，只需列出一種使得⑤為1的情況即可，不需要列出⑤為1時的所有輸入情況組合。又根據(jù)第a)條思路，當(dāng)結(jié)點⑤為1時，我們不應(yīng)將結(jié)點①和②同時設(shè)為1。于是，得到結(jié)點①②③④的取值狀態(tài)：

1，0，0，0（5=1，6=0）

1，0，0，1（5=1，6=0）

1，0，1，0（5=1，6=0）

同樣的，對于⑤為0而⑥為1的情況，也只需要列出⑥為1的一種情況即可（盡管在本例中也只有這一種）。

0，0，1，1（5=0，6=1）

因果圖有助于用一個系統(tǒng)的方法選擇出高效的測試用例集。它還有一個額外的好處，就是可以指出規(guī)格說明的不完整性和二義性。但通常它不能生成全部應(yīng)該被確定的有效測試用例。

注意：因果圖方法沒有充分考慮邊界條件。建議，最好是單獨考慮邊界值分析。這不意味著我們要為此增加相應(yīng)多的測試用例，而是在由因果圖生成測試用例時，可以將邊界條件分析一并考慮進(jìn)去。最好的結(jié)果是既滿足了兩方面的目標(biāo)，又不需要增加新的測試用例。

四、錯誤推測

錯誤猜測是一項依賴于直覺的非正規(guī)的過程，其基本思想是人們利用直覺和經(jīng)驗猜測可能犯得錯誤或錯誤易發(fā)情況的清單，然后編寫測試用例來暴露這些錯誤。

例如，程序輸入中出現(xiàn)0這個值，就是一種錯誤易發(fā)情況。因此可以編寫測試用例檢查特定的輸入值中有0，或特定的輸出值被強制為0的情況。同樣，在出現(xiàn)輸入或輸出數(shù)目不定的地方，如，對某個列表進(jìn)行搜索，結(jié)果為“空列表”或“只包含一個”條目的列表，也是錯誤容易發(fā)生的情況。

第五篇：常見的測試用例設(shè)計方法都有哪些

/ 6

（常見）測試用例-設(shè)計方法-面試題目

常見的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應(yīng)用。

1.等價類劃分

常見的軟件測試面試題劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.2.邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤.使用邊界值分析方法設(shè)計測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).3.錯誤推測法

基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計測試用例的方法.錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例.例如, 在單元測試時曾列出的許多在模塊中常見的錯誤.以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗的總結(jié)。還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行.這些都是容易發(fā)生錯誤的情況。可選擇這些情況下的例子作為測試用例.4.因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等.考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況.但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當(dāng)多.因此必須考慮采用一種適合于描述對于多種條件的組合,相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計測試用例.這就需要利用因果圖（邏輯模型）.因果圖方法最終生成的就是判定表.它適合于檢查程序輸入條件的各種組合情況.5.正交表分析法

有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增，同時，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進(jìn)行縮減一些用例，從而達(dá)到盡量少的用例覆蓋盡量大的范圍的可能性。

6.場景分析方法

指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。

您認(rèn)為做好測試用例設(shè)計工作的關(guān)鍵是什么？

白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果

黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題

詳細(xì)的描述一個測試活動完整的過程。

1.項目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現(xiàn)的功

能的地方。項目經(jīng)理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項目計劃。然后sqa進(jìn)入項目，開始進(jìn)行統(tǒng)計和跟蹤

2.開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進(jìn)行評審，評審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內(nèi)容上面有描述。

3.測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完成概要設(shè)計文檔，詳細(xì)設(shè)計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。

4.測試用例完成后，測試和開發(fā)需要進(jìn)行評審。

5.測試人員搭建環(huán)境

6.開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進(jìn)行測試，發(fā)現(xiàn)bug后提交給bugzilla。

7.開發(fā)提交第二個版本，包括bug fix以及增加了部分功能，測試人員進(jìn)行測試。

8.重復(fù)上面的工作，一般是3-4個版本后bug數(shù)量減少，達(dá)到出貨的要求。

9.如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。

以往是否曾經(jīng)從事過性能測試工作？請盡可能的詳細(xì)描述您以往的性能測試工作的完整過程。

曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試，主要測試該軟件在同時管理大量終端的情況下，在響應(yīng)時間，cpu/磁盤/內(nèi)存等參數(shù)是否滿足要求。

也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試，主要是測試軟交換系統(tǒng)在有大量呼叫的情況下，響應(yīng)時間，呼叫成功率，cpu/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計要求。

您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應(yīng)用的。

測試網(wǎng)管系統(tǒng)中，使用的mimic來模擬終端，能夠大量的節(jié)省成本。

測試軟交換系統(tǒng)的時候，使用的prolab來模擬終端并發(fā)送呼叫軟交換，他完成了同時數(shù)百人才能完成的摘機(jī)撥號工作，主要工作原理是產(chǎn)生一些符合要求的ip包并發(fā)送給軟交換系統(tǒng)，同時對軟交換系統(tǒng)的回應(yīng)進(jìn)行處理，決定下一步動作。

您認(rèn)為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？

主要是保障在大量用戶的情況下，服務(wù)能正常使用。

在您以往的工作中，一條軟件缺陷（或者叫bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（bug）記錄？

1.在傳統(tǒng)的bugzilla中，bug描述應(yīng)該包括以下的信息

2.和bug產(chǎn)生對應(yīng)的軟件版本

3.開發(fā)的接口人員

4.bug的優(yōu)先級

5.bug的嚴(yán)重程度

6.bug可能屬于的模塊，如果不能確認(rèn)，可以用開發(fā)人員來判斷

7.bug標(biāo)題，需要清晰的描述現(xiàn)象

8.bug描述，需要盡量給出重新bug的步驟

9.附件中能給出相關(guān)的日志和截圖。

高質(zhì)量的bug記錄就是指很容易理解的bug記錄，所以，對于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位。

1、黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別？

軟件的黑盒測試意味著測試要在軟件的接口處進(jìn)行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。

黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：

1）是否有不正確或遺漏的功能？

2）在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？

3）是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？

4）性能上是否能夠滿足要求？

5）是否有初始化或終止性錯誤？

白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。

軟件的白盒測試是對軟件的過程性細(xì)節(jié)做細(xì)致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進(jìn)行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。

白盒測試主要是想對程序模塊進(jìn)行如下檢查：

1）對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。

2）對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

3）在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體。

4）測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己。可以這么說，程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴(kuò)展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴(kuò)展進(jìn)程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進(jìn)程的所有模塊一起測試。

系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）

系統(tǒng)測試的目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。

驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。

驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進(jìn)一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。

● 單元測試的主要目的是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗證過程中的邊界值的錯誤。

● 集成測試主要目的是針對詳細(xì)設(shè)計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。

● 系統(tǒng)測試主要針對概要設(shè)計，檢查了系統(tǒng)作為一個整體是否有效地得到運行，例如在產(chǎn)品設(shè)置中是否達(dá)到了預(yù)期的高性能

● 驗收測試通常由業(yè)務(wù)專家或用戶進(jìn)行，以確認(rèn)產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要(需求)。

2、您認(rèn)為做好測試計劃工作的關(guān)鍵是什么？

1）明確測試的目標(biāo)，增強測試計劃的實用性

編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確

2）堅持“5W”規(guī)則，明確內(nèi)容與過程

“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團(tuán)隊理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。

3）采用評審和更新機(jī)制，保證測試計劃滿足實際需求

測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團(tuán)隊，測試計劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導(dǎo)測試執(zhí)行人員。

4）分別創(chuàng)建測試計劃與測試詳細(xì)規(guī)格、測試用例

應(yīng)把詳細(xì)的測試技術(shù)指標(biāo)包含到獨立創(chuàng)建的測試詳細(xì)規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細(xì)規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細(xì)規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。

3、你認(rèn)為公司的BUG測試流程是什么？

1）當(dāng)測試工程師發(fā)現(xiàn)了一個bug而且在bug tracking tool里面沒有相同的bug, 他需要填寫所有需要的bug信息并且把這個bug分配給test leader

2）如果這個bug不是一個真正的bug, test leader需要close這個bug

3）test leader需要審查bug的各種信息都完備，如果有信息不完整，他需要把狀態(tài)改成”feedback” 并重新assign給提交者

4）如果這個bug是一個真正存在的bug, test leader需要把這個bug分配給相關(guān)的開發(fā)團(tuán)隊的PM, 并且把bug狀態(tài)改成Assigned

5）如果這個bug屬于另外一個開發(fā)團(tuán)隊，PM需要把這個bug重新分配給那個開發(fā)團(tuán)隊的PM

6）PM審查bug,并且分配給相應(yīng)的開發(fā)人員去改正。

7）開發(fā)人員收到bug以后，對相關(guān)的缺陷進(jìn)行改正，并且重新分配給提交bug的測試人員并且把狀態(tài)改成”Fixed”

8）測試人員需要對這個bug進(jìn)行重新測試，保證相關(guān)的缺陷已經(jīng)改正，測試人員可以reopen這個bug如果缺陷依然存在并且重新分配給相關(guān)的開發(fā)人員或者close這個bug如果缺陷已經(jīng)改正。

4、測試人員所應(yīng)具備的知識

1）基本的測試知識，測試方法，測試用例，缺陷的概念

2）測試計劃

3）數(shù)據(jù)方面(數(shù)據(jù)庫/XML/Hibernate/LDAP)

4）表現(xiàn)層知識(JSP/HTML/Struts/CSS)

5）EAI(中間件/SOA概念, 項目相關(guān)的經(jīng)驗)

6）測試自動化知識

7）設(shè)計模式知識(UML等等)

8）敏捷實踐(TDD, Refectoring, CI等等)

9）軟件生命周期經(jīng)驗(分析，設(shè)計，團(tuán)隊開發(fā)，測試，部署)

10）管理經(jīng)驗(Estimation, Mentoring, 團(tuán)隊組織)

11）學(xué)習(xí)能力

5、測試類型共劃分為哪些？

1）功能測試：對軟件功能進(jìn)行測試，檢查軟件的各項功能是否實現(xiàn)了軟件功能說明書（軟件需求）上的要求。

2）界面測試：對用戶界面進(jìn)行測試，檢查用戶界面的美觀度、統(tǒng)一性、易用性等方面的內(nèi)容。

3）流程測試：按操作流程進(jìn)行測試，主要有業(yè)務(wù)流程、數(shù)據(jù)流程、邏輯流程、正反流程，檢查軟件在按照流程操作時是否能夠正確處理。

4）并發(fā)測試：在網(wǎng)絡(luò)環(huán)境、并發(fā)環(huán)境和多用戶條件下對軟件進(jìn)行的測試。

5）極限測試：在軟件的極限條件下進(jìn)行的測試，主要有對數(shù)據(jù)的極限值、邊界值操作，對軟件進(jìn)行致命操作等。

6）數(shù)據(jù)處理測試：對軟件數(shù)據(jù)接口進(jìn)行的測試，主要檢查軟件數(shù)據(jù)處理中輸入、處理、輸出數(shù)據(jù)過程。

7）安全測試：對軟件安全性方面的測試，主要檢測軟件中加密、解密、數(shù)據(jù)備份、恢復(fù)、病毒檢測等問題。

8）性能測試：對軟件整體性能的測試，測試內(nèi)容有適應(yīng)性、健壯性、可恢復(fù)性、災(zāi)難恢復(fù)能力等

9）安裝測試：在不同PC條件、操作系統(tǒng)、模擬客戶機(jī)等條件下進(jìn)行軟件的安裝測試，主要檢查軟件打包或發(fā)布之后存在的問題。

10）性能測試：對軟件整體性能進(jìn)行測試，測試的內(nèi)容有適應(yīng)性、健壯性、可恢復(fù)性、災(zāi)難恢復(fù)能力等

6、你是怎么看待測試的？

1）試想一下如果一個系統(tǒng)開發(fā)完畢后不能正常運行可能造成的后果，損失錢財，損失時間，損失客戶，等等

2）介紹一下軟件測試的意義

a.發(fā)現(xiàn)軟件錯誤；

b.有效定義和實現(xiàn)軟件成分由低層到高層的組裝過程；

c.驗證軟件是否滿足任務(wù)書和系統(tǒng)定義文檔所規(guī)定的技術(shù)要求；

d.為軟件質(zhì)量模型的建立提供依據(jù)。

3）介紹一下軟件測試的目的？

a.確認(rèn)軟件的質(zhì)量，其一方面是確認(rèn)軟件做了你所期望的事情（Do the right thing），并且確認(rèn)軟件以正確的方式來做了這個事件（Do it right）。

b.提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險評估所準(zhǔn)備的信息。

c.軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。

正是基于以上所述，我認(rèn)為軟件測試是整個軟件質(zhì)量保證過程中重要的一部分，這也就是我選擇軟件測試這個行業(yè)的原因

7.如何撰寫集成測試計劃？

1）確定集成測試對象

2）確定集成測試策略

3）確定集成測試驗收標(biāo)準(zhǔn)

4）確定集成測試掛起和恢復(fù)條件

5）估計集成測試工作量

6）估計集成測試所需資源

7）進(jìn)行集成測試任務(wù)劃分（包括任務(wù)名、責(zé)任人、輸入和輸出、風(fēng)險及應(yīng)對措施、進(jìn)度安排等）

8.測試技術(shù)方面的鬼話？

1、功能測試的規(guī)范化、流程化操作；

2、利用Robot錄制和編寫自動功能測試腳本

3、利用LoadRunner進(jìn)行性能測試執(zhí)行

4、主流關(guān)系型數(shù)據(jù)庫（例如Oracle、SQLServer）的優(yōu)化策略

5、非關(guān)系型數(shù)據(jù)庫（例如Trip）的配置、安裝、常用命令等

6、非Windows操作系統(tǒng)的安裝和常用命令

7、常用服務(wù)器的安裝、配置和優(yōu)化策略（Weblogic，TomCat）

8、對系統(tǒng)存在的性能問題進(jìn)行定位診斷

9、對系統(tǒng)存在的性能問題提出優(yōu)化解決方案，并配合研發(fā)和集成人員進(jìn)行系統(tǒng)調(diào)優(yōu)

問hr的問題：

1.貴公司近期和遠(yuǎn)期的發(fā)展目標(biāo)是什么？

2.貴公司的主要競爭對手有哪些？

3.貴公司有多少開發(fā)人員有多少測試人員？

4.貴公司又進(jìn)一步擴(kuò)充測試人員的計劃嗎?

5.如果我有幸能進(jìn)入貴公司的話，我有怎么樣的發(fā)展？

6.測試人員的溝通能力很重要，貴公司有規(guī)范的溝通渠道嗎？

7.請介紹一下貴公司的福利情況。

8.請問我什么時候能知道結(jié)果？