我去热饭的博客

到时候别人一看，谁能知道 DB_Project是A端的表，DB_Objects是B端表？1. 旧名不包含端名的，比如/scriptList/ ，DB_Project ，新功能要全部后缀端名，变为：/scriptList_B/ ，DB_Project_B ，以后只要看到没有后缀的，就可以认定为最早的A端业务代码。2. 旧名中包含端名的，比如/set_A_Detail/ ，/objects_A/ ，全部把端名进行更改，位置和大小写不变，变为：/set_B_Detail/ ，/objects_B/。

代码】【测开方法论】测开平台pk心得-抉择。

阅读完此文章，你会明白要怎么学习新知识后举一反三，理解真正的知识创造方法。没事也看看哲学和方法论，对成为高p可能有好处哦~前言学习有俩种方式，一种是显式学习，一种是隐式学习。显式学习：看书，看教程，看视频，传统培训等。隐式学习：在公司由老手带，跟师傅修行等。显式学习会产生显性知识，也就是摸得见看得着的技术。隐式学习会产生隐性知识，也就是所谓的经验，能力等。正文为什么同一个教程，有的同学可以举一反三，有的则不能。问题就出在这个显性知识和隐性知识的对立和统一上。原文：墨格尔认为一切事务的发展变化都是对立统一运动

    最近，在给同学上课的时候，偶然聊到测试排期。    有一部分同学说，测试经理一直都是拍脑袋决定排期，根据以往的经验推测出测试排期，特别准。周围人都很信服。    另一部分同学说，测试排期应该是严密的根据各种因素来求出，比如目本身-字数/涉及的功能点数/涉及的测试范围/涉及的测试端/产品经理/开发同学/测试同学/开发同学人日/当前月份等等因素，严丝合缝的求出。  

    二次开发，大多数情况下，我们的技术水平，精力时间，都不允许我们对源码进行深度解读。    想弄明白每一行代码的含义，每一个变量参数的含义，每一次调用和原作者每一次的意图，都非常困难。    所以我们需要用更加经济，实用，性价比高的方法去实现我们的二次开发需求，在这个理论下去用最高效率的方式实现需求，如果第一次不顺利，则一点点增加成本，扩大范围，到正好足够为止，此方法论会节省大量时间

     测试开发的领域中，我们做的最多的就是 生产测试数据的工具，还有自动化脚本，工作流自动化等等提效工具。     今天要说的就是在制作这些工具的时候，要留个心眼，留什么心眼呢？当然不是坏心眼，而是要做好脚本代码执行失败的 处理办法。    执行失败后，确保不生成脏数据。这个意思很简单，比如你做一个自动注册的脚本：原来需要很多恶心的实名认证/验证码/邮箱/昵称设计/推荐码等等

    什么叫 自造自用？ 就是你自己做出的工具，麻烦你自己先用几十遍。  这么做是很有必要的！为什么呢？且听我细细道来：    在测试的完整周期中，不知道大家听过没有：我们不但要测试程序的准确正确性，还要测试需求的合理性？        我们大部分的工作是按照需求测功能，看符不符合需求，不符合就算bug。但是在我很久之前接受到培

在我们测试开发日常的工作中，经常会遇到一些需要控制的 需求。    问题1：    比如一个自动化测试平台，它有100个脚本，你想让它们多线程并发执行。但是你为了减轻电脑压力，所以想设计规定 每次最多并发10个线程。你要怎么控制？    问题2：    再比如，你要做一个能关掉一个监控进程的功能，这个监控进程在无时无刻的运行，但是有个按钮，只要点下去

什么是追踪溯源，这个词语放在 “测试开发” 工作中要怎么理解 我们先放一放。先来想一下，在测试开发工程师写一个复杂平台的时候，最担心什么？如果是一位初级测开，那么他最应该担心的是能否搭建成功，实现功能。如果是一位中等测开，那么可能他最担心的是功能的性能，效果，以及推广问题。如果是一位高级测开，那么他最担心的八成就是后续的维护成本，自己能不能有精力维护，能不能交接给新人。而其实最影响后续维护成本的，也是最让人操心的，就是自己和后续的人，很难看懂之前的代码，或者很难去再次置身于当时开...

