面经 | 管理规划

一、题目记录之应用问题

（一）测试职业的理解

测试的主要工作就是收集证据、→ 形成假设，→ 执行操作、→ 验证假设。

这也是Cem Kaner他们在一次演讲中就说过的。测试人员的关键在验证“逻辑”，验证“合理性”，而开发人员的关键在于证明“可行性”。
这明明就是两种不同的工作内容，要去比较他们的技术，该如何比呢？
同一个系统，开发人员要对系统进行修改和增加功能，他们必须要知道系统的设计原理、架构，以及相应的开发语言和环境，还要去读代码，理解代码的实现，因为这些都是他们增加新功能新代码的时候会涉及到的。
而测试人员呢？当然也要了解系统的设计原理和架构，因为这样才能相应地设计出充分且足够的测试用例去覆盖，语言和代码部分了解即可，环境当然也要懂，但主要的不是开发环境，而是测试环境。

那么，我们可以说，开发对系统的熟悉要达到“掌握”的程度，而测试熟悉到“理解”程度也差不多够了。
但是我们再回过来看的话，开发通常只需要也只能够了解系统的一部分，因为他们要深入，要掌握这一部分所有的细节。而测试呢，因为不需要深入了解实现的过程和知识，更关注的是软件的呈现，通常所负责的范围会比开发的宽，知道系统更多部分的原理。
从这个角度来比较，开发的知识量远远不足啊，就好比是开发只知道一个模块，而测试却知道好几个甚至十几二十个模块，谁更牛？
有些朋友可能不爽了，说开发也懂很多模块的啊？别拿个例来说话，那测试也一样有很牛逼的人呢。我们说的是一般情况，也即average的情况。任何一个人只要肯投入时间不断地精炼自己的能力，横跨几个领域不也是很正常的事情么，这一点《异类》等文章里有描述，不多说。

但另一点不得不提的是，上述的说法也取决于所处的行业以及产品的关键因素在哪里，也决定了开发、测试的边界在何处，也决定了开发、测试人员的比例以及他们对这个问题的回答。比如coolshell在博客和微博上都有表过的态，他认为不需要有专职的测试（有兴趣的去看他博客、微博，此处不讨论）。
提升自身竞争力，跟担当什么角色没有关系。只要你能认清楚角色的价值、所需要具备的技能，不断地修炼、反思和继续提高，就行。开发工作每天都有写代码这个很明确的任务驱动着，要学习什么通常也有解决问题（例如需要找到某个API来实现某个功能）来驱动着，所以相对来说，提高的进度更可见。
而测试人员，更重要的是理解各种“道理”，也即系统运行的道理、各模块集成的道理、客户提交bug背后的道理，这些，则是不那么容易见效的东西，而当你认清楚了一个道理的时候也并没有那么容易被人看见，所以只是相对来说，提高的进度不那么可见。因而会让大家觉得好像测试的提升没有开发快。
但测试有一个好处，就是道理通常都是想通的，在顺畅的情况下，到了职业发展的中期，相对来说会体现出更大的优势，因为，由于工作所养成的习惯，更喜欢也更容易做到触类旁通、举一反三。（别跟我谈开发也可以，当然可以，他们学好了一门语言，学另一门自然快。但我谈的是理解不同的模块、部件、子系统、系统等等这个维度。）

（二）为什么选择自动化测试而不去去搞开发

（三）请用编程的思路来介绍自己？你的优点是什么？你觉得测试人员应该有什么必备的东西？

（四）关于测试工具和测试流程的方法和实践，然后阐述自己的看法？

（五）问在需求评审的时候作为测试应该注意什么？你觉得你如何能胜任这个工作，你的优势是什么？

二、题目记录之测试流程管理

（一）软件测试流程

需求评审-测试计划-测试策略-测试要点-测试用例-用例评审-测试执行-缺陷提交-缺陷回归-测试报告-测试总结

（二）如何平衡手动测试和代码测试

（三）服务端测试流程

（四）什么叫灰度测试,为什么要进行灰度测试?

灰度测试是什么意思呢?
其实灰度测试就是指如果软件要在不久的将来推出一个全新的功能,或者做一次比较重大的改版的话,要先进行一个小范围的尝试工作,然后再慢慢放量,直到这个全新的功能覆盖到所有的系统用户,也就是说在新功能上线的黑白之间有一个灰,所以这种方法也通常被称为灰度测试从目前来看,灰度测试存在两种方式,一种是软件系统内自带灰度测试发布系统,另一种方式就是使用第三方工具来辅助进行,这两种方法都是可行的。
灰度测试这种方法可以帮助团队快速试验并发现问题并在大规模推向用户之前及时把问题修正过来,很大成度上减少了不少风险的产生,所以灰度测试是很有必要的。
要知道只有不断创意并完善的软件才能在激烈的市场竞争中立于不败之地,当有创意的时候,小规模的灰度测试是非常有必要的。
不但满足了一部分人抢先体验的愿望同时也可以发展研发团队不容易发现的各种问题,还能收集到真正的用户体验,这些对于优化全新的系统内容都是非常有帮助的,如果没有灰度测试的话,其实和闭门造车的感觉是差不多了,在增加灰度测试以后才能真正把其推向用户。
灰度测试存在的意义是什么呢?要知道现在很多互联网产品都存在用户规模非常大,版本更新过于频繁的问题,每当有新版本进行更新或者上线的时候,新的版本都是要承受非常大的压力的,而灰度测试的使用则可以很好的规避这种存在可能性非常大的风险问题。

