《软件测试---你必须掌握的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。可容忍 的数量为2个，且该1级BUG的复现率不大于5%。  概率型1级BUG特性：需要在特定的操作中实现，执行该操作几率较小，按正常流程操作时对功能影响不大，而且目前而言解决该问题有技术上的难度。  
(二) 版本发布不能遗留2级BUG。考虑特殊情况，容忍第三方型2级bug。可容 忍的数量为2个。  第三方型2级BUG特性：属于某功能的子功能模块功能且不影响其他子功能模块功能的正常使用。造成该功能失效原因必须是由第三方提供的SDK引起的问题。修复此BUG必须由第三方更换SDK等。 
 (三) 版本带bug发布，遗留3、4级bug数不能超过该系统BUG总数的5%。 (四) 详细测试用例执行率：100%。 (五) 详细测试用例通过率: 不低于95%。  通过率计算方式：通过用例数/总用例数。

21 我们在做测试工作的时候，提交的bug经常会被开发人员说不是BUG时， 我们如何应付？
其实分情况来看待： 第一种  需求没有写明确， 这个时候我们可以找产品看这个是不是bug，如果产品说不是， 那就不管了，如果产品说是，让他修改需求然后提bug走到产品，  第二种 开发说这种场景在客户那边不存在，不要提这种bug， 这个可以给测试经理说，这个bug提交上去，让他们去定夺修改不修改，   第三种情况， 开发说不是bug，环境问题导致的， 这个时候保留bug的证据截图，让开发指出什么环境问题导致的，如果不能说清楚，把bug提交上去，让他们改

22 如果测试人员提单，然后给开发，开发跟测试人员的关系很好，他说提单会影响他的绩效考核，这个时候咋办
场景1： 面试的时候如何回答，  面试的时候尽量回答  发现bug就提单， 测试要有测试的原则性，不能因为影响谁而不提单，影响到产品的质量
场景2 ，实际工作中， 如果是测试还有几轮才结束， 且bug问题影响不大，可以让开发私下偷偷修改， 在下一个版本转测试后，一定要去验证开发偷偷修改的地方，   如果影响比较严重，还是要坚持提单，不让问题给遗漏了 ，好好和开发沟通，开发会理解你的， 可以运用一些技巧，这些你们自己去想

23 为什么需要交叉测试， 一般在什么时候开展，以及如何开展
为什么需要交叉测试：1、每一个测试人员有自己思维的局限性，通过交叉测试，可以把新的测试思维带进来，测试出未发现的bug。
     2、检查测试人员的工作是否认真
3、帮助测试团队的测试人员熟悉整个测试系统，提升测试效率，降低人员流失的风险
什么时候开展：1、一轮测试结束后还有剩余测试时间可以安排交叉测试， 2、 每轮测试分给同一个测试人员的测试任务不同，在不知不觉中完成交叉测试
如何开展：交叉测试不等同与发散测试，一定要进行测试任务的分配,而且测试结果一定要在测试用例中体现

24 自动化测试能否取代手工测试，为什么？
当然是不能代替手工测试的，
原因：
1、在软件功能没有稳定时，自动化的脚本写起来比较费劲，容易出现较大改动，浪费人力，
2、自动化测试的前期投入很大（写脚本的工作量比较大），如果是一次性项目，就没有必要做自动化测试，投入收益比比较低，
3、一个持续演进的项目适合做自动化测试， 因为前面版本写的自动化用例可以在后面的版本使用， 一个脚本使用的测试轮次越多，收益越高
4、有些用例比较复杂，实现自动化的成本很高，不合算，这部分用例可以手工执行
5、自动化测试用例检查点有限，只会检查一些主要的验证点，如果其他验证点出问题就验证不出来

25 交叉测试和发散测试的区别，目的，开展方式，测试内容

交叉测试	发散测试

目的 1、每一个测试人员有自己思维的局限性，通过交叉测试，可以把新的测试思维带进来，
测试出未发现的bug。
2、检查测试人员的工作是否认真
3、帮助测试团队的测试人员熟悉整个测试系统，提升测试效率，降低人员流失的风险 1、发散寻找测试用例没有覆盖到的测试点，发现系统潜在的bug
开展方式 1、一轮测试结束后还有剩余测试时间可以安排交叉测试，
2、 每轮测试分给同一个测试人员的测试任务不同，在不知不觉中完成交叉测试 1、在一轮测试结束后，如果有空余的时间开展
测试内容 1、按照分配的测试用例执行测试 1、按照分配的模块测试，但是不需要按照测试用例执行
2、常用的套路 1、学习团队其他成员提交的bug，拓展自己的测试
思维，发散测试 2、和开发聊程序的运行流程，思考我们没有测试到
的路径
3、天马行空，想到哪测试哪（效率没有前两种高），

26 为什么需要测试这个岗位？
1、现在软件系统越来越复杂，一个软件系统可能由几个几十个人一起开发的，单个开发可能只熟悉他所有编写的模块，对于其他有影响的模块不熟悉，容易产生错误
2、开发自己写的代码自己不容易检查出错误，开发也有可能遗漏需求功能或者缺失异常处理，需要测试来帮助他们检查软件是否有bug ，是否符合产品设计，是否符合用户习惯，异常是否都已经处理，
3 、现在市场竞争激烈，对软件开发的周期和质量要求越来越高， 如果没有测试，开发很难再短时间内开发出客户满意的系统，导致软件的经济效益不好
总之一句话， 如果没有测试，软件的质量很难得到保证，

27 敏捷开发中有一个活动是每日站立会议， 每日站立会议的目的是什么？团队成员汇报什么？团队领导想要知道什么？
目的：沟通每个成员的工作进度，遇到的困难，传达我们团队今日要各项事务要达到的进度
团队成员汇报内容：个人负责工作的进度，遇到的困难， 是否有解决方案， 可能的风险，需要的帮助
团队领导想要知道的内容：1、团队成员的进度是否正常，2、我们今天的工作目标传递给成员，3、 各种风险、求助的解决方案，成员解决不了的，我怎么去推动解决，是否需要寻找外部的援助

31 版本转测试前，测试需要做好哪些准备？
大多数情况：我们需要准备测试用例，测试数据，测试计划，测试环境，准备预测试 、还要和开发沟通转测试的范围
如果是一个新项目：还需要沟通转测试流程， 转测试邮件的内容， bug规范， 测试退出标准

32 每轮转测试的预测试

33 一个数字型的输入框，要测试哪些场景？

34 如果一个迭代计划测试三轮，第一轮测试内容， 第二轮测试内容，第三轮测试内容
一般情况下1、第一轮测试本次迭代新增、修改的功能，以及有影响的功能 （全量覆盖）
2、第二轮测试第一轮失败的，阻塞的case和修改的bug， 以及加强测试第一轮问题较多的功能
3、第三轮 如果第二轮没有发现特别影响用户使用的bug，就进行冒烟测试，验证整个系统所有功能都没有问题
每一轮测试的时候把交叉测试、兼容性测试给融合进去， 如果有性能测试，稳定性测试再单独讨论 这个是我的思考，欢迎大家一起来探讨

35 根据是否执行代码划分软件测试，可以划分成哪两类？
动态测试 静态测试
36 我们每一轮回归bug ，回归哪些
回归这轮转测试时，开发修改的bug
37 发现的缺陷越多，说明软件缺陷越多吗？为什么

