软件测试过程及方法指南
最近总有人询问测试计划的编写方法和步骤，如何合理的设计测试计划是每个测试经理的责任，测试中需要关注的要素太多了，既有技术方面的考虑，也有管理方面的考虑，如何才能设计出实用的测试计划呢？我根据自己的经验，理出一份软件测试计划编写指南，希望对大家有所启示，并同大家交流测试中的心得和方法。
1 前言
1.1 软件测试的目的
软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。
不同的软件项目会有不同的测试目的；相同的软件项目，不同的时期也可能有不同测试目的，可能是测试不同区域或是对同一区域的不同层次的测试。
软件测试：
①、软件测试是为了发现错误而执行程序的过程；
②、测试是为了证明程序有错，而不是证明程序无错误。
③、一个好的测试用例是在于它能发现至今未发现的错误；
④、一个成功的测试是发现了至今未发现的错误的测试。
这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。
首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。
其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
对于测试数据的动态积累可以给项目管理者展示出当前项目的实时状态，为科学的决策提供有力的保障，并且为今后的培训，考评，工作的检查等提供强有力的数据基础。
1.2 软件测试的复杂性和经济性
人们常常以为，开发一个程序是困难的，测试一个程序则比较容易。这其实是误解。设计测试用例是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。不论是黑盒测试方法还是白盒测试方法，由于测试情况数量巨大，都不可能进行彻底的测试。所谓彻底测试，就是让被测程序在一切可能的输入情况下全部执行一遍。通常也称这种测试为“穷举测试”。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。“白盒”法是穷举路径测试，贯穿程序的独立路径数是天文数字，但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。所以说：“程序测试只能证明错误的存在，但不能证明错误不存在”。
在实际测试中，穷举测试工作量太大，实践上行不通，这就注定了一切实际测试都是不彻底的。当然就不能够保证被测试程序中不存在遗留的错误。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例应注意遵守“经济性”的原则。第一，要根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级；第二，要认真研究测试策略，以便能使用尽可能少的测试用例，发现尽可能多的程序错误。掌握好测试量是至关重要的，一位有经验的软件开发管理人员在谈到软件测试时曾这样说过：“不充分的测试是愚蠢的，而过度的测试是一种罪孽”。测试不足意味着让用户承担隐藏错误带来的危险，过度测试则会浪费许多宝贵的资源。
测试是软件生存期中费用消耗最大的环节。测试费用除了测试的直接消耗外，还包括其它的相关费用。能够决定需要做多少次测试的主要影响因素如下：①、系统的目的
系统目的的差别在很大程度上影响所需要进行的测试的数量。那些可能产生严重后果的系统必须要进行更多的测试。
②、潜在的用户数量
一个系统的潜在用户数量也在很大程度上影响了测试必要性的程度。这主要是由于用户团体在经济方面的影响。
③、信息的价值
在考虑测试的必要性时，还需要将系统中所包含的信息的价值考虑在内，一个支持许多家大银行或众多证券交易所的客户机/服务器系统中含有经济价值非常高的内容。很显然这一系统需要比一个支持鞋店的系统要进行更多的测试。这
两个系统的用户都希望得到高质量、无错误的系统，但是前一种系统的影响比后一种要大得多。因此我们应该从经济方面考虑，投入与经济价值相对应的时间和金钱去进行测试。
④、开发机构
一个没有标准和缺少经验的开发机构很可能开发出充满错误的系统。在一个
建立了标准和有很多经验的开发机构中开发出来的系统中的错误不会很多，因此，对于不同的开发机构来说，所需要的测试的必要性也就截然的不同。然而，那些需要进行大幅度改善的机构反而不大可能认识到自身的弱点。那些需要更加严格的测试过程的机构往往是最不可能进行这一活动的，在许多情况下，机构的管理部门并不能真正地理解开发一个高质量的系统的好处。
⑤、测试的时机
测试量会随时间的推移发生改变。在一个竞争很激烈的市场里，争取时间可
能是制胜的关键，开始可能不会在测试上花多少时间，但几年后如果市场分配格局已经建立起来了，那么产品的质量就变得更重要了，测试量就要加大。测试量应该针对合适的目标进行调整。
1.3 文档介绍
1.3.1 本文档的受众
测试计划编写指南有两类潜在的受众。首先，测试经理使用它作为指导方针
编写测试计划。测试计划编写完成后，将作为整个团队（包括开发人员和测试人员）沟通的基础。
1.3.2 文档更新
测试项目开始时，应该完成测试计划的大部分内容。项目开始后，由于测试情况有变化，可能导致测试计划文档变化。如果文档有明显的变化，必须在文档中添加变更历史来记载这些变化。
1.3.3 文档目的
测试计划在策略和方法的高度说明如何计划、组织和管理测试项目。测试计划包含足够的信息使测试人员明白项目需要做什么是如何运作的。另外，清晰的文档结构能使任何一个读者在浏览计划的前面几页后，就能对项目有一个大概的认识。测试计划只是测试的一个框架，很多细节需要跟开发人员或其他人员沟通，因此计划不包括测试用例的细节和系统功能的详细信息。
本文档描述出了整个开发过程中测试工作的流程，不同的测试时期可以根据需要对本文档的一部分进行充实（如：单元测试阶段等），但是在结项后，本文档规定的各个时期的测试计划均需完整，以备检查。对于项目类产品，可根据实际情况参照执行。
1.4 测试工作流程
测试工作从产品立项后开始介入，贯穿于软件产品的整个生命周期。初期测试经理参与项目的需求评审，并以需求设计为标准设计系统测试的测试用例。当开发进入详细设计阶段时，测试经理根据测试的需要同开发经理讨论技术的实现方式，在允许的范围内，尽量使用方便今后测试工作开展的实现方式。同时此阶段测试经理开始设计集成测试的测试用例。详细设计评审通过后，开发人员开始进入编码阶段，同时，测试经理应同开发经理协调好进度，按照模块开发的时间规划，测试经理开始根据模块的接口规范设计灰盒测试用例，尽量保证模块级的测试可以同开发进度协调进行。编码完成后，测试人员协助开发人员进行集成测
试，测试经理使用前期已经完成的集成测试方案对产品进行测试。集成测试完成后，由测试经理对集成测试的效果进行评估，对于合格的产品填写系统测试申请报告，向测试部正式申请进入系统测试阶段。系统测试完成后，由测试经理向测试部申请软件发行。当相关的产品化工作正式完成后，由测试部开据质量合格证书，产品正式发行。
以上概要的介绍了测试方法和测试原则，以及公司对于产品类项目的测试流程，以下将具体的给出各个测试阶段，相关测试计划的文档要求，文档中将给出关键的考察点，计划编制的技巧与说明，以便在书写测试计划的时候有章可循。
2 引言
2.1 编写目的
阐明编写测试计划的目的并指明读者对象。
2.2 项目背景
说明项目的来源、委托单位及主管部门。
2.3 定义
列出测试计划中所用到的专门术语的定义和缩写词的原意。
2.4 参考资料
列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源，可包括：项目的计划任务书、合同或批文；项目开发计划；需求规格说明书；概要设计说明书；详细设计说明书；用户操作手册；本测试计划中引用的其他资料、采用的软件开发标准或规范。
2.5 文档摘要
主要说明测试计划中重要的和可能有争议的问题。本节的主要目的是将这些信息传递给那些可能不会通读整个测试计划文档的人员（比如经理或开发项目的负责人）。
提示和技巧：
在写这一节时，考虑一下你的计划在那些地方可能会引起反对。这个计划跟以前的计划相比，有什么不同的地方。测试项目与系统开发计划的关系等。
使用列表的格式，可以将问题按重要程度罗列出来，然后在后面的章节中再对这些问题进行详细说明，这样就能让对这些问题有重要影响的人员知道问题的所在。
2.6 文档历史和变更
[作者] – [日期] – [文档的当前状态，上版本以来所作的主要变化]
3 管理
3.1 系统视图和目标
系统视图对测试人员了解自己需要做什么是非常重要的。测试项目负责人应积极与系统设计人员或开发人员沟通，以取得相关资料。系统目标是帮助实现系统视图的重要指标。系统视图和目标对实现整个项目计划来说是至关重要的。测试人员必须知道系统是做什么并且帮助项目实现这种目标。在计划中包括系统视图和目标后，要确保所有的测试人员都知道项目和系统的目标。
通常情况下视图和项目计划都是模糊的。模糊的目标必须通过成员的努力转换成可衡量和实现的东西。没有固定的视图和目标，你将无法完成部分任务。而且，你会发现很难将对产品的认识向别人转述。
提示和技巧：
为什么视图对客户是重要的？
你如何向客户表达这种视图？
你将做什么来保证你是在向实现视图的方向前进?
在你回答这些问题之后，你就可以将视图转换成测试导向的目标？
整个系统的总体运行框架什么？各个部分的运行目标是什么？
3.2 运行环境
需测试的软，硬件环境，有无特殊的要求。如有些设备是有使用时限的需注明，如果测试环境不能满足测试要求，如何解决等？
3.3 资源需求
3.3.1 培训需求
本节说明项目测试人员需要哪些培训。
提示和技巧：
对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。
是否进行自动测试。
测试人员要不要培训以编写自动化脚本。
3.3.2 硬件需求
本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。
3.3.3 软件需求
本节说明测试人员需要使用的软件。
3.3.4 办公空间需求
本节说明需要多少办公空间。
3.4 风险分析
目前存在那些不确定因素，包括可预计的和不可预计的。系统开发和测试过程中，会有各种可能导致系统发布延迟，在计划中需要预先估计这些风险，并且提出相应的对付办法。
3.5 测试团队结构
这一节说明测试团队的结构和项目测试人员的数量。
提示和技巧：
查看开发计划确定那些功能需要最多资源。
在各个测试阶段确定需要多少测试人员，各需掌握那些技巧。
多少人做自动测试，是哪些人。
列出项目参与人员的联系方式包括E-mail 和电话。
3.6 相关信息保存的位置
测试服务器的相关信息；
测试文档保存的位置；
测试工具保存的位置；
测试中需要使用的软硬件的存放地点；
Bug如何记录，存放的位置。
3.7 测试时间安排
包括主要时间点的安排，如各个测试阶段的开始，截至日期，产品预计发布日期等。
3.8 缺陷处理
测试过程中可衡量的是发现的缺陷的状况。因此缺陷的报告和管理必须写成书面文档。
3.8.1 Bug 数据库管理
提示和技巧：
谁负责创建数据库？
谁有权限增加数据库的帐号？
谁有权使用哪类帐号？
数据库使用过程中出了问题和谁联系？
谁负责数据库备份？
多长时间备份一次？
由谁使用数据库？
缺陷管理应该与开发部门的负责人一起讨论。
3.8.2 缺陷处理过程
提示和技巧：
解释缺陷报告和分配过程。
缺陷标题、测试环境应如何填写。
解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。
让测试人员清楚一个缺陷从击活到解决的全过程。
缺陷必须指定由谁负责解决。
定义优先级、严重级别等。
在项目结束时，如何解决这些缺陷。
如果有Bug管理工具，只需遵照工具的流程执行。
3.9.测试过程控制
在测试过程中，通过对缺陷数据库进行分析可以确定测试的状态。另外，通过让测试人员填写测试工作周报，可以对项目进展状况进行反馈。
3.9.1 缺陷数据分析
提示和技巧：
在开发过程和稳定阶段是否有过多的未处理缺陷，这可能说明开发的资源不够，或者有其它问题。
如何确定项目中是否有过多的缺陷。
测试人员是否积极发现缺陷，或者过分积极。
在每个时间点上，系统是否稳定。
系统哪些部分的缺陷最集中。
在系统发行时修复了多少缺陷。
哪些类型的缺陷最普遍。
3.9.2 测试工作周报
提示和技巧：
周报中应包括哪些信息。
如何填写工作周报。
谁负责查看工作周报。
以上详细的描述了，测试过程中可能遇到的或者必须提前安排的工作内容，
有一些项是要在工作过程中陆续充实的，有一些是需要提前给出解决办法的，在制定计划过程中，请依据实际情况进行书写。
4 测试计划
4.1 整体测试策略
本节的目的是说明计划中使用的基本的测试过程。
提示和技巧：
是否使用里程碑技术和在测试过程中验证每个模块？或者是什么都不做，只
是普通的测试而已。
测试人员是否在项目开发初期就开始工作？或者测试人员只在系统开发完后，才开始测试。
是否明显的界定出单元，集成，系统，验收测试阶段？
自动测试工作是否进行？
对于像压力，性能，兼容性等的测试项目，放到那一个测试区间内，有什么
质量要求？
4.2 测试范围
通常说明什么是要测试的，什么是不要测试的是非常重要的。明确规定这些
问题后，测试人员对该做什么有一个清晰的认识。
提示和技巧：
需要特别测试那些部分？
那些部分不需要测试，为什么？
测试人员是否需要测试内容以及相关部分？
是否要验证每个模块的稳定性？
是否有理论上应该测试的，但是测试环境无法进行测试的内容？
对于产品附带的文档，测试人员是否需要检查？
4.3 质量目标
围绕软件质量，有几种不同的说法。第一个是质量是一种绝对的标准，对所有的系统必须等同处理。事实上，质量是相对的而且是和产品相关的概念。例如，多媒体产品的质量目标倾向于精美的表示和适当的内容，而应用系统可能倾向于易用性、健壮性和适用于不同的任务。质量目标可能是动态的。在项目进行过程中，会由于市场压力、新的机会和功能改变而重新设定质量目标。
另一种有关软件质量的说法是，定义和衡量系统质量是测试部门一个部门的事。实际上，建立质量标准是所有职能部门共同努力的结果。测试、开发、系统使用部门、用户教育、系统支撑必须为建立和维护系统的质量标准做出自己的贡献。每个部门必须对自己最了解的部分做出相应的质量定义。例如，测试和开发部门对系统质量的衡量标准主要是健壮性和正确性。用户部门可能对易用性方面比较熟悉。
最后，质量不仅是衡量系统的功能或性能是否正常。对系统来说，在开发过程中尽早建立全面的质量标准与系统的及时发布是一样重要的。质量目标是一个强有力的工具，应该在系统开发过程中尽早建立。一个定义准确的质量目标在以后的产品开发过程中帮助决策。例如，系统是否能够正式发行？在代码完成后，应该修复那些缺陷？在系统完成后那种类型的测试是最合适的。
提示：
质量目标应该是一个确实可行的软件质量描述，在确定之前应该同相关人员达成一致的意见，不要等到发货的时候才发现大家对其的理解有分歧，这时测试人员会非常被动，在达成一致意见后，当开发人员和测试人员有分歧时，可以使用质量目标作为衡量的标准。
4.4 测试计划
一般情况下测试活动大致分成四个部分：单元测试，集成测试，系统测试，验收测试。下面具体介绍一下测试计划的书写方法，工作过程中可以依据实际情况进行删减和补充。
4.4.1 单元测试
单元测试是代码一级的测试，主要依赖于开发人员进行。
单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设计描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。
一、单元测试任务
单元测试任务包括：
（1）模块接口测试；
（2）模块局部数据结构测试；
（3）模块边界条件测试；
（4）模块中所有独立执行通路测试；
（5）模块的各条错误处理通路测试。
模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：（1）输入的实际参数与形式参数的个数是否相同；
（2）输入的实际参数与形式参数的属性是否匹配；
（3）输入的实际参数与形式参数的量纲是否一致；
（4）调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
（5）调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
（6）调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
（7）调用预定义函数时所用参数的个数、属性和次序是否正确；
（8）是否存在与当前入口点无关的参数引用；
（9）是否修改了只读型参数；
（10）对全程变量的定义各模块是否一致；
（11）是否把某些约束作为参数传递。
如果模块内包括外部输入输出，还应该考虑下列因素：
（1）文件属性是否正确；
（2）OPEN/CLOSE语句是否正确；
（3）格式说明与输入输出语句是否匹配；
（4）缓冲区大小与记录长度是否匹配；
（5）文件使用前是否已经打开；
（6）是否处理了文件尾；
（7）是否处理了输入/输出错误；
（8）输出信息中是否有文字性错误；
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
（1）不合适或不相容的类型说明；
（2）变量无初值；
（3）变量初始化或省缺值有错；
（4）不正确的变量名（拼错或不正确地截断）；
（5）出现上溢、下溢和地址异常。
在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：
（1）误解或用错了算符优先级；
（2）混合类型运算；
（3）变量初值错；
（4）精度不够；
（5）表达式符号错。
比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：
（1）不同数据类型的对象之间进行比较；
（2）错误地使用逻辑运算符或优先级；
（3）因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
（4）比较运算或变量出错；
（5）循环终止条件或不可能出现；
（6）迭代发散时不能退出；
（7）错误地修改了循环变量。
一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：
（1）输出的出错信息难以理解；
（2）记录的错误与实际遇到的错误不相符；
（3）在程序自定义的出错处理段运行之前，系统已介入；
（4）异常处理不当；
（5）错误陈述中未能提供足够的定位出错信息。
边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。
二、单元测试过程
一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进
入-退出”消息。
驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的集成测试方法。
提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。单元测试计划的编写应该含盖上述的内容，单形式不限，对于测试的数据应该有效的予以保留，为今后进行数据分析作准备。
4.4.2 集成测试
集成测试针对的是各个相关模块的组合测试，最终的目标是将整个系统正确的组合成功，没有明显的模块之间的匹配问题。
时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。集成测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行集成测试以便发现与接口有关的各种错误。
某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大
堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。
一、自顶向下集成
自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5 和M8 集成在一起，再将M6 集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3 和M4 与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。
自顶向下集成测试的具体步骤为：
（1）以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；
（2）依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；
（3）每集成一个模块立即测试一遍；
（4）只有每组测试完成后，才着手替换下一个桩模块；
（5）为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。
从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。
自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，
因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。
二、自底向上集成
自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，
因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。
自底向上集成测试的步骤分为：
（1）把低层模块组织成实现某个子功能的模块群（cluster）;
（2）开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
（3）对每个模块群进行测试；
（4）删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。
从第一步开始循环执行上述各步骤，直至整个程序构造完毕。
自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序
最后一个模块加入时才具有整体形象。它与自顶向集成测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用
单项选择题：共20小题，每小题1 分，满分20分；请将答案填入题后括号中。 1.在软件生命周期的哪一个阶段，软件缺陷修复费用最低（） （A）需求分析（编制产品说明书）（B）设计 (C) 编码（D）产品发布 2.单元测试中用来模拟被测模块调用者的模块是（） (A) 父模块（B）子模块 （C）驱动模块（D）桩模块 3.为了提高测试的效率，应该（） （A）随机地选取测试数据； （B）取一切可能的输入数据作为测试数据； （C）在完成编码以后制定软件的测试计划； （D）选择发现错误可能性大的数据作为测试数据。 4.侧重于观察资源耗尽情况下的软件表现的系统测试被称为（） （A）强度测试（B）压力测试 (C) 容量测试（D）性能测试 5.必须要求用户参与的测试阶段是（） （A）单元测试（B）集成测试 (C) 确认测试（D）验收测试 6.软件测试员究竟做些什么。（） （A）软件测试员的目的是发现软件缺陷 （B）软件测试员的目的是发现软件缺陷，尽可能早一些 （C)软件测试员的目的是发现软件缺陷，尽可能早一些，并确保其得以修复 （D）软件测试员的目的是发现软件缺陷，尽可能早一些，并将其得以修复 7.下面四种说法中正确的是（） （A）因果图法是建立在决策表法基础上的一种白盒测试方法； （B）等价类划分法是边界值分析法的基础； （C）健壮性等价类测试的测试用例要求在有效等价类中取值； （D）在任何情况下做黑盒测试皆应首先考虑使用错误推断法。 8.不属于单元测试内容的是（） （A）模块接口测试（B）局部数据结构测试 (C) 路径测试（D）用户界面测试 9.划分软件测试属于白盒测试还是黑盒测试的依据是（） （A）是否执行程序代码 （B）是否能看到软件设计文档 （C）是否能看到被测源程序 （D）运行结果是否确定 10.下列项目中不属于测试文档的是（） （A）测试计划（B）测试用例 (C) 程序流程图（D）测试报告 11.几乎没有产品计划、进度安排和正规的开发过程的软件开发模式是（） （A）大棒模式（B）边写边改模式 (C) 瀑布模式（D）快速原型开发模式 12.如果某测试用例集实现了某软件的路径覆盖，那么它一定同时实现了该软件的（） （A）判定覆盖（B）条件覆盖 (C) 判定/条件覆盖（D）组合覆盖 13.下列说法不正确的是（）
其他测试、软件测试过程和管理(二) (总分：100.00，做题时间：90分钟) 一、{{B}}选择题{{/B}}(总题数：42，分数：100.00) 1.下面有关软件测试的叙述中，不属于H模型核心思想的是______。 ? A.软件测试不仅指测试的执行，还包括很多其他的活动 ? B.软件测试是一个独立的流程，贯穿产品整个开发周期，与其他流程并发地进行 ? C.软件测试要尽早准备，尽早执行 ? D.软件测试不同层次的测试活动严格按照某种线性次序执行 （分数：2.50） A. B. C. D. √ 解析：[解析] 软件测试的不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试活动就可以开展。 2.以下有关测试用例设计与开发的说法中，错误的是______。 ? A.白盒测试的测试用例设计不必考虑软件功能 ? B.软件测试用例设计要关注测试用例设计的测试需求覆盖率 ? C.自动化测试的测试脚本开发属于测试用例设计工作的一部分 ? D.测试用例设计的主要依据是测试计划中的测试需求定义 （分数：2.50） A. B. C. D. √ 解析：[解析] 白盒测试义称为逻辑驱动的测试，这种测试策略对程序的逻辑结构进行检查，从中获取测试数据，故A对。自动化测试的测试脚本开发属于自动化测试用例设计工作的一部分，故C对。根据产品需求分析、系统设计等规格说明书，在测试的技术方案基础上设计具体的测试用例，故D错。测试用例是否完整、边界是否考虑，其覆盖率能达到多高，是软件测试设计要点的一部分，故B对。 3.下列有关测试过程管理的基本原则，哪个是错误的______。 ? A.测试过程管理应该首先建立测试计划 ? B.测试需求在测试过程中可以是模糊的、非完整的 ? C.在测试任务较多的情况下，应该建立测试任务的优先级来优化处理 ? D.整个测试过程应该具有良好的可测性和可跟踪性，强调以数据说话 （分数：2.50） A. B. √
测试体系建设与软件测试流程 （初稿）
目录 1.目的3 2.范围3 3.测试过程描述4 3.1 测试流程图4 3.2 活动说明5 3.2.1 需求评审5 3.2.2 编写测试计划6 3.2.3测试用例设计8 3.2.4 测试用例执行9 3.2.5发布版本回归测试12 3.2.6版本迭代回归测试13 3.2.7 文档测试16 3.2.8 测试报告18 4.软件缺陷管理系统—禅道19 4.1 概述19 4.1.1 编写目的19
4.1.2 适用范围19 4.1.3 角色和职责19 4.1.4 禅道简介19 4.2 缺陷状态关系示意图20 4.3 缺陷流转的过程及处理20 4.3.1 基于禅道的项目/测试/Bug管理21 4.4 禅道项目管理流程图21 5.配置管理21 1.目的 本文是对项目软件测试的指导性文件，对软件测试过程中所涉及到的测试理论、测试类型、测试方法、测试标准、测试流程及测试过程中涉及到的角色职责进行总体规范，以有效保证软件质量。 2.范围 本文适用于所有软件测试人员。
3.测试过程描述 3.1 测试流程图 需求规格说明书 测试用例 测试计划 开发计划 评审Checklist 需求评审会议 评审通过 评审 测试版本发布 执行测试用例部署测试环境提交缺陷报告 修复缺陷 确认缺陷是否 验证缺陷 不通过 测试完成通过 测试报告发布上线
3.2 活动说明 3.2.1需求评审 3.2.1.1目的 从源头把握软件质量，并确保开发结果与实际需求相一致，分析需求实现的可能性，功能细节描述无二义，补充需求细节，确定项目周期和时间。 3.2.1.2角色与职责 测试负责人：《需求规格说明书》的编写，以及软件开发过程中《需求规格说明书》的修正； 评审人员：项目经理、开发人员、测试人员等项目干系人； 评审《需求规格说明书》，从全面性、完整性、正确性、一致性、可靠性方面检查《需求规格说明书》，将需求缺陷Checklist提交给产品需求人员，在评审会议上讨论，确定为缺陷后，跟踪需求缺陷直至需求缺陷验证关闭。 3.2.1.3启动标准 《软件需求规格说明书SRS》编写完成
1、判定覆盖设计足够多的测试用例，使得被测试程序中的每个判断的“真”、“假”分支_至少被执行一次。 2、黑盒测试的具体技术方法 ____________、 __________、 __________、____________。 等价类划分法，边界值分析法，决策表法，因果图法 3、黑盒测试又称之为___________测试。 功能 4、等价类划分有两种不同的情况：____________和____________。 有效等价类，无效等价类 5、根据覆盖目标的不同，逻辑覆盖又可分为：________________，_____________，_______________，__________________，条件组合覆盖，判断/条件覆盖。 语句覆盖，判定覆盖，条件覆盖，路径覆盖 6、根据软件生命周期中的定义，可以把自动化测试工具划分3大类____________，____________和 ____________。 白盒测试工具、黑盒测试工具、测试管理工具 7、软件测试是为发现程序中的______________而执行程序的______________。 错误，过程 8、测试用例是由______________和预期的______________两部分组成。 测试输入数据，输出数据 9、白盒测试又称为______________，可以分为______________和______________两大类。 结构测试，静态测试，动态测试 10、软件是包括____________﹑____________﹑____________的完整集合。 程序，数据，相关文档 11、边界值分析法属于____________。 黑盒测试 12、单元测试是以____________说明书为指导，测试源程序代码。 详细设计 13、集成测试以____________说明书指导，测试软件结构。 概要设计 14、确认测试以____________说明书为指导。 需求分析 15、软件开发的基本过程____________，_____________，_______________，_____________， _____________，______________。 需求分析、概要设计、详细设计，编码，测试、维护 16、代码复审属于____________，不实际运行程序。 静态测试 17、集成测试把模块组成成系统的测试方式：_____________和______________。 一次性集成测试，增量式集成测试 18、黑盒测试有两种基本方法，即：_____________和______________。 通过测试，失败测试 二、选择题（每题3分，共10题，分数为30分） 1. 下列哪一项不是白盒测试？（C） A.单元测试 B.集成测试 C.系统测试 D.回归测试 2. 属于黑盒测试的方法？(C) A.基于基本路径 B.控制流 C.基于用户需求测试 D.逻辑覆盖 3．在Assert类中断言对象为NULL是_____。（C） A.assertEquals B.assertTrue C.assertNull D.fail 4．___________的目的是对最终软件系统进行全面的测试确保最终软件系统产品满足需求。（A）
近来，软件测试行业发展迅速，企业越来越重视测试了。越来越多的人加入了测试大军中，很多人也想通过自学来学习软件测试技术加入这个行业，但是现在软件测试的书籍越来越多，也良莠不齐，而且软件测试涉及的技术也越来越多。本文主要说明的是从事软件测试行业需要必备的知识，以及该如何学习，主要给大家提供一些比较优秀的书籍，并给出学习的顺序。希望通过阅读本文，读者可以明确该如何学习测试，并学习哪些知识。由于仅是个人建议，如有错误不妥的地方，敬请提出批评。 一、软件测试基础知识
要想进入测试这个行业，就必须要了解什么是软件测试，该如何测试？ 这部分的学习目标：掌握软件测试的基本概念、软件测试的流程，并能熟练的应用常见的用例设计方法来设计测试用例。掌握常见的测试方法和类型，并知道如何进行每个阶段的测试。 下面是推荐的参考书： 1、软件测试(原书第2版) （美）佩腾（Patton,R.）著，张小松等译 这本书可以用来作为进入行业的第一本书，本书讲解的都是实用的技术，通过阅读本书可以快速的去学会如何测试软件。个人建议，这本书至少要读3遍以上。
看完这本书，自己可以去找一个项目（可以到开源中国上查找）来测一测，应用一下学的知识，找一找缺陷。在测试这个项目中要体会一下测试的流程，学习如何搭建测试环境。 2、软件测试的艺术(原书第3版) (美)梅耶等 第二本就是这本软件测试的“圣经”，这本书据说是硅谷测试人员必备的书。这本书最值得看的地方就是测试的思想。阅读这本书可以让你有豁然开朗的感觉。 3、计算机软件测试（原书第2版）（美）卡尼尔这本书也是值得一读的，同样也是非常适合初学者阅读的。 4、全程软件测试朱少民 上面的都是外国人写的，来本国产的。
（流程管理）软件测试的流 程
软件测试的流程，包含各阶段会产生什么文档 无论是采用瀑布式仍是其他的产品生命周期模型，软件测试分为如下几个阶段：1、测试需求分析阶段。 测试需求分析阶段主要工作是获得测试项目的测试需求（测试规格）。 输出产物：《可测试性需求说明书》和《测试规格》 2、测试计划阶段。 以测试需求为基础，分析产品的总体测试策略。 输出产物：《产品总体测试策略》 3、测试方案设计阶段。 本阶段主要是以测试规格为基础获得特性测试方案，对于有自动化测试的项目，进行自动化测试的分析，获得测试策略。 输出产物：《产品或者版本总体测试方案》 4、测试用例实现阶段。 本阶段主要是完成各个特性的测试用例的编写和自动化脚本的编写。 输出产物：《产品自动化测试用例》和《手工执行测试用例》 5、测试执行阶段。 本阶段是根据测试策略开展测试执行和回归测试。 输出产品：《产品或版本测试方案》和《缺陷分析方案》 6、评估和关闭阶段。 只对前面的各个阶段的执行情况，完成对测试项目的关闭，同时提供完整的度量数据和项目总结方案。 输出产物：《遗留问题风险分析方案》、《度量分析方案》和《测试关闭方案》软件生命周期的各个阶段如何应用哪些软件测试方法。
画壹个V模型你就明白了：左边为开发过程，对应右边的测试过程，开发自上而下，测试是自下而上 开发过程测试过程 可行性研究验收测试 需求分析系统测试 概要设计集成测试 详细设计单元测试 软件编码阶段 1、需求分析阶段对应生成需求规格说明书，对应测试生成系统测试方案，即为系统测试准备的，该阶段已经完成了单元测试和集成测试，主要是对软件产品的功能和非功能进行测试，几乎不测试代码，所以测试方法以黑盒为主； 2、概要设计阶段对应生成概要设计说明书，对应测试生成集成测试方案，该阶段已完成单元测试，是将各个功能模块组装起来进行的测试，所以也叫组装测试。主要见模块调用是否正常，接口是否可用，数据传输是否正确等，所以用到的测试方法几乎是白盒的方法，如路径覆盖，条件组合覆盖等； 3、详细设计阶段对应生成详细设计说明书，对应测试生成单元测试方案，该阶段是开发人员编码后的第壹个测试阶段，是对开发出来的单独模块进行测试，以确保每壹个功能模块的功能正常，能够构建桩模块和驱动模块来回调用，方法也是以白盒为主。 4、白盒测试的准则是尽可能覆盖程序内部的逻辑结构，黑盒则是尽可能覆盖所有的输入输出接口，包括文档等壹些静态的测试。除常用的测试方法外，仍需补充大范围的随机测试，尽可能达到覆盖率100%。
软件测试流程及规范V1.1
二、各阶段具体流程 1.需求分析阶段 立项 需求调研 编写/修改SRS 提交SRS SRS 审核 审核是否通过 达到要求 提交最终版SRS 审核是否通过 审核通过 依据SRS ，项目整体计划，设计、编写《测试计划》 和《测试设计》《测试计划》根据SRS 定义相应的测试需求报告，即制订测试的标准，以后所有的测试工作都将围绕着测试需求来进行，符合测试需求的应用程序即是合格的，反之即是不合格的；同时，还要适当选择测试内容，合理安排测试人员、测试 时间及测试资源等。 《测试设计》 将测试计划阶段制订的测试需求 分解、细化为若干个可执行的测 试过程，并为每个测试过程选择 适当的测试用例。 进入概要设计阶段评审测试计划 和测试设计优化测试计划、 测试设计1.1步骤说明 1、需求定义基本完成，SRS 编写完成。 2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题，相关人员解答并确认。 3、当评审未通过，直接打回，重新修改SRS ，问题解决后，重新提交评审。
4、当评审通过后，依据SRS，项目整体计划，设计、编写《测试计划》和《测试设计》，具体模板见附件。 5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。 6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。 7、审核通过后，进入下一阶段。 1.2测试通过打回标准 1.3、阶段的输出 输入：最新SRS、项目计划 输出：测试计划、测试设计 2、单元及集成测试流程
太原理工大学软件测试技术 适用专业：软件工程2011级考试日期：2014.1 时间：120 分钟 一、判断题 1. 测试是调试的一个部分（╳） 2. 软件测试的目的是尽可能多的找出软件的缺陷。（√ ） 3. 程序中隐藏错误的概率与其已发现的错误数成正比（√ ） 4. Beta 测试是验收测试的一种。（√ ） 5. 测试人员要坚持原则，缺陷未修复完坚决不予通过。（√ ） 6. 项目立项前测试人员不需要提交任何工件。（╳） 7. 单元测试能发现约80%的软件缺陷。（√ ） 8. 测试的目的是发现软件中的错误。（√ ） 9. 代码评审是检查源代码是否达到模块设计的要求。（√ ） 10. 自底向上集成需要测试员编写驱动程序。（√ ） 11. 测试是证明软件正确的方法。（╳） 12. 负载测试是验证要检验的系统的能力最高能达到什么程度。（√ ） 13. 测试中应该对有效和无效、期望和不期望的输入都要测试。（√ ） 14. 测试人员要坚持原则，缺陷未修复完坚决不予通过。（√ ） 黑盒测试也称为结构测试。（╳） 集成测试计划在需求分析阶段末提交。（╳） 15. 软件测试的目的是尽可能多的找出软件的缺陷。(√) 16. 自底向上集成需要测试员编写驱动程序。(√) 17. 负载测试是验证要检验的系统的能力最高能达到什么程度。(╳) 18. 测试程序仅仅按预期方式运行就行了。(╳) 19. 不存在质量很高但可靠性很差的产品。(╳) 20. 软件测试员可以对产品说明书进行白盒测试。(╳) 21. 静态白盒测试可以找出遗漏之处和问题。(√) 22. 总是首先设计白盒测试用例。(╳) 23. 可以发布具有配置缺陷的软件产品。(√) 24. 所有软件必须进行某种程度的兼容性测试。(√) 25. 所有软件都有一个用户界面，因此必须测试易用性。(╳) 26. 测试组负责软件质量。(╳) 27. 按照测试实施组织划分，可将软件测试分为开发方测试、用户测试和第三方测试。(√) 28. 好的测试员不懈追求完美。(×) 29. 测试程序仅仅按预期方式运行就行了。( ×) 30. 在没有产品说明书和需求文档的条件下可以进行动态黑盒测试。( √) 31. 静态白盒测试可以找出遗漏之处和问题。( √) 32. 测试错误提示信息不属于文档测试范围。( ×)
软件测试过程管理实践 关键词 测试过程模型测试管理理念可持续改进 1 测试过程概述 1．1 软件测试过程概述 软件测试过程是一种抽象的模型，用于定义软件测试的流程和方法。众所周知，开发过程的质量决定了软件的质量，同样的，测试过程的质量将直接影响测试结果的准确性和有效性。软件测试过程和软件开发过程一样，都遵循软件工程原理，遵循管理学原理。 随着测试过程管理的发展，软件测试专家通过实践总结出了很多很好的测试过程模型。这些模型将测试活动进行了抽象，并与开发活动有机的进行了结合，是测试过程管理的重要参考依据。 1．2 软件测试过程模型介绍 Ｖ模型 V模型最早是由Paul Rook在２０世纪８０年代后期提出的，旨在改进软件开发的效率和效果。Ｖ模型反映出了测试活动与分析设计活动的关系。在图1-1中，从左到右描述了基本的开发过程和测试行为，非常明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。 图1-1 软件测试V模型 V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。 但V模型存在一定的局限性，它仅仅把测试作为在编码之后的一个阶段，是针对程序进行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。 Ｗ模型 W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。如图1-2所示，W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早
软件测试方法 β测试_Beta测试 β测试，英文是Beta testing。又称Beta测试，用户验收测试（UAT）。 β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。 当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。 α测试_Alpha测试 α测试，英文是Alpha testing。又称Alpha测试. Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。 在系统开发接近完成时对应用系统的测试;测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。 可移植性测试 可移植性测试，英文是Portability testing。又称兼容性测试。 可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。 用户界面测试-UI测试 用户界面测试，英文是User interface testing。又称UI测试。 用户界面，英文是User interface。是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。 用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 用户界面测试用户分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息(Menu 和Help content)等方面的测试。比如，测试Microsoft Excel中插入
第1章指导软件测试的故障模型 软件测试的目的 好的测试员具有一种直觉，这种直觉引导他们彻底全面地思考测试场景。使测试员产生这种直觉的技术术语就是故障模型，因为故障模型提供了一个模型或框架，用来讨论代码中的故障是如何以及为什么能在软件执行时引起软件失效。对于测试员来说，重要的是能够构造出一个准确的故障模型，并在测试过程中使用该模型，确保能检查出隐错最可能隐藏的地方。 人们处于不同的动机去进行软件测试，其中绝大多数动机都可用一个名称来描述。想要通过测试确定所在机构是否应该接受某个产品，这种测试成为符合型测试；想要通过测试确定某个产品是否易于使用，这种测试成为可用性测试。这样列举下去，还会包括性能测试，可靠性测试，健壮性测试等等。 诸多种类的测试具有一些共同特性： 每种测试都需要测试员按照产品行为描述来实施。产品行为描述可以是书面的规格说明书、需求文档、产品文件或用户手册。 每种测试都需要产品运行于真实或模拟环境下。 每种测试都要求以系统方法展示产品功能性，说明测试结果是肯定的还是否定的，以及是否课判断其中的区别。真正区分失效测试和成功测试的关键在于：必须知道在寻找什么，并能说出何时找到了。 每种测试都包括上述特性，主要差别在于其目的和一些细节处理上的差别。总之，抛开这些细节和目的不谈，软件测试需要以系统和智能的方式运行和展示产品的功能。 软件测试应具有智能性，有关于应用程序如何运行的加精盐，规程和知识及可能会出现的故障知道测试员实施测试。 优秀的测试员不能依靠运气，而是必须为所测试的软件设定清晰、明确、可实现的目标以及所有错误纠正后的下一个测试目标。有效测试的特点就是设定这样的目标，并进行系统的开发，直至目标达到。 理解软件行为 开发具有影响力的软件是相当困难的，一旦投入使用环境，软件常常会失效。开发人员必须找出能减少编程出错倾向的方法，测试员页必须把重点放在寻找测试方法上，通过测试说明软件能无效的完成它应该完成的功能。让测试员深感遗憾的是，测试时有太多的输入，输入变量、输入组合以及软件状态。还有一些功能必须保持未测状态。测试的难题是选择哪些要进行测试以及哪些不需要测试。 要有效的完成这些关键的决策过程，测试员需要理解软件运行时正在做什么，哪些会引起软件失效。我所知道的最好的测试员已经具有这种直觉，知道什么能使软件失效，这种直觉引导他们彻底全面的思考测试场景、换句话说，他们知道隐错一般隐藏在什么地方，如何有效的找出这些隐错。 使测试员产生这种直觉的技术术语就是故障模型，因为故障模型提供了一个模型或框架，用来讨论代码中的故障是如何以及为什么能在软件执行时引起软件失效。对测试员来说，重要的是能够构造出准确的故障模型，并在测试过程中使用该模型，确保能检查出隐错最可能隐藏的地方。也就是说，故障模型可以用来选择测试，该测试最可能暴露嵌入的软件故障。
一、判断题 1.测试是调试的一个部分（X ） 2.软件测试的目的是尽可能多的找出软件的缺陷。（2 ） 3.程序中隐藏错误的概率与其已发现的错误数成正比（2 ） 4.Beta 测试是验收测试的一种。（2 ） 5.测试人员要坚持原则，缺陷未修复完坚决不予通过。（2 ） 6.项目立项前测试人员不需要提交任何工件。（ X ） 7.单元测试能发现约80%的软件缺陷。（2） 8.测试的目的是发现软件中的错误。（2） 9.代码评审是检查源代码是否达到模块设计的要求。（2 ） 10.自底向上集成需要测试员编写驱动程序。（ 2） 11.测试是证明软件正确的方法。（X ） 12.负载测试是验证要检验的系统的能力最高能达到什么程度。（2 ） 13.测试中应该对有效和无效、期望和不期望的输入都要测试。（2 ）验收测试是由最终用户来实施的。（2 ） 14.测试人员要坚持原则，缺陷未修复完坚决不予通过。（2 ）黑盒测试也称为结构测试。（X ）集成测试计划在需求分析阶段末提交。（X ） 15.软件测试的目的是尽可能多的找出软件的缺陷。（2 ） 16.自底向上集成需要测试员编写驱动程序。 （2 ） 17.负载测试是验证要检验的系统的能力最高 能达到什么程度。（X） 18.测试程序仅仅按预期方式运行就行了。（X） 19.不存在质量很高但可靠性很差的产品。（X） 20.软件测试员可以对产品说明书进行白盒测试。（X ） 21.静态白盒测试可以找出遗漏之处和问题。 22.总是首先设计白盒测试用例。（X ） 23.可以发布具有配置缺陷的软件产品。 （2） 24.所有软件必须进行某种程度的兼容性测试。（2 ） 25.所有软件都有一个用户界面，因此必须测试易用性。（X） 26.测试组负责软件质量。（X ） 27.按照测试实施组织划分，可将软件测试分为开发方测试、用户测试和第三方测试。（2） 28.好的测试员不懈追求完美。（X ） 29.测试程序仅仅按预期方式运行就行了。 （X ） 30.在没有产品说明书和需求文档的条件下可以进行动态黑盒测试。（2 ） 31.静态白盒测试可以找出遗漏之处和问题。（2 ） 32.测试错误提示信息不属于文档测试范围。（X ） 33.代码评审是检查源代码是否达到模块设计的要求。（2 ） 34.总是首先设计黑盒测试用例。（2 ） 35.软件测试是有风险的行为，并非所有的软 件缺陷都能够被修复。（V ） 36.软件质量保证和软件测试是同一层次的概念。（x ） 37.程序员兼任测试员可以提高工作效率。 （x ） 38.在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。（V ） 39.传统测试是在开发的后期才介入，现在测试活动已经扩展到了整个生命周期。（V ）40.传统测试以发现错误为目的，现在测试已 经扩展到了错误预防的范畴。V 41.软件测试的生命周期包括测试计划、测试设计、测试执行、缺陷跟踪、测试评估。（V ）42.软件生存周期是从软件开始开发到开发结束的整个时期。（x ） 43.测试用例的数目越多，测试的效果越好。（x ） 44.只要能够达到100％的逻辑覆盖率，就可以保证程序的正确性。（x ） （2）
软件测试过程管理-考题-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
一、软件测试过程管理 1. 关于软件测试模型，描述正确的是（C） A. V模型测试的对象就是程序本身，测试与开发可以同一阶段进行 B. W模型测试的对象是程序，需求、设计等，可以支持迭代的开发模型 C. H模型软件测试过程活动完全独立，贯穿产品整个生命周期,与其他流程并发地进行。 D. X模型是事先计划再进行测试。 2. 制定测试计划的步骤：（D） A. 确定项目管理机制预计测试工作量测试计划评审 B. 确定测试范围确定测试策略确定测试标准、预计测试工作量 C. 确定测试构架确定项目管理机制预计测试工作量测试计划评审 D. 确定测试范围确定测试策略确定测试标准确定测试构架确定项目管理机制预计测试工作量测试计划评审 3、编写测试计划的目的是：（ABC）(多选) A、使测试工作顺利进行 B、使项目参与人员沟通更舒畅 C、使测试工作更加系统化 D、软件工程以及软件过程的需要 E、软件过程规范化的要求 F、控制软件质量 4、某公司采用的软件开发过程通过了CMM2认证，表明该公司（C）。 A. 开发项目成效不稳定，管理混乱 B. 对软件过程和产品质量建立了定量的质量目标 C. 建立了基本的项目级管理制度和规程，可对项目的成本、进度进行跟踪和控制 D. 可集中精力采用新技术新方法，优化软件过程 5. (B )可以作为软件测试结束的标志。 A．使用了特定的测试用例B．错误强度曲线下降到预定的水平C．查出了预定数目的错误D．按照测试计划中所规定的时间进行了测试 6．软件测试计划的内容应包括（D）。 A. 测试目的、背景 B. 被测软件的功能、输入和输出 C. 测试内容和评价标准 D. 以上全部 7．下面不属于软件测试过程中的输入类的是(B)。 A. 软件配置 B. 测试用例 C. 测试配置 D. 测试工具 8. 下列不属于测试需求分析阶段的输入的是（A）。 A. 软件测试的方法与规范 B. 软件需求规格说明 C. 软件测试计划 D.软件设计说明
测试环境管理规范
修改履历 修改编号版本修改条款及内容修改日期 1 V1.0 初稿
目录 1.概述 (5) 1.1目的 (5) 1.2适用范围 (5) 2.环境使用要求和原则 (5) 2.1环境使用要求 (5) 2.2环境使用原则 (5) 3.硬件环境 (6) 3.1全流程测试环境申请 (6) 3.1.1申请流程图 (6) 3.1.2申请流程说明： (6) 3.2待测系统环境申请 (7) 3.2.1申请流程图 (7) 3.2.2申请流程说明： (7) 3.3测试用机申请 (8) 3.3.1申请流程图 (8) 3.3.2申请流程说明： (8) 3.4硬件环境变更 (9) 3.4.1全流程测试环境变更流程图 (9) 3.4.2全流程测试环境变更流程说明： (9) 3.5硬件环境释放 (10) 3.5.1释放流程图 (10) 3.5.2释放流程说明 (10) 4.环境权限 (11) 4.1权限说明 (11) 4.1.1查询帐户 (11) 4.1.2监控帐户 (11) 4.1.3应用帐户 (11) 4.1.4备用帐户 (11) 4.1.5特殊帐户 (11) 4.2权限申请流程 (11) 4.2.1查询帐户申请流程 (11) 4.2.2监控帐户申请流程 (11)
4.2.3应用帐户申请流程 (12) 4.2.4备用帐户申请流程 (12) 4.2.5特殊帐户申请流程 (12) 4.3应用系统 (12) 4.3.1应用版本变更 (12) 应用版本部署 (12) 应用版本变更 (12) 4.3.2测试数据 (12) 测试数据预埋 (13) 测试数据变更 (13) 5.系统参数变更 (13) 5.1工作时段参数变更 (14) 5.1.1变更流程图： (14) 5.1.2变更流程说明： (14) 5.2非工作时段参数变更 (15) 5.2.1变更流程图： (15) 5.2.2变更流程说明 (15) 6.系统备份 (16) 6.1不定期备份 (16) 6.1.1备份说明 (16) 6.1.2备份流程 (16) 6.2特需备份 (16) 6.2.1备份说明 (16) 6.2.2备份流程 (16)
软件测试的定义及常用软件测试方法介绍 一、软件测试的定义 1.定义：使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满 足规定的需求或弄清预期结果与实际结果之间的差别。 2.内容：软件测试主要工作内容是验证(verification)和确认(validation )，下面分别给 出其概念： 验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件以正确的方式来做了这个事件(Do it right) 1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程 2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程 3.评市、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否 和规定的需求相一致进行判断和提出报告。 确认(validation)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。(Do the right thing) 1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性 2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。 软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。 二、软件测试常用方法 1. 从是否关心软件内部结构和具体实现的角度划分： a. 黑盒测试 黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。 黑盒测试是以用户的角度，从输入数据和输出数据的对应关系出发进行测试的，很明显，如果本身设计有问题或者说明规格有错误，用黑盒测试是发现不了的。
软件测试说明
目录 1范围 (1) 1.1标识................................................................................................................................................... 错误!未定义书签。 1.2系统概述 (1) 1.3文档概述 (1) 2引用文档 (1) 3测试准备 (1) 3.1功能性测试 (1) 3.1.1 硬件准备 (1) 3.1.2 软件准备 (1) 3.1.3 其它测试前准备................................................................................................................. 错误!未定义书签。4测试说明 (1) 4.1功能测试 (1) 4.2性能测试 (5) 4.3接口测试 ............................................................................................................................................ 错误!未定义书签。5需求的可追踪性 ............................................................................................................................... 错误!未定义书签。6注解.......................................................................................................................................................... 错误!未定义书签。附录A........................................................................................................................................................... 错误!未定义书签。 整理范本
[模拟] 软件测试过程和管理(二) 选择题 第1题： 下列哪个不是测试环境的组成要素______。 A.软、硬件 B.技术文档 C.测试工具 D.网络环境 参考答案：B 第2题： 以下活动中，不属于测试计划的内容是______。 A.为测试各项活动制定一个实现可行的综合的计划 B.确定测试过程中每个测试阶段的测试完成标准 C.识别测试活动中各种风险，并给出风险应对措施 D.分析测试需求，并制定测试方案 参考答案：D 第3题： 下列有关测试过程抽象模型的描述中正确的是______。 A.V模型指出，软件测试要尽早准备，尽早执行，只要某个测试达到了准备就绪点，测试执行活动就可开展 B.W模型强调，测试伴随着整个软件开发周期同步进行，而且测试的对象不仅仅是程序，需求、设计也同样需要测试 C.H模型指出，单元测试和集成测试应检测程序的执行是否满足软件设计的要求 D.X模型提出针对完整的程序进行集成的编码和测试 参考答案：B 第4题： 下列哪个选项不属于测试计划要达到的目标______。 A.为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的
对象、范围、方法、进度和预期结果 B.为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容 C.为测试执行活动设计测试方案，编制测试用例 D.确定测试需要的时间和资源，以保证其可获得性和有效性 参考答案：C 第5题： 下列有关软件测试设计的说法中，正确的是______。 A.测试方案应考虑是否可行、是否有效和是否能够达到预期的测试目标 B.基于判定表的测试用例设计方法是白盒测试用例设计方法 C.测试方案设计中可以忽略软件系统的实际使用环境 D.测试开发不是测试用例设计的工作内容 参考答案：A 第6题： 下列有关测试项目结束与定稿测试报告的说法中，正确的是______。 A.测试执行完成，测试人员向测试负责人提交测试报告后，测试项目就可以结束了 B.对当前软件产品存在的缺陷进行逐个分析，认定剩余缺陷对产品质量无重大影响后，即可定稿测试报告 C.审查测试全过程，检查测试计划和内容无遗漏后，即可定稿测试报告 D.当所有测试计划内容完成，测试覆盖率达到要求及产品质量达到定义的标准，即可定稿测试报告 参考答案：D 第7题： 下列哪项工作与软件缺陷管理和追踪无关______。 A.对缺陷应该包含的信息条目、状态分类等进行完善设计 B.通过软件系统自动发送通知给相关开发和测试人员，使缺陷得到及时处理 C.对测试用例的执行结果进行记录和追踪 D.通过一些历史曲线和统计曲线来分析和预测未来的缺陷发展情况 参考答案：C
软件开发与测试配合 工作流程 XXX软件股份有限公司质量部 目录 1．简介 本流程文件旨在规定一个简单的可使开发人员和测试人员在软件开发的编码阶段相互配合工作的工作流程，其中包括测试与开发的配合、送测单和BUG单的填写、测试循环的结束等部分。开发阶段与测试循环的关系、测试模块的组合与测试原则、BUG的分类评级原则等也在本流程文件中有相关的描述。 鉴于公司的技术要求，目前质量部的测试人员不仅要完成黑盒测试工作，而且还要进行白盒测试中的“代码走查”工作。其它的白盒测试工作，目前还不在测试人员的工作职责之内。 由于公司已经为质量管理部开发完成“辅助测试系统1.0”，因此本测试流程的制定就建立在辅助测试系统之上，如果辅助测试系统有了新的版本，质量部将根据其变化适当调整测试流程。 2．适用范围 本流程文件适用于公司开发软件并需要测试服务的任何软件开发项目组、软件开发人员，以及任何测试人员。
当项目组在辅助测试系统中注册以后，公司领导可以使用本系统查询了解所有在本系统中注册的项目的测试信息，项目的质量管理员可以使用本系统查询了解项目的当前测试进展情况。程序员和测试员都可以使用本系统查询到自己产生的送测单和BUG单。 3．术语、名词定义 3.1 送测软件 送测软件包括一切软件执行必须的文件、数据、数据库配置等。开发人员必须提供所有的详细的资料以保证测试人员可以像客户一样的运行被测软件。 3.2 开发文档 开发人员提供给测试人员的开发文档至少包括以下几种：用户需求，概要设计，详细设计，用户手册等。开发人员应当在开发每阶段完成后三天内就向测试人员传送本阶段完成的开发文档，以利于测试人员的工作。 3.3 测试文档 测试文档包括测试计划、测试用例说明、BUG报告及分析、测试总结，以及测试工作全部完成后的测试报告等。测试文档由测试人员编写并维护，也属于开发文档的一部分。
一个常见的软件测试面试题 一个常见的软件测试面试题 考官从办公室（面试现场）随意选取一个简单物品，假定是一个喝水的带广告图案的花纸杯，让应聘人对它设计出尽可能多的测试用例。 测试项目：杯子 需求测试:查看杯子使用说明书 界面测试:查看杯子外观 功能度：用水杯装水看漏不漏；水能不能被喝到 安全性：杯子有没有毒或细菌 可*性：杯子从不同高度落下的损坏程度 可移植性：杯子再不同的地方、温度等环境下是否都可以正常使用 兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等 易用性：杯子是否烫手、是否有防滑措施、是否方便饮用 用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述 疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等 压力测试：用根针并在针上面不断加重量，看压强多大时会穿透 跌落测试:？？杯子加包装(有填充物)，在多高的情况摔下不破损 震动测试: 杯子加包装(有填充物)，六面震动，检查产品是否能应对恶劣的铁路\公路\航空运输 测试数据： 测试数据具体编写此处略（最讨厌写测试数据了）。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法 期望输出：
该期望输出需查阅国标、行标以及使用用户的需求 说明书测试: 检查说明书书写准确性 给大家提三个产品:1.手机 2.电饭锅 3.电梯 有兴趣的同学可以把答案写出来 一个常见的软件测试面试题 问题集 1.软件测试分哪两种方法?分别适合什么情况? 2.一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。 3.软件测试的类型有那些?分别比较这些不同的测试类型的区别与联系。 4.测试用例通常包括那些内容?着重阐述编制测试用例的具体做法 5.在分别测试winform的C/S结构与测试WEB结构的软件是，应该采取什么样的方法分别测试?他们存在什么样的区别与联系? 6.在测试winform的C/S结构软件时，发现这个软件的运行速度很慢，您会认为是什么原因?您会采取哪些方法去检查这个原因? 7.描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程8.如果您是测试组长，您会采取什么样的方式管理团队?在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果?维持测试人员同开发团队中其他成员良好的人际关系的关键是什么? 问题解答： 1.软件测试分哪两种方法?分别适合什么情况? 软件测试方法一般分为两种：白盒测试与黑盒测试。白盒测试又称为结构测试、逻辑驱动测试或基于程序本身的测试，它着重于程序的内部结构及算法，通常不关心功能与性能指标;黑盒测试又被称为功能测试、数据驱动测试或基于规格说明的测试，它实际上是站在最终用户的立场，检验输入输出信息及系统性能指标是否符合规格说明书中有关功能需求及性能需求的规定。 2.一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。 计划阶段、设计阶段、白盒单元、白盒集成、黑盒单元、黑盒集成、系统测试、回归测