優(yōu)秀測試工程師應(yīng)具備哪些素質(zhì)

人是測試工作中最有價(jià)值也是最重要的資源，沒有一個(gè)合格的、積極的測試小組，測試就不可能實(shí)現(xiàn)。然而，在軟件開發(fā)產(chǎn)業(yè)中有一種非常普遍習(xí)慣，那就是讓那些經(jīng)驗(yàn)最少的新手、沒有效率的開發(fā)者或不適合干其他工作的人去做測試工作。這絕對是一種目光短淺的行為，對一個(gè)系統(tǒng)進(jìn)行有效的測試所需要的技能絕對不比進(jìn)行軟件開發(fā)需要的少，事實(shí)上，測試者將獲得極其廣泛的經(jīng)驗(yàn)，他們將遇到許多開發(fā)者不可能遇到的問題。

①、溝通能力

一名理想的測試者必須能夠同測試涉及到的所有人進(jìn)行溝通，具有與技術(shù)（開發(fā)者）和非技術(shù)人員（客戶，管理人員）的交流能力。既要可以和用戶談得來，又能同開發(fā)人員說得上話，不幸的是這兩類人沒有共同語言。和用戶談話的重點(diǎn)必須放在系統(tǒng)可以正確地處理什么和不可以處理什么上。而和開發(fā)者談相同的信息時(shí)，就必須將這些活重新組織以另一種方式表達(dá)出來，測試小組的成員必須能夠同等地同用戶和開發(fā)者溝通。

②、移情能力

和系統(tǒng)開發(fā)有關(guān)的所有人員都處在一種既關(guān)心又擔(dān)心的狀態(tài)之中。用戶擔(dān)心將來使用一個(gè)不符合自己要求的系統(tǒng)，開發(fā)者則擔(dān)心由于系統(tǒng)要求不正確而使他不得不重新開發(fā)整個(gè)系統(tǒng)，管理部門則擔(dān)心這個(gè)系統(tǒng)突然崩潰而使它的聲譽(yù)受損。測試者必須和每一類人打交道，因此需要測試小組的成員對他們每個(gè)人都具有足夠的理解和同情，具備了這種能力可以將測試人員與相關(guān)人員之間的沖突和對抗減少到最低程度。

③、技術(shù)能力

就總體言，開發(fā)人員對那些不懂技術(shù)的人持一種輕視的態(tài)度。一旦測試小組的某個(gè)成員作出了一個(gè)錯(cuò)誤的斷定，那么他們的可信度就會(huì)立刻被傳揚(yáng)了出去。一個(gè)測試者必須既明白被測軟件系統(tǒng)的概念又要會(huì)使用工程中的那些工具。要做到這一點(diǎn)需要有幾年以上的編程經(jīng)驗(yàn)，前期的開發(fā)經(jīng)驗(yàn)可以幫助對軟件開發(fā)過程有較深入的理解，從開發(fā)人員的角度正確的評價(jià)測試者，簡化自動(dòng)測試工具編程的學(xué)習(xí)曲線。

④、自信心

開發(fā)者指責(zé)測試者出了錯(cuò)是常有的事，測試者必須對自己的觀點(diǎn)有足夠的自信心。如果容許別人對自己指東指西，就不能完成什么更多的事情了。

⑤、外交能力

當(dāng)你告訴某人他出了錯(cuò)時(shí)，就必須使用一些外交方法。機(jī)智老練和外交手法有助于維護(hù)與開發(fā)人員的協(xié)作關(guān)系，測試者在告訴開發(fā)者他的軟件有錯(cuò)誤時(shí)，也同樣需要一定的外交手腕。如果采取的方法過于強(qiáng)硬，對測試者來說，在以后和開發(fā)部門的合作方面就相當(dāng)于“贏了戰(zhàn)爭卻輸了戰(zhàn)役”。

⑥、幽默感

在遇到狡辯的情況下，一個(gè)幽默的批評將是很有幫助的。

⑦、很強(qiáng)的記憶力

一個(gè)理想的測試者應(yīng)該有能力將以前曾經(jīng)遇到過的類似的錯(cuò)誤從記憶深處挖掘出來，這一能力在測試過程中的價(jià)值是無法衡量的。因?yàn)樵S多新出現(xiàn)的問題和我們已經(jīng)發(fā)現(xiàn)的問題相差無幾。

⑧、耐心

