一.發現的缺陷越多，說明軟件缺陷越多嗎？
這是一個比較常見的現象。測試工程師在沒有找到缺陷前會絞盡腦汁的思考，但是找到一個後，會接 二連三的發現很多缺陷，頗有個人成就感。其中的原因主要如下：
-代碼複用、拷貝代碼導致程序員容易犯相同的錯誤。類的繼承導致所有的子類會包含基類的錯誤，反覆 拷貝同一代碼意味可能也複製了缺陷。
-程序員比較勞累是可以導致某些連續編寫的功能缺陷較多。
程序員加班是一種司空見慣的現象，因此體 力不只時容易編寫一些缺陷較多的程序。而這些連續潛伏缺陷恰恰時測試工程師大顯身手的地方。 “缺陷一個連着一個”不是一個客觀規律，只是一個常見的現象。如果軟件編寫的比較好，這種現象 就不常見了。測試人員只要嚴肅認真的測試程序就可以了。
從技術上講，所有的軟件缺陷都是能夠修復的，但是沒有必要修復所有的軟件缺陷。測試人員要做的 是能夠正確判斷什麼時候不能追求軟件的完美。對於整個項目團隊，要做的是對每一個軟件缺陷進行取 舍，根據風險決定那些缺陷要修復。發生這種現象的主要原因如下：
-沒有足夠的時間資源。在任何一個項目中，通常情況下開發人員和測試人員都是不夠用的，而且在 項目中沒有預算足夠的迴歸測試時間，再加上修改缺陷可能引入新的缺陷，因此在交付期限的強大壓力 下，必須放棄某些缺陷的修改。
-有些缺陷只是特殊情況下出現，這種缺陷處於商業利益考慮，可以在以後升級中進行修復。 -不是缺陷的缺陷。我們經常會碰到某些功能方面的問題被當成缺陷來處理，這類問題可以以後有時 間時考慮再處理。 最後要說的是，缺陷是否修改要由軟件測試人員、項目經理、程序員共同討論來決定是否修復，不同 角色的人員從不同的角度來思考，以做出正確的決定。
三.如何編寫提交給用戶的測試報告？
隨着測試工作越來越受重視，開發團隊向客戶提供測試文檔是不可避免的事情。很多人會問：“我們 可以把工作中的測試報告提供給客戶嗎？”答案是否定的。因爲提供內部測試報告，可能會讓客戶失去信 心，甚至否定項目。
測試報告一般分爲內部測試報告和外部測試報告。內部報告是我們在測試工作中的項目文檔，反映了 測試工作的實施情況，這裏不過多討論，讀者可以參考相關教材。這裏主要討論一下外部測試報告的寫 法，一般外部測試報告要滿足下面幾個要求：
-根據內部測試報告進行編寫，一般可以摘錄；
-不可以向客戶報告嚴重缺陷，即使是已經修改的缺陷，開發中的缺陷也沒有必要讓客戶知道；
-報告上可以列出一些缺陷，但必須是中級的缺陷，而且這些缺陷必須是修復的；
-報告上面的內容儘量要真實可靠；
-整個測試報告要仔細審閱，力爭不給項目帶來負面作用，尤其是性能測試報告。
總之，外部測試報告要小心謹慎的編寫。
四.軟件測試的原則：
1.儘快報告軟件缺陷
軟件缺陷發現的越早，在進度中留下的修復時間就越多。優先對APP的功能測試，發現的越早，修復的就越早，不會阻塞後面的測試。
2.有效軟件缺陷的描述
短小：只解釋事實和演示、描述軟件缺陷必須的細節
單一：每一個報告只針對一個軟件缺陷
明顯並通用：
用使用者容易看懂的，簡單易行步驟描述的軟件缺陷的一個特例，得到修復的機會較大。
可再現：
要想得到重視，軟件缺陷報告必須展示其可再現性--按照預定步驟可以使軟件達到缺陷再次出現的相同狀態。
3.在報告軟件缺陷時不要做評價
測試員和程序員容易形成對立關係。軟件缺陷報告應該針對產品，而不是具體的人，
只陳述事實。避免幸災樂禍，譁衆取寵，個人傾向，自負，責怪。得體和委婉是關鍵。需要善於溝通與合作。
4.對軟件缺陷報告跟蹤到底
比沒有找到重要軟件缺陷更糟糕得是，發現了一個重要的軟件缺陷，作了報告，然後把
他忘掉了或者跟丟了。對項目負責，有責任心是每個測試工程師必須有的。
5.對軟件缺陷標記嚴重優先等級
對嚴重性和優先級高的問題優先解決
6.軟件缺陷包含以下幾個規則：
軟件未達到產品說明書標明的功能；
軟件出現了產品說明書指明不會出現的錯誤；
軟件功能超出產品說明書指明的範圍；
軟件未達到產品說明書雖未指明但應達到的目標；
軟件測試員認爲軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認爲不好。
導致軟件缺陷的最大原因是產品說明書，其次是設計方案。軟件測試員的目標是找出軟件缺陷，儘可能早一些，並確保其得以修復。