IT培训分享常见的几种自动化测试形式都有哪些

在软件测试中UT，IT，ST，UAT指单元测试，集成测试，系统测试 ，用户接受测试。

一、UT(单元测试，Unit Test):

单元测试任务包括：

1、模块接口测试；

2、模块局部数据结构测试；

3、模块边界条件测试；

4、模块中所有独立执行通路测试；

5、模块的各条错误处理通路测试。；

二、IT（集成测试，Integration Test）：

也称系统集成测试（System Integration Test）或结合测试，集成测试阶段是以黑盒法为主，在自底向上集成的早期，白盒法测试占一定的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒法测试占据主导地位。

三、ST（系统测试，System Test）：

从技术角度看，系统测试是整个测试阶段的最后一步，所有的开发和测试在这一点上集中表现为生成一个具有一定功能的软件系统。

该阶段主要对系统的准确性及完整性等方面进行测试。

主要进行：

功能确认测试、运行测试、强度测试、恢复测试、安全性测试等。

系统测试的测试人员由测试组成员（或质量保证人员）或测试组成员与用户共同测试。在整个系统开发完成，即将交付用户使用前进行。在这一阶段，完全采用黑盒法对整个系统进行测试。

四、UAT(验收测试，User Acceptance Test):

验收测试是向未来的用户表明系统能够像预定要求那样工作。

经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。

扩展资料

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中软件规模都很小、复杂程度低，软件开发的过程混乱无序、相当随意，测试的含义比较狭窄，开发人员将测试等同于“调试”，目的是纠正软件中已经知道的故障，常常由开发人员自己完成这部分的工作。

对测试的投入极少，测试介入也晚，常常是等到形成代码，产品已经基本完成时才进行测试。

到了上世纪80年代初期，软件和IT行业进入了大发展，软件趋向大型化、高复杂度，软件的质量越来越重要。

这个时候，一些软件测试的基础理论和实用技术开始形成，并且人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。

参考资料：

百度百科 - 软件测试

IT部分大概分：需求分析部分，产品设计部门，软件研发部门，软件测试部门。

目前比较容易入手，而且起薪比较高的，就是软件研发和软件测试，随着这工作的深入这两个行业可以逐渐往产品和需求两个方向发展。

软件研发的主要语言分为：C#，Java，php，C语言等等

软件测试的主要学习自动化测试，还有一些脚本的编写能力。

软件研发目前Java是第一大语言，应用广泛，入门快，薪资高，第二梯队，就是C#，php，python，C。学习Java可以在网上下载免费的视频，当然也可以管我要，自学能力好的当然可以自己研究学习，然后找工作，不过难度挺大，因为涉及到很多技术难点要克服，个人毅力还要坚强，市场环境要分析，简历撰写也有很多学问，流行技术如果没有企业实战经验和指导自己摸着石头过河怕是会耽误时间甚至掉进坑里不能翻身。能花钱买到的服务尽量不要用时间去交换，寸金难买寸光阴。

软件测试从去年开始市场环境比较好，就业环境也比较乐观，毕竟伴随着软件蓬勃的发展，人们对于用户体验的要求也越来越高，软件测试的重要性也显得越来越重要。而且软件测试入门相对于开发来说更简单一些，而且工作也不是很累，所以成为很多人的选择。

自动化测试的问题我们在前几期的文章中已经给大家分析过很多了，而且就不同的运行环境下的自动化测试方法也做了归类，下面IT培训就一起来了解一下，目前比较常见的几种自动化测试形式都有哪些。

物联网测试

物联网(InternetofThings，IoT)正对测试领域产生显著的影响。像Selenium这样的传统自动化方法在嵌入式环境中变得毫无用处。我们已经看到越来越多的基于Python和C/C++的测试框架执行单元测试、集成测试和系统测试。大多数测试框架都是测试由这些嵌入式库导出的API，其中相当多的框架调用嵌入式代码来执行单元测试。这需要具有重要软件开发经验的专业测试工程师，但我们看到更多的软件开发人员将被部署到自动化测试的角色。Python可能是物联网测试框架开发的选语言，因为它能够直接使用ctypes包来调用C代码。

另一个新趋势就是物联网的DevOps环境开始标准化。到目前为止，我们看到的大多是CI环境的Ad-hoc实现。我们已经预先构建了解决方案，用于构建管理、测试管理、镜像加载、物联网镜像在不同设备上的部署、不同构建物联网设备的A/B测试等。

持续测试

持续测试是从去年至今仍在继续的另一个趋势。我们在过去已经看到了DevOps和CI/CD框架的爆炸式增长，而今年这种趋势，将随着新的框架(如Nevercode和Codefresh)的出现而继续。

持续测试的另一个趋势是对每个版本进行基于人工智能的风险评估。以前，这种 *** 作是手工执行的，以确定能为应用程序部署哪些版本。我们已经实现了几个CI/CD平台，它们执行应用程序基于人工智能的自动A/B部署。

