第一篇：測試經驗總結

6年測試工作的思考

前言

在公司已經干了6年的測試了，干測試經理也5年了。正好趁此機會把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對自己工作的回顧。由于時間倉促基本上是想到什么些什么，有點兒亂，也請大家多多擔待了。只要還有些人能從中找到些兒同感，或從中得到一些幫助，一些經驗，我就知足了。

1.什么是測試

首先我要談談什么是測試。相信好多測試人員跟我一樣，來公司之前也沒有從事過任何測試工作。對于測試都是從零開始的。也有好多人跟我一樣，從各種書上或是培訓中得到過有關測試的各種定義。但不知道大家有沒有凈下心思考一下。什么是測試。在公司公司測試工作的定義是什么，測試的工作范圍是什么。

測試的定義根據測試技術的發展，歷經了3個主要的階段。第一個階段，認為測試就是找產品中的bug。第二個階段，除了找bug以外，又增加測試是對軟件質量的度量這一概念。第三個階段，明確了測試是指為了度量和提高被測試軟件的質量，對測試件進行工程設計，使用和維護的并發生命周期。注意其中提高的測試件，其主要是與軟件這個詞進行對應。明確測試也是一種開發過程。他的工作成果就是測試件，好像平時我們所謂的測試案例、測試腳本等等都可以稱為測試件。然后使用測試件去度量和提高被測試軟件的質量。

目前，在中國大部分軟件企業，尤其是中小型的軟件企業還停留在第一階段。我個人覺得公司稍微好一點兒，處于一、二階段之間。因為我們平時做的最多的一件事，還是找bug。至于測試案例和測試腳本等等，只占用工作量的很小一部分。而且我看不到大家在平時的測試工作中是完全依據測試案例進行測試的。目前測試案例等工作更多的成為了一種形式上的產物。從有些部分所有產品的測試案例在一個下午就能評審完就能看得出來。

說到這里順便在談一句測試計劃。目前的測試計劃是作為產品計劃的一部分。先明確大概發版時間，然后是各個階段的里程碑，其中提交集成的里程碑是死的。開發需要的時間就是那么多，剩下倒推的時間就是測試的時間。這樣定出的計劃是否能夠起到計劃的作用就不好說了。現在的計劃更多的是羅列聯調測試的各種內容，至于時間，不說也罷。所以從中也可以開出公司的測試也就停留在一、二階段之間。

明確了公司測試的定義（個人理解），也就不難理解公司給測試人員的定位了。在測試人員中經常流傳的一種說法就是國外測試人員的地位多么多么的高，開發就是coding。咱們公司開發比測試多拿多少多少，測試人員地位是開發序列中最低的。大家也要看看人家公司測試人員的素質，測試在開發過程中的重要性。再看看自己所從事的工作，就是找軟件的bug。當然我也個人認為有經驗極其豐富的測試人員對產品的貢獻比開發和需求大。明確了這些，心里也就能少點兒不平衡感。

2.測試方法的思考

說完個人對測試含義的理解，再說說個人對測試方案的一些思考。

個人認為在公司6年，測試方法沒有什么提高。主要還是以黑盒測試為主。中間也曾經引入過各種各種工具，但測試人員真正用起來的也就是robot。而且robot主要是進行回歸測試，再加上一些人并沒有真正認識到其價值，應用范圍也極其有限。對整體測試效率的提升影響不大。所以目前的測試方案還主要是以需求為依據的黑盒測試。至于什么極限值了，成對測試法等等，都是建立在黑盒測試的基礎上，而且從我一來公司就有相應的測試項目，只不過沒有明確概念而已。

另一個說個人覺得6年來公司測試方法沒有什么提高的原因是，6年前測試是以人為主，靠得是測試人員的經驗，對產品的熟悉程度，對業務的理解程度。6年后測試還是以人為主，人就是測試的主體，產品質量的保證。還沒有過渡到測試案例就是測試的主體，測試案例的完整性是產品質量的保證。只要測試還是以人為本，我覺得測試的效率就不會有太大提高，產品質量的信心來源也是對相關測試人員的信任。我個人覺得以黑盒測試為主要的測試方法沒錯，而且也比較符合目前公司的測試現狀。但一定要注意各種經驗的總結、積累，更重要的是共享。雖然目前測試案例在測試工作過程中的地位不重要，但其畢竟是編寫者的經驗積累。匯總起來也是一筆可觀的財富。可現在如果有人問我850的測試方案在那里，其中還有多大比例能夠用在現在的產品中，在現在的測試工作中有多少以前的案例能夠復用。其他產品中的測試案例中有多少是關于接口功能，有多少我可以借鑒。我不知道，這也是自己工作不到位的地方。所以我要說的作為黑盒測試為主要的測試方法，一定要注意測試經驗的總結和共享。

而且我認為一個人如果黑盒測試能做到位，做到最后培養的是一種測試的感覺。測到最后，產品你一看就能知道那里可能有問題，那里應該沒什么問題。這樣有重點地投入測試力量可以收到事半功倍的效果。可這是需要大量測試經驗的積累的，不是我告訴你，你就知道的能力。在此前提上加強測試人員之間的橫向溝通，形成經驗貢獻。可以較快的培養測試人員的測試感覺。

最為測試經驗積累的另一個重要方法就是加強對測試案例的要求和管理。每版測試案例不僅要包括新增功能，還需要包括上一版本中繼承的案例，修改或刪除上版案例中變更的內容。從而形成一份完整的關于產品所有功能點、接口、升級、年結等等各方面的測試案例。真正做到測試案例是測試的主體，從而提高測試效率，提高產品質量。

3.測試工具的概念和作用

測試工具，什么叫測試工具。我認為任何能提高你測試效率的工具都可以稱之為測試工具。不僅僅指robot或是loadrunner這類專門的測試工具，也不僅僅指使用各種編程工具編寫的測試工具。像總賬工具、eai等，即使只是幫我們導入一些常用檔案，也可以節約我們的測試時間也可以稱之為測試工具。

我個人現在公司測試在測試工具開發上還很不足。在公司里一提起測試工具，大家第一個想到的可能就是robot。即使是robot應用的也不夠深入。大家經常認為robot主要錄制gui的腳本，跟產品界面聯系緊密。每次回放成功率不高，各個版本間腳本復用率也較低。而且每次總是以各種理由將腳本錄制放到最后，經常就不了了之了。最后階段的測試任務實在太緊。我想說的是robot的應用雖然有各種各樣的局限性，但其畢竟提高了測試效率。比如說安裝盤驗證，使用robot驗證，每天都可以節約一半以上的驗證時間，這就是效率。認識了它的好處，才能想盡辦法解決或避免在robot使用中的各種問題。以前同事有一套robot腳本規范就很好，使用后不僅提高了回放成功率，而且回放中斷后，繼續回放也變得很容易。所以說使用robot后，想100%回放成功不可能，想不再進行腳本的調試也不可能。認識這兩個問題后，就需要加強robot使用經驗的總結和共享，有針對性地加強robot使用問題的研究，每版測試開始時針對上版robot腳本的復用問題進行研究。這樣才能用好它，真得使之成為一個工具，而不是一項任務。

