《软件测试---你必须掌握的100个问题》

01 测试用例好坏的评判标准
02 如何写好一份测试用例
03 测试用例评审的目的：
04 没有发现bug的测试是否是有价值的？为什么？
05测试用例是否是越多越好？
06软件测试的价值
07 需求评审时，测试应该做什么？
08 需求评审的目的
09 测试用例的重要性
10 偶现问题如何处理？
11 如何深度定位问题
12 软件测试就是对软件进行测试，文档不用测试？
13 软件测试的流程
14 bug 的基本流程图
15 转测试后的冒烟测试和整个迭代的最后一轮冒烟测试的区别
16 什么黑盒测试？黑盒测试常用的测试用例设计方法
17 软件上线前所有提交的bug都要解决完吗？为什么？
18 偶现类的问题回归时如何处理
19 测试中不停发现BUG，一些比较小的BUG还要提吗？为什么？
20 软件测试通过标准是什么？
21 我们在做测试工作的时候，提交的bug经常会被开发人员说不是BUG时， 我们如何应付？
22 如果测试人员提单，然后给开发，开发跟测试人员的关系很好，他说提单会影响他的绩效考核，这个时候咋办
23 为什么需要交叉测试， 一般在什么时候开展，以及如何开展
24 自动化测试能否取代手工测试，为什么？
25 交叉测试和发散测试的区别，目的，开展方式，测试内容
26 为什么需要测试这个岗位？
27 敏捷开发中有一个活动是每日站立会议， 每日站立会议的目的是什么？团队成员汇报什么？团队领导想要知道什么？
31 版本转测试前，测试需要做好哪些准备？
32 每轮转测试的预测试
33 一个数字型的输入框，要测试哪些场景？
34 如果一个迭代计划测试三轮，第一轮测试内容， 第二轮测试内容，第三轮测试内容
35 根据是否执行代码划分软件测试，可以划分成哪两类？
36 我们每一轮回归bug ，回归哪些
37 发现的缺陷越多，说明软件缺陷越多吗？为什么
38 测试用例评审的目的， 如何做好测试用例评审：
39 集成测试和系统测试，测试内容的侧重点分别是什么？
40、如何做好探索式测试，有哪些套路？
41、开发说你提交的bug 是非问题，这个时候我们怎么处理？
42、自动化用例在什么时候执行， 自动化用例在什么时候编写
43、软件迭代开发模型中， A迭代已经做完上线了， B迭代是A迭代的下一个迭代， B迭代是否会测试A迭代的功能？
44 软件测试退出的标准是什么？
45 白盒测试一定是动态测试不？
46 在保证测试质量的情况下，如何有效降低测试轮次，缩短测试周期，提升测试效率
47 版本转测试之后，系统部署到测试环境，测试环境不稳定咋解决，功能一会好一会不好，开发就这么说，不稳定， 我们测试怎么办？
48、写好一份测试用例的套路
49、版本转测试后预测试(冒烟测试)和最后一轮测试（大部分是冒烟测试的）区别：
51缺陷的定义：
52 提交了一个bug，开发说这个需求中没说，这个时候怎么办
53 测试任务中，按期完成测试的风险大，这个时候怎么办
55 如果要定位线上问题，需要客户系统的数据，公司是否需要制定一个获取数据的流程
56 面试问， 如何测试系统登陆的性能，该如何回答呢
57 如何降低和开发人员的bug沟通成本？
58、一个页面有一个文本框，一个按钮，判断bug是前端还是后台的？这个要怎么设计测试用例
59、WEB页面上数据显示错误，本来应该显示38, 结果显示35，这个时候你怎么去定位这个问题出在哪里？
60、为什么需要软件测试、 软件测试的价值
61 软件测试的价值：
62、 你提交了一个bug，开发说客户没有这种场景，但是你认为这个bug可能会对客户造成影响，这个时候怎么办
63、在一局域网里有两台PC，用IP地址互相ping不通，可能原因有哪些，尽可能多的列出。
64 在做测试的时候，我们提交bug的时候，需要填写很多字段，比如严重级别，比如发现bug的模块，发现bug的版本，填写这些字段都有什么好处，有什么作用
65、一个软件，你测试了一个星期都没有发现bug，这说明什么？你怎么办？
66、发现的bug提交开发修改关闭后，过两天又出现了算不算新bug
66、在你测试的时候发现一个功能有点慢，但是功能是正常的，这个时候怎么处理？
67、软件测试完后,还有BUG,是测试人员的问题吗?
68、如何回归一个bug
69、我们发现了一个bug牵扯到A、B两个模块，想找A模块的开发确认下这个是不是bug，但是A模块的开发说，这块是别人负责的，我负责的部分没有问题， 这个时候你怎么办？
70、如何评价一个测试人员的绩效
71、没有需求说明书的功能如何测试
72、websocket如何测试？
74、 在软件的开发阶段（转测试之前）有哪些测试活动
75、转测试质量不高，我们测试能够怎么处理？
76、性能测试的并发和TPS分别代表的是什么？ 测试的重点在哪里？
77、测试怎么去测试一个接口的性能？
78、 给系统添加账号， 账号 4位数字， 不可重复 ，必填， 密码，6位数字或者字母，可重复，必填， 能够设计那些测试用例呢
79、测试的bug里面有一个2 8原则，指的是什么， 针对这种情况，测试如何应对？
80、http协议常见的状态码，比如200 404 502 ， 如果你请求返回是502， 这个时候怎么定位这个问题
81、一个web系统，如果发现某一个功能，比如下订单的功能比较慢，查找可能的原因：
82、我们测试中在N轮发现了很多bug，N+1轮测试的时候如果没有发现bug，这个时候我们应该怎么办？
83、 有一个测试用例，比如测试列表的翻页，需要几十上百条数据， 这个 数据你怎么去造？
84、TPS和QPS什么时候可以等价
85、bug有哪些字段，如何提交一份优秀的bug
86 一个下拉菜单你能想到那些通用的测试用例
87 测试用例需要评审，为什么需要评审呢？是因为不相信测试工程师写的用例吗
88 如何测试一个网站？
89，思考一个问题，我们天天说敏捷开发，敏捷是一种思想，很多时候落地还是迭代开发模型，为什么现在大家用迭代模型而不用瀑布模型了呢？
90、 数字文本编辑器，只能输入0-9的数字，长度不限， 设计一种保存的方法，保存数字文本占用硬盘最小？
91 在页面构造了5个数据，但是查询的时候只能查出来三条数据，怎么时候怎么去排查错误
92 把测试环境更新后，启动测试环境后，这样就算部署好测试环境了吗？
93 在一轮迭代中，哪些情况下需要去修改测试用例？
94 我只是一个点点点的测试人员，如何提升自己？
95 ：有一个http接口，如何根据请求的数据来判断是否是合法请求，验证请求者的身份是合法的
96 接口测试用例设计题
97、编程题目：
98、我们远程连接Linux的时候,至少需要知道哪些信息才能连接上？
99、http协议经常报404错误，502错误，500错误，根据这些错误，我们能推断出哪些信息？
100、做性能测试时，TPS是否和并发用户数有关？
101、 QQ传文件的功能， 你能想到多少需要测试的场景
102、 执行用例时，什么情况下修改用例， 什么情况下标记成成功 ，什么情况下标记成失败， 什么情况下标记成阻塞？
103、如何扩展自己的测试思路，提升自己的测试技巧？
104、什么是线上问题？测试需要做什么？
105、能不能帮忙举几个例子，1.测试和开发因为一个具体的什么问题有争议，然后我们是怎么处理的
106、我们觉得是bug，开发觉得不用改，然后怎么处理的
107、转测试版本质量差怎么样办？开发老是忘这往哪的
108、在迭代开发中，如何在保证质量的前提下，如何缩短测试周期，提高测试效率
109、如何提高测试在开发那边的地位，一般开发觉得测试是小菜比， 这个怎么办？
110、 有时间来了一个紧急的版本，时间很紧，没有时间写用例，如何做好测试？
111、 什么是冒烟测试，冒烟测试主要的目的是什么？
112、怎么评判产品是可测的，可以开始测了？什么标准的时候要打回给开发？
113、怎么保证自己测得覆盖的比较全？
115、一个偶现的问题，我们如何去重现，重现的思路是什么？
116、sql语句练习题目

