【你来问我来答第86期】：浅谈敏捷在项目中的可持续发展！（活动结束）

lsekfe

论坛ID：  子慕予兮
真实姓名： 仲老师
现任公司： 博为峰
现任职位： 讲师
工作经验：
毕业于英国Univ. of Glasgow 计算机工程硕士；具备10多年软件测试及IT项目管理经验；曾供职于皇家苏格兰政府机构，花旗软件，完美世界等国内外知名企业，先后担任SQA，测试经理，敏捷教练。熟悉软件测试流程，工具，熟悉IT项目管理方法论，持有Prince2 Practitioner， CMMI， CSM；对软件测试领域和敏捷研发有较深入地研究，在软件测试培训行业亦有多年授课经验。
老师课程：
征服Python3-快速突击班点击进入>>>

各位会员可以在10月10日前以回帖的方式向客座专家提问。
（请大家围绕本期客座专家的擅长领域进行提问、探讨）
客座专家将在10月11日—10月31日为大家集中解答。
机会难得，欢迎大家踊跃提问！

楠族开心果

哇 美女老师呀

诶嘿嘿

哈哈，仲玲大美女啊

予衬

请问仲老师 UI自动化测试框架怎么学习才能做到最好，目前打算往这方面发展，比如怎么去学，从哪里开始？谢谢！

八戒你干嘛

我做了多年的手工测试，目前想找selenium自动化测试的工作，看到很多招聘都是写的熟练掌握selenium自动化有多少年经验以上，我目前的公司没有做自动化，都是自己有时找一些模块尝试，目前我可以做到脚本编写没问题，会对对象，对象查找方法，测试数据读取，多浏览器进行封装，个人觉得自己欠缺的是具体项目中的个别难识别对象的处理。
您有多年的selenium测试经验，请问我目前的selenium能力达到一个什么样的程度，如果我想提高需要从什么方面下手，谢谢！

乐哈哈yoyo

先说一下我项目的环境：
小团队，我们做的是三周一个迭代的非常强调用户体验的iOS产品，除了BVT外，其他内容全部手工黑盒测试

第一周主要时间是用来明确当前版本具体做哪些feature
  test在第一周主要工作是review需求，写case
第二周主要工作是编码和实现
  test在第二周主要工作是跟进dev每天check in的变更点
第三周bug fix&发布
  第三周test会做比较全面的测试，测试重点是功能的变更点和新的feature

整个项目中虽然每个阶段测试的重点都在新功能和变更内容上，但所有功能的测试工作穿插在项目中的真个过程，每个功能在三周中都能测试到

问题：
进度上的瓶颈经常block到开发进度上，总是在release当天上午才code freeze，下午就发布了
对于模块上的某个变更点去进行全面的测试效率低，时间上不允许，所以对变更内容去做针对性测试的思路我认为是对的
每天代码上的change在20个左右，dev对每个change的描述上和test沟通不清（dev和test思想上的区别），会出现变更的影响范围描述不清导致测试不能很好的跟进
结果好几个版本在release当天的change出现bug，然后测试时间不够导致bug露出

我希望测试人员能够针对代码上的change去做百盒测试，这对测试人员的要求不比负责code review人员的能力低，并且要从另一个角度出发去测试
现在没有一个水平能够达到这种要求的人，项目的节奏不变的话这个问题就会一直存在
怎样才能解决bug漏出呢？

巴黎的灯光下

敏捷项目是拥有一支支小规模但职能全面的团队，在这样一个普通的敏捷团队里，拥有具备不同职能的 成员，如1 名 UCD(User Centered Designer)，1 名 Visual Designer，1 名测试人员（Tester）， 1 名 Information Developer 和 3 名开发人员（Developer）。
      我不明白的是，当一个项目被分解成一支支小规模但职能全面的团队，那些测试经理在测试管理方向该如何做呢？
   他们的位置是不是要被取消？
   这时候他们的主要工作又是什么了呢？

草帽路飞UU

论述敏捷研发下如何保障产品质量？请老师讲解下谢谢！

lsekfe

予衬 发表于 2017-10-11 16:43
请问仲老师 UI自动化测试框架怎么学习才能做到最好，目前打算往这方面发展，比如怎么去学，从哪里开始？谢 ...

http://bbs.51testing.com/thread-1144677-1-1.html 这个附件应该会适合你！

lsekfe

八戒你干嘛 发表于 2017-10-11 17:08
我做了多年的手工测试，目前想找selenium自动化测试的工作，看到很多招聘都是写的熟练掌握selenium自动化有 ...

