登录注册
最新博客
最新资源下载
这一天还是来了，连Dev都会高效地编写自动化用例了
活动主持人2018-06-13 12:32
1.背景
自从杭研质量保障部引入“bug率” 这个指标， 大多数项目的 "开发质量" 都稳步提高。我们在质量度量平台上统计了30+ 个项目的质量， 现阶段优良率已经达到90%以上，请参考下图：
开发质量的提高，不仅使得测试过程更加顺畅，整个研发周期缩短，测试阶段bug大幅度减少，并且线上问题也成比例地降低。
总之，将质量前移到开发阶段，取得了正向的效果，也获得了整个团队的认可。
2.开发更深度地自测------接口自动化、持续集成
而我们今天所要讨论的内容，仍然脱离不了"开发自测" 这个大主题。
正如标题所述，我所对接的网易**团队，他们不仅能高质量得完成冒烟自测，
而且可以高效地将用例自动化。
目前我们用于回归的场景用例，有一部分就是开发编写的，每天定时、认真地跑，保证了系统的主流程随时处于可工作状态， 真正做到了持续集成。
如下图：
不知道目前，有没有哪个团队的开发人员深度参与了自动化测试的工作？
可以和大家分享下，我们的团队，开发与QA在自动化测试中是怎样紧密合作的!
2.1 团队介绍
在讲干货之前，我先穿插一段团队介绍。
开发成员：11个后台，1个前端（看人员比例，这位前端确实很猛）。其中3位老员工， 8位新同事。
测试成员：1.5人
你可以得出结论：
这个团队属于一个新团队，而且在干一件从0到1的大事！
这件大事一共经历了2个月正式上线。
请看我的质量报告中的其中一段：
是的， 我想强调的就是这个项目，
从0到1， 又包含多个模块： 应用层（3个平台）、基础服务（多个子模块，以PRC的服务提供给应用层）、投放引擎、账户、结算、帐号、权限等， 能在2个月如期顺利上线，除了同学们夜以继日、加班加点高强度工作以外， 我认为还有一个很重要的原因：开发测试之间紧密协作（其实是开发分担了很多测试工作），才换来了高质量快节奏的上线！
当然肯定离不开团队领导的英明指导（他最不想我夸他，所以稍微带一下，不然我可以夸3天3夜）
2.2 开发完成接口自动化
一个全新的项目，开发有延期，在意料之内
一个崭新的团队，各个模块进度不一致，也是在意料之内
但如果测试阶段能够搏一搏，说不定还能力挽狂澜，
这是一个正常的团队，正常的幻想
事实证明，这样的幻想还是要有的，万一实现了呢？
开发已进入了尾声，除了WEB端进度滞后，其他模块已开发完成。
在测试登场之前，有一项非常非常重要的事情需要开发来完成---
各个模块之间的联调。
我给了开发们几点建议：
- 在测试环境联调
- 由于入口web端未开发完成，用接口来测试
- 开发能像测试一样，用上游的数据，而不是简单的在数据库插入数据， 否则就失去了联调的意义
- 每个模块的开发在接口测试平台上定义好自己的接口，并调试完成。
- 测试同学把整个系统所有的主干场景梳理出来， 整理到接口测试平台上
- 由1-2个同学（2个提供基础服务的开发）主导，把整个场景在接口层面调通
- 如果可能， 尽量把这些场景的用例实现自动化！（最后这条是开发负责人的诉求！）
上线时间紧迫， 任何合理的建议都有可能被采纳!
也是在这个阶段， 见识了后台开发同学思维的严谨，一个查询的接口用例，可以设计地这么清爽详细，还分了好几个状态来校验：
UI状态，配置状态、内部状态。
场景用例就更不用说了， 作为一名测试， 我非常喜欢开发同学写的场景用例（只有标题是QA写的， 内容都是开发填充的）
总结：开发写接口/场景用例的优势
- 由于是自己写的代码， 对接口定义非常了解，哪些参数有意义， 哪些没意义，一清二楚（开发甚至把测试写的接口用例干掉， 自己重新写了）
- 由于是自己写的代码， 对内部逻辑非常了解，在用例的实现和校验上，一清二楚 （测试只需要写个标题，开发就知道怎么去实现校验）
- 如果测出问题， 直接修改代码，少了沟通环节， 效率高。
所有模块联调完成整体提测后， 重中之重的结算，资金，投放引擎多个后台模块的bug有且仅有3个， 在线上试运营一段时间后，也没有明显的问题。
2.3 持续集成不仅只有jenkins能做
大家都知道，我们传统的接口自动化，都是通过测试代码来实现的，杭研比较常用的框架为， Testng + Java，他的特点是灵活，需要一些代码基础。
假如有这么一个可视化的平台， 代码能实现的接口自动化， 这个平台都能实现
你们愿意尝试哪种方式？
我想答案不言而喻！
平台化是大家喜闻乐见的事情， 使用简单， 技术壁垒小， 上手快， 而且整个团队都能看得见， 摸得着。
哪怕有一天这个开发团队没有了测试，也可以玩转。
所以我们的开发团队，一听说有这么好的平台，就立马采用。
就像我当初给他们推荐，还有一个很好的性能测试平台， 他们毫不犹豫全副武装就上， 一个道理！
接口测试平台，不得不说，是一个很好的平台， 从接口定义， 到接口测试， 再到场景测试， 最后制定执行集， 定时跑执行集， 一条龙服务， 贯穿了整个研发的生命周期啊！！ 而且开发测试可以共同维护，PM也一眼就能看穿目前自动化用例跑的怎样，帮忙敦促及时修复
有几个功能点，我觉得设计的挺有意思的。
我们有这样的场景， 就是校验返回值， 他不是固定的， 是概率事件
接口测试平台用 “轮询”完美得实现了我的需求， 不得不赞。
等待功能也不错， 相当于代码里的sleep
开启/暂停功能，能让你像代码里那样， 断点调试。
场景回归用例， 持续集成跑了2个月，已经处于稳定的状态， 有些不稳定的因素，也用比较合理的方式解决掉了！
例如保持环境的干净， 防止脏数据的干扰，我们写了一个工具， 以微服务的方式提供接口服务。目的是在跑用例之前， 批量暂停广告，清理脏数据。
还有的测试要辅助一些工具，你都完全可以部署一个简单的微服务。（我们的开发也会非常主动地响应我们的建议， 因为自动化不是测试一方的事情）
可喜的是，2个月的持续集成，除了能提升回归的自信心，提高效率， 也提前暴露了一些问题。
3. 实践总结
看到这里，也许很多人会想一个问题： "有哪些是我们的团队能借鉴的？"
如果你的测试， 经常做着接口测试， 我觉得至少有两点是非常值得尝试的：
第一： 你可以把用例直接搬到平台上， 让开发在上面定义接口参数，调试自测， 省得测试同学找开发要各种接口文档，还不一定调得通！
与其在文档上维护接口， 不如就在平台上， 方便你我他！
第二：如果模块较多，联调就显得非常重要，可以适当地让开发学会编写场景（选择最了解业务逻辑的那位开发，他写起来会非常easy），这些场景用例一定是整个系统的核心所在！
在接口自测，场景联调完成之后， 测试再进行系统的测试，会非常省时省力省沟通！
分享至：
