目前開發人員對測試人員的工作有一些不太理解：用戶不可能進行的操作，測試人員非要進行操作，甚至找出一些開發人員都沒有想到的操作；有時還設計一些用戶沒有的流程進行測試；還有時提出一些用戶沒有提出的要求，比如非要增加一個列表排序功能；測試組的數據庫服務器本身就是一臺PC機，配置不高，運行復雜程序比較慢，非要提出來要求修改。等等、等等。在開發任務不太忙的時候還能忍受，如果開發任務很緊的時候就容易發生摩擦了。
測試人員到底是怎么想的？怎么有時總是往牛角尖里鉆呢？怎么總是讓人搞不懂？后續章節里就簡單的說說“測試人員的腦袋里到底在想什么呢？”
測試人員測試考慮問題基本有幾個方面：
“測試人員的腦子里到底在想什么呢？”（一）
在一個項目中，測試人員與開發人員的良好合作往往起到事倍功半的作用。縱觀一個成熟的項目，測試與開發都是緊密合作、相得益彰的。在軟件行業說明舉例中大家都習慣于用微軟、IBM、HP等國際大企業來說明，也確實如此，這些大公司都是一些好的借鑒。好像有這么一個規律：凡是做的好的項目，測試與開發的合作也都是比較好的。而在國內一些企業里，由于軟件工程發展相對晚一些，這方面的經驗比較少，好多項目中測試人員和開發人員經常會發生一些摩擦、甚至沖突，一些有經驗的管理人員、開發人員和測試人員還比較好一些，而經驗較少的人員表現比較突出，如果再加上一些管理方面不夠到位的話這種沖突就比較嚴重了，有的項目測試人員和開發人員甚至到了互相不能容忍的地步。這不是夸大其辭，確認經歷過這樣的公司和這樣的人，往往是經驗越豐富的人員對測試與開發的作用越理解的比較透徹。
追其原因，主要是因為測試和開發的工作內容雖然相同，但考慮問題的角度卻各異。這樣有時候站在這個角度看到的問題與另一個角度看到的問題是不相同的。有時這種不相同就會導致爭議發生。如果雙方都能夠站在對方的角度考慮一下就會明白對方為什么要提出這樣的問題。但是站在對方的角度來考慮不是說說就能明白的，有時非得親身體驗一回不可，否則還是有一些不理解。更何況對方是怎么想的、原則是什么都不一定能夠說的很清楚。
往往會聽到這樣的評價：測試人員不知道怎么想的，總是做一些用戶不可能進行的操作；我真服了測試人員，不是好好的測試功能，不知道都在想些什么，非要搞一大堆沒用的數據錄入；我看測試人員故意找茬，本來好好的功能非要鉆牛角尖，找出幾個沒用的BUG來表現自己的水平。等等。
后續章節就測試人員考慮問題的思想因素做一說明，試圖起到拋磚引玉的作用，供開發人員和測試人員來參考。文章中的描述或用詞不妥之處也希望大家指出來我盡快更正，提前道謝了！
“測試人員的腦子里到底在想什么呢？”（二）
系統是否做了該做的事情？還有就是系統是否做了不該做的事情？
今天，在用戶現場的測試人員打電話回來：“我們的系統出現了一個大的問題：通過前臺界面修改一條記錄沒有成功，系統也很正確的進行了提示，可是后臺系統卻把修改信息發了出去，其他廠家開發的系統接收到消息后同時進行了響應的修改，并且把修改成功的信息發送回來了，可是我們的系統卻沒有成功修改，導致業務不能正常進行，這樣的系統根本就不能放行。”
這個案例就是一個很好的說明。測試人員在測試的時候首先會考慮系統是否實現了預期的功能－前臺界面修改記錄不成功進行提醒，但同時還要考慮系統是否做了不該做的事情，在這個案例中就是既然沒有修改成功，那就不應該發送消息給其他系統要求修改相關信息。
這種問題多發生在功能之間的接口或者是多個人開發的系統中。例如在航天史上有名的案例：美國發射火星探測器，整個研發過程都比較嚴密，但是最終登錄失敗了。問題的原因就在于系統出現了問題：火星著陸與著陸后出現不銜接。著陸后系統運行應該在著陸的數據基礎上運行，而項目研發的時候著陸后的系統運行實在數據清空的基礎上運行，根本就沒有考慮到實際情況。
這種情況開發人員與測試人員容易發生爭議的地方是：開發人員認為我做的系統或功能沒有問題，我已經測試通過。有的還會說當初沒有告訴我要這樣做，或者是別人沒有在我的基礎上考慮，或者別人沒有給我傳送我需要的數據。這時如果項目組織不夠好的話測試人員往往要協調多名開發人員或開發團隊來解決問題，有如果不樂觀的話會吃力不討好，無人理睬。
“測試人員的腦子里到底在想什么呢？”（三）
不僅要進行合法性的測試，同時還要考慮非法的是否可以進行。
測試人員認為合法輸入或流程等一定能夠正常進行，同時非法的輸入或者流程不能夠進行，系統應該有所判斷并有相關信息提示。為什么要有提示？不一定所有使用系統的人都知道哪些是非法的。
舉個很簡單的例子：數據錄入的時候，如果沒有進行非法檢查，一些非法字符進入系統很可能會給以后造成很大的數據錯誤，比如一些保留字、特殊字符等等。例如在一個文本框中輸入一個單引號（‘）成功的話，在數據庫中有時執行一條SQL語句的時候會把單引號做為SQL命令而導致SQL腳本執行不成功或者錄入錯誤數據。試想如果在遠程緊急救護系統中把緊急搶救時間1分鐘錯誤成10分鐘后果會是什么？如果關鍵時刻系統出現崩潰會是什么后果？那就不是BUG了，是殺人！
這種情況開發人員往往會說：測試的都是些什么呀？不痛不癢。能不能發現一些重要的、深層的BUG呀？豈不是這個不中要的BUG如果把數據放行進入數據庫，后面就會出現重要的、深層的BUG了。有時對這些BUG不置可否。
“測試人員的腦子里到底在想什么呢？”（四）
健壯性、穩定性
這是測試人員和開發人員最容易產生爭議的問題。測試人員總是從各個角度進行測試，尤其是各個非法操作角度進行測試，測試人員想：不能因為用戶的誤操作導致系統出錯或者崩潰，所以盡量考慮各種非常情況，有的情況開發人員都覺得有點變態了。下面是測試人員和開發人員的一段對話，從中可以看出一些不同點：
開發人員：“用戶輸入數據時怎么可能按住鍵盤不放呢？你這樣按著不放能不出錯嗎？”
測試人員：“用戶是不會故意按著鍵盤不放的，但是有可能不小心會用手或者書之類的東西壓著鍵盤，如果發生這樣的事情，我們的系統總不能崩潰吧？怎么著也應該給個提示或者警告一下。”
有時候用戶是會發生錯誤的，人嗎，誤操作總是難免的，如果有了誤操作系統就出一點小錯，用戶還能忍受，如果出打錯或者崩潰，用戶估計會有意見了。測試人員正式從這個方面進行考慮的。
易用性
一般經常與用戶接觸的人員會對易用性理解深刻，用戶覺得操作繁瑣會要求系統修改的，上帝不滿意了你能不管嗎？
測試人員說了：我操作都感到麻煩，用戶會操作的舒服嗎？
這是測試人員對待系統在易用性方面的心態。
比如測試人員說“在查詢結果中增加一個排序功能或者模糊匹配功能吧，要不查出這么多的數據，要找用戶要的那個數據太不容易了。”
“這個增加功能太慢了，我都等的有點不耐煩了！”
有時這些提示會被開發人員忽略掉的。
“測試人員的腦子里到底在想什么呢？”（五）
安全性
（略）
響應速度、容量、壓力負載
“這個增加功能太慢了，我都等的有點不耐煩了！”如果測試人員覺得時間長，用戶也會有這種感覺的，更何況到用戶使用的時候數據量可能會更多，隨著用戶數據量的增加，速度還會下降的。有時測試人員提出有關速度等性能問題的時候就是基于這個思路提出來的。
盡可能多的發現BUG
測試人員的職責就是找BUG，盡可能多的發現BUG，不管BUG是嚴重的還是輕微的，都要提出來。如果有時系統相對穩定或者測試人員不熟悉系統的時候，會發現很多輕微的BUG，比如顯示錯字、位置不對等等，開發人員會認為這些問題都不是問題而輕視測試人員，從而造成矛盾。
提前、盡早、不斷
測試人員的原則之一。提前發現問題有助于盡早的解決問題降低成本（時間、人力、金錢等成本），也有助于對系統有全盤的把握。
不斷測試原則比較典型的矛盾是這樣：
開發人員：“能不能一次測試完就告訴我有多少問題？總是沒個完。”
要知道BUG是永遠都存在的，不可能一下子發現全部問題的。
足夠好的測試
測試不是無休止的，所以即使你想進行完全的測試是不可能的，這在好多教科書中都有介紹，再加上測試是有成本的，需要花費時間、金錢、人力資源等成本的，有時過多的測試對企業來說是虧本的，因此測試有一個結束時間。但是總不能在不該停止測試的時候停止，否則系統中包含很多問題怎么辦？因此測試既不能過度，也不能過少，進行足夠好的測試就可以了。
這怎么會有矛盾呢？可以看一看開發人員的這句話就明白了：“用戶都發現問題了，測試人員怎么不測試了呢？害的我們費這么大勁去修改。”
管理方式（處理方式）
有的管理人員對測試認識比較深刻，只要是測試人員發現問題，就要求開發人員必須限期修改完成，而不是對問題進行分析、評估并根據開發人員的工作量進行適當的安排。這樣有時開發人員容易與測試人員造成矛盾：這么簡單的問題也要提出來，而且這么多小問題，我哪有時間去改那！測試人員也不高興了，我沒有錯呀，我都把問題發現了，提前告訴你不是很好嗎？要是到了用戶那里豈不是麻煩了？我做了好事不但不感謝，反倒成了我的不是了。但是測試人員也不愿意得罪開發人員呀，所以有時矛盾發展結果就成了開發人員與測試人員私下里達成協議：不記錄問題，與雙方都有利。
爭議處理流程
（略）
缺陷處理成本 環節少
（略）