原文链接: https://dsx2016.com/?p=661

单兵作战只能胜任分发到自己的模块,团队协作才能让产品快速而高质量上线.

有正必有反

想要提升团队协作的效率,先分析哪些事物阻碍了开发进度.

一般情况下,项目预估的时间相对的紧凑,如果发挥正常,则上线时间不会相差太远,中途有什么变化,也会根据反馈实时调整进度.

但有时候,代码能够稳定的发挥其固定的作用,人就不一定了,不同的行为会导致差别极大的影响.

负面作用

全局干扰

最近的一个项目中,进入到提测阶段的时候,一些新版的功能都已经通过第一轮测试.

但是在代码没有改动的情况下,测试忽然提出了一堆的bug,一些以前的功能部分都不能正常使用了.

请注意,一旦遇到类似的情况,几乎没有改动主要功能代码的前提下,忽然发生大面积的bug,于前端而言,不是后台挂了,就是某个兼容性问题,特定手机机型或者系统版本等.

还有一种不应该发生的错误,就是团队的其他分支代码影响到整个项目的全局,从而导致你的功能异常,如css样式覆盖,js变量覆盖等操作.

现在回顾一下,当时我的操作是先排查功能异常的原因,发现是vuex和vue-router传参parmas失效,但是为什么莫名失效,google了好久,定位到怀疑人生.

由于之前已经有过协作导致错误类似的经验,加上对自己代码机制还残留一点点信心(技术的熟练度决定排查问题的思维和方式),转而开始查看gitlab的日志记录

在查看同事的日志中,发现一段才提交不久的代码,这段代码的定义就是在全局路由做了一些操作.

在这里,我也犯了一个错误,看到对方的注释写的是仅在第一次登录xxx,然后就没有往下看代码的作用了,然后又开始怀疑人生.

当时间耗时超过半小时后,就应该想办法解决当下无法解决的问题,和同事交流或者稍稍放松,换个思维方式等,当排查超过一个小时,于是去问了同事.

同事说前不久是在ios上进行了全局操作,因为需要开发一个新功能,所以在ios上每次页面切换时,把vuex和vue-router传参parmas给重置了.

在这里,先不提排查和定位问题的能力,只能提醒在座的各位,如果明知道自己的代码会对全局有着影响甚至是颠覆的作用,请一定要在群里声明,或者至少和同事口头声明.

当然,尽可能不要产生对全局不可控的代码,没有谁能保证自己的代码不会对以前的功能或者同事的模块造成影响,解耦是一种能力,声明是一种态度,也是协作的方式.

tips:

有一些团队会进行codeReview,一个是提交时review,一个是提交后review.

不论哪一种,都是对代码的质量负责,像上述这种错误,如果进行了review,在发布测试前就会被发现和拦截,这种错误不应当出现.

团队没有review的流程,也没关系,大多数时候不要养成别人定了规则才会去执行的习惯,一定要有自己的独立思维,要有自己的优秀习惯,团队没有,但是不妨碍自己定期的review.

前几期讲了提升效率的方法和技巧还可以加上一条,加班时或者定期review,及时看看自己的代码和同事的代码,查漏补缺.

协作时间

前一段时间,测试在没有任何告知的情况下,周六加班冒烟测试,前后端的都不加班,也不知道要测试.

于是产生了几个严重的影响,同样也是人为的不该犯的问题.

一是由于没有邮件或者群里正式声明周六提测,导致前端没有发布最新的测试版本,周六测试的是上上个不知道什么时候打包的版本.

这种情况几乎可以说测试是白测了,所幸测试的版本恰好功能上都符合,只有一些样式没有跟上进度,所以没有造成极大的时间浪费,影响不大.

二是正常工作期间,前后端每次发版的时候,很少有人会主动在群里提起或者正式邮件声明(虽然有时候不需要太正式)

导致测试测着侧着就提示网络错误,或者用旧的标准在测试新的代码(如忽然改一个新需求和ui,但是测试不知道),导致提出bug或者被中断测试流程(如下单)

