leveret
應該說這不是一篇文章，這應該屬於是乙個討論的話題吧，無論觀點是否正確，希望大家能夠在論壇裡面可以發表自己的見解。尤其在這方面深有感觸的朋友。
提起這個話題的原因是因為現在乙個專案裡面測試人員的介入是到開發後期階段——編碼工作完成之後介入的，我認為很不合理，所以提出這個問題。從大的方面來考慮的話，現在流程的測試模型有三種：v模型，w模型，h模型。而在這三種模型裡面，無論哪一種模型，測試的介入都是在軟體開發過程的前期介入的。測試工作在這時介入，無論從哪方面考慮，都比我們直到開發過程的後期才介入更有好處。
從成本方面來看：前期介入也許增加了測試人員的成本，但是相對於後期的投入和專案的風險方面，這個成本顯然遠遠小於後期的投入，前期發現的bug的修改代價比後期的修改代價小多了，如果把成本投入跟介入時間進行比較的話，那麼應該可以得到如下的結論：介入時間越早，成本投入越小，反之越大。在需求調研階段，設計階段，編碼階段，測試階段，產品出貨階段我們都會發現bug，但是處理bug的代價在這幾個階段卻是截然不同的，越往後代價越高。做過專案的人應該都有體會的。
從專案風險來看：如果把編碼階段作為風水嶺的話，編碼階段之前的工作為前期工作，編碼階段包括編碼之後的工作為後期工作。乙個問題在開發過程的前期被發現，則可以很大程度上降低專案的風險問題，如果在後期發現乙個問題，將不可避免地要面對專案風險問題。很多時候乙個專案最後實施的失敗大部分都是在後期發現的問題所致的。當然這不是實施失敗的全部因素。
從其他方面來考慮，都是前期介入比後期介入的情況好的。但是目前所遇到的情況是：等需求調研完成之後測試人員一起進行需求整理，這個時候我覺得很迷糊的一點就是測試人員都沒有參加過需求調研，讓測試人員進行需求調研整理，那不是需要重複一次工作嗎？很多問題測試人員還是要去問進行調研的人的。我覺得效率不是很高。而且經過中間的一道程式很多時候會發生一種曲解需求的現象。
所以測試人員的介入從有些方面來說還是值得乙個專案小組的負責人考慮的，不能只是從投入成本來考慮，而且如果要從成本方面考慮的話那麼請考慮整個專案週期的成本。專案風險是專案負責人必須面對的乙個問題，而在這個問題上最重要的乙個環節就是測試人員來進行把關的，當然有的公司在測試人員之後還有qa來負責質量的。其實關於這個話題要詳細展開的話不是三言兩語就可以說完的。今天只是有感而發。更何況有時候很多公司的規定都是不一樣的。有時候有些流程不一定往日的經驗就是很好的總結，該改新的時候還是需要動手術的。一成不變只能固步自封。墨守成規只能停滯不前。
其實有時候覺得測試也可以進行分階段，比如需求調研時候了解需求，然後等開發人員進行設計時候我們對需求進行剖解，然後提交**之後再開始執行測試，中間可以根據需求和設計做很多測試計畫，測試設計策略等方面的事情，主要包括測試計畫，測試用例的設計，產出，並且準備相關測試資料。然後主要的一點就是要對自己進行的專案測試有乙個很可觀，比較全面的測試風險等的評估。
呂不為：程式開發人員進行的是創造**的活動，所以，很多初級程式設計師在寫**之前，很明白自己在要做什麼，該怎麼做。但是，當開始寫**時，隨著時間的流逝，目的就不再那麼清晰了，也偏離了原先自己的思路，只是顧全自己的部分邏輯，而對整體的業務邏輯不是很清楚。所以，為了保證程式設計師的正確航向，測試人員應該在程式設計師寫**前，先寫出測試用例，因為測試人員關心的是**執行的結果是否符合使用者的業務流程以及是否實現了預定的目標。相對來說，測試人員比開發人員更了解使用者對軟體的需求。因為測試是面向業務流程的，而軟體開發是按模組分工的。所以，我們的做法是，在調研使用者需求的時候，首先寫出測試用例，用來規範程式開發人員的工作範圍，使他們能在正確的道路上前進而不會偏離使用者需求太遠。當使用者需求變化時，測試人員更改用例，開發人員修改**，以通過用例為準。
周舟：提到介入階段，做了這麼多專案我倒以為這不是該有很嚴格界定的，也確實真的很難界定，因為不論是需求，設計，永遠不變的是一切都在變，甚至上線應用之後，使用者認為不滿意，那也還得再變。
所以依據需求分析，概要設計......寫出來的測試用例也很難一成不變。所以只要需求，設計都要變，測試就是有風險的。就算一切都是安裝需求和設計寫出來的，但那些不是使用者最終要求，最終就這樣白忙活了一場。
我以為測試不論什麼時候介入，了解和理解使用者的最終需求是必須和萬無一失並適合中國國情的。
當然若是需求分析和設計能夠很好的了解和理解需求，那測試的工作到是可以減輕許多，並風險也會小很多。只要測試「實現的功能是否正確」就行了，而不必費心於「系統是否實現了正確的功能」的測試。
逐漸的行業背景知識竟也成了對測試人員的一種竟聘要求。
leveret：to:周舟,"逐漸的行業背景知識竟也成了對測試人員的一種競聘要求。"這句話正在被越來越多的企業應用到，不僅僅是測試知識，相關的行業背景知識也是很重要的，需求很難被固定，用例總是在改動，這都是很正常的。思考了很久，也真的很難總結出真正的乙個介入的分水嶺。還是活學活用吧，根據自己的實際，不要脫離科學的軌跡。路漫漫其修遠兮，偶們將上下而求索。。。。。。。。。。。。。。
何時介入效能測試
我們知道了壓測的概念的介紹，那麼很多人都想問，我們應該怎麼做，在專案中的流程是怎樣的，整個過程需要什麼。那麼我們來一一道來。我們選擇什麼樣的時機去介入壓測，時機的選擇是很重要的，如果時間選擇不對呢，那麼可能壓測都是無用功。或者是高投入，低產出的。我大概總結了幾個時機。大概是5個方面，當然了，也不只是...
專案出問題了,測試部人員是否應該介入後的思考
背景 早上接到 erp部門經理的 說 erp二期專案出問題了，總是不明原因的宕機，這個專案又沒有做效能測試，客戶說我們應該做效能測試，所以能不能請馬上派效能測試工程師來現場 今天看能不能查出問題在 我回答說 這個時候做效能測試沒有意義，你應該要做的是分析出錯的原因啊，例如 分析，框架分析和原因假設排...
測試如何快速介入乙個新專案
軟體測試人員如何快速介入乙個新專案 一般我們在入職乙個新公司或者進行專案調動的時候，接觸到的專案基本上都是以前沒有接觸過的專案，就算是專案型別類似，但是總歸是乙個全新並且未接觸過的專案，這個時候，作為乙個測試人員如何快速介入這個新專案就很考驗測試人員的意識和水平了，當然也和測試經理有關 畢竟經理要你...