过程之精益研发测试

最新推荐文章于 2025-05-24 13:31:39 发布

原创最新推荐文章于 2025-05-24 13:31:39 发布 · 3.1k 阅读

7 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#精益 #研发 #测试 #标准

质量控制专栏收录该内容

3 篇文章

订阅专栏

本文详细介绍了精益研发流程中的测试实践，涵盖需求阶段、设计阶段、开发阶段、测试阶段以及日常运营阶段的测试活动。重点强调了需求评审、用例设计、缺陷管理以及在不同阶段的测试策略，旨在提升产品质量和效率。

精益研发测试产出标准

测试产出标准 1

一．精益研发流程 2

二．精益研发流程测试实践 4

(1)需求阶段测试： 4

(2)设计阶段测试: 5

(3)开发阶段测试： 6

(4)测试阶段测试： 7

(5)发布阶段测试： 8

(6)日常运营阶段： 8

一．精益研发流程

二．精益研发流程测试实践

在整个精益研发流程中，

6条角色主线，产品，设计，研发，测试，运维，运营

6个阶段：需求-设计-开发-测试-发布-日常运营

(1)需求阶段测试：

在需求阶段，测试人员主要做的事情，如下表所示：

阶段	测试人员	QA
需求阶段	1.参与需求评审，用户需求分析，挖掘需求含混性	1.保证确认需求活动符合需求管理过程2.管理用户需求评审
需求阶段	2.参考经验库质疑开发的时间估算	3.管理需求变更

作为测试人员的主要实践如下：

需求评审

在sprint会议上，对用户需求进行分析，检查功能性需求和非功能性需求是否描述清晰，其中可以将非功能性需求作为验收要点，例如一个用户需求："客户希望提高响应时间"

测试人员应当协助开发人员消除需求的含混性：提高什么的响应时间和响应时间为多少？可以建议修改为："客户信息普通查询返回结果的响应时间为5s内"

说明在"客户信息"模块，进行"普通查询"操作，返回结果的时间在5s内，这个陈述句已经清晰表达了，也达到了消除含混性的效果。同样，测试人员可以编写提高查询效率的用户需求："客户在信息查询模块，进行普通查询，能够在5s内返回结果"、"备注：5s为非功能性需求，也是验收要点"

需求评审需要建立评审的checklist建立需求评审checklist，如下所示：

1：需求描述是否具备完整性；（没有遗漏内容；或描述片面） 2：需求描述是否有二义性；（没有让不同的人有不同的理解结论） 3：需求描述是否是正确的；（需求之间没有冲突等） 4：是否包含有非功能属性的需求；（性能，安全性，可靠性，易用性等） 5：是否需求是可以验证的；（需求描述具备可测试性） 6：需求是否可实现；

参考经验库质疑开发的时间估算

在sprint会议上，开发人员根据经验出牌（团队自己定义的规则，用扑克牌）估算时间，当给出最终结果的时候，测试人员应当对其进行质疑。测试人员借鉴历史经验库：开发人员在某方面的技能如何、该模块曾经产生过何种程度的缺陷、修复缺陷的消耗时间是多少等等，综合考虑，提出疑问，让开发估算最终的时间，尽可能考虑这些因素。当然，测试人员能够质疑的其中一个前提是：测试人员具备相关开发经验。

(2)设计阶段测试:

在设计阶段，测试人员主要做的事情，如下表所示：

阶段	测试人员	QA
设计阶段	1.参与UI评审
	2.测试计划设计
	3.接口测试用例设计
	4.功能测试用例设计

参与UI评审

测试计划设计

接口测试用例设计

测试用例设计测试用例编写规范

测试人员主要设计测试故事点，使用DSL(Domain Specific language)，对测试用例进行描述，包括三个基本要素：Feature、Scenario、Example，补充要素：xmind、Requirement。

Feature：把测试分类到某个模块，并对这个特性本身的业务目的进行相关描述，带进业务目标，传递业务知识。

Scenario：标明这个Feature的测试场景，可以使用文字描述步骤，或者使用xmind脑图描述，场景中的数据使用Examples中列出的。

Example：引出具体的数据表格把用到的数据都展示出来，避免相同步骤因为测试数据的变化而重复若干遍造成冗余。

Xmind：脑图文件，展示测试故事点

Requirement：关联需求管理系统的需求id。

功能要点确认

Xmind是一个非常好用的脑图工具，通常在开发人员进行编码前，测试人员会针对需求处理的用户故事，与开发人员进行确认，修正理解偏差，确保需求理解一致。

(3)开发阶段测试：

在开发阶段，测试人员主要做的事情，如下表所示：

阶段	测试人员	QA
开发阶段	• 接口测试用例评审	• 管理评审活动
	• 功能测试用例评审	• 管理文档产物
	• 测试探索
	• 功能测试
	• Bug Tracking
	• 回归测试
	• 系统测试
	• 验收测试

用例评审建立用例评审checklist

主要是坚持同行评审的原则，主要在测试组内进行，负责该任务的开发人员也会参与，简单来说就是对测试用例进行查漏补缺的工作。用例评审建立用例评审checklist

测试探索

进行了"功能要点确认"和"用例评审"后，为了保证测试场景的覆盖率，需要再进行测试探索。在开发人员完成雏形之后，使用探索式测试的策略，对功能基本流程进行有目的的快速走查，挖掘功能不确定的地方和补充测试场景，避免不确定的因素拖延到开发阶段后期，造成返工。

其中：功能测试、Bug Tracking、回归测试、系统测试、验收测试都是日常测试工作所需环节。

缺陷经验库建立自己的缺陷经验库

每个团队都存在开发/测试新人和开发/测试老人，当测试人员与开发新人进行需求确认的时候，还需要进行缺陷经验教训的提醒，避免多走弯路。

提升开发自测质量

测试人员可以提供相关checklist（大家可以根据原作者提供的修改为符合团队的）帮助开发人员在编码过程中关注开发自测的要点，从而提升质量。

(4)测试阶段测试：

在测试阶段，测试人员主要做的事情，如下表所示：

阶段	测试人员	QA
测试阶段	• 接口测试
	• 冒烟测试
	• 系统测试
	• 探索性测试
	• 回归性测试
	• 测试报告
	• 缺陷统计分析报告