【測試面試】測試面試題集錦（二）

給你一個全新的軟件，你就是負責人，你怎麼去開展測試工做
參考回答：
第一步：需求分析：我會對這個全新的軟件需求進行全面分析，主要的分析點有：1.軟件的版本需求合理性，是否可測試；2.項目人員配置（遇到什麼問題找誰，有多少人投入測試，測試環境，硬件，軟件）；3.要測試的軟件的主流程，異常流程，測試重點；4。項目總體規劃（發佈時間

第二步：指定測試策略、測試計劃和bug定義標準，這一步主要是針對需求，在已有的和可協調到的資源上作出具體的，可執行的計劃，這個階段的輸出是測試計劃。測試計劃中明確包含測試範圍，測試策略，好比功能測試，性能測試，自動化測試，可用性測試，雲測，mokey等

第三步：按計劃執行，編寫測試用例，（編寫測試用例的方法：等價類，邊界值，錯誤猜想法，因果圖，正交分解法等等）（編寫測試用例須要注意的點，用例區分等級，特殊場景考慮：爲空（接口空、數據空）、加載超時、網絡異常、重複提交、異常中斷、緩存衝突、系統兼容、流程迂迴、流程中斷；若是是PC，要注意瀏覽器（IE，chrome,火狐，蘋果的），操做系統（xp,win7,win8,win10,linux,mac）的兼容,若是是手機，注意手機的品牌，操做系統，android版本，手機屏幕尺寸，手機網絡等等場景），寫完用例，若是有條件，就要評審測試用例

第四步：執行用例，補充場景，記錄bug，迴歸bug（注意開發提測的需求須要冒煙測試經過）

第五步：功能合入，迴歸測試（各個功能點測試經過以後，再合入）

第六步：提交驗收（迴歸測試經過以後，提交給驗收人員進行驗收）

第七步：發佈上線（全新的軟件，先是小範圍內測，觀察線上數據（如：crash,用戶反饋，運營數據等）若是有產品認爲嚴重的問題，則須要修復後重發，符合預期才能擴大發布）

若是你發現了bug可是開發不認爲是bug，怎麼辦
首先找證據支持我說這個是bug，（好比需求文檔這麼寫的，競品這麼作的等等），若是找不到足夠的證據支持你的觀點，那就將問題升級到小組內討論，一級一級的上升，直到PM或者項目經理拍板定義

，你以爲bug須要修改，很緊急，可是開發沒時間，怎麼辦
這個你須要先把這個問題說清楚，問題影響範圍有多大，而後給PM或者項目經理還有拉上開發一塊兒評審，說明這個問題遺留的風險，若是PM和項目經理接受這個風險，那就能夠發佈，不然必須修改了才能發佈

即便他們接受了，發佈以後，也要注意線上的表現，並知會出來

若是線上這個問題表現超過預期，那麼就要要求發佈hotfix

面試題：如何測試登陸模塊
註冊登陸在軟件測試中是基礎，但也會有漏測的狀況出現，尤爲是對於普通帳戶密碼登陸的狀況，須要考慮帳戶密碼的長度限制、字符類型、匹配判斷等等。
目前市場上經常使用的登陸方式也有不少，帳密登陸裏又支持郵箱、帳號、手機號登陸。對於同時支持多種登陸方式，測試時除了考慮每種方式是否可以登陸成功之外，特別須要考慮不一樣登陸方式的優先級、對於用戶習慣登陸方式的設置和記憶、各類登陸方式之間的切換、不一樣設備的不一樣方式登陸等等。
今天我與你們一塊兒對登陸方式及測試重點進行梳理，主要關注一些特殊點，以及容易出現漏測的狀況。
下面說一下測試點

