BVT & BAT
版權聲明：本文為博主原創文章，未經博主允許不得轉載。
一、BVT: (Build Verification Test )
BVT的概念：
BVT（版本驗證測試）是在所有開發工程師都已經checkin完自己的代碼，並編譯完成，生成當天的版本之后進行，主要目的是驗證最新生成的軟件build版本功能的完整性，主要的軟件特性的正確性。如無大的問題，就可以進行相應的BAT測試。
BVT優點是時間短，驗證了軟件的基本功能。
缺點是該種測試的覆蓋率很低。因為運行時間短，不可能把所有的情況都測試到。
BVT測試也被稱為“冒煙測試”。
BVT測試介紹：
BVT (版本驗證測試) 由一組測試組成，這些測試用於驗證特定版本的總體質量。BVT 通常根據設定的計划自動運行，經常在夜間進行。也可以手動運行，例如自動運行失敗后。如果 BVT 中的所有測試均已通過，則認為該版本成功。
也就是說，新生成的軟件，先不急於完全測試，而是在很短的時候內把軟件的基本功能走一遍，看有沒有什么大的問題，如果存在大的問題，就沒有必要再進一步測試了。可以節約時間，提高測試效率。
冒煙測試，也有稱作煙霧測試（smoke Test)，一種用於驗證系統基本功能的實現並達到一定程度的穩定性的測試。這種測試經常用作進入下一個等級的測試的入口准則的一部分。關於冒煙測試，應該是微軟首先提出來的一個概念，和微軟一直提倡的每日build有很密切的聯系。具體說冒煙測試就是在每日build建立后對系統的基本功能進行簡單的測試，這種測試強調功能的覆蓋率，而不對功能的正確性進行驗證。從這一點看和所謂的“接受性（驗收）測試（Acceptance Test）”非常相似。不同之處就在於他們執行的頻率和被測的版本不同。 至於冒煙測試這個名稱的來歷，大概是從電路板測試得來的。因為當電路板做好以后，首先會加電測試，如果板子沒有冒煙在進行其它測試，否則就必須重新來過。類似的如果冒煙測試沒有通過，那么這個build也會返回給開發隊伍進行修正，測試人員測試的版本必須首先通過冒煙測試的考驗。冒煙測試應該是對整個系統流程從輸入到輸出的完整測試。測試不必是面面俱到的，但是應該能夠發現系統中較大的問題。冒煙測試應該是足夠充分的，通過了冒煙測試的build就可以認為是經過充分測試、足夠穩定的。
不進行冒煙測試的build是沒有太大價值的。冒煙測試阻止着產品質量惡化和集成問題的產生，不進行冒煙測試，每日構造可能會變成浪費時間的練習。冒煙測試必須隨着系統的擴充而擴充。
何時應該進行BVT測試：
從BVT測試介紹中可以看出，BVT測試次數越多越好，但現實情況，當拿到新的build版本之后，進行BVT測試，測試通過后，進行BAT測試，之后才給測試組進行接下來細致詳盡的測試工作。若BVT測試未通過，則報出bug，需要修改bug，build出新的版本后，重新進行BVT測試直至BVT測試通過。
BVT測試應該包含的內容：
1、業務流的測試，保證正常業務鏈路的通暢。
2、工作流的測試，主要是測試流程流轉是否正常，至於流程步驟的表單內容是否正確則不關注。
3、關鍵功能的測試，至少要保證系統運轉所需的啟動數據，以及一些開關控制正常。
4、重要基本功能的測試，比如對核心業務有影響的一些增刪改等。
BVT測試的過程：
1、軟件的各個單元測試通過
2、build出新版本
3、拿到最新的版本
4、根據文檔要求准備測試環境
5、執行BVT測試用例 【自動或者手動】
6、BVT測試結束，如果成功，則給測試組進行接下來詳盡的測試工作
如果不成功，報bug，修改bug，重新進行BVT測試
工作中的BVT測試：(如SQL2016RC0 + MS Dynamics AX 62 & 63 )
The Dynamics AX BVT is a smoke test run as part of the official product build that is used for three primary purposes:
- Measure the state of the build, validating product setup, application launch and core feature functionality. A failure indicates no further testing should be attempted.
- Indicator that integration between branches (especially for a reverse integration to “main”) did not break core product functionality
- Indicate if the core capabilities of the product are functional. A BVT with no failures is a strong indicator that the build can be installed and used by internal developers and testers.
步驟：
1、 拿到最新的build后，安裝環境
2、 執行BVT測試【自動或手動，一般fail掉的BVT手動再跑一邊】
3、 BVT測試結束，如果成功，則給測試組進行接下來詳盡的測試工作
如果不成功，報bug，修改bug，重新進行BVT測試
自動跑BVT，是將BVT的cases寫進一個job中，在相應的機器上run這個Job ID，從而跑BVT
手動跑BVT:
參考網站，根據上面的步驟進行手動跑BVT
http://dynamics/functionalteams/test/wiki/Test%20Execution/BVT%20Execution.aspx
工作中的BVT包含哪些cases：
是在用例庫中找出一部分用例作為BVT的測試用例，被挑選出來的BVT用例的特點:
1、 AX的基礎應用及開發部分(the BVT is a smoke test, the BAT suite's goal is to measure the basic functionality of the features in the build，and the BVT has a strong focus on AX Foundation and Development capabilities.)
2、 產品的基本功能測試
3、 應用程序啟動測試
4、 產品設置測試
5、 業務流的測試
6、 工作流的測試
Types of BVT Tests
The BVT test cases will fall into one of the following three categories:
- Foundation Tests - The Foundation feature areas form the foundation of the application design time and run-time experience. These tests are critical for both goals of the BVT.
2. Business Logic Acceptance Tests - Core business logic must work as expected for a build to undergo further testing, especially business logic that is built upon by other logic in the application. These test cases execute at an API layer and are built with the SysTest framework and wrapped by Test Services.
3. Application Smoke Tests - Core application capabilities must exist for a build to undergo further testing. These smoke tests exercise the application through the user interface and are a predictor of success in the next level of testing (BAT).
二、BAT(Build Acceptance Testing)
BAT概念：
BAT指“工作版本可接受測試”。新工作版本正式測試前進行的一項快速測試過程，目的是保證軟件的基本功能和內容正確完整，經過BAT測試后，就進入了正軌測試階段。BVT只驗證build版本構建的成功與失敗，不需要深入測試構建好的build的功能、性能等，同時只考慮功能的覆蓋率；而BAT測試則需要考慮功能，性能等測試，以及考慮功能的覆蓋率的同時，也要考慮功能的正確性。
何時進行BAT測試：
新版本build成功后，且BVT測試通過，接下來進行的一項專項測試，測試目的是：是否要接受這個構建的版本，找出構建版本的主要功能及性能上可能存在的bug。
工作中的BAT測試：
About Build Acceptance Tests for Microsoft Dynamics AX, BAT are a suite of high-priority tests run after an official product build to measure basic functionality of features in the build. Build Acceptance Tests are used to evaluate if key scenarios are functioning as expected. Users of a module, or the entire product, may use successful BAT results as an indicator that the build supports these basic scenarios.
Because BATs represent a subset of important tests from each of the teams, they should also be used to pre-test proposed changes that may have impact that is not localized to a feature team. Running private builds against the BATs prior to check-in provides evidence as to whether the proposed changes are likely to negatively impact tests (and by implication consumers). This pre check-in process is especially valuable for changes where the impact across all features may not be fully understood.
BAT的測試用例也是從用例庫中挑選出來的用例，作為BAT的測試用例，選取作為BAT測試的用例特點：
1、 主要功能的測試
2、 基礎應用 (BAT suite has a focus on end user scenarios for both Foundation and Application functionality.)
The results of Build Acceptance Tests:
· Are an initial measure of build health: low pass rates are correlated with poor build health.
· Allow consumers to determine if they wish to use a build.
· Indicate if basic functionality is working (for those feature areas that are passing).
· Are used to qualify the build as sufficiently high quality for self-host use (all tests passing).
· Are a necessary prerequisite for limited external release of the build for preview and casual usage by Partners (e.g. TAP or CTP drops). (Requires that all tests are passing.)
三、BVT & BAT的區別
Unlike Build Verification Tests (BVTs), the results of BATs are not intended to be all or nothing, but allow the consumer to determine the state of the features of interest.
BATs run after each official build (after BVTs have passed) and do not “cause” build breaks if one or more of the tests fails. The run results of the BATs (and BVTs) are used to categorize the build into one of three states:
Self Host: A build where the BVT and BAT runs have a Pass Count greater than zero and a Fail Count of zero.
Self Test: A build where the BVT has a Pass Count greater than zero and a Fail Count of 0, but the BAT either has a Pass Count of zero, or a Fail Count greater than zero.
Self Toast: A build where the BVT has a Pass Count of zero or a Fail Count greater than zero.
BAT測試一般位於BVT測試之后進行，同時，兩個測試的側重點不同，BVT更側重於build版本功能的完整性，對於功能的覆蓋率，正確性及性能等各方面沒有很大的要求，而BAT則相反。同時，BAT測試中的case，允許用戶自己決定關注點應該更多的放在哪個模塊，比如說對於一個金融會計公司，更關注財會模塊（Finance，General journal等）功能的完整性和正確性的狀態，對於供應鏈（supply chain）模塊不關注，而對於物流公司則相反。
博主：海寧
聯系：whnsspu@163.com