qileilove

　　1、對于新產品和維護版的老產品設計的用例應該注意些什么呢？

　　專家分析：新項目和維護項目從本質上看沒有區別，維護產品，無非就是新增功能和缺陷修復兩大類，和新項目相比，唯一需要注意的就是新增\修復的功能是否對其他部分有影響，這里就涉及到一個回歸策略的問題——老功能要測多少。一般來說，需要和開發討論確定受影響的范圍，然后制定測試范圍。當然最理想的情況就是整個系統全測，因為一旦系統復雜了，沒有哪個開發能說清楚影響范圍。

　　專家建議：“新產品”在了解需求的情況下，先設計測試用例，再測試，避免發生遺漏。“老產品”維護，若改變了需求，依然先設計（修改）測試用例，再測試，避免發生遺漏；若項目緊急可先測試，再修改測試用例。

　　2、做手機應用，流程不像是WEB的那樣清楚，感覺應用除了主功能還有很多零碎的小功能。設計用例時容易遺漏。需要怎么樣做更好呢。

　　專家分析：手機應用端測試是最適合應用場景分析方法的，場景設計需要經驗的累積，不是簡單學習知識就行的，建議使用思維導圖，做個有心人，把平時測試的經驗都記錄下來，形成最適合的場景設計方法。

　　專家建議：手機測試考慮有各種手機的牌子、型號（還有現在的太陽能手機情況下）、停機、沒電、內存容量等等。

　　3、怎樣用簡短的測試用例達到高覆蓋率的測試？并且寫用例時候采用非常清楚的描述好還是采用測試點描述讓測試執行人自行發散測試思維？

　　專家分析：我們一般不做這樣的考慮，用例需要有合適的顆粒度，并不是說一條用例覆蓋的越多越好，如果一條用例如果顆粒度很大，覆蓋了很多測試點，當前看起來很好，但過幾天你還看得懂這條用例嗎？而往往測試用例數量往往大大超過測試數量。

　　用例存在的目的，一個是溝通交流，讓其他人能看懂你的測試思路，幫你評審，另一方面也是經驗的累積，最終形成用例庫，所以一定要體現用例設計思路。自行發散測試思維是要不得的，這樣幾年做下來，一點積累都沒有，久而久之在測試界會被淘汰。

　　4、如何能把黑盒測試做精，做好，對于一些對測試不是特別重視的公司又如何開展較為完善的測試工作？然后黑盒測試必須要向白盒與性能走嗎？

　　專家分析：可以向公司商議有關測試的重要性。若公司不同意，也盡量采用專業些的測試方法（工具）及bug管理等，便于引起公司的重視和認可。測試人員也要適應這種情況。首先就是了解公司對質量的訴求，比如現階段對性能沒什么要求，那就集中于將功能測試做好，同時要考慮提升測試的效率，比如自動化測試。在需求確認環節，盡量參與，比如針對每個需求寫驗收標準，然后再和開發一起進行需求討論，把測試工作融入到整個開發過程中，那么測試的重要性就會和開發并列到一起了。

　　黑盒測試很難精通，比白盒難得多，白盒測試是 測試中最簡單最沒有技術難度的一環。哪個價值大，應該清楚了吧。如果沒有一定的代碼基礎，不建議你去做白盒。測試最有發展的還是黑盒測試。黑盒測試需要學 習的東西很多，比如需求環節的測試需求分析，場景分析，設計階段的用例設計方法，實現階段的測試自動化，DFX測試技術等等。性能測試是很重要的發展通道，其實性能測試也屬于黑盒，性能分析和優化才有點偏白盒。

　　在國內，功能占用的比例確實很高，但現在大部分公司的入職要求是要會點性能工具或者自動化工具的。

　　5、針對做嵌入式開發的公司，作為測試人員，主要需要學習哪些內容？數據庫，自動化測試是否能用到？

　　專家分析：嵌 入式來說，數據庫可能不太會涉及，不過自動化依然很重要。嵌入式軟件可以看做一個黑盒，測試最大的難度在于搭建測試環境，因為你要為這個黑盒搭建好輸入、 輸出環境。一般來說，必須掌握最底層的一些知識，像單片機原理啊，認識芯片那些引腳啊，數轉模啊，還有一些基本的匯編。從我了解的嵌入式軟件測試來看，它是最容易實現自動化測試的。

　　6、黑盒測試可以做多久，應該怎樣規劃黑盒測試的職業生涯？

　　專家分析：黑盒測試來說其實研究透了，你也非常厲害，像自動化測試、性能測試它們有時候還是需要有些功能測試的功底的。

　　7、怎樣寫好黑盒測試用例，在不出現冗余的情況下達到覆蓋面廣？

　　專家分析：為何會有等價類劃分、邊界值、判定表等等工程方法？就是為了幫助大家寫好用例的。

　　出現冗余舉個最簡單的例子：0-100之間取值（整數），可取0、55、100；若再取-1、1、99、101就是冗余。

　　SQL Server數據庫用視圖來處理復雜的數據查詢關系是本文我們主要要介紹的內容，該內容是這樣想到的：在輔助教務系統那塊的時候，我做的一個頁面是對單個老師和整個學院老師的工作量查詢，這個操作設計到了三個本數據庫中的表和一個不同數據庫中的一個教師信息表，如果用普通的SQL語句是非常難實現的，由于我剛開始做的視頻播放系統，數據庫的表相對比較少，沒有涉及到這么復雜的處理關系，剛開始感覺很難。

