如何用一個測試方法去調起

1. Java中如何測試方法調用時間

測試方法執行了多長時間，你可以使用列印語句列印出系統時間，兩者相減除以3600就可以計算出秒數

2. java中，imp實現類里的方法，在Test測試類里怎麼調用出來謝謝 指教一下

如果要在Test測試類里調用imp實現類里的方法，您需要實例化化imp實現類，得到實體對象，然後就可以調用該介面的實現方法了。如有不對，請把您的代碼附送到問問，我幫您看看。。

3. ICT測試參數的調整方法

CB 板ICT 測試點設置調整方法
ICT類似如萬用表，只是把表筆換成了測試針。那麼問題就簡單了，一顆普通的RLC元件，都必須有兩個測試點才能夠測試，當然同一個網路共用的節點用一個測試點就可以了。一般Coverage一般要求在85%以上才建議加入ICT測試。
ICT是在產品不通電的狀況下，機器對產品上的每個元件進行阻值、容量、感量、通斷等參數的測試。
FCT是在整合了ICT和功能測試，即完成ICT測試步驟後，轉到產品通電狀態，測試產品的各項正常工作時的參數。這樣的好處是不要再去拿放一次產品。測試點的設計要求：
1、定位孔採用非金屬化的定位孔 ，誤差小於0.05mm。定位孔周圍3mm不能有元件。
2、測試點直徑不小於0.8mm，測試點之間的間距不小於1.27mm,測試點離元件不小於1.27mm，否則錫會流入到測試點上。
3、如果在測試面放置高度超過4mm的元器件，旁邊的測試點應避開，距離4mm以上，否則測試治具不能植針。
4、每個電氣節點都必須有一個測試點，每個IC必須有POWER及GROUND的測試點，且盡可能接近此元器件，最好在距離IC 2.5mm范圍內 。
5、測試點不可被阻焊或文字油墨覆蓋，否則將會縮小測試點的接觸面積，降低測試的可靠性 。
6、測試點不能被插件或大元件所覆蓋、擋住。
7、不可使用過孔或DIP元件焊點做測試點。
ICT植針率需要達到100%，元件可測試率要達到85%以上。

4. 軟體測試的步驟

1、根據軟體項目、產品的需求規格說明書提煉，整理測試需求，即本項目具體的測試點是什麼，並形成文檔，並對測試需求進行評審；

2、根據測試需求和項目的整體計劃，制定測試計劃，測試方案等，包括測試的時間節點安排，人力資源安排，測試策略等，並進行評審；

3、根據測試需求以及相關的設計文檔，編寫測試用例，即明確每個測試點的具體的操作步驟，預期結果等內容，並對用例進行評審；

4、准備測試環境和測試數據，包括測試系統部署的硬體環境和軟體環境；

5、執行測試用例，提交測試過程中發現的bug，並通過版本迭代進行回歸測試，驗證相關的bug；

6、完成內部軟體系統的功能測試，系統測試之後，系統趨於穩定，提交客戶進行驗收測試；

7、編寫軟體測試報告；

8、對測試過程進行總結，並將測試過程中的所有文檔進行歸檔。

(4)如何用一個測試方法去調起擴展閱讀：

軟體測試一般分為測試需求分析階段，測試計劃階段，測試設計階段，測試執行階段，測試總結階段。根據項目的不同，每個階段的具體工作內容會有些差別。但是每個階段的目標是一樣的。與軟體開發步驟相配套，從而達到質量保障的目的。

測試需求分析階段以整個項目或者產品的需求為基線，進行分析、整理得到測試的需求，這也是測試的綱領性文檔和標准；測試計劃階段主要是結合整個項目的計劃，編制軟體測試部分的工作計劃。

測試設計階段主要是根據測試需求和項目的相關設計，編寫測試用例，這也是很重要的一環；測試執行階段，就是進入常說的測試階段，在測試系統中執行用例，驗證系統功能是否正確；測試總結階段是測試執行完成後，需要做的收尾工作，給出所測試系統的質量評估與報告。

5. 測試類中有許多Junit的@Test方法，如何控制只運行其中的一個測試方法呢

