敏捷测试和面试的知识点分享

lsekfe

　敏捷
　　敏捷是什么？
　　区别于传统的模型，敏捷是一个迭代式的研发模型。
　　敏捷开发的最大特点：高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。有时候讲究所有人集中所有精力快速完成一件事情。
　　敏捷测试(Agile testing)
　　测试的一种, 主张尽早开始测试，重点关注持续迭代地测试新开发的功能.。敏捷的测试团队还要保证整个软件开发过程是正确的是符合用户需求的。
　　遵循：
　　1、强调从客户的角度，即从使用系统的用户角度，来测试系统。
　　2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
　　3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
　　敏捷测试与传统测试的区别
　　·项目相当于开发与测试并行，项目整体时间较快
　　· 模块提交较快，测试时较有压迫感
　　· 工作任务划分清晰，工作效率较高
　　· 项目规划要合理，不然测试时会出现复测的现象，加大工作量
　　· 发现问题需跟紧，项目中人员都比较忙，问题很容易被遗忘
　　· 耗时、或较难解决对项目影响不大的问题一般会遗留到下个阶段解决
　　· 发现BUG能够很快的解决，对相关的模块的测试影响比较小
　　· 版本更换比较勤，影响到测试的速度
　　· 要多与开发沟通
　　· 要注意版本的更新情况
　　· 测试人员几乎要参加整个项目组的所有会议
　　敏捷要了解的
　　· Incremental test 增量测试
　　全回归测试太多了，每次迭代做一部分，分开的总量合起来就是完整的测试用例数量。
　　· Exploratory test 探索性测试

　　· Retrospective meeting 回顾总结的会议

　　· Stand up meeting
　　· 燃尽图（英語：burn down chart）：是用于表示剩余工作量的工作图表，是对需要完成的工作的一种可视化。
　　  -表示由横轴（X）和纵轴（Y）组成，横轴表示时间，纵轴表示工作量。
　　  - 这种图表可以直观的预测何时工作将全部完成，常用于软件开发中的敏捷软件开发方式，也可以用于其他类型的工作流程监控。（禅道新版本里面有这个图）
　　组织架构
　　PO(Product Owner)一名，项目拥有者
　　TPM(Technology Project Manager)一名，技术项目经理
　　DEV Leader一名，开发组长
　　Developer二到四名，码农
　　Test Leader一名，测试组长
　　Test engineer两名，测试工程师
　　Scrum Master一名，除了PO和TPM谁都能争取，是一个服务型领导，沟通、推动用的，可以开发组长或者测试组长选一个


