做了將近一年的功能測試，現在轉入到了自動化測試來。
功能測試自己做的算不上很精，但基本的流程還算清楚。
功能測試給我的感覺就是－－不受重視。最起碼測試人員沒有受到重視。
聽到最多的就是，產品都會做，產品都能取代你們。
說這話肯定是不懂測試的人。至少肯定不是我一人碰到這種不受重視的待遇。
痛定思痛，行，我學**去，學自動化去，學更多的技術去。只要工作閒下來，俺就去學，報培訓班，自學兩者兼有，看測試理論書籍，學測試工具，
總而言之，言而總之，不虛度光陰，不混日子。更不能被人看不起，為未來，為安全感 ，為可觀的收入，自己不能停止學習的腳步。
上述這些話並沒有抱怨，測試人員自身的技術水平決定了自己是否能得到重視。其實測試這個崗位，說得再重要都不為過。不是因為自己做這個，而是崗位決定的。（如果沒有中紀委，**就會不自覺。如果沒有廉政公署，警員就敢明目張膽的勒索。如果沒有測試，開發就敢不按規範來，反正自己覺得自己開發出來的肯定沒有什麼大問題，是按照需求來的。哈哈。乙個優秀的 開發人員是在測試人員的督促下，慢慢提高自己的規範，提公升自己的技能。這話真不假。當然他想成為優秀的開發人員，不然，就會和測試人員扯犢子了。）
多話不說了，自己總結一下一年多來，對測試流程的概述。
首先，產品立項（會有聚會活動的。通常大吃一次）
等產品人員出文件。（測試這個時候可以先想一下測試計畫，測試需要的硬體資源登記，軟體工具準備。等準備工作要做起來）
產品人員文件出出來後，先進行評審，也就是通常說的需求澄清。（需求文件也是乙個不斷完善的過程，這也是為什麼後期需求會變更，開發要罵人的原因，有時也是客戶的原因，臨時變更）
乙個系統的成敗，產品需求的採集能影響至少50%，我做過乙個失敗的系統，就是因為產品需求採集的原因，導致專案最後失敗，當然，產品也被除名了。）
其次，需求澄清時，產品，開發，測試，運營，客戶等全部到場。評審產品規格書。這個時候，測試要小心，要逐字逐句的揣摩，要理解。配合需求說明書的還有產品原型。這是個好東西，根據它
測試非常容易就畫出思維導圖。這個過程，是討論，修改，再討論，再修改的過程。直到大家都接受為止。現實大部分是客戶能接受，不管研發的死活，只要能開發出來，不管難易。理論與現實總有差距。
再次：需求澄清了，都開始幹活了。開發出計畫，出時間表，測試出計畫，出方案。
測試這時，要畫思維導圖，要寫測試大綱，測試方案，接著就是測試用例。當然，先分工。具體到每個測試人員到系統的某個具體模組。
測試經理收到各個測試人員的方案，導圖，用例後，接著就是經常性的評審，分工，再評審，再修改。直到ok為止。
再接著：測試人員的用例 評審通過後，就等著開發人員出模組了。出乙個測試乙個。直到下乙個模組的出現。
此時的開發改bug的積極性不高。開發大部分喜歡在全部模組或大部分模組出來後，系統出現了雛形後，開發 再統一改bug，前提是不要有一，二級bug。
如果這時開發非常配合，改了bug後，測試人員就回歸測試，跑個小整合之類的。發現乙個提乙個。（這時不要找到乙個bug就大聲叫出來，表現的興高采烈的樣子，估計開發聽到後，一定會橫眉冷對你的。這個時候的開發人員重心放在開發新模組上，根本不願意來配合你改bug，一聽到自己開發的模組出現了bug，心裡都是不爽的。）
隨著新模組開發出來越來越多，測試人員的工作量就直線上公升了。重複提bug，每天就是「點，點，點」，心裡也是很枯燥的。（這個時候如果會自動化，就體現了工具的 價值）
最後：開 發人員開發完了全部的模組，測試人員就要進行大規模的整合測試（公司測試人員多的話，活還能 及時幹完，如果人少，測試就要苦逼了。），剛開發出來的系統，剛做前幾次整合測試時，每 天不提十幾個bug，好像都不正常了。只有經過了多輪測試，每天發現的bug數才能下降。如果經過了多輪測試，每天發現的bug數還沒有下降，或者原來沒有的模組也出現了bug，或者，改過的bug回歸通過了，又出現了。這個時候，就要反思開發人員的開發水平了，或者開發人員版本管理方面是不是出現 了問題，或者測試環境是不是有問題了。
不去反思的話，bug是測試不完的。或者還要考慮業務流程是否符合設計的需求了。（如果是這樣，問題就大了。）
再最後：bug也改的差不多了，沒有一，二級bug了，至少是沒有發現，3，4級bug也控制在bug總數的5%以內了，（當然bug等級定義要清晰，這樣才不會提高，降低bug的嚴重程度）。
再做最後上線前回歸測試吧。加班，加班，再加班，這個時候的專案組要加班到很晚，而且要持續一周左右。
等客戶來驗收了，有需求文件，合同，用例 來驗收吧。來付款吧。
一切順利的話，大家都好。開慶功會。否則，挨屌是少不了的。（我以前公司開發同事的口頭禪－－不求有功，但求不被屌。哈哈，太沒自信了。）
上述的流程是概述，也有時不按這樣的規範來。實際中，改了又改，測了又測。再改，再測。例如敏捷開發，真的很類似於邊做邊改的。哪有什麼需求文件給你來參照。完全就是產品嘴上得來的資訊。一周一兩個功能模組的開發。以這樣的進度。沒有時間，畢竟時間就是生命。當然，測試的時間就更少了。
測試前要搭建測試環境，測試結束後要寫測試報告。這倆步不能漏了。
關於Iometer測試的一些總結
前段時間一直在用iometer對一家雲儲存進行測試。剛剛開始測試的時候，儲存廠商推薦我們採用iometer進行測試。那會不明就裡，說那就用iometer吧。在測試的過程中，發現儲存廠商的產品基本可以提供千兆網絡卡的極限頻寬，大約穩定可以提供110mb左右的頻寬流量。本來我們系統設計中，所有的寫入頻寬...
一些關於測試的問題
1.有一根不均勻的繩全部燒完用1個小時，現在有很多材質，規格完全相同的繩，怎麼用燒繩法計時1個小時15分鐘？我的回答 用一根繩做標記，另一根繩，兩頭開始燒，燒到一塊的位置，表在第一根繩上，這是半個小時的時間同理找到1 4個小時的位置，進而可以得到乙個小時15分鐘啊 2.什麼是冒煙測試？冒煙測試 sm...
關於SVGKit匯入的一些流程
因為專案的需要,最近一直在研究svgkit.在匯入的時候遇到了一些問題.網上資料也很少.現在總結一下,以便供需要的人參考.先說明一下我使用的xcode7.具體有以下步驟 1 在 2 決定你的專案需要的是svgkit的靜態庫即可,還是需要將svgkit的源 一併拷入專案中.a.如果只是需要靜態庫,那麼...