通用技术 想让开发自测,我们测试需要给开发提供啥?

米阳MeYoung · November 28, 2019 · Last by married577 replied at December 04, 2019 · 1401 hits

很久不发帖,这里丢个问题。

我们现在越来越讲究测试左移,越来越看重开发测试的比重。 测试左移,或者提高开发测试比重有一点清单就是让开发做更多的测试。 那么问题来了:

1. 开发做更多什么类型的测试?
2. 测试如何帮忙开发自测,测试需要提供什么等?
3. 如何去校验开发自测与否,以及自测的质量如何?
4. 第三个问题也引申一个问题,提测的标准可以有哪些?

共收到 14 条回复 时间 点赞

被测需求核心流程的用例即可,用例中不需要体现太多细节性的东西,至于用例的载体,随便什么都行,可以是xmind、文本文件。。。
第三个问题:先不说怎么检查,我们先说怎么做好自测,这个东西尽量用流程去约束(小公司可能没有流程,那么靠你自己的冒烟用例),有时候自测质量不高,有可能是人的问题,如果真的是这样,就不好办了。。。

好问题,关注下

GAGA 回复

心里有一定答案只是想看看 大家都怎么去定义。

我们当前尝试做的2件事:

  1. 在用例评审阶段,真正的跟开发共同定下自测用例,并真实给到开发,并开发自测后用例备注。
  2. 测试最烦的是准备数据,我们测试可以为开发自测提供一些基础的数据准备,甚至数据生成工具。

来自大老板的重视

就我司的实践,分享下个人经验见解:

  1. 开发做更多什么类型的测试?
    ——正向的基本功能流程,或者说相当于冒烟测试类型的测试

  2. 测试如何帮忙开发自测,测试需要提供什么等?
    ——冒烟测试,或者说开发自测的用例(内容写明确一点,别只是要点,免得认知有偏差后面撕逼);造数据的脚本或者平台(特别是对于后端比较复杂的,前端不懂造数据会导致自测效率很低);走通整体流程的一些手把手教程或培训(有时候开发只知道自己负责的一小块子模块,不知道整体流程怎么回事,我们既然很熟悉这个,可以分享下)。严格说不是帮忙自测,而是让开发更方便、更高效地去做自测,这样他们才更愿意做。毕竟开发最能产生价值的还是写代码完成功能,都想在写代码之外的事情尽可能不要花太多时间。

  3. 如何去校验开发自测与否,以及自测的质量如何?
    ——用例精简到顺利的话半小时内可以全部完成,然后提测前让开发组织做一次半小时到一小时的演示(我们内部称为 showcase ),开发自己亲自执行这些自测用例,测试和产品一起看。一个是确认功能确实已经可用,测试自己也不用再花时间重复执行一遍;另一个是产品确认实现效果和他期望一致(有时候产品需求会有些没提及的模糊地带,开发可能不沟通直接自己脑补做功能,和产品期望不一样)。如果老是走不通,开发自己也会不好意思的,所以能借此促进他们自己先做好自测再演示,免得出溴。

    很多时候开发自己对质量没要求,是因为自己开发的东西自己都不用,所以对里面的问题都没感觉,磕磕碰碰能过一次就交差了。让他们自己实际用起来,自然就会发现自己开发的东西有啥问题或者哪里不好用,产生改进的自驱力。用流行点的话说就是 eat your own dog food ,各个大公司内部最新版本要求研发全员自己日常就得使用也是这个道理。

  4. 第三个问题也引申一个问题,提测的标准可以有哪些?
    ——核心还是要能证明自己的代码能用,至少能走通正向核心功能,所以最低要求是上一步说的演示必须进行并且测试、产品都认为可以通过。更严格的提测标准可以在这个基础加上一些代码质量要求(如 sonar 标准、单测标准等)

恒温 回复

这个才是根本,大老板不重视,其他都白扯

米阳MeYoung 回复

