作者： 张振兴 　来源： 51testing   

本文的目的不是将软件测试流程优化的话题阐述的面面俱到，而是从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。

　　常闻软件测试者的如此抱怨：

　　测试用例在实际中根本没有起多大作用？

　　测试人员在实际测试时都没有按测试用例来执行？

　　测试执行后没有把需要更新的测试用例补充到用例库中？ ……

　　当前国内软件企业测试流程不规范的原因分析：

　　1） 从事物的发展规律看，软件测试行业在我国还是新兴行业，目前还处于起步和探索期，虽然国外的同行业发展到了一定阶段，但事实上他们也在不断的否定自我并探索着更成熟的方法、寻求着更有效的方案；而国内的测试行业发展期不过10来年，所谓的测试管理流程不规范，也就情有可原了。

　　2） 从企业个体角度讲，测试部门的整顿和加强，按照企业自身发展的优先层次，还没有被纳入优先解决的程度，开拓市场、签订定单才是首要问题，也是维系企业生存发展的命脉。当然国内很多优秀的大中型软件公司的测试部门相对完善，如神州数码、用友、联想等，他们和大型跨国软件公司的合作，也从中汲取了宝贵的管理经验。

　　3） 还有一个普遍存在的问题。近几年国内软件企业为了加强企业的竞争优势和名气提升，通常大搞特搞ISO/CMM认证；笔者也很支持这么做，但更关注的是通过这些认证后的企业有多少真正按照那些规范、设计的标准在后续的测试或软件开发管理工作中着手开展下去呢？社会上流传着这样的话：任何认证到中国，最后都免不了砸牌儿！笔者读书时很多高校搞的MCSE认证，有培训机构明目张胆声称"百分百通过率"！当年也有专门媒体报道此事。听到这样的话，我们都会寒心，这里真心希望我们的软件企业通过ISO/CMM后真正为企业的内部软件开发流程带来一点新生的曙光。

　　4） 最后一个原因，我想是企业内部测试管理人员和技术人员技能的不足，还有自身工作态度的不够端正。有了再好的规范标准，没人遵守不行！没人实施不行！应该说，很多中小软件企业的高层都或多或少的逐渐意识到软件测试的重要性和必要性，以及它的标准化、流程化改革的紧迫性，但也有很多的工程师、技术人员并不理会这套，常常在实际工作中投机取巧；也有很多测试管理人员后天的经验不足、技能不够，对公司测试管理工作考虑不到位，和开发工程师交流不充分，和上层领导反映不及时等等。

　　总之，任何问题的出现都不是单方面的原因，从宏观的社会形势到微观的企业个人，都有无可推卸的责任；正因为如此，解决问题也要对症下药，如何完善软件测试流程，就要从小处出发；本文不可能将软件测试流程优化的话题阐述的面面俱到，因此只从管理角度谈谈测试用例在测试活动中的重要性，以及测试用例管理流程的一些改进思路。

　　1. 强化测试用例在测试活动中的作用

　　测试用例在实际中没有起多大作用,在实际测试时根本没有按测试用例执行，测试执行后没有把新的测试用例补充到用例库中……为何如此？我们分析认为，根本原因是对测试用例重要性的认识不够，测试流程不完善，针对测试用例的管理流程更不完善，从三个方面具体来说：

　　1） 测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据，如果这个依据不能足够发挥它应起的作用，那是不是说这个依据不明确、依据设计的不合理呢？答案是肯定的！

　　2） 制定了完备有效的测试用例，为什么不按测试用例执行测试呢？首先是因为企业没有严格和良好的机制促使和保证测试执行者这样做；其次是个别测试人员投机取巧心理作祟的表现。

　　3） 测试用例设计得不可能天衣无缝，不可能完全满足软件需求的覆盖要求，测试执行过程里肯定会发现有些测试路径或数据在用例里没有体现，那么事后该将其补充到用例库里，以方便他人和后续版本的测试；如果没有这样做，那么测试部门负责人和每个测试员都难辞其疚，是该重新坐下来思考一下公司的测试用例管理规范和测试流程了。

