第一篇：自動化測試學(xué)習(xí)歷程感悟--（定稿）

軟件設(shè)計與自動化測試學(xué)習(xí)歷程感悟

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

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

軟件設(shè)計學(xué)習(xí)過程：

某位人士23歲畢業(yè)，對Java的優(yōu)雅設(shè)計情有獨鐘，其Java技術(shù)之旅開始了。

1、最開始三個月，開始接觸Java，比如接口、繼承、封裝等，買了本《Think in Java》天天啃，并且同時做項目實踐。猛學(xué)了三個月后，對面向?qū)ο缶幊蘋OP熟悉了，原來腳本式思維和對象思維確實有差別。

2、三個月后，開始啃《Core Java》，《Effective Java》，對Java有了更深入的了解，回調(diào)的概念也有了，逐漸接觸到更高的層次，面向?qū)ο笤O(shè)計OOD，這時又看了一本書《Head First Design Patterns》，感覺設(shè)計模式特別有趣。再寫代碼，已經(jīng)不是面向?qū)崿F(xiàn)編程，而是面向設(shè)計編程。感覺寫Java代碼太簡單了。逐漸了解了WebWork等Web框架的使用。

3、六個月過去了，Java癮越來越大，逐漸開始往更高層次攀登，這時，又看到兩本書《企業(yè)應(yīng)用架構(gòu)模式》、《UML和模式應(yīng)用：面向?qū)ο蠓治雠c設(shè)計導(dǎo)論》，已經(jīng)開始從設(shè)計往面向?qū)ο蠓治鯫OA、架構(gòu)攀登了。Hibernate已經(jīng)比較熟悉了，了解Hibernate背后的持久化技術(shù)、Spring背后的IoC容器、組裝技術(shù)原理。

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

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

自動化測試學(xué)習(xí)過程：

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

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

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

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

4、之后，因為對RFT的學(xué)習(xí)，開始喜歡上了java設(shè)計，每天都享受應(yīng)用java設(shè)計，開始沉迷于技術(shù)，想著如何去用技術(shù)完善自動化測試，開始不注重那些已經(jīng)搭建好的腳本環(huán)境。

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

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

7、而在學(xué)習(xí)java的過程，也接觸過J2SE、J2ME、J2EE，用了swing界面，也進(jìn)行web設(shè)計，進(jìn)行最基礎(chǔ)的設(shè)計、也應(yīng)用了一些框架，在沒有多少實踐的時候，就開始專研設(shè)計模式且一直以數(shù)據(jù)結(jié)構(gòu)為伴隨，后來在進(jìn)行整個系統(tǒng)設(shè)計中，也學(xué)了一點系統(tǒng)建模以及數(shù)據(jù)庫建模，但總的來說，還是處于模糊狀態(tài)，也曾迷戀過，也曾迷茫過，一直處于一種不斷懷疑、不斷痛苦、不斷驚喜的過程。

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

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

所以，自己還在技術(shù)的迷亂期，需要的還是不斷的學(xué)習(xí)，這就是一個過程，所以相信，最終還是會有一個接一個的領(lǐng)悟，但關(guān)鍵是堅持啊，堅持啊，不管迷茫、不管懷疑。

第二篇：自動化測試經(jīng)驗分享

一、測試的困惑

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

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

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

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

總結(jié)來看，我個人覺得擁有這樣的測試?yán)砟羁梢越忾_我們的疑惑，帶領(lǐng)我們走出目前的困境。

二、自動化測試迷失

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

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

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

“如同不能指望原始社會擁有了汽車就能進(jìn)入現(xiàn)代社會一樣，自動化測試工具永遠(yuǎn)都不能主導(dǎo)測試實現(xiàn)自動化”（出自國信培訓(xùn)文檔）。我們錯誤的把自動化測試看成了一種測試工具或測試手段。自動化測試是一種理念，它要發(fā)揮它真正的作用就需要這種理念轉(zhuǎn)變?yōu)橐环N體系——自動化測試體系。

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

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

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

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

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

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

（5）自動化開始時要首先關(guān)注開發(fā)成熟、理解透徹、相對穩(wěn)定的且不易變的部分優(yōu)先考慮自動化

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

第三篇：創(chuàng)業(yè)歷程和感悟

創(chuàng)業(yè)歷程和感悟

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

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

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

第四篇：軟件測試學(xué)習(xí)感悟

學(xué)習(xí)軟件測試的感受及體會

這學(xué)期學(xué)習(xí)了趙培英老師教授的軟件測試這門計算機(jī)專業(yè)的專業(yè)課，我們學(xué)院又開設(shè)了劉老師的關(guān)于這方面的講座，更徹底的使我們加深了對軟件測試的認(rèn)識。所以我想談?wù)勱P(guān)于軟件測試的體會及學(xué)到的一些知識。

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

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

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

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

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

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

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

5、千年蟲（大約1974）估計世界各地更換或升級該系統(tǒng)程序解決原有2000年錯誤的費(fèi)用已經(jīng)超過數(shù)億美元。

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

5、為了達(dá)到最佳效果，應(yīng)該由獨立的第三方來構(gòu)造測試?！?最佳效果 ” 指最有可能發(fā)現(xiàn)錯誤的測試（測試的主要目標(biāo)），所以創(chuàng)建系統(tǒng)的軟件工程師并不是構(gòu)造軟件測試的最佳人選。

6、不充分的測試是不負(fù)責(zé)任的；過分的測試是一種資源的浪費(fèi)，同樣也是一種不負(fù)責(zé)任的表現(xiàn).。

