技术学习：软件测试中如何实现充分性测试（测试充分性分析）

如果你想在做软件测试时保质保量，就需要正确的测试。 充分的测试意味着覆盖所有需要覆盖的场景。

如何全面覆盖这个领域，尤其是时间有限、任务繁重的情况下？

根据我多年的经验，总结一些，分享给大家。希望它们对您有用。

第一早期干预测试

那又怎样？ 什么时候是测试干预的最佳时间？测试可能会在需求明确和开发开始之前进行干预以了解需求。要求相关内容。

该区域通常有两个阶段。

第一阶段是需求澄清阶段。 在这个阶段，需求接口专家向开发人员解释详细的需求以及需求的实现能力。 此时您可以加入测试并一起聆听。 听完之后，我们会对这个需求有一个大概的了解，知道这个功能是做什么的，输入输出是什么，然后准备详细的实施方案。

第二阶段是明确制定实施方案。 在此阶段，涉及的开发人员通常与需求提出者和接口者一起审查需求的功能实现计划和详细逻辑。 我们公司此时也参与其中。 算法的决策逻辑是什么，值是什么，输入的值类型是什么，取哪个表的什么字段的值等等，根据开发时提到的实现方案和逻辑就可以理解。

当然，一些小型企业可能没有时间执行这些步骤。 一旦有了需求，我们就可以口头讨论开发，直接实施，无需进一步澄清。 这个时候我们应该做什么呢？ 我们别无选择，只能自己主动去找。 在开发沟通中，如果遇到与开发理解有出入的地方，请向产品经理或者需求协调员询问，避免因需求不明确而造成不必要的问题，为后期测试用例创建时需要找到并再次检查。 。

No.2 测试分析，测试用例设计

根据目前的理解，下一步就是将你脑子里的信息转换成文本并创建一个列表。 分析测试场景。

为什么我们需要将这些信息转换成文本并根据我们的想法直接列出测试场景？因为这些信息在我们的头脑中很容易被遗忘并且不是很清楚因为没有。 只有对信息进行整理和组织，才能形成对我们有用的信息。

不知道你是否遇到过这样的情况。 您已经阅读了文档或听到了需求接口人员或开发人员的解释。 您也知道它是什么并且感觉良好。 然而，在实际编写测试用例时，仍然存在一些歧义。

而将理解的信息翻译成文字将帮助你成功解决这个问题。

如何组织这些信息我通常按​​以下顺序工作：

1）首先分析需求背景和业务需求。

写下您到目前为止学到的所有背景要求。 如有疑问，请及时询问相关人员，直至澄清。

例如，需求背景如下。 业务人员在一线工作时，会发现有些国家对某些模块需要特殊的型号，而另一些国家则默认配置了不同的型号。 系统命令。 希望在配置该国家订单时，系统能够自动识别并更换为指定型号的模块。

在写需求背景的时候，除了写上面这一段之外，还需要写明“一些国家”，即是哪些国家。 您还需要清楚地说明名称是什么、代码是什么以及模块模型。 更换之前您使用的是哪个模块？型号是多少？ 更换了什么模块，型号是多少？

2）分析需求实现方案和逻辑

这个应该尽早学习. 开发实施计划和逻辑列表。 如有必要，可以用图表来说明开发实施流程、逻辑决策过程、数据走向等。

例如，针对上述需求，制定实施计划时需要知道订单中应包含哪些信息。 需要更换模块型号的国家、以及如何获取模块型号。 、替换后的结果体现在哪里？等等。

现在我们需要在这个分析模块中将它们全部列出来，并一一揭晓。

3）分析测试点和测试要素

在前两项分析的基础上，快速分析测试点和需要整理的关键点。 。 。 关注点及更多

描述上述模块模型的替换。 我们知道国家、指定的模块型号和替换的模块型号反映在哪里。 这些都是我们关心的问题。 同时，您还应该知道，这种替代型号不受指定国家/地区以外的型号的影响。 这些是测试的要点和要素。

4）列出测试场景

根据上面的分析，就可以把需要测试的场景写成表格的形式了。

5）将测试场景转换为测试用例

此时就可以输出测试用例了。 那么，我们的用例是否足够？输出结果是否正确？

接下来，请相关人员查看文档和用例。