其实在发版前群里告知一下是基本的沟通义务,也是最起码的工作态度,就效率而言,能避免很多不应该出现的问题,仅仅是一句话的事情.

其次,与人方便也是为自己方便,发版时也可以注明当前版本,发布内容(更新了哪些功能等),以及一些其他说明,让事物有据可查,有别人更容易理解.

但是在好几家公司发现,不论是刚入职的小白,还是混久的老油条,都不会去过多的关注一些团队和沟通的细节,或者说懒得操作,宁愿事后甩锅也不愿事前留心.

tips:

国内没有倾向于使用邮件的习惯,即使是重度有工作属性的职场.

如果不强制要求,别说邮件了,连聊天软件都懒得回复,如非需要,甚至口头内容都不会有.

建议大家多使用邮件,最少也应该使用有聊天记录的群或者沟通工具.

其实说到底,首先是一个工作态度的问题,愿不愿意协作和配合,其次才是工具的使用.

其次,要注意的事,最好的工作时间是全员都在的时候,有问题一定要及时处理.

不可能等到别人下班再去解决,这样也解决不了,事情要分轻重疾缓.(很重要,思维方式)

建议上班的时候解决要和人协作的问题,个人不太紧急和重要的问题可以留到临近下班或者加班或者解决合作问题之后.

权限问题

测试的过程常常需要反复去操作一个流程.

但是一个流程往往操作后就固定了数据状态,再次操作不可能再创建一个账户或者每次叫后台清空数据(仅前端).

虽然假数据也可以,但是有些逻辑仍然需要真实的反馈,如登录,短信验证,身份识别,提交订单等等等.

一般开发,有本地环境,测试环境,正式环境,至少在本地环境和测试环境,数据是可以临时操作的.

如果有管理后台建议获取操作测试环境后台面板,针对自己开发的模块做一些流程设定操作,如更改用户状态等.

如果没有管理后台,使用sql等直接操作数据库也行(前提是要会一点点数据库和对表结构了解~具体可以问后端)

前提是避免一个功能测试需要很多遍,但每次都要找别人来重置数据,别人也可能一直在忙,没有时间帮忙或者留意到你的需要.

其次是,直接操作数据库是一个很大权限的事物,哪怕只是本地环境,一定要尽可能避免产生脏数据,影响其他流程.

有的时候需要去复现一个bug,必须走完一些流程,操作繁琐且很难定位,通过后台和修改数据库会快很多.

总的来说,就是测试有的权限,你尽量也要有,如管理后台,数据库等,没有,就只能让相关模块的人尽量配合.

避免有时间但是流程卡住无法操作的情况,这种现象是真正的极大浪费时间,而且一废就是大半天.

tips:

当然还会有一些其他权限,如代码合并的权限,发布测试和线上的权限.

这就涉及到技术和态度意外的因素,要留心那些你有时间有技术但是你无法操作的事物.

正面作用

正面的方法可以简单概括为

• 分工合理,责任明确,模块化

• 高效的沟通机制(聊天软件,任务面板,邮件等)

• 定期检查,及时调整(codeReview,日报,周报,大小会议)

比起正面作用,更倾向于排除负面作用,哪怕正面作用不大,但至少不会影响效率和进度.

要知道吖,大大小小的公司,其实最混乱的,最致命的,也最为核心的.

从来不是技术和能力,而是团队管理和协作,是人与人之间的沟通和行为.

tips:

正面作用下一期文章再细说.

目录

前言

1、提升测试效率

2、提升开发效率

3、提升版本发布效率

4、提升特性交付效率

前言

在大部分研发项目经理心中，进度通常往往会放在第一位，其次是成本，最后是质量，当然人员队伍也最好要稳定。天下武功，唯快不破：进度 > 成本 > 质量 > 人。

这个说法并不是绝对的，当然今天我们并不是讨论他们之间的优先顺序。而是围绕效率提升，测试可以做什么？