一些質(zhì)量保證工作需要難以置信的耐心。有時(shí)你需要花費(fèi)驚人的時(shí)間去分離、識(shí)別和分派一個(gè)錯(cuò)誤。這個(gè)工作是那些坐不住的人無法完成的。

⑨、懷疑精神

可以預(yù)料，開發(fā)者會(huì)盡他們最大的努力將所有的錯(cuò)誤解釋過去。測式者必須聽每個(gè)人的說明，但他必須保持懷疑直到他自己看過以后。

⑩、自我督促

干測試工作很容易使你變得懶散。只有那些具有自我督促能力的人才能夠使自己每天正常地工作。

11、洞察力

一個(gè)好的測試工程師具有“測試是為了破壞”的觀點(diǎn)，捕獲用戶觀點(diǎn)的能力，強(qiáng)烈的質(zhì)量追求，對細(xì)節(jié)的關(guān)注能力。應(yīng)用的高風(fēng)險(xiǎn)區(qū)的判斷能力以便將有限的測試針對重點(diǎn)環(huán)節(jié)。

UML軟件工程組織

--------------------------------------------------------------------------------

軟件測試之我見

mume（轉(zhuǎn)載自CSDN）2002年09月16日

我做軟件測試有一段不短的時(shí)間了，可大量的盲目測試幾乎沒有增長我的測試經(jīng)驗(yàn)，每次測試前總有些茫然，不知道自己怎樣才能有效的發(fā)現(xiàn)軟件中存在的缺陷；測試后也不能肯定是否可以放心的發(fā)布被測軟件。我想可能很多初涉測試的工作者都同我有相似的感覺，我們需要有關(guān)測試的理論知識(shí)的引導(dǎo)，以下是我讀了一些講解測試技術(shù)的書籍后的收獲，以及我對我國當(dāng)前軟件業(yè)中測試這一領(lǐng)域的認(rèn)識(shí)，希望也能給測試同行點(diǎn)滴的收益。

一、軟件測試員的目標(biāo)是盡可能早一些找出軟件缺陷，并確保其得以關(guān)閉。

或許大家會(huì)認(rèn)為軟件測試員的工作目標(biāo)是不言而喻的：就是找軟件缺陷，然而《軟件測試》這本書為軟件測試人員提出了更確切的目標(biāo)：盡可能早一些找出軟件缺陷，并確保其得以修復(fù)。在閱讀全書并仔細(xì)思考后，我覺得此目標(biāo)包含三大點(diǎn)含義：

1． 軟件測試員的基本目標(biāo)是發(fā)現(xiàn)軟件缺陷。

我覺得在這里有必要把這不言而喻的事實(shí)再次強(qiáng)調(diào)一下，因?yàn)橛袝r(shí)產(chǎn)品的開發(fā)小組要測試員只是為了證實(shí)軟件可以運(yùn)行，而不是找缺陷。在這種情況下，測試人員也就缺乏不懈努力發(fā)現(xiàn)缺陷的探索精神和熱情。所以我覺得在心里堅(jiān)信不移的認(rèn)為：軟件測試員的基本目標(biāo)是發(fā)現(xiàn)軟件缺陷，是做好測試的首要條件。

2． 軟件測試員追求的是盡可能早的找出軟件缺陷。

因?yàn)檐浖男迯?fù)費(fèi)用，隨著時(shí)間的推移，將數(shù)十倍的增長，所以軟件測試員應(yīng)盡可能早的找出軟件缺陷。對大型的軟件，在軟件開發(fā)的同時(shí)，就應(yīng)該有緊隨其后的測試，如果等到產(chǎn)品已經(jīng)開發(fā)完畢才開始測試，非常有可能引起大量耗時(shí)費(fèi)力的返工。而如何盡可能早的找出缺陷？《軟件測試》這本書向我們介紹了一些理論上的測試方法：靜態(tài)黑盒測試、動(dòng)態(tài)黑盒測試、靜態(tài)白盒測試、動(dòng)態(tài)白盒測試；配置測試、兼容性測試、易用性測試……，怎樣才能有效的用這些方法盡早的發(fā)現(xiàn)軟件缺陷，需要大家在工作實(shí)踐中不斷的摸索、總結(jié)，進(jìn)而不斷的提高自己的測試能力。

3． 軟件測試人員必需確保找出的軟件缺陷得以關(guān)閉。