一種工具也不是萬能，有許多針對產品特性的測試工具。只能自己開發，大家應該積極提需求。凡是認為有可能提高測試效率的工具需求都可以提。能從網上找到現成的工具解決需求更好。不能，如果是普遍性的需求，可以專門進行開發。因為咱們產品的特性，每版間測試工具的復用度很大。從長遠看就是節約開發成本，縮短開發周期。

在現階段加大測試工具的適用范圍和力度，用好各種測試工具，可能是提高整體測試效率最快最好的方法。但一定要加大推廣的力度。否則有了好的工具，沒人用或用不起來也是沒用。

4.如何看待各種規則和執行

可能大家覺得平時開發過程中有好多規則、制度。這些除了一些自己公司內根據各種情況制定的外，大部分都是跟cmm體系相關的一些規則。可以說是已經被許多軟件公司驗證過，可以提高開發和測試效率的規則。但好多人覺得起沒有什么用，就是在浪費時間。總是以一種完成任務或是應付差事的心情去做。我覺得大家之所以覺得其沒用，恰恰就是由于你去做這件事的動機不對。總以應付差事的心情去做，你就不可能真正理解這么做的目的，這樣做能給你帶來什么好處，你從中會得到什么收益。所以我個人認為，既然有規則，不管是公司自創的或是借鑒其他標準，都是為了解決開發過程中的問題，為了提高開發的效率，保證產品質量。也許這些規則中有這樣那樣的不合理，但只有你認真地去做了，才能發現其中的不妥之處，才能改進，才能更有助于你的工作。

執行也是我覺得在工作中需要進一步加強的環節。許多規則就是因為執行力度不足，才容易讓一些人找到空子，應付了事。但怎樣加強執行力度，還是一個需要大家一起進行探討的問題。

5.作為一名測試人員應該具有的素質

測試人員應該具有什么樣的素質，相信好多人都有自己的理解，不同書上的觀點也不盡相同。我就說說我在公司工作了六年，覺得一個合格的測試人員應該具有什么樣的素質。業務和測試方面的能力就不說了。

測試人員應該具有的素質包括： 1.踏實細心和積極主動

我覺得作為一名測試人員首先要踏實細心。測試人員每天都要面對著枯燥的程序，從事著大量的重復工作，還要盡量發現產品中的bug。如果不踏實，你就坐不住，總想干別的，就無法凈下心來想用戶有可能怎么用，需求對產品是怎么要求的，現在產品中是怎么做的，哪里可能存在問題。不細心，就特別容易一些產品中微笑的錯誤，而恰恰就是這些錯誤是最影響產品形象的問題。

至于積極主動就不多說了。這是每個人都應該具有的素質。2.懷疑一切

不抱著懷疑一切的態度就不是一名合格的測試人員。經過你手測試的產品面對的是直接用戶。你不認真負責，不抱著懷疑一切的態度。總想著這個功能本版沒動應該沒什么問題，這個功能沒什么用戶用不用認真測了。這樣發出的產品，我是不敢讓用戶用。因為用戶用起產品來是千奇百怪，有些用戶的水平和對產品的理解比咱們還要深。所以一定要抱著懷疑一切的態度，認為產品每個功能都可能有問題，認真地測試產品的每一個測試點。

3.協作和團隊感

協作和團隊感也是十分重要的。要意識到測試、開發、需求是一個團隊，一個整體。離了誰，產品的質量都無法保證。誠然有個別開發人員責任心不強，經常將未經任何驗證的代碼編譯后發給測試進行驗證。耽誤了測試人員不少的時間。但越這樣，測試人員越應該負責，否則產品發出去影響的是公司的形象。

還有個別開發人員開不起測試。此時就需要你通過各種方法去證明你自己的能力。比如測試出他根本就沒考慮過的問題等等。以實際行動證明你離不開我，咱們是一個水平的。只有這樣加強協作和團隊建設，加強整個團隊的質量意識，才能提高開發效率，保證產品質量。

4.自我提高和總結的能力

測試人員經常很迷茫，不知道自己的發展方向在哪里。測試技術還是專業知識。領導們所謂的個人發展方向考慮也經常是畫一個餅在那里。這時就只能靠我們自己了。看你想今后從事哪方面的工作。一般情況下，如果升不到管理層就只有兩條路可選了。一是業務精通，將來可以向需求或是售前、實施方向發展。一是技術精通，多掌握幾種測試工具，又能力可以學習一些編程方面的知識。將來還繼續從事測試方面的工作。隨著中國軟件開發的規范化，這條路也是很有發展的。

另外，我覺得作為一名合格的測試人員，一定要注意進行總結。通過總結可以對自己的工作進行一個回顧分析，看看那些做得不錯，下次還繼續這么做。那些工作還有改進的余地。對自己能力的提高是一個很好的幫助。

6.作為一名測試經理應該具有的能力

作為一名測試經理，我覺得除了具備一個測試人員應該具備的素質外，還應具備以下能力。

1.出色的溝通和協調能力

由于測試人員和開發人員的工作性質，必然導致測試人員和開發人員在工作中會產生沖突，對同一問題會產生不同的看法。這時，你怎么去協調，去溝通，解決這種矛盾，讓自己所在的開發團隊中極少的受此影響，就是考驗你能力的時候。

2.條理性和計劃性

作為測試經理，要負責帶領團隊內的其他測試人員全面的測試產品。由于測試項目很多，不僅包括產品功能，還要包括效率，性能，壓力，并發互斥，環境等等方方面面。此時你如何去安排這些測試項目，哪些可以先做，哪些可以并行。與開發人員在一些項目的測試中如何協調就是考驗你做事的條理性和計劃性。

3.從全局考慮產品測試的能力

每一個測試人員在產品測試中，重點肯定是自己負責產品的功能，此時就容易遺漏其他的一些測試項目。有可能是接口的部分功能，又可能是升級或年結的部分功能。此時，你如何提請他們還有漏測的功能點。在有限時間內，能找出他產品測試上的薄弱點，就是考驗你通盤考慮產品測試的能力。

