１．引言
随着软件技术的迅猛发展，软件的质量愈来愈受到广泛的重视。而测试又是保证软件质量的重要手段。根据IEEE/ANSI标准，软件测试的定义是："使用为发现错误所选择的输入和状态的组合而执行代码的过程"。这就非常明确地提出了软件测试是以发现错误，检验是否满足需求为目标。软件测试在软件生命周期中占有非常突出的重要地位，是保证软件质量的重要手段。根据Boehm的统计，软件开发总成本中，用在测试上的开销要占40%到50%。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误，以提高软件的质量。现代的软件测试不仅仅是在软件开发完成以后来做测试工作，而是将测试渗入到软件开发的各个阶段，而且提高自动化软件测试手段，来提高测试效率。
有些项目的主持人，认为以尽快的速度把测试之前的所有开发阶段完成（实际并没有完成），早日开始测试，以图达到快速和高质量（因为似乎有更长的时间可用于测试）。实际的效果将会是俗语所说的"欲速则不达"。从常识就可以知道，花开发时间去继续扩大发展前面阶段引入的错误，得出的只能是更大量的需要耗时修正的错误。因此，正确分析与利用测试的结果，我们可以非常有效地进行软件过程改进。
2．完善测试过程策略
2.1 双效合一，不断进步
公司的管理层和质量控制小组通常进行软件过程的改善，并编写出了一系列的企业的标准与规范，经过一系列的评审、培训，然后让开发人员去执行。但是在执行过程中常常碰到阻力，多数是来自于开发人员，除了紧张的开发工作，他们往往会抱怨又多出许多其它工作，比如按照一定的规范的文档的撰写；制定的企业开发规范不符合企业的实际情况，标准太高，无法达到。这一种做法，费时费力不讨好，大家的意见都比较大，规范定的比较完美，而且在评审时还要大家表面上都要认可，制定规范的人花费了很大的精力，对规范的评审浪费了大家的很多的时间，执行时还难以贯彻下去。这种方式肯定收效甚微。这是一种效率比较低的做法。
通常，还会有另外一种做法：降低要求，暂时抛弃各种标准与规范，采用一种简单易行的策略，即由质量控制小组找开发人员、项目经理让他们自我发现问题：你有什么缺点？你将如何改进？在开发人员、项目管理人员讲自己的改进措施后，让他们确保能做到。在这种办法中，不需要管理人员花费太多的精力进行标准的制定，改进的推动，这些工作都是由开发人员自己去做的，管理人员仅仅是起到了监督的作用，只要开发人员自己说到做到就可以了。但是，我们做了一个尝试，如果仅仅从开发人员的角度出发制定标准，每个人的习惯不同，开发人员往往倾向于按照平日自己的编程习惯制定符合自己需要的规范，这样做的随意性比较大，难以形成统一的、正规的文档体系结构。而且，开发人员往往利用这一点，给自己留有充分的弹性。往往自己制定的规范都有自己不同的解决办法，这样会造成编程风格的不统一。既然是规范，总得有一定的强制性，而如果单单从下而上，放权给开发人员，实施的过程中可能会发生更大的问题。
综上所述，我们就采取了一个折中的办法，即，根据开发人员的要求，先拟订一份开发规范，然后提交给开发人员或者项目管理人员评审。允许他们提出自己的意见，如果意见合理，可以对规范实施修改。举例来说，假设公司原来的文档体系中本身有一套编程规范，但是在实际开发的时候，其中的某些规则不是很实用，所以，公司就根据每个项目组所使用的开发工具和语言的不同，制定不同的编程标准，而这些编程标准的修改意见，基本上来自于开发人员，但是是经过公司的管理人员和质量控制部审核过的。
这种做法的好处就是可以主动提高公司全体员工的质量意识。对于高层管理人员而言，所有的规范都是经过他们审核批准的，他们起到监督作用；对于开发人员而言，很多规则是他们提出的，他们会自觉遵守。这样双管齐下，双效合一，不仅会大大提高软件的质量，而且不用将发现错误的责任全部推给测试人员，而是提前预防错误、减少潜在危险的发生、减轻测试人员负担、培养开发人员良好的编程习惯。
2.2 重视文档，需要技巧
软件文档也称文件，通常指的是一些记录的数据和数据媒体，它具有固定不变的形式，可被人和计算机阅读。它和计算机程序共同构成了能完成特定功能的计算机软件（有人把源程序也当作文档的一部分）。硬件产品和产品资料在整个生产过程中都是有形可见的，软件生产则有很大不同，文档本身就是软件产品。没有文档的软件，不称其为软件，更谈不上软件产品。软件文档的编制在软件开发工作中占有突出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软件产品的效益有着重要的意义。
然而，在实际工作中，文档在编制和使用中存在着许多问题，有待于解决。软件开发人员中较普遍地存在着对编制文档不感兴趣的现象。从用户方面看，他们又常常抱怨：文档售价太高、文档不够完整、文档编写的不好、文档已经陈旧难于使用等等。
众所周知，文档的编写对于开发人员来说是一个十分头疼的任务，本来开发周期就很紧，还要按照要求的格式撰写文档。所以，这样结果往往就是文档不全，或者文档过于简单致使测试人员看不懂。甚至于，有时候项目需求早就更新了，而文档的内容依然不变。
换个角度想想看，如果文档不全，测试人员遇到不理解的地方肯定会去问相应的开发人员，那么开发人员肯定要花费时间做解释。如果测试人员和开发人员处在不同的工作地，这将造成十分的不便。
在软件开发过程中，文档十分重要，书写文档工作量也是相当大的。但是，只要掌握住技巧，还是可以缓解这令人头疼的问题的。首先，要站在别人的角度上看待这个问题。自己是做开发当然必须十分清楚程序的流程及功能，但是其他人就不一定，包括测试人员。所以，不要排斥写文档，先要换个角度想问题。再次，阐述基本功能，要做到重点突出。就是说，用简单的语言把功能简要介绍。对于其中的重点部分，要突出，要详细。不是说语言上要十分详细，而是理解的角度要详细。为了让测试人员快速理解模块的功能，最好的办法就是：功能流程图、数据流程图和例子。尤其是对于那些有相当强逻辑的程序而言，数据流程图和例子是非常好的方法，它不仅可以帮助指明数据的流向，还可以帮助测试人员理解测试用例的类型，以及结果形式。制作简明扼要的流程图和例子对开发人员而言是一项理清思路、省时省力的工作。而对于测试人员而言则是一份理解程序逻辑和功能的重要文档。在开发过程的后期，可以继续细化和完善文档。
2.3 结队编程，提前测试
为了提高软件的质量，公司可以尝试实行先结队编程，这其中也贯穿着质量意识。因为团队的两个开发人员轮流编程、轮流写文档、互相监督、互相测试。这样不仅可以有精力把文档写好写全，而且可以提前单元测试，互相监督对方养成好的编程习惯。最终提高工作效率。
结队编程后，单元模块先由项目组配备的测试人员首先进行测试，然后质量控制部的人员按照项目计划检查项目是否按照预定计划正常进行，相关文档是否撰写，并进行集成测试。
2.4 善于总结，提高效率
总结是一种非常好的学习方法，它可以节省精力、节约时间达到事半功倍的效果。在项目的开发过程中，可以将碰到的重要的技术方面的问题要及时记录并将解决方案也记录下来，以便于其他相关人员的参考。同样，在测试的过程中，测试人员应该及时总结发现的错误并归类，标明经常容易出错的地方，将意见提交项目经理，审核后，制定出一份统一标准并提供给开发人员，这样就可以提前避免错误、避免重复错误和重复测试，提高测试效率。不仅如此，项目结束后的各项总结报告将是项目的后期维护或二次开发的宝贵参考资料。
３．结论
软件开发作为一种复杂的智力密集型的活动，同一般产品的设计和生产过程有相当大的差别，人的因素占的比例很大，控制也更为复杂。例如软件的正确性无法证明、测试也很困难，如果希望通过最终的测试确保产品的质量是完全做不到的；生命周期的各个阶段的转化无法确保百分之百的正确和完整，等等。实践证明，如果不从本公司的实际情况出发，盲目地套用一些好高骛远的开发体系或者质量体系文件是行不通的，所建立的体系对提高管理水平非但不能起到多大的促进作用，而且可能会对正常的开发活动起阻碍作用，引起开发人员的反感。这样建立的体系或者难于维持下去，或者要花费宝贵的资源去维持一套无用的体系。所以，建议根据公司的实际量身定做，建立起一套符合本公司情况的切实可行的标准和规范，真正的改善软件过程，加强测试，提高软件质量。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |