首先測試用例設計階段，設計並維護乙個各個功能入口的說明文件。其實這個文件的作用很大，一方面對於bug回歸階段的人來說，這是用於提醒的;另外乙個方面，在隨機測試的時候，隨機程度也能有所提高，測試人員能夠自己隨意組合可能的路徑。當然，一樣乙份文件也能提公升文件設計人員，文件閱讀人員對於模組的整體認識
在bug提交階段，評估阻塞用例說明。在專案初期，尤其是版本剛提交的時候，往往會出現功能無法使用或者沒有實現的問題，這時候我們提交bug並不僅僅是說明預期沒有實現，更重要的是我們如何備忘這件事情，如何保證沒有實現的功能在最終版中實現，那麼在提交bug的時候，我們需要註明，哪些case被阻塞，該功能沒有驗證會影響到哪些其他模組和功能的驗證等
bug提交階段，在bug描述中備註回歸時的路徑說明。測試工程師提交bug時是在當時的環境下的，也就是說對測試目錄，前後操作及路徑都非常清楚，對於其他可能的入口或者操作，測試工程師是知道的，因而在提交bug的時候，測試工程師除了提交出現bug的操作步驟之外，如果能補充一下其他可能的路徑說明，一方面開發在修復bug的時候可以作為參考，另外一方面測試工程師在bug回歸的時候也能夠進行更全面高效的回歸
接著，在bug提交完畢，對非用例內影響因素或路徑更新到測試用例或者進行備忘。測試影響因素包括各個方面，因為測試工程師的經驗，知識儲備等各方面原因，測試設計往往會有一定的遺漏，這是不可避免的，在測試過程中我們往往會突然想到某個影響因素或者測試路徑，這時候我們往往會去執行一下是否有問題，如果有問題，則會有bug提交，如果沒有bug呢?往往我們會去繼續去執行下一條case去了。實際上這種情況是對測試工程師腦力的一種浪費，不利於測試工程師經驗的積累。
最後在自動化測試回歸時，盡可能與開發溝通bug原因及修改方案。這個在實際操作時是有困難的，因為哪些bug需要與開發溝通，開發是否有時間等都是影響因素，當然有人會提出由開發在處理bug時提交修改說明，這當然是最好的方式，但是與國內實際環境是不符的，因而我們是盡可能的與開發了解bug原因及修改方案，然後在bug跟蹤系統中或者其他什麼方式進行乙個簡明的說明，例如是初始化資料錯誤這樣的原因，那麼在後期我們進行bug分析時，就能從乙個統計意義上的資料來對測試的測試設計及執行進行乙個指導
安裝pcre無法成功執行make的解決方法
問題描述 在ubuntu上安裝nginx，第一步安裝pcre的時候獲取安裝包 解壓縮 執行.configure 然後執行make的時候報錯 make no targets specified and no makefile found.stop 仔細看執行.configure的最後有報錯 you n...
div中的img標籤多餘空白bug解決方案
上圖之前之後 原圖是這樣的 發現區別了吧，這裡用到了css3的object fit屬性為cover 保持原有尺寸比例。保證替換內容尺寸一定大於容器尺寸，寬度和高度至少有乙個和容器一致。因此，此引數可能會讓替換內容 如 部分區域不可見。之前不知道這個屬性的時候還傻傻寫js判斷 img.onload f...
Js toFixed 四捨五入BUG的解決方法
問題描述 在js中四捨五入的函式 tofixed n n為要保留的小數字數。n為0 20，當n超過20的時候，js會出錯。var d 139.605 var f d.tofixed 2 alert f 期望值 139.61 結果為 139.60 bug 如果小數點前和要擷取的前一位都是0時，不會按常...