项目开发中的测试

 

         开发过程中需要做多少的测试才是足够的呢？我想要是没有标准，做再多的测试也是不够的，在测试的广度和深度上都要有个折中，在不同的阶段要有不同的重点，开发人员和测试人员要分工合作，发挥各自的优势。

 

          对开发人员来说，对代码相对更熟悉一些，虽然在项目开发中有不同的分工，开发在测试出一个 bug 并修复的成本比测试人员测试出一个 bug 并报告给开发去修复要低得多，所以我们提倡开发人员做尽量多的测试，尽量把 bug 消灭在萌芽中，听说在 google 中的开发 / 测试 =10:1 ，不知道是否属实，他们的开发人员要做很多测试的工作，开发人员提交给测试人员的代码是要保证一定质量的，不然测试人员是不会接收的。又听说微软的开发 / 测试 =1:1 ，他们的测试要为开发做许多事情。一般的软件公司一般不会像 google 或是微软那样极端，可能介于二者之间，我们公司的开发，测试比例大约是 4:1 。

 

         无论是开发，测试的比例是多少，目的都只有一个，就是把软件整稳定，并不需要分得太清楚开发为测试做测试，或是测试为开发写代码。开发和测试在项目开发过程 中是相辅相成的，开发在写好代码的同时尽量多做测试，做深入的测试，对不确定，不放心的模块多做测试，而测试人员尽量能对系统做全面的测试考虑，不放过任 何一个功能点。我的观点就是，开发深入测试的同时兼顾全面，测试在全面测试的同时兼顾深入。

 

         无论是开发或是测试，项目时间都是很紧张的，交流不畅将会影响到项目的进度，特别是开发和测试泾渭分明的公司中，交流显得特别重要，测试如何给开发描述遇到 的问题，怎样向开发询问一些实现的技术细节，开发如何向测试询问测试场景细节，解释技术实现细节，这里面设计到不少的交流细节和艺术。我的观点就是交流必 须及时，当发现了问题，请尽快找到能解答这个问题的人询问，无论是直接去找他或是马上拿起电话拨通对方的号码，立即行动，即使问了个白痴的问题又何妨，大 家都是在错误中成长过来的嘛。

 

         大家每天都很忙，真的很忙，开发忙着修 bug ， 测试忙着测试，那我们什么时候思考呢，任何时候都可以思考，任何时候做事都要先思考，无论是开发或是测试遇到问题，都要首先多问几个为什么，试图通过自己 的独立思考解决，不光要知道怎么做，为什么要这么做同样重要。比如我以前一直认为在项目开发中随便一点，开放一点好，为什么要遵循那么多繁琐的项目开发流 程呢，每个项目组都有自己的特点，也未必见得那种开发模式完全适合自己的开发团队。正是由于这样的想法，个人的思想和行为都比较自由，提交未 review 的代码，在系统测试中发现的 bug 直接联系相关人员调试修改，不走正规的 bug 上报修复流程，这样查找 bug 或是修复 bug 还真的比较快，但这样却不便于项目管理，所做的事情没有记录备案，谁知道你今天做了什么，谁知道系统以前曾经出现过的这个 bug 是否真的修复了。遵守项目约定的开发测试规则，磨刀不误砍柴工，不以规矩，不成方圆。

 

        每天都要项目例会，每个人都要在例会上回报今天的工作，这也是 scrum 开 发流程中必不可少的一个环节，如果这个环节组织得好的话，将大大提高项目组成员的交流效率，同时也是展现个人成绩的一个平台，应该好好的利用。我以前不太 注重这个会议，比较随便，自己每天忙死忙活，但缺乏展现，自己做过的，已经做好的，却没有表达出来。所以我逐渐重视日常会议，在会前准备几分钟，整理一下 今天做的事情，在会上表现得积极点。另外暂时做得不过好的地方就是不太习惯做笔记，以后要在工作中养成多记笔记的习惯。

 

        最近，经过几个月开发的项目进入全面测试阶段，开发已经在开发的同时做了不少的单元测试和模块压力测试，在系统联调时还算比较顺利的让系统运行起来，我们的测试主要负责整个系统的黑盒测试，由于他们前期跟开发这边接触得不多，所以测试那边进展比较慢，每天测试不出几个 bug ，没有测试出 bug ，但不代表系统 bug 少，也许只是测试人员暂时还不很熟悉系统，等到系统上线前夕，测试对系统有了更多的了解，会测试出许多严重的 bug ，将导致系统推迟上线。鉴于这个问题，开发这边不是对系统更了解一些吗，于是我最近抽空写了一个系统的压力测试工具，这个工具能测试 T 级别的数据量，千亿级别的操作，数据一致性验证，该工具已经基本能运行，短短一两天，就发现数个 bug ，从而让我们对系统更放心一点，测不出 bug 的系统最让人揪心了。我相信在未来的几天，这个压力测试工具将发挥更大的作用，测试出更多的 bug 。