软件测试流程
1.1、需求调研
在软件需求分析阶段，测试人员从软件生命周期的需求阶段就开始介入在需求阶段的测试人员参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；同时全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即哪些功能点需重点测试、哪些无需，以便将来制定测试计划。
1.2、制定测试计划
进行每一种测试之前，测试负责人要根据“产品定义书”及“总体设计说明”和“详细设计文档”制定“测试计划”，制定总体的测试计划，详细阐明本次测试目的、对象、方法、范围、过程、环境要求、接受标准以及测试人员和测试时间等内容，“测试计划”经过审查通过，才能实施。
1.3、需求Review
开发在完成软件需求分析之后，会提交需求分析文档，测试人员根据需求调研所了解的需求以及产品需求说明文档等资料，对需求分析文档进行Review，检查文档是否满足了需求，是否与需求一致等等。
1.4、设计Review
在软件分析设计阶段，测试人员参与设计讨论，了解系统的实现方式和原理，并对概要设计和详细设计提出自己的见解。设计结束之后，开发提交概要设计文档和详细设计文档，测试人员对设计进行Review，检查设计规划和实现方案是否合理，如果不合理，存在的问题是什么、如何改进等等。
1.5、测试设计
在设计测试方案时，首先分解测试内容，对于一个复杂系统，通常可以分解成几个互相独立的子系统，正确地划分这些子系统及其逻辑组成部分和相互间的关系，可以降低测试的复杂性，减少重复和遗漏，也便于设计和开发测试用例，有效的组织测试，将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等。然后以功能点分析文档作为依据进行测试用例的设计，设计测试用例是关系到测试效果以至软件质量的关键性一步，也是一项非常细致的工作，根据对具体的北侧系统的分析和测试要求，逐步细化测试的范围和内容，设计具体的测试过程和数据，同时将结果写成可以按步执行的测试文档。
每个测试用例必须包括以下几个部分：
（1） 标题和编号；
（2） 测试的目标和目的；
（3） 输入和使用的数据和操作过程；
（4） 期望的输出结果；
（5） 其他特殊的环境要求、次序要求、时间要求等。
1.6、开发测试工具和准备测试数据
在软件测试中，为了提高测试工作的效益和质量，只要条件许可，应尽可能采用计算机自动或半自动测试的方法，利用软件工具本身的优势来提高工作效率。
1.7、测试执行
当所有必需的测试准备工作都已完成，并且产品已经开发完毕并提交测试，则可以按照预定的测试计划和测试方案逐项进行测试。在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录。为了能准确的找出问题产生的原因，及时的解决问题，保证测试工作的顺利进行，一般来说所发现的问题必须是能够重视的。
1.8、回归测试
在测试中发现的任何问题和错误都必须有一个明确的解决方法。一般来说，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试。另一方面，对于版本更新后的软件也必须进行同样的测试过程。
1.9、测试分析报告
?测试结束后要及时地进行总结，对测试结果进行分析，由测试负责人提交“测试分析报告”。
1.10、产品发布?
测试完毕，整理产品发布包和相关文档并发布。对于新产品来说，必要的文档必须包括：
（1） 安装操作手册
（2） 产品白皮书
（3） 管理维护手册
（4） 用户操作手册
（5） 测试报告
1.11、版本控制
新版本软件发布之后，马上对代码进行质量控制。
（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。
（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。
二、 工程维护管理流程
2.1、收集新需求
新功能和不紧急的故障，其代码的修改操作不必马上进行，取而代之的是做好新需求与故障统计；对已经确认的故障也可以先在bug管理系统报bug，但只是记录，不需要马上修改。当然了，对于紧急的工程故障，需要马上修改和测试。
2.2、确认新需求
与工程人员或客户或产品经理确认新需求，确保需求被理解正确。
2.3、需求讨论
当需求与故障积累到一定数量或者工程有新版本需求，进行一次发布测试，在新版本开始修改之前把近期积累的需求与故障整理，与相关开发人员、测试人员、项目经理和测试经理讨论，确认哪些新功能可以实现、新功能的实现方法与业务流程、新功能开发修改时间、测试版本、测试时间与发布时间。
2.4、在bug跟踪管理系统报bug
确认所有需要修改的新功能和需求录入bug跟踪管理系统，并在bug跟踪管理系统中详细描述新功能需求和解决方法，同时整理相关bug列表，交付开发修改。
2.5、制定测试计划
A、 根据用户需求，定义并完善测试需求，作为测试的标准；
B、 确定重点测试事项，哪些功能需要重点测试；
C、 测试时间计划，并详细计划具体测试任务与时间；
D、 风险说明；
E、 测试准备，提前对测试环境和测试资源进行准备；
F、 发布具体时间；
G、 资源需求：包括测试人员、硬件需求、软件需求和培训计划；
2.6、编写测试案例
根据功能需求编写测试案例；
2.7、测试开发
开发自动测试脚本，补充自动测试案例；
2.8、测试实施
按照测试计划进行测试，发现并申报bug；
2.9、测试评估
A、 哪些需求通过了测试；
B、 有哪些遗留问题；
C、 测试效率评估；
D、 开发质量度量和评估；
E、 并根据评估编写测试报告；
2.10、发布新版本
A、 编写新功能文档，给工程提供新功能说明；
B、 编写升级文档，给工程提供升级参考方案；
C、 软件发布，包括新版本软件、新功能文档、升级文档和测试报告；
2.11、代码版本控制
新版本软件发布之后，马上对代码进行质量控制。
A、 Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为p2p3.3.2，则给该软件源代码也打一个与发布版本相同名字的tag p2p3.3.2。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。
B、 Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源版本版本与当前最新的发布版本一致。
----转载七点测试
