測試基礎：

爲何須要軟件測試？

不少時候：

• 每當LOL更新一個新英雄或者某個英雄太強，場場五殺，因爲過度變態，遊戲玩家紛紛投訴，這個英雄太bug了！趕忙把刀妹削弱了！這個英雄的手太長了，讓咱們削弱刀妹吧！
• 菜逼如你在玩火熱的吃雞（絕地求生）時，要不是有系統保護，可能在落地以前就被幹死了，落了地還沒見着人，就被啪啪啪給打死了，你確定大喊一聲，這他孃的有bug！快把老子的8倍鏡拿過來，看看是哪一個菜逼開的槍！！！
• 再好比你們如今都喜歡用微信支付寶，若是你滴掃一下，你的微信提示你扣款了998元，可是商家說沒收到，咋辦？是跑路仍是再交一次錢？這個就是嚴重的bug！！

一款軟件的誕生經歷不少個階段，每一個階段都有不一樣的人員參與，因此最終產品會或多或少的問題，所以爲了保證軟件的可用性，因此，咱們必須通過測試環節，減小軟件的問題。

哪一個程序員也不敢說寫的程序沒有bug！可是咱們使用的軟件，基本上不多見到bug，這和軟件測試是分不開的。

so，一個提供業務訪問的軟件，必須在嚴格測試，經過層層測試環境才能夠正式的上線。就像遊戲同樣，也基本是先提出內測版，最後纔是公測版，就是公司在驗證程序的正確性！！

爲何選擇軟件測試行業？

 

發展前景

就目前而言，相對於國外的軟件測試行業來講，國內的測試行業稍顯落後，因此國內的軟件測試行業對於專業的測試人員需求慢慢變大。

裝逼語錄

有人喜歡創造世界，因此，他們作了程序員。

有人喜歡拯救世界，因此，他們作了測試員。

其餘

知乎上已經有了優秀的答案。

爲何不讓開發本身作測試？

 

首先，開發不是不能作測試，甚至有的測試人員以前都作過開發。

而是說，軟件測試和軟件開發分屬軟件行業中兩個不一樣的技術方向。因此，一個半吊子開發不如一個專業的測試！這就是專業度的問題了。

從邏輯角度來講，開發人員大多數時間都在思考如何實現具體的功能。而做爲測試人員，大多數時間都站在用戶的角度思考如何挑出軟件的問題。

從測試力度來講，軟件對於開發人員來講，那就是本身的孩子，我家孩子怎麼可能有毛病？你家孩子纔有毛病！這就會致使本身測試本身寫的軟件，下手可能不夠狠！

什麼是測試？

 

Glenford J. Myers在《軟件測試的藝術》一書中有這樣的一個定義：測試是爲了發現錯誤而執行程序的過程。

另外，軟件專家溫伯格和Cem Kaner也提出了本身對軟件測試的理解，在溫伯格的《完美軟件》一書中提到：測試是一個獲取信息的過程，用來下降決策風險。Cem Kaner教授也提出：軟件測試是一種技術調查，其目的是向關係人提供有關產品（軟件、系統或服務）質量的實驗信息。

除此以外，IEEE（電氣和電子工程師協會，全稱是Institute of Electrical and Electronics Engineers）和ISO（國際標準化組織，全稱是International Organization for Standardization）也不甘落後的發表了本身的見解。1983年IEEE曾這樣定義軟件測試：軟件測試是使用人工或者自動化手段來運行或者測試定某個系統的過程，檢驗它是否知足規定的需求或是弄清楚預期結果與實際結果之間的差異，從這個定義中咱們能夠看出，軟件測試不只爲了發現錯誤，並且須要驗證軟件是否知足了規定的需求。ISO 29119標準也嘗試標準化軟件測試。提到： Software testing should focus on providing information about a software product and finding as many defects as possible, as early as possible in development process, under given constraints of costs and schedule，其中有兩個重要的觀點：一個是儘量的早（early），一個是成本（cost）受限。測試發現bug應儘量的早，這樣形成的影響越小，修復成本越低。而測試活動每每是在時間和人力成本受限的狀況下進行，在有限的資源下，測試人員應該有的放矢，對測試對象的進行選擇排序，測試技術進行選擇組合使用，這也是測試策略方面的東西。

說點人能聽懂的。當你寫的代碼越多，你就越認同測試，曾經聽過一個很貼切的比喻：寫程序的人就像在造沒有護欄的橋，本身去走那確定安全無虞，那怕摸黑也不至於掉河裏去；測試則像給橋修護欄的，讓橋的普通使用者也能像開發那樣來去自如。從這一點上說，測試遠比開發重要。

總結，軟件測試的定義：經過手工或者相關工具，對被測對象進行測試操做。從而驗證明際與預期結果是否存在差別。

軟件測試的做用？

 

經過測試工做能夠發現並修復軟件中存在的缺陷，從而提升用戶對產品的使用信心。

測試能夠經過記錄軟件運行過程當中產生的一些數據，從而爲決策提供數據支持。

測試能夠下降同類型產品開發遇到的問題風險。

軟件測試的誕生

 

這個標題讓我想起了我喜歡的一首歌Shallow，學什麼習，這個天氣不適合學習，只適合Move your body，是否是很happy。OK，讓咱們隨着音樂的節奏回到.......

在20世紀50年代，英國計算機科學家圖靈已提出了程序測試的定義，測試是驗證程序正確性的一種實驗形式。
直到60-70年代，軟件危機出現後，人們意識到測試的意義。軟件測試慢慢的發展起來......

