搭建软件测试环境应注意的几个问题
测试环境
应注意的
几个问题
编者按：软件测试环境的搭建在软件测试项目中至关重要，其中应注意的问题也
是不少，本文重点向读者介绍在测试过程中应注意的几个问题，希望能给读者以
启迪。
问题一：提交一份优秀的问题报告单
软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是
测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。缺陷
报告单中最关键的几个部分：第一部分是发现缺陷的环境，包括软件环境、硬件
环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。
通过对上述缺陷报告单的三个部分进行仔细分析，从中掌握了软件产品最常见的
基本问题，并吸收了其它软件测试人员的工作经验。
最关键的域就是“ 问题描述” ，这是开发人员重现问题，定位问题的依据。问题
描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、
输出、当时输出设备的相关输出信息和相关的日志等。
软件配置：包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版
本、相关支撑软件，比如数据库软件的版本和补丁版本等。
硬件配置：计算机的配置情况，主要包括CPU 、内存和硬盘的相关参数，其它
硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网
情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需
要根据当时的情况，准确翔实的记录硬件配置情况。
测试用例输入\ 操作步骤\ 输出：这部分内容可以根据测试用例的描述和测试
用例的实际执行情况如实填写。
输出设备的相关输出信息：输出设备包括计算机显示器、打印机、磁带等等输出
设备，如果是显示器可以采用抓屏的方式获取当时的截图也可以录制视频，其他
的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。
日志信息：规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，
测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交
到问题报告单中。
测试结果分析
软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环
测试环境
应注意的
几个问题
节，“ 编筐编篓，全在收口” ，测试结果的分析对下一轮测试工作的开展有很大
的借鉴意义。前面的“ 测试准备工作” 中，建议测试人员走读缺陷跟踪库，查阅
其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，
对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把
一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所
提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程
中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析
和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下
一轮测试用避免盲区。
搭建软件测试环境时与开发的关系处理
测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，
开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软
硬件环境，比如要求操作系统系统是Windows 2000 pack4 版本，数据库是Sql
Server 2000 等等。此外，应该给出被测试软件产品的详细安装指导书，包括安
装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软
件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。
如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人
员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，
避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发
人员对测试人员的认可程度。
问题二：全方位的观察测试用例执行结果：
测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时
候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测
试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使
用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现
很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，
测试用例的实际输出与预期输出完全一致，不过在查询CPU 占用率地时候，发
现CPU 占用率高达90 ％，后来经过分析，软件运行的时候启动了若干个1ms
的定时器，大量的消耗的CPU 资源，后来通过把定时器调整到10ms ，CPU 的
占用率降为7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了.
问题三：加强测试过程记录：
测试环境
应注意的
几个问题
测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描
述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提
供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行
后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以
通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发
人员重现问题。
问题四：及时确认发现的问题：
测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报
告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，
然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否
为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，
测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现
问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
问题五：提交缺陷时与开发的关系处理：
测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。
这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义
软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有
共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，
测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自
己的前提下，再开始与开发人员交流。
问题六：及时更新测试用例
测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现
遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具
体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗
余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执
行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用
例。
软件测试详细标准
软件测试标准 前言 前一版的《软件测试标准》，在测试工作中发挥了很好的指导作用。本次修改在原标准基础上，提出了新的测试理念、工作方法、组织方式，使之更贴近实际工作，真正起到纲领的作用。 一、软件测试 1、软件测试的目的 软件测试是指为了度量和提高被测试对象的质量、对测试对象进行工程设计、使用和维护的与软件开发过程并发的生命周期过程。软件测试的目的为：验证软件产品的实现状态以及实现质量。 2、软件测试相关概念 2.1白盒测试 指基于程序结构的测试，测试目标是检查程序内部逻辑结构和逻辑路径，是代码级的测试。 2．2黑盒测试 基于程序功能的测试，根据输入输出的关系推断程序功能的正确性。 2．3测试用例 测试方案，包括数据输入和相应的期望输出。依据测试用例来执行具体操作。 2．4预防性测试 其原理为：只要测试在生命周期中进行得足够早，就能够提高待测软件的质量。 2．5测试风险分析 其目的为：确定测试对象、测试的优先级、测试的深度。 2.6软件测试模型 公司目前采用V模型，实现测试与软件开发的同步进行。
2.7等价类划分 将测试对象按某种约定划分为有限个组成部分，提高测试的有效性。 2.8边界值分析 分析测试对象的所有边界值及边界附近的临界值。 二、测试工作流程 需求分析审核需求分析，编写验收测试部分用例 实地调研重点收集客户实际业务资料、操作习惯，并与需求分析作出对比 概要设计审核概要设计，从用户角度提出问题 编写集成测试用例 详细设计 审核详细设计报告，与需求分析、概要设计进行比对编写单元测试用例编写用户手册总体框架单元测试阶段提出测试计划 审核测试用例 执行测试 测试总结 集成测试阶段验收测试阶段 补充测试用例资料归档 修改测试 审核修改计划程序员提供修改清单编写测试用例执行测试 测试总结 复测测试报告复测测试用例复测 三、开发—测试流程
测试环境搭建方案
各种缺陷管理工具比较 mantis 1.概述 缺陷管理平台Mantis，也做MantisBT，全称Mantis Bug Tracker。Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。 Mantis是一个缺陷跟踪系统具有多特性包括：易于安装，易于操作，基于Web，支持任何可运行PHP的平台(Windows,Linux,Mac,Solaris,AS400/i5等)。已经被翻译成68种语言，支持多个项目，为每一个项目设置不同的用户访问级别，跟踪缺陷变更历史，定制我的视图页面，提供全文搜索功能，内置报表生成功能(包括图形报表)，通过Email报告缺陷，用户可以监视特殊的Bug，附件可以保存在web服务器上或数据库中(还可以备份到FTP服务器上)，自定义缺陷处理工作流，支持输出格包括csv、MicrosoftExcel、MicrosoftWord，集成源代码控制(SVN与CVS)，集成wiki知识库与聊天工具(可选/可不选)，支持多种数据库(MySQL、MSSQL、PostgreSQL、Oracle、DB2)，提供WebService(SOAP)接口，提供Wap访问。 2 .优点 1，流程定制方便且符合标准，满足一般的缺陷跟踪； 2，安装简单； 3 .缺点 1.只能简单的对缺陷进行管理，不能管理整个测试流程：测试需求-测试计 划-测试案例-执行测试案例-提交缺陷-测试总结报告；
2.界面比较简单，有些功能不能实现（如上传附件） QC 1.概述 Quality Center 是一个基于Java 2 Enterprise Edition (J2EE) 技术的企业级应用程序。Quality Center 可以帮助您组织和管理应用程序测试流程的所有阶段，包括制定测试需求，计划测试，执行测试和跟踪缺陷。 2.优点 1，QC能够帮助你组织和管理软件测试过程的每个阶段，包括测试需求管理、测试计划、测试案例、测试执行和缺陷跟踪。 2，QC执行对测试用例执行统计情况，对bug的统计，分析等功能比较强大； 3.缺点 1，安装比较复杂 2，收费软件。 JIRA 1.概述 JIRA是集项目计划、任务分配、需求管理、错误跟踪于一体的商业软件。JIRA创建的问题类型包括New Feature（新功能）、Bug、Task（任务）和Improvement（增加或修改）四种，还可以自己定义，所以它也一是过程管理系统。JIRA融合了项目管理、任务管理和缺陷管理，许多著名的开源项目都采用了JIRA。
开发环境与测试环境搭建方案
开发环境与测试环境搭建方案 1. 总体原则 1．开发与测试环境单独搭建，开发与测试环境的分离便于利于重现开发环境无法重现的BUG 以及便于开发人员并行地修复BUG ，如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。 2．测试环境与测试数据库分离，测试环境与测试数据库分离保证测试数据库的稳定性、数据准确性以及今后性能测试指标值的准确性。 3．开发环境与开发数据库共用一台，由于开发环境对及其性能要求不高，因此应用与数据库采用共用。 4．测试环境WEB 应用部署与生产环境相同，测试数据库的配置（用户、表空间、表）也需与生产环境一致。 2. 环境管理 2.1. 系统架构 开发环境构架： 测试环境系统构架： 2.2. 硬件配置 从上述的系统架构图分析需要3台服务器组建开发与测试环境，机型选择普 通的PC Server 机器即可。 2.3. 安装软件 建议方案中给出是环境搭建的主要软件，其他的工具未在罗列中，根据具体 需要自行安装。 服务器 内存 CPU 硬盘 备注 开发服务器 2G 到4G 之间 4C ，主频2G 以上 300G 左右 测试服务器 8G-16G 之间 4C ，主频2G 以上 300G 左右 测试数据服务器 8G-16G 之间 4C ，主频2G 以上 500G 左右
3. 权限管理 3.1. 开发环境 开发人员均可访问开发服务器应用代码与开发数据库，可以修改代码与数据 以及发布部署开发版本以便自测。 3.2. 测试环境 测试环境由版本管理员管理，负责整个测试环境的管理，包括版本部署、服 务启停、数据变更等，测试环境对开发人员只开发查询权限，仅可查询应用日志，服务运行、测试数据。 4. 版本管理 开发与测试环境安装 SVN 版本管理软件，由版本管理员负责对开发与测 试环境的版本管理工作。 5. 备份管理 1．备份主要包括开发与测试环境的代码与配置，备份方式暂为全量备份。 2．每日凌晨3点系统自动对每个项目的代码已经配置文件自动备份，备份文件名：项目名称_code_yyyymmdd.tar ，备份完成后传至备份服务器(服务器待定)。 3．每当长假(元旦、清明、五一、端午、十一、中秋、春节)前期，需手工对开发与测试环境进行全量备份。 4． 服务器 操作系统 中间件 数据库 测试工具 版本管理 工具 开发服务器 RedHat Linux 5.4 64位 Weblogic 9 Oracle 10 无 SVN 测试服务器 RedHat Linux 5.4 64位 Weblogic 9 无 JIRA SVN 测试数据服务器 RedHat Linux 5.4 64位 无 Oracle 10
软件测试BUG提交规范_模板
BUG提交模板和注意事项 一、BUG提交模板 1.现象描述 <详细描述BUG现象> 2.组网环境 <组网图及简要说明：机箱、板卡（型号、序列号和槽位）、测试仪、连接线缆等描述> 注：简单组网环境或一般性BUG情况下，可只简要描述组网环境，无需组网图。 3.版本信息 <被测设备所有组件版本信息> 软件版本： 硬件版本： 芯片版本： CPLD版本： MCU版本： uboot版本： 4.操作步骤 <详细描述发现BUG的操作步骤> 注：说明发现BUG对应用例名称编号或为非用例发现BUG。 5.期望结果 <预期正确的结果> 6.实际结果 <实际不正确的结果> 7.BUG严重性等级 <初步判定BUG的严重性等级>
8.开发确认情况 <开发确认BUG情况描述及确认人> 注：严重等级以上BUG必须要有开发人员确认 9.附件 <包括：组网图、BUG现象截图、操作产生的系统日志等> 注：严重等级以上BUG必须带有附件，一般性BUG则附件可选。 10.备注
测试环境搭建及测试基础
测试环境搭建及测试基础 一、建立测试环境 用来进行单板测试的房间需要具备以下条件： 1、尽量独立一个房间，因为测试中很容易受到其他设备的干扰； 2、如果需要准确测试的电压低于1mV，必须对房间进行金属屏蔽； 3、房间必须有独立接地系统接往本层楼层保护地入口； 4、房间必须有接地汇流排，截面积不得小于6平方毫米； 5、房间最好有独立的防静电地； 6、房间交流电源必须使用两路总空气开关，一路供测试设备使用，一路供EUT 使用，防止EUT故障引起断电，导致测试设备需要多次重启； 7、测试房间必须至少具备1台隔离变压器； 8、测试设备带宽高于500MHz的位置，房间必须设有EPA区； 9、有EPA区的房间必须设置人体电阻测试仪和防静电鞋帽； 10、测试人员在测试实验室必须遵守ESD防护程序； 11、待测设备要有“正在测试”的警示标牌； 12、放置待测设备和测试仪器的桌面必须铺设防静电台布，和手腕带接地插座； 13、测试实验室必须对不同的测试范围划定功能区，固定测试设备位置，制定设备责任人，放置实验设备和配件移动导致结果实验错误； 14、不同测试平台之间不能共用接地汇流排。 设备摆放参考以下： 配电方式建议如下，采用专用地线、零、火线，降低同楼层干扰。 二、示波器选择与使用要求: 1、测里前保证测试仪器(仪表)和被测单板或系统共地。如果不共地，地线浮空，可能会得到错误的测试结果； 2、测里前需要校准仪器； 3、为确保测试数据的精度，应尽举采用高输入阻抗、小电容值、高带宽的有源探头和高带宽的示波器；
4、示波器的带宽：描述了示波器固有的上升时间(即时延)。探头和示波器的带宽要超过信号带宽的3-5倍以上； 5、示波器的采样速率：表示为样点数每秒〔S/s )，指数字示波器对信号采样的频率。为了准确再现信号，根据香农(Shannon )定律，示波器的采样速率至少需为信号最高频率成分的2信； 6、程应尽星小，波形尽量展开，以方使观察波形变化的细节，并准确测量其幅值； 7、测量信号边沿时，应选用合适的边沿触发； 8、高档示波器都具有毛刺捕捉模式，可以用于捕捉毛刺； 三、探头选择与使用要求： 1、不允许在探头还连接着被测试电路时插拔探头； 2、有源探头和差分探头、电流探头等是很昂贵的设备，注意保护。插拔探头时必须先关示波器。无源探头一般没有硬性规定，但是出于可靠考虑，建议所有探头都不能热插拔，热插拔任何探头时都必须先关闭示波器； 3、探头地线只能接电路板上的地线，不可以搭接在电路板的正、负电源端。否则，可能会造成电路板器件损坏，甚至会烧坏探头的小夹子和探头木身； 4、探头电容越小，它对对电路的负载就越小，测试结果就更精确。选用时请根据情况仔细考虑； 5、探头是有测量幅度的，不要用于测大信号，以免造成探头损坏。例如：信号幅度超过+/-40V时，用有源探头P6245和P6243测量会造成探头的损坏； 6、差分探头能够测量差分电压范围是有限的。例如，差分探头P6247，其上的开关打在÷10档位时，能测的差分电压范围是+/ V，打在÷1档位时只有+/-850mV 差分信号峰峰值超过850rnV时(比如测公司常用的平衡线传输信号+/-5V)，要注意选用÷10档，否则会因输入过大而使显示的波形发生错误； 7、使用电流探头需先校准。每测试一个信号都需要校准一次； 8、使用时，探针尽量垂直于测试表面。但不可用力按压，以免探针受损； 四、测试点的选择： 1、一般只测试单板接收到的信号，不测试发送的信号； 2、信号质量测试点要求在信号在末端测量〔根据当前信号流向决定测试点)。尽里在芯片的输 入管脚上测量，或者尽量靠近输入管脚；
测试环境搭建与部署
测试环境搭建与部署 1.目的 1.1.为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。稳定 和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。 2.适用范围 2.1.硬件环境搭建：指测试必须的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助 设备所构成的环境；若要求的硬件配置种类较多，可以定义一些基本硬件配置； 2.2.软件环境搭建：指测试软件运行时的操作系统、数据库及其他应用软件构成的环境；2. 3.利用辅助测试环境进行的测试： 兼容性测试：在满足软件运行要求的范围内，可选择一些典型的操作系统和常用应用软件对其进行主要功能的验证。 2.4.网络环境：指被测软件运行时的网络系统、网络结构以及其他网络设备构成的环境、网 络设备、网络结构、网络系统等。 2.5.对测试环境的要求： 尽可能真实的环境 符合软件运行的最低要求 选用比较普及的操作系统和软件平台 营造纯净、独立的测试环境 无毒的环境 3.术语和定义 无 4.职责 4.1.技术部测试组成员 4.1.1.负载规划、建立和维护软件测试管理流程并持续优化 4.1.2.组织环境搭建工作的实施 4.1.3.在搭建环境中进行的工作分批写入测试用例和测试报告中 4.1.4.对应环境中发现的问题及时反馈并追踪
5.部署和管理测试环境 5.1.确定测试环境的组成 5.1.1.所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存 和硬盘的容量、网卡所支持的速度、打印机的型号等； 5.1.2.部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以 及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 5.1.3.用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理 系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 5.1.4.用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务 器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本； 5.1.5.是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份； 5.1. 6.测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定 性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈； 5.2.管理测试环境 5.2.1.设置专门的测试环境管理员角色：职责包括：测试环境的搭建。包括操作系统、数据 库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写； 记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；测试环境各项变更的执行及记录；测试环境的备份及恢复；操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理； 5.2.2.记录好测试环境管理所需的各种文档：测试环境的各台机器的硬件环境文档，测试环 境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因以及所形成的备份文件的文件名和获取方式；用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录； 5.2.3.测试环境访问权限的管理：为每个访问测试环境的测试人员和开发人员设置单独的用 户名和密码。访问操作系统、数据库、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；测试环境管理员拥有全部的权限，开发人员
开发环境与测试环境搭建方案
开发环境与测试环境搭建方案 总体原则 1．开发与测试环境单独搭建，开发与测试环境的分离便于利于重现开发环境无法重现的BUG 以及便于开发人员并行地修复BUG ，如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。 2．测试环境与测试数据库分离，测试环境与测试数据库分离保证测试数据库的稳定性、数据准确性以及今后性能测试指标值的准确性。 3．开发环境与开发数据库共用一台，由于开发环境对及其性能要求不高，因此应用与数据库采用共用。 4．测试环境WEB 应用部署与生产环境相同，测试数据库的配置（用户、表空间、表）也需与生产环境一致。 环境管理 1.1. 系统架构 开发环境构架： 测试环境系统构架： 1.2. 硬件配置 从上述的系统架构图分析需要3台服务器组建开发与测试环境，机型选择普 通的PC Server 机器即可。 1.3. 安装软件 建议方案中给出是环境搭建的主要软件，其他的工具未在罗列中，根据具体 需要自行安装。 服务器 内存 CPU 硬盘 备注 开发服务器 2G 到4G 之间 4C ，主频2G 以上 300G 左右 测试服务器 8G-16G 之间 4C ，主频2G 以上 300G 左右 测试数据服务器 8G-16G 之间 4C ，主频2G 以上 500G 左右
权限管理 1.4. 开发环境 开发人员均可访问开发服务器应用代码与开发数据库，可以修改代码与数据 以及发布部署开发版本以便自测。 1.5. 测试环境 测试环境由版本管理员管理，负责整个测试环境的管理，包括版本部署、服 务启停、数据变更等，测试环境对开发人员只开发查询权限，仅可查询应用日志，服务运行、测试数据。 2. 版本管理 开发与测试环境安装 SVN 版本管理软件，由版本管理员负责对开发与测 试环境的版本管理工作。 3. 备份管理 1．备份主要包括开发与测试环境的代码与配置，备份方式暂为全量备份。 2．每日凌晨3点系统自动对每个项目的代码已经配置文件自动备份，备份文件名：项目名称_code_yyyymmdd.tar ，备份完成后传至备份服务器(服务器待定)。 3．每当长假(元旦、清明、五一、端午、十一、中秋、春节)前期，需手工对开发与测试环境进行全量备份。 4． 服务器 操作系统 中间件 数据库 测试工具 版本管理 工具 开发服务器 RedHat Linux 5.4 64位 Weblogic 9 Oracle 10 无 SVN 测试服务器 RedHat Linux 5.4 64位 Weblogic 9 无 JIRA SVN 测试数据服务器 RedHat Linux 5.4 64位 无 Oracle 10
软件测试基础要点总结
软件测试基础要点总结 软件测试基础要点总结 从宏观的角度讲，软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。 1.测试计划注意事项 1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况； 2．测试计划一旦制定下来，并不就是一成不变的，随着软件需求、软件开发、人员流动等发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细．测试原则 ①应尽早和不断地进行软件“测试”。 ②测试用例中，不仅要选择合理的输入数据，还要选择不合理的输入数据。③在开发各阶段应事先分别制定出相应的测试计划，在测试开始后应严格执行，防止随意性。④对发现错误较多的程序模块，应进行重点测试。⑤避免程序员测试自己的程序。 ⑥用穷举测试是不现实的，一般通过设计测试用例，充分覆盖所有条件或所有语句即可。⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。 2.测试用例文档 测试用例文档通常是由简介和测试用例两部分组成：
简介部分编制了测试目的、测试范围、定义术语、参考文档等，这个与测试计划是一致的。 测试用例部分逐一列出各个测试用例。 测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例部分 测试用例通常包含的信息：用例标识和用例名称内容描述前提条件执行步骤预期结果评价准则 用例设计人员和设计时间用例执行人员和执行时间其它内容3.软件缺陷 缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有：①软件没有实现产品规格说明所要求的功能模块软件中；②出现了产品规格说明指明不应该出现的错误； ③软件实现了产品规格说明没有提到的功能模块； ④软件没有实现虽然产品规格说明没有明确提及但应该实现的目标； ⑤软件难以理解，不容易使用，运行缓慢，或从测试员的角度看，最终用户会认为不好。测试用例：以计算器为例 ①计算器的产品规格说明定应能准确无误地进行加、减、乘、除运算。如果按下加法键，没什么反应，就是第一种类型的缺陷；若计算结果出错，也是第一种类型的缺陷。②产品规格说明书还可能规定计算器不会死机，或者停止反应。如果随意敲键盘导致计算器停止接受输入，这就是第二种类型的缺陷。 ③如果使用计算器进行测试，发现除了加、减、乘、除之外还可以求平方根，但是产品规格说明没有提及这一功能模块。这是第三种类型的缺陷④在测试计算
WEB测试环境搭建和测试方法
WEB测试时搭建测试环境所需的软硬件包括：电脑一台、JDK1.6、Tomcat7.0、mysql、IE 浏览器、Firefox浏览器、Chrome浏览器、SVN客户端 通过SVN客户端导出最新的Web工程部署到Tomcat7.0下的webapps中，另外重要的一 点就是修改数据库连接的配置文件，连接到正确的测试数据库（企业一般有开发人员所用的数据库和测试人员所用的数据库），数据库连接的配置文件在WEB-INF文件夹下，修改好数据库的配置文件后，在Tomcat7.0\bin\startup.bat启动Tomcat，在Tomcat没报错的情况下，用浏览器访问后台，出现一个登录界面，这样，一个简单完整的Web测试环境就搭建起来了！ 二、Web测试方法 1、链接测试 链接是web应用系统的一个主要特征，它表示页面与页面直接的切换和用户不知道具体地 址去访问其他页面的手段，如果页面不能跳转或者是访问失败，有很大程度上是web应用程序的链接出问题了；其中有一个重要的性能指标就是链接速度的测试，用户打开一个页面或者是去访问另外一个页面，如果web系统响应时间太长（例如超过5秒钟），用户就会因没耐心而离开，还有就是有些页面有超时的限制，这样可能引起数据丢失，使用户得不到真实的页面。 2、数据库测试 在web应用技术中，数据库起着重要的作用，数据库为web应用系统的管理、运行、查询和实现用户对数据存储的请求提供空间，也就是说用户在页面进行各类操作，如添加、查询 删除等一系列动作，都会被数据库记录。 3、浏览器测试 浏览器是web客户端最核心的构件，来自不同厂商的浏览器对不同开发语言开发的应用程序有不同的支持，这就需测试人员对主流的浏览器和不同版本的浏览器进行有效的测试。
软件测试基础要点总结
从宏观的角度讲，软件测试过程一般可划分为单元测试、集成测试、验收测试和系统测试等几个主要测试阶段。 1.测试计划注意事项 1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况； 2．测试计划一旦制定下来，并不就是一成不变的，随着软件需求、软件开发、人员流动等发生变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求．3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细． 测试原则 ①应尽早和不断地进行软件“测试”。 ②测试用例中，不仅要选择合理的输入数据，还要选择不合理的输入数据。 ③在开发各阶段应事先分别制定出相应的测试计划，在测试开始后应严格执行，防止随意性。 ④对发现错误较多的程序模块，应进行重点测试。 ⑤避免程序员测试自己的程序。 ⑥用穷举测试是不现实的，一般通过设计测试用例，充分覆盖所有条件或所有语句即可。 ⑦长期妥善保存测试计划、测试用例、出错统计和有关的分析报告。 2.测试用例文档 测试用例文档通常是由简介和测试用例两部分组成： 简介部分编制了测试目的、测试范围、定义术语、参考文档等，这个与测试计划是一致的。 测试用例部分逐一列出各个测试用例。 测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。 测试用例部分 测试用例通常包含的信息： 用例标识和用例名称 内容描述 前提条件 执行步骤 预期结果 评价准则 用例设计人员和设计时间 用例执行人员和执行时间 其它内容 3.软件缺陷 缺陷的表现形式不仅体现在功能的失效方面，还体现在其他方面。主要类型有： ①软件没有实现产品规格说明所要求的功能模块软件中； ②出现了产品规格说明指明不应该出现的错误；
史上最全ProE二次开发测试及环境配置方法
32位系统preo5.0二次开发测试及环境配置 首先,proe5.0是配合VC++2008来进行二次开发的,因此首先得安装VS2008,其次,要确保proe5.0中已经安装了protoolkit,安装方法略。 如何测试Pro/Toolkit安装成功 第一步，找到proe安装目录下的protooltik文件夹，并找到..\protoolkit\i486_nt\obj这个路径下的一个叫做make_install的文件，用写字板打开，找到如下 # Pro/Toolkit Source & Machine Loadpoint (EXTERNAL USE - DEFAULT) 这么一行字，然后把它下面的PROTOOL_SRC=../..改成PROTOOL_SRC = ...\PTC\protoolkit，保存下关闭就好了。 第二步，在“开始”中找到Microsoft Visuall Studio Tools→Visual Studio Tools→Visual Studio Tools2008命令提示符，打开。 第三步，在打开的这个界面里面敲下如下字符cd ...\PTC\protoolkit\i486_nt\obj，然后回车，再敲上如下字符：nmake /f make_install dll，然后再回车，等其运行完毕，关掉命令提示符，然后再回到...\PTC\protoolkit\i486_nt\obj文件夹中，会发现多了一个pt_inst_test.dll文件，证明前面的工作全是成功的。 第四步，回到...\PTC\protoolkit文件夹，找到protk.dat文件，用写字板打开，将第二行和第三行前面的“.”改成路径...\PTC\protoolkit，将第五行后面的“18”改成“wildfire5.0”，其他保持不变，保存，关闭。 第五步，启动proe5.0，找到工具→辅助应用程序，打开，点“注册”，找到...\PTC\protoolkit，里的protk.dat，打开，选中，点“启动”，发现左上角出现“’pt_inst_test.dll’启动成功”。关闭“辅助应用程序”。 第六步，打开“文件”菜单栏，会有一个“安装检测”，点击后，会出现“PRO/PROTOOLKIT 安装检测成功”。至此，PRO/PROTOOLKIT安装检测全部完成。 配置VC++2008 Debug模式配置 第一步，加上PRO/TOOLKIT的包含文件和库文件，打开工具→选项→项目与解决方案→VC++目录显示以下内容的目录→包含文件，添加如下文件： ...\PTC\protoolkit\includes ...\PTC\protoolkit\protk_appls\includes ...\PTC\prodevelop\includes ...\PTC\prodevelop\prodev_appls\includes 将包含文件换为库文件，添加如下文件： ...\PTC\protoolkit\i486_nt\obj ...\PTC\prodevelop\i486_nt\obj
软件测试指导手册
软件测试指导手册 张宝良 为了提高测试效率,保证产品测试质量,从而保证产品开发工期与质量,统一测试思想就是十分必要得。本文就用友软件测试相关内容进行阐述,力求给大家启示与参考。 第一章测试概念 第一节测试要点 测试要点就是依据等价类方法(或其她方法),经过对被测试内容进行分析后,以清单方式进行描述要测试得内容。 注意事项: 1.针对任何一个被测试内容,均要考虑就是否涉及系统提供得公用功能。 2.测试要点尽可能穷举,避免遗漏。 3.测试要点给出代码实现正确实现就是什么,什么样实现就是错误得。 4.测试要点就是针对最小功能单元,可以就是一个功能结点,也可以就是一个操作按钮,但不 允许多个内容一起描述 举例:U8产品 XXX产品测试要点 第二节测试用例 测试用例就是指数据测试用例,针对测试要点,必须以数据形式才可描述清楚,作为测试要点得补充。测试要点不一定必须有测试数据用例,但测试数据用例必须对应有测试要点。 注意事项: 1.测试用例一般会涉及多个功能配合。 2.描述中要体现操作次序 3.数据准备考虑以下情况 ●小数 ●外币 ●表体一条记录 ●表体满记录 ●表体满记录多一条 4.数据准备不要太复杂,要便于操作。如果复杂可拆开描述。
第二章测试策略 测试策略:针对某项具体任务,安排最合适得人选,采用最佳得测试方法,在规定得时间内,保质保量完成。 策略要点 （1）在测试策略中,人员能力得培养就是最重要得,就是完成任务得关键。 （2）针对被测试对象得不同,测试策略应有差异。 （3）测试计划就是保证被测试对象完全测试得关键,同时也就是提高测试人员工作效率得关键。 （4）被测试对象在分解任务时要有主次之分 （5）测试资源安排时要有主次之分 （6）测试进度安排要有主次之分 （7）合理设计各测试阶段测试内容,充分体现早期测试思想,及早稳定产品。 （8）最大限度地提高测试经理得作用(任务安排、测试设计、问题分析、产品把握) （9）建立监督、检查机制。每个阶段都要有报告产生,对报告要进行详细分析,以便掌握进度与质量。（10）向过程要效益,过程不同效益不同。 任务计划 任务计划分两类:测试经理使用得“阶段任务计划”,测试人员使用得“每日任务计划” XXX测试组阶段任务计划 反馈 XXX测试员每日任务计划 该计划根据阶段测试任务制定,由测试经理编写,测试人员执行。切不可以由测试人员编写,理由就是缺乏全面考虑,尤其就是测试覆盖度方面。测试人员每日向测试经理反馈。 工作内容 分类 以就是否改动可以分为改动部分与非改动部分。 以就是否就是重点可以分为重点内容与非重点内容。
开发环境与测试环境搭建办法
精心整理 开发环境与测试环境搭建方案 1.总体原则 1．开发与测试环境单独搭建，开发与测试环境的分离便于利于重现开发环境无法重现的BUG 以及便于开发人员并行地修复BUG，如果选择开发环境来进行测试，开发人员进行某项误操作后发生系统崩溃或者系统不能正常运行的意外，此时测试工作也不得不停止。 2．测试环境与测试数据库分离，测试环境与测试数据库分离保证测试数据库的稳定性、数据准确性以及今后性能测试指标值的准确性。 3．开发环境与开发数据库共用一台，由于开发环境对及其性能要求不高，因此应用与数据库采用共用。 4．测试环境WEB应用部署与生产环境相同，测试数据库的配置（用户、表空间、表）也需与生产环境一致。 2.环境管理 2.1. 系统架构 开发环境构架： 测试环境系统构架： 2.2. 硬件配置 从上述的系统架构图分析需要3台服务器组建开发与测试环境，机型选择普通的PCServer机器即可。 服务器内存CPU 硬盘备注 开发服务器2G到4G之间4C，主频2G以 300G左右 上 300G左右 测试服务器8G-16G之间4C，主频2G以 上
2.3. 安装软件 建议方案中给出是环境搭建的主要软件，其他的工具未在罗列中，根据具体需要自行安装。 3. 权限管理 3.1. 开发环境 开发人员均可访问开发服务器应用代码与开发数据库，可以修改代码与数据以及发布部署开发版本以便自测。 3.2. 测试环境 测试环境由版本管理员管理，负责整个测试环境的管理，包括版本部署、服务启停、数据变更等，测试环境对开发人员只开发查询权限，仅可查询应用日志，服务运行、测试数据。 4. 版本管理 开发与测试环境安装SVN 版本管理软件，由版本管理员负责对开发与测试环境的版本管理工作。 5. 备份管理 1．备份主要包括开发与测试环境的代码与配置，备份方式暂为全量备份。 2．每日凌晨3点系统自动对每个项目的代码已经配置文件自动备份，备份文件名：项目名称_code_yyyymmdd.tar ，备份完成后传至备份服务器(服务器待定)。 测试数据服务器 8G-16G 之间 4C ，主频2G 以上 500G 左右 服务器 操作系统 中间件 数据库 测试工具 版本管理 工具 开发服务器 RedHatLinux5.464位 Weblogic9 Oracle10 无 SVN 测试服务器 RedHatLinux5.464位 Weblogic9 无 JIRA SVN 测试数据服务器 RedHatLinux5.464位 无 Oracle10
软件系统测试规范
上海兴汉科技公司软件测试规范
目录
一.概述 本规范是对项目软件测试的一份指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程以及软件产品开发单位所承担的职责进行总体规范，以有效保证软件产品的质量。
1.什么是软件测试 无论怎样强调软件测试的重要性和它对软件可靠性的影响都不过分。在开发大型软件系统的漫长过程中，面对着极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺，因此，在软件生命周期的每个阶段都不可避免地会产生差错。我们力求在每个阶段结束之前通过严格的技术审查，尽可能早地发现并纠正差错；但是，经验表明审查并不能发现所有差错，此外在编码过程中还不可避免地会引入新的错误。如果在软件投入生产性运行之前，没有发现并纠正软件中的大部分差错，则这些差错迟早会在生产过程中暴露出来，那时不仅改正这些错误的代价更高，而且往往会造成很恶劣的后果。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对它做必要的测试(称为单元测试)，模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段。在这个阶段结束之后，对软件系统还应该进行各种综合测试，这是软件生命周期中的另一个独立的阶段，通常由专门的测试人员承担这项工作。大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终日的。软件工程的根本目标是开发出高质量的完全符合用户需要的软件。 2.软件测试的目标 下面这些规则也可以看作是测试的目标或定义： (1)测试是为了发现程序中的错误而执行程序的过程； (2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； (3)成功的测试是发现了至今为止尚未发现的错误的测试。 从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。 由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。
测试环境搭建及工程部署
测试环境的搭建 我所描述的这些软件安装或工程部署都是根据自己所在的开发与测试团队中所需的操作模式总结。从各个软件的安装到工程部署启动，都是按步骤及截图来说明，希望大家能够通过图解明白这个过程。 JDK6.0安装 1.JDK安装过程：直接对软件进行下一步下一步的安装（最好选择默认安装路 径）。安装完成后需对此软件进行设置，步骤如下：在我的电脑------->环境变量中新建环境变量，定义变量名为JAVA_HOME，然后输入jdk安装路径，如图所示 然后需对path变量名进行编辑，如图所示：
在变量值最后加分号隔开，然后输入%JAVA_HOME%\bin，然后点击确定即可。 此时JDK才算是完全安装好，如果没有进行环境变量的设置，那安装了JDK 相当于没有安装。 Myeclipse10.0安装与破解 2.Myeclipse10 按照软件安装提示一步步安装即可。安装完成后打开 myeclipse时会发现它是试用版需输入激活码进行激活。如果没有激活码，此时就需要对软件进行破解，破解步骤（myeclipse 9.1 破解激活，java 编写，适用于装有java环境的各种操作系统，win，linux，maxos）如下所示： 第一步：输入任意用户名 第二步：点击Systemid... 按钮，自动生成本机器的systemid。 第三步：点菜单Tools->RebuildKey 第四步：点击active按钮.会在显示区域生成 LICENSE_KEY ACTIVATION_CODE ACTIVATION_KEY 这时候不要打开myeclipse的激活页面输入。 第五步：打开菜单Tools->ReplaceJarFile，弹出文件选择对话框，到myeclipse的安装目录common文件夹下选择plugins文件夹 点击打开，程序会卡住，不要担心，正在替换文件呢！一会之后，会输出信息，文件已被替换 第六步：点菜单Tools->SaveProperites 打开你的myeclipse已经不需要再输入激活码什么的了。
windows环境下测试环境配置流程
Windows环境下服务器配置流程 一、JKD安装 安装JDK 选择安装目录安装过程中会出现两次安装提示。第一次是安装 jdk ，第二次是安装 jre 。建议两个都安装在同一个java文件夹中的不同文件夹中。（不能都安装在java文件夹的根目录下，jdk和jre安装在同一文件夹会出错） 如下图所示 1：安装jdk 随意选择目录只需把默认安装目录 \java 之前的目录修改即可 2：安装jre→更改→ \java 之前目录和安装 jdk 目录相同即可 注：若无安装目录要求，可全默认设置。无需做任何修改，两次均直接点下一步。
安装完JDK后配置环境变量 ?计算机→属性→高级系统设置→高级→环境变量
系统变量→新建 JAVA_HOME 变量。 变量值填写jdk的安装目录（本人是 E:\Java\系统变量→寻找 Path 变量→编辑 在变量值最后输入 %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin; （注意原来Path的变量值末尾有没有;号，如果没有，先输入；号再输入上面的代码） 系统变量→新建 CLASSPATH 变量 变量值填写 ? .;%JAVA_HOME%\lib;%JAVA_HOME%\lib\（注意最前面有一点） 系统变量配置完毕 检验是否配置成功运行cmd 输入 java -version （java 和 -version 之间有空格） 若如图所示 安装JDK 选择安装目录安装过程中会出现两次安装提示。第一次是安装 jdk ，第二次是安装 jre 。建议两个都安装在同一个java文件夹中的不同文件夹中。（不能都安装在java文件夹的根目录下，jdk和jre安装在同一文件夹会出错） 如下图所示 1：安装jdk 随意选择目录只需把默认安装目录 \java 之前的目录修改即可 2：安装jre→更改→ \java 之前目录和安装 jdk 目录相同即可
软件测试技术经典教程
第一章软件测试基本概念 1.1软件是计算机中与硬件相结合的一部分，包括程序和文档 软件=程序+文档 1.2软件的分类 1.2.1按功能划分 系统软件 应用软件 1.2.2按技术架构划分 单机版软件 C/S结构软件 B/S结构软件 1.2.3按用户划分 产品软件 项目软件 1.4什么事软件测试 使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检查它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 1.5.1什么是测试环境 测试环境=软件+硬件+网络 1.5.2怎样搭建测试环境 搭建测试环境的要点： 1.真实尽量模拟用户的真实使用环境 2.干净测试环境中尽量不要安装其他与被测试软件无关的软件 3.无毒测试环境没有中毒 4.独立测试环境和开发环境独立 1.5.3软件环境的分类 软件开发环境 软件生产运行环境 1.6.1什么是测试用例 测试用例=输入+输出+测试环境 输入包括测试数据和操作步骤 输出期望结果 测试环境系统环境设置 1.6.3编写测试用例的注意事项
开发生命周期 需求分析= 〉概要设计=〉详细设计=〉编码=〉维护 测试生命周期 测试计划=〉测试设计==============〉测试执行=〉测试评估
第二章软件测试分类 2.1黑盒测试和白盒测试 2.2静态测试和动态测试 静态测试，不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。即静态测试包括代码测试、界面测试和文档测试。 2.3单元测试、集成测试、系统测试和验收测试 桩模块，指模拟被测模块所调用的模块 驱动模块，指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块并输出结果。 2.3.3系统测试和验收测试 单元、集成、系统、验收测试比较 单元测试最小模块，如函数、类等《详细设计》白盒测试工程师或开发人员主要采用白盒测试 集成测试模块间的接口，如参数传递《概要设计》白盒测试工程师或开发人员黑盒和白盒测试相结合 系统测试整个系统，包括软硬件《需求规格说明书》黑盒测试工程师黑盒测试验收测试整个系统，包括软硬件《规格需求说明书》，验收标准主要为用户，还可能有测试工程师等黑盒测试 2.4.1功能测试 功能测试，是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。 1.逻辑功能测试 2.界面测试 3.易用性测试 4.安装测试 5.兼容性测试 2.4.2性能测试 性能测试是软件测试的高端领域，性能测试工程师的待遇和白盒测试工程师不相上下，通常我们所说的高级软件测试工程师一般就指性能测试工程师或是白盒测试工程师。 1.一般性能测试让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。 2.稳定性测试也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定程度。 3.负载测试是性能测试的一种，通常是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。 4.压力测试是性能测试的一种，通常是指连续不断地给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。 2.5回归测试、冒烟测试、随机测试 回归测试，是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。 冒烟测试，是指对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。