　　2. 改进测试用例执行过程

　　那么究竟如何做，才能尽量避免上述问题呢？我们不妨从软件开发周期的每个阶段就把这些问题考虑进去，以便从初始就力争将问题缩到最小，将其扼杀在萌芽阶段，以防后期阶段出现问题时互相推卸责任或干脆束手无策！

　　1） 软件需求分析阶段，笔者从来认为测试人员从软件生命周期的需求阶段就开始介入。通常测试人员的测试工作开展在开发周期的末尾，如果前期不涉入，如何通晓整个系统的需求和架构而对其充分测试呢？虽然该观点被大多数同行所认可，但我知道依然有很多公司为了节省费用，不让测试人员参与前期调研或制定需求，经常的做法是等到系统开发完毕或将近完成，跟测试经理说一声"这边有个项目，你找几个人来测试一下吧！"经验表明，这样的做法实不可取。

　　测试人员（指项目的测试负责人和测试工程师）在需求阶段的任务有：

　　a. 参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。

　　b. 全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。 推荐企业采用类似于IBM Rational Requisitepro的需求管理工具来制定和管理软件需求，同时需要测试人员的配合，保证对软件测试环节的充分考虑。

　　2） 软件分析设计阶段，测试人员除制定测试计划书等基本工作外，笔者认为还有一个相当必要的任务，那就是将系统的可测性落实到书面文档，以备将来编写测试用例。 之所以要这么做，是因为考虑到很多企业编写测试用例直接参考需求规格说明书或者分析流程图，这样跨度大，难度也大，是造成测试用例不完备、覆盖范围小的重要原因。 如果公司采用类似于IBM Rational Rose的建模分析工具和IBM Rational Rose XDE Developer的可视化设计开发环境，这个工作更好执行；如果没有，那么测试人员更有必要编写一份《软件功能点测试描述书》，它是软件的详细测试分析文档，其主旨是将系统分析人员的开发分析文档加工成以测试为角度的功能点分析文档，重要的是描述对系统分解后每个功能点逐一的校验描述，包括何种方法测试、何种数据测试、期望测试结果等，这些信息都是描述性的，无须具体数据；它的作用是据此编写测试用例，以及测试执行时的参考依据，基于它直接来源于需求，覆盖当然最全，也最能贴近客户要求。

　　当然该文档不是非要不可，笔者只是提倡一种原则，如果有类似的替代文档或有工具可自动实现此功能，则会倍加受推崇！

　　笔者之所以推荐IBM Rational系列产品在软件项目中的应用，是因为IBM Rational倡导的RUP（Rational Unified Process）方法论采用了用例驱动的原则。所谓用例驱动，是以体系结构为中心，采用迭代、增量方式的开发过程；而其Rational工具系列正是将这一理念进行行为表述，是当前软件工程领域一套无可比拟的强大工具集，从需求到测试，它都以用例为基本模型，全面贯穿软件开发的每个环节。

　　3） 软件开发阶段，编写测试用例。我不想从技术角度探讨到底如何编写功能强大、质量优秀的测试用例（可参考笔者主页转载的"如何设计编写软件测试用例"），这里只想从管理角度和大家谈谈如何有效控制和增强测试用例在测试活动中的应用。应该遵守的原则是：

　　首先，从覆盖率来说，测试用例库的用例要达到最大覆盖软件系统的功能点。按照我上述所言的方式，测试工程师从前期阶段顺次下来，编写测试用例时，基本上就是将《软件功能点测试描述书》中的每个功能点进行操作上的细化：一是从步骤上描述到达校验点的方式，二是从内容上描述以何种数据校验功能点；如此可实现趋向最大需求覆盖率。

