想從零基礎學習軟件測試到成為測試工程師詳細了解南京手工測試手工測試

1.感覺手工測試不往管理方向上發(fā)展，手工測試的技術路線沒啥錢途，想聽聽大家的意見？

大家都知道，軟件測試的一個顯著特性，那就是重復。而重復就容易讓人產生厭煩，尤其是大量的工作量，因此人工測試容易出錯，而且效率不高。自動化測試則能很好的解決這個問題，自動化測試工具能彌補手工測試的精確性，并且效率也要高得多。目前，很多企業(yè)或管理者期望借助軟件測試自動化作為催化劑，提高效率、提高質量，同時，節(jié)省開支。甚至有些企業(yè)希望實施自動化測試后，就能夠給企業(yè)帶來效益。但是自動化測試的成本也不容忽視，涉及到軟件成本、培訓成本、人力成本。當然，如果使用TestBird已有的自動化測試是一個很好的選擇，但是也還是要考慮自身的需求，是否真的適用于自動化測試。至于手工測試不往管理方向發(fā)展，我覺得也不是沒“錢”途，業(yè)務的精通也很重要，特別是在某些特殊的行業(yè)中。

2.手工測試（黑盒測試）的高手是什么級別

我覺得針對這個用例：所有字段都輸入*字符長度存儲時就crash，如果能*重現問題，就不需要在定位到具體是那個字段啦。試想，如果有20個字段呢，你需要逐個去試到底是那個字段超過長度，至少需要嘗試20次吧，如果字段更多呢（比如人事基本信息啥模塊），你的用例數會增加很多，但是如果采用調試，你只需要每個字符都輸入*值，很快就能在賦值時跟到是哪個字段超出導致拋出異常，從純時間花費上來說，調試也許更經濟，而且更有針對性。有時我覺得這種情況跟蹤一下比逐個嘗試來得更快。再舉個例子，比如創(chuàng)建時間這個當我提交后總是不等于當前時間，而是一個其他什么時間，但是我不知道到底這個其他時間是怎么來的，這時候，其實我已經可以提交這個bug了，我可以*重新問題了。實際在跟蹤后你發(fā)現，這個創(chuàng)建時間是字段賦值錯誤，而這個其他時間根本不在當前頁，你就算一一嘗試也想不到是和當前頁無關。換句話說，這實際是個測試粒度的問題，如果我已經能*重新，我還有必要定位到更細的粒度嗎？再定位下去，我實際就進入調試領域啦。再換個思維想想，其實這種字符長度問題，應該在單元測試階段就檢查出來，當到達更高的級別（集成測試、功能測試）我們其實應該更關注流程上的問題，業(yè)務流是否正確。而這種字符長度邊界問題我覺得應該放在白盒更容易覆蓋到而不會遺漏。 查看原帖>>

3.軟件測試中手工測試重要還是自動化測試重要？

這個問題好像好多人都問過。手工測試、自動化測試哪個更重要? 答：都重要，不存在孰輕孰重的問題。感覺可以考慮，不同場景或階段下選擇哪種方式當時更適合？手工測試和自動化測試都基于對用戶需求、功能需求的正確理解，對測試對象進行充分測試設計的基礎上開展的。按照測試階段或者功能穩(wěn)定程度來劃分，手工測試更適合軟件模塊、集成測試階段或者功能穩(wěn)定性低（缺陷多、變動快等），如果這個時候開展自動化會引入過多的自動化開發(fā)、維護成本。自動化測試更適合在產品迭代后期或者功能相對穩(wěn)定的時候開展，通常應用于回歸測試場景下（關注我后續(xù)的文章，會有關于自動化前移的探討）。按照不同的測試對象來劃分，如測試百萬級的元數據遷移、匯聚處理時，由于數據的多樣性，很難通過用手工測試保障質量，自然而然需要考慮自動化的方式提高測試效率，進而保障測試質量。時間有限的情況下，使用自動化盡可能覆蓋重復性高的操作。同時自動化并不是生搬硬套，根據不同的業(yè)務場景選擇合適的自動化框架十分重要，可以有效的提高測試開發(fā)效率和降低維護成本。如，對于一個含有強流程的業(yè)務模塊，采用關鍵字驅動測試框架更利于用例的組織和維護。通常常用的自動化框架還包含數據驅動測試框架、模塊化測試框架。自動化測試的類型也要因地制宜，如ui自動化、接口自動化等等，也需要結合業(yè)務特點、底層架構選擇合適的類型開展。*應該盡量避免為了做自動他而做自動化，而是為了去做更多有價值的測試。

想了解軟件測試學習課程，費用以及時間了解感覺手工測試不往管理方向上發(fā)展，手工測試的技術路線沒啥錢途，想聽聽大家的意見？，手工測試（黑盒測試）的高手是什么級別，軟件測試中手工測試重要還是自動化測試重要？??