后記

上面就是我對6年測試工作的一個回顧。這些都是我個人的一些觀點，很不全面，也有不正確和遺漏的地方。大家看后，能從中得到一些自己需要的東西，我就知足了。

再次感謝在這6年中給了我許多幫助和支持的各位兄弟姐妹們。

附錄A、QA工作心得

看過許多同行兄弟姐妹的工作感受，反映了一些從事QA工作過程中的困惑，心里也很有同感。之前做過幾年的測試工作，到了新的公司開始做QA工作，雖說測試工作也是屬于質量工作范疇，但是真正干起來才發現，還是有很大的不同的，尤其是思想方法和工作方法上。所以也是邊學邊干，這邊和大家分享一點心得。

1、調整好自己的心態。

尊重開發人員、產品經理、項目經理等項目組內同事，不要把自己定位為監工，要把自己定位為服務員。如果你真的是從心里想幫助大家把事情做好，而不是教訓別人，大家會感受到的。很多時候，調整好自己的心態才是難點。

2、有的放矢 不要盲目的發表意見，要做到有理有據，這也是避免項目組內成員產生爭執和不理解的前提。在提出意見和建議前，最好做一下調查，收集一些資料和數據，或者和大家深入的聊一聊，開一些交流會，座談會，收集到一線開發人員的真實感受，不要自己一覺得有問題就沖出來，這樣肯定會被別人反感，也會降低大家對QA的認同和信任感。

3、數據說話

質量工作相對務虛不假，之前做測試好歹還有很多的bug擺在那里，剛開始做QA工作確實覺得虛了很多。自己的產出在哪里？后來發現，其實還是可以有很多的，呵呵。你可以給相關人員進行培訓（質量知識、軟件工程知識、產品開發知識、質量制度和規范等等），會議記錄和培訓資料算是你的產出的一部分。另外，對于項目過程中產生的問題，變更等，要有記錄，一定周期內作出分析和報告，比如，變更發生率，項目延期的原因分布，與計劃的不符合程度等等。進一步提出改進建議，有了這些數據支持，你提出建議也就更有說服力。

4、溝通再溝通

其實很多問題都是發生在溝通上，我覺得溝通好了，起碼可以解決70%的問題。多為大家提供交流和溝通的機會，比如，發起一個交流會，讓組內同事互相培訓，形成一個良好的內部學習交流氣氛。另外，什么也比不過面對面的溝通，拋棄聊天工具和email吧，走過去，和你的同事一起好好聊聊，吃飯的時候，坐車的時候，你會發現很多深入的問題的，呵呵。

5、循序漸進

規范制定好了，不要一下子就想完全推行到底。畢竟要改變別人已有的習慣，是會讓別人不舒服的，呵呵。所以要循序漸進，分期分批，一點點來，習慣慢慢的就被改變了，這樣大家就不會太抵觸。而且，在分期分批推行規范的過程中，別忘了不斷收集反饋意見，不斷改進和修正規范，規范可不是qa說是什么就是什么的，一定要收集大家的意見，達成共識，這樣才有被大家執行的基礎。

6、展示自己

QA工作務虛，但是可以落到實處，是有很多實際工作要做的，比如文檔編寫，規范起草。培訓、評審、跟進問題。這些工作的成果如何體現，效果如何，可以通過一些問卷調查，來收集大家的反饋，舉個例子，如果推行產品開發流程規范前大家對流程的滿意度是50%，推行規范兩個月以后，滿意度成了90%，你說這是誰的功勞呢？呵呵，這也是數據說話的一個方面，也是QA工作成績的展現。說了這么多，其實我做QA工作也只有3個月，還有很多的不足，希望能和大家多多的交流，如果自己的一點心得，能夠給大家一些幫助或啟發，就深感欣慰了，呵呵。歡迎拍磚！

附錄B、SQA之Q&A 軟件質量保證，即 SQA，全稱是 Software Quality Assurance。

問： SQA 目的是什么？

答： 對于任何的行業，講到質量控制，歸根結底都是為客戶提供更高品質的產品，更好地滿足客戶的需求。質量有問題的話就不能滿足客戶的需求。在 CMMI 里邊就有 “ 集成流程產品開發 IPPD(Integrated Product & Process Development)”，為什么要集成呢？就是說產品的研發不僅僅是開發團隊的工作，還要把市場團隊、銷售團隊、整個的流程、包括客戶的反饋都要考慮進來、集成進來。目的是為了什么？其實就是為了更好地滿足客戶的需求。六西格瑪里面說 DPMO(Defect Per Million Opportunities)，百萬產品里有缺陷的產品只有三個。這是為什么？就是為了減少差錯，從而讓客戶享受非常高質量的服務。

問： SQA 等于測試？

答： 測試其實只是 SQA 的一個環節，SQA 的全稱是軟件質量保證。在國外很多的大型的企業，比如說摩托羅拉、愛立信，他們的研發團隊里面都專門有一個 QA 部門，其實他們并不是做測試工作的。QA 部門其實是管理開發流程的執行，并專門負責制定產品開發流程。比如說 RUP 里面有一個角色，叫 Process Engineer，過程工程師，他就屬于 QA 部門，他的工作就是負責制定整個軟件開發的流程。因為如果說要保證質量的話，不能只靠測試來保證。而必須在整個開發流程的各個環節都要做得很好，才能夠真正地提升軟件的質量。而測試只是整個開發流程最后的一個階段。所以說一個好的流程就決定了一個軟件的開發能不能按時交貨，能否保證軟件質量。這個流程就是由 QA 部門來制定的。QA 部門還有另外一個職責，就是保證整個研發團隊能夠嚴格按照這個流程來運作。在項目到達每一個里程碑的時候，QA 部門的 QA 經理就會介入，對項目做一個審核，檢查前一階段的工作是否按照公司制定的流程來運作。看看該有的工件是不是都有了，該有的步驟是不是都有了。開發團隊要證明給 QA 人員看。只有過了這一關，QA 部門才會同意說開發團隊可以往下走，進行下一步的工作。所以嚴格來講，眾廣義上理解，SQA 是針對整個軟件開發流程的，它關心的是怎樣在軟件開發生命周期中來保證好軟件的質量。這是一個非常大的概念。

問： SQA 在 RUP 中是如何體現的？

