BVT & BAT（版本验证测试和版本验收测试）

　　工作中的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）模块不关注，而对于物流公司则相反。