如圖，在某一個方法名上右鍵

6. 怎麼用junit 只測試1個方法

JUnit是由 Erich Gamma 和 Kent Beck 編寫的一個回歸測試框架（regression testing framework）。Junit測試是程序員測試，即所謂白盒測試，因為程序員知道被測試的軟體如何（How）完成功能和完成什麼樣（What）的功能。Junit是一套框架，繼承TestCase類，就可以用Junit進行自動測試了。
JUnit是一個開發源代碼的Java測試框架，用於編寫和運行可重復的測試。他是用於單元測試框架體系xUnit的一個實例（用於java語言）。它包括以下特性：
1、用於測試期望結果的斷言（Assertion）
2、用於共享共同測試數據的測試工具
3、用於方便的組織和運行測試的測試套件
4、圖形和文本的測試運行器
另外junit是在xp編程和重構（refactor）中被極力推薦使用的工具，因為在實現自動單元測試的情況下可以大大的提高開發的效率，但是實際上編寫測試代碼也是需要耗費很多的時間和精力的，那麼使用這個東東好處到底在哪裡呢？筆者認為是這樣的：
1、對於xp編程而言，要求在編寫代碼之前先寫測試，這樣可以強制你在寫代碼之前好好的思考代碼（方法）的功能和邏輯，否則編寫的代碼很不穩定，那麼你需要同時維護測試代碼和實際代碼，這個工作量就會大大增加。因此在xp編程中，基本過程是這樣的：構思－》編寫測試代碼－》編寫代碼－》測試，而且編寫測試和編寫代碼都是增量式的，寫一點測一點，在編寫以後的代碼中如果發現問題可以較塊的追蹤到問題的原因，減小回歸錯誤的糾錯難度。
2、對於重構而言，其好處和xp編程中是類似的，因為重構也是要求改一點測一點，減少回歸錯誤造成的時間消耗。
3、對於非以上兩種情況，我們在開發的時候使用junit寫一些適當的測試也是有必要的，因為一般我們也是需要編寫測試的代碼的，可能原來不是使用的junit，如果使用junit，而且針對介面（方法）編寫測試代碼會減少以後的維護工作，例如以後對方法內部的修改（這個就是相當於重構的工作了）。另外就是因為junit有斷言功能，如果測試結果不通過會告訴我們那個測試不通過，為什麼，而如果是想以前的一般做法是寫一些測試代碼看其輸出結果，然後再由自己來判斷結果使用正確，使用junit的好處就是這個結果是否正確的判斷是它來完成的，我們只需要看看它告訴我們結果是否正確就可以了，在一般情況下會大大提高效率。
安裝JUnit
安裝很簡單，先到以下地址下載一個最新的zip包： http://download.sourceforge.net/junit/
下載完以後解壓縮到你喜歡的目錄下，假設是JUNIT_HOME，然後將JUNIT_HOME 下的junit.jar包加到你的系統的CLASSPATH環境變數中，對於IDE環境，對於需要用到的junit的項目增加到lib中，其設置不同的 IDE有不同的設置，這里不多講。
如何使用JUnit寫測試？
最簡單的範例如下：
1、創建一個TestCase的子類
package junitfaq;
import java.util.*;
import junit.framework.*;
public class SimpleTest extends TestCase {
public SimpleTest(String name) {
super(name);
}
2、寫一個測試方法斷言期望的結果
public void testEmptyCollection() {
Collection collection = new ArrayList();
assertTrue(collection.isEmpty());
}
注意：JUnit推薦的做法是以test作為待測試的方法的開頭，這樣這些方法可以被自動找到並被測試。
3、寫一個suite()方法，它會使用反射動態的創建一個包含所有的testXxxx方法的測試套件
public static Test suite() {
return new TestSuite(SimpleTest.class);
}
4、寫一個main()方法以文本運行器的方式方便的運行測試
public static void main(String args[]) {
junit.textui.TestRunner.run(suite());
}
}
5、運行測試
以文本方式運行：
java junitfaq.SimpleTest
通過的測試結果是：
.
Time: 0
OK (1 tests)
Time上的小點表示測試個數，如果測試通過則顯示OK。否則在小點的後邊標上F，表示該測試失敗。
每次的測試結果都應該是OK的，這樣才能說明測試是成功的，如果不成功就要馬上根據提示信息進行修正了。
如果JUnit報告了測試沒有成功，它會區分失敗（failures）和錯誤（errors）。失敗是你的代碼中的assert方法失敗引起的；而錯誤則是代碼異常引起的，例如。
以圖形方式運行：
java junit.swingui.TestRunner junitfaq.SimpleTest
通過的測試結果在圖形界面的綠色條部分。
以上是最簡單的測試樣例，在實際的測試中我們測試某個類的功能是常常需要執行一些共同的操作，完成以後需要銷毀所佔用的資源（例如網路連接、資料庫連接，關閉打開的文件等），TestCase類給我們提供了setUp方法和tearDown方法，setUp方法的內容在測試你編寫的TestCase子類的每個testXxxx方法之前都會運行，而tearDown方法的內容在每個 testXxxx方法結束以後都會執行。這個既共享了初始化代碼，又消除了各個測試代碼之間可能產生的相互影響。
JUnit最佳實踐
Martin Fowler說過：「當你試圖列印輸出一些信息或調試一個表達式時，寫一些測試代碼來替代那些傳統的方法。」一開始，你會發現你總是要創建一些新的 Fixture，而且測試似乎使你的編程速度慢了下來。然而不久之後，你會發現你重復使用相同的Fixture，而且新的測試通常只涉及添加一個新的測試方法。
你可能會寫許多測試代碼，但你很快就會發現你設想出的測試只有一小部分是真正有用的。你所需要的測試是那些會失敗的測試，即那些你認為不會失敗的測試，或你認為應該失敗卻成功的測試。
我們前面提到過測試是一個不會中斷的過程。一旦你有了一個測試，你就要一直確保其正常工作，以檢驗你所加入的新的工作代碼。不要每隔幾天或最後才運行測試，每天你都應該運行一下測試代碼。這種投資很小，但可以確保你得到可以信賴的工作代碼。你的返工率降低了，你會有更多的時間編寫工作代碼。
不要認為壓力大，就不寫測試代碼。相反編寫測試代碼會使你的壓力逐漸減輕，應為通過編寫測試代碼，你對類的行為有了確切的認識。你會更快地編寫出有效率地工作代碼。
下面是一些具體的編寫測試代碼的技巧或較好的實踐方法：
1. 不要用TestCase的構造函數初始化Fixture，而要用setUp()和tearDown()方法。
2. 不要依賴或假定測試運行的順序，因為JUnit利用Vector保存測試方法。所以不同的平台會按不同的順序從Vector中取出測試方法。
3. 避免編寫有副作用的TestCase。例如：如果隨後的測試依賴於某些特定的交易數據，就不要提交交易數據。簡單的會滾就可以了。
4. 當繼承一個測試類時，記得調用父類的setUp()和tearDown()方法。
5. 將測試代碼和工作代碼放在一起，一邊同步編譯和更新。（使用Ant中有支持junit的task.）
6. 測試類和測試方法應該有一致的命名方案。如在工作類名前加上test從而形成測試類名。
7. 確保測試與時間無關，不要依賴使用過期的數據進行測試。導致在隨後的維護過程中很難重現測試。
8. 如果你編寫的軟體面向國際市場，編寫測試時要考慮國際化的因素。不要僅用母語的Locale進行測試。
9. 盡可能地利用JUnit提供地assert/fail方法以及異常處理的方法，可以使代碼更為簡潔。
10.測試要盡可能地小，執行速度快。
JUnit和ant結合
ant 提供了兩個 target ： junit 和 junitreport 運行所有 測試用例 ，並生成 html 格式的報表
具體操作如下：
1.將 junit.jar 放在 ANT_HOMElib 目錄下
2.修改 build.xml ，加入如下 內容：
-------------- One or more tests failed, check the report for detail... -----------------------------
運行 這個 target ，ant 會運行每個 TestCase，在 report 目錄下就有了 很多 TEST*.xml 和 一些網頁打開 report 目錄下的 index.html 就可以看到很直觀的測試運行報告，一目瞭然。
在Eclipse中開發、運行JUnit測試相當簡單。因為Eclipse本身集成了JUnit相關組件，並對JUnit的運行提成了無縫的支持。

