測試
我們不是看**都是bug，只是活的比較細緻而已
1.功能是否符合需求：符合的定義是等於，多了，少了都是不符合預期
2.凡是影響使用都是問題：環境，資料，功能，體驗，甚至於使用習慣，操作場景
3.功能使用範圍：大眾需要，小眾需求，主要功能，特殊場景，異常情況
4.功能穩定性：使用時間多久，使用者群是否固定
5.資訊安全性
行話：專案中百分之八十的問題出在百分之二十的模組上
所以專案前：
測試可以提前預期**容易出問題，哪些邏輯需要重要關注，也為測試排期提供依據
專案中：
高階bug，問題反覆的及時與開發溝通，明確資訊一致性
需求問題，及時產品，開發一起溝通
沒有阻礙bug，但bug數量較多，及時整體問題，與開發一起梳理問題，有順序，有條理解決，並確定問題解決的deadline
及時跟進bug狀態，開發解決後及時回歸
1.驗證後有問題方便開發再次跟進；
2.測試中驗證bug，繼續測試可以作為bug回歸，節省時間；
3.避免bug積累，大量bug驗證容易遺漏回歸點；
4.將bug驗證放在功能回歸中，容易遺漏測試點，整體回歸應該在穩定環境(沒有問題，**不在改動)執行
專案後：
bug分類整理
開發角度：檢視bug產生原因--自測問題，環境問題，資料問題，**問題，其它
測試角度：檢視bug功能型別--文案問題，前端問題，後端問題，使用問題，體驗問題，場景問題
檢視bug產生型別--新功能產生，優化產生，修復問題引出，環境問題，特殊資料導致
產品角度：檢視bug影響--測試環境，線上環境，問題範圍，評估影響，調整需求
軟體專案文件及其必要性
在許多軟體專案中，開發人員從商討結構的會議開始，然後開始書寫 不論專案的規模如何小，專案經理聰明的做法都是 立刻正式生成若干文件作為自己的資料基礎，哪怕這些迷你文件非常簡單。接著，他會和其他管理人員一樣要求各種文件。做什麼 目標。定義了待完成的目標 迫切需要的資源 約束和優先順序。做什麼 產品技術說...
專案執行 專案中問題
多部門，多人員參與 1.確定專案總負責人，及時協調各方任務和人力 2.晨會溝通當天任務，同步專案進展 15min，晨會不做小組討論 3.同步專案進度和風險，已知風險確定解決方案或解決時間 下班前 前期調研不足，開發延期 專案已啟動，開發中期發現前期調研不足，不能按時交付測試 提測質量較差 bug堆積...
交叉測試的必要性和遇到的問題
在軟體測試過程中，每個專案一般由多名測試工程師組成，分別負責不同模組的測試。對同乙個模組進行多輪測試，測試人員對手中的模組無論從整體到細節都有了非常深刻的掌握，但同時存在的定向思維，測試疲態也影響了bug的發現。這種測試模式不但影響了產品的最終質量，同時測試人員對產品整個邏輯和功能的了解也受到了限制...