答： 其實 RUP 整個流程都在講 SQA。業界常見的模型，譬如 CMM/CMMI，六西格瑪，ISO9000，RUP，它們做的基本上是同一件事情--都是在做流程改進，都在做質量控制，但是各自的側重點不一樣。像 RUP 和 SDP 專門側重于從軟件開發的整個生命周期來保證軟件質量，所以對軟件開發商特別適合。而其它的模型，側重點則在其它的環節，比如說 ISO9000，用在制造業比較多一些； CMM，原來是應用在軟件這個行業的，后來擴展到 CMMI，就擴展到其它行業它也適用。但適用面越廣，它拉的層次就越高，可實際操作的東西就越少。RUP 是專門側重于軟件項目開發的。怎樣來保證做好 QA 呢？ RUP 里定義了一個軟件生命周期模型，分成四個階段--初始階段、細化階段、構造階段、交付階段，每個階段有不同的側重點，通過多次的迭代，每次迭代里面都要做質量控制。

質量控制從需求開始，有很多需求分析和需求管理方面的技巧和技術方法，它們從需求方面來保證軟件的質量；到了設計，就有很多成熟的設計方法，例如可視化建模，基于構件的架構設計和現在提出的模型驅動開發方法；再到實現，到測試等方面，都有很多的方法和技巧來提高軟件的質量。這里面每一個環節的目的都是為了提高整個軟件開發的質量。

開發過程中，什么樣的問題會造成質量問題呢？其實最主要的就是溝通方面的問題，以及對系統復雜度把握程度的問題。我們逐漸發展了一些技術來幫助我們解決這些方面的問題，例如用 UML 這種標準化的語言來增強團隊的溝通，用面向對象的技術來幫助加強對復雜度的控制能力。

原來這個系統很復雜，使用面向對象的方法，本身就是為了簡化系統構建的復雜度。改變你看問題的角度，你對問題的把握程度就會不一樣。譬如人看一個二維迷宮很容易就能找到出路，但螞蟻在里面就走不出來，因為看問題的角度不一樣。面向對象方法和可視化建模技術可以讓開發人員可以更好地去把握系統，增強對系統的可控制能力，從而從這些維度上來提高和保證軟件的質量。

現在有很多自動化的工具，如 IBM Rational RAD(Rational Application Developer)/ RSA(Rational Software Architect)，都是支持 MDA 的開發方法，在模型這一級進行開發，從模型直接生成代碼。在開發方面我們有很多輔助工具，幫助開發人員盡量將人工做的工作、復雜的重復性的工作、不具有創造性的工作讓工具來做。讓人去關注他應該關注的方面，比如開發人員應該關注業務邏輯的處理，但是軟件的構建方面我們是盡量讓工具來降低構建細節上的難度。這樣也是有助于提高質量的。

然后產品出來了，需要進行測試，有測試流程、測試規范來幫助保證質量，這是最直接的。然后還有很多的環節還會發生錯誤，比如配置管理、版本的管理，也需要相關的支持來保證軟件的質量。所以說軟件質量保證不應該只是在一個環節上，比如測試環節來保證，而應該是整個的流程，我們應該全面地去改進流程來保證質量。

問： 做 SQA 這方面的人員，在溝通方面需要的什么樣技巧和能力？

答： 首先從大的方面說，整個團隊的溝通，首先是大家要講同樣的語言。UML 只是這種語言的一部分，我們不要狹義地理解這種溝通語言就是 UML。它還包括采用一個什么樣的流程方法，整個團隊都要理解。譬如你說項目正處于 “ 精化(Elaboration)” 階段，這個團隊都要能理解這個術語。

還有就是整個組織機構內部大家采用的流程都是要一樣的。舉個例子來說，Rational 有很多產品，其中很多都是收購來的。不同的產品團隊采用的開發方法、開發工具都是不一樣的，他們到了 Rational 之后做的第一件事就是整合。這個整合一方面是說產品要整合起來（我們有 Suite 產品）；同時也是針對開發團隊開發方法的整合，例如 Rational 花了一兩年的時間把所有產品團隊統一到 RUP 和 ClearCase/ClearQuest平臺之上，這是我們的首選。實際上到了 IBM 之后也是一樣，IBM 現在正在做的計劃就是讓所有的實驗室、研發團隊都要使用 IBM Rational 自己的開發工具，他們都在使用 IBM 自己的開發方法、開發平臺。這就是讓大家的溝通基于一個統一的基礎架構 ―― 統一的軟件開發平臺，這也是增強溝通的一種方式。另外，講到 SQA 的人員，在 RUP 里對應的就應該是 Process Engineer。他的主要的職能就是定義流程，保證流程的執行，并且不斷地改進流程。對他的要求就是要對流程要比較了解，有實際項目的開發經驗，不然沒有辦法理解流程，這是技能方面；另外就是與人的溝通能力要強，跟一般的開發人員和項目經理是有區別的，溝通的能力一定要強，他要負責說服項目團隊來遵循標準。

問： QA 人員與目經理和開發人員之間的關系是怎樣的？

答： 首先彼此之間是一個合作的關系。如果片面理解 QA 人員只是 “ 過程警察 ” 的話，就可能把他和其他的角色對立起來了。實際上在一個團隊內部要避免這種認識。因為大家都是在一個組織架構內部的，大家的目標是一致的，就是要把公司的業務做好。所以 QA 人員的職責和任務就是幫助這個項目團隊更好地進行軟件的開發。既然已經定義的流程是比較適合企業的，項目就應該遵守這個流程來進行開發。如果有時候項目因為趕工，或是其它的原因違背一些流程上的規定的話，就會對軟件的質量會造成一定影響，他就有責任來幫助開發團隊來糾正這方面的一些錯誤。還有就是進度方面的問題。如果不按照流程來走的話，短期內看起來進度是快了一點，但從整個項目的周期來看，有可能是給以后的工作帶來隱患，客觀上肯定是延長整個開發的進度的。所以對于一些流程管理得比較好的企業，你會發現他們的 QA 部門和開發團隊是相處得比較融洽的，配合是比較緊密的。在我們的客戶里就看到過他們的開發團隊非常感謝自己的質量控制人員，覺得他們對自己是給了很大的幫助。

QA 人員跟每一個角色的關系，如果你對應到 RUP 的話，RUP 里就定義好每一個角色是做什么工作的。RUP 里分了 9 個規程(discipline)，流程工程師是在環境規程里邊，項目經理是在項目管理規程里邊。每一個規程其實就是一類開發活動，其中的角色和他們所產生的工件集合，是一個分類。可以把項目經理相關的工作，他所涉及到的工件，比如說軟件開發計劃、風險管理計劃、質量保證計劃都放在一起，放在這個規程里面。所以 QA 人員跟項目經理的關系就是去檢查項目經理在這個崗位上所做的職責是否到位，是不是跟流程相符合。其他的角色也是一樣的，譬如一個測試人員，就要看你有沒有根據規定把缺陷按正確的測試流程匯報，發現缺陷之后是否能夠得到改正，并作一個復審，還有回歸測試的時候有沒有考慮測試的完備性等問題，就是看測試人員有沒有做好具體的工作。QA 人員和整個項目團隊在工作中的關系就是看每一個角色是不是很好地完成了自身角色所應該完成的開發任務。標準是什么？就是這個組織的流程，流程是保證質量很重要的一個依據。

