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