功能測試
輸入正確的用戶名和密碼登陸成功
輸入錯誤的用戶名密碼登陸失敗
用戶名正確，密碼錯誤，是否提示輸入密碼錯誤？
用戶名錯誤，密碼正常，是否提示輸入用戶名錯誤？
用戶名和密碼都錯誤，是否有相應提示？
用戶名密碼爲空時，是否有相應提示？
若是用戶未註冊，提示請先註冊，而後進行登陸
已經註銷的用戶登陸失敗，提示信息友好？
密碼框是否加密顯示？
用戶名是否支持中文、特殊字符？
用戶名是否有長度限制？
密碼是否支持中文，特殊字符？
密碼是否有長度限制？
密碼是否區分大小寫？
密碼爲一些簡單經常使用字符串時，是否提示修改？如：123456
密碼存儲方式？是否加密？
登陸功能是否須要輸入驗證碼？
驗證碼有效時間？
驗證碼輸入錯誤，登陸失敗，提示信息是否友好？
輸入過時的驗證可否登陸成功？
驗證碼是否容易識別？
驗證碼換一張功能是否可用？點擊驗證碼圖片是否能夠更換驗證碼？
用戶體系：好比系統分普通用戶、高級用戶，不一樣用戶登陸系統後可的權限不一樣。
若是使用第三方帳號(QQ,微博帳號)登陸，那麼第三方帳號與本系統的帳號體系對應關係如何保存？首次登陸須要極權等

界面測試
佈局是否合理、美觀，輸入框是否對齊
風格和提示信息用語是否符合語境
登陸頁面顯示是否正常？文字和圖片可否正常顯示，相應的提示信息是否正確，按鈕的設置和排列是否正常
頁面默認焦點是否認位在用戶名的輸入框中
首次登陸時相應的輸入框是否爲空？或者若是有默認文案，當點擊輸入框時默認方案是否消失？
相應的按鈕如登陸、重置等，是否可用;頁面的前進、後退、刷新按鈕是否可用？
快捷鍵Tab,Esc,Enter 等，可否控制使用
兼容性測試：不一樣瀏覽器，不一樣操做系統，不一樣分辨率下界面是否正常

性能測試
單用戶登陸系統的響應時間是否符合"3-5-8"原則
用戶數在臨界點時併發登陸是否還能符合"3-5-8"原則
壓力：大量併發用戶登陸，系統的響應時間是多少？系統會出現宕機、內存泄露、cpu飽和、沒法登陸嗎?
穩定性： 系統可否處理併發用戶數在臨界點之內連續登陸N個時的場景？

安全性測試
1.登陸成功後生成的Cookie，是不是httponly (不然容易被腳本盜取)
2.用戶名和密碼是否經過加密的方式，發送給Web服務器
3.用戶名和密碼的驗證，應該是前端驗證+服務器端驗證， 而不能單單是在客戶端用javascript驗證
4.用戶名和密碼的輸入框，無SQL 注入攻擊風險
5.用戶名和密碼的的輸入框，不能輸入腳本 （防止XSS攻擊）
6.錯誤登陸的次數限制（防止暴力破解）
7.驗證碼不能被輕易破解、欺騙

兼容性測試
1.主流的瀏覽器下可否顯示正常
2.不一樣的操做系統是否能正常工做
3.移動設備上是否正常工做
4.不一樣的分辨率

易用性測試
1.根據場景，考試是否提供記住用戶名密碼、自動登陸的功能
2.輸入帳號後，回車登陸
連續輸入3次或以上錯誤密碼，用記是否被鎖必定時間（如：15分鐘）？時間內不容許登陸，超出時間點是否能夠繼續登陸。

其餘測試
用戶session過時後，從新登陸是否還能從新返回這前session過時的頁面？
用戶名和密碼輸入框是事支持鍵盤快捷鍵？如：撤銷、複製、粘貼等等
是否容許同名用戶同時登陸進行操做？考慮web和app同時登陸
手機登陸時，是否先判斷網絡可用？
手機登陸時，是否先判斷app存在新版本？
是否支持單點登陸？
是否有埋點接口

http和https的區別
HTTPS和HTTP的區別主要以下：

一、https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。

二、http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。

三、http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。

四、http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

擴展資料：

HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

支付模塊的測試
連接：https://blog.csdn.net/jiangbqing/article/details/61917979
正常流程：
　　正常使用支付寶、微信、銀行卡（目前使用最多的第三方支付方式）支付（正常金額的支付），功能是否正常。
　　異常流程：
　　一、支付帳號和密碼錯誤，系統如何處理；
　　二、餘額不足，系統如何處理；
　　三、取消支付，系統如何處理；
　　四、重複支付，系統如何處理；
　　五、微信或支付寶帳號未登陸時支付，系統如何處理；
　　六、手機上沒有支付寶APP時選擇支付寶支付，系統如何處理；
　　七、支付期間忽然斷網，系統如何處理；
　　八、取消支付後再次支付，系統如何處理；
　　九、金額上：最小值金額的支付，最大值金額的支付，錯誤金額的支付（如金額格式的錯誤、不容許使用的貨幣等等）；

