軟件測試工做近兩年來的感想和將來規劃（一）

想一想從去年2013-3月份實習開始，到如今進入公司參與測試工做實際上已經快兩年了，說實話，當初找測試工做的緣由真的很簡單（不知道大部分人是否是都這樣？）：快畢業了！學過一些編程知識（c,c++等），知道一些數據庫的操做，想趕忙找份工做！發現作開發還不行，那就找測試吧！----當時真是這麼想的。結果就是大四下學期，幾乎住在了廣工教六（由於我是汕大的，又想在廣州找份工做），花了一個半月的時間，簡直渾天暗地，苦攻測試知識（主攻這個），數據庫知識，操做系統，編程，數據結構，面試題；邊找工做，邊看書，那時候招聘會多，趕場趕得厲害，累到爆！面試了不少，被刷掉不少次，最後感受實在堅持不下去了，想回校的時候，終於拿了兩份offer，拿到第二份offer的時候，簡直高興的狂奔（是的，當時的狀況就是這樣的，我在廣工體育館上面狂奔了！），後面就進了第二份offer的公司，開始與測試結緣了！

  關於應屆生面試經驗，其實很難講，我以爲首先你得具有最起碼的你職位所需求的東西，如測試，那就基本的測試理論、測試方法、測試用例設計方法，還有多去作一些面試例子題等，而後，你有一些編程能力，數據庫能力，邏輯思惟好，有些算法基礎這些就最好不過了（固然你在這些方面很好的話，去作開發吧，哈哈），最後，我想說的是要自信！和有本身的想法或堅持（也能夠說是原則吧），關於軟測面試的書，本人推薦一本，感受還不錯，蔡爲東的《軟件工程師面試指導》，裏面基本的都有講到。

  下面開始吐槽這兩年來（兩年工做經歷，加班太多，算三年工做經驗吧）的工做感想，一進來，正常的業務培訓，簡單的工做內容，去公司所負責的網點見習，分小組，每週總結啥的，很正常的實習經歷；不得不說，實習期間除了錢少（一個月1K！只能用來交房租和吃飯），公司的氛圍，人員相處，特別是咱們測試部的人，真的很是nice，讓我這個白白嫩嫩的應屆生以爲，"哇靠!這就是公司啊！跟我想象中的強烈競爭很不同,這公司，不錯！",接下來就是回校答辯，回來正式入職！開始真正的工做了。

  正常的工做，這裏我能夠分三部分來說：

  首先，能夠先說下目前咱們的測試流程（我所瞭解到的，版本負責人應該比我清楚，到時候問下，更新下）：

  開發那邊，我知道的就是：需求--需求評審（參加過幾回）--設計人員根據需求，設計版本任務--版本負責人分配任務給開發人員--開發人員負責開發、處理bug和一些運維的事

  測試會從需求評審階段（主要是根據經驗，看需求的合理性，需求與產品實現能力，需求會對產品及用戶形成的影響）介入--而後根據版本任務內容，進行評審（主要是評審版本內容的測試優先級，並根據測試人員的定位，分配任務，評審任務完成時間，進度安排，人員協調等）--各個測試人員完成本身版本內容的用例編寫設計（忙的時候就不寫了，唉~）--用例評審（各個測試人員講下本身的用例，而後其餘人給建議，這個其實很重要，有利於測人員瞭解每一個人的測試用例設計思路，並相應的瞭解每一個人測試內容涉及到的知識，同時，集思廣益，有利於用例的廣度和深度，發現更多的bug，但由於趕進度和時間的問題，老是作的不多！）--執行首輪測試，bug的跟蹤管理（咱們這邊用的是TD）--交叉測試（就是每一個人去測別人的測試項，其實這個有利有弊，很差的是，分到本身徹底不熟的項，還得找首輪測這項的人瞭解下，而後再從新想測試用例，再測，很花時間；重要的是當首輪測試人員和開發都不在的時候，你能夠想象那時候的痛苦！好處就是，不一樣人的測試思路，用例，測試方法的不一樣，有些bug，你沒發現，他發現了，並且影響還挺大！那時候，就是謝天謝地了！其實，這裏能夠但願版本負責人能夠多考慮下測試組員的定位，讓定位類似至少不要差很遠且讓對彼此測試項都有些瞭解的人進行交叉，避免溝通帶來的大量時間的損失。）--迴歸測試--版本測試總結，生成測試報告，對版本上載進行評估--版本上載跟進（這個很辛苦，基本上都是通宵熬夜，主要是驗證基本主要業務功能和新上載的功能是否能夠實現，是否不會報錯，是否有其餘不可預估的影響等），這就是大概的流程（加吐槽）了。

 

 

  接着是工做內容：

  一、版本測試，到如今爲止，我所知道的咱們公司的版本測試就是，瞭解需求—>瞭解開發上載的功能（不懂找開發，必要時拉上設計）—>根據需求，功能設計測試用例—>執行測試—>bug的跟蹤管理......(後面的都像上面的流程差很少)，版本測試也就是你們所說的黑盒測試，你也能夠理解爲，根據功能在前臺點點點，而後看是否會報錯；（說到這，你會不會覺得好簡單！--too young!），首先，我得說下，我很佩服那些版本測試作得很好的人！就咱們公司來講，版本測試涉及面很是廣，雖然表面上就一個系統，上載一些功能項而已，但是考驗的功力，我只能說，我在這工做近兩年了，能達到50%，我都會偷笑了！我以爲，任何測試，都必須從本身產品的業務需求出發（我的看法），因此在設計測試用例時，業務的實現就是咱們的出發點，要考慮業務成功是怎樣的，失敗時怎樣的，什麼狀況下會成功，什麼狀況下會失敗，邊界狀況怎樣,特殊狀況等等，固然這只是其中一個業務，當還存在其餘業務項有關聯時，咱們又要考慮業務間的影響，當你的系統有多個地方用時，你又要考慮，這個地方上這個業務項，別的地方會不會有影響，影響大不大，當有多個業務項一塊兒上時，彼此間又該怎麼搞?......這就是版本測試須要考慮的地方之一，在我瞭解的範圍內，優秀的版本測試人員首先須要對整個產品的業務功能都有必定的熟悉，即便它不少，而後對不一樣點的具體實現結果，影響範圍以及特殊業務都要知道，這樣才能夠儘量的精簡本身的用例的同時提升用例的覆蓋率；而後還要會對測試項的優先級，嚴重性進行判斷（這須要時間經驗的積累），對測試工做進行安排（不少時候你會發現，一大堆任務擺在你面前，根本連寫用例的時間都沒有，測試的時間也會很吃緊！）