第一篇：自動化測試學習歷程感悟--（定稿）

軟件設計與自動化測試學習歷程感悟

序言：最近一段業余時間都在進行web編程設計，采用的是JSP技術，雖然JSP在網站設計上過于復雜，可是其能幫助學習java的思想，而且覺得在理解自動化測試方面頗有些幫助。自動化測試設計也是軟件產品設計的一種，不過為了在此區分，一個為被測試軟件的設計，一個為測試軟件的設計。前者是面向特定用戶使用的，后者是面向測試人員使用的，前者是為了幫助特定用戶實現某個場景、提高生活效率。后者是為了幫助測試人員完成測試工作，提高測試效率。

回想自動化測試過程和軟件設計學習過程，后來看了一個人所謂的軟件設計學習歷程，頗有感悟，當然，只是在這里說說自己的感受，也許說的有點亂，讀者需要保持一顆自我和清醒的心。

軟件設計學習過程：

某位人士23歲畢業，對Java的優雅設計情有獨鐘，其Java技術之旅開始了。

1、最開始三個月，開始接觸Java，比如接口、繼承、封裝等，買了本《Think in Java》天天啃，并且同時做項目實踐。猛學了三個月后，對面向對象編程OOP熟悉了，原來腳本式思維和對象思維確實有差別。

2、三個月后，開始啃《Core Java》，《Effective Java》，對Java有了更深入的了解，回調的概念也有了，逐漸接觸到更高的層次，面向對象設計OOD，這時又看了一本書《Head First Design Patterns》，感覺設計模式特別有趣。再寫代碼，已經不是面向實現編程，而是面向設計編程。感覺寫Java代碼太簡單了。逐漸了解了WebWork等Web框架的使用。

3、六個月過去了，Java癮越來越大，逐漸開始往更高層次攀登，這時，又看到兩本書《企業應用架構模式》、《UML和模式應用：面向對象分析與設計導論》，已經開始從設計往面向對象分析OOA、架構攀登了。Hibernate已經比較熟悉了，了解Hibernate背后的持久化技術、Spring背后的IoC容器、組裝技術原理。

4、一年后，他逐漸脫離了Java語言，開始看這類書《面向模式的軟件體系結構卷1》。這個階段持續了一年，并且對以前的學過的設計模式，如命令模式、觀察家模式有一個更深入的了解。因為兩年的企業應用開發，他已經熟悉了Java EE的十來種規范，對Web容器和Servlet規范的關系有很深的理解，對JDBC規范和數據庫驅動程序的關系也很了解。他正在經歷Java開發的快速上升期。

5、兩年后，他突然發現，他學的很多東西都沒用，都是紙上談兵，比如，在自己的企業應用開發中，Command模式、Template從來沒有用過。他還發現，本來100行寫的一個功能，花了1000行，就是為了所謂的設計優雅性：可擴展。而實際上，還沒有等到擴展，該系統就已經廢掉了。他發現原來設計模式主要用在系統框架開發，而不是應用開發，一般開發人員不用，只需要理解。他還發現，他認真學過的JMS、JCA、JTA、EJB像是從來沒有用過。突然他想通了，JMS、JTA可能是一種無奈的選擇：處理遺留系統。當他開始對自己兩年學到的知識進行反省、批駁時，他已經有了技術辨別能力，知道技術推廣也不是那么純潔，也有商業炒作。這時候，他已經不限于Java了，開始了解C#，Ruby，發現Java可能并不太適合互聯網開發，PHP可能更適合，ROR開發更快但需要在牛人的手里。兩年后的這個時候，他才開始真正駕馭Java，他已經不再限于Java，而是企業應用。這個時候，技術提升的速度越來越慢了，因為不知道還可以學習什么新技術。因為他發現，原來這些東西，最深層次的，都是幾十年前的技術概念：消息系統、異步通訊、事件機制等等....6、三年過去后，他已經不再限于企業應用，而是解決方案，技術只是一種解決問題的方式，比如企業信息化成功的關鍵，恐怕不是技術，而是企業本身的業務流程成熟度;企業信息化成功的關鍵，不是處理好了技術，而是處理好了幾位企業高官的利益。這時候，對IT行業新聞，逐漸有判斷力和免疫力。他突然發現，技術的力量很有限，商業才是最大的驅動力量。而此時，他已經不再鉆研技術細節，比如JVM的垃圾回收機制，如果他在一個技術研發型公司，比如普元，可能還會深入挖掘技術。如果他在東軟這類行業應用開發企業，這類企業的口號是Beyond Technology，這時候他再執迷于技術而輕業務，恐怕不太受歡迎。這個時候，技術的提升，就會進入一個平臺期。

