軟件測(cè)試時(shí)間簡(jiǎn)史
1979年，Glenford Myers 在《 The Art of Software Testing 》一書中提出“測(cè)試的目的是證偽”這一概念，推翻了過去“為表明軟件正確而進(jìn)行測(cè)試”的錯(cuò)誤認(rèn)識(shí)，為軟件測(cè)試的發(fā)展指出了方向，軟件測(cè)試的理論、方法在之后得到了長(zhǎng)足的發(fā)展。
測(cè)試的目的是證偽，不是要想盡一切辦法將測(cè)試和開發(fā)對(duì)立起來，而是想盡一切辦法證明不存在偽，這樣測(cè)試工程師就不再是永遠(yuǎn)帶“壞消息”的人。
1983年，Bill Hetzel 在《軟件測(cè)試完全指南》中指出：測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)，測(cè)試是對(duì)軟件質(zhì)量的度量。
2002年，Rick和Stefan在《系統(tǒng)的軟件測(cè)試》一書中對(duì)軟件測(cè)試做了進(jìn)一步定義：測(cè)試是為了度量和提高被測(cè)軟件的質(zhì)量，對(duì)測(cè)試軟件進(jìn)行工程設(shè)計(jì)、實(shí)施和維護(hù)的整個(gè)生命周期過程。這也轉(zhuǎn)變了測(cè)試的定義，測(cè)試不單是一個(gè)發(fā)現(xiàn)問題的成果，而是一個(gè)軟件質(zhì)量評(píng)價(jià)的行為活動(dòng)，是質(zhì)量工程。質(zhì)量工程學(xué)中對(duì)于軟件失效是這樣分析的:由于軟件內(nèi)部邏輯復(fù)雜，運(yùn)行環(huán)境動(dòng)態(tài)變化，且不同的軟件差異可能很大，因而軟件失效機(jī)理可能有不同的表現(xiàn)形式。
20世紀(jì)90年代，測(cè)試工具、系統(tǒng)開始大行天下。時(shí)至今日，工程效率、DevOps越來越熱，測(cè)試工程師如果沒有辦法快速融入其中，就容易被淘汰。
軟件測(cè)試工程師是一個(gè)技術(shù)崗位
在信息系統(tǒng)的質(zhì)量保障過程中，測(cè)試工程師發(fā)揮重要的作用，但是卻是一個(gè)沒有實(shí)質(zhì)性產(chǎn)出的角色。一個(gè)系統(tǒng)上線后平穩(wěn)，沒有明顯的被觸發(fā)的缺陷。公司老板會(huì)認(rèn)為開發(fā)技術(shù)實(shí)力強(qiáng)，如果出了問題，鍋就甩給了測(cè)試。這到底是為什么呢？
其實(shí)這種現(xiàn)象并不是測(cè)試不重要，而是是很多測(cè)試從業(yè)者偷懶帶來的后果。相信很多人都知道軟件測(cè)試過程中很重要的一項(xiàng)工作就是設(shè)計(jì)測(cè)試用例，設(shè)計(jì)測(cè)試用例有很多科學(xué)的方法例如等價(jià)類、因果圖、場(chǎng)景法、邊界值。
但是在如今，很多軟件測(cè)試工程師都已經(jīng)將這些科學(xué)的方法丟到了一遍。這也難免會(huì)讓一些不懂技術(shù)的人（例如你公司的老板）會(huì)認(rèn)為你做測(cè)試做的事情和他自己使用一個(gè) APP 或者一個(gè) WEB 的方式?jīng)]區(qū)別，也就不會(huì)受到重視了。
但是軟件測(cè)試工程師是一個(gè)技術(shù)崗位，除去設(shè)計(jì)和撰寫測(cè)試用例以外，你還需要有很多和開發(fā)、運(yùn)維交際的技能，例如 API 的服務(wù)怎么做測(cè)試、服務(wù)間怎么解耦合、測(cè)試環(huán)境怎么部署、測(cè)試結(jié)果如何分析等等。
現(xiàn)如今，提高工程效率已經(jīng)變成了一個(gè)大街小巷都在流傳的一個(gè)話題，無(wú)論是 DevOps 還是 TestOps，都在支持測(cè)試用更多的自動(dòng)化手段代替手工。但是自動(dòng)化并不是恒等于要寫代碼，這是一個(gè)種狹義的自動(dòng)化看法。
自動(dòng)化測(cè)試就是讓測(cè)試階段通過自動(dòng)化的方式完成，并不一定要寫很多的測(cè)試腳本代碼，編寫測(cè)試腳本僅僅只是自動(dòng)化的一種方法。所謂條條大路通羅馬，現(xiàn)如今很多有效的工具都可以滿足自動(dòng)化的測(cè)試需求，例如 postman 可以完成 API 的接口自動(dòng)化的工作任務(wù)、基于圖形的自動(dòng)化框架可以完成 UI 的自動(dòng)化任務(wù)需求。但是作者推薦大家，有代碼能力的還是要盡量多寫代碼。沒有代碼能力的測(cè)試工程師也不用誠(chéng)惶誠(chéng)恐，利用好各種各樣的工具，同樣可以讓你跟上工程效率的要求，不被技術(shù)進(jìn)展的車輪碾壓。
什么是測(cè)試架構(gòu)師？
說道測(cè)試工程師了，在這再扯一點(diǎn)測(cè)試架構(gòu)師的東西吧。
架構(gòu)師是一個(gè)并非計(jì)算機(jī)行業(yè)本來就有的詞匯，來自于建筑學(xué)，英文是Architect。建筑工程中的架構(gòu)師是負(fù)責(zé)整體建筑的架構(gòu)設(shè)計(jì)。因此從宏觀上看，軟件行業(yè)的架構(gòu)師也類似，是負(fù)責(zé)對(duì)整體架構(gòu)設(shè)計(jì)。
在軟件工程中架構(gòu)師是一個(gè)團(tuán)隊(duì)的技術(shù)的領(lǐng)頭者。主要工作內(nèi)容出去對(duì)項(xiàng)目的整體設(shè)計(jì)和規(guī)劃外，也會(huì)參與一些實(shí)際技術(shù)問題的解決和探討，攻克技術(shù)難關(guān)，趟平技術(shù)線上的坑，使得工程在軟件生命周期過程中平穩(wěn)順利完成。
在研發(fā)領(lǐng)域有各式各樣各司其職架構(gòu)師，負(fù)責(zé)系統(tǒng)業(yè)務(wù)的業(yè)務(wù)架構(gòu)師、負(fù)責(zé)基礎(chǔ)設(shè)備和設(shè)施的基礎(chǔ)設(shè)施架構(gòu)師，負(fù)責(zé)公共組件和平臺(tái)的中間件架構(gòu)師。
在測(cè)試領(lǐng)域只有一個(gè)，測(cè)試架構(gòu)師。那么什么才是測(cè)試架構(gòu)師呢？
測(cè)試架構(gòu)師其實(shí)是在測(cè)試部門中承擔(dān)著規(guī)劃自動(dòng)化技術(shù)棧、基礎(chǔ)測(cè)試框架選型、基礎(chǔ)測(cè)試環(huán)境維護(hù)等工作的角色。肩負(fù)提高部門提高工程效率的職責(zé)，有著為部門提供技術(shù)指導(dǎo)和制定質(zhì)量保障策略的使命。除此之外，測(cè)試架構(gòu)師必須能駕馭產(chǎn)品的質(zhì)量、提供指導(dǎo)、反饋和建議，以提高整個(gè)工程部門的質(zhì)量規(guī)范。
測(cè)試架構(gòu)師應(yīng)該都具備跨組織的溝通和推動(dòng)變革的能力。
測(cè)試架構(gòu)師應(yīng)該有的工作日常內(nèi)容
-
審查系統(tǒng)架構(gòu)、系統(tǒng)構(gòu)件/組件及其接口關(guān)系等的設(shè)計(jì)
-
確保系統(tǒng)的可測(cè)試性
-
設(shè)計(jì)軟件系統(tǒng)的測(cè)試策略和方法，特別是在系統(tǒng)的性能、安全性、穩(wěn)定性、可靠性等方面的測(cè)試方法、技術(shù)線路和質(zhì)量標(biāo)準(zhǔn)
-
構(gòu)件復(fù)雜的系統(tǒng)測(cè)試環(huán)境，并分析、解決測(cè)試中出現(xiàn)的較深的技術(shù)問題(Troubleshooting)和幫助做好缺陷的隔離
-
對(duì)系統(tǒng)(性能、安全性、穩(wěn)定性、可靠性)測(cè)試作出分析、評(píng)估，并提出為改善系統(tǒng)性能、可靠性而進(jìn)行設(shè)計(jì)修改、代碼重構(gòu)的建議
-
設(shè)計(jì)測(cè)試自動(dòng)化的技術(shù)框架，主持重要的測(cè)試工具的研究、評(píng)估、設(shè)計(jì)
-
參與系統(tǒng)部署的設(shè)計(jì)
-
參與新技術(shù)的評(píng)估和引進(jìn)
-
幫助改進(jìn)測(cè)試流程、提高測(cè)試效率
總結(jié)
這個(gè)小節(jié)我們了解了一下測(cè)試工程師和測(cè)試架構(gòu)師到底是什么，下節(jié)課我們一起來看一下一個(gè)合格的測(cè)試工程師的職業(yè)路線規(guī)劃是什么。