01 测试用例好坏的评判标准
1、测试用例写的是否规范， 描述是否清晰
2、测试用例是否全部覆盖了需求中说明的正常场景和异常场景
3、使用这份测试用例测试的模块上线后， 线上没有出现问题，或者出现的问题都是影响极其小的问题
02 如何写好一份测试用例
1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例， 然后还需要看类似需求的bug情况
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑， 通过等价类、边界值、场景法等方法找出大部分用例
4、 找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、书写格式一定要清晰

03 测试用例评审的目的：
参考答案：
1、找到测试用例写的不正确的地方，比如说预期结果写错了，测试点描述错误等，
2、向产品、开发阐述我们对需求的理解，如果理解不一致，可以提前发现，避免在转测试后才发现，降低修改的成本。
3、每个人的思维具有局限性， 大家一起评审可以找到遗漏的测试点，让测试用例覆盖更加完全

04 没有发现bug的测试是否是有价值的？为什么？

参考答案：这个问题要分两种情况讨论
1、测试用例质量较高，覆盖了需求设计中的测试点，并且测试人员认真负责，没有发现bug ，说明程序质量很好， 这种测试的价值就很大，能够去评判软件的质量
2、测试用例质量不高，测试人员的责任心不强，没有发现bug，这种测试的价值就比较低，不能用这个测试结果去评判软件的质量
另外我们在实际工作过程中，大部分情况测试都是能发现bug的，如果没有发现bug，思考你还有那些场景没有测试到， 对需求理解是否到位，如果这些都做到位， 没有发现bug也不要紧，要相信咱们的测试能力。

05测试用例是否是越多越好？
相反如果测试用例中冗余用例太多，这样在执行测试用例会浪费大量测试人力，而且不会产生测试效果。

