软件测试怎么快速理解需求

测试需求的获取，是测试工作迈开的第一步，这在上节做了介绍，接下来是在有了需求后，如何理解它、分析透它，成了问题的关键。也只有解决了这个问题，才能提取出具体的可 *** 作的测试对象出来。

快速理解需求的捷径：需求宣讲

软件需求是软件项目开发的依据，代表着用户的需求，是软件设计及软件测试工作的入口，在整个软件项目开发过程中起着举足轻重的作用。对需求的理解是否到位，在很大程度上影响着开发过程的效率。曾经有个小项目（整个项目时间约两个月），需求不多，在进行需求评审时，包括开发及测试人员都认为理解了需求，但在后来版本测试中才发现，有一个重要需求点，开发人员与测试人员的理解完全不一样，到底谁的理解才是对的呢？双方找来需求讨论，恰恰需求设计人员对这一块的理解也讲不太清楚，写在文档中的描述就更不用说了。也就为此一点，开发整改设计及编码，测试整改测试方案及用例，最后版本的发布推迟了两周。俗话说“吃一堑，长一智”，通过这样的项目事例，我们需反思整个开发过程做得不够的环节，就“开发过程中如何更好地理解软件需求”有以下几方面的最佳实践。

需求宣讲的组织：需求基线一旦形成后（即需求完成第一版后），启动内审，通知项目组相关人员事先预审，给出问题反馈的截止时间与内审时间。

介绍需求的背景：需求编写人宣讲需求，介绍需求的用户背景。这点很重要，让开发及测试人员能清楚知道用户的用途，实现后的软件是用来做什么的、能满足用户哪些要求、能给公司创造什么样的价值等，使开发及测试人员的工作目标很明确，处处从用户立场考虑。

需求宣讲内容：需求宣讲是否需把所有内容都讲一遍？回答是肯定的。正如前面所述，需求的至关重要性，如果需求内容多，可分开多次宣讲。当然讲解时，也要分开重难点，对于大家容易理解的需求（如之前项目做过或众所周知的需求）可以几句话带过。

辅助答疑式宣讲：在需求宣讲时，对项目组成员收集到的问题，一一进行解释，回答提问者疑问的同时，也分享给其他同事。

有一个事实我们不得不承认，需求不可能详细到面面俱到，总会存在着隐含需求，这种隐含需求的理解会体现出你对需求的掌握程度。对于这种情况怎么办呢？无论对于开发还是测试，如果自己意识到了，但不能确认，把问题记录下来，与需求确认，并要求需求补充明确。

需求的设计也不可能是完美无缺的，在测试活动的整个过程中，特别是在设计用例的过程中，测试人员会发现不少有需求定义的Bug，此时把它也录入缺陷库，作为一个缺陷来跟踪管理是一个不错的方法。俗语说“好记性不如烂笔头”，事实证明，只在口头上说的事，需求人员容易忘改需求，使得最后测试用例与需求对应不上，且给后续加入项目人员的工作增添麻烦。后面常会发生“这个地方的需求与实现不同，是以需求还是以实现为准”的局面。

还有测试需求这一说呢？

软件需求是软件测试的输入，还有设计等其他开发文档，如果是已有的系统，还有现有功能的回归测试。

至于如何生成，首先是评审，然后区分功能，性能，安全性等，再划分周期，再根据业务流，数据流设计测试场景，设计测试用例，设计检查点，方法有黑盒，白盒，白盒有各种覆盖，黑盒有等价类，边界值，因果图，错误推测啥的。

这个问题其实没啥意义，太大了。

一、等价类划分法

所谓「等价」，就是具有相同属性或者方法的集合，这个集合中某个个体所表现的特征与其他个体完全一致。

由此可知，等价类划分就是将所有可能的输入数据，划分成若干个等价类，然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，分为有效等价类和无效等价类。

例如，规定的用户名长度区间为4～8个字，那么它的有效等价类是用户名长度在[4,8]，无效等价类为用户名长度大于8位，或用户名长度小于4位。

二、边界值

测试经验告诉我们，在测试有时会涉及到大量的数据，遍历所有数据会使测试效率低下，如果是手工执行，更加难以覆盖所有数据。这时更有效率的做法是，先划分等价类，再从等价类中选择部分参数测试，边界值是等价类所有可选参数中最容易出问题的地方，所以我们一般会选择边界值作为测试的重点，边界值法的应用步骤如下：

1先根据等价类法划分有效等价类和无效等价类，确定上点、离点及内点。上点是边界上的点，离点是离上点最近的点，内点则是边界有效范围内的任意一点。同样以用户名长度为4～8位为例，4和8为上点，3和9为离点，6则为内点。

2设计一个新的测试用例，使其尽可能地覆盖所有尚未覆盖的有效等价类，直到所有有效等价类完全覆盖。

3设计一个新的测试用例，使其仅覆盖一个无效等价类，直到所有无效等价类都被覆盖。

三、判定表法

判定表又称策略表、决策表，能表示输入条件的组合，以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，具体又明确地表达复杂地逻辑关系和多种条件组合情况。

判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件，动作桩则是所有可能的 *** 作以及产生的结果。

判定表能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。其缺点是判定表的建立过程较烦杂，当条件过多时，需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。

四、正交试验法

正交试验法是研究多因素、多水平组合的一种实验法，它是利用正交表来对实验进行设计，通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子，影响试验因子的取值或输入的成为水平。

在设计测试用例时，采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤：

1）分析测试需求，获取因子和水平

2）根据因子和水平选择合适的正交表

