以下是一次典型的軟件測試電話面試分享，答案僅為個人看法，非標準答案。希望對正在找軟件測試工作的同學有所幫幫助。
1、自我介紹
我叫XXX，畢業于XX大學計算機科學與技術專業。畢業后進入XX公司做了X年的軟件測試工作，主要從事XXX項目功能及性能測試的工作，熟悉TD/QTP/LoadRunner/SqlSever等，注重團隊合作，工作認真負責，有強烈的責任心，喜歡專研新技術；同時帶領過XX項目的管理工作，熟悉項目管理流程...
有些公司可能還需要準備一份英文的自我介紹。
2、測試流程
就說說最近的這次xxxx網站功能的測試流程。
首先：得到相關文檔（需求文檔和設計文檔），理解需求和設計思想后，制定測試計劃（需評審），擬定測試策略（需評審），需要考慮到測試環境，測試時間，測試風險等
第二步：設計測試用例，測試策略是：先完成網站部分的功能點測試，然后再進行系統測試（包括與其他模塊的聯調測試）。進行測試用例的設計時，需要覆蓋到各種正常、異常處理情況。同時還包括界面測試、瀏覽器兼容性測試，易用測試及性能測試等。
第三步：搭建測試環境，執行測試，記錄測試缺陷
第四步：進行測試缺陷分析，完成測試報告編寫
3、LoadRunner 如何優化腳本
● 參數化（模擬真實的用戶選擇）
● 手動關聯（服務器返回的信息，例如sessionid，key的值等）
● 添加相應事務的集合點（主要是用于控制并發情況）與檢查點（主要用于檢查文字是否正確和圖片是否正常顯示）
4、說一說工作中發現有價值的bug
拿xxx來說發現登錄模塊中，出現登錄延時現象，服務器響應很慢，通過多次測試在分析與確認以及和開發人員的溝通發現是login的**有問題。
拿xxx來說，用于導航的樹型菜單，加載數據延時，通過反復測試與確認，和開發人員溝通發現是算法和當初的設計加載數據導致的。
5、Bug管理流程
● 發現Bug，使用缺陷管理工具提交到Bug管理庫，此時狀態時New
● 測試TM審核缺陷，如果確認是問題，再分配給對應的開發人員，設置狀態是Open
● 如果不是錯誤，則拒絕，設置為Declined（拒絕）狀態
● 開發人員查詢狀態為Open的Bug，如果不是錯誤，則置狀態為Declined；如果是Bug則修復并置狀態為Fixed；不能解決的Bug，要留下文字說明及保持Bug為Open狀態；對于不能解決和延期解決的Bug，不能由開發人員自己決定，一般要通過某種會議（評審會）通過才能認可
● 測試人員查詢狀態為Fixed的Bug，然后驗證Bug是否已解決，如解決置Bug的狀態為Closed，如沒有解決置狀態為Reopen
6、軟件錯誤流程管理要點
● 為了保證錯誤的正確性，需要有豐富測試經驗的測試人員驗證發現的錯誤是否是真正的錯誤，書寫的測試步驟是否準確，可以重復。
● 每次對錯誤的處理都要保留處理信息，包括處理姓名，時間，處理方法，處理意見，Bug狀態。
● 拒絕或延期錯誤不能由程序員單方面決定，應該由項目經理，測試經理和設計經理共同決定。
● 錯誤修復后必須由報告錯誤的測試人員驗證后，確認已經修復，才能關閉錯誤。
● 加強測試人員與程序員的交流，對于某些不能重復的錯誤，可以請測試人員補充詳細的測試步驟和方法，以及必要的測試用例
7、談談個人軟件測試職業發展計劃
個人認為測試經驗越多，測試能力越高。所以我的職業發展是需要時間累積的，一步一步向測試經理目標靠近。而且我也有初步的職業規劃，前3年累積測試經驗，不斷的更新自己改正自己，做好測試任務，擴展更多的技術。做一個全面的測試人員，我希望能夠在一個好的職位上待幾年，而且最好有一次晉升，然后就期待著下一步。不管是向上提升，還是在企業內橫向調動，對我個人來說，我希望找到一家企業，一家愿意做相互投入的企業。
8、你有哪些優點？
我的學習能力和適應環境的能力很強，和同事們的關系處理的非常融洽，工作中很細心，投入，一旦下定決心做某事，我就要把它做好。熟話說的好：細節決定成敗，我覺得這句話在測試當中相當實用，往往是一個不起眼的小問題，引起了Bug.
9、你有哪些缺點？
我這人比較執著，認定的事情就不會放棄。在家的時候老媽也經常說我蠻固執的，在就是個性子有點急，分配給我的工作，我總想趕在第一時間盡快做好。
10、有沒有意向去外地工作？
我一直以來都比較獨立，不喜歡依賴于人，年輕人也需要多在外地多闖一闖。至于去哪里工作，我服從公司的調度和安排。
11、對于加班有什么看法？
有句話說的好加班是合理的，不加班也是合理，除特殊情況外，我都服從工作上的安排。
12、對自己的評價？
對于工作我比較有責任心和耐心，具備良好的職業素養。對于生活充滿信心和愛心，懷著一顆感恩的心，努力做好每一件事情。
13、您所熟悉的測試用例設計方法都有哪些？
● 等價類劃分
● 邊界值分析法
● 錯誤推測法：基于經驗和直覺推測程序中所有可能存在的各種錯誤， 從而有針對性的設計測試用例的方法
● 因果圖方法：輸入條件之間的聯系和相互組合情況，生成判定表。從而設計測試用例
● 比較法：比較每個版本 主要用于后期的用例
● 業務流程圖分析和狀態轉換分析/業務邏輯分析
14、通過畫因果圖來寫測試用例的步驟為：
● 分析軟件規格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。
● 分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的是什么關系？根據這些關系，畫出因果圖。
● 由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件。
● 把因果圖轉換成判定表。
● 把判定表的每一列拿出來作為依據，設計測試用例。
15、您認為做好測試用例設計工作的關鍵是什么？
● 白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程序邏輯結果
● 黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
16、什么是安全性測試？
全測試是在IT軟件產品的生命周期中，特別是產品開發基本完成到發布階段，對產品進行檢驗以驗證產品符合安全需求定義和產品質量標準的過程 。
● 用戶認證安全
● 系統網絡安全
● 數據庫安全
17、什么是集成測試？
在單元測試的基礎上，將所有模塊按照設計要求組裝成為子系統或系統，進行集成測試。英文一些模塊雖然能夠單獨工作，但并不能保證連接起來也能正常的工作。程序在某些局部反映不出來的問題，在全局上很可能暴露出來，影響功能的實現。
集成測試應該考慮以下問題：
● 在把各個模塊連接起來的時候，穿越模塊接口的數據是否會丟失；
● 各個子功能組合起來，能否達到預期要求的父功能；
● 一個模塊的功能是否會對另一個模塊的功能產生不利的影響；
● 全局數據結構是否有問題；
● 單個模塊的誤差積累起來，是否會放大，從而達到不可接受的程度
18、你有什么問題要問的？
可以問一問該公司的測試流程，個人職業發展方向，公司產品項目等等。