軟體測試經典測試題（4）

在您以往的工作中，一條軟體缺陷（或者叫Bug）記錄都包含了哪些內容？如何提交高質量的軟體缺陷（Bug）記錄？

一條Bug記錄最基本應包含：

bug編號；
bug嚴重級別，優先順序；
bug產生的模組；
首先要有bug摘要，闡述bug大體的內容；
bug對應的版本；
bug詳細現象描述，包括一些截圖、錄影....等等；
bug出現時的測試環境，產生的條件即對應操作步驟；

高質量的Bug記錄： 

通用UI要統一、準確
缺陷報告的UI要與測試的軟體UI保持一致，便於查詢定位。

1. 儘量使用業界慣用的表達術語和表達方法
   使用業界慣用的表達術語和表達方法，保證表達準確，體現專業化。
2. 每條缺陷報告只包括一個缺陷
   每條缺陷報告只包括一個缺陷，可以使缺陷修正者迅速定位一個缺陷，集中精力每次只修正一個缺陷。校驗者每次只校驗一個缺陷是否已經正確修正。
3. 不可重現的缺陷也要報告
   首先缺陷報告必須展示重現缺陷的能力。不可重現的缺陷要盡力重現，若盡力之後仍不能重現，仍然要報告此缺陷，但在報告中要註明無法再現，缺陷出現的頻率。
4. 明確指明缺陷型別
   根據缺陷的現象，總結判斷缺陷的型別。例如，即功能缺陷、介面缺陷、資料缺陷，合理化建議這是最常見的缺陷或缺陷型別，其他形式的缺陷或缺陷也從屬於其中某種形式。
5. 明確指明缺陷嚴重等級和優先等級
   時刻明確嚴重等級和優先等級之間的差別。高嚴重問題可能不值得解決，小裝飾性問題可能被當作高優先順序。
6. 描述 (Description) ，簡潔、準確，完整，揭示缺陷實質，記錄缺陷或缺陷出現的位置
   描述要準確反映缺陷的本質內容，簡短明瞭。為了便於在軟體缺陷管理資料庫中尋找制定的測試缺陷，包含缺陷發生時的使用者介面（UI）是個良好的習慣。例如記錄對話方塊的標題、選單、按鈕等控制元件的名稱。
7. 短行之間使用自動數字序號，使用相同的字型、字號、行間距
   短行之間使用自動數字序號，使用相同的字型、字號、行間距，可以保證各條記錄格式一致，做到規範專業。
8. 每一個步驟儘量只記錄一個操作
   保證簡潔、條理井然，容易重複操作步驟。
9. 確認步驟完整，準確，簡短
   保證快速準確的重複缺陷，“完整”即沒有缺漏，“準確”即步驟正確，“簡短”即沒有多餘的步驟。
10. 根據缺陷，可選擇是否進行圖象捕捉
    為了直觀的觀察缺陷或缺陷現象，通常需要附加缺陷或缺陷出現的介面，以圖片的形式作為附件附著在記錄的“附件”部分。為了節省空間，又能真實反映缺陷或缺陷本質，可以捕捉缺陷或缺陷產生時的全螢幕，活動視窗和區域性區域。為了迅速定位、修正缺陷或缺陷位置，通常要求附加中文對照圖。
     附加必要的特殊文件和個人建議和註解l
    如果開啟某個特殊的文件而產生的缺陷或缺陷，則必須附加該文件，從而可以迅速再現缺陷或缺陷。有時，為了使缺陷或缺陷修正者進一步明確缺陷或缺陷的表現，可以附加個人的修改建議或註解。
11. 檢查拼寫和語法缺陷
    在提交每條缺陷或缺陷之前，檢查拼寫和語法，確保內容正確，正確的描述缺陷。
12. 儘量使用短語和短句，避免複雜句型句式
    軟體缺陷管理資料庫的目的是便於定位缺陷，因此，要求客觀的描述操作步驟，不需要修飾性的詞彙和複雜的句型，增強可讀性。
    以上概括了報告測試缺陷的規範要求，隨著軟體的測試要求不同，測試者經過長期測試，積累了相應的測試經驗，將會逐漸養成良好的專業習慣，不斷補充新的規範書寫要求。此外，經常閱讀、學習其他測試工程師的測試缺陷報告，結合自己以前的測試缺陷報告進行對比和思考，可以不斷提高技巧。
13. 缺陷描述內容
    缺陷描述的內容可以包含缺陷操作步驟，實際結果和期望結果。操作步驟可以方便開發人員再現缺陷進行修正，有些開發的再現缺陷能力很差，雖然他明白你所指的缺陷，但就是無法再現特別是對系統不熟悉的新加入開發人員，介紹步驟可以方便他們再現。實際結果可以讓開發明白錯誤是什麼，期望結果可以讓開發瞭解正確的結果應該是如何。</pre>

黑盒測試和白盒測試是軟體測試的兩種基本方法，請分別說明各自的優點和缺點！ 