如何設計一個好的測試case
連接：http://www.sohu.com/a/247756141_165433

「好的」測試用例必定是一個完備的集合，它可以覆蓋全部等價類以及各類邊界值，而跟可否發現缺陷無關。
一個「好的」測試用例，必須具有如下三個特徵。

1.總體完備性：「好的」測試用例必定是一個完備的總體，是有效測試用例組成的集合，可以徹底覆蓋測試需求。

2.等價類劃分的準確性：指的是對於每一個等價類都能保證只要其中一個輸入測試經過，其餘輸入也必定測試經過。

3.等價類集合的完備性：須要保證全部可能的邊界值和邊界條件都已經正確識別。

作到了以上三點，就能夠確定測試是充分且完備的，即作到了完整的測試需求覆蓋。

一，檢查標準
1.準確性(Accurate)
測試覆蓋了描述部分須要測試的內容。

2.經濟性(Economical)
測試用例沒有冗餘的步驟

3.可重複性(Repeatable)
測試用例應該是獨立一致的，無論任何人執行，結果都一致。

4.可追蹤(Traceable)
測試用例應該追溯到具體需求。

5.自我清理(Self cleaning)
測試結束後，恢復到原有乾淨的狀態，不該該對原有系統形成影響。

6 結構化和可測試性（Structure and testability）
測試用例應該是結構化。通常能夠根據一個橫向維度，對測試用例進行功能模塊的劃分；同時縱向維度上能夠根據測試類別對測試用例進行縱向結構的劃分。
測試同時應該是可測試性的。對於沒法執行的測試用例是沒有意義的。

7.規範性
命名 + 編號

目的

測試方法

環境， 數據， 前提，權限。

步驟， 指望結果。

清理數據，還原系統。

這裏其實包含一個測試用例的組成部分：

命名， 編號（通常會結合功能進行命名）
目的描述
測試類型（該測試用例屬於功能測試，性能測試，單元測試，系統測試等等）
環境
測試數據
前提
步驟
指望結果
實際結果
測試結果（經過仍是失敗）
通常來講測試用例，不會說明備份系統，還原系統的步驟，這兩個步驟通常都會由自動化腳本自動執行。

8.簡潔性

不超過15步。

執行時間不要超過20分鐘。這兩點實際上是但願測試用例的規模比較小，粒度不要太大。這點在大型系統不太適用。

這裏給出了一個測試用例編寫的指導規範。儘可能簡潔，精悍。

9.完整性
自動化腳本應該包含必要的註釋，包括，目的，輸入，預期結果。

若是可能，提供不一樣的前置條件下的測試。

測試用例應該儘可能完整，包含自動化腳本。

10.有效性
測試用例是否符合商業案例？

11.獨立性
測試用例應該保持獨立性，一個測試用例最好是能獨立運行，不依賴於其餘的測試用例的輸出結果。出於結構的考慮，有些特殊測試用例設計自己就是做爲setup來設計的，這個除外。

二， 測試用例的配置管理
採用命名和編號規範歸檔。

用例版本是否與當前被測試軟件版本一致（對應）。測試用例最好有版本控制

包含用例須要的相應測試對象，如特定數據庫。

存檔閱讀。

存檔時按角色控制訪問方式

當網絡備份時存檔。

離線歸檔。

壓力測試，負載測試和性能測試關係？
連接：http://www.51testing.com/html/06/n-3721106.html
性能測試是動力，負載測試載重，壓力測試強度

壓力測試stresstest：是在必定的負荷條件下，長時間連續運行系統給系統性能形成的影響。

負載測試Loadtest：在必定的工做負荷下，給系統形成的負荷及系統響應的時間。

軟件測試風險分析

