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

編輯測試用例方法感言

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

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

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

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

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

由于測試用例是本人執行，所以測試用例可以寫的簡單些，但是一定要開發人員能夠看明白。可惜我所在的公司，都沒有人來看我的測試用例。測試用例對我來說是用來提示我不要忘記了要測試哪些項。一些很有價值的bug通常不是在寫測試用例的時候發現的，而是在

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

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

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

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

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

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

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

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

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

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

由安博測試空間技術中心http://www.tmdps.cn/提供

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

編寫背景：

一直以來都不太想把技術方面的文章寫出來給大家看，一個是怕寫作功底不好誤導哪些剛入門的測試同行，自己的表達能力有限，另一方面怕有的同行拿出去炒作，再者測試網站論壇上關于測試用例的資料已經實在是多。但是看到同行紛紛都在問我測試用例的問題，都很想知道我寫測試用例的心得體會。我就抱著試試看的心態寫寫吧，希望測試的老前輩看見了，可以給我多提提建議。

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

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

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

２、剛開始做測試的時候，你是怎么學習寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

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

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

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

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

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

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

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

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

１、測試用例要根據測試大綱來編寫

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

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

４、熟悉系統，對編寫測試用例很有幫助。

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

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

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

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

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

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

編寫背景：

一直以來都不太想把技術方面的文章寫出來給大家看，一個是怕寫作功底不好誤導哪些剛入門的測試同行，自己的表達能力有限，另一方面怕有的同行拿出去炒作，再者測試網站論壇上關于測試用例的資料已經實在是多。但是看到同行紛紛都在問我測試用例的問題，都很想知道我寫測試用例的心得體會。我就抱著試試看的心態寫寫吧，希望測試的老前輩看見了，可以給我多提提建議。

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

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

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

２、剛開始做測試的時候，你是怎么學習寫測試用例的？

３、你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

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

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

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

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

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

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

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

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

你對黑盒測試用例的編寫的體會是什么？有什么好的版本或者標準嗎？

我的體會：

１、測試用例要根據測試大綱來編寫

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

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

４、熟悉系統，對編寫測試用例很有幫助。

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

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

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

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

一、等價類劃分

1）確定等價類

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

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

書籍數量

書籍類型

2）生成測試用例

1.為每個等價類設置編號。

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

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

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

二、邊界值分析

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

上例中的書籍數量范圍是1~99，那么應該針對0，1和99，100的情況分別設計測試用例。

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

舉例來說：

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

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

三、因果圖

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

1）因果圖的基本關系

?恒等（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、對于輸出結果的約束只有M一種：

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

一、假設有一規格說明：

“第一列中的字符必須是‘A’或‘B’，第二列中的字符必須是一個數字。在這種情況下，對文件進行更新。如果第一個字符不正確，產生提示信息X12。如果第二個字符不是數字，產生提示信息X13。”

（1）將規格說明分解為可執行的片段，確定“因”和“果”，為每個“因”和“果”都賦予唯一的編號。“因”是條件，是指一個明確的輸入條件等價類。“果”是動作，是指一個輸出或系統轉換（輸入對程序或系統狀態的延續影響）。

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

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

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

判定表

（4）將判定表中的列轉換為測試用例。

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

1.選擇一個“果”作為當前狀態。例：71。

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

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

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

對因果圖進行回溯時，需要做到以下考慮：

1.當回溯經過一個結果為1的OR結點時，不要將OR結點的1個以上的輸入同時設為1。

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

3.當回溯經過一個結果為0的AND結點時，所有輸入皆為0的這一種情況應當列舉出來。

找出因果圖中，所有導致輸出狀態為0的輸入條件

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

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

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

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）

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

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

四、錯誤推測

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

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

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

/ 6

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

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

1.等價類劃分

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

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

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

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

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

6.場景分析方法

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

您認為做好測試用例設計工作的關鍵是什么？

白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果

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

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

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

能的地方。項目經理通過綜合開發人員，測試人員以及客戶的意見，完成項目計劃。然后sqa進入項目，開始進行統計和跟蹤

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

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

4.測試用例完成后，測試和開發需要進行評審。

5.測試人員搭建環境

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

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

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

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

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

曾經做過一套網管系統的性能測試，主要測試該軟件在同時管理大量終端的情況下，在響應時間，cpu/磁盤/內存等參數是否滿足要求。

也曾經做過軟交換系統的呼叫性能測試，主要是測試軟交換系統在有大量呼叫的情況下，響應時間，呼叫成功率，cpu/磁盤/內存等參數是否滿足設計要求。

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

測試網管系統中，使用的mimic來模擬終端，能夠大量的節省成本。

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

您認為性能測試工作的目的是什么？做好性能測試工作的關鍵是什么？

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

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

