软件测试实践之测试环境的规划与管理

第一篇：软件测试实践之测试环境的规划与管理

测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。

简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

一、规划测试环境——让环境为你服务

对于“金山词霸”这样的软件，大多数测试工作都可以在一台单独的电脑上完成，而对于一套电信系统，为了执行测试用例，你可能会需要搭建一个由多台计算机以及其他网络设备组成，采用集群和负载均衡技术，并且接驳到Internet的计算机网络。

不同的行业应用，不同的质量目标，都可能会影响到测试环境的规划。但从测试工作自身的要求来看，一条应当遵守的原则就是“尽可能的还原软件在用户那里最终实际运行的环境”——虽然在很多时候这是不现实的。^_^

通常来说，我们所需要搭建的环境，主要是用于被测应用的系统测试——单元测试和集成测试由开发人员在开发环境中进行，而验收测试则在用户的最终应用环境中进行，因此都可以暂不考虑。

为了确定测试环境的组成，我们需要明确以下问题：

1.所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；

2.部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3.用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4.用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

5.是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

6.测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；

7.执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

8.为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料；对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。当然，还有另外一个非常关键的问题：在测试过程中受到影响的数据如何恢复？

明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。建议在搭建测试环境之前，把上面的问题做成一张 CheckList，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。当然，如果时间或其他条件允许，应当做好应急预案，尽量保证在环境失效时不会对正常工作产生太大的影响。

二、管理测试环境——把变化掌握在手中

测试环境搭建好以后不太可能永远不发生变化，至少被测应用的每次版本发布都会对测试环境产生或多或少的影响。而应对变化之道，不是禁止变化，而是“把变化掌握在手中”。下面的这些建议可以帮助你尽可能摆脱环境变化所带来的不利影响。

1.设置专门的测试环境管理员角色

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；

记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

完成被测应用的部署，并做好发布文档的编写；

测试环境各项变更的执行及记录；

测试环境的备份及恢复；

操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

2.明确测试环境管理所需的各种文档

一般来说，下面的几个文档是必需的，当然你也可以根据需要增加新的文档。

组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

被测应用的发布手册，记录被测应用的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测应用的发布情况，对版本差异进行描述；测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

3.测试环境访问权限的管理

应当为每个访问测试环境的测试人员和开发人员设置单独的用户名，并根据不同的工作需要设置不同的访问权限，以避免误操作对测试环境产生不利的影响。下面的要求可以作为建立“测试环境访问权限管理规范”的基础。

访问操作系统、数据库、中间件、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

测试环境管理员拥有全部的权限；

除对被测应用的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限；

除测试环境管理员外，其他测试组成员不授予删除权限；

用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

4.测试环境的变更管理

对测试环境的变更应当形成一个标准的流程，并保证每次变更都是可追溯的和可控的。下面的几项要点并不是一个完整的流程，但是可以帮助你实现这个目标。

测试环境的变更申请由开发人员或测试人员提出书面申请，由测试环境管理员负责执行。测试环境管理员不应接受非正式的变更申请（例如口头申请）；

对测试环境的任何变更均应记入相应的文档；

同每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

对于被测应用的发布，开发人员应将整个系统（包括数据库、应用层、客户端等）打包为可直接发布的格式，由测试环境管理员负责实施。测试环境管理员不接受不完整的版本发布申请；

对测试环境做出的变更，应该可以通过一个明确的方法返回到之前的状态。

5.测试环境的备份和恢复

对于测试人员来说，测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价 值。因此，应当在测试环境（特别是软件环境）发生重大变动（例如安装操作系统、中间件或数据库，为操作系统、中间件或数据库打补丁等对系统产生重大影响并 难以通过卸载恢复）时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。并由测试环境管理员在相应的“备份记录”文档中记录每次备份的时 间、备份人以及备份原因（与上次备份相比发生的变化），以便于在需要时将系统重新恢复到安全可用的状态。

另外，每次发布新的被测应用版本时，应当做好当前版本的数据库备份。而在执行测试用例或性能测试场景之前，也应当做好数据备份或准备数据恢复方案，例如通过运行SQL脚本来将数据恢复到测试执行之前的状态，以便于重复的使用原有的数据，减少因数据准备和维护而占用的工作量，并保证测试用例的有效性和缺陷记录的可重现。

第二篇：软件测试（推荐）

一、简答5*6’

1.为什么不让时间有余的人做测试工作

表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。2.软件测试风险主要体现在哪里

我们没有对软件进行完全测试，实际就是选择了风险，因为缺陷极有可能存在没有进行测试的部分。因此，我们要尽可能的选择最合适的测试量，把风险降低到最小 3.所有软件测试缺陷都需要修复吗

从技术上讲，所有的软件缺陷都是能够修复的，但是没有必要修复所有的软件缺陷。测试人员要做的是能够正确判断什么时候不能追求软件的完美。对于整个项目团队，要做的是对每一个软件缺陷进行取舍，根据风险决定那些缺陷要修复。发生这种现象的主要原因如下：-没有足够的时间资源。在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且在项目中没有预算足够的回归测试时间，修改缺陷可能引入新的缺陷。

-有些缺陷只是特殊情况下出现，这种缺陷处于商业利益考虑，可以在以后升级中进行修复。-不是缺陷的缺陷。我们经常会碰到某些功能方面的问题被当成缺陷来处理，这类问题可以以后有时间时考虑再处理。缺陷是否修改要由软件测试人员、项目经理、程序员共同讨论来决定是否修复，不同角色的人员从不同的角度来思考，以做出正确的决定。4.如何减少测试人员跳槽带来的损失 建议我们从以下两个方面做起：

