十多年前我在上一家公司的時(shí)候看到過(guò)內(nèi)部有個(gè)網(wǎng)站有一個(gè)Hard Problems in Test的列表，上面大概有三四十個(gè)問(wèn)題的樣子，是各個(gè)部門的測(cè)試同學(xué)提供的。但可惜后來(lái)那個(gè)list失傳了，我很后悔自己當(dāng)時(shí)沒(méi)有保存一份。后來(lái)很多次我都想要找到那份list，因?yàn)樯厦媪械哪切﹩?wèn)題指出了測(cè)試專業(yè)在自身專業(yè)性上的巨大發(fā)展空間。那份list上的問(wèn)題讓當(dāng)時(shí)的我相信，軟件測(cè)試這件事情本身的難度一點(diǎn)都不亞于軟件開(kāi)發(fā)，甚至可能更難一點(diǎn)。

如果今天要重建這么一份Hard Problems in Test列表，下面這些問(wèn)題是我會(huì)加到這份列表上的[1]。

一 測(cè)試充分度(Test Sufficiency)

如何回答“測(cè)夠了嗎“(包括測(cè)新和測(cè)舊)。代碼覆蓋率是衡量測(cè)試充分性的起點(diǎn)，但遠(yuǎn)遠(yuǎn)不是終點(diǎn)。要回答”測(cè)夠了嗎“，至少還要考慮是否測(cè)了所有的場(chǎng)景、所有的狀態(tài)、所有的狀態(tài)轉(zhuǎn)移路徑、所有的事件序列、所有可能的配置、所有可能的數(shù)據(jù)等等等等。即便如此，我們可能還是無(wú)法100%確信我們已經(jīng)測(cè)夠了。可能我們最終只能做到非常趨近于測(cè)夠了[2]。

二 測(cè)試有效性(Test Effectiveness)

如何評(píng)價(jià)一組測(cè)試用例的發(fā)現(xiàn)bug的能力。有效性(發(fā)現(xiàn)bug的能力)和充分性(測(cè)夠了沒(méi)有)是兩個(gè)正交的屬性。評(píng)價(jià)測(cè)試用例有效性可以通過(guò)正向的分析進(jìn)行，例如，分析測(cè)試用例是否校驗(yàn)了所有在測(cè)試過(guò)程中SUT落庫(kù)的數(shù)據(jù)。更具有通用性的做法是變異測(cè)試(Mutation Testing)，即在被測(cè)代碼里注入不同的“人造bug”，統(tǒng)計(jì)多少能被測(cè)試用例感知到。目前變異測(cè)試我們已經(jīng)有工程化規(guī)模化的落地了，后續(xù)的工作重點(diǎn)有：1)如何防止鈍化(或曰“殺蟲劑效應(yīng)”)，2)不但對(duì)被測(cè)代碼進(jìn)行注入，還能對(duì)配置、數(shù)據(jù)等進(jìn)行更全面的注入。

三 測(cè)試用例瘦身

以前廣告行業(yè)有句話：我知道廣告費(fèi)有一半是浪費(fèi)掉的，但不知道哪一半是浪費(fèi)掉的[3]。

軟件測(cè)試也有類似的困惑：那么多用例，要花那么多時(shí)間去跑，我知道這里面有很多時(shí)間是浪費(fèi)掉的，但我不知道哪些時(shí)間是浪費(fèi)掉的。浪費(fèi)的形式包括：

• 冗余步驟：有些是浪費(fèi)在一些重復(fù)的步驟上，每個(gè)用例都要去做一些類似的數(shù)據(jù)準(zhǔn)備，每個(gè)用例都要去執(zhí)行一些中間過(guò)程(這樣才能推進(jìn)到下一步)。
• 等價(jià)類：一個(gè)支付場(chǎng)景，我要不要在所有的國(guó)家、所有的幣種、所有的商戶、所有的支付渠道和卡組的排列組合都測(cè)一遍?這么測(cè)，代價(jià)太高。不這么測(cè)，我擔(dān)心可能某個(gè)特定商戶在某個(gè)特定國(guó)家有個(gè)特定邏輯我就漏掉了。對(duì)于具體的業(yè)務(wù)，還可以進(jìn)行人肉分析。有沒(méi)有更通用的、而且比較完備和可靠的等價(jià)類分析的技術(shù)手段?
• 我有N個(gè)用例，我猜這N個(gè)用例里面可能存在M個(gè)用例，即使刪掉這M個(gè)用例，剩下的N-M個(gè)用例的效果和之前N個(gè)用例的效果一樣。如何識(shí)別是否存在這樣的M個(gè)用例、如果存在的話是哪M個(gè)。

