中生代技術

鏈接技術大咖，分享技術干貨

接力技術，鏈接價值

阿里QA導讀：當郭靖遇到洪七公，當楊過斷臂遇雕兄，當張無忌落入昆侖洞，當令狐沖思過風清揚，當段譽摔進無量洞，當虛竹誤解珍瓏局，少室山下的少年還在苦練基本功，許多年后，再回少室山，以一敵三，一句你們三個一塊上吧，好霸氣蕭峰！不是所有人都有奇遇，也不是每個人都會斷臂，勤奮苦練，也能頂天立地。做夢的少年郎，贈你測試基本功，愿你固本培元，早入山門。

認識軟件質量

軟件產品質量屬性

這一章會從軟件質量的基本概念出發，以標準化（ISO/IEC25010）的軟件定義，介紹軟件產品質量模型和使用質量模型。里面的內容都可以在《GBT25000.10-2016系統與軟件工程系統與軟件質量要求和評價(SQuaRE)第10部分系統與軟件質量模型》中找到詳細解釋，這里主要列出我們測試工作中常用且必須關注的質量特性以及實際場景中如何運用。

系統/軟件產品質量屬性有8個特性：功能性、性能效率、兼容性、易用性、可靠性、信息安全性、維護性和可移植性。其中功能性，性能效率，可靠性、易用性（人工差錯防御）是我們著重需要關注的質量特性，也是導致線上90%故障的主要因素。

產品質量特性說明和理解：

我們從8個方面去闡述產品質量特性

功能性

性能效率

可靠性

易用性

兼容性

信息安全性

可維護性

可移植性

1. 功能性

在指定條件下使用時，產品或系統提供滿足明確和隱含要求的功能的程度。包括：

• 功能完備性

• 功能正確性

• 功能適合性

• 功能性的依從性

從定義上來理解，功能性并不止滿足 “明確” 的要求，還有很多 “隱含” 的質量特性。我們在做功能測試的時候，“明確”+“隱含”需求一起覆蓋才是完整的測試場景。我們在工作中如何能前置讓隱含的需求明確，是質量同學的一項重要能力，這個過程包括在需求前期跟PD的明確，比如需求文檔里描述了想要實現的功能，但沒有寫明對性能和用戶體驗的要求，測試同學就是需要在評審階段就對焦明確，這樣在TC設計，測試策略以及后面業務方驗收測試中才能充分被覆蓋到。還是一個基本原則，問題越前置被識別并解決，是成本最低的做法。

功能子屬性子屬性特性描述

完備性	功能集對指定的任務和用戶目標的覆蓋程度；
正確性	產品或系統提供具有所需精度的正確的結果的程度；
適合性	功能促使指定的任務和目標實現的程度
功能性的依從性	產品或系統遵循與功能性相關的標準、約定或法規以及類似規定的程度。

2. 性能效率

性能效率的評估與在指定條件下所使用的資源量有關。包括時間特性、 資源利用率 、容量、性能效率的依從性。

實際工作中，我們基礎架構的彈性能力，常態化壓測能力、大促的全鏈路壓測等都是這一質量屬性的測試體現。后面在測試進階能力中，會有專門篇幅介紹性能測試和全鏈路壓測的內容。

功能子屬性子屬性特性描述

實踐特性	產品或系統執行其功能時,其響應時間、處理時間及吞吐率滿足需求的程度；
容量	產品或系統參數的最大限量滿足需求的程度；
資源利用率	產品或系統執行其功能時,所使用資源數量和類型滿足需求的程度；
性能效率的依從性	產品或系統遵循與性能效率相關的標準、約定或法規以及類似規定的程度。

3. 可靠性

系統、產品或組件在指定條件下、指定時間內執行指定功能的程度。包括成熟性、可用性、容錯性、易恢復性、可靠性的依從性。

質量同學在評估方案時經常會出現這樣的靈魂拷問：怎樣設計測試場景保障線上不出問題、如何設計架構讓主流程不受阻塞、強弱依賴如何解耦、準備怎樣的預案讓問題發生時也能快速恢復等，都是對可靠性質量屬性的測試實踐，可靠性也是我們在設計評審中需要著重關注的特性。

功能子屬性子屬性特性描述

