优秀的开发都应该是一名合格的测试。写到了一半，想起了TDD，，，当做过过去一年半的总结了
主要想聊一下component test的经历和经验，对于集成测试没有相关的经验，所以一下测试和开发均是针对单个组件或者多个相关组件的测试。
当然单元测试也不在讨论范围内，聊得是介于集成测试和单元测试颗粒度之间的测试。不过受同事在单元测试的成果，自己也慢慢意识到了单元测试的重要性和可玩性。
一、开发和测试的分界线
我自己看来开发和测试所以只是在意的点不一样，不应该有很明显的分界线，甚至他们应该坐在一起，深度参与到开发过程中。
想起来在nio时自己的一个尝试，让测试lead一个功能的开发，包括前期的需求理解、分解以及排期都是由测试来做的，然后测试来给系统、开发分享自己的理解。开发的一个功能是酒精锁，涉及的ecu还挺多的，所以与其他模块的交流也是由测试拉通的，并且会涉及到PEU模块，所以在开发阶段，不太可能上实车和用上台架，所以测试人员基本把该模拟的都模拟出来，后续极大的方便了开发人员去开发，最后的结果和进度都是超乎想象的好。不知道算不算是另类的测试驱动开发。当然，结果这么好，与当时主导该项目测试人员的能力还是有很大关系的。但是想说的是，开发和测试不应该有很强的分界线，可以视情况互相主导情况。
二、开发阶段的测试
开发阶段的调试受我在怿星领导影响最大的，他经常对我说的一句话就是，我希望我交出去的代码是可被信任的，所以我的代码基本都会进行比较充分的测试。在后期的时候，通过仔细看他的代码，发现基本都是开发代码和测试同时进行，虽然不是TDD，但是至少是DIT(Dveloper Is Tester)了，所以后续写代码时，也会刻意的去考虑测试。
印象很深刻的一件事是，去年在nio重构上线时，项目经理提出了挑战，你怎么保证你的代码是没问题的？
先说结果，项目经理最终从怀疑到决定提前一个版本上线，但是牺牲了我的国庆假期。
我是怎么保证我的代码没有问题的，当时我记得列了一个表：
-
当前会进行的测试，通过自己搭建的简易台架，我全部测试过了，然后列了：
-
。。。
-
。。
-
。
-
-
使用当前会涉及的集成测试工具，进行了完整的功能测试
-
整个项目一开始是将近5万行代码，每层通过对等实体进行了测试，每个小组件都是经过接口测试的
-
针对当前未考虑的异常状况我也做了一些测试，做了鲁棒性测试
回过头去想这个事情，如果是全部开发完再进行测试，我觉得是很难想象的，一个是考虑的不够全，很多开发细节在开发完就忘了，另一个就是测试是一个很琐碎也相对无聊的事情，如果放在一起做，很容易就懈怠了。
在zeekr的这段时间，开发s2s过程中，我觉得是我进一步爱上测试的经历。先看如下图：
-
在开发阶段设计，就设计好了测试的解决方案，包含各层对等实体、功能测试以及压力测试部分
-
开发过程中，测试代码一直在迭代（UT在其他地方）
为什么要在设计阶段考虑好整个测试解决方案？主要是因为，负责的这个模块还是通信为主，所以就有相应的对等实体，考虑到不想依赖于真正的对端，所以我需要复用我自己的大部分代码来完成对端的模拟。正是因为在开发阶段一直想着测试的事情，所以面对后面可能几十、几百的s2s service服务时，也很自然有了自动测试的想法并且在实践中真正落地了。
目前来看，s2s整体的软件代码质量是挺高的，无论是从性能还是功能层面。当然这也离不开同事在单元测试付出了很大的精力。（这里得吐槽一下他，他觉得单测是万能的。。。）
在开发阶段同时关注测试，不仅可以降低，编程过程中的忧虑感，同时在后续遇到bug时，给出solution代码时的调试也有很大帮助。最后我们可以把测试方案以及测试代码全部给到测试人员，由他们把测试代码和方案用他们专业的知识做进一步完善，这个过程也是触进测试和开发感情的很重要一部分，而且也能让测试参与到开发的过程。
三、bug阶段的精准测试
在软件交付阶段，最不喜欢听到开发人员的两句话：
-
：“这个日志我看了，大概知道了原因，我加点日志，你再帮我复现一下。”
-
：“我修复了一下，你再帮我测试一下。”
在面对超低概率的bug时，比如万分之一甚至更低，我觉得这是对测试人员的折磨，，，而且大概率上述两句话还是重复很多次。
那么面对上述的问题，开发人员应该如何做？我自己的个人经验是，如果拿到的日志足够分析出大概原因，针对第一句话的解决方案是：
-
拿到测试步骤，
-
本地模拟，
-
写个测试脚本，自动化，反反复复的测试，
-
一步步分析日志，把测试的工作全部通过本地模拟+测试脚本来代替。
因为我是在linux开发的所以，上述的方案基本是很容易实现的，如果在mcu上做开发的同事，相对来说会难很多，当然思路也是可以借鉴的，无非就是更难模拟和自动化测试（这是我从mcu准到linux开发的关键原因，需要的工具太多了）。同时我觉得开发人员掌握shell、python等脚本语言真的是强需求~~~入门容易，作用又大。
而第二句话其实就是第一句话解决方案的延续，自己修复了，自己是需要做精准测试的，然后再把修复给到测试让他们帮忙做完整的回归测试。
如果开发人员在开发阶段考虑过测试方案，上述针对bug的精准测试特别容易实现，没人比你更懂开发了。并且后续我们可以把我的精准测试case加到测试人员的回归测试用例中去，跟测试一起积累测试用例。
四、性能测试阶段的摸索
在我看来，最不应该由测试人员做的一个测试就是性能测试或者不应该是测试在组件测试阶段关心的（不太懂集成测试阶段的性能测试）。因为，软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是在完成该功能时展示出来的及时性（cpu负载也是间接影响及时性）
开发更关注的性能测试应该是：
-
压力测试
-
稳定性测试
-
并发测试
压力测试是评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。要完成压力测试，要么是直接上到实际环境或者进行模拟，而实际环境时即使压力超过预期，也不一定立马出现bug，而且是概率性的，所以测试效率很低；而模拟的话，测试人员只能从整体角度来模拟。但是开发人员可以在软件的各个层级来模拟，并且可以通过很多手段来增加压力，比如以不同的速率不同层级的接口，然后看看长期在压力环境下，各个指标是否要求。再结合在不同层次的打点，很快就能分析出问题所在，基本是开发、调优、迭代一条龙；所以性能测试由开发来做是很合适的一件事，当然把所有的工作做完之后，可以把性能测试的成果给到测试，由测试用进一步的完善补充。
稳定性测试，我们既可以在压力测试时，长期让组件运行一段时间，用来检测系统的稳定性；而并发测试，我一般也是放在压力测试中完成，因为造成系统负载的方式有很多，并发可以的。
五、写在最后
开发爱上测试，重要的不是测试代码本身，是解决问题的思维，也许可以泛化，哪怕没测试，如果能够做到快速验证，反馈，价值的稳定叠加，有足够信心，也未尝不可。也许你会说测试可以cover功能，那么如果只有这一点的话，但是如果所有测试都由测试来做，相对流程来说，已经往下走了，修复的成本越来越高，而且也会让测试对你产生怀疑；而价值反馈思维才是开发应该去做测试的目的。测试的过程，会让我们以结果导向，使得我们简单设计(并不是无设计)，日常重构我们的代码库，注重交付价值流稳定叠加。
另外一方面，开发在开发阶段思考测试，个人感觉是一个很好的思维框架，见过很多开发解bug更多的是靠猜，很主观的觉得，这个bug可能是这里的原因，我先改一下试一下，靠灵感编程，凭直觉涉及，撞大运修bug，还总觉得有很多灵异现象（曾经的自己）。