軟件測試出現緣由

 

軟件複雜度

程序代碼的複雜度，軟件產品的併發性，複雜性愈來愈高，對程序的正確性檢測也愈來愈高

行業競爭大

因爲用戶審美提高與需求愈來愈高，如今一個新聞類app，就有百度新聞，網易新聞，趣頭條，今日頭條，各家公司都想作到完美，用戶喜歡本身的產品，那就得從易用性，美觀性，趣味性，快速性，等等等等方面超過其餘的產品，那麼大公司都會配備專門的功能測試崗位，性能測試崗位，乃至於更強大的測試開發崗位。

軟件測試的發展

 

國內處於起步和迅猛發展的階段。
大公司很是重視測試，初創型小公司對測試關注較少。
主要仍是手工測試爲主，自動化測試爲輔。

國外的軟件測試基本成熟，軟件企業很是重視軟件測試部門。
測試流程化體系嚴謹。
一線大公司還會成立軟件測試中心，服務於子公司的軟件開發。

軟件測試的目標

 

經過軟件測試暴露軟件中隱藏的錯誤和問題，便於考慮是否使用該產品。
例如咱們去買手機，總得反反覆覆的觀察，這個手機的CPU性能怎麼樣？內存是多大的？拍照怎麼樣？可是，反覆觀察有xx用？領導不換iPhone X，你能用的上iPhone 8？

軟件開發者的角度
經過軟件測試證實軟件中不存在錯誤和問題，給與本身產品質量足夠的信心。

一個成功的測試，是不懈的挖掘軟件的錯誤，不斷的完善產品。

知足用戶需求是產品成功的關鍵點。

確保交付的產品符合用戶的需求。

在產品上線前儘量的發現和修復bug。

用戶角度

快看，搖了半天，終於有人加我微信了！

缺乏軟件測試發生的事故

 

軟件中的Bug很是使人討厭。但同時有缺陷的軟件還有可能形成重大甚至致命的事故。下面是一些很是有名的軟件事故：

• 1962年，水手號火箭的致命BUG。經濟損失：1850萬美圓
• 1962年，攜帶空間探測器的水手1號火箭前往金星，在起飛後不久就偏離了預約航線。任務控制在起飛293秒後摧毀了火箭。事故的原由就在於一名程序員把一條手寫的公式抄寫爲錯誤的計算機代碼。從而將火箭引導偏離了航向。
• 1979年，新西蘭航空公司的一架客機因計算機控制的自動飛行系統發生錯亂，撞上了阿爾卑斯山，致使257名乘客遇難。幾乎引起的第三次世界大戰。
• 1983年, 蘇聯導彈預警系統錯誤地報告遭到美國發射的5枚導彈攻擊. 但幸運的是,當時的負責人認爲若是美國真的要攻擊的話, 發射的決不僅是5枚導彈. 最終沒有釀成大災難。
• 2012年，蘋果IOS 6系統首次使用地圖服務，因爲諸多定位出現錯誤，引起大批量用戶投訴，48小時內有1000萬個用戶投訴Google地圖。
• 拼多多近期出現一個重大bug，程序員誤改了代碼，本來100元的中國移動充值卡，一分錢就能夠購買，很短的時間內就損失了大量金額財產，這已經觸犯了刑事責任。

所以公司中進行軟件測試，是必須的！

軟件測試常見的誤區

 

• 調試和測試是同樣的。
• 測試組應該爲保證質量負責。
• 過度依賴beta測試（驗收測試）。
• 把測試做爲新員工入職的一個過渡過程。
• 把不合格的開發人員安排作測試。
• 關注於測試的執行而忽略測試的設計。
• 測試自動化是萬能的。
• 測試是能夠窮盡的。
• 測試爲了保證軟件的正確性。
• 測試是枯燥乏味，缺少創造力的工做。
• 過渡測試度量軟件的質量。

軟件測試的主要工做

 

• 檢查代碼，評審開發文檔。
• 進行測試設計、寫做測試文檔、測試計劃、測試方案、測試用例等等。
• 執行測試、發現軟件缺陷，提交缺陷報告，並追蹤缺陷修復的過程。

測試原則

 

測試原則是指在執行測試工做時必需要遵照的一些規則：

• 測試證實軟件存在缺陷，不管執行什麼樣的測試操做，都能保證當前軟件是有缺陷的。
• 不能執行窮盡測試，有些功能是沒有辦法將全部的狀況都羅列出來，因此任何的測試操做都有結束的時間。
• 缺陷存在羣集現象，首先要了解一個二八理論，即對於軟件的功能來講，核心功能佔20%，非核心功能佔80%（固然，不是絕對的）。那麼在測試中，咱們會集中測試20%的核心功能。因此，這部分發現缺陷的機率會遠高於80%非核心部分。也所以咱們遇到的缺陷就都會集中在20%的核心功能這塊。
• 某些測試須要依賴特殊的環境，毋庸置疑，有些測試依賴極端的條件，這種條件有時候很難知足。
• 測試應儘早介入，越早的發現和解決軟件存在的缺陷，咱們應該儘量的儘早展開測試。
• 殺蟲劑現象，一樣的測試用例不能重複執行屢次，由於軟件會對它產生免疫。好比說，你用3 * 3測試出代碼不等於9，把這個缺陷提交給開發，開發隨後解決了這個bug，那咱們再測試的時候，就不要用3 * 3來測試了，由於開發在改bug的時候，想法設法的讓3 * 3 = 9，因此，一樣的用例，軟件會對它產生免疫。
• 不存在缺陷謬論，任何軟件不多是完美的。

