把我几年前写的“企业如何预防软件缺陷，结合我自己的经验谈谈：软件企业如何提高自己的产品质量
一：软件开发的源头—需求
问题：笔者自己亲身的经历的一个项目《昆山地税短信业务系统》，用户确实也在项目的需求规格说明书上签了字，但是最后做出的东西，尽管实现了需求规格说明书中的功能，但是却是用户不想要的。
遇到这样的情况，我认为最重要的是要做到以下几点：
■ 第一要做到：根据需求开发一个Demo,让测试人员尤其是用户来确认，因为国内的很多用户不会提出需求，但是等开发商做好了软件之后，用户根据你目前所做的软件（依照现有的界面或者功能情况，然后再结合自己的业务）他们就会提出新需求了，在这方面我深有体会。所以有问题，有不明白的地方让用户早提出来，否则弄到最后大家都很被动。
■ 第二要做到：其次，在开发期间，还可以邀请客户参与软件设计规格说明书、测试计划、测试用例等的评审，当软件能基本正常工作时再次邀请客户从头到尾再看一遍（product work-through）。最后，就是开发人员和测试人员做好自己的本质工作，构建高质量的软件，进行充分的测试（但是如果客户或者用户没有足够的时间评审你的设计规格说明书、测试计划、测试用例，但是至少要能做到在软件基本上能工作的时候，把软件放在用户能够使用的地方，让用户亲自试用，因为用户对业务的了解远远比开发人员好，他们能在早期发现该软件中一些不利于用户使用的地方）。
■ 第三点要做到：重点评审需求中不明确的功能模块和存在分歧的模块，对于不明白的地方一定要弄懂，因为需求是软件开发的源头。
■ 第四点要做到：对于一些重点模块和用户业务常用的模块，要重点评审，比如说笔者前做无线POS机的系统，“销售”这个功能当然是重重之重了（因为对于零售商来说，如果软件的功能上的问题，而导致不能“销售”，那么用户对于花了钱买了这样的软件部室暴跳如雷吗？）。
二：做好单元测试，目前国内很多软件企业根本没有一个单元测试的标准
■ 笔者的亲身经历1：上海某软件外包公司的开发人员曾经私下讨论说：这个功能可能有问题，让测试人员以后去发现吧。有这样的心态开发出的软件按怎么可能没有bug，如果没有bug那就真是怪事了。
■ 笔者的亲身经历2：笔者所在的软件公司曾经为loreal做的无线pos机器（终端和服务器端居然没联通,也就是说开发人员联调都没有通过，这样的软件你敢保证没有问题吗？）
比如：SAP的单元测试做法如下：
■ 自我测试，要求开发人员在完成自已负责的模块后，马上进行测试，消除模块内部的错误 。
■ 相互测试，要求开发人员之间测试对方的模块，由于不同开发人员的思维、开发方式的不同，对方会很容易找到一些自已很难发现的问题 。
■ 代码检查，通常是由资深开发人员及开发经理来进行，从模块功能、性能、可用性、编码规范、模块集成性等角度进行全面检查。这一工作会在系统实现的各个阶段定期进行。SAP还提供了如CATT等辅助测试工具。
三：通过软件测试来提高软件的质量
（1） 测试人员最好能做到交叉测试，因为测试人员毕竟考虑问题产生思维定势，能做到交叉测试，最好了。
（2） 测试经理在测试人员的安排上，要注意以下几点：
■ 不要安排新手测试已经快要结束的项目
■ 安排好的测试人员测试水平较差的开发人员的代码
■ 安排经验较差的测试人员测试水平好的测试人员的代码
（3） 要尽可能模拟用户的真实使用环境，进行测试
笔者以前做过一个加密软件，用户反馈回来的一个问题，在公司内部环境下总是重新不了，最后才发现用户服务器的使用环境是windows2003 server打了补丁，而在公司的测试环境中虽然使用的也是windows2003 server但是没打补丁，因为环境不一致，导致在用户那里出问题了。
（4） 在系统测试阶段要弄到用户的真实数据进行测试
因为有一些Bug，只有用用户的真实数据才能测试出来，测试人员自己造一些数据是测试不出来的。这一点我在测试欧莱雅（中国）系统的时候深有体会，比如欧莱雅的会员数据系统，欧莱雅的会员成千上万，千奇百怪。
（5）要尽早做好性能测试（有可能能在早期发现一些设计上的重大问题）
比如：数据库设计方面的错误，这样的问题要早发现，如果在后期发现补救的可能性非常小。笔者以前从事过的一个系统，设计人员在设计的时候，把销售、入库、订货、会员、退库、退货这么多的业务同时放在这一张表上来操作，当在大用户量并发的情况下，很容易使数据库出现死锁等情况。
（6）测试的核心---测试用例的设计
测试人员在设计测试用例的时候，要结合用户的实际使用情况：
■ 用户是这样操作软件的吗？这样的操作符合用户习惯吗？
■ 测试用例覆盖了所有的用户需求吗？
■ 用户有非正常的操作步骤吗？比如：软件在突然断电情况下，比如在输入手机号码的位置，输入汉字，来检验程序的容错性和健壮性
（7）测试人员要多看服务器端的日志
无论是测试B/S或者C/S结构的软件，无论是在做功能测试还是做性能测试的时候一定要多看服务器端的日志文件。
■ 笔者的亲身经历1：比如查看IIS日志，tomcat日志，在日志当中你会发现很多你想要的东西，比如软件的一些潜在的错误，其实在日志当中是可以看出来的。
■ 笔者的亲身经历2：比如在欧莱雅（中国）的service.exe程序的时候，当时测试人员忽略了看日志文件信息，导致欧莱雅的服务器平均每隔2-3天重新启动--这是一个很严重的问题，但是如果早期测试人员如果多看日志的话，就能发现一些文件打开没有关闭导致内存泄漏方面的问题。
（8）软件测试注意的事项-测试人员如何迅速找出问题的经验
■ 首先测试经过变更（修改的功能）的部分，然后测试没有变化的部分。修改和更新都意味着新的风险。
■ 首先测试核心功能，然后测试辅助功能，测试产品所完成的关键和常用功能，测试完产品基本任务的功能（比如笔者近期测试点法院审判软件，首先一定要保证整个审判的流程能跑通）。
■ 首先测试能力，然后测试可靠。先测试每个功能是否完全能用，然后在深入检查任何一个功能在很多条件不同条件下的表现如何。
■ 首先测试常见情况，然后测试少见情况。使用常用的数据和使用场景。
■ 首先测试常见威胁，然后测试罕见威胁。用最有可能出现的压力和错误情况进行测试。
■ 首先测试影响大的问题，然后测试影响小的问题。测试在失效的情况下会产生大量破坏的产品部件
■ 首先测试最需要的部分，然后测试没有要求的部分。测试对团队其他人有重要意义的任何部分的任何问题
（9）测试人员一定要熟悉公司相关的业务
■ 比如我以前做欧莱雅无线POS销售系统测试的时候，其中有个测试人员做的就很好：因为这个测试人员的优点是非常熟悉销售、促销、羽西会员，薇姿会员的业务等。另外，比如测试ERP软件的测试人员，肯定要对ERP的运作模式很熟悉，才有可能找出软件的缺陷，尤其是业务上的软件缺陷才是有价值的缺陷。
■ 如果这点做不到，那么测试人员找出的软件缺陷肯定是纯软件的缺陷，价值不大。
■ 做为测试经理，你一定要求你的项目组中的至少1-2个成员对公司的产品很熟悉。
四：提高软件质量的另一个重要手段：评审
首先众所周知：测试时保证软件质量的一个重要手段；但同时想提高软件软件仅仅依靠软件测试是肯定不够的，软件开发商可以增加各个阶段的评审，比如：
需求评审，测试计划的评审，测试用例的评审，设计文档的评审，代码的评审，最后发布产品阶段的评审等等。
举例代码的评审效果就很好：
■ 笔者以前所在的公司开发了个报表，中间有个会员更新的功能，当时一个刚入门的开发人员，是这样实现系统：比如先把会员的第一个字段比如“姓名“，先update,然后再重新insert数据库；然后第二个字段比如“电话”先update,然后再重新insert数据库；然后再依次下去，这样的执行效率当然是低下的。
当然了，后来这个问题，在做代码评审的过程中，被项目组的其他程序人员发现了。也就是说这样的软件缺陷不一定非要等项目后期由测试人员来发现这样的问题。
五：给开发人员的建议：
■ 不要频繁的拷贝代码，这样很容易注入缺陷到你的代码中
■ 不要认为公司里已经有了测试人员，所以我不需要对代码精雕细琢，甚至可以马虎一点；如果开发人员真的抱有这样的心态的话，那么有测试团队的公司在软件的质量效果上肯定不如没有测试人员，但是每个开发人员都对自己的代码尽职、尽责。
六：给测试人员的建议：
测试人员应当把下面二句话作为自己的座右铭：
■ 每个测试人员都应该把“尽早测试，经常测试”（Test early and test often ）。
■ 测试人员永远记住一句话：不要让程序开发人员对你说：“用户不会进行这样的操作”为理由，拒绝修改Bug。因为，如果，你遗漏掉这个Bug，你将直接面对的是用户的的指责。
金朝阳
