上一篇中我們詳細講述了為什么測試是一個技術崗位，測試技術的最高崗位——測試架構師的工作角色、分工以及相關主要的工作內容。想要成為一名合格的測試工程師并不是一件容易的事情，但是想要劃水的人生其實也不難。但是想必來到這里的同學一定是不甘于劃水的人生，那么我們繼續往下看：
軟件測試的人生從測試用例開始
說到軟件測試，那么我們不得不從測試的基本功測試用例的設計開始。那么首先我們應該知道測試用例是什么，這里我們引用 IEEE Standard 610 (1990) 的測試用例的定義開始：
A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
(IEEE Std 829-1983) Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.為特定目標開發的一組測試輸入，執行條件和預期結果，例如執行特定程序路徑或驗證是否符合特定要求。
（IEEE標準829-1983）指定測試項目的輸入，預測結果和一組執行條件的文檔。
軟件測試用例的定義描述得非常清楚，測試用例就是一組有測試輸入、執行條件和預期結果的集合。那么如何設計這樣的一個測試用例呢？
我相信你從任何一個軟件測試的大學教材里面都能看到，例如邊界值法、等價類法、因果圖法、場景法等待。只要一提到等價類方法，我相信很多小伙伴都會想起書本上的三個整型變量組成三角形的例子。這里我們不會和你一起來學習這些基本的方法，講這些內容的書、文章等太多了。如果你對這些內容不熟悉，那么只能說你欠下的技術棧太多了，需要你自己慢慢還債。
在這本專欄中我想說一下所有的書、文章里面都沒有寫的，那就是這些科學的方法也不是用來解決所有測試用例設計問題的方法，就如同我們學習數學的時候，如果一道題目中有兩個未知數那么我們可以通過二元方程解決，如果有一個未知數，那么我們就要用一元方程來解決一樣。
等價類設計測試用例比較適合解決有很多條件組合的輸入方面的測試用例的設計，場景法適合對批量任務、定時任務等業務邏輯進行測試用例設計，邊界值適合于一個輸入框的測試用例設計，同時邊界值還可以和正交試驗方法進行組合使用，因果圖方法比較適合有相互約束的功能的測試用例設計。
無論你是一個測試經理還是一個測試工程師，甚至你是一個測試開發工程師，你也需要知道這些科學的方法，這些科學的方式是軟件測試中輸入項的有效的設計方法，在工作中使用這些科學的方法設計測試用例，可以使你的測試工作更加得可靠和可信。
選擇技術還是選擇業務
伴隨著工作年限的提供，所有人都在面向于業務或者技術的一個選擇。
測試工程師
這上面是完全不同的兩條路，一個是走純業務路線，即測試工程師。測試工程師對自己負責業務很了解，對所有細枝末節的流程都很清楚。在一個團隊中，產品經理對每次新 feature 很了解，因為是他設計的，他有可能也對一些和這些新設計的 feature 相關聯的一些業務邏輯也很清楚，但是他對上上一次乃至更久之前的迭代的 feature 有可能并不了解。
開發工程師對本次開發的功能很熟悉，并且對和本次迭代的feature有交集的一些內容了解，但是對歷史版本的邏輯并不清楚。這里面唯獨業務測試工程師對某一個被測試系統所有的 feature 都很了解，這樣他才能更好地評估一個系統的質量。隨著業務測試工程師的努力，慢慢地會變成測試負責人或者一個對應業務領域的專家。
測試開發工程師
如果要選擇測試開發這條路，那么你會走上一個半測試、半開發的路，在這條職業生涯的路上，你會不斷地coding，不斷重新定義測試。從自動化腳本的撰寫到測試框架的設計、開發和維護，從測試執行到測試平臺的研發和搭建，然后慢慢走向高級測試開發工程師的道路，推進項目級別的持續集成、持續交付、持續部署的進程，推進工程效率的不斷提高。最后會走上測試架構師的角色，這個時候你有可能更加貼合實際，更加的底層。在某一項技術的細節上和開發架構師的知識庫和技能庫相差無幾，但是又多出了很多DevOps相關的內容知識體系，是真個團隊的自動化程度的推進者，或者發展成一個測試開發負責人，管理team內部的交付周期，推動過程化測試進程。
該選擇那一條路？
隨著測試自動化的發展，測試開發工程師和測試工程師最終變成一個矛盾體，測試開發工程師在推動團隊內的自動化程度，通過不斷地開發、引進和探索，釋放大量的業務測試的手工測試工作量。業務測試工程師的很多工作越來越多的交由機器來完成，業務測試工程師會逐漸的變成整個測試進度、測試進程的決策者，輔助測試工具鏈最終完成測試，并評審最終的測試結果。
但是如今市場已經越來越多地開始意識到了自動化可以給團隊交付效率帶來的紅利，因此現在的一個純業務測試工程師的工作機會越來越少了，因此我還是建議很多人選擇第二條路，無論你現在是中級業務測試工程師還是高級業務測試工程師，都要嘗試著去學習測試開發的技術，給自己充電。
測試的技術棧
在掌握測試理論基礎之上你還需要知道如下的知識內容：
- HTTP協議等一些相關的通信協議，掌握各種各樣的協議截獲方法；
- 開發的專業術語：序列化、MVC、NIO等內容；
- 自動化測試框架（這里面包含了WebUI、AppUI和API相關的自動化測試框架）；
- 性能測試工具；
- Linux操作系統相關操作方法；
- 數據庫的一些查詢方法語句；
- 各種消息、協議的模擬手段；
- 理解持續集成、持續交付、持續集成和DevOps；
- 了解敏捷，懂得精益，會用看板；
- 懂得容器化以及容器編排；
- 會一種coding的技術（有基礎的你會什么就深入學習一下對應的，要是都沒有建議學習python）。
上面都是很多星星點點的一些知識點，最后要通過 DevOps 類的平臺可以流程化你的技術體系，達到一種可以通過端到端交付效果的過程。
總結
今天我們從軟件測試工程師基本功測試用例設計開始，討論了測試職業生涯的兩條路，但是就與當今招聘市場的需求，建議大家都多少走到第二條路上。最后介紹了要走上第二條路需要逐漸學習的一些內容，以及對大家的一些建議。