軟體測試的學習方法
軟體測試就是利用測試工具按照測試方案和流程對產品進行功能和效能測試，那麼如何學習軟體測試呢?別走開，接下來，小編就和大家分享，希望對大家有幫助!
：
一、抓包工具各自的特點：
1、httpwatch
特點：嵌入瀏覽器的抓包工具，結合瀏覽器使用介面清晰，方便易用，且提供自動化api，開啟--錄製--儲存結果檔案;但只能檢視抓取的資訊，不能自定義修改;
2、fiddler
特點：客戶端抓包工具，通過代理方式獲取瀏覽器資訊，且支援自定義請求***composer***，自定義伺服器返回等;但介面不太直觀，且只能抓取http協議;
3、firebug
特點：fixfox自帶的外掛，與httpwatch功能非常相似，且支援控制跟蹤審查元素，可以修改控制元件名字等，功能十分強大，抓包只是firebug其中很小一個功能;
4、科來
特點：此工具直接監視網絡卡，既能抓還能修改，抓取內容更多更詳細，不僅僅支援http協議，還支援tcp/udp/ftp/pop3等協議，適合對協議要求相對較高的抓包活動;
二、闡述作業系統中的系統呼叫、中斷、上下文切換這三個概念的含義
系統呼叫：
在作業系統上如果想要執行你的程式，就得靠自己從面向底層硬體的程式碼編起，但這件事太枯燥，且不是每個人都能做到，這樣作業系統就替我們做這些事情，把硬體封裝，統一提供一套介面，這些介面就是系統呼叫;
系統呼叫把應用程式的請求傳給核心，當作業系統接收到系統呼叫請求後，會讓處理器進入核心模式，呼叫相應的核心函式完成所需的處理，當處理完成後，作業系統會讓處理器返回使用者模式，來執行使用者程式碼，提高了我們寫程式的效率，所以系統呼叫此時充當的角色就是一個介面，外面由使用者程式呼叫，內部連線核心的其他部分，共同實現使用者的請求;
上下文：
上下文簡單來說就是一個環境，相對於程序而言，就是程序執行時的環境，具體來說就是各個變數和資料，包括程序開啟的檔案，記憶體資訊等;當發生程序排程時，導致程序切換時，程序的執行環境也應及時切換，CPU切換到另外一個程序需要儲存當前程序的狀態並恢復另一個程序的狀態：當前執行任務轉為就緒狀態，另一個被選定的就緒任務成為當前任務，上下文切換包括儲存當前任務的執行環境，恢復將要執行任務的執行環境;上下文切換就是這樣一個過程，他允許CPU記錄並恢復各種正在執行程式的狀態，使它能夠完成切換操作;
通常在三種情況下可能會發生上下文切換：中斷處理，多工處理，使用者態切換;
中斷：
中斷是為了裝置與CPU之間的通訊，是實現多道程式設計的必要條件，是CPU對系統發生的某個事件作出一種反應，CPU暫停正在執行的程式，保留現場後自動轉去處理相應的事件，處理完該事件後，到適當的時候返回斷點，繼續完成被打斷的程式;例如：讀盤，讀一半，盤有問題，無法讀了，產生中斷，解決後，程式恢復，軟體錯誤也會中斷;特點：中斷是隨機的，可恢復的，自動進行處理的;
三、作業系統中的程序的概念和程序都有哪些狀態
程序是作業系統結構的基礎，是一次程式的執行，是一個程式及其資料在處理機上順序執行時發生的活動;程式是一個沒有生命的實體，只有處理器賦予程式生命時，它才能成為一個活動的實體，我們稱其為程序。
程序狀態：
就緒狀態：程序已獲取處理器外的所需資源，等待分配處理器資源，只要分配了處理器程序就可執行。
執行狀態：程序佔用處理器資源;
阻塞狀態：由於程序等待某種條件***如I/O操作或程序同步***，在條件滿足之前無法繼續執行
四、 DNS根伺服器的概念是什麼?
當客戶端通過瀏覽器訪問網站時候，輸入的是域名需要把域名轉化為網路識別的ip地址***即DNS解析***，首先會查詢本地域名快取，如果不存在，向上一級當地ISP的DNS查詢，比如你用的聯通網路，會去查詢聯通的本地快取，如果仍然查不到，繼續上一級，最終到根目錄伺服器，其實根目錄伺服器並沒有具體的域名對應資訊，但他可以告訴你去哪臺伺服器去找，直到最終找到為止;
至於全球的13組根域名伺服器，1個為主根伺服器，放置在美國。其餘12個均為輔根伺服器，其中9個放置在美國，歐洲2個，位於英國和瑞典，亞洲1個，位於日本，由網際網路域名與號碼分配機構ICANN統一管理。
五、網路拓撲結構一般分幾層，具體叫什麼?
分三層，接入層，匯聚層，核心層;
六、效能測試的概念是什麼?負載測試、壓力測試、配置測試呢?
效能測試：在一定的負載情況下，系統的相應時間等特性是否滿足特定的效能需求;
負載測試：通過測試系統在資源超負荷情況下的表現，以發現設計上的錯誤或驗證系統的負載能力;Linux系統中通過top命令檢視，load average:第一分鐘內平均負載***待處理的執行緒數***，第五分鐘內平均負載，第十五分鐘內平均負載;業界定義值超過cpu核數的4倍，這個時候負載就重了;
壓力測試：指被測系統在一定資源***CPU/記憶體***飽和的情況下，系統的執行情況;與負載測試的區別是沒有超負荷，在效能允許的範圍內測試;
可靠性測試：被測系統在一定負載情況下長時間執行下執行情況;
配置測試：通過調整被測試系統軟硬體的不同配置，找到一個最合適被測系統的配置或者獲得被測系統在不同配置下的執行情況;比如配置執行緒數，由於系統本身的特性，比如上下文切換影響效能的考慮，並不是越多越好，而多少合適，是通過配置測試實驗出哪個配置效能最好;
七、 用自己的話描述TPS、PV、UV的基本含義
TPS：每秒事務數，單位時間內被系統處理的事務數量，這裡的事務只指一個動作;
PV：訪問一個URL產生一個PV，不管此使用者是同一個還是多個，只要點選了URL就有一個PV，即頁面訪問量;
UV：獨立使用者訪問量，單個使用者訪問站點的所有頁面，此使用者可以產生多個PV，但算一個UV;日誌分析中一般通過user-agent和IP來判斷是否是一個使用者;
八、併發使用者數和線上使用者數的區別是什麼?
併發使用者數：多個使用者同時操作，會對系統造成負載;
線上使用者數：系統線上人數，包括操作的人數和只登陸不操作***對系統不會造成負載***的使用者;
九、用自己的話描述選擇效能測試工具需要關注哪些方面
1、從成本上考慮，包括工具成本和學習成本，工具成本是工具是否開源，因為購買工具也是很花錢的，不是每個公司都可以支撐得了。學習成本就是在職人員是否具備使用這個工具的能力，相應的語言編寫能力等，如果沒有需要花費多久時間去學習等等，這都需要成本的;選擇成本要在可接受範圍內去選擇工具;
2、通訊協議的考慮，效能測試工具都是基於協議的，如果被測系統是基於標準的TCP/IP協議，那可以有很多工具選擇，如SMTP/FTP/HTTP等可以選擇相應的工具;如果被測系統是基於自有協議的，效能測試工具可能不支援，那就需要自己想辦法去實現;
3、生命力，選擇效能測試工具需要考慮他的活力，軟體更新週期，市場佔有率等，就是發展前途如何，可以持久使用，避免不必要的損失;
4、跨平臺 ，類似於JAVA的跨平臺能力，適合更多平臺的客戶;
軟體測試的原則：
1.軟體開發人員即程式設計師應當避免測試自己的程式不管是程式設計師還是開發小組都應當避免測試自己的程式或者本組開發的功能模組。若條件允許，應當由獨立於開發組和客戶的第三方測試組或測試機構來進行軟體測試。但這並不是說程式設計師不能測試自己的程式，而且更加鼓勵程式設計師進行除錯，因為測試由別人來進行會更加有效、客觀，並且容易成功，而允許程式設計師自己除錯也會更加有效和針對性。
2. 應儘早地和不斷地進行軟體測試
應當把軟體測試貫穿到整個軟體開發的過程中，而不應該把軟體測試看作是其過程中的一個獨立階段。因為在軟體開發的每一環節都有可能產生意想不到的問題，其影響因素有很多，比如軟體本身的抽象性和複雜性、軟體所涉及問題的複雜性、軟體開發各個階段工作的多樣性，以及各層次工作人員的配合關係等。所以要堅持軟體開發各階段的技術評審，把錯誤克服在早期，從而減少成本，提高軟體質量。
3.對測試用例要有正確的態度：第一，測試用例應當由測試輸入資料和預期輸出結果這兩部分組成;第二，在設計測試用例時，不僅要考慮合理的輸入條件，更要注意不合理的輸入條件。因為軟體投入實際執行中，往往不遵守正常的使用方法，卻進行了一些甚至大量的意外輸入導致軟體一時半時不能做出適當的反應，就很容易產生一系列的問題，輕則輸出錯誤的結果，重則癱瘓失效!因此常用一些不合理的輸入條件來發現更多的鮮為人知的軟體缺陷。
4.人以群分，物以類聚，軟體測試也不例外，一定要充分注意軟體測試中的群集現象，也可以認為是“80-20原則”。不要以為發現幾個錯誤並且解決這些問題之後，就不需要測試了。反而這裡是錯誤群集的地方，對這段程式要重點測試，以提高測試投資的效益。
5.嚴格執行測試計劃，排除測試的隨意性，以避免發生疏漏或者重複無效的工作。
6.應當對每一個測試結果進行全面檢查。一定要全面地、仔細地檢查測試結果，但常常被人們忽略，導致許多錯誤被遺漏。
7.妥善儲存測試用例、測試計劃、測試報告和最終分析報告，以備迴歸測試及維護之用。
在遵守以上原則的基礎上進行軟體測試，可以以最少的時間和人力找出軟體中的各種缺陷，從而達到保證軟體質量的目的。