哪個測試由程序員來做而非測試員

Ⅰ 測試程序員

比較累的工作，但工資還可以。

Ⅱ 測試工程師和程序員那個好做

測試工程師其實也屬於程序員類別吧，只不過對編程的代碼要求低。但是想發展好的話確實還是需要能看懂一些代碼。
以前測試行業不受重視，但是現在真的是不一樣了。
如果要是單純的靠薪酬去衡量的話，基本上現在已經達到持平的標准了，而且和開發一樣，對於一線城市，像北上廣深，薪資始終是最好的。近兩年西安的軟體測試行業發展很好，那邊的同學可以留意一下。
除了簡單的薪資對比，還有很多對比反面可能會讓你更加青睞於這個行業。比如說：
這個行業不像開發那麼累，而且入門比較簡單，比較適合女生之類的。總體來說，兩者對比，測試入門容易，精進比較難，開發是入門難，精進更難。

Ⅲ 測試算不算程序員

軟體測試嚴格意義上說也算程序員。軟體測試員是指根據測試計劃和測試方案進行軟體測試；能夠針對軟體需求開發測試模型，制定測試方案，安排測試計劃，並對測試項目進行管理的專業人員。

執行測試工作時候要細心，認真執行測試，不可以忽略一些細節。某些缺陷如果不細心很難發現，例如一些界面的樣式、文字等。

測試員需要有難以置信的耐心。有時你需要花費驚人的時間去分離、識別和分派一個錯誤。很多測試工作有時候顯得非常枯燥，需要很大的耐心才可以做好。如果比較浮躁，就不會做到「專心」和「細心」，這將讓很多軟體缺陷從你眼前逃過。

Ⅳ 軟體測試員要知道那些有關的知識呢

軟體測試是一項復雜的系統工程，從不同的角度考慮可以有不同的劃分方法，對測試進行分類是為了更好的明確測試的過程，了解測試究竟要完成哪些工作，盡量做到全面測試。
1,按是否需要執行被測軟體的角度
按是否需要執行被測軟體的角度，可分為靜態測試和動態測試，前者不利用計算機運行待測程序而應用其他手段實現測試目的，如代碼審核。（我認為主要是讓測試人員對編譯器發現不了的潛在錯誤進行分析，如無效的死循環，多餘的變數等，有開發人員進行測試），而動態測試則通過運行被測試軟體來達到目的。

2、按階段劃分：
1 單元測試
單元測試是對軟體中的基本組成單位進行的測試，如一個模塊、一個過程等等。它是軟體動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟體基本組成單位的正確性。因為單元測試需要知道內部程序設計和編碼的細節知識，一般應由程序員而非測試員來完成，往往需要開發測試驅動模塊和樁模塊來輔助完成單元測試。因此應用系統有一個設計很好的體系結構就顯得尤為重要。
一個軟體單元的正確性是相對於該單元的規約而言的。因此，單元測試以被測試單位的規約為基準。單元測試的主要方法有控制流測試、數據流測試、排錯測試、分域測試等等。

2 集成測試
集成測試是在軟體系統集成過程中所進行的測試，其主要目的是檢查軟體單位之間的介面是否正確。它根據集成測試計劃，一邊將模塊或其他軟體單位組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。

3 系統測試
系統測試是對已經集成好的軟體系統進行徹底的測試，以驗證軟體系統的正確性和性能等滿足其規約所指定的要求，檢查軟體的行為和輸出是否正確並非一項簡單的任務，它被稱為測試的「先知者問題」。因此，系統測試應該按照測試計劃進行，其輸入、輸出和其他動態運行行為應該與軟體規約進行對比。軟體系統測試方法很多，主要有功能測試、性能測試、隨機測試等等。

4 驗收測試
驗收測試旨在向軟體的購買者展示該軟體系統滿足其用戶的需求。它的測試數據通常是系統測試的測試數據的子集。所不同的是，驗收測試常常有軟體系統的購買者代表在現場，甚至是在軟體安裝使用的現場。這是軟體在投入使用之前的最後測試。

5 回歸測試
回歸測試是在軟體維護階段，對軟體進行修改之後進行的測試。其目的是檢驗對軟體進行的修改是否正確。這里，修改的正確性有兩重含義：一是所作的修改達到了預定目的，如錯誤得到改正，能夠適應新的運行環境等等；二是不影響軟體的其他功能的正確性。

6 Alpha 測試：在系統開發接近完成時對應用系統的測試；測試後，仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。

