沒有大綱和用例的測試

目前所在的公司，做測試的時候想要一個像樣的大綱或者用例是困難的，一般用例是沒有的（除非我自己加班加點的寫），大綱一般就把需求列表搞出來（還是為了所謂的驗收時用的，驗收時，讓用戶、領導啥的看著系統各功能操作一遍），剛來的時候，有項目喊我測試，直接扔給我一個需求列表（還是只說了功能名字那種），然后說 你照著這個把每個功能用一下就行了。

　　原來我的測試工作再他們眼里就是做這么小白的事情，怪不得工資低低呢。

　　不過，工作一半是為了賺錢。一半是豐富生活嘛。。所以該努力的還是要努力，不然只會對不起自己。

　　最近測一個網站的后臺管理，包括學生、老師、學校班級的信息處理，簡單的說就是增刪改。

　　因為是要測的時候才被通知有這個項目，而且這次也沒有需求（自然沒有需求大綱了），所以就完全盲測，讓我和開發方都沒有想到的是，發現了碩多錯誤，兩周都沒有結束“本應該簡單的工作”，另，更驗證了那句，錯誤出現多的地方，還隱藏著更多的錯誤！

　　這次工作讓我對沒有大綱和用例的測試重新審視了一下，優缺點可以列成下面這樣：

優點
　　這種工作方式這么不符合滿天飛的規范，為什么還有優點呢？因為存在即合理嘛?，F在很多項目，由于用戶、開發等種種原因，工期緊人手緊變化快，從實際角度來說根本無法按這規那范來做，但是負責的人還是希望能通過某種方式對系統進行測試，于是這種形式的“盲測”是必要的。
　　如果1不算是優點，那么這種方式的測試，隨叫隨到隨時開始、不需準備不耗費過多的項目時間，測試的人完全可以身兼數職增加人力利用，這應該算了吧？ 對于周期短的項目。
　　另外從私人角度講，這樣的測試工作很有彈性，你可以說一天就結束，也可以拖一個星期還說沒有完，想偷懶的人也大可放心的啥都不做，等時間到了交工就可以。
　　如果你能沒有文字也能有條理的進行測試并喜愛探索式的工作，那么這種方法還挺適合你，因為他會讓你感覺到喜悅和無約束，相反的寫出大量步驟重復的用例文檔反而讓人感覺不爽。
缺點
　　缺點多了去了！測試完全沒有計劃，無邊無界而且沒有什么可見性，測了哪些漏了哪些除了做的人知道外別人一概不知，如果測試者記性差的話，說不定完全不知道做了哪些方面的測試。
　　效果跟執行測試的人的經驗、責任心具有絕對正比的關聯,而且再高級的測試人員可能也無法確保這樣散漫的工作的效果會高于有計劃有依據的測試。
　　無法提供合理的文檔來應付各類規范的檢查。
　　測試的人如果不主動思考，可能無法從這樣的測試中積累經驗，工作不能帶來進步，直到最后厭倦。
...
　　其實不管理想情況下是多么的美好，我們還是在現實中度日，所以應付這樣的工作，還是需要一些方法，怎樣讓自己能用條理的做測試工作，最近我在這樣思考著。

原文轉自：http://www.kjueaiud.com