120度視角看PD

2021-09-30 22:04:43 字數 2070 閱讀 5857

跟著師傅做了幾個日常,參加了幾次需求的討論,漸漸感覺到做需求還是需要花費不少精力的。如果說對原來的業務非常熟悉,相對來說做起來就輕鬆一些,而要是從來都沒接觸過這塊內容,就會感覺有點像丈二和尚摸不著頭腦:知道使用者想要什麼,但是卻不知道如何跟現有的系統更好的結合起來,我們到底能夠提供什麼?使用者的需求是否合理?做需求分析,不能跟著使用者的感覺走,因為這樣的話,只能是使用者說一你做一,而如果使用者不能很好的提煉需求的時候,我們就會進入乙個死迴圈了。在和使用者討論的時候,我們首先要知道使用者為什麼會提出這個需求?能夠幫助他解決什麼樣的問題?希望達到什麼樣的效果?並不是所有的使用者都能正確的表達自己所想要的東東的。

乙個比較典型的例子:最近跟乙個營銷平台的pd在聊使用者一般會怎麼樣來提需求的時候,談到曾經做過的乙個營銷活動的推廣需求,運營人員為了推廣某一項活動,往往會比較糾結在頁面上這個按鈕應該如何放置,需要新增加幾個顯示字段才能達到這次活動的效果,那這是使用者最根本的需求嗎?不是,實際上他真正需要的是應該給他提供幾個維護活動的介面:類似什麼樣的活動時應該出現下拉的選擇框進行維護,什麼樣的活動應該給他提供幾個選項項。他們習慣上只會關注到現在他需要什麼樣的功能,在下次需要新的功能的時候,又會來提新的需求,所以對於類似這樣的問題,pd的作用就顯現出來了:透過現象看本質,要善於抓住使用者描述問題的過程,引導他丟擲隱含在這個需求背後的衍生內容,複述一下使用者所說的目前存在的問題,了解一下使用者可能會用的方式有哪些?並說明對流程的理解,再結合流程中的不明確點設計要詢問的問題,並將客戶的反饋記錄下來,然後與客戶確認一下是否有遺漏的內容,增加這些屬性是否就都已經覆蓋了他所想要的所有功能了?

我想這其實也就是需求分析的價值所在吧。這步工作如果沒有做好,往往就會導致考慮得不夠充分而引起新的需求變更,甚至關係到開發出來的軟體產品能否得到使用者的認可,客戶能否真正運用我們的產品幫助他們解決業務或管理上的問題。當然要做到這一點,也不是一兩天就能搞定的,需要乙個逐漸積累的過程,學會如何巧妙的向客戶提問也是一門非常值得我們去思考的學問。業務方在需求的提出方面起著主導作用,但pd必須要能夠對客戶的需求進行過濾,要在非常了解原有系統功能,架構設計的基礎上來給出建議,這樣才有可能在需求階段規避掉一些具有比較大業務風險、技術風險的需求。

做需求分析的過程,其實跟我們的測試分析工作有非常相似之處:我們在測試活動中,也都是從理解業務的需求開始的,首先需要明確測試需求(what),才能決定怎麼測(how),通過了解這個專案具體是做什麼的,完成乙個什麼樣的業務,哪些功能是最常用的?哪些功能是重點?還有就是使用者在處理實際業務時都要作些什麼,多個業務之間的先後順序是怎樣的,使用者在處理業務時對於哪些地方有特別的要求,等等。這部分規則,就是我們的測試需求中最基本的一部分。測試需求不明確,只會造成獲取的資訊不正確,無法對所測專案有乙個清晰全面的認識,活在自己世界裡的人是可悲的。

測試需求並不等同於軟體需求,它是以測試的觀點根據專案需求整理出乙個checklist,作為測試該項目的主要工作內容。根據所測的功能點進行分析、分解,從而得出著重於某一方面的測試,如介面、業務流、介面、資料等等。理解專案需求,需要從整體到區域性,從區域性到細節。測試人員不要總只了解自己模組的內容,要先從整個專案的業務流程入手,然後再到自己的功能模組,這樣的好處是,測試人員了解上下游的交易功能,更加的能夠了解業務的實現方法。經過一番狂轟亂炸式的深入理解之後,再將自己負責的模組有條有理的整理出來,然後講解給專案組成員,這樣也有利於模組之間的整合理解,再由他們提出各種各樣的問題,若能很輕鬆的回答出各種各樣的問題,說明你對專案的理解已經很到位了,而如果在提問的過程中有很多的問題,都是你之前沒有考慮到的,那說明測試的需求分析做的還不夠到位,這時你就需要好好總結一下,是因為自己經驗方面的問題,還是由於其他方面的原因。總結起來測試需求的內容大致如下:

1、理解系統的流程:整理出業務的常規邏輯,一項一項列出各種可能的測試場景,同時借助於需求文件資料,來確定該場景應該導致的結果

2、進行功能的分解:系統包含哪些主要的功能,每個功能的期望值是什麼;各個模組處理哪些業務,各子系統模組之間的資料介面關係,基礎資料從**進入,通過哪些處理生成哪些結果等等。在做完以上步驟之後,將業務流中涉及的各種結果以及中間流程分支回顧一遍,確定是否還有其他場景可能導致這些結果,以及各中間流程之間的互動可能產生的新的流程,從而進一步補充與完善測試需求。

以上只是個人對如何進行需求的捕獲以及怎麼樣做好需求理解的一些看法,同時也是對我自己前段時間的工作做的一點梳理,希望大家能多多交流,共同進步,把我們的測試工作做的更好。

從檔案視角看mysql

這裡的幾個rpm意義分別是 mysql client 包含最少的訪問mysql伺服器所需要的客戶端命令。裡面包含的是像mysql,mysqladmin這樣的工具。mysql devel 包含開發mysql客戶端所需要的庫。裡面沒有包含工具,都是包含.a這樣的庫鏈結檔案 mysql server 包含...

從微觀視角看消費問題

一位忙著裝修新居的朋友這兩天到處看家具,轉了北京多個賣場竟然很難找到沒有刺鼻的甲醛味道的產品,最後還是乾脆到宜家購買一套家具了事。我也稱不上是宜家的粉絲,但是宜家的東西質量上過得去,設計得簡潔明瞭,讓我放心 省心。我是被那些賣爛貨的店趕去宜家的。原來是一種 驅趕效應 難怪宜家店裡的客人總是那麼多,直...

硬體視角看段頁式儲存

一直認為,段頁式儲存是乙個軟體概念,將軟體分為各個不同的段來進行管理,通過劃分頁面進行記憶體分配,使用實際的物理記憶體空間。今天乙個同事提到了硬體的段頁式管理的概念,感覺這個角度很好,以前從來沒考慮過還能從這個角度去想段頁式管理的問題,所以將他的描述整理記錄下來。從硬體實現上來看,mips的虛擬位址...