在项目中，如果在第N轮某一个模块（模块B）发现了很多bug， 在第（N+1）轮中同样的模块相比其他功能也会发现较多的bug ，这个是一个客观的规律， 软件的质量不会从不好一下就变到好，中间是一个逐步提升的过程
所以如果我们在带测试团队时，如果发现某一个模块bug较多， 那就需要对这个模块进行更深入的测试， 比如多投入人力或者换一拨人从不同的角度测试等方法， 来尽早找到软件存在的缺陷
这个还有一句总结的话， 就是在一次迭代中， bug也是符合2-8原则的， 80%的bug 在20%的功能中发现

38 测试用例评审的目的， 如何做好测试用例评审：
测试用例评审的目的
1、找到测试用例遗漏的测试场景，提升用例的覆盖度
2、找到测试用例写的不正确的地方，比如说预期结果写错了，测试点描述错误等，
3、向产品、开发阐述我们对需求的理解，如果理解不一致，可以提前发现，避免在转测试后才发现，降低修改的成本。

如何做好测试用例评审

1、评审之前，需要将即将评审的测试用例以及测试需求、测试分析的结果（测试点分析）等文档提前发送给相关的人员；最好能够让他们有时间提前阅读； 
2、随时的问题沟通与反馈机制。评审之前做一些问题的沟通与反馈，以便于在测试用例评审会议上能够节省出来宝贵的时间； 
3、评审会议的主持者，需要事前做好关于测试用例的疑问，问题点等记录，以便于在评审会上引导提问和解答； 
4、评审期间做好详细的记录，需要对有关的疑问和问题及时进行澄清； 
5、评审会议的主持者需要能够把控会议的进度，让参加评审的测试人员能够集中精力在测试用例上，而不要思维太发散而跑题。 
6、评审会议结束之后，及时提交审核评审记录；并且与参加会议的人员分享评审记录。
7、连续评审的时间不要超过2个小时，时间太长，评审的同时可能脑子都转不动了
其他的思考，如果有不同的思路，一起探讨

39 集成测试和系统测试，测试内容的侧重点分别是什么？
把测试流程按照时间先后顺序划分，可以划分为单元测试，集成测试， 系统测试、验收测试
软件测试的V模型

根据V模型就能清楚知道集成测试和系统测试的侧重点了：
集成测试的侧重点：验证了2个或多个单元之间的集成是否正确,并有针对性地对详细设计中所定义的各单元之间的接口进行检查;
系统测试的测重点：验证系统是否达到了在概要设计中所定义的功能和性能;

40、如何做好探索式测试，有哪些套路？
探索式测试：强调测试人员的主观能动性，抛弃繁杂的测试用例设计过程，强调在碰到问题时及时改变测试策略。
那什么场景下会开展探索性测试呢？在这些场景下如何做好，有哪些套路
场景1：测试任务比较紧急，没有完整的需求设计文档，也没有充足的时间编写测试用例
1、挑选对被测试功能的业务熟悉的测试人员 2、让开发给我们讲设计的思路，程序运行流程，3、测试的过程中记录测试过的点 4、测试人员相互review测试的点是否有遗漏
场景2：一轮测试完成后，时间还有剩余，开展探索式测试
1、相互学习其他人的bug单， 给自己提供新的测试思路 2、请开发讲核心流程的设计和运行流程，来检查我们的测试是否有遗漏 3、天马行空想吧

41、开发说你提交的bug 是非问题，这个时候我们怎么处理？
1、首先明确开发说不是bug的理由，
2、如果是需求变更， 那就找产品经理确认是否是需求变更
3、如果开发说测试环境问题， 让他说明清楚测试环境问题是什么，我按照他说的验证一遍， 如果确实如他所说， 那就非问题打回，但是不是他说的那样，不能让他打回
4、如果开发说用户不存在这种使用场景， 但是我们不认可他说的，把这个bug 知会到测试经理，让测试经理去判定，

42、自动化用例在什么时候执行， 自动化用例在什么时候编写

43、软件迭代开发模型中， A迭代已经做完上线了， B迭代是A迭代的下一个迭代， B迭代是否会测试A迭代的功能？

44 软件测试退出的标准是什么？
1、首先明确一点，这个每个公司的标准不太一样
我罗列一个我之前公司的标准吧：
1、当前迭代需求设计中的功能都已经实现
2、遗留缺陷的di值不大于2， DI值计算方法（DI = 10*（致命bug个数）+3*（严重bug个数）+1*（一般bug个数））+0 .1*（提示bug个数）， 未修改的哈
3、所有未修改的bug的影响范围可控，且不会阻塞用户使用

45 白盒测试一定是动态测试不？
这个说法不对哈， 因为白盒测试还有代码review， 代码review是静态测试

46 在保证测试质量的情况下，如何有效降低测试轮次，缩短测试周期，提升测试效率
1、让整个研发团队重视质量，质量不仅仅是测试的事，也是开发，产品的事，所有的人都对质量负责人
产品：对需求说明要细致
开发：1、 不要出现修改一个bug 引出另一个bug ， 修改bug不通过不完整的情况
2、转测试前自测要细致，不要出现版本打回的情况， 打回一次，基本浪费测试团队半天的时间
测试：1、测试要细致，不要把本该第N轮发现的bug，在第N+1轮发现， 就是测试的bug尽早发现
总之一句话，全员重视质量， 转测试流程， bug流程， 测试流程规范化

47 版本转测试之后，系统部署到测试环境，测试环境不稳定咋解决，功能一会好一会不好，开发就这么说，不稳定， 我们测试怎么办？
参考答案：不能开说不稳定，我们就不管了，我们要去尝试找到产生这个不稳定的原因， 首先看看开发环境是否也会有这个问题，如果开发环境没有，测试环境有， 那就比较两个环境的差异性（配置、系统、软硬件的差异性），排除差异后，看看是否还会不稳定，如果测试环境和开发环境都不稳定，这个时候提交一个偶现的bug，让开发找到可能的原因， 总之一句话，遇到不稳定出现的bug，一定不要轻易放过，要寻根问底，找到原因， 不然项目上线后会因为这些不稳定的原因出现问题，影响客户使用。

48、写好一份测试用例的套路
1、测试人员尽早介入，彻底理解清楚需求，这个是写好测试用例的基础
2、如果以前有类似的需求，可以参考类似需求的测试用例， 然后还需要看类似需求的bug情况， 站在巨人的肩上总能看的更远嘛
3、清楚输入、输出的各种可能性，以及各种输入的之间的关联关系，理解清楚需求的执行逻辑， 通过等价类、边界值、场景法等方法找出大部分用例
4、 找到需求相关的一些特性，补充测试用例
5、根据自己的经验分析遗漏的测试场景
6、多总结类似功能点的测试点，才能够写出质量越来越高的测试用例
7、书写格式一定要清晰， 测试点写的再好，也要让其他人能够看懂，能够执行

49、版本转测试后预测试(冒烟测试)和最后一轮测试（大部分是冒烟测试的）区别：
（1）测试目的不同， 前者是验证转测试版本是可测试的， 后者是验证版本满足客户需求的；
（2）测试范围不同：前者针对本轮新增功能或者修改点的简要测试，后者针对的是整个系统所有核心功能的主流程测试。

50、偶现 问题如何处理
针对偶现类的问题如何处理：
1、截图保留当时页面场景， 把日志保留下来
2、查看日志中报什么错误， 分析可能出错的原因，或者重复执行出现bug的步骤
3、请求开发协助定位这个bug
4、如果找出了bug的原因，提交bug ， 如果找不到bug的原因，提交一个偶现的bug ，附上当时的截图、日志、环境信息

