測試工作的一些心得體會

一、測試的首要條件----明確需求

        做了6個月的測試了，覺得有必要把自己的一些心得體會寫下來。

        具體地和測試的內容有關，剛開始測試，犯了一個比較嚴重的方向性錯誤，覺得錯誤就是找BUG,找出最多BUG就顯得自己有多牛似的，現在才發現自己錯了。

        首先測試，要做的就是驗證軟件是工作的，就是在一般情況下能完成其基本功能，這個就要緊扣需求，試想，如果軟件連最基本的需求都滿足不了，那么界面再美觀，也只是一個空殼。這部分內容的測試要求測試人員要研究軟件的說明文檔，了解了需求才有資格做測試，其實，如果你不知道什麼是正確的，那你提BUG的依據又在哪里?你提的BUG又怎么讓開發人員心悅誠服地接受并修改呢？

        話又說回來，只有明確了需求，也才能真正提出隱藏在軟件內部，深層次的BUG，提出那些讓開發人員覺得受益的BUG，也會受到開發人員的尊重與歡迎，也才能體現我們測試的價值。

        否則，不明確需求，在界面上點點，提一些邊邊角角的缺陷，讓開發人員不開心，覺得測試人員沒水平，竟提些無關痛癢的BUG浪費他們的時間，領導也會覺得測試的意義不大。

        不過需求說明文檔各個公司不一樣，正規的公司都有比較詳細的說明文檔。還有就是當你對需求不清楚的時候，一定要去溝通。

        這部分測試的時候也要分優先級的，軟件最核心的功能是什麼？把握最核心的，其次有影響的，再其次界面，幫助文檔之類的。

二、根據需求設計測試用例

        我就我工作的這邊，需求文檔就是一張張的表，剛開始測試的時候不知道表的意義何在，覺得看這些表太浪費時間了，沒有好好研究，好在亡羊補牢，為時不晚，其實所有的內容都蘊含在一張張的表里。表中有表字段，表字段有取值范圍，我們的測試用例來了，取值范圍，邊界值。還有索引值，是唯一索引，主索引的話，唯一性這里也要驗證。還有表的關聯性，A表中的值在B表中必須存在，也是一個測試點?？傊?，靈感就這么源源不斷地來了，覺得測試真的是一件具有創造性的事情，絲毫沒有覺得它的乏味。

        我們還可以到數據庫中去查表字段的取值是否和需求說明中一致，也是有很多測試點的。

        當然，以上是說手工測試。何時才能自己開發自動化測試工具呢？或者用自動化測試腳本代替手工測試呢？期待這一天快點到來。

三、如何開展自動化測試呢？

        因為我們測試的軟件是一套很大的系統軟件，整個測試是通過GUI界面進行的黑盒測試。這套軟件也提供了人機命令接口，我一直在想，如果能通過這個接口把基本功能的驗證都做了，抽出人力去充分發揮測試人員的創造性，那該多好啊。

        想法想來已久，也小小實踐了一下，實現了一小部分的自動化測試，不過，因為命令本身設計的不完善，所以只涉及了一部分功能，其二，命令本身存在缺陷，并不能取代界面的測試。其三，因為開發人員對命令部分的不重視。

        也學習了Functional Tester工具，進行錄制與回放，這個方法腳本的復用性不高，維護的代價也比較高，所以不選它了。

        最好的方法就是開發自己的自動化測試框架。

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