1.在傳統的bugzilla中，bug描述應該包括以下的信息

2.和bug產生對應的軟件版本

3.開發的接口人員

4.bug的優先級

5.bug的嚴重程度

6.bug可能屬于的模塊，如果不能確認，可以用開發人員來判斷

7.bug標題，需要清晰的描述現象

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

9.附件中能給出相關的日志和截圖。

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

1、黑盒測試、白盒測試、單元測試、集成測試、系統測試、驗收測試的區別？

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

黑盒測試主要是為了發現以下幾類錯誤：

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

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

3）是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？

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

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

白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。

軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。

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

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

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

3）在循環的邊界和運行的界限內執行循環體。

4）測試內部數據結構的有效性，等等。

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

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

系統測試是將經過測試的子系統裝配成一個完整系統來測試。它是檢驗系統是否確實能提供系統方案說明書中指定功能的有效方法。（常見的聯調測試）

系統測試的目的是對最終軟件系統進行全面的測試，確保最終軟件系統滿足產品需求并且遵循系統設計。

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

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

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

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

● 系統測試主要針對概要設計，檢查了系統作為一個整體是否有效地得到運行，例如在產品設置中是否達到了預期的高性能

● 驗收測試通常由業務專家或用戶進行，以確認產品能真正符合用戶業務上的需要(需求)。

2、您認為做好測試計劃工作的關鍵是什么？

1）明確測試的目標，增強測試計劃的實用性

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

2）堅持“5W”規則，明確內容與過程

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

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

測試計劃寫作完成后，如果沒有經過評審，直接發送給測試團隊，測試計劃內容的可能不準確或遺漏測試內容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內容沒有及時更新，誤導測試執行人員。

4）分別創建測試計劃與測試詳細規格、測試用例

應把詳細的測試技術指標包含到獨立創建的測試詳細規格文檔，把用于指導測試小組執行測試過程的測試用例放到獨立創建的測試用例文檔或測試用例管理數據庫中。測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關系，測試計劃主要從宏觀上規劃測試活動的范圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。

3、你認為公司的BUG測試流程是什么？

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

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

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

4）如果這個bug是一個真正存在的bug, test leader需要把這個bug分配給相關的開發團隊的PM, 并且把bug狀態改成Assigned

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

6）PM審查bug,并且分配給相應的開發人員去改正。

7）開發人員收到bug以后，對相關的缺陷進行改正，并且重新分配給提交bug的測試人員并且把狀態改成”Fixed”

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

4、測試人員所應具備的知識

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

2）測試計劃

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

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

5）EAI(中間件/SOA概念, 項目相關的經驗)

6）測試自動化知識

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

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

9）軟件生命周期經驗(分析，設計，團隊開發，測試，部署)

10）管理經驗(Estimation, Mentoring, 團隊組織)

11）學習能力

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

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

2）界面測試：對用戶界面進行測試，檢查用戶界面的美觀度、統一性、易用性等方面的內容。

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

4）并發測試：在網絡環境、并發環境和多用戶條件下對軟件進行的測試。

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

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

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

8）性能測試：對軟件整體性能的測試，測試內容有適應性、健壯性、可恢復性、災難恢復能力等

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

10）性能測試：對軟件整體性能進行測試，測試的內容有適應性、健壯性、可恢復性、災難恢復能力等

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

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

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

a.發現軟件錯誤；

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

c.驗證軟件是否滿足任務書和系統定義文檔所規定的技術要求；

d.為軟件質量模型的建立提供依據。

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

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

b.提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息。

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

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

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

1）確定集成測試對象

2）確定集成測試策略

3）確定集成測試驗收標準

4）確定集成測試掛起和恢復條件

5）估計集成測試工作量

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

7）進行集成測試任務劃分（包括任務名、責任人、輸入和輸出、風險及應對措施、進度安排等）

8.測試技術方面的鬼話？

1、功能測試的規范化、流程化操作；

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

3、利用LoadRunner進行性能測試執行

4、主流關系型數據庫（例如Oracle、SQLServer）的優化策略

5、非關系型數據庫（例如Trip）的配置、安裝、常用命令等

6、非Windows操作系統的安裝和常用命令

7、常用服務器的安裝、配置和優化策略（Weblogic，TomCat）

8、對系統存在的性能問題進行定位診斷

9、對系統存在的性能問題提出優化解決方案，并配合研發和集成人員進行系統調優

問hr的問題：

1.貴公司近期和遠期的發展目標是什么？

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

3.貴公司有多少開發人員有多少測試人員？

4.貴公司又進一步擴充測試人員的計劃嗎?

5.如果我有幸能進入貴公司的話，我有怎么樣的發展？

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

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

8.請問我什么時候能知道結果？