51缺陷的定义：
软件未实现需求和规格要求的功能
软件出现了需求和规格指明不该出现的错误
软件实现了需求和规格未提及的功能
软件未实现需求和规格未明确提及但应该实现的内容
软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。
测试用例执行中发现的与预期结果不符的现象

52 提交了一个bug，开发说这个需求中没说，这个时候怎么办
1、首先给开发说这个bug的会对客户产生的影响，如果开发认可，那就修改， 如果不认可， 进入第二步
2、找对应的产品，确认这个bug是否有修改的必要， 如果有，让他细化需求，然后把问题单走给产品，让他走给开发， 如果还是确定不下来，走步骤三
3、把这个bug报给测试领导，让领导去推动解决

53 测试任务中，按期完成测试的风险大，这个时候怎么办
1、把风险汇报给测试领导或者项目负责人
2、加班加点完成任务， 优先测试重要的模块

54 每日一问 测试用例的重要级别如何划分， 那些用例是高等级， 中等级，低等级

测试用例优先级的目的：测试用例优先级可以用来方便地基于测试策略来筛选用例。比如某块功能改动小，就只用测高或中高优先级的用例。 比如冒烟测试的时候我们只需要筛选优先级最高的用例执行即可。

根据我们测试用例优先级目的：那么优先级越高的测试用例覆盖的测试点应该是用户最关心的，  比如一个注册功能， 能够注册成功这个用例的优先级就是最高的（但是不是所有的注册成功的case都是优先级最高，只需要挑选一个即可）， 其他各种异常校验都是次要优先级的，  还有一些场景覆盖的测试点很难出现，或者叫就算有问题影响也不大， 可以放到低优先级

55 如果要定位线上问题，需要客户系统的数据，公司是否需要制定一个获取数据的流程
在回答之前先讲两个小例子，
Case1： 国内某个通信巨头A的研发工程师为了解决一个客户网上问题，私自拷贝了客户的数据， 最后圆满结局了客户的问题， 客户缺投诉了这个工程师， 认为偷取公司运营的核心数据， 导致最后A给客户赔偿客户损失且开除了定位问题的工程师
case2： 某个软件开发商， 私自拉取了客户数据进行问题的定位， 客户没有开启自动退款， 但是家里面的测试环境使用了客户数据，且开启了自动退款， 把客户的第三方支付的订单给退款了，造成了巨大的损失， 最后客户启用该软件公司的软件，且要求赔偿损失，不仅是退票的钱，还包括私自核心运营数据的造成的损失

最后：当然要指定一个流程，不然会给公司的运营造成极大的风险，一般情况下拉取客户数据一定要慎重，最好征求客户的同意， 另外一定要保证客户数据的安全

56 面试问， 如何测试系统登陆的性能，该如何回答呢
1、先抽取登录的业务模型， 手机号登录 账号密码登录的占比
2、执行测试计划
3、编写测试用例
4、使用jmeter录制对应的脚本
5、执行测试
6、出测试报告
57 如何降低和开发人员的bug沟通成本？
1、 每一个bug描述要清楚， bug标题指明是什么bug， bug内容的步骤清晰可操作，根据步骤可以重现bug， bug的实际结果和预期结果要明确， 另外如果文字说明不清楚的，尽量截图说明、或者录制视频说明，或者附上错误日志， 降低开发修改bug时需要询问测试的频率
2、尽量使用bug管理工具，这样不管是开发修改bug，测试提交跟踪bug都非常方便，减少沟通成本
3、指定一份bug流程手册， 手册中说明各种情况下，bug流程操作的说明
对于大部分测试来说，做好第一点就好了， 2、3是管理人员思考的

58、一个页面有一个文本框，一个按钮，判断bug是前端还是后台的？这个要怎么设计测试用例
1、判断这个bug是前端还是后台的，如果判断准确了，方便我们找对应的人沟通，减少沟通成本， 在分析这个之前，我们先讲一讲前台和后台的区别
前端“主要是负责页面的展示， 以及一些校验，比如字符串的长度格式校验 ，当然这些后台接口也需要做对应的校验的，
后端接口：主要是负责业务相关的功能
现在来分析bug可能是前台还是后台：
case1：文本框输入不合法的内容，点击提交按钮， 如果不合法的内容提交成功， 那应该是前后台没有做校验， 前后台都有这个bug
case2：文本框输入合法的内容，点击提交按钮， 查看数据库中的数据和输入的内容不一致， 这个时候需要看前台传的数据是否正确，使用fiddler抓包， 查看请求头里面的数据是否和输入一致，如果一致就是后台的问题， 如果不一致，就是前台的bug
case3：界面展示不友好， 重复提交 这些都是前台的bug

59、WEB页面上数据显示错误，本来应该显示38, 结果显示35，这个时候你怎么去定位这个问题出在哪里？
1、通过fiddler抓包工具（或者其他抓包工具）， 分析接口返回的数据是35还是38， 如果返回的是正确的，那就是前端的问题， 如果返回就是错误的， 你还得看看我们请求的参数是否正确，如果不正确，那肯定是前端的问题，如果正确，那就是后端的问题，接着以下步骤看
2、分析这个数据的业务， 搞清楚这个数据是怎么产生的， 把数据的源头到显示整个业务流搞清楚， 通过日志和数据库， 检查每一个环节的数据是否正确，通过每一个环节的检查，肯定可以查出问题出在哪里，

       那我们为什么要分析bug的产生原因：第一 提高我们测试的精确度， 第二 提高我们的测试技能  第三  减少bug的沟通成本，直接给到对应的开发修改，而且开发还不能推三阻四（因为我们已经确实定位是他的问题） 第四 提升测试的成就感，让开发不敢小瞧我们测试

60、为什么需要软件测试、 软件测试的价值
为什么需要测试这个岗位？
1、现在软件系统越来越复杂，一个软件系统可能由几个几十个人一起开发的，单个开发可能只熟悉他所有编写的模块，对于其他有影响的模块不熟悉，容易产生错误
2、开发自己写的代码自己不容易检查出错误，开发也有可能遗漏需求功能或者缺失异常处理，需要测试来帮助他们检查软件是否有bug ，是否符合产品设计，是否符合用户习惯，异常是否都已经处理，
3 、现在市场竞争激烈，对软件开发的周期和质量要求越来越高， 如果没有测试，开发很难再短时间内开发出客户满意的系统，导致软件的经济效益不好
总之一句话， 如果没有测试，软件的质量很难得到保证，

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

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

62、 你提交了一个bug，开发说客户没有这种场景，但是你认为这个bug可能会对客户造成影响，这个时候怎么办
对于这种问题，
1、首先和开发沟通这个bug ，说这个场景会有哪些影响，是否在需求中体现了
1、如果这个场景在需求说明书里面体现了， 这个时候先找产品经理（负责需求的人）沟通下，看看这个场景是否是想错了，如果产品说这个场景没问题，把这个问题（bug单）提给对应的开发即可， 如果产品经理说这个场景弄错了，那就不需要考虑了
2、如果需求说明书里面没有体现，先和产品经理沟通，如果产品说这个场景可以不考虑且说服了你， 那你可以不用管这个场景， 如果产品说这个场景需要考虑，提bug单给开发，如果产品说这个场景不需要考虑，但是没法说服你， 那你要坚持自己的意见， 把这个问题（bug）单走给测试经理，让测试经理去处理这个bug