測試對象

 

對於當前的測試行業來講，咱們最常測試的主體就是軟件（主體功能），但須要咱們測試的也不只僅是功能需求測試。咱們能夠將軟件分爲三個部分組成：

• 功能集合
• 使用說明書
• 配置數據

一款軟件的誕生會經歷不一樣的過程，咱們將整個過程分爲不一樣的階段，而後每一個階段都會有相應的測試對象。那麼每一個階段咱們能進行什麼測試呢？

• 需求分析階段，各類需求規格說明書，好比說以當前的技術手段可否實現，市場上是否存在相似的軟件。這個時候會產生相應的說明書。
• 軟件架構設計，由CTO或一把手，整體構建軟件的架構，而後生成API接口文檔（接口測試），而後交由專門的開發去具體實現。
• 具體編碼階段，這個時候，咱們的測試對象就是源代碼，（但這對測試水平要求過高），因此，咱們會進行相應的白盒測試、單元測試。
• 系統功能使用，軟件功能主體測試，也就是目前測試行業作的作多的一種測試，測試人員充當用戶進行軟件使用、測試。

軟件架構

 

所謂的軟件架構，簡單理解爲是用來指導軟件開發的一種思想，目前來講，最多見的兩種架構模式：

• B/S，瀏覽器和服務端。
• C/S，客戶端和服務端。

兩種架構的比較：

• 效率，B/S架構的數據都是由服務器端處理，瀏覽器只負責展現結果，因此對於服務端壓力相對較大，而C/S架構的客戶端能夠承擔一些數據處理，因此執行效率高。
• 安全，B/S架構的數據都根據HTTP協議進行的，因此安全性相對於C/S架構來講，安全性相對低一些。
• 升級，B/S架構的升級只需升級服務端便可，而C/S架構則須要兩端都須要升級更新。
• 開發成本，相對於B/S架構來講，C/S架構的客戶端也須要本身開發，因此成本會高一些。

再來補充兩個知識點：

瀏覽器

瀏覽器本質上是一款軟件，安裝在操做系統之上，爲用戶提供網頁瀏覽服務，目前，世界主流的五大生產廠商：

• IE（Windows Internet Explorer）：IE4以上版本都是Trident內核。因爲壟斷性，IE在很長一段時間內沒有更新，致使兩個後果：一是IE與W3C標準脫節，二是Trident內核大量的bug問題沒獲得及時解決。因此這就給了其餘瀏覽器機會，好比firefox等。也正是這些緣由，使Web前端開發人員大費折，特別是IE6正處在新舊交替的關鍵地方（已經逐漸被捨棄），目前微軟家的最新瀏覽器edge的內核也是採用谷歌家的內核了。
• Chrome（Google Chrome）：谷歌瀏覽器以前一直使用蘋果的webkit內核，可是如今它與蘋果內核分道揚鑣，本身開創了新的blink內核，這個內核也在被歐鵬（opera瀏覽器）共同採用和開發。
• Safari（蘋果）：使用的是蘋果公司本身的內核webkit
• Opera（歐朋）：最開始是presto，目和Chrome一塊兒使用blink。
• Firefox（Mozilla Firefox）：gecko。

國內的瀏覽器及內核：

• 搜狗瀏覽器：兼容模式（IE：Trident）和高速模式（webkit）
• 傲遊瀏覽器：兼容模式（IE：Trident）和高速模式（webkit）
• QQ瀏覽器：普通模式（IE：Trident）和極速模式（webkit）
• 360極速瀏覽器：基於谷歌（Chromium）和IE內核
• 360安全瀏覽器：IE內核

對於瀏覽器來講，最核心的技術，就是瀏覽器內核，固然，僅作了解便可。

圖片

常見的圖片類型有：

• jpg（jpeg），能夠高度保留圖片色彩信息的圖片格式，常見與互聯網客戶端。
• png，該類型的圖片，能夠實現透明。
• gif，圖片所佔體積小，能夠實現動圖。
• psd，分層的圖片。

常見項目組織架構

 

項目組通常由項目經理領導並負責指定項目計劃，分配任務。

參與人員：

• 分析人員。
• 設計人員。
• 開發人員。
• 測試人員。
• 配置管理人員。軟件研發過程的倉庫管理員，包括產品，文檔等等。
• SQA，軟件質量保證，監控整個軟件研發過程。

軟件測試用例

 

生活中，處處都是測試案例，好比你買個手機，買個顯示器，都要測試一下，開關機、屏幕是否有漏光，按鍵是否好使、這些都是測試用例。

咱們須要知道測什麼和怎麼測這兩個問題。

什麼是測試用例

 

測試用例的定義

測試用例（Test Case）是爲特定的目的而設計的一組測試輸入、執行條件和預期的結果，以便測試是否知足某個特定需求，經過大量的測試用例來檢驗軟件的運行效果，它是指導測試工做進行的重要依據。

舉個例子

好比咱們買個電腦，要進行測試。

測試的前提條件

按下開機鍵，至關於輸入一組測試數據，執行的條件是，是否達到開機的前提條件，好比電池是否有電，或者外接電源是否接入。

測試過程

按下開機鍵。

預期結果

