軟件測試中對于功能測試的一些看法
工作也快1年了，卻一直沒有寫過一篇關于測試方面的文章。一直做功能測試，功能測試這個東西，也有他的一套理論，一套流程，以及測試過程中的一些方法，什么邊界法，等價類。但實際工作中，因為真正把測試流程走的很好的公司畢竟很少。所以編寫測試計劃，寫完整的測試用列，運用這些方法可能機會不多。而實際工作中，完全的功能測試重要的就是理解業務和需求。所以具體的什么流程就不說了，網上資料很多。
下面談談自己對功能測試的一點看法：需求理解了，知道客戶想要系統實現什么，理解了業務，就知道了系統是怎樣一個流程來實現的。然后按照需求來進行測試的，不滿足需求要求的都可以認為是BUG.但實際中，這樣一個簡化了過程都很難，畢竟想從開發那拿到一份完整詳細的需求都是很不容易的（當然，可能也有比較規范的公司，但目前大多數應該是這個情況）。
當然功能測試也不是真的那么簡單，要做好一個功能測試，前提是要對需求比較熟悉，各個業務細節都很了解。甚至做到比開發人員還要了解。這或許是測試人員唯一的優勢了。個人做了快1年功能測試的一點看法。要做好功能測試，還需要對整個業務中數據庫的操作比較清楚（針對信息管理相關的系統）。比如哪個業務需要用到那些表，做怎么樣的操作。了解了這個就可以不單單從程序前臺來看程序，看到數據庫的過程，更有利于你找到隱藏的BUG.比如庫表沒有進行關聯刪除，日志表沒有插如記錄。這些是從前臺看不出來的，但實際可能會導致程序出現問題。
除此之外，了解程序框架的一個結構也有助你更好的去測試程序以及定位程序錯誤。比如前臺是如何和后臺通信的，之間是什么協議，什么格式。后臺是如何處理這些數據的。做完一個業務，發現錯誤，可以通過系統的日志記錄來查看錯誤的原因。而前面數據庫的也可以用上�？赡苋罩局杏涗浟藞绦心翘�SQL語句出錯，執行哪個函數出錯。這樣就要助于你幫開發人員定位問題。當然，測試人員不可能去深入的了解程序代碼（當然你如果足夠有興趣也有時間還是可以的，以后可以幫改BUG了）
在一個就是開發人員溝通。這個溝通其實也不是想象中那么重要，畢竟出現了BUG他就需要去改。但和開發人員搞好關系絕對很重要。因為BUG你可以問他原因，他會給你講解，這也有助你在以后測試中多注意這樣的問題，當然這是要靠自己總結的。在就是2個人溝通比較好的話，相互合作容易找到BUG的原因以及改正和驗證。要知道，開發人員是很喜歡一個能幫他找到問題地方的測試人員，雖然這并不是我們工作的重點，但這也是對自己的一個提高。
最后一點就是個人的學習習慣了。確實，功能測試能學習到的東西并不多，如果你僅僅是了解業務，那你換個公司，換個系統，你永遠都是個新人。所以做功能測試的如何去提高自己呢？功能測試是不能一輩子做的，當然如果你就喜歡用手點來點去，看看程序有沒問題那也沒辦法。所以學習是很重要的。比如操作系統，數據庫，網絡。
自己做了這么久功能測試，也曾經很彷徨，覺得就這樣點來點去，看看結果，覺得真的沒有什么前途�，F在想下覺得自己太浮躁。畢竟大多數的地方還是需要這樣的功能測試人員。而且任何一個做測試的人也需要從這一步開始，熟悉測試的過程，有一定的測試理論基礎才能走的更遠。所以要多學習，多總結。做功能測試，經驗也是很重要，當然也要熟悉整個任何工作，都可以從中學到很多東西，都可以做的很深入，即便是功能測試。關鍵是自己時候有興趣，是否適合自己。因為自己的興趣并不是很大，雖然做的很認真，但并沒有很深入的去學習。自己其實還很膚淺，或許只看到了功能測試的冰山一角，所以也只是談談自己對這一角的看法把。也歡迎大家談談自己的看法。
文章來源于領測軟件測試網 http://www.kjueaiud.com/