测试经理和PM对TC进行Review：
敏捷测试流程总结：
在敏捷方法中，XP方法强调测试在整个项目开发过程中的重要性。针对敏捷开发方法的敏捷测试不同于以往针对传统开发模式的测试,在敏捷团队中,测试是整个项目组的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。测试员为项目组提供丰富的信息，使得项目组基于这些可靠的信息作出正确的决定。不仅是测试员要保证质量，而是整个项目组的每一个人都要对质量负责。测试员不跟开发人员纠缠错误，而是帮助他们找到目标,共同为达到项目的最终目标而努力。敏捷测试也需要高度迭代工作、频繁得到客户的反馈，需要动态调整测试计划、测试的执行。并且，敏捷测试人员参与到了更多的敏捷生产活动中，积极的影响了团队做出的决定和计划。
根据公司项目目前采用的敏捷开发模式，相应的敏捷测试建议采用以下流程：
1 验证需求和设计
需求和设计具体来说一般包括：(1)由项目经理根据需求文本而编写的功能设计文本(Functional Design Specification);(2)由开发人员根据功能文本而编写的实施设计文本(Implementation Design Specification)包括(Architecture Document, Project Scope Statement, Use Case )。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性
在测试初期，测试人员要学会做静态测试，做好需求分析，做好对设计逻辑的分析。测试人员要更多的思考需求的可实现性，将自身作为第一用户积极参与项目和系统的需求分析，设计和开发。积极地参与前期工作，并迅速反馈给设计和开发其静态测试结果。要尽早的开始测试，不要等待到功能完全做好才开始。
产出物:测试需要提交评审结果文档,可以让测试更多的参与DB Design,框架的评审中来
2 测试计划，测试用例
21 编写计划、测试用例
在敏捷开发的过程中由于是根据每个user story来估算时间的。开发人员将对本次迭代所需要的完成的user story进行评估。开发人员可以和客户直接沟通，来确定每个user story的优先级。
好处：
客户可以很清楚的了解到哪些user story需要花费多长的时间，以及他们的优先级。
问题：
在user story的时间估算上，开发人员常会估算过少。引起版本无法按时发布或者必须进行加班才能进行发布。
分析：
由于版本更新很快，任务的时间都是以小时来进行估算的。开发人员一般会忽略掉开发以外的时间，比如开发中遇到问题的时间，开会，给其他成员提供帮助的时间，等等。
举个例子：
开发人员估算某个user story编码的时间需要15天，开发人员自己估算了其他时间为半天。于是开发人员给的估算时间是2天。开发阶段实际的花费时间如下，每天花费开例会的时间。在例会中项目的其他成员需要技术上的支持。于是发费了3个小时进行帮助。在开发的过程中遇到了一些没有预见到的问题，结果解决问题花费了4个小时。(也许更多)。需要处理一些公司突发性的事务等等。所以非常建议大家在估算时间上能充分的考虑到以外的因素，某本XP相关的书上写到，在时间估算上最好的时间是编码时间的2-3倍。听起来很吓人，但是实际的过程中，的确需要这么多的时间。
测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。测试的这两个文本也要被项目经理和开发人员审核。
22 测试用例的审核
为使开发人员能参与到Test Case的Review中来，以保证TC的质量和可行性，确保测试工作的顺利进行，让开发人员迅速地了解测试的重点并给出相应的意见和建议，测试人员在出 TC的同时，应出一份TC_Matrix(Test Case跟踪矩阵)，其中注明TC已覆盖了哪些Features，具体每个Features对应的TC的编号，这样在测试经理和PM对TC进行 Review的时候，能够对TC的覆盖率一目了然，对覆盖率不足(如某个重点Feature的Test Case不够)的地方能够及时给出意见。
另外，在每天早上的Morning Meeting上，测试人员可以简洁地讲述一下当天测试的重点部分，以及项目中存在哪些严重的bug，让开发人员了解当天测试的重点是什么，怎样进行测试，并提出自己的意见和建议。这样做加强了开发与测试人员的交流和沟通，使测试工作能够更加有效，更加顺利地开展。
在迭代后期测试要抽时间更新test case。
3 实施运行测试
在敏捷方法中，测试有两种：单元测试和接收测试。单元测试是由开发人员来完成的，接收测试是由客户代表来完成。
由于我们客户无法在现场，我们采取了，开发人员做单元测试，测试人员做验证测试，最后由客户进行接收测试。在每个版本发布给客户之前必须由测试人员进行测试，发布版本之后由客户做接收测试，提出需要修改的地方。需要修改的地方将在下一个发布完成。
�6�1 单元测试
在daily build版本给测试前，开发首先要做单元测试，提前告知软件中的薄弱环节，帮助测试人员调整测试重点。Unit test
做单元测试的好处是可以提高版本质量，减轻测试的工作量，减少浅层次的bug的发生率，使测试人员能够将更多的精力投入到寻找深层次的bug上面。
�6�1 验证测试
测试人员的验证测试从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。这一阶段的测试必须在周密的计划下进行。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看，测试执行的一开始可以是针对部分功能的，之后可以逐步扩展。接着开始采用迭代的过程完成测试任务，即将测试任务划分为多个周期，一开始可以做些关键的功能性测试，可以对代码中的可复用部分(组件，构件)做完整的测试。接着的迭代周期可以做边缘化的功能测试和其他测试，最后的几个迭代应该用于回归测试，和关键的性能和稳定性测试。
31 每日提供bug趋势
为方便衡量项目的进度，测试可每天测试完毕后提供测试的bug趋势，即将每天新生成的Bug数和每天被解决的Bug数标成一个趋势图表。一般在项目的开始阶段新生Bug数曲线会呈上升趋势，到项目中后期被解决Bug数曲线会趋于上升，而新生Bug数曲线应下降，到项目最后，两条曲线都趋向于零。PM会持续观察这张图表，确保项目健康发展，同时通过分析预测项目Bug，
对于每个版本的bug，开发都应该想想为什么会出现这样的问题，特别是很低级的bug，对于同类的bug，是否可以避免。
测试需要考虑:探索性测试用例的编写
32 测试用例的维护
在执行测试阶段中，测试人员需要对已有的测试用例进行及时的维护。通常以下两种情况下要新增一些测试用例：一是对于当初测试设计不周全的领域，二是对于外部的Bug(比如从Beta客户报告来的)，没有被现有测试用例所覆盖。当产品的功能设计出现更改时(敏捷项目中功能设计的更改频繁)，所涉及的测试用例也要相应地修改，使测试用例保持和现有的功能需求同步。
33 根据项目不断补充Common Sense
在项目进行过程中，测试人员需要不断积累经验，不断补充、完善各类目的Common Sense标准。例如，由CTTS项目总结出的Common Sense for USA标准，在以后的美国项目中要严格按照它来执行测试，保证以前出现过的失误在以后的项目测试中不会再出现。在保证项目质量的同时，不断积累新的经验。
34 控制中间版本
为更好地保证软件质量，规避风险，必须加强对中间版本的控制。例如，客户要求或者计划周五要提交版本，则周三一定要提交一个中间过程的版本进行测试，也就是控制中间版本，避免所有的工作都压到后期最紧急的时候去完成。以前的项目中出现过项目前期很轻松，到后期bug越来越多，开发人员和测试人员都异常忙碌，经常加班的情况。为减少后期工作量，规避风险，建议开发进行Daliy Build，或者按照完成一个feature就进行一次build，针对这个feature进行测试，这样就可以有效避免后期bug越来越多的状况发生，后期工作量也就会相应减少，项目的质量也会更有保证。
35 发布版本前编写Release Note
在每次发布版本之前，测试人员要根据待发布的版本情况编写Release Note，使客户对发布的版本情况一目了然。Release Note主要包括三方面的内容：Fixed，New Features，Known Problems。其中，Fixed部分写明此版本修复了上个版本中存在的的哪些比较大的bug;New Features部分写明此版本新增加了哪些功能;Known Problems部分写明此版本尚存在哪些比较大的问题，有待下个版本改善;或者列出需求不太明确的地方，有待客户给出明确答复意见，在下个版本中完成。
4 需求管理
采用敏捷开发模式的项目中，客户对于需求的变更很频繁。因此，需求管理是十分必要和重要的工作。整个项目进行过程中，对不断变化的需求，一定要作跟踪，每次的需求变更都要有相应的历史记录，方便后期的管理和维护工作。可将每次的变更整理记录到需求跟踪文档中，并使该文档始终保持最新更新的状态，与需求的变化保持同步。
问题：
客户可能会在一个功能点上来回修改他们的需求，也许开始需要某个功能，结果做完以后又觉得不好，于是让去掉这个功能。后来又由于一些原因，有需要加上。在整个过程中可能来回修改了很多次。那一定要记录下变更的内容和日期。可能后期客户会觉得一个功能怎么会花那么多的时间，不是以前很早就做过了吗这时这些记录才是解决客户疑虑的最好证明。说白了，是有证据证明我们做了很多的变更。大家可能觉得，怎么会有这个问题。其实当一个项目长达半年以上，也许大家的记忆力都不可靠了(:p)
建议：
目前采用的是vss工具，对每天的Email中提到的需求变更做一次backup，文档以当天收到Email的日期命名
5 项目开发末期开展“bug大扫除”
在项目开发的末期，可以开展“bug大扫除”活动。划出一个专门的时间段，在这期间所有参与项目的人员，集中全部精力，搜寻项目的Bug。注意以下要点：
(1)尽管这是一个测试活动，但参与者并不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益;(2)要鼓励各部门，领域交叉搜索，因为新的思路和视角通常有助于发现更多的Bug;(3)为调动积极性，增强趣味性，可以适当引入竞争机制，比如当活动结束时，评出发现Bug最多，发现最严重Bug的个人，给以物质和精神奖励。(4)可以分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。啄木鸟之家大吕
本文通过四步就可以帮你建立敏捷测试思维方式：
1） 教育、教育、教育！ 重要事情说三遍。
2） 权衡到底需要多少文档
3） 调整你的度量
4） 改变态度
从传统换挡到敏捷，需要做好教育、文档和度量等基础工作。敏捷研发和测试不仅仅只是一个方法，更多是一种思维方式。根据VersionOne调查，88%的商业都在实践敏捷研发，但很多在转型过程中苦苦挣扎，不成功的主要原因一般归结为：“文化习惯和抗拒变化”。
你在尝试变化前，若没完成测试同学正确思维方式的转变，那你的团队实际上正在开启一场失败之旅。
敏捷技术的采用通常都是开发同学的事，实际上，敏捷测试是该过程里面非常重要的组成部分，值得相当大的关注。主要的挑战在于传统的测试方法不能很好的匹配敏捷方法论。若你的团队正在考虑转型敏捷，或你就是正在痛苦转型敏捷的测试同学，可能需要将你的关注点从敏捷方法论扩展到敏捷思维方式。
到底该如何做？
下面将通过四步帮你建立敏捷测试思维方式。
Step #1 教育、教育、教育！
若要测试拥抱敏捷的思维方式，首先必须从教育开始。
1，测试必须教育自己，很清楚敏捷过程究竟需要什么。新的工作流是什么样的对他们新角色中的期望？
2，测试团队需要在业务中有自己的声音。他们必须有能力影响和说服管理层或敏捷指导小组。他们对采用敏捷是有贡献的以及能感受到组织能考虑他们顾虑，这很重要。这样才能确保各个层面都坚信敏捷的转型。
3，测试必须积极主动投入每个项目。新项目一开始就要通知到测试，并包括他们。他们必须理解业务价值以及对最终用户需求的深入理解。
Step #2 权衡到底需要多少文档
测试依靠文档的传统习惯必须破除，文档必须要创建的期望值必须重新设置。开发开始前需求文档必须写好，这点不再有效。
敏捷就是围绕着用户的不断反馈，通过一个个迭不断打磨产品，这是一个很灵活的过程。这意味着所有你实际依赖的文档必须在研发和设计演进中保持持续更新。
敏捷测试思维意味着要避免测试工作陷入官僚主义或者繁文缛节。测试在低级工作花费的时间越多，类似编写大量测试用用例，那么他们就越少投入真正有价值的活动，比如寻找深层次缺陷。探索式测试同时能自动产生回归测试所需脚本，就是一个非常聪明的做法。
敏捷的环境需要聪明的文档。我们需要接受并不是所有的东西多需要文档化，而应聚焦敏捷过程真正需要的。
实现敏捷过程最难的部分就是要平衡好：既要记录足够的东西帮助将来的知识传递，又要最小化不必要的工作。
Step #3 调整你的度量
对于成功的敏捷测试转型，替换传统测试在度量方面的思维方式可能是最大的观念转变。QA团队和测试同学在过去已习惯度量测试活动完成的跟踪和测试缺陷创建。这些度量跟敏捷研发中关注客户价值是不匹配的。下列“不应该”列表可能让习惯传统度量的测试不适应，但绝对能驱动团队思考匹配业务成功所需的度量。
1，不应该强调缺陷数量。测试发现的缺陷数量并不能有效衡量他们工作有效性。强调数量胜过质量是错误的。一旦测试在缺陷数量方面感到压力，他们很可能会提一堆有争议的缺陷。特性需求、设计差异、没说清楚的需求细节不应归类到缺陷。
2，不应强调每天执行的测试脚本数量。每个测试用例的粒度是不同的，数量容易误导人，应该聚焦交付质量。
3，不应强调测试脚本整体通过率。测试脚本执行过程中没有发现问题并不能告诉我们这个产品就是可用的或符合最终用户的期望。测试，必须站在最终用户的角度，时刻考虑他们需要。
重心应该转移到最终用户的满意度，而不是活动的跟踪度量。若公司每位同学都能聚焦给用户交付最好的产品，成功就是很自然的事情。
Step #4 改变态度
沟通和协作的意愿对敏捷的成功至关重要。在过去，单独存在的QA部门定位自己是产品质量的守门员，将自己站在开发同学的对立面，是经常能成功做到的。现在时代不同了，需要改造测试同学：教育他们，赋能他们，他们就能交付更大的商业价值。
好比双向的道路，自上而下赋能测试，自下而上考虑他们的发展。这能协调整个公司目标的一致性，才能保证每一个部门和每一名员工都能帮整个团队朝同一个方向努力。
每一位同学尽他最大可能给用户创造最好体验。
顾翔凡言：
麒怀科技：专注于敏捷转型，产研效能质量提升
如果你点开了链接，看到了本文章，我想你一定被文章的标题吸引了进来，或许你们会说又是标题党。标题党就标题党吧，你们肯定会看完的
刚开始接触测试的朋友，对测试用例（case)一定不陌生，它是测试的基本功。或许你已经被他磨平了棱角 可能在几年之前，测试用例的编写和执行是许多IT公司招聘的必备条件之一, 可能不少朋友经常使用Excel编写case 殊不知，随着项目和时间的推移，Excel的文件大小会越来越大，打开速度也越来越慢。加上项目迭达速度的加快，Excel的效率已经明显不够。而且阅读起来也相对比较吃力，下文我将提到敏捷模式下的测试该如何进行。
一、开发和测试通性困扰？
面对复杂性（需求）：不断地修改计计划、不断地增加预算、低劣的产品质量……
面对复杂性（项目组成员）：经常加班到深夜、提交的产品不合格……
二、敏捷开发中的敏捷目的
敏捷宣言
个体和交互比过程和工具更有价值；能的软件比全面的文档更有价值；顾客的协作比合同谈判更有价值；及时响应变更比遵循计划更有价值。
其核心是:以人为本,发挥人的主观能动性
三、传统测试和敏捷测试区分：
31 传统的测试
1守门员:质量保证者，阻止那些不可靠的、无效的、充满BUG的版本发布。
2信息提供者:提供大量积极的、关于项目开发的状态的信息。告诉大家哪些功能正常工作、哪些功能不能正常工作、哪些BUG必须处理。
32、某大厂敏捷测试
测试和开发的角色界线变得模糊。有些人主要做测试工作，有些人主要做开发工作，但是在快速推进的过程中，所有人都会被号召起来测试或支持测试的工作。
更多职责:帮助开发人员理解需求,尽早确定测试规范。
四、敏捷测试用例的设计和评审要素
41、基于需求的用例场景来设计测试用例
1基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。
2把测试用例当成"活"的文档,因为需求是"活"的、善变的。因此在设计测试用例方面应该符合敏捷的"及时响应变更比遵循计划更有价值"这一原则。
3测试用例的设计不是一个阶段，测试用例的设计也需要迭代，在软件开发的不同的阶段都要回来重新审视和完善测试用例。
42、敏捷测试用例设计原则
通常我们所看到的测试用例的设计是其中一项。
测试用例可以写得很简单，也可以写得很复杂。最简单的测试用例是测试的纲要，仅仅指出要测试的内容，如探索性测试中的测试设计，仅会指出需要测试产品的哪些要素、需要达到的质量目标、需要使用的测试方法等。而最复杂的测试用例就像银行取款机系统中工作指令系统界面一样，会指定输入的每项数据，期待的结果及检验的方法，具体到界面元素的 *** 作步骤，指定测试的方法和工具等等。
测试用例写得过于复杂或过于详细，会带来两个问题：一个是效率问题，一个是维护成本问题。另外，测试用例设计得过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。
测试用例写得过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行"设计"，只是把需要测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。测试用例的设计的本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，方便辅导后面的测试。
请看如下一个例子：
现在有一个 PC 客户端的命令行工具，这个工具可以接收三个命令行参数，其中，前两个是数字，最后一个是运算符，运算符只支持加减乘除四种，工具的功能就是把前两个数字使用运算符做下运算，然后输出运算结果。
我们来看下面的用例：
第一种风格，完全是遵循脑图的本来用法，属于层级递进式，前面层级都是后面层级的前置条件，需要把每一个分支的所有层级全部组合到一起，才是一条完整的用例
第二种风格，是按照要素归类的方式，每一层都是同一要素的不同类别，细化到的最后一级就是一条完整用例，前面的层级只是为了让分类清晰，为了把后面一大坨的最终用例更有条理的进行展示。
二种风格的用例各有优点
第一种风格适合做需求分析，通过思维的逻辑发散，把不同的路径通过脑图进行展现，从而激发更多的灵感。
但是测试用例是针对已经固定的需求和实现来做覆盖，它的前提是固定的，我们用脑图需要做得，就是把已有的需求和实现，转换为用例后，再通过合理的方式进行呈现。
我们需要的，一方面是合理的拆分，比如第二种格式里的第一层，我们按照输入、输入顺序和输出分成三块，后续继续按第一个参数、第二个参数和第三个参数这种方式进行更细的划分，所以条理性还是蛮清晰的。
这种格式的用例，在做用例评审时，可以很方便的和需求进行一一对应，能够很快的确认需求覆盖率。
另一方面，这种格式的用例，对于用例执行者也是比较友好的，执行者可以只关注用例的最后一个节点，按照指定策略执行就行了，在这种情况下第二种用例会比第一种用例效果更好，如果是第一种格式，需要每次都从头看到尾，很容易出错。不过笔者相对来说喜欢第一种，通过不同路径脑图进行展现，激发更多的灵感。
本文部分内容来自 51testing
1） 产品的质量不是测试出来的，是软件生产出来就是这样的。2）但现实很残酷，上线前最紧张的还是QA，我们也很无奈
1QA就是一个角色。
团队中任何一个人被赋予这个角色就要承担QA的职责，承担QA要做的事情，eg:BA 也可以被赋予这个角色。
2能力要求
-----学习自《ThoughtWorks》首先敏捷测试(Agile testing)是测试的一种，敏捷测试的理念是，和编码一样，测试是开发的一个关键部分。在敏捷中，测试被直接集成到软件开发过程中，以便尽早、频繁地发现bug。因此，测试人员可以在开发过程的每一个节点上发现问题，从而使产品快速走向发布。
敏捷测试的特点有以下几点：
传统测试即基于瀑布模型开发的测试，瀑布模型将软件生命周期划分为 制定计划、需求分析、软件设计、程序编写、软件测试 和 运行维护 六项基本活动，其过程是将上一项活动接收的工作对象作为输入，当该项活动完成后会输出该项活动的工作成果，并将该项成果作为下一项活动的输入。该模型规定这六项基本活动自上而下、固定相互衔接的次序，如同瀑布流水，逐级下落。 从本质上讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从需求分析直到产品发布和维护。 如果在其中某个阶段有信息未被覆盖或有问题，那么就得返回到上一个阶段，并对这些阶段进行适当的修改才能进入下一个阶段，这样每个阶段都会产生循环反馈，开发过程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
瀑布模型的优点如下：
增量迭代应用于瀑布模型，迭代1 解决最大的问题，每次迭代产生一个可运行的版本，同时增加更多的功能，但每次迭代必须经过严格的质量和集成测试。
瀑布模型有以下缺点：
搞清楚了什么是敏捷测试，什么是传统测试，最后我们来对比一下他们之间的区别，整理如下：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）