我參加過(guò)內(nèi)部一場(chǎng)質(zhì)量線晉升到P9的評(píng)審，當(dāng)時(shí)有個(gè)評(píng)委問(wèn)了那位同學(xué)一個(gè)問(wèn)題：“那么多測(cè)試用例，以后你怎么刪”。這個(gè)問(wèn)題看似簡(jiǎn)單，其實(shí)非常難。我覺(jué)得，從原理上來(lái)說(shuō)，如果測(cè)試充分度和測(cè)試有效性的度量都做的非常好了、度量成本非常低了，我們是可以通過(guò)大量的不斷的嘗試來(lái)刪用例的。這是一種工程化的思路，也許還有其他的理論推導(dǎo)的思路。

四 測(cè)試分層

很多團(tuán)隊(duì)都會(huì)糾結(jié)到底要不要做全鏈路回歸、做到什么程度。這個(gè)問(wèn)題的核心點(diǎn)就是：有沒(méi)有可能、有沒(méi)有一種做法，只要把系統(tǒng)間的邊界約定的足夠好足夠完整，就可以做到在改動(dòng)一個(gè)系統(tǒng)的代碼后，不需要和上下游系統(tǒng)進(jìn)行集成測(cè)試，只要按照邊界約定驗(yàn)證好自己的代碼就可以確保沒(méi)有任何regression了。

包括我在內(nèi)的很多人相信那是可能的，但既無(wú)法證明，也不敢在實(shí)操中就完全不跑集成。我們也缺乏可以完全復(fù)制的成功經(jīng)驗(yàn)，缺乏一套完整的方法論指導(dǎo)開(kāi)發(fā)團(tuán)隊(duì)和QA團(tuán)隊(duì)要怎么做就可以達(dá)到回歸無(wú)需集成上下游。

有時(shí)候，我覺(jué)得我現(xiàn)在就像是哥德堡的市民，不斷的走啊走，嘗試找出一條一次性不重復(fù)的走過(guò)那7座橋的路線。但也許就有那么一天，有一個(gè)像歐拉那樣的人會(huì)出現(xiàn)在我面前，用理論證明告訴我，那是不可能的。

五 減少分析遺漏

分析遺漏是很多故障的原因。開(kāi)發(fā)做系分的時(shí)候，有一個(gè)corner case沒(méi)考慮到、沒(méi)有處理。測(cè)試做測(cè)分的時(shí)候，忘記考慮某個(gè)特殊場(chǎng)景了。兼容性評(píng)估，評(píng)估下來(lái)沒(méi)有兼容性問(wèn)題的，但結(jié)果是有的。而且很多時(shí)候，分析遺漏屬于unknown unknowns，我壓根就不知道我不知道。有沒(méi)有一套方法和技術(shù)，可以減少分析遺漏，可以把unknown unknowns轉(zhuǎn)化為knowns?

六 用例自動(dòng)生成

Fuzz Test、Model Based Test、錄制回放、Traffic Bifurcation(引流)等都是自動(dòng)生成用例的手段。有些已經(jīng)比較成熟(例如單系統(tǒng)的錄制回放、引流)，有些多個(gè)團(tuán)隊(duì)都在探索(例如Fuzz)，有些則一直沒(méi)有大規(guī)模的成功實(shí)踐(例如MBT)。我們也有過(guò)探索如何從PRD里通過(guò)NLP來(lái)生成用例。用例自動(dòng)生成中，有時(shí)候難點(diǎn)還不是生成test steps，難度反而是怎么生成test oracle。Anyway，測(cè)試用例自動(dòng)生成是一個(gè)非常大的領(lǐng)域，這個(gè)方向上未來(lái)可以做的還非常多。

七 問(wèn)題自動(dòng)排查

包括線上和線下。對(duì)于比較初級(jí)的問(wèn)題，自動(dòng)排查方案往往有兩個(gè)局限性。首先，方案不夠通用，多多少少比較定制化。其次，比較依賴人工積累規(guī)則(說(shuō)的好聽(tīng)點(diǎn)叫“專家經(jīng)驗(yàn)”)，主要是通過(guò)記錄和重復(fù)人肉排查的步驟來(lái)實(shí)現(xiàn)。然而，每個(gè)問(wèn)題都不完全一樣，問(wèn)題稍微一變，之前的排查步驟可能就不work了?，F(xiàn)在有一些技術(shù)，比如調(diào)用鏈路的自動(dòng)比對(duì)，對(duì)排查問(wèn)題和缺陷自動(dòng)定位很有幫助。