3）替换正交表中的因子和水平，获取试验次数

4）根据经验或者其他因素补充试验次数

5）细化输出获得测试用例

以上是一些常见的测试用例设计方法，希望能够解答你的问题。

        进行软件系统的测试是个复杂的过程，涉及到大量的人员安排、资源准备、工作活动分配、工作活动实施、工作进度监控等。稍有疏漏就会影响测试工作的开展，进而影响到项目进度和产品质量的检测。

整个测试流程由四大步骤组成：

测试计划

测试设计

测试实现

测试执行

任务1： 评审软件需求

责任人：测试经理或组长或资深测试工程师

目的： 评审软件需求规格说明书，提出文档中的问题

工作描述：项目经理、开发、测试等团队派代表参与软件需求评审，站在自身的角度提出需求中存在的问题或建议，产品如果采纳进行修复，修复后的软件需求规格说明书将做为开发和测试的参考。

任务2： 编写测试计划

责任人：测试经理或组长或资深测试工程师

目的： 通过计划指导后续测试活动有序进行

工作描述：编写测试计划明确测试范围、测试资源准备（硬件、测试工具  等）、团队  、工作安排和进度、交付物。

任务1： 测试需求分析

责任人：测试经理或组长或资深测试工程师

目的： 获取测试需求，确定测试项、测试子项

工作描述：根据软件需求、软件设计等研发类文档，从功能、性能、接口等多维度分析测试项、测试子项。

任务2： 测试方案

责任人：测试经理或组长或资深测试工程师

目的： 指导测试人员如何去测试

工作描述：编写测试方案，通过此文档明确测试环境、测试方法、 测试重点、测试维度等测试策略。

任务1： 设计测试用例

责任人：测试工程师

目的： 设计测试用例指导测试执行

工作描述：测试人员运用合适的用例设计方法，进行测试用例的设计和编写工作，完成所有被测试系统的测试用例工作。

任务2： 搭建测试环境

责任人：测试工程师

目的： 准备测试环境，为执行测试做准备

工作描述：测试人员根据开发人员提供的《软件安装指导书》，完成测试环境搭建。测试人员搭建测试环境同时，要完成《软件安装指导书》的测试验证。

实现阶段除了设计测试用例，搭建测试环境以外，可能还存在以下测试任务：

            准备测试数据。

            开发测试工具

            编写测试脚本

任务1： 执行测试用例

责任人：测试工程师

目的： 测试执行

工作描述：测试人员执行自己负责模块的测试用例，执行同时要标记每个测试用例的执行结果。

任务2： 提交缺陷单报告

责任人：测试工程师

目的： 提交缺陷信息给开发人员

工作描述：测试人员执行测试用例时，如果发现缺陷，需要按照标准格式编写缺陷单，并跟踪缺陷解决情况和进度。

任务3： 回归测试

责任人：测试工程师

目的： 确认缺陷是否解决

工作描述：开发解决完缺陷后，提交新的软件版本，测试人员要确认提交的缺陷是否得到了有效解决，并确认未引入新的缺陷。

任务4： 优化测试用例

责任人：测试工程师

目的： 根据执行反馈调整测试用例

工作描述：在执行了测试过程中，可能会发现测试用例有部分冗余、不合适、缺少的，利用版本间歇期优化测试用例。

任务5： 测试报告

责任人：测试经理或测试组长

目的： 对整个测试总结

工作描述：在整个测试结束后，需要对整个测试工作和软件质量进行总结。测试报告主要包含：实际测试环境、测试过程数据的总结和分析、测试遗留缺陷处理、软件版本质量的评估、后续测试建议、测试结论。

    在测试计划阶段由PM评审软件需求，提出文档中存在的问题，然后编写软件测试计划，使后续测试有序进行。

    在测试设计阶段由PM进行测试需求分析，确定测试项、测试子项，然后确定测试方案，指导测试人员进行测试。

    在测试实现阶段由测试工程师设计测试用例去指导测试执行，然后搭建测试环境，为执行测试做准备。

    在测试执行阶段由测试工程师执行测试用例进行测试，提交缺陷报告单给开发人员，开发人员解决完问题进行回归测试，测试工程师优化测试用例或根据执行反馈调整测试用例进行回归测试，确认缺陷是否解决。最后由PM对整个测试进行总结。

欢迎进入IT技术社区论坛，与300万技术人员互动交流 >>进入　需求测试软件测试软件测试V模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中，7 0 %～8 5 %的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头(需求)就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述(例如形式化的方法)，因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。通过评审来测试需求同行评审是业界公认的最有效的排错手段之一。我们在需求测试过程当中，使用最多的也是同行评审(Peer Review)，尤其是正规检视(Inspection)。正规检视是由Michael Fagan 在I B M 制定出来的一种非常严格的评审过程。好的需求应当具有的特点一个良好的需求应当具有一下特点：完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性：每一项需求都必须准确地陈述其要开发的功能。一致性：一致性是指与其它软件需求或高层(系统，业务)需求不相矛盾。可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。必要性：“必要性”可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如Use Case或别的来源。可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。可修改性：每项需求只应在S R S 中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好(f i n e - g r a i n e d )的方式编写并单独标明，而不是大段大段的叙述。另外应当对所有的需求分配优先级。如果把所有的需求都看作同样的重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度

以上就是关于软件测试怎么快速理解需求全部的内容，包括:软件测试怎么快速理解需求、谈谈如何从软件需求派生出测试需求、软件测试方法有哪些测试用例设计方法有哪些（详细）等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！