自動化測試沒有工作經驗

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

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）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(1)自動化測試沒有工作經驗擴展閱讀

軟體測試的內容：

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

2 得到預算和進度要求

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

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

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

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

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

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

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

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

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

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

13 准備白盒測試案例

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

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

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

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

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

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

❷ 我做軟體測試有些年了，項目經驗也較豐富，可是基本很少接觸自動化測試，反而做了一些項目管理梳理的工作

每個公司都有抄自己獨特的開發襲經驗和技術走向，如果覺得和自己預期的偏離了，那擺在你面前的就是岔路口，跟著公司走，或者跟著自己走，糾結是沒有用的，做個決定，別怕找不到，測試崗位現在越來越被企業所重視，現在還是挺缺人的，可以試試。 來自職Q用戶：鄧先生
自動化可以自己部署測試環境練手，這東西不難。做了這么多年你可以嘗試轉型，比如你說的項目管理，或者產品 來自職Q用戶：林先生

❸ 做軟體測試的，工作4年,自動化測試經驗近兩年，求問，申請自動化職位工資大概能拿多少

8K到9K，也可以要10K，不過10K一般會被壓價，當然不同的地方的價格是不一樣的，這個和所在的城市消費水平有關。

❹ 想找軟體測試工作，自動化方面，18年7月畢業，有兩份實習經驗都是功能測試，第一份6個月，第二份不到

如果作為第一份真正抄意義上的工作的話，請別用薪資限制了自己的選擇，請做好相應的規劃和安排，自己嚮往的工作環境，和心儀的工作所處行業，公司的發展前景，這些是更加看中的，一家優秀的公司，有很明確的薪酬體系，在一定意義上可以說不會虧待他們想要的人才的 來自職Q用戶：江先生
問題是你沒自動化經驗，不知道你會不會自動化，如果不會的話基本找不到，當然，不排除從功能測試培養你到自動化的大型測試中心或公司，要麼去參加培訓，學習自動化後再去找自動化，不然，你只能先找一個能接觸到自動化的公司，慢慢學習和鑽研，就OK了。 來自職Q用戶：三觀正

❺ 富士康普通工人的真實工作狀態如何

富士康很多人第一反應都是流水線，因為富士康的主要工作就是代工，所以大多數人到富士康裡面打工，都會到流水線上當操作人員，但是這並不妨礙富士康在廣大務工人員心中的形象，因為在這座工廠裡面，只要你踏實肯干，就一定能夠掙到比別人更多的工資，可不久之前一名富士康的員工卻說出了一些我們不知道的秘密。
這個富士康的員工表示在富士康裡面，工作10個小時以上的那些人月工資只有3500，富士康裡面有三件事情是最黑的，第1個就是中介，很多人進富士康都不是工廠直招進來的，而是被一些黑中介騙進來的，在進場之前中介會把工廠的各種情況描述的天花亂墜，但是當打工人員來到工廠以後，才發現自己上當受騙，可大多數人在這個時候早就已經簽訂了勞務合同。
其次就是老闆黑，有很多富士康的老闆根本就不把員工當人，簡直就是在把他們當成機器人使用，恨不得他們一天24小時都能夠在流水線上工作，而且在富士康打工的這些人基本沒有任何自由可言，上班期間不能說話也不能夠看手機，只能夠重復性的忙著手裡的事情，這對於很多人來說實在是太折磨了。
而最後一件事情就是主管，在富士康裡面有很多主管特別黑，由於他們是領導崗位，所以工人們都非常懼怕他們，而且主管主要管理考核方面的東西一旦得罪了主管，只要他給你在考勤表上稍微改動一下，你的工資，將會和別人產生天差地別的變化。所以這個打工仔認為明年還是回家種土豆吧，最起碼不會被工廠裡面的這些大事小情給坑騙，在外面打工實在是太難了。

❻ Python自動化測試程序員1年工作經驗的工資多少錢

國內的Python程序方面的工作太少了,價格還不清楚,我上幾天在群里看到北京一個招PYTHON的.月薪上萬.是開發,但我想.如果你懂其它的語言.測試工作應該有四千吧.我是在深圳.