基于人工智能的测试

基于人工智能的测试方法已不仅仅是时髦语，现在已经进入了主流测试实践。人工智能和自动化是测试的两个并行方面：自动化用于功能测试，而人工智能则用于视觉测试。基于人工智能的视觉测试，包括视觉测试和感觉测试，并快速浏览每个构建版本的视觉变更，是一个非常有用的发布验证方法。我们已经在Denver的不同客户中实施了基于Applitools的视觉测试解决方案。

刚工作的第一个任务是搭建缺陷管理系统。在朋友的帮助下，我知道了缺陷管理系统有 TD 、JIRA和bugzilla ，前两个是收费的，bugzilla是开源。这对当时的我来说绝对是一个有挑战的事情。我当时花了一周时间，尝试搭建这三个环境中的任意一个都没有成功，晚上稿到凌晨一两点，压力很大的说。最后，在一次偶然的一次搜索中发现了禅道，那时禅道10刚发布。加了他们的群。搭建非常简单。一个上午就稿定了，非常感谢王春生（bugfree\禅道的作都）。然后，得到老大的认可，开始在我们项目组使用。

第二个困难就是老大让我对目前的项目做一次性能测试，晕死。一入行两天就稿这么牛B的东西，自我膜拜一下。哈哈！老大推荐我用JMeter 和apache ab，apache 是个小工具。jmeter配合badboy使用，下了个jmeter中文文档。也算把第一份性能测试报告做出来了。不过，现在看来，那个报告没有一丝价值。

其实，这里不得不提一下博客园jacke的博客，也正是看了他的博客自己才对性能测试略有所悟，虽然，他近两年很少写技术博客，但他以前的好多文章仍然非常好。这也是我在博客园安家的原因。

之后的性能测试中，我开始采用loadrunner，因为在用jmeter的过程中，有些问题以我当时的水平无法理解。比如，百度地图，当你打开那个页面时，先出现的一定是框架，地图的显示要慢一点显示出来。但我通过badboy录制脚本时。Badboy会把那个框架与地图转化成两个地址，虽然他们调用的不是一个数据，但他们毕竟在一张页面上显示的。Jmeter会分别对这两个地址进行加压。我不知如何描述这个页面加载完成的时间。

所以，loadrunner是将一个 *** 作定为一个脚本。比如，一个登录，一次填写提交。这样我把重点放在结果分析上就行了。但实际也没想的那么简单。Loadrunner与浏览器的兼容问题比较麻烦，还有在录制的脚本的过程中还遇到不少问题、参数化、集合点等等。其实，对于新手来说，学习LoadRunner的难点应该在录制脚本的部分，新手往往会在录制的过程中遇到各种问题。至于结果分析，主要是看自己性能测试知识的积累，还有对被测系统理解的程度。

学习LoadRunner时，对我最大帮助的是播布客论坛，上面有大量的视频。最适合初学者观看。尤其要感谢无私奉献小布、小强老师。但那hp单点登录系统的广告也听得烂熟于心了，哈哈！天下哪有免费的午餐。

之后的工作都比较我顺利了，又不是太忙，关于功能测试主要是你对公司项目的熟悉程度，平时多搜集一些通用测试用例，比如，文件上传下载用例，用户登录用例，查询功能测试用例。积累的多了一看到一个功能，测试思路自然就有了。

后面，开始看QTP自动化功工具的视频，把自带的飞机订票系统练习了一下。为此还买了一本书《QTP自动化测试进阶》，因为没有项目拿来练手，学起来动力不足，再加上好多项目并不适合自动化。又要学习VBS脚本。于是学了一点就丢那里了。

当然，其间又了解了许多个测试相关的工具，测试死链接工具Xenu、页面性能测试工具Charles 、网络安全性测试工具Appscan 。

本文涉及到测试用例的编写规范，以及用例管理的分享，因此，无论是对于初级测试工程师，还是质量团队的管理者，都有一定的参考意义。文中涉及到的方法和工具并不是唯一解决方案，希望大家收获到的不仅仅是文字表面，而是文中分享的一些思路。

有人说：测试用例还不知道？不就是描述测试步骤吗？

这么回答确实没什么错，只是如果内心上也仅仅这么认为的话，只能说并未理解测试用例。

测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(Use Case) 以及自身对业务领域知识的经验，一个软件测试工程师的专业度往往体现在他设计的测试用例上。

专业的工程师设计出的测试用例集，不仅能够描述自己的行为，还能指导别人实施，不仅强调深度，还具有优秀的用户思维。

虽然从格式上来说，基本就定型了：

关于这部分，网络上的教程只多不少，就不赘述了。