問： QA 人員如何判斷其工作效果和質量？

答： 最直接就是 RUP 里的工件。可以去檢查這些工件，可以根據檢查的結果來判斷角色是否達到了要求。既然是檢查這個結果的話，就有必要涉及到統一流程和工具的問題。就是說開發團隊有必要采用統一的開發方法和流程。不然的話每一個開發團隊各自采用不同的開發流程，流程工程師就很難去評價，沒有一個可對照的標準，沒有可比性。另外，和采用的工具也有關系，就是說團隊要盡量采用統一的開發平臺。采用統一的開發平臺，工具會幫助自動收集很多的信息。比如說我們的 Project Console 可以幫助收集很多量化的指標；現在有 Portfolio Manager，項目組合管理平臺，可以幫助了解項目進度還有項目進行過程中產生的各種結果；還有包括測試的報告等等，這些都最好有一個統一的標準。打個比方來說，現在的航空公司都會選擇相同飛機制造廠商的機型，就是要降低維護的成本。因為機型比較統一的話，就比較好進行管理。在一個軟件企業的話，在內部采用統一的軟件開發平臺也能有助于企業判斷項目的情況，判斷的方法也會相對比較簡單，工作量會降低。

這是從 QA 的角度來看，其次從整個團隊的角度來說，今天是做這個項目，明天做另外一個項目，作為企業的管理人員肯定不希望員工今天做這個項目用一個工具，明天做另外一個項目用另外的工具，這樣學習成本就太高了。

第二篇：測試經驗總結

1.測試人員和用戶的聯系與區別

黑盒測試人員和用戶，都是站在實際應用層進行操作，因此他們對應用層的可用性、實用性非常關注。用戶不懂的是軟件的使用，而相對用戶來說，測試人員對軟件比較了解，但不熟悉業務本身。

八個字歸納：用戶是用，測試是測。

用戶不懂使用就需要技術支持人員去培訓，而測試人員在測試初期經過開發人員和項目負責人的簡單培訓后，就應該通過所學的理論知識和相關的業務知識獨立去了解、深入到軟件的功能點中。

應該做到：由測試人員培訓技術支持人員，由技術支持人員實施時給用戶培訓。

2.帶著問題去測試

阿豬工作守則第一條：帶著問題去測試

測試中會遇到很多問題，沒關系，沒有腦子里面的一個個問號，是不能很好的發現問題的。往往發現一些藏的很深的bug都是在測試人員一步步解決這些問號的過程中，切忌遇到問題就問，不僅因為增加不必要的與開發人員、負責人等的交流時間可能延誤項目進度，而且自己對問題的印象也不會很深刻，畢竟在相對較短的測試時間內，聽不如記，記不如自己去發現規律。

3.測試期間提問題和交流的時機

什么時候應該提問題？

我們都知道，作為測試人員，并不是測試期間什么時候遇到問題就要馬上問，那什么時候是提問的時間？

培訓

培訓時，一般在講解內容的間歇允許打斷，由培訓人員解答測試人員的疑惑。培訓的過程其實就是一個傳輸新知識并答疑的時間，這個期間的提問是歡迎的，也可以增加參與性和調動積極性。所以希望大部分的問題能在這個階段提出來。受時間、環境等條件制約，有時培訓的人講的也不一定細致和全面，這時就需要自己多想，想想這個功能是干什么的，為什么這么做，對應的業務是什么。

阿豬工作守則第二條：培訓時腦子靈活轉動，多想多問

以前大家可能有過參加辯論會的經歷，就算沒有其實和人聊天也是一個交互的過程。參加辯論會要求快速思考，然后放慢語速說出自己的觀點，因為不能說錯。我們在參加培訓時前者相同，后者相反。腦子嘴巴都要快，說錯了也沒有關系，自己的想法被糾正的過程中也是加深印象和理解的過程。

計劃評審

提出對于軟件不理解、安排的任務不明白的地方。

測試期間

這個時期最主要的問題應該集中在影響測試流程和進度的問題，而不是說明書或其它文檔上已有的內容，或者與自己負責模塊無關的內容。開發人員和其他測試人員都有自己的進度安排，因此，影響測試流程和進度的問題,馬上問！

不影響流程的問題，記下來統一問！

不必要的問題（說明書或其它文檔上已有的內容、講過三遍以上的問題、今晚去哪里吃飯的問題），不問！

好處：避免不必要的時間支出，不打亂自己的測試思路，一氣呵成，并且使項目成本得到控制

壞處（？）：腦子里、筆記本上留下一堆待解決的問號吧，浪費腦細胞和公司的筆和紙

張等資源

阿豬工作守則第三條：先做事，后學習

在有限的時間內先完成該做的事，有空閑的時間再去補充自己的知識。

要很好的把握上述內容，也要求提高培訓期間培訓人員培訓內容的完善性，要求前期培訓人員強調出軟件的重點、難點和注意事項。這個期間適合于上面提到的“帶著問題去測試”的方法。

但有一點需要注意：不要為了一個地方的卡殼在那耗上一天半天的，這就不值得了。測試中期評審測試問題

答疑解惑的時間。

測試報告評審

對一些結論有疑惑和不解的地方，提！

4.記筆記

一個老生常談的話題。

阿豬工作守則第四條：好記性不如爛筆頭

測試培訓的時候對于一些重點應該記下來，即使當時聽懂了；沒聽明白的更應該記下來，到測試軟件的時候去驗證自己的疑問。如果培訓時特別強調的地方，測試時再去問，這就不好了。

養成一個良好的習慣，會使以后的工作更加順利。

5.在公司和學校的學習的區別

學校是專門學習的地方，公司就是工作的地方，因此，它們的性質決定了其學習內容和方法的不同。

學校 公司 備注

內容上 主要是系統的理論知識 主要是和項目相關的業務知識 如果在測試中感到自己部分理論知識欠缺時，就應該回家多補充了

時間上 大塊時間的連續學習相對鄰散 在公司一般不會拿出大塊時間來學習和講解 形式上 老師授課＋自學 培訓＋交流＋測試過程中自學

個人覺得，一個高效的測試流程應該如下：