❼ 現在學什麼專業好

現在比較好的專業有經濟學類專業、語言類專業、公共事業管理類專業、中國語言文學類專業、工商管理。

1、經濟學類專業

這個專業被稱為高富帥專業，畢業生就業面非常廣，不管是考公務員，金融機構、留校還是大中型企業等都可以有適合的崗位適合的工作，甚至有能力還能自主創業。但因為經濟學學的東西多，想要學好並不容易，想要好就業對專業能力要求相對較高。

4、中國語言文學類專業

這個專業是很多文科生最愛報考的專業，比如漢語言文學、對外漢語、秘書學等，尤其是漢語言文學專業，看似能做的工作很多，當老師、考公務員、做編輯等都是很不錯的發展前景，但競爭激烈，對文學功底要求很高。

5、工商管理

工商管理也是一個就業方向很多的專業，不過很多人是認為這個專業是一個所學知識很雜的專業，所以很難讓學生能夠抓住重點，看似能走的工作多，但往往專業性不夠，除了考研之外，大部分畢業生都不知道自己該做什麼工作。

大學選專業注意事項：

1、是否感興趣：進入大學將要在這四年內學習的專業可能就決定以後的專業方向，很多進入大學後發現自己所學的專業自己並不喜歡，然後在退學回高中復讀的人也很多，所以一定要選自己喜歡的感興趣的專業，也有人畢業後從事了和專業無關的職業，這樣大學好像白讀了。

2、不要忽略專業限制：有些特殊的專業對考生有身高、視力等方面的要求。專業方向：在大學所讀的專業決定的以後是做什麼工作的。所以選擇專業的時候一定要慎重。

3、 選擇優勢專業：選定了專業的方向以後，可以參考某些有特色專業的院校，如果專業不好再好的大學也很難找工作，所以在先選專業，學校次之。

❽ 軟體測試 畢業論文

搜一個給你參考一下：
軟體測試從零開始
引言

幾年前，從學校畢業後，第一份工作就是軟體測試。那時候，國內的軟體企業大多對軟體測試還沒有什麼概念，書店裡除了鄭人傑編寫的《計算機軟體測試技術》之外，幾乎沒有其它的軟體測試相關書籍，軟體測試僅僅在軟體工程的教材中作為一個章節列出來，因此，我對軟體測試一無所知。不過，在正式走上工作崗位之前，公司提供了為期兩周的系統的軟體測試技術專題培訓，對接下來的軟體測試工作有很大的指導意義。現在，我繼續從事軟體測試的培訓與咨詢服務，在這個過程中，親眼目睹了很多軟體測試新手面對的困惑，他們初涉軟體測試行業，沒有接受系統的培訓，對軟體測試一無所知，既不知道該測試什麼，也不知道如何開始測試。下面針對上述情況，給出若干解決辦法。

• 測試准備工作

在測試工作伊始，軟體測試工程師應該搞清楚軟體測試工作的目的是什麼。如果你把這個問題提給項目經理，他往往會這樣回答： 「 發現我們產品裡面的所有 BUG ，這就是你的工作目的 」 。作為一名軟體測試新手，如何才能發現所有的 BUG ？如何開始測試工作？即便面對的是一個很小的軟體項目，測試需要考慮的問題也是方方面面的，包括硬體環境、操作系統、產品的軟體配置環境、產品相關的業務流程、用戶的並發容量等等。該從何處下手呢？

• 向有經驗的測試人員學習

如果你進入的是一家運作規范的軟體公司，有獨立的軟體測試部門、規范的軟體測試流程、軟體測試技術有一定的積累，那麼，恭喜你！你可以請求測試經理委派有經驗的測試人員作為你工作上的業務導師，由他列出軟體測試技術相關書籍目錄、軟體測試流程相關文檔目錄、產品業務相關的文檔目錄，在業務導師的指導下逐步熟悉軟體測試的相關工作。其實，在很多運作規范的軟體公司，已經把上述的師父帶徒弟的方式固化到流程中。

