在软件生命周期的哪一个阶段,软件缺陷修复费用最低 需求分析编制产品说
你提出的问题,很有水平!软件工程师编程写作都需要防范缺陷的问题.因此,一般存在缺陷的软件生命周期是指一个好的软件缺陷被发现后,要接收到报告到这个缺陷被修复、验证的过程.直至最后关闭的完整过程阶段. 关闭这个软件是对这一阶段中的应用,但不能说“关闭”这个软件是失败.希望能够帮助到你并对你的启发.
软件测试哪个阶段修复缺陷的成本最低
需求阶段,在需求阶段可能只需要改几个字的事,在后面要能就需要几千到几万的修复成本,BUG越往后修复的顾本越高~
软件测试发现缺陷的最佳时机是什么阶段
开发阶段. 发现的越早,修改错误的成本越低.
软件测试中为什么缺陷越早发现越好?
发现的越早,修正时所投入的人力物力越少.因为前期程序还未完善,各种逻辑和代码复杂度都要相对开发后期来说简单的多,缺陷修改起来也比开发后期修改要容易的多
个人软件过程的缺陷管理
缺陷是指程序中存在的错误，例如语法错误、标点符号错误或者是一个不正确的程序语句，是任何影响程序完整而有效的满足用户要求的东西，是可以表示、描述和统计的客观事物。
有人把缺陷称为Bug，这是不正确的。当成为Bug时，令人想到的是那些令人讨厌的小虫子，应该把它们拍死或者不予理睬。这会使一些重要的问题被视为琐碎小事，会养成一种错误的态度。缺陷并不像无足轻重的Bug，更像是定时炸弹。大家可能会觉得有些夸大其词，绝大部分细小的缺陷没有引起严重后果。然而不幸的是，很小一部分看起来无关紧要的缺陷却能引起严重问题。虽然现在缺陷对你来说还不是一个严重问题，但很快就会成为一个重要的问题。
设计错误的复杂性和所导致的缺陷的影响没有直接关系，一些微小的编码错误却可能引起严重的系统问题。事实上，绝大多数软件缺陷都源于程序员的疏忽大意。
为了减小缺陷，就必须进行缺陷管理，研究已经引入的缺陷，确定引起这些缺陷的原因，并学会在将来如何避免重复同样的错误。
缺陷分类。在分析缺陷时，将缺陷进行分类是有帮助的。通过缺陷分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷，这就是缺陷管理的关键。把精力集中到最容易引起问题的几类缺陷上，一旦这几类缺陷得到控制，在进一步找到新的容易引起问题的几类缺陷上。表4.1是Chillarege和他的IBM研究院的工作成果。
不要急于把10种类型的每一类细分出若干子类，直到你已经搜集到大量程序的缺陷数据。那时，才能够看出哪里需要更详细以及补充什么样的信息才是最有用的。
统计缺陷个数。采用缺陷记录日志，记录那些当你完成初始设计或编码后仍然留在产品中的缺陷。人们很容易对缺陷辩解，但是要管理好缺陷，就必须收集有关缺陷的准确数据。如果原谅缺陷，那只会自欺欺人。如果你这样做的话，就别指望有所提高。
为什么要尽早发现缺陷。不要期望一个简单拼凑出来的满是缺陷的程序，经过修改可以成为一个合格的产品。一旦生产出一个有缺陷的程序，它将永远是有缺陷的。虽然你可以修复所有已知的问题，并且让它通过所有的测试，但它还是一个有许多不定的有缺陷的程序。如果工程师能宽容有缺陷的工作，他将生产出低质量的产品。“我们忙，以后在修补吧”，这样的态度不可能出产出优质产品。
发现和修复缺陷的费用。在典型项目中，产品被分成很多小的模块，由不通的工程师负责开发。在模块设计、实现、编译后，工程师作初始的单元测试；单元测试后，多个模块组成一些大组件进行集成测试；经过各种级别的组件测试后，这些组件集成为产品进行产品设计；最后，将产品集成到系统中进行系统测试。随着系统的规模和复杂程度不同，单元测试、集成测试、组件测试、产品测试、系统测试的类型、持续时间、复杂程度有所不同，但几乎所有规模的软件产品，都需要这个过程。
研究证明，开发过程每前进一步，发现和修复缺陷的平均代价要增长10倍。尽管缺陷的修复时间变化很大，但平均时间总是遵循这样的规律，而与缺陷的类型无关。
发现和修复缺陷的方法。尽管没有办法不引入缺陷，但是在开发过程中尽早发现和修复缺陷还是可能的。有多种发现程序中的缺陷的方法，基本上都包括以下步骤：表示缺陷征兆；从征兆中推断出缺陷的位置；确定程序中的错误；决定如何修复缺陷；修复缺陷；验证这个修复是否已经解决了这个问题。
有多种工具和辅助手段来帮助完成这些步骤，工程师最常用的工具是编译器，它能够表示出大部分语法缺陷。但是编译器最基本的任务是生成目标代码，并且可能会在源程序有缺陷的情况下生成代码。因此，不能检查出所有的拼写、标点符号或其他不符合语法的缺陷。一般编译器仅提供了缺陷的征兆，你必须自己对问题定位，并确定是什么问题，通常很快能够做到这一点，但偶尔也需要较长的时间
另外一种常用方法就是上面讲述的测试。测试的质量是由测试用例覆盖所有程序功能的程度决定的。测试可以用来验证程序几乎所有的功能，但有自己的缺点：同编译器一样只能满足缺陷派出的第一个步骤，你仍必须从缺陷征兆找出问题的根源，然后才能修复；随着项目规模的扩大，全面的测试会花费大量的时间，要进行完全测试几乎不可能的。
最有效的发现和修复缺陷的方法是个人复查源程序清单。这种方法是负很难彻底清除程序中的缺陷，但事实证明，这是最快而且最有效的方法。
代码复查就是研究源代码，并从中发现错误。代码复查更有效的原因是：在复查时看到的是问题本身而不是征兆。从头到尾复查代码时，考虑的是程序应该做什么。因此，当看到某些地方不正确时，就可以看到可能的问题是什么，并立即去验证代码。复查的缺点是：非常耗时，而且很难恰当的进行；复查时一种技能，当然可以通过学习和实践来提高。
代码复查的第一步是了解自己引入的缺陷的种类，这是收集缺陷数据的主要原因。因为在下一个程序中引入的缺陷种类一般会与前面的基本类似，只要采用同样的软件开发方法，情况会一直如此。另一方面来说，当你有了技能和经验或改变了过程，缺陷的类型和数目会随之变化。但是到了一定程度后，改进就变得非常困难了。这是，就必须研究缺陷，这可以帮助你找到更好的发现和修复缺陷的方法。
如何进行代码复查。代码复查的目标是在软件过程中尽可能早和尽可能多的发现缺陷，缺陷发现时间越少越好。采用表4.3描述的一个有序的检查方法，在编译之前进行代码复查，是完成目标最好的方法。
编译之前进行复查。有几个原因说明应在编译之前进行代码复查：不论编译前或编译后，进行完整的代码复查的时间大约相同；不论编译前或编译后，对检查语法有效性的效果是一样的；先做复查将节省大量编译时间，若不做代码复查，一般要花12%～15%的开发时间进行编译，一旦使用代码复查后，编译时间可以缩短至3%或更少；编译程序后，代码一般复查很难彻底的进行； 经验证明，在编译阶段有大量的缺陷时，一般在测试阶段也有许多缺陷。
建立个人代码复查检查表。如果想发现和改正程序中的每一个缺陷，就必须遵照一个精确的规程。检查表可以确保遵循这个规程，它包括一系列程式的步骤。按照检查表去作时，就知道如何进行代码复查。
如果能够正确使用检查表，还能知道每个步骤发现了多少缺陷。这样就能测量出复查过程的效率，并进一步改进检查表。检查表包括了个人的经验。通过不断的使用和改进个人检查表，就可以帮助你用较少的时间发现这些缺陷。表4.4是一个C++程序代码复查表的范例。
定期更新检查表。随着时间的推移，检查表自然的要变大。但是，检查表的主要作用是帮助你把注意力集中在关键的方面。太大以后，你将失去重点。所以要定期复查缺陷数据，删除那些不能找到问题的表项。
从个人检查表的方法可以认识到，每个工程师都有各自的特点，某个工程师的实践经验对别人不一定适用。因而要设计出适合自己的检查表，并定期的对它进行检查以保证检查表更有效。只要你在代码复查中还遗漏缺陷，就要不断寻找改进检查表的方法。
进展是很缓慢的。最初，你发现缺陷的能力随着每次复查都有所提高。此后，提高将变得很困难。要坚持收集和分析缺陷数据，并坚持思考如何才能预防缺陷的产生或怎样更好的找到缺陷。只要坚持不断的做下去，就能在代码复查中不断进步，不断提高自己编写程序的质量。
编码标准。编码标准是被广泛接受的、能够作为工作样板的编码实践集。良好的编码标准将有效地帮助您避免开发有潜在危险的代码，有助于预防缺陷。例如，可以在编码标准中列出那些应该避免使用的方法，规定号循环入口或在说明是初始化变量，避免不良的变量命名等。编码标准还能有效地统一和规范整体开发活动。当其他开发人员加入到项目中来时，他们能够很好地适应这一切。代码也将变得更规范更易维护。
其他种类的代码复查。在软件组织中，一种常用的方法是同行评审，就是几个工程师彼此复查程序。组织良好的同行评审一般会发现程序中50%～70%的缺陷。互查虽然需要很多时间，但是可以有效发现缺陷，因为工程师往往难于发现自己的设计错误。他们创作这个设计，直到程序应该完整什么，即使概念有瑕疵、作了错误的设计或实现假定，他们往往很难发现。检查这可以帮助他们克服这些问题。对一个大的项目，最佳检查策略是，先做个人代码复查再进行编译，然后在任何测试前进时行同行检查。
细心工作是有回报的。当工程师觉得对自己开发的程序附有质量责任时，他就不会依赖于编译器或其他工具来发现缺陷。全面的代码复查要花费时间，但是他们节省出来的时间比花费的时间多得多，并能够生产出更好的产品。
引入缺陷是人类的正常现象，所有的工程师都会引入缺陷。因此所有的工程师都应该了解自己引入缺陷的类型和数据。
在开发过程中，总是可再进行一轮测试或代码复查，决定是否这样做的唯一方法就是分析缺陷数据。通过分析历史数据，可以估计出程序中缺陷的个数。通过把当前项目的数据??的质量情况。这样就能决定是否需要增加一些缺陷排除步骤。
缺陷率的预测。当开发一个新的程序时，可能会觉得很难估计你将引入多少缺陷，理由是缺陷的个数因程序的不同而不同。缺陷个数不稳定是有以下几个原因造成的。首先使经验问题，个人的技能是在不断提高的。开始编程序时，要面临着很多以前没有碰到过的问题。往往不能确定有些过程和函数是如何执行的，可能是语言的结构不清楚或者可能会遇到新的编译器或编程环境的问题。这些问题都会引起开发时间和缺陷路的波动。有了经验后，你将逐渐克服这些问题，犯的错误就减少了。这既减少缺陷的总数又减少缺陷数目的波动。缺陷的减少起初是由于经验的增加和对语言熟练程度的提高。经过这最初的提高后，就需要收集和分析缺陷数据来进一步改进了。
缺陷路波动的第二个原因是个体过程不稳定。当开始学习写程序时你也同时开始学习使用新的过程和方法。你的过程将随着实际的经验不断的发展，这就会引起完成不同程序任务的时间和引入缺陷的数据的波动。
最后，缺陷本身也是这种变化的原因，引入的缺陷越多，修复这些缺陷所花时间就越长。修复缺陷所花的时间越长，引入新的缺陷的几率也就会增加。因此缺陷的修改时间变动幅度很大。所以，很难对一个引入很多缺陷的过程进行预测。
随着开发过程的改进，过程会逐步稳定下来。这种稳定将提高缺陷预测的准确性。试验证明，如果在代码复查方面花了足够的时间，你的过程会迅速稳定下来。一旦你的过程相当稳定，缺陷也将容易预测。
根据对最近的程序跟踪每千行引入和排除的缺陷数，就可估计出在将来的程序中可能引入和排除的缺陷数。