7 Beta 測試：當開發和測試根本完成時所做的測試，而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員員完成，不能由程序員或測試員完成。

3、按測試方法劃分：

1 白盒測試

白盒測試也稱結構測試或邏輯驅動測試，是指基於一個應用代碼的內部邏輯知識，即基於覆蓋全部代碼、分支、路徑、條件的測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能，白盒測試的主要方法有邏輯驅動、基路測試等，主要用於軟體驗證。
「白盒」法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。「白盒」法是窮舉路徑測試。在使用這一方案時，測試者必須檢查程序的內部結構，從檢查程序的邏輯著手，得出測試數據。貫穿程序的獨立路徑數是天文數字。但即使每條路徑都測試了仍然可能有錯誤。第一，窮舉路徑測試決不能查出程序違反了設計規范，即程序本身是個錯誤的程序。第二，窮舉路徑測試不可能查出程序中因遺漏路徑而出錯。第三，窮舉路徑測試可能發現不了一些與數據相關的錯誤。
白盒測試可以藉助一些工具來完成如Junit Framework，Jtest等。

2 黑盒測試

黑盒測試是指不基於內部設計和代碼的任何知識，而基於需求和功能性的測試，黑盒測試也稱功能測試或數據驅動測試，它是在已知產品所應具有的功能，通過測試來檢測每個功能是否都能正常使用，在測試時，把程序看作一個不能打開的黑盆子，在完全不考慮程序內部結構和內部特性的情況下，測試者在程序介面進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數鋸而產生正確的輸出信息，並且保持外部信息（如資料庫或文件）的完整性。黑盒測試方法主要有等價類劃分、邊值分析、因—果圖、錯誤推測等，主要用於軟體確認測試。
「黑盒」法著眼於程序外部結構、不考慮內部邏輯結構、針對軟體界面和軟體功能進行測試。「黑盒」法是窮舉輸入測試，只有把所有可能的輸入都作為測試情況使用，才能以這種方法查出程序中所有的錯誤。實際上測試情況有無窮多個，人們不僅要測試所有合法的輸入，而且還要對那些不合法但是可能的輸入進行測試。
黑盒測試也可以藉助一些工具，如WinRunner，QuickTestPro，Rational Robot等。

3 ALAC(Act-like-a-customer)測試
ALAC測試是一種基於客戶使用產品的知識開發出來的測試方法。ALAC測試是基於復雜的軟體產品有許多錯誤的原則。最大的受益者是用戶，缺陷查找和改正將針對哪些客戶最容易遇到的錯誤。

Ⅳ 做程序員與做測試員的選擇

1、學歷問題：大公司對於學歷還是有一定的要求的，學歷高的起薪也高，但是學歷不能代表所有，也有學歷高，但是技術垃圾的人，所以不要因為學歷的問題來妄自菲薄，學歷只是入門和之後評職稱的時候有用，學歷可以以後慢慢考。所以學歷不是問題。

2、方向問題：如果是培訓出來的話，那的基礎知識一定不會非常的好，一定要注意基礎部分，不要總是因為學習了多少框架而感到驕傲並且否定基礎的東西，其實無論是框架還是什麼都是基礎的延續，只要打下了扎實的基礎，那麼學習起框架那些東西。培訓出來的人大都做開發，而測試一般都是逼不得已而為之！

3、測試和開發哪個好：都是比較枯燥的工作，測試久了想轉開發，開發久了想轉行。就像圍城。測試，沒有做過，但是聽說過一些，測試枯燥、乏味、而且經常熬夜，（開發也一樣），但是從薪方面看，開發的優勢就遠遠大於測試了，不是說測試比開發低級，用共產黨的話就是：革命沒有貴賤之分，只有分工的不同而已。

(5)哪個測試由程序員來做而非測試員擴展閱讀：

做好一名測試工程師的方法：

1、溝通能力。

一名理想的測試者必須能夠同測試涉及到的所有人進行溝通，具有與技術（開發者）和非技術人員（客戶，管理人員）的交流能力。既要可以和用戶談得來，又能同開發人員說得上話，不幸的是這兩類人沒有共同語言。

2、技術能力。

一個測試者必須既明白被測軟體系統的概念又要會使用工程中的那些工具。要做到這一點需要有幾年以上的編程經驗，前期的開發經驗可以幫助對軟體開發過程有較深入的理解，從開發人員的角度正確的評價測試者，簡化自動測試工具編程的學習曲線。