-加强部门内员工之间的互相学习，互相学习是建立学习型组织的基本要求，是知识互相转移的过程。在此基础上，可以把个人拥有的技术以知识的形式沉积下来，也就完成了隐性知识到显性知识的转化。

-管理者就应该把员工的个人成长和企业的发展联系起来，为员工设定合理发展规划并付诸实现。

5.验收测试的注意点有哪些 测试要注意下面的事项：

（1）用户现场测试不可能测试全部功能，因此要测试核心功能。这需要提前做好准备，这些核心功能一定要预先经过测试，证明没有问题才可以和用户共同进行测试。测试核心模块的目的是建立用户对软件的信心。当然如果这些模块如果问题较多，不应该进行演示。（2）如果某些模块确实有问题，我们可以演示其它重要的业务功能模块，必要时要向用户做成合理的解释。争得时间后，及时修改缺陷来弥补。（3）永远不能欺骗用户，蒙混过关。6.完全测试程序是可能的吗

实际上完全测试是不可能的。主要有以下原因：-完全测试比较耗时，时间上不允许；

-完全测试通常意味着较多资源投入，这在现实中往往是行不通的；-输入量太大，不能一一进行测试；-输出结果太多，只能分类进行验证；-软件实现途径太多；

-软件产品说明书没有客观标准，从不同的角度看，软件缺陷的标准不同；因此测试的程度要根据实际情况确定 7.是不是发现的缺陷越多就说明软件缺陷越多 其中的原因主要如下：

-代码复用、拷贝代码导致程序员容易犯相同的错误。类的继承导致所有的子类会包含基类的错误，反复拷贝同一代码意味可能也复制了缺陷。-程序员比较劳累是可以导致某些连续编写的功能缺陷较多。

“缺陷一个连着一个”不是一个客观规律，只是一个常见的现象。如果软件编写的比较好，这种现象就不常见了。测试人员只要严肃认真的测试程序就可以了。8.软件测试就是QA吗

软件测试人员的职责是尽可能早的找出软件缺陷，确保得以修复。而质量保证人员（QA）主要职责是创建或者制定标准和方法，提高促进软件开发能力和减少软件缺陷。测试人员的主要工作是测试，质量保证人员日常工作重要内容是检查与评审，测试工作也是测试保证人员的工作对象。软件测试和质量是相辅相成的关系，都是为了提高软件质量而工作。9.测试产品和测试项目区别

习惯上把开发完成后进行商业化、几乎不进行代码修改就可以售给用户使用的软件成为软件产品，也就是可以买“卖拷贝”的软件，软件项目是一种个性化的产品，可以是按照用户要求全部重新开发，也可以修改已有的软件产品来满足特定的用户需求。项目和产品的不同特点，决定我们测试产品和测试项目仍然会有很多不同的地方：

-质量要求不同。通常产品的质量要高一些，修复发布后产品的缺陷成本较高，甚至会带来很多负面的影响。而做项目通常面向某一用户，虽然质量越高越好，但是一般只要满足用户要求就可以了。测试资源投入多少不同。做软件产品通常是研发中心来开发，进度压力要小些。同时由于质量要求高，因此会投入较多的人力、物力资源。项目最后要和用户共同验收测试，这是产品测试不具有的特点。此外，测试产品与测试项目在缺陷管理方面、测试策略制定都会有很大不同，测试管理者应该结合具体的环境，恰如其分的完成工作 10.如何编写提交给用户的测试报告

测试报告一般分为内部测试报告和外部测试报告。内部报告是我们在测试工作中的项目文档，反映了测试工作的实施情况,一般外部测试报告要满足下面几个要求：

根据内部测试报告进行编写，一般可以摘录；不可以向客户报告严重缺陷，即使是已经修改的缺陷，开发中的缺陷也没有必要让客户知道；报告上可以列出一些缺陷，但必须是中级的缺陷，而且这些缺陷必须是修复的；报告上面的内容尽量要真实可靠；整个测试报告要仔细审阅，力争不给项目带来负面作用，尤其是性能测试报告。总之，外部测试报告要小心谨慎的编写。

二、论述2*12’

1.请论述为什么要进行软件测试，并列举历史上2~3个著名软件测试（缺陷）案例，说明测试重要性

软件测试的目的,第一是确认软件的质量，其一方面是确认软件做了你所期望做的事情（，另一方面是确认软件以正确的方式来做了这个事情。第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息。第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。

爱国者导弹防御系统把“枪口”对准了自己人 美国迪斯尼公司的狮子王游戏软件的兼容性问题 售票系统性能问题

2.论述软件测试科学的发展历程 1957年之前－调试为主 20世纪50年代，计算机刚诞生不久，只有科学家级别的人才会去编程，需求和程序本身也远远没有现在这么复杂多变，相当于开发人员一人承担需求分析，设计，开发，测试等所有工作，当然也不会有人去区分调试和测试。

1957–1978－证明为主 当时计算机应用的数量，成本和复杂性都大幅度提升，随之而来的经济风险也大大增加，测试就显得很有必要了，这个时期测试的主要目就是确认软件是满足需求的，也就是我们常说的“做了该做的事情”。

1979–1982－破坏为主 我们不仅要证明软件做了该做的事情，也要保证它没做不该做的事情，这会使测试更加全面，更容易发现问题。

1983–1987－评估为主 人们提出了在软件生命周期中使用分析，评审，测试来评估产品的理论。软件测试工程在这个时期得到了快速的发展.1988–至今－预防为主 预防为主是当下软件测试的主流思想之一。测试不是在编码完成后才开始介入，而是贯穿于整个软件生命周期。3.论述软件缺陷的由来

软件缺陷的产生主要是由软件产品的特点和开发过程决定的。

