您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
最近看到的这个词，可能有点落伍，但觉得很有道理，当一个测试和一个开发团队合作时间很长，就像同一款农药对农作物上面的害虫的效果，最开始的时候锋芒毕露，有奇效，慢慢的效果会越来越差，也就是害虫知道了杀虫剂的弱点在哪，盲区在哪，因而产生了耐受性，免疫杀虫剂。测试就像杀虫剂，想去去除开发出来的软件上面的虫子（bug），而长时间的一直合作，测试同学的手法、思维方式会在一定区间内禁锢，使得这个区间之外的bug不容易被看到，事实上这个问题也不是不能解，借鉴农药的例子，也许可以想一下：
换别的牌子的农药，也就是测试岗轮换，每个人的思维方式不同，每个人的盲区也不同，这个时候轮换可以将重叠的部分加固，盲区部分被一点点发现，相辅相成互相沟通，可成活水。
农药升级，修改配方，也就是测试同学通过各种途径，拓展自己的视野和思路，试着消灭自己的盲区，这个拓展和提高不仅局限于技术，还包括思考方式以及对业务核心的理解等。
多用集中不同农药，也就是交叉测试，跟换品牌农药差不多一个意思，多种不同的覆盖面，会让盲区变得小，但也可能会导致副作用，比如耗时会比较长，ROI低。
提升农药浓度，也就是加大测试密度和强度，这样也可以解决一部分盲区，一些耐受力不强的虫子会被去掉，但也有弊端，比如ROI低，高密度和强度会使顽固的bug更加顽固，还会使降低工作积极性和成就感。
我们一直在做自动化覆盖的核心思路是：“我来看看系统是不是有bug，是不是和之前不一样了”，就像有一条路，有一个机器人按照既定路线往前走，看看原来平坦的地方是否有坑了。
按照这个思路再拓展一下，另一个核心思路也许是“系统里现在可以确认有1个bug，能不能找到”，就像有一条路，现在明确了有1个坑，这个机器人按照它既定的路线走，能否找到这个坑。
再按照这个思路往下想想，发现也许也可以这么想
系统里现在有1-10个bug，能不能都找到
系统里现在有至少10个bug，能找到多少
系统里面有1个关于数字格式化的bug，能不能找到
系统里面有1个关于数字格式化的bug，有1个空指针bug，能不能找到
系统里有3个类型的bug各2个，能不能都找到
...
想了想，今年云栖大会上有人的分享了一个思路，修改被测代码、用AOP等手段注入故障或者修改运行时数据，以此来检查测试用例有效性，也就是说，不再是从未知的一片漆黑中找坑，而是制造明确的1个或者多个坑，看看我们的用例是否能找得到。
这个思路可以做的事情其实还挺多的，也是对于测试同学对业务代码的理解要求更高了一层，需要能够通晓业务代码，并且有模拟故障模拟bug的能力，然后以此去测试自己的自动化的覆盖能力，也许这就是有同学曾经问过，但至今不知道怎么回答的那个问题：
“你用自动化去测试业务系统，那用什么来测试你的自动化呢？”
现在这个问题也许可以这么回答：“用自动化的断言测业务系统，用业务系统的bug测自动化，测开闭环，相辅相成”
我们测试业务系统的时候，从单元考虑到接口考虑ui然后考虑大qps考虑多并发，考虑容错考虑异常处理，考虑监控考虑.....
设计自动化测试的用例的时候，也许也应该试试能不能这么做，比如：
单元能力封装，可能是接口，可能是数据准备，每个单元可以单独运行，可以复用
单元能力编排成流程，可能是接口-接口-数据可能是数据-数据-接口，每个编排可以单独运行，可以复用，比如编排成提交流程、发起审批流程、审批通过流程
流程编排成业务，可能是提交-审批-通过可能是提交-审批-拒绝
考虑并发问题，单个用例多触发，同时触发运行
单元用例，也是需要测试的输入--运行--输出--断言，就像业务代码中的1个方法一样。
把自己业务线的自动化用例封装成一套以单元用例、单元流程、单元业务组成的一套有层次有验证侧重点的框架，比如单元用例主要校验单个接口或者数据准备的健壮性、可靠性、正确性等等，单元流程用例主要通过每个单元用例吐出的数据进行业务流程串联，以验证单个流程【或者某页面，1个页面的渲染需要很多接口同时生效】正确性，业务用例主要通过各流程的能力串联完成完整的业务，验证业务正确性。
以接口为单位封装单元用例，以页面为单位封装流程用例，以页面操作步骤为单位封装业务用例，大致思路如是。
数据构造类自动化，核心目的是构造测试数据，如果能构造出来预期数据，代表其中的各个环节、接口是ok的，顺带验证了功能，作用是人工测试可以替代的。
业务验证类自动化，核心目的是验证业务功能，大约需要3个基本板块，作用是人工测试可以替代的。这一类自动化，被数据、环境问题严重干扰其稳定性和结果可信性。
数据构造，用于给后续的流程生成将要验证的数据
执行验证，通过既定数据，进行相关业务逻辑操作，验证正确性
数据销毁，将构造的数据、执行后产生的临时数据、垃圾数据进行销毁，保证自动化的清洁。
必要自动化，核心目的是完成一些必要的枚举和排列组合的相关验证，其作用是人工测试无法替代的。
业务验证类自动化，多数是以验证业务完整性为准绳，这类自动化核心逻辑是“它本来应该是这样的，等下次我再跑的时候，看看它还是不是这样”，对于bug发现能力其实相对较弱，必要自动化能很大程度上发现排列组合各种极限场景的bug，但需要这种自动化的场景也较少，数据类自动化，其发现问题的能力、发现bug的能力都是最弱的，但对于手工测试的提效是最为明显的。
UI自动化
前端是最贴近用户使用习惯，用户对系统能力的直观感认知，直接决定用户对系统的评价
UI自动化的稳定性、可靠性、ROI一直是阻碍这个其实最应该冲在业务最前沿猛士的核心原因。
接口自动化
服务端业务逻辑的正确和健壮，是业务能够平稳运营的根本，也是让业务赢的根基。直接决定对业务的支撑能力和扩展能力。
接口自动化相对于UI，更稳定，能验证的点更多，更深入，更容易发现服务端业务逻辑的问题，保证业务核心逻辑的正确完整
单元测试
单元逻辑的正确和健壮，直接决定了由单元拼装起来的接口、业务的能力，是整个工程健壮、稳定、扩展性的基石。
单元测试相对于接口自动化，极稳定，一般都与业务在同一工程，验证颗粒度更细，验证更全面、深入，更能发现每个逻辑单元的问题，保证每个逻辑单元基础的正确、完整、健壮，但，目前单元测试难于推进，实施难度相当大，增加开发时长、增加项目时长，也增加工作量，因此目下多数应用都没有铺设单元测试。
安全测试
试图通过技术手段，站在***的角度，尝试攻破系统，类似于安全演练，挖掘更深层次的框架、或者部署架构、或者网络、或者中间件等相关的bug。
对专业技能要求极高，不仅对网络、操作系统、中间件、开源框架有整体了解，更需要对当前业务系统的业务有深层理解和分析，甚至要比开发同学更了解业务系统代码，综合从各方面对系统进行全方位的专业性技术测试，保障的是系统的安全性
性能测试
通过对系统进行各方面的大量摧残，去看系统的支撑能力、反应速度等，比如同时又10000个人在用会不会出问题，10000个人能同时用多久不出错，最多能同时支撑多少个人用等。其实是为了保证系统的可用性，一个系统在业务能力满分，UI设计交互等满分的时候，如果总是不能用或者用起来很慢，那么业务能力满分，UI设计交互等满分这样的好东西就会荡然无存。
对专业技能要求较高，不仅需要对系统的整体部署接口很了解，也需要对系统所采用的的框架、实现方案、数据库、网络结构等进行评估，还需要对业务特点进行分析，从而通过对系统进行各种场景的模拟，对系统的支撑能力进行全面评估，大致有，稳定性测试（大并发撑很久不出问题），容量测试（系统最大能抗住多少并发），并发测试（某个业务被同时操作时的业务逻辑处理，增减库存问题）。
其实无论哪种测试，当积累抽象到了一个层面时，就可以进行自动化，性能测试自动化、安全测试自动化，UI、接口等等各种自动化，甚至借助于AI可以自动生成自动化case，自动修正等等，但问题在于，当把这些东西都做成自动化了，那么就需要有一个手段来验证自动化，否则自动化变成一个开环的东西，往往会变成“为了完成目标”，最终自动化也没起效果，手工回归覆盖也不做了，从而废弃。
斗胆说接下来的话：
业务系统的能力有自动化测试作为衡量手段，但自动化测试的能力却几无衡量手段。
代码覆盖率，分支覆盖率，核心业务覆盖率，这些可以证明，测试覆盖过，或者覆盖了，但无法体现自动化的能力，譬如我加了case，但没做断言，覆盖率会上去，但事实上是无效case
在衡量自动化提效比例或者时长时，鲜有将维护自动化投入时间的比例、时长算进去，如果每提效5分钟就需要维护1小时，那么就需要考量是自动化没有必要，还是自动化有问题亟待解决
单一、不闭环衡量标准很多时候会造成“为了衡量标准”！自动化测试对业务系统有制衡，但自动化测试却无物制衡。
试试想一想集中自动化和业务系统的闭环衡量方式衡量业务系统：用自动化去却
衡量业务系统：用自动化去确认业务系统某个功能或接口或前端是否符合预期。
衡量自动化：用接口返回的某个功能或接口或前端不符合预期去确认自动化是否会发现。
也许需要做的几件事
从体系化的业务场景定义出发：看自动化核心验证的是什么，保障的是什么，如果是保障业务，那么就挑核心业务、故障场景定义了的业务，在其中随机挑选一个点进行bug注入。
从用户使用直观感出发：可以进行随机挑选，把自己看成一个用户，或者找到旁边的同学，让他看看自己在这个系统上会关心什么样的功能和地方，然后在这些场景里面进行随机注入。
从竞技角度出发：如果我是你系统的用户，你是我系统的用户，那么我们调过来，你把自己用我系统最多的地方进行注入，我也对你的系统做同样的事，我们都来看一看互相的自动化是否能够对对方关注的业务点有问题有感知能力。
从红蓝角度出发：开发同学在发布的时候，随机对自己认为最重要的地方专门写一个bug，检查自动化测试是否能在发布后可以发现，或者将注入能力提供给开发同学、PD、业务方，这样的行为可以大大提高开发同学、PD、业务方对测试专业性、对自动化的认可，以及对自动化结果可信性的认可。
很大一个问题是，这个bug、故障给注入到哪
依然需要通过数据mock、环境探活、数据准备等手段，确保自动化运行时，需要验证的业务逻辑所必须的条件都具备，而后需要通过技术手段或者直接改代码（不推荐）对系统进行bug注入，然后执行自动化，尽可能尝试在一切必要条件都完备的时候，模拟系统出现了bug的情况，用这个确切已知的bug验证自动化的能力。
服务端的bug多数时候很难被用户感知，但前端的很容易被用户感知，因此，前端的bug注入验证自动化能力，变得价值更高，数据返回对，但前端没加载、数据返回不对但前端展示了、后端报错前端没有弹窗、前端图标位置不正确等等。尽可能尝试将前端这个用户感知最明显的地方，将自动化验证的能力放大到像真正的用户在进行操作。
逆向方式“我系统今天告诉你我有bug，我倒要看看你自动化有没有这个本事找到”
通过数据mock、环境探活、数据准备等手段，确保自动化运行时，需要验证的业务逻辑所必须的条件都具备，尝试尽可能将验证业务逻辑这件事做的纯粹。用自动化验证系统的业务能力。
通过数据清理、数据恢复，将自动化运行后产生的中间数据、临时数据等进行清理，尝试尽可能将自动化做的，我来过，看过，但不带走一片云彩，不留下一篇垃圾。
正向方式“我自动化今天要看看你这系统有没有bug”
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。