軟體測試工程師面試–start

     上個星期去TZ面試，他們提供的崗位並沒有我熟悉的軟體開發，但是盧老師介紹我過來，我總不能臨時逃跑吧。只好硬著頭皮選了軟體測試崗位。筆試和面試的經曆前面我有記載：

經曆：http://www.cnblogs.com/kulong995/archive/2010/02/24/1672848.html

筆試題：http://www.cnblogs.com/kulong995/archive/2010/03/05/1679338.html

其實再這後面還有一輪面試，面試官只問了我三個問題：1.軟體測試的流程。2.軟體測試的常規方法。3.關於黑盒和白盒測試。當時出於抵觸情緒，我都沒有好好回答就離開了。

      後來胡星期一去面試了，筆試和面試的結果應該和我一樣，但是他主動提出自己會as，曉得air開發。面試官對這個技術也有興趣，就交個他一個題目讓他回去做。經過幾天的努力，那個程式寫出來來了，他也獲得了複試的機會。在有些方面，我確實比不上他：主動、自信、有實力。我與面試官溝通的時候，只是問他們公司招什麼樣的職位，發現沒有適合我的，就放棄了，而沒有充分的展示自己的能力來勾起面試官的興趣。當然，這也存在一定的運氣成分，但是如果自己不嘗試，又何來的機會呢？

       盧老師後來又再次幫我與那邊溝通，讓我也去複試一下。叮囑我這幾天熟悉下測試相關知識。但是我一直拖到今天這個時候才開始，我真的很想做開發，做自己感興趣的事，但怎麼也不能辜負他的好意啊！也許測試也適合我呢?當然，我是不會放棄做開發的。

       隨便上網瞭解了下作測試人員的基本要求：電腦專業技能（包括測試專業技能、軟體編程技能和網路、作業系統、資料庫、中介軟體等知識）。

       發現我每個方面都懂一點點，但又不精通，也沒有相關的經驗。但我想，電腦專業技能對我來說應該不難。我相信自己會上手很快的：）

       除了基本要求，還有就是做軟體測試的素質，我發現這個要求很搞。我打算一條條分析：

①、溝通能力 -- 我樂於與人溝通，也善於跟人打交道。

②、移情能力 -- 我是個感情豐富，又有同情心的人。

③、技術能力 -- 這個差點，我對常規的測試載入器都較少使用。

④、自信心 --  這個比較缺乏，我總認為自己不夠好，不夠專業。

⑤、外交能力 -- 這個經驗得學習，也得注意，我說話比較直。

⑥、幽默感 -- 朋友一致認可的。

⑦、很強的記憶力 -- 上心的事記得很牢，一般的事過了就忘。

⑧、耐心 -- 長期耐心可能不行，但是短期耐心很強。從自己平常偵錯工具可以看出。
⑨、懷疑精神 -- 缺乏。總相信牛人是對的。

⑩、自我督促 -- 缺乏。能為自己制定計劃，但是長期實施有困難。

 11、洞察力 --  平常粗心大意，但是能留心到別人不注意的地方。

     通過分析，我還是能成為測試工程師吧~對於薄弱的技術環節，我想現在趕快抱一抱佛腳吧。searching......好吧，我承認以前小看測試了，以為就是測試下程式能不能正確運行，會不會出bug就ok了。

     先來說說第一個問題，軟體測試的流程是什麼。

測試的流程：

需求階段流程圖：

 

單元/整合測試階段流程圖

系統測試階段流程圖

壓力測試流程圖

 

效能測試流程圖

 

 僅僅瞭解就夠複雜的了，實際操作過程中的問題肯定更多。像壓力測試、效能測試，一般的情況下我哪裡用得上啊。雖然也知道些什麼分布式應用、海量儲存之類的，但是我連1T的資料都沒見過。光說說那是是空話=。=

 

第二個問題：軟體測試的常規方法。

不看不知道，原來比我想象中的還要多啊。

第三個問題：黑箱測試和白盒測試

     白盒測試(White-box testing)是通過程式的原始碼進行測試而不使用使用者介面。這種類型的測試需要從代碼句法發現內部代碼在演算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。

　　黑箱測試(Black-box testing)是通過使用整個軟體或某種軟體功能來嚴格地測試, 而並沒有通過檢查程式的原始碼或者很清楚地瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。測試人員通過輸入他們的資料然後看輸出的結果從而瞭解軟體怎樣工作。通常測試人員在進行測試時不僅使用肯定出正確結果的輸入資料，而且還會使用有挑戰性的輸入資料以及可能結果會出錯的輸入資料以便瞭解軟體怎樣處理各種類型的資料。

 

順便補充一下軟體工程課上，我們學到的其他測試方法介紹：

      灰箱測試或灰盒測試(Gray-box testing):灰箱測試就像黑箱測試一樣是通過使用者介面測試，但是測試人員已經有所瞭解該軟體或某種軟體功能的原始碼程式具體是怎樣設計的。甚至於還讀過部分原始碼。 因此測試人員可以有的放矢地進行某種確定的條件/功能的測試。這樣做的意義在於:如果你知道產品內部的設計和對產品有透過使用者介面的深入瞭解，你就能夠更有效和深入地從使用者介面來測試它的各項效能。

　　有效用例(Valid case)或者叫合法輸入用例:是那些已知軟體程式能正確地處理的測試案例。一般是指軟體輸入的測試案例。比如說，在 Microsoft Excel 中，用鍵盤輸入“=1+1”, 看到的結果是“2”。 這裡輸入的有效用例是“=1+1”。無效用例(Invalid case有人叫不合法輸入用例)或者出錯用例(error case):是那些事先就知道軟體程式不支援處理的測試案例。比如說在 Microsoft Excel 中，用鍵盤輸入“=a+1”, 看到的結果是“#NAME?”。這裡輸入的“=a+1”既是無效用例同時也是出錯用例。

　　邊界條件(Boundary Cases):環繞邊界值的測試。通常意味著最大值，最小值或者所設計軟體能夠處理的最長的字串等等。比如說某軟體字型的字型大小支援範圍是:從8到72。那麼邊界測試案例應該包括:小於8, 等於8, 等於72 和大於72。

　　等價類別(equivalent classes):等價類別測試案例指的是如果有很多測試案例執行再多也不會找到新的中的缺陷。因為雖然輸入和輸出結果有所不同，但是它們都通過同樣的軟體的原始碼路徑。通常只要一個原始碼程式的路徑是用於處理一定數值範圍內的所有數值，那麼除了邊界值以外，在邊界值範圍以內的所有數值一般都屬於等價類別。因為如果軟體程式能正確處理一個值，也就意味著該程式能正確處理在這個範圍內的除了邊界值以外的其他任何有效輸入值。我們來用以上軟體字型的字型大小來舉例說明。軟體支援的字型大小範圍是:從8到72。那麼8和72之間的所有支援的字型大小都可以被認為是等價類別的測試案例。再比如:測試超連結時兩個用例http://www.yahoo.com/ 和 http://www.yahoo2.com/ 也是等價類別的測試案例。

 

 先記下這些知識，應付下吧。希望明天去面試不是Stop，而是Continue......

 

 

結果。。End.