自動化測試學習過程：

自動化測試的整個學習過程中，不斷在探索，雖然時間不算很長，但是確實是在一直在思考、一直在觀察、一直在領悟：

1、剛開始的時候，是從手工測試入手，偶然之間開始了自動化測試之旅，發現自動化測試很神奇，在進行自動化測試用例撰寫過程中(命令行的填充)，對腳本技術(tcl)猛學了幾個月。

2、若干月后，隨著自動化測試用例加多，偶然開始有了結果的輸出、日志的記錄以及腳本庫。在不清楚所謂的框架時，形成了一個簡單的“框架”。

3、之后，需要對界面進行測試，開始研究自動化測試工具，之后在領悟了其神奇之后，開始瘋狂的學習商業自動化測試工具(RFT、QTP等)，因為主要是研究RFT，被其ITCL的框架深深打動、后來在實踐過程中，脫離了錄制，開始迷戀基于工具的各種框架。RFT的ITCL、QTP的輕量級框架以及各種工具的自動化測試框架，后來也學會了自己去拓展這些框架。

4、之后，因為對RFT的學習，開始喜歡上了java設計，每天都享受應用java設計，開始沉迷于技術，想著如何去用技術完善自動化測試，開始不注重那些已經搭建好的腳本環境。

5、到了現在，突然回過頭發現，自動化測試最害怕的事情就是一群瘋狂技術者的游戲，其實最基礎的還是踏踏實實的把需求做好，以前所設想的搭建的業務分層現在不是主要問題，以前設想的如何去跟蹤命令行的變更問題，到現在也不是主要問題，其主要問題是一個簡單的技術是否實現了其需求正常的落地了，發現現在真正用起來的東西才是最好的。而更多的技術只是在需求不能得到滿足的情況下去拓展的。

6、當然，工具、編程、框架都是必須的一個過程，關鍵是不要糾結于一些技術細節而不去向前，要看到主要和本質的東西，其工具、編程、框架、流程最終都需要轉換成思想，不管何種方式都信手拈來，成為滿足需求中的一部分。所以接下來，我覺得，自動化測試的學習道路有兩個階段，第一個階段，以技術學習為基礎，不斷進行技術方面的探索。然后，每隔一個階段，跳出技術的視野，去挖掘一定的自動化測試需求，其癡迷的細節不是技術方面，而是自動化測試需求方面，從另一個角度說，也是測試的方式和需求。

7、而在學習java的過程，也接觸過J2SE、J2ME、J2EE，用了swing界面，也進行web設計，進行最基礎的設計、也應用了一些框架，在沒有多少實踐的時候，就開始專研設計模式且一直以數據結構為伴隨，后來在進行整個系統設計中，也學了一點系統建模以及數據庫建模，但總的來說，還是處于模糊狀態，也曾迷戀過，也曾迷茫過，一直處于一種不斷懷疑、不斷痛苦、不斷驚喜的過程。

其實個人想說的是，上兩種方式，并不是去評斷其好壞，不管什么方式，都有其好壞性，大家看看熱鬧就行，但是每種方式、每種領悟都是一段過程的結果，最重要的是我們堅定一個學習的信念不斷學習下去，學習但不要迷戀于技能、要總處于一種簡單的自我懷疑狀態，一切以價值實現為導向即可。

突然想起，以前看的一段話：人早期看山是山、看水是水;中期看山不是山、看水不是水、晚期看山還是山、看水還是水，也許就是說的我們這一段學習過程吧，剛開始因為單純，所以我們能夠簡單應用那些知識實現我們的需要就行，后來學習的深究，各種技術交雜在一起，人難免會有點暈眩，不能把控好自己的方向，后來，才發現不論什么方式，其實最終目的還是為了需求，不管簡單或者復雜，能夠把控好自己，把控好整個流程就好。