软件本身：①需求不清晰，导致设计目标偏离客户的需求，从而引起功能或产品特征上的缺陷。②系统结构非常复杂，而又无法设计成一个很好的层次结构或组件结构，结果导致意想不到的问题或系统维护、扩充上的困难；即使设计成良好的面向对象的系统，由于对象、类太多，很难完成对各种对象、类相互作用的组合测试，而隐藏着一些参数传递、方法调用、对象状态变化等方面问题。③对程序逻辑路径或数据范围的边界考虑不够周全，漏掉某些边界条件，造成容量或边界错误。④对一些实时应用，要进行精心设计和技术处理，保证精确的时间同步，否则容易引起时间上不协调，不一致性带来的问题。⑤没有考虑系统崩溃后的自我恢复或数据的异地备份、灾难性恢复等问题，从而存在系统安全性、可靠性的隐患。⑥系统运行环境的复杂，不仅用户使用的计算机环境千变万化，包括用户的各种操作方式或各种不同的输入数据，容易引起一些特定用户环境下的问题；在系统实际应用中，数据量很大。从而会引起强度或负载问题。⑦由于通信端口多、存取和加密手段的矛盾性等，会造成系统的安全性或适用性等问题。⑧新技术的采用，可能涉及技术或系统兼容的问题，事先没有考虑到。

团队工作：系统需求分析时对客户的需求理解不清楚，或者和用户的沟通存在一些困难。不同阶段的开发人员相互理解不一致。对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。项目组成员技术水平参差不齐技术问题。算法错误：在给定条件下没能给出正确或准确的结果。语法错误：对于编译性语言程序，编译器可以发现这类问题；但对于解释性语言程序，只能在测试运行时发现。计算和精度问题：计算的结果没有满足所需要的精度。系统结构不合理、算法选择不科学，造成系统性能低下。接口参数传递不匹配，导致模块集成出现问题。

项目管理的问题：缺乏质量文化，不重视质量计划，对质量、资源、任务、成本等的平衡性把握不好，容易挤掉需求分析、评审、测试、等时间，遗留的缺陷会比较多。系统分析时对客户的需求不是十分清楚，或者和用户的沟通存在一些困难。开发周期短，需求分析、设计、编程、测试等各项工作不能完全按照定义好的流程来进行，工作不够充分，结果也就不完整、不准确，错误较多；周期短，还给各类开发人员造成太大的压力，引起一些人为的错误。开发流程不够完善，存在太多的随机性和缺乏严谨的内审或评审机制，容易产生问题。文档不完善，风险估计不足等。4.软件测试V模型

①绘制示意图

②阐述每个步骤是做什么 需求分析

即首先要明确客户需要的是什么，需要软件作成什么样子，需要有那几项功能

概要设计

主要是架构的实现，指搭建架构、表述各模块功能、模块接口连接和数据传递的实现等项事务。详细设计

对概要设计中表述的各模块进行深入分析，对各模块组合进行分析等。软件编码

按照详细设计好的模块功能表，编程人员编写出实际的代码。单元测试

按照设定好的最小测试单元进行按单元测试，主要是测试程序代码，为的是确保各单元模块被正确的编译，单元的具体划分按不同的单位与不同的软件有不同。集成测试

经过了单元测试后，将各单元组合成完整的体系，主要测试各模块间组合后的功能实现情况，以及模块接口连接的成功与否，数据传递的正确性等，其主要目的是检查软件单位之间的接口是否正确。根据集成测试计划，一边将模块或其他软件单位组合成系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。系统测试

经过了单元测试和集成测试以后，我们要把软件系统搭建起来，按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞，等。验收测试

主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。

第三篇：软件测试管理总结

软件测试管理总结

软件测试工程师管理系统是我接触的测试管理项目，通过近两个星期对软件测试管理的学习和实践，遇到了很多问题，觉得还是有很多经验需要总结。

随着软件开发规模的增加、复杂程度的增加，以寻找软件中的故障为目的的测试工作就

显得更加重要。因此，为了尽可能多的找出程序中的故障，开发出高质量的软件产品，必须

对测试工作进行组织策划和有效管理，采取系统的办法建立起来软件测试管理系统。在进行

测试工作识别管理的过程中，我主要做了测试计划，测试实施，测试总结这几部分工作。

一、测试计划的编写要足够清晰合理。

测试计划阶段的整体目标是为了确定测试范围、测试策略和方法，以及对可能出现的问

题和风险，所需要的各种资源和投入等进行分析和估计，以指导测试的执行。在计划中要明

确测试的目的，完善对测试人员的资源分配，设置测试的标准，责任及时间都有明确的进度

安排，指出所用工具。测试计划编写时要对照产品需求说明书，系统全面的对测试工作作出

筹划。

二、准确的填写bug记录单需进行充分的步骤记录。

在测试过程中，bug记录单不清晰，产品错误便不会容易再现。作为测试管理人员对于

问题记录单中必须包括的要素要了解。我曾经有过造成填写的问题记录单过于简练，只有结

果，没有清晰的操作步骤，没有描述产生错误的数据信息等，这些都会在测试实施过程中造

成不必要的麻烦，给开发人带来模糊理解。认识问题才能解决问题，我在以后的工作中正尽

可能避免这些问题。

三、测试结果的分析要全面公正。

测试结束后，对测试结果进行分析，以确定软件产品的质量，为产品的改进或发布提供

数据和支持。在管理上，应做好测试结果的审查和分析，做好测试报告的撰写和审查工作。

对软件测试工程师管理系统的管理工作中，我觉得还可以努力地还有，明确测试流程，注意测试流程中各阶段的注意事项，及正确填写问题记录单。及时发现测试实施工作中的各

种问题，加强与开发人员的沟通，以便及时解决问题，保证产品测试进度。

