測試某個程式路徑或者合適是否滿足特定需求
俗話理解：通過一組輸入輸出來驗證某個需求的狀態或者結果是否滿足預定結果
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同...
快取 這件事
資料庫來說最大的瓶頸出現在io這個問題上，那麼在專案中普遍情況大家用快取。這情況可以減少對資料庫的操作。快取原理和機制是 一般的快取和nhibernate 快取的區別？一般情況 快取的是存在 客戶端記憶體？還是伺服器記憶體？快取是硬碟控制器上的一塊記憶體晶元，具有極快的訪問速度，是一種處理方式。快取...
上網這件事
遲來的一些對於想要自由上網的幫助內容。說明 僅限採用ipv4版本的協議，重新整理dns的方式僅限windows下的使用方式，其他系統請自行解決。友情提示，本意在於分享知識，別無惡意 請奔著學習國外前沿技術的目標，否則請自行承擔自由過後帶來的後果。notepad 開啟c windows system3...