黑盒測試的優點有：比較簡單，不需要了解程式內部的程式碼及實現；與軟體的內部實現無關； 從使用者角度出發，能很容易的知道使用者會用到哪些功能，會遇到哪些問題；基於軟體開發文件，所以也能知道軟體實現了文件中的哪些功能；在做軟體自動化測試時較為方便。

黑盒測試的缺點有：不可能覆蓋所有的程式碼，覆蓋率較低，大概只能達到總程式碼量的30%；自動化測試的複用性較低。

白盒測試的優點有：幫助軟體測試人員增大程式碼的覆蓋率，提高程式碼的質量，發現程式碼中隱 藏的問題。

白盒測試的缺點有：程式執行會有很多不同的路徑，不可能測試所有的執行路徑；測試基於程式碼，只能測試開發人員做的對不對，而不能知道設計的正確與否，可能會漏掉一些功能需求；系統龐大時，測試開銷會非常大。

如何測試一個紙杯？

功能度：用水杯裝水看漏不漏；水能不能被喝到

安全性：杯子有沒有毒或細菌

可靠性：杯子從不同高度落下的損壞程度

可移植性：杯子在不同的地方、溫度等環境下是否都可以正常使用

相容性：杯子是否能夠容納果汁、白水、酒精、汽油等

易用性：杯子是否燙手、是否有防滑措施、是否方便飲用

使用者文件：使用手冊是否對杯子的用法、限制、使用條件等有詳細描述

疲勞測試：將杯子盛上水（案例一）放24小時檢查洩漏時間和情況；盛上汽油（案例二）放24小時檢查洩漏時間和情況等

壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透

測試計劃工作的目的是什麼？測試計劃文件的內容應該包括什麼？其中哪些是最重要的？

軟體測試計劃是指導測試過程的綱領性檔案：

• 領導能夠根據測試計劃進行巨集觀調控，進行相應資源配置等
• 測試人員能夠了解整個專案測試情況以及專案測試不同階段的所要進行的工作等
• 便於其他人員瞭解測試人員的工作內容，進行有關配合工作

包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計劃，參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。

測試計劃編寫6要素（5W1H）：

• why——為什麼要進行這些測試；
• what—測試哪些方面，不同階段的工作內容；
• when—測試不同階段的起止時間；
• where—相應文件，缺陷的存放位置，測試環境等；
• who—專案有關人員組成，安排哪些測試人員進行測試；
• how—如何去做，使用哪些測試工具以及測試方法進行測試

測試計劃和測試詳細規格、測試用例之間是戰略和戰術的關係，測試計劃主要從巨集觀上規劃測試活動的範圍、方法和資源配置，而測試詳細規格、測試用例是完成測試任務的具體戰術。所以其中最重要的是測試測試策略和測試方法（最好是能先評審）。

黑盒測試的測試用例常見設計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設計工作中的應用。

1）等價類劃分： 等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對於揭露程式中的錯誤都是等效的.併合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個資料作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

2）邊界值分析法：是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料.

3）錯誤猜測法：基於經驗和直覺推測程式中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想: 列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模組中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入資料和輸出資料為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

4）因果圖方法：前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯絡, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）. 因果圖方法最終生成的就是判定表. 它適合於檢查程式輸入條件的各種組合情況.

5）正交表分析法：可能因為大量的引數的組合而引起測試用例數量上的激增，同時，這些測試用例並沒有明顯的優先順序上的差距，而測試人員又無法完成這麼多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到儘量少的用例覆蓋儘量大的範圍的可能性。

6）場景分析方法：指根據使用者場景來模擬使用者的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。

7）狀態圖法：通過輸入條件和系統需求說明得到被測系統的所有狀態，通過輸入條件和狀態得出輸出條件；通過輸入條件、輸出條件和狀態得出被測系統的測試用例。

8）大綱法：大綱法是一種著眼於需求的方法，為了列出各種測試條件，就將需求轉換為大綱的形式。大綱表示為樹狀結構，在根和每個葉子結點之間存在唯一的路徑。大綱中的每條路徑定義了一個特定的輸入條件集合，用於定義測試用例。樹中葉子的數目或大綱中的路徑給出了測試所有功能所需測試用例的大致數量。

詳細的描述一個測試活動完整的過程。（供參考，本答案主要是瀑布模型的做法）

專案經理通過和客戶的交流，完成需求文件，由開發人員和測試人員共同完成需求文件的評審，評審的內容包括：需求描述不清楚的地方和可能有明顯衝突或者無法實現的功能的地方。專案經理通過綜合開發人員，測試人員以及客戶的意見，完成專案計劃。然後SQA進入專案，開始進行統計和跟蹤

開發人員根據需求文件完成需求分析文件，測試人員進行評審，評審的主要內容包括是否有遺漏或雙方理解不同的地方。測試人員完成測試計劃文件，測試計劃包括的內容上面有描述。