八 缺陷自動(dòng)修復(fù)

阿里的Precfix、Facebook的SapFix等是目前比較知名的一些工業(yè)界的做法。但總的來(lái)說(shuō)，現(xiàn)有的技術(shù)方案，都有這樣那樣的局限性和不足，這個(gè)領(lǐng)域還在相對(duì)早期階段，后面的路還很長(zhǎng)。

九 測(cè)試數(shù)據(jù)準(zhǔn)備

測(cè)試用例的一個(gè)重要設(shè)計(jì)原則是：測(cè)試用例之間不應(yīng)該有依賴關(guān)系，一個(gè)測(cè)試用例的執(zhí)行結(jié)果不應(yīng)該受到其他測(cè)試用例的執(zhí)行結(jié)果(包括是否執(zhí)行)的影響?；谶@個(gè)原則，傳統(tǒng)的最佳時(shí)間是確保每個(gè)測(cè)試用例都應(yīng)該是自給自足的：一個(gè)用例需要觸發(fā)的后臺(tái)處理流程應(yīng)該由這個(gè)用例自己來(lái)觸發(fā)，一個(gè)測(cè)試用例需要的測(cè)試數(shù)據(jù)應(yīng)該自己來(lái)準(zhǔn)備，等等。但如果每個(gè)用例所需要用到的測(cè)試數(shù)據(jù)都是自己來(lái)從頭準(zhǔn)備的，執(zhí)行效率就比較低。怎么既不違背“測(cè)試用例之間不應(yīng)該有依賴關(guān)系”的大原則，又能減少測(cè)試數(shù)據(jù)的準(zhǔn)備時(shí)間?

我設(shè)想的是一種更加完備的數(shù)據(jù)銀行。每個(gè)測(cè)試用例執(zhí)行完后，都會(huì)把它自己產(chǎn)生的數(shù)據(jù)交給數(shù)據(jù)銀行，例如，一個(gè)在某個(gè)特定國(guó)家的已經(jīng)通過(guò)KYC、已經(jīng)綁了一張卡的會(huì)員，一筆已經(jīng)支付成功的交易，一個(gè)已經(jīng)完成入駐簽約流程的商戶。下一個(gè)測(cè)試用例開(kāi)始的時(shí)候，會(huì)先問(wèn)一下數(shù)據(jù)銀行：“我要一個(gè)滿足這樣這樣條件的商戶，你有沒(méi)有”。上個(gè)用例跑出來(lái)的那個(gè)商戶正好符合條件，數(shù)據(jù)銀行就會(huì)把商戶“借”給這個(gè)用例用。而且一旦借出，直到被歸還前，這個(gè)商戶不會(huì)被借給其他用例。

經(jīng)過(guò)一段時(shí)間的運(yùn)行，數(shù)據(jù)銀行能夠?qū)W習(xí)到每個(gè)測(cè)試用例需要什么樣的數(shù)據(jù)、以及會(huì)產(chǎn)生什么樣的數(shù)據(jù)。這個(gè)知識(shí)是通過(guò)學(xué)習(xí)得到的，不需要人肉去添加描述，所以也能適用于老系統(tǒng)的存量用例。有了這個(gè)知識(shí)，數(shù)據(jù)銀行可以實(shí)現(xiàn)兩個(gè)優(yōu)化：

• 一次測(cè)試執(zhí)行批次開(kāi)始后，數(shù)據(jù)銀行會(huì)看到這個(gè)批次中后面那些用例需要什么樣的數(shù)據(jù)，提前先準(zhǔn)備起來(lái)。這樣，等執(zhí)行到那些用例的時(shí)候，數(shù)據(jù)銀行里就已經(jīng)有符合條件的數(shù)據(jù)準(zhǔn)備好了。
• 根據(jù)每個(gè)測(cè)試用例需要什么樣的數(shù)據(jù)、以及會(huì)產(chǎn)生什么樣的數(shù)據(jù)，數(shù)據(jù)銀行可以合理的編排測(cè)試用例的執(zhí)行先后次序，最大化的實(shí)現(xiàn)測(cè)試數(shù)據(jù)的復(fù)用，減少測(cè)試數(shù)據(jù)的量和準(zhǔn)備開(kāi)銷。