當咱們按下開機鍵，順利的啓動成功，那麼在有電的前提下，啓動成功就是咱們的預期結果。

經過上面的測試過程，就會發現，測試用例主要解決的就是測什麼？怎麼測？

爲何須要測試用例

 

測試用例的優點在於：

• 避免盲目測試，提升測試效率，使測試活動規範有序
• 減輕測試設計的工做量，減小回歸測試的複雜程度
• 根據測試用例的多少和執行難度，估算測試工做量，便於追蹤項目的時間進度和資源分配。

測試用例的意義

 

• 測試用例是軟件測試的核心。
  • 軟件測試的重要性是毋庸置疑的，測試用例是測試工做的指導，是軟件測試質量穩定的根本保障。
  • 影響軟件測試的因素不少，如軟件自己的複雜程度，開發質量，測試方法和技術的運用。也有客觀因素存在，如人員變更，環境，情緒等。
• 評估測試結果的基準。
  測試用例的經過率以及錯誤率，是測試結束的一個重要依據，用來判斷該軟件測試結果是否能夠經過，可否達到上線的標準。
• 保證測試的時候不遺漏測試功能點。能夠對測試工做進行牽引。
• 在編寫測試用例的過程，能夠熟悉需求，對系統架構或者業務流程有一個總體深刻的瞭解。

測試用例的生命週期

 

測試環境設計

 

測試環境(TE)

• 爲了運行被測軟件、完成測試工做所必須的硬件、軟件和網絡環境的集合。
• 穩定可控的測試環境可使測試人員花費較少的時間，完成測試用例的執行。

測試環境內容包括

• 硬件環境
• 軟件環境
• 網絡環境
• 測試數據
• 測試工具

測試環境設計原則

• 儘量用真實的環境，少用模擬器和虛擬機。
• 機器配置根據軟件不一樣，不得低於軟件運行最低要求。
• 選擇主流的操做系統以及軟件平臺，例如ios系統 Android系統。
• 測試環境要乾淨、獨立、排除干擾。例如無用的殺毒軟件，無用的播放器等等，性能測試中，突然蹦出個漏洞修復程序，那必然影響測試結果。

測試環境所需的知識

• 常見操做系統安裝使用
• 安裝程序所需驅動，解決驅動報錯問題
• 數據庫使用
• 瀏覽器調試
• 模擬器和虛擬機的使用
• 系統鏡像和備份與還原工具的使用

測試用例的八大要素

• 用例編號：產品名字-測試階段
• 測試項目：對應一個功能模塊
• 測試標題：直接對測試點進行細化得出
• 重要級別：高/中/低
• 預置條件：須要知足一些前提條件，不然用例沒法執行
• 測試輸入：須要加工的輸入信息，根據具體狀況設計
• 操做步驟：明確給出每一個步驟的描述，執行人員根據該步驟執行工做
• 預期結果：根據預期輸出對比實際結果，判斷被測對象是否符合需求。
• 實際結果：根據實際結果，填寫報告。(可寫可不寫)

輸出測試用例

• excel
• word
• HTML

最後，上圖：

測試力度

 

測試用例力度

測試用例能夠寫的很簡單，固然也能夠寫的很是複雜。

• 最簡單的測試用例是測試的綱要，僅僅指出要測試的內容。
  測試用例寫的過於簡單，則可能失去了測試用例的意義。過於簡單的測試用例設計其實並無進行「設計」，只是須要把測試的功能模塊記錄下來而已，它的做用僅僅是在測試過程當中做爲一個簡單的測試計劃，提醒測試人員測試的主要功能包括哪些而已。
• 最複雜的測試用例則會指定輸入的每項數據，期待的結果即檢驗方法，具體到界面元素的操做步驟，指定測試的方法和工具等。

測試用例寫得過於複雜或詳細，會帶來兩個問題：一個是效率問題，另外一個是維護成本問題。另外，測試用例設計的過於詳細，留給測試執行人員的思考空間就比較少，容易限制測試人員的思惟。
ps:大多數的測試團隊編寫的測試用例的力度介於二者之間。

測試用例的本質
測試用例的設計本質（測什麼？怎麼測？）應該是在設計的過程當中理解需求，檢驗需求，並把對軟件系統的測試方法的思路記錄下來，以便指導未來的測試。
基於需求的測試用例設計：

• 基於需求的用例場景來設計測試用例是最直接有效的方法，由於它直接覆蓋了需求，而需求是軟件的根本，驗證對需求的覆蓋是軟件測試的根本目的。
• 要把測試用例當成活的文檔，由於需求是活的，善變的。所以在設計測試用例方面應該要把敏捷方法的及時響應變動比遵循計劃更有價值這一原則體現出來。

不要認爲測試用例設計是一個階段，測試用例的設計也須要迭代，在軟件開發的不一樣階段都要回來從新評審和完善測試用例。

軟件測試計劃書

 

計劃書是什麼

測試計劃是一個敘述了預約的測試活動的範圍、途徑、資源以及進度安排的文檔，咱們親切地稱爲測試計劃書。
此文檔確認了測試項、被測特徵、測試任務、人員安排，以及任何偶發事件的風險。

爲何要指定測試計劃書

定製測試計劃使得軟件測試是有計劃，有組織的軟件質量保證活動。若是沒有計劃，工做就會很鬆散，隨意。

測試計劃的意義

 

測試計劃

• 測試範圍
• 測試策略
• 測試資源
• 測試進度
• 測試風險

測試流程規範