这个和敏捷测试有点关系不大哦，不过你这个属于遇到瓶颈了。建议你可以多看些职业发展的帖子，论坛中不少。

lsekfe

草帽路飞UU 发表于 2017-10-11 17:15
论述敏捷研发下如何保障产品质量？请老师讲解下谢谢！

http://xueshu.baidu.com/s?wd=%E8 ... =utf-8&sc_hit=1 这上面有很多关于你想知道的方方面面，你可以搜索下。

子慕予兮

乐哈哈yoyo 发表于 2017-10-11 17:10
先说一下我项目的环境：
小团队，我们做的是三周一个迭代的非常强调用户体验的iOS产品，除了BVT外，其他内 ...

首先就你们团队中测试人员目前三周的task定位而言，不能说是真正意义上的敏捷，没有结合自动化的敏捷很难确保测试的效率和每一次发布的产品质量，毕竟每次的迭代重点都放在新功能或者一些change上面，而这些是手工测试的重点，但是随着产品迭代次数的增多，不可避免的会带来越来越多的回归测试，这些回归测试用例如果每一次都是你们人为手工去执行的话，而且要确保回归测试的覆盖率的前提下，效率会非常低；

另外一点，根据你问题中描述的开发的进度往往成为你们团队的瓶颈，这个就是前期的需求没有梳理清，通常而言，每个迭代的第一天是planning meeting，这个会议中除了从产品backlog中挑选合适的用户故事（需求）外，还要尽可能的拆分每一个用户故事，拆分的越细，团队的后续任务就越清晰，也越容易估算出每一个task需要花费的时间，然后通过每日燃尽图实时跟踪团队完成工作的状态；不清楚你们是否有每日的燃尽图，这个是敏捷中控制每一个迭代最有效最透明的软工具；

同时，每个迭代的最后一天，是否会有个回顾会议，时间不在于多长，这个会议能够帮助大家一起讨论出当前迭代实施中的优缺点，如果是开发block住了进度，导致测试时间不够，从而不可避免一些bug定位不到，针对于这个现状，能够挖掘出根本原因所在，是开发技术问题？还是planning meeting中故事拆分不够细致，还是团队中的各位对当前的需求没有很好的了解，或者缺乏有效沟通所导致的，这些都是敏捷中容易被忽视的问题；

总而言之，要真正敏捷起来，团队中的每个成员需要保持有效沟通，敏捷中的会议偏多，但是不是我们通常上意义上的会议，这些会议需要有效沟通，有效梳理，而非范范而谈，等到真的着手开发/测试时，才发现一些似是而非模林两可的需求；需求不明，沟通无效，自然会导致瓶颈，然后眼看着release date的接近，只能被迫加速，bug的接踵而来就无可厚非了

最后针对你提出的白盒测试，确实，需要测试人员有coding的能力，建议是否可以把回归测试用例代码化，通过持续集成的方式，自动运行，这样你们每次的迭代，测试人员就能完全focus on 在新功能/新change上了

子慕予兮

巴黎的灯光下 发表于 2017-10-11 17:13
敏捷项目是拥有一支支小规模但职能全面的团队，在这样一个普通的敏捷团队里，拥有具备不同职能的 成员， ...

这个问题很有意思，确实敏捷团队中每个成员都有自己的角色，打个不太合适的比方类似几个人参与一部网络剧集的拍摄，周期短，效率高，人员与人员之间靠的就是有效沟通和协作，每个人都在这部剧里扮演一个角色，在较短的周期内完成剧集的制作；所以真正的敏捷是没有管理层的参与的，敏捷强调的是沟通，协作，在短期中共同完成一个小目标，发布可以使用的产品（这些产品必须经过有效的测试，能够确保质量的）；

那么曾经瀑布模式下研发的那些管理层，项目经理，技术经理，测试经理等，去哪儿了呢。。。很明显这些人员也要和团队一起做好只能转换的过渡期，如果这类管理人员对产品精通，业务精通，完全可以转型为PO，敏捷中的另一大核心角色，独立于研发团队（通常就是我们所说的产品经理）；如果是曾经的技术经理，那么这类人员可以转型为敏捷教练（此处不同于scrum master），在熟悉敏捷的整体运作模式后，结合自己的技术特长给予不同的敏捷团队可观有效的建议，从而促使敏捷团队的顺利转型；

既然研发模式从曾经的瀑布式逐渐转型为敏捷，那么其中的所有人员都将会重新定位，这是职业发展的必经之路，IT人员的自适应性很重要；如同敏捷中的测试人员已经不单单是测试人员了，测试驱动开发的理念已经逐步深入到实际项目中，由此带来的是测试开发无缝结合，曾经的测试人员和开发人员的界限已经越来越模糊化了

