軟體測試入門篇：工作中經常會遇到的十個問題

第一問： 測試團隊的工作也依賴於業務和開發，如何有效提高與業務團隊和開發團隊的合作默契？

答1

測試團隊與開發團隊和業務團隊的溝通，都是難點，這個難點，一方面是溝通機制的問題。但是更為重要的是各自的知識積累，比如測試人員的業務知識積累，以及對軟體系統的全面瞭解。

因此，對於複雜的產品，比如業務性很強的軟體，比如複雜通訊系統，複雜的金融系統，測試工程師的測試效果，可能三分靠測試技術，氣七分要考對測試金融、通訊具體業務的瞭解和掌握程度。測試人員的職業壽命比較長，與這一點也是密切相關。對於複雜的業務來說，培養一個測試專家不難，難事培養一個對業務全面瞭解的業務專家是很難的。這也是測試工程師職業競爭力的一個積累點所在。

除此之外，測試工程師最好能夠學一點心理學的知識，測試工程師和碼農還不完全一樣，如果學習一點心理學的知識，對工作更有幫助。目前，有關心理學的課程，知識都很多。最簡單的，買一本戴爾卡耐基的《人性的弱點》反覆看一看，會對工作有幫助的。還有幾本書，也可以作為參考比如《狂熱分子》，《烏合之眾》，對人的心理和人性理解的深入一些，工作開展更為容易一些。

答2

測試團隊和開發團隊的關係時上下游關係，測試的程序依賴於開發的進度，測試的結果需要開發承認。需要注意的是雙方的關係要融洽。開發和測試容易形成敵對關係，這需要開發和測試的主管要具備協調對立關係的能力和緩解對立情緒辦法。

第二問：團隊如何考慮平衡質量和速度的測試策略？

答1

測試本身就是在成本和質量之間找的平衡點，如果投入的財力和工作量是有限的。那麼必須對被測試物件的功能點劃分優先順序，優先順序高的優先測試。

另外，一個要考慮產品遺留bug會產生後果的嚴重程度。如果是公司內部IT系統，功能對業務影響不大，又著急上線，那麼跑完正常功能和正常流程，以及少量異常流程，基本就可以上西線了。如果，是銀行、電信這類系統，沒有辦法避免投入。目前，中國的銀行在IT方面的投入，可能是世界之最，超級就，超級的投入，產生超級的應用和質量。大家可以對比國外的金融IT，基本上都不是中國的對手。如果是產品，或者系統不斷迭代升級的軟體系統，那麼就需要考慮自動化了。一般來說，同一產品，五輪以上的手工測試，就可以考慮自動化了。這是提升效率的好辦法。

不同的專案，對軟體的質量要求是不一樣的，公司的領導層必須對產品質量的要求要有理性客觀的定位，否則，會出現測試資源投入不足，造成既要馬兒跑，又不讓馬兒吃草的局面。所以說，測試工作的定調，首先是研發的老大要做好的。如果一旦做不好，可能工作開展就比較麻煩。我對這個問題，就闡述到此。

答2

移動app舉例解答下這個問題，app要求全質量（功能、效能、易用性、安全和相容性，一樣不少），考慮到釋出要求儘量做到分層測試，第一種分層考慮是先考慮介面功能、UI功能和效能測試，再考慮相容性和安全測試。

第二種分層考慮研發階段、系統測試階段和上線迴歸三個階段任務分層，研發相當於功能整合測試，儘量做到介面功能自動化測試，用例和自動化保持在基本覆蓋用例集，內部測試團隊獨立承擔；在系統測試和上線驗收階段，可考慮眾測、灰度釋出使用者中組織並承擔測試。

對程式碼質量檢查和持續整合活動是自動化測試活動、介面測試是自動化測試活動、UI介面功能也是自動化活動，迭代最多還是版本持續整合這個環節。

系統測試和驗收測試階段，倘若用例質量高，建立眾測能力也是不錯的選擇發，用例覆蓋有保障，執行層面參與的人多了，手工比自動化測試效率更高。

第三問：敏捷模式下，如何平衡快速釋出和客戶對質量的期望？

敏捷指的是內部迭代的敏捷，不是魯莽的把一個沒經過充分測試的產品直接推給客戶。客戶對質量的期望需要在銷售階段就做好引導，測試人員在後期面對客戶去平衡客戶的期望就太晚了。

第四問： 團隊的人測不出問題 ，上線後問題又很多，主管只能抽測一些重點的 ，這種情況怎麼解決？

答1

團隊的人員測試不出來問題，這是很嚴重的。那麼，首先要找到原因所在。既然主管，做了一些重新測試，如果主管發現了問題，針對這些問題，要與測試工程師一起分析為什麼測試工程師沒有發現問題。也就是做缺陷分析，缺陷分析是提升測試人員測試效果很好的手段。

答2

如果系統的使用環境很複雜的話，這種情況就不是自己能避免的了。我最近遇到一個客戶，他們內部測試團隊能力已經比較強了，但是系統部署到客戶那裡依然會出現各種問題，歸根到底是因為客戶是多樣的，而自己的測試環境變化是有限的。 解決方案只能是自家的測試隊伍努力提高測試用例的完備性，利用其它力量在不同的環境下做充分驗證。

答3

我覺得測試測不出問題，工作量評估、工作環境評估不準也是原因。

應需充分調研客戶的具體需求，實際運作環境，然後做測試工作量的準確評估，提出合理的人力、測試時長訴求。如果人力、時間給足了，Case也覆蓋到了，還有遺漏，就是嚴重的工作態度問題，屬於測試遺漏。我們的做法是所有跟用例無關的缺陷，後續都必須維護回測試用例裡，不求用例百分百覆蓋，但應儘可能趨近於百分百。

