第一篇，先說一下測試用例。
首先呢，關於測試用例呢，我認為是比較重要的。
但是在實際的工作過程中，這個東西往往是受到多方面的影響的：
公司規模小，測試用例沒有乙個清晰或者完整的規範。用例寫的再好，也沒有任何的表揚和實質性的獎勵；用例寫的再含糊，領導說行那就行，那誰還會用心寫？
公司有完整的用例規範和要求，但是有些過於繁瑣，無關鍵緊要的字數太多，體現不出來測試用例的重點；…
但是這些客觀的種種限制，並不能成為影響你的設計用例的思路的理由。
我的理解是，你可以一肚子的用例，針對你公司的實際情況，有的放矢的寫出來。畢竟一開始，大家要適應工作，而不是工作適應大家。
言歸正傳
我們首先明確一點：面試官讓你設計測試用例，是想考察你什麼？
我的理解是，考察你思考乙個場景的角度。
之前我的面試的時候，常常會給面試者乙個場景：**的購物車用過吧？那就說說購物車吧！
很多面試者（十個裡面有五六個）上來就是說要看頁面上一些元素顯示的對不對。比如文字啊，啊；
還有一些說新增乙個商品到購物車，看看成不成功；
那麼這些回答總結起來就是：思考角度缺乏分類。
作為面試官，從你的回答的裡面我能感覺到的不僅僅是你的用例寫的怎麼樣，還有的就是你做事情的時候有沒有一套正確的方法，還有的就是你描述的能力、語言組織能力。
不囉嗦，那我在我看來乙個比較好的做法是什麼呢？
（敲黑板三次 !!! 劃重點了！）
畫**
如圖：**的左側，寫用例的角度；
**的上方，寫用例的場景；
如果按照個這個模式寫出來，可能你剛準備往裡面寫一些細節點：詳細用例的時候，面試官可能就會說：好了，不用寫了。
因為他已經知道你的思考問題的角度了，那麼角度+場景有了，裡面填充細節的東西，大家都可以做的。
其實以上操作反應出來的東西就是：
你的思考會不會被某乙個角度的侷限住；
你做事的時候有沒有總結出來自己的一套流程；
有些道友就會說了，哎呀這些角度大家都知道呀！沒錯，這就是乙個通用的、基礎角度（預設不考慮安全和效能）。
那麼加分項來了：
我們都知道分布式的系統越來越多，像這種電商類的大公司，不可能不用分布式的。那麼針對這種情況，我們思考用例的角度，要更多一些，更全面一些。
以上新加的角度，大家可以參考…當然，具體情況也要視情況而定。
總結一下：
今天這篇部落格實際上是幫助大家整理一下思路。
希望大家在設計用例的時候，不要侷限在某一角度出不來。首先畫**（重點！！！）——左側寫角度，右側寫場景。用例自然而然就有了。寫的時候盡量針對角度和場景寫的更多一些，更全面一些。
希望對大家有所收穫！
再重複一遍：先畫**！！！（嘔心瀝血四個字）
軟體測試面試 測試用例
1 你認為做好測試用例工作的關鍵是什麼？需求和設計文件的理解程度，對系統的熟悉程度 2 軟體的安全性應從哪幾個方面去測試？使用者認證機制 如資料證書 智慧卡 雙重認證 安全電子交易協議 加密機制 安全防護策略 如安全日誌 入侵檢測 隔離防護 漏洞掃瞄 資料備份與恢復手段 儲存裝置 儲存優化 儲存保護...
測試用例設計
1.測試用力的概念 測試用例是為特定的目的而設計的一組的測試輸入。執行條件和預期的結果，體現在測試方案 方法 技術和策略。2.測試用例具備的特點 1 正確性 2 完整性 3 準確 4 清晰 簡潔 5 可維護性 6 適應性 7 可重用性 8 其他 3.測試用例基本原則 個人認為比較重要的加黑了。1 基...
測試用例設計
1.名稱與標識 2.測試追蹤 3.用例說明 4.測試的初始化要求 5.測試的輸入 6.期望的測試結果 7.評價測試結果的準則 8.操作過程 9.前提和約束 10.測試終止條件 編寫用例規範 1 系統性 對系統業務流程要完整說明整個系統的業務需求 系統由幾個子系統組成以及它們之間的關係 對模組業務流程...