所以，自己還在技術的迷亂期，需要的還是不斷的學習，這就是一個過程，所以相信，最終還是會有一個接一個的領悟，但關鍵是堅持啊，堅持啊，不管迷茫、不管懷疑。

第二篇：自動化測試經驗分享

一、測試的困惑

以前我時常反思，測試組的工作多嗎？我的回答是多。測試小組的工作成果的好壞和工作任務的多少成正比嗎？最終的回答卻并非成正比。我們的測試工作成果往往并不理想，甚至是差。那么為什么事倍功半？這問題很難找到清晰的答案。

參與了外部培訓之后，發現了自己在對測試的工作有了新層次的理解。對之前工作成果差的問題思考也有了新的方向。“測試的最高境界是找出所有BUG嗎？不是，測試的最高境界是不需要進行測試。為什么不需要進行測試？是因為所有的問題都已經在軟件各階段中介入的測試工作中給預防解決了。由此引申，測試的定位并不是找出BUG，而是預防BUG。” 這是我培訓報告中的一部分。如果測試的出發點只為是發現BUG，那么測試工作將會如何？辛苦的發現了一個BUG，之后開發針對性的修正了這個BUG，再回重新測試的過程，又會有多少人會重新被卷入，又會有多少BUG因此而產生，又需要花費多少時間，答案可想而知。這就是我們忙又不見成果的主要原因。所以改善這個問題的出發點就是改變對測試工作的認識——測試的目標并不是為了找出BUG，而是預防BUG的出現。

如何理解正確的測試目標是預防BUG的出現。首先可以從軟件測試的階段劃分來看。軟件測試的階段劃分為需求、設計、編碼、測試、驗收。但按此劃分來定位測試是錯誤的。假如在編碼階段完成后測試出的BUG屬于設計問題（這也是我們測試工作中經常遇到的情況），那么我們已經編碼完成的產品就要面臨著傷筋動骨的修改，這樣的修改會帶出多少個新的BUG出現？為這個修改我們又要重復的測試我們的新提交版本多少次？想必都有很深刻及慘痛的答案了。由此可以說明需求設計階段的測試比編碼階段測試重要的多。在需求上出現的BUG就很有可能足以推翻整個產品。那么如果在需求設計階段測試人員就能發現產品設計的BUG，那么就可以避免了因此而衍生的產品BUG，達到預防BUG這種測試理念的目標。

那么又如何能做好以預防BUG為目標的測試工作。“測試工作不只是一種技術，也不僅是一種活動。測試工作的成功也不能取決于測試成果，測試的BUG越多并不能證明測試工作做的好，所以由此引申，測試工作要站在團隊的高度來開展，在團隊中做好測試，而不是在測試小組中做好測試。”這是我培訓報告中的另一部分。要做好以預防BUG為目標的測試工作，首先要盡早的參與到項目中，其次就是需要各部門及小組的大力支持，與業務、項目、代碼人員共同形成團隊，在團隊中影響其他小組提高產品質量，更好的完成以預防產品出現BUG為目標的測試活動。

總結來看，我個人覺得擁有這樣的測試理念可以解開我們的疑惑，帶領我們走出目前的困境。

二、自動化測試迷失

隨著工作、發展、提高等等多方面的需要，我接到了開展自動化測試的研究工作。概念上來說自動化測試是一種測試度量體系。現實點來說，自動化測試可以為我們自動、無誤的運作完成大量且需要重復執行的測試用例。這是多么讓人振奮的概念。甚至可以解開我上文所提到的有關測試工作的困惑。我很興奮的去展開研究目前最流行的自動化測試工具之一QTP。甚至設計出了管理中心的三個重要功能的自動化測試腳本，并且運行無誤在自動化測試討論會上興奮的向大家演示。之后還用工具按鍵精靈設計出了前端的A類測試用于實際的測試。但很讓人沮喪的是最終這些腳本全被遺棄在電腦硬盤的角落，再也沒派上用場。為什么？因為他們維護起來很困難，因為他們編寫它們的時間與實現的價值并沒有超過手工測試。這就是自動化測試嗎？怎么不可行啊，我有點不太相信這種結局，所以我再一次困惑了。