第四篇：软件测试管理常见问题及其回答

由安博测试空间技术中心http:///提供

软件测试管理常见问题及其回答

软件测试管理常见问题及其回答

1、测试负责人要进行严格的测试进度跟踪吗？

很多时候，由于人力资源的不足，测试项目负责人都是在执行测试，这样就使整个项目缺乏控制，一些问题（例如：有些成员的缺陷质量不够合格；开发人员修改不及时，系统某些功能发生严重问题导致部分功能无法测试。）得不到解决，耽误了进度。所以测试负责任必须全程监控项目，尽可能多的掌握信息。通常，测试负责人需要完成下面这些内容的管理工作： 测试用例执行情况；

每个测试员提交的缺陷情况；

测试中是否发生突发问题。

2、测试也有版本控制吗？

这里的版本主要是指测试对象的版本控制，也就是指对开发部提交的产品进行版本控制。在开发小组版本管理不规范的情况下，测试小组进行版本控制十分重要，要保证测试对象是可以控制的。建议开发和测试双方进行明确的约定，可以各自指定专门的测试版本负责人，制定提交原则，对提交情况进行详细的记录，这样基本避免了版本失控导致的测试失误或无效。

3、如何处理测试人员的流动问题？

人员流动不仅仅是测试部门，这是IT行业的普遍现象。从管理者角度，主管需要多多和团队内成员进行沟通，建立一个融洽的团队环境，及时掌握情况，可以早些进行相应的调整。但是只有企业建立好的用人制度，给员工提高广阔的发展空间和好的培训学习机会，才能从根本上解决这一问题。

加强项目管理，强化文档管理并保证文档的有效性，可以大大减少由于人员流失带来的损失。同时，测试部门要建立培训机制，使新到员工接受直接或者间接的培训，快速适应工作。

4、为什么开发人员经常抱怨测试工程师提交的缺陷质量太差？

我们经常听开发人员说：“这不是缺陷！”，“这个缺陷没有，因为我的系统上运行正常！”。测试工程师本身就是做质量工作的，提交的成果本身就应该质量高些，为什么还会有这种现象？

提交的缺陷引起争议是一种正常的现象，例如测试人员描述不清楚就会引起争议。减少甚至避免这种现象的方法是交叉测试，交叉测试是提高测试质量的一个有效手段，当然交叉测试会增加一定的测试成本投入。在测试任务完成后，测试工程师之间互相验证彼此提交的缺陷，就会避免了缺陷描述不清、因运行环境而产生的缺陷等一系列问题，从而大大降低了回归测试以及交流的成本，因而这种投入也是值得的，实际开发人员在单元测试阶段也会进行交叉测试，来提高开发质量。

另外，测试人员一定要按照规范描述测试中发现的缺陷，一个缺陷至少描述清楚概要描述、详细描述、重现步骤三方面的内容，缺陷管理参考第八章的内容。

5、“让那些新手来做测试，反正他们也不会什么”正确吗？

在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员。也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率低下，测试人员对测试工作索然无味。

根据笔者的经验，测试团队应首先聘请一名资深的测试领域专家，他应具有极为丰富的同类项目软件测试经验，对软件开发过程中常见的缺陷或错误了然于胸;此外，他还具有较好的亲和力和人格魅力。其次，项目测试团队还具有很多具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本等。

另外，测试团队还应聘请一些兼职成员，如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。至于测试团队里里的测试新手，这部分人可以安排去从事交付验证或黑盒测试之类的6、测试同化现象是什么？

同化现象是指随着时间的推移，开发人员会逐渐影响测试人员的思维和对缺陷的判断能力，尤其是针对同一产品，同一组开发人员和同一组测试人员共同配合了很长时间，很多本来是缺陷的问题，由于测试人员对软件“习惯成自然”的使用，会不被当成缺陷，尤其是在开发人员的解释和说服下。同化现象发生可能意味着“恶性循环”的开始：测试人员会帮着开发人员解释一个个缺陷的合理性，一轮有一轮的测试都不会发现问题。

招聘新的人员，不同的测试项目组轮换去测试不同的产品，就可以避免。同时建议产品可以发布测试版，更多的人对其进行测试，就可以发现更多的问题。

7、测试工程师如何避免定位效应？

社会心理学家曾作过一个试验：在召集会议时先让人们自由选择位子，之后到室外休息片刻再进入室内入座，如此五至六次，发现大多数人都选择他们第一次坐过的位子。这种现象称为定位效应，说明人们习惯上凡是自己认定的，人们大都不想轻易改变它。

定位效应在开发人员和测试人员身上都有体现。例如开发工程师针对某一自己写的功能，经常进行代码移植，这种复制的“功能”，由于上一次经过调试，在新的地方往往不会认真调试，这些代码往往会带来共享变量冲突等许多种类型的缺陷。

定位效应体现在测试人员身上就是测试过的功能不再进行认真测试：在回归测试时，之前由于进行过认真的测试，往往会认为某些功能是可靠，只要验证一些以前发现的缺陷是否修改完成就可以了。这种现象在反复多次回归时表现的更加突出，因为回归测试中很多功能都会进行多次反复测试。众所周知，开发人员在修改缺陷时往往会引入新的缺陷，测试人员的疏于防范就会把这些缺陷带到用户这里。

解决这种问题的方案一般有两个：

(1)完整的执行测试用例：这种方法投入较大，但是在开发产品时最好在最后一次回归测试时测试的执行一次全部的测试用例。

(2)交叉测试：测试人员交叉测试，就可以很大程度的避免定位效应。测试工程师在回归测试时互相交换任务，反复测试某一功能的机会大大减少，从而也就不会“主观的”人员某些功能没有缺陷。