No.3 测试用例评审

测试用例评审不仅评审测试用例，还评审需求理解和想法。 这就是为什么在审查期间应该首先讨论它。 我们将讨论测试分析文档，然后提取测试用例并重点关注测试的输入和输出结果。

这样，在开发人员和系统设计人员的帮助下，可以及早发现被忽视的用例和测试点的缺陷，并及时补充测试用例，从而改进测试用例。

我之前公司的测试用例审查非常严格。 每个参与审核的人都必须提出问题，避免出现刚刚参加审核但没有审核的人。 有些问题会留到最后。

第四，严格按照测试用例执行测试

这很重要，但为什么会这样呢？ 因为无论你的测试用例设计得多么好，如果你不遵循它们，你的测试就不好。

我仍然记得当我为我的需求创建测试用例时。 当我复习完考试后，我感觉我已经记住了大部分内容，所以我就按照我记得的方式开始测试，而不是一个一个地运行测试用例。 上次测试非常快并且几乎没有问题。

后来在做回归测试的时候，突然发现还有几个问题。 原因是我没有完全覆盖测试用例，遗漏了两个相关点。 在此之后我会再试一次。 我没有勇气留下测试用例，凭着记忆自己测试了一下。

No.5 需求分解

根据需求的不同，接收或测试可能会有延迟。 该功能很复杂，必须按时触发。 这个时候我该怎么办呢？

需求测试用例完成后，按 。该功能被分成几个较小的功能点，并分配给多个团队成员进行测试（当然，在交给任何参与测试的人之前，应该详细说明所需的功能）。 测试过程中应保持定期沟通，避免相互重复。 测试并不与测试分开。

我记得当时有一个web系统功能。 早期我因为忙于其他紧迫的事情而推迟了。 后来我把它提上日程，发现时间不够。 太多，您将无法自己测试所有内容。 这时我主动和老板沟通，又请了两个同事和我一起测试。 然后我在两位同事的帮助下成功测试了这个功能。

No.6 交叉测试

对于大规模的需求或者功能复杂的需求，必须由多人进行交叉测试。 这种类型的测试可以在系统测试期间执行。 之前我公司的项目中，我们每次做系统测试的时候都会有这样的安排，避免后期回归测试出现更多问题。

七、关键功能要及时跟踪，进行测试充分性分析

对于功能复杂、风险较高的项目，应在每轮测试后进行测试。 测试适宜性分析，及时做出调整。

有一次，我们做了比较大的改变。 这一变化涉及软件流程的核心部分。 这意味着内容很多，但测试的时间不多了。 我只有两周的时间，我该怎么办？ 组长首先根据受影响的功能点将变更进行分解，并分配给三个人进行测试。 每天，她都会跟踪测试进度统计，分析问题分布点，跟踪问题修复情况，并据此及时调整测试策略，有重点、有条不紊地在两周的时间里进行了测试。 ，终于这个功能上线成功了。

上述作者的经历与横向知识网络创建交流平台914172719类似。 群内有各种技术同行交流、学习资料、面试经历等，其中有一些使用jenkins、docker、mutebank、python编程等，花更多的精力在更深层次的学习上是有需要的。 每项技能只有掌握到一定深度，才能称为完整的知识体系。

最后： 您可以关注公众号：Sad Latio！自从加入公司以来，我有很多信息想与您分享！ 这些信息包括了面试官在面试时应该问到的所有知识点，比如基础知识、Linux要领、shell、互联网编程原理、Mysql数据库、抓包工具等话题，还包括了很多测试行业的常识，例如： 接口测试工具。 、高级测试-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、高级持续集成测试、测试架构开发测试框架、性能测试、安全测试等等。

如果您觉得我的博客有用或者您喜欢博客内容，请一键给我“点赞”、“评论”、“收藏”！

---

推荐文章

求职面试，转行面试，软件测试人员应该知道的面试技巧！

面试经历：一线城市搬砖！我又面试软件测试岗位了。 5000就够了...

面试官：工作了3年了，你还来面试初级测试吗？不幸的是，软件测试工程师这个职位需要用双引号括起来。 ..

什么样的人适合做软件测试？

按时下班的人在我之前升职了..

我换过很多工作。考试期间出现过几次，然后就消失了...