測試計劃都包括什麼？
概述 1.1 編寫目的 1.2 項目背景 1.3 項目質量目標 1.4 預期讀者 1.5 參考資料
測試環境 2.1 系統架構 2.2 軟硬件環境要求 2.3 測試環境部署圖
測試規劃 3.1 測試範圍 3.2 測試工具 3.3 人員、角色及職責
測試策略 4.1 系統框測試 4.2 業務流程測試 4.3 功能點測試 4.4 UI界面測試 4.5 性能測試 4.6 兼容性測試 4.7 安全測試
測試進度安排
工做彙報
web測試和手機測試有什麼區別
WEB測試和App測試從流程上來講，沒有區別。都須要經歷測試計劃方案，用例設計，測試執行，缺陷管理，測試報告等相關活動。從技術上來講，WEB測試和APP測試其測試類型也基本類似，都須要進行功能測試、性能測試、安全性測試、GUI測試等測試類型。

他們的主要區別在於具體測試的細節和方法有區別，好比：性能測試，在WEB測試只須要測試響應時間這個要素，在App測試中還須要考慮流量測試和耗電量測試。

兼容性測試：在WEB端是兼容瀏覽器，在App端兼容的是手機設備。並且相對應的兼容性測試工具也不相同，WEB由於是測試兼容瀏覽器，因此須要使用不一樣的瀏覽器進行兼容性測試（常見的是兼容IE6，IE8，chrome，firefox）若是是手機端，那麼就須要兼容不一樣品牌，不一樣分辨率，不一樣android版本甚至不一樣操做系統的兼容。（常見的兼容方式是兼容市場佔用率前N位的手機便可），有時候也可使用到兼容性測試工具，但WEB兼容性工具多用IETester等工具，而App兼容性測試會使用Testin這樣的商業工具也能夠作測試。

安裝測試：WEB測試基本上沒有客戶端層面的安裝測試，可是App測試是存在客戶端層面的安裝測試，那麼就具有相關的測試點。

還有，App測試基於手機設備，還有一些手機設備的專項測試。如交叉事件測試，操做類型測試，網絡測試（弱網測試，網絡切換）

交叉事件測試：就是在操做某個軟件的時候，來電話、來短信，電量不足提示等外部事件。

操做類型測試：如橫屏測試，手勢測試

網絡測試：包含弱網和網絡切換測試。須要測試弱網所形成的用戶體驗，重點要考慮回退和刷新是否會形成二次提交。弱網絡的模擬，聽說能夠用360wifi實現設置。

從系統架構的層面，WEB測試只要更新了服務器端，客戶端就會同步會更新。並且客戶端是能夠保證每個用戶的客戶端徹底一致的。可是APP端是不可以保證徹底一致的，除非用戶更新客戶端。若是是APP下修改了服務器端，意味着客戶端用戶所使用的核心版本都須要進行迴歸測試一遍。

還有升級測試：升級測試的提醒機制，升級取消是否會影響原有功能的使用，升級後用戶數據是否被清除了。

selenium 和 Appium 是怎麼聯繫的?有什麼關係?
一 、 selenium是專門作web端的自動化測試工具
Selenium與其餘測試工具相比，最大好處是：

Selenium 測試直接在瀏覽器中運行，就像真實用戶所作的同樣。Selenium 測試能夠在 Windows、Linux 和 Macintosh上的 Internet Explorer、Chrome和 Firefox 中運行。其餘測試工具都不能覆蓋如此多的平臺。使用 Selenium 和在瀏覽器中運行測試還有不少其餘好處。

下面是主要的兩大好處：

經過編寫模仿用戶操做的 Selenium 測試腳本，能夠從終端用戶的角度來測試應用程序。經過在不一樣瀏覽器中運行測試，更容易發現瀏覽器的不兼容性。Selenium 的核心，也稱browser bot，是用 JavaScript 編寫的。這使得測試腳本能夠在受支持的瀏覽器中運行。browser bot 負責執行從測試腳本接收到的命令，測試腳本要麼是用 HTML 的表佈局編寫的，要麼是使用一種受支持的編程語言編寫的。

二 、appium是手機app端的自動化，它繼承了webdriver(也就是selenium 2)
不過appium仍然須要經過selenium最後作測試工具，可是appium起到了一個鏈接手機端很是好的橋樑工做！能夠鏈接到電腦上很是方便的調用selenium工具來作測試。