測(cè)試銀行把測(cè)試數(shù)據(jù)“借”給用例的時(shí)候，可以有多種不同的模式。可以是獨(dú)占(exclusive)的，也可以是共享的。共享的也可以指定共享讀、共享寫、還是都只讀不能寫(例如，一個(gè)商戶可以被多個(gè)用例用來(lái)測(cè)試下單支付結(jié)算場(chǎng)景，但這些用例都不可以去修改這個(gè)商戶本身，例如重新簽約)。

如果把開(kāi)關(guān)、定時(shí)任務(wù)等resource也作為一種廣義的測(cè)試數(shù)據(jù)由數(shù)據(jù)銀行來(lái)管理，能實(shí)現(xiàn)測(cè)試用例盡可能并行執(zhí)行。例如，有N個(gè)用例都需要修改一個(gè)開(kāi)關(guān)值，這N個(gè)用例如果并行執(zhí)行的話就會(huì)相互影響，他們相互之間應(yīng)該串行執(zhí)行。但N個(gè)用例中的任何一個(gè)，都可以和這N個(gè)用例之外的用例并行執(zhí)行。數(shù)據(jù)銀行掌握了每個(gè)用例對(duì)各種資源的使用模式的詳細(xì)情況，再加上每個(gè)用例的平均運(yùn)行時(shí)間等數(shù)據(jù)，就可以最優(yōu)化、最準(zhǔn)確的對(duì)一批測(cè)試用例進(jìn)行編排，做到可以并行的都盡可能并行、不能并行的確保不并行，而且還可以在一個(gè)批次的執(zhí)行過(guò)程中不斷的調(diào)整余下還未執(zhí)行的用例的編排。

這樣一個(gè)數(shù)據(jù)銀行是普遍適用的，不同業(yè)務(wù)之間的差異無(wú)非是具體的業(yè)務(wù)對(duì)象和resource不一樣。這些差異可以通過(guò)插件形式實(shí)現(xiàn)。如果有這么一個(gè)通用的數(shù)據(jù)銀行[4]，可以很方便的adopt，大量的中小軟件團(tuán)隊(duì)的測(cè)試效率都可以得到明顯的提高。這樣的一個(gè)更加完備的數(shù)據(jù)銀行的想法，我到目前為止還只是想法，一直沒(méi)有機(jī)會(huì)實(shí)踐。

十 異常測(cè)試

一個(gè)分布式系統(tǒng)，它的內(nèi)部、內(nèi)部各部分之間以及它和外部的交互都會(huì)出現(xiàn)各種異常：訪問(wèn)超時(shí)、網(wǎng)絡(luò)連接和耗時(shí)的抖動(dòng)、連接斷開(kāi)、DNS無(wú)法解析、磁盤/CPU/內(nèi)存/連接池等資源耗盡等等。如何確保系統(tǒng)的行為(包括業(yè)務(wù)邏輯、以及系統(tǒng)自保護(hù)措施如降級(jí)熔斷等)在所有的情況下都是符合預(yù)期的?今天我們的線上演練(本質(zhì)上也是一種異常測(cè)試))已經(jīng)做了很多了。如何把更多的問(wèn)題提前到線下來(lái)發(fā)現(xiàn)?對(duì)于一個(gè)復(fù)雜的分布式系統(tǒng)來(lái)說(shuō)，要遍歷所有可能出現(xiàn)異常的地方和所有可能出現(xiàn)的異常，異常用例的數(shù)量是非常大的。此外，某些異常情況下，系統(tǒng)對(duì)外表現(xiàn)出來(lái)的行為應(yīng)該沒(méi)有變化;而另一些異常情況下，系統(tǒng)行為是會(huì)有變化的。對(duì)于后一類，如何給出每一個(gè)異常用例的預(yù)期結(jié)果(即test oracle)，也是比較有難度的。

十一 并發(fā)測(cè)試(Concurrency Test)

