概念
測試用例（test case）為某個特殊目標(biāo)而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序路徑或核實是否滿足某個特定需求。
好處
1、有效的、快速的熟悉了解待測產(chǎn)品
2、測試用例的編寫、執(zhí)行的數(shù)量可以評估需求的覆蓋程度
3、測試用例的細化程度，可以作為階段性工作排期的一個依據(jù)
4、測試用例的輸出可以將人為因素的影響減小，例如編寫測試用例的人不能操作執(zhí)行工作，那么依據(jù)用例文檔，其他人可以進行執(zhí)行操作。
總結(jié)：思路清晰、避免遺漏、跟進測試進展、歷史參考、避免重復(fù)性
測試用例開始設(shè)計時間
當(dāng)需求文檔定版后，就可以進行測試點的提煉，開展測試用例的編寫
如果文檔不合格，最好帶著解決方法去找領(lǐng)導(dǎo)
在測試過程中如果出現(xiàn)需求變更，一定要評估
如何設(shè)計
1、將產(chǎn)品文檔中或者需求文檔中的原則或規(guī)則轉(zhuǎn)化為每個用例的檢查點
2、單個用例最小化原則，一條用例只做一件事
3、先從單個模塊或者功能點開始入手
4、借助一些用例設(shè)計方法，如等價類、邊界值、因果圖等
5、兼容性：如瀏覽器兼容性、操作系統(tǒng)兼容性等
PS：1.設(shè)計用例時要注意數(shù)據(jù)庫中數(shù)據(jù)正確性的驗證
? ? ? ? 2.要考慮關(guān)聯(lián)模塊的問題
? ? ? ? 3.異常用例非常重要
實際工作中測試用例的設(shè)計
1、首先根據(jù)需求文檔匹配模塊與角色的關(guān)系即usecase
2、輸出流程圖
3、依照usecase圖和流程如、業(yè)務(wù)規(guī)則以及設(shè)計用例方法，輸出測試用例
思考
1、用例的評審與更新？
? ? ?所有的用例都要評審，評審過后用例更新了才有價值
2、所有的項目都需要寫測試用例？
? ? ? 中型或大型的需求
3、測試用例越詳細越好
? ? ? 只要保證任何人能看懂
? ? ? 元素：編號、用例描述、前置條件、步驟、預(yù)期結(jié)果
感想
? ? ? ? ?其實我真正做測試的時間也不長，大概只有2個多月。轉(zhuǎn)正沒多久，就被領(lǐng)導(dǎo)派去做別的事情了，直到今年3月初才結(jié)束，簡直喜大普奔?，F(xiàn)在在跟一個項目，還在開發(fā)階段，所以剛好面臨用例編寫。之前我只寫過一次，還是做得二期項目，所以基本就是在前人的用例基礎(chǔ)上更新。現(xiàn)在是新開的一個項目，3個人測試，我資歷最淺，所以負責(zé)相對簡單的部分。負責(zé)這個項目的開發(fā)有組織過2次小會，講解這個項目。第一次講解了項目流程圖和參與項目的人員以及項目的計劃。第二次是因為需求有變動。然而，木有需求說明書，現(xiàn)有的文檔只有項目流程圖和技術(shù)方案，寫用例簡直麻爪。其實開會的時候，我自認為對整個流程聽得還是比較認真的，也覺得理解的還行，覺得用例編寫應(yīng)該還可以。但是，我現(xiàn)在基本只列出了測試點，具體內(nèi)容不知道咋寫，沒有需求說明書，一些小細節(jié)就不是很清楚，再加上開發(fā)說還要對現(xiàn)有的頁面功能點進行改造，所以簡直一言難盡。現(xiàn)在才發(fā)現(xiàn)，用例編寫也沒有我想的那么簡單。困難總是要克服的，我打算在仔細研究下技術(shù)方案，然后再跟測試小組長請教下。希望我的第一次用例編寫能夠順利完成。
