日常設計
的時候，有許多經典的測試理論。比如邊界法、等價法，這些經常用到我們日常的
工作中。當然也有許多的理論，比如正交分解法是使用起來非常費勁。往往轉化為實際的容易理解的測試語言就非常困難。
測試用例
測試的時候，我們也會碰到難堪的場景，那就是測試遺漏。
我們來分析下，開發的過程。開發拿到需求後，就會開發相應的**，然後簡單的測試下功能。**之間有可能是互相呼叫的，**可能影響到的模組，有些開發是知道的，有些是不知道的。如果是有關
資料庫的操作，乙個地方的改動有可能影響了多個模組。所以問題的複雜性就體現在這裡了。
那麼對於日常測試每個新功能，我們該怎麼去構築我們堅固的質量堡壘呢。
根據開發過程的特點，總結了我們設計測試用例六把刀。
關注頁面單個功能點驗證，充分考慮開發改動的每個點。這個是保證開發每個已知的修改點都能改對。
重點考慮修改點對
其他模組的影響，包括**的影響和運算元據引起的影響。
比如新增加的功能增加了資料庫表的字段，必須關聯的驗證每個使用該錶的該字段的模組是否正常工作。難點在於需要分析出已知和未知的影響模組，考慮的越多，往往遺漏的問題就越少。
很多系統是有流程的，比如工作流系統。當修改了乙個點的時候，我們必須考慮整個流程是否能夠正常運轉起來。
我們大部分系統都是對已有的系統進行公升級。對於公升級前的資料，我們必須保證能夠正常工作。公升級之前，需要模擬好各種情況。同時，也需要對公升級的資料庫指令碼進行充分的檢查。
比如選單功能許可權等。
有的時候需要對效能進行考慮，比如公升級指令碼的執行效率，功能點的響應時間，事務交易的時間。
這六把刀現在已經應用到了我們日常設計測試計畫，測試用例工作中去了，成為了大家思考的乙個入口點。後來大家發現有如下特點：
1）實踐證明，該方法非常靈活。
在不同的顆粒度設計測試用例都可以作為我們思考的乙個切入點。比如站在測試計畫的角度，站在每個測試用例的角度都可以使用。
2）平易近人
道理非常簡單，非常容易理解，可操作性非常高。不再是只能在課堂上講，在實踐中用不上的理論了。
3）功能和關聯使用頻率最高
軟體測試之測試用例的設計
測試用例的設計方法 面試案例 為了實施測試而向被測試的系統提供的一組集合 測試環境 操作步驟 測試資料 預期結果 對比好壞 的評價標準 rbt requirements based testing 是基於需求的測試方法，會使測試更加有效，因為它使測試專注於質量問題產生的根源，即需求。重點關注以下兩大...
軟體測試之測試用例設計題
1.假設京東有乙個web api 輸入打折價p1和原價p0,返回折扣資訊0.9，請設計測試 用例進行測試。答案 1 輸入打折價錯誤 輸入原價錯誤 輸入值不在正常範圍內 2 輸入打折價錯誤 輸入原價正確 3 輸入打折價正確 輸入原價錯誤 4 輸入打折價正確 輸入原價正確 打折價高於原價 5 輸入打折價...
軟體測試理論測試用例測試之等價類劃分
把所有可能輸入的資料，即程式的輸入域劃分策劃若干部分 子集 然後從每乙個子集中選取少數具有代表性的資料作為測試用例，是一種黑盒測試方法 有效等價類指對於程式規格說明來說，是合理的 有意義的輸入資料構成的集合 無效等價類和有效等價類相反，無效等價類是指對於軟體規格說明而言，沒有意義的 不合理的輸入資料...