只不过要强调的重点是， 格式只能保证测试用例明晰，并不能提升测试用例的设计能力 。因此，测试用例该怎么写？还是要从结构化设计开始。这里需要提到一个概念 HLTD [ High Level Test Design ]，可以简单粗暴的理解为测试大纲的设计。

就如同我们写文章一般，提笔正文之前，会先拟个草稿，列出中心思想及段落提纲，然后再攥写润色。

写测试用例也是类似的套路，先列出测试点作为大纲，并且具有结构化布局。通常以大的功能或模块进行分类，再细化二级甚至三级类别，最终列出具体的测试点。该阶段的设计，笔者倾向于利用思维导图（脑图），相较于传统的文档软件工具，思维导图的展现更直观。

由于最终会是一张大图，所以硬伤也随之体现，只适合用于思路梳理，不适合用于文档化管理。

把这些结构化好的测试点文档化，就是我们所说的测试用例了。

所以从这里我们可以看出，每一条测试用例的目的很明确，是验证一个或一类测试点，颗粒度需要根据公司实际情况权衡，太粗不利于对于测试点覆盖的总结，拆太细会消耗更多的精力。

测试用例其实是一个非常详尽的文档，必然会消耗测试工程师相当一部分的精力。在传统软件开发时代，甚至作为 KPI 的一项指标。

但随着敏捷时代的兴起，有一种声音开始冲击这种认知。

早期的敏捷实践者，对敏捷宣言的解读仅仅停留在了文字表面，认为“只需要软件，不需要文档”。这直接导致了这一时期，大量的团队缺失了详尽的文档，甚至连一些基本的文档都没有。

如今，越来越多的敏捷实践者认识到，敏捷宣言所宣扬的并不是“不用详尽的文档”，恰恰相反， 敏捷宣言认同了“详尽的文档很重要”这件事，并且提出了更高的要求 —— “工作的软件更重要”

对于测试用例文档化工具的选择，很多团队仍然停留在传统的办公软件，如 Word、Excel

但如今凡事比快的市场环境下，团队成员高效协作、团队信息实时共享的需求越来越高，测试用例平台化管理必然还是最终归属，除了文档化，还利用平台制定计划，展示进度和结果。

事实上，在传统时代，大一些的软件公司就已经使用平台来管理测试用例了，这再一次证明了敏捷时代并不意味着推翻过去的经验和成果，而是提出了更高的要求。

如今，相对知名的管理平台有基于 Jira 做插件的，如：Zephyr、Xray、synapseRT、TM4J，也有独立的开源平台: 如：TestLink，或收费的独立平台: 如：TestRail

我们主要从其生态、推行成本、可扩展、费用角度去综合考虑。

Zephyr 的名气一直都很大，但实际上并不太符合国人使用的习惯，使用起来诸多不便。用例直接使用 Jira issue，功能比较简单，用例管理主要在计划和循环的关联上。由于其是 Jira 插件，因此能很好的跟 Jira 上其他 issue (需求、任务、缺陷) 进行关联。但其用例管理的可视化不是很好，没有用例集的概念。迁移方面，数据导入支持类型有限。扩展方面，若要使用其 API，还需要另外装一个插件。其费用中等。

Xray 算中规中矩，也是使用 Jira 的 issue 来创建测试用例。但其新增的 issue 类型多达 5 类，显得极其复杂。关联能力与 Zephyr 相同，数据导入支持类型有限，本身有 API 可供使用。其费用中等。

synapseRT 是国人开发，汉化效果最好，功能强大。有用例集的概念，用例也是用的 Jira issue 来扩展。数据导入支持了 TestLink、Zephyr 这样的其他平台。关联能力同 Zephyr，数据导入支持类型依旧有限，其本身也有 API 可使用。而费用相对较低。

TM4J 使用独立页面管理测试用例，脱离复杂的 Jira issue 页面，上手难度低。数据导入功能强大，覆盖很多类型及一些知名平台。关联能力与上述插件一致，本身也有 API 可使用。但费用相对较高。

TestLink 作为独立的测试管理平台，功能全面，开源免费。可以关联 Jira 这样的知名平台，但由于不是 Atlassian 体系，所以生态体验不高。硬伤是界面丑陋，容易影响工程师的心情。笔者曾经使用其本身的 API 进行 UI 美化。

TestRail 是一个强大的商业平台，笔者接触不多，不乱作评论。

综合考虑，虽然 TestLink 作为免费开源用例管理平台中的 TOP，在用例管理上做得非常科学，一直值得学习，但笔者所在公司已经在使用 Jira，并在落地 DevOps，外加笔者常受 Atlassian 中国社区研究院副院长的支持，TM4J 成为最终选择：

出品方还是挺强的，除了 TM4J，Zephyr 其实也是其下产品，Swagger 也已经是目前认知度很高的产品了。

从官网介绍上可以看出，TM4J 还是比较现代化的：

