用别的眼光去感悟软件测试
曾经对软件测试很轻视，因为我那时很无知，只是一名普通的中国程序员，这也是那时绝大多数程序员的心态，那时中国程序员最讲究“编程才是硬道理”。如今却非常热爱软件测试，包括软件测试工具，方法，理论，技术。因为我在3年的测试工作中，深刻体会到软件测试的重要性和趣味性。此时，我已经跳出了“小程序员”的圈子，以软件系统工程的更大视角审视软件测试这项工作。很长时间以来我一直被下面的问题而困惑，有些问题至今仍然只是具有肤浅的认识，而且，我感觉我做的测试项目越多，阅读的测试书籍越多，我越感到我对软件测试理解的越肤浅。因为我越来越感受到软件测试的广度和深度的无限性，它像大海宽广，像宇宙那样深邃。 为什么要进行软件测试？软件测试的前途如何？软件测试的工具和思想谁更重要？软件测试的最高境界是什么？软件测试是保证软件质量的重要活动，是软件项目实施的不可缺少的环节。软件测试的直接目的是发现软件中存在的缺陷。此为测试的有效性。在软件项目没有结束之前的全部软件缺陷主要由软件开发人员负责，因为软件缺陷来自程序员的编程。软件项目结束后的软件缺陷主要由软件测试人员负责，因为软件测试人员没有在软件发布之前的测试中没有发现隐藏的错误。 但这不是绝对的，因为软件项目是一个系统工程，软件质量牵扯到多个部门和人员，以及需求分析，设计，编码等各个环节和过程。软件测试只能证明软件存在缺陷，不能保证软件没有错误。软件测试不是万能的，因为不可能发现全部的软件缺陷，而且软件的功能和性能不是由测试决定的。此为测试的有限性。软件测试目前主要以手工测试为主，自动测试工具虽然很多，但实际应用的广度和深度还有很大潜力，自动将有很大的发展空间！。软件驱动开发的观点说明了测试与编程的关系，测试应该贯穿于软件开发的整个生命周期，编程只是软件开发的一个环节。但往往大家非常重视软件编程，把测试作为编程后的一个辅助环节。这是典型的本末倒置。 软件测试的缺陷管理流程非常重要，报告的软件缺陷的质量，应该由他人验证，做到责任明确，方法简便可行。软件测试技术不断进步，但总体来看，国内的测试重视程度还不够，但已经发展很快。差不多两年之前，国内计算机书店中关于软件测试的书籍非常稀少，如今却琳琅满目，异彩纷呈。软件测试是个可以很快入门的职业，门槛不高，但是，不要认为什么人都可以做好软件测试。因为会做和做好是两个概念。软件测试人员最好具有软件开发经验，理解软件工程的知识。这是提高软件测试能力的基础。对于刚刚毕业的学生，如果希望今后从事软件开发，那么，先从事一段时间的测试可能更有利于今后的编程。而对于具有多年编程经验的程序员，如果改行做测试，更容易提高技术。 软件测试不是孤立的活动或过程，需要开发和市场人员的参与和交流，需要软件质量保证人员SQA的积极配合和沟通。软件测试的技术不断进步，与具体测试技术相比，掌握测试的核心思想比具体技术更重要！测试的最高境界在于运用最简单有效的测试技术，最大限度的发现软件缺陷!应当承认，目前国内的软件测试工程师的地位和待遇仍然很低，而且不少测试人员存在浮躁的心态（我甚至感到整个软件行业始终存在着躁的泡沫）。如何改变这种局面，这应该是个漫长的过程。当整个IT业真正以客户为上帝时，当软件质量成为决定企业生存和发展的决定因素时，当软件测试工程师的测试工作给软件企业带来更大的经济效益时，软件测试工程师才会得到应有的尊重！软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：第一、风险识别：从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。第二、风险分析：对风险出现的可能性和潜在的危害性进行量化分析。第三、应急计划：如果识别出的风险真的出现，你将采取的应急措施。第四、风险缓解：为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。第五、持续的监控：跟踪需要管理的风险，寻找风险出现的迹象。项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：第一、缺乏合理的进度安排这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。第二.它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。第二、需求的变化从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。第三、人员的变更在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。第四、规约崩溃这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。第五、低效率对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益。文章转自：http://www.uml.org.cn/Test/200609205.htm
页:
[1]
