软件测试管理中项目管理，质量先行

软件测试管理中项目管理，质量先行

提到软件产品开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦地工作，加班加点，甚至通宵达旦。虽然项目经理一次又一次地修改了进度计划，而实际的开发情况却总是令人担忧，以至于每次向领导汇报工作的时候，总是觉得以前制定的计划没有很好完成，总是觉得人力资源不够，总是觉得没有太多的时间。等到代码终于开发完成了，测试进度同样非常令人担忧，每一个小BUG 都要花很长的时间去查找，改了某一个小错误却又引起了很多新的错误，结果产品发布遥遥无期，而项目组里的每一位成员已经筋疲力尽。

　　怎样摆脱这样的困境？为何软件开发项目管理这么困难？为何我们做的计划总是不能按时完成？为何软件开发不能像硬件开发那样可以控制？

　　软件开发是完全依靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定、可变化的因素。那么我们怎样把握住这些变化因素呢？

　　软件项目管理——质量先行，如果我们能够控制软件生命周期每一个阶段的质量，就能很好地控制了软件开发的整个过程。

　　软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，是将大脑里无形的思维变成可以解决实际问题的一组界面或者组件。在这样一个复杂的过程中，应该如何保证质量呢？有人想到了ISO9000、CMM，也有人提出反对意见，认为应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的本质。

　　有人说，ISO和CMM到中国来怎么就变了味了？其实，我们只学到了怎样去做，但是不知道为什么要这样做。大家都知道在产品立项之前要写市场分析报告，但不了解为什么要写，市场分析报告的重要性有多高？不是资深开发人员很难理解其重要性，如果是简单地去写一篇形式上的文档，那么，除了负担之外就没有其它用途了。

　　有些人又想到了测试，觉得是我们测试的力度不够，所以产品质量不过关。

　　其实，软件开发的质量保证从最初就应该开始了，如果到了测试阶段才重视就已经晚了。软件产品开发过程，不管采用瀑布式模型还是迭代式模型，都离不开需求、设计、编码、测试这几个阶段。在迭代式开发中，这几个阶段也是周期性出现的。

　　怎样把握好每个阶段的质量，确实不是一件容易的事。对于软件产品的测试，不管是单元测试还是集成、系统测试，这方面的介绍已经很多了，因此笔者重点介绍一下需求、设计和编码阶段的质量保证。

　　让我们开始一次质量之旅吧，第一站就是需求分析。

　　在需求分析过程中，如何进行质量保证呢？我们平时可能更多地关注需求本身，却忽视了一个很重要的因素，那就是市场。因为我们开发出来的产品是直接面向市场的，如果费了很多的人力物力开发出来一个没有市场前景，缺乏竞争力的产品，那么所有的努力都是白费。如何充分考虑市场因素，具体可以从以下几个方面进行。

　　首先，判断需求是否符合愿景目标，所谓愿景目标就是我们开发出来的产品能够给我们的用户带来什么样的好处？如果有些需求没有被包含在愿景目标里，那么这样的需求其实就背离了我们开发产品的初衷。其次，判断产品需求能够给企业带来多大的利润，如果某个需求只是代表个别用户的需求，并不能给企业带来较大的利润，但又花费甚高，就可以考虑删除。最后，与竞争对手相比核心竞争力有哪些？如果核心竞争力不够，就应该考虑重新进行需求分析，因为如果没有核心竞争力，开发出来的产品就没有市场。

　　在排除了市场因素产生的风险之后，我们应该保证需求描述的质量。人与人的交流总会存在一些误会，同样一句话，心情不好与心情好的时候听起来可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对UML比较熟悉的话，需求分析可以利用UML工具进行，这样可以减少一些自然语言引起的歧义，但是并不是所有的用户都了解UML各种图形的意思，与用户沟通起来存在障碍，除了工具之外，我们可以从以下几个方面来保证需求描述的质量。

　　首先，看句子和段落是否简短。长句子看起来会非常困难，很难弄懂真正的需求：另外，过长的句子和段落容易让人忽视一些需求。所以，如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。

　　其次，句子是否有语法错误，还要注意标点符号，有时，标点符号点错了就完全成了另外一个意思。再次，是否存在模糊不清的需求，出现“可能，大概，或者”等词汇表述。

　　最后，注意是否存在形容词及比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的、界面友好的、减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围。

　　另外，保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化就很容易造成代码的返工，出现程序员尽管加班加点却总是不能如期完成任务的情景。怎样才能判断需求细化的程度呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？

　　答案是：是否可以将需求写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要进一步进行细化。

　　把握住了需求分析这一关，下一站我们就可以进行设计了。

原文转自：http://www.ltesting.net