軟體測試人員怎麼去瞭解業務

標籤：

被測軟體的商務程序是開展測試工作的重要準備活動，同時在測試過程中起到十分重要的參考和分析依據作用。

　　這個問題很簡單但是又很難。簡單是因為軟體商務程序可以順藤摸瓜，難是因為不知從何入手。

　　“被測軟體”聽起來有點大，被測軟體的行業背景、軟體的大體作用，總的架構結構這些“大”方面的資訊比較容易擷取和理解。實際上軟體是由眾多功能組成的，在實際工作中，功能模組的商務程序對測試起到了直接的指導和參考作用（例如測試案例的編寫，測試結果的分析等等），不掌握商務程序則不足以很好的測試。

　　測試人員想要獲悉軟體功能模組的商務程序，就必然要牽涉到開發人員，也就是要涉及到開發與測試的介面。

　　這個問題想要解決，有很大程度要依賴於測試與開發的合作。開發測試體系是否規範和健全非常影響這一結合點乃至影響整個測試的流程。

　　請務必現場找到這個軟體功能模組涉及的開發人員，最好能夠找到一個“頭”（也可以由你的頭找到他們的頭），OK，下面就是真人PK，剛開始這很折磨人，你什麼都不知道，但是你必須得問，一定要把某個點弄明白（例如功能模組中的某個程式是做什麼的，這個功能模組是誰誰誰負責，這個功能模組涉及到了介面、資料庫），找到這個點就可以順藤摸瓜，把所有涉及的開發人員問個遍（有條件的話，可以所有涉及的人員坐下來探討一下，對測試人員對開發人員都有好處，要知道負責不同功能的開發人員很可能對項目的其他開發人員負責的部分一竅不通，對整個業務也是糊裡糊塗）。溝通的同時要記得互惠互利，你知道的，也要告訴不知道的人，在你以後的溝通交流生涯中，形成一種良性的互惠活動，而非一味的索取答案。

　　通過良性的迴圈，使得測試人員從“不知”變為“晚知”。

　　當然“晚知”相對於“早知”花費的氣力和代價大很多，但這恰恰是很多人遇到的情況，不得不面對。

　　對於有著良好的開發測試流程體系的團隊來說，則要幸福很多，可以“早知”。

　　但是也不要放鬆自己，因為“早知”不代表你“明知”（正確明白的知道）。

　　在測試過程中，隨著測試的覆蓋和深入，必然引發各種問題和疑問，需要去判斷和分析。這個時候依然需要測試人員和開發人員協力合作，促成雙方對商務程序、功能細節、原始需求等方面的加深理解

　　要如何才能掌握好商務程序呢？有以下幾點比較重要：

　　一、瞭解主體的業務架構，不必追求分支細節。先對總體業務有一個印象，知道一些概念性的東西，混個面熟；

　　二、瞭解為什麼要有這個業務，最原始的需求來自於哪裡。可以跳出當前的這個商務程序思維，考慮下最源頭的業務驅動，原本這個業務是解決一個或者一類什麼問題的。這樣也算是有的放矢了。

　　三、站在使用者或業務需求本身的角度來理解分支細節。這個時候可以充分發揮我們的想象力去理解這些東東，也可以找一個熟悉這塊業務或類似業務的同事來聊聊，或許會有很多意外的收穫。

　　四、將分支和主幹全部都串起來，一體化思考整個商務程序。重新梳理你對整個商務程序的理解，如果還有不通的地方，可以再次去求證。這個時候你對業務可能就不再僅僅是理解，或許你還可以發現其中不合理的地方，一切皆有可能。

　　另外，不要把自己限制在測試人員的角色裡，在熟悉和理解業務的時候，需要從多個維度去思考問題，比如：從需求方的角度去考慮業務本身的價值走向；從開發的角度去推斷業務的邏輯構架；從測試的角度去分析業務的合理和完整性；從使用者的角度去體驗業務的易用性。

　　1、在需求文檔，設計文檔等相當的規範的情況下，當然是先拿到文檔後熟悉商務程序，一般在商務程序比較瞭解的情況下，公司會有開發做產品和技術的介紹，這樣可以比較深入的瞭解開發的背景，以及一些技術的特點，也可以瞭解到測試的側重點等等……

　　2、在沒有詳細的需求文檔時，一般有2中情況，一種是有設計文檔，看以先看看設計文檔，熟悉業務的流程圖，這樣的話測試人員要花比較多的時間在流程上，希望在開發講解產品和技術介紹之前，能夠補上沒有需求文檔帶來的業務不熟悉……

　　第2種情況是既沒有需求文檔也沒有設計的詳細文檔，那個人建議多和開發溝通，不懂，不清楚的都只有找開發口傳需求了，這樣估計效率不叫低。

　　3、需求一直變？  那最好的辦法是多和開發，需求設計人員溝通吧，溝通在沒有詳細的文檔的時候是最有效了 。

　　4、開發不好溝通……事情不好做哦

軟體測試人員怎麼去瞭解業務