　　其次，从数量来讲，笔者觉得很多公司的测试用例太少，甚至远远不能覆盖系统需求，这也是很多测试人员在测试工作开展初期按照用例执行、而后渐渐凭"意念"去执行测试的原因。应该说测试用例的数量很难用数学模型来模拟，更没办法衡量，但凭借个人经验来说，一个多于半年开发周期（指从编码开始直到提交客户的时间段）的软件系统，它的用例数量不要低于4000个，甚至更多！也许有人惊讶这一数字，不过了解IBM等大公司测试过程的人士会认为4000还是很少的数目。我们试想，对于一个中小型软件系统，如果设计出5000个用例，那它的测试覆盖率还怕不高么！

　　再次，如此众多测试用例的管理问题。是的，需要管理工具软件！笔者从来都反对以word或excel来编写测试用例：

　　首先，格式上难于编写--通常方式是企业自己设计表格模版，但编辑上始终存在不便，尤其对于一些共性内容，如测试目标、测试环境、参考说明等，每次都要大量的复制、粘贴。

　　其次难于管理--如果把几千个文档文件放在一个共享文件夹里，即便以子目录方式管理，但是每次查找一个特定用例，你的眼睛也必将饱受煎熬！ 更是难于执行--莫非真要针对几千个用例都是打开一个word-执行测试-输入测试结果-关闭word吗？ 最重要的是，根本没办法追踪测试结果--在本轮回归测试输入完测试结果，但是下一轮结果输入到哪里？输入了这些测试结果什么用？能方便的根据其结果统计软件质量吗？还有，可以用它追踪发现的软件缺陷吗？有办法追踪吗？ 使用word等软件编写测试用例的种种不便大致如上，但换个思路思考一下使用集成工具的种种优势便更加一见分晓。测试同业者们都了解的测试用例管理工具便是IBM Rational TestManager，它是专业的测试用例管理和测试管理工具，其设计出发点就已经考虑到了我们上述的种种困境，因此给予了良好的解决方案。以其为测试管理平台，测试人团队成员可以计划、管理、组织、执行、评诂以及报告等纵向测试活动，如果与IBM Rational Clearquest集成使用，还可即时跟踪软件的需求变更，从而增强整个软件团队的横向沟通与合作。

　　 而且，个人觉得测试行业的快速发展，必将带来从每个环节都逐渐向自动化和标准化方向迈进，尽早适应这一趋势，不仅提高了工作效率，也提高了企业的信誉和名誉。 最后，说一下测试用例格式上一般内容以外的几个要点：

　　一、是在测试管理工具中制定适合本公司的测试用例模版

　　二、是用例模版里要有关键字索引，以方便按关键字分类查找，如测试方法（分手工/自动两种）

　　三、是测试用例要有状态跟踪，可根据用例执行状态索引用例（测试通过、测试失败、测试中断等）

　　四、是执行失败的用例要链接到相应的缺陷报告，如有根据缺陷报告检索测试用例的试图更妙，可评估该缺陷影响范围的大小

　　五、是测试用例的修改，以及每个测试周期的运行都有日志记录，以便后期追踪和新员工参考

　　4） 软件测试阶段，测试负责人划分不同的测试阶段（如集成测试、系统测试、回归测试、性能测试等），再划分不同的子测试周期（如前两个星期做冒烟测试，测试方式是手工/自动，测试版本是**，测试环境是**，包括服务器端与客户端等；接着做第一模块功能测试；如此顺次。），再为项目组测试人员分配测试用例（通常原则是每个人负责几块区域的测试任务），测试人员则按照详细的用例文档去执行测试，测试失败则提交软件缺陷报告。这里要遵循的几个原则是：

　　A）有健全且严格的体制保证测试执行者严格按照测试用例执行测试。这并不妨碍测试者创造力的发挥，因为前期用例的设计和编写就是项目全体测试人员智慧的结晶！我们一直苦苦追寻众多测试工程师加班加点辛苦工作的原因，其实大都发生这一阶段；如此实施，即便没有解决根本问题，也会大大提高测试执行效率。

　　B）如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。

　　C）测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。

　　D）测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态不断验证软件功能点。

　　E）应该提及的是，大多数软件公司都采用集成的缺陷管理工具来管理软件缺陷，如IBM Rational ClearQuest（变更管理与缺陷管理工具）等，这是值得称颂的好迹象；这样的集成工具都提供了清晰的报告模版及强大的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。

