Electron 是一个跨平台的、基于 Web 前端技术的桌面 GUI 应用程序开发框架。

使用 Web 前端技术来开发一个桌面 GUI 程序是一件多么炫酷的事情，你可以使用 HTML、CSS 来绘制界面和控制布局，使用 JavaScript 来控制用户行为和业务逻辑，使用 平台上的模块已经超过 90 万个，覆盖领域广，优秀模块繁多且使用非常简单方便。

4) 无需考虑兼容性问题

在完成 Web 前端开发工作时，开发者需要考虑很多浏览器兼容的问题，比如：用户是否使用了低版本的 IE 浏览器，是否可以在样式表内使用 Flexbox（弹性盒模型）等。这些问题最终会导致前端开发者束手束脚，写出一些丑陋的兼容代码以保证自己的应用能在所有终端表现正常。

但由于 Electron 内置了 Chromium 浏览器，该浏览器对标准支持非常好，甚至支持一些尚未通过的标准，所以基于 Electron 开发应用不会遇到兼容问题。开发者的自由度得到了最大化保护，你可以在 Electron 中使用几乎所有 HTML5、CSS3、ES6 标准中定义的 API。

另外，Web 前端受限访问的文件系统、系统托盘、系统通知等，在 Electron 技术体系下均有 API 供开发者自由使用。

基于 Electron 开发桌面 GUI 应用并不是完美的方案，它也有它的不足，综合来说有以下几点。

1) 打包后的应用体积巨大

一个功能不算多的桌面应用，通过 electron-builder 压缩打包后至少也要 40MB。如果开发者不做额外的 Hack 工作的话，用户每次升级应用程序，还要再下载一次同样体积的安装包，这对于应用分发来说是一个不小的负担。但随着网络环境越来越好，用户磁盘的容积越来越大，此问题给用户带来的损失会慢慢被削弱。

2) 开发复杂度较大，进阶曲线较陡

跨进程通信是基于 Electron 开发应用必须要了解的知识点，虽然 Electron 为渲染进程提供了 remote 模块来方便开发人员实现跨进程通信，但这也带来了很多问题，比如某个回调函数为什么没起作用、主进程为什么报了一连串的错误等，这往往给已经入门但需要进阶的开发者带来困惑。

为了跟上 Chromium 的版本发布节奏，Electron 也有非常频繁的版本发布机制，每次 Chromium 改动，都可能导致 Electron 出现很多新问题，甚至稳定版本都有很多未解决的问题。幸好 Electron 的关键核心功能一直以来都是稳定的。

Electron 把一些有安全隐患的模块和 API 都设置为默认不可用的状态，但这些模块和 API 都是非常常用的，因此有时开发者不得不打开这些开关。但是，一旦处理不当，就可能导致开发的应用存在安全隐患，给开发者乃至终端用户带来伤害。

安全问题有很多值得关注的技术细节，以至于 Electron 官方文档中专门开辟出来一个章节号召程序员重视安全问题。但我认为，很多时候安全和自由是相悖的，在不损失自由的前提下提升安全指标的工作是值得肯定的，如果哪天 Electron 以安全为由停用脚本注入的技术，相信很多开发者都会反对。

Electron 底层基于的 Chromium 浏览器一直以来都因资源占用较多被人诟病，目前来看这个问题还没有很好的解决办法，只能依赖 Chromium 团队的优化工作。

除了以上这些问题外，Electron 还不支持老版本的 Windows 操作系统，比如 Windows XP。在中国还有一些用户是使用 Windows XP 的，开发者如果需要面向这些用户，应该考虑使用其他技术方案。

　　到底什么是 ISV

　　ISV 是 Independent Software Vendors 的英文缩写，意为“独立软件开发商”，特指专门从事软件的开发、生产、销售和服务的企业。

　　为什么是「独立」软件开发商？

　　多思考一下，就会好奇，直接叫软件开发商就行了呗，为什么要加一个独立呢？独立从何说起？

　　这就得追溯一下软件行业的发展历史了。

　　之所以叫独立，是因为软件最早是依附于硬件，是不独立的。

　　自 1946 年的情人节，第一台通用计算机埃尼阿克（Eniac）问世，计算机产业开始诞生和发展，如下图所示，那时候的计算机，贵就算了，还贼占地方。

　　也正是因为又贵又大，所以当时只有少数特殊部门才能够用得起计算机，比如国防、科研等等。

　　因此，计算机的供应量也少得可怜，相应的，对软件编写需求也较少。

　　所以，在当时，软件还是作为计算机硬件的附属，是由计算机硬件厂商开发并随机赠送的。

　　一些新兴职业，如程序员、分析员和计算机系统专家等应运而生。这就为软件行业的「独立」发展奠定了一定基础。

