問(wèn)：如何才能評(píng)價(jià)一個(gè)SDET的工作情況呢？

　　答：關(guān)鍵還是在找Bug的情況上。評(píng)價(jià)SDET的工作不一定在于他找到的Bug數(shù)量，更重要的是還是找到質(zhì)量更高的Bug。找到質(zhì)量更高的Bug有時(shí)候需要一些運(yùn)氣，但是更多的是基于經(jīng)驗(yàn)，是對(duì)產(chǎn)品深入了解的程度。

　　要找到質(zhì)量好的Bug一定要花費(fèi)很多的時(shí)間。在產(chǎn)品開(kāi)始階段，Bug多，可能比較容易找到Bug，隨著這些Bug逐漸被修正，Bug的尋找機(jī)會(huì)越來(lái)越困難，能否找到更高質(zhì)量的Bug需要看SDET對(duì)這些代碼所付出的努力了。一般來(lái)說(shuō)SDET會(huì)對(duì)于尋找Bug有經(jīng)驗(yàn)積累和感覺(jué)。開(kāi)發(fā)人員在編寫和設(shè)計(jì)某些代碼時(shí)可能會(huì)欠考慮，一般來(lái)說(shuō)如果一個(gè)地方出現(xiàn)Bug，作相應(yīng)的改動(dòng)之后，會(huì)產(chǎn)生更多的Bug，另外一般有Bug的代碼周圍會(huì)有更多的Bug聚集。有經(jīng)驗(yàn)的測(cè)試人員會(huì)根據(jù)這點(diǎn)，鎖定Bug的特殊特征，然后根據(jù)這個(gè)特征能夠找到更多更好的Bug出來(lái)。

　　問(wèn)：這么看起來(lái)SDET的工作還是地分繁重的。那么市面上的自動(dòng)化測(cè)試的工具是否能夠減輕他們的工作量呢？

　　答：首先要判斷所要測(cè)試的對(duì)象適合不適合自動(dòng)化測(cè)試，不是所有的問(wèn)題都適合做自動(dòng)化的測(cè)試。自動(dòng)化有它不能或者不適合解決的問(wèn)題。它善于解決的問(wèn)題是， 一次編寫出來(lái)，可以重用，每次軟件版本更新，都可以用同一個(gè)自動(dòng)化測(cè)試的工具進(jìn)行測(cè)試。然而，自動(dòng)化找Bug，并且要找到新的Bug的時(shí)候，還是離不開(kāi)人工的操作。通過(guò)查看我們的Bug日志也可以發(fā)現(xiàn)，新Bug很多都是SDET自己動(dòng)手找到的。SDET需要對(duì)于常規(guī)的地方，自己動(dòng)手進(jìn)行編寫測(cè)試工具進(jìn)行測(cè)試，然而也是思考哪些地方可能會(huì)出現(xiàn)新的Bug，這些要去手工地進(jìn)行查找。因?yàn)楣ぞ弋吘惯不能幫助人去思考。

　　現(xiàn)在第三方的測(cè)試工作和微軟的平臺(tái)軟件并沒(méi)有很好的介入。這個(gè)也是由于微軟件平臺(tái)軟件的特殊性所決定。 但是對(duì)例如URL這些通用并且與平臺(tái)無(wú)關(guān)的軟件功能模塊進(jìn)行測(cè)試的時(shí)候，第三方軟件會(huì)有一些幫助。但是，在API的測(cè)試方面做一個(gè)通用的工具對(duì)它進(jìn)行測(cè)試是很非常困難的。有個(gè)工具叫做“Any Unit”，直接照調(diào)用API去做一些很基本的測(cè)試，例如檢驗(yàn)這些API是否有正確的相應(yīng)和返回正常。但是，如果要做一些索引測(cè)試（Index testing）的話，非常困難。這是因?yàn)槊鎸?duì)的對(duì)象，越是特殊，這些工具起到的幫助作用越小。所為作為一個(gè)SDET， 需要自己編寫測(cè)試工具來(lái)開(kāi)展工作。

　　TA

