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