63、在一局域网里有两台PC，用IP地址互相ping不通，可能原因有哪些，尽可能多的列出。
参考答案：
1、防火墙挡住了ping请求
2、ip地址弄错了
3、网线没有接好
4、交换机坏了
5、ping服务被禁止掉了
6、网络配置不对，比如ip、网关、子网掩码

64 在做测试的时候，我们提交bug的时候，需要填写很多字段，比如严重级别，比如发现bug的模块，发现bug的版本，填写这些字段都有什么好处，有什么作用
参考答案：
1、我们bug信息写的越全面，越详细，开发在分配问题单、修改问题单、确定哪些bug优先修改的时候可以减少和测试的沟通，提升研发效率， 如果我们写的bug单，开发看不懂或者有疑问，那开发会不断询问我们这个问题单怎么复现，问题单的现象是什么， 把开发人员和测试人员的时间都消耗了，
2、bug单是研发过程的大数据库，通过对数据分析，帮助我们优化研发过程，通过bug单可以分析出那些模块的研发过程质量好，那些模块研发过程质量差， 那些人修改bug比较细致，那些人修改bug不细致， 整个迭代的bug趋势是否是收敛趋势等， 总之一句话，通过不同的维度分析我们的问题单，就可以发现不同的研发中的问题。
65、一个软件，你测试了一个星期都没有发现bug，这说明什么？你怎么办？
第一种情况：正常执行测试
1、如果测试的人只有你一个，看看测试的软件版本是开发中的还是已经上线的，如果是开发中未上线的版本，发现不了bug要引起注意， 毕竟绝大部分情况下应该是能发现bug的
2、如果测试的人不止你一个的时候，看看其他人是否可以找到bug，分两种场景讨论：
场景1、如果测试的bug不多，那说明软件质量应该还不错， 你测试不出来bug 也不要着急，
场景2、其他人能够发现bug，但是你发现不了， 这个情况就要去思考，你的测试方法是不是不对， 你对需求是否理解到位，是否还有遗漏， 仔细分析下其他人发现的bug是否在自己负责的模块存在，

第二种情况：新人到公司， 为了让新人尽快熟悉业务，会让新人跑跑 测试用例， 这个时候测试的模块一般都比较成熟了，或者可能都已经上线了， 发现不了bug很正常

66、发现的bug提交开发修改关闭后，过两天又出现了算不算新bug
算新bug，但是一定要清楚这个bug为什么重新出现，是回归的时候没有认真，还是回归之后修改代码导致的这个bug
66、在你测试的时候发现一个功能有点慢，但是功能是正常的，这个时候怎么处理？
分几种情况来讨论：
1、由于客户端的电脑配置引起的系统慢，如果客户也使用相同配置的电脑，这个慢需要提单解决
2、由于客户端网络慢导致的系统反应慢，这个不用解决
3、由于系统架构导致的系统慢（数据库设计不合理、程序运行流程不合理、计算方法不合理等），这个测试工程是可以通过分析系统日志，使用性能测试工具测试对应功能的响应时间（RT），提交bug单解决
在我们提交bug单前，需要和产品沟通下，这种慢是否需要更改，需要才提交bug，

67、软件测试完后,还有BUG,是测试人员的问题吗? 
bug也要分情况：
1、需求里面有明确说明或者测试应该测试到的点，如果还有bug，那就是测试的责任
2、如果还有优化类的bug不能算测试的责任
3、如果还有不符合用户要求但是需求设计就错了的，不算测试的bug
为了测试不背锅， 所有关于bug沟通的记录都要有记录，方便以后不背黑锅
1、测试发现这个问题，但是不修改的， 这个也要有问题单记录
2、测试发现这个问题， 但是开发说没有这个场景的， 这个也要有沟通记录
3、测试发现这个问题，但是开发说不能复现，不修改的， 这个也要问题单记录
4、测试发现这个问题，但是说这个问题不重要，不修改的， 这个也要有沟通记录

68、如何回归一个bug
1、这个bug要从开发转给测试
2、测试环境的代码已经是开发修改好的代码
3、查看开发对bug定位的原因，修改的方法，测试建议
4、在测试环境验证bug对应的场景 是否修改好，修改bug影响的相关功能是否正常， 如果都ok， bug关闭， 如果有问题，和开发沟通确认后，bug打回给开发

69、我们发现了一个bug牵扯到A、B两个模块，想找A模块的开发确认下这个是不是bug，但是A模块的开发说，这块是别人负责的，我负责的部分没有问题， 这个时候你怎么办？
场景1、如果可以确认是bug，不需要找开发再确认了，直接提交bug给开发主管，
场景2、不能够确认是否是bug，害怕是测试环境部署不正确引起的bug，先排查是否是环境部署不正确，然后分析这个bug 的业务流程，分析流程中每一个阶段的数据是否正确， 找到数据不正确的那个模块，截图或者日志给开发，这个时候找对应模块的开发，开发想推脱也推脱不了
场景3，找到了bug出问题的模块，但是开发还是不帮忙解决，就说自己的模块没问题，是测试环境的问题，这个时候找测试领导推动解决下

70、如何评价一个测试人员的绩效
一个正确绩效评价体系会测试团队带来积极的作用，反之绩效考核牵引的方向不对，就会给团队带来副作用。
评价测试人员的绩效我这边会分成四部分， 工作量， 工作量的质量，团队合作，劳动态度
1、工作量就是我每次给成员分配任务时，都会考虑工作的难易程度，评估一个工作量，然后我会记录下来，方便后面打考核的时候用
2、工作量的质量从这几个方面来考核：1、负责模块的上线后的线上问题 （客户反馈的bug） 2、发现bug 的数量 （非主要） 3、编写测试用例的质量
3、团队合作，这个比较主观 占比不超过15%, 和同事关系融洽肯定是团队合作好的
4、劳动态度：这个也比较主观

粗略总结了下， 不足之处，欢迎探讨

71、没有需求说明书的功能如何测试
1、主动了解做这个功能的背景，意图，要去解决一个什么样的问题， 这个可以找产品或者开发要，或者谁要求做这个功能的人要，知道这些后，测试的时候才心中有数，知道功能实现对不对
2、尽量让熟悉这块的业务的人去测试，这样功能的一些业务问题就可以测试出来
3、 因为没有需求说明书，测试这边只有在功能做好了，转测试了，才知道功能是什么样子，所以这个时候写测试用例来不及，就采取这样思路操作

72、websocket如何测试？
1、断网测试
2、长时间不操作， websocket是否会出现断连接

74、 在软件的开发阶段（转测试之前）有哪些测试活动
测试活动不仅仅针对测试，测试是整个研发团队的事情， 所以测试活动不仅仅只算测试的，开发的也算
1、需求澄清 （产品主导）
2、编写测试计划 （测试）
3、编写测试用例 （测试）
4、评审测试用例（测试）
5、分配测试任务（测试）
6、准备测试环境（测试）
7、代码检视 (开发)
8、单元测试 (开发)
9、开发自测 (开发)

