【新炬網路名師大講堂】軟體測試中常見問題與解決辦法

軟體測試中常見問題與解決辦法
1 描述缺陷
軟體測試人員對提交的缺陷往往需要向開發人員進行解釋或者演示後，才能讓人明白他真正要表達的意思。實際上，是否能夠清晰地描述軟體缺陷，體現著一個測試人員能力的高低。
除了極個別的不能重現的缺陷外，一個軟體缺陷至少應該描述清楚三方面的內容：缺陷概述、詳細內容、重現步驟。
缺陷概述-用一到兩句話描述缺陷的症狀，使管理人員一目瞭然大概是什麼問題。詳細內容-詳細地描述缺陷的症狀，可以發表自己對該缺陷的一些意見，主要供程式設計師進行分析。重現步驟-詳細描述如何在系統中重現缺陷，這是非常重要的一項內容，如果重現步驟清晰，將大大加快開發人員修改缺陷的速度。
通常情況下，很多缺陷管理軟體把”詳細內容”與”重現步驟”進行了合併，即只有一個文字輸入框供測試人員錄入資訊，這就導致很多測試人員疏忽了去描述”重現步驟”。此外，諸如測試版本、測試環境、發現日期等輔助資訊也應該認真錄入。

2 處理不能重現的缺陷
缺陷應該可重現，問題重現才可以讓開發者快速定位原因並解決問題。在測試的過程中偶爾會碰到一些不能重現的問題，對於這類的問題：
（1） 應該將缺陷產生的條件和出現的問題做一個記錄，建議開發者根據問題的描述進行原因定位。當然，即使開發者解決了問題，如果不能重現，也不能有效地驗證。
（2） 根據經驗，一般的問題的產生都可以找到重現的規律，只是看所花費的時間和成本。嚴重的缺陷一定要想辦法找到原因，而優先順序別低的問題因考慮成本可先將缺陷擱置，以後重現的時候再讓開發者解決。通常，不能很快找到規律的問題都是一些比較重要且奇怪的問題，開發者一般不能根據描述進行定位，此時測試工程師應該有很強的責任心和信心想辦法重現問題。
（3) 開發人員與測試人員應很好地配合，缺陷的重現效率才會更高，測試人員切忌一個人冥思苦想，而應該及時把問題和看法與開發人員交流，大家一起探討可以有效地促進問題的解決，要懂得利用團隊的力量。
（4) 注意缺陷出現時候的日誌，通常程式日誌都包含著很重要的資訊，從那些資訊中分析出現問題的條件，並嘗試重現。
（5 ）遇到問題時，應該儘量將出錯資訊作為關鍵字在網際網路搜尋，可以幫助你獲取靈感。
（6） 必要時，寫一些簡單的測試程式以幫助重現問題。

3 面對暫時無法解決的問題
在測試過程中，開發者可能會在缺陷回覆的時候告訴你暫時無法解決該問題，這個時候作為測試人員應該：
（1 ）確定問題是否真的無法解決，解決需要付出的成本有多大。
（2 ）確認問題的嚴重性，如果此類問題不解決，是否會導致嚴重的後果。
（3 ）對於會導致嚴重後果的問題，要堅持讓開發者解決並想辦法幫助開發者解決問題。測試人員應該主動協助開發人員找到問題的原因和解決方法，充分利用團隊的資源，請教這個領域比較有經驗的工程師一起討論問題的解決方法。
（4 ）對於對系統不會造成危害或雖然有微小的危害但修改成本過高而又可以人為避免的問題，則可以將問題留到下一版本解決或關閉這個缺陷，並在缺陷報告中說明原因和注意事項。
（5 ）測試人員的態度非常重要。在告訴開發者這個問題一定需要解決時態度要溫和而堅定，讓他意識到問題的嚴重性。

4 測試工程師和開發者的意見不一致
（1 ）客觀地比較自己的建議和開發者的意見哪個更好。
（2 ）如果開發者的方法的確具有優勢，那就應該接受開發者的意見；否則就堅持自己的建議並詳細給開發者解釋你的建議，使開發者認為你的建議值得采納。
（3 ）如果雙方還是對各自的意見相持不下，可以跟專案經理一起討論，由專案經理衡量應該採取哪種處理方法，應儘量說服專案經理。
5 開發者不配合工作時的對策
（1 ）先進行一個自我檢討：我的態度有問題嗎？我報的缺陷是否都描述清楚了？我所發現的問題是否有價值？如果這些問題的答案是否定的，那麼自己先改正了，開發者看到你的改變，也會調整自己的態度。
（2) 在一個團隊中有一、兩個不合作的開發者是正常的，不可能每個人都那麼配合、態度良好，堅持自己該做的就行了。
（3 ) 不要去逃避，雙方之間換一種有效的溝通方法。比如，在郵件上交流不清楚，就換成電話或面對面，總之，交流的方式是很多的，選擇雙方更能有效溝通的交流渠道會達到事半功倍的效果。
（4 ）儘量避免與對方直接衝撞，即使雙方之間發生了爭執，也不要太介意。
（5）如果開發者實在不配合，必要的時候，可以適當表達你的立場，或者委婉地向開發者的領導反映或者將你們之間的互動郵件抄送給開發者的領導。這是一個有效的方法，同時也容易引發新矛盾，但這樣做是為了有效解決問題。

6 處理不能迅速定位的工程故障
對於一些不能迅速定位的工程故障，開發者很自然寄望於測試環境能將問題重現，但正是因為問題複雜或者是在測試時沒有考慮過的問題，才會遺留到工程上而導致出現故障。
（1）檢視工程環境程式日誌，如果沒有查詢的許可權，請工程實施人員幫忙查詢，分析日誌查詢到問題的原因或相關線索。
a . 如果日誌的提示資訊足夠，可以根據日誌定位原因，則在測試環境中按照日誌提示構造條件相同的測試案例測試，嘗試在測試環境中將問題重現；
b . 如果不能從日誌中獲取足夠的資訊，而且測試環境中也無法把問題重現，那麼先跳出思維定勢，想想為什麼會出現這樣的故障，可能導致的原因有哪些，自己還有哪些測試點或異常沒有考慮到，測試環境和配置與實際的工程環境和配置有哪些差異等等。同時主動與開發負責人、工程實施人員以及有經驗的專案經理討論，分析可能導致的原因。
（2 ）在測試環境中使用實際工程環境的配置檔案和執行程式，並儘量模擬實際環境搭建測試環境。
（3 ）在模擬實際環境的測試環境中，根據分析的可能原因構造測試案例測試，嘗試在測試環境中將問題重現。
（4 ）問題重現後協助開發者解決問題。
（5 ）驗證解決後的程式是否仍然會出現類似故障。
（6 ）總結出現故障的原因並作記錄：如果是配置的問題需要提醒工程人員在實施時注意；如果是測試疏忽的測試點要在測試報告中記錄並在案例庫中增加相應的案例；如果某些異常是開發者沒有考慮全面，要總結類似的問題並提示所有開發者注意。