1. 测试用例是什么？

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

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

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

3. 设计用例的益处？

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

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

对于中大型任务，还是要写详细的测试用例；对于紧急小型任务，可以写测试点；对于新人负责的模块，一定要写测试用例（加深对业务功能的理解）。

5. 测试用例怎么写？（★★★）

写用例的思路：产品需求 -> 测试需求 -> 测试点 -> 测试用例

可分为以下几个要点：

根据需求文档，拆分测试点，划分功能模块

正向功能 + 异常功能验证

功能之间交互验证，需要注意关联模块的用例设计

还要考虑兼容性问题，如浏览器、操作系统等，如果是app测试还要考虑中断测试、弱网测试等

注意新增接口、新增字段的用例设计

6. 用例必备4个方面？（★★★）

预置条件

执行步骤

预期结果

测试结果

用例要点：需包括与其他模块耦合关系、用例的级别（level0、level1）考虑哪些需求必须先完成，哪些需求可以后完成。

7. 用例设计理念？（★★★）

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

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

查找其他相关文档来帮助理解所要测试的产品需要完成的不表；

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

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

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

如果时一款已经上线的产品，可以多使用产品，有不懂的就问产品经理

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

9. 测试用例有哪些设计方法？（★★★）观察法等价类划分法边界值分析法判断表因果图流程图场景法错误推测法10. 写用例，用什么形式写？或者什么工具写？

excel、word；也可以是工具，如testlink、zentao、xmind等。

11. 写用例，是否有通用的用例模板？（★★★）

考虑以下几个主要元素：

用例编号(具有唯一性)用例类型用例标题用例级别前置条件测试输入执行步骤预期结果测试结果备注12. 如何保证用例的覆盖度？（★★★）

首先一定要熟悉产品、熟悉需求，对需求进行分析和拆解非常重要，需求熟悉过程中，不理解的地方，一定要找产品及时沟通，确定结果。

其次项目开发过程中，每期的用例都要不断总结，学会总结，尽可能地保证少漏。其实这个与测试思维关系密切，工作经验的积累，以及测试思维的形成，都有助于你设计一份较完整的测试用例。

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

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

14. 何为测试用例评审？

A. 什么是用例评审？

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

B. 用例评审的目的？

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

C. 评审前需要做哪些工作？

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

D. 用例参加人员？

主要是产品、开发、测试、项目负责人、运营;

E. 用例评审时间？

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

F. 用例评审形式？

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

G. 正式评审？

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

H. 评审结束后需要做些什么事？

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

15. 用例写完，我们要先做什么？（★★★）

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

16. 测试用例的更新？

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

17. 什么时候写测试点，什么时候写用例？（★★★）

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

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

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

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

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

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

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

18. 测试点怎么写？（★★★）

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

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

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

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

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

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

20. 测试的价值是什么？

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