外部培訓的老師這樣告訴我們：“我們并沒有理性的看待自動化測試，自動化測試并不是我們看上去的那樣美。首先自動化測試能直接的節約成本、讓測試人員變輕松的想法是一個誤區。因為原本用于手工測試的時間用來編寫及維護測試腳本了，而完善的自動化測試腳本編寫或維護的時間很可能會超過手工測試的時間。再者自動化測試腳本用例是測試人員所編寫，自動化測試只能是沿著該測試人員的“足跡”前進。所以用自動代測試來發現更多軟件產品問題的想法也是一個誤區。其次并不是所有的測試都能自動化，測試的自動化也不一定是解決問題的最佳手段。”

聽完這些，原本困惑的我又多了份驚訝，一方面驚嘆產述的這些狀況與我之前的自動化測試的試行失敗是相近的。另一方面又猜疑這自動化測試該不會像共產主義社會那般吧！隨著培訓內容的展開，我終于解開了困惑，何為理性的看待自動化測試。

“如同不能指望原始社會擁有了汽車就能進入現代社會一樣，自動化測試工具永遠都不能主導測試實現自動化”（出自國信培訓文檔）。我們錯誤的把自動化測試看成了一種測試工具或測試手段。自動化測試是一種理念，它要發揮它真正的作用就需要這種理念轉變為一種體系——自動化測試體系。

“引入自動化測試的前提是已經建立了合適的自動化測試體系，如果沒有這些，而片面的追求自動化，無異于緣木求魚。自動化測試體系是指能夠適用某種環境的測試工具、過程、人員結構、方法的綜合，運用于整個項目團隊”。回到我之前的對QTP研究失敗的原因，首先我開始就覺得因為研發的設計、編碼實現并沒有考慮到自動化，而導致自動化腳本的編寫非常吃力。比如產品頁面項目的命名不規范，導致自動化測試工具很難捕捉這些頁面對像。其次就是測試腳本的方向迷失，我在研究QTP的時候就發現了這個問題。隨著我一點點的在編寫著腳本，我不斷的發現自己在的測試腳本的編寫方向上出現了迷失。這段腳本我編寫的目標本來是功能測試，但隨著我的補充卻接近于開發級的單元測試。而另一段本屬于功能性測試的腳本，因為功能的重點需要，我又補充了部分腳本導致整個測試腳本測試目標變成了完整關聯性測試。而做為單元測試的腳本卻并沒有在開發的角度上來設計，根本做不到函數、類等代碼級的測試，根本不能達到要求。做為完整性測試的腳本也無法模擬接口功能中幾何倍數級的各種條件輸入對應的輸出測試。而功能測試腳本算是碩果僅存，但隨著開發對產品的代碼大規模調整（這些調整當然不會考慮對已經實現的腳本的影響）而直接“報廢”。如果需要腳本繼續工作，那么就要花時間來修改調整它。這些腳本的結局又再一次可想而知了。

所以首先我們要理性的看待自動化測試，不要片面的去追求它。對不同的項目要開展不同自動化策略。參考如下

（1）評審項目中特定的部分作為應用自動化的候選對像。

（2）從項目中高度冗余的任務或場景重點考慮自動化。

（3）將乏味且人工容易出錯的工作重點考慮自動化。

（4）將回歸測試經常需要“照顧”到的部分重點考慮自動化。

（5）自動化開始時要首先關注開發成熟、理解透徹、相對穩定的且不易變的部分優先考慮自動化

其次，自動化所實現的最大價值目標是可不間斷的、可重復的自動執行對需求、設計、代碼全面覆蓋的大量測試用例從而預防bug的產生的一套質量保障機制。所以自動化測試的重點在于測試自動化作為一個體系，要運用于整個項目團隊。項目組要討論它（策略、時間、成本等）、研發需要參與它（編碼方向、自動化支撐、以及代碼單元測試自動化的計劃和執行等）、測試要引導及推進它（策略、方法、執行、跟進、維護等），各團隊共同形成體系，才能讓自動化測試工具真正的成為一種質量保證的有力武器。

第三篇：創業歷程和感悟

創業歷程和感悟

我在這六年的創業歷程中，正如剛才VCR中所說，一路走來有激情，也有迷茫，在創業的路上我要感謝政府和社會各界對我的大力支持，感謝我的團隊給了我前進的動力，我也曾經抱怨，但我從不抱怨社會，我直報怨我自己的努力不夠，能力不足。因為這個社會給了我們每個創業者太多的機會，太多的資源。