7. 用junit測試某個方法時,能否調用同一個類中未經測試的另一個方法

push() pop() peek()是靜態方法，或者new一個MyStack的靜態實例，就可以這樣做，而且可以根據testcase的上下順序將上一次執行的結果做為下一個用例的輸入，但是這樣做就破壞了每個用例的數據獨立性，不利於長期維護同時也很容易出現測試代碼上的錯誤，不建議這樣用。push() pop() peek()三個方法一般會協同使用，所以用例設計時應該將每個場景獨立設計，在每個testcase前對MyStack進行初始化，針對Stack中所存儲數據邊界值、等價類、Stack中方法單獨調用，反復調用，交叉調用等情況分別設計用例覆蓋。

8. 軟體測試的方法有哪些

選擇培訓機構時就一定考慮到以下幾點：

1、課程選擇，不要只是簡單的學習功能測試，而是會涵蓋有現在流行的自動化測試、GUI測試，介面測試和性能測試開發等內容；

2、培訓機構的教學不僅僅是教會你做標準的軟體測試，而是要教你一些測試邏輯，教會你使用工具但又不依賴於這些工具也可以完成自動化測試，也就是其背後的底層的工作原理，這些東西才是真正能夠內化成屬於你個人的核心競爭力。

3、現在的移動互聯網企業對自動化測試的需求非常大，也會要求學員掌握程序設計的原理，所以測試開發性綜合性人才才是未來IT行業的需求方向。