75、转测试质量不高，我们测试能够怎么处理？
1、如果转测试的版本不能够测试， 版本直接打回
2、分析项目有没有转测试规范，如果有，没有按照规范转测试导致质量不高，汇报给研发的负责人， 如果没有规范， 汇报项目负责人， 阐述转测试规范的重要性， 请求他去推动这个事情。
转测试质量不高需要改进的原因：
1、增加测试成本， 本来三轮测试可以解决的问题，由于每轮转测试都有问题，最后测试了五轮才封板， 延长了测试周期，延期交付产品
2、转测试的版本不可用， 浪费了测试的精力，让测试做了无用功

76、性能测试的并发和TPS分别代表的是什么？ 测试的重点在哪里？
并发是一个针对的是瞬间对系统产生的压力， 比如100个人同时登陆（注意不是弄个线程组，设置线程数是100就好啦）， 用来判断系统瞬间能够接收多大的请求量
TPS是每秒事务数，是衡量系统的处理能力的重要指标，判断系统每秒可以完成多少次请求

77、测试怎么去测试一个接口的性能？
1、单次数据量较大的时候性能如何
2、同时可以处理多少个请求
3、每秒事务数

78、 给系统添加账号， 账号 4位数字， 不可重复 ，必填， 密码，6位数字或者字母，可重复，必填， 能够设计那些测试用例呢
账号相关验证：
1、验证添加4位数字（1111）的账号成功
2、验证添加4位非全数字（11AA）的账号不成功
3、验证添加重复的账号的账号不成功
4、验证不输入账号，只输入密码添加不成功
5、验证添加删除的账号成功， 比如删除1111，再添加一个1111的账号
6、验证添加用户A和用户B同时添加一个账号1111， 先提交的成功， 后提交的提示账号重复
7、验证添加3位数字的账号不成功
8、验证添加5位数字的账号不成功
密码相关验证：
9、验证添加5位密码账号不成功
10、验证添加7位密码账号不成功
11、验证添加6位数字加字母的密码成功（123ABc）
12、验证添加6位数字加字母的重复密码成功（123ABc）
13、验证只输入账号，不输入密码，添加失败
14、验证添加6位带有特殊字符的密码不成功

79、测试的bug里面有一个2 8原则，指的是什么， 针对这种情况，测试如何应对？
1、bug的2 8 原则指的是80%的bug分布在20% 的模块中
针对这种情况我们怎么指导我们测试工作呢：
1、第一轮测试完成之后，分析bug主要分布在哪些模块， bug发现多的模块意味着还有更多的bug 没有发现， 这个可以再次换一个人测试这个模块，促使这些bug多的模块的bug尽可能早，尽可能多的被发现，提升我们的测试质量。

80、http协议常见的状态码，比如200 404 502 ， 如果你请求返回是502， 这个时候怎么定位这个问题
502错误定义：是网关错误， 通俗点说就是和web服务器通信失败
错误的原因：
1、网络不同， 不能访问web服务器， 有可能断网， 开启了防火墙等， 可以通过ping命令来定位
2、我们的web服务器没有启动， 可以通过查看日志来定位这个问题，或者查看端口是否启动
3、web服务器请求太多，响应不了这个请求， 这个表现是有时间好有时间不好， 可以通过查看web服务器的日志来定位

81、一个web系统，如果发现某一个功能，比如下订单的功能比较慢，查找可能的原因：

 1、查找原因前，先分析整个业务流：
       浏览器（客户端）发送请求 -> 网络1->生成订单的服务 ->网络2 -> 数据库各种操作 -> 网络3-> 生成订单服务整理返回的数据 -> 网络4 -> 浏览器（客户端）接收返回的数据并展示
      1、客户端电脑配置比较差导致慢  （换一个配置高的电脑试一试）
      2、客户端的前端代码没有优化，  通过fiddler查看接口返回时间和实际展现时间的差值   
      3、网络1  网络较差    ping一下看看响应时间
      4、生成订单的算法没有优化，   通过iddler捕获接口的响应时间
      5、生成订单请求量比较大导致慢， 通过统计数据分析，慢的时候的生成订单请求数量， 增加生成订单的服务节点看能不能变快
      6、数据库的语句比较慢， 这个是可以通过日志查看sql语句的执行时间
      7、服务器配置比较低， 可以通过top命令查看各项资源的占用情况
      8、连接数据库比较耗时， 询问开发是否是做了数据库连接池

82、我们测试中在N轮发现了很多bug，N+1轮测试的时候如果没有发现bug，这个时候我们应该怎么办？
正常情况下N轮发现了很多bug，N+1也会发现一些bug的
我们在N轮发现了很多bug 的功能，我们在N+1轮需要对这个模块进行更深入的测试， 比如多投入人力或者换一拨人从不同的角度测试等方法， 来尽早找到软件存在的缺陷
如果找不到缺陷，那说明缺陷确实比较少了，这种情况比较少见

83、 有一个测试用例，比如测试列表的翻页，需要几十上百条数据， 这个 数据你怎么去造？
1、可以通过写一段sql去造数据，这种针对数据只在一个表中比较好使，如果数据来自于很多个表，建议看下面的方法
2、通过接口自动化工具，录制接口脚本，然后需要多少个跑多少次就完事了
3、通过ui自动化脚本
4、如果其他环境存在这个数据，我们可以把其他环境的数据导入到我们要测试的环境
上面是几个方向， 具体的技术细节在群里面继续探讨

84、TPS和QPS什么时候可以等价
当然事物只有一个接口的时候，可以等价

85、bug有哪些字段，如何提交一份优秀的bug
其实如何判断是否是一个优秀的bug，最重要的一个标准： 开发不用询问测试就知道怎么重现这个bug， 或者能够理解这个bug， 而不是看不懂这个bug

字段如下，每个字段的要求如下
一个bug单包含哪些要素：
1、所属的系统
2、发现的版本
3、发现bug所属的模块
4、bug提交人
5、bug的错误类型：代码错误、界面优化、设计缺陷、配置相关、安装部署、安全相关、性能问题等
6、bug的重现概率： 必现 大概率重现 小概率重现 极小概率重现
7、bug的严重级别：致命 严重 一般 提示
8、bug的优先级：高 中 低
9、bug的标题 言简意赅说明是什么bug， 而不是把测试用例名字复制一遍
10、bug单号 一般系统自动生成
11、bug内容：发现的环境、 预制条件、重现步骤、预期结果、实际结果， 截图证明，bug错误说明，
12：附件：测试用的数据或者出错的日志， 如果需要添加上日志

提交bug的时候尽量把截图附上，并对截图进行标注，如果不好描述的可以录制视频， 如果是偶现bug ，把发生这个错误的错误日志，操作过程说明清楚
毕竟字不如图，描述半天不如一张图， 图不如视频

86 一个下拉菜单你能想到那些通用的测试用例
1、首先要思考这个下拉菜单的数据来自哪里，哪些场景的数据会在下拉菜单中显示（具体业务不同场景不同）（ 比如这个列表是选择人名， 那么我们添加一个人名， 修改一个人名， 列表里面都应该显示最新的
如果我们删除一个人名，列表里面的内容就不应该存在删除的这个人名了
）
2、下拉菜单显示的条目过长时怎么展示
3、下拉菜单条目过多时有没有滚动按钮或者模糊匹配
4、下来菜单条目过多时，下拉框展示是否友好
5、下拉菜单列表为空时展示是否ok
6、下拉菜单默认展示那一条数据
7、下拉选项列表内容的排序