對于創業者來說我是幸運的！我為我的選擇而驕傲，農民對于我們每個人來講都有不同的認識和認知，我和我的父輩都是以種地謀生，我的創業初衷就是要把農民從田間地頭拉回來，從溫飽線上拉回來。因為我能懂的農民的艱辛和不易，通過這幾年的努力我感到我的選擇是對的。我的夢想也會實現。應為我堅信“只要我的夢想足夠大，全世界都會來幫我”

走現代農業道路是解決目前中國農業發展的唯一出路，食用菌工廠化生產是現代高效設施農業的最具有代表的產業，食用菌工廠化生產是按照菇類生長需要設計的封閉式廠房中，在不同地域不同氣候條件下利用溫控、濕控、風控、光控設備創造人工環境；利用機械設備自動化（半自動化）操作，高效率生產；他集約用地、綠色、環保。六年的摸爬滾打鍛造了我堅定的信念，我堅信“打造中國養生菇第一品牌，做中國食用菌行業領跑者的目標”在不久的將來就會實現，因為我得到了來自大家的支持，來自全世界的幫助。

第四篇：軟件測試學習感悟

學習軟件測試的感受及體會

這學期學習了趙培英老師教授的軟件測試這門計算機專業的專業課，我們學院又開設了劉老師的關于這方面的講座，更徹底的使我們加深了對軟件測試的認識。所以我想談談關于軟件測試的體會及學到的一些知識。

作為計算機專業的一門很重要的課程，在計算機領域占據著不可替代的角色，隨著人類社會的進步，各種領域計算機的普及，計算機軟件也越來越多的出現在各個場合，為人們的辦公，生活，學習，休閑等提供了前所未有的方便。軟件測試，其目的是：第一是確認軟件的質量，其一方面是確認軟件做了你所期望的事情（Do the right thing），另一方面是確認軟件以正確的方式來做了這個事件（Do it right）。作為計算機專業的學生，我想以我自己的觀點來闡述一下我對軟件測試的理解。

以前，就是在我沒有認真了解測試行業之前，我也一直認為測試應該是不重要的，甚至認為有必要有專門的測試職業嗎？認為軟件主要是開發人員的事，軟件的成果也是由開發人員決定的，當我學了軟件工程這門課，真正的了解到它的必要性，事實上真的不是那么一回事哦。軟件無處不在，然而，軟件是人編的——所以不完美。

我還查閱了一些資料就是不注意軟件測試的案例：

1、迪士尼的獅子王（1994～1995）軟件在少數系統中能正常工作，但在大眾使用的常見系統中不行。后來證實，迪士尼公司沒有對市場上投入實用的各種pc機型進行正確的測試。

2、英特爾奔騰浮點除法軟件缺陷（1994）英特爾為自己處理軟件缺陷拿出4億美元支付更換壞芯片的費用。導致付出如此昂貴的代價，其主要原因是發現了軟件缺陷沒有正確的處理。

3、美國航天局火星極地登陸（1999）該項目使用前有經過測試，兩個測試小組雙方獨立工作都很好，但從未走在一起。

4、愛國者導彈防御系統（1991）一枚導彈在多哈擊斃28名美國士兵，癥結在于一個軟件缺陷：一個很小的系統時鐘錯誤累積起來就可能拖延14小時，造成跟蹤系統失去準確度。在多哈襲擊戰中系統被拖延100小時。

5、千年蟲（大約1974）估計世界各地更換或升級該系統程序解決原有2000年錯誤的費用已經超過數億美元。

這就是不注重測試的一些嚴重后果，因此我們發現了軟件測試的必要性！在設計有效測試用例之前，測試工程師必需理解軟件測試的基本原則，包括： 1、所有的測試都應追溯到用戶需求。正如我們所知：軟件測試的目標在于揭示錯誤。而最嚴重的錯誤（從用戶角度來看）是那些導致程序無法滿足需求的錯誤。、應該在測試工作真正開始前的較長時間內就進行測試計劃。測試計劃可以在需求模型一完成就開始，詳細的測試用例定義可以在設計模型被確定后立即開始。因此，所有測試應該在任何代碼被產生前就進行計劃和設計。、Pareto 原則應用于軟件測試。簡單地講，Pareto 原則暗示著測試發現的錯誤中的 80 ％很可能起源于程序模塊中的 20 ％。當然，問題在于如何孤立這些有疑點的模塊并進行徹底的測試。、測試應從 “ 小規模 ” 開始，逐步轉向 “ 大規模 ”。最初的測試通常把焦點放在單個程序模塊上，進一步測試的焦點則轉向在集成的模塊簇中尋找錯誤，最后在整個系統中尋找錯誤。

