以下高能预警，测试用例知识全集----所有关于测试用例的问题，只够了

                                                                                                                                                                               20个测试用例问题20个测试用例问题20个测试用例问题--20答

1.测试用例是什么？答：测试用例的设计是如何覆盖所有软件的状态，即在满足输入/输出的一组条件下，软件运行是一系列有序、可控的状态变化过程。

2.设计用例有必要吗？答：如果不写下来，测试点很可能会在实施过程中遗漏。此外，用例评估和用例总结也不方便，对以后的测试工作没有太大的改进作用。因此，必须编写测试用例，粒度取决于情况。对于测试人员少、上线时间紧的项目，只能制作思维导图列出测试点。

3.设计用例的好处？答：设计用例的过程可以更深入地了解需求，熟悉每个功能点，确保测试点尽可能完全覆盖。它也很容易评估用例。

4.一定要写测试用例吗？答:对于大中型任务，要写详细的测试用例；对于紧急小任务，可以写测试点；对于新人负责的模块，一定要写测试用例(我写或者老人写完，新人执行)。

5.如何编写测试用例？答：（1）根据需求文档拆分测试点；（2）根据测试用例设计方法 经验 通用用例约束。设计最终详细的测试用例；（3）编写用例的想法：产品需求-测试需求-测试点-测试用例；(4)如果是，还应考虑兼容性、浏览器兼容性和操作系统兼容性app测试还应考虑中断测试、弱网测试等。；在设计用例时，还应注意所涉及的数据库中的字段值是否正确；应注意相关模块的用例设计；注意设计新接口和新字段的用例；（5）xmind整理测试点，也可以：根据需求文档找到角色与功能模块的匹配关系，输出usecase图---输出流程图---根据业务规则，usecase、输出测试用例的流程图。

6.用例有四个方面？答：预设条件、执行步骤、预期结果和测试结果；用例要点：应包括与其他模块的耦合关系和用例的级别（level0、level1），必须完成哪些需求，后续可以完成哪些需求。

7.用例设计理念？答:首先要保证产品质量。测试用例的数量不能决定质量，要全面覆盖，提倡高质量的自动化测试。

8.没有需求文档，如何测试，如何设计测试用例A.查找其他相关文件，帮助了解需要测试的产品的目标；B.尽可能多地参加项目组的会议，如需求讨论、设计讨论、计划讨论等，以加深对产品的理解；C.咨询相关人员-项目负责人、营销人员；D.召集相关人员讨论您整理的结果。通过评审后，本文档可以作为设计您的基础case了；E.若是已上线的产品，可多使用产品，有不懂的问产品经理；F.也可以看历史bug，了解一些需要注意的事情。

9.测试用例有哪些设计方法？答：等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。

10.用什么形式和工具写用例？excel、word，也可以是工具，比如testlink、zentao、xmind。

11.写用例，是否有一个通用的用例模板？答：用例只需包含几个主要元素：用例的唯一编号、用例类型、模块、功能项、输入、预期结果、实际结果、测试结论注释OK。

12.如何确保用例的覆盖范围？答：首先，我们必须熟悉需求。需求分析和拆卸非常重要。在熟悉需求的过程中，我们必须找到产品及时沟通，以确定结果。其次，在项目开发过程中，应不断总结每个阶段的用例，学会总结，以确保尽可能少的泄漏。事实上，这与测试思维密切相关，工作经验的积累和测试思维的形成都有助于您设计一个更完整的测试用例。

13.测试用例什么时候开始设计？答:需求文档定版后，可以开始展示测试点，编写测试用例

