1、测试用例是什么？

答：测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

2、设计用例是否有必要？

答：如果不记下来，很可能到执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。所以测试用例一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。

3、设计用例的益处？

答：设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点。也便于用例评审。

4、一定要写测试用例吗？

答：对于大中型任务，还是要写详细的测试用例；对于紧急小型任务，可以写测试点；对于新人负责的模块，一定要写测试用例（本人写或者老人写完，新人执行）。

5、测试用例怎么写？

答：

1）根据需求文档，拆分测试点；

2）根据测试用例设计方法 + 经验 + 拆分后的测试点 + 通用用例约束，来设计最终的详细测试用例；

3）写用例的思路：产品需求-测试需求-测试点-测试用例；

4）还要考虑兼容性问题、浏览器兼容、操作系统兼容性，如果是app测试还要考虑中断测试、弱网测试等；设计用例时也要注意涉及到的数据库中的字段值是否正确；需要注意关联模块的用例设计；注意新增接口、新增字段的用例的设计；

5）除了用xmind整理测试点，也可以这样：根据需求文档找到角色和功能模块的匹配关系，输出用例图—输出流程图—依据业务规则、用例图、流程图输出测试用例。

6、用例必备4个方面？

答：预置条件、执行步骤、预期结果、测试结果；用例要点：需包括与其他模块耦合关系、用例的级别，考虑哪些需求必须完成，哪些需求可以后续完成。

7、用例设计理念？

答：首先要保证产品的质量，测试用例的数量并不能决定质量的好坏，要做到覆盖全面，提倡高质量的自动化测试。

8、没有需求文档，如何测试，如何设计测试用例？

答：

1）查找其他相关文档，来帮助理解所要测试的产品需要完成的目标；

2）尽量多参加项目组内的会议，比如需求讨论、设计讨论、计划讨论等，能够加深对产品的理解；

3）咨询相关人员-项目负责人、市场人员；

4）召集相关人员，对你整理的结果进行讨论，通过评审后，这份文档就可以作为依据来设计你的case了；

5）如果是一款已经上线的产品，可以多使用产品，有不懂的问产品经理；

6）也可以去看历史bug，可以了解到一些需要关注的东西。

9、测试用例有哪些设计方法？

答：等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。

10、写用例，用什么形式写，什么工具写?

答：excel、word，也可以是工具，如testlink、zentao、xmind。

11、写用例，是否有通用的用例模板？

答：用例只需包含几个主要元素：用例唯一编号、用例类型、模块、功能项、输入、预期结果、实际结果、测试结论、备注，就OK。 

12、如何保证用例的覆盖度？

答：首先一定要熟悉需求，需求分析，拆解非常重要，需求熟悉过程中，不理解的地方，一定要找产品进行及时沟通，确定结果。其次项目开发过程中，每期的用例都要不断总结，学会总结，尽可能的保证少漏。其实这个与测试思维关系密切，工作经验的积累，以及测试思维的形成，都有助于你设计一份较完整的测试用例。

13、何时开始设计测试用例？

答：需求文档定版后，即可开始陈列测试点和编写测试用例。

14、测试用例评审

答：

1）什么是用例评审？用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作；

2）用例评审的目的：为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题）；为了避免三方需求理解不一致；为了每个测试人员的质量标准与项目要求标准达成一致；

3）评审前需要做哪些工作：用Xmind，将测试点梳理出来；在脑图上，补全预期结果和实际测试结果，便于测试结果跟进；用例写完后，先做自检，有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论；和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看；

4）用例参加人员：主要是产品、开发、测试、项目负责人、运营；

5）用例评审时间：对于敏捷开发项目，建议控制在半小时以内；如果需求太复杂，功能点太多，半小时讲不完，那么建议对功能点划分优先级，优先评审优先升级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过；

6）用例评审形式：先对功能复杂，优先级高、疑问多的用例进行评审，再评审功能简单，优先级低的功能点。对于评审过程中，还没有结论的问题，可以记录下来，作为会后讨论跟进的重点。另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的；

7）正式评审：评审要按用例的优先级，功能的复杂程度进行；评审时间尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；超过5分钟无法确定结果的问题留作会后讨论跟进；

8）评审结束后需要做些什么事：第一时间整理测试用例，把修正的内容重新整理补全；会上未确定的内容，会后继续跟进，直到确定结果；都无疑问了，做个简单的用例评审总结（如修正了哪些功能点，补全了哪些，哪些模块功能有变动？哪些功能推迟到下一期做？）。

15、用例写完，我们要先做什么？

答：先自检，自检完毕，列出有疑惑的点，评审之前，把用例提前发给相关的开发、产品，预留时间告诉他们先看，再统一时间进行评审。

16、测试用例的更新？

答：评审后需要更新、测试过程中需要更新、测试结束后根据线上反馈情况进行更新。

17、什么时候写测试点，什么时候写用例？

答：

1）如果公司只有你一个测试员，就没必要写测试用例了，写测试点，提取关键要素；

2）如果需求老是频繁变化，写测试点吧；你的测试用例的更新速度永远跟不上需求的变化速度，每天都在改用例。太详细的用例，无太多的意义和价值；

3）如果你们的节奏控制的非常紧凑，完全没时间严格按照测试用例执行，写测试点吧，提取关键要素；

4）如果团队的整体测试员技能均衡，测试点已经能够充分覆盖了，写测试点吧，测试用例的意义不大；

5）如果这块的逻辑非常复杂，你未曾接触，尽量写详细点的测试用例，通过用例的梳理过程，是一个很好的梳理理解需求和产品的过程；

6）如何用更少的测试点，尽可能的充分考虑各种可能性呢?跟什么因素有关呢？与用例设计方法、经验、需求理解等等有关。我们要综合运用等价类、边界值、错误推测、场景法、因果图等测试用例的设计方法；

7）不要总找刁钻的用例，要把客户常用的流程弄好。产品上线之前无论经过多少轮测试，一定要把主体业务流程进行回归测试。

18、测试点怎么写？

答：

1）重点关注业务逻辑、业务场景、异常测试等，至于具体UI细节，简单带过即可。（因为UI层面的问题，视觉就可直观的看出来，不需要大篇幅的测试用例，浪费时间，产出并不高）

2）总结来看，就是写更大颗粒度的测试点来代替测试用例。由此减少需求变更带来的用例维护成本，又可测试前置，还可以保证核心流程、功能、场景化、异常情况充分覆盖。

补充一个话题：需求频繁变更，本身就是不合理的，特别是版本发布临界点，是不建议临时插播需求的。源头没控制，最后出问题属于正常现象。

19、对于开发不自测的，测试该如何做？

答：

1）建议加入提测环节，测试给出提测标准，没达到就打回。或者先给产品进行功能主流程验收（设计对UI进行验收），产品说通过验收了再给测试提测。要开发自测，可自上而下进行推动，加入某个环节也需要技术总监的支持。

2）开发自测可以使测试人员轻松点，有更多的时间去测复杂的逻辑问题，而不是只测需求功能问题。同时，给研发一点压力，开发的功能模块质量也会有所提高。多次提测不通过也可以作为研发考核的一个标准。

20、测试的价值是什么？

答：不是发现多少bug，而是产品上线之后，有多少漏测问题。作为测试从业者，必须明白自己的核心价值在何处，把它作为目标，才能正确指引我们平时的测试工作中的具体内容及细节落实。

作者：测试猿David

原文链接：https://blog.csdn.net/weixin_50271247/article/details/109773137