首先，從需求，用戶及研發(fā)角度考慮，要想為產(chǎn)品貢獻(xiàn)最大的力量，就不能只專注于做好測試保證質(zhì)量這一個方面，而應(yīng)該是從多個角度全面衡量。

用戶思維

在工作中，一部分測試同行特別是初入者在對待需求時都過于被動，不太會把產(chǎn)品各個模塊的業(yè)務(wù)串聯(lián)起來，成了因?yàn)樾枨髞砹怂�以做需求，純粹看著需求文檔就開始做測試用例的設(shè)計(jì)了，并沒有想著先把需求理順了想明白了再開始著手。

其實(shí)這個階段也即是非常重要的需求分析及功能點(diǎn)拆解，即使說這主要是產(chǎn)品經(jīng)理們的主要工作，但是他們也并非圣賢，對產(chǎn)品設(shè)計(jì)的細(xì)節(jié)考慮可能并不周全，甚至嚴(yán)重時會出現(xiàn)較大的需求漏洞，引發(fā)較嚴(yán)重的影響。而我們也應(yīng)該具備該項(xiàng)能力，如果不能站在公司戰(zhàn)略層面考慮該需求對業(yè)務(wù)上能帶來哪些促進(jìn)，也至少能站在用戶的角度考慮能給用戶帶來什么價值，能滿足用戶哪方面的需求，同時能及時發(fā)現(xiàn)對于用戶操作過程中的體驗(yàn)問題.

在糗事百科創(chuàng)始人著作的《結(jié)網(wǎng)》一書中，也提出了用戶體驗(yàn)的三大原則：別讓我等，別讓我想，別讓我煩。我覺得作為一名合格的QA是需要具備這方面能力的，但是在實(shí)際工作實(shí)操中還是需要具備溝通技巧，畢竟能對于用戶體驗(yàn)方面的改進(jìn)需要產(chǎn)品經(jīng)理拍板，如果的的確確非常明顯的體驗(yàn)問題，是有必要堅(jiān)持真理說服他們優(yōu)化的，否則還是把話語權(quán)留給他們，我們只是提供建議吧，不然工作中的**味一定會很濃。

架構(gòu)思維

要想設(shè)計(jì)一份有效的測試用例，就必須要對軟件開發(fā)設(shè)計(jì)思路有深入的了解，我們也經(jīng)常有類似的事情，業(yè)務(wù)需求未做任何改變，而架構(gòu)做了優(yōu)化，如果單純地拿著一份根據(jù)業(yè)務(wù)整理出的用例是無法準(zhǔn)確而有效的測試的，架構(gòu)的調(diào)整包括：底層數(shù)據(jù)結(jié)構(gòu)的調(diào)整如分庫分表，服務(wù)化(SOA)，日志的收集處理以及容災(zāi)處理等等，另外，為了能有助于測試開展，我們同樣需要了解開發(fā)技術(shù)，畢竟在測試環(huán)境的搭建及維護(hù)，測試過程中各種場景的模擬特別是異常情況，以及自動化測試，如果不借助于開發(fā)技術(shù)，自動化工作也是很難開展的。

比如被測系統(tǒng)依賴其他系統(tǒng)發(fā)的一條MQ消息而做相應(yīng)的處理，那自動化代碼中為了驗(yàn)證該邏輯，就需要MOCK這條消息(即設(shè)置樁Stub)并且發(fā)送到某個管道中，讓被測應(yīng)用接受并處理它，如果連MQ是什么都不知道，也不知道如何在代碼中發(fā)送消息，那這個部分的自動化測試是沒法開展下去了。

上面只是舉了一個例子，總結(jié)一下，需要具備的架構(gòu)思維包括：

1)了解并熟悉開發(fā)使用的技術(shù)及開發(fā)框架，比如用到的Spring MVC，Mybatis，Redis，前端HTML，JS，相關(guān)協(xié)議等(視不同項(xiàng)目具體情況而有所不同);

2)理解研發(fā)設(shè)計(jì)的架構(gòu)及設(shè)計(jì)思路，并考察開發(fā)設(shè)計(jì)是否滿足業(yè)務(wù)需求;

3)Review技術(shù)方案時，考察是否滿足易維護(hù)性，易擴(kuò)展以及對性能和安全的要求，并且在關(guān)鍵業(yè)務(wù)出現(xiàn)異常時是否添加報(bào)警等，而這一點(diǎn)也是大多數(shù)從事功能測試的同學(xué)最易忽略的。

測試思維