首先我们看看利用 TM4J 如何来编写测试用例。

层级结构上，我们根据 HLTD 来创建目录以及子目录，以方便所有人理解和阅读，最后的测试点则实例化为一个测试用例，它拥有全局唯一的 Key。

点击 New 按钮创建新测试用例，默认在 Details 标签页，在这里定义用例名称、目的、前提条件，详情中可以设置状态、优先级、所属组件，并可以添加一些便于管理的标签。

切换到 Test Scripts 标签页，默认是 Step-by-Step 类型，按照 STEP - TEST DATA - EXPECTED RESULT 添加每一个测试步骤。

另外值得一提的是，在 Traceability 标签页，可以关联 Jira issue、Confluence page

通常我们针对每次产品发布交付，需要制定范围，因此计划管理是必不可少的。

计划管理推荐按照发布版本来制定顶层目录，然后针对测试类型创建二级目录，如回归、新功能、端到端、接口、性能等等。

测试计划的创建本身 *** 作倒并不复杂，除了定义计划名称、目的、状态、责任人，外加一些标签。

还需要关联一下需求或者 Confluence 页面。测试周期在刚创建测试计划的时候可能并不存在，可以在之后创建测试周期的时候，会双向关联。

测试周期是一个承上启下的关键，往上关联测试计划，往下关联具体的测试用例。

通常一次发布交付会经历 3-5 次冲刺，每轮冲刺的范围不一定完全相同。

在新建完测试周期名称、描述以及详情之后。

进入 Test Cases 标签页，点击 + Add test cases 添加已经编写好的测试用例。

这一步 *** 作使得测试用例具备了项目属性。

最后在测试周期的 Traceability 标签页点击 Test Plans 后面的放大镜。

通过查找来关联已经做好的测试计划。

创建完测试周期，就可以进入该周期浏览到分配到自己名下的测试用例了，这是所有测试执行者都需要用到的界面，还可以通过 Group by 根据不同规则进行归类，比如根据测试周期中制定的不同目录。

对于用例步骤的执行，TM4J 提供了一些快捷按钮，可以直接标记通过、失败、阻塞，并且可以点击齿轮按钮，快速创建、查找 Jira issue 进行关联，当然，除了对于步骤关联 issue，也可以针对该用例标记 issue，点击 Issues 后面的 + ▼ 可进行 *** 作。统一平台的好处便是在此了。

虽然我们在查看测试周期列表的时候可以看到测试的进度，但更多数据展示可以通过测试报告来体现。

TM4J 的 Reports 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。

最后，笔者想说， 测试工作不能作为一个独立的业务，应该更多的与其他角色协作 ，特别是在现在的敏捷时代，测试用例的执行可以要求开发工程师关注，测试的状况可以要求产品经理随时介入，因此，强烈建议我们软件测试工作者尽量选择一些跨职能协作平台。

功能测试：验证软件产品功能是否如其 *** 作手册所述或按用户需求实现，具体方法包括边界值、等价类等，在软件生命周期各个阶段决可进行；例：检验

输入身份z是否符合要求，可以根据输入字符类型、长度、格式等内容检验其是否符合要求；

集成测试：一般是在开发过程中，各个单独开发完成的模块进行拼装后检验其整体协同工作能力及交互能力的测试，以确认数据、接口的准确为主；例：模块A的输出为模块B的输入，两个模块各自测试通过并进行拼装后，由A输入数据，检验B的输出结果是否正确；

兼容性测试：检验软件产品在其预期的不同环境的工作能力，包括软硬件环境，如不同的机型、 *** 作系统、数据库、中间件及其它相关软件；例：检验软件是否能在Unix、Linux、Windows98、Windows2000、WindowsXP、Windows2000环境运行，需要数据库支持的是否在Oracle9i、Oracle10g下均能正常工作，系统中安装不同版本Office工具时是否正常工作；

性能测试：检验某功能一模块或软件产品整体的工作效率，包括资源占用率、执行响应时间、B/S或C/S结构的还涉及用户并发能力等，性能测试有些可以手工实现并通过简单的工具进行监控，用户并发方面则多利用测试工具（如Loadrunner）进行测试；例：单位网站多用户并发测试，检验不同数量用户登录访问网站时，服务器的承受能力，如能支持多少用户并发访问，用户进行 *** 作时服务器系统资源占用情况，不同用户并发 *** 作过程单一业务执行响应时间等。

软件测试技术是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽快尽早地发现在软件产品中所存在的各种问题——与用户需求、预先定义的不一致性。检查软件产品的bug。写成测试报告，交于开发人员修改。

以上就是关于在软件测试中UT，IT，ST，UAT分别是什么意思全部的内容，包括:在软件测试中UT，IT，ST，UAT分别是什么意思、学什么软件测试比较好、IT培训分享常见的几种自动化测试形式都有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！