優(yōu)就業(yè)是達(dá)內(nèi)教育IT培訓(xùn)品牌，致力于培養(yǎng)面向互聯(lián)網(wǎng)領(lǐng)域的人才，以學(xué)員就業(yè)為目的，就業(yè)為宗旨，是一家集互聯(lián)網(wǎng)營(yíng)銷師、UI/UE交互設(shè)計(jì)師、Web前端工程師、Java工程師、Python工程師、Unity開發(fā)工程師、大數(shù)據(jù)工程師、Linux云計(jì)算工程師、PHP工程師等課程為一體的IT培訓(xùn)機(jī)構(gòu)。為培養(yǎng)符合時(shí)代需求的IT人才，達(dá)內(nèi)教育優(yōu)就業(yè)以高瞻的視野，經(jīng)多年布局，打造人才培訓(xùn)服務(wù)體系。以企業(yè)需求為導(dǎo)向，以行業(yè)未來為驅(qū)動(dòng)，向企業(yè)和社會(huì)不斷輸送IT人才。
軟件測(cè)試是什么？
軟件測(cè)試是描述一種用來促進(jìn)鑒定軟件的正確性、完整性、安全性和質(zhì)量的過程。換句話說，軟件測(cè)試是一種實(shí)際輸出與預(yù)期輸出之間的審核或者比較過程。軟件測(cè)試的經(jīng)典定義是：在規(guī)定的條件下對(duì)程序進(jìn)行操作，以發(fā)現(xiàn)程序錯(cuò)誤，衡量軟件質(zhì)量，并對(duì)其是否能滿足設(shè)計(jì)要求進(jìn)行評(píng)估的過程。
軟件測(cè)試能做什么？
當(dāng)軟件在開發(fā)或者已開發(fā)完成的階段，軟件測(cè)試人員作為軟件的質(zhì)量管理員，需要站在用戶的角度上，使用不同的工具和方法較大限度的查找，軟件在功能以及性能上暴漏出來的問題，反饋給軟件開發(fā)人員，增加軟件的質(zhì)量，這就是軟件測(cè)試的工作內(nèi)容。
軟件測(cè)試行業(yè)發(fā)展趨勢(shì)如何？
軟件測(cè)試在未來的5~10年內(nèi)發(fā)展會(huì)很快，人才缺口很大，入門比較容易，就業(yè)機(jī)會(huì)多，因?yàn)檐浖髽I(yè)要靠軟件產(chǎn)品的質(zhì)量去占領(lǐng)市場(chǎng)，測(cè)試人員可謂是一個(gè)軟件企業(yè)生存的關(guān)鍵因素。
為什么要選擇達(dá)內(nèi)教育就業(yè)學(xué)習(xí)軟件測(cè)試技術(shù)？
達(dá)內(nèi)教育就業(yè)軟件測(cè)試培訓(xùn)機(jī)構(gòu)采用階段式授課方式，學(xué)完一部分內(nèi)容進(jìn)行考核，將掌握不牢固的技術(shù)點(diǎn)在下個(gè)階段再進(jìn)行講解。并且定期更新課程大綱所學(xué)技術(shù)，讓學(xué)員可以學(xué)到企業(yè)所需軟件測(cè)試技術(shù)。
第 一階段：軟件測(cè)試核心理論
第二階段：全棧測(cè)試軟件測(cè)試
第三階段：全棧測(cè)試數(shù)據(jù)管理
第四階段：編程語言Python
第五階段：Web自動(dòng)化測(cè)試
第六階段：移動(dòng)端自動(dòng)化測(cè)試
第七階段：接口自動(dòng)化測(cè)試
第八階段：性能測(cè)試
作為一名軟件測(cè)試工程師，就跟一名醫(yī)生一樣，我想我失業(yè)，如果軟件測(cè)試工程師失業(yè)了，那么就證明軟件開發(fā)的正確率、與用戶需求的匹配程度已經(jīng)很高了，這對(duì)社會(huì)資源是極大的節(jié)約不是嗎?如果醫(yī)生失業(yè)了，那么人們就不會(huì)再生命了，就再也沒有痛苦了不是嗎?但是，這又怎么可能?!我們能做的就是減少、降低，再減少再降低，所以就有了軟件測(cè)試工程師想要知道的問題：如何更快地修復(fù)Bug?
你有沒有想過為什么有時(shí)修復(fù)錯(cuò)誤似乎比它應(yīng)該花費(fèi)更長(zhǎng)的時(shí)間?當(dāng)你終于找到問題時(shí)，事實(shí)證明你所需要的只是一個(gè)小小的改變。然而，花了很多時(shí)間才能找到正在發(fā)生的事情。這種情況比我想象的更頻繁。
另一方面，當(dāng)您編寫代碼并進(jìn)行測(cè)試并且無法正常工作時(shí)，修復(fù)錯(cuò)誤非?？?。你跳回編輯器，掀起一行代碼，問題就解決了。
為什么即使問題很簡(jiǎn)單，有時(shí)修復(fù)錯(cuò)誤也需要很多工作，有時(shí)候，修復(fù)問題的速度很快 -
甚至可能很難解決問題?我們可以從易于修復(fù)的錯(cuò)誤中學(xué)到一些東西，這樣我們可以花更少的時(shí)間來修復(fù)bug嗎?
讓我們來談?wù)勥@個(gè)問題，看看我們可以用什么方法來解決這個(gè)問題，并且因?yàn)楹茈y找到錯(cuò)誤而停止拔頭發(fā)。
典型的錯(cuò)誤修復(fù)過程
為了確定在修復(fù)錯(cuò)誤時(shí)花了這么長(zhǎng)時(shí)間，我們先來看看修復(fù)錯(cuò)誤所涉及的步驟。
首先，我們需要了解這個(gè)問題。這意味著我們需要知道出了什么問題，在哪里，以及應(yīng)該發(fā)生什么。
接下來，我們需要重現(xiàn)這個(gè)bug。一個(gè)典型的案例可能是我們需要進(jìn)入我們正在處理的應(yīng)用程序并點(diǎn)擊一些事情來看看會(huì)發(fā)生什么。
然后，我們需要弄清楚代碼的哪個(gè)部分導(dǎo)致了問題。我們通?？梢酝ㄟ^使用調(diào)試工具來啟動(dòng)它 -
例如使用Chrome的調(diào)試器在我們重現(xiàn)問題的頁(yè)面上逐步執(zhí)行代碼。
一旦我們找到導(dǎo)致問題的代碼片段，我們就需要確定根本原因。根據(jù)問題的復(fù)雜性，這種困難可能會(huì)有很大的不同。
在確定了根本原因后，我們終于可以修復(fù)該錯(cuò)誤了。
較后，我們需要確保錯(cuò)誤實(shí)際修復(fù)。這通常是通過嘗試再次重現(xiàn)它來完成的。
嗯，我想我們已經(jīng)開始在這里看到一個(gè)問題了。修復(fù)bug本身只有六分之一!
但在我們得出結(jié)論之前，讓我們更詳細(xì)地看一下這些步驟。然后，我們可以看到每個(gè)步驟中的內(nèi)容需要花費(fèi)時(shí)間，并找到使它們更快的方法。
第1步：了解問題
錯(cuò)誤修復(fù)過程的步是理解問題。我們需要收集足夠的信息，以便我們知道發(fā)生了什么，以及應(yīng)該發(fā)生什么。
這個(gè)步驟花費(fèi)很長(zhǎng)時(shí)間的較大貢獻(xiàn)者是可怕的，糟糕的錯(cuò)誤報(bào)告。
用戶從不提供好的錯(cuò)誤報(bào)告。這是生活中無可否認(rèn)的事實(shí)。
我可能會(huì)夸大一點(diǎn)，但我確信你已經(jīng)比你想要的更頻繁地聽到“它不起作用”的字樣。
“X不起作用，它需要在昨天修復(fù)!”
然后你繼續(xù)問一些問題，希望你能從記者那里收集一些比“它不起作用”更有用的信息。
當(dāng)然，有時(shí)當(dāng)行星和恒星正確對(duì)齊時(shí)，你會(huì)得到一個(gè)好的錯(cuò)誤報(bào)告。您可以清楚地了解出現(xiàn)了什么問題，重現(xiàn)它的步驟，甚至可以獲得有關(guān)用戶使用的瀏覽器和操作系統(tǒng)的信息!那時(shí)候你可以直接進(jìn)入第2步并開始修復(fù)bug。
但在較糟糕的情況下，你只會(huì)對(duì)發(fā)生的事情有一個(gè)模糊的概念，這意味著在第2步中需要付出更多的努力。
第2步：重現(xiàn)錯(cuò)誤
如果您在步驟1中獲得了良好的錯(cuò)誤報(bào)告，則此部分可以很容易。您可以按照錯(cuò)誤報(bào)告中的步驟操作，然后立即重現(xiàn)錯(cuò)誤。太棒了!現(xiàn)在，您可以繼續(xù)查找損壞的代碼。
可悲的是，這一步往往不是那么順利。
由于模糊的錯(cuò)誤報(bào)告，這一步往往涉及很多猜測(cè)。
也許用戶使用的是Firefox，或者他們使用的是Chrome。在點(diǎn)擊此按鈕之前，他們不確定他們做了什么。我想知道我是否應(yīng)該隨意按下按鈕并希望較好?
有時(shí)，在嘗試重現(xiàn)問題后，您必須反復(fù)執(zhí)行步驟1和步驟2，而不會(huì)產(chǎn)生任何結(jié)果。希望您可以從用戶那里獲得更多信息，然后再試一次。
在這一點(diǎn)上很清楚，為了加快步驟1和2，我們需要收集盡可能多的信息。我們掌握的信息越多，理解和重現(xiàn)問題就越容易。
第3步：找到有問題的代碼片段
一旦我們?cè)佻F(xiàn)了這個(gè)bug，我們就需要找到導(dǎo)致問題的代碼的特定部分。
此步驟的難度各不相同，主要取決于兩個(gè)因素：
您擁有的代碼量
您熟悉代碼庫(kù)
(在較小程度上，您對(duì)調(diào)試工具的了解)
代碼量會(huì)影響這一點(diǎn)，因?yàn)槊啃写a都會(huì)增加可能的錯(cuò)誤數(shù)量。值得慶幸的是，熟悉代碼庫(kù)可以顯著縮小范圍。
找到問題通常從采取有根據(jù)的猜測(cè)開始。
“好吧，這就是問題，這就是我可以重現(xiàn)它的方式，所以我認(rèn)為問題出現(xiàn)在代碼的Y部分”
您對(duì)代碼庫(kù)的熟悉程度越高，您的猜測(cè)就越好。這使您可以縮小需要查看的代碼量，可能需要大量調(diào)整。
“好吧，我較近在處理函數(shù)Z，它有與此相關(guān)的代碼。我較好先檢查一下?！?/p>
根據(jù)問題的類型，您還可以使用調(diào)試工具來幫助您更輕松地找到有問題的代碼。
“是的，當(dāng)我點(diǎn)擊它時(shí)會(huì)出現(xiàn)錯(cuò)誤。我將在事件處理程序中設(shè)置一個(gè)斷點(diǎn)并從那里開始?！?/p>
**在此過程的這一步，較大的時(shí)間匯是找到問題發(fā)生的確切位置。**它可能是行為不當(dāng)?shù)墓δ?，用戶的不良價(jià)值或任何數(shù)量的東西，您需要在繼續(xù)之前找到問題的根源。
第4步：確定根本原因
這可能是這個(gè)過程中較重要的一步，但它經(jīng)常被完全跳過!
由于感知時(shí)間限制，或者僅僅因?yàn)榻?jīng)驗(yàn)不足的開發(fā)人員可能不知道他們應(yīng)該這樣做，它可能會(huì)被跳過。無論哪種方式，跳過此步驟通常意味著您的代碼慢慢開始填充hacks和kludges。
注意，我說感覺時(shí)間限制。通常你可能會(huì)感到有壓力要修復(fù)。
“只需修復(fù)，客戶就在等待。你以后可以做好工作?！?/p>
因此，您可以使用一些代碼來修復(fù)損壞的代碼并跳過根本原因。當(dāng)然，你很可能永遠(yuǎn)無法妥善修復(fù)它，因?yàn)榭傆幸恍〇|西需要完成。
但修復(fù)修復(fù)的結(jié)果與使用膠帶修復(fù)漏水管道相同。即使在芬蘭，我們稱膠帶為“耶穌膠帶”，因?yàn)樗哂行迯?fù)任何東西的神奇能力，在某些時(shí)候膠帶修復(fù)開始泄漏，你需要再使用一些膠帶。不久之后，你手上就會(huì)有一個(gè)巨大的混亂，你必須把它全部撕下來。
較后，您需要花費(fèi)更多時(shí)間來修復(fù)修復(fù)，而不是花費(fèi)更多時(shí)間來完成正確的工作。
但我離題了。
確定根本原因意味著您需要找到錯(cuò)誤的真正來源。讓我給你舉個(gè)例子。
假設(shè)您網(wǎng)站上的某些價(jià)值顯示不正確。您可以通過更改顯示代碼來解決此問題，但更多時(shí)候，顯示癥狀的代碼不是根本原因。
如果您更深入地研究問題，您可能會(huì)發(fā)現(xiàn)數(shù)據(jù)庫(kù)中的數(shù)據(jù)也是錯(cuò)誤的。進(jìn)一步深入研究，您會(huì)發(fā)現(xiàn)保存該值的代碼已被破壞。這是問題的根本原因。您找到的原始代碼只是在其他地方顯示問題的癥狀。
如果您只是修復(fù)了癥狀，那么真正的問題就會(huì)存在。它將繼續(xù)在將來引起問題，同時(shí)你不斷修復(fù)更多的癥狀。
與查找癥狀不同，此步驟不需要太多猜測(cè)。你有一個(gè)起點(diǎn)，從那里你可以追溯到根本原因，所以你不需要猜測(cè)。
盡管如此，這一步可能非常耗時(shí)，因?yàn)槟?jīng)常需要在幾個(gè)級(jí)別上深入研究代碼。多長(zhǎng)時(shí)間在很大程度上取決于根本原因與癥狀相比的位置 -
有時(shí)它們甚至可能是相同的，但如示例所示，它可能會(huì)降低幾個(gè)等級(jí)。
第5步：修復(fù)錯(cuò)誤
較后我們可以解決這個(gè)問題。我們已經(jīng)復(fù)制了這個(gè)錯(cuò)誤，找到了癥狀發(fā)生的地方并找到了根本原因。
在完成所有工作之后，這一步通常是相當(dāng)微不足道的。我們有關(guān)于出了什么問題，應(yīng)該發(fā)生什么以及出現(xiàn)什么癥狀的信息。錯(cuò)誤通常不需要大的修改來修復(fù)，因此實(shí)現(xiàn)部分往往很快。
第6步：確保錯(cuò)誤得到修復(fù)
作為這個(gè)過程的較后一步，我們需要確保錯(cuò)誤被??徹底掩蓋。
這可以通過重復(fù)您之前重現(xiàn)問題的步驟來完成。
偶爾這個(gè)bug仍然會(huì)重現(xiàn)。在這種情況下，您通常需要返回步驟4或5并從那里繼續(xù)。
如果對(duì)軟件測(cè)試、接口測(cè)試、自動(dòng)化測(cè)試、性能測(cè)試、LR腳本開發(fā)、面試經(jīng)驗(yàn)交流。感興趣可以175317069，群內(nèi)會(huì)有不定期的發(fā)放0元的資料鏈接，這些資料都是從各個(gè)技術(shù)網(wǎng)站搜集、整理出來的，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我，我會(huì)注明出處之后分享給大家。
這個(gè)過程有什么問題?
現(xiàn)在我們已經(jīng)查看了錯(cuò)誤修復(fù)過程中的每個(gè)步驟，我們可以確定這些關(guān)鍵難點(diǎn)：
缺乏有關(guān)該問題的信息：錯(cuò)誤報(bào)告通常缺少重要信息，這使得很難理解問題并重現(xiàn)問題。我們擁有的信息越少，花費(fèi)的時(shí)間就越多。
猜測(cè)：我們經(jīng)常需要進(jìn)行一些猜測(cè)。我們沒有解決問題所需的所有信息，也沒有辦法在代碼中查明問題。因此我們需要猜測(cè)，這本質(zhì)上是容易出錯(cuò)的
時(shí)間限制的壓力：我們經(jīng)常需要修復(fù)錯(cuò)誤，因?yàn)橛脩艉涂蛻粢约皹I(yè)務(wù)依賴于軟件的工作。反過來，這可能會(huì)使得不能正確分析問題，這會(huì)導(dǎo)致更多的錯(cuò)誤和問題。
所有這些都有助于減緩錯(cuò)誤修復(fù)并使其成為一個(gè)繁瑣的過程。我們編寫代碼來修復(fù)bug的部分很少是較大的時(shí)間下沉!
但是，盡管如此，有時(shí)我們可以非常地修復(fù)錯(cuò)誤。這通常發(fā)生在我們添加新功能和處理全新代碼時(shí)。
為什么是這樣?
如果我們?cè)诳紤]使用全新代碼時(shí)的典型情況，我們通常會(huì)非常熟悉我們剛才寫的內(nèi)容。在這種情況下發(fā)現(xiàn)錯(cuò)誤的人通常與編寫代碼的人相同。
這幾乎完全消除了猜測(cè)!
我們知道我們剛寫的代碼
我們經(jīng)常以小的漸進(jìn)步驟測(cè)試我們的代碼，因此可能導(dǎo)致錯(cuò)誤的代碼更少
因此，修復(fù)錯(cuò)誤是一件輕而易舉的事。通常情況下，您只需將alt-tab返回到編輯器，立即發(fā)現(xiàn)問題并進(jìn)行更快的修復(fù)，而不是說“它不起作用”。
收集更好的信息
我們可以有把握地說，缺乏信息和由此產(chǎn)生的猜測(cè)是導(dǎo)致修復(fù)bug變慢的較大因素。
我們可以做些什么來改善這種情況?
讓我們首先看一下我們可以做些什么來從用戶那里獲取更多信息并進(jìn)入錯(cuò)誤報(bào)告。邁出這一步的步是向用戶詢問一些具體問題。這有助于指導(dǎo)用戶為我們提供更有效地解決問題所需的信息。
以下是您可以使用的一些問題。我不記得我次看到這些，但我傾向于自己使用這種格式并且效果很好。
1.問題的簡(jiǎn)短描述
2.發(fā)生了什么?
3.應(yīng)該發(fā)生什么呢?
4.如何重現(xiàn)這個(gè)問題?
個(gè)并不是必要的，但是如果您使用像JIRA這樣的工具，因?yàn)槟枰搯栴}的名稱，這將非常有用。第二個(gè)是相當(dāng)明顯的，第三個(gè)對(duì)于理解用戶期望發(fā)生的事情非常有用。雖然你可以自己解決這個(gè)問題，但較好事先了解一下
- 特別是有時(shí)它可能不是技術(shù)問題，而只是混亂的結(jié)果。
第四點(diǎn)可能是較重要的，但用戶并不總是知道如何填補(bǔ)這一點(diǎn)。如果可能的話，較好給他們一個(gè)小樣本，如你想要它填充，如“1。我在第X頁(yè)2.我點(diǎn)擊按鈕Y
3.我輸入值Z“。
特別是對(duì)于Web應(yīng)用程序有用的其他信息是用戶的瀏覽器和操作系統(tǒng)。根據(jù)用戶的不同，他們可能并不總是知道這一點(diǎn)，因此能夠自動(dòng)收集這些信息可能很有價(jià)值。為此，您可以考慮集成Usersnap等服務(wù)，這有助于將更多數(shù)據(jù)收集到錯(cuò)誤報(bào)告中。
在腳本錯(cuò)誤的情況下，具有堆棧跟蹤通常也是有用的，盡管具有良好的再現(xiàn)步驟，您也應(yīng)該能夠自己獲得它。像Loggly這樣的工具可用于自動(dòng)收集有關(guān)錯(cuò)誤的信息(即使在客戶端Javascript代碼中)，這樣您就可以更好地了解發(fā)生的情況。
這些步驟是改進(jìn)流程的良好起點(diǎn)。但是他們并沒有真正解決所有問題。例如，無論您嘗試多少，用戶都可以并且將繼續(xù)發(fā)送令人困惑的錯(cuò)誤報(bào)告。
我知道。我反復(fù)告訴用戶他們需要包含重現(xiàn)問題的步驟，或者我們不能做任何事情，而且我仍然不斷得到可怕的“它不起作用”的錯(cuò)誤報(bào)告。
“Jani，X破了修復(fù)它”
啊。
那么還有什么我們可以做到這一點(diǎn)并不依賴于那些挑剔的用戶呢?
記錄運(yùn)行時(shí)信息
記錄經(jīng)常被忽視作為一種工具。也許這樣做缺乏好的庫(kù)，或缺乏使用日志輸出的好工具 -
因?yàn)樽屛覀兠鎸?duì)它，誰想通過手工查找特定事件來瀏覽一個(gè)巨大的日志文件?但是正確完成并使用好的工具，日志可以提供有價(jià)值的信息。
大多數(shù)開發(fā)人員僅將日志記錄用作臨時(shí)措施。很容易將一堆`console.log打入我們的代碼只是為了看看發(fā)生了什么 - 我做了很多。
但是當(dāng)我說伐木時(shí)，我不只是談?wù)撜{(diào)試日志或錯(cuò)誤日志。我正在談?wù)撘话愕牡卿?- 關(guān)于代碼中發(fā)生了什么，正在發(fā)送什么輸入等的信息。
以更系統(tǒng)的方式登錄需要一些工作。我們需要注意包括登錄我們的代碼，我們需要確保記錄可能有用的信息。那么這有助于加快bug的修復(fù)速度呢?
有時(shí)，如果沒有用戶告訴我們，可能會(huì)出現(xiàn)問題。自動(dòng)進(jìn)程在沒有記錄的情況下基本上是不透明的，你永遠(yuǎn)不會(huì)知道出了什么問題。
如果您有良好的日志，他們可以幫助您更快地找到問題。根據(jù)您記錄的內(nèi)容和方式，他們可以指出問題的一般方向，甚至提供更具體的信息，例如向您顯示哪些值是錯(cuò)誤的。
特別是在自動(dòng)化流程的情況下，日志記錄很重要。除非您有日志，否則通常無法跟蹤此類進(jìn)程中發(fā)生的情況。日志應(yīng)該足夠詳細(xì)，以便讓我們對(duì)發(fā)生的事情有一個(gè)合理的了解。
使用這樣的日志有助于通過向我們提供更多有用信息來減少猜測(cè)工作量。
盡管我喜歡將Java變得糟糕，但日志記錄是他們做得很好的一件事。它有許多庫(kù)和已建立的日志實(shí)踐。如果您遇到過Java應(yīng)用程序的問題，您可能會(huì)查看日志甚至增加日志詳細(xì)程度。他們中的許多人輸出了大量的日志。
記錄有用的是什么?對(duì)于每個(gè)應(yīng)用程序來說，擁有日志或記錄所有內(nèi)容并不是必要的，但這里有一些例子：
記錄個(gè)人請(qǐng)求。例如，如果您使用過Apache或Nginx，它們都有一個(gè)日志文件，該文件為服務(wù)器執(zhí)行的每個(gè)請(qǐng)求獲取一行，以及有關(guān)它的信息。僅此信息不一定有用，但如果您為每個(gè)請(qǐng)求記錄多條信息，這可能是首先記錄的好信息。
記錄流程或事務(wù)中的步驟。我們假設(shè)您的用戶可以上傳圖片，但您可以調(diào)整圖片大小。您可以記錄流程中的每個(gè)步驟，例如“上傳的圖像”，“調(diào)整圖像大小”等。
記錄與外部工具/服務(wù)的交互。訪問數(shù)據(jù)庫(kù)，API或在我們的圖像大小調(diào)整示例中，如果您調(diào)用ImageMagick等工具來執(zhí)行某些操作。
根據(jù)您查找日志的有用程度，實(shí)現(xiàn)啟用/禁用某些類型的日志或基于每個(gè)用戶啟用/禁用日志的方法也是一個(gè)好主意。
更快地發(fā)現(xiàn)錯(cuò)誤
到目前為止我們所看到的所有這些措施都沒有解決我們的關(guān)鍵問題。錯(cuò)誤報(bào)告和日志雖然有用，但只會(huì)在事后提供更多信息。
還記得我們?nèi)绾握业叫迯?fù)的錯(cuò)誤之間的重要區(qū)別，以及需要很長(zhǎng)時(shí)間才能修復(fù)的錯(cuò)誤是我們檢測(cè)問題的時(shí)間。
每當(dāng)我們積極處理一段代碼并在開發(fā)過程中發(fā)現(xiàn)錯(cuò)誤時(shí)，它們的修復(fù)速度要快得多。我們對(duì)代碼有了全新的記憶，我們已經(jīng)掌握了所有信息，因此我們不需要進(jìn)行其他必要的考古。
到目前為止，這些都沒有任何幫助，即使這是花費(fèi)多少時(shí)間的較大貢獻(xiàn)者之一。
我們?cè)鯓硬拍芨斓匕l(fā)現(xiàn)更多的錯(cuò)誤，甚至在我們的開發(fā)過程中?
顯然，我們可以聘請(qǐng)二十多位QA來用顯微鏡進(jìn)行更改。然而，對(duì)于大多數(shù)團(tuán)隊(duì)而言，這并不是很實(shí)用，即使使用質(zhì)量增加流程，也可能需要一些時(shí)間來發(fā)現(xiàn)問題，此時(shí)我們已經(jīng)轉(zhuǎn)向了其他方面，所以它無濟(jì)于事。
在開發(fā)過程中可以幫助我們發(fā)現(xiàn)錯(cuò)誤的是測(cè)試自動(dòng)化。
我們可以在開發(fā)機(jī)器上運(yùn)行自動(dòng)化測(cè)試
即使在小代碼更改后，單元測(cè)試套件也可以自動(dòng)運(yùn)行
精心設(shè)計(jì)的測(cè)試可為我們提供有關(guān)問題的準(zhǔn)確信息
測(cè)試自動(dòng)化是一個(gè)更加現(xiàn)實(shí)的目標(biāo)。它不需要大量的前期投資：您可以逐步開始使用它，并且每一步都可以獲得越來越多的好處。
單元測(cè)試如何加速bug修復(fù)?
每當(dāng)我們更改代碼時(shí)，我們都會(huì)冒險(xiǎn)引入錯(cuò)誤。但是，如果我們新添加的代碼存在錯(cuò)誤，我們通常會(huì)輕松地發(fā)現(xiàn)并修復(fù)它們。
新添加或更改的代碼很容易修復(fù)，因?yàn)槲覀円呀?jīng)掌握了它 -
我們只是花時(shí)間研究它!這意味著可以輕松找到并修復(fù)其中的任何問題，因?yàn)槲覀儾恍枰_始挖掘代碼來找到它。我們?nèi)匀豢梢杂涀∈虑榈陌l(fā)展方向。
因此，我們可以同意，我們?cè)皆绨l(fā)現(xiàn)錯(cuò)誤，就越容易修復(fù)。
但單元測(cè)試如何幫助我們做到這一點(diǎn)?
首先，單元測(cè)試通常包含以下部分：
正在測(cè)試的內(nèi)容的描述性名稱，例如“它應(yīng)該驗(yàn)證用戶的名稱”
用于初始化和運(yùn)行測(cè)試的簡(jiǎn)短代碼段
驗(yàn)證。每個(gè)測(cè)試都有一個(gè)斷言來驗(yàn)證代碼片段產(chǎn)生了正確的結(jié)果。
然后，如果這樣的測(cè)試失敗，我們會(huì)得到以下信息：
失敗測(cè)試的名稱
關(guān)于斷言如何失敗的具體信息，經(jīng)常給我們一個(gè)特定的比較，例如“用戶名與預(yù)期格式不匹配”
堆棧跟蹤，它為我們提供了導(dǎo)致失敗的特定代碼行
讓我們將這些與我們想要的錯(cuò)誤報(bào)告進(jìn)行比較：
名稱
發(fā)生了什么的描述
應(yīng)該發(fā)生什么的描述
重現(xiàn)問題的步驟列表
你能看到我們從測(cè)試中得到的結(jié)果嗎?我們從一個(gè)好的錯(cuò)誤報(bào)告中獲得了我們想要的信息!不僅如此，測(cè)試在開發(fā)過程中為我們提供了這些信息。
當(dāng)您仍在處理代碼時(shí)，單元測(cè)試可以為您提供所需信息的即時(shí)反饋，因此您的想法一切都很新鮮。
所有這些都有助于確保我們有足夠的信息來修復(fù)錯(cuò)誤。我們知道發(fā)生了什么，應(yīng)該發(fā)生什么，我們可以通過再次運(yùn)行測(cè)試來重現(xiàn)錯(cuò)誤...我們甚至可以通過再次運(yùn)行測(cè)試來驗(yàn)證我們的錯(cuò)誤修復(fù)代碼是否正常工作。
作為額外的好處，測(cè)試也會(huì)捕獲代碼中其他地方的更多錯(cuò)誤。通常由于我們的更改，我們會(huì)在其他地方意外地導(dǎo)致錯(cuò)誤。這些很容易被忽視，較終難以修復(fù)，但如果你有單元測(cè)試，沒問題
- 一旦你編寫測(cè)試，你可以保持它，它不斷捕捉錯(cuò)誤和有用。
結(jié)論
通過修復(fù)錯(cuò)誤，較大的時(shí)間接收器不是編寫修復(fù)程序。在我們開始編寫任何代碼來修復(fù)bug之前，我們需要做的所有工作。其中大部分是由于缺乏信息 -
錯(cuò)誤的錯(cuò)誤報(bào)告，大量的代碼，甚至糟糕的代碼都可能導(dǎo)致錯(cuò)誤。
我們可以通過嘗試在錯(cuò)誤報(bào)告中獲取更多信息來改善這種情況，但更快地修復(fù)錯(cuò)誤的較佳方法是更早地發(fā)現(xiàn)錯(cuò)誤。
在開發(fā)過程中遇到的錯(cuò)誤是較快修復(fù)的，因?yàn)槲覀冋诜e極處理有問題的代碼，并且我們?cè)陬^腦中擁有所需的信息。這意味著我們不需要開始挖掘錯(cuò)誤報(bào)告或代碼來弄清楚發(fā)生了什么。
在測(cè)試期間捕獲更多問題的較佳方法是單元測(cè)試。他們解決了所有三個(gè)問題：
1.我們沒有足夠的信息。解決了?- 失敗的測(cè)試告訴我們出了什么問題以及應(yīng)該發(fā)生什么，指出我們確切的功能。測(cè)試本身就是bug的再現(xiàn)。
2.除非我們對(duì)整個(gè)代碼庫(kù)非常熟悉，否則我們需要做一些工作來找到問題的根源。已解決?-
失敗的測(cè)試告訴我們哪個(gè)功能失敗，因此不會(huì)涉及任何猜測(cè)。更好的是，測(cè)試通常在開發(fā)過程中失敗，因此所有代碼在我們的記憶中仍然是新鮮的。
3.由于時(shí)間限制，有時(shí)會(huì)跳過查找根本原因，導(dǎo)致代碼錯(cuò)誤。解決?- 測(cè)試將失敗的根本原因，而不是癥狀，給我們確切的位置，我們需要解決。
您也不需要花費(fèi)大量精力進(jìn)行測(cè)試。您可以逐個(gè)開始添加測(cè)試，例如修復(fù)錯(cuò)誤時(shí)。隨著您添加的每項(xiàng)測(cè)試，您將獲得越來越多的好處。
測(cè)試的主要問題是它可能很難入門。然而，一旦你學(xué)會(huì)了這些概念，它們就不會(huì)過時(shí)了 -
不像當(dāng)下流行的圖書館，測(cè)試已經(jīng)存在了很長(zhǎng)時(shí)間，無論你使用什么庫(kù)或語言，都可以使用完全相同的原理。
單元測(cè)試還有更多的好處，而不僅僅是更快地修復(fù)bug。
感謝您的閱讀，相信通過今天的文章你已經(jīng)了解了如何更快地修復(fù)Bug的方法，你在實(shí)際的工作中，還有別的好主意好方法嗎?快來達(dá)內(nèi)教育就業(yè)軟件測(cè)試培訓(xùn)機(jī)構(gòu)跟我們分享吧!
