严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。

对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。

什么是缺陷的严重性和优先级

严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

缺陷的严重性和优先级的关系

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。

另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。

处理缺陷的严重性和优先级的常见错误

正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不是很丰富的测试和开发人员而言，经常犯的错误有以下几种情形：

第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。

第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。

因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。

如何表示缺陷的严重性和优先级

缺陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。

为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。

具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。例如，使用数字1，2，3，4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1，2，3，4可以分标表示低优先级、一般、较高优先级和最高优先级。

如何确定缺陷的严重性和优先级

通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。

确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。

对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定：

1 – 非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。 　2 – 较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果； 　3 - 软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确； 　4 -软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；

对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定：

1 –最高优先级，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。 　2 – 较高优先级，例如，影响软件功能和性能的一般缺陷； 　3 -一般优先级，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷； 　4 – 低优先级，例如，对软件的质量影响非常轻微或出现几率很低的缺陷；

其他注意事项

比较规范的软件测试，使用软件缺陷管理数据库进行缺陷报告和处理，需要在测试项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。

在测试项目进行过程中和项目接收后，充分利用统计功能统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度。统计优先级的分布情况，控制开发进度，使开发按照项目尽快进行，有效处理缺陷，降低风险和成本。

为了保证报告缺陷的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现问题，及时反馈给项目负责人，及时解决。

对于测试人员而言，通常经验丰富的人员可以正确的表示缺陷的严重性和优先级，为缺陷的及时处理提供准确的信息。对于开发人员来说，开发经验丰富的人员严重缺陷的错误较少，但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标，因为软件的模块的开发难度不同，各个模块的质量要求也有所差异。

软件测试过程中有哪些风险？

那么到底都有哪些风险要注意呢?如何解决呢?另外这些风险如何在计划中写明呢，不会写“张三可能要离职”，“开发提交代码可能会延期”吧? 精彩答案： 会员liuchunyanli、贝贝酷、namisang： 设计方面： 风险：(1)没有详细设计说明书; 解决方案：测试人员要在开发阶段对相关设计及需求文档进行分析，对大体模块功能进行分类，分析业务逻辑，在不清楚的地方及时与开发人员沟通。 风险：(2)没有统一的界面设计规范。 解决方案：与项目负责人确认测试标准。 开发方面： 风险：(1)所有模块开发没有统一设计，开发人员有自己的设计方式; 解决方案：与项目负责人确认标准方式，与标准方式不一致的地方全部以BUG形式提交。 风险：(2)需求变更开发。 解决方案：建议将需求变更形成文档，对没有文档的需求变更，在测试过程中发现及时与开发负责人确认，并存档相关变更文档。 测试本身： 风险：(1)人力资源; 解决方案：保证稳定的人员安排。 风险：(2)硬件资源; 解决方案：事先分析测试所需硬件资源，及时申请，保证测试工作顺利进行。 风险：(3)版本控制; 解决方案：严格控制版本，BUG以版本为单位进行提交。在测试过程中及BUG确认阶段禁止任何代码更新。 风险：(4)测试时间不足。 解决方案：动员测试人员完成测试任务，必要时，应给予相应物质奖励。 测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有： 一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对; 二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏; 三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够; 四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智; 五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等; 六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差; 七、有些缺陷出现频率不是百分之百，不容易被发现;如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大; 八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。 前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。 针对上述软件测试的风险，有一些有效的测试风险控制方法，如： 测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查; 有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险; 有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率(如达到99.9%)来降低这种风险; 为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如： 在做资源、时间、成本等估算时，要留有余地，不要用到100%; 在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中; 对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司， 项目不会受到严重影响，仍能可以继续下去; 制定文档标准，并建立一种机制，保证文档及时产生; 对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换; 对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。 要想真正回避风险，就必须彻底改变测试项目的管理方式;针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。

常见铸件缺陷的修补方法都有哪些？求助中……

