如何管理软件测试环境

如何管理软件测试环境

概述

管理软件测试过程中相关的测试环境是软件测试人员必备的能力之一，也是高效提升测试过程和测试质量必备的基础能力。

什么是测试环境

测试环境是软件测试团队用于执行测试用例的一系列软件和硬件的集合。

换句话说：在测试环境，软件测试团队可以对硬件、软件、网路等基础设施进行配置、管理。

测试环境关键配置

对于测试环境的管理有哪些关键性的管理因素或配置呢？下面列出了一些关键的需要进行管理的方向：

系统和应用程序

测试数据

数据库

前后端运行环境

浏览器

硬件设备及操作系统

网络

文档包括但不限于：文档、配置手册、安装手册、用户手册等

测试环境配置过程

交互人员角色

因企业、团队不一样，过程也会有些不一样的地方，但在测试环境配置过程中，一般得涉及与以下角色进行交互：

系统管理或是运维人员

开发人员

测试人员

其他对测试环境或相关技术有影响的人员

整个测试环境配置管理的过程中，需要与不同的人员进行交互协作，才能确保环境的有效管理，为测试实施提供一个稳定的基础环境。

测试服务

因测试目标服务的技术不一样，所涉及的技术也会不一样，所要维护的测试服务也会不同，例如我们以java技术为例，那么所需要维护的测试服务将会以java相关中间件为主，例如jdk版本等等

因部署方式不一样，可能维护的量也会不一样，例如分布式部署还是集中式部署等等

网络

在网络方面，也是一个要重点关注的方向，由于现在云技术的发展，我们要维护管理的网络也会不同。

以往通常维护，本地网络即可，而现在可能需要维护本地网路，同样也需要维护云，甚至本地和云混合的网络，以及wifi网络等等，整个网路结构更为复杂。

测试设备

我们统一把PC、手机、平板、嵌入式设备等都归为测试设备，随着业务的负责、用户场景的离散化，同一个业务可能需要在PC端、移动端、专用设备等等上提供服务，对软件测试人员而言，需要维护不同类型的测试设备，同时还需要在不同测试设备上构建不同的测试模拟环境，这也是一个很大的挑战。

测试设备利用率管理

测试设备维护管理

测试设备上构建用户模拟环境及维护

原始的手工管理还是利用系统来自动化的维护管理

等等

测试报告

测试报告跟踪管理工具也是必须提供的，以便跟踪回溯及分析。

测试数据管理

一个好的测试数据管理策略，不仅仅包括业务测试数据的管理，同样也应该提供基础数据的管理，包括配置、业务测试数据等等，需要至少做到以下几个方面：

测试基础数据可备份和还原

测试数据的原子化，可高度复用

测试数据的可定制

测试数据的可自动化维护（包括但不限于配置、业务测试数据等等）

测试环境管理的一些难点

高效的规划好可用的资源
如何协调好团队内部和跨团队在有限的资源的情况下，提升资源的利用率

混合环境的管理
随着云技术的发展，企业在综合成本等因素后，通常采用云+私有服务的方式来构建测试环境，对软件测试人员而言，这也是一个不小的挑战

复杂环境管理
业务的复杂，服务的复杂、复杂的部署方式以及跨团队协作，带来的更复杂的测试环境的管理，对软件测试人员的综合能力的要求进一步提升

复杂的配置
涉及更多的基础环境，更广的技术应用，带来了更为复杂和庞大的配置管理，配置管理和维护也变得更为复杂，对软件测试人员而言，如何维护复杂的而庞大的配置也是不小的挑战

关于管理测试环境的一些意见

与测试团队、开发团队、运维团队及其他相关团队进行深度交互，深入理解测试需求、技术架构及难点

在初始化测试环境前，应当全面的检测环境的连通性

检查所有的硬件、软件、需求、配置等，并形成checklist

确定所有测试设备、浏览器等版本信息，并形成checklist

严格规划测试环境的使用计划，例如准入准出原则，什么适合更新，什么时候发布，什么节点清理等等

尽可能的自动化进行管理维护

【经验分享】软件测试用例管理

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

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

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

