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