Selenium 1.0版包括三個部分，分別是Selenium IDE（插件，用於錄屏，並轉化代碼）、Selenium Grid（擴展工具集）和Selenium RC（Remote Controller），其中最主要部分爲Selenium RC。

可是Selenium與WebDriver合併後，Selenium2.0就等價爲WebDriver了，因此學習Selenium2.0的話，至關於主要學習WebDriver API了。

3.0版本直到2016年才發佈，該版本完全移出了Selenium RC，對開發環境也有了限制（例如只支持jvav8以上版本，對不一樣的瀏覽器也有最低版本要求）。相對而言，2.0版的通用性更高。

搜索功能的測試用例包括哪些？
功能測試

搜索內容爲空，驗證系統如何處理
搜索內容爲空格，查看系統如何處理
邊界值驗證：在容許的字符串範圍內外，驗證系統的處理
超長字符串輸入，系統是否會截取容許的長度來檢驗結果
合法的字符串長度後，加空格驗證檢索結果
多關鍵字中間加入空格，逗號，tab驗證系統的結果是否正確
驗證每種合法的輸入，結果是否正確
是否支持檢索內容的複製、粘貼、編輯等操做
是否支持回車鍵搜索
屢次輸入相同的內容，查看系統的檢索結果是否一致
特殊字符、轉義字符、html腳本等須要作處理
敏感詞彙，提示用戶無權限等
輸入的內容是否支持快捷鍵操做等
只能輸入容許的字符串長度等
輸入連接是否正確跳轉，
搜索的歷史紀錄是否顯示在下面
搜索內容有沒有聯想功能
界面測試

查看UI是否顯示正確，佈局是否合理
是否有錯別字
搜索結果顯示的佈局是否美觀
已查看的結果連接，連接的顏色要灰化處理，
結果數量龐大時，頁面的分頁佈局是否合理
安全性測試

腳本的禁用
SQL的注入，檢索SQL SELECT語句等
敏感內容的檢索是禁止的
特殊字符的檢索
被刪除、加密、受權的數據，不容許被查出來，是否有安全設計控制
兼容性測試

多平臺Windows，mac
移動平臺android，ios
多瀏覽器火狐、chrome、IE等
性能測試

搜索頁面的連接打開速度是否知足設計要求
搜索出結果消耗時間，是否知足設計要求

階段評審與同行評審的區別？
同行評審目的：發現小規模工做產品的錯誤，只要是找錯誤；

階段評審目的：評審模塊 階段做品的正確性 可行性 及完整性

同行評審人數：3-7人 人員必須通過同行評審會議的培訓，由SQA指導

階段評審人數：5人左右 評審人必須是專家 具備系統評審資格

同行評審內容：內容小 通常文檔 < 40頁， 代碼 < 500行

階段評審內容： 內容多，主要看重點

同行評審時間：一小部分工做產品完成

階段評審時間： 一般是設置在關鍵路徑的時間點上

驗收測試包括？
功能測試、易用性測試、兼容性測試、安裝測試、文檔測試等等

兼容性測試是指軟件能夠在不一樣的平臺下運行，包括軟件環境（好比LINUX的各個版本等）、硬件環境（好比android的各款手機等）。

安裝測試，也叫部署測試，確保軟件安裝後能夠正常使用，包括不一樣的安裝方式、不一樣平臺下的安裝等。

文檔測試只要是測試文檔，文檔也是軟件交付的產品之一，包括用戶手冊、使用說明等等。

非正式驗收包括Alpha 測試、Beta 測試。Alpha 測試通常是在開發者所提供的場所進行測試，由用戶來執行。Beta 測試徹底脫離開發者的環境，徹底交給用戶進行測試。

測試策略有哪些？
連接：https://blog.csdn.net/hongfuqiang/article/details/78786187

設計系統測試須要參考的項目文檔
軟件測試計劃
軟件需求規範
迭代計劃

文檔測試
Namaste,guys ~此博客Val主要分享關於文檔測試的概念。

1、文檔測試的內容：
一、文檔的完整性：主要是測試文檔內容的全面性與完整性，從整體上把握文檔的質量。例如用戶手冊應該包括軟件的全部功能模塊。