并發(fā)(concurrency)可能出現(xiàn)在各個(gè)level：數(shù)據(jù)庫(kù)層面，對(duì)同一張表、同一條記錄的并發(fā)讀寫;單系統(tǒng)層面，同一個(gè)進(jìn)程內(nèi)的多個(gè)線程之間的并發(fā)，單服務(wù)器上的多個(gè)進(jìn)程之間的并發(fā)，以及單個(gè)服務(wù)的多個(gè)實(shí)例之間的并發(fā);業(yè)務(wù)層面，對(duì)同一個(gè)業(yè)務(wù)對(duì)象(會(huì)員、單據(jù)、賬戶等)的并發(fā)操作，等等。傳統(tǒng)的并發(fā)測(cè)試是基于性能測(cè)試來(lái)做的，有點(diǎn)靠撞大運(yùn)，而且經(jīng)常是即便跑出問(wèn)題來(lái)了也會(huì)被忽視或者無(wú)法repro。并發(fā)測(cè)試領(lǐng)域，我接觸過(guò)的一些成果包括Microsoft的CHESS以及阿里的譚錦發(fā)同學(xué)在探索的分布式模型檢查&SST搜索算法。

十二 回滾的測(cè)試

安全生產(chǎn)三板斧宣傳了多年，在阿里經(jīng)濟(jì)體內(nèi)大家都能做到“可回滾”了。但我所觀察到的是：很多時(shí)候我們有回滾的能力，但是對(duì)回滾后系統(tǒng)的正確性，事前保障的手段還不夠。我們更多的是靠灰度和監(jiān)控等事后手段來(lái)確?；貪L不會(huì)回滾出問(wèn)題來(lái)。事實(shí)上，過(guò)去兩年，我自己已經(jīng)親身經(jīng)歷過(guò)好幾次回滾導(dǎo)致的線上故障。回滾測(cè)試的難度在于：需要覆蓋的可能性非常多，一個(gè)發(fā)布可能在任何一個(gè)點(diǎn)上回滾?；貪L可能還會(huì)引發(fā)兼容性問(wèn)題：新代碼生成的數(shù)據(jù)，在新代碼被回滾后，老代碼是否還能正確的處理這些數(shù)據(jù)。

十三 兼容性測(cè)試

代碼和數(shù)據(jù)的兼容性問(wèn)題有很多形式。例如，如何確保新代碼能夠正確的處理所有的老數(shù)據(jù)?有時(shí)候，老數(shù)據(jù)是幾個(gè)月前的老代碼產(chǎn)生的，例如，一個(gè)正向支付單據(jù)可能會(huì)到幾個(gè)月以后才發(fā)生退款退票。有時(shí)候，老數(shù)據(jù)可能就是幾分鐘前產(chǎn)生的：用戶的一個(gè)操作，背后的流程執(zhí)行到中間的時(shí)候代碼被升級(jí)了。驗(yàn)證這些場(chǎng)景下的兼容性的難度在于：需要驗(yàn)證的可能性太多了。今天的退款請(qǐng)求對(duì)應(yīng)的正向單據(jù)，可能是過(guò)去很多個(gè)版本的代碼產(chǎn)生的。一個(gè)業(yè)務(wù)流程執(zhí)行到中間具體什么地方代碼被升級(jí)了，可能性也非常多。

異常測(cè)試、并發(fā)測(cè)試、回滾測(cè)試、兼容性測(cè)試，這些問(wèn)題的一個(gè)共同點(diǎn)是：我們知道這些問(wèn)題是可能存在的，但要測(cè)的話，需要測(cè)的可能性又太多。

十四 Mock

測(cè)試的有效性也依賴于mock的正確性。既然是mock，它和被mock的服務(wù)(包括內(nèi)部的、二方的和三方的)的行為就多多少少會(huì)有差異。這種差異就有可能導(dǎo)致bug被漏過(guò)。前人也為此想出了“流量比對(duì)”等辦法。我曾經(jīng)有另一個(gè)想法：“一鴨三吃”。也就是說(shuō)，通過(guò)bundle和compiler instruction等方法，讓同一套源代碼支持三種不同的編譯構(gòu)建模式：

• 正常模式：這就是和今天的編譯構(gòu)建是一樣的，產(chǎn)出的構(gòu)建物是拿去生產(chǎn)環(huán)境跑的。
• Mock模式：這個(gè)模式編譯出來(lái)的就是該服務(wù)的一個(gè)mock，但由于是同一套代碼編譯出來(lái)的，最大可能的保留了原來(lái)的業(yè)務(wù)邏輯，做到最大限度的仿真。而且由于是同一套代碼編譯出來(lái)的，后期也不會(huì)有“脫鉤”的擔(dān)心，應(yīng)用代碼里的業(yè)務(wù)邏輯變化都能及時(shí)反映在mock里，大大減少mock的人肉維護(hù)工作量。
• 壓測(cè)模式：這個(gè)模式編譯出來(lái)的也是一個(gè)mock，但這個(gè)mock是用來(lái)給(上游)做性能測(cè)試用的。過(guò)去在線下的性能壓測(cè)中經(jīng)常遇到的情況是：我們想要壓的系統(tǒng)還沒(méi)到瓶頸，這個(gè)系統(tǒng)的下游系統(tǒng)(往往是一個(gè)測(cè)試環(huán)境)反而先到瓶頸了。壓測(cè)模式編譯出來(lái)的這個(gè)mock犧牲了一部分的業(yè)務(wù)邏輯仿真，但能確保這個(gè)mock本身性能非常好，不會(huì)成為性能瓶頸(但對(duì)lantency仍然是仿真的)。

