软件测试面试一百问：4：敏捷开发流程中的测试流程
再来说一说敏捷开发流程中的测试流程。前面简单的讲了敏捷开发流程，参与过敏捷流程的同志们也会有个清晰的认识，相对于传统开发流程，敏捷开发流程要求所有的参与人员能够更快速更高效的应对变化。
所以对敏捷流程中的测试人员要求更高了。
名词解释：
sprint：项目开发过程中最小迭代周期，根据同的项目周期不同；现有产品维护1~5天，二次开发5~10，
新项目5~30，业务复杂或开发所用语言较多或开发复杂度较高10~45
Story：敏捷开发的基础，把原本需求拆成最小粒度的Story，以方便拆分Task，估计开发时间，领取开发任务。
第一点：先说项目进入需求讨论和开发阶段，这个时间点测试应该做些什么？
项目经理和产品经理会根据客户的需求，制定概要的产品发布日程计划。
此时，测试人员可以和开发人员一起学习新的功能，了解客户的需求。其中，有两个主要活动：了解需求和设计测试案例。
不同于传统开发模式过程中开发将所有的功能统一开发，敏捷开发流程中开发人员通常会关注功能的实现而忽视很多的细节。所以就要求测试人员从各种角度来挖掘需求，探寻隐藏的功能点。
测试对象的粒度也是到story的，所以先将story的功能实现案例设计完成，
定义完一系列user story（用户故事）后，测试人员就可以着手设计概要的系统测试用例。
系统测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。测试人员可以根据每个story来扩展，前景和后景进行关联，寻找其中的“动作”，然后为每条“动作”制定正例和反例。
第二点：迭代 Sprint 阶段
在每个sprint阶段中开发人员在做代码coding和单元测试的时候，测试人员在案例设计或者上一个sprint的测试阶段。
如果一个sprint只有一周的话，工作日5天，周一周二软件开发，周三周四测试，周五总结已经下个sprit分析。
测试人员的时间和开发时间竟然相同？不会有问题？
当然不相同，目前正常的软件和测试人员的比例是3:1到4：1的样子，也就是正常三四个开发对应一个测试人员。
当然不同的公司或者项目还是有差别的。
由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。
对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；
而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。
此外，对测试中出现的缺陷可以设计回归测试用例（Regression Test Case），
为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。
敏捷开发不提倡撰写太多的文档，提倡直接编写测试用例。
此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化成验收测试用例。如果资源充足，最好对验收测试用例建立版本控制机制。
第三点：Sprint结束
在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。
团队成员可以在会议上畅所欲言，指出在过去一个 Sprint 周期中可行的，不可行的和有待改进的地方。
待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。
由于敏捷开发倡导增量开发，当新的 Sprint 开始时，测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。
如果新 Sprint 周期没有具体的新功能开发，测试团队可以将精力集中在执行验收测试和寻找缺陷上。
如果下一个 Sprint 周期是发布周期，那么测试人员需要准备执行回归测试。
第四点：手工测试和自动测试是两个主要的测试类型。
考虑到敏捷开发的高效性，自动测试会优于手工测试。
手工测试有两个主要的缺点：不可靠和容易被遗忘。
当测试人员按部就班得手工完成一个一个测试用例时，他们很容易遗忘一些特殊的测试用例，很多缺陷因此而被埋没。
敏捷测试主张一些基本的验收测试可以被自动化；对一些涉及系统方面的测试，手工测试比较适合。
以上我们简单的了解了敏捷开发中的测试流程，其实我们写的还是太粗略，很多的细节无法设计到，后续会专门哪一个项目来着重讲解一下。
页:
[1]