　　后來想到用視圖可以解決多個表的復雜關系，但是另外一張表是不同數據庫的，是否依然能進行操作，經過測試之 后，居然可以將不同數據庫中的兩張表進行建立視圖關系，從而視圖就是一個虛擬的表，我們將需要查詢的不同數據庫中的表或者相同數據庫中的表，放到一起，然 后選擇需要的字段，重新建立一個新的虛表，然后這個視圖就可以作為一個新的表，進行操作。這樣就為我們提供了很多方便。

　　視圖是一個續表，是從一個或者多個表或視圖倒出來的表，其結構和數據時建立在對表的查詢基礎上的。

　　視圖的優點有：

　　1、視圖可以讓用戶我們選擇某些特定的數據和或者特定的任務，而那些不需要的或者無用的數據可以不再視圖中顯示。

　　2、視圖大大的簡化了對數據庫的操作，可以通過視圖操作進行對表的操作。

　　3、視圖可以讓不同的用戶以不同的方式看到不同或者相同的數據集，相當方便

　　4、在某些情況下，由于表中數據量太大，因此在表的設計時常將表進行水平或者垂直分割，但是表的結構變化對應用程序的產生不良的影響，而使用視圖可以重新組織數據，從而使外模式保持不變，原有的應用程序可以通過視圖來重載數據。

　　5、視圖提供了一個簡單而有效的安全機制。

　　視圖的缺點：

　　如果該視圖處理的數據量非常大，那么就給sql數據庫帶來了很多壓力，執行速度相對來說比較慢，不如存儲過程，所以如果可以用存儲過程實現的，優先用存儲過程創建視圖主要創建方式：

　　1、用sql server管理平臺創建視圖

　　2、用Transact-sql語句中的create view命令來創建視圖

　　3、利用sql sever管理平臺的視圖模板來創建視圖

　　創建視圖的時候要注意：

　　1、只能在當前數據庫中創建視圖，在視圖中最多只能引用1024例，視圖中記錄數目先知只有其基表中的記錄數決定。

　　2、如果視圖引用的基表或者視圖被刪除，該視圖不能再被使用，知道創建新的基表或者視圖

　　3、如果視圖中某一列是函數、數學表達式、常量或者來自多個表中的列名相同，則必須為列定義名稱。

　　4、不能再視圖上創建索引，不能再規則、默認、觸發器中引用視圖

　　5、當通過視圖查詢數據時，sql server要檢查以確保語句中涉及的所有數據庫對象存在，每個數據庫對象在語句的上下文中有效，而且數據修改語句不能違反數據完整性規則。

　　6、視圖的名稱必須遵循標示符的規則，且對每個用戶必須是唯一的，此外，該名稱不得與該用戶有任何相同名稱的表 這是建立的視圖，其中TeacherInfo是從另外一個數據庫中添加進來的。

　　以下是通過視圖查詢出來的數據表“select * from QueryWorkInfoByFaculty”

　　關于SQL Server數據庫用視圖來處理復雜的數據查詢關系的相關知識就介紹到這里了，希望本次的介紹能夠對您有所收獲！

　　作為測試人員，編寫測試用例是我們的核心，他最重要的作用就是讓我們跟著測試用例測試，不會遺忘一個測試的功能點。在現實的設計用例環節來說，做到很好的測試用例對我個人來說是很難的。尤其是場景測試用例設計。

　　本文不以概念和一些教科書似的例子來講解場景測試和業務測試的相互關系。以一個輕松交流的方式來總結場景測試的流程。當今很多產品不再是單一的互聯網或者是獨立產品作為測試的對象，往往跟多個模塊進行配合測試。即使有嚴格的規格說明書，事件流的測試也是不能忽視。

　　為什么要用場景測試用例：

　　因為用等價，邊界等設計方法對于一些流程較多或者對于沒有需求規格書來說，是非常難做到的，尤其是邏輯性比較強的嵌入式產品。他的邊界值往往都要到性能測試的性能kpi和壓力2個測試點才能夠觀察到。

　　測試階段中什么時候用場景測試：

　　在產品開發階段和測試階段同步進行時（說正規點是敏捷，說不正規點是趕工，個人意見），還有單元測試或者單個模塊測試完畢后。

　　場景測試用例設計的困難點：

　 　1、需求不足和邏輯關系較多的時候。這里需要展開來講。很多時候我是不得不用到場景測試法。因為需求規格書不足和該產品從等價，邊界等測試用例方法是設 計不出有效的測試用例。流程和涉及產品較多，對比網上的場景用例實例，現實中使用場景用例的流程往往復雜很多，單單了解流程都很吃力。

　　2、設計事件流的過程中很容易設計出沉余的測試用例，因為就算每個流的條件不一樣，但是你實際測試過程中使用的手法和觀察點確是一樣的。難就難在這用正交法是很難瘦身這類的用例，只能通過測試來慢慢優化該用例，流程關注點越多，重復的幾率就更多。

　　為什么我既愛又恨場景測試法：

