测试流程是什么？

Question

如题所述

Answer 1

敏捷 双V W 瀑布
成熟的模型 双V 需求参与其中 需求分析 参与人员 一同评审需求 然后开始写测试用例 每个人分配用例上的各自担任模块职责
测试报告分两个：一个是 验收测试报告：给客户去看（外部看）
一个是内部看（尽可能的详细）

Answer 2

我晕，楼上的回答简直不让人晕啊……貌似直接从51testing拷贝的哦，简直是……不过楼上的给出的51testing确实不错，里面很多测试方面的东西值得学习的，这个顶一个。好了，现在来说说测试流程吧，测试流程这个要因公司而异，没什么特别准确的答案，但是至少应该包含以下内容：1、测试需求：就是根据用户需求来评定测试员需要测试的内容，因为并不是说所有的东西都是可测的，对于某些软件，有些部分是无法测试的，这就需要测试员来评估，哪些可测哪些不可测；2、测试计划：根据测试需求来制定测试计划，即时间安排，人员安排以及硬件安排等；3、测试用例设计：设计测试用例，用以指导测试并可直观看出你测试的覆盖率；4、测试环境搭建；5、用例执行；6、提交BUG；7、回归BUG；8、测试总结：即完成一轮测试后，需要根据BUG分布来分析软件薄弱点在何处，以方便后续测试计划的制定；这个就是一轮测试的基础流程，但是并不是所有公司都会严格按照这点做，很多小公司为了节省时间和成本，几乎都只有：用例设计，环境搭建，用例执行，提交BUG，回归BUG，所以真正的测试流程必须要包含以上8点才行，很多大公司都会根据自身的特点制定各自的测试流程，这个就不好详细说明了……希望这些对你有帮助……

Answer 3

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