敏捷测试学习.docxVIP

敏捷开发宣言中提到了敏捷开发的四个核心价值观：简明（Simplicity）、沟通（Communication）、反馈（Feedback）、勇气/决断（Courage） 敏捷测试的两个主要特点：“遵循敏捷宣言的测试实践，将开发当成是测试的客户”（Testing practice that follows the agile manifesto, treating development as the customer of testing），以及“在使用敏捷技术的项目中的测试实践”（Testing practice for projects using agile methodologies）。 敏捷过程中的测试是一个integration的任务，在不同层面（单元测试，集成测试，系统测试，用户验收测试）均需要按照敏捷的方式组织测试，目的是符合敏捷方法的价值观。 个敏捷项目中的测试工程师应该具有这样一些技能： 良好的沟通和协作能力； 良好的设计和代码能力，至少可以和开发工程师在同一水平上讨论具体的设计和代码实现； 快速学习和总结的能力（运用探索性测试发现缺陷）； 对自动化测试有深刻的理解（至少要能清楚的认识到自动化测试不等于UI自动化测试，也不等于用自动化测试工具进行录制和回放）； 快速的风险分析和判断能力（在许多情况下都不会有足够的时间开展full regression，如何判断风险和决定相应的对策至关重要）。 测试工程师必须完成的工作：? 与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试； 深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷； 建立系统和用户验收级别的测试验收标准； 通过自动化测试手段缩短每个产品发布周期中测试所需的时间； 测试工程师需要去推进的工作： 推 动低层次测试（单元测试和接口级别的测试）的进行。低层次是测试对于需要快速发布的敏捷开发来说至关重要，但在大部分国内的软件组织中，开发测试都需要经 过不断的推动才能被最终执行下去，测试工程师具有相关的测试技巧，并且能够用翔实的统计数据表明低层次测试的必要性，是最好的推动低层次测试的人选； 推 动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致。这一点对于敏捷组织来说也是至关重要的；在许多传统的软件开发组织中，经常能看 到开发和测试之间的扯皮，针对一个遗漏的缺陷，大家考虑第一件事不是如何去修复，如何去防止，而是首先“追究责任”─在敏捷过程中，需要一个非常不同的环 境：也即，质量责任是由所有工程师共同承担的，对于出现的问题，重要的是解决和预防。 能为项目带来巨大价值的工作 建 立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。保证产品质量度量的可见可以让整个团队清楚的看到我们现在正在工作的产品与 我们期望交付的产品在质量上还有多大的差距，这样整个团队可以以质量度量作为指示，集中精力工作在这些差距上，从而可以尽快的发布“可工作”的产品。“验 收测试的通过度”，“单元测试的通过率”，“功能完成情况”等等项目都可以是质量度量中的度量项。 通过技术或是管理的手段，保证产品、 代码具有良好的可测试性。良好的可测试性对于产品的维护，自动化测试的进行都是非常有利的─我觉得，甚至可以武断的说，如果一个应用系统没有良好的可测试 性，就很难期望可以在该项目上设置良好的测试框架。测试工程师一般不参与具体的设计工作和代码实施工作，但测试工程师可以推动开发工程师在设计和实现时尽 可能的考虑可测试性设计，另一方面，测试工程师也可以通过测试覆盖率这个质量及时发现应用中可测试性不强的地方，推动开发工程师的改进。 微软Visual Studio团队的敏捷之路 在讨论敏捷之前，我们先来看看Visual Studio团队的敏捷之路。 ?Visual Studio是微软最重要的核心开发工具，到去年10月止，全球.NET开发人员近6百万人，光是VS 2013年版本，下载次数就达到7百万次。 ?参与VS开发的人数超过4,700人，分布在美国、瑞士、中国、印度等地的微软研发中心。这群人要负责190万个开发工作项目，完成了近3,600万个程序代码库，累计数据量达到15.3TB。开发团队平均每个月会组建（Build）22万多次。 过去——瀑布开发模式 ?瀑布开发模式，开发时程约2年 ?花3个月时间来定制长期计划。其中，部门主管需要订定5年产品计划，而产品经理则是要想象2年后的市场需求，来拟定2年后产品上市时的功能蓝图。 然后再设定多个里程碑（如图M1、M2，会发布一个对应的测试版本）区分开发阶段，每阶段内先开发程序代码，再进行测试与功能稳定，达成里程碑后发布一个 顾客可用的版本。工程师们再依每一个里程碑估算自己的工作进度，