Skip to content

Latest commit

 

History

History
185 lines (141 loc) · 12.3 KB

产品项目测试工作规范.md

File metadata and controls

185 lines (141 loc) · 12.3 KB
Raw

1. 工作职责

  • 需求讨论和评审： 在需求产生后参与需求的讨论，确认需求与历史策略没有冲突，没有二义性，具有可测性（也就是说能够测试或者易于测试）。
  • 设计讨论和评审： 在系统设计完成后，参与设计评审，主要关注扩展性，可测性（这里是指架构是否合理，不会出现很小的改动就会带来巨大的测试回归量）。这一点是很重要的，因为系统架构的好坏，直接关系到测试的质量以及自动化的易开展性。
  • 测试计划制定： 根据测试的需求和代码的规模，测试人力资源情况，测试方法、方式等情况，制定相应的测试计划，包括测试设计（case、数据、工具）的计划，环境部署的计划，测试执行的计划。
  • 测试设计： 根据需求以及系统设计，进行测试用例的设计、形成，以及相应数据、工具的准备。
  • 测试执行： 以测试用例为依据，借助准备好的数据、工具开展的用例执行工作。
  • 性能评估： 对产品/模块的性能情况根据目标给予评估是否可以满足，或者能够满足到什么程度。
  • 过程改进： 从每日测试面板，关注自动化趋势，及时发现用例退化情况，改进测试用例质量。

2. 工作过程规范

2.1. 测试工作规范

2.1.1. 启动准则

需求说明书和系统设计文档完成以后

2.1.2. 输入

需求说明书和系统设计文档

2.1.3. 主要步骤

2.1.3.1. 设计系统测试用例

2.1.3.1.1. 前期文档评审

详细设计评审是测试工作流程的一部分，是在测试用例设计之前的一个过程。由于文档的质量直接关系到测试用例的质量，在这里我们还是要重点提出。 测试人员进行测试用例设计时，主要是依据需求文档和设计文档。这就要求我们在测试前期介入文档的评审，以测试的角度对文档进行评估和检查。主要关注以下几方面：

  • 正确性：要保证文档描述的内容是真实的、可实现的。具体说就是检查需求文档是否在业务上是合理的，与其他的功能是否矛盾。设计文档是否是可实现的，是否与其它模块和接口是匹配的；
  • 可测试性：对一条需求，必须存在一个可以明确预知的结果，并且可以设计一个可重复的过程对此进行验证。对一段代码（要求测试的方法和接口），必须存在一个可实现的测试路径，能够覆盖设计中的路径和分支。
2.1.3.1.2. 迭代的用例设计过程

设计测试用例时，最好不要一开始就第一个模块进行详细的用例编写。这样做的后果可能会使我们过早地陷入细节、迷失重点，使测试用例编写的进度和工作量脱离控制。 迭代的用例设计过程的方法：

  • 确定测试用例设计的范围。确定用例要包含的测试类型（功能、性能、接口等）、明确用例覆盖的模块、采用的测试方法、使用的测试工具、用例大致的设计粒度。
  • 根据上面的结果，进一步细分。设计功能测试的测试大纲，设计性能测试的方案，划分测试用例集。
  • 测试用例设计是一个不断加深，不断调整的过程。定期的review用例，不断提高用例的精度和覆盖度，调整用例的合理性。
2.1.3.1.3. 用例类型

测试用例按照面向模块的需求差异、模块的数据流程、与其他模块的接口关系，可以大致的划分为以下几种类型：

  • 功能测试：主要是根据详细设计文档的需求描述，设计相关的功能测试用例；
  • 接口测试：根据测试模块与其他模块的接口关系，或者测试对象本身就是对外提供的API，设计相关的接口测试用例；
  • 性能测试：根据测试模块或者测试系统的性能要求，设计性能测试用例。包括但不限于：处理能力测试、并发用户数测试、大数据量测试。
  • 稳定性测试：主要是针对系统的稳定性，设计测试用例。
2.1.3.1.4. 用例粒度规则