　　F）对于自动测试（包括自动化功能测试和性能、压力测试），有一些特殊要点。本人的原则是自动化测试无须编写测试用例，只要在编写时将用例库里适合或需要自动测试的用例的测试方法（不同工具可能名称不同）设为自动即可，故而到此阶段才提及自动化测试。自动化测试的实施方案有所不同，每款测试工具的使用和测试流程也不同，但都可以从在这一阶段编写测试脚本，并运行自动测试。例如IBM Rational Robot或XDE Tester（http://www-900.ibm.com/cn/software/ra ... ts/xde_tester/index.shtml，现更名为Rational Functional Tester）。针对自动化测试原则，可参阅笔者的"自动化测试要点"译文，这里要提的其他几个基本原则是：

　　一、是选择恰当的测试工具品牌，并要求提供培训；

　　二、是项目的自动化测试工作有专人负责跟踪，以保证工作质量，他们可不参与日常测试；

　　三、是确定自动化测试成员在项目中的角色，一般自动化测试成员隶属于项目测试负责人，负责人同样跟踪其工作状态；

　　四、是选择最简单、最重用的测试用例使用自动测试方法；

　　五、是使用工具厂商提供的测试框架编写脚本，千万别采用单纯录制-加校验点-回放的方式，以开发出健壮且重用性强的测试脚本；

　　六、是有专人更新脚本，也有专人跟踪自动测试结果；

　　七、是一般选择的测试工具品牌和缺陷管理工具品牌是同一厂商，以方便不同类型缺陷的集中管理；

　　八、是在多人协作开发测试脚本、代码量相对较大情况下，应考虑使用配置管理工具来管理测试脚本，IBM Rational ClearCase是当前业界功能最强大的配置管理工具，可以将开发代码和测试代码都集中管理，进行高效的版本控制和工作空间管理，保证多人开发大量代码的稳定性。对于局域网范围内的开发工作，使用ClearCase LT版足够。 由于不同公司开发产品的特殊性，也许需要特殊类型的测试，如安全测试、甚至代码级单元测试等，这些内容需要酌情考虑测试用例的编写，以及测试的执行。

　　5） 软件验收阶段，除了提交软件测试评估报告（各种类型测试结果的评估都应有报告）这些基本工作外，对于测试用例，此时要集中时间更新，更新整个测试周期中一切需要更新的内容，以方便未来新版本的测试。即便您开发的是项目软件--提交客户后没有新版本--那也需要后期维护，维护阶段需要重新测试某功能点，然而用例如果不准确，碰巧又是一个新员工来做，那就死翘翘了！ 退一步说，如果您公司的测试部门经历一次这样重大的洗礼，有一个项目真正按照此原则实施一次，也必将对未来测试工作的开展发挥推波助澜的作用、起到事半功倍的效果。

　　6） 其他说明：加强测试部门内部人员的培训教育很重要，包括工作技能与个人素质两方面，可通过国内主要的培训机构，也可是购买工具厂商的直接培训。应该说，很多测试新人对于测试用例的书写还存在问题，更别提及测试用例的管理或执行；以此可见，我们的测试工程师需要培训的空间还很大。

　　另外，笔者不赞成对人员的强制性管理，例如大张旗鼓整顿公司测试部门的管理，采取缺陷报告数和人员绩效挂钩、不按测试规范执行就适当惩罚等手段；个人认为切不可急功近利，当以人为本，鼓励+促进甚善然、甚妙哉！

　　3. 总结

　　综上所述，我们得出结论-- 测试用例在测试中没起到应有的作用，是因为测试用例编写质量不高，覆盖不够，执行不利；测试执行时不遵循测试用例，执行后不更新用例库，是测试部门的整体工作流程不健全、不规范；至于如何解决，笔者提出了微薄建议，供业界朋友参考与交流。

