相信大家在測試工作過程中一定遇到許許多多的問題，而且每個人的問題都不太一樣。今天總結小編在測試過程中經常遇到的幾個方面與大家分享一下。

1.測試執行方面

測試過程中，我們常常會擔心測試不夠全面，覆蓋不全。因為我們知道測試不足（沒有覆蓋到足夠的度）極有可能帶來嚴重的後果，但過多的測試就能夠在解決這個問題的同時不帶來弊端嗎？顯然不是的。設計測試用例本意是為了規避測試的隨意性，讓我們測試時既不多測也沒有少測。

很多測試行業的前輩或同事都會在總結測試的時候分析出在測試過程中有些功能可以不需要測試得那麼詳細，有些用例存在的意義很小（甚至是冗餘）。將容易的、明顯的模組/功能進行詳細的測試而複雜的功能沒有得到充分測試，這屬於明顯的資源分佈不均，會帶來嚴重的浪費。

在測試用例設計的過程中也存在過多的執行的現象。比如為了覆蓋一個功能點，有人就會在設計測試用例的時候持有“寧可多，不可少”的觀念，就算是存在著大量重複的測試用例，也不進行刪除和精簡。比如同樣都是測試“地區簡訊黑名單不攔截聯絡人發來的簡訊”功能，那麼測試一個聯絡人發來一條“晚上一起吃飯吧？”和發來一條“週末一起打球吧？”的簡訊，就是一種重複。還有一種測試用例設計中得過多執行現象是，在用例設計過程中寫過多的重複（冗餘）用例，評審的時候再進行刪除，這也是不可取的。

在測試過程中，這樣的過多測試，我們多少都會碰到，這樣的重複測試對我們的能力提升和行為優化是沒有幫助的，因此在測試過程中我們應該留意，主動去克服這些問題。

2.測試範圍方面

對於測試人員來說，漏測風險是難免會存在，這讓所有的測試人員都感到不安。有時候就會出現因為怕承擔責任就去做超出測試範圍的事情，無形中加大了測試的工作量，而不是去按照開發的功能實現去分析測試邊界、測試重點。

比如有的時候，開發只是去修改了一個模組中得一個很小的功能點的實現邏輯（甚至是改動了UI上面的佈局，更甚至只是替換了UI資原始檔），這個時候不去與開發確認修改範圍，而對整個模組進行功能的測試就是一種超出範圍的測試。這樣的超出範圍的測試，也是一種測試能力不夠優秀的表現，而且這也不是 一個追求卓越的測試人員應有的態度。 這種情況下，我們應該及時的去了解開發的實現思路與修改邏輯，對測試範圍進行一個評估，最終得到一個合理的測試範圍。

3.測試文件方面

一個優秀的測試團隊，一定存在著許許多多凝聚了許多人智慧的文件。也一定會有更多的人編寫更多的文件。在編寫文件的時候，首先要明白所編寫的文件的作用，不顧文件編寫初衷也是不可取的。文件最重要的作用一方面是保證資訊傳遞的有效性、便捷性，保證文件在檢視過程中資訊不失真；另一方面是對既有的測試經驗的一種總結和傳承。如果文件在辛苦編寫後再無檢視，那麼該文件就失去了存在的意義。對於許多技術崗位上得同學來說，可文件可能是一件不太招人喜歡的任務，但是文件的整理和編寫對於一個優秀的測試人員來說確實必不可少的一項基本能力。而且對於專案中經驗的積累和傳承，對於工作任務的傳達都具有十分重要的意義。

但是，並不是所有的文件就是越詳細越好，比如一項文件的面向物件是一個工作經驗一年以上的專案組成員，那麼給他一份包含了詳細測試步驟、具體操作、甚至每一步都帶有截圖和標註的文件反而是一種過度的行為。再有比如在測試執行過程中，有時候需要記錄測試的執行。一份包含所有過程、步驟、截圖、風險的詳細文件有時候也不是必須的，而且還有可能降低執行的效率。

4.溝通方面

相信大家一定見過這樣的場景：同一個辦公室裡或者隔著幾道工位的同事，經常會因為一個可能三兩句話就說完的事情而在QQ（或其它通訊工具）上聊半天。這種不合理溝通方法，很大程度上降低了工作的效率，而且也不利於同事之間溝通上的瞭解。

溝通方面還存在一種不同角色間的問題。各方面的進度（可能會給測試帶來Delay壓力）的推進中，有一種不主動去推進，而是等待進度反饋的現象。假如前面的角色進度都正常的話，整理進度對測試的壓力影響不大；但是若前面的角色進度存在著阻塞或者其他情況的Delay，那麼測試的工作往往會收到很大的影響。專案上的排期需要重新制定，測試任務的展開也會出現混亂。倘若上線的時間是定死的，那麼測試的壓力就會非常大，風險也會非常大。

因此溝通上面，能夠儘量的完成當面溝通，及時推進，把可能的突發情況儘可能早的發現並暴露出來，讓各方面都有提前準備，對於測試方面，甚至是各方面的工作都是百利無害的。

5. 問題發現與創新

任何的工作都是在前人工作的經驗的基礎上展開的，從而進入到一片帶有自己色彩的天地。測試工作也不例外。（當一個新人）在進入到一項測試工作中時，往往發現該團隊的工作模式，流程文件，例行產出等都已經存在著成熟的規範或者約定。而這些約定也並不一定是完整的，甚至有時候隨著時代的不同，可能也不見得正確（比如傳統PC軟體的測試到移動APP的測試）。這個時候有的人可能處於對既有流程的尊重，或者對前輩同事的尊重，而不敢提出自己創新的觀點和看法。這個其實從長遠來看，對專案和團隊也是不利的。

比如我們現在的QWERTY鍵盤佈局，是機械打字機時代為了解決打字過快而造成卡鍵問題而發明的，它最初的目的是為了最大程度上降低打字的速度。除去商業和製造業上的一些原因不談，如今大部分人對這種鍵盤模式採取的是適應的態度。但這種鍵盤佈局對於打字速度的提升和打字時手指的受力方面存在著極大的不合理。因此才會有DVORAK和MALT這兩種按鍵佈局方案的產生。

測試工作中，也應該有這種創新的思路和對問題的發現能力。並積極的思索和提出解決方案。

原文連結

如需轉載該篇文章，請註明來自“搜狗測試”