子慕予兮

草帽路飞UU 发表于 2017-10-11 17:15
论述敏捷研发下如何保障产品质量？请老师讲解下谢谢！

这个问题有点宽；

简单来说敏捷并不是单纯意义上的快，他是把整个项目周期划分成一个个小迭代（2-4周为一个迭代，互联网时代，一周一个迭代也不是没可能），每个迭代结束后都会发布一个可以使用的产品，每个迭代包含了需求分析，研发，测试，文档等；说到如何确保质量，每个迭代的质量可以简单的分为两部分，其一当前迭代中新功能是测试重点，其二就是回归测试（通常都是要做成代码，通过持续集成自动运行），持续集成的概念在瀑布式年代就已经提出而且实施了，敏捷中更是不可缺少，如果不太了解，可以去看下相关文章，有个整体的概念；

所以，敏捷中的测试，说白了就是新功能，新更改的手工测试（一般而言，新功能不建议自动化）+自动化回归测试；如果能够做到测试驱动开发，以及能够有时间做一些探索性测试，那说明你们的小团队中人员的各方面水准已经达到了相当的水平了

子慕予兮

八戒你干嘛 发表于 2017-10-11 17:08
我做了多年的手工测试，目前想找selenium自动化测试的工作，看到很多招聘都是写的熟练掌握selenium自动化有 ...

这个再补充一点，可以去看下现在主流的框架，maven+selenium+jekins持续集成，自动化构建，因为真是的企业环境中，代码都是需要通过框架来管理的，方便代码的复用，消除冗余；同时，可以去看下PO，页面对象模式；

至于你说到的对象识别问题，企业中的项目不会存在那么多让你纠结定位的对象，目前用的最多而且灵活度相对高的是xpath定位，如果xpath定位不到，再考虑css定位，其他的基本不怎么常用，建议xpath相对路径定位要重点掌握

黑盒测试

请问下老师，每次版本迭代中，旧的功能做接口自动化重要些还是UI自动化重要些，感觉自动化不是一时就能写的完善的，需要不断集成、优化并完善的

子慕予兮

这个还需结合当前你们的项目和测试人员的技术水平是否都达到了自动化的标配水准综合考虑；

首先敏捷模式下的自动化测试向来都有一些纷争，其实主要原因来自于sprint周期短，时间有限，而自动化脚本的开发与维护本身就是一个代码开发的过程，说白了和软件开发几乎没有本质的区别，同样需要设计，编写，修改、调试自动化测试脚本；不同的只是开发人员通过代码最后呈现客户需要的产品，而测试人员通过编码最后呈现基于自动化框架的测试脚本，目的是为了高效率地确保开发人员研发产品的最终质量；

从这一层面上来讲，测试人员需要不断提高自己的编码能力，自动化用例的设计能力，确实如你所说的自动化不是一时就能写的完善的，不是一蹴而就的；

对于传统模式转为敏捷模式的一些公司，往往由于测试人员的技术水平还没有到位，导致自动化测试很难同步应用于每个迭代，这也就是为什么有些公司会成立专门的自动化测试小组，独立于敏捷团队，主要职责就是负责自动化框架的搭建，以及一些回归测试脚本的编写维护，从而作为support为敏捷小组提供实时的自动化帮助；

旧的功能做接口自动化重要些还是UI自动化重要些？
这个问题不在于接口还是UI的问题，需要从当前项目的属性来分析，哪些需要自动化，哪些没有必要，并不是所有的回归测试（泛指旧功能）都一定要自动化；通常适合自动化的测试用例有这么些特征：

需求变动不频繁 —— 这里指的是已经经过了几个迭代后，不太会有大变更的需求，那么这些需求可以通过原来的手工测试转变为自动化脚本，每次需要迭代的时候，直接自动执行即可；

自动化测试脚本可重复使用 —— 一个公司的主流业务下的各类项目，基本上都会有些共性，可以把这些拥有共性的项目需求综合看一下，是否当前的项目是基于之前的版本做的二次开发，或者版本更新，那么就会有相当一部分的回归测试用例可以被重复使用，而这些很适合转为自动化脚本；

同时针对到底是接口自动化，还是UI自动化，他们都同样重要，无论是接口还是UI从宏观上讲都是功能范畴，接口倾向于集成阶段，UI更侧重于系统层面，是用户最后能够直接看到的产品；所以一般先接口，再UI，两者在测试中属于从底层到高层的互补作用；