請注意，我們這里提的是軟件測試人員必需確保找出的軟件缺陷得以關(guān)閉，而不是要軟件缺陷得以修復(fù)。我們軟件測試員需要對自己找出的軟件缺陷保持一種平常心：并不是我們辛苦找出的每個(gè)軟件缺陷都是必要修復(fù)的?？赡苁怯捎跊]有足夠的時(shí)間、不算真正的軟件缺陷、修復(fù)的風(fēng)險(xiǎn)太大等原因，產(chǎn)品開發(fā)小組決定對一些軟件缺陷不作修復(fù)。

另外，測試員對軟件缺陷描述不清楚，也會(huì)使軟件測試員發(fā)現(xiàn)的缺陷被忽略。所以我們測試員必須在描述軟件缺陷方面狠下功夫：用簡單明了的語句描述軟件缺陷；每一件報(bào)告盡量針對一個(gè)軟件缺陷，避免多個(gè)缺陷混雜在一起，以致其中一些被忽略或忘卻；記錄引出軟件缺陷的操作步驟，使缺陷得以再現(xiàn)。

雖然我們軟件測試員需要對自己找出的軟件缺陷保持一種平常心，但同時(shí)又必須堅(jiān)持有始有終的原則，跟蹤每一個(gè)軟件缺陷的處理結(jié)果，確保軟件缺陷得以關(guān)閉。關(guān)閉軟件缺陷的前提可以是缺陷得以修復(fù)或決定不作修復(fù)。而缺陷是否需要修復(fù)的最終決定權(quán)在軟件的最終負(fù)責(zé)人，檢查缺陷得以關(guān)閉的責(zé)任在測試人員。

二、測試一個(gè)軟件最首要也是最重要的是測試其產(chǎn)品功能說明書。

1 概念

產(chǎn)品功能說明書：對產(chǎn)品最終需要實(shí)現(xiàn)的功能的描述。這些功能是最終確定的需要滿足的客戶需求，也包括是一些軟件必須具備的能力。

在規(guī)范的軟件生成的流程中，產(chǎn)品功能說明書應(yīng)在用戶需求評審會(huì)議召開后，進(jìn)行系統(tǒng)的概要設(shè)計(jì)前確定。

2 原因

（１）很多軟件的缺陷都是因?yàn)楫a(chǎn)品功能說明書不夠全面，經(jīng)常更改造成的；

（２）只有詳細(xì)的閱讀了產(chǎn)品功能說明書，確認(rèn)產(chǎn)品需要實(shí)現(xiàn)的功能，才能擬定切實(shí)可行的測試方案；

3 方法

（１）參照需求說明書，檢查產(chǎn)品功能說明書描述的產(chǎn)品將要實(shí)現(xiàn)的功能是否已經(jīng)完整、準(zhǔn)確、一致、合理的描述了產(chǎn)品的功能，并確保這些功能是可測試的

（２）研究產(chǎn)品說明書是否符合現(xiàn)有的軟件設(shè)計(jì)開發(fā)的標(biāo)準(zhǔn)或規(guī)范；

（３）研究同類軟件，預(yù)測產(chǎn)品的最終結(jié)果；

如果測試人員發(fā)現(xiàn)產(chǎn)品說明書不符合以上幾點(diǎn)，該怎么做？

測試人員需要明白，我們的責(zé)任是反映產(chǎn)品的缺陷，我們不需要也不能修正產(chǎn)品，所以同發(fā)現(xiàn)軟件的其它缺陷一樣，在發(fā)現(xiàn)產(chǎn)品說明書的缺陷后，應(yīng)該把它們?nèi)鐚?shí)并詳細(xì)的記錄下來，呈報(bào)給此軟件的最終負(fù)責(zé)人，對并此缺陷的處理情況進(jìn)行跟蹤。

注意同發(fā)現(xiàn)的軟件其它缺陷一樣，缺陷列表應(yīng)該呈報(bào)給軟件的最終負(fù)責(zé)人，而不是給相關(guān)技術(shù)人員或技術(shù)主管，因?yàn)榧夹g(shù)人員可能會(huì)以在技術(shù)的實(shí)現(xiàn)上有難度為推托，拒絕對缺陷的修改。

4 目前的可執(zhí)行度

（１）很多軟件在開發(fā)前并沒有書面形式的產(chǎn)品說明書

