測試某個程式路徑或者合適是否滿足特定需求
俗話理解：通過一組輸入輸出來驗證某個需求的狀態或者結果是否滿足預定結果
a、有效、快速的了解待測需求
b、測試用例的編寫、執行數量可以評估需求的覆蓋度
c、測試用例的細化程度、可以作為階段性工作的排期的依據
d、測試用例的輸出可以將人為因素的影響減少，如a同學編寫用例後，b同學可以依據用例進行執行功能
需求文件定版後，即可開始陳列測試點和編寫測試用例
a、首先將需求文件或者產品文件中的規則轉述為每個用例的檢查點
b、單個用例最小化原則，即一條用例只做一件事
c、先從單個模組或者功能點入手寫用例
d、借助常用的測試用例設計方法，如等價類、邊界值、因果圖等
總結：考慮中斷測試、弱網測試等等
n2：設計測試用例時也要注意涉及到的資料庫中的字段值是否正確
n3：需要注意關聯模組的用例設計
n4：注意新增介面、新增欄位的用例的設計
a、根據需求文件找到角色和功能模組的匹配關係，輸出usecase圖
b、輸出流程圖（如果產品有輸出流程圖那是最好的了，沒有只能測試自己輸出流程圖，並發給產品進行
查缺補漏）
c、依據業務規則、usecase、流程圖輸出測試用例
測試用例是一定要評審的，因為每個人都有自己的測試盲區，所以不要認為自己考慮的是全面的
評審參與人員，相關產品、開發、測試參與即可
評審的意義：將測試用例編寫中遇到的疑問在此得到答案，並引導開發、產品功能進行思考補充現有用例（查缺補漏）
測試用例更新：一是評審後需要更新，在者就是測試過程中需要更新，測試結束後根據線上反饋情況進行更新
測試用例的編寫需要根據待測試任務的大小、緊急程度、測試人員數量等多方面衡量
對於大中型任務，個人建議還是要寫詳細的用例，因為寫用例就是思考的過程
對於緊急小型任務，可以寫測試點
對於新人負責的模組，一定要寫測試用例（本人寫或者老人寫完，新人執行）
其實和問題7有一定的關聯，在問題7的前提下，僅僅就測試人員來說是否寫測試用例，寫何種顆粒度的測試用例其實取
決於測試人員本身的水平
如何寫用例、怎麼寫、寫到何種粒度都需要依據當前公司的專案的情況決定。
但是依舊建議無論測試人員本身水平如何，都需要輸出基本的測試用例或者測試點。
首先這是對自己的負責，其次隨著時間的流逝，你能保證記錄下曾經所有的用例麼，
這也就是為何建議輸出用例或者測試點的原因，不要認為測試用例的設計沒有任何的含量，
恰恰相反，測試用例的設計反而是最核心的技能。
測試用例這件事
測試某個程式路徑或者合適是否滿足特定需求 俗話理解 通過一組輸入輸出來驗證某個需求的狀態或者結果是否滿足預定結果 a 有效 快速的了解待測需求 b 測試用例的編寫 執行數量可以評估需求的覆蓋度 c 測試用例的細化程度 可以作為階段性工作的排期的依據 d 測試用例的輸出可以將人為因素的影響減少，如a同...
部落格這件事兒。。。
csdn發表部落格傳是龜速。還不能和word直接對接，我來試試。csdn的 數量遠遠少於，最重要的是可以和word發部落格直接對接。csdn檢查部落格發布太慢，秒發 csdn走好不送。word2010可以直接發部落格到csdn上嗎？親測，不能！或者儲存並傳送 部落格文章 格式為 部落格名 servi...
看穿面試這件事兒
有個朋友 min十幾年工作經驗，最近計畫換工作，很快接到到有幾個外企面試的通知。因為有幾年沒被別人面試了，min 面試就是乙個平等溝通的過程。看穿幾個關鍵點，會大大加強我們面試的成功率。乙個基本點 公司希望也需要優秀的人加盟。絕大公司招聘的目的是為了填補已經有的 將要有的職位空缺，極少的公司約我們面...