1：公司流程
開發：編寫概要和詳細設計--- 編碼並自測(開發環境)
立項(確定項目)--編寫需求(需求人員)--需求評審(編寫需求人員發起)-- ---------------部署環境(linux)---冒煙測試(通過)--提交bug---回歸測試(測試報告)--驗收測試--上線
測試: 測試用例--測試用例評審(測試人員發起)
1.1. 測試用例的4個特性
代表性：能夠代表並覆蓋各種合理的和不合理、合法的和不合法的、邊界的和越界的以及極限的輸入數據、操作等。
針對性：對程序中的可能存在的錯誤有針對性地測試
可判定性：測試執行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果
可重現性：對同樣的測試用例，系統的執行結果應當是相同的。
1.1. 測試用例通常包括以下幾個組成元素：
用例編號、測試模塊、用例標題、用例級別、測試環境、測試輸入、執行操作、預期結果,實際結果….
1.2測試用例示例
1. 編寫測試用例的基本方法
1.1.1. 概念
有效，無效
等價類划分是指分步驟地把海量（無限）的測試用例集減得很小，但過程同樣有效。
等價類 ：何為等價類，某個輸入域的集合，在這個集合中每個輸入條件都是等效的。
一般可分為有效等價類和無效等價類
比如：一個青少年考試的分數（備注13-17歲為青少年）
假設青少年年齡為x,13<=x<=17,數學成績為y：0<=y<=100
那么年齡按照等價類划分可分為x<13,13<=x<=17,x>17,有效等價類是13<=x<=17，無效等價類是x<13，x>17
數學成績按照等價類划分可分為y<0,0<=y<=100,y>100,有效等價類是0<=y<=100，無效等價類是y<0，y>100
1.1.1. 示例
計算兩個1～100之間整數的和。
如果要進行完全測試，一共要設計多少個測試用例呢？
加數1有1～100共計100個取值，加數2也有1～100共計100個取值，所以他們之間的組合就有100*100=10000種組合可能，但這只是測試了正常范圍內的取值。如果用戶輸入的數據不在1～100之間呢，窮舉測試肯定不可能的。由此引入了等價類划分思想。
等價類划分為：
有效等價類：指符合《需求規格說明書》，輸入合理的數據集合
無效等價類：指不符合《需求規格說明書》，輸入不合理的數據集合
我們將輸入域分成了一個有效等價類（1～100）和兩個無效等價類（<1,>100），並為每一個等價類進行編號，然后我們就可以從每一個等價類中選取一個代表性的數據來測試，設計如下表所示的測試用
1.1練習案例:
划分等價類並編號,下表為等價類划分的結果
1.1. 邊界值法
一般邊界值分析是因為程序開發循環體時的取數可能會因為<,<=搞錯。
比如下面代碼
for(int i = 0;i <100; i ++)
{
int j = i+1;
System.out.println("循環第“+j+"次")//循環地做某件事情
}
這里的程序是循環了100次，所以會做100次;
如果程序員不小心，把i <100寫成i <= 100，則多循環添加一次，這時候邊界值檢查是一個很好的測試方法。
比如：在一個系統中，填寫一個多少歲的青少年考了多少分（假設成年人年齡為x,13<=x<=17,數學成績為y：0<=y<=100
根據上面的等價類划分法我們可知，年齡的有效等價類是13<=x<=17，所以邊界值就是12， 18
數學成績的,有效等價類是0<=y<=100，所以邊界值就是-1，0，100，101
對數據進行軟件測試，就是在檢查用戶輸入的信息、返回的結果以及中間計算結果是否正確。即使最簡單的程序要處理的數據量也可能極大，使這些數據得以測試的技巧是，根據一些關鍵的原則進行等價類的划分，以合理減少測試用例，這些關鍵的原則是：邊界條件，次邊界條件、空值和無效數據。
1.1.1. 確定邊界值的方法（）
選取正好等於、剛剛大於或剛剛小於邊界值作為測試數據
輸入要求是1 ～ 100之間的整數，因此自然產生了1和100兩個邊界，我們在設計測試用例的時，要重點考慮這兩個邊界問題。
[1 100] 上點1 ，100 離點 0 101所屬
(1,100) 上點 2，99 離點 1 ，100
(1,100] 上點 2，100 離點 1 ，101
1.1. 因果圖法
1.1.1. 概念:
因果圖法比較適合輸條件比較多的情況，測試所有的輸入條件的排列組合。所謂的原因就是輸入，所謂的結果就是輸出。
1.1.2. 因果圖基本圖形符號
恆等：若原因出現，則結果出現；若原因不出現，則結果不出現。
非（～）：若原因出現，則結果不出現；若原因不出現，則結果出現。
或（∨）：若幾個原因中有一個出現，則結果出現；若幾個原因都不出現，則結果不出現。
與（∧）：若幾個原因都出現，結果才出現；若其中有一個原因不出現，則結果不出現。
1.1.1. 因果圖的約束符號
E（互斥）：表示兩個原因不會同時成立，兩個中最多有一個可能成立
I（包含）：表示三個原因中至少有一個必須成立
O（惟一）：表示兩個原因中必須有一個，且僅有一個成立
R（要求）：表示兩個原因，a出現時，b也必須出現，a出現時，b不可能不出現
M（屏蔽）：兩個結果，a為1時，b必須是0，當a為0時，b值不定
1.1.1. 因果圖測試用例
例如：有一個處理單價為2.5元的盒裝飲料的自動售貨機軟件。若投入2.5元硬幣，按“可樂”、“啤酒”、或“奶茶”按鈕，相應的飲料就送出來。若投入的是3元硬幣，在送出飲料的同時退還5角硬幣。
分析這一段說明，我們可列出原因和結果
原因(輸入)：
投入2.5元硬幣；
投入3元；
按“可樂”按鈕；
按“啤酒”按鈕；
按“奶茶”按鈕。
中間狀態： ① 已投幣；②已按鈕
結果(輸出)：
退還5角硬幣；
送出“可樂”飲料；
送出“啤酒”飲料；
送出“奶茶”飲料；
1.1. 場景法
1.1.1. 測試用例設計的思想
現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利於測試設計者設計測試用例，同時使測試用例更容易理解和執行。
用例場景是通過描述流經用例的路徑來確定的過程，
這個流經過程要從用例開始到結束遍歷其中所有基本流和備選流。
遵循上圖中每個經過用例的可能路徑，可以確定不同的用例場景。從基本流開始，再將基本流和備選流結合起來，可以確定以下用例場景：
基本流和備選流的區別
1.1.1. 銀行案例ATM:
個人標識號 (PIN＝personal identification number )，用於保護智能卡免受誤用的秘密標識代碼。PIN 與密碼類似，只有卡的所有者才知道該 PIN。只有擁有該智能卡並知道 PIN 的人才能使用該智能卡
第一次測試中，根據測試計划，我們需要核實提款用例已經正確地實施。此時尚未實施整個用例，只實施了下面的事件流：
基本流-提取預設金額（100 元、200元、500元、1000元）
備選流2 - ATM 內沒有現金
備選流3 - ATM 內現金不足
備選流4 - PIN 有誤
備選流5 - 帳戶不存在/帳戶類型有誤
備選流6 - 帳面金額不足
對於這7個場景中的每一個場景都需要確定測試用例。可以采用矩陣或決策表來確定和管理測試用例。
從確定執行用例場景所需的數據元素入手構建矩陣。然后，對於每個場景，至少要確定包含執行場景所需的適當條件的測試用例。
下面顯示了一種通用格式，其中各行代表各個測試用例，而各列則代表測試用例的信息。
本示例中，對於每個測試用例，存在一個測試用例ID、條件（或說明）、測試用例中涉及的所有數據元素（作為輸入或已經存在於數據庫中）以及預期結果。
1.1. 錯誤推測法
錯誤猜測法是測試經驗豐富的人喜歡使用的一種測試用例設計方法。
一般這種方法是基於經驗和直覺推測程序中可能發送的各種錯誤，有針對性地設計。只能作為一種補充。
例如，測試手機終端的通話功能，可以設計各種通話失敗的情況來補充測試用 例：
1) 無SIM 卡插入時進行呼出（非緊急呼叫）
2) 插入已欠費SIM卡進行呼出
3) 射頻器件損壞或無信號區域插入有效SIM卡呼出
4) 網絡正常，插入有效SIM卡，呼出無效號碼（如1、888、333333、不輸入任何號碼等）
5) 網絡正常，插入有效SIM卡，使用“快速撥號”功能呼出設置無效號碼的數字
技巧：最重要的是要思考和分析測試對象的各個方面，多參考以前發現的bug的相關數據，總結的經驗，個人多考慮異常的情況、反面的情況、特殊的輸入，以一個攻擊者的態度對待程序，就能設計出比較完善的測試用例來。