14.测试用例评审答：A.什么是用例评审？用例评审主要是针对测试用例是否可用于项目测试的产品、开发和测试人员。B.用例评审的目的：减少试验人员执行阶段的无效工作（无效执行）case，提交无效问题)；为避免对三方需求的不一致理解，各测试人员的质量标准与项目要求标准一致。C.评审前需要做哪些工作:使用:Xmind，整理测试点；在脑图上，填写预期结果和实际测试结果，便于跟进测试结果；用例完成后，先进行自检，列出问题点，可提前与产品开发讨论，确定结果后改进用例，仍有问题，评审会议讨论；与评审人员（开发和产品）确定具体评审时间，并提前向参与者发送测试用例。D.参与者：主要是产品、开发、测试、项目负责人、运营；E.用例评审时间：对于敏捷开发项目，建议控制在半小时内；如果需求太复杂，功能点太多，半小时内无法完成，建议优先考虑功能点，优先考虑升级高的用例，然后对有很多问题的用例进行评审，最后可以简单带来功能简单的用例；F.用例评审形式：先对功能复杂，优先级高、疑问多的用例进行评审，再评审功能简单，优先级低的功能点。对于评审过程中，还没有结论的问题，可以记录下来，作为会后讨论跟进的重点。另外，整个评审会主次分明，有 ** 有缓点，可以更有效地达到我们评价的目的。G.正式评审：评审应优先考虑用例和功能的复杂性；评审时间尽可能清晰，每个功能点用最简洁的语言解释；会后讨论和跟进5分钟以上无法确定结果的问题。H.评审结束后需要做什么:第一时间整理测试用例，重新整理修改后的内容；会后继续跟进不确定的内容，直到确定结果；毫无疑问，做一个简单的用例评审总结(比如修改了哪些功能点，完成了哪些，哪些模块功能发生了变化？哪些功能推迟到下一期？

15.用例完成后，我们应该先做什么？答：先自检，自检完成，列出疑问点。评审前，提前将用例发送给相关开发和产品，预留时间告诉他们先看，然后统一评审时间。

16.更新测试用例？答:评审后需要更新，测试过程中需要更新，测试后根据线上反馈更新。

17.什么时候写测试点，什么时候写用例？A.假如公司只有你一个Tester，没有必要写测试用例，写测试点（Xmind），提取关键要素；B.如果需求总是频繁变化，写下测试点；您的测试用例的更新速度永远无法跟上需求的变化速度，您每天都在更改用例。用例太详细，意义和价值太小；C.假如你的节奏控制得很紧凑，完全没有时间严格按照测试用例执行，写下测试点，提取关键要素；D.假如整个团队Tester技能均衡，测试点已完全覆盖，写测试点，测试用例意义不大；E.如果这一块的逻辑非常复杂，你没有联系，试着写一个详细的测试用例，这是一个梳理需求和产品的过程；F.如何用更少的测试点，尽可能的充分考虑各种可能性呢?跟什么因素有关呢？与用例设计方法、经验、需求理解等等有关。我们要综合运用等价类、边界值、错误推测、场景法、因果图等测试用例的设计方法；G.不要总是找到棘手的用例，做好客户常用的流程。无论产品上线前经过多少轮测试，主要业务流程都必须回归测试。

18.如何写测试点？A.关注业务逻辑、业务场景、异常测试等。UI简单带过细节(因为UI视觉上可以直观地看到问题的层次，不需要大量的测试用例，浪费时间，产量不高)B.综上所述，它是为了写一个更大粒度的测试点来代替测试用例。因此，可以降低需求变化带来的用例维护成本，并可以在测试前进，确保核心流程、功能、场景和异常情况的充分覆盖。C.补充一个话题，需求频繁变化是不合理的，尤其是版本发布的临界点，不建议临时插播需求。源头无法控制，最终出现问题是正常的。

19.如何开发不自测的测试？A.建议加入测试环节，测试给出测试标准，达不到就返回。或者先验收产品的主流功能(设计对UI验收)，产品说验收后再测试。要开发自测，可以自上而下推广，加入某个环节需要技术总监的支持。B.开发自测可以让测试人员更容易，有更多的时间测试复杂的逻辑问题，而不仅仅是需求功能问题。同时，给研发带来一点压力，开发的功能模块质量也会提高。多次测试不合格也可作为研发评估的标准。

20.测试的价值是什么？答：你找不到多少？bug，但在产品上线后，有多少泄漏问题。作为一名测试从业者，我们必须了解我们的核心价值在哪里，并以此为目标，以正确指导我们在日常测试工作中的具体内容和细节。