通常上面的两个方法都是结合使用的，既要进行交叉测试，又要全面执行测试用例，测试覆

盖面要尽可能的广泛。

8、测试人员忽然辞职怎么办？

目前IT行业人员流动较大已经成为一种不争的事实，员工的辞职大多数都会给组织带来一定的影响，而这种影响基本是不可能避免的。在测试领域，员工忽然辞职也会带来很大的负面影响，尤其测试队伍规模较小时。面对这种情况，我们所能做的，就是如何最大限度的降低这种影响。

根据作者的经验，主要有两种方法：第一种是在测试人员内部建立一个良好的学习环境，大家互相学习，这样某些特有技术不会被某一个人所掌握，而互相学习和提高自身，也是大多数成员愿意做的；第二种就是在组织中进行知识管理，把技术作为知识沉淀下来，这样新的员工在接手工作时容易上手，通过学习快速适应环境。

此外，日常还要注意工作规范化，例如形成尽可能多的文档，都可以降低员工离职带来的损失。

9、测试人员工作发生问题测试经理应该如何做？

测试人员工作发生问题是测试经理经常要面对的问题，作为测试部门的领导，首先要做的是指出测试人员所犯的错误，使其尽快改正错误。

唯一不能做的就是盯着下属的错误不放。总盯着下属的失误，是一个领导者的最大失误。英国行为学家波特说：当遭受许多批评时，下级往往只记住开头的一些，其余就不听了，因为他们忙于思索论据来反驳开头的批评。身为测试经理要根据测试人员的心理来进行指导，最大限度的调动每个人员的积极性来参加工作。

10、不深入到具体测试工作时，测试经理如何考核员工？

这种现象在测试规模较大的组织中很常见。测试经理应该尽可能的安排每周与每个成员在不被打扰的环境下进行谈话，这样可以尽早发现和解决很多问题。

最为一个测试经理，主要工作之一就是定期的评定组织做了些什么并且是怎样做的。同时还要为员工做一个报告——关于充分了解测试人员正在做什么和怎样做的报告，以此来给测试人员做做工作成绩考核。这份报告要了解到每个人的动态。

测试经理和每个员工重点是谈谈目前的工作，例如大家在工作中的问题或意见；是否需要帮助等。许多管理者经常抱怨没有时间在一周会见每一个员工来谈他们的工作。但是根据作者的经验，如果不能安排时间和员工进行每周的谈话，员工会来打扰测试经理的工作，因为员工很多问题还要要来找测试经理商议。

同时对待员工要用他们能接受的方式，而不是我们自己可以接受的方式。“己之不予，勿施于人”，这条黄金法则可能会对许多生活中的纯粹的社交因素有效，但是并不是总对工作有用。有效率的管理者知道应该逐渐了解每一个员工需要怎样的对待方式。

总之，只有尽可能多的和员工接触，才能更精确的进行考核。

11、测试经理如何面对加班问题？

大多数情况下，作者是不主张加班的。当员工每周工作超过40个小时的时候，他们开始在工作的时候关心自己的事。他们花钱，会给很久没有联系的人打电话，因为员工们一直都在工作。员工不能在太疲劳的状态下完成工作，这是因为他们在工作时不能关心自己，这种情况下通常效率很低。

测试管理工作的重要任务之一就是要创造一个环境，让员工在工作时间内完成工作，同时还要鼓励他们每周不要超过40小时，甚至可以基于他们在40个小时能够完成的工作量给他们酬劳。通常情况下这样做能够提升创造力，从而会逐渐提高效率。

测试工作本身的一个突出特点就是不断重复枯燥、冗长的测试，如果在疲劳状态下，很有可能精力不集中，略过一些重要的测试环节。而且有的时候测试需要编写测试驱动程序，这种情况更需要较好的状态来工作。

12、测试管理者如何面对自己的错误？

每个人都会犯错。我们可能会因为忘记开会而使客户发怒，承认自己犯错是一件尴尬的事情，尤其是管理人员认为对自己负责的项目小组承认犯错可能会失去尊严。如果我们不是经常犯错，承认错误的时候其实能够赢得尊敬。例如我们忘记一次会议，然后为此向同事或者客户道歉，其他的人会理解我们的。

不管做了什么，不要否认或故意忽略自己的失误。故意忽略不会让错误消失，这只会让错误成长为怪物。

13、为什么计划定期的培训?

测试工作和开发工作一样，不但要面对日新月异的新技术，还要学习相关系统的领域知识。只有在不断的学习中，才能做好工作，跟上行业的发展。如果测试管理者没有基于不断的变化而培训员工，就会给组织带来一定的损失。日常培训可以是关于特定项目或者是技术，通常采用下面几种方法：

（1）测试部门内自由交流方式的培训。这种培训的交流比较随意，可以在周五的例会上进行交流，也可以大家一起坐在茶馆里进行交流。方法可以采用“头脑风暴法”，让每个组员讨论一个特定的领域，这种交流方法特别对同时要做很多不同项目的小组比较有益处。当每个人做不同的项目，这会有助于每个人了解你小组所有的工程。

（2）跨部门的互相学习。测试工作需要很多领域以及技术知识，这些知识单靠自学是远远不够的。和其它部门的同事进行交流是一个相当好的办法，大家在工作中可以在技术等各个方面互相得到提高。

（3）外部培训。外部培训尽管投入较高，但也是值得的。这些专家一般在自己的领域非常精通，可以快速提高整个测试团队的水平。也可以通过测试小组介绍一些朋友来进行培训，这种方式可以降低成本。

培训是构造学习型组织的基本条件，也是提高员工水平的重要方法。经常的定期培训，可以增强组织凝聚力，使员工更加愿意长期留在组织中发展。做为测试负责人，定期的进行培训是十分必要的。

