浅谈在软件开发中的开发与测试

我们知道开发人员与测试人员在某种程度上可以说是冤家对头，因为开发总是认为我做的产品是完美无缺的，没有Bug的，但是测试总是想方设法给你挑刺，因而产生了“矛盾”。很多公司对开发的绩效评估里就有一条是每千行代码产生的Bug量，当然是越少越好了，但是对于测试的绩效评估也有一条平均每天提交的Bug量，所以表明上看起来这种矛盾真的是无法避免的，因为大家都要“混饭”吃的。

但是大家其实心里都很清楚，一个产品不可能没有Bug的，或多或少，或大或小，总是会有Bug存在，不然微软也不会这样经常发布补丁了，连微软这种级别的公司都会Bug，所以对于Bug的存在，我们大可以泰然处之。

虽然可以泰然处之，但是对于Bug我们还是需要很重视，因为既然产生Bug，总是某一方面没有想到或者是想错了，所以我是建议可以通过对Bug分布进行分析，找出哪些地方特别容易出Bug，然后在开发过程中特别注意。对于我们公司而言，之前说过了我们是用TechExcel DevSuite 系统来管理，所以我们在开发中会加入几个强制检查项，比如说是否兼容不同数据库，是否支持不同语言，是否考虑过不同浏览器，开发在完成代码如果不检查这几项的话，是无法把开发任务直接交给测试来测的，这样就可以从某种程度上避免一些Bug的产生。

不过即使避免了总还是会有一些Bug会被找到的，呵呵，没有Bug还要测试干嘛呀？在很多公司里测试人员的数量都大于开发人员的，像微软这种公司，可能是2：1的关系，为什么需要这么多测试呢？

第一方面，当然是他们的产品太大了，太复杂了

第二方面，一个产品的质量光靠开发是不行的，因为开发虽然能把产品做出来，也可能可以用，但是他们可能没法考虑其他一些方面，比如用户体验上，比如压力测试上，比如不同语言下的应用，甚至是不同操作系统下的应用等等，这些方面光靠开发可能没法想全，甚至即使想全了也做了，你能保证在哪些环境就一定不出问题吗，毕竟开发编程总是在一个环境下的编的，他编完即使自己测了一下也不可能把所有环境下都测过的。

第三方面，因为一个产品/一个功能需要在很多外在环境下测试（操作系统，数据库，浏览器，网络），另外一个功能需要测试点又很多（正常输入，非正常输入，临界，压力值等），所以即使是一个功能，需要测试的地方就很多，何况产品大功能多的了。而且，我们知道一个人再强，他能想到的测试点总是有限的，所以我还需要另外的人对一个已经测过的功能点进行再次验证测试 （关于这个方面，由于我们公司是用DevSuite 方案中的 DevTest 工具来管理测试覆盖面的，所以稍微可以减少一些测试人员配置）。另外对于一个开发来讲，由于功能点是他做的，所以别人发现了问题让他修，其实他是可以修起来很快，代码都轻车熟路的，所以如果一个测试配一个开发的话，可能发现的Bug量无法让开发完全忙起来，从领导角度说这个比较浪费成本的。

所以考虑到这些原因，一般大公司就会有很多的测试人员了，当然现在的情况又有不少改变了，随着自动化测试的引入，需要人工的地方会相对减少，所以有不少公司开始减少纯手工测试的活，但是做过开发的人也知道，如果一个产品很复杂，光靠自动化测试是远远不够的，所以呢，我相信手工测试还会在很长时间内存在，至少在我能看到的范围呢，好像还没法用自动化测试来代替。

不过在国内的话，我接触到的大多数软件公司里，对测试人员的配置都不太多，当然我不认为他们是忽视软件质量，他们可能认为功能做出来了，开发直接测一下就好了，测试人员的话只要最后综合跑一下就Ok了。我相信这个是怎么保证软件质量的一种认知的观念问题，我认为这样就可以保证产品质量，你认为那样才可以保证质量，大家各有说法，但是从我们公司的角度来说，我们还是比较看重质量的，可能也跟我们公司背景有关吧，外企，跟国外比较接轨。所以我们公司现在的开发与测试配置是大于1：1的，不过比微软还是差一点。

介绍了一下测试的必要性，再回过头来继续说开发与测试的“矛盾”，其实这个矛盾从本质上来说是由于绩效管理时过分强调了开发人员造成的Bug，而这个“过分强调”又必须是测试人员一定要强调的。所以呢，矛盾就开始产生了，开发说，这个不是Bug，或者说我不能重现，还说，你干嘛老是提Bug，是不是对我有啥不满的。久而久之，“矛盾”产生了，激化了，产品质量下降了......从领导层角度来说，他们当然也希望开发做出来产品是没有Bug的，这样子我连测试人员都不用配了，成本下降很多了。当然，大多数领导也知道这个是不可能的，与其由于产品质量下降造成产品不好卖，还不如配几个测试人员了。配了测试人员，又出现“矛盾”了，我想许多公司的领导已经处理得很好了，不过我还是想简单介绍一下我们公司的处理方案：