• 測試模型
• 傳統金字塔形
• 冰淇淋模型
• 菱形模型
• 測試過程改進

參考：http://www.testclass.net/post/test_level

測試計劃書內容包含哪些內容

• 人力以及時間資源分配
• 責任劃分
• 風險控制

測試目標

 

產品的質量目標

• 測試已實現的產品是否達到設計的要求。
• 產品規定的操做是否實現，運行是否穩定。

測試活動的質量目標

• 全部的測試用例所有執行。
• 全部自動化腳本都已經經過。
• 全部嚴重級別的缺陷已經被修復。

資源配置

 

人力資源

• 須要多少名測試人員
• 測試人員須要具有什麼技能
• 是否須要崗前培訓

測試環境資源配置
硬件資源：服務器，計算機，手機，打印機
軟件資源：不一樣平臺的操做系統，數據庫軟件，多種瀏覽器
網絡環境：在什麼網絡環境下測試，是內網仍是外網
測試工具：都是使用哪些工具

風險控制

 

風險指：不可預料的後果，如事件，危險，威脅等特殊狀況的發生。

客觀性風險：

• 客觀性因素，沒法規避的風險：
• 人手不夠了，短時間也沒法招到合適的人
• 同事生病請假了
• 開發團隊不能如期交付代碼
• 測試環境所需的環境，腳本，數據等沒有提供好，沒法進行。
• 沒法徹底控制風險，只能遵循規律，下降風險形成的影響。

如何制定測試計劃

 

1.任務送達

• 測試經理接到軟件測試需求書和需求說明

2.分析測試任務

• 充分理解被測試軟件的需求。
• 評估被測試軟件的進度，狀態，複雜度和風險

3.資源規劃

• 組件測試團隊
• 準備人力資源

4.制定測試計劃

• 研究肯定測試計劃的各項內容

5.評審測試計劃

• 測試團隊共同參與評審測試計劃。

5W1H方法

 

what 對象

• 測試什麼
• 測試是什麼類型
• 被測軟件有什麼特色
• 測試環境是什麼

when 時間

• 何時開始測
• 何時提交缺陷報告
• 何時結束測試

why 緣由

• 爲何要作此項測試

who 有誰參與

• 軟件提供給誰去用
• 誰來執行測試用例

where 場所

• 在哪裏進行軟件測試
• 測試到哪個步驟算是完成

how 方法

• 如何進行測試
• 如何編寫測試用例書
• 如何控制風險

工做經驗之談

 

計劃是死的，人是活的....

• 目的性引導去規劃測試進度，而不只僅是爲了寫計劃而計劃。
• 保證本身的計劃書能夠隨着變化而調整。
• 測試計劃須要整個測試團隊來共同評審和執行。

圖解軟件測試計劃

 

這年頭，沒有圖過不了啊，雖然朕不看！

軟件計劃報告

 

最後，來看軟件計劃報告。
軟件測試基礎流程：通常是測試主管編寫測試計劃，測試計劃是指在作完需求分析後，在開始整個測試工做以前的準備計劃工做。

遵循5W + 1H原則進行測試：

• why 測試目的
• what 測試範圍
• when 測試進度安排
• who 測試人員
• where 測試環境
• how 測試方法 測試工具
• 產品測試風險評估

測試報告範圍：

• 測試範圍
• 測試環境
• 遺留bug
• 測試用例覆蓋率
• bug統計與分析
• 風險檢測
• 版本測試評估
• 發佈的建議

軟件兼容性

 

5W1H思想很流行啊！由於咱們將基於這個思想來闡述軟件的兼容性測試！

what，什麼是軟件兼容性測試

 

軟件兼容性測試既是測試被測試軟件可以與操做系統、網絡環境、瀏覽器、相關其餘軟件（包括數據庫）、外接設備等可以友好合做，不出現UI界面顯示異常、同等分辨率下顯示異常、改變顏色及顯示大小改變、排版出錯、CSS格式及顏色錯誤、滾動條相關問題、內容或者標籤重疊、表格或者框架不完整等等兼容性軟件缺陷。兼容性測試包括向前兼容性測試和向後兼容性測試。

向前兼容性測試(forward compatibility testing)：測試的應用程序或軟件在新的或即將到來的版本，而且應用程序的早期版本可以打開較新版本中的文件並忽略早期版本中未實現的功能。好比USB1.0可以兼容USB3.0，或者是MS office2003可以使用轉換器打開MS office2007的文件，並忽略MS office2007 的新功能。

向後兼容性測試(backward compatibility testing)：測試的應用程序或者軟件處於舊版本，而且應用程序的新版本可以順利處理舊版本的程序數據。好比說USB3.0兼容USB1.0，或者MS office 2007可以打開MS office 2003的文件。

why，爲何要進行軟件兼容性測試

 

從兼容性測試的概念中得知，軟件的運行與操做系統類型及版本（windows、linux、mac等）、瀏覽器種類及版本（IE、火狐、谷歌等）、網絡環境的帶寬、數據庫種類和版本（SQL、DB二、MySQL、Oracle等）、外接設備（打印機、傳真機等）、其餘相關軟件（MS office、SharePoint等）等因素有關，那麼最終用戶使用的環境咱們不得而知，但在資源和時間有限的狀況下，咱們要儘量的模擬用戶使用的環境去確保咱們的開發軟件可以正確使用。因此兼容性測試是檢查的是全部平臺的應用程序的工做方式。一般開發團隊和測試團隊的測試是在單一平臺中進行展開。可是，一旦發佈應用程序，客戶能夠在不一樣的平臺測試咱們的產品，他們可能會發如今應用程序中的錯誤，要減小這些問題，在全部平臺上測試應用程序是很重要的。換句話說，當最終的用戶發現了應用程序的缺陷，這須要花費不少時間去開發補丁包去彌補錯誤的後果，可是常常發佈產品補丁包會使用戶感受不安，因此產品的兼容性測試是無可避免的。

