作者：admin 時間：2022-08-26
本文為《軟件可靠性簡介》培訓課程中摘錄的公開內容。
本文目錄：
一、軟件測試的概念
二、軟件測試的分類
三、軟件測試計劃
四、測試用例的設計
五、測試用例的評審
六、如何記錄Bug
七、回歸測試
八、測試報告的輸出
本文為拓展內容，《可靠性工程師》一書中并無此內容。
一、軟件測試的概念
首先，我們要明確軟件測試和軟件可靠性測試是不同的。軟件測試是從前期需求文檔的評審，到中期測試用例及測試執行，再到后期問題單的提交和關閉等一系列的測試過程。
而軟件可靠性測試，我們在上一節講過了，是指為了滿足用戶對軟件的可靠性要求，基于用戶使用模型對軟件進行測試，發現并糾正軟件中的缺陷提高軟件的可靠性水平，并驗證軟件能否達到用戶可靠性要求的軟件測試方法。
軟件錯誤：測試人員在測試軟件的過程中，當發現實際運行的結果和預期的結果不一致時(這個預期的效果其實就是指需求文檔里面的規格要求)，就把這個不一致的地方統成為軟件錯誤。
軟件錯誤不僅僅是指與需求文檔不符的地方，在測試過程中，測試人員發現有影響用戶體驗和使用的任何地方，都可以把它當做軟件錯誤提出來。軟件錯誤稱為Bug(Bug、錯誤、缺陷、問題，這四類表述是同一個意思)。
二、軟件測試的分類
根據測試原理，軟件測試可以分為黑盒測試、白盒測試、灰盒測試。
◆黑盒測試：黑盒測試(Black-box testing是通過使用整個軟件或某種軟件功能來嚴格地測試而并沒有通過檢查程序的源代碼或者很清楚地了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的。測試人員通過輸入他們的數據然后看輸出的結果從而了解軟件怎樣工作。通常測試人員在進行測試時不僅使用肯定出正確結果的輸入數據，而且還會使用有挑戰性的輸入數據以及可能結果會出錯的輸入數據以便了解軟件怎樣處理各種類型的數據。
◆白盒測試：白盒測試(White-box testing或glass-box testing是通過程序的源代碼進行測試而不使用用戶界面。這種類型的測試需要從代碼句法發現內部代碼在算法，溢出，路徑，條件等等中的缺點或者錯誤，進而加以修正。
◆灰盒測試：灰盒測試(Gray-box testing就像黑盒測試一樣是通過用戶界面測試，但是測試人員已經有所了解該軟件或某種軟件功能的源代碼程序具體是怎樣設計的，甚至于還讀過部分源代碼，因此測試人員可以有的放矢地進行某種確定的條件或功能的測試。這樣做的意義在于：如果你知道產品內部的設計和透過用戶界面對產品有深入了解，你就能夠更有效和深入地從用戶界面來測試它的各項性能。
按測試階段，軟件測試可分為4個階段，分別為單元測試、集成測試、系統測試、驗收測試。
◆單元測試：一小段代碼稱為軟件系統的最小組成單元，單元測試指對這小段代碼進行測試。采用白盒測試的方法，主要由開發人員來做。
◆集成測試：單元模塊組合在一起形成“組合體”。集成初期，模塊比較少，采用白盒測試，由開發人員執行。集成后期，由于集成模塊越來越多，模塊之間的依賴性越來越強，此時，可對軟件進行部分的功能測試，采用黑盒測試，一般也是由開發人員進行。
◆系統測試：對軟件系統做全面測試，關注軟件的外觀界面、功能、性能、性、易用性、兼容性，采用黑盒測試方法，由測試人員進行。
外觀測試：界面功能模塊的布局是否合理，整體風格是否一致，界面文字是否正確，命名是否統一，頁面是否美觀，文字、顏色、圖片組合是否等。
功能測試：軟件所呈現給用戶的所有功能點是否都能正常使用和操作，是否滿足需求文檔里的要求。
性能測試：軟件在不同環境和壓力下是否能正常運轉，其中有一個很重要的指標就是系統響應時間。
性測試：測試軟件防止非法侵入的能力。
易用性測試：測試軟件是否容易操作，主觀性比較強，站在用戶的角度體驗軟件產品好不好用。
兼容性測試：測試該軟件與其他軟件的兼容能力，例如經常見的：與瀏覽器的兼容。
◆驗收測試：由用戶進行的測試，測試的內容與系統測試的內容相似，主要測試軟件系統是否滿足需求文檔里的要求、是否滿足用戶的需求。采用的方法也是黑盒測試。通常驗收測試通過之后，軟件才能交付投產。例如：PLM系統的UAT1測試，UAT2測試。
三、軟件測試計劃
軟件測試前，首先會制定軟件測試計劃，包括測試范圍的描述、測試環境、測試策略、測試管理和測試中可能出現的風險。
測試范圍：主要測試哪些內容，哪些內容不在本次測試范圍中，是否需要額外的測試。
測試環境：運行軟件的軟硬件環境。例如測試的溫度、濕度，也屬于硬件環境。
測試策略：包括測試的依據、測試的準入標準、測試工具的選擇、測試的重點及方法、測試的準出標準等內容。
測試管理：任務的分配，時間進度的安排，溝通方式。
測試風險：常見風險有不透徹理解需求溫度、估計不足測試時間、測試執行不到位。
一般有各類模板來體系管控，舉例：一個測試環境確認表(局部摘錄)
四、測試用例的設計
什么是測試用例？測試用例是為某個目標而編制的一組測試輸入、執行條件以及預期結果，以便核實是否滿足某個特定需求。
測試用例是測試的一個例子，這個例子包括：測試序號、測試模塊、前置條件、測試環境、操作步驟和數據、預期結果、實際結果、是否通過、備注這9個關鍵的基本元素。每個公司的規范可能不一樣，有的還包括測試時間、測試人員、軟件的版本名稱、優先級等一些附加元素。
我們以郵箱登錄為例：
一個測試用例如下：
五種常見測試用例設計方法：
(1)等價類劃分法
等價類劃分法是一種重要的、常用的黑盒測試方法，它將不能窮舉的測試過程進行合理分類，從而保證設計出來的測試用例具有完整性和代表性。
這里有兩個概念，有效等價和無效等價。
有效等價：有效，是指它們都是符合需求文檔中定義的數據；等價，是指它們都是同一類型的數據。
無效等價：無效，是指它們都是不符合需求文檔中定義的數據；等價，是指它們都是同一類型的數據。
舉個例子，很多時候我們會有填年齡的情形，假設要求的是填20-99的整數。
那我們就可以把值劃分為：
取代表性數據后：
(2)邊界值分析法
邊界值分析法是取稍高于或稍低于邊界的一些數據進行測試，通常被視為對等價類劃分法的一種補充。
在以下兩種情況下經常被用到：第一種，輸入條件是一個取值范圍；第二種，輸入條件規定輸入的數據是一個有序集合。
為什么要取這些數據做測試？因為測試經驗告訴我們，程序在處理邊界數據的時候容易出錯。
繼續上面的例子：
涉及的邊界值如下：
(3)錯誤推測法
測試人員憑借自己的直覺、測試經驗、發散思維去設計一些容易導致軟件出錯的測試點，也可看作是對等價類劃分法和邊界值分析法的一個補充。
還是這個例子：
一般情況下，程序在處理空格、空的、邊界值、超長字符串、全角字符串、0以及單引號等情況下較容易出錯。所以使用錯誤推測法，取值如下：
工作中可根據自己的想象力，或者參考以前測試過的模塊和設計過的測試用例，盡可能地多去設計出有可能讓程序出現錯誤的測試點。這個就比較靠想象力和經驗了。
測試數據的整合
運用前面3種測試用例的設計方法，把測試點統一到一個表中，就變成了一個較為完整的測試用例。
測試用例中可能存在等價，如上表中的16和19，103和100，如何選??？一般可以把靠近邊界的值保留下來，對于相對復雜的需求文檔，也可以把這些數據全部測試一遍。
(4)正交表分析法
正交表分析法是一種有效地減少用例設計個數的方法。測試人員需要根據實際的業務場景和組合特點進行算法設計，時還可以咨詢開發人員，最終的目的就是選擇一些典型的組合進行測試。
我們舉個例子，某個人信息查詢系統的查詢頁面如下，只有3個框都輸入時才可查詢：
我們要驗證的就是3個框都有輸入時才可以查詢，其他情況都不可查詢。它全部的組合可能如下，一共8個組合，稱之為3因子2水平全測試用例：
而如果我們采用正交表方法，則可以用如下組合去完成驗證，對比原來少了3個測試用例：
再舉一個例子，假設一個WEB站點，該站點有大量的服務器和操作系統，并且有許多具有各種插件的瀏覽器瀏覽：
WEB瀏覽器：Netscape6.2、IE6.0、Opera4.0
插件：無、RealPlayer、MediaPlayer
應用服務器：IIS、Apche、Netscape Enterprise
操作系統：Windows2000、Windows NT、Linux
屬于4因子3水平，全部組合會去到3^4=81種，測試起來就很麻煩?？梢杂谜槐砣ピO計，我們選L9，我用minitab跑了出來：
WEB瀏覽器：1＝Netscape6.2、2=IE6.0、3=Opera4.0
插件: 1=None、2=RealPlayer、3=MediaPlayer
應用服務器: 1=IIS、2=Apche、3=Netscape Enterprise
操作系統: 1=Windows2000、2=Windows NT、3=Linux
把因子、狀態映射上去，就得到了正交表：
(5)因果判定法
因果判定法一般主要應用于頁面中各類按鈕之間存在組合和制約的關系，測試人員需要去分析它們的因果對應關系，并最終去檢查輸出結果的正確性。
比如這個例子，常見的就是公交充值，地鐵充值。
列出它的因果判斷表如下：
因果判定法的步驟：
1.明確所有的輸入條件(因)。
2.明確所有的輸出條件(果)。
3.明確哪些條件可以組合在一起，哪些條件不能組合在一起。
4.明確什么樣的輸入組合條件可產生哪些輸出結果。
5.通過判定表展示輸入條件的組合與輸出結果的對應關系。
6.根據判定表設計測試用例。
我們做家電，很多按鍵的組合，是可能存在的，其實應該去做因果判定。
比如我舉一個例子，假設某機器，只有2個按鍵，長按，短按，同時按，都會有不同的結果，我們假設是如下表這樣要求的：
這樣一個因果判斷表，我們看起來覺得很簡單。但是軟件設計的時候，就很可能會出錯。例如對按鍵的去抖沒做好，對兩個按鍵信號的優先級沒有考慮好，就很可能出問題。
我遇到的一個真實的案例，用戶真就誤觸發了組合按鍵，而這個按鍵理論上不應該被用戶觸發。
五、測試用例的評審
我在講評審時提到，評審是包含方方面面的，包括了測試方案的評審。
測試用例評審的目的在于，通過測試用例的評審，確保用例是全面的、正確的、沒有冗余的。
評審主要內容包括：
1.測試用例是否是依據需求文檔編寫的。
2.測試用例中的執行步驟、輸入數據是否清晰、簡潔、正確；對于重復度高的執行步驟，是否進行了簡化。
3.每個測試用例是否都有明確的預期結果。
4.測試用例中是否存在多余的用例(無效、等價、冗余的用例)。
5.測試用例是否覆蓋了需求文檔中所有的功能點，是否存在遺漏。
需求、開發過程中是存在變化的，測試案例在不同的階段需要維護。
如同FMEA一樣，很難見到一份非常的測試用例，你很難窮舉覆蓋所有，寫得很。
我自己參與過的大項目測試，就覺得有些測試用例描述不清晰，且覆蓋不夠。因為內部項目，這里就不舉例放出來了。
六、如何記錄Bug
1.Bug的概要要清晰簡潔。
2.在Bug的具體描述中，測試的步驟和使用到的具體數據都要清楚地寫出來。
3.如果可以截圖，要截圖，因為這是最直接的證據。
主流Bug管理工具有很多，如Test Director(簡稱TD)、Quality Center(簡稱QC，它是TD的升級版)、JIRA、禪道、Mantis以及各公司自行開發的Bug管理工具等。
七、回歸測試
開發人員把Bug好之后，測試人員需要重新驗證Bug是否好了，同時在新版本中進行測試以檢測開發人員在代碼過程中是否引入新的Bug，此過程稱為回歸測試。
1.回歸測試執行全部的測試用例。一般情況下，當第一輪測試發現的Bug數量過多時，第二輪回歸測試應該執行全部用例。
2.選擇重要的功能點、常用的功能點、與Bug相關聯的功能點進行回歸測試。
3.選擇性執行關鍵功能點的測試用例。
4.僅測試出現Bug的功能點。
每個策略都有其適應的場景，不能一概而論，應當以Bug的數量和嚴重程度為導向，深入分析，然后得出適合本項目的回歸測試策略。
說到回歸測試，我就覺得我們比較痛苦，原因是開發過程中，很可能因為需求變化，導致程序要改變。
八、測試報告的輸出
最后輸出測試報告，描述軟件的測試過程、測試環境、測試范圍、測試結果，分析總結存在的風險以及測試結論。
舉例：一份軟件測試報告內容
本文參考書籍：《軟件測試工程師》（江楚 編著）
以上文章來源于永恒之地，作者徐步陌上行
國可RFMEA
與傳統的FMEA分析方法和軟件相比，R-FMEA最大的特點是通過其七步的分析流程， 構建了關聯緊密的FMEA基礎數據關系，即FMEA主模型。通過FMEA主模型，工程人員可以根據需要構建簡單的或者復雜的FMEA分析， 并實現企業知識的積累和快速重用。
國可R-FMEA軟件支持免費在線使用，并保證數據。日前，R-FMEA V4.6已正式發布，歡迎感興趣的朋友在線申請
版權所有© 國可工軟科技有限公司 滬ICP備2020030271號
中文
英文