　　對于我來說，場景測試法既是我用最多的測試法也是我最不想用的設計方法。作為測試人員在長期的測試過程中，你會慢慢變得很懂內部原理，尤其是你轉化為自動化測試后，甚至做到一個確定鍵報錯都會聯想到這是數據庫和web的存儲過程入參不一致導致的境界。好處是你可以測試出很多底層的東西，壞處是經過你測試的產品，功能很多，但是卻不好用。因為我忽略了我是一個用戶的角度去測試，而是一個開發測試開發的東西。

　 　場景測試讓我找到了平衡點，我知道了這東西的流程，可以在了解中提出改進建議，對產品有了很深的了解。讓我從自動化測試中拉回來一點點。為什么我會不想 用的此種設計方法。他很考你的經驗和總結能力，同上面所說你缺乏需求規格書的時候，你就是用想來寫用例。所以當別人表揚我測試不少用例以外的關鍵Bug的時候，我是高興我的有好的測試經驗還是我寫出了差的測試用例。

　 　對于做測試有一定年頭的人，項目組對你的要求不再是了解普通的測試流程，還有很多里面的原理，設計，方案，進度。場景測試設計的時候你就要把關，我設計 的是多深入的測試用例？能否根據你項目的期望來測試出關鍵的bug。好比我測試的是web的流程，但是項目關注的后臺的處理流程。實際情況中，你設計場景 用例的時候不再是培訓那套理論和”真理”。

　　通過以上可以看出，為什么有些業務測試工程師比自動化，性能，甚至開發的地位都要高。例如銀行，無線通信業務中，手工的測試手法非常多，同樣的產品不同的人測出的效果不一樣。體現出現的就是業務流程的能力，部分情況下就是場景測試設計的功力。

　　總結，作為一個測試人員的我的目標測試周期，第一了解產品的應用架構，第二了解產品使用的業務流程，第三總結業務流，第四根據業務流跟各個開發組了解設計流程，第五寫出按需求的自動化測試的架構，第六寫出場景測試用例，第七進行系統測試，第八進行細節的自動化用例編寫，第九進行自動化測試，第十出測試報告和測試周期的自我”性能調優”總結文檔。

　　這篇就是我的場景測試總結文檔。

　　不同于“顛覆式”創新，作者提出的創新“漸進式”是依靠精準定位、從小做起、局部發展、快速迭代、持續漸進等理念，推動互聯網產品的演化。

　　我在IT行業從業十余年，只待過兩家公司：金山和騰訊。在談創新之前，我想先從我所觀察到的兩家公司的節奏談起。

　　大家知道，在十年前，傳統IT企業如金山或金蝶，軟件開發常 以年為單位。年初由產品經理寫好一份大需求，各方評估完后啟動項目。設計、開發各做幾個月后進行提測，之后緩慢迭代。雖然現在聽來，一年的時間很長，但到 最后項目Deadline時，所有人仍喊時間不夠用。最終項目經理卡死時間、編版本、壓盤，所有殘念在壓盤的一瞬間煙消云散。這樣，一個歷經了一年開發出 的、被我們稱為軟件的東西，夾雜著未竟的feature、待解決的Bug、需調整的UI，被壓入盤中大規模生產，包裝起來送到消費者手里。

　　而互聯網企業的生產，則是完全不同的一番景象。2003年進入騰訊之初，我就被這家公司的敏捷震驚了—一個月一個版本！我只有1～2周的時間做界面設計，并且大部分進度是與開發重合的。產品經理（如果有的話）根據用戶反饋和競爭對手的情況做需求，界面設計和開發同步進行，測試時間更是若有若無。就這樣，一個歷經了一個月開發出的，被我們稱為互聯網軟件的東西，夾雜著更多未竟的feature、待解決的Bug、需調整的UI，被打包放在服務器上，在Web上提供鏈接，開始供用戶下載。

　　兩家公司的開發過程都包含程度不一的慌亂，最大的差別是節奏。相較之下，一個月一個版本，更能抓住用戶需求的變化，有更大機會在不斷開火中瞄準，也有更多機會嘗試創新。

　　創新是企業保持競爭力的保證，近年來，互聯網人都講“微創新”，這個詞雖然道出了創新的“形”，但未道出“勢”。我更喜歡用“漸進式創新”來描述我們在產品上做的循序漸進式的創新改良。

　 　請允許我打一個比方：上帝按照他自己的樣子造出了亞當，如果你愿意說他山寨的話，這個說法也可行，但特別的是，他還根據亞當的需要造出了女人。從男人到 女人，還是有那么一些漸進式的意思。我們轉換一個頻道到達爾文這里：在廣袤的非洲大草原，春天到了，動物們又到了交配的季節……這時，一只猿猴忙碌之余， 興之所至忽然站立起來行走。與其他猿猴相比，當時的它也許并沒有顯示出劃時代的高明，但它做了創新，而這一創新，可以說是以后劃時代變革的開始。請大家主 意，這只猿猴并沒有突然從猿猴1.0升級到猿猴2.0，而是猿猴1.01，因為它只是漸進式地做了變革—站立起來，并未具備可以思考云計算的大腦和足以操作鍵盤的靈活雙手。