a.花幾個小時至多半天時間快速閱讀瀏覽軟件說明書、設計文檔；

這個階段要讓腦子里面形成對軟件的整體印象感，能夠讓自己把握全局，因此，測試負責人安排時間看文檔時，決不能忽視它的重要性，否則就會出現后續階段磕磕碰碰的情況。注重速讀，把握軟件說明，忽略具體的數據庫設計、功能點設計、計算、規則和輔助工具（相關軟件）說明文檔，囫圇吞棗的方法在這里就顯得很有效。

如果項目時間緊或沒有文檔，這個步驟所做的事可以在下面完成。

b.利用培訓時間消化吸收的知識

c.軟件上手

幾個小時至多半天時間，熟悉軟件框架和基本功能，不要求所有功能都會操作，自己負責的模塊可以多側重一些。

d.細測

主要癥對計劃中安排給自己做的模塊，這時就要相對放慢節奏，每一步操作、每個對話框（操作界面）都要深究，別放過任何情況。這時會遇到一些錯誤或不理解的地方，明顯的如報錯就提到開發過程論壇，不明顯的就先記下來，等這個功能點測完再回頭去看，你會發現：

50％的問題可以自己分析出來和解決，有的問題不是問題，只是開始還沒有完全理解。阿豬工作守則第五條：軟件不是一次能測透的Rome is not built in one day.工期、人力、環境資料等，都制約著測試的深度和廣度，因為不要期望一次能完全把握某個軟件。

綜合測試的優勢在于，我們負責公司產品的把關，而項目由產品延伸而來；測試產品會不斷出新的版本，一次沒有理解，可以在下一次中彌補，溫故而知新。

一口吃不成一個胖子，看我這么瘦又這么能吃就知道了^^

要結合自己的實際情況決定本次測試的深度，不要看著別人進度快了就打亂自己的節奏，只要安排合理，應該按照計劃來。特別忌諱認為自己這塊沒問題了就馬上去看看別人負責的功能，期望全能。這樣一般來說除了ljl這種全能性人物外都會造成最后自己的問題留了一堆，別人的也沒搞懂。

新人特別注意，踏踏實實的搞懂每個自己負責的模塊，打陣地站，這種方法很有效。評價自己是否可以轉入下個模塊的幾個因素：自我提問與別人提問、測試進度

如果大多數相關人員（主要是測試負責人、其他部分相關測試人員特別是開發組集成測試人員和技術支持人員）對于自己負責模塊的問題都能解答，搞定！NEXT-->轉入下個模塊。

否則，還是再回頭想想思路和遺漏的地方。當然，要綜合考慮測試進度。請組長對自己提幾個軟件的問題，他會很樂意的。

e.小結

一個階段就進行一次小結，這個小結可以是書面的，比如測試問題記錄、測試用例補充、測試模塊設計等，但大多是自己分析，為了方便接下來模塊的測試.f.性能測試

性能測試不僅是測試性能，同時也加深自己對軟件應用的理解，因為性能測試往往和實際應用或用戶需求結合的很緊密，避免造成軟件功能都會用，但不知用來干麻的尷尬情況。g.安裝盤測試

安裝盤程序測試，簡單過一下軟件功能有無錯誤。

安裝盤程序文件、庫文件、組件等的完整性、正確性，這個非常重要，要不返工就浪費時間了。這個階段要積極與開發負責人和GJ溝通，確保最后的勝利。

h.測試總結

測試接近尾聲，總結自己對軟件的掌握情況，得出測試結論、歸納測試方法、提出修改建議，為軟件以后版本的修改提供依據，也為以后再測類似軟件提供捷徑。

5.小結

? 用戶用軟件，測試測軟件

培訓時多想多問?

好記性不如爛筆頭?

帶著問題去測試，在測試中解決問題?

? 先做事，后學習，爭取雙贏

軟件不是一次能測透的?

第三篇：測試工作經驗總結

測試工作經驗總結

功能測試最重要的是理解業務和需求。知道系統要實現什么功能，業務流程是怎樣的，然后就可以根據需求編寫測試計劃和測試用例了。測試書籍上介紹常用的編寫測試用例的方法有：等價類、邊界值、因果圖、判定表等，在實際工作中，我使用較多的有等價類、邊界值、場景法和錯誤猜測法。在這里需要提一點，將測試用例按測試目的進行分類，比如用戶界面、功能點、業務場景等，會讓測試用例的結構看起來更清晰，執行測試用例的效率也更高。

要做好功能測試，還需要對整個系統的數據庫結構比較清楚，每個功能點涉及哪些數據表，對數據的操作方式是怎樣的。這樣就不單從前臺頁面來進行測試，通過對數據庫中數據的驗證，可以發現隱藏的一些bug。比如庫表沒有進行關聯刪除，從前臺頁面是看不出來的，但實際可能導致程序出現問題。對一些比較復雜的組合查詢或數據排序，也可以自己編寫sql語句對結果進行驗證。

了解程序的框架結構和一些開發知識也有助于更好地測試程序和定位錯誤。

測試用例的編寫經驗步驟和數據的分離

將輸入的各種數據已參數的形式表達在操作步驟中，而不需要為每一種輸入數據創建一個測試用例。

例如：atm存款

好的測試用例，在執行的步驟(Step)的表達上應該是盡可能和數據相分離。舉例來講，有一個ATM機取款的功能，可能有以下幾個場景：

1.密碼正確的登錄

2.密碼錯誤的登錄

3.密碼輸入三次錯誤，卡被鎖定

4.取少于余額的款項

5.嘗試取大于余額的款項

6.嘗試取等于余額的款項(考慮手續費)

6.取款額度大于當次的限制

7.取款額度大于當天的限制

7.取款次數大于限制次數

等等

不管你用什么用例設計的方法論來做指導，作為這個簡單的例子，有經驗的人都應該能看出，此處的很多步驟是可以重用的，總結下來如下(此處只列出了操作的步驟，略去了系統的交互中的反饋結果)：

1.插入卡->A:輸入密碼->B:按“確定”鍵->重復A-B

2.A:選擇取款功能->B:填寫取款金額->C:點擊“確定取款”的按鈕->D:取現金->重復A-D

因此，我們只需要寫出兩套比較完整的步驟，將密碼和取款金額多數字用參數來表達即可。這樣是不是簡單了很多呢?單獨的測試基礎數據準備工作

將測試基礎數據提前準備好，寫到你單獨的測試數據準備文檔中，而不是分散到 所有使用到它的case中才去描述。測試用例的前后置條件