如果要特意區(qū)分用戶思維和架構(gòu)思維的話，在測試過程中，就要額外關(guān)注：以嚴(yán)謹(jǐn)?shù)臏y試設(shè)計(jì)方法覆蓋需求功能點(diǎn)及代碼分支，具有場景思維和對異常情況的考察。對此我們可以細(xì)化總結(jié)為以下幾點(diǎn)：

1.逆向思維

比如我們經(jīng)常需要對接口做測試，通過輸入驗(yàn)證輸出，如果我們使用各種輸入都無法得到接口設(shè)計(jì)中某一種輸出的情況時，就需要從輸出來逆向推導(dǎo)輸入，另外比如驗(yàn)證一些異常情況，接口需要返回一些error code，使用正常手段是肯定不能得到的，就需要為了出現(xiàn)該error code借助環(huán)境及工具來模擬。另外，我們在分析很多問題時，同樣也離不開逆向思維。

2. 組合思維

比如軟件在多用戶，多進(jìn)程，多次執(zhí)行等情況下，都可能出現(xiàn)意想不到的缺陷，甚至對于復(fù)雜的業(yè)務(wù)場景，在對同一份數(shù)據(jù)進(jìn)行操作時，不同子業(yè)務(wù)并行執(zhí)行情況下，都有可能造成數(shù)據(jù)上的錯誤，特別是對于與核心數(shù)據(jù)有關(guān)的業(yè)務(wù)上(如money)，是否添加行級鎖都是需要測試到的，同時，不同業(yè)務(wù)不同的操作順序，組合方式下，不同的維度等都有可能出現(xiàn)bug。

3. 全局思維

即能把握整個項(xiàng)目的多個方面，多個團(tuán)隊(duì)的任務(wù)及分工，整體的數(shù)據(jù)流及業(yè)務(wù)流，從全局思考是否滿足業(yè)務(wù)需求，這其實(shí)并不只是說對于需求的評審，更多的是關(guān)注上下游相關(guān)聯(lián)的系統(tǒng)或接口等，凡是涉及跨團(tuán)隊(duì)開展的工作，一定就需要更多的溝通協(xié)調(diào)，很明顯的就體現(xiàn)在對業(yè)務(wù)理解不正確，接口定義有誤，具有全局思維的人更能在大型項(xiàng)目中游刃有余，體現(xiàn)其leader的潛質(zhì)，畢竟做leader就需要關(guān)注本部門之外其他部門都在干些什么，以備能做出對大局有利的決定。

4. 兩極思維

即站在事情的兩個極端來考慮，比如數(shù)據(jù)上的無窮大與無窮小，在數(shù)據(jù)存儲上，數(shù)據(jù)庫層面字段設(shè)置為int與bigint所支持的數(shù)量級是不一樣的，基于業(yè)務(wù)數(shù)據(jù)，如果存在超過int的長度的數(shù)據(jù)，那么在存儲上以及代碼中，都需要做相應(yīng)支持，否則就只會顯示到該類型的最大值了，而且在業(yè)務(wù)層面也經(jīng)常有兩個極端的情況，比如商家入駐開店，很多時候都只是考慮到開店該怎么做，卻忽略關(guān)店的情況。其實(shí)在邊界值用例設(shè)計(jì)方法中也用到了兩極思維模式。

5. 簡單思維

簡單思維表現(xiàn)在很多方面，比如經(jīng)常非常嚴(yán)重的bug都可能是犯了一個很簡單的錯誤引起，在處理測試環(huán)境時經(jīng)常出現(xiàn)無法正常訪問，也許可能只是磁盤空間滿了而已或者一個簡單的配置不正確引起，在日常工作中這樣的例子非常多，我們也要善于一層一層剝開問題的現(xiàn)象，找到其本質(zhì)，就好比剝洋蔥一樣，不要一開始就把問題想的過于復(fù)雜，往往事情并沒有那么復(fù)雜。

6. 比較思維

比較思維其實(shí)貫穿在我們整個測試生涯中，測試本來也就是一種驗(yàn)證，根據(jù)實(shí)際結(jié)果跟預(yù)期結(jié)果對比。而且我們在平時工作排查問題時，也有非常多需要去對比的，比如配置文件的差異，環(huán)境的差異引起的不正常結(jié)果，此外，我們也通過svn中代碼diff的差異來明確改動的范圍制定回歸策略。還比如在做一些前后兩個版本吐出的數(shù)據(jù)差異時，頁面顯示差異時，都可以使用diff的思想來開展自動化的工作，大大提高效率。其中，包括我很久之前寫的《我在蘭亭這三年(九)之AutoDiff自動化測試框架》也是基于比較的思維。

總之，用好了以上幾種思維方式，我想在以后的測試工作中，一定更加的游刃有余，有效且高效!