- 主题:大家公司的代码都做自动化测试吗
赞！
我之前参加过的项目有这种情况，这都是大型项目了。
严重影响QA的主要有两种情况，一种是break build，另一种是build不能用。
Joel on software提到微软30年前遇到break build一般是让肇事者午饭时间看着rebuild。
但我们有个项目build一次10个小时，没法搞。
如果按瀑布开发管理方式，我们之前是在qa和build之间插automation qa，保证基础功能可用
如果是按agile管理，按feature划分小scrum团队，每个scrum团队有自己的branch。有的qa在主branch上工作，有的qa在各个feature之间流动工作
这是我们遇到的情况和处理方式
【 在 eGust 的大作中提到: 】
: 我们也有类似的问题，有时 QA 环境更新收到大量 PR。在测试 A 功能时，由于功能 B 出了问题，导致 QA 无法进行测试。而 QA 又无法判断是谁导致的，于是就随机 bounce 某一个 ticket。然后开发这边就得花时间 debug，找到出错的代码，再告诉 QA 这个问题是由另外一个 jira 导致的，你 bounce 错了。如果有 work around 的话我可能也会讲一下，不然可能不光我一个人的没法继续测。有时候实在太严重，只好 ssh 过去直接修了，不然按照我们的流程，可能半天时间 QA 都干不了活儿了。一来二去，浪费至少两个人的时间。
: 这方面我们感觉很大程度上是 branching model 导致的，因为 QA 用的 branch 包含所有人的代码。而 QA 只是随机的拿一个 jira，并不知道有哪些变动，更不具备可以判断问题出在哪里的能力。出了问题，自然也做了一定的研究，看看别人的经验。不过这方面我并没有非常成熟的想法，主要也是很多相关 model 的介绍中都并没有提到 QA 的角色。
: 比如 git flow，并没有明确说 QA 应该测试哪个 branch。如果测 develop branch，那就跟我们的现状没有差别，完全解决不了问题。测 feature branches 的话，首先就是可能某些 features 单独测没问题，但是它们又并非完全独立的，merge 到 develop 后可能会产生新的问题。其次，某些 feature 本身的工作量也很大，需要几个人协作完成，并且也无法避免产生依赖关系。最后需要给 QA 能够主动切换 branch 的能力，但我们最大的问题是数据库，想要 rollback 是非常困难的。当然技术上的问题不光数据库一个，但个人感受技术上的问题都是有办法解决的，更大的问题还是在人的观念上。
: ...................
--
FROM 123.116.198.*
feature branch merge之后，scrum团队就解散了...
主branch上的qa会做一些简单测试，确保没有严重问题。
如果出现问题，会是原scrum团队中的senior dev在主branch修复，修复一般不会出现严重问题。
不过就算出现问题也没事，主branch上的activities比较少，qa大不了退回到上一个build。
别的scrum会定期从主branch merge稳定的代码过来。
qa团队手头有个长长的test cases列表，不同的情况人工跑不同的case集合
这种是传统软件开发公司，qa和dev配比在1：1甚至1.5：1之间
国内互联网公司不是这样。我见过某互联网公司某个项目，开发测完了就上线了，qa也不能说没有，50人的开发配了3-5个qa。
然后灰度ci，灰度用户。那个团队经常半夜3点被客服叫起来修复客户问题。每年团队离职率至少10%...
【 在 eGust 的大作中提到: 】
: feature branch 并入主 branch 之后，再让 qa 把 feature 重新测一遍吗？如果发现问题，之后的 fix 是直接进主 branch 还是有其它的流程？我其实挺好奇其他公司都是怎么做的，毕竟网上能找到的文章大都忽略了 QA 的角色，而在实际中真的 CI/CD 后敢直接拿用户当小白鼠的还是极少数。所以不管有没有自动测试，不至于一个小错误就浪费许多人的时间，应该是每个项目都会遇到的问题。
: 这么来看，我们 rails app 还算是很容易搞了，如果能用上 container 的话。我们最主要的问题是数据库，我本地电脑上的测试，启动 oracle container 大概要30秒左右能用，然后大概3分钟建好空的数据库。一旦数据库准备好，启动应用本身不会超过1分钟。按照我的估计，技术上不超过10分钟就能从0跑起来，跟10个小时比起来几乎就没有时间成本。上个厕所，倒杯水，再读一下 jira，差不多也就能用了。
:
--
FROM 123.116.198.*
“这本书里是不提倡feature branch这种方式的”
主要是看开发人数。敏捷那边有不同背景的人提出相矛盾的准则，然后换个环境互相被打脸的
你们开发人数多少？
【 在 xunery 的大作中提到: 】
: 《持续交付：发布可靠软件的系统方法》这本书里是不提倡feature branch这种方式的，比方说要不要而对这个分支配置CI/CD，如果长时间不能合并到主干，合并的时候还有很多问题。还有很多其他理由
:
: 实际操作中，我们是小地迭代都在主干做（哪怕有新feature），非常大的版本升级，会新拉一个主干，以后都基于新主干，CI/CD和QA的工作主要基于主干来做，感觉效果还是可以的
: ...................
--
FROM 123.116.198.*
那个帖子说了，build一次10个小时。一般开发人员没有build能力
【 在 xunery 的大作中提到: 】
: 可以通过流程管理来避免break build这种情况。
: developer提交完代码可以自己提交编译自己那部分，编译成功之后，自己可以先拿回来测试一下或者跑一下自动化测试，没有问题就当作打包的备选版本。整个项目打包的时候不再build，而是去拿这些备选版本打包。这样可以做到开发者随时发现编译问题，或重大问题版本不入包，需要整体安装包的时候也能在很短的时间内出包。
--
FROM 123.116.198.*
那个情况很复杂。这么说吧，那个项目当年觉得从瀑布改敏捷，是从thoughtworks总部找的咨询，咨询来了之后大家觉得太水，改培训了。
改完敏捷之后俩同事分别出了本关于敏捷的书
软工的东西需要根据不同的项目情况采用不同的策略。
【 在 xunery 的大作中提到: 】
: 这10个小时只编译一个组件吗？
: 哪怕项目有100个组件就应该可以划分组件各自随时编译，编译出备选版本随时可打包。每一个开发者可以随时对自己的组件提交编译申请，然后就是等待编译服务干活出结果。
: 要是打包的时候一块编译100个组件，是一种糟糕的流程管理方式。
--
FROM 123.116.198.*
那个项目是个传统企业it软件，瀑布的时候是每1-2年一个版本，改成scrum之后变成一年俩版本（不过不一定在有些市场上发布），交付周期上改进还是蛮大的。
一个scrum team2/3的开发，1/3的qa。automation qa会出个人旁听。一般总共10-12个人
那个项目也是有人员的问题：之所以build一次要10个小时，
首先是项目确实复杂，2000w行的cpp代码，各种相互依赖甚至很多环状依赖。要出x86和x64两个版本，有的模块当时还有ia64的版本。同时还有文档编译，还有iso打包等等一堆步骤。
不过要用10个小时，也是dev们懒得去降低依赖，风险高没有收益，就都装看不见
当年云计算的变革开始，一线提了很多设想，都被美国总部嫌风险高否定了，之后产品就缓慢的向下滑，后来总部那人就直接被开除了...
你们产品底子还是不错，人员上没那么顺畅但还能风水水起
【 在 eGust 的大作中提到: 】
: 我理解 scrum 就是开发和 QA 组成的针对功能的小组，基本上按 sprint 来？
: 我们目前开发是5个左右 ruby（偶尔写 plsql），2.5个 plsql，一共就俩 QA，其中一个觉得心太累下个月离职了……
: 我们这 senior 破坏力更大，有时候本机都没测就提交了，然后 QA 环境一堆500。而且超级没耐心，bitbucket 上面一个 build 要跑大概20分钟，没等跑完就 merge，结果自然出问题。前段时间加了点儿东西到 bitbucket-pipeline.yml 里，版本之间有 conflicts。人家特别勤快的亲自去修，结果缩进搞错了格式不对，两天跑不了 build……
: ...................
--
FROM 123.116.198.*