如果你進入的是一個軟體測試一片空白的軟體企業，那麼，也恭喜你！你可以在這里開創一片自己的軟體測試事業，當然，前提是老闆確實認識到軟體測試的重要性，實實在在需要提高產品的質量。這時候，可以到國內的軟體測試論壇和相關網站上尋找軟體測試資源，這種情況下，自學能力和對技術的悟性就至關重要了。

• 閱讀軟體測試的相關書籍

現在，中文版的軟體測試書籍越來越多，有的是國人自己寫的，有的是翻譯國外經典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等網路購書的站點查找軟體測試相關的書籍。目前，從國外引入的軟體測試書籍有很多經典之作，但是，翻譯成中文後，翻譯質量對閱讀效果有很大的影響。

• 走讀缺陷跟蹤庫中的問題報告單

如果您所在的公司已經有軟體缺陷跟蹤庫了，無論採用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，還是採用的 Bugzilla 、 Mantis 等開源工具，這都無關緊要，缺陷跟蹤庫中的缺陷報告單才是有價值的。缺陷跟蹤庫中的問題報告單是軟體測試工程師工作績效的集中體現，同時也是軟體產品問題的集中體現。一般來說，缺陷報告單中最關鍵的幾個部分包括：第一部分是發現缺陷的環境，包括軟體環境、硬體環境等；第二部分是缺陷的基本描述；第三部分是開發人員對缺陷的解決方法。通過對上述缺陷報告單的三個部分作仔細分析，不知不覺你已經吸收了其他軟體測試人員的工作經驗，並掌握了軟體產品常見的基本問題。這是迅速提高軟體測試經驗的好方法。

• 走讀相關產品的歷史測試用例

如果你所在的公司有測試用例管理系統，那麼，走讀相關產品的軟體測試用例是迅速提高測試用例設計水平的一條捷徑。走讀測試用例也是有技巧的。測試用例寫作一般會包括測試用例項和根據測試用例項細化的測試用例，下面舉例說明。 「 測試用戶登錄的功能 」 是一個測試項，該測試項的目的是測試用戶登錄功能是否正確，是否能夠完成正常的登錄功能，是否能夠對非法用戶名和密碼做異常處理等等。因此，根據該用例項，可以設計出若干個測試用例，大多數情況下，測試用例項和測試用例是一對多的關系。

通過走讀測試用例項目，你可以掌握應該從哪些功能點著手未來的測試工作；通過走讀軟體測試用例，你可以了解如何根據被測試的功能點開展軟體測試用例的設計工作，包括如何確定測試用例的輸入、測試用例的操作步驟和測試用例的輸出結果等。

總之，走讀其他軟體測試人員設計的優秀軟體測試用例，是提高自身用例設計水平的好方法。

• 學習產品相關的業務知識

軟體測試人員不僅要掌握軟體測試技術相關知識，對產品相關的業務知識也要學習。這很好理解，如果從事財務軟體的測試工作，一定要學習財務知識；如果從事通訊產品測試工作，那麼相關的通訊理論知識也是必須的；如果從事銀行軟體的測試，銀行的業務流程也是不可或缺的知識點。

因此，在學習軟體測試技術的同時，千萬不要忽略產品相關業務知識的學習。如果你是一個軟體測試技術專家，但是對產品業務知識一無所知，那麼也只能測試出來純粹的軟體缺陷，而面對眼前出現的產品業務相關的缺陷，很可能是視而不見，如此這般，軟體測試的效果會大打折扣。

• 識別測試需求

識別測試需求是軟體測試的第一步。如果開發人員能夠提供完整的需求文檔和介面文檔，那固然好。可以根據需求文檔中描述的每個功能項目的輸入、處理過程和輸出，來設計測試用例。如果開發人員沒有提供軟體需求文檔，那該如何是好？下面給出幾個有效的方法：

• 主動獲取需求

