“测试开发不分家”之我的感触

我在自己的角度来谈这些感触，不免有些偏见或不足，请走过路过的测试小伙伴轻拍, 也请小伙伴们在留言区分享下感触，大家一起互动下，互相了解、学习，便于日后在工作中小伙伴们可以更好的协作。

感触1

合作过的一些测试小伙伴，大部分基于页面、应用界面测试，一起协同工作的过程中最大的感触就是：测试人员也需要有HTML、JavaScript、CSS、网络甚至UML等基础知识，能借助浏览器开发者调试工具（F12）简单的分析、了解页面的HTML元素组成 ，能够了解基本的网络协议、常见HTTP状态码，这样才能在日常测试工作中事半功倍（例如：测试、开发沟通方便，测试人员可以自己分析接口API Response信息），而且我认为测试人员也是技术人员，也应该具备一些基础的技术知识/技能。

感触2

合作过的测试小伙伴，他们做的接口测试，更像是单元测试（自己平时单元测试大部分也是借助Postman、JMeter来做，一些不方便的内部方法单元测试则借助JUnit或者TestNG来做）；

感触3

如果测试小伙伴有UML的基础知识，这就大大的方便了，能减少很多的沟通成本呢，比如我在开发前一般会做功能模块的详细设计（有时候是开发结束后补），用例图、状态图、活动图、时序图等真的很方便展示、讲解对应的业务模块，也容易借助这些来了解产品，但实际情况是详细设计中我画的这些个图在用来向高级架构师讲解我的设计方案、实现思路后便搁在那里了，很少/基本不会再用来和测试小伙伴讲系统/产品功能，也不能强行这么做。

小知识

用例图：从用户角度描述系统功能。
类图：描述系统中类的静态结构。
对象图：系统中的多个对象在某一时刻的状态。
状态图：是描述状态到状态控制流，常用于动态特性建模。
活动图：描述了业务实现用例的工作流程。
顺序图：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互。
协作图：描述对象之间的协助关系。
构件图：一种特殊的UML图来描述系统的静态实现视图。
部署图：定义系统中软硬件的物理体系结构。
包图：对构成系统的模型元素进行分组整理的图。
组合结构图：表示类或者构建内部结构的图。
交互概览图：用活动图来表示多个交互之间的控制关系的图。