什么是软件测试环境_软件测试环境有哪几种_做软件测试要用到什么工具

软件测试一共有哪几种类型

软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别，本文主要描述一下软件测试一共有哪几种类型。

单元测试（Unit test）：是针对模块组件或方法的测试。在本人的操作中，一般是开发员工作范围内的测试；在具备组件接口规范的情况下，一般需要做一个测试工具模拟调用环境，编写测试实例，通过断点情况监视模块实际工作是否正常。

白箱测试：在理解内部流程的情况下针对逻辑流程设计测试实例，目的是找出极限边缘以及内在的逻辑错误。单元测试中白箱测试的比例很高，（原因不难理解，还有谁比作者自已更理解模块的构造流程的？）。

黑箱测试：这是QC部门的主要工作。黑箱测试主要在于编写测试实例。不过在实际操作中，都是把最不懂技术的成员分配做测试，最高技术水平就是会用VSS，所以也就别指望编什么测试实例。

压力测试：评价一个系统极限可以承受的压力是多少，同时在超负荷后的的响应情况；同时，在极限状况下，一些平时不太出现的bug也会浮现出来。

回归测试；在修改其中一个模块后看其他模块有什么问题。作者认为这个测试是过程化程序的观念产物，在模块化软件中相互耦合程度低，而且服从统一的调动协议，是不是修改真是自家里的事情，和他人（模块）没有半点相干。

整体测试：把不同的模块连结后，看看联合工作情况如何。这实际上是对接口协议的测试。作者认为是可以作为接口互动部分的设计一部分工作，没有必要摆出来作为流程之一。同理还有系统测试，反正最后整个系统运行起来是什么情况。看似大，但如果前面已经做到好好的，这里如果出问题那才叫怪呢！

软件测试一共有哪几种类型？作为一名初学者来说，了解了软件测试的类型还不够，应用在不同类型中所需的工具也是很多的，那么做软件测试要用到什么工具呢，请看下文

做软件测试要用到什么工具

俗话说“工欲善其事、必先利其器”，作为一名合格的软件测试工程师，测试用到的工具一定要准备齐全，当然学会如何使用它们也是你必须要做到的，那么做软件测试要用到什么工具呢？南京达内软件测试培训师为您详解。

测试管理工具：帮助测试人员完成计划、追踪等任务的工具，并且有助于根据需求、设计、编码以及缺陷。

静态分析工具：在不执行代码的前提下进行分析，是非常重要的缺陷检测工具，以各种指标来对代码进行衡量，如McCabe测定复杂度，Logiscope度量代码和规范的复合度等等。

动态分析工具：系统运行中进行分析、评估。例如运行过程中检测内存使用情况、内存是否有越界、内存有无泄漏情况，常用工具有Purify、BoundChecker等。

覆盖率工具：这类工具用于对软件执行后，测试软件被执行的程度，在单元测试中被广泛应用，如TrueCoverage、PureCoverage、Logiscope等等。

测试执行工具：这类测试工具往往能够自动执行，覆盖单元测试、集成测试、系统测试等各种需求应用，分为功能测试自动化工具：Robot、Winrunner、SilkTest等；性能测试工具，如Loadrunner、SilKPerformer等。

做软件测试要用到的工具就为大家介绍到这里，以上几种为软件测试工程师必备工具，具体根据黑盒、白盒测试也会有不同区分。

搭建软件测试环境应注意的几个问题

软件测试环境的搭建在软件测试项目中至关重要，其中应注意的问题也是不少，本文重点向读者介绍在测试过程中应注意的几个问题，希望能给读者以启迪。

问题一：提交一份优秀的问题报告单

软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。缺陷报告单中最关键的几个部分：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分进行仔细分析，从中掌握了软件产品最常见的基本问题，并吸收了其它软件测试人员的工作经验。最关键的域就是“ 问题描述” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。软件配置：包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。

硬件配置：计算机的配置情况，主要包括CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。测试用例输入 操作步骤 输出：这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。输出设备的相关输出信息：输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图也可以录制视频，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。

日志信息：规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。

测试结果分析

软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节，“ 编筐编篓，全在收口” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的“ 测试准备工作” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。搭建软件测试环境时与开发的关系处理测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是Windows 2000 pack4 版本，数据库是Sql Server 2000 等等。此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。

问题二：全方位的观察测试用例执行结果：

测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询CPU 占用率地时候，发现CPU 占用率高达90 ％，后来经过分析，软件运行的时候启动了若干个1ms 的定时器，大量的消耗的CPU 资源，后来通过把定时器调整到10ms ，CPU 的占用率降为7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。

问题三：加强测试过程记录：

测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。

问题四：及时确认发现的问题：

测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。

问题五：提交缺陷时与开发的关系处理：

测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。

问题六：及时更新测试用例

测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执

行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。