開發人員通常不會更好地考慮軟體測試，如果沒有開發流程的強制規定，他們通常是不願意提供任何開發文檔，即便有強制規定，需求文檔也未必能夠真正指導軟體系統測試工作。因此，需要測試人員發揮主觀能動性，與相關的軟體開發項目經理和軟體開發人員保持溝通，了解軟體實現的主要功能是什麼，並記錄得收集到的信息。一般來說，開發人員即便沒有提供相關需求文檔，也會保存一些簡單的過程文檔，主動向開發人員索要這些文檔，可以作為測試的參考。此外，可以與公司的技術支持人員交流，技術支持人員是最貼近用戶的人，因此，通過交流可以獲取第一手的用戶使用感受，在測試的過程中會更加貼近用戶。

當拿到相關的資料後，從哪些方面分析需求？如何與開發人員交流需求？其實，只要把握需求分析的幾個關鍵的點就可以解決問題：輸入、處理過程、輸出、性能要求、運行環境，下面針對每一個項目逐一分析：

軟體輸入： 與該需求相關的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入參數的數量、輸入參數的度量單位、輸入參數的時間要求、輸入參數的精度和輸入參數的有效輸入范圍。在測試用例設計中，這部分內容作為測試用例輸入的依據。

處理過程： 描述對輸入數據所執行的所有操作和如何獲得輸出的過程。測試人員了解處理過程即可，在測試過程中發現 BUG 時候，如果對處理過程了解的深入，對定位問題根源有很大的幫助。

軟體輸出： 描述每個需求的輸出結果，包括輸出的位置（如計算機顯示器、列印機，文件），輸出參數的數量、輸出參數的度量單位、輸出參數的時序、輸出參數精確度、輸出參數的有效輸出范圍、錯誤消息。在測試用例設計中，這部分內容作為測試用例的預期輸出。

性能要求： 與該需求相關的性能要求，比如 「 插入 ATM 取款卡後， 3 秒鍾內彈出提示用戶取款的圖形界面 」 。 3 秒鍾這一限制，就是對需求的基本性能要求。

運行環境： 軟體的運行所需的環境，包括硬體平台的要求、操作系統的要求、資料庫的要求，以及其它相關支撐軟體的要求。

• 確認需求的優先順序

確認需求的優先順序是很必要的，如果在產品進度比較緊的情況下，測試人員可以考慮優先測試優先順序高的需求項，如果進度允許，那麼在測試優先順序低的需求項，如果進度不允許，那麼就放棄測試優先順序低的需求項。如果軟體公司有規范的流程支撐，開發人員在提供軟體需求文檔的時候，應該在文檔中確定需求的優先順序。但是，如果開發人員連基本的軟體需求文檔都沒有提供，又怎能指望他們確定軟體需求的優先順序？如果是這樣，需求的優先順序只能由測試人員完成了。

• 加入開發小組的郵件群組

測試人員需要通曉被測試產品，但是，產品在開發的過程中往往是不斷變化的。如果軟體開發團隊有一套變更控制流程，測試人員會對產品的變更了如指掌。如果沒有變更控制，那就要採用其他的土方法了。如果公司裡面有自動化辦公系統，也許採用的是 Lotus Notes 系統，也許使用的是 E-mail 系統，測試人員應該加入到開發人員的郵件群組中。當開發人員通過郵件討論問題、通知召開技術會議的時候，測試人員可以及時知曉，如果必要，可以參加開發人員的技術會議。即便公司裡面有了軟體變更控制流程，加入到開發郵件群組也是一個很好的習慣。

• 與開發人員為鄰

建議測試人員與開發人員為鄰。我所在的測試組曾經與開發組是在相鄰的寫字間里，開發人員與測試人員的關系非常融洽，拋去同事關系，大家還是不錯的朋友。不管開發人員有什麼樣的活動，測試人員都能第一時間獲得信息。無論從事軟體測試工作，還是從事其它的工作，與工作中上下游環節的同事保持良好的個人關系對工作有很大便利。一般的公司內部都存在部門牆，良好的人際關系是打通部門牆的手段之一。向領導建議測試人員與開發人員為鄰，這很必要。

• 測試用例設計

測試需求收集完畢後，開始測試設計。測試用例是什麼？測試用例就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。設計測試用例需要考慮以下問題：

• 重用同類型項目的測試用例

如果我看得遠，那是因為我站在巨人的肩上 －－牛頓。

