1、你認為做好測試用例工作的關鍵是什麼？
需求和設計文件的理解程度，對系統的熟悉程度
2、軟體的安全性應從哪幾個方面去測試？
使用者認證機制：如資料證書、智慧卡、雙重認證、安全電子交易協議
加密機制
安全防護策略：如安全日誌、入侵檢測、隔離防護、漏洞掃瞄
資料備份與恢復手段：儲存裝置、儲存優化、儲存保護、儲存管理
防病毒系統
3、描述測試用例設計的完整過程？
需求分析+ 需求變更的維護工作；
根據需求得出測試需求；
設計測試方案，評審測試方案；
方案評審通過後，設計測試用例，再對測試用例進行評審；
4、功能測試用例需要詳細到什麼程度才是合格的？
這個問題也是測試工程師經常問的問題。有人主張測試用例詳細到每個步驟執行什麼都要寫出來，目的是即使乙個不了解系統的新手都可以按照測試用例來執行工作。主張這類寫法的人還可以舉出例子：歐美、日本等軟體外包文件都是這樣做的。
另外一種觀點就是主張寫的粗些，類似於編寫測試大綱。主張這種觀點的人是因為軟體開發需求管理不規範，變動十分頻繁，因而不能按照歐美的高標準來編寫測試用例。這樣的測試用例容易維護，可以讓測試執行人員有更大的發揮空間。
實際上，軟體測試用例的詳細程度首先要以覆蓋到測試點為基本要求。舉個例子：「使用者登陸系統」的測試用例可以不寫出具體的執行資料，但是至少要寫出五種以上情況（），如果只用一句話覆蓋了這個功能是不合格的測試用例。覆蓋功能點不是指列出功能點，而是要寫出功能點的各個方面（如果組合情況較多時可以採用等價劃分）。
另乙個影響測試用例的就是組織的開發能力和測試物件特點。如果開發力量比較落後，編寫較詳細的測試用例是不現實的，因為根本沒有那麼大的資源投入，當然這種情況很隨著團隊的發展而逐漸有所改善。測試物件特點重點是指測試物件在進度、成本等方面的要求，如果進度較緊張的情況下，是根本沒有時間寫出高質量的測試用例的，甚至有些時候測試工作只是一種輔助工作，因而不編寫測試用例。
因此，測試用例的編寫要根據測試物件特點、團隊的執行能力等各個方面綜合起來決定編寫策略。最後要注意的是測試人員一定不能抱怨，力爭在不斷提高測試用例編寫水平的同時，不斷地提高自身能力。
5、您認為做好測試用例設計工作的關鍵是什麼？
白盒測試用例設計的關鍵是以較少的用例覆蓋盡可能多的內部程式邏輯結果
黑盒法用例設計的關鍵同樣也是以較少的用例覆蓋模組輸出和輸入介面。不可能做到完全測試，以最少的用例在合理的時間內發現最多的問題
6、您所熟悉的測試用例設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。
1）．等價類劃分
劃分等價類:等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對於揭露程式中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入資料合理劃分為若干等價類,在每乙個等價類中取乙個資料作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2）．邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料.
3）．錯誤推測法
基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.
錯誤推測方法的基本思想:列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模組中常見的錯誤.以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入**為空格或輸入**只有一行.這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.
4）．因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯絡, 相互組合等.考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多.因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）.因果圖方法最終生成的就是判定表. 它適合於檢查程式輸入條件的各種組合情況.
7、請以您以往的實際工作為例，詳細的描述一次測試用例設計的完整的過程。
就說最近的這次**功能的測試吧
第二步：設計測試用例，測試策略是：把**部分的功能點測試完，然後在進行系統測試（另外個模組呢有另乙個測試人員負責，可以進行聯調測試），**模組的測試基本是功能測試和介面測試（使用者併發的可能性很小，所以不考慮）：這次的**的輸入資料呢是使用資料庫中的某張表記錄，如果表中某一資料記錄中新加進來的（還沒有被處理的，有個標誌位），**啟動後會立刻去刷那張表，得到多條資料，然後在進行處理。處理過程中，會經歷3個步驟，**才算完成了它的任務。有3個步驟呢，就可以分別對 這3個步驟進行測試用例的設計,盡量覆蓋到各種輸入情況（包括資料庫中的資料，使用者的輸入等），得出了差不多50個用例。介面測試，也就是使用者看的到的地方，包括傳送的郵件和使用者填寫資料的頁面展示。
第三步：搭建測試環境（為什麼這個時候考慮測試環境呢？因為我對**環境已經很熟了，只有有機器能空於下來做該功能測試就可以做了），因為**本身的環境搭建和其他的系統有點不同，它需要的測試環境比較麻煩，需要web伺服器（apache,tomcat），不過這次需求呢，**部分只用到了tomcat，所以只要有tomcat即可
第四步：執行測試
軟體測試 用例
三 什麼是測試用例的有效性 四 測試用例的粒度和評價 軟體測試 用例 本節重點 1.測試用例的基本要素 2.測試用例的設計方法 3.測試用例的有效性 4.測試用例的粒度和評價 測試用例就是向被測試系統發起的一組集合，包含測試資料，測試環境，操作步驟，預期結果 要素 測試前期 測試版本 功能模組 重要...
測試面試 設計測試用例
第一篇，先說一下測試用例。首先呢，關於測試用例呢，我認為是比較重要的。但是在實際的工作過程中，這個東西往往是受到多方面的影響的 公司規模小，測試用例沒有乙個清晰或者完整的規範。用例寫的再好，也沒有任何的表揚和實質性的獎勵 用例寫的再含糊，領導說行那就行，那誰還會用心寫？公司有完整的用例規範和要求，但...
軟體測試與軟體測試用例
程式設計要寫 測試要寫用例。做了這麼多年的軟體測試工作，經歷了對測試用例認識的不同階段。第一階段，入門。編號，測試點，測試環境，測試資料，測試步驟，預期結果，設計人，設計時間，執行結果，執行時間，備註。所有的一切都要寫的清清楚楚，詳詳細細。設計 評審 修改，迴圈往復。這個階段提到的有關測試用例設計最...