软件测试流程及规范

软件测试流程及规范篇一：软件测试工作流程及规范软件测试工作流程及规范 1 计划与设计阶段 召开测试启动会议 测试经理召集项目经理、开发经理开会确定测试交接时间，得到当前最新的相关资料。进行规模预估并成立测试团队，完成测试计划 设计测试用例在需求分析文档确立基线以后，测试组需要针对测试需求编写测试用例，在实际的测试中， 测试用例将是唯一实施标准。在用例的编写过程中，具体的任务和责任人如下：2 实施测试阶段实施测试用例 实施测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础 上。 提交测试报告 在约定的测试周期完成之后，测试工程师需要总结此测试的结果，编写测试报告 3 总结阶段 测试工作结束或即将结束时，测试组就要开始着手准备进行总结的工作。 编写测试报告 在测试结束之后，测试经理编写测试报告，对测试进行总结，并且提交给项目经理，为产 品的后续工作提供重要的信息支持。 测试验收 测试验收工作是在以上工作全部结束后，对测试的过程，效果进行验收，宣布测试结束 测试归档 测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档 进行归档。 篇二：软件测试流程规范软件测试流程规范 一、 通读项目需求设计文档 1. 测试的准备阶段； 2. 仔细阅读软件需求规格说明书 ； 3. 根据测试手册，做前期的测试准备； 二、 明确测试任务的范围 功能测试；界面测试；接口测试；容错测试；负载测试； 安全测试；性能测试；稳定性测试；配置测试；安装测试； 恢复测试；文档测试；可用性测试； 三、 学习理解被测试软件 由开发人员组织讲解所要执行测试的软件或者产品，测试人员必须认真理解拿到手中待测试的软件或者产品。 四、 制定测试计划 “工欲善其事，必先利其器” 。软件测试必须以一个好的测试计划作为基础。作为测试的起始步骤和重要环节。测试计划应包括：产品基本情况调研、测试策略、测试大纲（功能模块的测试、详细测试、高级测试） 、测试内容（界面测试、测试需求说明） 、测试人力资源配置、测试计划的变更、测试硬件环境、测试软件环境、测试工具、测试进度计划表、问题跟踪报告、测试通过准则、测试计划的评审意见等。另外还包括测试计划的目的、测试对象信息、测试计划使用的范围及测试参考文档。 1. 项目简介；对产品（项目）的一个了解和概述，主要对产品（项目）功能的简述。 2. 测试背景； 产品在那种情况下开始研发，执行测试，交待为何而测试产品的背景。 4. 测试类型（方法） ；（黑盒测试） 功能测试；界面测试；接口测试；容错测试；负载测试； 安全测试；性能测试；稳定性测试；配置测试；安装测试； 恢复测试；文档测试；可用性测试； 5. 测试资源； 人力资源系统资源 6. 测试策略测试需求测试任务测试点； 针对测试需求定义测试类型、测试方法以及需求的测试工具等。 对于每种测试，都应提供测试说明，并解释其实施的原因。 制定测试策略时所考虑的主要事项有：将要使用的技术以及判断测试何时完成的标准。 下面列出了在进行每项测试时需考虑的事项，除此之外，测试还只应在安全的环境中使用已知的、有控制的数据库来执行。 不实施某种测试，则应该用一句话加以说明，并陈述这样的理由。例如， “将不实施该测试。该测试本项目不适用” 。 五、 设计测试用例测试用例的主要来源为：1）需求说明书及相关文档2）相关的设计说明（概要设计，详细设计等）3）与开发组交流对需求理解的记录（可以是开发人员的一个解释）4）已经基本成型的 UI（可以有针对性地补充一些用例） 从所得到的资料中，分解出若干小的“功能点” ，理解“功能点” ，编写相应的测试用例。 测试用例模板（Excel）： 六、 确定软件测试软硬件环境 七、 搭建测试环境 记录下配置环境，常用软件均要安装， 八、 执行测试（集成测试、系统测试、验收测试）与优先级的控制 集成测试：也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要 求（如根据结构图组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 集成测试应该考虑以下问题： 1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2、各个子功能组合起来，能否达到预期要求的父功能； 3、一个模块的功能是否会对另一个模块的功能产生不利的影响；4、全局数据结构是否有问题； 5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。对子系统，集成测试也叫部件测试。 任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系 统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。九、 提交缺陷报告 Bug 单附表环境 新建： 测试人员报告 bug 的状态 已指派：测试人员分配 bug 的状态 已解决：修改人员修改 bug 的状态，在解决 bug 界面准确标注 bug 的完成度 已确认：修改人员对暂时不能、以后修改的 bug 进行确认的状态 反馈： 测试人员对开发人员认为不修改、但测试人员需要修改的 bug 的反馈给经理的状态 公认： 经理查看反馈的 bug 后认为需要修改，则标示 bug 的状态为公认，认为不做修改，直接关闭此 bug，注明原因已关闭：测试人员对修正后的 bug 进行回归测试后，确认 bug 已修正即可关闭 bug 状态 注：BUG 级别说明 A（严重级）：操作系统或者网络瘫痪； B（中等级）：应用程序崩溃、非法退出或功能模块无法实现。 C（一般级）：篡改设计；功能实现错误或功能不完善，容错失败、数据逻辑关系错。 D（允许级）：界面布局；操作不方便；建议性修改。 ? 职责： 测试人员：准确定位 bug，新建 bug，指派 bug 与开发人员 1. 对修正后的 bug 进行验证，确认修正后将其关闭 2. 通过验证，bug 仍然存在，重新指派给开发人员 3. (来自: 小龙 文档 网:软件测试流程及规范)对修改人员认为不需要修改，而测试人员认为要修改的 bug，反馈与经理 4. 对已关闭的 bug 以后又浮现，将其重新打开，指派与原开发人员 研发人员：查看指派给自己的 bug，准确选择 bug 的完成度，添加 bug 注释，将其状态 置为已解决 1. 查看 bug，确认是 bug，进行修正，并注明原因 2. 对不属于自己模块的 bug 指派其他人修改 3. 对延迟解决的 bug 标注确认 4. 需要讨论的 bug，将其状态置为公认 经理：查看测试人员提交的 bug，确定要修改的，添加注释，指派与修改人员 1. 需要讨论的 bug，将其状态置为公认 2. 对不做修改的 bug，将其关闭 管理员： 对项目、人员进行管理维护，定期备份数据库 1. 对于重复报告的 bug，查看报告时间，将报告晚的删除 2. 对由于配置、数据库未更新将其删除 十、 测试退出准则 1. 系统满足需求规格说明书的要求 2. 按照测试计划完成了系统测试 3. 测试用例执行覆盖率达到 100% 4. 测试需求覆盖率达到 100% 5. Block，Crash，Major 级缺陷修复率达到 100% 6. Minor，Trivial 级缺陷修复率达到 80% 7. Text，Suggestion， Feature 级缺陷修复率达到75% 8. 程序能够处理要求的负载 9. 系统在要求的硬件和软件平台上工作正常。 篇三：软件测试流程及规范二、各阶段具体流程 1.需求分析阶段 步骤说明1、需求定义基本完成，SRS 编写完成。 2、开评审会，由需求调研人员、开发组、设计组、测试组等人员对需求中不清楚、不完整、存在疑义的地方提出问题，相关人员解答并确认。 3、当评审未通过，直接打回，重新修改 SRS，问题解决后，重新提交评审。 4、当评审通过后，依据 SRS，项目整体计划，设计、编写测试计划和测试设计 ，具体模板见附件。 5、开评审会，由开发组、设计组、测试组等人员对计划和设计中不清楚、不完整、存在疑义的地方提出问题。6、当审批未通过，直接打回，优化测试计划、测试设计，问题解决后，重新提交评审。 7、审核通过后，进入下一阶段。 测试通过打回标准 、阶段的输出输入：最新 SRS、项目计划 输出：测试计划、测试设计 2、单元及集成测试流程 步骤说明：1、理解需求和设计 理解设计是很重要的，特别是要搞清楚被测试模块在整个软件中所处的位置，这对测试的内容将会有很大的影响。需要记住的一个原则就是：好的设计，各模块只负责完成自己的事情，层次与分工是很明确的。在单元测试的时候，可以不用测试不属于被测试模块所负责的功能，以减少测试用例的冗余，集成测试的时候会有机会测试到的。所以，单元测试主要是关注本单元的内部逻辑，而不用关注整个业务的逻辑，因为会有 别的模块去完成相关的功能。2、概览源代码 浏览一下源代码，主要任务： 1）初步检查源代码的编码风格与规范。 2）大致估算测试工作量，比如：需要多少的测试用例、需要写多少的驱动模块和装模块等。 3）确定模块的复杂程度，初步制定测试的优先级等。3、精读源代码 认真阅读和分析代码，主要任务： 1）理解代码的业务逻辑。 2）检查代码与设计是否相符，如果详细设计没有该模块的流程图的话，先去画出流程图。 3）仔细研究逻辑复杂的模块。 4）可以采用一些检查列表来检查程序可能会出现的问题。 4、设计测试用例 综合运用白盒测试方法（和结合黑盒测试方法）来设计测试用例，包括功能测试、性能测试等，要达到一定的测试覆盖率。在设计测试用例的过程中，流程图或控制流图是分析的好帮手。 5、搭建单元测试环境 使用工具或自己写的框架将有助于单元测试的实施。在这个阶段主要就是写桩模块和驱动模块，第 4 步所设计的测试用例是通过驱动模块传递给被测试模块的，然后驱动模块想办法获取被测试模块对数据的处理结果，并判定返回的实际结果与测试用例的预期结果是否一致，通过测试框架来记录执行的结果，对于出现的错误，还需要统计错误的信息，供执行完之后分析。 6、执行测试 运行写好的驱动模块完成对被测试模块的测试。 7、补充和完善测试用例 单元测试也是个循序渐进的过程，可能一开始考虑的不够全面，或预期的覆盖标准太低，需要在测试过程中不断补充测试用例，直到满足要求为止。 8、分析结果，给出评价 根据测试的结果分析、查找错误的原因，并找到解决的办法。测试结束之后，根据测试过程的数据统计，给出被测试对象评价测试通过打回标准 1、通过标准 2、打回标准 、阶段的输出 输入：最新 SRS、项目计划、详细设计 输出：单元测试计划、单元测试用例、单元测试总结分析。 3、系统测试流程 系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测