　　国内软件测试行业目前仍处在群雄逐鹿、百家争鸣的时期，芸芸纷说，不如从企业自身出发，确立最适合自我的测试管理解决方案，整顿自身的测试工作流程，那才是金玉良言的上上策！

　　【作者简介】 网名：Sincky，本名张振兴，是北京的一名测试工程师，擅长软件功能测试和和自动化功能测试，也从事过白盒测试、性能测试与测试管理工作，尤其对IBM Rational工具套件和RUP理论具有深入的了解和研究，多年也积累了一定测试经验和测试思想，在此分享给业界同行。

性能测试就是用来测试软件在系统中的运行性能的。 性能测试可以发生在各个测试阶段中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统的所有成分都集成到一起之后，才能检查一个系统的真正性能。



　　性能测试经常和压力测试一起进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要的在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。外部的测试设备可以监测测试执行，当出现情况（如中断）时记录下来。通过对系统的检测，测试者可以发现导致效率降低和系统故障的原因。



　　压力测试：对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。



　　性能测试：在交替进行负荷和强迫测试时常用的术语。 性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试测试有密切关系。所以压力和强度测试应该于性能测试一同进行。



　　举例说明：针对一个网站进行测试，模拟10到50个用户就是在进行常规性能测试，用户增加到1000乃至上万就变成了压力/负载测试。如果同时对系统进行大量的数据查询操作，就包含了强度测试。



　　性能测试(Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原 则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题，修复起来是非常艰难的，因为这常常意味着程序的算法不好，结构不好，或者设计有问题。因此在产品开发的开始阶段，就要考虑 到软件的性能问题。



　　压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和 性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况, 如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以)。



　　压力测试和性能的测试的区别是在于他们不同的测试目的



　　压力测试是为了发现系统能支持的最大负载，他的前提是要求系统性能处在可以接受的范围内，比如经常规定的叶面3秒钟内响应。



　　所以一句话概括就是：在性能可以接受的前提下，测试系统可以支持的最大负载。



　　性能测试是为了检查系统的反映，运行速度等性能指标，他的前提是要求在一定负载下，如检查一个网站在100人同时在线的情况下的性能指标，每个用户是否都还可以正常的完成操作等。



　　概括就是：在不同负载下（负载一定）时，通过一些系统参数（如反应时间等）检查系统的运行情况；



　　比如我们说某个网站的性能差，严格上应该说‘在N人同时在线情况下，这个站点性能很差）。



　　总之，就像一个方程式：综合性能=压力数*性能指数， 综合性能是固定的， 压力测试是为了得到性能指数最小时候（可以接受的最小指数）最大的压力数；性能测试是为了得到压力数确定下的性能指数。

“什么叫成熟产品？只要有一个成功案例的产品就是成熟产品！”某国内大型软件公司CEO的这个经典观点广为流传，但其中的逻辑错误将风险带给了客户也带给了软件企业本身。国内一些软件企业居然一夜间成了万能公司，ERP ？ CRM ？OA？WorkFlow？我们都行！然而这些企业对软件测试的重要性大多认识不足，重开发轻测试的现象过于严重，很多公司没有专门的测试部门，测试工程师太少，开发人员兼作测试工作的现象十分普遍，在这种状况下推出的缺少严格测试等环节的软件产品只能给客户带来悲剧。

　　近年来，我国的软件企业已越来越意识到软件测试的重要性，逐渐加大软件测试在整个软件开发的系统工程中的比重。据调查统计，在成本上一般来说是“需求分析”和“规划确定”各占3%，“设计”占5%，“编程”占7%，“测试”占15%，“投产和维护”占67%.近些年来，测试成本的比例更有上升趋势 .

　　不成熟软件带来的风险

　　不成熟的软件产品是把测试成本交给了用户：企业往往是出于项目周期安排不当，或者根本没有安排专门测试，匆匆完成编码设计就将产品交付使用了。这样的后果自然是用户觉得产品漏洞百出，项目执行过程也遥遥无期，最后，项目双方都筋疲力尽，用户觉得受骗，而软件商则毁了声誉，追加了大量项目实施费用，可谓是“赔了夫人又折兵”。