還有就是關(guān)于軟件測試的分類：從是否需要執(zhí)行被測軟件的角度，可分為：

－靜態(tài)測試

－動態(tài)測試

從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和具體實現(xiàn)算法的角度來看，可分為 ：

－白盒測試

－黑盒測試

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

其中包括代碼測試、界面測試和文檔測試3個方面。對于代碼測試，主要測試代碼是否符合相應(yīng)的標(biāo)準(zhǔn)和規(guī)范。對于界面測試，主要測試軟件的實際界面與需求中的說明是否相符。對于文檔測試，主要測試用戶手冊和需求說明是否符合用戶的實際要求。

（2）動態(tài)測試是指實際運(yùn)行被測程序，輸入相應(yīng)的測試數(shù)據(jù)，檢查實際輸出結(jié)果和預(yù)期結(jié)果是否相符的過程。所以，我們判斷一個測試屬于動態(tài)還是靜態(tài)測試，唯一的標(biāo)準(zhǔn)就是看是否運(yùn)行程序。

關(guān)于黑盒測試和白盒測試 ：（1）黑盒測試

指的是把被測軟件看作是一個黑盒子，我們不去關(guān)心盒子里面的結(jié)構(gòu)是什么樣子，只關(guān)心軟件的輸入數(shù)據(jù)和輸出結(jié)果。

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

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

用黑盒測試發(fā)現(xiàn)程序中的錯誤，必須在所有可能的輸入條件和輸出條件中確定測試數(shù)據(jù)，來檢查程序是否都能產(chǎn)生正確的輸出。但這是不可能的。

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

指的是把盒子蓋打開，去研究里面的源代碼和程序結(jié)構(gòu)。白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試，它是知道產(chǎn)品內(nèi)部工作過程，可通過測試來檢測產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進(jìn)行，按照程序內(nèi)部的結(jié)構(gòu)測試程序，檢驗程序中的每條通路是否都有能按預(yù)定要求正確工作，而不顧它的功能。使用被測單元內(nèi)部如何工作的信息，允許測試人員對程序內(nèi)部邏輯結(jié)構(gòu)及有關(guān)信息來設(shè)計和選擇測試用例，對程序的邏輯路徑進(jìn)行測試?；谝粋€應(yīng)用代碼的內(nèi)部邏輯知識，測試是基于覆蓋全部代碼、分支、路徑、條件。

白盒測試的主要方法：

?邏輯驅(qū)動測試

?基本路徑測試

主要用于軟件驗證。

使用程序設(shè)計的控制結(jié)構(gòu)導(dǎo)出測試用例。

邏輯驅(qū)動測試：

主要是測試覆蓋率，以程序內(nèi)在邏輯結(jié)構(gòu)為基礎(chǔ)的測試。包括以下6種類型：

?語句覆蓋

?判斷覆蓋

?條件覆蓋

?判定-條件覆蓋

?條件組合覆蓋

?路徑覆蓋

白盒測試的主要目的

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

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

?在上下邊界及可操作范圍內(nèi)運(yùn)行所有循環(huán)； ?檢查內(nèi)部數(shù)據(jù)結(jié)構(gòu)以確保其有效性

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

經(jīng)過這一門課程的學(xué)習(xí)和老師的給我們的講座，意識到測試并非是我想像的從客戶角度任意使用軟件產(chǎn)品，從而發(fā)現(xiàn)有無質(zhì)量問題，它有它的理論和實踐體系。軟件測試是一項嚴(yán)謹(jǐn)?shù)墓ぷ鳎浖y試員一個基本的素質(zhì)是打破砂鍋問到底。喜歡找出那些深藏不露的系統(tǒng)沖突，樂于處理最復(fù)雜的問題，外表上熱衷於來回奔忙，追求盡善盡美，為征服系統(tǒng)而額手稱慶。

最后特別感謝老師對我們的課程學(xué)習(xí)的講授，讓我們了解到計算機(jī)更多的知識，也讓我們了解到求職關(guān)于計算機(jī)方面的崗位，應(yīng)具備哪些專業(yè)知識，謝謝老師！

第五篇：自動化測試平臺學(xué)習(xí)總結(jié)

自動化測試平臺學(xué)習(xí)總結(jié)

學(xué)習(xí)工作內(nèi)容

在如下的案件流程中：

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

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

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

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

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

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

添加新法標(biāo)_接待新案件模塊到流程中； 添加新結(jié)案方式到配置中；

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

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

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

操作過程

這幾個案件的自動化流程是用于新案件類型的，所以需要添加“新案件來源”“新結(jié)案方式”“新法標(biāo)_接待新案件模塊”到每個案件流程中，使得新案件流程能夠?qū)?yīng)新修改的頁面走通流程。

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

2.需要加進(jìn)去新案件來源的參數(shù)值，是在“新法標(biāo)_新案件來源_公用”模塊中。參數(shù)值來源于laxt頁面上的下拉框的值；

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

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

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

在執(zhí)行時如果有連接服務(wù)器一直處于連接狀態(tài)的話，就直接在服務(wù)器：172.16.31.105上進(jìn)行執(zhí)行。（從101到120都是可用的服務(wù)器：Microadministrator/ceshi1）

步驟：將要執(zhí)行的流程名字放在服務(wù)器的：D:自動化開發(fā)平臺自動化開發(fā)平臺配置

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

點擊開始的自動化平臺遠(yuǎn)程助手，【調(diào)試模式】，再運(yùn)行QTP。就可以執(zhí)行自動化了。

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