除了第二點中談到的數據需要準備外，在測試用例這個Level，必須有一些條件滿足，您才能開始執行它。集中的把這些步驟整理成一個相對獨立的操作單元，具體用例中只要引用就可以了，這樣會便于對用例的理解和在多處復用。

順便說一下，對于一些類似軟件運行環境的條件，比如安裝和配置測試中，需要3種操作系統和3種瀏覽器的組合等，我們可以把他放在Test Set這個Level上來，不用寫多個用例，只是在測試計劃和執行的管理系統中作為測試集的一個環境參數，恰當地表達出來就可以。

第四篇：手機測試經驗總結

手機測試經驗總結

VPM主要是激勵團隊成員測試和學習，而不是自己去執行用例。當被委派為一個項目的測試經理時，VPM應該清楚項目計劃和轉折點、軟件發布時間表、產品定義特征列表。

1、作為VPM應具備以下幾方面能力：

（1）、用不同的方式看待問題

（2）、制定計劃，滿足項目上市時間

（3）、依據質量、時間、成本對PR進行判斷和決定

（4）、增進溝通，總結不同項目的經驗

（5）、和團隊的密切合作

2、測試工作點：

（1）、測試軟件機制

（2）、分析問題

（3）、對產品進行認證并得到相應證書

（4）、評估對于返修率、最終用戶和運營商抱怨的影響

若做歐洲市場的產品，一定要做CE認證。FCC認證在Latam市場是必須的，CTA認證在中國是必須的。

一、相關測試知識學習

1、軟件測試包括測試計劃、測試設計、測試執行、測試評估這幾個階段；

測試計劃：

了解軟件當前狀態及客戶對軟件的需求；

了解產品規格書：按鍵定義及菜單樹；

管控和跟催軟件方案商的版本發布時間；

測試設計：根據客戶需求和產品規格說明書來編寫測試用例；

測試執行：測試策略包括基本功能測試、UI測試、沖突測試、壓力測試、兼容性測試、驗收測試

測試評估：進行三次全面測試，由方案商發出軟件和報告，TMC和SZ Team

同時測試并反饋給方案商，如此反復數次，方案商改善結果并商討最終結論。

2、場測

在硬件成熟、軟件基本成熟的情況下做場地測試，主要測試這幾項：尋網時間、呼通率數據、通話質量、Wap測試、FM測試、信息、緊急呼叫、基本功能測試。

3、說明書測試

驗證說明書基本功能是否正確，是否清晰易懂、排版規范、無錯別字等。

4、認證分類

按照銷售地區分為國內認證和國外認證，國內認證是CTA認證，國外認證是CE認證和FCC認證。CTA認證需要拿到國家無委頒發的入網證書、受理中心頒發的許可證書、3C認證頒發的3C證書。

第五篇：軟件測試經驗總結

軟件生命周期(SDLC)的六個階段

1、問題的定義及規劃

此階段是軟件開發方與需求方共同討論，主要確定軟件的開發目標及其可行性。

2、需求分析

在確定軟件開發可行的情況下，對軟件需要實現的各個功能進行詳細分析。需求分析階段是一個很重要的階段，這一階段做得好，將為整個軟件開發項目的成功打下良好的基礎。“唯一不變的是變化本身。”，同樣需求也是在整個軟件開發過程中不斷變化和深入的，因此我們必須制定需求變更計劃來應付這種變化，以保護整個項目的順利進行。

3、軟件設計

此階段主要根據需求分析的結果，對整個軟件系統進行設計，如系統框架設計，數據庫設計等等。軟件設計一般分為總體設計和詳細設計。好的軟件設計將為軟件程序編寫打下良好的基礎。

4、程序編碼

此階段是將軟件設計的結果轉換成計算機可運行的程序代碼。在程序編碼中必須要制定統一，符合標準的編寫規范。以保證程序的可讀性，易維護性，提高程序的運行效率。

5、軟件測試

在軟件設計完成后要經過嚴密的測試，以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試，以減少測試的隨意性。

6、運行維護

軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投入使用后，由于多方面的原因，軟件不能繼續適應用戶的要求。要延續軟件的使用壽命，就必須對軟件進行維護。軟件的維護包括糾錯性維護和改進性維護兩個方面。

2、軟件生命周期模型

從概念提出的那一刻開始，軟件產品就進入了軟件生命周期。在經歷需求、分析、設計、實現、部署后，軟件將被使用并進入維護階段，直到最后由于缺少維護費用而逐漸消亡。這樣的一個過程，稱為“生命周期模型”（Life Cycle Model）。

典型的幾種生命周期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型的特點（文檔是主體），很多的問題在最后才會暴露出來。迭代模型比瀑布模型問題暴露的要早；快速原型法比瀑布模型直觀。

3.軟件測試概念

廣義概念：指軟件生存周期中所有的檢查、評審和確認工作，其中包括了對分析、設計階段，以及完成開發后維護階段的各類文檔、代碼的審查和確認

狹義概念：識別軟件缺陷的過程，即實際結果與預期結果的不一致

4.軟件測試目的測試的目的就是發現軟件中的各種缺陷

測試只能證明軟件存在缺陷，不能證明軟件不存在缺陷

測試可以使軟件中缺陷降低到一定程度，而不是徹底消滅

以較少的用例、時間和人力找出軟件中的各種錯誤和缺陷，以確保軟件的質量

5．軟件測試原則

Good-enough: 一種權衡投入/產出比的原則

保證測試的覆蓋程度，但窮舉測試是不可能的所有的測試都應追溯到用戶需求

越早測試越好，測試過程與開發過程應是相結合的測試的規模由小而大，從單元測試到系統測試

為了盡可能地發現錯誤，應該由獨立的第三方來測試

不能為了便于測試擅自修改程序

既應該測試軟件該做什么也應該測試軟件不該做什么

6．軟件測試的的重點

測試用例的設計

測試用例的設計是整個軟件測試工作的核心

測試用例反映對被測對象的質量要求，決定對測試對象的質量評估

測試工作的管理

尤其是對包含多個子系統的大型軟件系統，其測試工作涉及大量人力和物力，有效的測試工作管理是保證有效測試工作的必要前提

測試環境的建立

測試環境應該與實際測試環境一致

7．黑盒測試

什么是黑盒測試

又稱功能測試或數據驅動測試，是針對軟件的功能需求/實現進行測試，通過測試來檢測每個功能是否符合需求，不考慮程序內部的邏輯結構

黑盒測試方法

功能劃分

等價類劃分

邊界值分析

因果圖

錯誤推測等

8．什么是白盒測試

白盒測試也稱結構測試或邏輯驅動測試，必須知道軟件內部工作過程，通過測試來檢測軟件內部是否按照需求、設計正常運行