目前我國的許多軟件公司都是小型的手工作坊式的公司，在程序開發(fā)前都沒有一個(gè)正式的、完整的、確定的產(chǎn)品說明書，即便是這種情況，產(chǎn)品說明書也是存在的，它存在在軟件設(shè)計(jì)人員、項(xiàng)目負(fù)責(zé)人的腦海里，在他們心中都有一個(gè)軟件的輪廓，假定了軟件將要實(shí)現(xiàn)的功能。我們的測試人員可以在同他們的交流和不斷的詢問中獲得這個(gè)非正式的產(chǎn)品說明書，值得注意的是在我們得到這些信息后還需要以書面的形式把它們一一列舉出來，再向相關(guān)人員請教，最后做到能完整、準(zhǔn)確、一致、合理的描述了產(chǎn)品的功能。

（２）測試人員一般不會(huì)在項(xiàng)目初期就參與項(xiàng)目

當(dāng)前還存在著這樣一種問題，公司一般不會(huì)讓軟件測試人員在項(xiàng)目的初期就參與項(xiàng)目，一般要等到軟件的雛形出來后才會(huì)讓軟件測試人員著手進(jìn)行測試。對這種情況，測試人員可以通過已經(jīng)建立的軟件的雛形，揣摩產(chǎn)品說明書，然后也是同上段所說一樣，向相關(guān)人員請教，擬定一份書面的完整的、準(zhǔn)確的、一致的、合理的產(chǎn)品說說明書。值得注意的是，測試人員在運(yùn)行軟件的雛形時(shí)，往往會(huì)發(fā)現(xiàn)一些軟件缺陷，這時(shí)千萬不要局限在這些缺陷上耗費(fèi)經(jīng)歷，以致忘了擬定產(chǎn)品說明書的主要任務(wù)，一定要記?。簻y試一個(gè)軟件最首要也是最重要的是測試其產(chǎn)品說明書，在產(chǎn)品說明書明確后，再制定具體的測試案例。

以上兩點(diǎn)是指在公司體系不太正規(guī)的情況下給測試員的建議，但我認(rèn)為要能更好的保證軟件的質(zhì)量，或許規(guī)范生成軟件的整個(gè)運(yùn)作流程更為有效：產(chǎn)品說明書由項(xiàng)目負(fù)責(zé)人來主持定版比較好，因?yàn)樗盐罩a(chǎn)品發(fā)展的方向；在產(chǎn)品說明書定版時(shí)的會(huì)議應(yīng)請負(fù)責(zé)測試的人參加，使他們對產(chǎn)品有一個(gè)宏觀的認(rèn)識(shí)，我也不贊成測試人員過早的局限于某一項(xiàng)目，如果那樣他們會(huì)覺得無所事事。

三、完全測試軟件是絕不可能的，必須對測試的各項(xiàng)進(jìn)行等價(jià)劃分。

1 概念

等價(jià)分配：軟件有無限的測試案例，我們要想辦法把軟件的相似輸入、輸出、操作分成一組，來使無限的測試案例減小到同樣有效的小范圍，這個(gè)過程稱為等價(jià)分配。

邊界條件：軟件計(jì)劃的操作界限所在的邊緣條件，即如果超出這個(gè)邊界條件，就可能會(huì)引出錯(cuò)誤。

2 原因

輸入量太大

輸出結(jié)果太多

軟件實(shí)現(xiàn)途徑太多

軟件說明書沒有客觀標(biāo)準(zhǔn)。從不同的角度看，軟件缺陷的標(biāo)準(zhǔn)不同。

3 方法

（１）數(shù)據(jù)測試：

1） 確定輸入的邊界條件，對邊界線上的及邊界線兩邊的數(shù)據(jù)進(jìn)行測試；

2） 邊界線可能是2的乘方，默認(rèn)值、空白值、零值等；每一個(gè)軟件測試問題各不相同，可能包含格式各樣邊界的不同數(shù)據(jù)。

（２）狀態(tài)測試（軟件的狀態(tài)是指軟件當(dāng)前所處的情況或者模式）

1） 每種狀態(tài)至少訪問一次；

2） 測試看起來最常見最普遍的狀態(tài)轉(zhuǎn)換；

3） 測試狀態(tài)之間最不常用的分支；

4） 測試所有錯(cuò)誤狀態(tài)及其返回值；

5） 測試隨機(jī)狀態(tài)轉(zhuǎn)換。

4 目前的可執(zhí)行度

如果為了減少測試案例的數(shù)量過度進(jìn)行等價(jià)分配，測試漏掉軟件缺陷的風(fēng)險(xiǎn)就會(huì)增加。對初涉軟件測試者，一定要請經(jīng)驗(yàn)豐富的測試員審查預(yù)定的等價(jià)類別。