06软件测试的价值
1、保证产品的质量，证明产品是满足客户要求的
2、优化研发过程，提升团队能力

针对第二点举例： 比如版本打回次数过多（说明开发自测不到位，或者转测试质量要求不到位，打开发板子）， 比如问题单过多（可能模块太复杂，分给技能不熟练的人了，可能是这个人就没有认真干活）， 比如问题单回归不通过数量多（修改问题单不认真，导致延长测试周期）， 比如 版本上线后线上问题多 （测试不到位，测试点覆盖不全，测试设计和用例评审不到位，或者执行的时候不认真 该打测试板子），通过这些数据我们可以优化我们的研发过程，提升团队的效率

07 需求评审时，测试应该做什么？

 1、深刻理解需求，需求澄清的时候就不要在会议上面玩手机或者干其他事情了，因为如果需求理解不深刻，后面测试相关的工作就很难开展，

2、找到需求中设计不合理或者很难理解的地方，让产品再次讲解，直到理解清楚
3、思考需求中的测试点，测试点预期结果不清楚的地方让产品经理给出说明？比如说这种异常情况怎么处理？有多少种状态？状态之间如何转化什么的，反正就是影响我们测试的地方都要让产品给出说明，这样给我们后面写测试设计扫清障碍
08 需求评审的目的
1、让产品、开发、测试三方对需求理解达成一致,减少开发过程中由于理解不一致产生的bug，提升效率
2、尽早发现需求设计中存在的问题，尽早修改，降低修复成本

09 测试用例的重要性
1、测试用例构成了设计和制定测试过程的基础。
2、测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
3、判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。类似下面这样的说明：“95 % 的关键测试用例已得以执行和验证”，远比“我们已完成 95 % 的测试”更有意义。
4、测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。

5、 在版本转测试之后，我们测试的基础是什么？如果没有测试用例，我们应该怎么展开测试？怎么样保证测试点不遗漏、而且人力投入不重复、怎么样追溯我们的测试质量？如果没有测试用例，这些工作可能都无法开展， 所以测试用例是测试的根基，可以让我们的测试活动从不可控的状态变成可控的状态， 让测试活动开展起来更加顺利，可视化的跟踪我们的测试进度，哪些已测试、哪些未测试，所以要想成为一个高水平的测试人员，写出一份高质量的测试用例是基础。

10 偶现问题如何处理？
1、出现bug后，首先截图，查看日志，把对应日志保留下来
2、尝试重现这个bug ，思考这个bug可能产生的原因， 然后每个原因逐步验证，如果重现不出来，可以找开发帮忙 ， 这个步骤是为了准确找到重现bug 的步骤， 开发修改的时候就容易多了，不然又会和开发来来回回扯皮
3、如果实在重现不出来， 还是要提交bug 的， bug单一定要写清楚bug出现的环境， 版本、步骤， 错误截图， 对应的日志， 尽可能多的提供出现bug时的信息， 方便开发定位

11 如何深度定位问题

12 软件测试就是对软件进行测试，文档不用测试？
软件测试是对软件和文档的测试，比如部署文档

13 软件测试的流程
咱们的那个图： 需求澄清 测试用例编写 测试用例评审 测试计划 测试执行 测试报告

14 bug 的基本流程图
新建 -》 开发修改-》测试回归-》关闭

15 转测试后的冒烟测试和整个迭代的最后一轮冒烟测试的区别
转测试后的冒烟测试是关注转测试的功能是否可以正常使用，能够正常进行测试
最后一轮冒烟测试是验证系统整个功能对客户是否可用，一般把系统的主流程测试一遍

16 什么黑盒测试？黑盒测试常用的测试用例设计方法
等价类 场景法 边界值

17 软件上线前所有提交的bug都要解决完吗？为什么？
不一定需要解决所有的bug，第一完全的测试是不可能的，也就说明没有bug的软件是不可能的，只要满足客户要求的就是好软件， 第二：版本上线是有时间截点的，在规定的时间内优先解决对客户影响大的bug。
bug遗留一般是下面几种情况： 1、bug没有好的解决方案，且影响可控的 2、优化类的bug 、转成需求来修改， 3、时间太紧张，对客户影响小遗漏到不紧张的版本修复

18 偶现类的问题回归时如何处理
情况1、开发找到了必现原因，偶现类问题转化一个必现问题， 问题解决了就可以直接关闭bug单
场景2、 开发只是找到疑似原因，尝试修改， 回归时没有出现降级， 每个版本没出现都降级，降到提示时不能在降级就关闭， 如果在降级的过程中bug重现了，需要把问题单走回重新修改
19 测试中不停发现BUG，一些比较小的BUG还要提吗？为什么？
当然要提， 小bug的优先级可以低一些，但是一定要提交，不然很可能遗漏， 小bug开发可以后面再修改，但是一定要提交
20 软件测试通过标准是什么？
(一) 版本发布不能遗留1级BUG。考虑特殊情况，容忍概率型1级bug。可容忍