軟件測試?？济嬖囶}-軟件測試面試寶典(10)

擔任過測試管理員、測試設計員、測試員

61.測試用例設計的原則是什么？目前主要的測試用例設計方法有哪些？

• 代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數據、操作和環境設置等.
• 可判定性：即測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果.
• 可再現性：即對同樣的測試用例，系統的執行結果應當是相同的。
• 方法有等價類、邊界值、因果圖、狀態圖、正交法、大綱法

61.LoadRunner 分為哪三個模塊？請簡述各模塊的主要功能。

Virtual User Generator：用于錄制腳步
Mercury LoadRunner Controller：用于創建、運行和監控場景
Mercury LoadRunner Analysis：用于分析測試結果

62.你對測試最大的興趣在哪里？為什么？

最大的興趣就是測試有難度，有挑戰性！做測試越久越能感覺到做好測試有多難。曾經在無憂測試網上看到一篇文章，是關于如何做好一名測試工程師。一共羅列了 11，12 點，有部分是和人的性格有關，有部分需要后天的努力。但除了性格有關的 1，2 點我沒有把握，其他點我都很有信心做好它。剛開始進入測試行業時，對測試的認識是從無憂測試網上了解到的一些資料，當時是沖著做測試需要很多技能才能做的好，雖然入門容易，但做好很難，比開發更難，雖然當時我很想做開發（學校專業課我基本上不缺席，因為我喜歡我的專業），但看到測試比開發更難更有
挑戰性，想做好測試的意志就更堅定了。
我覺得做測試整個過程中有 2 點讓我覺得很有難度（對我來說，有難度的東西我就非常感興趣），第一是測試用例的設計，因為測試的精華就在測試用例的設計上了，要在版本出來之前，把用例寫好，用什么測試方法寫？（也就是測試計劃或測試策略），如果你剛測試一個新任務時，你得花一定的時間去消化業務需求和技術基礎，業務需求很好理解（多和產品經理和開發人員溝通就能達到目的），而技術基礎可就沒那么簡單了，這需要你自覺的學習能力，比如說網站吧，最基本的技術知識你要知道網站內部是怎么運作的的，后臺是怎么響應用戶請求的？測試環境如何搭建？這些都需要最早的學好。至少在開始測試之前能做好基本的準備，可能會遇到什么難題？需求細節是不是沒有確定好？這些問題都能在設計用例的時候發現。
第二是發現 BUG 的時候了，這應該是測試人員最基本的任務了，一般按測試用例開始測試就能發現大部分的 bug，還有一部分 bug 需要測試的過程中更了解所測版本的情況獲得更多信息，補充測試用例，測試出 bug。還有如何發現 bug？這就需要在測試用例有效的情況下，通過細心和耐心去發現 bug 了，每個用例都有可能發現 bug，每個地方都有可能出錯，所以測試過程中思維要清晰（測試過程數據流及結果都得看仔細了，bug 都在里面發現的）。如何描述 bug 也很有講究，bug 在什么情況下會產生，如果條件變化一點點，就不會有這個 bug，以哪些最少的操作步驟就能重現這個bug，這個bug產生的規律是什么？如果你夠厲害的話，可以幫開發人員初步定位問題。

63.當開發人員說不是 G BUG 時，你如何應付？

開發人員說不是 bug，有 2 種情況，

• 一是需求沒有確定，所以我可以這么做，這個時候可以找來產品經理進行確認，需不需要改動，3 方商量確定好后再看要不要改。
• 二是這種情況不可能發生，所以不需要修改，這個時候，我可以先盡可能的說出是 BUG 的依據是什么？
  如果被用戶發現或出了問題，會有什么不良結果？程序員可能會給你很多理由，你可以對他的解釋進行反駁。如果還是不行，那我可以給這個問題提出來,跟開發經理和測試經理進行確認,如果要修改就改,如果不要修改就不改。其實有些真的不是 bug，我也只是建議的方式寫進 TD 中，如果開發人員不修改也沒有大問題。如果確定是 bug 的話，一定要堅持自己的
  立場，讓問題得到最后的確認。

64.為什么要在一個團隊中開展軟件測試工作？

因為沒有經過測試的軟件很難在發布之前知道該軟件的質量，就好比 ISO 質量認證一樣，測試同樣也需要質量的保證，這個時候就需要在團隊中開展軟件測試的工作。在測試的過程發現軟件中存在的問題，及時讓開發人員得知并修改問題，在即將發布時，從測試報告中得出軟件的質量情況。#####65.如果有機會轉成開發人員，你會去做開發工作嗎？

原文轉自：https://blog.csdn.net/mj813/article/details/52451355