领测软件测试网：微软自动化测试实战指南

于软件测试范畴之内，微软所拥有的自动化测试组织结构，始终被相当数量的人视作行业之中标杆表率。此套组织结构究竟是以怎样的方式进行运行的呢，并且又存在着哪些方面是值得一般普通测试团队去进行借鉴学习的呢，我们径直去查看它的具体实施办法。

什么是微软眼中的软件测试

对于微软而言，其软件测试并非仅仅是查找Bug，它更是软件开发进程里不可或缺的依赖环节。每日进行一次的版本建造，再加上自动化测试，开发人员需凭借测试结果来确认自身所编写的代码未对已有功能造成破坏。正是这样一种机制，使得整个开发团队能够安心地朝着前方推进。

同时，测试得出的结果同样是项目管理所依赖的基础性依据，在微软之地，项目管理的主要脉络线索便是Bug的生命周期管理，从察觉到Bug开始直至修复后进行验证，其间的每一个步骤均需要借助测试所获取的数据来为决策提供支撑，诸如Bug Bash这般具有阶段性特征的活动，特意促使全体人员都参与进来去寻找Bug，这便是极为典型的实例。

一套完整的自动化测试体系长什么样

此套体系所需六个部分一块协同开展工作。其一为开发环境，涵盖开发语言、库程序、驱动程序以及开发工具。其二系测试用例管理，去负责用例的定义、做设置、去分类以及进行组合运行。其三属运行环境，含有机器池、自动执行安装配置以及运行调度。

有三个部分剩余着，它们分别是代码管理、硬件基础设施以及分析报告这三者。代码管理承担着存储以及编译的任务，硬件涵盖了实验室和测试机器这些，分析报告则给出单次运行结果一类的东西，还有多次综合报告以及长期走势图。以BizTalk Server团队做例子来说，他们运用这样的架构去支撑每日数千个用例的运行活动。

测试用例设计的一个具体实例

选取BizTalk SQL Adapter当作实例来讲，开展测试设计之时应当将SQL数据库与XML消息彼此之间的交互纳入考量范围之内。测试工作的相关人员必须去准备好多张的数据表，进而对真实场景下的消息传递予以模拟。当BizTalk服务器把XML消息接收到以后，借助Adapter将其写入到SQL数据库之中，对于整个流程而言，得对数据完整性跟性能进行验证。

测试用例的运行步骤清晰明了，首先需去验证BizTalk已然妥善安装与配置，接着着手准备测试数据以及预期结果，随后开展落实核心操作，最终将实际输出跟预期予以比对，在这个进程里边，前置条件的验证常常占据了用例代码的半数以上，缘由在于环境问题极易致使测试遭遇失败。

测试用例如何分级和运行控制

微软划分测试用例为四个等级，分别是BVT、第一级、第二级、高级 ，BVT是用于确认核心功能未完全损坏的最简单功能验证，需每日运行一次。第一级覆盖非出错时全部代码路径，隔一日运行一回。第二级涵盖出错时代码路径，每周运行一次。高级针对压力、性能、安全性，按需求运行。

具有单个用例作为最小设置单元的测试用例，其运行以及报告的基本单元是测试用例组合，一个能够包含别的组合从而构成嵌套结构的组合，比如在其中可能有着几十个核心用例的BVT组合，在第一级组合里又包含了BVT组合以及更多边界测试，这样的层级管理使得运行控制极为灵活。

测试报告要看哪些关键数据

要知晓测试报告，可不在于单单看通过率，微软所出的报告里，有着单次运行的结果，还有多次综合起来的报告，以及长期的走势情况。单次的报告，会告知你此次建造是否能够投入使用，综合报告呢，乃是用于对比不同版本的测试结果，而长期走势，它能够让你发现测试覆盖方面存在的盲点。

假设存在一个模块，其通过率连续三天出现下滑情况，哪怕每天都是95%，这种状况也需要予以警惕。长期走势图能够绘制出通过率的变化曲线，借此让团队看到的是趋势而非孤立存在的数字。诸多团队仅仅查看单次报告，结果是每次看到95%时觉得状况良好，然而一个月之后才发觉核心功能已然出现严重退化。

硬件管理和自动化发展的五个阶段

关键在于硬件管理的高级自动化，涵盖实验室建设以及自动测试机器池，系统要做到能动态选用测试机器，要自动安装测试平台，要监控机器工作状态，并且还要支持多机协同运行，要是没有这套基础设施，那再好的测试代码也跑不起来。

自动化发展被划分成五个阶段，其中，无自动测试阶段完全依赖手工，初始阶段着手尝试工具并构建小型实验室，发展阶段引入高级编码人才，借助开发人员协助设计测试代码库，成熟阶段进行系统化地选择与整合各类工具，高级阶段搭建流程模型以及商业服务模型，每个团队能够依据自身技术水平挑选适宜的阶段，无需一蹴而就。

测试自动化的风险和误区

做测试自动化所需付出的代价极为高昂，得依据项目自身的特性以及团队所具备的技术水准来判定恰当的自动化比率。存在一些团队一味去追求百分百的自动化，最终致使维护成本过高，将所有人都压得喘不过气来。一般而言，百分之六十到百分之八十这样一区间的自动化率属于相对健康的范畴，其余部分则借助手工测试予以补充。

常见的另外一种风险是，测试覆盖朝着易于自动化的功能有所偏向，举例来说，界面自动化开展难度高情况下，团队便会特意测试界面的量减少，转而对后端API开展大量测试，这会致使经常被用户操作的界面所出现的问题反倒无法被发现，良好的测试计划得要于自动化难易程度以及功能重要程度之间寻得平衡。

就你所认为的，你们的那个团队当下所处的自动化测试它究竟处于哪一个发展阶段呢，而其最大的瓶颈到底是技术方面，或者是流程方面，又或者是机器资源这儿呢，欢迎于评论区域去分享你的实践情况，与此同时也别忘记点赞并且转发，以此使得更多的测试同行能够看到这一篇文章。