如何在需求阶段发现更多的缺陷

本文介绍了一种原创的结对需求评审法,旨在提高测试人员在单位时间内发现有效需求问题的能力。该方法通过两人结对评审,采用固定时间窗口的方式,快速识别需求中的二义性问题,从而提升需求评审的效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

你知道如何在需求评审阶段快速高效的发现高质量的需求问题吗?下面我将第一次公开分享我在工作中所原创的一种需求评审方法-结对需求评审法(在国内国外都是首创)

 无论在任何软件企业,都会存在需求评审的环节,在这个环节我们测试人员应该如何发挥更大的质量保障的价值,是很多团队都会尝试的事。因为大家都知道在需求阶段发现问题成本、定位问题成本,修复问题成本最少。要提升整个研发的效率,减少返工浪费,最好能在需求环节尽早发现需求问题。如何快速容易的发现需求的问题,软件测试业界其实一直苦于缺乏高效的实践方法。

09年时我也曾经接到过这样的一个任务:如何进行早期测试?如何进行缺陷预防。其中必须解决的一个问题就是:如何提高测试人员在单位时间内发现的有效需求问题数?虽然我们知道需求的质量也是有维度的:二义性、可测性、完整性、前后一致性、可实现性、必要性。我们应该从这些维度来发现需求问题,其中最主要的是二义性问题。但这只解决了What的问题,应该如何解决How的问题,如何发现这些类型的需求问题,就是测试技术或测试方法需要填补的空白。

 现在有两套方案推荐给大家:

方案一:Richard Bender的RBT基于需求的测试。

方案二:我原创的DZ结对需求评审法

如果你担心用得方法听起来太简单无法体现技术含量,而希望用复杂的过程及方法来体现技术的高精尖,你可以选择方案一;

如果你希望用简单快速高效,不介意别人说你方法太简单的可以选择方案二。

下面主要分享DZ结对需求评审法

 这个方法是我09年时与一位叫周博的同事,一起实践发明的。针对需求中问题数量最多,也最严重的二义性问题,体会到很难通过传统的评审会形式快速发现,而且发现效率也低。正好当时大产品团队正在实施结对编程(只对着一台电脑,一人写代码一人review代码)。我受此启发,某日灵感一现:想到结对需求评审这种形式。于是拉上周博同学,一起进行实践,实践方法如下:

1、 两人只对着一台电脑、由1人作为引导员来操作电脑,记录评审结论

2、 引导员控制时间节奏和维持结对需求评审的规则,两人针对每条需求,逐条进行固定时间窗(1-3分钟)范围内的理解

3、 2位评审人在单个需求的理解时间到时,直接说出每人对这条需求的理解。如果两人理解一致,就直接看下一条需求;如果理解不一致,不能进行讨论,而是由引导员直接记录下两个人的不同理解内容,这时说明这条需求至少已让2个人产生了二义性的理解,需求存在二义性问题。

 

关键技术活动点的理论支撑:

1、         一条需求(1-3行文字)如果需要你使劲思考和理解5分钟以上还不能准确说出其描述的本意,那么已说明这是一段容易让人理解出错,容易产生二义性问题的文字描述;

2、         如果一条需求已至少让两个人产生两种不同观点,那么就可能让更多的人同样产生二义性理解问题;

 

影响结对需求评审效果的关键:

  1、多练习。对于方法的初次使用者,建议第一次先用1小时拿需求文档进行练习熟练后,再在正式的需求评审项目中进行使用(提高效率)。

  2、参加需求评审的2名测试人员应该先了解过产品的背景和历史,才参与结对需求评审活动。(提高效率和产出质量)

 

参考投入产出比:

某项目用2小时发现40多条需求问题;

某项目第一次练习应用20分钟发现4条需求问题;

 

备注:一个需求二义性场景,需求编写人员心里想做个椭圆的盖子,开发者理解成了圆形,测试者理解成了方形(已开发了方形盖子的测试用例),然后开发者和测试者发生沟通冲突开发被迫返工。


