《持續(xù)交付發(fā)布可靠軟件的系統(tǒng)方法》讀書筆記
項(xiàng)目在一開始階段，測試人員就會與開發(fā)人員及客戶一起寫自動化測試。這些測試應(yīng)該在開發(fā)前就寫好。
以上這些測試僅僅是系統(tǒng)進(jìn)行功能測試，容量、安全性及其非功能性試也應(yīng)盡早建立，為它們寫自動化測試套件。確保不符合需求的問題盡早暴露。
業(yè)務(wù)導(dǎo)向且支持開發(fā)過程的測試
在開發(fā)一個用戶故事之前，應(yīng)寫好驗(yàn)收測試，采取完美的自動化形式。
系統(tǒng)的驗(yàn)收測試應(yīng)運(yùn)行在類生產(chǎn)環(huán)境（UAT)
驗(yàn)收測試有價值的特性：
- 它加快了反饋速度
- 減少了測試人員的工作負(fù)荷
- 讓測試人員集中精力做探索性測試和高價值的活動
- 這些驗(yàn)收測試也是一組回歸測試套件
- 行為驅(qū)動開發(fā)，可以以這些測試中自動生成需求說明文檔
并不是所有的東西都需要自動化。我們傾向于將自動化驗(yàn)收測試限于完全覆蓋Happy Path的行為，并僅覆蓋其它一些極其重要的部分。每一種測試都應(yīng)該覆蓋應(yīng)用程序的80%
驗(yàn)收測試一般都是端對端測試，但是這樣很多時候驗(yàn)收測試的失敗并不是因?yàn)檎嬲娜毕荩且驗(yàn)榻缑娴淖兏?，這將導(dǎo)致增大了驗(yàn)收測試腳本的維護(hù)。有兩種方法解決這個問題：
- 在測試與用戶界面之間增加一個抽象層，以便減少因用戶界面變更而導(dǎo)致的問題
- 通過公共API來運(yùn)行這些驗(yàn)收測試，用戶界面會使用這些公共API來執(zhí)行真正的操作
技術(shù)導(dǎo)向且支持開發(fā)過程的測試
單元測試：不應(yīng)該訪問數(shù)據(jù)庫，不應(yīng)該使用文件系統(tǒng)，不與外部系統(tǒng)交互
組件測試：涉及更多的準(zhǔn)備工作并執(zhí)行更多的IO，需要連接數(shù)據(jù)庫，文件系統(tǒng)，與外部系統(tǒng)交互
部署測試：用于檢查部署過程是否正確
業(yè)務(wù)導(dǎo)向且評價項(xiàng)目的測試
其中非常tgsvr一種測試是：演示
探索性測試，并不只是發(fā)現(xiàn)缺陷，它還會致使創(chuàng)建新的自動化集合
易用性測試，為了驗(yàn)證用戶是否能很容易使用該應(yīng)用軟件完成工作
Beta測試，金絲雀發(fā)布，多個版本同時運(yùn)行在生產(chǎn)環(huán)境，收集不同版本的數(shù)據(jù)，如果分析證明新功能無法帶來足夠的價值，就刪除它
技術(shù)導(dǎo)向且評價項(xiàng)目的測試
驗(yàn)收測試分兩類：功能性測試，非功能性測試
測試替身
- 啞對象：那些被傳遞但不被真正使用的對象
- 假對象：可以真正使用的實(shí)現(xiàn)，但通常會利用一些捷徑
- 樁：在測試中為每個調(diào)用提供一個封裝好的響應(yīng)，它通常不會對測試之外的請求進(jìn)行響應(yīng)，只用于測試
- SPY：一種可記錄一些關(guān)于它們?nèi)绾伪徽{(diào)用的信息的樁
- 模擬對象：一種在編程時就設(shè)定了它的預(yù)期要接收的調(diào)用
現(xiàn)實(shí)中的情況與應(yīng)對策略
新項(xiàng)目：一開始就要寫自動化驗(yàn)收測試
- 選擇技術(shù)平臺和測試工具
- 建立一個簡單的自動化構(gòu)建
- 制定遵守INVEST原則【獨(dú)立的，可協(xié)商的，有價值的，可估計(jì)的，小的，可測試的】用戶故事及考慮其驗(yàn)收條件
- 客戶、分析師和測試人員定義驗(yàn)收條件
- 測試人員與研發(fā)人員一起基于驗(yàn)收條件實(shí)現(xiàn)驗(yàn)收測試的自動化
- 開發(fā)人員編碼來滿足驗(yàn)收條件
- 只要有自動化測試失敗，開發(fā)人員優(yōu)先修復(fù)問題
項(xiàng)目進(jìn)行中
- 引入自動化測試最好的方式是選擇應(yīng)用程序中那些最常見，最重要且高價值的用例為起點(diǎn)。
- 讓測試覆蓋的范圍稍稍寬于通常的用戶故事級別的驗(yàn)收測試。
- 如果發(fā)現(xiàn)對同一個功能重復(fù)進(jìn)行了多次的手工測試，就判斷該功能是否還會個性。如果不會，就將這個測試自動化，否則，說明這個測試覆蓋的功能一直變化，可以與客戶和開發(fā)確認(rèn)后，把它從測試集合中先忽略掉，并盡可能詳細(xì)地寫注釋
- 如果時間緊，最好利用各種各樣的測試數(shù)據(jù)來確保一定的覆蓋率
遺留系統(tǒng)
- 如果沒有自動構(gòu)建流程，最高優(yōu)先級是創(chuàng)建一個自動構(gòu)建流程，然后創(chuàng)建更多的自動化功能測試來豐富它
- 識別系統(tǒng)中高價值的功能，聚焦于系統(tǒng)中高價值的功能
- 基于高價值功能，創(chuàng)建一套廣泛的自動化測試
- 逐漸為新增功能添加相應(yīng)的測試
- 只寫那些有價值的自動化測試，如果只是新增功能，而不需要修改提供支撐的框架代碼時這部分代碼不需要寫全面的測試
集成測試
集成測試：那些確保系統(tǒng)的每個獨(dú)立部分都能夠正確作用于其依賴的那些服務(wù)的測試
集成測試應(yīng)該在兩種上下文中運(yùn)行：
- 被測試的應(yīng)用程序使用其真正依賴的外部系統(tǒng)來運(yùn)行時，或使用由外部服務(wù)供應(yīng)商所提供的替代系統(tǒng)
- 應(yīng)用程序運(yùn)行于你自己創(chuàng)建的一個測試用具之上
確保在正式部署生產(chǎn)環(huán)境之前，應(yīng)用程序不要與真實(shí)的外部系統(tǒng)進(jìn)行交互，否則就要想辦法告訴外部系統(tǒng)，應(yīng)用所發(fā)送的數(shù)據(jù)只用于測試 - 在測試環(huán)境中使用“防火墻”，將該應(yīng)用程序與外部系統(tǒng)隔離開來
- 在應(yīng)用程序中用一組配置信息，讓其與外部系統(tǒng)的模擬版本交互
把關(guān)于集成的活動放到發(fā)布計(jì)劃中是非常必要的。與外部系統(tǒng)的集成總是比較復(fù)雜，需要花時間并制定計(jì)劃。每當(dāng)增加一個外部系統(tǒng)集成點(diǎn)時，項(xiàng)目風(fēng)險(xiǎn)就會增，集成風(fēng)險(xiǎn)： - 測試服務(wù)是否準(zhǔn)備好了？它是否能正常運(yùn)行？
- 外部服務(wù)供應(yīng)商是否有足夠的資源與人力來回答我們遇到的問題，修改缺陷，添加我們提出的一些定制功能?
- 我們是否能直接訪問真實(shí)的生產(chǎn)環(huán)境，以便驗(yàn)證外部系統(tǒng)是否滿足我們的容量要求或可用性要求？
- 外部服務(wù)提供的API是否很容易與我們自己開發(fā)應(yīng)用軟件時所采用的技術(shù)進(jìn)行集成，我們團(tuán)隊(duì)是否需要某些專業(yè)技能才能使用這些API?
- 是否需要編寫并維護(hù)我們的測試服務(wù)？
- 當(dāng)外部系統(tǒng)的響應(yīng)與我們所期望的行為不一致時，我們自己的應(yīng)用程序是否能夠正確地處理？
- 還需要構(gòu)建與維護(hù)這個集成層及相關(guān)的運(yùn)行時配置，測試服務(wù)與測試策略。
流程
- 找出最高優(yōu)先級的測試場景
- 代碼讓這些驗(yàn)收條件變成可執(zhí)行的測試
- 測試人員與研發(fā)人員在開發(fā)前應(yīng)盡早一起討論驗(yàn)收測試
管理待修復(fù)的缺陷列表
- 將待修復(fù)缺陷列表可視化
- 一種零缺陷，關(guān)注缺陷問題，并修復(fù)
- 像對待功能一樣對待缺陷，將功能與缺陷一起做優(yōu)先級排序，讓開發(fā)按優(yōu)先級進(jìn)行開發(fā)