相信大部分测试人员脑海里首先会跳出来：“自动化测试”或者“敏捷测试”，没错，自动化和敏捷都可以帮助提升研发效率，但是并不是只要做了就都有这个提升作用。

测试效率提升有以下几个不同段位：

1、提升测试效率

提升测试的效率，最有效的手段是制定测试策略。对，你没有看错，是测试策略而不是自动化！

测试策略提升测试效率的逻辑是：减少不必要的测试，重要的问题早发现早解决。

测试策略的基础是风险评估，首先从失效概率、失效影响这两个维度，区分高、中、低风险的特性，失效概率是发生错误的可能性，评分一般是依据：同类特性的历史表现，设计中需要考虑的要素多寡，需求变更的频繁程度，是否采用新方法等。失效影响是错误发生造成的影响，评分的一般是参考：错误失效对主要业务流程的影响范围，给研发团队以及客户带来的直接经济损失，修复成本，信誉影响等。这两个风险维度的评分虽然有一些参考维度，但主要是依赖经验。

风险评估完成后，根据每个测试内容的风险评分，确定测试的时间和强度（测试强度通常是用千行代码用例数来衡量）。原则上高风险的内容要尽可能早测试，低风险的内容在计划安排上灵活性可以大一些。高风险的内容要多测试，比如考虑多种测试设计方法同时使用，安排探索式测试等。测试的过程中，需要持续地分析缺陷数据、指标数据，以确定风险是降低还是升高了，如果发现风险升高，甚至已经成为会阻碍产品发布的问题，则必须进行例外报告，调整开发和测试策略。

提升测试的效率，基于需求的测试也是有效手段之一，基于需求进行测试设计的目的，是减少不必要的参数组合和虚构的应用场景的测试用例。当然，只基于需求进行测试，往往不那么让人放心，因为总会有意外的情况发生，一般还需要再基于经验、基于错误猜测，或者基于在线应用采集的应用场景进行一些补充。对于特别重要的测试内容，可能还需要基于设计进行更高强度的测试。

那么，为什么不是自动化呢？大多数时候，我们是将原本手工执行的功能用自动化的方式来执行，这种情况下自动化测试更多的是服务于质量，其目的是发现新特性对老特性产生的，不为人知的影响。如果新特性每次发布，都会导致老特性发生意外的变化，进而导致测试不得不在每个版本都全面测试老特性，那么这种自动化就是提升测试效率的。不过，这种情况比较少见，而且，如果真的发生这种情况，一定是产品架构设计出了问题，优化架构比实现自动化测试的优先级要高。

2、提升开发效率

测试活动不再局限于测试活动本身，测试帮助提升研发效率，最有效的手段是自动化和工具化，这两个手段是实现TDD和缺陷快速定位的关键措施。

TDD的作用，是用测试用例的形式表述需求或设计目标，从而确保codeing过程中，始终在做正确的事，在向主干中加入各种分支处理逻辑、或者进行各种修改时，不会破坏已经正确的功能，让开发可以放心的修改缺陷或者重构代码。在TDD实施中，测试的主要价值是提供趁手的工具，这个工具不仅要能够驱动测试用例执行，还要让开发很方便的构建测试用例及其执行所需的条件。我们有些团队在TDD实施的早期，把TDD用例编写和调试的工作也交给测试完成，这种方式无法让开发及时验证自己的每一次改动，做不到及时的质量反馈，也起不到TDD宣称的那些作用，不建议采用。

缺陷快速定位为什么要拿出来讲呢？因为，我们曾经统计过开发的工作量，在实现阶段，大概有1/3~1/2的开发工作量是耗费在缺陷的确认、重现、定位、修改、验证，如果能加快这个过程，则开发效率会有大幅提升。

通过缺陷辅助定位工具，可以提高这部分工作的效率。在一个用例执行不通过的时候，工具自动采集缺陷定位所需的信息，如：系统产生的日志和其他过程与结果记录，产生变化的数据库记录，此用例执行覆盖到的代码。通过这些信息，可以在无需重现、无需跟踪执行的情况下定位大部分的问题。当然，要实现这个目的，仅仅有工具是不够的，还需要产品做一些日志上的增强，例如在函数的入口和出口记录函数的输入、输出参数。缺陷修改完成后，再用自动化用例进行验证，就能够对开发的缺陷定位产生积极影响。

