關於測試這東西，玩了四年，仍然沒有摸透它的脾氣。
有人說，測試是為了發現更多的缺陷，也有人說，測試是為了保證產品的質量。都沒錯啊，乙個是從職責的角度來看，乙個是從控制的角度來看。
測試，其實就是乙個驗證的過程，測試人員竭盡所能的折騰一套軟體，看它是否符合客戶要求的標準，是否能經得起折騰，藉以評價產品的***不好。不就是這樣嗎？：-）
常規的測試理論是遵循了v模型中的v&v過程，也就是validation and verification。validation是對客戶需求的驗證，比如通常所說的驗收測試、beta測試。verification指的是軟體過程中每一次確認活動，包括客戶需求確立以後的每一階段關鍵產物的評審與測試。
按照v模型的概念，我們將軟體過程分為了客戶需求、需求規格、概要設計、詳細設計、編碼、系統測試這幾個關鍵的階段。每乙個階段都會有相關的評審與測試，因此，以客戶需求為主要依據的測試，我們稱之為驗收測試，著重於使用者需求的驗證，通常由客戶來做；以需求規格為主要依據的測試，被稱為系統測試，著重於對產品綜合能力的驗證，通常由專業的測試人員來做；以概要設計為依據的測試叫做整合測試，著重於對各級別的介面所進行的驗證，通常會由編碼人員與測試人員一起完成；以詳細設計為依據的測試就成為了單元測試，著重於對**的最小級別進行驗證，通常由編碼人員實現。看到這樣的乙個規則，我們很容易理清，每乙個測試階段，所要測試的物件是不同的，而相應的依據一旦通過了評審，便可以著手進行該項測試的準備。
相對於之前的每乙個關鍵階段而言，測試階段的執行順序剛好相反。編碼階段只能執行單元測試，只有單元測試通過了，才可以對單元與單元之間進行整合，測試它們之間的介面，這被稱之為整合測試。當軟體所有的模組完成之後並且通過了整合測試，那麼就可以進入系統測試階段了。這個時候，測試人員摩拳擦掌，躍躍欲試，不找出bug不罷休。
然而，到底每乙個測試階段的測試工作是怎樣開展的呢？這樣的乙個過程，我們稱之為測試管理過程。每乙個測試階段，都會包括測試計畫、測試設計、測試執行這三部分，有些人會把它劃分得更細，比如獲取測試需求、測試實施、搭建測試環境等。
測試計畫並不是單純的寫乙個時間表，它是當對應的作為測試依據的文件定格之後（通常我們叫做基線化）就開始做的，最主要的目的是要告訴你的專案組成員，你要做什麼（明確測試目的）？對什麼來做（明確測試物件及測試需求）？怎麼做（制定測試策略）？要使用什麼來做（確定測試資源）？何時做（安排測試進度）？需要注意跟控制什麼（估計測試風險，使用規避手段）？
測試設計是要在測試計畫通過了評審之後才做的，主要的產物是測試用例，是將你的測試策略公升級為詳細的步驟，對你確定的測試物件進行驗證，應該要出現的理想結果是什麼。當執行測試的時候，人們依據這份文件，會發現實際的結果與預期的不一樣，於是便把它判定為缺陷。輔助的測試設計產物還包括測試環境的搭建、測試指令碼、測試使用的資料等。關於測試指令碼，是要衡量開發成本與預期收益的，不可以為使用了自動化的測試就是測試高手，這是個極其嚴重的誤區。測試指令碼的目的是要提高你的測試效率，怎樣設計還是依賴於乙個人的測試水平，如果片面的追求程式設計技能，把這認為是測試技能的提高，那麼你不用做測試了，去做開發吧。在單元測試跟整合測試過程中會使用較多的測試指令碼，是因為這些**的復用率極高，幾乎編碼過程中的每天都會執行n遍。而系統測試階段，由於測試重點不同，測試指令碼的復用率也遠遠達不到前兩個階段的效果，自然就更要慎重了。要知道，乙個常規的80/20法則，描述了乙個事實，就是80%的缺陷是手工測試出來的，只有20%的缺陷是使用自動化測試得到的。你花費了兩個月的時間去做了一套測試指令碼，卻只需要執行四五遍，發現的缺陷也寥寥可數，畢竟測試中的很多驗證點是程式無法實現的。那麼，如果使用兩個月的人工測試，收到的效果會是天壤之別。你會選擇哪一種方式呢？
測試執行是在必備的**實現之後才可以做的。拿著文件做設計，卻不在真正的環境中執行，就變成了紙上談兵的趙括。因此，你可以說測試設計是最重要的，我毫不反對，但是，測試執行卻是最關鍵的。只有這個時候，你才能了解軟體的質量如何，存在多少問題，需要怎樣修復。在這時，才是我們經常說的測試階段(單元測試階、整合測試階段、系統測試階段)。測試階段中，缺陷管理變成了重中之重，缺陷的追蹤與控制成為彌補軟體缺陷、控制產品質量的最直接有效的手段。
在測試的每個環節都會產生相應的文件：測試計畫、測試用例、測試報告，這三份文件成為最基本的資源。乙份文件的好壞，關鍵不在於文筆怎樣，而是能否清晰的表達你的意圖，並讓所有的人員能夠了解，使得你所做的工作是可見可控的，不會出現較大的偏差。因此，寫文件不是隨便完成任務那麼簡單，它融入了你全部的思想、你的技能、你的溝通水準，是站在一定的高度上來完成的。即使你是個捉蟲能手，但你不會寫文件，不會把自己的思路清晰的表達出來，這至少能表明你不是個優秀的測試人員。
我絕對不贊同乙個測試新手去寫什麼測試計畫、測試用例。他能把測試報告、缺陷描述寫清楚就不錯了。試想，誰也不是天生的文件高手，必然是經過千錘百鍊、日益積累而成的。先要學會測試，能從測試中找到很多的缺陷，知道測試應該是怎樣一種過程，再開始進行文件的修煉。
我並不認為乙個測試人員一開始寫測試計畫/用例的時候，就能夠根據使用者需求/需求規格/概要設計/模組設計這類的文件，寫出好的東東。畢竟在國內，大多數技術類文件並不是很過關的。因此，我覺得要練習寫，就要從乙個你比較熟悉的已經成形的軟體開始練起。此時你不需要去假想乙個軟體應該是怎樣，而是針對乙個實際的軟體開始操作，記錄你的操作跟你的結果，把它變為你的測試用例。測試計畫更不消說，自然是要在你熟悉這套軟體，知道怎樣去測它的基礎上來完成的。
經過了這樣乙個鍛造，你會明白要怎樣展現自己的思路，在新專案中，根據分析或設計文件，你只要考慮它具體實現的是什麼，然後根據你的測試思想，你的撰寫經驗，來完成乙份較高質量的測試文件。
雜談測試這東西
關於軟體測試這東西，玩了四年，仍然沒有摸透它的脾氣。有人說，軟體測試是為了發現更多的缺陷，也有人說，軟體測試是為了保證產品的質量。都沒錯啊，乙個是從職責的角度來看，乙個是從控制的角度來看。軟體測試，其實就是乙個驗證的過程，軟體測試人員竭盡所能的折騰一套軟體，看它是否符合客戶要求的標準，是否能經得起折...
雜談測試這東西
關於軟體測試這東西，玩了四年，仍然沒有摸透它的脾氣。有人說，軟體測試是為了發現更多的缺陷，也有人說，軟體測試是為了保證產品的質量。都沒錯啊，乙個是從職責的角度來看，乙個是從控制的角度來看。軟體測試，其實就是乙個驗證的過程，軟體測試人員竭盡所能的折騰一套軟體，看它是否符合客戶要求的標準，是否能經得起折...
組長這東西
我是這專案的組長,第一次幹這活,問題有是很正常滴.專案的每乙個階段,基本上是按軟體工程的意思來辦的,這也是為了公司的文件化管理做個開始.首先說分任務吧,分的不好下面又難完成,輕鬆了上面又不好交代,那完成的結果也沒有乙個標準 怎麼辦?好了,既然沒有標準,但問題總得解決吧,那就是溝通咯,這不 我的死肋就...