87 测试用例需要评审，为什么需要评审呢？是因为不相信测试工程师写的用例吗
1、其实为什么要评审，不是怀疑测试工程师没有好好干活哈， 最重要一个原因是：每个测试工程师写测试用例的时候或多或少都会遗漏一些测试点， 不是说他们能力不行，而是每个人的思维有局限性，通过测试、产品、开发一起评审，把没有想到的测试点找出来
其次才有以下好处：
1、评审时还可以做到让开发 产品 测试 对需求达成一致理解，帮助开发提前修改代码中的bug，因为在评审的时候可能会发现某个地方自己理解错了，直接在转测试前就修改了，不用等到测试时才发现，提升了研发效率
2、发现测试用例描述不对或者不规范的地方

88 如何测试一个网站？
其实简单来说，首先明确测试目的， 咱们大部分时候都是功能测试哈，就主要讲功能测试
1、要测试功能，那首先需要理清楚这个功能的业务，相当于需求澄清
2、规划测试人力，整个测试需求的测试计划
3、分配测试用例的设计任务，评审测试用例
4、准备测试环境，等待转测试
5、转测试 分配测试用例的执行任务，预测试，执行测试用例，提交bug，回归bug
6、发布测试报告，评估测试结果，如果测试通过，则测试退出，否则继续进行下一轮测试

 如果有性能测试，兼容性，国际化测试等，另外安排。

89，思考一个问题，我们天天说敏捷开发，敏捷是一种思想，很多时候落地还是迭代开发模型，为什么现在大家用迭代模型而不用瀑布模型了呢？
从商业角度考虑：
1、迭代模型能够更快的开发出一个可用的版本，可以尽早的推广，占领市场

   从软件开发角度看优势：
   1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
   2）降低了产品无法按照既定进度进入市场的风险，每一个迭代都是一个可用的版本，基本上每一个迭代都会给客户使用，可以不断验证我们开发功能是否符合客户要求

3）加快了整个开发工作的进度。因为每个迭代都会专注于开发某一个或某几个功能，开发人员清楚问题的焦点所在，他们的工作会更有效率。
　 4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的（也可以通过观察客户反馈，细化需求，挖掘需求，瀑布模型就没有这个优势）。因此，迭代过程这种模式使适应需求的变化会更容易些。

90、 数字文本编辑器，只能输入0-9的数字，长度不限， 设计一种保存的方法，保存数字文本占用硬盘最小？
如果按照我们平常存文本的方式存储， 就算是用ASCII码，一个数字需要在硬盘上面占用8位bit位，
但是我们思考下， 0-9只有10个数字， 如果用ASCII码存储的话，会有浪费， 其实只需要4个bit位就可以存储一个数字啦， 4个bit位可以表示16种字符，而0-9只有10种，绰绰有余啦，
多余的6种我们记为 1010 1011 1100 1101 1110 11111 六种
通过使用4位bit位就可以少占用一半的空间啦

0 的二进制表示 0000
1的二进制表示 0001
其他的不列举了

我们再来分析下 一个简单的数字文本 22234345555232323123123123， 我们可以看见2连续重复了3次， 5连续重复了4次 23连续重复了3次， 123连续重复了3次
那我们可以使用 多余的六种 1010 代表单个字符重复
1011 代表两个字符重复
1100 代表3个字符重复
重复后面的4位代表重复的次数，最多可以匹配15次重复

那我们看看我们刚刚那个字符串可以编码生成：
222编码成 0010 1010 0011 不节约
5555编码成 0101 1010 0100 节约1位
232323 0010 0011 1011 0011 节约 2位
123123123 0001 0010 0011 1100 0011 节约4位

91 在页面构造了5个数据，但是查询的时候只能查出来三条数据，怎么时候怎么去排查错误

整个业务流程：B代表浏览器也就是web端， S代表服务端， DB代表的是数据库， 首先按图中第一步分析，然后按第二步分析

92 把测试环境更新后，启动测试环境后，这样就算部署好测试环境了吗？
执行启动脚本后，不能算真正部署环境完成， 还需要完成以下几件事情
1、查看启动的日志，观察是否启动成功，启动是否有错误， 有错误不要放过，看不出来原因找开发协助
2、打开测试的软件，走一下主要的功能，看看主要功能是否存在问题
只有当1 和2 都通过时，才算是环境部署完成。

93 在一轮迭代中，哪些情况下需要去修改测试用例？
1、一轮迭代，那说明有新需求， 新需求需求澄清完之后需要做测试设计，这个时候要新增（添加新功能需求）修改（修改已有的功能需求）测试用例
2、测试用例评审的时候，每个人思维就有局限性，那么测试用例有可能有遗漏，另外每轮迭代写的测试用例比较多，很有可能手误导致写错的， 这些情况都需要修改
3、在测试用例执行的时候， 需求可能发生变更，但是没有知会到测试人员这边来， 导致用例还是旧的需求，这个时候需要更新测试用例到更改后的需求

94 我只是一个点点点的测试人员，如何提升自己？
1、思考自己测试的模块质量怎么样？有没有去总结自己的测试经验，漏测的bug是否都是因为自己技能不足还是因为自己思维局限， 技能不足学习相关技能， 思维局限多总结常见的测试场景
2、思考自己对测试的系统整个系统结构熟悉不， 每一个模块分别有什么作用， 各个模块怎么组合在一起构成一个完整的系统
3、思考自己发现bug后有没有去分析错误的原因， 通过分析整个业务流找到问题原因，提升自己的精确度
4、思考自己的测试工作还需要在哪方面提升， 是否重复工作多，是否需要引入自动化测试， 线上环境经常性能不足，是否需要引入性能测试，然后针对性的学习相关技能
5、思考测试流程有没有改进的空间， 让测试质量尽可能额提升

95 ：有一个http接口，如何根据请求的数据来判断是否是合法请求，验证请求者的身份是合法的

  1、判断请求者携带的cookie值是否是合法的， 这种很常见， 比如自己登陆一个网站，长时间不操作，cookie过期了， 然后再次会强制跳转到登录页面， 因为判断请求不合法了
  
  2、http接口是被其他系统调用的， 可以协商一个加密规则，然后在参数中携带一个校验码， 校验码是根据请求的数据和加密规则 算出来的，这个校验码可以防止其他人恶意修改数据，或者其他恶意请求， 因为只要修改数据，非法请求，校验码就验证不通过
  其他的方法大家继续查相关的资料

96 接口测试用例设计题
一个http接口， post请求，

接口参数 有三个 a,b,c 是三个数字，代表三角形的三边，
接口返回：
如果数字不全是正数，则返回数据格式不对
如果不能构成三角形，则返回不能构成三角形
如果能够成三角形， 则返回可以构成三角形
正常的场景：a b c都是正数
一类：是三角形
1、a+b>c a+c>b b+c>a abc都是正整数
2、a+b>c a+c>b b+c>a abc都是正浮点数
二类 非三角形
1、a+b>c a+c>b b+c=a
2、a+b>c a+c>b b+c<a
3、a+b=c a+c>b b+c>a
4、a+b<c a+c>b b+c>a
5、a+b>c a+c=b b+c>a
6、a+b>c a+c<b b+c>a
异常的场景：
一类：参数格式不对
1、a <=0 （不合法） b c合法（正数）
2、b <=0 （不合法） a c合法（正数）
3、c <=0 （不合法） a b合法（正数）
4、a （非数字） b c合法（正数）
5、b （非数字） a c合法（正数）
6、c （非数字） a b合法（正数）
7、a （缺失） b c合法（正数）
8、b （缺失） a c合法（正数）
9、c （缺失） a b合法（正数）
10、 a b c 合法，但是参数过多，多传一个d

