測試用例編寫的一點體會
一是測試用例對需求覆蓋的完整性；
二是測試用例的有效性；
三測試用例的可理解性;
四是測試用例的清晰性；
五是測試用例的可維護性。
測試用例是基於需求的，為了測試程式是否滿足需求，個人覺得要想寫好測試用例必須對於需求做到完全理解，並能從全域性上把握住需求。乙個好的方法就是用mm圖把需求分解了。把基本路徑分解出來，將需求歸類。理順了需求，用例寫起來就順手的多。在編寫用例的過程中進行等價類的劃分，最後用判定表進行評判，補充缺少的用例，剔除冗餘的用例。做到對需求的100%覆蓋。也就是說拿到需求文件必須進行必要的分析，不能上來就盲目的寫用例，尤其應該注意。測試用例編寫完成後必須明確哪些是核心功能的用例！
（測試用例的有效性）測試用例應該包含清晰的輸入資料以及預期輸出，沒有測試資料的用例更多的是具有指導意義，執行過程中更多的是靠個人根據指導的自由發揮。但是看看我們的基線庫更多的是這樣指導意義的用例。（但是輸入資料又涉及到了維護的問題，以及環境或者業務發生變更後引起的有效性問題）。對於預期的結果不能僅僅是頁面上或者介面上的可見結果，如果和資料庫發生了互動，必須包含資料庫裡準確的驗證結果。用例基於資料驅動。
（測試用例的可理解性）測試用例步驟必須描述清晰，不能出現模稜兩可以及重複的話語，測試用例應該按照增刪改的順序進行安排，這樣執行的時候效率比較高，避免不必要的重複測試，用例寫完不是就ok了，我們最好通讀2遍，進行修改，讓單條用例流暢。
（測試用例的清晰性）測試用例的驗證點必須明確清晰重點突出，按照最新的用例標準，乙個用例進行乙個功能點的驗證，乙個蘿蔔乙個坑。對於流程性的用例也是建議按照流程順序進行用例安排，從第乙個驗證點到最後乙個驗證點，組成流程的開始到結束，方便測試執行。測試用例包含前置條件的必須將前置條件描述清楚，包括入口等。
（測試用例的可維護性）我們的用例主要是基於web的，用例存在一定的變數。
因此在測試用例因為業務需求發生變更的時候，請及時修改，維護測試用例，做到測試用例的實時性與有效性，同時也方便後來的新人同學及時學習，不會產生誤解與費解。
ross collard在」use case testing」一文中說：「測試用例的前10%到15%可以發現75%到90%的重要缺陷」。如果你在專案或者日常結束後，仔細的分析過我們的bug列表，那麼你會覺的這句話非常適用。合理提高我們的測試效率就是在編寫測試用例時進行測試用例優先順序的劃分。
幾點建議：
1．你是否感覺測試的時候思維很混亂，或者總感覺有些功能沒有測到，而一些功能已經測過好幾遍？請明確你的需求，是否做到覆蓋100%。你的用例優先順序是否設定的合理。
2．在測試時間緊迫的情況下，你不知道要測什麼，或者要先測試那些功能？那麼你需要調整自己用例的優先順序，順帶回去好好整理整理需求。
3．在編寫測試用例的時候優先去學習，老人們優秀的做法。在學習別人優秀成果的基礎上，編寫自己的用例。
軟體測試用例設計心得
1 了解軟體的原始需求 測試目的 在編寫乙個軟體或者模組的測試用例時候，一定要明白這個功能的原始需求，也就是軟體的使用者 客戶 的需求。理解原始需求後，編寫的測試用例才更有目的性。2 熟悉軟體的功能需求 測試點 這個功能需求是指軟體的細化需求點，這個一般在需求文件裡面都會體現。這裡要做的是把 粗略 ...
CISSP考試心得分享
拖拉了好幾年，去年年底終於決定開始認真學習cissp準備考試。11月4號報的匯哲的培訓班，截止今天2018.1.19,一共2個半月，順利通過了。隨便寫寫經驗，分享給大家。我自身本科學的資訊科技，碩士學的網路 通訊，工作後一直搞網路以及運營，以及少量專案管理，考了工信部下面的資訊系統專案管理師，跟著單...
CISSP考試心得分享
拖拉了好幾年，去年年底終於決定開始認真學習cissp準備考試。11月4號報的匯哲的培訓班，截止今天2018.1.19,一共2個半月，順利通過了。隨便寫寫經驗，分享給大家。我自身本科學的資訊科技，碩士學的網路 通訊，工作後一直搞網路以及運營，以及少量專案管理，考了工信部下面的資訊系統專案管理師，跟著單...