本文目录
- 总是听说敏捷测试，敏捷开发了解，这个敏捷测试是这样的
- 什么是敏捷测试
- 敏捷开发中，测试人员做哪些工作
- 关于敏捷开发模式下的测试如何开展
- 什么是敏捷软件测试
- 敏捷开发流程中测试工作各阶段的内容有哪些
- 敏捷开发模式用的测试是什么模型
- 敏捷开发对于什么样的公司来说是好的选择
- 如何评价领导要用代码行数衡量每个人的工作量
- 如何在引入敏捷开发的时候，取得团队的支持
总是听说敏捷测试，敏捷开发了解，这个敏捷测试是这样的
敏捷测试应该是适应敏捷方法而采用的新的测试流程、方法和实践，对传统的测试流程有所剪裁，有所不同的侧重，例如减少测试计划、测试用例设计等工作的比重，增加与产品设计人员、开发人员的交流和协作。在敏捷测试流程中，参与单元测试，关注持续迭代的新功能，针对这些新功能进行足够的验收测试，而对原有功能的回归测试则依赖于自动化测试。由于敏捷方法中迭代周期短，测试人员尽早开始测试，包括及时对需求、开发设计的评审，更重要的是能够及时、持续的对软件产品质量进行反馈。
在敏捷方法中，需求变化比较快、产品开发周期很短，我们目前采用四周时间，也就是每个月发布一个新版本。开发周期短，功能不断累加，给测试带来很大的挑战，测试流程要做相应的调整。
在对新功能进行app功能测试和回归测试策略上，测试任务简单地可分为新功能测试和回归测试。在敏捷方法中，针对这两部分的测试建立相应的策略，加上自动化测试，以提高测试的效率，最大限度地降低质量风险。
TestBird - 手游和App自动化测试平台
什么是敏捷测试
什么是敏捷测试
首先敏捷测试(Agile
testing)是测试的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。
2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。
敏捷开发的最大特点是高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。敏捷测试即是不断修正质量指标，正确建立测试策略，确认客户的有效需求得以圆满实现和确保整个生产的过程安全的、及时的发布最终产品。
敏捷开发中，测试人员做哪些工作
对应的敏捷测试,敏捷方法强调测试驱动,在编写功能模块前,首先编写对应的测试代码和测试用例,代码写完后用测试代码进行测试.敏捷方法集中精力在单元层次上实现自动化测试，主要由开发人员实施，测试人员提供单元测试框架，并辅助完成一些所需的基础工作。
关于敏捷开发模式下的测试如何开展
1、敏捷开发模型：
Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。
2、如何开展测试：
敏捷模式下的测试要与开发工作开展模式结合，让开发反过来也配合测试，开发的工作可以合力完成一部分后交给测试，
此时，测试既有任务可以开展，开发又能继续接下来的新任务，而不是开发集中开发，测试集中测试，这种模式下已经
脱离了敏捷的概念，开发要敏捷，测试也要敏捷；
什么是敏捷软件测试
【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。
既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。
那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离
建立单元测试覆盖率等度量指标
共享质量目标意味着质量责任由所有工程师共同承担
开发测试应该建立一定的测试覆盖率标准，例如，在单元测试这个级别上，建立60%或80%的覆盖率要求
通过使用TDD、BDD等技术，保证产品和代码的可测试性
建立足够多的自动化测试，保证测试能够满足快速迭代的要求
检查表提到了团队、反馈、质量文化和开发测试四个方面的内容，在本人看来，这四个方面体现的就是敏捷软件测试与传统软件测试的最大的不同。传统软件测试关注的是通过尽可能完备的覆盖去发现尽可能多的问题，把测试和开发当成是两个独立的过程，测试是对开发阶段产生成果的验证
。而敏捷软件测试则建立了一种不同的质量文化：测试的目的是为了保证产品快速发布，也就是对生产率本身的提高。基于验证的出发点必然会要求测试与开发的独立，以及尽可能客观和完备的度量产品质量；而基于生产率的出发点则要求建立敏捷的团队，要求测试与开发尽可能紧密，要求建立具有高度可测试性的软件，以及基于这些的高度自动化测试。
在检查表列出的所有项目中，质量文化是基础，团队是敏捷软件测试得以实施的条件，反馈和开发测试则是敏捷软件测试的具体方法。当然，你可以可以从敏捷的核心价值观来阶段这些项目：团队关注的是沟通与尊重；反馈直接对应于反馈；质量文化基于勇气（承担质量责任的勇气）与尊重；而开发测试则是反馈与简单的具体体现。
另一个在本文最初提出来的问题是：敏捷软件开发还需要测试工程师吗？，对这个问题，业界有不同的观点。有人认为需要，因为总有一些是需要测试工程师的技能完成的工作；当然，也有人认为不需要，因为敏捷开发中的测试注重开发测试与自动化测试，开发工程师就可以自己搞定与测试相关的工作。在实践中，那些大规模实践敏捷开发的公司（例如Google），倾向于在组织中设置数量较少的测试工程师，在项目中分配较少的测试资源，甚至对某些项目，完全不使用测试工程师。
就我的个人实践经验，对大部分的项目，尤其是为明确的客户开发的项目，需要在敏捷开发团队中设置专职的测试工程师，因为：
测试与开发具有不同的思维方式：测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。因此，无论是从系统的层面验证产品，或是从应用系统的角度发现值得测试和验证的点（access point），专职的测试工程师都更有效。
专职的测试工程师能够更关注于测试基础，建立测试需要的基础架构：由于测试工程师具有更好的对测试的理解，通常他们能够更多的考虑测试的需求而开发适合项目的测试基础架构（自动化测试框架），而开发工程师可以使用这些框架来建立面向功能或代码的测试。
但是，不得不说的是，敏捷开发对开发和测试工程师都提出了更要的要求，尤其是对测试工程师而言，传统的只能精确模拟用户操作的测试工程师，因为不能为产品带来生产率的提升，在敏捷开发的团队中，很难有所作为。在本专栏的后续文章中，我们会进一步讨论测试工程师在敏捷软件开发中的工作和任务。
关于作者段念：Google中国高级测试经理，毕业于华中科技大学，先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。
敏捷开发流程中测试工作各阶段的内容有哪些
1、story澄清会议（即需求澄清），参与人员：开发人员、资料开发人员、测试人员、TSE、需求接口人等。目的顾名思义就是让所有参与项目的人员更深入的了解需求，会议上任何参与者都可以发表疑问，对不理解的地方要及时问清楚，实践证明这个会议能尽早的发现开发人员遗漏掉的功能点以及功能实现的方式对其他模块的影响等。这个阶段开发输出的文档有：story验收标准。一般情况下对于功能复杂的模块，为了让大家跟直观的了解功能点，一般开发人员会准备demo演示，这样也更有利于测试人员测试用例的输出。
2、测试人员根据需求澄清时了解的需求点编写测试方案，然后输出用例，完成后发给开发人员、TSE对用例进行评审，编写人员根据检视意见修改用例，直到大家都认可了，再导入用例管理工具TMSS。
3、迭代story转测试之前，测试人员需要向开发人员分一部分基本功能的用例验证，用例通过后才可以转测试。转测试附带的文档包括：代码检视确认报告、测试部提供用例的执行结果报告、开发自测用例样例参考等。
4、测试人员执行测试，执行用例---提交bug---回归问题---story评价---关闭story
5、迭代结束，回归会议，开发测试人员一起进行此次迭代版本的优缺点分析等。
敏捷开发模式用的测试是什么模型
【编者按】敏捷的理念已经深入人心，开发过程已经渐入佳境，测试的处境却稍显尴尬。测试从业者应该何去何从，怎样才能拥抱敏捷，体现出自己新的价值呢？InfoQ特地邀请了来自Google的敏捷测试专家段念，为读者答疑解惑，希望所有测试从业者可以从中得到自己的答案。更多关于敏捷测试的内容，请访问InfoQ中文站敏捷测试相关内容。
在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：到底？，敏捷软件开发还需要测试工程师吗？。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。
确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的频繁交付，还是对可工作的软件的度量，或是敏捷开发实践中的测试驱动开发，行为驱动开发，都离不开测试的支持。在本人看来，敏捷开发中不把测试单独拿出来描述的原因，恰恰是因为在敏捷开发中，测试不再是一个单独的、和开发独立的过程，而是变成了驱动开发、衡量产出的主要的手段，成为了敏捷开发中所有工程师在工作时必须时刻考虑和实践的一个部分。简而言之，敏捷软件测试更多的是一种理念，而非过程。
既然是这样，为什么我们还要在这个专栏中专门来讨论敏捷软件测试？本人接触过不少软件开发和测试工程师，他们所处的组织有的正在努力向敏捷开发转型，有的已经实践了一段实践的敏捷开发，但由于由来已久的工作习惯，他们中的绝大多数并不能自觉的认识到测试在敏捷开发中的关键作用，而是有意无意的将测试仍然看作是与开发截然分开的下一个阶段，导致在实践敏捷开发的过程中遇到种种问题：要么是忽略了代码质量，导致在频繁的迭代过程中，每一个迭代的问题层出不穷；或是沿用原有的方法安排对系统的系统测试，导致测试团队疲于奔命，却总也赶不上开发所要求的进度。在这种情况下，专门来讨论敏捷软件开发中的测试，也就是敏捷软件测试的话题，对这些工程师应该会有一些帮助。
那么，到底？很难给敏捷测试下一个精确、完善的定义，在本人看来，接纳了敏捷的核心价值观（沟通，简单，反馈，勇气，尊重），在敏捷软件开发过程中开展的测试就可以被称作是敏捷软件测试。因此，敏捷软件测试并不是一个与敏捷软件开发同一层次的划分，而是敏捷软件开发中的一部分，与传统的测试不同，敏捷软件测试并不是一个独立的过程，相反，它与整个敏捷开发中的其他活动交织在一起，处处都能看到它的影子。由于敏捷软件测试并不倾向于一个单独的过程定义，本人拟从敏捷软件测试与传统测试观点的比较、敏捷软件测试中采用的方法、测试工程师在敏捷软件测试过程中的工作等方面来阐述之。在这篇文章中，我们主要从宏观的角度来描述敏捷软件测试，而在本专栏的后续文章中，我们将对敏捷软件测试中采用的方法、工程师在敏捷软件测试中的工作内容等进行进一步的描述。
使用Dashboard、燃尽图等方式展示当前工作与可交付产品之间的距离
建立单元测试覆盖率等度量指标
共享质量目标意味着质量责任由所有工程师共同承担
开发测试应该建立一定的测试覆盖率标准，例如，在单元测试这个级别上，建立60%或80%的覆盖率要求
通过使用TDD、BDD等技术，保证产品和代码的可测试性
建立足够多的自动化测试，保证测试能够满足快速迭代的要求
检查表提到了团队、反馈、质量文化和开发测试四个方面的内容，在本人看来，这四个方面体现的就是敏捷软件测试与传统软件测试的最大的不同。传统软件测试关注的是通过尽可能完备的覆盖去发现尽可能多的问题，把测试和开发当成是两个独立的过程，测试是对开发阶段产生成果的验证
。而敏捷软件测试则建立了一种不同的质量文化：测试的目的是为了保证产品快速发布，也就是对生产率本身的提高。基于验证的出发点必然会要求测试与开发的独立，以及尽可能客观和完备的度量产品质量；而基于生产率的出发点则要求建立敏捷的团队，要求测试与开发尽可能紧密，要求建立具有高度可测试性的软件，以及基于这些的高度自动化测试。
在检查表列出的所有项目中，质量文化是基础，团队是敏捷软件测试得以实施的条件，反馈和开发测试则是敏捷软件测试的具体方法。当然，你可以可以从敏捷的核心价值观来阶段这些项目：团队关注的是沟通与尊重；反馈直接对应于反馈；质量文化基于勇气（承担质量责任的勇气）与尊重；而开发测试则是反馈与简单的具体体现。
另一个在本文最初提出来的问题是：敏捷软件开发还需要测试工程师吗？，对这个问题，业界有不同的观点。有人认为需要，因为总有一些是需要测试工程师的技能完成的工作；当然，也有人认为不需要，因为敏捷开发中的测试注重开发测试与自动化测试，开发工程师就可以自己搞定与测试相关的工作。在实践中，那些大规模实践敏捷开发的公司（例如Google），倾向于在组织中设置数量较少的测试工程师，在项目中分配较少的测试资源，甚至对某些项目，完全不使用测试工程师。
就我的个人实践经验，对大部分的项目，尤其是为明确的客户开发的项目，需要在敏捷开发团队中设置专职的测试工程师，因为：
测试与开发具有不同的思维方式：测试更注重全面的验证和检查一个系统，而开发工程师往往很难在大的范围内建立这样的思维方式。因此，无论是从系统的层面验证产品，或是从应用系统的角度发现值得测试和验证的点（access point），专职的测试工程师都更有效。
专职的测试工程师能够更关注于测试基础，建立测试需要的基础架构：由于测试工程师具有更好的对测试的理解，通常他们能够更多的考虑测试的需求而开发适合项目的测试基础架构（自动化测试框架），而开发工程师可以使用这些框架来建立面向功能或代码的测试。
但是，不得不说的是，敏捷开发对开发和测试工程师都提出了更要的要求，尤其是对测试工程师而言，传统的只能精确模拟用户操作的测试工程师，因为不能为产品带来生产率的提升，在敏捷开发的团队中，很难有所作为。在本专栏的后续文章中，我们会进一步讨论测试工程师在敏捷软件开发中的工作和任务。
关于作者段念：Google中国高级测试经理，毕业于华中科技大学，先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解，对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。
敏捷开发对于什么样的公司来说是好的选择
敏捷开发是一个概念性软件开发的方法论。具体的执行细节是有很多经验性内容的。但，无论组织形态大小或结构，只要使用“敏捷”，那么组织一定会被划分成7-10人左右的小团队（无论有多少人参与到开发中，我所在的交付团队曾经达到过150人，且全球化分布），敏捷是在这些小团队中被执行的。
敏捷对个人能力的要求是很高的，而且应用范围也不应该仅仅局限于“开发”团队。比如，你是做互联网产品的，产品经理、UI设计、开发工程师、测试工程师以及其他相关维护人员都应该一并组织到敏捷团队中。
结局：无论什么样的公司或团队其实都适合敏捷。然而，国内很多公司只愿意去做“捷”，却很难做到“敏”。
如何评价领导要用代码行数衡量每个人的工作量
作为一名IT行业的从业人员，主要在从事产品研发及项目管理工作。所以我来探讨一下这个问题。
我已坚守IT行业工作15载，还没有碰到有领导通过代码来衡量员工的工作量。在这里我想起了比尔盖茨总结的一句非常经典的话：“用代码行数来衡量编程的进度，就如同用重量来衡量飞机的制造进度”。如果是为了绩效考核可从很多的方面进行：代码质量、BUG数量、代码的命名规范、项目中所承载的角色、工作量等等。
在现实编程中一个软件工程师一天的代码量有200行就很优秀了，高质量的代码一天有50行就非常不错了，所以代码数量并不等于代码质量，代码的数量和质量比起来差距还是非常明显的，一味的追求写了多少行代码没有多大本质意义，关键代码是不是真的能够解决实际问题。
在编程过程中，使用不同的编程语言，代码的行数也是不一样的，同样的功能，不同的算法来完成，行数也有差别。有的几行代码就能完成，换个算法可能就要上百行了。编程的本质是解决问题，更不是一个炫耀技能的工作。
用代码行数来评估工作量，无疑是管理方式的问题。高产出=高价值，这样的等式在软件研发领域是个伪命题。
如何在引入敏捷开发的时候，取得团队的支持
老妖在去年的时候在团队中引入了敏捷管理。基本没费任何力气，因为整个团队的人员从开发，测试到运维都是我招进来的，在这种情况下，团队中基本上就是我的一言堂，我说什么就是什么？但对引进敏捷开发我没有一言堂，我把所有人召集在一起开了个会，让大家讨论了一下，让所有人都对这个敏捷开发产生了兴趣，我才按步就班的开始引入敏捷管理。所以，我觉得要引入敏捷开发，有两点很关键，一是你对团队有绝对的掌控力，二是取得所有成员的认可。