成熟性	系統、產品或組件在正常運行時滿足可靠性要求的程度；
可用性	系統、產品或組件在需要使用時能夠進行操作和訪問的程度；
容錯性	盡管存在硬件或軟件故障,系統、產品或組件的運行符合預期的程度；
易恢復性	在發生中斷或失效時,產品或系統能夠恢復直接受影響的數據并重建期望的系統狀態的程度；
可靠性的依從性	產品或系統遵循與可靠性相關的標準、約定或法規以及類似規定的程度。

4. 易用性

在指定的使用環境中,產品或系統在有效性、效率和滿意度特性方面為了指定的目標可為指定用戶使用的程度。包括可辨識性、易學性、易操作性、人工差錯防御性、易訪問性、易用性的依從性。

易用性的另一個描述就是功能級別的用戶體驗（下一章會介紹使用級別的用戶體驗），我們新零售技術質量的愿景就是“做用戶體驗的捍衛者”，因此易用性是測試過程中很重要的一個覆蓋范圍。易用性里核心需關注的是人工差錯防御，我們有很多故障或線上問題都來自于人工操作或配置類錯誤，這都是人工差錯防御范圍。

功能子屬性子屬性特性描述

可辨識性	用戶能夠辨識產品或系統是否適合他們的要求的程度；
易學性	在指定的使用環境中,產品或系統在有效性、效率、抗風險和滿意度特性方面為了學習使用該產品或系統這一指定的目標可為指定用戶使用的程度；
易操作性	產品或系統具有易于操作和控制的屬性的程度；
人工差錯防御性	系統預防用戶犯錯的程度；用戶界面舒適性：用戶界面提供令人愉悅和滿意的交互的程度；
易訪問性	在指定的使用環境中,為了達到指定的目標,產品或系統被具有最廣泛的特征和能力的個體所使用的程度；
易用性的依從性	產品或系統遵循與易用性相關的標準、約定或法規以及類似規定的程度。

5. 兼容性

在共享相同的硬件或軟件環境的條件下,產品、系統或組件能夠與其他產品、系統或組件交換信息,和/或執行其所需的功能的程度。

包括共存性、互操作性、兼容性的依從性。 兼容性測試在移動應用測試和跨平臺組件應用上需著重評估。

6. 信息安全性

產品或系統保護信息和數據的程度,以使用戶、其他產品或系統具有與其授權類型和授權級別一致的數據訪問度。包括保密性、完整性、抗抵賴性、可核查性、真實性、信息安全的依從性。

這部分質量屬性直接對應安全性測試，已經是測試領域里獨立的一個重要方向。后面的進階篇會有詳細介紹。

7. 可維護性

產品或系統能夠被預期的維護人員修改的有效性和效率的程度。包括 模塊化、可重用性、易分析性、易修改性、易測試性、維護性依從性。 可維護性更多體現在對設計方案的評估過程中。

8. 可移植性

系統、產品或組件能夠從一種硬件、軟件、或者其他運行(或使用)環境遷移到另一種環境的有效性和效率的程度。包括適應性、易安裝性、易替換性、可移植性的依從性。 遷移類項目和版本升級類變更需評估。

產品使用質量屬性

使用質量屬性是從用戶使用體驗的角度進行定義，質量同學作為用戶體驗的捍衛者，除了產品質量，使用質量也需要關注。它描述了產品(系統或軟件產品)對利益相關方造成的影響。它是由軟件、硬件和運行環境的質量,以及用戶、任務和社會環境的特性所決定的。所有這些因素均有利于系統的使用質量。

產品使用質量屬性說明：

• 有效性： 用戶實現指定目標的準確性和完備性。

• 效率： 與用戶實現目標的準確性和完備性相關的資源消耗。

• 滿意度： 產品或系統在指定的使用環境中使用時，用戶的要求被滿足的程度。包括有用性：用戶對實用目標的實現感到滿意的程度，包括使用的結果和使用后產生的后果；可信性：用戶或者其他利益相關方對產品或系統將如預期地運行有信心的程度；愉悅性：用戶因個人要求被滿足而獲得愉悅感的程度；舒適性：用戶生理上感到舒適的程度。

• 抗風險： 包括經濟風險緩解性：在預期的使用環境中，產品或系統在經濟現狀、高效運行、商業財產、信譽或其他資源方面緩解潛在風險的程度；健康和安全風險緩解性：在預期的使用環境中，產品或系統緩解人員潛在風險的程度；環境風險緩解性：在預期的使用環境中，產品或系統在財產或環境方面緩解潛在風險程度。