5、為了達到最佳效果，應該由獨立的第三方來構造測試。“ 最佳效果 ” 指最有可能發現錯誤的測試（測試的主要目標），所以創建系統的軟件工程師并不是構造軟件測試的最佳人選。

6、不充分的測試是不負責任的；過分的測試是一種資源的浪費，同樣也是一種不負責任的表現.。

還有就是關于軟件測試的分類：從是否需要執行被測軟件的角度，可分為：

－靜態測試

－動態測試

從測試是否針對系統的內部結構和具體實現算法的角度來看，可分為 ：

－白盒測試

－黑盒測試

關于靜態測試和動態測試：（1）靜態測試是指不實際運行被測軟件，而只是靜態的檢查程序代碼、界面或文檔中可能存在的錯誤的過程。

其中包括代碼測試、界面測試和文檔測試3個方面。對于代碼測試，主要測試代碼是否符合相應的標準和規范。對于界面測試，主要測試軟件的實際界面與需求中的說明是否相符。對于文檔測試，主要測試用戶手冊和需求說明是否符合用戶的實際要求。

（2）動態測試是指實際運行被測程序，輸入相應的測試數據，檢查實際輸出結果和預期結果是否相符的過程。所以，我們判斷一個測試屬于動態還是靜態測試，唯一的標準就是看是否運行程序。

關于黑盒測試和白盒測試 ：（1）黑盒測試

指的是把被測軟件看作是一個黑盒子，我們不去關心盒子里面的結構是什么樣子，只關心軟件的輸入數據和輸出結果。

黑盒測試方法是在程序接口上進行測試，主要是為了發現以下錯誤: ? 是否有不正確或遺漏了的功能?

? 在接口上，輸入能否正確地接受? 能否輸出正確的結果? ? 是否有數據結構錯誤或外部信息(例如數據文件)訪問錯誤? ?性能上是否能夠滿足要求? ? 是否有初始化或終止性錯誤?

用黑盒測試發現程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數據，來檢查程序是否都能產生正確的輸出。但這是不可能的。

黑盒測試的測試用例設計 ?等價劃分法 ?邊界值法 ?錯誤推測法 ?因果圖法（2）白盒測試

指的是把盒子蓋打開，去研究里面的源代碼和程序結構。白盒測試也稱結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規格說明書的規定正常進行，按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能。使用被測單元內部如何工作的信息，允許測試人員對程序內部邏輯結構及有關信息來設計和選擇測試用例，對程序的邏輯路徑進行測試。基于一個應用代碼的內部邏輯知識，測試是基于覆蓋全部代碼、分支、路徑、條件。

白盒測試的主要方法：

?邏輯驅動測試

?基本路徑測試

主要用于軟件驗證。

使用程序設計的控制結構導出測試用例。

邏輯驅動測試：

主要是測試覆蓋率，以程序內在邏輯結構為基礎的測試。包括以下6種類型：

?語句覆蓋

?判斷覆蓋

?條件覆蓋

?判定-條件覆蓋

?條件組合覆蓋

?路徑覆蓋

白盒測試的主要目的

? 保證一個模塊中的所有獨立路徑至少被執行一次；

?對所有的邏輯值均需要測試真、假兩個分支；

?在上下邊界及可操作范圍內運行所有循環； ?檢查內部數據結構以確保其有效性

測試是軟件開發過程的重要組成部分，是用來確認一個程序的品質或性能是否符合開發之前所提出的一些要求。軟件測試的目的，第一是確認軟件的質量，其一方面是確認軟件做了你所期望的事情（Do the right thing），另一方面是確認軟件以正確的方式來做了這個事件（Do it right）；第二是提供信息，比如提供給開發人員或程序經理的反饋信息，為風險評估所準備的信息；第三軟件測試不僅是在測試軟件產品的本身，而且還包括軟件開發的過程。如果一個軟件產品開發完成之后發現了很多問題，這說明此軟件開發過程很可能是有缺陷的。