（五）你印象最深的Bug? BUG定位技巧了解哪些？

（六）如何对测试用例进行优化与提炼，精简不必要测试用例？

（七）关于BUG提交

提交bug是个既愉快又痛苦的过程。因为有时候bug会很多（特别是前期），项目周期又很忙。但是好的bug能避免很多麻烦。比如避免了开发让你 重现的情况（不绝对，有些开发确实自身有问题），避免了 开发看不懂又找你麻烦的情况，避免了时间久了 自己都看不懂的情况。
什么样的bug才是好bug。曾经有人面试过我这个问题，我忘了怎么回答的了，但是他提到一点，有图的bug是好bug。这印证了有图有真相的那句话。确实能够用图表说明的bug确实比纯文字描述的bug好理解的多，久了之后，也不至于开发不认账。
至于bug不重复、严重等级、优先级这些问题这里就不谈了，这是基本的东西，而且每个公司不一样。

1. 关于截图，要有 截图（如果有日志更好），这很有说明性，可以说明绝大部分情况，开发也能一目了然。也便于跟踪
2. 关于标题，语言描述始终是个难题，如果bug的标题能让开发猜对 80%应该算是成功的。所以至少要有‘在哪里’，‘做了什么’，‘导致出现了什么问题’，这几点要清晰。关于做了什么做好找到最短路径，否则就在详情中说清楚。
3. 关于跟踪，有时候提交bug会忘记一些信息，这些信息最好在发现的时候补上，重新修改自己的bug不丢脸。即使是错误的bug，及时去修改也避免了浪费时间，因为大家始终会发现的，所以没必要刻意隐瞒人都会犯错。
4. 关于偶现，偶现的bug经常遇到，发现了就先提交吧，有时候死磕也不容易复现的。如果上线后或者几个版本都没有出现再关闭总比在线上发现好。
5. 关于回归，回归环境、版本、结果（通过、不通过、变相通过、场景不存在...）、步骤，应该要有，方便回溯。
6. 关于项目周期很紧，很多情况是因为bug太多，提交bug会占据很多时间，所以很多同事就简单几句，就把bug提交了，为后面埋了很多坑。其实截个图，把标题的要素习惯养起来，提交bug也会很快的。

（八）如何评判系统是否具备可测性？（冒烟测试通过标准）

以下有1条执行结果，冒烟测试不通过:

1. 提测模块中，不可测试的功能点占总功能的30%以上。
2. 崩溃或BUG导致70%以上的功能无法测试；
3. 个别BUG导致60%以上的功能逻辑不可测试；
4. 核心业务流25%以上不合格

（九）如何保障测试的充分度？

1. 这里给你一个简单的保证测试用例完整性的解决方案，
2. 最重要的是行业经验 一定要懂产品的定位和价值
3. 根据ui界面，界面功能，前后交互，用户流程，商家流程，异常测试，新旧数据，兼容测试，安全测试，权限测试，性能响应等等基本可以涵盖

（十）什么是测试用例?什么是测试脚本他们两者的关系是怎样的

（十一）给你一个网站,你如何进行测试?

（十二）解释下TDD是什么意思?

TDD（测试驱动开发 Test Driven Development）**
TDD（Test-Driven Development） 测试驱动开发 是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。
TDD测试驱动开发，简单的理解就是通过测试来推动整个开发的进行。就像建房子时，先把框架给你搭好，开发需要做的就是按照框架来开发每个功能。
TDD优点： 目标明确，架构清晰，可以保证不会偏离需求。 每个阶段就能进行测试，节省开发成本。TDD缺点：架构提前搭好，灵活性差，需求一旦有变更，就要重新更新测试用例。
BDD（行为驱动开发 Behavior Driven Development）**
BDD（Behavior Driven Development）行为驱动开发是一种敏捷软件开发的技术，它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD最初是由Dan North在2003年命名，它包括验收测试和客户测试驱动等的极限编程的实践，作为对测试驱动开发的回应。
BDD关注的是业务领域，而不是技术。BDD强调用领域特定语言描述用户行为，定义业务需求，让开发者集中精力于代码的写法而不是技术细节上。着重在整个开发层面所有参与者对行为和业务的理解。
BDD的优点是： 将各个参与协作团队的人员（跨领域）集中在一起达成一致的理解，节约了很多协作上的沟通时间。具有明确的目的性，准确的让参与协作人员认识到开发什么。
TDD和BDD的区别