1、測試過程常用思維技巧分享測試過程常用思維技巧分享測試過程常用思維技巧分享提綱提綱收到收到版本版本后主要要做哪些后主要要做哪些2多人版本測試，相互多人版本測試，相互配合配合的的原則原則3布署版本時，最容易布署版本時，最容易出現出現的問題的問題4高效準備測試數據高效準備測試數據5迭加需求版本，測試策略迭加需求版本，測試策略6有效利用等版本時間有效利用等版本時間1等待版本中可做的事情等待版本中可做的事情一般，版本與版本之間時間回歸時間較長，會安排其它的工作開展；在版本臨時推遲時（比如晚一個小時、兩個小時）這樣的情況下，可以提前進行如下一些碎片化的工作；1、BUG單的查閱統計已經FIXED的BUG個數

2、；查看reject或CancelBUG單，避免錯誤處理遺留到下一輪2、補充必要的用例可僅針對邏輯性較強的功能；減少用例統計/用例總體補充時的工作量。3、提前進行回歸測試所需要的數據制作。4、備份上一輪版本；收到收到版本版本后主要要做哪些后主要要做哪些事情檢查打包文件檢查打包文件檢查打包的文件是否齊全（文檔、執行文件、源碼-源碼正確性）檢查版本號是否正確檢查升級說明、修改說明是否正確（是否與本次需求一致）。測試環境確認（常用于新項目或版本運行環境變更）部署版本進行測試。兩個方面兩個方面版本測試版本測試冒煙測試1.新增功能瀏覽（確認是否有功能遺漏）；2.主流程簡單測試（確認本次提交的功能及相關功能

3、是否能正常使用）正常版本測試回歸版本，確認本輪需回歸的BUG總數、是否存在有爭議被異常處理掉的BUG單（接口人）多人版本測試，相互配合的原則多人版本測試，相互配合的原則功能之間的聯系緊密程度（聯系緊密的功能通常安排同1個人測試）測試數據互相不受影響功能交織在一起的復雜測試，可按邏輯前后順序來安排測試工作，但要明確測試開始點及結束點（數據值、頁面流程等）明確自身的測試范圍（需求、功能、測試開始點及結束點）有功能、數據影響時，應及時通知相關測試人員發現日志、控制臺異常，應及時通知相關測試人員因功能缺陷可能影響到其他人測試的模塊功能時，應及時通知相關測試人員，并說明可能影響到的原因有功能、數據交互影

4、響的測試時，應與對方配合進行測試。2文檔問題部署人員應詳細查看文檔（升級、配置、版本號），在動手實際部署前應思考這么部署是否正確再進行部署，且應嚴格按照升級說明和配置說明進行部署。另外應注意升級文檔的措詞，比如替換和覆蓋。有歧義，不清楚的地方應及時詢問開發再進行部署。4部署環境部署版本不要用ROOT文件夾；部署版本后應清理tomcat的work文件夾及臨時文件夾。布署版本時，最容易出現的問題布署版本時，最容易出現的問題1版本備份無論是補丁版本還是完整版本部署前都應做原版本備份，補丁版本升級比較容易忽視這個問題。3迭加功能對于在測試過程中有迭加功能的補丁版本，部署時應在原版本（主版本）的基礎上進

5、行升級，不要在前一個輪測試版本上升級。5項目部署對于新項目，版本提交前就應準備好部署環境（web容器、數據庫等）布署完成之后，不能一看啟動無問題就認為布署OK了，或出現一些錯誤日志忽略掉；正確的做法：是要觀察好日志是否有異常，且首次訪問數據庫是否正常、模塊之間互聯是否正確后，再開始正式的測試。對比對比找文檔找文檔重新設計重新設計結果無對比結果無對比已有文檔已有文檔稍作修改稍作修改可對比結果可對比結果測試數據的記錄測試數據的記錄養成記錄測試數據的習慣，尤其是一些常用的、重用性比較高的測試數據，比如接口類測試報文、安全性測試規范數據、數據生成腳本、常用測試數據（用戶名、手機號碼）等。高效準備測試數

