**實現的業務邏輯存在問題，就是bug
不符合業務需求和驗收標準的，就是bug
使用者體驗不好的，就是bug
**錯誤
**錯誤指的是，按照設計流程圖，當出現某種情況下，返回的結果是這一種，而實際測試返回的結果卻與設計不符。
比如：我們如果測試乙個登入介面，設計文件明確說明，當輸入錯誤的賬號或密碼時，提示「賬號或密碼錯誤」，而開發實現是提示「登入錯誤」，這就是乙個最簡單的**錯誤。
在實際測試過程中，**錯誤，驗收標準是根據設計文件和設計流程來進行判斷，根據嚴重程度，可以出現不同程度的bug。
設計缺陷
設計缺陷指的是設計文件和設計流程本身就存在不合理的地方。
介面優化
效能問題
效能問題的缺陷，是指一款產品在承受使用者量大情況下，可能存在執行緩慢甚至宕機的情況
其它型別
配置相關 、安裝部署 、安全相關 、標準規範 、測試指令碼等
注： 一般在我們的測試過程中，經常碰到的就是**錯誤、色痕跡缺陷、介面優化這三個型別的缺陷。
致命錯誤
常規操作引起崩潰、宕機、死迴圈造成資料洩露的安全性問題，比如惡意攻擊造成的賬戶私密資訊洩露涉及金錢操作。
嚴重錯誤
重要功能不能實現錯誤的波及面廣，影響到其它重要功能正常實現；功能互動非常規操作導致的程式崩潰、宕機、死迴圈 外觀難以接受的缺陷，密碼明文顯示（介面+資料庫），密碼視覺化操作。
一般錯誤
不影響產品的執行，不會成為故障起因，但對產品外觀和下道工序影響較大的缺陷 次要功能不能正常實現 操作介面錯誤（包括資料視窗內列名定義、含義不一致） 查詢錯誤，資料錯誤顯示 簡單的輸入限制未放在前端進行控制（格式限制），減輕後端壓力 刪除操作未給出提示（誤操作）
細微錯誤
介面不規範 輔助視窗說明描述不清楚 提示視窗文字未採用行業術語 介面存在文字錯誤 改進建議：可以站在提高使用者體驗，提高產品質量
生命週期中一般流程：
重新認識container
我還清楚的記得，第一次從 那兒聽說container這個詞 結果他給我解釋了半天還是似懂非懂的。今天，偷閒翻了下posa4,發現裡面對container的解釋特別清楚。粗略的理解下來是，為了分離關注點，而實現的對系統資源的封裝。豁然開朗的發現，os就是應用程式的container。突發奇想的，開發乙...
重新認識測試
以前總覺得測試是軟體開發的邊緣職位，開發人員才是軟體生命週期的核心人員。隨著對網際網路公司的了解，逐步了解到測試的重要性。以bat為例，三家公司均設定了測試開發工程師崗位，該崗位的主要職責就是編寫自動化測試案例，通過對 的邏輯進行分析，設計出能夠覆蓋大部分 的測試用例。如阿里的測試開發工程師的崗位描...
重新認識ARC
雖然用了很久的arc，感受了 簡潔。但是對arc底層實現並不了解。今天抽空研究了下，做些簡單地總結。一 strong 1.區域性變數 對於區域性變數來說，在超出作用域的地方由編譯器自動插入release。大概轉化為 在非arc返回的autorelease型別的方法 在blog手碼大概 如有錯誤還望指...