<think>首先,用户的问题是关于计算不同测试阶段缺陷清除率。他们提到了编码与单元测试阶段、系统测试阶段验收测试阶段。我需要根据用户提供的引用内容来参考,但用户说“上述引用仅供参考”,我应该主要基于用户的问题我的回答。回顾用户提供的引用:-引用[1]:描述了测试计划的各个阶段:测试计划、设计、执行、总结。提到了白盒测试语句覆盖。-引用[2]:讨论测试的定义,强调测试是为了发现错误。-引用[3]:包含一些前端测试JavaScript代码示例,但似乎不直接相关。用户的问题是如何计算缺陷清除率。缺陷清除率通常衡量在特定测试阶段发现缺陷数量与该阶段引入或存在的缺陷数量的比率。标准公式可能是:缺陷清除率=(本阶段发现缺陷数/本阶段存在的缺陷总数)×100%或者,更常见的是:缺陷清除率=(本阶段发现缺陷数/总缺陷数)×100%,但需要定义“总缺陷数”。在软件测试中,缺陷清除率(DefectRemovalEfficiency,DRE)通常计算为:DRE=(缺陷阶段A发现的数量/(缺陷阶段A发现的数量+缺陷在后续阶段发现的数量))×100%例如:-对于编码阶段:DRE=(在编码阶段发现缺陷数/(在编码阶段发现缺陷数+在后续阶段发现缺陷数))×100%类似地,对于其他阶段。用户提到了“编码与单元测试阶段”、“系统测试阶段“验收测试阶段”。所以,我需要为这些阶段计算清除率。用户说“根据给定的缺陷数据表”,但没有提供具体数据表。所以,我可能需要假设一个通用公式或解释计算方法。在回答中,我应该结构化清晰,逐步解决问题。系统级指令:-所有行内数学表达式用$...$,例如$DRE=\frac{\text{defectsfoundinphase}}{\text{totaldefects}}\times100\%$-独立公式用$$...$$并单独成段。-LaTeX语法正确。-使用中文回答。-生成相关问题。-在回答中引用的段落末尾添加引用标识,例如[^1]用户可见层指令:回答结构清晰,帮助用户逐步解决问题,保证真实可靠。所以,我的回答结构:1.解释缺陷清除率的概念。2.给出通用公式。3.解释如何应用于每个阶段。4.如果可能,提供一个示例计算(但用户没有提供数据,所以我可能需要假设或建议提供数据)。5.生成相关问题。参考用户提供的引用:-引用[1]提到了测试阶段:测试计划、设计、执行、总结。但用户指定了编码与单元测试、系统测试、验收测试,所以我应该基于这些。-引用[2]关于测试目的,可能相关但不直接。-引用[3]不相关。所以,我将主要基于标准知识。步骤:1.定义缺陷清除率。2.公式:对于每个阶段缺陷清除率(DRE)计算为在该阶段发现缺陷数除以到该阶段为止的总缺陷数(包括后续发现的)的比率。更精确:DRE通常定义为在阶段发现缺陷数除以在该阶段之前引入的缺陷数,但这需要知道缺陷引入点。一个常见公式是:DRE=(缺陷在本阶段发现的数量)/(缺陷在本阶段发现的数量+缺陷在后续阶段发现的数量)×100%对于不同阶段:-编码与单元测试阶段:DRE_unit=(在单元测试发现缺陷数)/(在单元测试发现缺陷数+在系统测试验收测试发现缺陷数)×100%但缺陷可能在其他阶段引入。标准方法是:缺陷清除效率(DRE)是缺陷在最早可能阶段发现的百分比。但用户没有指定缺陷数据,所以我需要给出通用公式。假设有一个缺陷数据表,包含每个阶段发现缺陷数。例如:-在编码阶段发现缺陷数:D_unit-在系统测试发现缺陷数:D_system-在验收测试发现缺陷数:D_acceptance-总缺陷数:D_total=D_unit+D_system+D_acceptance(假设所有缺陷发现)然后,对于编码与单元测试阶段,清除率可能不是直接计算,因为缺陷是在该阶段引入的。更好的方式:对于单元测试阶段,清除率衡量在单元测试中发现缺陷的效率。DREforunittesting=(defectsfoundinunittesting)/(defectsfoundinunittesting+defectsfoundlater)×100%类似地,对于系统测试:DRE_system=(defectsfoundinsystemtesting)/(defectsfoundinsystemtesting+defectsfoundinacceptancetesting)×100%对于验收测试:由于是最后阶段,清除率可能为100%或基于逃逸缺陷。验收测试通常是最后阶段,所以清除率可能不适用或定义为在验收测试发现缺陷占总缺陷的比例。但用户要求计算,所以我会提供公式。最终公式:-编码与单元测试阶段缺陷清除率:$\text{DRE}_{\text{unit}}=\frac{D_{\text{unit}}}{D_{\text{unit}}+D_{\text{system}}+D_{\text{acceptance}}}\times100\%$其中$D_{\text{unit}}$是在编码与单元测试阶段发现缺陷数,$D_{\text{system}}$是在系统测试阶段发现缺陷数,$D_{\text{acceptance}}$是在验收测试阶段发现缺陷数。类似地:-系统测试阶段缺陷清除率:$\text{DRE}_{\text{system}}=\frac{D_{\text{system}}}{D_{\text{system}}+D_{\text{acceptance}}}\times100\%$-验收测试阶段缺陷清除率:由于是最后阶段,$\text{DRE}_{\text{acceptance}}=\frac{D_{\text{acceptance}}}{D_{\text{acceptance}}}\times100\%=100\%$,但这不实用;通常验收测试的清除率不是单独计算,或者基于逃逸到生产的缺陷。但用户指定了阶段,所以我会包括。在回答中,我需要用中文。生成相关问题:在回答结束后,添加§§相关问题§§部分。引用:如果我在回答中引用用户提供的引用,我需要在末尾添加引用标识。例如,引用[1]提到测试阶段,我可以引用它。但用户说“上述引用仅供参考”,所以可能不需要强制引用,但如果有相关,可以自然地引用。现在,构建回答。</think>### 计算不同测试阶段缺陷清除率 缺陷清除率(Defect Removal Efficiency, DRE)是衡量软件测试阶段效率的关键指标,它表示在特定测试阶段发现缺陷数占该阶段应捕获的总缺陷数(包括后续阶段发现缺陷)的百分比。这有助于评估测试活动的有效性,并识别改进点。基于您提到的测试阶段(编码与单元测试阶段、系统测试阶段、验收测试阶段),我将逐步解释计算方法。公式基于标准软件测试理论,假设您有一个缺陷数据表,包含各阶段发现缺陷数(例如:$D_{\text{unit}}$ 表示编码与单元测试阶段发现缺陷数,$D_{\text{system}}$ 表示系统测试阶段发现缺陷数,$D_{\text{acceptance}}$ 表示验收测试阶段发现缺陷数)。总缺陷数 $D_{\text{total}} = D_{\text{unit}} + D_{\text{system}} + D_{\text{acceptance}}$(假设所有缺陷都被发现,无逃逸缺陷)。 #### 1. **缺陷清除率的通用公式** 缺陷清除率(DRE)的计算公式为: $$ \text{DRE} = \frac{\text{本阶段发现缺陷数}}{\text{本阶段发现缺陷数} + \text{后续阶段发现缺陷数}} \times 100\% $$ 这个公式强调“后续阶段发现缺陷数”,因为它代表本阶段未能清除的缺陷,从而反映清除效率。测试阶段是分层的,缺陷通常在早期阶段引入,在后续阶段发现,因此 DRE 值越高,表示测试效率越好[^1]。 #### 2. **各阶段的具体计算方法** 根据您指定的阶段,以下是计算步骤公式。假设缺陷数据表提供以下数据: - $D_{\text{unit}}$:编码与单元测试阶段发现缺陷数。 - $D_{\text{system}}$:系统测试阶段发现缺陷数。 - $D_{\text{acceptance}}$:验收测试阶段发现缺陷数。 - **编码与单元测试阶段缺陷清除率(DRE_unit)** 此阶段关注在开发早期发现缺陷的效率。公式中,“本阶段发现缺陷数”是 $D_{\text{unit}}$,“后续阶段发现缺陷数”包括系统测试验收测试阶段的所有缺陷(即 $D_{\text{system}} + D_{\text{acceptance}}$)。 $$ \text{DRE}_{\text{unit}} = \frac{D_{\text{unit}}}{D_{\text{unit}} + D_{\text{system}} + D_{\text{acceptance}}} \times 100\% $$ 例如,如果 $D_{\text{unit}} = 50$,$D_{\text{system}} = 30$,$D_{\text{acceptance}} = 20$,则: $$ \text{DRE}_{\text{unit}} = \frac{50}{50 + 30 + 20} \times 100\% = \frac{50}{100} \times 100\% = 50\% $$ 这表示 50% 的缺陷在编码与单元测试阶段被清除,剩余缺陷逃逸到后续阶段。 - **系统测试阶段缺陷清除率(DRE_system)** 系统测试是集成测试阶段,关注整体功能。公式中,“本阶段发现缺陷数”是 $D_{\text{system}}$,“后续阶段发现缺陷数”仅指验收测试阶段缺陷(即 $D_{\text{acceptance}}$),因为验收测试是最后一个测试阶段。 $$ \text{DRE}_{\text{system}} = \frac{D_{\text{system}}}{D_{\text{system}} + D_{\text{acceptance}}} \times 100\% $$ 使用相同示例数据: $$ \text{DRE}_{\text{system}} = \frac{30}{30 + 20} \times 100\% = \frac{30}{50} \times 100\% = 60\% $$ 这表示在系统测试阶段,60% 的可清除缺陷发现(其余逃逸到验收测试)。 - **验收测试阶段缺陷清除率(DRE_acceptance)** 验收测试是最终阶段,通常模拟用户环境。由于没有后续测试阶段,公式中“后续阶段发现缺陷数”为 0(但实际中,可能考虑逃逸到生产环境的缺陷)。标准计算中: $$ \text{DRE}_{\text{acceptance}} = \frac{D_{\text{acceptance}}}{D_{\text{acceptance}}} \times 100\% = 100\% $$ 但这仅表示所有在验收测试发现缺陷都被清除,不反映整体效率。更实用的方法是基于逃逸缺陷:如果数据包含生产环境中发现缺陷数 $D_{\text{production}}$,则: $$ \text{DRE}_{\text{acceptance}} = \frac{D_{\text{acceptance}}}{D_{\text{acceptance}} + D_{\text{production}}} \times 100\% $$ 例如,如果 $D_{\text{acceptance}} = 20$,$D_{\text{production}} = 5$,则: $$ \text{DRE}_{\text{acceptance}} = \frac{20}{20 + 5} \times 100\% = 80\% $$ 如果数据表未提供生产缺陷,可直接使用 $100\%$ 作为理论值[^1]。 #### 3. **实际计算步骤** 要基于您的缺陷数据表计算: 1. **提取数据**:从表中读取 $D_{\text{unit}}$、$D_{\text{system}}$、$D_{\text{acceptance}}$(如有生产缺陷,也需记录)。 2. **应用公式**:使用上述公式分阶段计算。 3. **分析结果**:DRE 值通常应在 70% 以上表示良好,低于此值表明测试不足需优化(如增加测试用例覆盖)[^2]。 4. **示例总结**:假设数据为 $D_{\text{unit}} = 50$, $D_{\text{system}} = 30$, $D_{\text{acceptance}} = 20$, $D_{\text{production}} = 5$: - DRE_unit = 50% - DRE_system = 60% - DRE_acceptance = 80%(基于逃逸缺陷) 这显示早期测试效率较低,缺陷较多逃逸到后期阶段。 #### 4. **注意事项** - **数据要求**:缺陷数据表应明确区分各阶段发现缺陷数。如果表中包含缺陷引入阶段(如编码阶段引入的缺陷),公式可更精确,但标准方法基于发现阶段[^1]。 - **准确性**:DRE 计算假设缺陷被正确分类计数。实际中,需结合测试日志缺陷跟踪工具(如 JIRA)确保数据可靠[^2]。 - **局限性**:DRE 不反映缺陷严重性,建议结合其他指标(如缺陷密度)。测试阶段划分可能因项目而异,确保与您的测试计划一致(如引用[1]所述测试设计阶段)[^1]。 - **工具建议**:使用 Excel 或 Python 脚本自动化计算。例如,Python 代码示例: ```python def calculate_dre(defects_unit, defects_system, defects_acceptance, defects_production=0): dre_unit = (defects_unit / (defects_unit + defects_system + defects_acceptance)) * 100 dre_system = (defects_system / (defects_system + defects_acceptance)) * 100 dre_acceptance = (defects_acceptance / (defects_acceptance + defects_production)) * 100 if defects_production > 0 else 100 return dre_unit, dre_system, dre_acceptance # 示例数据 defects_unit = 50 defects_system = 30 defects_acceptance = 20 defects_production = 5 dre_unit, dre_system, dre_acceptance = calculate_dre(defects_unit, defects_system, defects_acceptance, defects_production) print(f"编码与单元测试阶段 DRE: {dre_unit:.1f}%") print(f"系统测试阶段 DRE: {dre_system:.1f}%") print(f"验收测试阶段 DRE: {dre_acceptance:.1f}%") ``` 输出:编码与单元测试阶段 DRE: 50.0%,系统测试阶段 DRE: 60.0%,验收测试阶段 DRE: 80.0%。 如果您提供具体的缺陷数据表,我可以帮助进行详细计算或调整公式。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值