產品經理做測試那些事兒
周六,深夜,我拖著滿是疲倦的身軀,四處閑逛,來到小巷一家還閃著霓虹的酒吧,我略一猶豫走了進去。
酒吧冷冷清清,寥寥幾對男女,在昏暗的燈光下切切私語,我沒興趣知道他們在說些什么,懶懶趴在吧臺,酒保一臉賊像,笑嘻嘻問我想喝點什么,并向我推銷他們的新品雞尾酒,我不看他,只說:啤酒。
酒保自討沒趣,把酒擺在我面前,我眼神空洞,一口口喝酒。
吧臺上還坐著個戴著墨鏡,滿臉胡茬的大叔,喝著的也是啤酒。
這時我的手機鈴聲響起,我掙扎兩下,拿出手機,卻看是總監打來的.
沒辦法,接吧:“喂,總監?!?/p>
總監:“朝聆夕改,你在干嘛?”
我:“我….我在回家路上?!?/p>
總監:“BUG處理得怎么樣,是不是要發新版?”
我:“嗯,BUG處理得差不多了,要發新版。不過研發的同事說怕再說問題,要多測兩天再上……”
總監:“那你還回什么家,好好測啊!當時測試的時候不好好測,現在倒想起來謹慎了…..”
我:“好的,我周末繼續測….”
掛了電話,我木木地喝了口寒徹心扉的啤酒,準備再做幾分鐘就回去。
這時,旁邊的大叔冷笑一聲:“小伙子,你是產品吧?”
我一激靈:“你怎么知道?”
大叔抿了一口啤酒:“我不僅知道你是個產品經理,還知道你們公司人不多,你們公司沒QA?!?/p>
我手抖了抖,杯子掉在桌上,濺起的啤酒,冰涼了我的神經,我一下子清醒了。
他猜的沒錯。我是個產品經理,移動互聯產品經理,公司剛B輪,人確實不多,沒有QA。
我轉過身去,看他,才發現其實他邋遢之余很是瀟灑,昏暗的燈光下那閃閃的墨鏡遮住了他深邃的眼睛,嘴角泛著淺淺笑意,胡茬還留存著啤酒的水漬….
我一抱拳:“請問前輩高名?”
他笑了:“別來那套文縐縐的,老子姓高,你可以叫我老高。以前是移動互聯創業公司的產品總監,現在下海做生意,兼職算命?!?/p>
得道高人!我知道我今天遇到高人了。
他不看我:“是不是測試遇到麻煩了?”
我低頭:“嗯,公司沒測試,我負責組織研發同事測試,結果測完上線,出現了機型適配的問題,只能重新發布…”
他說:“你知道測試是什么嗎?為什么你們公司沒測試?你作為產品經理,卻得做測試的工作?”
我有點蒙:“測試,就是一群人拿著手機測BUG啊,公司不是沒招過測試,上次來的那個測試,看所有人下班了都沒走,第二天就不愿因來了…….我對產品最熟啊,再說也缺人?!?/p>
老高咂兩下嘴:“錯,錯,錯!測試是產品策劃到上線維護中不可缺少的一環,測試質量的高低直接關系到產品的可用性,友好性,可靠性。雖然測試是必要的,但測 試人員不是必要的,因此大多數的初創公司并不設置QA的崗位。同時,沒有測試人員,其實也是一種敏捷的方式,facebook在從創立起很長一段時間里都 是沒有測試的。產品經理做測試,一方面是因為對產品最熟,另外也是因為開發思維與測試思維是不同思維的原因,說了你也不懂?!?/p>
我不服氣,猛地喝了一口酒:“那你說說測試是什么?”
他 又笑:“從測試內容上看,測試主要分為UI測試、功能測試、兼容性和性能測試。UI測試就是界面視覺的測試,找設計師測就行了,兼容性和性能測試人力不可 為,一般要借助工具測,但是必須測,像你們這種手機適配問題肯定是沒走過這個流程。一般來說,產品跟研發做的就是功能測試。測試是有許多方法的,但主要分 為三類…..”
“黑盒測試、白盒測試和沙盤測試!”原來是酒保打斷,這廝在旁邊偷聽許久了,我還以為他是想趁我不注意給我倒酒。
我說:“你還懂這個?!?/p>
酒保賤賤一笑:“略懂,略懂,以前做測試的,花名測三通?!?/p>
老高也有興趣了:“那你說說什么是黑盒測試?!?/p>
測三通:“黑盒測試,也可以叫不透明測試,它著眼于程序外部結構,不考慮內部邏輯結構,主要針對軟件界面和軟件功能進行測試。主要方法有等價類劃分法、因果 圖法和錯誤推測法。等價類劃分法就是把產品按照模塊進行劃分成若干個部分,分人測試,一般公司都用這。因果圖法就是根據流程圖,測試前、后置條件,從而推 斷是否可以正常使用的辦法。”
見我不太明白,他又補充說:“比如在購物車點擊確定,但是購物車里是空的——返回“用 戶名錯誤”提醒,就是一條因果圖法的測試用例。白盒測試與黑盒測試互補,是透明測試,在于全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。沙盤測試就 像你們產品經理做競品分析的時候做的那個什么….“
老高提醒:“任務走查?!?/p>
測三通:“嗷~任務走查,模擬用戶在實際環境中的測試,也就是把一個個用戶場景都走通一遍把重要的邏輯漏洞過濾掉,一般產品上線前的回歸測試就用它。”
真是人不可貌相,我深深看了測三通一眼,然后溫柔地對他說:“倒酒?!?/p>
老高補充說:“其實還有許多測試內容,比如:
- 排序測試
- 字符測試
- 緩存測試
- 必要信息測試
- 準確性測試
在測試中是很容易忘記的,你最好記住?!?/p>
我拼命點頭:“前輩教導的是,我們平時用的就是黑盒測試,那你能跟我講講測試的流程嗎?”
老高用酒杯砸了砸桌子:“這個要好久(好酒)呀…..”
我定睛一看:果然酒杯空了。
我看了測三通一看:“倒酒,算我的!”
測三通這小子早就在旁邊等著了,趕緊給老高倒了杯12年的人頭牛。
老高喝了口:“好酒,既然你這么有誠意我就好好跟你說說。”
我跟測三通都聚精會神地看著他。
老高:“測試流程主要分為這么幾步,
- 測試資源準備;
- 測試人員分工與選擇測試方式;
- 測試FIX任務。除此之外你還要準備相關文檔。話說你叫什么名?”
我這才想起我沒做自我介紹:“哦哦,我叫朝聆夕改,你叫我小朝就行了。”
老高:“小改呀,你平時測試資料準備都準備些什么呀”
我想了想:“主要就是各種型號、操作系統的手機,有時候還需要給他們準備點紙筆?!?/p>
老高點點頭:“嗯,你說的是測試設備的準備。測試資料一般要準備下面幾項:
- 測試設置,除了你說的手機、紙筆外,你還要借場所,就是會議室之類的,準備點小零食也是有好處的;
- 測試壞境,一般就是內測壞境、正式環境;
- 測試賬號,普通賬號和特殊賬號,都要多準備些,臨時準備會影響測試人員的士氣;
- 測試人員,要預約好,安排規劃,不然臨時就叫走,把你氣的半死;
- 測試用例,這兒是產品測試的核心,是對產品的所有節目的視覺、交互和功能邏輯的匯總?!?/li>
測三通插嘴:“這個測試用例可得好好講講?!?/p>
我冷冷地看了他一眼:“你也要請喝酒嗎?”
測三通閉嘴。
老高呵呵一笑:“當然,不講測試用例算什么測試。
測試用例撰寫的原則有這么幾種:
- 有效性,就是說測試用例必須是真實有效的,不同的測試人員依據相同的測試用例所得到的輸出應該是一致的;
- 復用性,不用寫的太死,能復制最好,要不然一個小產品就隨隨便便幾千個,累都累死你了;
- 易組織性,寫用例的時候最好能考慮到測試的場景,別上一個用例寫的是A頁面,下一個又跑到C頁面去了,當然產品經理還是有這個思維的;
還有其他原則,比如可評估性,可管理性,太專業了不太重要,原則有幾個就夠了。
得,我先上個廁所?!?/p>
說罷,他扶著墻去廁所了。
老高真是教科書一樣的人物,只可惜,人到中年就雙目失明…我正在替他感到悲哀,就聽到老高遠遠地就在廁所門口喊:“你這賊酒保,又趁我不在給我倒酒是不是!”
測三通,僵住了正在偷偷倒酒的手臂,尷尬地說:“哎呀,你老身體健康就好,沒事戴什么墨鏡算命吶,我就想做點好事,請您喝杯酒……“
老高大步流星走到位置,不客氣地猛喝一口:“原來是這樣,三通你這年輕人不錯,我看好你?!?/p>
測三通訕訕而退,我看看老高,他正摘下眼鏡朝我眨眼:原來是裝的,騙酒喝!
我苦笑:“前輩,咱們接著說測試用例吧?!?/p>
老高:“好嘞,剛說了原則,下面說說類型,類型就這么幾種:
基本功能用例、交互用例、臨界用例還有壓力測試。前面三種你應該都懂,最后一種壓力測試一般人就不懂了,壓力測試一般是指在比較短的一段時間內,被測手機執行比較多的任務或者操作,來檢測被測手機承受壓力的能力。這個測試還是比較有必要的,知道了也可以裝X?!?/p>
我深以為然:“前輩,我也寫了一些測試用例,請您指點?!?/p>
老高看完我的測試用例,點點頭:“小改,其實這就夠了。測試用例在內容上可以分為兩個部分:測試信息和用例信息。
- 測試信息包涵了測試人、測試時間、測試版本號、測試機型、操作系統以及測試的結果統計;
- 用例信息主要包涵用例所屬模塊、用例ID、用例事件描述、前置條件、期望結果以及測試結果等?!?/li>
老高頓了頓,說:“這是黑盒測試的用例,如果是沙盤測試或者白盒測試,用例就會復雜許多,往往需要流程圖之類的,如果是成熟的,或者傳統公司對測試的流程就要多許多,你是用不著學的?!?/p>
我得到了前輩的認可,還是有些欣喜:“那該說說測試分工的事情了?!?/p>
老高:“那你們平時怎么分工的。”
我說:“就找兩端的主管要些人,然后隨即分模塊給他們,把測試用例分給他們,下午的時候組織一下集中測試?!?/p>
老高搖搖頭:“效果怎么樣?!?/p>
我品了品苦澀的啤酒:“不太好?!?/p>
老高:“具體表現呢,列舉出來,你個產品總得有點邏輯能力吧?!?/p>
我掐了掐自己已經快麻木的大腿,強打起精神:“那我可得好好吐槽一下:
- 集中測試的時間縮水太嚴重,每次召集人手都要幾十分鐘,還經常檢查出BUG就馬上去改,一次集中測試要測1~2小時;
- 集中測試效率低下,測試時很容易被與自己測試內容不相關的部分打斷;
- 負責測試的研發同事對產品不熟悉,要跟他們講,特費時間,效果還不好;
- 單獨測試不能很好執行,不可控;
- 經常性被不同的人提出重復的BUG,浪費時間。”
老高哈哈一笑:“看來你很清楚出現的問題呀,可是你還是不能解決是不是。”
我:“是啊,請前輩指教。”
老高揮揮手:“叫老高就行了,指教談不上,兵法有云:知己知彼,百戰不殆。你既然知道問題,也應該知道出現問題的原因。第一條,集中測試太費時間,主要的原因是這么幾個方面:
- 沒有很好的時間規劃,測試人員不知道什么時候測什么時候停止測,建議你們的集中測試由下午改成中午,到午休的時候自動停止,這樣至少有個停止的時候,讓測試人員能夠自覺調節測試的速度,同時下午的時間其實更有彈性,你懂得,改不完的可以加班嘛;
- 人氣不足,可能是你在公司呆的不久,跟開發不是很熟,更重要的是沒有建立那種說一不二的威信,所以你得以身作則,梳理形象;
- 測試人員責任心不足,這是怎么回事,你知道烏合之眾這個詞吧,差不多就是說群體會降低每個人的智慧,大家嘻嘻哈哈沒當回事,自然不行。這時候我建議你使用交叉結對測試的方法測試。
- 測試人員動力不足。沒獎勵呀,你得多鼓勵鼓勵才行,有鼓勵師沒?”
我張張嘴,還沒說話,老高就打斷了我:“沒有是吧,那就物質獎勵,前面說測試資料準備的時候不是也提了準備零食嗎,這時候就得上啊。”
我皺皺眉:“老高,那個什么交叉結對測試是什么意思?我只聽說過交叉測試?!?/p>
老高瞇了瞇眼睛:“交叉結對測試,就是指安卓和iOS兩端的負責同一個模塊的開發人員,組成隊伍,相互測試對方的客戶端。有點拗口,但很有用處:
- 由于是負責自己開發的模塊,所以不需要學習,能夠很快投入狀態;
- 測試對方的模塊,能夠在測試的同時檢查自己的錯誤,測試的時候能夠心中有數;
- 既是合作也是競爭,同時由于測試必須同時進行,一個人不來,另一個人也沒辦法開展工作,所以時間被拖延,這樣也是培養他們的責任心。
這樣,使用交叉結對測試的方法,其實也很好地緩解了第二、三、五個問題?!?/p>
我搶過測三通手上的酒,給老高滿上:“高哥,這個我算明白了,你給我講講其他的吧?!?/p>
老高滿意地點點頭:“集中測試效率低下,很容易被打斷。其實這個也很好理解,集中測試就是發現一些重要、明顯的BUG的嘛,不要指望它能夠帶來多大的效果, 但是由于單獨測試不可控,所以集中測試是很有必要的,你就把集中測試當成一個測試的熱身,調動熱血與氣氛的工具就好了,可以適當地縮短集中測試的時間?!?/p>
我把手機調成的錄音機,放在老高面前,生怕漏了一句。
老高頓了頓,說:“你說了許多集中測試的事,卻不說單獨對照測試,肯定不是因為單獨測試很順利,而是因為沒人單獨測試是不是?!?/p>
”是啊,除了我跟個別的開發,其他人都不照著測試用例測?!蔽胰缬鲋?。
老高嘆了口氣:“這也難怪,我以前也遇到這種問題,原因無非以下幾點:
- BUG改不完,沒有時間單獨測試;
- 利用測試用例做單獨測試的習慣未養成,同時也缺乏良好的監督;
- 認為自己的本職不是測試,所以對測試有排斥;
怎么破呢?我的建議是:
- 規范測試用例,以及單獨測試的任務,甚至可以作為績效指標;
- 招聘專業測試?!?/li>
我已經打開自己的筆記本在做筆記了:“
- 使用交叉結對測試;
- 在中午午休之前做集中測試,并減少集中測試時間;
- 做測試激勵,規范單獨測試的任務;
- 招聘專業測試?!?/li>
老高:“嗯,你這小產品,做整理的本事還是不賴的嘛。行,那我就傾囊而出,下面講講測試流程的第三環–FIX任務流程?!?/p>
見我有些疑惑,老高點了根煙,狠狠抽了一口:“測試出問題,就得歸類、整理、分配嘛。我現在隨便給它起個名字,叫FIX任務流程。自創的名字,不用回憶了。”
原來如此,我對老高更崇拜了。我想我要是個女生,現在的樣子肯定很花癡。
老高見我默認了他的命名,很高興地繼續講了下去:“我按照任務的生命周期,把整個流程分成了四步:任務創建、任務處理、任務審核、任務歸檔。現在都是在線辦公了,咱們也不能總用SVN這種傳統工具不是,多不方便,如果公司沒有開發自己的任務系統,那也可以用現成的?!?/p>
我急說:“是,我們公司用的就是在線辦公,還不錯?!?/p>
老高得意地吐個煙圈:“看來我還沒過時。那你覺得怎么好用了,有哪些不好用的地方嗎?!?/p>
我說:“還不錯,不過確實也有不對勁的地方。
- 任務創建的時候,有的開發把自己發現的BUG提交上去,但他們描述的任務的風格不一樣,有的描述問題,有的描述正確的做法,讓那些修BUG的人看不懂;有 的開發把BUG給負責人,讓他們去提交BUG,結果修BUG的人不知道這個BUG是誰提交的,到處找,遇到一個人就描述一遍,費勁;
- 改BUG的時候,有時候需要跨部門合作,可能需要產品、設計、服務端、前端等部門的同事參與,周期太長,他們也不見得有時間幫忙,總是拖拖拖;
- 有的問題,其實不是BUG,是產品設計上的問題,這時候要找負責該模塊的產品確定,但是常常就是一個客戶端改了,另一個根本不知道,好麻煩;
- 任務太多的時候,就需要歸檔,可是一個個歸檔特別耗時間,然后就是歸檔任務之后就不知道這個任務是怎么發現,怎么處理得了?!?/li>
老高笑道:“這些簡單,我教你幾招:
第一招,集中測試時,每個人一張紙,將BUG寫在紙上,然后署名,由負責人去記錄,同時任務創建的同事需要關注BUG的發現人;單獨測試時,創建的任務默認關注自己。這樣有幾個好處:
- 集中測試時,BUG多、亂,這時候做記錄很麻煩,不如用筆記;
- 由負責人做記錄,文風統一了,理解起來不困難;
- 關注了BUG的發現人,遇到不理解的,或者不能重現的,可以快速準確地找到發現人;
- 為BUG的修復檢查做準備,須BUG的發現人去檢查BUG是否被修復,之后才能做歸檔處理。
其實,還有個好處。”老高露出一絲與剛才騙酒喝一樣的詭異笑容:“出了問題,可以追究責任。但真實目的是讓大家更有責任意識?!?/p>
我覺得老高真是個妙人,隨便支了一招居然解決了五個問題。
老高接著說:“第二招,記錄與通知?!?/p>
說完就靜靜地看著我,我當然知道什么意思,趕緊順著他的意思,裝成傻子:“什么意思?!?/p>
老高看看杯中的酒,緩緩地晃晃杯子:“記錄就是時刻記錄這些產品設計上的改動,不一定需要PRD,但一定要記著;通知就是做了修改后就通知兩端的負責人,記住啦,別把別人當傻子,就敘述就好了,別過去就傻愣愣地問別人改了沒?!?/p>
我拼命點頭。
老高:“就這兩招吧??绮块T的事情,其實你需要做的就是:
- 處好關系;
- 把問題整理好,別找到了別人還說不出個所以然來;
- 把測試的重要性強調強調再強調。至于任務歸檔這件事,我建議你不要隨便歸檔,最好就是等到新版本上線并穩定后,再歸檔?!?/li>
老高喘了口氣:“最后就是文檔了,測試日報、周報,目的就是評估開發質量、對問題進行分析。你們既然用了在線工具,那么這個日報也不是問題。”
我沒想到今夜居然有如此大的收獲,三謝老高,準備離開。
測三通不知道什么時候已經冷冷地站在我背后,看我要離開,就冷冷地來了一句:“你沒有把話講完。”
我跟老高都看著他。
他好不容易有點存在感了,又在哪里賣關子:“我就看不慣你們這些做產品的,有什么話講…….“
我跟老高同時冷冷地道:“有話就說,沒事就滾?!?/p>
測三通徹底蔫了:“你們都避著人的事情不說,我當初就是處不好人情才出來做酒保的?!?/p>
我心一驚,沒想到這衰貨居然還有這種思考深度。
老高也把臉對著我,他的墨鏡后面深邃的眼睛也一定盯著我看。
我喝了口酒:“好吧,人的確是很大的問題。除了前面的責任感與專業程度外,還有幾個麻煩:
- 不可控的外界原因,比如緊急事件處理、測試場所被占、測試機不足等都會影響測試,甚至讓測試停止;
- 人員的不可控,緊急任務的人員抽調,請假、離職都會導致人員不足;
- 非測試人員的參與,由于不了解測試的進展,胡亂創建任務、歸檔任務,導致了大量的重復任務,甚至有些人還直接來詢問產品和開發,一個個都要講清楚才行。增加了開發的負擔,歸檔任務的就更麻煩了,直接找不回來了?!?/li>
“還有在測試的時候集中提需求的。”測三通補充道。
我看著老高,老高沉默良久,說:“這件事情,是解決不了了,只能緩解:
- 盡量做足準備,比如預約多個會議室,向公司多申請些測試機,或者讓同事們借出等,做好備用方案;
- 強調,提升測試的重要性,不能因為周期長而認為測試不緊急;
- 盡可能地調整人員調派的時間,不予固定的測試時間沖突;
- 提高人員出借的難度,如果有人要借人,那么需要找負責人說明原因;
- 盡量控制非測試人員的權限,不允許直接向測試項目組添加、修改、歸檔任務;
- 非測試人員創建的人員,需要測試審核通過后,才能由測試負責人創建任務;
- BUG修復審核完成后,應該先歸類到特別的任務組中,等到產品上線并穩定后才可以歸檔;
- 由項目負責人整理測試日報、周報發送給非測試人員,打消他們對測試進度的疑惑?!?/li>
我設置的零點鬧鐘響起,我必須回家了,明天還有許多工作去做。我再謝了老高,也辭別了測三通,離開酒吧。
出了酒吧,寒風襲來,我被酒染紅的燥熱的耳朵,感受到今年入冬以來最刺骨的寒意,但我還很興奮,我的手機收到一條短信,原來是老高送我的十六字箴言:寫好用例,處好關系,做好溝通,招個測試。
我回頭看看這家不起眼的酒吧,霓虹燈上的有些燈泡已經熄滅,但我還是能夠辨認:測馬奔騰。
再會,離場不散場。我心說,然后扭過頭,疾步離開。
#專欄作家#
朝聆夕改,人人都是產品經理專欄作家。移動應用客戶端產品經理,關注移動社交、教育等領域;拒絕空談的行動派,愛深度研究。
本文原創發布于人人都是產品經理,未經許可,不得轉載。
精彩~精彩??!
那么問題來了,老高什么時候拿到你的手機號的
厲害
我覺得你要去寫本書,能火 ??
2018年會寫一本 ??
“朝聆夕改”這是在黑產品嗎? ??
意思是早上聽說了不好的地方,到了傍晚就能改好,代表靈活,敏捷
皮還是你皮
寫得挺好,贊一個
難道只有我一個人關心 。。這家酒吧的名字跟坐標嗎?
弱問哈 那個項目管理工具是?
一股子韓利的問道?。?/p>
??
其實還是有必要招一兩個測試??幢槿?,一個產品經理 頂著 項目經理 + 測試經理雙重職責,跟程序員說計算機語,與業務人員說人話,真不是一般的累啊
寫作能力不錯哦 ~
軟軟的干貨 收藏了哈哈
故事型的說法,真不錯
?? 一個苦逼的測試人員
別具一格的文風,濕潤的干貨。
測試就找testin
不錯 收藏了