14、时间上不允许进行全部测试，测试负责人应该如何做？

这个问题也许十分可笑，可是现实中我们的测试经理们却不得不面对这个问题。这里的全部测试不是指对软件进行遍历测试，而是指测试负责人制定的测试计划包含的全部测试内容。通常，不管是开发产品还是做具体的项目，都会发生耽误进度的情况。一旦整体进度不能向后延迟，项目相关人员习惯上的做法就是缩减测试时间。尤其在功能还没有开发完成的情况

下，这种现象更为突出。

担负着质量重任的测试经理，如何来解决这个问题呢？比较好的做法是按照下面的步骤逐步来完成和改进工作：

（1）按照测试任务的轻重缓急，尽最大努力完成测试任务。在时间不足的情况下，我们应该对测试任务按照优先级来划分，重要紧急的任务先完成。这个时候的测试任务是一种辅助性工作，其目的就是尽最大努力来提高质量。因此，面对这种情况，测试负责人要做的就是带领测试小组充分利用所有资源来保证质量。

（2）在实际工作中和开发人员共同配合，逐步改进工作。只有整个团队的软件开发能力提高了，才能从根源上解决问题。因此，测试负责人要带领团队和开发小组共同寻找适合自己的开发模式，从而使项目规划的更加合理，进而按照预定计划来开展测试工作。

总之，在任何情况下，测试负责人都不应该抱怨。只有积极的面对问题，才能更好的解决问题。

15、公司不重视测试，测试负责人如何开展测试工作？

目前国内的软件公司不重视测试仍然是一种普遍现象。尽管很多公司在意识上已经开始重视测试，但是在具体工作中，往往由于追赶进度、节省资源等方面原因而忽略测试工作。在这种情况下，测试负责人仍要对软件质量负主要责任。在这种环境下，测试负责人应该如何开展工作呢？

首先，要主动去配合开发人员完成工作。尤其是不能抱怨环境，在任何情况下抱怨是不能解决问题的，只能加重矛盾的激化。在此基础上，逐渐显出测试工作的重要性，然后再逐步健全测试体系。

其次，用实际行动来证明测试工作的重要性。只有测试工作的业绩逐步表现出来，人们才会真正的注意到测试的重要性。因此，测试负责人从点滴开始做起，才能逐步做好测试工作。要想做好软件，把开发的软件产品形成商品，测试工作必须和开发一样重视。否则，质量不好的产品，很快会被市场淘汰的。现代的软件规模越来越大，测试工作也会越来越重要，因此测试负责人只要坚持做好工作，可发挥作用的空间会越来越大。

最后要说的是，如果真的是在一个没有希望的团队里，测试负责人可以考虑辞职。辞职也是一个不错的选择，到新的环境去发挥自己的能力，要比长时间的怀着“郁闷”的心情去工作好的多。

16、测试管理者需要是技术专家吗？

测试管理者在测试项目中的主要任务是制定测试策略，管理测试计划的落实情况，并且还要为测试项目的进行创造良好的执行环境。同时还要调动员工的创造性，对员工的工作作出评估。这些工作不一定要求测试管理者达到专家的水平。

但是在实际工作中，由于测试人员的短缺，测试管理者常常做为测试员来执行具体的测试任务。尤其在规模较小的测试团队，测试管理者的日常工作通常以具体的测试执行工作为主，这个时候更需要测试管理者有较好的背景知识。

总体说来，技术方面的背景知识对测试管理者是十分有益的。例如：分配工作任务、做进度预算，以及一些具体的执行工作，都需要一定的背景知识。当然，做为一个测试管理者，没有必要精通所有的技术，那也是办不到的。测试管理者做到正确的帮助员工最好地完成工作，并且提供最好的完成工作的环境就可以了。

第五篇：软件测试复习资料

1． 黑盒测试法是通过分析程序的功能来设计测试用例的方法。

2． 黑盒测试除了测试程序外，它还适用于对需求分析阶段的软件文档进行测试。3． 白盒测试除了测试程序外，它也适用于对软件具体设计阶段的软件文档进行测试。4． 单元测试一般以白盒测试法为主，测试的依据是模块功能规格说明。5． 软件测试中常用的静态分析方法是引用分析和接口分析。

6． 测试人员的基本素质为计算机专业技能、测试专业技能、行业知识

7． 软件危机的体现为：A、开发成本和进度估计不正确B、用户对完成的软件不满足C、软件经常不可维护；

8． 软件测试按照开发阶段划分：A、单元测试

B、集成测试；系统测试C、确认测试；验收测试

9． 软件测试按照测试技术划分：A、性能测试、负载测试、压力测试B、恢复测试、安全测试、兼容测试

10． 软件测试项目周期是指：A、需求阶段、测试计划B、阶段测试、设计阶段测试、执行阶段 11． 软件测试原则有：A、制定严格的测试计划 B、保留所有的测试文档C、功能测试中的缺陷确认 12． 制定测试计划的步骤：确定测试范围、确定测试策略、确定测试标准、确定测试构架、确定项目管理机制、预计测试工作量、测试计划评审 13． 对于软件的β测试，β测试就是在软件公司外部展开的测试，由非专业的测试人员执行的测试。14． 正式的技术评审FTR（Formal Technical Review）是软件质量保证活动，其相关的描述为： A.FTR是评审产品而不是评审生产者的能力B.FTR要有严格的评审计划并遵守日程安排C.FTR限制参与者人数并要求评审会之前做好预备 15． 在进行单元测试时，常用的方法是采用白盒测试，辅之以黑盒测试

16． 侧重于观察资源耗尽情况下的软件表现的系统测试被称为压力测试 17． 必须要求用户参与的测试阶段是验收测试 18． 系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