一般來說，每個軟體公司的項目可以分為固定的幾大類。可以按業務類型劃分，比如 ERP 軟體、產品數據管理軟體、通信軟體、地理信息系統軟體等等；可以按軟體結構來劃分，比如 B/S 架構的軟體、 C/S 架構的軟體、嵌入式軟體等等。參考同類別軟體的測試用例，會有很大的借鑒意義。如果，公司中有同類別的軟體系統，千萬別忘記把相關的測試用例拿來參考。如果，系統非常接近，甚至經過對測試用例簡單修改就可以應用到當前被測試的軟體。 「 拿來主義 」 可以極大的開闊測試用例設計思路，也可以節省大量的測試用例設計時間。

• 測試用例執行

測試用例設計完畢後，接下來的工作是測試執行，測試執行中應該注意以下幾個問題：

• 搭建軟體測試環境，執行測試用例

測試用例執行過程中，搭建測試環境是第一步。一般來說，軟體產品提交測試後，開發人員應該提交一份產品安裝指導書，在指導書中詳細指明軟體產品運行的軟硬體環境，比如要求操作系統系統是 Windows 2000 pack4 版本，資料庫是 Sql Server 2000 等等，此外，應該給出被測試軟體產品的詳細安裝指導書，包括安裝的操作步驟、相關配置文件的配置方法等等。對於復雜的軟體產品，尤其是軟體項目，如果沒有安裝指導書作為參考，在搭建測試環境過程中會遇到種種問題。

如果開發人員拒絕提供相關的安裝指導書，搭建測試中遇到問題的時候，測試人員可以要求開發人員協助，這時候，一定要把開發人員解決問題的方法記錄下來，避免同樣的問題再次請教開發人員，這樣會招致開發人員的反感，也降低了開發人員對測試人員的認可程度。

• 測試執行過程應注意的問題

測試環境搭建之後，根據定義的測試用例執行順序，逐個執行測試用例。在測試執行中需要注意以下幾個問題：

全方位的觀察測試用例執行結果： 測試執行過程中，當測試的實際輸出結果與測試用例中的預期輸出結果一致的時候，是否可以認為測試用例執行成功了？答案是否定的，即便實際測試結果與測試的預期結果一致，也要查看軟體產品的操作日誌、系統運行日誌和系統資源使用情況，來判斷測試用例是否執行成功了。全方位觀察軟體產品的輸出可以發現很多隱蔽的問題。以前，我在測試嵌入式系統軟體的時候，執行某測試用例後，測試用例的實際輸出與預期輸出完全一致，不過在查詢 CPU 佔用率地時候，發現 CPU 佔用率高達 90 ％，後來經過分析，軟體運行的時候啟動了若干個 1ms 的定時器，大量的消耗的 CPU 資源，後來通過把定時器調整到 10ms ， CPU 的佔用率降為 7 ％。如果觀察點單一，這個嚴重消耗資源的問題就無從發現了。

加強測試過程記錄： 測試執行過程中，一定要加強測試過程記錄。如果測試執行步驟與測試用例中描述的有差異，一定要記錄下來，作為日後更新測試用例的依據；如果軟體產品提供了日誌功能，比如有軟體運行日誌、用戶操作日誌，一定在每個測試用例執行後記錄相關的日誌文件，作為測試過程記錄，一旦日後發現問題，開發人員可以通過這些測試記錄方便的定位問題。而不用測試人員重新搭建測試環境，為開發人員重現問題。

及時確認發現的問題： 測試執行過程中，如果確認發現了軟體的缺陷，那麼可以毫不猶豫的提交問題報告單。如果發現了可疑問題，又無法定位是否為軟體缺陷，那麼一定要保留現場，然後知會相關開發人員到現場定位問題。如果開發人員在短時間內可以確認是否為軟體缺陷，測試人員給予配合；如果開發人員定位問題需要花費很長的時間，測試人員千萬不要因此耽誤自己寶貴的測試執行時間，可以讓開發人員記錄重新問題的測試環境配置，然後，回到自己的開發環境上重現問題，繼續定位問題。

