《测试用例知识大全》----测试用例所有疑问,只需这篇就够了_软件测试


测试用例20问--20答

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