51Testing測試經(jīng)理人Q群活動(dòng)回顧| 如何提高測試團隊的效率？三位大咖給你齊支招
11月23日下午，我們舉辦了一場(chǎng)以“如何提高測試團隊效率”為主題的QQ群互動(dòng)問(wèn)答活動(dòng)。2個(gè)小時(shí)的活動(dòng)，吸引了眾多51Testing測試經(jīng)理人QQ群用戶(hù)的積極參與和熱情圍觀(guān)。
為了更好地幫助大家解決測試團隊在日常工作中遇到的各種難題?；顒?dòng)當天，我們特邀三位嘉賓來(lái)到群里，參與此次活動(dòng)，為大家答疑解惑。
王威：
51Testing創(chuàng )始人之一，具備多年軟件開(kāi)發(fā)經(jīng)驗和軟件測試工作經(jīng)驗。曾供職于華為技術(shù)有限公司，
針對大型復雜軟件產(chǎn)品的開(kāi)發(fā)和測試，積累了深厚的開(kāi)發(fā)、測試和管理工作經(jīng)驗；從事多種軟件測試工具的開(kāi)發(fā)工作，對產(chǎn)品測試的方法和管理流程有深刻的認識。
宋光照：
博為峰技術(shù)總監和指導教練。先后參與了終端技術(shù)論壇WG3、WG7工作和測評聯(lián)盟技標委工作，對移動(dòng)互聯(lián)、互通、互操作的業(yè)務(wù)規范和測試規范有深刻的認識，尤其在移動(dòng)測試與分析、數據挖掘與質(zhì)量保證方法論的學(xué)習與探索領(lǐng)域頗有建樹(shù)。
陳文廣：
博為峰51testing軟件測試總監。具有15年軟件測試實(shí)施和團隊管理經(jīng)驗，熟悉軟件測試全流程。能夠根據產(chǎn)品特性，選擇測試技術(shù)，制定測試策略?？梢愿鶕F隊情況，對研發(fā)和測試流程進(jìn)行優(yōu)化。曾擔任oracle測試經(jīng)理、上海途創(chuàng )軟件測試總監等職務(wù)，精通自動(dòng)化測試、性能測試、接口測試等。
三位重量級大咖在QQ群里與眾多用戶(hù)進(jìn)行了深入互動(dòng)，并就大家關(guān)心的問(wèn)題，進(jìn)行了一一解答。
為了讓錯過(guò)此次活動(dòng)的小伙伴們不再錯過(guò)精彩的活動(dòng)內容，我們特意精選了10個(gè)非常有價(jià)值的問(wèn)答干貨，供大家學(xué)習與探討。
第一問(wèn)： 測試團隊的工作也依賴(lài)于業(yè)務(wù)和開(kāi)發(fā)，如何有效提高與業(yè)務(wù)團隊和開(kāi)發(fā)團隊的合作默契？
答1
測試團隊與開(kāi)發(fā)團隊和業(yè)務(wù)團隊的溝通，都是難點(diǎn)，這個(gè)難點(diǎn)，一方面是溝通機制的問(wèn)題。但是更為重要的是各自的知識積累，比如測試人員的業(yè)務(wù)知識積累，以及對軟件系統的全面了解。
因此，對于復雜的產(chǎn)品，比如業(yè)務(wù)性很強的軟件，比如復雜通訊系統，復雜的金融系統，測試工程師的測試效果，可能三分靠測試技術(shù)，氣七分要考對測試金融、通訊具體業(yè)務(wù)的了解和掌握程度。測試人員的職業(yè)壽命比較長(cháng)，與這一點(diǎn)也是密切相關(guān)。對于復雜的業(yè)務(wù)來(lái)說(shuō)，培養一個(gè)測試專(zhuān)家不難，培養一個(gè)對業(yè)務(wù)全面了解的業(yè)務(wù)專(zhuān)家是很難的。這也是測試工程師職業(yè)競爭力的一個(gè)積累點(diǎn)所在。
除此之外，測試工程師最好能夠學(xué)一點(diǎn)心理學(xué)的知識，測試工程師和碼農還不完全一樣，如果學(xué)習一點(diǎn)心理學(xué)的知識，對工作更有幫助。目前，有關(guān)心理學(xué)的課程，知識都很多。最簡(jiǎn)單的，買(mǎi)一本戴爾卡耐基的《人性的弱點(diǎn)》反復看一看，會(huì )對工作有幫助的。還有幾本書(shū)，也可以作為參考，比如《狂熱分子》、《烏合之眾》，對人的心理和人性理解的深入一些，工作開(kāi)展更為容易一些。
答2
測試團隊和開(kāi)發(fā)團隊的關(guān)系時(shí)上下游關(guān)系，測試的進(jìn)程依賴(lài)于開(kāi)發(fā)的進(jìn)度，測試的結果需要開(kāi)發(fā)承認。需要注意的是雙方的關(guān)系要融洽。開(kāi)發(fā)和測試容易形成敵對關(guān)系，這需要開(kāi)發(fā)和測試的主管要具備協(xié)調對立關(guān)系的能力和緩解對立情緒辦法。
第二問(wèn)：團隊如何考慮平衡質(zhì)量和速度的測試策略？
答1：
測試本身就是在成本和質(zhì)量之間找的平衡點(diǎn)，如果投入的財力和工作量是有限的。那么必須對被測試對象的功能點(diǎn)劃分優(yōu)先級，優(yōu)先級高的優(yōu)先測試。
另外，一個(gè)要考慮產(chǎn)品遺留bug會(huì )產(chǎn)生后果的嚴重程度。如果是公司內部IT系統，功能對業(yè)務(wù)影響不大，又著(zhù)急上線(xiàn)，那么跑完正常功能和正常流程，以及少量異常流程，基本就可以上線(xiàn)了。如果是銀行、電信這類(lèi)系統，沒(méi)有辦法避免投入。目前，中國的銀行在IT方面的投入，可能是世界之最，超級的投入，產(chǎn)生超級的應用和質(zhì)量。大家可以對比國外的金融IT，基本上都不是中國的對手。如果是產(chǎn)品，或者系統不斷迭代升級的軟件系統，那么就需要考慮自動(dòng)化了。一般來(lái)說(shuō)，同一產(chǎn)品，五輪以上的手工測試，就可以考慮自動(dòng)化了。這是提升效率的好辦法。
不同的項目，對軟件的質(zhì)量要求是不一樣的，公司的領(lǐng)導層必須對產(chǎn)品質(zhì)量的要求要有理性客觀(guān)的定位。否則，會(huì )出現測試資源投入不足，造成既要馬兒跑，又不讓馬兒吃草的局面。所以說(shuō)，測試工作的定調，首先是研發(fā)的老大要做好的。如果一旦做不好，可能工作開(kāi)展就比較麻煩。我對這個(gè)問(wèn)題，就闡述到此。
答2：
移動(dòng)app舉例解答下這個(gè)問(wèn)題，app要求全質(zhì)量（功能、性能、易用性、安全和兼容性，一樣不少），考慮到發(fā)布要求盡量做到分層測試，第一種分層考慮是先考慮接口功能、UI功能和性能測試，再考慮兼容性和安全測試。第二種分層考慮研發(fā)階段、系統測試階段和上線(xiàn)回歸三個(gè)階段任務(wù)分層，研發(fā)相當于功能集成測試，盡量做到接口功能自動(dòng)化測試，用例和自動(dòng)化保持在基本覆蓋用例集，內部測試團隊獨立承擔；在系統測試和上線(xiàn)驗收階段，可考慮眾測、灰度發(fā)布用戶(hù)中組織并承擔測試。
對代碼質(zhì)量檢查和持續集成活動(dòng)是自動(dòng)化測試活動(dòng)、接口測試是自動(dòng)化測試活動(dòng)、UI界面功能也是自動(dòng)化活動(dòng)，迭代最多還是版本持續集成這個(gè)環(huán)節。
系統測試和驗收測試階段，倘若用例質(zhì)量高，建立眾測能力也是不錯的選擇，用例覆蓋有保障，執行層面參與的人多了，手工比自動(dòng)化測試效率更高。
第三問(wèn)：有低成本且簡(jiǎn)單好用的相關(guān)管理工具推薦嗎？
答1：
jira所在的公司是澳大利亞的一家軟件公司，規模很大，全套的敏捷開(kāi)發(fā)工具都涵蓋了。在他的工具鏈中，應該有相關(guān)的支撐。atlassian的產(chǎn)品功能強大，就是重了。但是擴展性很好。
答2：
我們一直用禪道，感覺(jué)開(kāi)源，輕量，禪道可以:產(chǎn)品--項目--用例--缺陷，還有豐富的報告圖表。
第四問(wèn)： 團隊的人測不出問(wèn)題 ，上線(xiàn)后問(wèn)題又很多，主管只能抽測一些重點(diǎn)的 ，這種情況怎么解決？
答1：
團隊的人員測試不出來(lái)問(wèn)題，這是很?chē)乐氐?。那么，首先要找到原因所在。既然主管，做了一些重新測試，如果主管發(fā)現了問(wèn)題，針對這些問(wèn)題，要與測試工程師一起分析為什么測試工程師沒(méi)有發(fā)現問(wèn)題。也就是做缺陷分析，缺陷分析是提升測試人員測試效果很好的手段。
答2：
如果系統的使用環(huán)境很復雜的話(huà)，這種情況就不是自己能避免的了。我最近遇到一個(gè)客戶(hù)，他們內部測試團隊能力已經(jīng)比較強了，但是系統部署到客戶(hù)那里依然會(huì )出現各種問(wèn)題，歸根到底是因為客戶(hù)是多樣的，而自己的測試環(huán)境變化是有限的。
解決方案只能是自家的測試隊伍努力提高測試用例的完備性，利用其它力量在不同的環(huán)境下做充分驗證。
答3：
我覺(jué)得測試測不出問(wèn)題，工作量評估、工作環(huán)境評估不準也是原因。應需充分調研客戶(hù)的具體需求，實(shí)際運作環(huán)境，然后做測試工作量的準確評估，提出合理的人力、測試時(shí)長(cháng)訴求。如果人力、時(shí)間給足了，Case也覆蓋到了，還有遺漏，就是嚴重的工作態(tài)度問(wèn)題，屬于測試遺漏。我們的做法是所有跟用例無(wú)關(guān)的缺陷，后續都必須維護回測試用例里，不求用例百分百覆蓋，但應盡可能趨近于百分百。
第五問(wèn)： 如何提高測試團隊學(xué)習業(yè)務(wù)知識的速度？
答1：
如果業(yè)務(wù)知識是行業(yè)知識，最好通過(guò)一些資格認證，比如做證券軟件，測試工程師可以去通過(guò)考證券從業(yè)資格考試，提升自己對證券行業(yè)的理解，其他行業(yè)也是一樣道理。
答2：
根據我的經(jīng)驗，提高學(xué)習業(yè)務(wù)知識的速度最有效的就是讓新手回歸缺陷。缺陷里有完整的執行步驟，有利于快速的掌握如何操作系統，并且預期結果和實(shí)際結果的對比，非常有利于新人梳理業(yè)務(wù)流中的測試項和觀(guān)察點(diǎn)。
答3：
找一些行業(yè)顧問(wèn)集中培訓幾天，并且可以長(cháng)期集中答疑。
第六問(wèn)： 如何快速打造組建一個(gè)測試團隊？
答：
說(shuō)到底，還是與預算有關(guān)系。預算允許，招聘有經(jīng)驗的關(guān)鍵人員，搭班子初期，要有好人。
在面試的時(shí)候，可以做一些邏輯測試和職業(yè)性格測試。尤其職業(yè)性格測試對后續組建團隊很有幫助。博為峰開(kāi)發(fā)了一套職業(yè)性格測試系統，有些人就是不適合做技術(shù)工作，或者不是做與人協(xié)調的技術(shù)工作，這種人，在搭班子初期不適合進(jìn)來(lái)。比如，我們曾經(jīng)招聘過(guò)樂(lè )群性是0分的人，后來(lái)通過(guò)評測才發(fā)現他的問(wèn)題如此嚴重，這類(lèi)人很難把工作做好。還有獨立性，穩定性，這都是可以通過(guò)測試發(fā)現問(wèn)題的。市面上比較多的是，mtbi測試。大家可以找來(lái)看看，尤其測試經(jīng)理。建議測試經(jīng)理和人事針對這個(gè)問(wèn)題做些討論。
（補充一句，后續，博為峰會(huì )發(fā)布免費的職業(yè)性格測試系統，大家如果有興趣可以自己測試一下，看看是否對自己有價(jià)值，了解自己，知己知彼，才能有所作為。）
第七問(wèn)： 關(guān)于面向業(yè)務(wù)的測試，自動(dòng)化測試該如何實(shí)施？
答：
自動(dòng)化方面的問(wèn)題，我覺(jué)得先要確定是否有必要做，再考慮怎么做。大部分公司的自動(dòng)化測試實(shí)踐是無(wú)效的。 先從成本角度和技術(shù)能力兩個(gè)方面考慮是否要做。
如果上述兩個(gè)問(wèn)題經(jīng)過(guò)認真評估，還是決定做自動(dòng)化，可以按照三個(gè)步驟來(lái)實(shí)施：1.選擇使用哪種自動(dòng)化測試解決方案。2.梳理需要自動(dòng)化測試用例。3.隨著(zhù)版本的變更，維護自動(dòng)化測試代碼。
第八問(wèn)：
測試人員主動(dòng)學(xué)習能力和積極性普遍弱于開(kāi)發(fā)人員，會(huì )存在被開(kāi)發(fā)同化現象（比如BUG的解讀被開(kāi)發(fā)牽著(zhù)走）；如果快速有效提升測試人員對產(chǎn)品理解及專(zhuān)業(yè)技能？
答1：
我覺(jué)得認為測試比開(kāi)發(fā)弱的觀(guān)念首先是不對的，這種觀(guān)念如果存在，很難有自己獨立的思想，很難來(lái)保證質(zhì)量。我招聘人員的時(shí)候會(huì )考量，一個(gè)測試人員如果連挑戰開(kāi)發(fā)的勇氣都沒(méi)有的測試，我們是不需要的。為什么弱，弱在那里，是業(yè)務(wù)弱，還是技術(shù)弱？每一樣事情做到極致了，就沒(méi)有弱的說(shuō)法。
答2：
測試人員在具體編程方面可能不如開(kāi)發(fā)，但是這只是個(gè)熟能生巧的工作。在業(yè)務(wù)整體性的理解方面，測試一定會(huì )強于單個(gè)的開(kāi)發(fā)人員。
答3：
這個(gè)問(wèn)題我覺(jué)得是團隊定位除了問(wèn)題，測試把自己定位成開(kāi)發(fā)的助手了。這需要測試團隊的老大從思想上給手下人明確自己的的職責，并且要提高業(yè)務(wù)水平。說(shuō)白了就是對自己不自信，被人一懟就慫了。
第九問(wèn)：APP自動(dòng)化測試，嘗試過(guò)python+appium的方式；UI自動(dòng)化實(shí)際產(chǎn)生的價(jià)值效果并不理想；希望能了解更實(shí)用的自動(dòng)化測試技術(shù)（比如接口、性能等）
答1：
關(guān)于A(yíng)PP自動(dòng)化測試，個(gè)人看法是，如果是兼容性測試，借助自動(dòng)化UI測試效率最高。其他的功能自動(dòng)化要看情況了。如果是做系統級接口測試，app的UI所對應的API都要有封裝，這個(gè)需要開(kāi)發(fā)團隊配合。這樣，做完接口測試，還是要跑一邊UI測試的。否則，無(wú)法保證UI的正確性。至于用python調用接口，這個(gè)技術(shù)就太簡(jiǎn)單了。python與其他語(yǔ)言的粘合性比較好，都有相關(guān)的辦法。這類(lèi)資料很多。
答2：
UI和接口哪個(gè)穩定就做哪個(gè)自動(dòng)化，都不穩定就放棄自動(dòng)化。自動(dòng)化大部分時(shí)間都是不成功的，不要強求。
答3：
如果UI變化不是很頻繁，可以考慮。往往和自動(dòng)化效率有點(diǎn)沖突。自動(dòng)化希望快速迭代回歸，快速迭代，UI可能變化頻繁。如果資源不是很多，或者先做重要流程的APP自動(dòng)化。接口的話(huà)，由于現在團隊代碼能力弱，所以采用Jmeter來(lái)做，還順便做接口壓測，jmeter搭積木試的，加業(yè)務(wù)斷言，測試可以把更多精力放在業(yè)務(wù)上。功能的同事也可以很快學(xué)起來(lái)，用起來(lái)，他們也比較喜歡學(xué)。
第十問(wèn)：制定上線(xiàn)的產(chǎn)品發(fā)布的質(zhì)量標準需要考慮哪些維度？ 怎么統計線(xiàn)上遺漏率？
答：
發(fā)布標準，很重要的一個(gè)是標識缺陷的收斂情況。如果不收斂，發(fā)布風(fēng)險太大。當然，是不同維度的bug的收斂程度，不能只看一個(gè)維度，包括功能和性能。一般上線(xiàn)之后遺留bug不是由研發(fā)部門(mén)來(lái)處理了，而是運維或者售后部門(mén)來(lái)收集和記錄，并反饋到研發(fā)。這類(lèi)bug要特別標識，便于集中分析。很多公司，記錄運維階段的bug是有專(zhuān)門(mén)的系統的。有別于我們研發(fā)階段的bug系統。
隨著(zhù)Q&A環(huán)節告一段落，這次精彩的Q群活動(dòng)也就正式圓滿(mǎn)結束了。后續我們還將繼續舉辦類(lèi)似的問(wèn)答互動(dòng)活動(dòng)，期待下次與大家再見(jiàn)噢~