　　企业逻辑的软件实现高于计算机技术：很多软件企业在没有做透前期调研的前提下就匆匆开始建设自己想象中的“大厦”，结果可想而知。当用户建立起真正的企业应用。才发现软件违背了企业逻辑，不得不进行修改。这样闭门造车无疑会给“大厦”带来致命伤害。

　　注重软件产品的质量和成熟度才会良性循环：有人把不成熟的软件产品比作是焦油坑中垂死挣扎的猛兽，布鲁克斯《人月神话》展示的可怕一幕在软件研发过程中屡见不鲜。很多软件企业常常将软件质量视为一种奢侈，如果有必要的话，为了更多功能、更快速开发或者更低成本，测试就可以被牺牲掉。然而，在实践中，如果软件开发组织对质量有一个坚定承诺，实际上可以加快开发，减少成本，并更容易地增加新的特性。在“已完成”的产品缺陷修复上花费的代价要比从一开始就修复高出很多倍。相反，一个从开始就加强产品质量的组织，是有远见和创新精神的，市场中的高质量软件将更具竞争力。

　　找出测试管理中的误区

　　笔者曾经从事专业的软件项目管理与实施，项目管理感受很深刻。有一些切身体会与读者分享。

　　吸取“前辈”经验。IBM在软件自动化测试技术核心的三个最佳成功经验是：尽早测试、连续测试、自动化测试，并在此基础上提供了完整的软件测试流程和一整套的软件自动化测试工具，组建一个测试团队，基于一套完整的软件测试流程，使用一套完整的自动化软件测试工具，完成全方位的软件质量验证。

　　别去“挖东墙补西墙”。由于项目研发期的“缺斤短两”，使项目实施和投入运行的初期 漏洞百出，时间一长用户会发疯，项目实施者也会发疯，国内前几年的众多的ERP项目失败的原因多出于此。项目实施的遥遥无期，将严重挫伤用户的耐性和信心。

　　代码与文档哪个值钱？多数项目管理者忽视了文档的重要性。对于大型软件的研发项目，还需要专业的测试过程管理软件来支撑大规模的信息交流和自动测试、代码的更新和版本的提交。这些文档和信息的价值从某种意义上甚至超出了程序代码本身。

　　全程还是后期？软件的设计阶段往往没有软件测试人员的参与，事实上设计上的缺陷往往是耗用成本最高，也是最难在开发后期修复的缺陷。而一个软件的质量与它有多大的设计缺陷有着密不可分的联系。而有经验的测试人员的质量意识，安全意识，对用户需求的了解及分析能力，对于打造高品质的软件设计都有着不可忽视的作用。

　　专职还是兼职？在传统的开发方式中，由于缺乏必要的配置管理和变更控制，测试工作根本无法提出具体的测试要求，加之开发人员的遮丑，测试工作往往是走走过场，测试结果既无法考核又无法量化，当然就无法对以后的开发工作起指导作用。事实上，每个软件项目都需要专业的测试人员进行相对独立的测试工作，从而保证软件项目的质量。

　　居安思危，控制风险。需求变更给测试带来的问题可能是灾难性的，客户需求不是变动的唯一来源。有时团队自身也能引起范围变动。团队的成员可能听说或“假设”解决方案因客户的实际要求而发生了变动。加强沟通和协作，随时了解变更的状态。

　　谁为产品质量买单？质量和质量控制应该是软件项目的的一项重要内容。但是，无论在消费类软件还是大型软件的测试领域，国内软件产品的质量掌控体系和标准都很模糊。质量控制越来越依托于公司在产品交付用户之前的测试工作的成败。

　　没有厚度就没有重心。软件测试过程的历史数据缺失是大多数软件项目失败的关键所在，这样的结论也许使很多人感到吃惊，但事实就是如此。因为这些历史数据是反映软件项目实施轨迹的第一手资料，是项目延续和反馈的基石。

