倘若互聯(lián)網(wǎng)的盡頭是編制漆弄、當(dāng)下是互聯(lián)網(wǎng)的寒冬查近，他就是個帥氣的逆行者杠纵。
以下內(nèi)容是根據(jù)2月23日的直播整理的文字內(nèi)容，戳鏈接可收聽完整音頻分享眶根。
01 當(dāng)下越來越多的互聯(lián)網(wǎng)人轉(zhuǎn)投金融行業(yè)蜀铲，出于怎樣的規(guī)劃選擇逆勢而為？
如果在同一家公司做測試時間做太長的話属百，能學(xué)到的東西會是有限的记劝，對個人職業(yè)發(fā)展來說容易有瓶頸。當(dāng)然這個觀點不是絕對的族扰，在BAT這類大廠厌丑，待得時間久一些對個人能力提升是非常大的。但是渔呵，并不是每個人都有機會進入大廠怒竿，所以我更愿意去嘗試一些不同的行業(yè)，去突破自己扩氢。
在不同的公司或者行業(yè)能學(xué)到的東西也不一樣耕驰，就拿我在保險和銀行的測試工作來說：因為它們背后的業(yè)務(wù)知識、業(yè)務(wù)屬性录豺，還有測試的方法都會有不一樣的地方朦肘，在保險和銀行工作的那幾年對自己業(yè)務(wù)和產(chǎn)品方面能力提升都很大。后來在外企的工作經(jīng)歷双饥，讓我更好的實踐和更加深入的學(xué)習(xí)了敏捷和DevOps媒抠。
我給我自己的一個總結(jié)就是：嘗試不同的行業(yè)，然后去突破自己咏花。
02 金融行業(yè)軟件測試的特點趴生？金融和電商的差異？
第一個方面迟螺，以銀行為例冲秽，金融業(yè)對安全性的要求很高
在銀行在做測試的過程中，有一部分工作是做安全測試矩父。為什么去做安全測試锉桑，因為在銀行系統(tǒng)里面有很多開放的API（Open API）。如果說這些API存在一些安全隱患的話窍株，可能會導(dǎo)致銀行的資產(chǎn)損失民轴。
另一方面是業(yè)務(wù)復(fù)雜性高
還是以銀行為例，不光要跟自己銀行內(nèi)部的業(yè)務(wù)去打交道球订，還要和央行或其他的一些銀行的系統(tǒng)做對接后裸。
補充：保險行業(yè)也是一樣，一個保險核心系統(tǒng)冒滩，可能要對接不同渠道方的系統(tǒng)微驶、理賠系統(tǒng)、收付費系統(tǒng)、監(jiān)管系統(tǒng)等等因苹。
第三點是關(guān)于測試數(shù)據(jù)
銀行和保險數(shù)據(jù)鏈路非常長苟耻，在測試的過程中測試數(shù)據(jù)是非常難創(chuàng)建和管理的，因為數(shù)據(jù)不僅涉及到本行的業(yè)務(wù)還要對接央行系統(tǒng)以及其他銀行系統(tǒng)扶檐，所以很難在短時間內(nèi)制造出符合各個不同系統(tǒng)要求的合法數(shù)據(jù)凶杖。
電商行業(yè)相較于金融業(yè)，業(yè)務(wù)復(fù)雜性沒有那么高款筑，測試造數(shù)比較管理智蝠。電商行業(yè)更注重用戶體驗，是以用戶為中心和驅(qū)動力奈梳。
03 測試架構(gòu)師的工作職責(zé)和內(nèi)容是什么杈湾？測試架構(gòu)師等于測試經(jīng)理嗎？
測試經(jīng)理工作中也需要技術(shù)基礎(chǔ)颈嚼，但是更多的是管理的能力毛秘。
一個測試團隊中的測試經(jīng)理，要制定測試計劃阻课，推動測試計劃執(zhí)行叫挟，還有包括活動反饋收集和測試人員管理等。
而測試架構(gòu)主要是技術(shù)向限煞。測試架構(gòu)師需要多站在企業(yè)的角度來考慮問題抹恳，比如說公司可能在面臨測試轉(zhuǎn)型，怎樣提升測試團隊工作效率署驻？解決測試領(lǐng)域的痛點奋献？這時候就需要測試架構(gòu)師利用自己的技術(shù)經(jīng)驗，設(shè)計合適的測試框架以及效能工具旺上，引導(dǎo)和幫助測試團隊瓶蚂，建設(shè)質(zhì)量內(nèi)建體系等。
總結(jié)一下宣吱，測試經(jīng)理偏管理窃这，測試架構(gòu)師偏技術(shù)。
補充：在小公司征候，或者小型測試團隊中杭攻，確實也存在測試經(jīng)理負責(zé)測試架構(gòu)的情況。但是對于測試人員多的大型測試團隊疤坝，管理和技術(shù)領(lǐng)域劃分清晰兆解，測試經(jīng)理和測試架構(gòu)師的不同職責(zé)就更明顯。
04 站在測試管理和測試技術(shù)的分岔路口，如何選擇？
在自己的職業(yè)發(fā)展中衣撬，這個問題也困擾過我一段時間乖订。剛開始做了一段時間測試管理后，因為很多的精力都投入在團隊管理上具练，技術(shù)這一塊就被落下了。當(dāng)時就想甜无，我到底是走管理還是走技術(shù)扛点？最終我給自己的答案是：能夠在公司需要做管理的時候，去做管理岂丘；需要我們?nèi)プ黾夹g(shù)的時候去做技術(shù)陵究，這樣是最好的一個平衡。
我本身其實比較喜歡技術(shù)方面的工作奥帘，現(xiàn)在做測試管理的過程中我還會堅持寫代碼铜邮，平時也會去看Spring、Spring Boot寨蹋、Spring Cloud一些框架的源碼松蒜，提升自己的編碼能力。我覺得作為測試已旧、作為一個技術(shù)人員秸苗，在任何時候都不要落下自己的技術(shù)能力。如果丟了自己的技術(shù)去做管理运褪，有一天你可能會后悔惊楼。
另一方面，（職場上）到達一定位置的時候秸讹，資深和專家崗位本身會有管理的屬性在檀咙，管理和技術(shù)并不是完全分裂開的。
比如資深測試工程師不免也要帶人一起做事璃诀，那么就需要”管理“團隊中的成員弧可。
總結(jié)下來，我比較認(rèn)可技術(shù)為主文虏，管理為輔的策略侣诺。
05 自動化測試平臺建設(shè)經(jīng)驗分享
在自動化的道路上，我自己曾經(jīng)也走過很多彎路氧秘。最早期從使用開源工具年鸳，進行自動化測試。后來就發(fā)現(xiàn)這些開源的工具或者平臺丸相，無法滿足實際使用的要求搔确，就走到自主研發(fā)這條路上。
開始用Python、Java做了一段時間后發(fā)現(xiàn)跟自己自己的設(shè)想還是不一樣膳算。那段時間一度懷疑自動化是不是真的能解決問題∽叮現(xiàn)在回過頭來發(fā)現(xiàn)其實是當(dāng)時只是解決了表面問題，沒有解決自動化難題的本質(zhì)問題涕蜂。
在自動化測試平臺建設(shè)的時候我們要考慮是為了解決什么問題华匾、目的是什么，以及如何真正實現(xiàn)測試提效机隙、研發(fā)質(zhì)量度量蜘拉，不能讓自己的自動化測試平臺變成一個發(fā)現(xiàn)不了問題的花架子。
我自己總結(jié)的關(guān)于高效自動化平臺的標(biāo)準(zhǔn)有以下三點：
第一點：測試提效有鹿。想象一下旭旭，當(dāng)你的測試用例有一千條一萬條的時候，維護成本是非常大的葱跋；如果能夠通過自動化測試技術(shù)創(chuàng)新持寄，大大降低自動化維護、投入成本和執(zhí)行用例的時間等娱俺，那么這就是一個很有價值的實踐也解決了自動化的疼點稍味。
第二點：質(zhì)量保障，研發(fā)團隊認(rèn)可矢否。在運行完自動化之后能發(fā)現(xiàn)bug仲闽，并且發(fā)現(xiàn)bug的準(zhǔn)確率高（90%及以上），能夠?qū)崿F(xiàn)對研發(fā)質(zhì)量的度量僵朗。在DevOps流程中測試自動化能夠融入DevOps平臺赖欣，做研發(fā)質(zhì)量的卡點。
第三點：是企業(yè)級可復(fù)用的平臺验庙。一些大型企業(yè)中可能有很多團隊顶吮，按照以往的模式，可能每個團隊都有自己的自動化框架或者工具——這種模式對企業(yè)來說粪薛，成本是非常高的悴了。如果說你的自動化框架在企業(yè)內(nèi)部是可復(fù)用的平臺，每個團隊都能使用违寿，也就是我們常說的“測試中臺”概念湃交，就能夠幫忙企業(yè)實現(xiàn)降本提效。
06 如何看待”去測試化“藤巢？
去測試化搞莺，并不是說不需要測試，而是對測試人員的技能要求更高了掂咒。
不會寫代碼才沧，只會手工點點點的功能測試應(yīng)該行不通了迈喉。在未來的話，我覺得技術(shù)是基礎(chǔ)温圆，我們測試人員要有研發(fā)60%~70%的編碼能力挨摸；再加上我們做為測試獨有的測試方法和測試?yán)砟睿瑥牟煌木S度進行提升質(zhì)量和效能的工作岁歉。
我們要不斷地提升自己的核心競爭力得运，不被去測試化。
Future 今年的規(guī)劃
今年可能會嘗試做一些開源的工具刨裆，另一方面可能會寫一本書澈圈。寫書這件事，其實去年就已經(jīng)開始規(guī)劃了帆啃，但因為工作太忙，沒有堅持下去窍帝。今年的話努潘，會把這兩件事做好。這本書也是自己的處女作坤学，書的內(nèi)容是偏技術(shù)方向疯坤，關(guān)于測試技術(shù)和實踐經(jīng)驗的分享。