　　還有一個案例：iPhone。在這個時代談創新，始終繞不開蘋果。 iPhone是如何出現的？看iPod的演化史，你會發現每一個iPod版本的進化：屏幕更大了、機身更纖薄了、性能和容量變化了、可以聲控了……這些漸 進式優化一步步發生，終于有一天，當秘密研發iPad的工程師把多點觸摸技術也準備好后，喬布斯一拍大腿說：“為什么不做個手機呢？！”【注：關于iPad在蘋果內部研發早于iPhone的信息，詳見喬布斯訪談】。

　　鑒于此，我想提出一個觀點：其實沒有所謂一步到位的劃時代的創新，任何一個創新都是建立在已經存在的事物的基礎上漸進發生的。

　　下面，我將以騰訊的案例闡述我的觀點。騰訊發布了數以百計個版本的QQ，這其中當然有大的重構和功能的革新，但更多的是遍布在小版本中的漸進式創新。

用戶頭像下的Tips

　　關鍵路徑上的創新影響力巨大

　　如果你碰巧是QQ的付費用戶，購買了綠鉆，那么你頭像的Tip底端會顯示一個綠鉆圖標，作為已經購買該項服務的印記。在最初的版本里，我們只做了已購買服務的圖標標記，直到某個版本的需求討論會上，業務部門提出：如何增加業務的開通量？

截圖功能

　　如何增加業務的開通量？

　 　提升業務開通量的方法有很多，比如打廣告。當時設計的思路是：有些增值服務用戶甚至都不知道，打廣告雖然能增加業務曝光度，但從用戶看到廣告到開通業 務，路徑很長，而Tip本身確實是一個很好的接觸點。于是我們靈光一閃，把未開通的業務圖標，以灰色未開通的形式展示在Tip上，而用戶鼠標移過灰色圖標 時，就顯示對該項業務的說明，點擊則會進入這個業務的詳細介紹和開通頁面。這個小小的改進對QQ增值業務的開通拉動是非常巨大的，至今我們仍無法估算這個 小改進帶來的直接經濟價值。

　　創新來自對使用場景的細微觀察

　　在即時通信軟件中，人和人溝通最初的方式只有文字。雖然文字傳情更有意境，但多媒體、全方位互聯網溝通時代早已浩浩蕩蕩地到來了。在視頻、音頻多方位溝通的背景下，截圖功能是這個歷史進程中的一朵奇葩。

　　兩個人在現實中溝通，往往以眼見之實物輔助，而在網絡上溝通，往往以眼見屏幕中之物輔助，但首先要能截取并給對方看到。在UI設計師和程序員的 合作聯調過程中，這樣的使用場景太常見了，既然QQ已具備傳送圖片的功能，為什么不做個截圖功能，作為圖片來源直接發送給好友呢？

　　第一個版本的截圖只是簡單的截屏、發送給好友。在之后的版本中，我們漸進的在截圖功能中加入了標記、文字說明等功能。現在，截圖功能這個貌似和即時通信軟件不相關的功能，已成了QQ的重要特性之一，甚至是某些用戶堅持登錄QQ的唯一動力。

　　大創新可拆解成小創新逐步實現

　　做產品的人一定很熟悉一句話：資源永遠是不夠用的。特別是在互聯網行業快速迭代的產品節奏下，任何一個功能特性的開發資源都很有限。在有限的資 源下，想說服所有人放下其他事情安心實現你的創新大計劃幾乎是不可能的。這么多年的斗爭經驗積累下來，在騰訊內部形成了一句話叫“小步快跑”，這句話本用 以形容功能迭代，但在創新上其實一樣適用。

　　如果你有一個大的創新計劃，需要動員巨大的資源來實現，那么不妨先把它拆解，逐步制作、逐步發布。發布后依據用戶反應進行下一步計劃：如果反應 不好，幸好這時的資源投入還不多，那就偃旗息鼓，還來得及反悔；但如果反應是正向的，提供給你資源的人也會有信心，這時就可以繼續推進，逐步地把創新點的 最終面貌呈現出來。

　　保持創新的方向感，做局部創新

　　中國互聯網正處于產品過剩時期。任何一個產品形態在市場上都有上十款免費產品可供選擇。雖然份額各有大小，但大家往往都很默契的遵循該形態的一 些基本標準。比如：即時通信、郵箱、微博、新聞門戶，基本都有已成型的產品形態，用戶也習慣了這些產品形態。在這種情況下，全面創新是一種既費力又不符合 用戶預期的做法。

　　QQ“主面板”+“聊天窗口”的設計模式，經過十幾年的沉淀和發展已經定形，已成為互聯網即時通信軟件的標準。后來者很少在這個聊天基礎體驗上做顛覆，但各廠家結合自身業務和資源優勢對產品做出創新是常見的。

　　我們對QQ的基礎體驗也做過顛覆性的創新嘗試，比如主界面摒棄窄面板形式，采用更大的、可容納更多內容的大界面，但通過用戶研究發現市場接受度非常不樂觀。

　　但當我們聚焦到局部創新時，我們發現即使是最基礎的“信息輸入”體驗，可做漸進式創新的點就非常多。我們聚焦在“信息輸入”這個小局部，結合用戶輸入困難，設計和開發出了手寫輸入、語音輸入等功能，很受用戶歡迎。

　　持續漸進創新，為后來者設立門檻

