網際網路公司發版節奏快，對於兜底（背鍋）的測試來說，壓力真的很大，不但是考核的問題，還要面對各方指責。
在這浮躁的時代，評價乙個優秀的測試人員，標準不是技術有多牛，開發的工具有多炫，職位有多高，收入令人羨慕。而是，如何務實、用心的為提公升效率和質量，如何交付高質量的版本而努力工作。還是剛入行那句話，不忘初心，方得始終。
提公升質量，先分析缺陷是如何從出生到線上的
1.開發人員沒有進行有效的單元測試，帶著一大堆問題提交；
2.**沒有進行code review，帶著一大堆問題入庫；
3.版本沒有提測標準，帶著一大堆問題到測試環境；
4.測試人員沒有充足的時間，基於黑盒很難覆蓋到每條路徑；
5.生產部署出紕漏，線上沒有進行快速有效的回歸。
1～3都是基於白盒，對於質量就是阿喀琉斯之踵，這部分沒做好，缺陷會猶如源頭之水，接踵而至。
本文要說的是第2點code review。
學會閱讀**
寫自己的**容易，讀別人的**好難。我想說的是，掌握了方法，其實不難。
1.首先，要了解開發對於需求實現的設計方案，了解架構圖、流程圖、時序圖；
2.其次，了解工程設計的層次結構，找到程式的入口；
3.然後，根據找到的入口，就可以從上往下，層層展開了；
以乙個典型的後台服務元件為例，直接對外提供服務的是controller層（程式入口），再往下是service層，負責業務邏輯，再往下是dao層，負責資料操作。當然，也會有一些基於aop的橫向切面邏輯，一般作用於controller層，做一些防重、攔截等特殊性處理。還有一些是公共方法、工具類方法等。
有效的code review
在review**前，要有自己的工作重點，並根據常見問題建立常規檢查點。
以下2點需重點review
1.影響主流程跑通的類和方法；
2.多個地方呼叫到的，影響面大的公共方法；
code review常規檢查點
以下所列只是常規檢查點，實際操作不僅限於以下幾點。
1.異常處理：是否需要捕獲異常，捕獲異常了有沒有處理，捕獲未處理的有沒有往上拋，往上拋的有沒有被上層處理；
// 向上丟擲異常
public
class
demo}}
// 未捕獲異常
public
class
test
public
static
void
main
(string
args
)}
舉個例子
完成乙個方法有a、b、c三種方案，正常情況下走預設的a方案，如果遇到xx問題，走備選方案b，如果遇到xx問題，走備選方案c。同時，還要鑑定備選方案b、c是否合理，是否為最優方案。
// 下段**的補償機制使用了預設值，更好的方案是redis遇到異常，channel返回null，channel嘗試去資料庫取值，db遇到異常再考慮預設值
private
static
final
string
default_channel
="default"
;public
string
loadchannel
(string
key)}}
catch
(exceptione)
}return
channel
;}
// 如果a.getresponsecode()為null，報npeif(
a.getresponsecode
().equals
(constant
.client_response_body
))// 常量放前面則不會報npeif(
constant
.client_response_body
.equals(a
.getresponsecode
()))
log
.info
("linsence入參：{}"
,dto
);// 此處列印的base64碼，耗費磁碟資源，也影響io效能
6.隱私安全：對於金融產品涉及的賬密、證件、手機、銀行卡等敏感資訊是否進行了脫敏處理；
7.資源浪費：浪費記憶體資源、cpu資源等情況；
例如：對變數賦值，而該變數從未使用、字串用＋連線、物件無意義的new了乙個例項等。
demo
demo
=new
demo
();// 此處無需new物件
demo
=createdemo
.invoke
();
@accesscontrol
@notrepeatable
@apioperation
(value
="xx"
,notes
="xx")(
value
="/test"
,method
=requestmethod
.post
)public
responsedto
<?>
demo
(@requestbody
requestdto
<
testdto
>
dto)
dataoutputstream
outputstream
=new
dataoutputstream
(connection
.getoutputstream
());
//如果是高頻呼叫的方法，outputstream沒有關閉流，存在記憶體洩漏隱患
validationerror
("100101"
,"validationerror"
),// 錯誤描述不明確
1.**階段發現和修復問題，效費比是最高的；
2.白盒發現的一些問題，往往是黑盒很難發現的；
3.對研發人員形成**的威懾，不能再隨意的寫**了；
4.能間接提公升版本的提測質量；
5.提公升測試人員的核心競爭力。
code review的利器
後話code review是提公升質量的重要環節，一般以研發人員主，測試為輔共同完成，研發不做，測試有條件的也可以做。由測試提出的問題，需要研發人員配合修復，從個人經歷而言，自下而上大都不會被重視，自上而下推動，可能落地效果更好。筆者認為，記錄下發現的所有問題，問題應驗了，自然會改變研發對測試的固化思維。
python 白盒測試 白盒測試方法
白盒測試是單元測試階段常用到的測試方法，其特點有 1 可以構成測試資料，使特定程式部分得到測試 2 有一定的充分性度量手段 3 可獲得較多工具支援 4 通常只用於單元測試。下邊通過一段 來看一下白盒測試中的邏輯覆蓋 那麼為了清晰，我們畫出乙個該程式的流程圖 1 語句覆蓋 語句覆蓋是最弱的邏輯覆蓋準則...
軟體測試與質量習題答案 白盒測試技術
1單選 2分 以下描述中哪個是正確的 a a.在評審會正式召開之前，評審員必須認真閱讀被審查的工作產品在評審會正式召開之前，評審員必須認真閱讀被審查的工作產品 b.在 評審過程中，應留出足夠的時間讓評審人員與開發人員就現場發現的缺陷修復達成一致意見 c.在 評審會前，必須提前設計測試用例，並在評審過...
黑盒測試 白盒測試
黑盒測試 black box testing，又稱為功能測試或資料驅動測試 是把測試物件看作乙個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程式所有功能需求的輸入條件。黑盒測...