_軟體測試面試必備
啟發法測試策略模型
啟發法測試策略模型是設計測試策略的一套模式。這個模型的直接意圖是提醒測試人員在建立測試時應該要想到的一些東西。最終，這套模型要根據實際情況來定製，並用來在專業測試人員中促進交流、自學、並且更充分的進行有意識的測試。
專案環境包括資源、約束、以及專案中有助於我們測試的其它強力因素，當然也包括阻礙我們做好工作的因素。當面對阻力時，先確認你是否利用了你所有可獲得的資源。
產品元素就是你要測試的東西。軟體是如此的複雜和不可見，以至於你要特別小心的確保你確實測試了產品中需要測試的所有部分。
質量標準是允許你作為乙個測試人員來判斷產品是否有問題的準則、價值觀和**。質量標準是多方面的，並且經常是隱藏的或者是自相矛盾的。
測試技術是建立測試時使用的策略。所有的測試技術都包括對專案環境、產品元素和質量標準的某種分析。
看得見的質量是測試的結果。你永遠不可能知道乙個軟體產品的「實際」質量，但是通過對應用的各種各樣的測試，你能對其質量做乙個比較準確的評估。
1. 常用測試技術
測試技術就是建立測試的方法。這都是些有趣的技術。下面列出了九種常用的技術。
使用「常用技術」這個詞，我是想說這些技術足夠簡單和普遍，並在各種不同的環境中都得到了廣泛的應用。很多特殊技術都是基於這九種方法中的一種或者幾種發展出來的。通過對一種或幾種常用技術用覆蓋的思想來組合，就可以構建成無數的特殊測試技術，這些覆蓋的思想都是來自啟發式測試策略模型中的其它列表中的。
1.1. 功能測試（function testing）
測試系統能夠完成的功能。
找出產品能夠做的事情（功能和子功能）。
判斷你將怎麼才能知道乙個功能是否能正常工作。
測試每個功能，一次測試乙個。
看看每個功能是否做了應該做的，而沒有做不應該做的。
1.2. 域測試（domain testing）
divide and conquer the data。（與等價類劃分＋特殊值的方法類似――譯者注）
分析產品的輸入輸出資料集。
判斷測試的特殊值。考慮邊界值，典型值，常用值，無效值，以及最具代表性的值。
考慮需要在一起測試的資料的組合。
1.3. 壓力測試（stress testing）
征服產品。（在規定的規格條件或者超過規定的規格條件下，測試乙個系統，以評價其行為）
找出在挑戰性的資料或者壓倒性的資源面前對超載或者「破壞」敏感的子系統和功能。
辨識出與那些子系統和功能相關的資料和資源。
選擇或生成測試所需的挑戰性的資料或約束條件的資源：例如，大量或複雜的資料結構，高負載，長時間執行，大量的測試用例，低速儲存器的情況。
1.4. 工作流測試（flow testing）
做完一件事再做另一件。
定義把具體的多個活動首尾鏈結起來測試過程或者高水平的用例。
在兩個測試之間不要重置系統。
改變時間和順序，並且嘗試併發的執行緒。
1.5. 場景測試（scenario testing）
作為乙個強制性的故事來測試。
首先，思考與產品關聯的每一件事。
設計把產品中有意義的和複雜的相互作用包括在內的測試。
乙個好的場景測試是乙個關於一些人或事可能對產品進行怎樣的操作故事。
1.6. 約束測試（claims testing）
驗證每一條約束。
在產品的參考資料中辨識出其包含的約束（隱藏的或直接的）。
分析單個的約束，並明確比較含混的約束。
驗證產品的每條約束是否是正確的。
如果你測試的依據是詳細的規格說明書，就很值得使用這個技術，並且會把產品做的比較標準。
1.7. 使用者測試（user testing）
涉及了使用者的測試。
分清楚使用者的類別和角色。
判斷每類使用者會執行什麼樣的用例，怎樣來執行，以及這樣做的價值。
獲得真實的使用者資料，或者讓真實的使用者來測試。
否則，就要系統地模擬乙個使用者了（當心――想像你是乙個使用者很容易，但是實際上你並不是）。
非常有效的使用者測試應該要涉及各種各樣的使用者和使用者角色。而不是僅僅乙個。
1.8. 風險測試（risk testing）
設想乙個問題，然後去找到它。
這個產品會有哪些種類的問題？
哪種問題是最要緊的？關注那些問題。
如果真有這些問題，你將怎樣來偵測？
做乙個有趣的問題的列表，並特別設計一些測試來發現這些問題。
可能需要一些幫助，包括諮詢顧問、設計文件、以前的缺陷報告、或者使用風險啟發法。
1.9. 自動化測試（automatic testing）
執行大量不同的測試。
尋找適合自動的生成大量的測試的機會。
開發一套自動化的、高速評估的機制。
寫程式來生成、執行並評估這些測試。
2. 專案環境
建立和執行測試是測試專案的核心所在。然而，在你決定要建立什麼樣特定的測試時，專案環境中有很多因素都是關鍵性的。對於下面的每個類別中的因素，都要考慮它們可能會怎樣幫助或阻礙你的測試設計程序。
試著利用好每乙個資源。
2.1. 客戶。這個測試專案中作為客戶的任何人。
你知道誰是你的客戶麼？誰的意見要緊？誰從你做的工作中受益或者利益收到損害？
你同你的客戶聯絡和交流過了麼？可能他們對你的測試有幫助。
可能你的客戶對你要建立和執行的測試有很強烈的想法。
可能客戶之間對測試有相衝突的期望。你可能不得不幫著分析清楚並解決這些衝突。
2.2. 資訊。關於需要被測試的產品或專案的資訊。
有任何的可獲得的工程文件麼？使用者手冊？網上的資料？
這個產品有歷史淵源麼？有已經被修復或者遺留的老問題麼？客戶有經常抱怨什麼？
在你知道怎麼測試該產品之前，你需要更熟悉該產品麼？
你的資訊是最新的麼？你怎樣得知新的或者修改的資訊？
看起來資訊好像異乎尋常少的產品中有任何複雜或者富有挑戰性的部分麼？
2.3. 與開發人員的關係。你怎樣同程式設計師相處。
傲慢型：開發團隊看起來對於產品的任何方面都過於自信？
防衛型：產品中存在開發人員似乎很奇怪地反對進行測試的部分？
融洽：你同開發人員發展出了一種夥伴合作關係？
反饋環路：你能同程式設計師根據需要進行快速交流麼？
反饋：開發人員對你的測試策略怎麼想？
2.4. 測試團隊。任何會執行或支援測試工作的人。
你知道誰會來測試這個專案？
有不在 「測試團隊」中，但可能會有幫助的人麼？有人以前測試過類似的產品，並可能提供一些建議麼？作者？使用者？還是程式設計師？
你有足夠的有正確的技能來執行乙個合理的測試策略的人麼？
這個團隊有沒有基於一些特殊技能或者動機地需要，來刻意執行使用一些測試技術？
需要任何的培訓麼？可以獲得一些什麼培訓？
2.5. 裝置和工具。管理測試所需要的硬體、軟體或者文件。
硬體：我們有執行測試所需要的所有的裝置麼？是否已經安裝好，並準備執行了？
自動化：需要使用任何的自動化測試工具麼？工具是否都準備好了？
探測器：在測試產品時，需要任何輔助性的工具來幫助我們觀察麼？
矩陣和一覽表：有需要跟蹤或者記錄測試的程序的任何文件麼？
2.6. 時間表。專案事件的順序、持續時間和同步。。
測試設計：我們有多少時間？這些測試晚一點建立是否會好一點？
測試執行：測試應該什麼時候執行？是否有些測試要被重複的執行，比如說，在回歸測試中？
開發：版本什麼時候可以來測試，增加了功能，**凍結，等等？
文件：使用者文件什麼時候可以評審？
2.7. 測試要素。被測試的產品物件。。
範圍：在你的測試職責範圍中，包含產品中的哪一部分功能，不包含哪些？
可用性：你有需要被測試的產品麼？
易變性：產品是否在不斷的變化？再次測試時需要些什麼？
新元素：最近，產品中新增或者修改了些什麼？
可測試性：產品的功能和可靠性是否足夠讓你能有效的來進行測試？
將來的版本：你測試中哪部分，如果有的話，必須被設計來應用到產品的將來的版本中？
2.8. 可提交物。測試工程的可以看得見的提交物。
內容：你要提交哪種報告？你會分享你的工作記錄，還是只有結果？
目的：你的提交物是不是作為產品的一部分？有別的其他人要執行你的測試麼？
標準：你有要遵循的一些特別的測試文件標準麼？
**：你要怎樣記錄和並與其它人交流你的報告？
3. 產品元素
乙個產品，最終是要提供給客戶一種體驗或者是乙個解決方案。產品是有很多尺度的。因此，為了獲得好的測試結果，我們必須檢驗這些尺度。
下面所列的每一類，都代表著乙個產品的重要的並且是獨一無二的乙個方面。測試人員如果對這些方面關注得很少的話，很可能會錯過很重要的bug.
3.1. 結構。構成產品本身的任何東西。
**：構成產品的**結構，從可執行到獨特的例程（from executables to individual routines）
介面：子系統間連線和通訊的點。
硬體：對產品必不可少的任何硬體元件。
非可執行的檔案：與多**和程式不同的任何檔案，例如文字檔案，樣品資料，或者幫助檔案。
附屬品：產品中除了軟體和硬體之外的任何其它部分，例如紙質文件，web鏈結和內容，包裝，許可宣告，等等…
3.2. 功能。產品能做的任何事情。
使用者介面：用來給使用者互動資料的任何功能（例如，瀏覽器，顯示介面，資料輸入視窗）。
系統介面：用來給不同於使用者的其它事物互動資料的任何功能，例如，其它程式，硬體，網路，印表機，等等。
應用：用來定義或區分產品或者實現核心需求的任何功能。
演算法：任何計算的功能或者演算法的操作嵌入在其它功能裡面的。
與時間有關的：暫停時間設定；每日或每月報告；每晚的批處理作業；時區；商業假日；利息演算法；條款和擔保期；以及要求精確的功能。
改變：修改或改變某些東西的功能（例如，設定字型，插入剪貼畫，從賬戶中取錢）
startup/shutdown：啟用和初始化或者退出產品時需要用到的任何方法與介面。
多**：聲音，**、**、或者嵌入在產品中任何圖形化的顯示。
出錯處理：偵測錯誤並從錯誤中恢復的任何功能，包括所有的錯誤資訊。
整合互動：產品的功能之間的任何互動或介面。
可測性：提供的可以用來幫助測試的任何功能，例如診斷(diagnostics)，日誌檔案，斷言，測試的選單，等等。
3.3. 資料。產品處理的所有東西。
輸入：產品要處理的任何資料。
輸出：產品處理過的結果資料。
預設值：作為產品的一部分提供的任何資料，或者直接在產品中建立的資料，例如初始化資料庫，系統預設值，等等。
配置項：任何內建的並且會在多個操作持續使用資料。包括產品的狀態或樣式，例如引數設定，檢視模式，文件目錄，等等。
資料排序：資料的任何順序或排列，例如文字的排序，分類或未分類的資料，測試順序。
軟體測試技術及策略 軟體測試面試必備
軟體測試面試必備 由安博測試空間技術中心提供 軟體測試技術及策略 軟體測試的流程 軟體開發全部過程 活動和任務的結構框架，是從可行性研究到需求分析 軟體設計 編碼 測試 軟體發布維護的過程。最後淘汰。測試計畫的前期是否需要需求調研？需要 測試具體分幾個階段，每個階段執行的依據是什麼？計畫測試 需要制...
測試計畫編寫策略 軟體測試面試必備
軟體測試面試必備 測試計畫描述了如何完成測試，有效的測試計畫會驅動測試工作的完成，使測試執行 測試分析以及測試報告的工作開展更加順利。gg xy w j d9z n5z331549 一 測試計畫的重要性和目的 t x o1 v u e l331549 1 測試計畫的重要性 z3y3v x k0 33...
黑盒測試功能測試常用的策略和方法 軟體測試面試必備
2 劃分等價類的方法 下面給出六條確定等價類的原則。在輸入條件規定了取值範圍或值的個數的情況下，則可以確立乙個有效等價類和兩個無效等價類。在輸入條件規定了輸入值的集合或者規定了 必須如何 的條件的情況下，可確立乙個有效等價類和乙個無效等價類。在輸入條件是乙個布林量的情況下，可確定乙個有效等價類和乙個...