[64] 測試技術常見的十一種問題之其他問題

　　1、 為什麼盡量不要讓時間有富裕的員工去做一些測試？

　　表面上看這體現了管理的效率和靈活性，但實際上也體現了管理者對測試的輕視。測試和測試的人有很大關係。測試工作人員應該是勤奮並富有耐心，善於學習、思考和發現問題，細心有條理，總結問題，如果具備這樣的優點，做其它工作同樣也會很出色，因此這裡還有一個要求，就是要喜歡測試這項工作。如果他是專職的，那麼肯定更有經驗和信心。國內的小夥子好象都喜歡做程式員，兩者工作性質不同，待遇不同，地位不同，對自我實現的價值的認識也不同，這是行業的一個需要改善的問題。如果只是為了完成任務而完成任務，或者發現了幾個問題就覺得滿意了，這在任何其它工作中都是不行的。

　　2、 完全測試程式是可能的嗎？

　　軟體測試初學者可能認為拿到軟體後需要進行完全測試，找到全部的軟體缺陷，使軟體“零缺陷”發布。實際上完全測試是不可能的。主要有以下一個原因：

完全測試比較耗時，時間上不允許；
完全測試通常意味著較多資源投入，這在現實中往往是行不通的；
輸入量太大，不能一一進行測試；
輸出結果太多，只能分類進行驗證；
軟體實現途徑太多；
軟體產品說明書沒有客觀標準，從不同的角度看，軟體缺陷的標準不同；
　　因此測試的程度要根據實際情況確定。

　　3、 軟體測試的風險主要體現在哪裡？

　　我們沒有對軟體進行完全測試，實際就是選擇了風險，因為缺陷極有可能存在沒有進行測試的部分。舉個例子，程式員為了方便，在偵錯工具時會彈出一些提示資訊框，而這些提示只在某種條件下會彈出，碰巧程式發布前這些代碼中的一些沒有被注釋掉。在測試時測試工程師又沒有對其進行測試。如果客戶碰到它，這將是代價昂貴的缺陷，因為交付後才被客戶發現。

　　因此，我們要儘可能的選擇最合適的測試量，把風險降低到最小。

　　4、 發現的缺陷越多，說明軟體缺陷越多嗎？

　　這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個後，會接二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：

代碼複用、拷貝代碼導致程式員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反覆拷貝同一代碼意味可能也複製了缺陷。
程式員比較勞累是可以導致某些連續編寫的功能缺陷較多。程式員加班是一種司空見慣的現象，因此體力不只時容易編寫一些缺陷較多的程式。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。
　　“缺陷一個連著一個”不是一個客觀規律，只是一個常見的現象。如果軟體編寫的比較好，這種現象就不常見了。測試人員只要嚴肅認真的測試程式就可以了。

　　5、 所有的軟體缺陷都能修複嗎？所有的軟體缺陷都要修複嗎？

　　從技術上講，所有的軟體缺陷都是能夠修複的，但是沒有必要修複所有的軟體缺陷。測試人員要做的是能夠正確判斷什麼時候不能追求軟體的完美。對於整個項目團隊，要做的是對每一個軟體缺陷進行取捨，根據風險決定那些缺陷要修複。發生這種現象的主要原因如下：

       沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在項目中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力下，必須放棄某些缺陷的修改。 
        有些缺陷只是特殊情況下出現，這種缺陷處於商業利益考慮，可以在以後升級中進行修複。 
        不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以後有時間時考慮再處理。
　　最後要說的是，缺陷是否修改要由軟體測試人員、專案經理、程式員共同討論來決定是否修複，不同角色的人員從不同的角度來思考，以做出正確的決定。

　　6、 軟體測試人員就是QA嗎？

　　軟體測試人員的職責是儘可能早的找出軟體缺陷，確保得以修複。而品質保證人員（QA）主要職責是建立或者制定標準和方法，提高促進軟體開發能力和減少軟體缺陷。測試人員的主要工作是測試，品質保證人員日常工作重要內容是檢查與評審，測試工作也是測試保證人員的工作對象。

　　軟體測試和品質是相輔相成的關係，都是為了提高軟體品質而工作。

　　7、 如何減少測試人員跳槽帶來的損失？

　　在IT行業裡跳槽已經是一種司空見慣的現象，而且跳槽無論給公司還是給個人都會帶來一定的損失。測試隊伍也無疑會面臨跳槽的威脅，作為測試經理管理者，只有從日常工作中開始做起，最能最大限度的減少損失。建議我們從以下兩個方面做起：

        加強部門內員工之間的互相學習，互相學習是建立學習型組織的基本要求，是知識互相轉移的過程。在此基礎上，可以把個人擁有的技術以知識的形式沉積下來，也就完成了隱性知識到顯性知識的轉化。 
        通常情況下，企業能為員工提供足夠大的發展空間時，如果不是待遇特別低，員工都不會主動離開企業。因此我們要想留住員工，管理者就應該把員工的個人成長和企業的發展聯絡起來，為員工設定合理髮展規劃並付諸實現。不過這項要求做起來比較，要有比較好的企業文化為依託。
　　8、 測試產品與測試專案的區別是什嗎？