第五問 上海—歸雲劍客：如何提高測試團隊學習業務知識的速度？

答1

如果業務知識是行業知識，最好透過一些資格認證，比如做證券軟體，測試工程師可以去透過考證券從業資格考試，提升自己對證券行業的理解，其他行業也是一樣道理。

答2

根據我的經驗，提高學習業務知識的速度最有效的就是讓新手迴歸缺陷。缺陷裡有完整的執行步驟，有利於快速的掌握如何作業系統，並且預期結果和實際結果的對比，非常有利於新人梳理業務流中的測試項和觀察點。

答3

找一些行業顧問集中培訓幾天，並且可以長期集中答疑。

第六問： 如何快速打造組建一個測試團隊？

說到底，還是與預算有關係。預算允許，招聘有經驗的關鍵人員，搭班子初期，要有好人。

在面試的時候，可以做一些邏輯測試和職業性格測試。尤其職業性格測試對後續組建團隊很有幫助。

博為峰開發了一套職業性格測試系統，有些人就是不適合做技術工作，或者不是做與人協調的技術工作，這種人，在搭班子初期不適合進來。比如，我們曾經招聘過樂群性是0分的人，後來透過評測才發現他的問題如此嚴重，這類人很難把工作做好。還有獨立性，穩定性，這都是可以透過測試發現問題的。

市面上比較多的是，mtbi測試。大家可以找來看看，尤其測試經理。建議測試經理和人事針對這個問題做些討論。

（補充一句，後續，博為峰會發布免費的職業性格測試系統，大家如果有興趣可以自己測試一下，看看是否對自己有價值，瞭解自己，知己知彼，才能有所作為。）

第七問： 關於面向業務的測試，自動化測試該如何實施？

自動化方面的問題，我覺得先要確定是否有必要做，再考慮怎麼做。大部分公司的自動化測試實踐是無效的。 先從成本角度和技術能力兩個方面考慮是否要做。

如果上述兩個問題經過認真評估，還是決定做自動化，可以按照三個步驟來實施：1。選擇使用哪種自動化測試解決方案。2。梳理需要自動化測試用例。3。隨著版本的變更，維護自動化測試程式碼。

追問（如何讓領導覺得測試團隊有成長。通常測試團隊的能力提升是很難透過圖示或數字表現出來的） 答：測試團隊能力的成長，可以在產品質量上得到體現，經過你們測試的產品質量逐步提升了，這就是團隊能力提升的一個有力的表現。 另外，測試團隊要逐步建立自己的質量保證體系，在規範、標準方面逐步積累，讓領導透過過程輸出文件看到你們在提升。

第八問：

①公司產品為智慧硬體（可定義為新型製造業），測試團隊負責範圍除了軟體測試，還包含傳統的硬體測試；

想聽下貴司專家對此類企業，測試經理/總監和品質經理/總監的關聯及區別

要看硬體的規模，一般這類產品分為軟體測試團隊、純硬體測試團隊，系統整合測試團隊這三類。如果智慧硬體的規模比較小，可能只有純硬體測試團隊和軟硬體系統整合測試的團隊即可。

②測試人員主動學習能力和積極性普遍弱於開發人員，會存在被開發同化現象（比如BUG的解讀被開發牽著走）；

如何快速有效提升測試人員對產品理解及專業技能？

答1

我覺得認為測試比開發弱的觀念首先是不對的，這種觀念如果存在，很難有自己獨立的思想，很難來保證質量。我招聘人員的時候會考量，一個測試人員如果連挑戰開發的勇氣都沒有的測試，我們是不需要的。為什麼弱，弱在那裡，是業務弱，還是技術弱？每一樣事情做到極致了，就沒有弱的說法。

答2

測試人員在具體程式設計方面可能不如開發，但是這只是個熟能生巧的工作。在業務整體性的理解方面，測試一定會強於單個的開發人員。

答3

這個問題我覺得是團隊定位除了問題，測試把自己定位成開發的助手了。這需要測試團隊的老大從思想上給手下人明確自己的的職責，並且要提高業務水平。說白了就是對自己不自信，被人一懟就慫了。

3）性格外向型測試人員，跨部門溝通效果好，但有些容易浮於表面；內向型的測試更容易發現潛藏較深BUG（微軟曾做過此類研究）；測試團隊搭建，性別、性格、開發/測試比例等是否存在“黃金比例”？

這可能是個偽命題。內向外向只是分析問題的一個維度，這可能不是決定性的。決定性的原因是測試人員是否有獨立工作的能力，有些人外向，是因為沒有獨立工作能力，凡事都需要協作。以及測試人員的邏輯分析能力，專研精神。

這個看情況的，不能一棍子打死一定是那種性格好，內向型中有內斂性的，也有小白兔性的，有外弱內強性的。面試的時候時間不夠，如果不擅於溝通，不擅長溝通，肯定是要吃虧的。

4）有低成本且簡單好用的相關管理工具推薦嗎？

個人摸索了多款專案管理工具沒找到太好解決方案，目前採用免費版JIRA+禪道（對使用還是偏繁瑣）舊版JIRA BUG管理很不錯，但無法追溯管理測試版本；禪道可以管理專案版本（包括附件），但BUG管理沒JIRA直觀；騰訊免費開放的TAPD版本迭代不具備附件功能（略遺憾）

答1

jira所在的公司是澳大利亞的一家軟體公司，規模很大，全套的敏捷開發工具都涵蓋了。在他的工具鏈中，應該有相關的支撐。atlassian的產品功能強大，就是重了。但是擴充套件性很好。

答2

我們一直用禪道，感覺開源，輕量，禪道可以：產品——專案——用例——缺陷，還有豐富的報告圖表。

5）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系統。