　　產品體驗被模仿的門檻較低。大家都不差錢、不差技術時，一個好的體驗創新點，總是很快被競爭對手模仿。但模仿一個點容易，模仿整個思路很難。清晰自己產品的方向，按照思路有節奏的不斷創新，始終領跑對手1～2個月，是為后來者設立的最有效的門檻。

手寫輸入，語音輸入

　　“找朋友”是微信最核心的功能點之一，每個版本創新出新的“找朋友”、“加朋友”的方式，讓微信在和競爭對手的賽跑中始終領跑。

　　在騰訊，漸進式創新的案例數不勝數，維持快速迭代的漸進式創新，是騰訊產品持續成功的重要因素之一。

　　人類的進步是在不斷螺旋重復中上升的。在某些時間點，當漸進式創新進行到一定階段，會有人進行整合和再創造，量變引發質變，但憑空出現一個劃時代創新產品是不可能的。如果你發現了這樣的產品，那么很有可能是你對它之前的歷史并不了解。

大界面QQ的概念圖

　　從現在起，凝視你手上的產品，承認它的不完美，并發現可進行漸進式創新的方向吧，腳踏實地進行改進，你的產品會在互聯網的進化史上，擁有屬于自己的位置。

　　做為一名測試人員，我們也許會問我們自己很多問題：

　　● 我們可以立即執行的最好的測試是什么？

　　● 我將要使用的測試方法是什么？

　　● 這是一個Bug嗎？

　　● 我已經測試完成了嗎？

　　但是我們之中會有多少人提出以下的這些問題呢？

　　● 這個組件需要一直被測試到嗎？

　　● 需要由我來測試它嗎？

　　● 如果它不工作，誰會去在意它呢？

　 　在我看來，我們提出的問題中和以上三個問題類似的還遠遠不夠。可能這是因為我們已經被告知要測試一切東西。甚至我們的一部分人會在其質量團隊中有一個流 程，要求某個人把每一個組件都貼上“已測試”的標簽。我們對待測試就像一個常規的工廠程序，我們甚至有時候引以自豪的說…

　　“我是測試工程師。因此，所有的東西都需要被測試…由我來做…即使非測試人員已經測試過了…即使我已經知道它將會通過測試…即使需要一個程序員告訴我怎么去測試…我必須測試它，沒有例外！”

　　這類想法可能會讓測試人員有一個壞名聲。由于欠缺思考的過程導致它強調了測試的重要性，而不是給一些人提供最有價值信息的服務。

　　James Bach 帶著以下的測試觀點出現：

　　基本的觀點：“如果它存在，我就要去測試它”

　　正如前面內容和我經常發布的文章中，我不同意這個觀點。盡管如此，我完全同意James 在2006年8月7日，他在博客發布的完整版本中關于這部分的介紹：

　　“如果它存在，我就要去測試它（唯一的例外是我有更重要的事情要做）”

　 　第二句話是可以有很多的理解方式！為什么呢？因為我們經常會有更重要的事情去做，通常是另外的測試工作！不幸的是，重要性往往不是區分的很明顯。所以與 其衡量重要性，我更喜歡提出上面的三個問題，去尋找那些可能不值得浪費我的時間去測試的東西。下面八個例子是我討論的內容：

　　1、不會在產品中出現的組件- 我的團隊中在每次迭代中都有這些內容。例如增強功能中的錯誤記錄表或者跟蹤生產活動中的審查報告。在敏捷開發的團隊中這些被歸入開發者用戶故事（Developer User Stories）。這些內容不會隨便的在產品中出現并且由于其本質不會直接影響到用戶。

　　2、關鍵產品問題的補丁不會很糟糕– 一天下午客戶給我們的技術支持打電話，由于我們的產品的一個阻塞性質的bug導致他們處于錯過一個關鍵最后期限（DeadLine）的邊緣。我們只有一個 小時交付修復的產品。程序員很快的修復了問題，由于當前的產品是無效的，所以對修復之后進一步的產品存在的風險來說這是微不足道的。想要當英雄嗎？不要讓 事情慢下來。快速的讓產品通過測試。如果需要以后再去測試。

　　3、界面問題修復要有適度的準備時間– 我們修復了一個在屏幕上出現的用戶錯誤消息中的拼寫錯誤。用戶并沒有察覺到拼寫錯誤但是我們無論如何修復了問題。很快而且簡單。觸發這個錯誤消息需要30分鐘的準備時間，值得嗎？

　　4、直接了當的配置改變– 去年我們產品開始偶爾出現很大的作業不能處理的問題。一個程序員嘗試改變通用配置修復問題。但在QA的環境中沒有一個簡單的方法去創建一個足夠大的作業超過這個臨界值，很難去測試。我們在產品中修改了配置然后用戶很高興的為我們做了測試。

　　5、技術性的需要非程序員的測試– 測試部分功能時需要實施某種行為而在代碼中設置斷點來復現競態條件.有時測試人員與工具和程序員精通產品代碼的知識并不匹配。討論這個測試但是回避它。

　　6、非測試人員借用– 如果團隊中一個非測試人員幫忙去做測試工作，或者更重要的，想幫忙測試某一組件，讓他去做吧。跟他分享測試的思路并且跟他要測試報告。如果你覺得滿意，不需要再去測試它了。

