6年測試工作的思考 轉
前言
在公司已經幹了6年的測試了，幹測試經理也5年了。眼看就要離開奮戰了6年的崗位，還真有點兒捨不得。但沒辦法，該離開的時候就要離開，光傷感是沒有用的。正好趁此機會把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對自己工作的回顧。由於時間倉促基本上是想到什麼些什麼，有點兒亂，也請大家多多擔待了。只要還有些人能從中找到些兒同感，或從中得到一些幫助，一些經驗，我就知足了。
什麼是測試
首先我要談談什麼是測試。相信好多測試人員跟我一樣，來公司之前也沒有從事過任何測試工作。對於測試都是從零開始的。也有好多人跟我一樣，從各種書上或是培訓中得到過有關測試的各種定義。但不知道大家有沒有淨下心思考一下。什麼是測試。在公司公司測試工作的定義是什麼，測試的工作範圍是什麼。
測試的定義根據測試技術的發展，歷經了3個主要的階段。第一個階段，認爲測試就是找產品中的bug。第二個階段，除了找bug以外，又增加測試是對軟件質量的度量這一概念。第三個階段，明確了測試是指爲了度量和提高被測試軟件的質量，對測試件進行工程設計，使用和維護的併發生命週期。注意其中提高的測試件，其主要是與軟件這個詞進行對應。明確測試也是一種開發過程。他的工作成果就是測試件，好像平時我們所謂的測試案例、測試腳本等等都可以稱爲測試件。然後使用測試件去度量和提高被測試軟件的質量。
目前，在中國大部分軟件企業，尤其是中小型的軟件企業還停留在第一階段。我個人覺得公司稍微好一點兒，處於一、二階段之間。因爲我們平時做的最多的一件事，還是找bug。至於測試案例和測試腳本等等，只佔用工作量的很小一部分。而且我看不到大家在平時的測試工作中是完全依據測試案例進行測試的。目前測試案例等工作更多的成爲了一種形式上的產物。從有些部分所有產品的測試案例在一個下午就能評審完就能看得出來。
說到這裏順便在談一句測試計劃。目前的測試計劃是作爲產品計劃的一部分。先明確大概發版時間，然後是各個階段的里程碑，其中提交集成的里程碑是死的。開發需要的時間就是那麼多，剩下倒推的時間就是測試的時間。這樣定出的計劃是否能夠起到計劃的作用就不好說了。現在的計劃更多的是羅列聯調測試的各種內容，至於時間，不說也罷。所以從中也可以開出公司的測試也就停留在一、二階段之間。
明確了公司測試的定義（個人理解），也就不難理解公司給測試人員的定位了。在測試人員中經常流傳的一種說法就是國外測試人員的地位多麼多麼的高，開發就是coding。咱們公司開發比測試多拿多少多少，測試人員地位是開發序列中最低的。大家也要看看人家公司測試人員的素質，測試在開發過程中的重要性。再看看自己所從事的工作，就是找軟件的bug。當然我也個人認爲有經驗極其豐富的測試人員對產品的貢獻比開發和需求大。明確了這些，心裏也就能少點兒不平衡感。
測試方法的思考
說完個人對測試含義的理解，再說說個人對測試方案的一些思考。
個人認爲在公司6年，測試方法沒有什麼提高。主要還是以黑盒測試爲主。中間也曾經引入過各種各種工具，但測試人員真正用起來的也就是robot。而且robot主要是進行迴歸測試，再加上一些人並沒有真正認識到其價值，應用範圍也極其有限。對整體測試效率的提升影響不大。所以目前的測試方案還主要是以需求爲依據的黑盒測試。至於什麼極限值了，成對測試法等等，都是建立在黑盒測試的基礎上，而且從我一來公司就有相應的測試項目，只不過沒有明確概念而已。
另一個說個人覺得6年來公司測試方法沒有什麼提高的原因是，6年前測試是以人爲主，靠得是測試人員的經驗，對產品的熟悉程度，對業務的理解程度。6年後測試還是以人爲主，人就是測試的主體，產品質量的保證。還沒有過渡到測試案例就是測試的主體，測試案例的完整性是產品質量的保證。只要測試還是以人爲本，我覺得測試的效率就不會有太大提高，產品質量的信心來源也是對相關測試人員的信任。
我個人覺得以黑盒測試爲主要的測試方法沒錯，而且也比較符合目前公司的測試現狀。但一定要注意各種經驗的總結、積累，更重要的是共享。雖然目前測試案例在測試工作過程中的地位不重要，但其畢竟是編寫者的經驗積累。彙總起來也是一筆可觀的財富。可現在如果有人問我850的測試方案在那裏，其中還有多大比例能夠用在現在的產品中，在現在的測試工作中有多少以前的案例能夠複用。其他產品中的測試案例中有多少是關於接口功能，有多少我可以借鑑。我不知道，這也是自己工作不到位的地方。所以我要說的作爲黑盒測試爲主要的測試方法，一定要注意測試經驗的總結和共享。
而且我認爲一個人如果黑盒測試能做到位，做到最後培養的是一種測試的感覺。測到最後，產品你一看就能知道那裏可能有問題，那裏應該沒什麼問題。這樣有重點地投入測試力量可以收到事半功倍的效果。可這是需要大量測試經驗的積累的，不是我告訴你，你就知道的能力。在此前提上加強測試人員之間的橫向溝通，形成經驗貢獻。可以較快的培養測試人員的測試感覺。
最爲測試經驗積累的另一個重要方法就是加強對測試案例的要求和管理。每版測試案例不僅要包括新增功能，還需要包括上一版本中繼承的案例，修改或刪除上版案例中變更的內容。從而形成一份完整的關於產品所有功能點、接口、升級、年結等等各方面的測試案例。真正做到測試案例是測試的主體，從而提高測試效率，提高產品質量。
測試工具的概念和作用
測試工具，什麼叫測試工具。我認爲任何能提高你測試效率的工具都可以稱之爲測試工具。不僅僅指robot或是loadrunner這類專門的測試工具，也不僅僅指使用各種編程工具編寫的測試工具。像總賬工具、eai等，即使只是幫我們導入一些常用檔案，也可以節約我們的測試時間也可以稱之爲測試工具。
我個人現在公司測試在測試工具開發上還很不足。在公司裏一提起測試工具，大家第一個想到的可能就是robot。即使是robot應用的也不夠深入。大家經常認爲robot主要錄製gui的腳本，跟產品界面聯繫緊密。每次回放成功率不高，各個版本間腳本複用率也較低。而且每次總是以各種理由將腳本錄製放到最後，經常就不了了之了。最後階段的測試任務實在太緊。我想說的是robot的應用雖然有各種各樣的侷限性，但其畢竟提高了測試效率。比如說安裝盤驗證，使用robot驗證，每天都可以節約一半以上的驗證時間，這就是效率。認識了它的好處，才能想盡辦法解決或避免在robot使用中的各種問題。以前同事有一套robot腳本規範就很好，使用後不僅提高了回放成功率，而且回放中斷後，繼續回放也變得很容易。所以說使用robot後，想100%回放成功不可能，想不再進行腳本的調試也不可能。認識這兩個問題後，就需要加強robot使用經驗的總結和共享，有針對性地加強robot使用問題的研究，每版測試開始時針對上版robot腳本的複用問題進行研究。這樣才能用好它，真得使之成爲一個工具，而不是一項任務。
一種工具也不是萬能，有許多針對產品特性的測試工具。只能自己開發，大家應該積極提需求。凡是認爲有可能提高測試效率的工具需求都可以提。能從網上找到現成的工具解決需求更好。不能，如果是普遍性的需求，可以專門進行開發。因爲咱們產品的特性，每版間測試工具的複用度很大。從長遠看就是節約開發成本，縮短開發週期。
在現階段加大測試工具的適用範圍和力度，用好各種測試工具，可能是提高整體測試效率最快最好的方法。但一定要加大推廣的力度。否則有了好的工具，沒人用或用不起來也是沒用。
如何看待各種規則和執行
可能大家覺得平時開發過程中有好多規則、制度。這些除了一些自己公司內根據各種情況制定的外，大部分都是跟cmm體系相關的一些規則。可以說是已經被許多軟件公司驗證過，可以提高開發和測試效率的規則。但好多人覺得起沒有什麼用，就是在浪費時間。總是以一種完成任務或是應付差事的心情去做。我覺得大家之所以覺得其沒用，恰恰就是由於你去做這件事的動機不對。總以應付差事的心情去做，你就不可能真正理解這麼做的目的，這樣做能給你帶來什麼好處，你從中會得到什麼收益。所以我個人認爲，既然有規則，不管是公司自創的或是借鑑其他標準，都是爲了解決開發過程中的問題，爲了提高開發的效率，保證產品質量。也許這些規則中有這樣那樣的不合理，但只有你認真地去做了，才能發現其中的不妥之處，才能改進，才能更有助於你的工作。
執行也是我覺得在工作中需要進一步加強的環節。許多規則就是因爲執行力度不足，才容易讓一些人找到空子，應付了事。但怎樣加強執行力度，還是一個需要大家一起進行探討的問題。
前言
在公司已經幹了6年的測試了，幹測試經理也5年了。眼看就要離開奮戰了6年的崗位，還真有點兒捨不得。但沒辦法，該離開的時候就要離開，光傷感是沒有用的。正好趁此機會把自己6年來一直想寫但沒寫的東西寫出來。這篇文件純粹是對自己工作的回顧。由於時間倉促基本上是想到什麼些什麼，有點兒亂，也請大家多多擔待了。只要還有些人能從中找到些兒同感，或從中得到一些幫助，一些經驗，我就知足了。
什麼是測試
首先我要談談什麼是測試。相信好多測試人員跟我一樣，來公司之前也沒有從事過任何測試工作。對於測試都是從零開始的。也有好多人跟我一樣，從各種書上或是培訓中得到過有關測試的各種定義。但不知道大家有沒有淨下心思考一下。什麼是測試。在公司公司測試工作的定義是什麼，測試的工作範圍是什麼。
測試的定義根據測試技術的發展，歷經了3個主要的階段。第一個階段，認爲測試就是找產品中的bug。第二個階段，除了找bug以外，又增加測試是對軟件質量的度量這一概念。第三個階段，明確了測試是指爲了度量和提高被測試軟件的質量，對測試件進行工程設計，使用和維護的併發生命週期。注意其中提高的測試件，其主要是與軟件這個詞進行對應。明確測試也是一種開發過程。他的工作成果就是測試件，好像平時我們所謂的測試案例、測試腳本等等都可以稱爲測試件。然後使用測試件去度量和提高被測試軟件的質量。
目前，在中國大部分軟件企業，尤其是中小型的軟件企業還停留在第一階段。我個人覺得公司稍微好一點兒，處於一、二階段之間。因爲我們平時做的最多的一件事，還是找bug。至於測試案例和測試腳本等等，只佔用工作量的很小一部分。而且我看不到大家在平時的測試工作中是完全依據測試案例進行測試的。目前測試案例等工作更多的成爲了一種形式上的產物。從有些部分所有產品的測試案例在一個下午就能評審完就能看得出來。
說到這裏順便在談一句測試計劃。目前的測試計劃是作爲產品計劃的一部分。先明確大概發版時間，然後是各個階段的里程碑，其中提交集成的里程碑是死的。開發需要的時間就是那麼多，剩下倒推的時間就是測試的時間。這樣定出的計劃是否能夠起到計劃的作用就不好說了。現在的計劃更多的是羅列聯調測試的各種內容，至於時間，不說也罷。所以從中也可以開出公司的測試也就停留在一、二階段之間。
明確了公司測試的定義（個人理解），也就不難理解公司給測試人員的定位了。在測試人員中經常流傳的一種說法就是國外測試人員的地位多麼多麼的高，開發就是coding。咱們公司開發比測試多拿多少多少，測試人員地位是開發序列中最低的。大家也要看看人家公司測試人員的素質，測試在開發過程中的重要性。再看看自己所從事的工作，就是找軟件的bug。當然我也個人認爲有經驗極其豐富的測試人員對產品的貢獻比開發和需求大。明確了這些，心裏也就能少點兒不平衡感。
測試方法的思考
說完個人對測試含義的理解，再說說個人對測試方案的一些思考。
個人認爲在公司6年，測試方法沒有什麼提高。主要還是以黑盒測試爲主。中間也曾經引入過各種各種工具，但測試人員真正用起來的也就是robot。而且robot主要是進行迴歸測試，再加上一些人並沒有真正認識到其價值，應用範圍也極其有限。對整體測試效率的提升影響不大。所以目前的測試方案還主要是以需求爲依據的黑盒測試。至於什麼極限值了，成對測試法等等，都是建立在黑盒測試的基礎上，而且從我一來公司就有相應的測試項目，只不過沒有明確概念而已。
另一個說個人覺得6年來公司測試方法沒有什麼提高的原因是，6年前測試是以人爲主，靠得是測試人員的經驗，對產品的熟悉程度，對業務的理解程度。6年後測試還是以人爲主，人就是測試的主體，產品質量的保證。還沒有過渡到測試案例就是測試的主體，測試案例的完整性是產品質量的保證。只要測試還是以人爲本，我覺得測試的效率就不會有太大提高，產品質量的信心來源也是對相關測試人員的信任。
我個人覺得以黑盒測試爲主要的測試方法沒錯，而且也比較符合目前公司的測試現狀。但一定要注意各種經驗的總結、積累，更重要的是共享。雖然目前測試案例在測試工作過程中的地位不重要，但其畢竟是編寫者的經驗積累。彙總起來也是一筆可觀的財富。可現在如果有人問我850的測試方案在那裏，其中還有多大比例能夠用在現在的產品中，在現在的測試工作中有多少以前的案例能夠複用。其他產品中的測試案例中有多少是關於接口功能，有多少我可以借鑑。我不知道，這也是自己工作不到位的地方。所以我要說的作爲黑盒測試爲主要的測試方法，一定要注意測試經驗的總結和共享。
而且我認爲一個人如果黑盒測試能做到位，做到最後培養的是一種測試的感覺。測到最後，產品你一看就能知道那裏可能有問題，那裏應該沒什麼問題。這樣有重點地投入測試力量可以收到事半功倍的效果。可這是需要大量測試經驗的積累的，不是我告訴你，你就知道的能力。在此前提上加強測試人員之間的橫向溝通，形成經驗貢獻。可以較快的培養測試人員的測試感覺。
最爲測試經驗積累的另一個重要方法就是加強對測試案例的要求和管理。每版測試案例不僅要包括新增功能，還需要包括上一版本中繼承的案例，修改或刪除上版案例中變更的內容。從而形成一份完整的關於產品所有功能點、接口、升級、年結等等各方面的測試案例。真正做到測試案例是測試的主體，從而提高測試效率，提高產品質量。
測試工具的概念和作用
測試工具，什麼叫測試工具。我認爲任何能提高你測試效率的工具都可以稱之爲測試工具。不僅僅指robot或是loadrunner這類專門的測試工具，也不僅僅指使用各種編程工具編寫的測試工具。像總賬工具、eai等，即使只是幫我們導入一些常用檔案，也可以節約我們的測試時間也可以稱之爲測試工具。
我個人現在公司測試在測試工具開發上還很不足。在公司裏一提起測試工具，大家第一個想到的可能就是robot。即使是robot應用的也不夠深入。大家經常認爲robot主要錄製gui的腳本，跟產品界面聯繫緊密。每次回放成功率不高，各個版本間腳本複用率也較低。而且每次總是以各種理由將腳本錄製放到最後，經常就不了了之了。最後階段的測試任務實在太緊。我想說的是robot的應用雖然有各種各樣的侷限性，但其畢竟提高了測試效率。比如說安裝盤驗證，使用robot驗證，每天都可以節約一半以上的驗證時間，這就是效率。認識了它的好處，才能想盡辦法解決或避免在robot使用中的各種問題。以前同事有一套robot腳本規範就很好，使用後不僅提高了回放成功率，而且回放中斷後，繼續回放也變得很容易。所以說使用robot後，想100%回放成功不可能，想不再進行腳本的調試也不可能。認識這兩個問題後，就需要加強robot使用經驗的總結和共享，有針對性地加強robot使用問題的研究，每版測試開始時針對上版robot腳本的複用問題進行研究。這樣才能用好它，真得使之成爲一個工具，而不是一項任務。
一種工具也不是萬能，有許多針對產品特性的測試工具。只能自己開發，大家應該積極提需求。凡是認爲有可能提高測試效率的工具需求都可以提。能從網上找到現成的工具解決需求更好。不能，如果是普遍性的需求，可以專門進行開發。因爲咱們產品的特性，每版間測試工具的複用度很大。從長遠看就是節約開發成本，縮短開發週期。
在現階段加大測試工具的適用範圍和力度，用好各種測試工具，可能是提高整體測試效率最快最好的方法。但一定要加大推廣的力度。否則有了好的工具，沒人用或用不起來也是沒用。
如何看待各種規則和執行
可能大家覺得平時開發過程中有好多規則、制度。這些除了一些自己公司內根據各種情況制定的外，大部分都是跟cmm體系相關的一些規則。可以說是已經被許多軟件公司驗證過，可以提高開發和測試效率的規則。但好多人覺得起沒有什麼用，就是在浪費時間。總是以一種完成任務或是應付差事的心情去做。我覺得大家之所以覺得其沒用，恰恰就是由於你去做這件事的動機不對。總以應付差事的心情去做，你就不可能真正理解這麼做的目的，這樣做能給你帶來什麼好處，你從中會得到什麼收益。所以我個人認爲，既然有規則，不管是公司自創的或是借鑑其他標準，都是爲了解決開發過程中的問題，爲了提高開發的效率，保證產品質量。也許這些規則中有這樣那樣的不合理，但只有你認真地去做了，才能發現其中的不妥之處，才能改進，才能更有助於你的工作。
執行也是我覺得在工作中需要進一步加強的環節。許多規則就是因爲執行力度不足，才容易讓一些人找到空子，應付了事。但怎樣加強執行力度，還是一個需要大家一起進行探討的問題。