　　到 1964 年，一个标志性的人物出现了，一个名叫戈兹的人，创建了世界上第一家专门围绕软件产品开发和营销运行的公司——ADR。

　　而且，在当时，随着计算机行业的快速发展，计算机计算能力、适用场景也迅速增加。相应的，应用的数量、复杂度也在不断提升，计算机硬件厂商，像原来一样提供免费软件的成本也越来越高。

　　终于，到 1969 年，当时的计算机巨头 IBM 宣布：停止发送免费装机软件。并从 1979 年 开始，分别为软件和硬件定价。

　　作为当时计算机行业的领导者，IBM 的这一举动，极大地推动了软件行业的发展。

　　目前我们熟知的 SAP(思爱普）、Microsoft（微软）、Oracle（甲骨文）等等，都是在 70 年代陆续创建的。

　　也正是从那时候开始，软件不再是硬件平台的依附，而是独立与硬件平台的独立存在。

　　这就是「独立软件开发商」这一名字的由来。

　　ISV 的当代含义

　　随着信息革命渗透到每个角落，如今软件的风头，早就超过了硬件，甚至有了 Software is eating the world 的说法。

　　当前的 ISV，也基本不再和硬件平台强关联。

　　现在的 ISV，更多开始和软件平台关联起来。

　　目前我们提及 ISV 概念，更多指的是使用、集成和销售其他软件产品，但本身并不依附其他主体的软件厂商。

　　比如在飞书、钉钉、企业微信平台，会有很多软件开发商，利用这些平台的基础能力，开发和销售自己的软件。

　　这些都可以称作 ISV。

　　再比如微软的 office，其产品已经从产品套件，发展成协同平台，在这个平台上很多协同办公相关的厂商，都可以将其产品和 office 集成，给用户提供更加丰富高效的办公体验。对于微软来说，这些服务提供商，都是 ISV。

　　所以，总结一下，当代的 ISV，已经成为了一个和软件平台关联的概念，即当阐述一个服务提供商和一个平台之间协作关系时，我们常用 ISV 代指和平台协作为客户提供服务的服务提供商，这种服务既包括软件开发集成，在某些语境下甚至可能也包括销售。

　　ISV 的生存价值

　　前面也提到，ISV 经历了半个世纪的发展，在这个平台经济大行其道的时代，ISV 到底在平台生态中扮演什么价值，让其经久不衰，甚至越来越抢手？

　　向前认为 ISV 之所以存在，是由企业服务的复杂性决定的。

　　ToB 的企业服务，和 ToC 的个人用户服务相比，一个最大的差异就是两者复杂度。

　　一个企业服务软件，可能需要支持协同不同层级，不同部门，企业内外部共同完成一个任务，尤其是随着分工的不断细化，这种趋势愈加明显。

　　而 ToC 的个人服务软件，基本上都是一个人可以完成的行为。

　　因此，整体的复杂度不在一个量级。

　　这个复杂度，就决定了 ToB 的服务商，要贴身服务才能帮助客户梳理清楚，把软件投入使用，这些要投入很多精力人力。

　　如果一个厂商单独来完成，这意味着什么？

　　意味着他需要建立渗透全国（全球）各地的分公司，需要招募海量的员工。这些员工，还需要能够理解各行各业。

　　没有任何一个企业可以做到这个程度。

　　而 ISV，各种各样分布在各地、各行各业的小企业，可以很好地解决平台型企业无法解决的上述问题。

　　更重要的是，从ToB 服务复杂度延伸出的，就是 ToB 领域大量的个性化需求。

　　个性化需求意味着，平台型企业的一套标准化产品是无法完整满足客户诉求的，这时候，就需要有大量的生态 ISV，围绕客户细分需求做补充定制，通过标准产品+定制产品，最终来满足客户的诉求。

　　重服务和个性化，这两点就是 ISV 存在的坚实根基，且这两个根基，短期还看不到动摇的迹象。

　　随着软件行业的发展，ISV 和平台、客户的协作模式，也正在变得越来越复杂，向前试着总结一下，当前 ISV 主流的业务模式。

　　开发类 ISV，指的是基于平台能力，为平台应用客户，提供自己开发的软件服务的开发商。

　　再细分一下，又可以分为两类：标准化应用 ISV 和个性化应用 ISV。

　　标准化应用 ISV，就是围绕平台基础能力，建设通用标准的应用，以弥补平台在一些细分场景下的不足。

　　比如在飞书、钉钉平台上，我们都能够看到一些项目管理、人力等应用，这些应用，是由 SaaS 厂商基于这些平台的接口，开发的标准化应用，所有钉钉、飞书的租户，都付费使用这些应用。

　　还有一类，是个性化 ISV，与上面提到的相反，虽然他们也是基于一个标准平台，但是会提供一些个性化开发，例如某些钉钉的 ISV，就会给客户定制一些业务流，并和钉钉的审批能力集成起来，帮助客户更好解决业务管理问题，同时又能够收口到钉钉上统一管理。

　　销售类 ISV，职能一般比较简单，就是帮助平台厂商销售产品。

　　需要说明的是，在狭义  ISV 语境下，专职负责销售的，不会被叫做 ISV，而是更多叫做「服务商」or「渠道商」。

　　销售类 ISV，主要目的，就是基于自己对某些行业的理解，手头的客户资源等，帮助平台厂商，拓展更多的客户，他们通过和平台厂商分成获得收入。

　　这类 ISV，再细分又可以细分为：

　　传统 ISV，他们是销售类 ISV 的主体，基本就是利用自己的资源、理解来进行地推销售。

　　集成类 ISV，这类 ISV 具备一定的技术实力，通常很了解某个领域的很多产品，他们代表甲方客户的利益，为甲方选型和集成。他们会和客户、SaaS 厂商保持较好的商务关系，以获得客户侧的解决方案收入，和软件厂商侧的产品售卖分润。

　　还有一类是咨询类 ISV，这类 ISV ，往往是一些咨询公司。在当前如果脱离软件为企业做咨询，基本也是空中楼阁无法落地的。

　　因此很多咨询公司也会在咨询过程中，给客户引入软件解决方案，在这个过程中帮助软件公司完成售卖，在获得甲方的咨询费同时，还可以获得软件厂商的分润收入。

　　到这里，相信你基本对 ISV 有了更多的理解。

　　ISV 即独立软件开发商，概念起源于软硬件的分离和独立，当前主要指的是平台和平台生态企业的关系。

　　生态企业有负责软件开发的，也有负责售卖的，共同推动软件厂商和 ISV 自身的发展。

特别声明：以上文章内容仅代表作者本人观点，不代表新浪网观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与新浪网联系。

从定义来说是：验证软件功能是否满足用户的需求

软件测试是在软件投入使用之前通过手动或自动的方法对软件进行测试，以找出与预期结果不相符的地方。

在我看来，可以简单的说一下，测试可以分为两个步骤：首先运行程序，先保证程序整体的正确性；其次，检查功能是否满足用户需求。

（1）在给定的产品中尽可能多地发现错误 ( 或 bug ) 。

（2）演示一个给定的软件产品与它的需求规格匹配。

（3）  使用最小的成本和努力来验证软件的质量。

（4）生成高质量的测试用例，执行有效的测试，并发布正确   和   有用的问题报告。

软件研发是让产品从无到有的过程，测试的任务是发现程序中的缺陷，贯穿于软件开发的整个生命周期。

那测试与研发有什么不同呢？

1. 完成的工作不同：

测试   主要由测试人   员和开发人员来执行，测试人员完成黑盒测试（功能测试），开发人员执行单元 / 集成测试、并同时完成调试工作。

测试广度大、但专业度低；研发广度小、但专业度高。

中小企业测试的薪资总体比研发低，自动化等专业测试领域和研发基本无差距。大厂研发和测试薪资基本无差别。

一般来说测试比研发工作轻松，但敏捷模式下差距不大，在产品发布前测试的压力较大。

测试要求更广泛：业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分析和理   解，编程能力。

测试开发工程师的目标有两点：质量和效率。

质量是提升产品的覆盖度，以求得更高的质量；

效率是提升产品的测试效率，以求得更快的产品交付和发布上线。

为了达到以上两点，测试开发工程师会使用各类手段以达到以上目标，包括但不限于：

（3）灰盒测试 ( 搜狗内部将通过了解代码实现而进行的功能测试称之为灰盒测试 )

（4）专项性测试 ( 性能、压力、内存、耗电、流量 )

（6）代码重构 ( 谷歌的测试开发工程师会对代码进行重构，仅限于重构而不做功能性开发，目前在国内这一工作职责还没有推广起来。 )

（8）自动化解决方案……等

所以，测试开发工程师是一个编码能力很强的程序员，可以写功能代码；也是一个能力很强的测试者，可以测试任何产品，有能力管理他们自己的工作和工具。

普通的测试人员不需要有太强的编程技术，普通应用或是代码段能看懂就行。思考问题时要全面、细致、有原则，对产品敏感，不能跟着开发和产品走，这是测试人员的基本要求。

测试开发人员需要写测试工具，自动化测试代码，具备一定的开发编码能力，虽然不像开发那样深入地掌握一种编码语言，但对于脚本语言还是要有所掌握。

说到底，其实这两个职位都属于软件测试体系。只是软件测试工程师是纯粹的软件测试，执行执行用例。而软件测试开发工程师，是测试体系里面会使用测试工具，或者能开发测试工具从而提高测试效率的软件测试人员。