　　測(cè)試架構(gòu)師（Test Architect）是在微軟內(nèi)測(cè)試技術(shù)人員技術(shù)發(fā)展方向的高職位。其實(shí)在4、5年前，微軟是沒(méi)有軟件測(cè)試架構(gòu)師這個(gè)職位的。測(cè)試人員發(fā)展到高級(jí)別是測(cè)試主管，然而這是偏管理方向的發(fā)展道路。對(duì)于那些鐘愛(ài)技術(shù)又十分的測(cè)試人員來(lái)說(shuō)缺少這方面的職位發(fā)展目標(biāo)。后來(lái)在測(cè)試工作的長(zhǎng)期發(fā)展過(guò)程中，需要有人去做整個(gè)產(chǎn)品在測(cè)試方面的推進(jìn)工作。慢慢地，隨著擔(dān)任此項(xiàng)工作的人越來(lái)越多，軟件測(cè)試架構(gòu)師這個(gè)職位定位和概念漸漸清晰起來(lái)。

　　那么對(duì)于這要一個(gè)職位，都需要具備什么樣的素質(zhì)和特性呢？

　　堅(jiān)持、有毅力、在逆境的時(shí)候要能堅(jiān)持自己的想法和做法。以ATC軟件測(cè)試經(jīng)理何浪飛為例，在成為軟件測(cè)試架構(gòu)師（Test Architect）之前，他是這樣堅(jiān)持，并且曾經(jīng)為了一個(gè)大家都覺(jué)得并不那么重要的Bug，歷經(jīng)周折來(lái)為這個(gè)小Bug“正身”。

　　這個(gè)既不會(huì)返回錯(cuò)誤又不會(huì)造成Down機(jī)的小小Bug只是在注冊(cè)表中某個(gè)值的默認(rèn)設(shè)置上可能會(huì)給一些初級(jí)用戶帶來(lái)不便，讓他們不知道該如何正確地使用這個(gè)值相關(guān)的功能。何浪飛當(dāng)時(shí)所在的測(cè)試小組中包括那些有20年以上經(jīng)驗(yàn)的員工，幾乎所有人都因?yàn)檫@個(gè)Bug造成不便的幾率只是可能，所以認(rèn)為它還到不了必須要去修訂的程度，而加入這個(gè)測(cè)試小組不到2年的何浪飛卻堅(jiān)信改進(jìn)它非常必要。既然問(wèn)題出在可能會(huì)讓用戶感到不便，那么用戶的反饋將是進(jìn)行驗(yàn)證的好證據(jù)。于是他找到負(fù)責(zé)相關(guān)產(chǎn)品支持的人員，查找該產(chǎn)品用戶反饋問(wèn)題的Top 10列表，發(fā)現(xiàn)自己堅(jiān)持需要修訂的Bug在其中。在了解了解決問(wèn)題所帶來(lái)的人員支持等所花費(fèi)的時(shí)間和各項(xiàng)費(fèi)用之后，何浪飛的意見(jiàn)終于被大家欣然采納，很快修正了那個(gè)Bug。

　　站在用戶的角度上審視產(chǎn)品，相信自己，并且要用例證說(shuō)話。這是要達(dá)到測(cè)試工作技術(shù)領(lǐng)域的高級(jí)別――軟件測(cè)試架構(gòu)師所必需具備的。在微軟，很多領(lǐng)域都有很強(qiáng)的競(jìng)爭(zhēng)對(duì)手，大家需要付出很長(zhǎng)時(shí)間的努力，然而也許需要5年才能超過(guò)他們，這個(gè)時(shí)候在市場(chǎng)上很長(zhǎng)一段時(shí)間都不會(huì)有比較明顯的表現(xiàn)，所以特別需要給自己信心，相信自己做的工作。在項(xiàng)目組里也是，也許觀點(diǎn)大家都不同意，但是如果在分析了事實(shí)之后，覺(jué)得自己是正確的，需要堅(jiān)持，而不是簡(jiǎn)單屈從大多數(shù)和經(jīng)驗(yàn)深厚的人或者是領(lǐng)導(dǎo)的決定。

　　然而，要成為軟件測(cè)試架構(gòu)師，僅憑這些還不夠。因?yàn)樗麄兊暮芏喙ぷ鞫夹枰晚?xiàng)目經(jīng)理、開(kāi)發(fā)人員以及項(xiàng)目外部相關(guān)人員互相協(xié)調(diào)和合作，在溝通和影響力傳遞的方面也需要有很高的造詣。

　　那么測(cè)試架構(gòu)師在和項(xiàng)目經(jīng)理、開(kāi)發(fā)人員以及項(xiàng)目相關(guān)的其他外部人員之間如何協(xié)調(diào)進(jìn)行工作呢？