1.1軟件行業基本介紹
1.4 面試題：在一個web測試頁面上，有一個輸入框，一個計數器（count）按鈕，用於計算一個文本字符串中字母a出現的個數。
思路：字母a區分大小寫嗎？只統計英文字母的a嗎？最長輸入字符是多少，最少輸入字符是多少？對輸入的字符類型是否有限制，是否會自動清除不符合要求的字符？
所以第一步應該是明確需求，然後我們纔開始進行思考如何設計測試用例
通常說來，我們考慮一個測試對象的時候至少從以下六方面來考慮
功能性
兼容性
易用性
可靠性
性能
安全
ll 優秀的軟件測試工程師
一、由單純的測試變成項目質量保證工作
1、測試計劃和測試用例編寫－測試執行－質量報告書寫。
測試人員一般會在開發階段就進行測試計劃和測試用例的編寫和準備工作；在測試階段，我們一般先會做功能測試，等項目功能基本穩定，bug較少了，就開始做兼容性測試、性能測試、安全性測試。兼容性測試保證了產品在多瀏覽器、APP在產品在不同機型下的兼容性；性能測試保證了產品在海量用戶大流量下的服務能力；安全測試能發現產品可能會被攻擊的各個隱患。做完了這些測試以後，人員發佈質量報告，產品上線。
不過，優秀的測試人員需要向上遊和下游拓展測試的領域，把自己放在“質量保障”的角色上，推動整個項目組一起保證質量。
上游的工作包括：
在產品剛立項、進行需求確認的時候，測試人員就會參與進去，仔細地Review需求，看需求是不是完整、有沒有漏洞，這個時候還沒有進入正式開發，修改需求對於項目組來說代價是最少的。在這個環節，測試人員憑藉縝密的推演、發散性的思維，往往能發現很多需求的漏洞，提高了項目的整體效率。
另外，測試人員在完成測試計劃、測試用例以後，會邀請開發、策劃一起來評審測試用例，在這個環節，由於測試人員把每個需求如何細化測試都體現在了用例裏面，就相當於再次把需求分析了個透，往往還能發現很多需求的漏洞。這也是提早發現需求漏洞的有效環節。
我們知道，代碼的質量歸根結底是由開發保證的，測試做的工作，只是發現Bug讓開發修復。如果一個花瓶，一開始就是很完美的；另一花瓶經過了各種修補，看起來比較完美，大家覺得哪個花瓶比較好？當然是第一個花瓶。所以，測試人員應該站在質量保障的立場，想辦法跟項目組溝通、給開發提供工具，讓開發自己把質量保障工作做好。比較可行的一些方式是：提供一些手工用例讓開發自測；給一些自動化的接口和UI測試代碼讓開發自測；部署靜態代碼檢查工具，並推動開發分析和修改發現的問題；有一些做得好的項目已經實現了持續集成，也可以嘗試。
下游的工作包括：
在產品完成了測試以後，就是發佈的環節了，測試人員在發佈的環節也能發揮作用，首先，測試人員爲了部署測試環境，研究自動化部署的技術，可以把上線部署的環節也自動化，以前需要2個小時的部署環節壓縮到半個小時甚至更少，而且更加準確可靠。
如果有些版本修改比較多，上線的質量風險大，測試人員會跟產品一起制定灰度發佈的方案並在技術上進行實現，讓版本先面向一小部分用戶開放，如果發現Bug了，影響的用戶也比較小，Bug改掉以後，再逐漸擴大用戶範圍。
另外，優秀的測試人員還會發動項目組的其他人一起來保證項目質量，比如推動開發進行代碼Review；引入冒煙自測流程，讓開發先自測以後再提交給測試做冒煙測試；通過在項目組分析Bug，讓開發提高自測，降低Bug數量等；引入策劃、交互、視覺在測試階段進行走查，等等各種措施。
二、持續集成探索和自動化測試技術研究
業界都在說持續集成，那持續集成究竟是什麼呢？
持續集成原本的意思是讓開發每提交一次代碼就自動化測試一次，如果自動化測試發現問題了，測試用例就會失敗，開發就會馬上發現這個失敗，並修改代碼。
要做到持續集成可有很多工作要做。
首先就是編譯環節，要把所有編譯的環節都自動化起來，開發每次提交代碼都能進行自動編譯；
編譯完成後，就是靜態代碼檢查的環節，通過靜態代碼檢查的工具檢查代碼的問題，比如，數據庫連接池沒有釋放，參數不匹配等。
靜態代碼檢查完成後，就是單元測試了，單元測試用例一般是開發人員或者測試人員編寫，或者開發和測試合作編寫，保證的是開發內部函數的正確性。一個健康的自動化測試方案中，單元測試用例的佔比是最高的。
然後就是接口測試，一般保證的是後端開發提供給前端開發的HTTP接口，接口一般也比較穩定，用例比較容易維護，所以，接口測試的自動化佔比也可以做到很高。
在接口測試的上層就是針對用戶界面的UI測試了，就像測試人員手工執行一樣，UI自動化測試能操作頁面的元素，完成自動化。不過，由於用戶界面常常要重構，所以我們常常會控制UI自動化測試的規模，只覆蓋主幹的用例。
優秀的測試人員可以把自己的工作儘量自動化，並用持續集成框架串起來，提高工作效率和質量。
三、測試相關工具的開發
優秀的測試人員會開發其他好用、趁手的工具來提高工作效率，比如數據自動生成、報表自動生成、報bug工具等。
其實歸根結底就是一句話：測試人員最核心的工作就是保障項目的質量，各類測試流程、技術、工具和平臺的發展讓我們可以更好地保證項目的質量。
四、業務分析能力
1.分析整體業務流程
不瞭解整個公司的業務，根本就沒辦法進行測試。
2.分析被測業務數據
瞭解整個業務裏面所需的數據有哪些？哪些是需要用戶提供的？哪些是自己提供的？有哪些可以是假數據？有哪些必須是真數據？添加數據的時候可以用哪個庫？
明白了整個軟件的數據庫架構，才能知道哪一個數據是從哪一個表裏頭帶出來的，它的邏輯是什麼，有沒有連帶關係。
3.分析被測系統架構
用什麼語言開發的？用的是什麼服務器？測試它的話需要用什麼樣的環境進行測試？整體的測試環境是什麼樣的？
如果缺少了，需要進行環境搭建，架構搭建。一般去一家新公司之後，架構是搭建好的，瞭解它即可，熟悉之前的這些老員工們使用什麼樣的架構去做的。
4.分析被測業務模塊
整個軟件有哪些模塊，比如說首頁面、註冊頁面、登錄頁面、會員頁面、商品詳情頁面、優惠券頁面等等。
明白有多少個模塊需要測試，每個模塊之間的連帶關係，進而怎樣進行人員分工。
5.分析測試所需資源
我需要幾臺計算機，需要幾部手機，手機需要什麼樣的系統，什麼樣的型號。
比如測一個網站的性能的時候，電腦的配置達不到測試併發5000人的標準，要麼升級電腦的硬件配置，要麼多機聯合，多機聯合時需要幾臺電腦，都需要提前籌劃。
6.分析測試完成目標
我的性能目標是什麼樣的？我的功能目標是什麼樣的？我要上線達到的上線標準是什麼樣的？
性能目標，比如我要達到併發5000人的時候，CPU佔用率不能高於70%，內存佔用率不能高於60%，響應時間不能超過5秒。
功能目標，比如整體的業務流程都跑通，所有的分支流程都沒有問題，所有的接口都能夠互相調用，整體的UI界面沒有問題，兼容性沒有問題等。
把這些問題都弄清楚，測試的思路會非常的清晰。
五、缺陷洞察能力
1.一般缺陷的發現能力
至少你要滿足一般缺陷的發現能力，這個是最基本的，如果要連最簡單的一般的缺陷都發現不了的話，別說優秀測試工程師了，你說你是測試我都不信。
2.隱性問題的發現能力
在軟件的測試過程當中有一些缺陷藏的比較深，有的是性能方面的問題，有的是功能方面的問題，它需要有一些設定特定的條件的情況下才會出現這樣的問題。
比如說買雙鞋必須選擇的是什麼品牌，必須選擇是紅顏色，必須選擇44號，而且必須選擇用特定的支付方式纔會出現這樣的bug的時候，那麼這種就屬於特別隱性的bug，對於這樣的問題的發現能力一定要比別人更強，要找到一些別人可能發現不了的bug。
3.發現連帶問題的能力
當發現了一個缺陷之後，能夠想到通過這個缺陷可能會引發其他哪個地方出現問題，這就叫做連帶的問題。而不是說發現這一個bug之後提了這一個就算完了，一定要有一個察覺，可能其他地方也存在這樣的問題。
4.發現問題隱患的能力
有些軟件裏邊可能有一些操作模塊，或者是代碼寫的接口，表面上沒有什麼問題，但是它是有隱患的，比如說這個接口寫的不穩定，當他傳的數據有一些問題的時候，可能它最後返回的結果就是報錯就是報404或者報亂碼。
5.儘早發現問題的能力
如果你只能停留在界面級別的話，那你根本就沒有辦法達到儘早發現問題的這個能力。
你必須要等到前端人員把每個界面都做好了之後才能進入測試，而我能比你早一個月進入測試了，然後我比你結束測試時間快一個月，而你又比我晚一個月，那麼咱倆的薪資一下就拉開了。
6.發現問題根源的能力
需要知道這個缺陷它到底是由什麼原因產生的，是屬於什麼類型的缺陷，是ui前端人員做的問題，還是後臺接口人員做的問題？
不僅要找到這個bug，還要知道這個bug產生的原因，這樣的測試人員是非常棒的，而且很是受人尊敬，提bug的方式也就不一樣了。
六、團隊協作能力
1.合理進行人員分工
合理的進行人員分工是提高效率的重要保證。
2.協助組員解決問題
比如說測試在趕進度，或者這個軟件項目的質量把控是一個團隊來把控的，協助組員解決問題就顯得尤爲關鍵。
3.配合完成測試任務
一個團隊裏邊的人員分工，他們的任務都是不一樣的，這就是咱們說的配合。你的東西做完了，要輪到我了，我的性能測完了之後該輪到你了，所以整個的一個流程下來之後，大家應該是各司其職，配合得非常緊密的一個過程。
4.配合開發重現缺陷
我給你提bug，你改我的bug，咱們的目的只有一個，就是讓這個軟件變得更好，所以在這樣的情況下，咱們就一定要配合開發。
5.督促項目整體進度
既然是一個團隊協作的過程，就一定要互相的去督促對方，包括督促開發去改bug，因爲開發人員他們有時候工作很忙，他們不知道要先改哪些問題，要後改哪些問題，但是往往有一些缺陷，它影響了測試的這個時間，影響了測試的進度，那麼這個時候就需要測試員去督促開發人員，讓他儘快的去解決你棘手的問題。這個東西能夠提高咱們的測試效率。
6.出現問題勇於承擔
願意背鍋的最後都成爲了領導，不願意背鍋的最後依然是員工。
七、專業技術能力
1.掌握測試基礎知識
基礎知識就是根基，根基打好了，你才能夠更有效地往後期發展，也就是爲了以後的學習做一個鋪墊。如果根基都沒打好，功能測試不會，就想直接學性能，那性能是做不好的。
2.嫺熟運用測試工具
熟悉工具和熟練使用工具完全是兩個概念，熟悉工具基本上等同於不會，遇到過很多簡歷上寫會使用什麼什麼工具，都沒有實際能力。比如loadrunner只會一個簡單的錄製，增強一下腳本，覺得會用了，那知識會用了1/5，其他4/5 都不會。
3.瞭解工具操作原理
它是怎麼樣給服務器發送請求的，是用什麼樣的方式去發送請的，是用什麼樣的方式去監控的，它的操作原理是什麼樣的，咱們要把這件事情搞清楚，這樣的話能有助於更好的去使用這些東西。包括一些請求的協議，每個協議代表什麼意思，它是用來幹什麼的。
4.自主完成測試任務
一定要能夠自己完成一個獨立的內容，獨立的工作，這件事情領導你交給我好了，放心我能給你搞定，要的是這樣的人。
5.找出問題出現原因
找出缺陷的時候，不僅要看它的表面，還要看它的本質。
6.提供問題解決方案
發現問題不是能力，發現問題並提出解決方案纔是真的能力。
7.提供完整測試報告
測試報告能夠說明你表達的清不清楚？領導能不能看懂？還有就是能不能夠把你整個測試的過程給它梳理得非常詳細，人家能夠通過你的報告，能夠瞭解到整個的項目的情況，而不是隻瞭解一個片面的情況。
八、邏輯思考能力
1.判斷邏輯的正確性
面試官也經常會給測試人去出一些邏輯題，邏輯題能夠分析出來你這個人思維有沒有？活躍不活躍？還有他的維度，包括他想的問題的全面性，都能夠判斷得出來。
比如說去買一樣商品，它的裏邊邏輯就會經常會出現很多問題，比如說它的會員的級別，什麼樣的級別去買什麼樣的商品，它的價格不一樣，什麼情況下會給優惠券，什麼樣的情況下不給優惠券？達到多少錢的情況下才能夠使用優惠券？如果說這裏邊的邏輯出現了問題的話，那麼整個的業務不用再測了。
2.對可行性邏輯分析
要去測一個網站的邏輯的時候，一定要先思考這一個業務流程可能會涉及到哪些邏輯，這些邏輯哪些是可行的，有些是正向邏輯，有些是逆向邏輯，都要考慮全面，而不是說只是把正向的邏輯測試全面了，逆向邏輯不考慮。其實往往更容易出錯的地方就是逆向邏輯。
3.思維導圖梳理思路
思維導圖工具能夠起到什麼作用，能夠讓你更有效的進行測試，能夠讓你的思路更清晰。
4.站在客觀角度思考
去測試的時候，不要僅僅只是站在測試人員的角度上去對整個網站進行測試，還更多的要站在用戶的角度，要替用戶考慮。
九、問題解決能力
1.技術上的問題
把自己的個人能力提升起來，多跟別人虛心請教，多去自己想辦法解決問題。
2.工作中的問題
在任何的企業裏邊去工作，肯定會遇到一些工作當中的一些不愉快的事情，而不是什麼事情都會讓你很順心。所以要去處理工作上的一些不順心的事情，不要把它帶到你的工作上，或者是你的生活上，儘可能的去跟別人溝通，去解決這個工作上遇到的麻煩。
3.同事間的問題
在工作當中可能會涉及到跟開發人員的溝通，跟產品人員的溝通，跟ui人員的溝通，跟這三方的人員去溝通的時候，就要用不同的溝通方式。
4.領導層的問題。
如果你覺得你的領導不好，或者說你覺得對你的領導一些建議，不要的去跟同事之間去說他壞話或者怎麼樣的，領導需要的是解決問題的人，而不是製造問題的人。
十、
溝通表達能力
1.和技術人員的溝通
跟開發人員闡述缺陷時要簡潔明瞭、清晰易懂。當發現嚴重缺陷時，也不要大驚小怪，要站在開發人員的角度思考如何解決問題。而不是踩在開發頭上，炫耀自己發現問題的能力。
2.和產品人員的溝通
當對產品提出意見時，要站在用戶的角度去說明自己的想法，而不要主觀認爲不好而要求產品進行修改。
3.和上級領導的溝通
跟領導溝通時要有大局觀，不能只考慮自己部門的情況。並且與領導溝通時，儘量直奔主題，不要拐彎抹角，當與領導意見不一致時，也不要直接反駁，應該先給予認可，再闡述自己的想法。
4.在集體會議中溝通
在集體會議中不要一味的突出自己的個人能力，不要當話癆，也不要默默無聞。適當的提出一些自己的見解，有助於讓大家更加重視你的存在。切記不要在多人會議中，去指責別人和推卸問題。各個部門的同事，都要面子~
5.與下級員工的溝通
與下級溝通時不要擺高姿態，不要讓下級產生畏懼感，應該更多的爲下級解決問題。服務好部門的同事，才能更好的產生凝聚力。
十一、宏觀把控能力
1.有效控制測試時間
測試周期的時間控制，應當採取多種方法去衡量，例如人員能力，人員數量，項目複雜程度，同類項目的測試經驗等多方面去衡量。
2.有效控制測試成本
測試成本指的是人員成本跟時間成本，不要浪費每個人的時間跟勞動力，要讓每個人充分發揮最大的價值。
3.有效制定測試計劃
測試計劃對於一個項目是核心關鍵，它的存在爲了讓測試進行中有依據可查。所以測試計劃，一定要切合實際情況，要經過思考和衡量最後得出計劃安排。
4.有效控制組員情緒
組員的情緒可以直接影響測試進度跟測試的質量，當有組員出現思想問題時，應當及時溝通，採取一些必要的措施去解決問題。而不能裝看不見。
5.有效進行風險評估
任何項目在進行期間都存在許多潛在的風險，例如，人員離職，生病請假，業務變更，需求變更，服務器或其他組件故障等。應當提前做出相應的解決方案，以免到時候手忙腳亂。
6.有效控制測試方向
測試的方向是指測試的目標和測試的範圍，很多項目的測試是有針對性的，例如性能測試，所以在測試中，一定要隨時清楚測試的目標和目的是什麼，以免把時間浪費在無關緊要的業務上。