　　省钱还是费钱？事实上，作为软件开发企业来说，投入人力，资金搞软件测试的最终目的还是离不开经济效益。而对与测试项目的管理也不能离开这个大前提。软件测试的经济效益主要来自以下两个方面。一是满足用户需求，提高产品的竞争力，最终提高产品的销售量。二是尽早发现缺陷，降低售后服务成本。而软件测试的最终目的就是使它带来的经济效益最大化。有一些专业的测试工具的购买、测试人员的配备和培训还需要一定的经济投入，项目决策者们可以选择适合自己的配置，但决不能没有这些方面的投入。

　　沟通还是对立？沟通是开发和测试人员必备的素质。但传统的思想认为，测试人员是找麻烦，是开发的“克星”。其实，项目管理者应该清楚，为软件的质量和品质努力的工作目标是一致的。沟通和建立沟通渠道是项目管理者的重要工作。

　　如何提高软件测试水平

　　要提高我国的软件测试行业的发展水平，首当其冲要解决软件测试队伍的问题。某著名国际软件企业的软件测试人员与软件开发人员的比率达到了3：5左右，并且在实践过程已经证明了这种人员结构的合理性。但国内公司显然一时很难达到，但更重要的是重视程度，在这个基础上壮大软件测试队伍，提高测试人员的素质。

　　其次是要学习借鉴国外完善的测试机制，包括丰富的软件测试经验，强大的测试工具，优秀的测试管理水平。真正解决测试手段落后、测试方法单一和测试工具欠缺的问题，在企业内部形成一个严密有效的纠错系统，使国内的测试工作流程、 技术水平接近国外先进水平，这样才能提高国内软件开发与测试的整体管理水平，增加软件产品的竞争力。

　　此外，要重视第三方的测试力量。第三方的专业测试企业是靠技术与服务来赢得客户信任的，也因此更加注重测试方法与质量。对于软件企业来说，从无到有地去建立测试部门，并完善测试体系，需要较大投入，将研发出来的软件产品交给实力强劲的第三方专业测试公司，在提高软件产品的质量问题同时，还节约了产品测试成本。

相信很多团队都有这个问题：编码人员和测试人员经常争论。测试人员说编码人员做的东西太烂，问题太多，缺乏规范，开发文档也没有；编码人员说测试人员责任心有问题，测完了还是令自己不放心；还有很多人认为“如果发布出去的软件有问题，就是测试人员的责任”，理由是“测试人员应该在发布之前把所有问题都找出来” 【1】。

为什么会这样？我们来简单剖析。

首先，我们先要叙述一条“公理”：任何人都不能保证其工作成果总是100％完美的。即任何人都不能做到“0缺陷”。

因此，任何一个开发团队做完了都必须经过测试，尽可能的发现潜在问题并修复后才能发布出去。所以，测试人员必须竭尽所能发现缺陷。注意了，基于上述“公理”，任何测试人员都不能保证把软件中的潜在问题100％的找出来[参见《体检报告中的“未见异常”和软件测试》]。这样说来，上述【1】的说法是有失公允的。

那为什么会争吵呢？第一，出了问题的时候编码人员和测试人员是直接责任人，并且要负责解决问题，因此很容易引起情绪上的冲动；而且多数人遇到责任归咎的时候会本能的为自己开脱。第二、大家都忽略了“任何人都不能0缺陷”的公理。

但是，这并不表示有了这个“公理”，所有人就可以心安理得的面对所有缺陷了。任何产品的主要竞争力最终来自质量。因此对质量的无限追求，是任何团队的要求。也就是说，虽然我们不能要求每个团队的工作成果100％完美、0缺陷，但是我们总期望我们的成果能够尽量趋于完美，比如99.9997％，所谓的“六西格玛”。

怎么样做到尽量趋近于完美？这可能受到多种因素的影响，比如团队的工作能力、工作态度以及项目客观因素；还有管理、过程、工具，等等；可能会有很多！但是，我们可以简单归结为所有参与者工作成果的近乎100％的完美！所以，不要争论，从自己这里开始找原因，去改进！