测试基本流程与规范

测试基本流程与规范-修改版 1.测试目标制定完整且具体的测试路线和流程，为快速，高效，和高质量的软件测试提供基础流程框架。最终目标实现软件测试规范化。2.测试流程图软件开发阶段软件开发阶段测试人员测试人员开发人员开发人员需求分析参与需求讨论与分析根据软件需求规格说明书进行功能点整理提取测试点需求讨论与分析编写软件需求规格说明书评审设计阶段测试计划初稿（包括测试活动的内容，进度安排，设计考虑，测试数据的整理方法及评价准则）进行软件系统的设计编写概要设计说明书，详细设计说明书等文档评审实现阶段测试计划定稿编写测试用例单元测试（开发完成单元模块）开发进行编码编写用户手册测试阶段单元测试集成测试系统测试修复测试发现的 BUG运行与维护阶段编写测试报告软件纠错性维护软件改进型维护项目开发总结报告修复 BUG 和改进系统编码3.测试需求分析测试需求是整个测试过程的基础；确定测试对象以及测试工作的范围和作用。用来确定整个测试工作（如安排时间表、测试设计等）并作为测试覆盖的基础。而且被确定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果。无法核实的需求不是测试需求。所以我现在的理解是测试需求是一个比较大的概念，它是在整个测试计划文档中体现出来的，不是类似的一个用例或者其他·测试需求是制订测试计划的基本依据，确定了测试需求能够为测试计划提供客观依据；·测试需求是设计测试用例的指导，确定了要测什么、测哪些方面后才能有针对性的设计测试用例；·测试需求是计算测试覆盖的分母，没有测试需求就无法有效地进行测试覆盖；3.1测试方法与规范（待商讨而定，根据不同公司，不同项目，不同需求而定）3.1.1 测试方法开发自测-开发人员该模块功能开发完成，需要开发人员进行基本功能的验证。 确保交付版本冒烟通过，冒烟测试用例由测试人员提供。冒烟/接口测试- 测试人员冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。黑盒测试（功能测试）-测试人员黑盒测试，英文是 Black Box Testing。又称功能测试或者数据驱动测试。黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。随机测试-测试人员随机测试没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 (TestCase)没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大 Bug，进行再次测试，可以结合回归测试(Regressive testing)一起进行。 性能测试-测试人员（待研）兼容性测试-测试人员（待研）3.1.2 测试规范测试规范是根据开发规范而制定的测试标准，测试规范也是后期测试用例编写的重要依据。因为开发规范因公司而异，因产品而异，所以测试规范的标准程度每个公司都不一样。从理论到方法到各类流程到各类报告模版，都属于测试规范的范畴，当一整套规范形成之后，可使得测试工作进行更加稳健，所有问题有据可查。3.2软件需求规格说明书（开发提供）3.3软件概要与详细设计（开发提供）4.测试过程设计4.1测试策略制定（1-2 人天）这一阶段在于需求、详细设计、测试计划完成之后，主要是本次测试的策略阶段。 很多公司少这个一个阶段，需要有计划性的分出产品的功能扣出测试的功能点，现阶段大多公司都是直接拿着文档就开始做用例设计。对需求进行分析，列出具体的功能列表。 （一般根据功能交互文档就能明确出此功能的大体功能，一层层的分下去，一直到没个功能表单。然后考虑到使用那些测试方法？工作一旦做到执行阶段，我们可以更好的根据这些功能表一点一点的覆盖。也能让我们在用例评审时，充分的证实我们的工作是有效的能够保证产品的质量。 ）一般在此之前，一些业务培训和需求评审是有必要是听一下的。这样能够更早更熟练的理解需求，也能保证产品设计中出现的一些误区。对于一个个测试该如何进行测试？如下：a)功能测试功能范围（划分出各自负责的功能模块）使用测试方法（等价类、边界值等测试方法）测试标准（符合设计、需求和规范文档对该功能的描述）b)界面测试c)兼容性测试4.2测试计划（2 人天）1)要充分考虑测试计划的实用性，即测试计划与实际之间的接近程度和可操作性。编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。a)测试内容：对一个软件来说测试计划中会明确本次测试做哪些测试？如：系统测试：在整个系统测试中会有（界面测试、功能测试、性能测试、兼容性测试、安装卸载测试、可靠性测试等测试） 。 b)测试目的：一般多为保证产品质量是否达到预期的指标。这个指标也就是在测试中定义的结束标准。c) 测试标准：需要考虑本次测试需要输入那些文档，该项目结束标准定义、测试 结束标准的定义？bug 级别定义、优先级定义、bug 管理流程定义。这个都需要在执行测试事明确。计划中应该包含这些内容。 d)资源分配：这里分为人力资源、软硬件资源等划分。一般会把人力资源的利用写入一个测试人员任务分配表里，按照不同的阶段，每个阶段提交相应的成果（难度很大） 。软硬件资源中主要是在做计划时考虑到需要多少电脑或别的工具，列出清单。e)测试风险：大多考虑到的就是项目开发延期、测试人员不足用例无法全面覆盖 测试点、时间不足用例无法全部执行、bug 无法及时修改导致无法验证、测试人员技能不足导致测试进度拉长。f)软件测试策略一般都是分开来做相关测试方案。4.3测试附件用例模板、缺陷报告模板测试环境的搭建缺陷管理流程和缺陷级别定义缺陷状态一般分为：新建、打开、已分配、已修复、关闭、重新打开中间会有：延期、重复、拒绝等状态缺陷管理流程图：缺陷管理流程图：1.测试人员或开发人员发现 bug 后，判断输入哪个模块的问题，填写 bug 报告后，系统会自动通过 Email 通知开发组长和该模块开发者。2.开发组长根据具体情况，重新 reassigned 分配给 bug 所属的开发者。3.开发者收到 email 信息后，判断是否为自己的修改范围。若不是，重新 reassigned 分配给开发组长或应该分配的开发者。若是，进行处理，resolved 并给出解决方法。 （可创建补丁附件及补充说明）4.测试人员查询开发者已修改的 bug，进行回归测试。经验证无误后，修改状态为 verified。待整个产品发布后，修改为 closed。还有问题，reopened，状态重新变为“new” ，并发送邮件通知。5.如果这个 bug 一周内一致没被处理过。Bugzilla 就会一直用 email 骚扰它的属主，直接采取行动。管理员可以设定最迟采取行动的期限，比如 3 天，系统默认 7 天。BUG 级别定义：级别定义：致命(Critical)BUG ：测试执行直接导致系统死机、蓝屏、挂起或是程序非法退出；系统的主要功能或需求没有实现。严重(Serious) BUG：系统的次要功能点或需求点没有实现；数据丢失或损坏。执行软件主要功能的测试用例导致系统出错，程序无法正常继续执行；程序执行过于缓慢或是占用过大的系统资源。一般(Minor) BUG：软件的实际执行过程与需求有较大的差异；系统运行过程中偶尔（<10%）有出错提示或导致系统运行不正常。微小(Information) BUG：一些小问题，对功能几乎没有影响，产品及属性仍可使用，如功能改进建议，有个别错别字、 文字排列不整齐等；5.测试实施5.1执行（3 轮一迭代）开发就会转版本给我们测试部门进行系统测试了。拿到版本我们首先搭建测试环境做一个预测试，目的是来评断这个版本是不是可测试的。如果预测试不通过，打回 开发部返工，如果通过了，就开始我们第一轮的系统测试。第一轮系统测试我们会执行我们所编写的所有测试用例，做好测试结果的记录，发现缺陷了提交缺陷报告。当第一轮测试结束后，我们把所有的 bug 单提交给开发人员，由他们进行修改。在他们修复 bug 期间，我们会对第一轮系统测试做一个测试评估，出一个测试报告。 还要根据实际情况，对我们写的测试用例进行修改和增加。开发改 bug 结束，提交一个新的版本给我们，我们重新搭建测试环境开始第二轮系统测试。首先是回归我们提交的缺陷报告，然后会在用例中挑选一些优先级别比较高的用例来进行测试，发现问 题了继续提交缺陷报告，只到缺陷率低于用户要求了，我们就进行最后一轮的回归测试，结束系统测试。具体测试轮次是根据版本质量和项目复杂度而决定的。5.2测试用例测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。5.2.1 测试用例设计原则1、测试用例的代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等。2、测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。3、测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。5.2.2 测试用例编写规范系统性。对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系连贯性。对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯全面性。应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备正确性。输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合符合正常业务规则。测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规可操作性。测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果5.2.3 测试用例内容模板例编号： 唯一标识，与需求编号对应，为多对一关系 用例编写者：设计用例的人员 被测对象：要测试的功能点（模块、系统） 用例标题：对测试项简短的描述 用例级别：确定用例执行的级别。 前提条件：执行用例时需要的预置条件 输入条件：执行该动作需要输入的数据 操作步骤：执行该动作需要完成的操作 预期结果：执行完该动作后程序的表现结果 实际结果：实际输出的结果 问题描述：执行该用例出现后系统显示的错误 验证结果：该测试用例是否执行通过 BUG 编号：填写 BUGBASE 中对应此用例的 BUG 编号 需求编号：唯一标识，与用例编号对应，为一对多关系 测试执行者：按照该用例执行测试的人员 测试日期：执行测试的时间 备注：对未执行或不能进行执行的用例进行说明6.测试评估（2-3 人天）执行阶段结束了进入测试评估阶段，我们会出一个总的测试报告对我们测试的这个过程 和版本的质量做一个详细的评估1)需求需要评审那些？2)用例需要评审那些？3)计划应该评审那些？4)缺陷评审那些？5)bug 评