铸件由于多种因素影响，常常会出现气孔、针孔、夹渣、裂纹、凹坑等缺陷。常用的修补设备为氩弧焊机、电阻焊机、冷焊机等。对于质量与外观要求不高的铸件缺陷可以用氩弧焊机等发热量大、速度快的焊机来修补。但在精密铸件缺陷修补领域，由于氩焊热影响大，修补时会造成铸件变形、硬度降低、砂眼、局部退火、开裂、针孔、磨损、划伤、咬边、或者是结合力不够及内应力损伤等二次缺陷。冷焊机正好克服了以上缺点，其优点主要表现在热影响区域小，铸件无需预热，常温冷焊修补，因而无变形、咬边和残余应力，不会产生局部退火，不改变铸件的金属组织状态。因而冷焊机适用于精密铸件的表面缺陷修补。冷焊的焊补范围为Φ1.5-Φ1.2mm焊补点反复熔化堆积的过程，在大面积缺陷修补过程中，修复效率是制约其广泛推广应用的唯一因素。对于大缺陷，推荐传统焊补工艺与铸造缺陷修补机的复合应用。可有时我们的缺陷没有很多，就不必要投入较大的成本，我们用一些修补剂就可以修补好的，方便简单，例如铁质材料的，我们可以用（劲素成）JS902修补一下就可以了，用不完可以放到以后再用，这样可以为我们的厂家节省成本啊，让我们的铸造厂家把更多的资金投入到提高产品本身质量上，让使用者创造更多的财富。

软件缺陷的优先级

严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。

对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。

什么是缺陷的严重性和优先级

严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

缺陷的严重性和优先级的关系

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。

另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。

处理缺陷的严重性和优先级的常见错误

正确处理缺陷的严重性和优先级不是件非常容易的事情，对于经验不是很丰富的测试和开发人员而言，经常犯的错误有以下几种情形：

第一，将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。

第二，将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。

因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。

如何表示缺陷的严重性和优先级

缺陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。

为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。

具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。例如，使用数字1，2，3，4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1，2，3，4可以分标表示低优先级、一般、较高优先级和最高优先级。

如何确定缺陷的严重性和优先级

通常由软件测试人员确定缺陷的严重性，由软件开发人员确定优先级较为适当。但是，实际测试中，通常都是由软件测试人员在缺陷报告中同时确定严重性和优先级。

确定缺陷的严重性和优先级要全面了解和深刻体会缺陷的特征，从用户和开发人员以及市场的因素综合考虑。通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。

对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定：

1 – 非常严重的缺陷，例如，软件的意外退出甚至操作系统崩溃，造成数据丢失。 　2 – 较严重的缺陷，例如，软件的某个菜单不起作用或者产生错误的结果； 　3 - 软件一般缺陷，例如，本地化软件的某些字符没有翻译或者翻译不准确； 　4 -软件界面的细微缺陷，例如，某个控件没有对齐，某个标点符号丢失等；

对于缺陷的优先性，如果分为4级，则可以参考下面的方法确定：

1 –最高优先级，例如，软件的主要功能错误或者造成软件崩溃，数据丢失的缺陷。 　2 – 较高优先级，例如，影响软件功能和性能的一般缺陷； 　3 -一般优先级，例如，本地化软件的某些字符没有翻译或者翻译不准确的缺陷； 　4 – 低优先级，例如，对软件的质量影响非常轻微或出现几率很低的缺陷；

其他注意事项

比较规范的软件测试，使用软件缺陷管理数据库进行缺陷报告和处理，需要在测试项目开始前对全体测试人员和开发人员进行培训，对缺陷严重性和优先级的表示和划分方法统一规定和遵守。

在测试项目进行过程中和项目接收后，充分利用统计功能统计缺陷的严重性，确定软件模块的开发质量，评估软件项目实施进度。统计优先级的分布情况，控制开发进度，使开发按照项目尽快进行，有效处理缺陷，降低风险和成本。

为了保证报告缺陷的严重性和优先级的一致性，质量保证人员需要经常检查测试和开发人员对于这两个指标的分配和处理情况，发现问题，及时反馈给项目负责人，及时解决。

对于测试人员而言，通常经验丰富的人员可以正确的表示缺陷的严重性和优先级，为缺陷的及时处理提供准确的信息。对于开发人员来说，开发经验丰富的人员严重缺陷的错误较少，但是不要将缺陷的严重性作为衡量其开发水平高低的主要判断指标，因为软件的模块的开发难度不同，各个模块的质量要求也有所差异。

. 计算机控制系统的典型形式有哪些？各有什么优缺点？

计算机控制系统的典型形式:(1)操作指导控制系统。优点：结构简单，控制灵活和安全，缺点是由人工操作，速度受到限制，不能控制多个对象。（2）直接数字控制系统（DDC），实时性好，可靠性高和适应性强。（3）监督控制系统（SSC），是生产过程始终处于最优工况。（4）分型控制系统（DCS），分散控制，集中操作，分级管理。（5）现场总线控制系统（FCS），降低成本，提高可靠性，可实现真正的开放式互连系统结构来自：求助得到的回答

软件测试开发成本