測試人員根據修改好的需求分析文件開始寫測試用例，同時開發人員完成概要設計文件，詳細設計文件。此兩份文件成為測試人員撰寫測試用例的補充材料。

測試用例完成後，測試和開發需要進行評審。

測試人員搭建環境

開發人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發現BUG後提交給BugZilla。

開發提交第二個版本，包括Bug Fix以及增加了部分功能，測試人員進行測試。

重複上面的工作，一般是3-4個版本後BUG數量減少，達到出貨的要求。

如果有客戶反饋的問題，需要測試人員協助重現並重新測試。

BUG.管理工具的跟蹤過程（用BugZilla為例子）

測試人員發現了BUG，提交到Bugzilla中，狀態為new，BUG的接受者為開發介面人員

開發介面將BUG分配給相關的模組的開發人員，狀態修改為已分配，開發人員和測試確認BUG，如果是本人的BUG，則設定為接收；如果是別的開發人員的問題，則轉發出去，由下一個開發人員來進行此行為；如果認為不是問題，則需要大家討論並確認後，拒絕這個BUG，然後測試人員關閉此問題。

如果開發人員接受了BUG，並修改好以後，將BUG狀態修改為已修復，並告知測試在哪個版本中可以測試。

測試人員在新版本中測試，如果發現問題依然存在，則拒絕驗證；如果已經修復，則關閉BUG。

您認為在測試人員同開發人員的溝通過程中，如何提高溝通的效率和改善溝通的效果？維持測試人員同開發團隊中其他成員良好的人際關係的關鍵是什麼？

儘量面對面的溝通，其次是能直接通過電話溝通，如果只能通過Email等非及時溝通工具的話，強調必須對特性的理解深刻以及能表達清楚。

運用一些測試管理工具如TestDirector進行管理也是較有效的方法，同時要注意在TestDirector中對BUG有準確的描述。

在團隊中建立測試人員與開發人員良好溝通中注意以下幾點：

一真誠、二是團隊精神、三是在專業上有共同語言、四是要對事不對人，工作至上

當然也可以通過直接指出一些小問題，而不是進入BUG Tracking System來增加對方的好感。

你對測試最大的興趣在哪裡？為什麼？

回答這個面試題，沒有固定統一的答案，但可能是許多企業都會問到的。提供以下答案供考：

最大的興趣，感覺這是一個有挑戰性的工作；

測試是一個經驗行業，工作越久越能感覺到做好測試的難度和樂趣

通過自己的工作，能使軟體產品越來越完善，從中體會到樂趣

回答此類問題注意以下幾個方面：

儘可能的切合招聘企業的技術路線來表達你的興趣，例如該企業是資料庫應用的企業，那麼表示你的興趣在資料庫的測試，並且希望通過測試提升自己的資料庫掌握能力。

表明你做測試的目的是為了提升能力，也是為了更好的做好測試；提升能力不是為了以後轉開發或其他的，除非用人企業有這樣的安排。

不要過多的表達你的興趣在招聘企業的範疇這外。比如招聘企業是做財務軟體的，可是你表現出來的是對遊戲軟體的興趣；或招聘是做JAVA開發的，而你的興趣是在C類語言程式的開發。

你自認為測試的優勢在哪裡？

該面試也沒有固定不變的答案，但可參考以下幾點，並結合自身特點：

有韌性、有耐心、做事有條理性、喜歡面對挑戰、有信心做好每一件事情、較強的溝通能力、從以前的經理處都得到了很好的評價表明我做的很好

簡述你在以前的工作中做過哪些事情，比較熟悉什麼。參考答案如下。

我過去的主要工作是系統測試和自動化測試。在系統測試中，主要是對BOSS系統的業務邏輯功能，以及軟交換系統的Class 5特性進行測試。效能測試中，主要是進行的壓力測試，在各個不同數量請求的情況下，獲取系統響應時間以及系統資源消耗情況。自動化測試主要是通過自己寫指令碼以及一些第三方工具的結合來測試軟交換的特性測試。

在測試中，我感覺對使用者需求的完全準確的理解非常重要。另外，就是對BUG的管理，要以需求為依據，並不是所有BUG均需要修改。

測試工作需要耐心和細緻，因為在新版本中，雖然多數原來發現的BUG得到了修復，但原來正確的功能也可能變得不正確。因此要注重迭代測試和迴歸測試。

在C/C++.中static.有什麼用途？（請至少說明兩種）
在函式體，一個被宣告為靜態的變數在這一函式被呼叫過程中維持其值不變。

1. 在模組內（但在函式體外），一個被宣告為靜態的變數可以被模組內所用函式訪問，但不能被模組外其它函式訪問。它是一個本地的全域性變數。
2. 在模組內，一個被宣告為靜態的函式只可被這一模組內的其它函式呼叫。那就是，這個函式被限制在宣告它的模組的本地範圍內使用