二、描述與軟件實際狀況的一致性：主要測試軟件文檔與軟件實際的一致程度。例如用戶手冊基本完整後，咱們還要注意用戶手冊與實際功能描述是否一致。由於文檔每每跟不上軟件版本的更新速度。

三、易理解性：主要是檢查文檔對關鍵、重要的操做有無圖文說明，文字、圖表是否易於理解。對於關鍵、重要的操做僅僅只有文字說明確定是不夠的，應該附有圖表使說明更爲直觀和明瞭。

四、文檔中提供操做的實例：這項檢查內容主要針對用戶手冊。對主要功能和關鍵操做提供的應用實例是否豐富，提供的實例描述是否詳細。只有簡單的圖文說明，而無實例的用戶手冊看起來就像是軟件界面的簡單拷貝，對於用戶來講，實際上沒有什麼幫助。

五、印刷與包裝質量：主要是檢查軟件文檔的商品化程度。有些用戶手冊是簡單打印、裝訂而成，過於粗糙，不易於用戶保存。優秀的文檔例如用戶手冊和技術白皮書，應提供商品化包裝，而且印刷精美。

2、軟件文檔測試對象與目的
一、文檔測試對象主要以下：
包裝文字和圖形；
市場宣傳材料、廣告以及其它插頁；
受權、註冊登記表；
最終用戶許可協議；
安裝和設置嚮導；
用戶手冊；
聯機幫助；
樣例、示範例子和模板；

二、文檔測試的目的：
提升易用性和可靠性，下降支持費用，由於用戶經過文檔就能夠本身解決問題。
所以文檔測試的檢查內容主要以下：

讀者對象——主要是文檔的內容是否能讓該級別的讀者理解；
術語——主要是檢查術語是否適合讀者；
內容和主題——檢查主題是否合適、是否丟失、格式是否規範等；
圖標和屏幕抓圖——檢查圖表的準確度和精確度；
樣例和示例——是否與軟件功能一致；
拼寫和語法；
文檔的關聯性——是否與其它相關文檔的內容一致，例如與廣告信息是否一致；
文檔測試是至關重要的一項測試工做，不但要給予充分的重視，更要要認真的完成，象作功能測試同樣來對待文檔測試。

3、作好文檔測試須要注意：
仔細閱讀，跟隨每一個步驟，檢查每一個圖形，嘗試每一個示例；
檢查文檔的編寫是否知足文檔編寫的目的；
內容是否齊全、正確、完善；

軟件的缺陷等級應如何劃分？
致命的：致命的錯誤，形成系統或應用程序崩潰、死機、系統懸掛，或形成數據丟失、主要功能徹底喪失等。
嚴重的：嚴重錯誤，指功能或特性沒有實現，主要功能部分喪失，次要功能徹底喪失，或致命的錯誤聲明。
通常的：不太嚴重的錯誤，這樣的軟件缺陷雖然不影響系統的基本使用，但沒有很好地實現功能，沒有達到預期效果。如次要功能喪失，提示信息不太準確，或用戶界面差，操做時間長等。
微小的：一些小問題，對功能幾乎沒有影響，產品及屬性仍可以使用，若有個別錯別字、文字排列不整齊等。

測試過程當中輸出的文檔
測試計劃，測試文檔，測試用例，測試日誌，bug報告，測試總結報告