與開發人員良好的溝通： 測試執行過程中，當你提交了問題報告單，可能被開發人員無情駁回，拒絕修改。這時候，只能對開發人員曉之以理，做到有理、有據，有說服力。首先，要定義軟體缺陷的標准原則，這個原則應該是開發人員和測試人員都認可的，如果沒有共同認可的原則，那麼開發人員與測試人員對問題的爭執就不可避免了。此外，測試人員打算說服開發人員之前，考慮是否能夠先說服自己，在保證可以說服自己的前提下，再開始與開發人員交流。

• 及時更新測試用例

測試執行過程中，應該注意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若干個冗餘的測試用例完全可以由某一個測試用例替代，那麼刪除冗餘的測試用例。

總之，測試執行的過程中及時地更新測試用例是很好的習慣。不要打算在測試執行結束後，統一更新測試用例，如果這樣，往往會遺漏很多本應該更新的測試用例。

• 提交一份優秀的問題報告單

軟體測試提交的問題報告單和測試日報一樣，都是軟體測試人員的工作輸出，是測試人員績效的集中體現。因此，提交一份優秀的問題報告單是很重要的。軟體測試報告單最關鍵的域就是 「 問題描述 」 ，這是開發人員重現問題，定位問題的依據。問題描述應該包括以下幾部分內容：軟體配置、硬體配置、測試用例輸入、操作步驟、輸出、當時輸出設備的相關輸出信息和相關的日誌等。

軟體配置： 包括操作系統類型版本和補丁版本、當前被測試軟體的版本和補丁版本、相關支撐軟體，比如資料庫軟體的版本和補丁版本等。

硬體配置： 計算機的配置情況，主要包括 CPU 、內存和硬碟的相關參數，其它硬體參數根據測試用例的實際情況添加。如果測試中使用網路，那麼網路的組網情況，網路的容量、流量等情況。硬體配置情況與被測試產品類型密切相關，需要根據當時的情況，准確翔實的記錄硬體配置情況。

測試用例輸入 \ 操作步驟 \ 輸出： 這部分內容可以根據測試用例的描述和測試用例的實際執行情況如實填寫。

輸出設備的相關輸出信息： 輸出設備包括計算機顯示器、列印機、磁帶等等輸出設備，如果是顯示器可以採用抓屏的方式獲取當時的截圖，其他的輸出設備可以採用其它方法獲取相關的輸出，在問題報告單中提供描述。

日誌信息： 規范的軟體產品都會提供軟體的運行日誌和用戶、管理員的操作日誌，測試人員應該把測試用例執行後的軟體產品運行日誌和操作日誌作為附件，提交到問題報告單中。

根據被測試軟體產品的不同，需要在 「 問題描述 」 中增加相應的描述內容，這需要具體問題具體分析。

測試結果分析

軟體測試執行結束後，測試活動還沒有結束。測試結果分析是必不可少的重要環節， 「 編筐編簍，全在收口 」 ，測試結果的分析對下一輪測試工作的開展有很大的借鑒意義。前面的 「 測試准備工作 」 中，建議測試人員走讀缺陷跟蹤庫，查閱其他測試人員發現的軟體缺陷。測試結束後，也應該分析自己發現的軟體缺陷，對發現的缺陷分類，你會發現自己提交的問題只有固定的幾個類別；然後，再把一起完成測試執行工作的其他測試人員發現的問題也匯總起來，你會發現，你所提交問題的類別與他們有差異。這很正常，人的思維是有局限性，在測試的過程中，每個測試人員都有自己思考問題的盲區和測試執行的盲區，有效的自我分析和分析其他測試人員，你會發現自己的盲區，有針對性的分析盲區，必定會在下一輪測試用避免盲區。

總結：

限於文章的篇幅，本文不可能給出一個類似於 checklist 的指導性的軟體測試新手入門。無論從事軟體測試還是從事其它的工作，技術上的和技巧上的問題都可以通過查詢相關的軟體測試技術書籍獲取，掌握一套基本的方法論是最重要的。以上文字，都是作者從事軟體測試工作積累的經驗之談，如發現謬誤之處請不吝指出。