编写测试用例前，需要确定测试用例的粒度。既要保证功能的覆盖度，又要避免增加不必要的用例编写工作量。 测试用例设计中常常使用“原子化”的概念。在这里我们可以这样理解：

  • 功能用例原子化：是指一个独立的、有实际意义的功能点。在实际测试中可以灵活使用；
  • 接口用例原子化：一般是指一组能够独立存在的输入、输出；
  • 性能测试原子化：按照测试重点的不同，可以是不同的并发设置和预期；
2.1.3.1.5. 自动化用例书写规范

命名规范：类名_测试点

自动化用例编写规范：

  • 前提条件：准备测试所需要的各种条件（创建所有必须的对象，分配必要的资源等等）；
  • 操作步骤：执行用例的步骤；
  • 验证点：验证实际输出和期望输出是否一致；
  • 释放资源：完成后清理各种资源。

好的自动化测试用例应该具有以下品质：

  • 自动化：前提条件，操作步骤，检查点的自动化；
  • 彻底的：所有可能会出现问题的情况；
  • 可重复：每个测试应该独立于所有其他的测试，而且还必须独立于周围的环境，目标是测试应该能够以任意的顺序一次又一次的运行，并且产生相同的结果；
  • 独立的：测试应该是简洁而且精炼的，每个测试都应该有很强的针对性，并且独立于环境和其他的测试。
  • 专业的：测试代码必须是以同产品代码相同的风格来编写。抽取出共同的且重复的代码，并放入一个函数中，从而可以多处调用该函数

2.1.3.2. 执行系统测试

在测试正式开始前，项目经理向测试组提交可以测试的版本，由测试负责人安排搭建测试环境，如果项目计划变更，则测试计划进行相应变更。 运行自动化测试用例和手动执行手动用例

2.1.3.3. 缺陷管理

2.1.3.3.1. 整体流程图

Image of flowchart

2.1.3.3.2. 缺陷跟踪
2.1.3.3.2.1. 提交

2.1.3.3.2.1.1. 角色

  • 项目成员（测试人员为主）提交缺陷请求；
  • 项目经理提交客户反馈问题。
  • 开发人员可以提交缺陷(由测试负责人定期查看，若是缺陷问题即联系开发负责人解决)；

2.1.3.3.2.1.2. 步骤

  1. 设置Status 为 New；
  2. 设置Type为Defect（缺陷）或Suggestion（建议）；
  3. 设置 Area，指Bug产生的区域；
  4. 设置 Iteration，指Bug产生的测试迭代；
  5. 设置 Priority ，在TFS中将Bug的优先级分为4个等级，开发人员应该按照优先级别解决Bug：
  • Priority 1 致命的：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃，悬挂，死机。（当天必须完成）
  • Priority 2 严重的：系统停止运行；系统的重要部件无法运行；没有可行的解决方法；严重影响测试进度。
  • Priority 3 一般的：系统无法满足主要的业务要求；没有显而易见的可行解决方法；性能、功能或可用性严重降低。
  • Priority 4 低级的：系统可以满足业务要求，比如，不严重的打字错误等

  1. 设置Severity，遵循以下软件缺陷和文档缺陷的严重程度的划分标准进行设置：

    软件缺陷的严重程度的划分标准：

  • High：系统停止运行；系统的重要部件无法运行；没有可行的解决方法；严重影响测试进度。

  • Medium：系统无法满足主要的业务要求；没有显而易见的可行解决方法；性能、功能或可用性严重降低。

  • Low：系统可以满足业务要求，比如，不严重的打字错误等。

    文档缺陷的严重程度的划分标准：

  • High：文档不完整，需求中的功能点在文档中没有完全体现； 软件中没有文档中所描述的功能；按照文档中的步骤操作，但没有得到预期的结果。

  • Medium：操作步骤的说明不够明确；图片与文字不配套。

  • Low：格式问题；文字错误；标点错误；表述略微不通顺。

  1. 设置Responsibility为项目经理：测试人员评经验判断可以修改bug的人员，如果无法判断则提交给项目组长，再由项目组长转给其他开发人员；
  2. 在 Title 输入框，填写用例名
  3. 在Description Tab，填写缺陷的详细描述，一般包含以下几项：
  • 前提条件
  • 操作的步骤
  • 期望的结果
  • 实际得到的结果
  • 可能的修改建议
  1. 在Attachments Tab中添加必要的附件，比如屏幕截屏或错误日志。