97、编程题目：
如果你认为描述是不完整的，并以任何方式影响答案，请在回答中适当地描述和描述。
我们是一家PHP商店，希望您能用PHP回复。
但是，如果你不熟悉它，你可以用其他任何语言回答，我们接受C语言、Java、JavaScript、Python、Perl、C+T、Ruby等问题的答案。
输入是一个英语句子的字符串，我们需要定义函数转换（$输入）”，它可以像下面描述的那样转换它，并返回一个新的字符串。
这个句子只包含字母表（A-Z和a-z）和空格，每个单词将被精确地用空格分隔开来，前后无空格。
请用每一个单词拼写倒数来返回字符串，但是，每个位置的单词大小写不比保持相同
例子：
输入: Many people spell MySQL
正确输出: Ynam elpoep lleps LqSYM

98、我们远程连接Linux的时候,至少需要知道哪些信息才能连接上？
1、至少需要知道哪些信息，其实有了ip和端口号就可以连接上的，我们在Linux上面开启一个套接字服务，用telnet协议连接就好

2、我们这里题目的意思是想表达用xhsell这个工具，通过ssh协议连接上Linux服务器，可以对服务器做各种操作，
    这个时候就至少需要 ip地址，ssh协议打开的端口（默认22）， Linux的用户名和密码
3、远程连接不上，经常是一下原因， 1、服务没有开启  2、网络不通（通过ping来检查） 3、防火墙隔离

99、http协议经常报404错误，502错误，500错误，根据这些错误，我们能推断出哪些信息？
404 可能我们构造的请求的url路径不对
502 和服务器连接不上
500 服务器内部错误， 这种要提交bug

100、做性能测试时，TPS是否和并发用户数有关？
参考答案：有关的，
TPS是英文TransactionsPerSecond的缩写，也就是事务数/秒，也叫系统吞吐量
TPS = 并发用户数*（1/平均响应时间） 等价于 一段时间内完成的事务数/时间
我们假定响应时间不变，响应时间RT=1S， 也就是完成一次事物需要1S
如果只有1个并发用户 那么TPS =1
如果只有2个并发用户 那么TPS =2
如果只有3个并发用户 那么TPS =3
注意实际情况，RT会随着并发用户数的增加而增加的。

101、 QQ传文件的功能， 你能想到多少需要测试的场景
QQ 传文件 ，扩展下这个词语： QQ通过网络传文件， 我们来分析下里面的名词和动词
名词： QQ 文件 网络 动词： 传

 QQ的属性：好友 非好友  QQ版本  在线  不在线
 文件属性：文件 文件夹    文件大小 文件类型  文件数量
 网络属性：网络好，网络差， 跨网
 
 根据我们提取出来的属性，分析出下面需要测试的场景

 1、给在线非好友传文件
 2、给不在线非好友传文件
 3、给不支持传文件版本的QQ的在线用户传文件
 4、给在线的好友传文件
 5、给不在线的好友传文件
 6、假如QQ支持单个QQ同时给5个用户传文件， 那么同时给5个用户和6个用户传文件
 7、传文件夹
 8、传文件
 9、文件大小最大支持XXG，  传XXG的文件和比XXG大一点的文件
 10、传不允许的文件类型
 11、同时支持传XX个文件，  那么测试同时传XX个文件， 测试同时传XX+1个文件
 12、支持文件的最大传输速率XX，需要测试是否有限制
 13、单个用户每天最大传输XXG文件，需要测试是否有限制
 14、 单个用户每天最多给XX人传输文件
 15、单个用户每天最多传输XX个文件
 16、传输过程中断网， 如何处理
 17、传输过程中网络很差，是否能够成功
 18、传输过程中取消
 19、传输时没有网络
 20、 传文件时对方拒绝

上面是我刚刚花了几分钟想到的测试场景，没有想到的继续补充
其实还有给群传文件等功能

102、 执行用例时，什么情况下修改用例， 什么情况下标记成成功 ，什么情况下标记成失败， 什么情况下标记成阻塞？
参考答案：
修改用例：情况1、用例描述不正确，或者写错了，这个时候和写用例的人确认下，修改过来， 情况2、需求变更，测试用例还是按照修改前的需求写的，这个时候需要根据最新的需求把测试用例修改过来， 情况3、测试用例场景有遗漏，需要补充
标记成功： 实际结果和预期结果一致
标记失败： 实际结果和预期结果不同，需要提交bug
标记阻塞： 执行用例还没有到最后一步时， 也就是执行到中间某一个步骤时，因为系统其他bug导致不能继续下去，标记阻塞

103、如何扩展自己的测试思路，提升自己的测试技巧？
咱们不讲哪些假大空的东西，说几个实实在在的套路
1、XXX功能， 网上查找相关功能都写了哪些测试场景，然后分析自己的功能是否也存在这些场景
2、分析其他人提交的bug单， 研究别人是怎么发现这个bug 的，扩展自己的测试思路
3、多看看组内哪些发现bug多的人的测试用例， 分析下她写用例的思路

104、什么是线上问题？测试需要做什么？
1、什么是线上问题？版本上线后，客户使用过程中遇到了bug， 反馈给研发团队的bug就是线上问题
2、测试一般主要是负责重现线上问题并且提单跟踪， 方便开发修改 ，开发修改后进行回归验证（一般在测试环境回归）。
3、测试如何复现bug呢？分析客户反馈的描述， 操作步骤， 如果有照片或者录屏更好， 然后思考可能重现方法， 根据想到的重现方法去重现bug ， 能够重现提交bug的时候注明重现的步骤， 实在不能重现的，也需要提交bug
4、线上bug也分严重等级， 严重的bug需要快速修改，快速给客户修复， 如果不严重的或者影响不大的， 可以后面的迭代中修复。

105、能不能帮忙举几个例子，1.测试和开发因为一个具体的什么问题有争议，然后我们是怎么处理的
场景1、订单（或者其他数据），新增XXX页面A有一个下拉菜单， 下拉菜单中的数据来自B页面， 如果B添加了数据， A需要关闭后再打开才能看到新数据， 因为新增时一个高频操作，我们觉得在A页面没点击一次下拉菜单就应该获取最新的数据，这样更加方便，但是开发认为重新打开一次页面也可以理解， 最后找产品确认， 产品定下来点击下拉菜单 就取最新的数据

106、我们觉得是bug，开发觉得不用改，然后怎么处理的
1、场景1、一个XX数据允许客户自己导入，我们制作了一个10W条的数据导入，结果导入失败， 开发说客户没有这么多数据，不算bug， 最后让产品找客户确认，发现确实有可能有10W条数据，后面开发给修改

107、转测试版本质量差怎么样办？开发老是忘这往哪的
质量差体现在哪些方面：
1、转测试的软件主要功能不可用 2、 给部署文档老是缺东少西的，要不断沟通才能部署好测试环境 3、转测试的功能bug很多， 需求里面明确说明的场景都没有覆盖完 4、bug老是修改不彻底，修改引出新问题
先说转测试版本质量差，有哪些影响：
1、浪费测试时间，测试好不容易把版本部署好了，发现不可测试，会延长测试周期
如何提高转测试的质量：
1、和开发负责人沟通， 讨论转测试的重要性
2、和开发达成一致，转测试必须提供哪些信息，也就是转测试的格式
3、和开发负责人沟通， 讨论开发自测的重要性
以上是参考建议

