引言：寫這個帖子也是近段時間一些專案的測試經理普片向我提及的乙個問題。即：面對幾千個測試用例，普通開發人員及專案經理如何評審他們，雖然我們已經構建了這樣乙個體系活動。但大部分的開發人員仍然不知道如何評審它們，即便是我們自己測試成員也是同樣。寫這個帖子目的，希望拋磚引玉談一些我的理解和我們採用的方法。這裡要感謝架構師jack這段時間交流與指導，因為這些方法來自於一些公共的測試技術。
先從測試方案入手：
一般我們常見的問題是哪些呢？
topic1：測試方案過於複雜，在不了解業務情況下，很難對逐點評審；
topic2：開發人員評審時無法聚焦焦點，測試用例太多，測試方案也太多；
topic3：評審方案往往耗費較多的人力與時間，需要太多人參與，且評審效果很不理想；
topic4：測試方案寫作視測試人員經驗和能力而定，寫作方案時的思路及策略無法找到依據；
topic5：測試用例的覆蓋如何判斷？用例命中率只能在執行後期統計及完善；
這些也許是我們通常評審方案是遇到主要問題，看看我們如何來破解他們，應該如何引導開發人員的視角在他們必須關注且能發揮極大作用的地方。
這裡，丟擲來乙個主題：何為開發人員的視角。
何為開發人員視角呢？他們在關注什麼？通常意義上來說，是微觀的部分。開發人員關注的基於需求的實現方案、模組之間的介面、傳輸的資料流，判定路徑等。
而測試人員的視角呢？他們在關注什麼？通常意義上來說，是巨集觀的部分。測試人員關注的基於需求的業務資料流向、多維互動、質量屬性、異常等。
不同的視角，造就了他們對同乙個事物不同的評判標準。
乙個好的評審，應該著重去引導兩方的思維，它們存在交集，也存在互斥的部分。而這些灰色地帶和未澄清的部分，正是容易出錯的部分。
分析完這些，我們可以給這個問題丟擲一些解決方案。
topic1：測試方案過於複雜，在不了解業務情況下，很難對逐點評審；
解決方案1：測試方案分類編寫，首先是基於物件導向分析，選擇不同的模板分開描述他們。如：功能測試、效能測試、協議測試、質量屬性、安全測試等等。
topic2：開發人員評審時無法聚焦焦點，測試用例太多，測試方案也太多；
解決方案2：測試方案不僅僅是乙個文字方案，更重要的是圖形化的表達，統一建模。 序列圖、狀態機、user story等技術，這樣的方案將更佳一讀，儘量減少文字描述。
解決方案3：測試方案需要按照結構化方式編寫，思路方面建議採用腦圖，這樣在評審時。開發及外部專家更容易聚焦到中心上。結構化的思路還包括抽象為opp的結構，如對ftp物件分析，應該從哪幾個方面入手。基於rbt技術，我們可以構建一種checklist公共測試框架，來解決這個問題。
topic3：評審方案往往耗費較多的人力與時間，需要太多人參與，且評審效果很不理想；
解決方案4：也許敏捷開發模型能很好的解決這個問題？xp方式，似乎能引入到這裡，但這樣評審必須依靠強大模板或者能力較強的tae介入。
topic4：測試用例的覆蓋如何判斷？用例命中率只能在執行後期統計及完善麼；
解決方案5：利用白盒測試技術來解決這類問題，通過se將需要評審測試用例。按照斷點方式來執行，以此收集對測試用例的覆蓋。加入新的路徑覆蓋，這是乙個互相牽引的過程。這個過程將使得研發能考慮到更多異常，而測試將通過此類方式彌補更多測試用例；
解決方案6：基於rbt思想，歷史問題及故障注入技術將幫助我們完善測試覆蓋。專案團隊總是犯著同樣的錯誤，同時他們有習慣性的思考模式。
解決方案7：基於風險測試技術，讓開發評審時聚焦最關鍵的方案部分。並將每個測試物件的測試方案、測試策略羅列出來，使得我們的開發人員和專案不在抓瞎，不在茫然。
專案經理眼中優秀開發人員的標準
專案經理眼中優秀開發人員的標準 楊爭 作為專案經理，我希望我們專案的開發人員做到以下幾點 1 主動性 在專案中積極思考，主動提出自己的意見和看法。遇到問題主動尋求相關人員協助，主動溝通。2 bug修復及時 專案經理在專案計畫中通常會安排了bug的修復時間,以及在此基礎上的後續工作 比如整合測試 回歸...
開發人員轉行做產品經理 1
很多從事開發的小夥伴，工作幾年後，都會有這樣的疑惑，未來的職業之路應該如何繼續。其實開發人員有自己的優勢，那就是了解熟悉技術，從事it行業，了解一些技術總也是好的。和開人員溝通有一定的優勢。但是開發人員也有自己的劣勢，就是溝通起來不是太好。一下是轉其他人的 文章 開發人員到一定階段以後就要尋求轉型，...
產品經理與開發人員的矛盾
1 是不是只要沒有技術上的實現問題，開發者就不應該對產品經理提出質疑？2 需求文件 功能文件 最新而最全的原型設計文件，這些要求過時了嗎？3 產品經理高階建議。軟體工程領域，本著分工合作高效進行的管理方式，每個人只要做好自己的分內事就行。當產品經理召集開發人員進行各種評審會的時候，其實是想讓開發人員...