2.1.3.3.2.2. 分配

2.1.3.3.2.2.1. 角色

项目经理根据缺陷的相关责任人分配

2.1.3.3.2.2.2. 步骤

  1. 设置Status为Open、Is Duplicate（重复）、As Designed （按设计）或 Deferred （延期）；
  2. 如果状态修改为Open设置Responsibility为指定给相关责任开发人员； 如果状态修改为Is Duplicate（重复）、As Designed （按设计）或 Deferred （延期）， 无须设置Responsibility；
  3. 当责任人被分配的未解决的缺陷数多于5个时，设置Priority为解决缺陷的优先级：高优先级应该优先解决；低优先级为开发人员根据自己的时间安排具体解决时间。
2.1.3.3.2.3. 解决

2.1.3.3.2.3.1. 角色

开发人员根据缺陷决定解决措施

2.1.3.3.2.3.2. 步骤

  1. 如果的确是一个错误，则需要修正，修正结束后
  • 设置Status为Resolved，解决的原因设置为Fixed。
  • 填写comment，注明所进行的修改的摘要，可在comment中填写测试人员需要注意的测试重点或由于本次修改需要重新测试的相关功能。
  1. 如果无法再现缺陷的情景（请开发人员确保该发现缺陷的版本为测试人员测试的版本而非当前的工作环境，请对应正确版本再现错误情况） 设置Status为Closed, 关闭原因设置为Cannot Reproduce
  2. 注： 如果缺陷不是自己的问题，转给项目经理，并与项目经理沟通； 当被分配了多个Change Request时，优先解决优先级高的CR，如果没有划分优先级，优先解决严重程度高的CR。
2.1.3.3.2.4. 验证

2.1.3.3.2.4.1. 角色

提交变更请求的人员来验证请求完成的情况。

2.1.3.3.2.4.2. 步骤

  1. 如果确认已修复并已验证，设置Status为Closed，关闭原因设置为Verified Fixed
  2. 如果确认无法重现，设置Status为Closed，关闭原因设置为Verified Cannot Reproduce
  3. 如果确认重复缺陷，设置Status为Closed，关闭原因设置为Verified Duplicate
  4. 如果确认是保留原样，设置Status为Closed，关闭原因设置为Verified As Designed
  5. 如果确认可以推迟修正，设置Status为Closed，关闭原因设置为Verified Deferred（在Comment中写清楚原因）
  6. 如果确认不需要解决，设置Status为Closed，关闭原因设置为Verified Documented（已复制到积压工作）
  7. 如果发现结果不正确，再次设置Status为Open
  8. 如果项目准备移交评审之前检查Change Request的状态，Change Request状态应是已关闭，需要推迟解决的Change Request请在Comment中说明原因。
2.1.3.3.3. 缺陷跟踪监控
2.1.3.3.3.1. 角色
  • 测试人员
  • 项目经理
2.1.3.3.3.2. 监控方式
  1. 定期抽查Change request流转的情况：
  • 长时间处于Open或New状态Change Request;
  • 长时间未确认的Change Request.
  1. 项目准备移交评审之前检查项目Change Request的状态： 确保所有修改的缺陷都得到确认，对遗留的缺陷在移交评审时须确定对项目的影响及解决时间。

2.1.3.4. 制定测试报告

在开发过程中输出的测试报告为：单元测试报告（不是必须的）和系统测试报告。代码开发完毕后，由开发人员提交单元测试报告，系统测试结束后由测试人员提交系统测试报告。 在测试执行完成后，测试负责人将输出的测试报告提交给产品经理和项目经理进行用例抽查，评测用例的覆盖率。用例覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。

2.1.4. 输出

  • 测试用例
  • 测试报告