1.测试用例是什么？
答：测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。
2.设计用例是否有必要？
答：如果不记下来，很可能到执行的时候测试点就遗漏了，另外也不便于用例评审，用例总结，对后期测试工作没大的改进作用。所以测试用例一定要写，颗粒度视情况而定。针对测试人员少，上线时间紧的项目，可只做思维导图列出测试点。
3.设计用例的益处？
答：设计用例的过程可以更深刻的理解需求，熟悉各功能点，保证尽可能全的覆盖到各测试点。也便于用例评审。
4.一定要写测试用例吗？
答：对于大中型任务，还是要写详细的测试用例；对于紧急小型任务，可以写测试点；对于新人负责的模块，一定要写测试用例（本人写或者老人写完，新人执行）。
5.测试用例怎么写？
答：（1）根据需求文档，拆分测试点；
（2）根据测试用例设计方法 + 经验 + 拆分后的测试点 + 通用用例约束。来设计最终的详细测试用例；
（3）写用例的思路：产品需求-测试需求-测试点-测试用例；
（4）还要考虑兼容性问题、浏览器兼容、操作系统兼容性，如果是app测试还要考虑中断测试、弱网测试等；设计用例时也要注意涉及到的数据库中的字段值是否正确；需要注意关联模块的用例设计；注意新增接口、新增字段的用例的设计；
（5）除了用xmind整理测试点，也可以这样：根据需求文档找到角色和功能模块的匹配关系，输出usecase图—输出流程图—依据业务规则、usecase、流程图输出测试用例。
6.用例必备4个方面？
答：预置条件、执行步骤、预期结果、测试结果；用例要点：需包括与其他模块耦合关系、用例的级别（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，而是产品上线之后，有多少漏测问题。作为测试从业者，必须明白自己的核心价值在何处，把它作为目标，才能正确指引我们平时的测试工作中的具体内容及细节落实。