19． 测试通常可分为白盒测试和黑盒测试。白盒测试是根据程序的内部逻辑来设计测试用例,黑盒测试是根据软件的规格说明来设计测试用例。20． 一个程序中所含有的路径数与程序的复杂程度有着直接的关系。

1． 测试阶段的根本目标是尽可能多地发现并排除软件中潜藏的错误，最终把一个高质量的软件系统交给用户使用。2． 功能测试时系统测试的主要内容，检查系统的功能、性能是否与需求规格说明相同。3． 软件测试主要分为单元测试、集成测试、确认测试和系统测试四类测试。4． 渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。5． 编写测试用例的依据是单元测试计划和详细设计说明书。6． 系统测试时在集成测试完成后，确认测试之前进行的测试。

7． 设计系统测试计划需要参考的项目文档有软件测试计划、软件需求工件、和迭代计划。

8． 测试设计员的职责有设计测试用例、设计测试过程、脚本。

9． 软件验收测试包括正式验收测试、alpha测试、beta测试三种类型。10． 软件测试按照开发阶段划分单元测试、集成测试、系统测试、确认测试、验收测试。11． 软件测试按照测试技术划分性能测试、负载测试、压力测试、恢复测试、安全测试、兼容测试

12． 静态测试基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件 13． 软件测试项目周期是指需求阶段、测试计划、阶段测试、设计阶段测试、执行阶段 14． 软件测试的角色分析人员、设计人员、开发人员、执行人员 15． 软件测试原则有制定严格的测试计划、、保留所有的测试文档、功能测试中的缺陷确认

16． 测试工作的文档主要有：测试计划、测试模型和用例设计或规格说明、测试分析报告等

17． 测试计划的制定必须要注重测试策略、测试范围、测试方法、测试安排、测试风险、测试治理

18． 缺陷的分类为：需求文档的缺陷、软件配置引起的缺陷、分析、设计的缺陷、静态文档的缺陷、软件开发引起的缺陷、短视将来的缺陷 19． 测试用例工作主要是如何添加测试用例、如何编写测试用例、将测试用例和需求关联

20． 自动化测试工具有：ratinal Robot、winrunner、quicktest 21． 软件性能测试工具有： loadRunner、Ratinaol Visual Qantify、PureLoad 22． BUG的种类有：需求阶段的BUG、分析设计阶段的BUG、实现阶段的BUG、配置阶段的BUG、静态文档的BUG。23． 测试项目主要包括以下几个阶段：计划阶段、初始阶段、执行阶段、总结评估阶段、设计阶段。

1． 缺陷报告

是描述软件缺陷现象和重现步骤地集合。软件缺陷报告Software Bug Report（SBR）或软件问题报告Software Problem Report（SPR）

2． 回归测试

是指重新执行已经做过的测试的某个子集，以保证修改变化没有带来非预期的副作用。

3． 动态测试 通过运行软件来检验软件的动态行为和运行结果的正确性。动态测试的两个基本要素： 被测试程序、测试数据（测试用例）

4． 白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。白盒测试是把测试对象看作一个打开的盒子，测试人员须了解程序的内部结构和处理过程，由于白盒测试是一种结构测试，所以被测对象基本上是源程序，以程序的内部逻辑和指定的覆盖标准确定测试数据。

5． 黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。

6． 路径覆盖的含义是，选取足够多的测试数据，使程序的每条可能路径都至少执行一次(如果程序图中有环，则要求每个环至少经过一次)。

7． 软件测试 ：在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。8． 单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。9． 集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为系统，应提交集成测试计划、集成测试规格说明和集成测试分析报告。

10． 确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。

11． 系统测试：将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。

1． 测试过程中会产生哪些基本文档？

（1）测试计划（通常包括单元测试和集成测试）：确定测试范围、方法和需要的资源

（2）测试过程：详细描述和每个测试方案有关的测试步骤和数据（包括测试数据及预期的结果）；

（3）测试结果：把每次测试运行的结果归入文档，如果运行出错，则应产生 问题报告，并且必须通过调试解决所发现的问题。

（4）

2.大型软件系统的测试过程基本上由几个步骤组成? 1）.模块测试

在设计得好的软件系统中，每个模块完成一个清晰定义的子功能，而且这个子功能和同级其他模块的功能之间没有相互依赖关系。因此，有可能把每个模块作为一个单独的实体来测试，而且通常比较容易设计检验模块正确性的测试方案。模块测试的目的是保证每个模块作为一个单元能正确运行，所以模块测试通常又称为单元测试。在这个测试步骤中所发现的往往是编码和详细设计的错误。2）.子系统测试

子系统测试是把经过单元测试的模块放在一起形成一个子系统来测试。模块相互间的协调和通信是这个测试过程中的主要问题，因此，这个步骤着重测试模块的接口。3）.系统测试

系统测试是把经过测试的子系统装配成一个完整的系统来测试。在这个过程中不仅应该发现设计和编码的错误，还应该验证系统确实能提供需求说明书中指定的功能，而且系统的动态特性也符合预定要求。在这个测试步骤中发现的往往是软件设计中的错误，也可能发现需求说明中的错误。不论是子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。4）.验收测试

验收测试把软件系统作为单一的实体进行测试，测试内容与系统测试基本类似，但是它是在用户积极参与下进行的，而且可能主要使用实际数据(系统将来要处理的信息)进行测试。验收测试的目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。验收测试也称为确认测试。5）.平行运行

关系重大的软件产品在验收之后往往并不立即投入生产性运行，而是要再经过一段平行运行时间的考验。所谓平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。这样做的具体目的有如下几点：(1)可以在准生产环境中运行新系统而又不冒风险；(2)用户能有一段熟悉新系统的时间；