我谈下我的看法~但是有些是纯看法,还没有实践过
1. 开发做更多什么类型的测试?
——我感觉开发要做的是两类测试:1.代码自测(目前我们没有严格规范,主要看研发个人能力);2.功能流程,我觉得如果考虑让开发自测,很大程度我们基于“功能测试”的想法,所以业务流自测是我们主要想让开发做的,目的是为了确保没有低级bug,确保业务流实现。
2. 测试如何帮忙开发自测,测试需要提供什么等?
——我们目前做的是提供自测用例,自测用例的来源是:我们认为哪些业务流是研发需要确保实现的。
我们的业务很少涉及大量数据,纯操作型,所以我们的业务流可能不像你们要制造数据,所以制造数据这块的我不了解,我看法是研发自己去想要产生什么样的数据。自测这块还是需要研发有些自主想法,所以之后我们也会借鉴你的方式,就是和研发讨论自测用例。有利于多暴露问题。
3. 如何去校验开发自测与否,以及自测的质量如何?
——啊~第三和第四个问题就是我想关注的!!!我们现在仅仅通过冒烟测试的效果来看自测效果,测试冒烟不通过及自测有问题。但其实这相当于通过结果来判断过程,不太好!我学习了下5#陈恒捷的关于这个问题的看法,可以借鉴,只是考虑的是如此做下去,效率和效果哪个对项目影响更大。
4. 第三个问题也引申一个问题,提测的标准可以有哪些?
——关注~

陈恒捷 回复

你好~关于第三和第四个问题你们的做法对我有些启发,我有个问题是,如此做下去,当项目内容/业务流/功能点很多时,效果和效率是如何权衡的?

这个问题很具备代表性,我也想结合团队的实践凑个热闹。
1. 开发做更多什么类型的测试?
看到这个问题第一反应是push开发写UT,实际上我们这边多个项目都尝试过,抵触的很厉害。只有少数稳定的项目才能主动写一点。我们的做法有几点(和恒捷他们的做法类似)

  • 研发部署好配置环境,设置好conf文件各种参数,我们的业务线配置文件比较复杂,经常因为研发本地自测环境不一致导致提测的和自测的不一致,提测被打回。(目前这个问题已经通过docker解决)
  • 研发根据测试人员提供的ckecklist在测试环境进行演示,保证自己的功能都ok,业务逻辑主流程通过
  • 前端开发会写mock保证交互的API格式和状态正常(不能是4或者5的错误)

2. 测试如何帮忙开发自测,测试需要提供什么等?
我们这边可以加速研发提测准入的方式有几种:

  • 完善的CI/CT/CD流水线功能
  • 自测用的checklist
  • 由测试开发的造数平台,方便研发自测一键造数(业务流程复杂,造一个测试数据非常麻烦)
  • 增量代码覆盖率统计
  • 性能监控、离线训练等(模型算法会用来自测)

3. 如何去校验开发自测与否,以及自测的质量如何?
如上面提到的,研发需要在测试环境进行演示,走主流程的checklist,如果没有自测到的话,会当场现形。
测试在测试过程中发现冒烟测试不通过会打回本次提测,在系统中会有记录。
自测质量主要有代码覆盖率统计来进行跟踪,目前没有特别好的办法来跟踪这个指标。

4. 第三个问题也引申一个问题,提测的标准可以有哪些?

  • checklist验证通过
  • API冒烟测试用例自动化测试通过
  • 静态代码分析结果没有Block级别bug
  • 部分业务需要性能自测QPS在指定范围内

*团队目前正在准备实行开发自测,分享一下流程,以及我遇到的一些还未解决的问题

1.需求评审会预留自测用例执行时间
2.测试在评审会结束后提供自测用例,并上传至任务链接
3.开发执行自测用例并填写执行结果,与测试环境编号
4.测试接入时发现功能本身与自测结果不符追述原因

遇到的问题:
1.如何定义哪些任务需要自测用例(UI类等)--测试主管主观界定并给任务打标签过滤
2.如何确认哪些任务已交付自测用例?--测试主管给任务打标签过滤
3.任务流之前间隔时间长,测试环境变更频繁会导致自测结果无效怎么定责?--未解决
4.任务提交杂乱导致测试可能上传N份自测用例不敏捷怎么处理?

GAGA 回复

当项目内容/业务流/功能点很多时,效果和效率是如何权衡的

核心点和自动化回归一样,这个事情不管谁做,是不是你在上线前必须做的。如果是,那做这个事情本身就不会降低效率,最多持平。而效果肯定比不做要好。

但要留意做好宣贯,让整个团队都认为这个事情是必需要做的,工作量纳入时间排期和提测标准。很多时候开发不做自测很大的原因也是给排期时没有考虑这块的时间,所以没时间做。

另外,如果项目自测的内容确实非常多,光测试执行可能就要超过1天,那真的得好好想想是不是需求划分出了问题,一个需求太过庞大了。

陈恒捷 回复

好的~非常感谢,关于这一部分我会考虑如何在我们这落地使用,看看效果如何

技术型的老板和公司是多么的重要啊
有吗?

感觉冒烟case就够了

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up