工做幾年的時間本身也參與了好幾個項目,可是沒有一個項目是讓本身滿意和舒服的。不少項目有很多問題,本身在項目中作測試工做也是頗有挑戰而且常常疲憊不堪。最近在思考本身心目中的理想項目是什麼樣子的,但願本身之後能參加到這樣的項目中。由於本身目前的職位是測試工程師(QA),因此我主要從測試人員的視角來討論。git
有些項目中開發人員認爲測試只是測試人員或者帶測試頭銜的工程師的工做,和本身無關,這實際上是錯誤的。全部項目組中的成員都要對產品的質量負責,而不是隻有測試工程師來負責。以前項目中也遇到過只認爲測試工做就是測試工程師的活兒,其餘的開發工程師和產品經理都不須要進行測試的工做。若是開發人員都沒有要好好測試的意識,那麼單元測試的質量也不用期待了。基本上在集成測試的時候就爆發不少bug和不少問題。編程
本身以前作過的項目,並無實際接觸過經過測試驅動開發的方式編程的開發人員。並且也沒有遇到作單元測試自動化測試的狀況。可是本身最近有經過測試驅動開發進行編程的實踐,感受仍是對提升代碼的質量頗有幫助的。 若是項目有良好的單元測試代碼覆蓋率的話,進行單元測試的自動化迴歸測試也很簡單。 固然頗有可能開發人員會反駁說,沒有時間來寫測試代碼,甚至單元測試只能手工簡單測試。由於項目排期太緊的緣由。實際上這種說法也不太對,雖然一開始經過測試驅動開發方法會在開發階段多花時間,可是單元測試的力度大力,發現bug和解決bug的成本更小了。同時後面集成測試的壓力也小了,其實經過整體項目進度來看不定會須要花更多時間來完成。 實際上公司內部能夠經過對一兩個項目進行實行測試驅動開發來進行試驗,最後在和其餘不用這種方法的項目對比質量和進度,就能發現測試驅動開發的方法是否會影響項目的進度。api
好的項目是流程比較合理和規範的,下面是簡化的項目流程從上到下來執行。框架
我的認爲理想的項目應該是擁抱新技術和工具的。特別是一些基本工具的使用,能提升項目中工做效率。 本身以前也在沒有使用bug管理工具和版本管理工具的項目工做過,相比使用JIRA和git等工具的項目明顯有不少缺點,並且效率也更低。工具
爲何要重視自動化測試呢?在實際的工做中由於要頻繁變動需求和修改代碼,那麼每發佈一個小版本都須要執行上一版本已經正確執行過的測試用例來進行迴歸測試,只有經過了迴歸測試才能確認此次新增或修改的功能沒有對以前的功能產生很差的影響。迴歸測試是很重要的,可是經過手工的方式進行迴歸測試的缺點不少,好比執行效率低,速度慢,並且成本高,要佔用好幾我的力,另外人也容易出錯,容易發生遺漏。單元測試
還有一種經過人工評審來篩選要執行那些迴歸測試的辦法,來減小要執行的測試用例數量,可是這種方式也是有問題的,由於一開始的選擇就有多是錯誤的,執行的測試用例越少,咱們對產品質量的信心就越小。開發工具
若是在敏捷開發項目過程當中沒有自動化測試的話,那麼迴歸測試的工做就會佔用測試工程師不少時間,這樣工程師就沒有時間來進行探索式測試等更有創造性的工做。測試
迴歸測試是很是適合做成自動化測試的,由於迴歸測試就是重複執行以前的測試用例,計算機比較擅長進行重複的工做,咱們應該利用計算機來完成儘可能多的迴歸測試。 另外迴歸測試不只僅包括集成測試和用戶驗收測試,我認爲單元測試和接口測試也應該作成自動化迴歸測試,單元測試和接口測試所佔的比重能夠更高一些。接口
綜上所述,我心中理想的項目是全體成員意識上都重視測試,同時有很強的自動化思惟。有規範的流程,而且經過工具和自制腳原本將大部分的流程自動化,例如自動發佈版本,自動化測試,自動部署等。開發
參考文獻:
《高效團隊開發工具與方法》 池田尚史,藤倉和明,井上史彰 著