• 周境覆蓋： 在指定的使用周境和超出最初設定需求的周境中，產品或系統在有效性、效率、抗風險和滿意度特性方面能夠被使用的程度。包括周境完備性：在所有指定的使用環境中，產品或系統在有效性、效率、抗風險和滿意度特性方面能夠被使用的程度；靈活性：在超出最初設定需求的環境中，產品或系統在有效性、效率、抗風險和滿意度特性方面能夠被使用的程度。

認識軟件測試

對軟件質量思考的不同角度，形成了不同的測試類型，不同類型對應不同的測試方法，而不同的測試方法針對不同的質量特性。要修煉更深更廣的測試覆蓋度，需要了解更多的測試方法用于設計測試用例。這類方法的介紹書籍非常多，下圖是一個質量特性對應測試方法的展示。實際項目中測試時間和資源往往有限，測試工程師就需要不斷的思高效的質量保障手段。下圖很多方法都已能通過工具或技術手段來完成，比如異常測試，故障輸入，冪等，灰度驗證等等。因此質量特性對應的方法更多只是一個范圍的參考，給測試同學一個基本原則，如何保障好這個特性，需要我們不斷的思考測試技術的突破來實現。

測試類型

根據測試方法不同的類型

• 黑盒測試 - 也稱功能測試或基于需求的測試，測試設計時把被測對象當成一個黑盒子，不關心盒子的內部結構，主要通過輸入/輸出數據驅動功能用例。這類測試中理論上的充分測試標準就是“窮舉輸入”，而窮舉肯定是不可能的，因此我們還需要其他的測試類型進行補充。

• 白盒測試 - 也稱為邏輯驅動測試，針對性較強，需要對代碼邏輯有了解。理論上的充分測試是所有的條件、語句、路徑組合都被覆蓋，對技術和成本都有一定要求。

• 灰盒測試 - 介于白盒與黑盒之間的測試方式，根據實際測試場景、資源、復雜度等情況進行結合，也是目前我們使用最多的測試類型。

每種測試類型都對應很多測試分析方法，后面進階篇也會針對各種測試方向進行深入介紹，這里不對基本概念和原理多做贅述。

軟件測試的基本原則

基本功修煉的最后，我們可以歸納出一系列重要的測試指導原則，可作為我們日常工作的提醒。原則大部分看上去顯而易見，淺顯易懂。但往往故障都發生在這些常見的場景中，用一位開發TL在某次故障復盤會上的話，給“修煉測試基本功”這一章做個結束語：故障中的一切問題看似天災人禍，實則人事不修。

序號原則

1	窮盡測試是不可能的 -窮舉測試解決不了覆蓋問題，多思考創新采用技術手段豐富覆蓋度
2	測試左移和測試右移（Shift left testing and Shift right testing） - 測試應盡早介入，問題發現越晚修復代價越大。同時測試活動也不應停止于發布前，線上業務監控，回歸以及系統恢復都是測試職責范圍。
3	缺陷集群效應 - 一旦某個模塊發現了較多問題，那一定隱藏了更多的問題
4	殺蟲劑悖論 - 測試用例和自動化腳本、工具、數據等要定期更新，用同樣的內容測變化的系統會越來越難發現問題。
5	測試依賴于上下文 - 質量保障不能僅僅考慮需求本身，還需要考慮關聯的上下游等諸多因素
6	**沒有不存在缺陷的系統 **- 要充分對系統進行風險分析，沒發現問題不代表沒有缺陷。
7	測試用例的設計不僅要考慮有效輸入輸出，也應該考慮無效和未預測到的輸入情況，異常測試必須覆蓋
8	檢查系統是否“沒有完成應該完成的”，僅僅是測試的一半，另一半是檢查系統是否“做了不應該做的”。
9	隨時沉淀，隨時總結，隨時思考，質量保障是持續性的，創造性的，富有挑戰性的工作。

- To Be Continued?-

阿里P9專家右軍：大話軟件質量穩定性

阿里P9專家右軍：以終為始的架構設計

假如把支付寶存儲服務器炸了，里面的錢還在么？

19歲P8入駐阿里？從阿里的人才成長體系學習

阿里P8架構師：淘寶技術架構從1.0到4.0的架構變遷！12頁PPT詳解

阿里技術：如何畫出一張合格的技術架構圖？

? ?END ? ?? #接力技術，鏈接價值#

點分享點點贊點在看

總結

以上是生活随笔為你收集整理的阿里技术专家麒烨：修炼测试基本功的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。