when，何時開始軟件兼容性測試

 

當build已經相對穩定的時候就進行兼容性測試。

where，軟件兼容性測試都要測什麼

 

以瀏覽器兼容性測試實例展開，討論在軟件兼容性測試中要測試什麼：

• CSS、HTML和XHTML驗證
• 頁面驗證
• 字體大小和字體樣式驗證
• 帶有HTML字符編碼的特殊字符
• 全部圖像對齊
• 頁眉和頁腳
• 頁面對齊
• 控件對齊(項目符號、單選按鈕、複選框應在各類瀏覽器上選中)。
• 應該正確地測試頁面放大和縮小
• 驗證提交給數據庫的信息
• HTML視頻格式:視頻格式應該驗證,由於全部的IE9瀏覽器不支持全部格式的視頻例子給mp4,只支持firefox支持mp4和.webm若是咱們Chrome那麼它支持幾乎mp4, .webm .ogm和其餘視頻格式。
• 文本對齊方式
• Flash內容應該進行測試
• 在關閉cookie和瀏覽器Javascript時測試頁面，在打開cookie和瀏覽器Javascript時測試頁面
• 外部站點開發的插件:一些jQuery插件可能沒法正常工做，好比IE8中的打印功能或播放視頻時的旋轉木馬。
• CMS兼容性:確保瞭解內容管理系統支持的瀏覽器，並主要關注該瀏覽器而不是其餘瀏覽器。

綜上所述，對於瀏覽器的兼容性測試，咱們要驗證的是頁面、字體大小和樣式、特殊字符的編碼、圖像對齊與否、頁面的頭尾、頁面對齊與否、文本對齊與否、控件的對齊狀況、頁面的放大放小測試、數據庫提交信息驗證、HTML視頻播放格式驗證、外部網站開發的插件驗證、關閉cookies和javascript後的頁面驗證等。還有其餘的驗證內容，能夠經過探索性測試中提到的一些方法，進行測試。如破壞測試法，懶漢測試法，一送一測試法，配角測試法，賣點測試法，指南測試法，超模測試法等等，能夠將探索性測試用於軟件的兼容性測試，更加有方向的進行兼容性測試。

who，誰來執行軟件兼容性測試

 

測試人員和最終用戶。測試人員只能模擬出大部分用戶使用的環境進行軟件的兼容性測試，儘量的使大多數的用戶在使用中出現較少的問題，因爲時間和資源的有限性，不可以模擬出全部用戶的環境，因此兼容性測試前期是測試人員進行的大範圍的掃除盲點，加上後期用戶的共同努力，來提高軟件質量。

how，怎樣執行兼容性測試

 

在執行兼容性測試以前要理解，在什麼平臺，怎樣的環境，去驗證哪一個軟件的兼容性，去根據對軟件以及環境的認識，去制定有測試計劃和測試策略的test plan (Test plan中包括了Test Scope, Test Strategy, Hardware, Test Schedule )，引入一些經常使用的測試方法，如探索性測試，手工測試，自動化測試，冒煙測試等方法，將軟件的兼容性測試作活，不那麼生硬，儘量的找到更多以前沒有發現的bug。 指定完test plan，就是執行這一輪的兼容性測試，配置相應的環境，採用局部自動化測試 + 手工測試的原則，去檢測軟件是否存在兼容性問題，完成這一輪CT，後signoff。

轉載：軟件兼容性測試

版本控制

 

引入版本控制的緣由

 

錯誤觀念：軟件測試不須要版本控制
測試人員在測試過程當中發現的bug提交給開發人員，開發人員在對提交的bug進行修改，bug修改後開發人員會將修改後的代碼放入當前的軟件版本之中，這樣一來二去，會致使軟件測試版本發佈過於頻繁，測試版本不穩定，致使修改過的bug再次出現，測試重複、失效和混亂。測試進度沒法保證，同時不便於追溯跟蹤問題。
緣由是：對於修改過的代碼，不可以保證他們必定是正確的，極可能在開發人員修改過以後，仍然是錯誤的，或者在修改過以後仍然會給軟件帶來別的問題，測試人員對新提交的代碼以及以前的代碼都要再次進行驗證，進行排錯，來確保不會所以而帶來新的隱患，新的漏洞，致使大量重複測試。
引入版本控制的好處：提升開發和測試的效率，提升軟件版本穩定性，便於追溯問題。

版本控制的定義

 

版本控制對象
開發提交給測試的產品版本。
測試人員提交的bug到了開發人員手中以後，開發人員針對這些bug進行修復工做，而且將修改後的代碼放入程序中，做爲新的軟件版本，而不能直接替換到現有的測試版本中去。
版本控制定義
測試版本的交付在專人控制之下，對每次測試的版本有明確的標識（新增長的功能、修復的bug等），不一樣版本能夠看到穩定度趨勢，每一個版本的測試狀態。

版本控制方法

 

