衆所周知，頭部互聯網公司測試團隊已經逐漸由人海戰術過渡到精幹單體作戰階段，測試人員與開發人員的比例已經由1:1逐漸過渡到1:12甚至更多，而產品質量也是步步高昇。
在測試人員精簡的前提下，他們是如何做到的呢？
祕訣有很多，最關鍵的有兩點，工具和人員。今天就暫且拋開各種輔助提效工具，重點說一下測試人員素質的提升。
傳統意義上的測試人員無非關注以下幾點：
-
良好的業務理解能力
-
良好的溝通表達能力
-
一定的抗壓能力
-
最基礎的技術能力
具備以上素質，基本可以勝任大部分公司的業務功能測試了。但是隨着業務迭代的加速，由於測試人員不能根據具體變動分析到位，在資源有限的條件下，只能是局部重點無腦覆蓋，至於是否命中以及命中了多少，只能根據經驗粗略估算。如果要追求一個較高的場景覆蓋，那隻能增加資源的投入。一是人力的增加，而這明顯與前面提到的比例趨勢背道而馳；二是單人工作時長的延長，但這個明顯只能偶爾爲之，不可持續。
那正確的做法是什麼呢？
提升人員素質，提高單兵作戰能力。不僅需要在測試方面精益求精，還需要深入瞭解開發的技巧。而這方面的提升，可以保證測試人員清楚洞察開發的架構設計與代碼實現，進而針對實際變更，從整體和局部兩方面入手，合理設計測試用例，並編寫針對的腳本，進而提高單位時間的覆蓋率，從而保證質量的一致性。
現在手頭有這麼一個需求，某項服務的IP地址需要進行變更，而該項服務IP地址是通過配置中心的某個值設定的，要求在變更後保證服務的可用性。
那對於測試人員需要如何入手呢？
首要問題是需要評估通過修改配置中心的對應IP地址，是否需要重啓服務才能生效。對於傳統人員來說，可能會先執行一遍測試用例，發現實際結果與預期結果不一致，才能推斷出需要重新啓動該項服務。
那正確的做法呢？
可以從該配置項生效的地方入手。如下文所示，實例是定義在單例模式中：
public static synchronized XXXClientFactory getInstance(address){
if (instance !=null){
return instance;
}else
{
instance = new XXXClientFactory(address);
}
}
很明顯該方法是靜態方法，由此我們可以得出該實例僅僅會初始化一次。如果直接進行配置中心相關配置項的變更，IP變更並不會生效，所以我們應該在變更地址後，果斷重啓服務，這樣前面的試錯就可以避免了，效率自然而然就提高了。由此可見，瞭解單例模式對於測試人員還是很有幫助的。
接下來就讓我們從簡單的單例模式的學習開始吧。Java單例模式有如下5種實現方式。
1、飽漢模式——非線程安全
public class Singleton1 {
private static Singleton1 singleton = null;
private Singleton1() {
}
public static Singleton1 getInstance() {
if (singleton == null) {
singleton = new Singleton1();
}
return singleton;
}
}
該種模式的優點是懶加載，啓動快，資源佔用小，使用時才實例化，無鎖，缺點是非線程安全。
2、飽漢模式——線程安全
public class Singleton {
/**
* 定義一個變量來存儲創建好的類實例
*/
private static Singleton uniqueInstance = null;
/**
* 私有化構造方法，好在內部控制創建實例的數目
*/
private Singleton(){
}
/**
* 定義一個方法來爲客戶端提供類實例
* @return 一個Singleton的實例
*/
public static synchronized Singleton getInstance(){
//判斷存儲實例的變量是否有值
if(uniqueInstance == null){
//如果沒有，就創建一個類實例，並把值賦值給存儲類實例的變量
uniqueInstance = new Singleton();
}
//如果有值，那就直接使用
return uniqueInstance;
}
/**
* 示意方法，單例可以有自己的操作
*/
public void singletonOperation(){
//功能處理
}
/**
* 示意屬性，單例可以有自己的屬性
*/
private String singletonData;
/**
* 示意方法，讓外部通過這些方法來訪問屬性的值
* @return 屬性的值
*/
public String getSingletonData(){
return singletonData;
}
}
該模式優點同上，並且加了鎖，缺點是synchronized 爲獨佔排他鎖，併發性能差。即使在創建成功以後，獲取實例仍然是串行化操作。
3、飽漢模式——雙重加鎖檢查
public class Singleton {
/**
* 對保存實例的變量添加volatile的修飾
*/
private volatile static Singleton instance = null;
private Singleton(){
}
public static Singleton getInstance(){
//先檢查實例是否存在，如果不存在才進入下面的同步塊
if(instance == null){
//同步塊，線程安全的創建實例
synchronized(Singleton.class){
//再次檢查實例是否存在，如果不存在才真的創建實例
if(instance == null){
instance = new Singleton();
}
}
}
return instance;
}
}
該模式是懶加載，線程安全。
4、餓漢模式
public class Singleton {
//定義一個靜態變量來存儲創建好的類實例
//直接在這裏創建類實例，只會創建一次
private static Singleton instance = new Singleton();
//私有化構造方法，好在內部控制創建實例的數目
private Singleton(){
}
//定義一個方法來爲客戶端提供類實例
//這個方法需要定義成類方法，也就是要加static
//這個方法裏面就不需要控制代碼了
public static Singleton getInstance(){
//直接使用已經創建好的實例
return instance;
}
}
該模式優點是天生是線程安全的，使用時沒有延遲，缺點是啓動時即創建實例，啓動慢，有可能造成資源浪費。
5、Holder模式
public class Singleton {
/**
* 類級的內部類，也就是靜態的成員式內部類，該內部類的實例與外部類的實例
* 沒有綁定關係，而且只有被調用到纔會裝載，從而實現了延遲加載
*/
private static class SingletonHolder{
/**
* 靜態初始化器，由JVM來保證線程安全
*/
private static Singleton instance = new Singleton();
}
/**
* 私有化構造方法
*/
private Singleton(){
}
public static Singleton getInstance(){
return SingletonHolder.instance;
}
}
該模式將懶加載和線程安全完美結合的一種方式（無鎖）。（推薦）
以上關於行業內人員變化趨勢的一點個人思考和單例模式的介紹，希望能夠對你有所幫助。
其他文章可以關注微信公衆號測試架構師養成記,還有資料可以領哦~
