了解用戶需求不要認(rèn)為和軟件測(cè)試沒有聯(lián)系，只要咱們和用戶的需求到達(dá)共識(shí)，調(diào)查用戶對(duì)軟件的需求和操作，才干更好的做軟件測(cè)試。所以，在測(cè)試的進(jìn)程中，咱們要時(shí)間想著用戶！

    與BUG樹立"密切"的聯(lián)系多讀Bug,在一個(gè)團(tuán)隊(duì)中，多位軟件測(cè)試工程師一同作業(yè)，請(qǐng)多閱覽他們發(fā)現(xiàn)的Bug, 特別是與你測(cè)試相關(guān)的Bug .咱們能夠從別人找Bug的進(jìn)程中，學(xué)到許多東西。

    促進(jìn)一個(gè)Bug的修正，首先從寫好Bug標(biāo)題、開端的，每次發(fā)完一個(gè)Bug,都要把這個(gè)Bug重讀一遍，保證它是合理的，并供給細(xì)節(jié)。假如某些重要的Bug 沒被糾正，要尋其本源，保證終究決議和利害權(quán)衡是恰當(dāng)?shù)摹?/p>

    參與Bug的審理 ,在發(fā)布前的一個(gè)階段里，審理組會(huì)決議哪些Bug有必要修正，哪些能夠留到版別更新時(shí)去修正。假如你沒在這個(gè)會(huì)議的名單中，能夠去自動(dòng)要求旁聽。你會(huì)體會(huì)到，審理組在測(cè)試員諾言、用戶影響、已知危險(xiǎn)等要素間，做出利害權(quán)衡的進(jìn)程。這會(huì)是一種十分有意義的閱歷。

    多讀代碼，進(jìn)步編程才能找到要測(cè)試那部分功用的代碼。盡管寫代碼并不是份內(nèi)的事，可是多讀代碼，對(duì)找到潛在的邊沿狀況和軟件缺陷，會(huì)有很大的協(xié)助。

    咱們遇到過一些很有天分的學(xué)員，他們傾向于不去寫代碼?？墒蔷幊淌且豁?xiàng)很有價(jià)值的技術(shù)，能夠協(xié)助咱們更好地閱覽代碼，了解產(chǎn)品的內(nèi)涵和開發(fā)邏輯，一起能夠協(xié)助你寫一些小工具，使本來平平重復(fù)的作業(yè)，變得十分簡(jiǎn)略。