　　習慣上把開發完成後進行商業化、幾乎不進行代碼修改就可以售給使用者使用的軟體成為軟體產品，也就是可以買“賣拷貝”的軟體，例如Windows 2000。而通常把針對一個或者幾個特定的使用者而開發的軟體成為軟體項目，軟體項目是一種個人化的產品，可以是按照使用者要求全部重新開發，也可以修改已有的軟體產品來滿足特定的使用者需求。項目和產品的不同特點，決定我們測試產品和測試專案仍然會有很多不同的地方：

        品質要求不同。通常產品的品質要高一些，修複發布後產品的缺陷成本較高，甚至會帶來很多負面的影響。而做項目通常面向某一使用者，雖然品質越高越好，但是一般只要滿足使用者要求就可以了。 
        測試資源投入多少不同。做軟體產品通常是研發中心來開發，進度壓力要小些。同時由於品質要求高，因此會投入較多的人力、物力資源。 
        項目最後要和使用者共同驗收測試，這是產品測試不具有的特點。
　　此外，測試產品與測試專案在缺陷管理方面、測試策略制定都會有很大不同，測試管理者應該結合具體的環境，恰如其分的完成工作。

　　9、 和使用者共同測試（UAT測試）的注意點有哪些？

　　軟體產品在投產前，通常都會進行使用者驗收測試。如果使用者驗收測試沒有通過，直接結果就是那不到“Money”，間接影響是損害了公司的形象，而後者的影響往往更嚴重。根據作者的經驗，使用者驗收測試一定要讓使用者滿意。

　　實際上使用者現場測試更趨於是一種示範。在不欺騙使用者的前提下，我們向使用者展示我們軟體的優點，最後讓“上帝”滿意並欣然掏出“銀子”才是我們的目標。因此使用者測試要注意下面的事項：

　　（1）使用者現場測試不可能測試全部功能，因此要測試核心功能。這需要提前做好準備，這些核心功能一定要預先經過測試，證明沒有問題才可以和使用者共同進行測試。測試核心模組的目的是建立使用者對軟體的信心。當然如果這些模組如果問題較多，不應該進行示範。

      （2）如果某些模組確實有問題，我們可以示範其它重要的業務功能模組，必要時要向

　　使用者做成合理的解釋。爭得時間後，及時修改缺陷來彌補。

　　（3）永遠不能欺騙使用者，矇混過關。道理很簡單，因為軟體是要給使用者用的，問題早晚會暴露出來，除非你可以馬上修改。

　　和使用者進行測試還要注意各種交流技巧，爭取不但短期利益得到了滿足，還要為後面得合作打好基礎。

　　10、如何編寫提交給使用者的測試報告？

　　隨著測試工作越來越受重視，Team Dev向客戶提供測試文檔是不可避免的事情。很多人會問：“我們可以把工作中的測試報告提供給客戶嗎？”答案是否定的。因為提供自我裝載報告，可能會讓客戶失去信心，甚至否定項目。

　　測試報告一般分為自我裝載報告和正式發行前小眾測試報告。內部報告是我們在測試工作中的項目文檔，反映了測試工作的實施情況，這裡不過多討論，讀者可以參考第9章的相關內容。這裡主要討論一下正式發行前小眾測試報告的寫法，一般正式發行前小眾測試報告要滿足下面幾個要求：

根據自我裝載報告進行編寫，一般可以摘錄；
不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修複的；
報告上面的內容盡量要真實可靠；
整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是效能測試報告。
　　總之，正式發行前小眾測試報告要小心謹慎的編寫。

　　11、開發人員老是犯一些低級錯誤怎麼解決？

　　這種現象在開發流程不規範的團隊裡特別常見，尤其是一些“作坊式”的團隊裡。解決這種問題一般從兩個方面入手：

　　一方面從開發管理入手，也就是從根源來解決問題。可以制定規範的開發流程，甚至可以制定懲罰制度，還有就是軟體開發前做好規劃設計。

　　另一方面就是加強測試，具體做法就是加強開發人員的自己測試，把這些問題“消滅”在開發階段，這是比較好的做法，讀者可以參考第13章試案例分析的“13.1.2缺陷反覆出現，誰的責任”小節，13.1.2專門討論了這類問題的方法。

　　此外，還可以通過規範的缺陷管理來對開發人員進行控制，比如測試部門整理出常見的缺陷，讓開發人員自己對照進行檢查，以減少這類低級錯誤的發生。

　　開發人員犯錯誤是正常的現象，作為測試人員一定不能抱怨，要認認真真的解決問題才是上策。

　　12.測試載入器在測試工作中是什麼地位？

　　國內的很多測試工程師對測試載入器相當迷戀，尤其是一些新手，甚至期望測試載入器可以取代手工測試。測試載入器在測試工作中起的是輔助作用，一般用來提高測試效率。自動化測試彌補了手工測試的不足，減輕一定的工作量。實際上測試載入器是無法替代大多數手工測試的，而一些諸如效能測試等自動化測試也是手工所不能完成的。

　　對於自動化的測試技術，應當依據軟體的不同情況來分別對待，一般自動技術會應用在引起大量重複性工作的地方、系統的壓力點、以及任何適合使用程式解決大批量輸入資料的地方。然後再尋找合適的自動化的測試工具，或者自己開發測試程式。一定不要為了使用測試載入器而使用。

轉載自：www.51testing.com