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