軟體測試工作是軟體生命週期相當重要的一個環節，對軟體的整體質量起到決定性作用，軟軟體必須經過系統的專業的測試才可進行生產釋出。那怎麼才能做好測試工作，是一個值得我們好好研究是課題。

首先一切從需求出發，客戶或者產品經理提出怎樣的需求，測試案例的編寫務必滿足並覆蓋住所有的可能情況。做好特殊情況和邊界的測試。

再則系統業務邏輯一定要深入理解，全面理解研發可能的實現情況，其實最好有一定的開發經驗，瞭解開發的大體思路和實現邏輯對測試工作會有很大幫助。

還有就是多向人請假溝通，無論是測試人員，研發人員，設計人員，只有你肯交流多交流，並把溝通的事情詳細理解並應用到測試工作中，相信你的測試工作會有突出的表現。

最後題主可能就是一個真正的測試從業者，所以還需要整體規劃自己的職業放心，不能只侷限於功能測試，要深入學習各種自動化測試，效能測試以及滲透性測試等等。不同方向的測試會有一些交叉借鑑的情況，希望題主的測試工作會有更好的發展。

回答我們是認真的。

你好， 首先我不知道你說的是什麼方面的測試，但是用的來說測試工作要注意些方面。首先你要知道產品設計的初衷是什麼？功能能否實現？符合行業標準嗎？從人機互動設計考慮是否符合？要多次嘗試才能更好的做好測試工作

現在軟體測試行業非常的熱門，薪資高不說，門檻還低，很多小夥伴們都想要入行軟體測試行業，入門簡單，但是要想做得好，倒也不是那麼容易了，想要成為一名出色的軟體測試員，有三種能力是一定要具備的。

一千個人心中有一千個哈姆雷特，眾多的軟體使用者，擁有各種各樣的使用習慣和意見，這就導致了軟體在使用過程中會出現各種各樣的狀況出現，為了應對各種突發現象，軟體測試工程師一定要擁有縝密的邏輯思維能力，和逆向思維能力，能夠以使用者角度出發，捕獲一切可能性，對細節有不同尋常的關注能力，這樣對於軟體後期維護和長期發展都是非常有利的。

軟體測試工程師並不只是自己蒙著頭幹活，溝通也是軟體測試工作中最重要的一環，既能和技術開發人員溝通，又能簡潔明瞭地向客戶、管理者等這些非技術人員闡述系統在哪方面有缺失。當發現軟體有問題時，不僅需要跟開發人員溝通，找到問題出在哪兒，闡述自己挑錯的理由，有時候甚至要提出解決方案，直接參與前期需求和程式碼的修改。所以說想要成為一名優秀的軟體測試工程師，出色的溝通和表達能力是必不可少的。

技術自然是軟體測試工作支撐，作為軟體測試工程師，雖然無須精通各種語言各類技術，但必須全面理解被測軟體系統，明白該使用何種工具進行測試。

1、測試要有具體的產品，測試具體的產品。要懂這個產品的業務。不然就理解不了需求，不知道該如何操作，也做不好測試工作。

2、要從客戶的角度去理解需求，明白客戶的操作習慣，在做測試設計的時候，要考慮在涵蓋所有測試點的基礎上。再把客戶的操作習慣考慮上去。

3、做好測試設計，用思維導圖覆蓋到所有測試點，正常流程和異常流程都要考慮到，特別是一些邊界值問題。

4、要考慮效能。比如一些匯入，匯出。要考慮效能，否則有可能出現功能卡死用不了的情況。影響客戶體驗

5、考慮併發，比如同時操作同一條資料，是否會給出提示。

目前的很多公司為了快速的迭代，短時間開發出產品；測試、產品、開發在同一個辦公地點工作；導致測試、產品、開發的職責出現混合交叉，從一定的程度上說可以節約開發時間，但是也會產生很多的問題；

首先，測試的職責不夠明確，立場不夠堅定；在測試的角度來看，首先是應該是對產品負責；那麼如何確保產品的質量是高效的呢 ？

1、產品的設計標準；

從產品立項開始，測試、開發、產品應該一同指定出一個合理的產品設計標準，明確產品的設計流程，應該實現的功能，具體的實現流程，具體的效能標準，針對的使用人群等等，當測試得到設計標準後應該針對設計標準制定對應的測試用例，並且嚴格針對測試用例來執行。

2、開發的設計流程

開發應該針對具體的功能產出開發設計流程，該流程應該具體明確某個功能的實現方式，涉及到哪些影響點等；

3、開發轉測試的流程

開發實現功能後，如何轉測試，應該實現什麼樣的標準後才能轉入測試？如果轉入測試的標準太低，將導致測試迴歸次數太多並且最終的產品質量將不能得到確保；如果轉入測試的標準太高，將在開發自測的時候花費太多的時間，最終也會使得產品的開發成本增加，因此，我們應該合理的控制開發轉測試的標準；此時，可以由開發、產品、測試共同制定出一套提測標準，最終實現開發轉入測試的流程

4、測試流程

測試的迴歸次數，在我看來超過3次的測試迴歸，就不應該算是一次成功的提測；過多的迴歸一是浪費過多的時間，另外會導致測試無力去做更多的穩定性、效能測試；從而只覆蓋到功能測試；更甚至是到了產品釋出的前一刻開發還在更改bug，這裡也就導致了測試沒有更多的時間去迴歸以前的功能，這樣的產品也是極具風險的，另外測試時間的計算是一件很有藝術的事情，首先我不建議測試時間估的太緊湊，慢工出細活這句話我是很認同的；我認為測試的流程應該是這樣的

一、需求熟悉，這是基礎，只有熟悉自己的產品才能覆蓋全面自己的測試點；測試應該比產品更熟悉需求，標準等

二、熟悉功能實現的方式，只有只其所以然才能更好的完成測試，而不是簡單的黑盒或者從功能上去體驗

三、測試環境的搭建；目前很多公司，尤其是網際網路公司，測試環境的搭建更多的依賴開發或者運維人員，也就導致了測試公司的地位比較低，我們必須將測試的所有資源維護在自己手中，才能具有一定的獨立性；在我看來某些特定的測試環境，測試應該比開發更專業，而現在很多公司，測試的很多測試方法都是從開發那邊來取經 ；

四、測試角度覆蓋全面；堅決不能只做功能測試，首先，需求拿到的時候，其實測試的任務就開始了，我們可以從需求上去否定掉一部分不合理的需求，其次，開發的設計方式說明書拿到的時候我們可以針對開發的文件，或者原始碼來進行部分的測試；從設計上是否合理；再次介面測試是絕對不能少的，這部分的測試能從邏輯上或者程式碼上來檢查開發的質量，對於後端的測試時及其重要的；最後才是我們的功能測試；從前端介面上來體驗產品；而到這一步時我覺得產品的問題應該只限於前端的問題，後端的問題應該就比較少了才是合理的；然後還有我們的體驗互動測試和效能測試；

五、測試能力的培養；我們應該針對公司的具體業務，指定一些提升計劃，比如；針對不同的人員分配不同的研究任務，比如效能測試、壓力測試、自動化測試等；每月進行一次彙報，檢視一下一定時間段內個人能力的提升，任何的工作，我覺得一是能賺錢二是能學到東西，起碼不用擔心自己在公司呆的久了反而不好換工作。