108、在迭代开发中，如何在保证质量的前提下，如何缩短测试周期，提高测试效率

1、需求分析阶段，和业务分析师一起写用户故事，参与到早期的需求讨论环节，尽可能多的了解需求
2、需求澄清阶段，和业务分析师，开发工程师，一起确认需求，确保大家理解一致
3、开发阶段：增加开发环境验证环节，开发人员完成后，在开发机器上多角色一起进行快速验证，这个是时候发现bug，开发直接修改，省去了提交bug，关闭bug的时间。
4、测试在写用例时，尽可多的考虑场景，这样在转测试后的第一轮测试可以尽早发现bug，
5、要求开发提高转测试质量，不要浪费测试时间，转测试质量差，就很浪费时间
6、由于是迭代开发， 产品的功能越来越多，需要测试的点也是越来越多， 这个时候添加一些必要的自动化测试，自动化测试覆盖的地方可以少投入人力， 提高测试进度
总的来说，迭代开发的团队中，测试要要参与到软件开发的全流程中，而且最好有自动化测试覆盖。

109、如何提高测试在开发那边的地位，一般开发觉得测试是小菜比， 这个怎么办？
1、提高自己的能力， 遇到bug最好找到bug的原因，这样方便开发修改，另外如果可以给出bug解决方案，那最好
2、尽可能多的发现bug，特别是那种开发没有考虑到的场景，尽量让自己测试的功能没有线上问题
3、还是要和开发搞好关系嘛，开发和测试在内部是对立关系，但是对外看，开发和测试都是研发，都是为了给客户交付好的产品。

110、 有时间来了一个紧急的版本，时间很紧，没有时间写用例，如何做好测试？
1、安排业务熟悉的人做这个紧急版本的测试
2、把版本的的修改点， 新增需求搞清楚，搞清楚这些变更是如何实现的
3、罗列主流程的测试用例（思维导图），优先保证主流程没有问题，然后再发散测试
4、在执行测试过程中，把测试过的点记录下来，这样方便事后检查自己哪些测试点还没有测试到
5、发现bug还是要提交bug，不能因为时间紧，而不提交bug，导致bug遗漏

111、 什么是冒烟测试，冒烟测试主要的目的是什么？
咱们就不讲哪些严格的定义
冒烟测试概念其实每个公司定义都有点不一样：
叫法1：有些公司把软件上线前的最后一轮测试叫冒烟测试， 叫法2： 有些公司把转测试后的预测试叫冒烟测试
这两种叫法对应的测试目的是完全不一样的
叫法1的目的：验证软件所有功能是可用的
叫法2的目的：验证转测试的版本是可以测试，没有出现转测试的功能大范围不可能用的情况

        叫法1和叫法2还是有共同点的：就是都是测试主流程，叫法1 测试所有功能的主流程， 叫法2测试转测试功能的主流程    

112、怎么评判产品是可测的，可以开始测了？什么标准的时候要打回给开发？
测试环境部署后，提交转测试内容都可以测试， 那么就可以开始测试啦，也就是预测试通过后就可以开始测试了
预测试不通过（核心功能不可测试），可以打回给开发

113、怎么保证自己测得覆盖的比较全？
用例层面
1、理解清楚需求， 确保需求中提到的点都实现了
2、测试用例不仅要覆盖正常的场景，还需要覆盖异常的场景
3、结合自己的经验， 分析类似模块的功能出现了哪些bug，然后看看自己用例是否覆盖了这些场景
4、认真做好测试用例评审，一个人的思路有限，大家一起思考就比较全面些
测试执行层面：
1、进行交叉测试，整个测试周期确保一个功能被多个人测试过
2、如果有空余时间，可以进行探索式测试，充分发挥人的发散思维来测试

114、现在大家都在讲敏捷开发，那对应的敏捷测试是怎么开展的？
1、敏捷开发 基本思路就是快速迭代， 小步快跑，持续响应用户需求的变化， 不断增加产品的功能
那敏捷测试就必须适应这种开发的节奏：
1、测试尽早接入，尽早搞清楚要做什么需求，这样测试可以准备的更充分写（很多时间在需求澄清的时候才介入）
2、理解清楚需求， 做好测试用例，做好用例评审
3、随着迭代的持续，产品功能越来越多，测试在每个迭代需要回归的功能越来越多， 实现合理的自动化测试，把人从重复的劳动中释放出来， 专注于新需求的测试
4、做好持续集成，尽早发现每次系统集成起来的bug
大概写了这几点，欢迎补充

115、一个偶现的问题，我们如何去重现，重现的思路是什么？
1、偶现的问题，说明我去重现了，只是没有复现出来， 不然你肯定不知道这个缺陷是不是偶现的
那我们怎么去重现呢？
1、仔细回顾自己的操作过程， 思考自己重现的过程是否和出现缺陷的过程一致
2、把出现bug 的日志找出来，看看日志中是否有报错，如果有分析，这个错误出现原因，不能分析出来找对应的开发看看
3、在重复自己步骤，查看日志都没有重现的情况下， 思考出现这个bug 可能和那些操作有关， 最好思考整个业务流有哪些情况， 比如订单显示不对， 业务流就是生成订单到结算订单到查看订单
然后看业务流的每个过程中数据库数据记录是否正确，日志中是否有异常
4、如果还是不能定位出来，还是要提交bug单，然后让开发定位

    以上是参考答案

116、sql语句练习题目
员工信息表 staff： user_id , name, store_id, salary
商店表store：store_id, name,city
题目1：
找出平均工资小于5000的商店所在的城市
select a.city b.story_id from story a,staff b  where b.story_id=a.story_id group by b.store_id having avg(b.salary)<5000

题目2 查找工资最低的人的名字，商店名字，商店所在城市

题目3查找每个店的店名、平均工资、城市

   分析： 店名  城市在 store  表中，  工资在  staff表中，   那么需要连接查询，   店的平均工资，  那么需要group by 店id，
      select  store.name,avg(salary),store.city from staff，store where  satff.store_id=store.store_id  group by store.id 

题目4 查询每个店的店名、平均工资、城市，且降序排列
select store.name, city, avg(salary) from staff,store where staff.store_id = store.stroe_id group by staff.store_id order by avg(salary) desc

题目5、查询重名的员工名字和重复次数。

题目6 ，查询每个商店的店名、员工数、城市，并且按照员工数升序排列。
select
s2.name 商店名,
s2.city 城市名,
count(s1.user_id) 员工数
from
staff s1,
store s2
where s1.store_id = s2.store_id
group by s1.store_id
order by count(s1.user_id) asc

题目7，count(*)和count(列名) 有何区别

题目8,连接查询的时候查询结果的列名一定要在前面加表名吗， 如 b.name

题目9、
员工信息表 staff： user_id , name, store_id, salary
商店表store：store_id, name,city
求每个店工资最高的人的名字，工资，所属商店，所属城市

SELECT
staff.name,
max_salary,
store_name,
city
FROM
(SELECT
staff.store_id AS store_id,
MAX(salary) AS max_salary,
store.name AS store_name,
store.city AS city
FROM
staff,
store
WHERE staff.store_id = store.store_id
GROUP BY staff.store_id

) AS aaa, staff WHERE aaa.store_id = staff.store_id AND aaa.max_salary= staff.salary;