3、很強的記憶力。

一個理想的測試者應該有能力將以前曾經遇到過的類似的錯誤從記憶深處挖掘出來，這一能力在測試過程中的價值是無法衡量的。因為許多新出現的問題和我們已經發現的問題相差無幾。

4、幽默感。在遇到狡辯的情況下，一個幽默的批評將是很有幫助的。

Ⅵ 測試方法有哪些，各有什麼優缺點

1、恢復測試

恢復測試主要檢查系統的容錯能力。當系統出錯時，能否在指定時間間隔內修正錯誤並重新啟動系統。恢復測試首先要採用各種辦法強迫系統失敗，然後驗證系統是否能盡快恢復。對於自動恢復需驗證重新初始化（reinitialization）、檢查點(checkpointing mechanisms)、數據恢復(data recovery)和重新啟動 (restart)等機制的正確性；對於人工干預的恢復系統，還需估測平均修復時間，確定其是否在可接受的范圍內。

2、安全測試

安全測試檢查系統對非法侵入的防範能力。安全測試期間，測試人員假扮非法入侵者，採用各種辦法試圖突破防線。例如，①想方設法截取或破譯口令；②專門定做軟體破壞系統的保護機制；③故意導致系統失敗，企圖趁恢復之機非法進入；④試圖通過瀏覽非保密數據，推導所需信息，等等。理論上講，只要有足夠的時間和資源，沒有不可進入的系統。因此系統安全設計的准則是，使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。

3、強度測試

強度測試檢查程序對異常情況的抵抗能力。強度測試總是迫使系統在異常的資源配置下運行。例如，①當中斷的正常頻率為每秒一至兩個時，運行每秒產生十個中斷的測試用例；②定量地增長數據輸入率，檢查輸入子功能的反映能力；③運行需要最大存儲空間（或其他資源）的測試用例；④運行可能導致虛存操作系統崩潰或磁碟數據劇烈抖動的測試用例，等等。

4、 性能測試

對於那些實時和嵌入式系統，軟體部分即使滿足功能要求，也未必能夠滿足性能要求，雖然從單元測試起，每一測試步驟都包含性能測試，但只有當系統真正集成之後，在真實環境中才能全面、可靠地測試運行性能系統性能測試是為了完成這一任務。性能測試有時與強度測試相結合，經常需要其他軟硬體的配套支持。

Ⅶ 軟體測試為什麼不讓編寫人員參與

一款軟體的開發,測試是貫徹始終的
前期的單元測試和集成測試都是由程序員來完成了
測試小組並不參與
到系統測試的時候測試元才退出測試過程,而負責修改軟體缺陷.
這些缺陷往往是由測試小組發現的,因為程序員對他們的程序很了解,知道怎麼操作不會出現BUG,而測試小組則不然,怎麼能引出BUG他就怎麼去操作,相當於找茬.只有這樣才能通過最後客戶的驗收測試.

Ⅷ 測試工程師是程序員嗎

測試工程師其實也屬於程序員類別吧，只不過對編程的代碼要求低.
一.過去的軟體測試行業
曾經軟體測試行業是一個門檻很低，入門非常簡單的職業。點來點去基本就完成了測試工作然後上線！
但是效果往往大跌眼鏡。
過去的軟體測試行業
曾經軟體測試行業是一個門檻很低，入門非常簡單的職業。點來點去基本就完成了測試工作然後上線！
但是效果往往大跌眼鏡。
測試有專門負責開發測試工具的，叫「開發測試」。其他的測試是開不參與開發的，所以不能算是程序員

開發是要負責寫實現的，而測試是負責實現沒問題。目的不同

Ⅸ 單元測試由誰來做最合適