测试用例除了作为测试行为的描述，更多的是作为被测目标是否达到需求的验证，主要还是考验了一个测试工程师的组织归纳能力，其输入来源往往是承诺书、用例(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 功能给我们提供了丰富的模板，方便一些经验不足的测试质量管理者。

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

为什么要进行软件测试?软件测试的目的是什么?

一款软件开发出来并不能保证其稳定性与毫无漏洞，这就需要进行软件的测试，找出该软件的缺陷。软件测试的目的理解产品的功能要求，检查软件有没有错误（Bug），决定软件是否具有稳定性（Robustness）。

简而言之，软件测试在一家软件企业中担当的是“质量管理”角色，及时纠错及时更正，确保产品的正常运作。

扩展资料：

软件测试工程师主要职责为：

1、负责项目/产品的测试工作，分析产品需求，建立测试环境和计划，保证产品质量以及测试工作的顺利进行；

2、按照软件工程规范和项目管理流程，实施、管理和知道软件开发不同阶段的各种测试，并提交测试报告。测试的计划安排包括人员安排、进度、使用的软硬件环境、测试的流程等；

3、提交测试报告，并撰写用户说明书；

4、参与软件测试技术和规范的改进和制定。

参考资料来源：中国网－软件测试工程师——职场上任我行

软件测试管理神器之zentao(禅道)-BUG管理

禅道在遵循其管理方式基础上，结合国内研发现状，整合了bug管理，测试用例管理，发布管理，文档管理等功能，完整的覆盖了软件研发项目的整个生命周期。在禅道软件中，明确的将产品、项目、测试三者概念区分开，产品人员、开发团队、测试人员，三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，终通过项目拿到合格的产品。

禅道是一个软件全生命周期管理工具，但作为测试人员，可能梗关注其中的bug管理及测试用例管理的模块， 本文就重点说下bug管理。

禅道里面的bug基本流程是：  测试人员提出bug -> 开发人员解决bug -> 测试人员验证关闭。

下面我们来演示下具体的使用方法。

一、创建产品

使用 bug管理功能之前，需要先创建产品，禅道里面设计的理念是bug主要附属在产品概念下面的，添加产品的入口有多个，可以在所有产品页面点击右侧的“添加产品”按钮。

新增产品的时候，需要设置产品的名称、代号，几个负责人信息，可以根据具体情况选择填写必填项。

二、提交bug单到禅道

有了产品之后，我们就可以来创建bug了， 在禅道里面提交bug的方式有两种，一种是测试用例的执行结果为失败时，转bug；另一种是不依赖测试用例的bug，可以直接进行提交。

1、由执行测试用例的测试用例直接转bug单

通过【用例】模块的不通过用例的【转bug】按钮后，可以打开一个bug提交页面。输入相应的缺陷信息后，点击【保存】即可完成缺陷的提交。

2、直接提交bug单

这样的bug提交方式是不依赖于测试用例的。可以直接通过【bug】模块内的【提bug】进行bug提交，提交bug的页面和转bug页面基本一致，但是提bug页面中没有预先填写的信息，这里需要一项一项的输入。输入完成后点击【保存】按钮完成缺陷的提交。

3、两种方式的区别

用【转bug】生成的bug单，在bug 的信息里面有一项数据是关于【来源用例】，用来展示该bug 是由哪一个测试用例转来的。

直接提交的bug单，没有【来源用例信息】，和系统中的测试用例没有任何关系。

最好的方式就是依据测试用例的执行结果进行bug的提交，这样也可以溯源，就算是通过探索方法发现的缺陷，也可以补充一条用例进行关联的；

三、bug单的生命周期管理

Bug的生命周期在课程中是一个重中之重，当一个bug被提交就表明他的生命周期的开始，之后指派给某一位研发人员之后，由开发来确认、解决这个bug。

一般bug的处理流程是：

1、确认bug单

确认该bug确实存在后，可以将其指派给某人，并指定bug类型、优先级、备注、抄送等。

2、解决bug单

当bug修复解决后，点击解决，指定解决方案、日期、版本，并可将其再指派给测试人员。

3、关闭bug单

当研发人员解决了bug之后，bug会重新指派到bug的创建者头上。这时候测试人员可以来验证这个bug是否已经修复。如果验证通过，则可以关闭该bug。（bug列表页和详情页中都有“关闭”按钮。）

4、激活bug单

如果一个bug没有被修复，解决之后或者关闭之后，也可以对其进行激活。

四、总结

关于禅道工具的使用，还有很多，官方也提供了很详细的说明，可以自行查阅。

官方帮助文档： https://www.zentao.net/book/zentaopmshelp/

欢迎关注作者，如果觉得写的还不错，就给点个赞同、喜欢、收藏（后续持续更新）。

软件测试一般都用到哪些工具

1、企业级自动化测试工具WinRunner，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，能够帮助测试人员对复杂的企业级应用的不同发布版进行测试，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

2、工业标准级负载测试工具Loadrunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，能够对整个企业架构进行测试。企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

3、功能测试工具Rational Robot，可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational TestManager上，测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

4、功能测试工具SilkTest，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。

5、全球测试管理系统testdirector，是基于Web的测试管理系统，可以在公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

扩展资料：

WinRunner可以通过Function Generator增加测试的功能。使用Function Generator可以从目录列表中选择一个功能增加到测试中以提高测试能力。

针对相当数量的企业应用里非标准对象，WinRunner提供了Virtual Object Wizard来识别以前未知的对象。使用Virtual Object Wizard，可以选择未知对象的类型，设定标识和命名。在录制使用该对象的测试时，WinRunner会自动对应它的名字，从而提高测试脚本的可读性和测试质量。

好了，本文就介绍到这里，愿我们如花绽放，不负韶华，学员们，加油！（来源：学分高考 https://www.xuefen.net）文章共10557字