制定合理版本發佈計劃，增強版本控制管理
協商測試版本發佈及發佈頻率：制定版本進度計劃，該計劃中包括開發團隊提交不一樣版本的計劃時間、每一個版本中新增功能模塊列表、提交版本的要求、修復的bug列表等。
測試版本發佈基礎：代碼評估（代碼review），版本控制的文檔（標識新增或修改的功能、修復的bug、可以很方便的跟蹤和監控測試版本的執行）
測試啓動條件：功能是否開發完成、有沒有進行自測（避免出現版本質量太差）、軟件版本說明。
提測後注意事項：非錯誤修正（Bug fix）的修改，必須說明（如代碼重構）；錯誤修正涉及的代碼，明確迴歸範圍和影響範圍（避免修復bug是修改共同文件，引發全局問題）。

強化測試准入條件
測試啓動條件：功能是否開發完成、有沒有進行自測（自測報告，避免出現版本質量太差）、軟件版本說明（清楚每一次版本更新都修改了什麼，會對哪些功能形成影響）。
開展冒煙測試：保證系統能跑的起來，不至於讓測試工做作到一半忽然出現錯誤致使業務中斷，若是最基本的測試都有問題則直接打回。

（開發人員在試圖解決一個問題的時候，形成了其它功能模塊一系列的連鎖反應，緣由多是隻集中考慮了一開始的那個問題，而忽略其它的問題，這就可能引發了新的Bug。）

冒煙測試的經過標準：基本的功能和流程經過就能夠。（測試場景/點能夠提供）
軟件提測後注意事項：非bug fix的修改，必須周知（如重構），Bug fix涉及的代碼，代碼review，明確迴歸範圍，減小質量隱患。

強化bug管理
bug內容（發現版本，對應人員，發現模塊，迴歸次數，bug關閉的版本號），能夠分析不一樣版本和不一樣模塊bug走勢。
發現這次迭代範圍外的以前遺留的bug，測試記錄後，和開發及項目管理人員商討是否解決，解決方式（代碼限制OR操做說明中限制），是否佔用這次迭代的開發時間。

版本控制文檔管理工做
版本信息、測試記錄、測試結果（開發和測試活動的追溯）

最後，就是要作到及時溝通

版本控制評價標準

 

這個沒的說，效率和質量。

如何下降測試的輪次

 

測版本最多不超過4輪測試
通常控制在3輪。通常在2到3個版本時，就很難發現缺陷。版本越多，質量隱患越大。
保證開發和測試的獨立性
打的包，部署的環境。測試環境和開發環境分開，儘可能作到測試數據不會被開發人員修改。
明確測試需求
需求功能點所有實現，若是有需求不能在規定時間完成，須要在需求階段提出，而不是在測試階段完善需求，從而加長了開發和測試時間，影響效率。
細化提測標準
開發到什麼程度能夠接受測試。
預測試
達到送測標準，在服務器上取下測試的版本，編譯、部署後，對部分主要的功能進行預測試，若是預測試經過了，就能夠開始測試。若是預測試不經過，就打回開發部門修改好後再預測試，直到預測試經過爲止。
控制需求的變動
變動了軟件需求必定要有記錄和說明，相應的測試用例及時追加和維護。
進行bug分級
界面和易用性的bug等到開發完成和重要bug解決完畢再改。
加強質量意識
上線前臨時改代碼修復問題或者臨時口頭追加的變更要有記錄，要通知一下。

測試環境維護

 

開發文檔和產品需求文檔生成或者變更後請周知一下，保證測試用戶及時編寫和維護。
測試環境最好是專人維護（開發、運維、測試），頻繁和擅自發布新功能或者修改是不可取的。保證版本的統一性很重要。
測試人員提交的bug到了開發人員手中以後，開發人員針對這些bug進行修復工做，而且將修改後的代碼放入程序中，做爲新的軟件版本，而不能直接替換到現有的測試版本中去。
代碼提交 ，review後再部署，直接打包部署的代碼不能保證完整 （提交衝突，合代碼後發佈失敗等）

轉載：軟件開發&測試版本控制說明

經常使用測試工具

 

扯了半天淡，咱們用什麼來作測試呢？
測試管理工具（項目流程管理）

• 惠普HP QC TD
• 國外工具 JIRA 使用最多，易用性強
• 國內工具 禪道

功能測試工具（自動化腳本測試）（黑盒）

• 惠普HP QTP(腳本錄製工具，解放重複的點擊等工做) vbs語言腳本
• Selenium

性能測試工具（黑盒）

• HP LoadRunner (使用人數最多，易用，收費軟件)
• Apache Jmeter(免費)

代碼測試工具（白盒測試）

• JUnit

開源測試管理工具：

• Bugfree，BugFree是借鑑微軟的研發流程和Bug管理理念，使用PHP+MySQL獨立寫出的一個Bug管理 系統。簡單實用、免費而且開放源代碼(遵循GNU GPL)。 命名BugFree 有兩層意思：一是但願軟件中的缺陷愈來愈少直到沒有，Free嘛；二是表示它是免費且開放源代碼的，你們能夠自由使用傳播
• Bugzilla，Bugzilla 是一個開源的缺陷跟蹤系統（Bug-Tracking System），它能夠管理軟件開發中缺陷的提交（new），修復（resolve），關閉（close）等整個生命週期。Bugzilla是一開源Bug Tracking System，是專門爲Unix定製開發的。
• TestLink，TestLink 是基於web的測試用例管理系統，主要功能是測試用例的建立、管理和執行，而且還提供了一些簡單的統計功能。
• mantis，缺陷管理平臺Mantis，也作MantisBT，全稱Mantis Bug Tracker。Mantis是一個基於PHP技術的輕量級的開源缺陷跟蹤系統，以Web操做的形式提供項目管理及缺陷跟蹤服務。在功能上、實用性上足以知足中小型項目的管理及跟蹤。更重要的是其開源，不須要負擔任何費用。

