測試的過程應該嚴格遵循一定的過程與計畫，這樣的過程體現於測試案例中，測試者可以只按照測試案例便可以找出該軟體的問題所在，而不需要對軟體的需求有深入的了解，恰恰這個測試案例的編寫人卻需要很深入了解軟體需求設計架構，可是能夠編寫好的測試案例的是乙個測試員的基本素質。總結幾年風雨兼程的測試歷程,有以下的一些膚淺體會，與大家一起交流：
編寫原則：fvt(功能測試)-- 涵蓋需求，細到api()， 綜合業務考慮，case數不在多，而在精，盡大地避免重複。
svt(系統測試)-- 全面考慮，介面部分要細，case數不在多，而要涵蓋所有可能的組合
1。熟悉需求，了解業務
2。熟悉設計
3。結合需求與設計進行模組劃分
4。根據模組的側重點來定位case數目的比例
5。case要寫的足夠詳細，盡量做到任何人拿著case能夠完成測試
6。測試**書寫命名規範，**注釋，盡量與case掛鉤
我們的軟體需要保證質量,規範這個流程的過程是必不可少的,希望我們能夠共同提高,希望我們的測試隊伍越來越壯大!!
做軟體的一點思考
這兩天在家畫了兩天的uml圖，當做是對自己所掌握知識的乙個複習。大概是這麼乙個過程，首先是編寫用例文件，將使用者的需求描述清楚。此步驟要盡可能的簡潔，盡量採用客戶的語言，不要採用計算機語言。其次抽象出參與者和動作，完成初步用例圖。確定主要動作和行為 分層，確定大致的開發框架。確定目錄結構 然後根據用...
關於測試的一點思考
測試部門接手乙個專案 產品的流程及關注點 1 明確產品需求 i.顯式需求 功能 效能 ii.隱式需求 安全性 應用場景等 2 確定產品定位 在效率 安全性 效能 易用性等方面的定位 2.5 確定產品質量目標 專案規範 驗收標準 執行維護標準等 3 知道產品使用者 其教育背景 偏好等，便於提取場景，增...
中日軟體行業的一點思考
公司一專案發生質量問題，被日本客戶要求進行根本原因分析，並提出對策。我們乙方的心態是怎麼能盡快把這件事情結束，而且盡量對未來的工作不產生太大的影響。當然能讓客戶看到好像是真正的原因，是最重要的。交涉了幾次之後，終於客戶納得 接受 了。歡欣鼓舞。天空頓時晴朗的感覺。根本原因分析是質量管理方面的乙個非常...