说起预判，大家可能并不陌生，在电子游戏中，高手通常预判非常好，比如，预判敌人的走位，提前把技能释放到地方等待敌人恰好撞到。那么在测试开发领域中，预判具体指的是什么呢？ 这里其实就是指，对某些比较复杂的开发等技术任务，在立项或者解决的前期，对整个项目链条的周期，方案，风险，成功率，效果等等进行精准的预测。为什么常见于测开领域呢？相比较普通的纯业务开发程序员的工作来说，测试开发的任务 往往充满着很多不确定性，甚至比摸石头过河还要有风险。很多经验不足的同学，往往会事倍功半，太多的意外发生...

影响稳定性的元素有很多，比如架构的复杂度，空间利用度，整个功能的链条长度。本篇主要说的一个情况就是链路长度。不知道大家是否听过一个词，叫全链路压测。也就是直接对整个功能的链路进行压力测试，压出最弱的那个环节 好进行优化和加固。那么在我们测试开发的工作中，当开发一个功能时，如果实现此功能的链路过长，支撑服务越多，那么其稳定性会大大降低。众所周知，车链子质量决定于最弱那节。在一个功能的全链路中，但凡一个环节出现错误，都会导致整个失败。小刘是一家大型公司的测试开发，他最近要负责一个定时监控.

磨刀不误砍柴功。在测试开发日常的工作中，对于某全新的领域开发工具/平台/框架/算法时，如果时间充裕，最好能提前准备好各种工具算法。当然，按照我们之前的优化章节中意外性优化所说，很多麻烦的事 是开发过程中才发现的，如果预计后续会经常重复这个过程，建议立即转去打造一套小工具脚本。小伟奉命打造一套 构造房源的 快速脚本，其中涉及到多个接口步骤，小伟迅速做好了这个工具。但是好景不长，没过两天，其中有个接口需要维护了。此时的小伟用了大概5分钟，进行新旧接口的对比，找出了需要修改的部分，替换掉了原来的

在目前最为正式且最早的笛卡尔 的方法论中，有着关于学习一套东西的四个注意点。本文将联合我们测试领域的工作，去学习一下：1.确保用来当作依据的事实是真实的例子1: 小张准备开发一个非常难的自动化测试框架，整个实现过程很漫长，其中很多步骤的前提，都是某某条件达成，比如某某技术存在且可靠。 在最理想甚至说是幻想的情况下，这个算法是可以完成的。结果小张开始了漫长的开发工作，可是好不容易进行了一大半的时候，才突然发现，其中一项很重要的技术元素自动定位技术 ，并没有开源，且无法改造，导致整个计划破产。小张

何为优化：大家虽然不是真正的开发工程师，但是也或多或少听说过 优化 俩字。而如今做到测试开发工程师，当然要去写代码，做工具，搞平台，写脚本了。那么但凡跟创造和代码沾边，就少不了优化，毕竟这世界上没有最好，只有更好。不同之处：那么测试开发和开发的不同之处在于以下几点：1.测开做的工具 用户量不大，效率要求也并不高，安全性要求也不大，便利性等等要求都不如真正的企业级c端工具，所以优化方向上要偏重于 稳定，可靠，权威。2.测开很多时候只能靠自己，没有开发同学配备的需求/产品/ui/设计/.

本内容在国内属于首次创造，属于先例，所以是摸着石头过河，内容在持续更新中，喜欢的可以收藏 点赞 关注一波，养肥再看！写在最前：什么是方法论？方法论是以科学的方法总结出来一套规律，可以复用到其他人身上一样生效的学习/研究/创造 的方法。它就像哈姆雷特，每位大佬心中都有自己的一套心得，已经提炼或正在提炼中。为什么需要方法论？1.总结自己的经历，提炼精华成规则，以遇到新困难时候可以有套路去做，而不用惊慌失措。2.可以分享给其他同事，让其他人变得向你一样优秀，举一反三，提高团队整体战斗力良药