　　7、沒有復現步驟- 程序員偶爾會嘗試某些東西。經常會出現一些錯誤報告，但是沒有人能對這些錯誤給出確切的重現步驟。我們也許想對修改的區域做回歸測試，但是我們發布的時候不會阻止這種明顯的修復，因為我們不知道它管不管用。

　　8、不足的測試數據或硬件– 讓我們面對它吧。在我們QA的環境中，根據產品中所需要，大部分情況我們沒有足夠多負載平衡服務器。當一個有效的測試需要的資源在產品使用環境之外不可用時，我們可能無法對其進行測試。

　　很多人也許嘗試想像上面這些如果不去測試會導致的問題。我也會做這些。記住，這些事情也許不值得花費我們的時間去測試。再次權衡你所做的事情，如果在不是很清楚的時候，去問問利益相關者。

　　如果你選擇不去測試某些東西，很重要的是，不能被我誤導。這是在我的團隊中使用到方法。在我們進行組件審查時，我們 的（測試人員）說，“我們將不會去測試這些”。如果有人反對，我們會改變我們的想法并且測試它。如果沒有人反對，我們就“未經審查即批準（rubber stamping）”。即表明沒有被測試就讓它通過這樣可以讓他進入到最終產品。

　　所以下次你發現你自己正在著手做的測試，感覺比其他你應該做的事情更不重要時，你應該需要考慮…不去測試它。逐漸的，你的團隊將會尊重你的決定并受益于更少的瓶頸，以及在你實際增加的價值的地方增長的覆蓋率。

　　1、手工測試用例和自動化測試用例功能定位的區別。

　　a）手工測試用例
　　　　i.較好的異常處理能力，能通過人為的邏輯判斷校驗當前步驟的功能實現正確與否。
　　　　ii.人工執行用例具有一定的步驟跳躍性。
　　　　iii.人工測試步步跟蹤，能夠細致的定位問題。
　　　　iv.主要用來發現功能缺陷

　　b）自動化測試用例
　　　　i.執行對象是腳本，任何一個判斷都需要編碼定義。
　　　　ii.用例步驟之間關聯性強。
　　　　iii.主要用來保證產品主體功能正確完整和讓測試人員從繁瑣重復的工作中解脫出來。
　　　　iv.目前自動化測試階段定位在冒煙測試和回歸測試。

　　2、自動化測試用例設計管理不善可以直接導致自動化測試開展的失敗。

　　誤區：

　　1、不編寫測試用例直接投入測試腳本編寫。

　　2、直接拿手工測試用例來編寫自動化測試腳本。

　　自動化測試替代不了手工測試，目的僅僅在于讓測試人員從繁瑣重復的機械式測試過程解脫出來，把時間和精力突入到更有價值的地方，從而挖掘更多的產品缺陷。

　　目前咱們TD中對用例加入了自動化測試的標簽。

　　目前自動化測試定位在冒煙測試和回歸測試。

　　冒煙測試執行的是主體功能點的用例。

　　回歸測試執行全部或部分的測試用例。

　　怎么編寫自動化測試用例，如何將自動化測試用例和手工測試用例相輔相成。

　　用例選型注意事項：

　　1、不是所有的手工用例都要轉為自動化測試用例。

　　2、考慮到腳本開發的成本，不要選擇流程太復雜的用例。如果有必要，可以考慮把流程拆分多個用例來實現腳本。

　　3、選擇的用例最好可以構建成場景。例如一個功能模塊，分n個用例，這n個用例使用同一個場景。這樣的好處在于方便構建關鍵字測試模型。

　　4、選擇的用例可以帶有目的性，例如這部分用例是用例做冒煙測試，那部分是回歸測試等，當然，會存在重疊的關系。如果當前用例不能滿足需求，那么唯有修改用例來適應腳本和需求。

　　5、選取的用例可以是你認為是重復執行，很繁瑣的部分，例如字段驗證，提示信息驗證這類。這部分適用回歸測試。

　　6、選取的用例可以是主體流程，這部分適用冒煙測試。

　　7、自動化測試也可以用來做配置檢查，數據庫檢查哦。這些可能超越了手工用例，但是也算用例拓展的一部分。項目負責人可以有選擇地增加。

　　8、如果平時在手工測試時，需要構造一些復雜數據，或重復一些簡單機械式動作，告訴自動化腳本，讓他來幫你。或許你的效率因此又提高了。

　　用例轉型注意事項：

　　1、首先測試人員應該了解腳本是怎么替代人工來執行用例。

　　2、當你寫自動化測試用例時，你需要意識到你的用例是寫給一個“智障人士”執行，執行對象是腳本。

　　3、當前的測試用例前置配置信息要寫清楚。

　　4、每一個步驟都要銜接好，錯了，腳本要報異常，我要去煩你。

　　5、每一個步驟要做什么，驗證什么要寫清楚，寫具體。有時一個檢查點，你只需看一眼，但是腳本要寫一堆代碼去驗證，這樣的做法是不可行的。

　　6、用例之間不要有關聯性，自動化測試開發同樣是軟件開發工程，腳本編寫同樣提倡高內聚低耦合的理念。

　　7、不是每一個步驟都需要驗證點，讓子彈飛一會兒。

　　8、別在多個地方重復相同的驗證。腳本很忙！我沒空。當然，除非有必要。

