测试用例设计面试题汇总

🔺1.什么是测试用例

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

🔺2.设计用例的好处？

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

🔺3.用例必备4个方面？

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

🔺4.测试用例的设计理念？

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

🔺5.测试用例有哪些设计方法？

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

🔺6.测试执行中如何去更新测试用例

1. 往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；

2. 有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；

3. 若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例；

4. 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

🔺7.等价类设计用例的步骤

1. 对输入项进行有效等价类和无效等价类划分，得到等价类表；

2. 设计一个新的用例，使其尽可能多的覆盖尚未覆盖的有效等价类，重复这一步骤，直到有效等价类都被覆盖为止；

3. 设计一个新的用例，使其仅覆盖一个尚未覆盖的无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。

🔺8.场景分析法设计用例的步骤

1. 分析需求，根据需求规格说明书画出流程图；

2. 确定流程图中的基本流和备选流，根据基本流和备选流生成不同的场景；

3. 对每一个场景使用若干个数据用例进行覆盖。

🔺9.关于验证码的问题：

1.验证码的测试用例你会从哪几个方面考虑？

2.突然收不到验证码，你会从哪几个方面考虑？

参考答案：

1.验证码一般是用来做登录密码，或者一些其他安全性较高的业务功能。验证码的测试是一种典型的匹配类测试，自然也就有正确验证码、错误验证码之分。另外验证码还有一个典型的特征是具有时效性，即2分钟会失效还有一个特征是验证码能够重发，一般设置1分钟重发。

2.验证码一般是由公司短信平台系统发出，在测试的过程中。我们在自己的业务系统点击获取验证码，再去短信平台查询验证码，所以不存在所谓的收不到验证码，因为在测试系统中，验证码根本就不发送到手机上来的。

如果真收不到验证码，可能有如下情况：

1.短信平台和业务系统环境出问题了，解决环境问题；

2.系统稳定性不够，请求没发出，再重发一次就好了；

3.是否你的业务账号记错了，那属于工作失误；

4.是否你的手机号被别人使用了，产生手机号的冲突。

🔺10.新增和修改页面的用例设计和Bug提交（心得体会）

问题：新增页面和修改页面，基本上输入框都一样，那比如同一个输入框的用例设计：

1. 写了新增页面的用例，修改页面对该输入框还有再写一遍用例的必要吗？

2. 执行用例时，新增页面验证了必填项，长度，数据类型，修改页面还要再验证一遍吗？

3. 提交Bug时，新增和修改页面的同一个输入框都出现了Bug，是只提交一个还是新增和修改各提一个。

参考答案：

总体原则：用例写得太多太细浪费时间，但完全不写用例也不好，应该折中。以下是讲的如何折中：

我们写用例最容易落入一个误区，就是为了写用例而写用例。实际上写用例最主要目的是分析系统，如果系统业务复杂，用例分析与设计就很重要，如果很简单的功能不写用例也能够搞定执行。就好像我们做数学题1+2基本上不用思考就知道等于3，如果是546+788，我们甚至可能要列竖式认真算，这也是如果我们遇到简单功能，不用过多写用例就能测好，那么何必写？

想必说到这里，我们的答案已经清晰了，新增的用例写完后，我们完全可以参考新增的用例去执行修改功能，不需要重复写用例了。

当然第二个问题，我就不太能确定了。新能功能和修改功能是否共用一个程序？如果是，那么可以不用测试，如果不是，那么需要测试，要不要测试取决于系统的实现方式。

第三个问题，同样我们需要思考我们提交缺陷的目的所在，我们是要开发能够修改所有的缺陷即可，那么不在乎到底是写在一起还是分开写，只要清晰体现即可。我一般做法是写在一起，说明同样的缺陷在其他具体哪些功能同样存在。

🔺11.关于登录功能的测试点：

1.用户名和密码均正确，登录成功

2.用户名错误，登录失败 3.密码错误，登录失败

4.用户名为空，提示报错 5.密码为空，提示报错

