霜波说测试（二）--敏捷开发中的测试
随着市场越来越走向多变，企业越来越追求创新，敏捷开发已经变成各个软件企业追求的方向。但是在传统的敏捷开发流程中并不存在测试这一角色，那么测试这一角色是否需要，如果需要应该如何不让测试成为敏捷的障碍，我们在这篇文章中一起探索下。1：是否需要专业测试人员
凡事做到极好，恰好而已。恰好由什么决定，由天，地，人来决定。所以是否需要测试不取决于流程，不取决于理论，取决于当时的环境、需求还有人的基本素质。一个抢占市场还没有用户的产品是否需要测试，需要测试，但是完全可以由开发人员本身来承担测试的工作，不需要专业测试人员的介入。但是一个已经有大量用户在使用，对稳定性和质量要求极高的产品是否需要专业的测试人员。答案就是肯定了，需要。我们需要专业的测试人员，他需要能将各个开发的模块组合起来系统验证，他需要能预先设定各种可能存在的异常和风险，他需要能对系统的性能有专业的测试方法和工具，最重要的是他需要从用户角度来考虑需求而不是从设计的角度来思考。
容我再啰唆一句：从心理学的角度来说：测试人员会把发现问题看做成功，因此在测试执行的过程中他们希望发现bug。开发人员会把发现bug看做是失败，在测试的过程中他们并不希望看到问题的存在。由于潜意识的出发点不同直接导致测试结果的不同。毫无疑问测试人员更加容易发现存在的问题和风险。
2：有了测试人员的敏捷开发如何才能敏捷
毫无疑问，多了测试人员的介入，多了一层的沟通环节和流程我们的效率会有所下降，但是我们的收获是质量会有更多的保障。接下来我们需要想的是如何在测试人员介入的情况下提高效率：
a：测试人员成为开发scrum的一份子，和开发人员坐在一起，参与开发人员每日的晨会，需求Review会，设计讨论，代码讨论，对设计了解的越清楚越能减少后期沟通的成本。
b：测试testcase适量的先行。在项目早期准备充分和大量详尽的testcase是比较浪费的，很可能在项目的过程中我们需要不断的变更和维护这些testcase。但是等到开发完成的时候才开始testcase的准备又太晚了，这个时候我们已经很难保证提交产品的质量是在几轮回归的过程中就可以测试完成。所以，我建议在需求分析之后，代码编码之前将满足产品需要的BVT的testcase先行完成，并且将这部分的testcase拿来和开发产品一起进行testcase review。同时要求开发每次提交代码之前都先行跑过这部分bvt的testcase再提交测试。在早期的时候bvt的自动化testcase可以由测试人员和开发人员一起完成，但在以后的回归阶段，bvt的测试用例更多的由开发人员自行完成。
c：可持续集成的测试。如果想让流程敏捷，最终的思想还是集中在越早发现问题，越早纠正问题，越能减少后期的投入和项目整体的投入。测试可以提早介入需求讨论，设计分析，代码Review，但是要提早发现问题，开发单元自测的代码必不可少。如果单元测试的代码在后期完成，每次运行的结果多数是成功，那么给人的感觉是我在做无用的工作，所以会轻视单元测试的作用，但是如果在开发代码之前就准备好单元测试的脚本，体会就不一样，首先单元测试的脚本是一个整理需求的过程，如果在这个过程发现需求有任何模糊的地方都可以及时和需求沟通，同时，每次的单元测试用例在之前都是fail的，但是随着开发工作的进行，越来越的测试用例会从fail转变为pass。这个转变能带给开发工作者极大的快乐和成就感。所以TDD（测试驱动开发）的开发模式对于敏捷开发是非常关键的环节。开发代码和单元测试的代码应该一起上传，上传之后出发所有相关联模块的单元测试脚本的及时回归。如果时间允许应该也同时触发所有测试自动化脚本的及时回归，只有最及时回归和反馈才能减少错误定位和修正的时间，也才可能让敏捷流程真正的敏捷起来。
d:测试和开发的互为备份：在敏捷开发中，不把测试作为和开发相对应的一个独立过程，而是将测试融入开发的全部阶段，二者是紧密配合协作的，只是在方向各有偏向并且各有专攻。当瓶颈出现在开发过程中，测试人员可以帮助开发一起完善单元测试的脚本，当瓶颈出现在测试阶段，开发人员可以帮助测试进行测试脚本的完善和执行。但是开发的代码应该有开发自己完成，测试用例应该由测试人员来设计和编写。也就是说每个角色的核心产出：开发的代码和测试的测试用例不应该由其他人员来替代完成。
真正保证质量的改善用户体验的是人，不是流程，但是流程的规范和完善能够让很多繁杂的工作变得轻松和顺畅起来。让更多人能够集中精力投入有意义而且感觉开心有成就感的工作。流程让工作成为一种习惯，而习惯让工作轻松高效。敏捷的流程是所有互联网必然发展的方向，原因只有一个，因为世界已经变得越来越快，我们要成功，就只能变得比他更加迅速。
霜波
附招聘广告一则：淘宝广告技术测试部长期招聘软件开发测试工程师，欢迎投递简历至shuangbo@taobao.com
职位：软件开发测试工程师（SDET）
部门：淘宝-技术研发部-广告技术
工作地点: 杭州
招聘人数：20人
职位描述
1. 参与互联网软件产品的测试，包括参与需求和设计评审，设计和执行测试用例，进行缺陷跟踪等；
2. 可能涉及的工作领域包括广告业务系统，广告投放引擎和算法，淘宝搜索引擎和匹配排序算法，分布式存储和CDN等核心系统，分布式计算及淘宝海量数据的分析和挖掘等；
3. 开发和维护自动化测试脚本和工具，提升测试的质量和效率；
4. 执行软件产品的性能测试并分析结果。
职位要求
1. 计算机或其他相关专业本科以上学历；
2. 一年以上软件开发、自动化测试或白盒测试工作经验；
3. 熟悉C/C++或Java编程，有Shell或PHP/Perl/Python/Ruby等使用经验者优先；
4. 熟悉Linux或Unix操作系统；
5. 熟悉Oracle或MySQL数据库基本操作；
6. 熟悉基本测试流程和测试方法，掌握基本的性能测试工具、方法、性能指标等；
7. 良好的学习能力，沟通与团队合作能力。 敏捷开发不适合中国目前的大环境，期望你们真的能走出一条敏捷开发的阳光大道。
也希望楼主能认真考虑一下：敏捷开发真的敏捷了么？它对工作效率、工作质量的影响是正面的还是负面的？从项目管理的角度看成本是增加了还是减少了？ 敏捷开发对测试工程师的技能要求很高，一般的功能测试工程师基本无法敏捷起来。 回复 2# Nio
哈。。
我承认敏捷开发所需的代价也的确不菲啊，可是并不是适合大型项目/产品的开发，不能否认人的主观能动性，但是也不能忽视局限性。
心有多大，舞台就有多大——作为广告语还不错，而大多数情况下，是舞台的大小，决定了其规模、品质要求和诸如人员素质等等。 学习学习，看完之后感触良多，受益匪浅 可惜是在杭州
页:
[1]