(3)可以验证用户指南和使用手册之类的文档；

(4)能够以准生产模式对新系统进行全负荷测试，可以用测试结果验证性能指标。3.一套完整的测试应该由哪些阶段组成？分别阐述一下各个阶段。

计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测试、验收测试一套完整的测试应该由五个阶段组成：

1）测试计划首先，根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，即制订黑盒测试的最高标准。以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试时间及测试资源等。2）测试设计将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例（测试用例选择的好坏将直接影响测试结果的有效性）。

3）测试开发建立可重复使用的自动测试过程。

4）测试执行执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理，测试执行一般由单元测试、组合测试、集成测试、系统联调及回归测试等步骤组成，测试人员应本着科学负责的态度，一步一个脚印地进行测试。

5）测试评估结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。4.软件测试的流程

制订测试计划、设计测试用例、实施测试、提交缺陷报告、编写测试总结。5.测试计划的内容都包括什么？其中哪些是最重要的？

1)测试计划的内容：测试目的和测试项目简介、测试参考文档和测试提交文档、术语和定义、测试策略、确定测试内容、资源、测试进度、测试员的职责与任务分配、项目通过或失败的标准、暂停和重新启动测试的标准、风险和问题等。2)最重要的：测试策略、确定测试内容、资源、测试进度、测试员的职责与任务分配、项目通过或失败的标准 6.测试计划的目的是什么？

测试计划的目的：编写软件测试计划的目的是指导测试组成员进行工作和让测试组以外的项目成员了解测试工作的。7.简述静态测试和动态测试的区别？

a)静态测试： 基本特征是在对软件进行分析、检查和审阅，不实际运行被测试的软件。静态测试约可找出30～70%的逻辑设计错误。对需求规格说明书、软件设计说明书、源程序做检查和审阅。包括：是否符合标准和规范；通过结构分析、流图分析、符号执行指出软件缺陷。b)动态测试：通过运行软件来检验软件的动态行为和运行结果的正确性。动态测试的两个基本要素：被测试程序和测试数据（测试用例）。动态测试方法：(1)选取定义域有效值,或定义域外无效值；(2)对已选取值决定预期的结果；(3)用选取值执行程序；(4)执行结果与预期的结果相比,不吻和程序有错。8.白盒测试有哪几种方法？

语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。9.压力测试和性能测试的区别？

1)广义上说压力测试是包括在性能测试之中的，是性能测试项内的一种。

2)性能测试：顾名思义就是测试软件的运行性能。验证SRS中的性能需求，是否实现。

3)压力测试：测试软件在超负荷下的工作情况，也是一种软件的性能。因此是属于性能测试范围的。

10.测试结束的标准是什么？

测试计划中所有规定的测试内容和回归测试都已经运行完成或根据上级主管对测试结果的意见，就可以结束本次测试。11.黑盒测试的测试用例设计方法包括哪些？：

a)等价类划分：划分等价类--确立测试用例--设计用例。b)边界值分析：通过分析，考虑如何确立边界情况 c)错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。d)因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试用例。这适合于检查程序输入条件的各种组合情况。

12.缺陷报告的作用

缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值缺陷报告可以把软件存在的缺陷准确的描述出来，便于开发人员修正缺陷报告可以反映项目、产品当前的质量状态，便于项目整体进度和质量控制。软件测试缺陷报告是软件测试的输出成果之一，可以衡量测试人员的工作能力。13.等价分类法的基本思想是什么？

根据程序的输入特性，将程序的定义域划分为有限个等价区段“等价类”，从等价类中选择出的用例具有“代表性”，即测试某个等价类的代表值就等于对这一类其他值的测试。如果某个等价类的一个输入数据（代表值）测试中查出了错误，说明该类中其他测试用例也会有错误。14.简单阐述一下软件测试的目标

(1)测试是为了发现程序中的错误而执行程序的过程；

(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；(3)成功的测试是发现了至今为止尚未发现的错误的测试。15.软件测试准则有哪些？

(1)所有测试都应该能追溯到用户需求。

(2)应当把“尽早地和不断地进行软件测试” 作为软件开发者的座右铭。(3)pareto原则：测试发现的错误中的80%很可能是由程序中20%的模块造成的。

（4）应该从“小规模”测试开始，并逐步进行“大规模”测试。

（5）测试用例应由输入数据和预期的输出结果两部分组成，并兼顾合理的输入和不合理的输入数据

（6）穷举测试是不可能的。

（7）为了达到最佳的测试效果，应该由独立的第三方从事测试工作。

（8）程序修改后要回归测试。

（9）应长期保留测试用例，直至系统废弃。16.您认为做好测试用例设计工作的关键是什么？

1)白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

2)黑盒测试用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

1． 根据下面给出的规格说明，利用等价类划分的方法，给出足够的测试用例。

“一个程序读入三个整数。把此三个数值看成是一个三角形的三个边。这个程序要打印出信息，说明这个三角形是三边不等的、是等腰的、还是等边的。”

2． 某报表处理系统要求用户输入处理报表的日期，日期限制在2003年1月至2008年12月，即系统只能对该段期间内的报表进行处理，如日期不在此范围内，则显示输入错误信息。系统日期规定由年、月的6位数字字符组成，前四位代表年，后两位代表月。请用等价类划分法和边界值划分法设计测试用例来测试程序的日期检查功能。

3． 设要对一个自动饮料售货机软件进行黑盒测试。该软件的规格说明如下：

“有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。若投入1元5角硬币，按下“可乐”、“雪碧”或“红茶”按钮，相应的饮料就送出来。若投入的是2元硬币，在送出饮料的同时退还5角硬币。”

利用等价类划分的方法，设计测试该软件的全部测试用例。