6.密码错误3次，账号锁定 7.账号锁定，登录失败

🔺12.微信群发红包的测试点：

1.此为拼手气红包，应检查收到的红包金额不均等，是拼手气的。

2.红包如果没有被抢完，24小时后钱会原路退回至发红包者账户。

3.红包已抢完，再抢红包会提示红包已被抢光

4.同一个人不能两次抢同一个红包，发红包者可以抢红包。

5.红包个数支持1~100个，无效取值为0，101个（边界值）

6.红包金额为人均0.01~200元，无效取值为：人均小于0.01，人均大于200元。

7.考虑红包个数和金额的边界组合，最小个数最小金额（1个0.01元），最小个数最大金额（1个200元），最大个数最小金额（100个1元），最大个数最大金额（100个2万元）。

8.使用自定义附言和默认附言发送红包，附言还支持图片附言。

9.如果账户余额不够，支持从银行卡进行扣款。

10.节假日等特殊日期可以发送大于人均200元的红包

🔺13.网银转账功能的用例设计

在银行项目面试中，面试官常问起网上银行转账功能如何测试，该问题既能考查面试者银行知识储备又能考查面试者的沟通表达能力。而很多人对于这个问题觉得很难回答，网上关于这块资料也并不多，特整理相关的测试点，抛砖引玉。

附图：网上银行转账截图

转账功能分析：

通过选择付款账号、填写转账金额、输入收款账户（含收款账号、收款人姓名、开户行）以及其他附加信息（手机号、备注等），填写好之后，点击【下一步】进入安全认证页面选择安全工具、填写安全密码，最后提交转账。

按照付款账号、金额、收款账号、安全认证分别进行测试分析

详细测试分析如下：

1. 付款账号、金额、收款账号、安全认证全部输入正确的，可以转账成功

2. 付款账号：

2.1 付款账号是借记卡，也可以是活期存折

2.2 付款账号不能是信用卡，这会在账号选择的时候就会屏蔽。

3. 转账金额

3.1 金额在(0,余额]之内，同时需要对边界值进行设计，需要测试0，0.01，账户余额，账户余额+0.01元以及负数值，空值测试。

3.2 付款账号金额不够、即转账金额大于账户余额

4. 收款账户：

4.1 收款账号、收款人姓名、开户行需要全部对应，只要任意不对应即是无效取值，固需测试收款账号，收款人姓名，开户行三者的任意不匹配

4.2 如果收款账号是行内账号，只需要进行账号与姓名的匹配即可，系统不再需要选择开户行信息

4.3 收款账号需要考虑：行内账号，跨行转账，借记卡、信用卡账号，同名账户（本人，本行）。

5. 安全认证：

5.1 安全认证：U盾（插入U盾输入密码），手机验证码（发短信到手机，输入验证码进行验证）

5.2 U盾密码错误、使用别人的U盾，验证码错误、超时、为空都会转账失败

3.其他特殊场景：

4.1 转账有当日限额、单笔限额（具体安全认证工具有关）

4.2 转对公账号（可能场景：给红十字会捐款，交学费）

4.3 转账汇路考虑，普通转账，实时转账的测试

4.4 外币转账（包含现钞和现汇，现钞是指同一币种间的转账，现汇是不同币种间的转账）

4.4 转入账户与转出账户相同（结果为转账失败）

4.5 转账超时导致转账失败（需要在测试环境模拟，产生一笔转账和一笔冲正数据）

5.输入框验证和用户体验等非功能考虑

为了不让文章写起来特别长，故此部分略去。

附加内容：

1. 转行外转账：转行外账户

🔺14.如何测试一个水杯：

关于一个水杯如何测试？这个被认为是测试界最为经验的面试题了，下面是我的回答思路：

对于一个软件的测试，重点是测试的思路以及测试的全面性的体现。

软件测试应该先重点再次重点，对于软件而言重点自然在于功能测试，尔后再非功能测试。

