用户名*
邮箱*
密码*
确认密码*
验证码* 点击图片更换验证码
找回密码
忘记密码了？输入你的注册邮箱，并点击重置，稍后，你将会收到一封密码重置邮件。
定好规矩，在规矩的基础上灵活应变就好，没什么特别的。不要被敏捷吓到了，其实很多号称敏捷的团队都不敏捷。
项目有各种各样的存在形式，我们只需要去适应，想办法在合理的时间内合理的完成任务就好。
至于是否敏捷，个人感觉并不是很重要。
为了提高测试与开发的协作效率，个人在尝试方法过程中也总结了几条小技巧，在这里和大家分享一下，欢迎互相探讨。
如何用敏捷方法做测试？
敏捷的核心就是个“快”字：快速开发，快速推出，快速验证产品方向。说白了就是管理每个小目标，保证他们能够按时完成。
想要运用敏捷方法，要注意几点：
1、开发做完一个小功能马上开始测试，减少等待时间。
2、测试的工作量更加分散，不会出现一段时间无事可做，一段时间忙的要死的情况。
3、每次的bug都是针对刚刚开发完的功能，开发处理起来会更得心应手，减少沟通成本。
在与同事沟通中，我还了解到，将bug加入开发计划会大大影响他们的目标完成进度，往往问题刚整理出一些思路，就因为某些bug需要处理而被迫中断了。
所以很多时候，直到deadline临近，目标中还会存留大量任务。如果测试一味地只管提交bug，而不考虑开发的工作习惯和目标的可执行性，就会导致效率大大降低。
*内容截图自teamin演示案例，结构略有修改，下同*
解决这个问题，需要将bug单独管理，同时做到合理分配，有节制，分缓急。
比较好的做法是，测试根据当前的开发计划设置自己的计划，将所有bug按紧急、重要、一般3种优先级来划分（分几级不重要，重要的是如何处理分级不同的bug），优先挑选紧急bug放入当前目标，重要bug根据当前进展情况适量分配，一般bug可以暂时不考虑。
另外，bug最好能建立单独的项目来管理，保证开发的任务集中度，避免产生过多冗余信息（属于当前版本却优先度不高的bug）。
项目、目标、标签，三位一体
举个不恰当的例子，测试与开发的配合就像父母喂孩子一样，不能等到孩子饿了才给吃的，这样容易一次喂太多，引起消化不良；也不能什么都给孩子喂，要注意合理配餐，否则营养失衡影响健康发育。回头心疼的不还是你这个做父母的吗？（哎！好像哪里不对……）
计划经常需要修改，测试如何应对？
计划变更频繁可以说是敏捷开发的另一大特点。上文提到了将bug单独管理，并将筛选后的bug加入计划，那么这种单独管理bug的方式就可以解决计划频繁变更的问题吗？
显然不能，因为bug最终还是要加入计划，计划出现变更，之前分配好的bug也会随之发生变化，这样之前设定的测试目标岂不乱套了吗？而且想必大家也会有疑问，我分配到开发计划中的bug，相当于从测试项目中移走了，那么修改后我如何得知，又如何统一审核呢？
简单来说，我需要任务支持跨项目协同，这样可以将同一个任务分配给不同的项目，达到测试与开发既各自独立、又相互联动的效果。这其实比较难实现，好在我用的协作工具支持我这样做，具体怎么做我不太好描述，直接上图吧：
跨项目协同，任务状态共享
这样一来，我在测试项目中设置的目标计划，不会随着开发计划的变更而变化，计划的调整都是自主和可预期的，另一方面，也能解决任务状态同步和后期审核的问题。
如何编写测试用例？
计划开始阶段没有测试工作，主要就是做测试用例了。我想这也是不少测试小伙伴的心头大患。测试用例结构复杂，分支众多，很难做的很详尽，一开始更是不知道从何写起。
到目前为止，我还没有找到一款非常合适的管理工具能够比excel做的更好，管理工具即使能够自定义功能，也很难达到excel的灵活性。与其在软件中记录分支，我宁愿将需要参考的相关任务导出成excel，然后自己添加情况分支，做优化修改。
导出任务列表，便于用excel编写用例
我一般会在开发前期就将产品的整体计划导出，作为总的测试用例大纲；再将开发当前正在做的计划导出，作为版本测试的用例大纲。
经常写测试用例的测试小伙伴可能都深有体会，用例最头疼就是整理结构大纲，而产品的整体计划本身就是一个结构性很强的需求大纲，相当于一个全部功能点的索引目录。
我们只要导出，稍作修改和补充，用例的完成度就会相当高。而且这样做还省去了与产品、开发一条条对接沟通的麻烦，减少了大量的沟通成本。
这种看似“投机取巧”的方法会让测试的用例编写工作事半功倍，效率大大提升。
个体和交互胜过流程和工具
可用的软件胜过完备的文档
客户协作胜过合同谈判
响应变化胜过遵循计划
敏捷测试人员定义：
1提供持续反馈
2为客户创造价值
3促进面对面沟通
4勇气
5简单化
6持续改进
7自我组织
我们这样定义敏捷测试人员：适应变化，与技术人员和业务人员展开良好协作
以前在敏捷团队待过，我来回答一下。在PM将需求排进需求池中以后，方案（解决方案的构思者）会按照需求文档开发相应的方案文档，方案文档经过测试和开发团队评审无异议（确认木有理解不一致或者不清晰的点）后，测试会按照此方案开发测试方案——测试用例；开发对此测试方案进行评审，如有疑问可讨论修改测试方案；开发完成需求开发后，需要自行运行测试按照测试方案分配给开发的一级用例；一级用例全部执行通过后，代码正式转入测试流程；测试会按照测试方案执行二级用例，有bug会在问题单系统中向对应开发提问题单；开发收到问题单后根据测试在问题单中描述的操作步骤和场景对问题进行重现，开发必须在（本轮测试结束之前，下一轮测试开始之前）对bug完成修复，然后再次执行一级用例；如此循环，直至系统无可以发现bug。
就一件事，不要把自己当测试。
昵称*
E-Mail*
回复内容*
回复 ( 5 )
定好规矩，在规矩的基础上灵活应变就好，没什么特别的。不要被敏捷吓到了，其实很多号称敏捷的团队都不敏捷。
项目有各种各样的存在形式，我们只需要去适应，想办法在合理的时间内合理的完成任务就好。
至于是否敏捷，个人感觉并不是很重要。
为了提高测试与开发的协作效率，个人在尝试方法过程中也总结了几条小技巧，在这里和大家分享一下，欢迎互相探讨。
如何用敏捷方法做测试？
敏捷的核心就是个“快”字：快速开发，快速推出，快速验证产品方向。说白了就是管理每个小目标，保证他们能够按时完成。
想要运用敏捷方法，要注意几点：
1、开发做完一个小功能马上开始测试，减少等待时间。
2、测试的工作量更加分散，不会出现一段时间无事可做，一段时间忙的要死的情况。
3、每次的bug都是针对刚刚开发完的功能，开发处理起来会更得心应手，减少沟通成本。
在与同事沟通中，我还了解到，将bug加入开发计划会大大影响他们的目标完成进度，往往问题刚整理出一些思路，就因为某些bug需要处理而被迫中断了。
所以很多时候，直到deadline临近，目标中还会存留大量任务。如果测试一味地只管提交bug，而不考虑开发的工作习惯和目标的可执行性，就会导致效率大大降低。
*内容截图自teamin演示案例，结构略有修改，下同*
解决这个问题，需要将bug单独管理，同时做到合理分配，有节制，分缓急。
比较好的做法是，测试根据当前的开发计划设置自己的计划，将所有bug按紧急、重要、一般3种优先级来划分（分几级不重要，重要的是如何处理分级不同的bug），优先挑选紧急bug放入当前目标，重要bug根据当前进展情况适量分配，一般bug可以暂时不考虑。
另外，bug最好能建立单独的项目来管理，保证开发的任务集中度，避免产生过多冗余信息（属于当前版本却优先度不高的bug）。
项目、目标、标签，三位一体
举个不恰当的例子，测试与开发的配合就像父母喂孩子一样，不能等到孩子饿了才给吃的，这样容易一次喂太多，引起消化不良；也不能什么都给孩子喂，要注意合理配餐，否则营养失衡影响健康发育。回头心疼的不还是你这个做父母的吗？（哎！好像哪里不对……）
计划经常需要修改，测试如何应对？
计划变更频繁可以说是敏捷开发的另一大特点。上文提到了将bug单独管理，并将筛选后的bug加入计划，那么这种单独管理bug的方式就可以解决计划频繁变更的问题吗？
显然不能，因为bug最终还是要加入计划，计划出现变更，之前分配好的bug也会随之发生变化，这样之前设定的测试目标岂不乱套了吗？而且想必大家也会有疑问，我分配到开发计划中的bug，相当于从测试项目中移走了，那么修改后我如何得知，又如何统一审核呢？
简单来说，我需要任务支持跨项目协同，这样可以将同一个任务分配给不同的项目，达到测试与开发既各自独立、又相互联动的效果。这其实比较难实现，好在我用的协作工具支持我这样做，具体怎么做我不太好描述，直接上图吧：
跨项目协同，任务状态共享
这样一来，我在测试项目中设置的目标计划，不会随着开发计划的变更而变化，计划的调整都是自主和可预期的，另一方面，也能解决任务状态同步和后期审核的问题。
如何编写测试用例？
计划开始阶段没有测试工作，主要就是做测试用例了。我想这也是不少测试小伙伴的心头大患。测试用例结构复杂，分支众多，很难做的很详尽，一开始更是不知道从何写起。
到目前为止，我还没有找到一款非常合适的管理工具能够比excel做的更好，管理工具即使能够自定义功能，也很难达到excel的灵活性。与其在软件中记录分支，我宁愿将需要参考的相关任务导出成excel，然后自己添加情况分支，做优化修改。
导出任务列表，便于用excel编写用例
我一般会在开发前期就将产品的整体计划导出，作为总的测试用例大纲；再将开发当前正在做的计划导出，作为版本测试的用例大纲。
经常写测试用例的测试小伙伴可能都深有体会，用例最头疼就是整理结构大纲，而产品的整体计划本身就是一个结构性很强的需求大纲，相当于一个全部功能点的索引目录。
我们只要导出，稍作修改和补充，用例的完成度就会相当高。而且这样做还省去了与产品、开发一条条对接沟通的麻烦，减少了大量的沟通成本。
这种看似“投机取巧”的方法会让测试的用例编写工作事半功倍，效率大大提升。
个体和交互胜过流程和工具
可用的软件胜过完备的文档
客户协作胜过合同谈判
响应变化胜过遵循计划
敏捷测试人员定义：
1提供持续反馈
2为客户创造价值
3促进面对面沟通
4勇气
5简单化
6持续改进
7自我组织
我们这样定义敏捷测试人员：适应变化，与技术人员和业务人员展开良好协作
以前在敏捷团队待过，我来回答一下。在PM将需求排进需求池中以后，方案（解决方案的构思者）会按照需求文档开发相应的方案文档，方案文档经过测试和开发团队评审无异议（确认木有理解不一致或者不清晰的点）后，测试会按照此方案开发测试方案——测试用例；开发对此测试方案进行评审，如有疑问可讨论修改测试方案；开发完成需求开发后，需要自行运行测试按照测试方案分配给开发的一级用例；一级用例全部执行通过后，代码正式转入测试流程；测试会按照测试方案执行二级用例，有bug会在问题单系统中向对应开发提问题单；开发收到问题单后根据测试在问题单中描述的操作步骤和场景对问题进行重现，开发必须在（本轮测试结束之前，下一轮测试开始之前）对bug完成修复，然后再次执行一级用例；如此循环，直至系统无可以发现bug。
就一件事，不要把自己当测试。