白盒測試的主要方法

對應于程序的一些主要結構：語句、分支、邏輯路徑、變量；白盒測試的主要方法是： 語句覆蓋方法

分支覆蓋方法

邏輯覆蓋方法

什么是動態測試

動態測試需要在開發/測試環境或實際運行環境中運行軟件，并使用測試用例去查找軟件缺陷；動態測試包括功能確認與接口測試、覆蓋率分析、性能分析、內存分析等

10.什么是靜態測試

靜態測試不實際運行軟件，主要是對軟件的編程格式、結構等方面進行評估.靜態測試包括代碼檢查、程序結構分析、代碼質量度量等。它可以由人工進行，也可以借助軟件工具自動進行

11.手工測試和自動測試

a.手工測試缺點在于測試工作量大，重復多，回歸測試難以實現

b.自動測試利用軟件測試工具自動實現全部或部分測試工作：管理、設計、執行和報告；節省大量的測試開銷，并能夠完成一些手工測試無法實現的測試

手工完成測試的全部過程無法保證測試的科學性與嚴密性:

修改的缺陷越多，回歸測試越困難

沒有人能向決策層提供精確的數據以度量當前的工作進度及工作效率

反復測試帶來的倦怠情緒及其他人為因素使得測試標準前后不一

測試花費的時間越長，測試的嚴格性也就越低

自動測試將測試人員從反復、煩雜的測試執行中解放出來，用更多的時間進行測試設計和結果分析

軟件測試不可能完全自動化

不能完成所有手工測試任務

無創造性且靈活性差，不能改進測試的有效性

過程中可能會遇到許多意想不到的問題，特別是當軟件不穩定時

測試腳本的維護高

12.測試流程

單元測試

集成測試

系統測試

用戶驗收測試

回歸測試

確認測試報告

13.單元測試

完成對最小的軟件設計單元—模塊的驗證工作

目標是確保模塊被正確地編碼

使用過程設計描述作為指南，對重要的控制路徑進行測試以發現模塊內的錯誤

通常情況下是面向白盒的對代碼風格和規則、程序設計和結構、業務邏輯等進行靜態測試，及早地發現和解決不易顯現的錯誤

單元測試的內容

接口測試

內部數據結構

全局數據結構

邊界

語句覆蓋，錯誤路徑

14.集成測試

通過測試發現與模塊接口有關的問題

目標是把通過了單元測試的模塊拿來，構造一個在設計中所描述的程序結構

應當避免一次性的集成（除非軟件規模很小），而采用增量集成集成測試主要內容

API(Application Programming Interface,應用程序編程接口)

API/參數組合15．系統測試

根據軟件需求規范的要求進行系統測試，確認系統滿足需求的要求

系統測試人員相當于用戶代言人

在需求分析階段要確定軟件的可測性，保證有效完成系統測試工作

系統測試主要內容

所有功能需求得到滿足

所有性能需求得到滿足

其他需求（例如安全性、容錯性、兼容性等）得到滿足

16.用戶驗收/確認測試

Alpha測試

是由用戶在開發者的場所來進行的，Alpha測試是在一個受控的環境中進行的Beta測試

由軟件的最終用戶在一個或多個用戶場所來進行的，開發者通常不在現場，用戶記錄測試中遇到的問題并報告給開發者

17．壓力測試VS性能測試

性能測試的目的不是去找bugs,而是排除系統的瓶頸，以及為以后的回歸測試建立一個基準。而性能測試的操作，實際上就是一個非常小心受控的測量分析過程。在理想的情況下，被測軟件在這個時候已經是足夠穩定了

性能測試是為了檢查系統的反映，運行速度等性能指標，他的前提是要求在一定負載下，如檢查一個網站在100人同時在線的情況下的性能指標，每個用戶是否都還可以正常的完成操作等。

概括就是：在不同負載下（負載一定）時，通過一些系統參數（如反應時間等）檢查系統的運行情況；

壓力測試是為了發現系統能支持的最大負載，他的前提是要求系統性能處在可以接受的范圍內，比如經常規定的葉面3秒鐘內響應；概括就是：在性能可以接受的前提下，測試系統可以支持的最大負載。

舉例說明：針對一個網站進行測試，模擬10到50個用戶就是在進行常規性能測試，用戶增加到1000乃至上萬就變成了壓力/負載測試。如果同時對系統進行大量的數據查詢操作，就包含了強度測試。

18.主流測試工具的測試流程

========winrunner啟動時選擇要加載的插件進行一些設置（如錄制模式等）識別應用程序的GUI，即創建map(就是學習被測試軟件的界面）建立測試腳本（錄制及編寫）對腳本除錯及調試（保證能夠運行完）插入各種檢查點（圖片，文字，控件等）在新版應用程序中執行測試腳本分析結果，回報缺陷

=========quicktestpro========準備錄制

打開你要對其進行測試的應用程序，并檢查QuickTest中的各項設置是否適合當前的要求。2 進行錄制

打開QuickTest的錄制功能，按測試用例中的描述，操作被測試應用程序。編輯測試腳本

通過加入檢測點、參數化測試，以及添加分支、循環等控制語句，來增強測試腳本的功能，使將來的回歸測試真正能夠自動化。調試腳本

調試腳本，檢查腳本是否存在錯誤。在回歸測試中運行測試

在對應用程序的回歸測試中，通過QuickTest回放對應用程序的操作，檢驗軟件正確性，實現測試的自動化進行。分析結果，報告問題

查看QuickTest記錄的運行結果，記錄問題，報告測試結果。

＝＝＝＝TestDirect============

安裝好后，先進入站點管理創建域及工程添加用戶編輯licenses及本服務器編輯數據庫

－－TD選擇新建的工程進行定制(列表，用戶，組，版本等)在require中增加需求把需求轉化為plan在testlab中由計劃新建測試具體用例與執行發現bug，在defect中提交bug

（每一部分都可以相對獨立地使用）

======loadrunner制定負載測試計劃

(分析應用程序，確定測試目標，計劃怎樣執行LoadRunner）開發測試腳本

（錄制基本的用戶腳本，完善測試腳本）創建運行場景

（選擇場景類型為Manual Scenario，選擇場景類型，理解各種類型，場景的類型轉化）監視場景（MEMORY 相關，PROCESSOR相關，網絡吞量以及帶寬，磁盤相關，WEB應用程

序，IIS5.0，SQL SERVER，NETWORK DELAY等)

分析測試結果

7(分析實時監視圖表,分析事務的響應時間,分解頁面,確定WEBSERVER的問題,其他有

用的功能)