開源功能自動化測試工具：

• Watir，Watir全稱是Web Application Testing in Ruby，發音相似water。它是一種基於網頁模式的自動化功能測試工具。
• Selenium，Selenium 是一個用於Web應用程序測試的工具。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操做同樣。支持的瀏覽器包括IE（7, 8, 9, 10, 11），Mozilla Firefox，Safari，Google Chrome，Opera等。這個工具的主要功能包括：測試與瀏覽器的兼容性——測試你的應用程序看是否可以很好得工做在不一樣瀏覽器和操做系統之上。測試系統功能——建立迴歸測試檢驗軟件功能和用戶需求。支持自動錄製動做和自動生成 .Net、Java、Perl等不一樣語言的測試腳本。
• MaxQ，是開源的Web功能測試工具。
• WebInject，WebInject是一個用於自動測試web應用程序和web服務的免費工具。它能夠用來測試具備HTTP接口的各個系統組件(JSP、ASP、CGI、PHP、AJAX、servlet、HTML表單、XML/SOAP Web服務、REST等)，而且能夠用做測試工具來建立一套[HTTP級別]自動化功能、驗收和迴歸測試。測試工具容許您運行許多測試用例並收集/報告結果。WebInject提供實時結果顯示，也能夠用於監視系統響應時間。WebInject能夠用做一個完整的測試框架，由WebInject用戶界面(GUI)控制。能夠選擇，它能夠用做一個獨立的測試運行器(文本/控制檯應用程序)，能夠從其餘測試框架或應用程序集成和調用它。

開源性能自動化測試工具：

• Jmeter，Apache JMeter是Apache組織開發的基於Java的壓力測試工具。用於對軟件作壓力測試，它最初被設計用於Web應用測試，但後來擴展到其餘測試領域。 它能夠用於測試靜態和動態資源，例如靜態文件、Java 小服務程序、CGI 腳本、Java 對象、數據庫、FTP 服務器， 等等。JMeter 能夠用於對服務器、網絡或對象模擬巨大的負載，來自不一樣壓力類別下測試它們的強度和分析總體性能。另外，JMeter可以對應用程序作功能/迴歸測試，經過建立帶有斷言的腳原本驗證你的程序返回了你指望的結果。爲了最大限度的靈活性，JMeter容許使用正則表達式建立斷言。Apache jmeter 能夠用於對靜態的和動態的資源（文件，Servlet，Perl腳本，java 對象，數據庫和查詢，FTP服務器等等）的性能進行測試。它能夠用於對服務器、網絡或對象模擬繁重的負載來測試它們的強度或分析不一樣壓力類型下的總體性能。你可使用它作性能的圖形分析或在大併發負載測試你的服務器/腳本/對象。
• OpenSTA，OpenSTA是一個免費的、源代碼開放的性能測試工具,基於CORBA(Common Object Request Broker Architecture)的結構體系。它是經過虛擬一個代理服務器,使用專用腳本控制語言,記錄經過代理服務器的一切HTTP/Straffic。測試工程師經過分析OpenSTA的性能指標收集器收集的各項性能指標,以及HTTP數據,對被測試系統的性能進行分析。
• DBMonster， DBMonster 是一個Java的開源項目，經過JDBC方式鏈接數據庫，所以能夠在任何支持Java和JDBC的平臺上運行。DBMonster開發的原意是爲數據庫 開發者服務，能夠協助產生大量的規則或不規則數據，便於數據庫開發者基於這些數據進行數據庫的調優。DBMonster經過兩個XML文件（配置文件 和 schema文件）控制數據產生的行爲，配置文件指明須要鏈接的數據庫、鏈接使用的用戶名和口令、須要操做的sheme、重試次數等全局設置，而 scheme文件則指明針對每張數據表的每一個字段產生數據的規則。
• Web Application Load Simulator，LoadSim是一個web應用程序負載模擬器。它容許您建立模擬並在web服務器上運行這些模擬。

軟件測試工程師

 

軟件測試工程師的技能要求

 

情商素養

• 責任心
• 良好的溝通能力，協做能力
• 耐心與細心
• 嚴謹的態度和態度

專業技能

• 軟件工程學
• 軟件測試流程
• 軟件測試技術
• 軟件測試管理
• 軟件開發基礎

軟件基礎知識

• 計算機硬件瞭解
• 操做系統
• 數據庫
• 網絡

業務能力

• 對產品需求的瞭解
• 業務的邏輯清晰
• 站在用戶角度思考產品

軟件測試工程師的職業發展

 

互聯網職業分類

 

互聯網行業的薪資水準相對較高，入行一年超過其餘行業薪資很正常。
互聯網行業究竟有哪些職位呢，又分別適合哪些傳統行業轉型？

1. 產品經理（Product Manager）
2. UI設計
3. 前端設計（css/html/js）
4. 後端（python/golang/java）
5. DBA(mysql/oracle)
6. 運維（linux）
7. 測試（software testing）
8. 算法工程師
9. 大數據工程師（Hadoop）
10. Android、IOS
11. 架構師
12. 運營