1、把产品的销售业绩与开发、测试绑定，也就是说销售得好，奖金就多，当然要销售得好，产品质量也得好，那就得开发与测试相互合作了。现在许多公司其实开发与测试工资与奖金比较固定，不会因为业绩好而增加奖金之类的。我们公司有明确规定，这个产品利润的百分之几是归开发，百分之几归测试，从而从制度上就让开发与测试有了定心丸，去好好把产品质量搞好。

2、在对于各个销售人员的绩效考核上，增加其他考核项，把每千行Bug的产生量权重降低，增加诸如，Bug修复成功率，类似功能再次出现Bug的百分比，与测试人员合作效率等考核项，这样子的话，开发人员就会开始很重视和测试人员的交流，因为他们开始知道跟测试人员的合作好坏决定了他们能拿到的Money。（刚才有人问怎么拿到这些类似Bug 修复成功率这种值，一般好一点的 Bug 管理工具里都能拿到，我们在 DevSuite 系统里自动生成的）

3、当然对测试人员也需要增加一些新的考核项，比如是Bug的描述是否能让开发一次看清楚等。

通过这些措施，开发与测试的效率提高很多，从而使得产品质量也提高很多。哲学上说，矛盾是事物发展的动力，学会利用这种矛盾来让公司健康稳健地发展是每个成功公司需要学会的，我们公司现在来说不能算特别成功，但是我们在这个方向上前进着。

后序：有个朋友评论说：（以下是原话）

软件测试部门是辅助软件开发部门将产品做好！

他们不是对立的关系，而是互相帮助的关系。

现实中，经常看到研发部门看不起测试部门，而测试部门则叫板研发部门，说产品存在如何多的问题。。。

牢记产品是做出来的，不是测试出来！

测试团队一定要摆正自己的位置，是协助研发团队将产品做好，提高产品质量！发现问题，跟踪解决问题！一定不要将与研发人员的关系搞僵！

时刻牢记：大家是一个团队！大家有一个共同的目标：将产品做好！开发与测试应该认识到大家是一个团队，一个整体，只有紧密合作才能把产品做好出来。

其实大方向我还是比较认同的，确实，开发和测试需要紧密合作，发挥团队精神才能把产品做好，这样子产品才能有机会卖好，公司也才能发展，所以这个朋友评论的话，我觉得可以认为是一种理想的开发与测试关系。但是要实现这个理想的关系，光靠这两个部门自身是无法彻底实现的，我们需要在整个公司层面制定合理的制度，从根本上解决问题。假设我给开发的考核中代码质量（也就是每千行出得Bug数）权重很大，而给测试人员考核时每日发现Bug数权重很大，势必会造成开发与测试之间的某种矛盾加剧，其实他们也知道要合作，不能有矛盾，但是自己是出来打工的，你给我提这么多Bug，我钱就会少拿；我不给你提这么多Bug，我钱也少拿。 所以我写这篇文章的目的，其实是怎么让开发与测试达到一个理想的关系，而不是说开发与测试应该达到一个怎么样的关系。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/

Qt+MySql开发笔记：Qt5.9.3的msvc2017x64版本编译MySql8.0.16版本驱动并Demo连接数据库测试 mysql驱动版本msvc2015x32版本调好， mysql的mingw32版本的驱动上一个版本编译并测试好，有些三方库最低支持vs2017，所以只能使用msvc2017x64，基于Qt5.9.3，于是本篇编译mysql驱动的msvc2017x64版本，满足当前的特定需求，这次过程有点费劲，可能是Qt的版本低于Qt5.12，继续无保留分享出来。   本篇主要描述Qt5.9.3 msvc2017x64 + mysql8.0.16的驱动编译过程。
Qt+MySql开发笔记：Qt5.9.3的mingw32版本编译MySql8版本驱动并Demo连接数据库测试 之前特定的mysql版本msvc版本已经调通了，但是为了更好的跨平台，所以选择用mingw32版本，于是需要编译mysql驱动的mingw32版本的驱动库，以便提供给qt连接mysql使用。
区块链交易所搭建开发_平台_测试_系统智能合约ATOM代示例 Cosmos（ATOM）没有传统意义上的原生智能合约，因为它没有自己的图灵完备编程语言。 相反，Cosmos 使用区块链间通信 (IBC) 协议来允许不同区块链之间的通信和价值转移。 这允许开发人员构建跨越多个区块链的去中心化应用程序。
【C#】 MVC4 开发小程序-实现人脸识别-本地和手机预览使用IP测试 小程序Camera组件拍照上传图片到指定的服务器（本地或者外网的IP服务器），然后C# MVC后台调用百度人脸识别接口，实现人脸识别功能呢