6、據高效準備測試數據舊新對比對比匆忙匆忙設計設計容易遺漏容易遺漏效率低效率低時間充足時間充足逐步完善逐步完善效率高效率高測試數據的記錄測試數據的記錄在提交版本前，針對本次版本功能提前準備測試數據，比如電商高級會員自動續訂功能如有修改（表結構并未修改），那么可在提交版本前準備測試數據，但要注意備份原表。對比對比匆忙匆忙設計設計容易漏測容易漏測效率低效率低時間充足時間充足覆蓋完善覆蓋完善效率高效率高用例設計階段用例設計階段版本提交前，在用例設計階段就詳細的寫出用到的測試數據，比如一個復雜的流程測試需要填寫那些數據、復雜的統計需要那些腳本等涉及到流程性測試時，盡可能同時至少走2條數據來進行測試；以更好

7、的復現和確定問題。迭加需求版本，測試策略迭加需求版本，測試策略對迭加的新需求要有充分的了解，包括其設計方法，因為只有你了解了這些，才可能想到其對舊功能的影響范圍。了解新功能測試過程測試部署建議先測試新功能，再回歸bug；對于耦合性很高的新功能，還要全面測試功能相關的舊功能。對于開發來說，新功能更容易出bug，及早發現新bug，開發也會有更多的時間去改正。剛前面已經說到過，要用依賴的主版本（最初的版本）來部署。bug內容編寫內容編寫新新BUGBUG編寫時，測試人員需保證此編寫時，測試人員需保證此BUGBUG單的唯一性、獨立性以及完整性。以達單的唯一性、獨立性以及完整性。以達到到BUGBUG單的效

8、率最大化，減少無效單的效率最大化，減少無效BUGBUG單的出現，以及減少開發人員對單的出現，以及減少開發人員對BUGBUG單的誤單的誤解。解。bug內容填寫規范1. SummarySummary中，填寫BUG的概要信息，包括：1) 所屬大模塊所屬大模塊，如：前臺/交易管理：2) 問題簡要說明問題簡要說明，如：交易密碼修改出現異常。Summary完整內容則為：前臺/交易管理：交易密碼修改出現異常。2. Description中，需詳細說明本BUG所屬的操作步驟及重現條件，如涉及數據表值更新及日志、圖片，都需要附上。新新BUGBUG編寫時，測試人員需保證此編寫時，測試人員需保證此BUGBUG單的唯

9、一性、獨立性以及完整性。以達單的唯一性、獨立性以及完整性。以達到到BUGBUG單的效率最大化，減少無效單的效率最大化，減少無效BUGBUG單的出現，以及減少開發人員對單的出現，以及減少開發人員對BUGBUG單的誤單的誤解。解。1) 例一（附圖或日志型）：前臺/交易管理：進入交易密碼修改頁面，系統出現腳本錯誤，錯誤圖見附件所示。2) 例二（數據庫型）：后臺/撤牌審核：撤牌審核通過或不通過后，未及時更新T_PROJECT_RELEASE_BASE表中的撤牌狀態，造成前臺/我發布的項目中，項目操作欄一直顯示為“撤牌審核中”。3) 例三（步驟型）：前臺/掛牌申請：選擇股權進行掛牌申請，按照界面操作引導

10、下一步至添加版權項目其他信息頁面后，再點擊上一步，系統轉到文化產品添加頁面了（正常是不應該轉到此頁面的）4）) 例四（解釋補充型）：后臺/商品管理：修改商品保存后，競價模式修改為其它了；造成商品同步到競價平臺異常；（前臺進行商品修改不存在本問題）bug內容編寫內容編寫有爭議問題單共享有爭議問題單共享語意不清孤芳自賞漫天過海原bug：mcp/我的莞惠，我的等級，頁面顯示位置不對，如圖開發：死活找不到關鍵詞：瀏覽器更改為：mcp/我的莞惠，我的等級，頁面顯示位置不對，如圖（ie7） 12新手問答新手問答1態度2過程3期望1.測試人員是否需要用爭吵來堅持自己的意見凡事只要開始吵，結果基本上就會輸了；但在測試過程中，觀點不一的爭議必然存在；要想堅持自己的意見，改變別人的想法，更好的形式是擺觀點，找論據，拉站隊；同時一定要留下自己的BUG證據。這樣的方式更OK點2.一個功能（版本）測試到啥程度算結束 按理說功能和版本應該測試到你認為用例已全面覆蓋，基本已測試不出bug來為止，但實際上由于時間關系，部分版本達不到這種程度，這就需要你對版本功能做權衡，找出測試的優先級，通常大的流程、頁面操作等方面功能是必須保證能正常使用的，異常則可做選擇性測試。3.減少漏測和提高效率的問題 對于這個