4、一定要去參加試學，因為很多人目標不明確，甚至是迷茫的，所以去試學一周，看看自己是不是真的想做技術，或者適合做技術。

5、授課方式，有些是面授，有些是視頻授課，各有優點，就看自己喜歡哪種了。當然，線下面授的學費應該更高，畢竟成本在那裡，學習時有老師盯著，有同學陪著，能夠更快的進入學習的狀態，有更充足的鬥志。

9. 軟體測試的方法一共有幾種

1、從是否關心內部結構來看

（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。

（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。

（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。

2、從是否執行代碼看

（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。

(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。

3、從開發過程級別看

（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。

(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。

（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

在系統測試中，對於具體的測試類型有：

（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。

（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。

（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。

（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。

（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）

（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。

（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。

（11）數據處理測試：對完成專門數據處理功能所進行的測試。

（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。

（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。

（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。

（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。

（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。

（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。

（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。

4、從執行過程是否需要人工干預來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。

（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）

5、從測試實施組織看

（1）開發測試：開發人員進行的測試

（2）用戶測試：用戶方進行的測試

（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環境看

（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(9)如何用一個測試方法去調起擴展閱讀

軟體測試的內容：

1 得到需求、功能設計、內部設計說書和其他必要的文檔

2 得到預算和進度要求

3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )

4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試

6 確定對測試環境的要求 ( 硬體、軟體、通信等 )

7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等

8 確定對測試的輸入數據的要求

9 分配任務和任務負責人，以及所需的勞動力

10 設立大致的時間表、期限、和里程碑

11 確定輸入環境的類別、邊界值分析、錯誤類別

12 准備測試計劃文件和對計劃進行必要的回顧

13 准備白盒測試案例

14 對測試案例進行必要的回顧 / 調查 / 計劃

15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

19 跟蹤問題 / 錯誤，並解決它

20 如果有必要，重新進行測試

21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具

10. 如何提高測試效率

1.盡早參與到項目中
測試盡早介入項目詳細了解項目的業務需求，做好測試的前期准備：目前來說，可能大家都有類似的感受，接觸到的大多數的項目，都是測試周期比較短，開發人員耽誤了時間，為了不拖延項目進度，留給測試人員做測試的時間都非常緊張。如果項目測試的前期了解業務需求、了解產品屬性和准備測試數據不充分，往往測試效率很低，測試時間變長，測試效率急劇下降。
2.合理的測試計劃
首先要有一個合理的詳細的測試計劃：沒有詳細的測試計劃，測試部的每個成員都在那兒盲無目的測試，何談提高測試效率？當然測試計劃也不能夠太細，太細了，編寫測試計劃同樣浪費時間，做到時可而止。最好是測試任務盡量能細化到測試的功能較為理想。
3.要做好測試文檔的評審
測試負責人認真做好測試文檔的評審：測試經理一定要認真做好測試用例的評審，盡量使用較少的測試用例，發現較多的Bug，無疑是最佳提高效率的一種方式。很多時候，經驗較少的測試人員在設計測試用例的時候，寫了很多的測試用例，測試時幾乎沒有發現缺陷。還有一種：比如說等價類的測試，只要具備代表性就可以了，如果寫了很多測試用例，執行了半天，臃腫的測試用例，未發現任何問題，也很不值。這些主要是靠測試用例評審的時候，測試Leader去把握了。盡量做到在滿足需求的情況下，精簡測試用例數量，提高測試覆蓋率。很多時候，測試人員寫好用例就自己測試，根本沒人評審，有些地方理解有偏差，測試點沒測試到，導致發給客戶版本被退回，給公司也會帶來巨大經濟損失。
4.提高測試接受的標准，減少測試版本送測次數：
大部分公司的開發人員都有一種惰性，一旦公司成了測試部，他們自己測試時，都不會那麼認真，以為有了測試人員，就自己就解放了。很多時候都是調試編譯通過，實際上開發人員沒有做完整的自測，就拿到測試部進行測試。如果測試部門有嚴格的測試接受標准，一旦發現有重大問題，立即拒絕測試，送回開發人員修改。可以減少很多次反復測試，重復測試，明顯提高了測試效率。
5.發揮主觀能動性，積極溝通
測試工作是一項溝通要求比較高的工作，一般需要同項目經理、產品經理、開發人員、業務人員、客戶溝通。很多時候，由於測試介入較晚，測試時間短，測試初期測試人員了解需求不及開發人員，為了迅速熟悉需求，需要項目組成員之間相互培訓和溝通。測試人員為了利於測試工作，平時也需要主動和開發團隊溝通項目的進度、項目存在的問題、項目的需求變更等等情況。與團隊成員溝通得越充分、對項目的信息收集和把握得越及時、越准確，我們的測試工作才可能做得越順利，才可能提高測試效率。我們絕不能消極等待或一味埋怨開發人員的不理解和不重視。我們首先需要正視自己、改進自己，通過自身的不斷努力讓開發人員，真正體會到測試的價值。同時，也需要理解並配合開發人員的工作。只有這樣，才能贏得開發人員的支持。互相配合、互相促進，項目成員之間形成良性循環，彼此感情加深了、配合默契了、工作效率和工作質量也就自然提高了。
6.按照項目的性質大小不同，引入自動化測試工具和自動化測試腳本
是否引入自動化的測試工具，主要取決於測試的時間長短和測試的輪次。一般來說，測試周期較長、版本升級平凡和回歸測試次數較多的項目，引用測試工具可以提高測試效率。如果測試周期較短，本來測試周期只有兩三個月，開發測試腳步就要花費大量時間，引入自動化測試工具，用的次數較少，結果得不喪失，勞民傷財！
7.對測試項目前景充滿信心，調整最佳心態，保持愉悅的工作心情：
一般來說，如果大家認為測試的項目沒什麼發展前景，當然測試也不會很賣命，測試效率不用說。如果某個測試人員碰到什麼不順心的事，當天的工作效率肯定比平常低。所以，要保證測試效率，測試負責人要察言觀色，及時找不開心的下屬談心，了解並幫忙消除部分員工的不良情緒，讓員工有更好的心情投入到測試工作中去。
8.提高測試人員的專業技能和工作能力：
由於測試技術的不斷成熟和完善，許多的新技術陳出不窮，作為測試人員需要不斷提高自己的專業技能和工作技能。不斷的給自己充電，補充測試理論知識，讓自己工作技能力去彌補專業技能的不足。這樣，你的工作同樣可以做到最棒，效率自然很高。一段時間過去，回過頭來一看，自己確實進步不少，沒有虛度光陰呀！