1.請描述如何劃分缺陷與錯誤嚴重性和優先順序別？
給軟體缺陷與錯誤劃分嚴重性和優先順序的通用原則：
（1）表示軟體缺陷所造成餓危害和惡劣程度。
（2）優先順序表示修復缺陷的重要程度和次序。
優先順序：
（1）最高優先順序：立即修復，停止進一步測試。
（2）次高優先順序：在產品釋出之前必須修復。
（3）中等優先順序：如果時間允許應該修復。
（4）最低優先順序：可能會修復，但是也可能釋出。
嚴重性：
（1）嚴重：系統崩潰、資料丟失、資料毀壞
（2）較嚴重：操作性錯誤、結果錯誤、遺漏功能
（3）一般：小問題、錯別字、UI佈局、罕見故障
（4）建議：不影響使用的瑕疵或更好的實現。
2.一套完整的測試應該由哪些階段組成？分別闡述一下各個階段。
一套完整的測試應該由五個階段組成：
1.測試計劃
首先，根據使用者需求報告中關於功能要求和效能指標的規格說明書，定義相應的測試需求報告，即制訂黑箱測試的最高標準，以後所有的測試工作都將圍繞著測試需求來進行，符合測試需求的應用程式即是合格的，反之即是不合格的；同時，還要適當選擇測試內容，合理安排測試人員、測試時間及測試資源等。
2.測試設計
將測試計劃階段制訂的測試需求分解、細化為若干個可執行的測試過程，併為每個測試過程選擇適當的測試用例（測試用例選擇的好壞將直接影響到測試結果的有效性）。
3.測試開發
建立可重複使用的自動測試過程。
4.測試執行
執行測試開發階段建立的自動測試過程，並對所發現的缺陷進行跟蹤管理。測試執行一般由單元測試、組合測試、整合測試、系統聯調及迴歸測試等步驟組成，測試人員應本著科學負責的態度，一步一個腳印地進行測試。
5.測試評估
結合量化的測試覆蓋域及缺陷跟蹤報告，對於應用軟體的品質和開發團隊的工作進度及工作效率進行綜合評價。
3.一條軟體缺陷都記錄了哪些內容？
1.通用UI要統一、準確
缺陷報告的UI要與測試的軟體UI保持一致，便於查詢定位。
2.儘量使用業界慣用的表達術語和表達方法
使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
3.每條缺陷報告只包括一個缺陷
每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
4.不可重現的缺陷也要報告
首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。
5.明確指明缺陷型別
根據缺陷的現象，總結判斷缺陷的型別。例如，即功能缺陷、介面缺陷、資料缺陷，合理化建議這是最常見的缺陷或缺陷型別，其他形式的缺陷或缺陷也從屬於其中某種形式。
6.明確指明缺陷嚴重等級和優先等級
時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先順序。
7.描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
描述要準確反映缺陷的本質內容，簡短明瞭。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的使用者介面（UI）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制元件的名稱。
8.短行之間使用自動數位序號，使用相同的字型、字號、行間距
短行之間使用自動數位序號，使用相同的字型、字號、行間距，可以保證各條記錄格式一致，做到規範專業。
9.每一個步驟儘量只記錄一個操作
保證簡潔、條理井然，容易重複操作步驟。
10.確認步驟完整，準確，簡短
保證快速準確的重複缺陷，「完整」即沒有缺漏，「準確」即步驟正確，「簡短」即沒有多餘的步驟。
11.根據缺陷，可選擇是否進行圖象捕捉
為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的介面，以圖片的形式作為附件附著在記錄的「附件」部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全螢幕幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
附加必要的特殊檔案和個人建議和註解
如果開啟某個特殊的檔案而產生的缺陷或缺陷，則必須附加該檔案，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。
12) 檢查拼寫和語法缺陷
在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
13) 儘量使用短語和短句，避免複雜句型句式
軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。
4.簡述一下缺陷的生命週期
開啟 ： 表示問題被提交等待有人處理。
重新指派 ： 問題被重新指派給某人處理。
處理 ： 問題在處理中，尚未完成。
固定 ： 確認此問題存在，但暫時不進行處理。
迴歸 ： 對已經修復的問題進行迴歸確認。Reopened :
關閉 ： 問題的最後一個狀態。
5.測試用例設計方法都有哪些？
1.等價類劃分法
顧名思義，等價類劃分，就是將測試的範圍劃分成幾個互不相交的子集，他們的並集是全集，從每個子集選出若干個有代表性的值作為測試用例。
2.邊界值分析法
長期的測試工作經驗告訴我們，大量的錯誤是發生在輸入或輸出範圍的邊界上，而不是發生在輸入輸出範圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。選出的測試用例，應選取正好等於、剛剛大於、剛剛小於邊界的值，例如，對於在區間min，max的值，測試用例可以記為min，min+，max，max-。
3.錯誤推測法
錯誤推測法是指：在測試程式時，人們可以根據經驗或直覺推測程式中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法。
4.判定表法
又稱為策略表，基於策略表的測試，是功能測試中最嚴密的測試方法。該方法適合於邏輯判斷複雜的場景，通過窮舉條件獲得結果，對結果再進行優化合並，會得到一個判斷清晰的策略表。
5.正交實驗法
用語言描述正交實驗法會很抽象難懂，簡單說，就是在各因素互相獨立的情況下，設計出一種特殊的表格，找出能以少數替代全面的測試用例。
其中，上面所說的特殊表格就是正交表，是按照一定規則生成的表。
雖然說是特殊的表格，實際表現形式跟一般的表格沒有什麼區別，正交表的主要特徵是，「均勻分佈，整齊劃一」，正是因為「均勻」的，所以才能以少數代替全部。
6.一個文字方塊要求輸入6位數位密碼，且對每個賬戶每次只允許出現三次輸入錯誤，對此文字方塊進行測試設計的等價區間有哪些？
1.密碼為空 登入
2.正確輸入（輸入正確的值） 登入
3.錯誤輸入
（輸入錯誤的值，輸入資料例如：特殊符號、英文字母、漢字及非法字元等一些非正確值；輸入方法例如：不足六位，超出六位，最大輸入值） 登入/取消
4.連續錯誤輸入三次以上 （檢視連續錯誤輸入後的提示資訊及結果）
5.其他（是否支援剪貼簿操作，例如：複製/剪下/貼上）
7.什麼時候開始進行效能測試？
效能測試一般分前期階段和後期階段。
前期階段是功能實現後還沒有到系統整合時期。 可以針對功能實現進行效能測試，看看單獨功能實現的響應時間
後期階段是指系統功能通過功能性測試完畢後，到整體的效能測試階段。
8.什麼是效能測試、負載測試、壓力測試？
效能測試（Performance Test）：通常收集所有和測試有關的所有效能，被不同人在不同場合下進行使用。 關注點：how much和how fast
負載測試（Load Test）：負載測試是一種效能測試，指資料在超負荷環境中執行，程式是否能夠承擔。 關注點：how much
壓力測試（Stress Test）： 壓力測試（又叫強度測試）也是一種效能測試，它在系統資源特別低的情況下軟體系統執行情況，目的是找到系統在哪裡失效以及如何失效的地方。
9.簡述Loadrunner的步驟
使用LoaderRunner進行效能測試的幾個步驟：
a、開發指令碼（在Vugen中執行）：涉及到，指令碼的錄製、引數化、事務的新增、檢查點的設定、同步點的設定。loaderRunner指令碼是符合c語言語法的。
b、場景建立（在Controller中執行）：加入指令碼（如果指令碼中有集合點，應該然集合點在這裡生效）、使用者設定。
c、測試結果的分析。