經過這一門課程的學習和老師的給我們的講座，意識到測試并非是我想像的從客戶角度任意使用軟件產品，從而發現有無質量問題，它有它的理論和實踐體系。軟件測試是一項嚴謹的工作，軟件測試員一個基本的素質是打破砂鍋問到底。喜歡找出那些深藏不露的系統沖突，樂于處理最復雜的問題，外表上熱衷於來回奔忙，追求盡善盡美，為征服系統而額手稱慶。

最后特別感謝老師對我們的課程學習的講授，讓我們了解到計算機更多的知識，也讓我們了解到求職關于計算機方面的崗位，應具備哪些專業知識，謝謝老師！

第五篇：自動化測試平臺學習總結

自動化測試平臺學習總結

學習工作內容

在如下的案件流程中：

1.自動化開發平臺_數字法院3.4_民事_中院_一審案件_走審查走審批_全子表流程

2.自動化開發平臺_數字法院3.4_民事_中院_二審案件_走審查走審批_全子表流程

3.自動化開發平臺_數字法院3.4_民事_中院_公示催告案件_走審查走審批_全子表流程

4.自動化開發平臺_數字法院3.4_民事_中院_申請支付令審查案件_走審查走審批__全子表流程

5.自動化開發平臺_數字法院3.4_民事_中院_民事再審案件_走審查走審批_全子表流程

添加新案件來源的模塊到流程中；

添加新法標_接待新案件模塊到流程中； 添加新結案方式到配置中；

添加完之后將各個案件流程跑通；

準備工作：登錄自動化平臺點擊客戶端下載“頁面元素抓取工具”，運行自動化平臺最好使用“獵豹瀏覽器”，因為IE用于抓取頁面信息，區別于自動化測試平臺登錄，這樣截取的頁面信息比較準確。

（laxt地址:http://172.16.60.244:8088/laxt(登錄用戶:lijh 密碼:123)審判系統:http://172.16.60.244:8484/spxt 自動化平臺地址:http://172.16.31.100/atdp/login.do 登錄用戶:wanghuanren 密碼:wanghuanren）

操作過程

這幾個案件的自動化流程是用于新案件類型的，所以需要添加“新案件來源”“新結案方式”“新法標_接待新案件模塊”到每個案件流程中，使得新案件流程能夠對應新修改的頁面走通流程。

1.在每個案件流程中的模塊都是添加好函數的模塊，在這次操作中，基本不需要修改模塊里的函數；

2.需要加進去新案件來源的參數值，是在“新法標_新案件來源_公用”模塊中。參數值來源于laxt頁面上的下拉框的值；

3.新結案方式的配置是在“配置”中，先數據后控件： 數據配置，先找到“小節”，選擇哪個小節，需要去流程模塊的最后階段“子表通用”的結案項之上的“批量賦值”中看，其參數就是小節，或者帶有結案字樣的模塊，看到是“結案”上有一個為批量賦值那一項中的參數值就是了。

然后就是控件，控件的話需要的頁面抓取工具，抓取結案方式的那個html id到參數值。

遇到的問題：在實際操作中，批量賦值中沒有小節名，現在需要在配置中在增加一個小節。在“配置”中點擊批量獲取，調用抓取工具，在NP的spxt的結案頁面上選擇一個框就能夠獲取到一個小節的頁面信息，注意將結案頁面上必填項都填上，抓取后的小節信息中關于日期的都修改為{今天}，就完成了一個結案信息的小節。

在執行時如果有連接服務器一直處于連接狀態的話，就直接在服務器：172.16.31.105上進行執行。（從101到120都是可用的服務器：Microadministrator/ceshi1）

步驟：將要執行的流程名字放在服務器的：D:自動化開發平臺自動化開發平臺配置

中的測試控制.ini下的第三行：當前流程=?的后面

點擊開始的自動化平臺遠程助手，【調試模式】，再運行QTP。就可以執行自動化了。

遇到的問題：在執行民事二審自動化流程時，點擊二審后跳轉的頁面是“刑事二審”的，這是由于重名導致的自動跳轉問題。修改的時候，在流程中加入一個判重模塊用于判重，修改參數值，排去無效模塊，進行再次運行，就將正確跳轉到民事二審頁面，見下圖：