這個(gè)“一鴨三吃”的想法so far還停留在想法層面，我還一直沒(méi)有機(jī)會(huì)實(shí)踐一下。

十五 靜態(tài)代碼分析

有一些類型的問(wèn)題，要用通常意義上的軟件測(cè)試來(lái)發(fā)現(xiàn)，難度和成本很高，但反而是通過(guò)靜態(tài)代碼分析來(lái)發(fā)現(xiàn)反而比較容易。例如，ThreadLocal變量忘記清除，會(huì)導(dǎo)致內(nèi)存溢出、會(huì)導(dǎo)致關(guān)鍵信息在不同的不同的上游請(qǐng)求之間串錯(cuò)。另一個(gè)例子是NullPointerException。一種做法是通過(guò)fuzz testing、異常測(cè)試等手段來(lái)暴露代碼里的NPE缺陷，以及可以在執(zhí)行測(cè)試回歸的時(shí)候觀察log里面的NPE。但我們也可以通過(guò)靜態(tài)代碼分析，更早的就發(fā)現(xiàn)代碼里面可能存在的NPE。有一些并發(fā)問(wèn)題也可以通過(guò)靜態(tài)代碼分析來(lái)早期準(zhǔn)確發(fā)現(xiàn)。總之，我們希望盡可能多的通過(guò)靜態(tài)代碼分析來(lái)防住問(wèn)題。

十六 形式化驗(yàn)證(Formal Verificaition)

除了在協(xié)議、芯片、關(guān)鍵算法等上面的運(yùn)用以外，形式化方法在更偏業(yè)務(wù)的層面是否有運(yùn)用的價(jià)值和可能?

十七 防錯(cuò)設(shè)計(jì)(Mistake Proof)

嚴(yán)格來(lái)說(shuō)，防錯(cuò)設(shè)計(jì)并不是software testing范疇內(nèi)的。但做測(cè)試做久了就發(fā)現(xiàn)，有很多bug、很多故障，如果設(shè)計(jì)的更好一點(diǎn)，就壓根不會(huì)發(fā)生(因此也就談不上需要測(cè)試了)。去年我總結(jié)了一下支付系統(tǒng)的防錯(cuò)設(shè)計(jì)，后面希望能看到在各類軟件系統(tǒng)形態(tài)下的防錯(cuò)設(shè)計(jì)原則都能總結(jié)出來(lái)，另外，最好還能有一些技術(shù)化的手段來(lái)幫助更好的落地這些防錯(cuò)設(shè)計(jì)原則，這個(gè)難度可能比總結(jié)設(shè)計(jì)原則的難度更高。

十八 可測(cè)性(Testability)

雖然目前大部分開(kāi)發(fā)和QA同學(xué)都知道“可測(cè)性”這么件事情，但對(duì)可測(cè)性把握的還不夠體系化，很多同學(xué)覺(jué)得可測(cè)性就是開(kāi)接口、加test hook。或者，還沒(méi)有很好的理解可測(cè)性這個(gè)東西落到自己這個(gè)領(lǐng)域(例如支付系統(tǒng)、公有云、ERP)意味著什么。在需求和系統(tǒng)設(shè)計(jì)分析階段還不能做到很有效很有體系的從可測(cè)性角度提出要求，往往要求比較滯后。我希望可測(cè)性設(shè)計(jì)可以總結(jié)出一系列像程序設(shè)計(jì)的DRY、KISS、Composition Over Inheritance、Single Responsibility，Rule of Three等設(shè)計(jì)原則，總結(jié)出一系列的反模式，甚至出現(xiàn)像《設(shè)計(jì)模式》那樣的一本專門的著作。

以上就是我會(huì)加到Hard Problems in Test列表的問(wèn)題，也是我已經(jīng)或打算投入精力解決的問(wèn)題。