蒙珣的博客

活好当下，做好今天该做的事情。

0%

软件测试常规提问

Posted on Edited on In
Symbols count in article: 1.9k Reading time ≈ 2 mins.

问题

  1. 什么是测试用例

    • 设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果

  2. 如果软件按照测试用例达不到预期结果这么办？

    • 如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表明软件人员已经c测出软件有缺陷，这有时候就必须将这个问题标示出来，并通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内
    • 软件测试工程师取得新的测试版本后，必须利用同一个测试用例来测试这个问题，确保该问题已修改完成。

  3. 开发人员说缺陷修复了，你认可吗？(回归测试)

    • 软件测试工程师取得新的测试版本后，必须利用同一个测试用例来测试这个问题，确保该问题已修改完成。

  4. 测试用例真的有必要耗费时间进行设计和编写吗？

  5. 时间不够用的情况下，还要进行详细的测试用例吗

  1. 测试用例需要经常更新吗？

    • 必须更新，尤其是发现过缺陷的测试用例。“杀虫剂效应”，一个发现过缺陷的测试用例，就相当于杀虫剂。必须使用“更强的杀虫剂”——新的测试用例（与之前的用例中数据类型保持一致）进行重新测试。

  2. 现在有一个文本框，有一个规则：xxxxx；请对这个规则，进行输入内容的等价类划分（尽可能详细划分）

  3. 缺陷的严重程度和缺陷的优先级有什么关系？

    • 二者之间没有任何直接的关系。
    • 不要认为严重的缺陷，修复优先级就高。
    • 如果碰到优先级和严重程度都高的缺陷，也只是偶然。例如QQ的帮助按钮，会有经常闪退的现象。严重程度很高，但是优先级就很低。

  4. 提交缺陷时能不能夸大或降低缺陷的严重程度或优先级？

    • 不能搞“狼来了”
    • 也不能私人关系“帮”好朋友减少不良影响

  5. 针对你工作中发现的一个bug,说说这个bug的处理过程。（缺陷的生命周期中，每一个环节由谁做什么）

    • 发现缺陷后，先再做一遍，发现真的是缺陷后在做提交缺陷。由主管领导确认是缺陷后，分配给相关人员去修复缺陷。在他们修复后，将状态改为已修复，我在去执行之前所发现的测试用例，去验证缺陷是否被真的修复。除此之外还应该，还去设计一条新的测试用例进行验证（对测试用例具有免疫性）。如果没有问题由我去关闭测试用例。

  6. 测试需求和测试用例、缺陷报告的关系？

    1. 测试的基本流程：获取测试需求——编写测试用例——制定测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本的测试

      • 获取测试需求是测试的工作重点，也是第一步。通过需求的分析，了解和掌握测试的方向和内容。设定测试中需求的正反向和优先级。例如：

        1. 分析出系统的模块和组织结构
        2. 分析出软件的基本功能和运行流程（业务分析）。包括分析出有那些人和那些角色要用
        3. 识别出软件的重要功能和次要功能获取测试需求的过程中，测试人员要有相应的分析成果。一般用思维导图进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析。

      • 当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计，也就是每一个需求点，都要被测。因此测试的过程中，衡量需求的覆盖程度，就非常重要了。使用：需求的覆盖程度 = 被测试用例覆盖的需求数 / 需求点总数

        如果需求覆盖度<100%，那一定说明测试覆盖度不够

      • 测试中，最能体现测试人员工作量的指标就是缺陷的数量和用例的数量

        1. 设计的测试用例总量 TC
        2. 执行的测试用例数量 EC
        3. 未执行的测试用例总量 WC
        4. 执行通过的测试用例总量 SC
        5. 执行失败的测试用例总量 FC
        6. 提交的缺陷总量 BC（Bug Counts）
        • 以上几个数据，他们要符合如下的数量关系
          1. TC 大于等于 EC
          2. TC = EC + WC
          3. EC = SC + FC
          4. BC 大于等于 FC。提交的Bug数量，多于未通过的用例数。一条测试用例的预期结果数量是固定的（甚至是唯一的）。测试过程中发现的缺陷，除一部分是测试用例执行失败带来的，还有一部分应该是测试人员自身的经验和直觉（其他知识）带来的
          5. 通过 SC/EC 可以表现出系统的质量是否合格
          6. 通过 EC/TC 可以表现出系统的需求是否被满足

  7. 测试时间不够的情况下，（还有大量的内容没有测试），软件能不能发布/上线/发版？

  8. 有的严重bug没修复，但是赶着上线，能不能通融/放任？

  9. 需求重要吗？错误的需求对测试有什么样的影响

  10. 你觉得软件测试在什么阶段介入比较好？为什么

  11. 软件发布了，但是有缺陷，是测试人员的错吗

  12. 你写过测试计划吗？包含什么内容？测试计划可以被修改吗？

  13. 设计与编写测试用例有什么区别？设计是一项脑力活动，编写从本质上是一种体力活动

  14. 针对已经发现了缺陷的模块，如何进行深入测试？对发现却显得模块使劲测，另外关联的模块也要进行测试（缺陷有一种集群效应）

  15. 软件项目不着急的时候，测试任务完成了，你会干什么？反复测试

  16. 软件项目上线了/发布了，还要进行测试吗？

  17. 你觉得你有什么样的缺点？（不能说的：粗心、耐心不够、不善沟通、语言表达能力不行）（对于工作比较爱计较，和追求完美。穷就不舍。认死理）