軟件質量評估指標
一、功能性的質量指標
　　功能的正確性：系統功能和用戶的實際需求、已定義的產品規範一致。
　　功能的準確性：系統產生的結果在精度容許的偏差範圍內。
　　功能的完整性：全部功能及其定義清楚、可用。
　　二、可用性的質量指標
　　可操做性：容易使用和操做，包括理解用戶界面、適應一些特殊用戶的可選項等。
　　通用性：數據顯示、網絡通訊接口和用戶界面等都遵照已有的軟件標準。
　　一致性：在軟件開發整個生命週期內創建和使用相同的標準，保證全局變量、數據類型、出錯處理的命名和使用一致。
　　三、可靠性的質量指標
　　自我恢復能力：當系統的某個功能失效發生時，系統在當前環境下能實現故障自動轉移，從新自動配置、繼續執行的能力，軟件系統具備自我檢測、容錯、備份等機制，儘可能作到獨立於硬件的編碼、硬件設備之間的通訊協議一致等。
　　健壯性：各類惡劣環境（大數據量、大用戶量）下系統能正常工做。
　　分佈性：軟件系統的某些子功能或子系統被定位於不一樣的處理主機、存儲設備。
　　四、性能的質量指標
　　有效性：系統在通訊、處理、存儲等方面佔有不多資源或者對所使用的資源進行了優化。
　　完整性：系統具備良好的安全管理，能防止不安全存取系統、防止數據丟失病毒入侵等。
　　易存取性：對系統的存取權限設置清楚，存取操做方便，存取操做有記錄。
　　五、可維護性的質量指標
　　模塊化：指講一個複雜的軟件系統分解爲分別命名並具有最小耦合性、很強凝聚性、結構化的組件。
　　靈活性：容易爲系統增長一個新功能或者新的數據而不須要進行大量的代碼修改或者設計修改。
　　可測試性：測試軟件組件或者集成產品時查找缺陷的簡易程度。
　　可追溯性：對一個特殊需求容易找出相應的代碼，反之，也能夠根據代碼找出特定的需求。
　　兼容性：軟件、硬件、通訊系統之間協調及兼容其餘系統的能力。
　　可解釋性：相關文檔齊全、符合標準、邏輯清晰、描述準確、用詞恰當，容易理解和定位。
　　六、可移植性質量指標
　　適應性：系統不依賴於環境，即系統不作修改或做不多的修改便可運行在其餘環境下。
　　易安裝性：與在指定的環境下安裝軟件所需努力有關的軟件屬性。如在線更新、安裝包自動生成等。
　　可重用性：一個軟件組件除了在最初開發的系統以外應用於其餘系統的能力。
　　互操做性：軟件系統與其餘系統交換數據和服務的難易程度。
　　可替換性：與軟件在該環境中用來替代指定的其餘軟件的機會和努力有關的軟件屬性。

測試用例的維護、
軟件產品的版本是隨着軟件的升級而不斷變化的，而每一次版本的變化都會對測試用例集產生影響，因此測試用例集也須要不斷地變動和維護，使之與產品的變化保持一致。如下緣由可能致使測試用例變動：

1）軟件需求變動：軟件需求變動可能致使軟件功能的增長、刪除、修改等變化，應遵循需求變動控制管理方法，一樣變動的測試用例也須要執行變動管理流程。

2）測試需求的遺漏和誤解：因爲測試需求分析不到位，可能致使測試需求遺漏或者誤解，相應的測試用力也要進行變動。特別是對於軟件隱性需求，在測試需求分析階段容易遺漏，而在測試執行過程當中被發現，這時須要補充測試用例。

3）測試用例遺漏：在測試過程當中，發現測試用例未覆蓋所有需求，須要補充相應的測試用例。

4）軟件發佈後，用戶反饋的缺陷：代表測試不全面，存在還沒有發現的缺陷，須要補充或者修改測試用例。

對於提供軟件服務的產品，其多個版本經常共存，而對應的測試用例也是共存的，並且測試用例須要專人按期維護，並遵循如下原則：

1）及時刪除過期的測試用例

需求變動可能致使原有部分測試用例再也不適合新的需求要求。例如，刪除了某個功能，那麼針對該功能的測試用例也再也不須要。因此隨着需求的每一次變動，都要刪除那些再也不使用的測試用例。

2）及時刪除冗餘的測試用例

在設計測試用例時，可能存在兩個或者多個用例測試相同內容，下降回歸測試效率，因此要按期整理測試用例集，及時刪除冗餘的測試用例。

3）增長新的測試用例

因爲需求變動、用例遺漏或者版本發佈後發現缺陷等緣由，原有的測試用例集沒有徹底覆蓋軟件需求，須要增長新的測試用例。

4）改進測試用例

隨着開發工做進行，測試用例不斷增長，某些用例隨着系統輸入和當前狀態的變化而變得再也不適用，這些用例難以重用，影響迴歸測試的效率，須要進行改進，使之可重用可控制。

總之，測試用例的維護是一個長期的過程，也是一個不斷改進和完善的過程。--------------------- 版權聲明：本文爲CSDN博主「hallomrzhang」的原創文章，遵循CC 4.0 by-sa版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/hallomrzhang/article/details/84992995