本博客引自：https://blog.csdn.net/wuxiaobingandbob/article/details/8598471
从事软件测试这么久，知道流程，但是一直没有形成理论体系，今天上午空闲时，浏览到作者的博客，看到此文，深感作者的基础之扎实。
引用一下他的这篇文章，一方面是传播让更多的人看到，学习一下。另一方面，方便自己以后回顾阅读。
在此，感谢作者。
1. 引言
1.1 目标
软件产品在发布前，如果能够经过全面的测试过程，可以有效控制软件缺陷最后遗留给用户，从而减少软件质量事故发生的概率，减少返工修复成本，增加用户对产品的信赖程度，提高产品在市场上的竞争力，这已经是不争的事实。因此软件测试过程应该与整个软件开发过程是平行进行的，测试计划应该在需求分析阶段就已经开始制定了，随后的工作则会伴随着软件开发的过程逐步展开。
本文档编写的目的是希望能建立起全程软件测试理念，形式测试体系贯穿整个软件生命周期，软件测试是发现软件缺陷的主要手段，但不是唯一的手段，软件的缺陷是伴随需求就已经诞生，所以，软件测试应该从需求阶段就开始介入，通过多种方法，多个手段来预防缺陷和发现缺陷。学者Hetzel认为“软件测试是对软件建立信心的一种积极行为”，想一想，如果软件发布前，没有做测试或测试不充分，客户凭啥相信我们的软件已经达到他期望的需求。所以，在软件开发过程中，测试工作很有必要。
1.2 背景
目前的测试主要还是依赖于开发人员自测或测试人员非流程化测试，这是有一些不妥或需要改进的地方:第一是开发人员和专职测试人员可能关注点不同，思考问题的侧重点不同，导致开发人员测试出结果不能覆盖全面；第二开发人员更多的喜欢并乐于研究一些代码上的东西，让开发人员频繁的做测试会产生抵触情绪，通常会没有耐心去深入测试下去，或许可能发现不了深入的系统问题；另外测试人员如果没有建立起测试流程化理念，会导致测试的随意性和盲目性，对软件的质量也无法做充分的肯定和把控，缺乏流程化测试，也不利于技术的积累和传递。
1.3 术语和定义
黑盒测试 基于软件需求，而不是基于软件内部设计和程序实现的测试方式。
白盒测试 基于软件内部设计和程序实现的测试方式，重点关注程序代码逻辑方面。
灰盒测试 灰盒测试是介于白盒测试与黑盒测试之间的一种测试模模式，重点关注模块接口。
单元测试 主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。
集成测试 将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机－服务器程序等等。
系统测试 测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。功能性需求可分系统测试又可为功能测试、性能测试、易用性测试等。一般由独立测试人员执行，通常采用黑盒测试方式或灰盒子测试方法。
功能测试 测试软件的功能是否符合功能性需求，测试是据软件需求规格说明书。
性能测试 测试软件在各种状况下的性能，如在正常或最大负载下的状况。
易用性测试 测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。
冒烟测试 是指在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性,冒烟测试通常由测试人员或开发人员完成。
回归测试 指错误被修正后或软件在功能、环境发生变化后进行的重新测试，回归测试的重点是保证修改后的bug都得以解决，回归测试的困难在于不好评估或判断修改的bug是否会引起其它问题发生，从而来确定哪些内容应当被重新测试。
缺陷（bug） 软件工程中明确规定和定义软件缺陷是指：1.软件没有达到产品说明书表明的功能；2.软件出现了产品说明书中不一致的表现；3.软件功能超出产品说明书的范围；4.软件没有达到用户期望的目标(虽然产品说明书中没有要求)；5.测试员或用户认为软件的易用性差。满足一项以上就可定义为软件存在缺陷。
2. 测试体系完善
2.1 项目启动
1. 项目情况
a. 由公司的市场部或产品部下达项目开发任务后，确定了项目情况后，项目的主要角色PM对项目应该有清楚的认识，应该尽快制定并拿出《项目计划书.mpp》，项目计划书中应该明确指定项目的时间进度表，并对每一个里程碑标注，对项目中涉及的开发任务、测试任务应该有对应的所属人负责。
b. 项目计划书准备好后，项目经理PM应该以邮件方式通知项目所属中的每一个人和关注项目的直接领导等人员，召开项目kick off启动会议，会议上应该重点介绍项目需求来源、项目周期、重点阶段里程碑、人员分工等情况，并重点对任务所属人员做点名回应，保证已经知悉并愿意承担其分配的任务。
c. 项目的计划是一个动态的过程，会随着需求的变化和人员的调整有可能会出现变动，项目经理在制定项目计划时应该给一定的时间，保持项目平稳进行。
2. 测试职责
a. 良好的开端对项目的成败有重要影响，要做好测试项目的工作，就不能忽视项目启动的一些情况，测试人员应该首选关注以下情况：
b. 弄清项目背景，抓住项目的要素。
c. 深刻认识项目需求，评估以前是否有一定知识储备，弄清项目开发团队成员，便于后期的沟通交流。
d. 分析和弄清测试工作量是否可以保证项目的高质量发布，在项目启动会议上应该和项目负责人做充分彻底的交流。
e. 项目启动后，目前的测试资源是否能满足测试需要，如果不满足，需求在项目启动后，多长时间能到位。
3. 职能流程
2.2 测试计划
1. 测试人员
a. 测试计划是一个过程，而不仅仅是一个文档，制定测试计划的目的有利于测试范围、测试时间和测试资源的调配和充分利用。测试计划是整个项目开发计划的一个组成部分，是对项目计划的分解和提炼。
b. 测试计划中应该明确规定项目在整个开发周期内各个阶段的测试任务，并确定测试任务的所属测试人员，在整个测试项目，除非特殊情况，一般规定测试人员应该做到专职专用，保证测试的连贯性和高效率。
c. 测试计划中测试测试风险应该加以标注和说明，比如人员的变动、测试人员对项目的熟悉程度、需求的频繁变动等等不可控因素加以说明。
d. 测试计划中应该对阶段测试任务有明确的工作量，一方面是对个项目的工作量的分解，同时能起到对测试人员在测试过程中做到自我管理的作用。
2. 职能流程
2.3 需求分析
1. 开发人员
a. 需求编写是将软件产品需求以结构化、共享的可管理的形式编写成文档的过程，需求分析和编写需求文档的过程关乎后续诸多操作，这是至关重要的一个过程，有道是“魔刀不误砍柴工”，由此引申到软件工程上，需求阶段应该花一些力气和时间，为后面的编码、测试打下良好的基础。
b. 需求的分层主要分为业务需求、用户需求、功能需求，开发人员不光要重点关注功能需求的实现，同时也要关注下业务需求和用户需求。
c. 需求的获得是多方面的，不能局限于项目合同和行业规范，也应该关注用户或潜在用户的诉求感受、用户使用产品情景分析等内容，确保需求的来源多方面。
d. 开发人员应在需求分析完成后，完成《概要设计文档》、《详细设计文档》文档，这作为整个项目开发阶段的重要参考文档，需求的确立是一个渐进和不断迭代的过程，不可控因素较多，所以，在需求的设计上，应有足够的可调控余地。
2. 测试人员
a. 在一个全新的项目中，对需求的了解程度通常要求是测试人员应该高于开发人员，这样，我们测试人员才能在测试过程中对业务方面不会有漏洞和瑕疵，以基础知识为内力，以测试方法和测试理论为核心力，以业务知识为动力，从而出色的完成项目整体测试过程。
b. 在开发人员编写需求文档的时间，测试人员如果没有其他项目的测试任务时，应该也紧跟项目，学习涉及的行业规范、需求来源文档。
c. 测试人员在需求分析后，应该配合开发人员完成《原型设计书》，一方面可以通过编写文档的方式更直接熟悉项目，同时也为后续测试文档的设计、测试的执行打下良好的基础。
3. 职能流程
2.4 测试设计
1. 开发人员
a. 测试设计是环境是整个测试执行的重要环节，良好的测试设计可以看做是基石，只有基石牢固才有可能使测试任务和测试质量高效而优质，有作为开发人员也应该配合和关注测试设计这一环节，可能不是义务，但至少应该做到协助。
b. 有可能测试人员在使用自动化测试工具过程中用到脚本，而测试人员在编写脚本的时候，可以请教开发人员，开发人员应该在不影响自己工作前提下，可以积极协助解决，毕竟在代码的编写和熟练程度上，开发人员应该优于测试测试人员，这是不争的事实。
c. 有一些项目在测试过程中，可能会用到第三方平台，而第三方可能需要写模拟程序来协助测试我们的项目，这个模拟程度就需要开发人员来提供，目的是更好的配合完成我们项目的测试工作。
d. 在测试设计过程中，可能有需求的变动或功能的增删，作为开发人员应该有义务将变更或增加的地方update到设计文档中，并告知测试人员按新的设计文档来编写测试文档。
2. 测试人员
a. 测试设计阶段是测试人员大显身手的阶段，应该拿出自己的所有能力，确保认真和高度重视，测试设计相当于承上启下的阶段，既是检验我们对整体项目需求的熟悉程度，又是考验我们对整个测试项目的计划把握和测试方法应用的检验，所以，有必要投入100%的精力去对待。
b. 测试设计阶段应该考虑的文档有《测试方案》、《测试用例》、测试工具等，其中测试用例是整个测试设计的重中之重，测试用例应该充分考虑需求的覆盖程度和用例的设计方法，采用多种设计方法、多种测试组合类型做到全覆盖项目需求。
c. 测试文档编写后，应该通知相关人员做评审，只有评审通过的测试文档才能作为测试执行的依据，评审文档应提前1~2天发送，给评审成员足够的时候阅读，并反馈提出的问题，在评审过程中，对问题做记录并更新测试文档，一般测试文档最多评审两次，所以，在编写过程中，测试人员应该自我严格把控文档质量，避免评审时因一些琐碎问题浪费大家的时间。
d. 测试方案和测试用例的关系是相互联系而又独立存在，在设计时应该考虑，测试方案中应该明确指定要测试项目的功能点需求，可以不考虑具体测试过程的测试方法，看做作是仅仅对测试内容功能按层次有条理的罗列，而测试用例则是对测试方案的延伸和扩展，测试用例中应该对每一个功能测试点做扩容和放大，保证每个功能从不同测试角度来测试，每一条测试用例只有一个输入和输出，意义完全明确，不带任意性，保证测试人员执行测试用例的可测试性，没有通过测试用例的功能就意味着需要提交bug，每一个bug和测试用例的ID也是存在唯一对应关系的。
3. 职能流程
2.5 测试执行
1. 开发人员
a. 测试人员在测试过程中，对测试出来不能确定的问题可能会和开发人员做进一步确认，作为开发人员应该和测试人员积极沟通配合。
b. 开发人员对给分配解决的bug，在解决bug后，应该在bug中描述问题出现的原因，一方面有利用自己的技术水平体现，另外也是在项目最后结项的时候统计bug，作为度量和改进软件开发体系，优化流程标准的重要参考依据。
c. 开发人员在测试执行过程中对分配给自己的bug，自认为不是bug的问题，可以告知项目经理，由项目经理再和测试沟通做状态转换，避免对一个bug双方用推拉的方式来处理，或直接将bug置为No bug，应该通过良好的方式处理和对待测试人员发现的问题，它既是测试人员的工作成果，更重要的是一定保证这个发现的问题不能放任和丢弃。
2. 测试人员
a. 测试人员在测试之前首先应该独立完成测试环境的部署，部署需要依据《部署文档》，有的时候部署文档时由测试人员在部署好测试环境后再来完成，不管如何，需要保证测试环境部署后的正确和干净。
b. 测试人员在测试过程中，应该主要以《测试用例》为规范和指导思想，测试过程中对出现问题的问题应该第一时间提交到bug系统中，并分配给相应的开发人员。
c. 测试过程中，对发现的bug应该能复现，在提交bug时，在复现步骤中能描述清楚，便于开发人员在解决问题的时候参考，对于偶然的bug或时出现概率很小的bug应该在提交bug的时候附上图片、日志等信息，便于开发人员更好的定位问题和解决问题。
d. 测试人员在测试完每一轮时，都应该对测试版本和环境做保存，在下一轮版本测试时在版本的配置文件，安装部署都应该是从版本树上全新取到的，避免和禁止用上一个版本的测试环境仅替换和更新修改的包，这样从测试的意义来说，并不是一次全新意义的测试过程。
e. 测试人员在测试过程中应该积极调动主动能动性，在发现问题时，不但可以发现，还能深刻思考和学习问题出现的本质，学习开发人员解决问题的思路，想想，这个问题为啥会出现，到底问题由何引起的呢？这一些的问题思考，不但能协助开发人员快速解决问题提供帮助，同时对自己的技能提高有很大的帮助。
f. 测试过程中测试人员不但能通过测试用例发现问题，同时，利用一定时间，做一些ad-hoc（随机的测试）、易用性的测试，这些问题主观色彩比较大，可以不记录为bug，可以当一些个人建议提交给项目经理，供参看和讨论。
3. 职能流程
2.6 测试记录
1. 测试人员
a. 测试记录主要包括记录测试结果和测试过程，测试结果是指针对测试发现的bug能详实地记录在bug缺陷库中，并且对缺陷的描述能做到言语简单明了，当包含的必要复现信息要全；测试过程是指在测试过程中发现的bug复现概率很小，或者有的无法复现等信息都要有测试记录。另一个方面是在测试过程中可能发现测试用例有点地方写的不全删或有的bug并不能通过测试用例来发现，需要进一步细化和完善测试用例，这也需要做记录，目的是在更好的把测试用例做到全覆盖。
b. 测试记录还应该记录在测试过程中，这些测试可能不作为版本发布的需要，比如测试人员的一些想法、测试过程中遇到的困惑、测试和开发之间对问题处理的想法、对项目功能的体验想法等等，这些都可以作为一个自我心得体会记录下来，在测试完成后，作为一种共享，大家一起来分享和讨论，这样对自己是一种成长，推动组织在流程的建设中可以更好的完善。
2. 职能流程
2.7 缺陷跟踪
1. 开发人员
a. bug的整个生命周期离不开开发人员的参于，当项目经理分配给属于自己的bug时，首先应该快速响应，并将bug状态置为Open，当发现分配的bug不属于自己来解决时，也不要有其它想法，直接将该问题Forward回去并注明原因即可，保持和项目经理口头沟通。
b. 对bug 解决后，首先应该自己测试，保证测试没有问题后再提交到版本上，避免未经自测就直接提交，导致解决bug的时间周期延长。
c. 开发人员在解决bug的过程中，有可能出现按描述的步骤根本复现不了该bug，这种情况完全有可能，因为bug的出现不但是操作的问题，还涉及测试环境、输入数据、数据的累积等原因，所以，遇到不能复现的问题，应该和测试人员积极沟通，不要将bug直接就No bug。
2. 测试人员
a. 测试人员在提交bug后，应该对该bug全程跟踪，bug从提交到Closed整个生命周期的各个阶段,测试人员一定要实事求是、严谨细致的认真对待。
b. 测试人员在提交bug中，应该明确标明bug的严重级别程度、优先解决顺序、测试步骤、预期结果、实际结果、项目版本、bug出现的概率等重要属性，便于bug的解决优先级和项目的总结统计。
c. 在验证bug时，发现bug已经解决，应该在不bugd的note中注明bug解决的当前版本，如果验证问题还存在，需要将bug状态重新置为reopen，并和解决bug的开发人员做主动积极沟通。
d. 在测试中，可能会发现有些bug出现的概率很小，复现的机会也非常小，但又确实存在，对这类bug应该先记录整理下来，并告知项目负责人，申请做长时间观察测试时间，因为这类bug可以需要长时间的测试才能复现，一旦复现应该将测试数据、日志、抓图等信息都保存下来。
3. 职能流程
2.8 测试结束
1. 测试人员
a. 测试结束后，首先需要将最后测试的版本发送到FTP服务器上，同时告诉项目经理，将版本控制工具上的版本流做lock操作，将版本流冻结，禁止操作人员随意提交代码到项目上。
b. 测试完成后，需要将测试的情况整理成报告，发送给参与项目的全部人员和相关领导，报告中应该重点体现测试的信息，比如测试轮数、发现的bug总数量、遗留bug的处理意见、性能指标等必要参考信息。
c. 测试结束后，对测试文档也要做整理并归档提交到服务器做备份保存，比如在测试过程中发现测试用例的不完善，测试过程中需求的微调等都需要同步到测试文档中有体现。
d. 测试结束是代表一个阶段的结束，应该给参与测试人员几天自由支配的时间，调节下状态。
2. 职能流程
2.9 测试总结
1. 测试人员
a. 一个项目测试完成后，应该就近抽半天时间大家一起座下来做个测试总结，总结时间不能和项目结束时间相差太久，因为刚测试完项目大家一定有很多想法，时间一长，很可能就会遗忘，而且时间长了，大家可能又有新的测试任务，所以，测试总结应该尽快完成。
b. 没有总结，就不能认识自我，就不知成功在哪里，失败和不足在哪里。只有经过思考，才能提高的更快，进步的更大。所以说，总结很有必要，在总结上，大家可以各抒己见，发表自己在测试中的困惑和困难，同时也应该分享自己在测试项目中一些经验。
c. 总结过程中，可以适当邀请项目负责人和开发人员代表，听听他们对我们测试的一些建议和看法，这样也有利于以后更好的配合工作，测试其实就是一种服务，测试应该怀着这样的心态去测试。
d. 总结完成后，应该形成文档化并保存下来，作为测试体系改进和完善的重要内容，同时也可以为部门、公司的流程体系建设完善提供一些参考信息。
2. 职能流程
3. 测试管理规划
3.1 测试人员
a. 测试任务：根据测试计划确定当前项目的测试人员，对测试人员做充分的沟通了解，涉及和所负责的有关项目评审会议都应参加，对制定的测试计划能确保测试人员知悉并能保持跟进状态。对重点项目和紧急项目，要求测试人员在经验和人员数量有适当倾斜，保证按时、高质量完成任务。
b. 测试沟通：测试中作为测试人员应该做到积极和有效的沟通，对不懂和不明白的问题，提倡自己通过多种方式尝试解决至少3次，如果还不能解决，再请教其它同事，如果还未解决，可以继续请求技术总监、总工等等，相信问题一定能够解决。在测试过程中，对reject的 bug，应该和开发就问题讨论，始终坚持“就是论事”原则，问题得不到解决，应该申请直接和跨级领导评估问题再做处理，不管结果如何，大家还是为了一个目标在一起。
c. 培训学习：作为一名软件测试人员，要学习和掌握的知识很多，在有限的生命中，我们不可能把所有的知识都学到手，但至少应该多学习和目前工作联系比较密切的知识，横向分如计算机知识、业务知识、行业知识、边缘知识等，纵向分如计划基础理论知识、测试技能理论、产品知识、行业规范等等。而且提倡学习后做分享，这样对自己成长或是自己心态都有好处。
3.2 测试环境
a. 独立：测试环境应该和开发环境、演示环境保持独立，测试环境就是给测试人员专门分配的，测试环境的独立性不但可以确保测试工作的有序进行，而且能保证测试出来的结果有实际的参考价值。
b. 干净：测试环境应该时刻保持干净，注意反病毒软件的安装和升级，不能有病毒侵入，这样在测试的效率和测试结果上才能有保障，测试出的数据才有一定的意义。
c. 备份：一个项目需要测试很多版本，在测试环境下部署的版本，每一次测试完成后，应该做备份，这样既是复现问题的证据，也是测试环境保持干净性的体现。
3.3 测试资源
a. 人力资源：所有测试资源中，无疑最重要是人，所有的测试工作是由人来完成的，只要人在测试过程中，始终体现出积极、专业、认真的精神态度，才有可能把事情做好。
b. 测试版本：测试人员的测试对象是项目，而项目是以版本树的形式出现的，所以，测试人员每测试一个版本都应该当成宝贵的成果资源来看待，尤其是最后测试完成的版本，作为测试的终结发布版本，一定要认真对待，通常情况下，推荐应该建立FTP服务器，将项目测试完成的版本由测试人员发布到FTP上的文件下，在运维演示、客户升级等需要时应该从FTP上获取版本，FTP作为唯一的出口，避免未经测试或测试不够充分的版本通过私下关系交流。
c. 测试文档：测试文档从测试计划、方案、用例、报告、用户手册等诸多文档中，都应该保存下来，作为一种资源管理起来，对后续的项目升级、新人的学习等都有非常重要的意义。
d. 测试工具：测试工具的研究和推广使用是一个漫长而且艰苦的事情，一旦在测试过程中能够使用起来并对测试项目有帮助的工具，就应该积极推广，同时，对工具的使用手册，使用情况，安装部署等以文档化的形式备份下来，后期能够减少新接触工具人员的学习成本，有利于工具的推广使用。
e. 其它资源：其它资源包括测试人员的个人总结心得、第三方测试资源、第三方测试人员联系方式等等都应该也以文档化的方式记录下来，作为一种资产备份下来。
4. 测试工具使用
|
功能描述 |
工具名称 |
使用阶段 |
获取方式 |
使用情况 |
|
测试计划定制 |
MS Project 2010 |
计划阶段 |
试用版本 |
熟悉 |
|
原型图设计 |
MS Visio 2010 |
需求阶段 |
破解版本 |
熟悉 |
|
测试方案编写 |
MS Word 2007 |
设计阶段 |
破解版本 |
熟悉 |
|
测试用例编写 |
||||
|
测试文档评审 |
MS Excel 2007 |
评审阶段 |
破解版本 |
熟悉 |
|
测试文档管理 |
SVN 、CC |
测试阶段 |
开源、商业 |
熟悉 |
|
性能测试工具 |
Jme ter、LR |
开源、商业 |
熟悉、了解 |
|
|
生成测试数据 |
TestDataBuilder、 Dbmonster |
开源、开源 |
熟悉、了解 |
|
|
缺陷管理工具 |
Mantis、JIRA、CQ |
开源、开源、商业 |
熟悉、了解、熟悉 |
|
|
自动化测试 |
Seleniu、Watir |
开源、开源 |
了解、了解 |
|
|
Robot |
商业 |
了解 |
||
|
测试报告 |
MS Word 2007 |
结束阶段 |
破解版本 |
熟悉 |
|
测试总结 |
备注：对上表格“使用情况”一列中标注的熟悉、了解的说明：
熟悉：指以前的工作中使用频繁或使用过，对该工具有一定的技能储备。
了解：指在以前工作使用很少用或在工作之余研究过该工具，可能还未在项目中实际使用过。
5. 测试规范建立
1． 软件测试方法指南：对测试人员在进行各类测试时进行规范化的要求，通过规范的制定，可以 有效统一测试人员的测试行为，避免不同的人在做同类测试时出现测试效果上的很大偏差。
2． 测试计划规范：包括测试计划的模板以及对测试计划的要求，测试进度和时间安排根据什么来 制定。
3． 测试用例测试规范：包括测试用例的模板以及测试用例的测试要求。
4． 缺陷提交规范：用于规范测试人员的bug录入过程要求，包括bug的录入格式要求，bug提交的要素包括哪些，bug的描述需要注意的地方等。
5． 测试报告规范：包括测试报告模板及对测试报告的要求。限定和指明测试报告应该包括哪些内容。
6． 测试工具使用规范：指出测试人员在测试阶段应该使用哪些测试工具，工具的获取途径和使用细则。
7． 其他规范：缺陷的分类规范、测试人员的测试流程规范、测试人员的培训制度规定等。