　　重点：敏捷面试问题
　　以下来自测试大神杰哥(Jeremy老师)的解说：
　　1. 敏捷是一种怎么样的模型？
　　区别于传统的模型，敏捷是一个迭代式的研发模型。
　　迭代就是循环做一件事情：一般正常情况下迭代周期是一周、两周或者四周，面试的时候最好说四周，否则时间太紧搞不定。
　　=以一个月举例=：
　　第 1 周我们一般做的是需求调研(和开发)。产品经理会给我们介绍，我们这次迭代要交给客户怎么样的功能，完成什么样的新功能，包括一些缺陷的修复，或者说一些功能的优化，这些都是属于敏捷的范围。作为测试来讲，应该是要理清楚这次敏捷，做一些什么任务，（领导会分配任务）。那么如果是对于新需求的话，其实敏捷的第 1 周我们大量的时间是在搞需求研究，研究完以后，就开始做一些测试点的一个设置了。
　　第 2 周的早期，我们就尽量把已经设计完了测试点进行一个评审。等评审完以后，开始把这些已经设计过的测试点写成测试用例。
　　前两周测试主要是做一些测试设计工作，开发其实也是在做一些需求分析调研，然后他们也在写代码，一般到了第 3 周和第 4 周，就会进入测试执行阶段，执行之前写的测试用例。期间会不断的更新版本，内部的版本一定会加上去，开发也不断地在修复。
　　尤其是到了第 4 周，主要就是解决第 3 周执行下来发现的 bug。
　　·如果说第 4 周的周五，我们就要发布这个版本给客户了，那么到了第 4 周的中间比如说周三，我们应该要把所有的功能里面的测试工作都结束，也就是执行工作全部要结束，包含测试用例的执行。然后所有的缺陷全部都要修复完毕以后验证通过。
　　· 周四，我们要进行一个回归测试，这个回归测试指的是系统的一个回归测试，包括一些老的功能等等，各模块的功能都要测试一遍，然后抽取那些优先级高的那些测试用例，作为我们的回归测试。
　　· 到了周五我们就要上线了，上线前有一个预发布的一个上线，外面也有人叫灰度环境（预发布的测试环境），我们进行一个冒烟测试，对这次要提交的给客户的新功能进行一个大致的测试，也是执行测试用例。预发布通过了以后，我们就正式上线。上线以后以后我们还会快速的进行一下冒烟测试，使用的是生产环境。
　　（如果上线之后冒烟测试出问题了，绝对不是测试的问题，有可能是一些开发配置的问题，这种情况下我们的紧急预案就是把它撤回来，回到原来那个版本。）
　　敏捷的大致流程就是前两周以写测试用例为主，后两周以集中执行用例为主。但是也有可能在第 2 周的某一天，这时候你已经把功能 c 测试用例设计完了，开发说你可以测试功能 c 了，这时候就要先开始执行测试了。一旦有执行就必须早点执行，早点执行才能早点发现问题，能让开发早点改掉。
　　补充：
　　回归测试和验证缺陷以及冒烟测试，这些是从测试执行阶段，每一天都在做的。因为冒烟是每一个版本都会去进行冒烟的。开发那边一天可以有几十个版本，但是一般开发和测试会约定好，每天给测试一个可执行的版本，这个可执行的版本提交给测试以后，测试进行一个冒烟测试，看一下主流程通过没有，如果不通过立马打回，让他们立马给一个新版本，通过的话，我们当天就回基于这个版本继续我们后面的工作。
　　一般情况我们第 2 天早上拿到的版本，就是开发昨天晚上发的最后一个版本，我们早上拿版本以后，立马进行一个冒烟，如果有问题，有问题是很正常的，经常会发生的，那么我们会立马叫开发出一个新的版本，作为我们今天的测试版本。这个版本里面会包含昨天一天开发所有修复的缺陷。测试在禅道里去看自己的缺陷，哪些是已经修复的状态，它上面传到上面会标版本号，在这个版本上进行缺陷验证。
　　回归测试一直要回归的，首先缺陷验证其实就是一种回归，要把之前已经失败的测试用例重新跑一遍，这个也算回归。还有一种情况就是说开发说缺陷我已经修改好代码了，但是可能会影响到另外一个功能，这个时候就要立马对另外一个功能进行回归测试，就要挑选一下另外功能比较重要的进行回归测试。
　　回归测试完成后就继续执行那些没有执行过的测试用例，要记住测试用例的执行率必须是 100%。
　　（可以跟面试官聊我们的执行通过率，最后上线的标准，也就是交给客户的标准。执行率 100%，测试的通过率 95%，就是说如果有 100 个测试用例，允许有 5 个测试用例不通过，失败了 5%，开发也没有修复。但是这些没有修复的缺陷不可以有严重的缺陷）
　　2. 敏捷的过程中有没有用过什么 mock 工具 造数据
　　敏捷跟工具没有半毛钱关系，不要陷入面试官的圈套。
　　他的意思是说，敏捷可能会发生：比如说你承接的一个任务，任务 a 和任务 b，b 依赖a，但是b开发完，a没有开发完。
　　那么为了测试b，就会做一些 mock 数据，做一些临时的数据，可以让测试执行下去。
　　3. 敏捷的过程中遇到的问题？
　　敏捷过程中最大的问题说白了就是时间的 delay。
　　敏捷讲究的是每天要早上开站会，开站会的目的就是比如开发计划好，本周二一定要提交给测试，那么测试周三就可以开始执行测试用例。但是有时候计划赶不上变化，开发没有按照他说的那一天提交给测试，他的代码还没有写完。这时候整个测试计划就被打乱了.
　　面试时就说这时候也没有办法，我只能先进行后面的计划，先写一点其他的测试用例或者先执行其它功能的测试用例。这是我们遇到过的一个问题，但是后面我们都改正过来了，团队合作更团结了。
　　敏捷里面还会出现比较多的一个问题是，测试有很大一部分工作量在回归测试上面，因为敏捷时间周期比较短，但是之前所有的我们也都要测试，怎么可能在一两天内把几年内积累的所有功能都测一遍，这也是敏捷测试里的一个痛点。
　　解决方案就是让开发提供影响性分析，开发改的代码可能会影响到哪些模块，测试就根
　　据这份列表，去找 到对应的测试用例，进行回归测试。
　　4. 如果需求变更了，有两种情况，一种是客户那边提出的需求变更，还有一种是之前的遗漏的一些点。这种情况怎么解决，怎么跟进的？
　　理论上来说，一个好的团队是不允许客户在研发阶段去变更需求的，其实这个问题不应该由测试来解决。但是客户毕竟是上帝，而且我们要拥抱变化，当然这不能是常态，万一紧急的变更怎么办？
　　这种情况只能通过加班加点来完成工作，同时为了更有效率进行呢，我还会考虑一下影响性分析，因为只要有需求变更，就说明开发又要改代码了，就可以去问开发有没有哪些可能会影响到的功能模块，然后有策略的做回归测试，
　　如果是遗漏点的需求变更也是一样的，还是要先做好影响性分析，然后进行回归测试。

oliver.tang

内容很多，慢慢消化下