為什麼要進行單元測試？ 單元測試保證局部代碼的質量 單元測試在隔離的前提下，分別對各個代碼單元進行測試，能夠達到其他測試不可能達到的測試完整性，從而保證了局部代碼的質量。只有局部代碼的質量得到了保證，軟體產品的質量才可能得到保證。 單元測試改良項目代碼的整體結構 要對代碼進行單元測試，最起碼的前提是代碼能夠隔離，也就是說，要具有一定的可測性，因此，單元測試是一種有效的約束機制，這種機制將有效地改良代碼的整體結構。例如，如果把業務代碼直接寫在界面類中，將很難進行單元測試，隨意的不合理的緊耦合也會造成難於測試，單元測試使這些不好的特性得於及時發現，從而很容易進行修正。可測性是高質量代碼的首要特性，不具有可測性，也就無法衡量代碼的正確性，有了可測性，也就基本上保證了代碼的可擴展性、可復用性。 單元測試降低測試、維護升級的成本 錯誤越早發現，修復的代價越小，另一方面，如果代碼經過了充分的單元測試，集成測試和系統測試就只需要關注設計方面的問題。自動回歸測試也大量降低升級維護成本。 使開發過程適應頻繁變化的需求 單元測試自然地使開發流程變得「敏捷」，這是因為，整體結構良好的代碼具有較好的可擴展性，自動回歸測試又能保證修改不會引入新的錯誤，因此可以適應頻繁變動的需求，降低系統分析、架構設計和後期測試的壓力。 單元測試有助於提升程序員的能力 對程序員來說，單元測試有利於養成縝密的思維習慣，及提高設計能力。 由誰進行測試？開發部門還是測試部門？ 應該由開發部門進行單元測試！ 由測試部門進行單元測試的問題 代價高：反復的重新理解代碼需要大量的時間，反復的溝通也需要大量的成本。 人手不足：進行單元測試的人員需要具備編碼能力，很多軟體企業的測試部門都沒有足夠的人手。 耽誤了測試部門對其他測試的准備工作：編碼階段，測試部門要為集成測試、系統測試等做好准備，如果測試部門陷在單元測試的「泥潭」里，很可能影響這些准備工作。 由開發部門進行單元測試的問題 擔心影響開發進度：這是現實問題，但自動化的單元測試工具可以解決這個問題。 程序員不習慣做單元測試：這種習慣是可以理解的，但並不難改變，實際上，程序員寫程序時都是要進行測試調試的，只不過通常比較零散和隨意而已。 測試自己編寫的代碼，難於保證測試的效果：測試自己寫的代碼，通常會只測試正常的輸入，因此難於保證測試的完整性，但自動化的單元測試工具，可以統計白盒覆蓋，甚至提供用於找出遺漏的測試用例的工具，達到很高的測試完整性。只要達到了足夠的測試完整性，那麼，無論誰測試，效果都是一樣的。 無論由哪個部門做單元測試，都要面對一些問題，但開發部門所面對的問題可以藉助工具來解決，而由測試部門進行單元測試，要麼無法真正實施，要麼代價昂貴。 由測試部門進行單元測試為什麼成本昂貴？ 需多次重復理解程序 測試人員進行單元測試時必須理解程序功能甚至代碼邏輯；充分的單元測試通常會發現很多細小的錯誤，程序員修改代碼時，又要再次理解程序。理解程序是很耗費時間的。 反復溝通需要大量時間成本 單元測試發現的錯誤一般是小Bug，但數量可能很多，修改錯誤一般由程序員進行，測試人員還要確認，這些反復溝通也需要很多的時間。 不利於發揮單元測試對代碼結構的約束機制 如果等編碼基本完成再由測試部門進行單元測試，也就不能及時發揮單元測試對代碼整體結構的約束效果，測試部門拿到代碼時，往往會發現難於測試。 耽誤測試部門對其他測試的准備工作： 編碼階段，測試部門要為集成測試、系統測試等做好准備，如果測試部門陷在單元測試的「泥潭」里，很可能影響這些准備工作。 基於以上理由，即使測試部門人手充裕，僅僅從效益來考慮，也不應該由測試部門進行單元測試。如果測試部門本來就人力不充裕（進行單元測試的人員需具備編碼能力），勉強由測試部門進行單元測試，結果往往是----沒有結果。 由開發部門進行單元測試能保證測試效果嗎？ 程序員測試自己編寫的代碼，往往只考慮「正常狀況」，這當然會影響測試效果。但如果所用的單元測試工具能夠統計各種白盒覆蓋率，就能檢查測試效果。當然，只做到這一點還是不夠的，因為白盒覆蓋具有逾後逾難的特點，達到一定的覆蓋率後，覆蓋率的提升會很困難。如果測試工具功能足夠強大，能提供工具幫助用戶快速地設計測試用例，達到完整的白盒覆蓋，那麼測試效果就能得到完全的保證。 實際上，如果沒有充分的統計數據，沒有達到足夠的測試完整性，那麼由誰做單元測試，效果都不能保證。 進行單元測試，關鍵是要達到比較高的輸入覆蓋，這樣，無論由誰測試，效果都是一樣的。