很多团队中，开发人员会把测试提交的缺陷集中在某个时间去修改，也是为了压缩处理缺陷的时间，但是这样会导致质量风险在开发后期集中爆发，是不值得借鉴的方式。

提升代码质量，除了TDD和缺陷定位，还可以在环境准备、测试结果采集上，使用工具和自动化提升效率。

3、提升版本发布效率

测试服务于研发整体而不是某个环节的效率提升。

测试帮助提升版本发布的效率，主要方法是自动化和CI（持续集成）、持续交付。

自动化是CI的基础，而自动化及CI是持续交付的基础。

CI对自动化的要求，除了用测试用例进行自动化的产品验证，还包括自动化的编译、打包、部署、环境检查等。

持续交付在一般CI的基础上，通常还需要做到应用场景的自动化验证（通常是基于UI的自动化测试，用于冒烟测试）、常规性能的自动化验证，不同环境的统一部署，以及按不同的策略发布。一般的组织中，持续交付主要还是用于向专门的测试团队交付产品版本。某些互联网公司能够做到将持续交付用于生产环境，这种场景下，除了上述能力，还需要在产品上线初期进行自动化的异常侦测，看护系统和业务的正常运行，此外，还应该有比较可靠的系统和数据回滚机制。在生产环境中，要使这个过程安全的走下来，验证用例最好能比较完整的覆盖基本功能和新增需求，也需要根据历史问题不断完善看护、侦测规则。

发布时对基本功能的覆盖，除了传统的人工编写自动化用例的方式，利用在线运行抓取实际场景是更能让测试适配产品更新节奏的方式。

理想情况下，CI可以做到每天（也可能是每周或者其他的周期）都能够有一个质量过关的版本为上线做好了准备。这是比较理想的情况，我没有见到过真正这样实施的团队，在我们团队中，CI更多的还是在开发过程中，检查程序员的代码质量，起到的是质量门槛的作用。

持续发布是研发整体的工程能力提升，需要的不仅是研发团队的工具开发能力，还需要在过程管理、配置管理，甚至产品架构、质量文化等方面进行匹配。持续发布的实施，有专门的书籍做了详细介绍。

4、提升特性交付效率

测试不是依赖工具和自动化，而是依赖分析设计服务于效率提升。

测试帮助提升特性 交付的效率，需要做到基于需求的测试，此外，敏捷也可以提升特性的交付效率。

基于需求的测试中，测试帮助研发团队在需求实现方面少一次试错。很多团队认为自己是基于需求进行测试的，但实际上是基于“需求规格说明书”进行测试，后者依赖一份质量优良的文档（标准是，内容完整且正确，研发各个环节都可以完全依据这份文档开展工作，并最终得到正确的特性），但通常这个依赖条件不存在。

基于需求测试需要做到的：

改善需求质量。利用需求内容模型（5W1H）促进需求内容完整性的提升，利用测试对产品、业务的理解，通过静态测试发现需求中的遗漏、矛盾、错误，从而改善需求，即测试设计输入的质量。

基于需求测试。根据需求进行单个操作、业务场景和端到端应用场景的测试。并在测试执行时，通过研发测试、邀请客户和需求工程师参与体验和演示等方式，在产品特性半成品上，利用形象的操作过程对抽象的分析进行验证和纠错。

基于需求的测试除了要会使用上述方法，也比较依赖测试工程师的经验，因为实际应用过程中，我们通常都是参照已经成熟的特性，曾经犯过的错误来进行查缺补漏。