　　9、開門記得要關門，配置信息要回歸原點，否則腳本要迷路。

　　10、當你設計自動化測試用例時，難免對一個用例的功能點加加減減。不要因此而剪掉了一些驗證點。因為手工用例+自動化用例=1。

　　寫給項目測試負責人的一些話：

　　1、項目加入了自動化測試平臺，負責人要有全局的把握。因為你的用例被拆分成自動化測試和手工執行用例，原來一些被打入冷宮的用例因自動化測試而重生，重生的用例需要你的維護。

　　2、當你迎來項目新立項，拿到需求文檔，開始設計新用例，此時，別忘了該如何統籌安排你的用例。是的，這很像排兵布陣，有了自動化測試這把利劍，還得看你會不會用。

　　3、不要永遠做自動化測試的門外漢。可能你的職業規劃是測試經理，產品經理，或者其他，又可能你對其感到畏懼或厭倦，認為自己無法跨越對編碼的恐懼。但是，無論如何，今天你是這個項目的測試負責人（一個資深的測試工程師），你要負起這個責任，挑起大梁。

　　4、如果以后你看到自動化測試報告單，沒有發現一個bug，請不要抱怨，自動化腳本主要不是來幫你找缺陷，而是告訴你沒有缺陷。

　　5、如果將來你參與了自動化測試腳本編寫工作，請做好面對一大堆錯誤的心理準備。在前期，測試結果往往會夾雜著一大堆的各種錯誤，可能是框架機制問題，可能是腳本編寫問題，可能是用例問題，還有可能是需求自身的問題。

　　6、咱們部門剛剛開展自動化測試，需要大伙的支持和理解。它的發展需要一個漸進的過程，從無序到有序，從困惑到豁然開朗。這個過程難免曲折艱 辛，甚至會引來非議，但是從一些成功案例中，還是堅定了我繼續走下去的信心。我渴望和大家一起分享這份成果，盡管現在連花兒都未曾開放。

　　7、會自動化測試和會QTP是兩回事，學習自動化測試不一定要會QTP，你也可以通過Selenium入門。

　　8、請考慮下你負責的項目是否需要實施自動化測試，我們可以一起坐下來討論，圈定一個范圍和實施的計劃。我們都是產品線上的一顆螺絲釘，我這顆螺絲釘很樂意為你的項目提供自動化測試的幫助。

　　9、不要過度信任自動化測試，它也是個撒謊高手。所以，自動化用例需要測試，框架需要測試，腳本函數需要測試，腳本過程需要測試，驅動數據需要測試。

　　10、看到這里，你一定覺得開展自動化測試很累人。沒錯，這本不是一件立竿見影的利索活。它的發光，需要一定時間的沉淀，我們現在討論的，和接下來要做的工作就是為了如何來縮短這部分的時間。

　　總結：今天討論的僅僅是自動化測試開展實施的一部分，這部分很關鍵，需要大家的支持，因為用例是整個自動化 測試的靈魂，沒了靈魂，框架搞得再好，也僅僅是個軀殼，行尸走肉。我自己寫測試用例的水平遠不如咱們部門的測試負責人，這是真話。討論自動化測試用例的選 型和轉型難免有些力不從心，盡管這樣，我還是憋著喊出來，希望能得到大家的更好見解，俗稱：拋磚引玉。

由于公司需要測試系統的最大用戶承受能力，所以需要學習使用loadrunner。在安裝的時候碰到了不少問題，所以寫下此文章總結遇到的問題以及解決方案，希望能幫到大家。也希望大家轉載注明出處。

Winsows 的Loadrunner 安裝就不多講了，這個太容易了。

以下是Linux 中安裝 Load Generator 說明：

Linux 系統版本：CentOS5.4

Load Generator 版本 ： Load Generator 11

安裝步驟如下：

1. 到HP官網下載Load Generator 安裝文件 Software,_Load_Generator_11.00_T7330-15010.iso

2.確保系統安裝了c++ ， gclib 相關工具（我的系統在安裝前已經安裝了gclib ，所以還不知道沒裝這個會發生什么問題）

3. 在Windows 系統下將Software,_Load_Generator_11.00_T7330-15010.iso 解壓出來會有三個文件夾（HP ， Linux ， Solaris），這三個文件夾是相關系統的安裝包。請根據你的系統選擇對應的文件夾copy到 要安裝的Linux 系統中。為什么要使用這種解壓后copy的原因是因為我根據網上的方法copy iso 文件到Linux 系統中并使用掛載的方式進行安裝，碰到了很多問題，所以使用這種方式，這可是我原創的哦。我是copy到/home/LoadRunner/目錄下

4. 緊跟著就是安裝了，只需要執行指令/home/LoadRunner/Linux/installer.sh 會出現如下圖中的安裝向導歡迎界面，選擇Next [n] 即可。

5. 出現下圖許可協議界面，也只需點擊Agree [a]，當然你可以選擇View Agreement [v] 查看協議的詳細內容

6. 出現確認安裝界面，選擇Install [i] 即可

7. 出現安裝界面如下圖

8. 完成安裝，選擇Finish [f] 即可，恭喜你安裝成功

9. 緊跟著就是配制環境了，網上有說要配置env.csh 的，但我安裝后env.csh 已經默認配置好了，這里也將的默認配置文件分享一下

