**
如果說範圍核實用來驗證「對」的事情，質量測試主要工作就是「糾錯」，盡可能的使用極端測試用例驗證產品是否穩健。理論上試錯的事情應該主要由測試部門完成，pm接收的時候只需要抽樣就可以了。因為質量測試需要三樣條件做為支撐，專業技術能力、豐富經驗和大量時間，這三樣產品人員往往都不具備，所以即便進行質量測試，也不過是範圍核實的加強版而已。
舉個例子：假設報名表裡有個功能，需要根據使用者ip判斷所屬城市，然後替使用者自動選擇乙個預設城市。這個功能的測試很難通過手動完成，需要測試人員編寫測試指令碼，隨機抽1000個已知ip位址，根據開發部開放的介面，讀取這1000個ip的城市id返回值，並判斷正確率。如果這個功能讓產品人員測試，限制非常多。通常的做法也就是qq群裡面喊一嗓子，請各地的朋友幫忙看一下而已。
前面說了這麼多不合適，不過由於一些公司測試方面的缺失，pm還是需要承擔更多的測試工作。有關測試方面工作需要閱讀相關專業書籍，這裡只能很簡單的介紹一下自認為重要的兩點。
1.合理編寫測試用例。
測試前的乙個重要準備工作，就是編寫測試用例。測試用例編寫的好壞依靠個人經驗和公司的歷史積累。用例格式類似下表，要把能想到的選擇和預期結果都寫入，不僅要包含正確資料，更多的是要包含邊界資料和錯誤資料。具體的設計測試用例方法可以檢視專業書籍，有等價類劃分法、邊界值分析法、錯誤推測法、因果圖法等等，不贅述。為乙個功能寫出三五千條測試用例是件很普遍的事情，所以要求一定要書面化積累，這樣下次遇到同樣需求可以拿來參考（不是直接拿來用哦！）。
編號 標題 操作 預期結果
1 使用者名稱對話方塊 輸入4個中文漢字 焦點離開對話方塊後，提示輸入正確
2 使用者名稱對話方塊 輸入1個中文漢字 焦點離開對話方塊後，提示錯誤提示
3 使用者名稱對話方塊 輸入5個中文漢字 焦點離開對話方塊後，提示錯誤提示
2 使用者名稱對話方塊 輸入純英文使用者名稱 焦點離開對話方塊後，提示錯誤資訊
3 使用者名稱對話方塊 輸入中文夾雜英文 焦點離開對話方塊後，提示錯誤資訊
4 .... .... ....
2.分級報錯。
a：系統錯誤（頁面無法開啟，系統報錯提示，死迴圈）
b：功能性錯誤（鏈結失效，非預期結果）
c：一般錯誤（錯字、錯圖）
d:使用者體驗（頁面變形，錯行，頁面訪問速度，改進性意見）
e：壓力測試
如上表所示，一般的頁面bug都歸為上面這五類。e類錯誤不考慮（沒條件測），其他錯誤的危害程度按a-d依次排序。一般pm新人會犯的錯誤是將驗收查到的所有問題及疑似問題統統上報，雖然這樣做沒什麼大錯，但是有三個麻煩的地方：1.看到bug清單一長串，自己先會被嚇到。2.會給開發人員排查問題帶來很大困擾；3.會被鄙視為「不專業」（其實本來就不是專業的測試嘛^_^）。
正確做法是將手上的bug列出清單後，先分級。建議類放一邊，錯誤類打上abcd標籤。ab類錯誤先上報，這個級別解決差不多了，再將新查出來的ab及累積的c類問題上報，等再解決差不多了，最後將所有剩餘問題、建議一次性上報。
產品設計 關於流程
昨天leader把我們叫到會議室，討論了下關於流程的問題。我們小組組建時間不長，人手也不多，平時忙起來可能會產生顧著不顧那的情況，碰到沒有顧及到的地方，難免會出現問題，出問題並不可怕，及時改正和承擔相應的責任就可以了，但就怕問題重複性的出現，這就有問題了，所有規範流程成了乙個必不可少的制度。專案分兩...
產品設計體會（九） 關於學習
這兩天在準備pd交流會的分享，目的是把前段時間去上海培訓 產品需求管理 的體會和大家說說。不妨順便說一下自己對培訓 分享這種學習活動的體會。用 武俠 裡的一些概念來比喻很有感覺，一直覺得培訓和分享在表面上交流的好比是招式，在短短的幾天甚至幾個小時內，最吸引人的往往是一些容易掌握 用來嚇 唬人很好的 ...
產品設計問題
如何把乙個實體物件進行輸出,利用mvc的原理.可以把實體物件 模型物件,如何進行轉化,我想到了乙個xml的方法 假設產品類 class product pno pricedescs array object 產品 集 desc productdesc 產品描述 class productpriced...