敏捷提升交付效率的基本逻辑是实现按特性开发和交付。首先，应对这种小步快跑的方式，测试需要及时对少量的新增和修改内容进行测试，在最短的时间内进行质量反馈，这要求测试设计、测试执行（自动化测试），甚至发布、部署都要能够在迭代周期的时间窗内完成。其次，按特性发布可以让客户尽可能快的看到和使用特性，以便更快的进行产品应用层面的质量反馈，因此，如果团队按特性开发了，但是并不能按特性 交付，那么对于交付效率的提升还是只完成了一半。

敏捷是建立在研发的质量文化、产品的架构优化、测试的自动化水平之上的研发模式的演进，如果没有这些基础，仅仅依靠模式的改变是无法既提升效率，又维持质量稳定的。

围绕效率提升，测试可以开展的工作远不止上面提到的这些，这些都有待我们持续地研究、探索和讨论。。。

感谢每一个认真阅读我文章的人！！！
如果下面这些资料用得到的话可以直接拿走：
1、自学开发或者测试必备的完整项目源码与环境
2、测试工作中所有模板（测试计划、测试用例、测试报告等）
3、软件测试经典面试题
4、Python/Java自动化测试实战.pdf
5、Jmeter/postman接口测试全套视频获取
我个人整理了我这几年软件测试生涯整理的一些技术资料，包含：电子书，简历模块，各种工作模板，面试宝典，自学项目等。需要的可以找我。

企业的竞争本质上就是生产效率和产品质量的竞争。如何提高生产效率是企业永续发展的关键问题，提高生产效率也有利于降低生产成本。在制造型企业里，生产工艺复杂，生产流程长，生产质量不易管控。如何保证生产质量，并提高生产效率，是制造型企业当下的发展难点。

影响生产效率的因素：

1、产品加工工艺变更频繁，生产工艺复杂

2、生产过程品质不稳定，频频出现返工或返修

3、紧急单或临时单太多，生产计划变更频繁

4、生产车间机器故障，维修时间长

5、采购物料计划与生产计划不能协调同步进行

6、采购物料时常延迟、采购品质经常不良

7、生产部门没有进行完善的质量分析

生产质量分析，做好质量数据管理，助力企业降本增效

生产质量分析-设备故障和备件分析

结合设备故障、设备维修情况、备件出入库情况进行数据分析，以优化设备维修、维护计划和备件采购计划，降低设备维护成本，减少维修给生产、管理带来的损失。

对故障的种类、原因、影响等参数进行统计分析，并构建故障预测模型，为设备的购置、维修、升级等业务计划提供支持。统计分析每种备件出入库数量，结合设备故障预测、生产需求等预测备件需求，为备件购置等其他业务提供数据支撑。

慧都生产质量分析-生产情况分析

通过对各工序生产情况、生产工艺参数分析、生产原辅料验证分析、生产过程分析、产品生命全周期质量分析，部署生产、质量分析模型，探索影响质量的数据因果关系和相互关系。

生产质量分析-生产质量预测

打通质量和人机料法环数据，建立机器学习模型进行预测，输出故障是否发生，质量管理由被动转为主动，有效降低出现返工或者返修的几率。

生产质量分析-质量数据自助分析

生产质量分析实用工具，自助部署质量分析模型，开发质量分析可视化页面。简单易上手的质量分析工具，员工只需对数据进行选取、拖曳，自助灵活地达成期望的数据结果。

生产质量分析-质量分析可视化看板

通过直观易懂，生动的可视化交互式图表、动态呈现分析数据。支持大屏看板、PC端、移动端展示，打造管理驾驶舱、企业数据中台

生产质量分析，通过对铝箔质量数据分析，找到制造过程中废品的根本原因

生产质量分析开启企业生产全流程分析应用

商业智能，基础平台建设：

生产过程控制分析、产品全生命周期质量分析、设备维护分析、生产工艺参数分析、生产原辅料检验分析、订单交付分析

高层管理驾驶舱：

市场营销分析、生产产能与能效分析、设备效率分析、库存管理分析、财务分析、高层管理驾驶舱

大数据智能分析平台：

质量分析及优化、能耗分析及优化、需求计划分析、设备故障预测、告警预测及直因分析、企业战情室