测试面试话题1：敏捷开发与测试

　　以下是我个人总结的一些经验：

　　传统开发模式：Ｖ模式，瀑布模式。传统开发模式往往循规蹈矩，从需求，概要设计，详细设计，开发，单元测试，集成测试，系统测试，验收测试，上线发布，整个周期往往需要半年到一年，由于周期长，产品在开发过程中会存在需求变化，传统模式不适应需求的变化。为了解决这个问题，当前出现了敏捷模式。

　　敏捷分为敏捷开发和敏捷测试，特点和特征是：

　　1. 测试驱动开发和行为驱动测试

　　测试驱动开发是指开发先写单元测试，再写开发的代码，当单元测试跑通的时候，代码开发就完成了。

　　行为驱动测试是通过直接写user story，例如Cucumber框架，说来也很简单，就是在excel里为每个测试用例写好场景对应的步骤，每个步骤又对应有关键字（动作函数），之后只要对userstory/测试场景进行补充，就可以扩展一个又一个的测试用例。当然刚开始的函数都需要一个一个去编写实现。

　　2. 小步快跑，拥抱变化

　　敏捷思想会把一个产品分成多个阶段，每个阶段大约２～４周，在这个２～４周里设定的需求是明确的，不接受过大的变化，这样能保证明确的需求的实现和产品的进度，对下一个周期需求，咱们拥抱变化。

　　3. 不过多强求文档话，强调人与人之间的沟通

　　不过多强求文档话，不是说拒绝文档，有文档是最好的，但是因为时间原因，不写文档时允许的。

　　强调人与人之间的沟通，开发测试人员在一个小的空间里（圆桌，没有挡板的办公环境），有问题可进行当面沟通。

　　4. 站会（用小黄贴，展示进度）

　　每日站会，开发和测试回报进度，把遇到的困难说出来讨论。每个人对项目整理进度也方便了解。

　　5. 结对编程

　　同一段代码由２个人写，一个人写代码，一个人review,或者交换。这个方式是google在用的一种方式

　　6. 持续集成

　　强调快速构建，快速测试，可以通过持续集成工具jenkins,好处是： 快速发现问题，快速定位问题，节约排查时间成本等。

　　7. 自动化测试

　　大多数是单元测试

　　8. 重构

　　因为敏捷开发时，注重的速度，很多代码写的不够好，之后可能需要重写代码，这时，单元测试就特别重要。 单元测试能检验代码重写是否正常。

　　测试面试话题2: 如何不漏测

　　不漏测这个话题本身就是个伪命题，微软的产品都天天打补丁呢，包括google, facebook都经常打补丁。测试人员是没有办法保证不漏测的，但是尽可能少漏测，而且每次保证漏测的原因都是不一样的。

　　不漏测就等于软件没有bug，这个是整个团队的事情，团队对整个产品质量负责，测试只是质量管理中的一个小环节。

　　如何通过团队来构建一个好的产品质量，才是一个好的话题。

　　产品测试分层和效果：单元测试>接口测试>UI测试

　　单元测试：开发需要做单元测试和代码 review来保证产品的健壮性

　　接口测试：接口层变化比较小，很适合做全面自动化，实现产品快速的回归；---测试人员

UI测试：UI层自动化测试＋探索式测试；UI层变化大，虽然大家都想做自动化，但是效果并不好；---测试人员

　　基于现有的情况，提高产品质量：

　　1. 梳理好研发流程，各司其职。

　　2. 从需求开始，测试就应该介入，并且了解每一个细节, 根据产品需求文档、产品设计文档（概要设计、详细设计）来设计详细的测试用例，并且让产品人员，开发人员一同参与评审，让团队的力量来对测试用例进行一个补充，这样可以大大减少漏测可能。

　　3. bug预防，测试框架，探索式测试在测试用例设计上的运用，可减少漏测出现。

　　4. 让项目的相关人员做一些抽测，从不同的角度去测试系统。

5. 群策群力。

　　测试面试话题3: 给你一个测试团队，你会如何管理？

　　这个是测试团队管理的话题

　　1. 管人

　　a. 招聘新人，找到合适的人，新人是需要做入职培训。让新人快速融入到团队中去，和开发和测试打成一片。

　　b. 与团队成员多做有效沟通，了解每个人真正诉求，根据诉求和公司的要求做一个管理上的平衡。

　　c. 设定KPI，合理的激励，奖惩分明。

　　d. 团建，增进了解。

　　2. 理事

　　a. 做好日常项目管理工作，监控项目的方方面面，保证公司的项目开发和质量要求。

　　a1. 团队成员往往以测试组的名字接不同的测试项目，需要全局把握项目的进展，比如说：需求是否了解足够充分，测试用例设计的是否足够充分，项目执行过程中是否有什么风险

　　b. 根据每个人的诉求和特点，合理的安排每个人的工作（喜欢挑战的，就给一些挑战性的工作；　不喜欢挑战的，就给一些日常性的工作）。

　　管理没有真正意义上的对和错，让每个人开开心心的工作，做到一个平衡，就算是成功了。