第一篇：软件测试,是成本还是投资？

发布时间: 2007-12-19 17:43 作者: 未知 来源: 网络转载

很多的软件公司都认为软件测试很重要，但基本上国内大部分的软件公司都只是象征性的请一到两个测试人员负责所有项目的测试。因为影响软件测试的因素太多了，时间限制、资源短缺、预算不足等等。于是就开始来减少软件测试的投入了。那么我们不禁要问一句，软件测试到底是成本花费呢，还是一种长期的软件投资呢？

一、引言

随着软件市场的成熟，人们对软件作用期望值也越来越高，软件的质量、性能、可靠性等方面也正逐渐成为人们关注的焦点。目前，中国软件产业在产品功能和性能测试领域都存在着严重不足，中国软件企业已开始认识到，软件测试的广度和深度决定了中国软件企业的前途命运。

软件测试并非传统意义上产品交付前单一的“找错”过程，而是贯穿于软件过程的始终，是一个科学的质量控制过程。国外成熟软件企业，1个软件开发工程师对应1-2个软件测试工程师，而国内软件企业，平均8个软件开发工程师才对应1个软件测试工程师，比例严重失衡。

二、软件测试行业现状

软件的大工业生产决定了软件测试是生产的必不可少的环节。对于人员配置，一直以来流行一种五比一的标准说法。 从公司内部看任何时候都是远高于这一比例。从近一个时期看，开发与测试工作量的比重甚至达到了二比一。同类型成熟产品之间的竞争最容易取胜的方法是提高质量。

软件的大工业化并不是在消灭个体户和小作坊，只是减少了他们直接与最终用户打交道的机会和必要。如今他们生产和包装软件的目的在于等待大公司的收购。为此，在最后阶段需要进行“最终用户测试”。

与此同步的是，软件测试市场已成为软件产业中的一个独特市场。在美国硅谷地区，凡是软件开发企业或是设有软件开发部门的公司，都有专门的软件测试单位，其中软件测试人员的数量相当于软件开发工程师的四分之三。在这些公司或部门中，负责软件测试的质量保证经理的职位与软件开发的主管往往是平行的。据了解，在软件产业发展较快的印度，软件测试在软件企业中同样拥有举足轻重的地位。

与国外相比，国内的软件测试业状况又如何？目前，国内软件测试市场表现实在有点令人尴尬。中国市场中的软件开发公司比比皆是，但软件测试公司则如凤毛麟角，“市场化的第三方测试如同刚刚出生的宁馨儿，目前的市场几乎可以忽略不计。”

为什么国内的软件测试市场会如此嬴弱，到现在企业才开始关注呢？以笔者之见，究其主要原因，首先是因为企业对软件测试的重要性理解不够。很多人认为程序能试运行基本上就已经成功，没有必要成立专门的测试部门或设立测试岗位。

另一方面，软件开发企业在为软件开发支付费用后，就不希望再为软件的测试支付新的成本，而项目甲方则往往认为开发合格的软件是软件开发企业的责任。即使有些项目的开发方或委托方有意对软件进行第三方测试，也会考虑到在测试过程中往往需要软件开发商提供源代码，担心其知识产权遭到侵犯。这是软件测试市场无法长大的又一个重要原因。此外，软件开发企业不重视利用外部的测试力量进行测试也是因素之一。

三、困惑的软件测试员

很多时候，投资在测试上的人力及财力，将由许多的因素来决定。而其中软件测试人员是很重要的考虑因素。其实组织在软件测试方面最大的成本开支就是测试人员上。在软件工具及测试设备都比较接近的今天，竞争对手之间在软件测试方面的竞争，主要就体现在软件测试人员上。

近期的无忧指数显示，软件测试工程师已经成为2007年最紧缺的人才之一，该类职位的需求主要集中在沿海发达城市，其中北京和上海的需求量分别占去了33%和29%；而从企业分布来看，民企需求量最大，占了19%，外商独资欧美类企业需求排列第二，占了15%。目前，国内软件测试人才紧缺的现状已经凸现出来。

笔者认识一位朋友A，做专业的测试工程师已经有一年多的时间了，目前仍然在做较为底层的测试。有时候也会写写测试需要的代码，但还没有开始设计整个项目测试案例。目前A正在为某一著名软件公司做软件测试，工作的流程非常严谨而明晰，这自然也意味着枯燥的重复。枯燥并没有淹没A的工作激情，发现一个Bug带来很大的成就感，特别是想到每天将会有几百万人通过使用没有这个Bug的软件准确无误的达到他们的目的。

