❶ 軟體測試中容易犯的測試錯誤
雖然說我們在工作中一再要求大家要認真細心，但是對於許多的新手來說，依然會在不知不覺中犯錯誤。下面雲南電腦培訓http://www.kmbdqn.com/就通過軟體測試崗位做為分析案例，了解一下，一個軟床測試新人都容易犯的測試錯誤都有哪些。
1.沒有測試
我們很容易毫無原因地掉入這個陷阱。從現在開始，制定計劃添加測試到你現在正在處理的代碼中，並添加測試到將來的項目中。
2.沒有從項目一開始就啟動測試
我們很難再回過頭去添加測試，並且可能需要改變架構才能添加測試，這樣做終將需要你花更長的時間才能產出可信任的代碼。從一開始就在項目的生命周期添加測試可以節省時間和精力。
3.編寫失敗的測試
TDD方法的普及將紅—綠—重構的理念帶到軟體測試世界。這個理念常常被誤認為應該「通過編寫一個失敗的測試開始」。其實並非如此。在寫代碼之前創建測試的目的是定義系統的正確行為應該是什麼。在許多情況下，它是一個失敗的測試(紅色表示)，但它可能會通過一個非決定性的或未實現的測試來表示。
4.擔心未實現測試
軟體開發中的一個大問題就是，代碼和任何關於系統實際上應該做什麼的文檔之間的溝壑。通過擁有一個名稱中明確定義你終想要實現的預期行為的測試，你將從測試中得到一定的價值，即使將怎麼寫測試目前還不得知。
5.沒有很好地命名測試
命名軟體這件事出了名的很難做好，這同樣適用於測試。關於如何命名測試有幾種流行的約定。無論你使用哪一種都沒有關系，只要你能夠一貫使用，並准確描述正在測試什麼。
6.讓測試做太多事情
又長又復雜的名字通常說明了你想同時測試多件事情。單個測試應該只測試一件事情。如果失敗了也應該在代碼中註明是什麼地方出了錯。你沒有必要為了知道代碼中出了什麼問題而查看是哪部分測試失敗。這並不意味著你不應該在測試中有多個斷言，但這些斷言應該緊密相關。例如，一個查看訂單處理系統輸出，並確認輸出中是否有一個單一項目以及它是否包含具體項目的測試，是ok的。但一個驗證相同系統的輸出的測試，既創建一個特定項目，又記錄到資料庫中，還發送確認電子郵件，就不行了。
7.沒有實際測試代碼
經常可以看到測試新手創建過於復雜的模型以及不能實際測試代碼的設置程序。他們可能會驗證模擬代碼是否正確，或者模擬代碼是否和真正代碼做相同的事情，或沒有任何斷言而只是執行代碼。這樣的「測試」都是白費力氣，特別是如果它們的存在只是為了提高代碼覆蓋率水平的話。
8.擔心代碼覆蓋率
代碼覆蓋率的理念很崇高，但往往實際價值有限。知道運行測試的時候有多少代碼被執行應該是有用的，但因為它不考慮正在執行代碼的測試的質量，因此就變得沒有意義。代碼覆蓋率在它數值非常高或非常低的時候，是挺博人眼球的。如果非常高，就表明，比起帶來的價值，過多的代碼可能正在被測試。非常低的代碼覆蓋率表明有可能代碼的測試不夠。因為這樣模稜兩可的意思，有的人就不知道單一片段的代碼是否應該進行測試。我用一個簡單的問題來明確這一點：代碼是否包含重大的復雜性?如果包含，那麼你需要一些測試。如果沒有的話，你就不需要。測試屬性訪問器不過是浪費時間。如果它們失敗的話，那麼比起你正在寫的代碼，你的代碼體系出現了一些更根本的問題。如果你不用看一段代碼，就立即知道一切，那麼它就不重大。這不僅適用於代碼，也適用於你寫代碼。如果我們在任意點重訪代碼，那麼它就需要測試。如果在現有代碼中發現過bug，那就說明這一塊的代碼對其復雜性沒有進行充分的測試。
9.著眼於一種類型的測試
一旦你開始測試，很容易只糾結於一種風格的測試。這是一個錯誤。只用一種類型的測試，你就不能充分測試系統的所有部分。你需要單元測試來確認代碼的各個組件是否能夠正確工作。你需要集成測試來確認不同組件是否能夠協同工作。你需要自動化UI測試來驗證軟體是否可以如預期使用。後，你需要為任何不容易自動化的部分和探索性嘗試進行手動測試。
❷ 軟體測試面試常見問題及答案有哪些
如下：
1、什麼是bug？
答：軟體的bug指的是軟體當中不符合用戶需求的問題。
常見的軟體bug分為以下三類：
沒有實現的功能。
完成了用戶需求的功能，但是運行時會出現一些功能或性能上的問題。
實現了用戶不需求的多餘功能。
2、簡單概述缺陷報告，並說明包括哪些項？
答：現在缺陷報告一般不再使用紙質檔文檔編寫，而是專用測試管理工具（如TestDirector），這樣便於缺陷管理。在這些工具中，每個缺陷作為一條記錄輸入指定的缺陷管理系統中。
缺陷報告包括：軟體名稱、版本號、功能模板、缺陷編號、對應的用例編號、編寫時間、編寫人、測試員、預期結果、實際結果、缺陷描述、嚴重級別、優先順序別
3、開發人員修復缺陷後，如何保證不影響其他功能？
答：重新執行用例、看是否出現錯誤結果。並對周圍的一些相關功能點追加新的測試用例。
4、什麼時候功能測試？
答：功能測試是在規定的一段時間內運行軟體系統的所有功能，以驗證這個軟體系統有無嚴重錯誤。
5、為什麼選擇測試這行？
答：它是一個新興的行業，有發展潛力，而且很鍛煉人，需要掌握更多的技能，比做開發要更全面。
❸ 軟體測試中非必現的bug怎麼找
寫寫我的經驗吧。其實很簡單：分析log
測試客戶端或web功能時，打開抓包工具，跟蹤自己的操作路徑。
當涉及到server功能時，就依賴於開發了，有經驗的開發會在自己的代碼中打很多的log，去log文件里按時間找自己的操作即可。通過分析log，可以：
1. 方便的回溯隨機bug，出現問題直接查錯誤日誌、定位原因、告知開發，就不需要再絞盡腦汁的重現bug了，提高測試質量。
2. 查log能夠准確的定位問題。特別是比較復雜的系統，一環套著一環，通過查log剝繭抽絲逐步定位問題所在。提高工作效率。
3. 查log的過程也是對系統實現細節的深入學習過程，通過了解到的技術實現，完善測試用例，避免漏測。
但在實際的測試中，可能會有很多意想不到的情況，比如開發忘記在出錯點打log了，你分析半天發現沒喲，浪費時間所以測試之前一定要提醒開發在關鍵點打好log：
1、異常處理。系統各層次都要顯式處理異常，任何可能出現的錯誤都能在日誌中找到原因和地點。
2、重要的邏輯處一定要有日誌。能夠通過日誌看出是哪個文件的哪個方法出了問題。
❹ web網站哪些模塊容易出BUG
非法登錄、SQL注入(這個現在少了)，多用戶同時登錄，多地點登錄，信息同步，文件、圖片以及音視頻的上傳下載、亂碼、瀏覽器版本支持、高訪問量、網路不通暢時的腳本不能載入等問題。
❺ 在測試/開發過程中遇到過哪些印象深刻的bug
目前在測試日歷,支持多(Android,iOS,web,PC)同步.遇見一個bug,有某些復雜操作下,可以創建一個開始時間比結束時間晚的日程,界面中無任何顯示,研發考慮不解決.提bug的測試也覺得可以不解決.
但我反對了.基於兩個方面,
第一,出現這個bug,可以判斷研發在最後保存數據時,並沒有對數據的有效性進行判斷.而是在相關控制項進行操作時進行判斷的.這樣風險有點大,因為控制項之間對數據也會有影響,如果僅在操作控制項時判斷,會產生問題.
第二,這種臟數據雖然不會在視圖展示,但保存在伺服器上,在各個上均會進行同步.這還需要保證其他對於臟數據進行處理,且不會出現問題.風險較大.
基於這兩個原因,研發還是解決了這個問題.這對我還是有一定啟發的.
看問題可能會更考慮多方面的影響.不單純只是現象.
❻ 如何定位Web系統前後台的BUG
分開跟你說
前台bug 主要有兩塊 第一就是JS寫的有問題，這個你可以按F12 打開控制台，一般瀏覽器都會顯示報錯的jS 你看你報錯的function然後去代碼里看，基本上都會找到錯誤原因的 變數未定義，參數未定義啦啥啥啥的，JS錯誤都很好解決的。 第二個就是你頁面中的bug了，現在做web項目基本上沒有做靜態頁面的都是動態了，所以你頁面中要麼使用了小腳本要麼使用了EL表達式來存值。頁面報錯的話 在控制台是可以看到你錯誤行號和附近代碼的，你自己去找就行了。
後台bug 改難改，但是找好找。主要就是看控制台報錯，然後定位錯誤行號。如果配置文件沒有問題，那麼一般的報錯就是空指針，或者是數組下標越界。看附近變數，看方法的參數基本上都可以定位錯誤了。。。純手打，望採納。如果還有什麼問題歡迎私聊
❼ Web前端工程師要掌握的JavaScript常見BUG及修復方法
今天小編要跟大家分享的文章是關於Web前端工程師要掌握的JavaScript常見BUG及修復方法。JavaScript看上去是一門十分簡單的語言，然而事實並不如此。它有很多容易被弄錯的細節，一不注意就導致BUG。所以今天小編就為大家分享了10個JavaScript常見的bug及修改方法，來和小編一起看一看吧！
一、錯誤的對this進行引用
在閉包或則回調中，this關鍵字的作用域很容易弄錯。舉個例子：
Game.prototype.restart=function(){
this.clearLocalStorage();
this.timer=setTimeout(function(){
this.clearBoard();//此處this指的是?
},0);
};
如果執行上面的代碼，我們會看到報錯：
UncaughtTypeError:undefinedisnotafunction
出錯的原因在於：當你調用setTimeout函數，你實際上調用的是window.setTimeout()。在setTimeout中傳入的匿名函數是在window這個對象環境下，所以this是指向window，但是window並沒有clearBoard方法。
如何解決呢?定義新的變數引用指向Game對象的this，然後就可以使用啦。
Game.prototype.restart=function(){
this.clearLocalStorage();
varself=this;//將this指向的對象綁定到self
this.timer=setTimeout(function(){
self.clearBoard();
},0);
};
或則使用bind()函數：
Game.prototype.restart=function(){
this.clearLocalStorage();
this.timer=setTimeout(this.reset.bind(this),0);//bindto'this'
};
Game.prototype.reset=function(){
this.clearBoard();//此處this的引用正確
};
二、和塊作用域(blockscope)有關的BUG
在大多數程序語言中，每一個函數塊都有一個獨立的新的作用域，但是在JavaScript中並不是。例如：
for(vari=0;i<10;i++){
/*...*/
}
console.log(i);//會輸出什麼呢?
通常在這種情況下，調用console.log()會輸出undefined或則報錯。不過呢，這里會輸出10。在JavaScript中，即使for循環已經結束，變數i依然存在，並且記錄最後的值。有些開發者會忘記這一點，然後導致許多bug。我們可以使用let而不是for來杜絕這一問題。
三、內存泄漏
你需要監控內存使用量，因為泄露很難避免。內存泄露可能由於引用不存在的對象或則循環引用導致。
·如何避免：關注對象的可訪問性(reachability)。
·可訪問的對象：
§現有的callstack任何位置可以訪問的對象
§全局對象
當一個對象可以通過引用訪問到，那麼會在內存中保存。瀏覽器的垃圾回收器僅僅會把那些不可訪問的對象回收。
四、混淆的相等判斷
JavaScript自動將所有在布爾環境下的變數類型轉換為布爾類型，但是可能導致bug。舉例：
//所有都是true
console.log(false==Ɔ');
console.log(null==undefined);
console.log("
"==0);
console.log(''==0);
//注意：下面兩個也是
if({})//
if([])//
{}和[]都是對象，他們都會被轉換為true。為了防止bug出現，推薦使用===和!==來做比較，因為不會隱式做類型轉換。
五、低效的DOM操作
在JavaScript中，你可以輕松操作DOM(添加、修改和刪除)，但是開發者往往很低效地去操作。這會導致bug出現，因為這些操作非常耗費計算資源。為了解決這個問題，推薦使用文檔碎片(Document
Fragment)，如果你需要操作多個DOM元素。
六、在for循環中錯誤的定義函數
舉例：
varelements=document.getElementsByTagName('input');
varn=elements.length;//假設我們有10個元素
for(vari=0;i
elements[i].onclick=function(){
console.log("元素編號#"+i);
};
}
如果我們有10個元素，那麼點擊任何一個元素都會顯示「元素編號#10」!因為在onclick被調用的時候，for循環已經結束，因此所有的i都是10。
解法：
varelements=document.getElementsByTagName('input');
varn=elements.length;//假設有10個元素
varmakeHandler=function(num){//outerfunction
returnfunction(){//innerfunction
console.log("元素編號##"+num);
};
};
for(vari=0;i
elements[i].onclick=makeHandler(i+1);
}
makeHandler在for循環執行的時候立即被調用，獲取到當前的值i+1，並且存儲在變數num中。makeHandler返回一個函數使用num變數，該函數被綁定到元素的點擊事件。
七、通過原型錯誤地繼承
開發者如果沒能正確理解繼承的原理，那麼就可能寫出有bug的代碼：
BaseObject=function(name){
if(typeofname!=="undefined"){
this.name=name;
}else{
this.name='default'
}
};
varfirstObj=newBaseObject();
varsecondObj=newBaseObject('unique');
console.log(firstObj.name);//->輸出'default'
console.log(secondObj.name);//->輸出'unique'
但是，如果我們做如下操作：
deletesecondObj.name;
那麼：
console.log(secondObj.name);//->輸出'undefined'
而我們實際上想要的結果是列印默認的name。
BaseObject=function(name){
if(typeofname!=="undefined"){
this.name=name;
}
};
BaseObject.prototype.name='default'
每一個BaseObject都繼承name屬性，並且默認值為default。此時如果secondObj的name屬性被刪除掉，通過原型鏈查找會返回正確的默認值。
varthirdObj=newBaseObject('unique');
console.log(thirdObj.name);//->輸出'unique'
deletethirdObj.name;
console.log(thirdObj.name);//->輸出'default'
八、實例方法中的無效引用
我們來實現一個簡單的構造函數用來創建對象：
varMyObject=function(){}
MyObject.prototype.whoAmI=function(){
console.log(this===window?"window":"MyObj");
};
varobj=newMyObject();
為了使用方便，我們定義變數whoAmI來引用obj.whoAmI：
varwhoAmI=obj.whoAmI;
列印出來看看：
console.log(whoAmI);
控制台會輸出：
function(){
console.log(this===window?"window":"MyObj");
}
現在我們來對比一下兩者調用的區別：
obj.whoAmI();//輸出"MyObj"(和期望一致)
whoAmI();//輸出"window"(竟然輸出了window)
當我們把obj.whoAmI賦值給whoAmI的時候，這個新的變數whoAmI是定義在全局下，因此this指向全局的window，而不是MyObj。如果我們真的要獲取對MyObj的函數的引用，需要在其作用域下。
varMyObject=function(){}
MyObject.prototype.whoAmI=function(){
console.log(this===window?"window":"MyObj");
};
varobj=newMyObject();
obj.w=obj.whoAmI;//任然在obj的作用域
obj.whoAmI();//輸出"MyObj"
obj.w();//輸出"MyObj"
九、settimeout/setlnterval函數第一個參數誤用字元串
如果你將一個字元串作為setTimeout/setTimeInterval，它會被傳給函數構造函數並構建一個新的函數。該操作流程很慢而且低效，並導致bug出現。
varhello=function(){
console.log("hello,fundebug!");
}
setTimeout("hello",1000);
一個好的替代方法就是傳入函數作為參數：
setInterval(logTime,1000);//將logTime函數傳入
setTimeout(function(){//傳入一個匿名函數
logMessage(msgValue);
},1000);
十、未能成功使用strictmode
使用strictmodel會增加很多限制條件來加強安全和防止某些錯誤的出現，如果不使用strict
mode，你就相當於少了一個得力的助手幫你避免錯誤：
·更加容易debug
·避免不小心定義了不該定義的全局變數
·避免this隱式轉換
·避免屬性名字或則參數值的重復使用
·eval()更加安全
·無效地使用delete會自動拋出錯誤
以上就是小編今天為大家分享的關於Web前端工程師要掌握的JavaScript常見BUG及修復方法的文章，希望本篇文章能夠對正在從事web前端工作的小夥伴們有所幫助，想要了解更多web前端相關知識記得關注北大青鳥Linux培訓官網，最後祝願小夥伴們工作順利！
作者：fundebug
原文：#/2017/11/15/top_10_bugs_and_fixing_method/
❽ 測試時遇到的印象深刻的bug是什麼
目前在測試日歷軟體,支持多平台(Android,iOS,web,PC)同步.遇見一個bug,有某些復雜操作下,可以創建一個開始時間比結束時間晚的日程,界面中無任何顯示,研發考慮不解決.提bug的測試也覺得可以不解決.
但我反對了.基於兩個方面,
第一,出現這個bug,可以判斷研發在最後保存數據時,並沒有對數據的有效性進行判斷.而是在相關控制項進行操作時進行判斷的.這樣風險有點大,因為控制項之間對數據也會有影響,如果僅在操作控制項時判斷,會產生問題.
第二,這種臟數據雖然不會在視圖展示,但保存在伺服器上,在各個平台上均會進行同步.這還需要保證其他平台對於臟數據進行處理,且不會出現問題.風險較大.
基於這兩個原因,研發還是解決了這個問題.這對我還是有一定啟發的.
看問題可能會更考慮多方面的影響.不單純只是現象.