setenv PRODUCT_DIR /opt/HP/HP_LoadGenerator
setenv M_LROOT $PRODUCT_DIR

if ( `uname` == SunOS ) then
    setenv LD_LIBRARY_PATH ${M_LROOT}/bin
else if ( `uname` == Linux ) then
    setenv LD_LIBRARY_PATH ${M_LROOT}/bin
else if ( `uname` == AIX ) then
    setenv LIBPATH ${M_LROOT}/bin
else if ( `uname` == HP-UX ) then
    setenv SHLIB_PATH ${M_LROOT}/bin
endif

setenv PATH ${M_LROOT}/bin:$PATH

10 .除了上文中講到的還需要在/root/.bashrc文件中添加如下配制，保存修改后注銷用戶重用登錄
export PRODUCT_DIR=/opt/HP/HP_LoadGenerator 
export M_LROOT=$PRODUCT_DIR 
export LD_LIBRARY_PATH=${M_LROOT}/bin 
export PATH=${M_LROOT}/bin:$PATH

11 . Load Generator會安裝到/opt/HP/HP_LoadGenerator目錄下，我也是使用默認的。進行/opt/HP /HP_LoadGenerator/bin 目錄執行./verify_generator （不能使用root用戶，至于為什么還不清楚）  檢查安裝是否成功，如果成功會有以下信息，

===================================================
              HP
     Vuser Environment Verification Utility
===================================================


Product: LoadRunner 11.0 
Version: 11.0.0.8866 
Build: 8866  

localhost.localdomain: 

verify_generator...OK
verify_generator...OK
verify_generator...OK 
Don't forget to make sure that the name of the controller machine 
is also in .rhosts 
Verify $M_LROOT ...Failed 
_____It was not possible to set the $M_LROOT from 
_____the shell dot files. One of several things might be happening: 
_____1) $M_LROOT is not set at all in the shell dot files. 
_____2) There is some error in the shell dot files which stops their execution 
_____   before it sets $M_LROOT. 
_____3) There is conditional code in the shell dot files (most likely related to 
_____   interactive and non interactive shells) and $M_LROOT is set 
_____   only in one of the sections. 
_____Aborting virtual user tests on host localhost.localdomain 
verify_generator...OK 
_______________________________________________


Summary:
________
Vuser Host localhost.localdomain: Failed

這些Failed 我都忽略了，因為這些Failed并不影響運行。我很希望哪位大蝦看過此文章后能在此回復解釋一下這些Failed可以解決嗎？

上面是正確的信息，我剛開始的時候遇到了下面這些提示，注意其實這些提示都很直觀，缺少了 libstdc++.so.5 ， 安裝就可以了。調用 yum install  libstdc++.so.5 .安裝后再調用 ./verify_generator 就可以看到上面的信息了。

===================================================
              HP
     Vuser Environment Verification Utility
===================================================


Product: LoadRunner 11.0
Version: 11.0.0.8866
Build: 8866




localhost.localdomain:


/opt/HP/HP_LoadGenerator/bin/lrv/chk_thread_lmt: error while loading shared libraries: libstdc++.so.5: cannot open 


shared object file: No such file or
 directory
/opt/HP/HP_LoadGenerator/bin/lrv/limithost: line 134: [: : integer expression expected
/opt/HP/HP_LoadGenerator/bin/lrv/chk_sems_lmt: error while loading shared libraries: libstdc++.so.5: cannot open 


shared object file: No such file or d
irectory
/opt/HP/HP_LoadGenerator/bin/lrv/limithost: line 154: [: : integer expression expected
verify_generator...OK
verify_generator...OK
verify_generator...OK
Warning: The file .rhosts does not exist in the home directory of the user.
Verify $M_LROOT ...Failed
_____It was not possible to set the $M_LROOT from
_____the shell dot files. One of several things might be happening:
_____1) $M_LROOT is not set at all in the shell dot files.
_____2) There is some error in the shell dot files which stops their execution
_____   before it sets $M_LROOT.
_____3) There is conditional code in the shell dot files (most likely related to
_____   interactive and non interactive shells) and $M_LROOT is set
_____   only in one of the sections.
_____Aborting virtual user tests on host localhost.localdomain
verify_generator...OK
_______________________________________________


Summary:
________
Vuser Host localhost.localdomain: Failed

12 . 啟動 Load Generator  ，在安裝的bin目錄下輸入 ./m_daemon_setup start 即可開戶服務了 （不能使用root 用戶啟動）

13 . 修改防火墻策略，對54345端口開放，或者直接關閉防火墻（不建議直接關閉）

講到這里安裝步驟就完，現在講如何在Windows 系統下啟用 剛才安裝的Load Generator

1. 打開Controller 的Load Generator 。 點擊 場景--> Load Generator

2. 添加一個Load Generator 。點擊 添加--> 輸入名稱（名稱即ip）--> 選擇平臺 --> 點擊更多 --> 點擊 Unix 環境 --> 勾選“不使用RSH” --> 確定

3. 添加后測試連接，如果顯示連接成功就功造成了，連接時如果有其它問題建議大家多思考，注意那些連接不成功的提前。我個人覺得LoadRunner 在提示之方面做的比較好，出了問題基本上看提示就知道問題在哪里。祝大家一切順利。