前途在A心目中是非常明朗的，颇有一些“随需”择业的味道。曾经有媒体报道过近来软件测试工程师在职场需求中的风光景况，尽管IT行业的总体需求仍然疲软。在北京和上海等地，测试员的需求量占到了招聘总量的近1/3。另一方面，A认为从测试员成长为软件项目管理者是更有优势的。

例如微软的开发方式本来就是“测试驱动”的，在测试过程中发现了墙角还有没涂到油漆的小块，开发则根据这个思想再补上那一块。测试的经历恰好让人更能从用户的角度来考虑问题，更能深入了解程序开发过程中可能出现的问题，这都是成为一个优秀的项目管理者的必要条件。尽管可能一整天都为了一个小控件“循规蹈矩”地反复测试并撰写测试文档，这样的重复被A当作了重要的积累。A喜欢新东方学校的徐小平新书《骑驴找马》中的一句话：“重复做汉堡，就是麦当劳；重复煮咖啡，就是星巴克；重复教托福，就是俞敏洪；重复做好事，就是活雷锋。”

测试工作，在好多公司说到底还是不够重视。如果管理层从控制成本考虑，不打算对测试投入太多，例如对用了2年左右的测试工程师不想加更多的薪水留人怎么办呢？那我们就要问了，什么是软件成本?不仅仅是生产过程中产生的费用叫成本，未来因为产品缺陷产生的服务费用也是成本，如果产生了客户退货、产品召回，也是要算成本的哦！作为测试的工程师要学会使用数据说话，把产品缺陷造成的成本数据搜集起来，关键的时候拿出来给重视成本的领导或管理层查阅方能实现工作向工作量的转变。

四、测试的成本

测试成本的要素包含很多方面，是否写了测试代码只是其中一个重要部分，是否采用JUint以及Mock对象更加不是对其评价的决定性因素。对测试的更好评价应该是额外代码、测试可重复性、测试范围和边界值识别等综合构成（测试对设计的作用是更高级的判断）。

对于涉及到数据库持久方面的测试、涉及到UI（浏览器或者富客户端）交互的测试以及多对象多方法过程的测试（也可体现为UI交互，这里是指独立性质的）等，以及上面说到的一些问题（不再重复），是我们现实测试实践要面临的问题。

对这些问题的解决，就会更多的涉及到项目具体情况的选择和具体项目和团队的情况来做最佳判断，这就是成本的意义。

在软件开发的早期，软件开发只是编码及部署。但随着软件行业的发展，开发企业开始在发布前进行测试。因此，这个意义上来说，软件测试是成本。但从更普遍的意义上来讲，软件测试其实是一种提供软件质量的投资。

软件测试看似成本，但其实可能就是一项可以减少将来若干不必要费用的投资，同时还可以为企业赢得良好的口碑。而达到这一目的解决方案，主要有：采用测试驱动开发方式；确保每个小功能的模块都得到很好的测试，并建立可持续的资源整合环境；进行可靠的整体测试。软件测试最终将转化成为节约成本的开支。不论它是产品开发、软件升级、或是软件维护。

许多统计资料表明，开发过程每前进一步，发现和修复一个缺陷的平均成本要提高10倍．那么是不是说找缺陷就不重要了呢？当然不是。软件测试的另一个经济目标是尽早发现缺陷，降低修复及售后服务成本。显然，每一个已发布产品中的缺陷除了会影响产品及企业的声誉外，还会直接增加产品的售后服务成本。无论是派人到现场调试，或研发、发布补丁程序都要远比在发布前的修复成本昂贵数十倍，甚至数百倍。

五、小结

软件测试的必要性已经完全为业内决策人士所接受。这是因为软件工业已经发展到了与其他主要工业相当的规模。经过十几年的发展，少数天才们手工作坊的世界已经转化为大工业生产的天下。由于Java的流行，我们更看到了组装生产线的模式。

在工业生产的传统行业里，测试是生产的有机组成环节，各道工序的测试、组装测试、出厂测试及致破坏性试验是生产目的实现的重要保证。

可以肯定，软件开发面临很多的困难，诸如发布时间紧、市场压力大、投资过高等。这些不能成为挤压软件测试投入的借口。因为软件测试是软件开以生命周期一个非常重要的部分。笔者认为，对于一些基于产品的公司或组织，软件测试作为一种投资可能更加适合一些，因为这样可以节约销售成本及技术支持成本。

转载请注明出处51数据库 » 尽早发现软件缺陷降低修复成本 软件缺陷的优先级