对于功能测试，重点在于核心功能的测试，尔后再其他功能的测试。

所以沿着核心功能-->其他功能-->非功能，整理出来的测试思路为：

1. 我们要进行功能层面的测试

（a) 核心功能的测试（装水）

i. 能装常温水

ii. 能装开水

iii. 能装冰水

（b) 附加的功能（装别的东西）

i. 能装饮料

ii. 不能装硫酸（不能装的那类）

iii. 能否装固体（装饭）

（c) 其他功能

i. 作为礼品（以前流行金杯银杯不如百姓的口碑，现在流行杯具）

2. 说完功能层面的，再来讨论非功能层面的

（a) 性能层面

i. 耐高温（是否能在微波炉中使用）

ii. 厚度和硬度（多高摔下来不破）

（b) 易用性层面

i. 是否可以方便的喝到水

ii. 是否很好的手持

iii. 是否防滑

iv. 是否界面美观

（c) 安全性层面

i. 是否不会割伤嘴巴

ii. 是否盛热水不会烫手（隔热）

（d) 兼容性层面

i. 是否在不同的温度下都能够使用

ii. 是否不同的人群使用

（e) 其他层面

抛砖引玉，留给大家扩展。

🔺15.电梯怎么测，附常见的测试用例

1.电梯的作用：载人

1.载人合适数量，可以正常运行

2.超载人数，无法运行，提示警告

3.空载，也可以正常运行

4.载货，也可以正常运行

2.电梯的特征：上下运行

1.按上，则上行

2.按下，则下行

3.不按，则不运行

4.没按对应楼层，不停该层

5.电梯运行是匀速运行，不会出去眩晕

6.双击楼层，会取消这个楼层

7.到了对应楼层，继续按这个楼层，无法点亮楼层

8.电梯上行时，在楼上按下，会跃过该楼不停

9.在顶层没有上行，不能按上。在底层没有下行，不能按下。

10.满员运行，外部按键，不再开门

3.开关门相关的用例

1.按开，则开门

2.按关，则关门

3.运行过程，开和关都无效

4.被夹了，则无法正常关门，会开门

5.在开门和关门过程中根据电梯特征，是否会有语音提示（不同电梯不同需求）

6.还有报警器按钮也能正常运行，功能正确

7.电梯门在一定时间内，会自动关闭

8.到楼层之后，会自动打开门

9.长时间按电梯开门，会警告声音

4.电梯编程（高低层，单双层，指定楼层停留）

1.如果是在高层电梯，低层按键不可用。如果是在低层电梯，高层按键不可用。

2.单双层同理高低层

3.长时间不运行，电梯会运行到指定层停留

4.如果是多个电梯，有一个电梯到了该层，其他电梯的灯灭

5.按一个电梯，其他电梯灯都会亮

6.按上，联动上的按钮。按下联动下的按钮

7.按上下按钮，就近的电梯运行过来，较远的电梯不动。

🔺16.我手上这支笔，请你根据这支笔设计测试用例

同水杯测试思路

针对于支付模块，如果接入了支付宝该如何测试

对于普通商城系统而言，如果接入的是支付宝从测试的角度，需要与支付宝对接联测方可完成测试。在这种情况，一般我们不会选择与支付宝的测试团队对接，因为过于麻烦。反而我们会选择接入第三方真实系统进行测试，来模拟我们的过程。即付款时走真支付宝付款，实际上付款是将某账户中的钱转入到另外一个账户，如果两个账户都是自家的则不需要担心金钱损失。

例如押金、支付、充值都可以考虑这种情况，甚至还有短信平台也会接入真实系统。

这种接入第三方真实系统，有一些注意事项：因为涉及到金钱交易，最好与公司申请得到公司的支持，如有必要可使用小额账务完成整个过程。另外，在这种情况涉及到的金钱交易要特别小心，以免造成公司损失。

一般有支付，就会有退款操作。有时候还需要验证退款操作，检查退款到哪里去了，是否原路返回，是否存在手续费扣减。