做一個靠譜的軟件測試人員
找朋友的想找一個靠譜的朋友，公司找員工想找一個靠譜的員工，可見靠譜多重要。
何為靠譜？
在帶新人過程中，交待測試新人測試任務時，都不會忘記交待這樣的一句話：這個開發如何如何……
比如這個開發代碼質量很好，少bug，修改bug也快。
比如這個開發編碼有點慢，跟任務時多催一下。
比如這個開發編碼質量不怎麽樣，bug多，你測試的時候多註意一點，仔細測試下。
像這樣的交代有很多，特別剛開始還不熟悉開發的時候，等時間久了，只要測試過某個開發人員的項目一二次，就這個開發人員的編碼質量基本也就清楚了。
靠譜的開發人員代碼質量高，轉測之前會先進行自測，代碼bug少，有bug時影響也很快，和這類開發人員一起搭檔做項目會感覺很輕松，代碼質量高，上線有保證，測試人員都喜歡這樣的靠譜開發，王豆豆就經常碰到這類開發，真是好運爆棚。
今天王豆豆並不是想分析如何找一個靠譜的開發，而是要分析如何成為一個靠譜的測試人員。
既然測試人員喜歡靠譜開發，那相反開發人員也會喜歡靠譜的測試人員。
那靠譜的測試人員是什麽樣的呢？
王豆豆認為靠譜測試人員應該具備以下幾個特點：
1.業務能力強，測試流程清晰
2.測試覆蓋面廣，測試深度足夠
3.對bug敏感，能發現隱藏極深的bug
總之一句話，你測試，我放心，軟件質量有保證。
靠譜技能之一：盡可能多的覆蓋測試範圍
這個技能特別適合那種項目時間很短，需要緊急上線的小項目，這類項目需求太多不明確，且留給測試人員的時間非常少，測試之前測試人員對項目需求不了解，這類項目如果一拿到就開始測試，很容易就造成了漏測，那作為一個靠譜的測試人員就要想辦法避免這種情況。
該類項目大部分都無需求，只靠與產品經理和開發人員的溝通整理需求。
1.溝通確定測試範圍
接到項目之後，首先查看提測郵件，配置測試環境和數據庫，根據情況判斷是否先進行一筆正常場景的測試，當成熟悉需求一種方法，當自己對需求有了大致的了解之後，就與找產品經理或開發人員進行溝通。
溝通內容主要圍繞以下幾點：
1.此項目修改點是什麽？主要做了哪些功能？
2.代碼是如何實現的？
比如一個對用戶敏感信息的加密解密功能，當前端將用戶信息傳入進來時，調用加密API，將用戶的敏感信息進行加密操作，然後存表數據，當再次取表數據進行其他操作時，這時調用解密api，將用戶的敏感信息進行解密操作。
這時業務流程上的實現方式，那對應到代碼中代碼是如何實現的？加解密API是怎麽調用的？地址是多少？如何傳參的等等
3.本次項目修改的代碼覆蓋的範圍，確實測試範圍
4.測試過程中需要註意哪些點？
5.異常情況會有哪些？
對照這幾個問題一個一個的問清楚，理清楚。
2.畫出測試範圍
如果上面幾點在溝通中能到位，那測試人員基本對整個項目有了相對清晰的認識了。
這時拿出一個本子和一支筆畫出測試流程，測試範圍，註意點等等。
這個地方大家註意，王豆豆說的是畫，並不是寫，畫代表在這個過程中會有修改或不明確的地方，將不確定的地方再次明確。
（今天以最近做的一個小項目為例，隱去了業務，見諒）
王豆豆經常在桌子上準備一個本子和一支筆，不管是對需求不理解的點，還是測試過程中遇到的不明確問題都先在本子上記錄下來，這種方法特別適合新人，當上級或帶你的前輩在安排任務或講業務的時候，都拿筆記下來，俗話說得好“好記性不如爛筆頭”，這是古人留給我們的智慧，我們理當好好傳承。
3.明確測試範圍
將在本子上整理的測試點，測試範圍，用XMIND等工具快速整理出來。
這時推薦用這種思維導圖的工具整理，不推薦用excel或word文檔整理，將整理好的內容發給開發人員和產品經理確認是否覆蓋完全，檢查點是否設置正確等問題。
為什麽要做這步？因為每個人的理解都有所不同，做這步其主要目的在於消滅這種因理解不同，而導致後期測試不全，出現漏測的情況。
這些操作其實對應到測試流程就是需求分析，寫測試用例和用例評審，在項目時間偏緊的情況下，可以通過這樣的方式來進行，這些操作一定不能省，如果以這樣的方式來做也需要不了多少時間就能完成。
靠譜的測試人員經手的項目覆蓋面全，測試結果會很讓人放心，測試質量更有保證，只有成為一個靠譜的測試人員，你的上級才會放心把項目交給你負責。
看了王豆豆的分享，大家有什麽不同的看法？歡迎一起來分享你們在工作中是使用何種技能讓自己更靠譜的。
這是王豆豆小密圈的第一個問題，雖然大家的回答算不上熱烈，但是王豆豆對結果還是滿意的，不愧都是王豆豆帶出來的好學生，以後王豆豆會在小密圈分享更多技能幫助你們能更快成長。
做一個靠譜的軟件測試人員