進到乙個新專案，作為測試人員應該都是想把測試做好，專案在符合客戶質量要求的情況下按時交付的吧。但往往都事與願違，造成這個結果的原因有很多很多。通過這段時間做自動化測試，站在自動化測試的角度看手工測試，以及排除其他部門的問題，單說測試自身的問題來和大家分析討論一下怎樣我能做到更好。
先說一下背景，我是中途進的專案，專案需要做自動化測試，依據是手工測試人員開發的用例。從測試用例和測試流程兩方面來進行闡述吧。
首先說說測試用例。當前大部分的專案一般都是任務重時間緊，往往為了能保證能把專案「做」完，擠壓了測試開發、執行和需求分析的時間。測試用例設計開發作為測試團隊主要的工作任務，其重要性僅次於需求分析。如果測試用例的質量出現問題會產生一連串的影響，比如不能讓新進開發團隊的人員了解系統、以手工用例為基礎的自動化測試開發人員無從下手或繁重的修改工作、最重要的是增加了回歸測試執行的時間及風險。
在測試用例開發上，比較常見的問題就是用例有量無質。
用例的數量上去了卻無質量可言，大量重複的又缺乏測試必要的用例。
做為測試團隊重要的輸出物之一，如果不能保證用例的質量那系統的質量又從何談起呢？測試用例的質量我覺得體現在以下兩個方面：
測試用例不夠詳盡、缺乏目的性、重複性高
測試用例的詳細程度是乙個相對的問題。太詳盡了使操作步驟過於繁瑣冗長，測試人員操作完之後無法對測試用例有乙個整體認識；過於簡約的用例同樣無法讓測試人員了解測試目的，應該如何操作。在我的想法中，乙個具有一定質量的測試用例應該經過多方面配合的，比如用例描述資訊、用例名稱及操作步驟等等。描述資訊中可以描述出測試用例是由誰、在和情況下、做了什麼事及最後的結果； 用例名稱顯示出是對哪個業務進行的正面/反面測試；如果說名稱和描述為輔助的資訊，那麼測試步驟無疑是在乙個相對比較重要的位置上了。測試步驟的**是什麼？是系統需求。那麼系統需求的好壞就決定了測試步驟的好壞。如果需求詳盡，簡潔省時的方法當然可以用直接引用的方式，這樣正確性有所保證也為開發其他用例節省了時間；相反的，需求不夠詳盡，是否應將測試步驟進行一定的擴充套件，避免操作步驟的混淆，讓對系統不熟悉的人盡快了解系統功能。在測試開發的迭代週期中，最常見的問題就是需求的更改，這個是無法避免的。那麼對於測試用例，我們如何應對這種變化呢？我想除了不要將用例中的期望結果過於詳細外，應當勤於進行用例的開發迭代以符合系統需求，關於這一點，我們稍後再說。
測試用例缺乏目的性、重複性高是造成用例數量直線上公升，質量直線下降的乙個重要因素。假設乙個使用者註冊的場景，使用者可通過不同的證件型別完成註冊，如何設計這個用例呢？我的想法是，對於註冊成功的預期結果，只安排乙個用例，在用例的前提條件或描述資訊中突出需通過不同證件型別引數進行測試。從開發人員的角度和2/8原則的角度講，他們的主要精力會放在將正常的註冊功能開發完成，即假定使用者輸入的值都是合法的。實際上，測試往往就是對那些無法順利完成功能的場景，輸入無效值或測試反面場景以覆蓋完全的測試場景。在設計用例時，就應當將更多的精力放在這些場景的設計上。有些人可能會說，如果將手工用例引數化，在執行用例的時候，不同的測試人員往往不會按照用例的描述，分不同的資料要求去執行，這個無法保證。從我的角度來說，一方面需要測試領導的信任，一方面也許要對測試人員進行監督。對同事信任，相信他們會進行全面的測試。對按用例要求進行測試的人員給予獎勵，對不能認真完成測試用例要求的測試人員實施懲罰，這樣鼓勵已經做好的人繼續保持，還沒做好的往好的目標前進。
2.
用例更新滯後
在軟體開發周期中會經過幾次迭代過程，每一次迭代都會經歷大小不同的需求變更、系統實現變化等等。在需求發生變化後，應及時更新測試用例，以保證測試用例適用於當前的系統實現，這樣才能保證回歸測試的執行是有效的，並節省下更多的人力物力到更容易發生錯誤的地方。除了新需求的增加、老需求的變更，實時的對測試用例進行重構也是必要的，如同對系統**進行重構一樣，這樣才能讓系統跑的更快更安全，以更少的測試用例覆蓋更多的功能點和業務規則。最初開發測試用例，由於對系統需求缺乏深入理解或開發時間緊，不能覆蓋全面的測試場景或者用例重複性較高，這都需要及時的通過測試用例的重構提高系統測試用例的有效性。我認為，應該盡量爭取在下乙個迭代週期結束前進行或完成之前乙個迭代週期中測試用例的重構。積壓的測試用例越多進行重構的難度越大，耗費的精力越多，風險也就越大。需求的遺忘、變更，需要修改的用例數量之大，加之有限的時間等等，都會給測試用例重構造成隱患，延誤回歸測試的進度。看著上千的測試用例，誰都會頭疼吧。說起來我們有幾千個用例測試系統可在真正執行時有多少是能發揮效果的呢？
其次再說說測試流程。最早接觸的是cmmi，現在慢慢的隨著客戶需求日新月異，加上新的流程概念的引入，越來越多的專案採用了敏捷開發的概念。就我對敏捷開發的認識，從形式上來說敏捷與cmmi的區別是，
注重敏捷的溝通
多於文件這些形式上的產物，當然敏捷開發不是簡簡單單注意溝通就可以的。對於剛剛引入敏捷概念的專案，團隊之間的契合度不高，理解不深，加之大家還沒有脫離cmmi的形式，導致專案流程既不敏捷，也不cmmi。說是cmmi可流程執行力度不夠，說敏捷溝通又不夠。我的理解，敏捷與cmmi在工作內容、職責上並無太大變化，不同的是需要加強團隊之間的溝通，任何的變化都應該是連環動起來的，而不是變化傳達到第乙個人就結束了，就像軍訓時的向右看齊，只有每乙個人都向右看，最後乙個人才有可能和第乙個人在乙個水平線上。在我經歷的幾個專案中，溝通不夠往往表現在幾個方面，專案資訊共享，包括技術的和業務的、需求變更、用例變更、開發進度等等。有多少會做到開發進度實時更新，更新了有多少人會去看，不如當面鑼對面鼓的說清楚。在變化快的情況下，過於依賴文件反而會讓大家對專案不甚了解或知之甚少。
敏捷強調溝通也是為了避免在文件的更新上各個環節出現之後。
這裡記錄了一些在專案中遇到的問題，希望可以給自己更多的思考，在以後自己的工作中可以避免，也是把一些問題拿出來和大家討論，希望集大家之廣議共同提高，有些說的不清楚，更像是抱怨別人的問題，可能因為自己的認識還不夠深刻吧，會在以後的時間中改進，多寫一些改進措施。
對於測試會有這樣的現象出現也不是測試單方面的責任，很有可能是需求沒有做好，或開發的問題。對於敏捷，我們應該想的更多做的更多，才能把專案做好。
更好的測試準則
1.測試名稱應該從使用者的角度來描述是什麼以及為什麼 核心思想是一名開發者應該能夠從測試名稱理解測試行為是什麼樣的。2.測試也是 愛他們吧 僅在產品 中做重構是不夠的。易於理解的測試更易於維護，而且後來的人也更容易弄清楚。我憎恨 憎恨長而複雜的測試。如果乙個測試的setup方法有30行，請將這些 放...
測試進度如何把控
遇到大的版本測試，測試週期比較長，很容易出現前面鬆懈 bug阻塞問題 環境問題導致測試進度慢，最終不能按時完成測試，或者後期時間緊張出現漏測的問題，如何解決這種問題呢 1 細化測試場景，讓用例覆蓋率更高，考慮測試用例的同時，需要準備的測試資料提前準備好 2 有整體的測試用例數量後，需要做好人員的分工...
測試如何把控專案
測試階段主要分為三個階段，測試前，測試中和測試後。1.測試前 1 測試前要先確定測試方案，比如有些場景的如何模擬，有些條件如何觸發，可以跟開發溝通下 2 資料準備，提前準備賬號或資料等。以及是否需要開發乙個測試小工具輔助測試等。3 再有可以評估下有哪些部分可以提前介入測試，能提前的盡量提前，為後面的...