软件测试管理中可能存在的问题及分析解决.docx
《软件测试管理中可能存在的问题及分析解决.docx》由会员分享，可在线阅读，更多相关《软件测试管理中可能存在的问题及分析解决.docx（15页珍藏版）》请在冰豆网上搜索。
软件测试管理中可能存在的问题及分析解决
软件测试管理中可能存在的问题及分析解决
摘要：
本文结合实践，主要探讨了在中小型软件企业中，在测试资源不是很充足的情况下的软件测试管理。
文中前两部分简要介绍了软件测试管理及测试的范围，方法及重要性，之后对当前国内中小型软件企业在测试及测试管理中可能存在的问题进行了简单的介绍与分析，最后介绍了一些较好的解决方法。
关键词：
软件测试；测试管理；测试问题；管理体系
1、引言
随着IT技术的迅速发展，计算机在各行各业日益广泛的应用，软件产品的不断推出，计算机软件已经越来越深人到人们的生活中，人们对计算机软件质量的要求也就越来越高。
如果软件存在故障，将可能造成人力、物力和财力的巨大浪费；如果软件的质量不高，其维护费用不仅将大大超过其开发费用，而且会使维护变得很困难，甚至将可能造成不可弥补的损失。
软件测试是软件质量保证的关键步骤。
美国质量保证研究所对软件测试的研究结果表明：
越早发现软件中存在的问题，开发费用就越低；在编码后修改软件缺陷的成本是编码前的10倍，在产品交付后修改软件缺陷的成本是交付前的10倍；软件质量越高，软件发布后的维护费用越低。
另外，根据对国际著名IT企业的统计，它们的软件测试费用占整个软件工程所有研发费用的50%以上。
由此可见，为了保证软件产品的质量，必须对计算机软件进行测试。
随着计算机硬件成本的不断下降，软件在整个计算机系统的成本中占有越来越高的比例，如何提高软件质量是整个计算机软件行业的重大课题。
软件测试作为软件开发的一个重要环节，日益受到人们的重视。
为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。
由于软件测试至今仍令人捉摸不定，为确保测试工作的顺利进行，就要对其进行有效地管理。
软件测试管理是一种活动，可以对各阶段的测试计划、测试案例、测试流程进行整理、跟踪、记录其结果，并将其结果反馈给系统的开发者和管理者。
同时将测试人员发现的错误立刻记录下来，生成问题报告并对之迸行管理。
所以采用软件测试管理方法可以为软件企业提供一个多阶段、逐步递进的实施方案。
通过此管理方法，软件企业还可以用有限的时间和成木完成软件开发确保软件产品的质最，进一步提高计算机软件在市场上的竞争能力。
一般应用过程方法和系统方法来建立软件测试管理体系，也就是把测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。
同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。
其主要目标是在设定的条件限制下，尽可能发现和排除软件缺陷。
但是当前，中国软件企业在软件测试方面与国际水准仍存在较大差距。
首先，在认识上重开发、轻测试，没有认识到软件项目的如期完成不仅取决于开发人员，更取决于测试人员；其次，在管理上随意、简单，没有建立有效、规范的软件测试管理体系；另外，缺少自动化工具的支持，大多数企业在软件测试时并没有采用软件测试管理系统。
所以对国内软件企业来说，不仅要提高对软件测试的认识，同时要建立起完善的软件测试管理体系。
2、软件测试及测试管理的范围
2.1测试的范围
下面主要就测试的参与者，测试要素，测试开始时应确定的工作，测试过程简要介绍软件测试的工作范围。
参与者
●用户方代表
●软件最终使用者
●软件开发人员
●软件测试人员
●高层经理的支持
●过程保证人员（SQA）
测试要素
●正确性：
数据输入，过程处理和输出的正确性（IPO）。
●文件完整性：
文件被正确使用，恢复和存储的数据正确。
●授权：
特殊的授权可以执行一个特殊的操作。
●进程追踪：
当进程运行中，程序有能力证实进程在正常工作。
●系统运行的连续性：
当有非致命性问题发生后，系统有能力继续运行关键的任务。
●服务水平：
系统有紧急情况发生时，要求程序的输出结果不经或进行简单的处理后就可以直接使用。
●权限控制：
防止系统被误用（意外或者有意的）。
●一致性：
确保最终设计和用户需求完全一致。
●可靠性：
在规定的时间内都可以正常运转。
●易于使用：
多数人均感觉易于使用。
●可维护性：
可以很容易的定位问题，并且进行修改。
●可移植性：
数据或者程序易于移至到其它系统上。
●耦合性：
系统中的组件可以很容易的联接。
●性能：
系统资源的占用率，响应时间，并发处理。
●操作性：
易于操作（Operator）。
测试开始时应确定的工作
●需求阶段
→确定测试策略
→确定收集了足够的需求
→产生功能性的测试用例
●设计阶段
→确定设计和需求之间的联系
→确定进行了足够的设计
→产生结构和功能的测试用例
●编码阶段
确定和设计之间的联系
确定拥有执行的足够条件
产生结构和功能的测试用例
●测试阶段
确定设计了足够的测试用例
测试应用系统已经完成
关键资源已经到位
●安装阶段
将测试完成的系统变为产品
●维护阶段
修改和重新测试
软件的测试过程
●估算：
对软件工作量的估算；对软件系统的状况的评估。
●测试计划：
详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。
●需求测试：
在软件开发的所有阶段进行测试，测试应该尽早，在需求和设计阶段发现的缺陷修正的花费最小。
●设计测试：
给测试要素打分；分析测试要素；对设计进行评审；检查修改的部分。
●编码测试：
编码是否按照既有的标准进行，过程是否易于实践；是否编制了足够的文档。
●测试总结：
表示出目前项目的实际状况；明确测试所做的工作，给出系统的操作性能的评价，明确什么时候系统可以进行产品化的工作。
●安装，交付测试：
检验检查表和产品的正确性；使用测试标准去检验发生的问题。
●维护阶段的测试：
开发一些测试用例，预先发现一些问题；对用户进行培训。
2.2测试管理的范围
软件测试管理要解决的课题是如何确保软件测试技术能在软件项目在软件生命内得到顺利实施，并产生预期的效果。
按照管理的对象不同，软件测试管理大致分为软件测试团队组织管理、软件测试计划管理、软件缺陷（错误）跟踪管理以及软件测试件管理四大部分。
软件测试团队组织管理通俗的讲就是测试团队应该如何组建以及测试人员管理。
在实际项目开发中，我们常常看到有些单位忽视测试团队存在的意义，当要实施测试时，往往临时找几个程序员充当测试人员；也有些单位尽管认识到了组建测试团队的重要性，但在具体落实的时候往往安排一些毫无开发经验的行业新手去做测试工作，这常常导致测试效率的低下，测试人员对测试工作索然无味。
一个好的测试团队首先要有好的带头人，他必须具有极为丰富的开发经验，对开发过程中常见的缺陷或错误了然于胸，此外，他还应具有亲和力和人格魅力。
其次，测试团队还应有具备一技之长的成员，如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本。
另外，测试团队还应有兼职成员。
如验证测试实施过程中，同行评审是最常使用的一种形式，这些同行专家就属于兼职测试团队成员的范畴。
测试团队里往往不乏缺乏开发经验软件新手，这部分人可以安排去从事交付验证或黑盒测试之类的工作。
软件测试计划管理通俗地讲就是安排好测试流程。
这部分内容具体涵盖软件测试策划、软件测试技术剪裁、测试进度管理、成本管理等几个部分。
其中测试策划工作主要是指具体测试活动实施之前做好策划工作，如起草测试大纲以及测试计划；软件测试技术剪裁工作主要是指测试团队应根据软件项目的具体实际剪裁出所要实施的测试技术；测试进度管理工作主要是指排出各项测试的时间进度及人员安排，如有变动时应做相应调整；测试成本管理工作的内容即开列出测试活动中会涉及到的资源需求。
软件缺陷（错误）跟踪管理通俗地讲就是确保发现的缺陷（错误）已经被开发团队纠正或处理过并且没有引入新的缺陷（错误）。
具体来讲，当测试团队通过各种途径发现了文档或代码中的缺陷或错误以后，并不是交一份测试报告就草草了事，而是在递交报告以后继续督促开发团队及时关闭已知缺陷或错误（当然，如有必要应对这些缺陷、错误做严重程度排序，以便开发团队能视轻重缓急安排处理顺序）。
当开发团队关闭了测试报告中的缺陷（错误）以后，测试团队还需验证开发团队在关闭过程中有没有引入新的错误。
通常，这个过程称为回归测试。
回归测试如发现问题，继续报开发团组，按上述流程循环，直至回归测试最终通过。
软件测试件管理通俗地讲就是指努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。
这里，财富库是指软件测试件。
测试件（Testware，指测试工作形成的产品）是一个不常见到的词汇，它包括是测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广至通用的测试脚本程序。
测试件管理工作做得越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递就越充分，测试脚本或规格文档的重复开发工作也就能被有效地避免。
软件测试件管理工作包括两部分，一是建设，另一个是培训。
建设工作大抵是收集各类测试外文档、测试工具、测试脚本，也包括收集整理测试人员的会议发言、总结报告、技术心得等等。
培训工作大抵是通过技术讲座、正式或非正式团队会议、印发学习资料等形式进行。
2.3软件测试管理内容
具体的测试管理内容有：
●测试方案管理：
单元测试、集成测试和产品测试的测试计划的录入、修改、删除、查询和打印。
●测试案例管理
测试案例的增、删、改、拷贝和查询；
测试案例测试情况的管理，如测试状态包括：
未测试、测试中、已测试；
测试结果分为：
通过、未实现、存在问题等；
测试案例输人、编号和归档。
●测试流程管理：
测试进度管理；测试流程标识；测试日志及状态报告。
●问题报告管理：
问题报告处理流程（问题报告、整改报告）、实现问题报告与测试案例的关联。
●测试报告管理：
生成单元测试、集成测试和产品测试的测试报告。
除了以上这些，在侧试管理过程中还应对人员和环境资源进行管理。
3、测试及测试管理中的问题及分析
通过以上的简单总结与分析，可以看到软件测试及测试管理的重要性，及其复杂、广泛的组织管理工作，所以在实施起来，难免与理论有些出入。
另外，国内的软件企业大多起步晚，技术基础薄弱，应用与管理经验缺乏，在测试上更是如此。
于是国内的一些中小型的软件企业，在软件测试方面存在诸多问题，不仅与理论要求相差甚远，与实际的应用需求也相差很多。
下面将简要介绍与分析当前国内中小型软件企业在测试及测试管理中存在的问题和问题原因，并在之后提出一些解决办法。
3.1软件本身的复杂性与企业自身的不足
这里复杂性包括软件用户需求的复杂与难确定性，软件开发过程的组织管理的难控制性等，使得软件开发过程必然会存在诸多问题，开发出的产品也必然存在一些缺陷与不足。
而由于生产与管理经验的不足，缺乏高效的开发与测试团队，往往是开发人员又是测试人员，或测试人员质量管理；缺乏有效的测试技术，代码走查室最常用的方法；测试开始较晚，往往在开发完成之后；对用户反馈信息缺乏整理总结等；使得不仅难以控制产品的缺陷数量，而且对于缺陷的定位与修补也很难到位。
3.2测试的特性
3.2.1测试是不完全的（测试不完全）
由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。
3.2.2测试具有免疫性（软件缺陷免疫性）
软件缺陷与病毒一样具有可怕的“免疫性”，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。
在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试必须采用不同的测试方式和测试数据，应该尽可能的多采用多种途径进行测试。
3.2.3测试是“泛型概念”（全程测试）
如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。
这非常不利于保证软件质量。
需求缺陷、设计缺陷也是软件缺陷，记住“软件缺陷具有生育能力”。
软件测试应该跨越整个软件开发流程。
需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：
需求测试和设计测试）的一种。
软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。
同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。
3.2.4软件缺陷具有空间聚集性（80-20原则）
80%的软件缺陷常常生存在软件20%的空间里。
这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发“地段”。
在那里发现软件缺陷的可能性会大的多。
这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。
聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。
80-20原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免80%的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的80%，最后的5%的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。
因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。
3.2.5为效益而测试
为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。
为此我们不难得出我们在实施软件测试应该掌握的度。
软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。
这个平衡点就是我们在实施软件测试时应该遵守的度。
单方面的追求都必然损害软件测试存在的价值和意义。
一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化。
3.2.6缺陷的必然性
软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。
某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。
很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。
比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。
更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。
因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。
3.3测试组织管理不专业
1、测试人员不独立于开发者，测试人员独立于开发者的程度将影响测试结果。
人很容易用自己已经非常仔细地做过测试来欺骗自己，开发人员做测试容易受到个人的习惯性想法的影响，程序中可能包含由于程序员对问题的叙述或说明的误解而产生的错误。
如果是这种情况，当开发人员测试自己的程序时，往往还会带着同样的误解致使问题难以发现。
开发和测试是两种不同的活动，开发人员对自己的程序进行一定的审查、调试是必要的，但是一般情况下还需要另外的专业测试者进行测试。
不过，由于有的企业中，人力有限，或者认为没有足够的资源或理由支持一支测试队伍，有时不得不由开发人员测试；那么，开发者对自己的程序的测试需要注意许多问题，或者应由另外的开发者对自己的程序进行测试。
2、测试时间安排往往计划不周，测试计划有时受制于开发计划。
3、测试等级以及在那个等级上的测试时间往往选择不当。
4、测试辅助设备和测试工具将影响开发者的测试效率及测试彻底性。
5、测试策略文档的普遍缺失。
6、测试范围的确认经常被其他文档或经验所取代。
7、测试任务应该像BUG一样有明确的分级，不同类型的测试应该有相应的测试用例集合与之对应。
8、关键路径概念在测试规划时容易被项目经理弱化。
9、测试用例不科学，测试用例在实际中没有起多大作用；在实际测试时根本没有按用例执行；往往测试执行后没有把新的用例补充到用例库中。
3.4测试人员的影响
1）测试人员入门容易学习困难，无章可循；人员增加可能有重复工作。
2）测试人员对现实应用与需求的理解可能有偏差。
3）测试人员可能对测试存在一些不正确的看法和错误的态度，如下：
（1）认为测试工作不如设计和编码那样容易取得进展难以给测试人员某种成就感；
（2）以发现软件错误为目标的测试是非建设性的，甚至是破坏性的，测试中发现错位是对责任者工作的一种否定；
（3）测试工作枯燥无味，不能引起人们的兴趣；
（4）测试工作是艰苦而细致的工作；
（5）对自己编写的程序盲目自信，在发现错误后，顾虑别人对自己的开发能力的看法。
4）提交以后对用户反馈信息缺乏及对缺乏足够的重视，对于有大量用户有持久生命力的软件产品（如MicrosoftOffice），用户反馈信息较全面，便于开发和测试人员进行软件的修补和维护；而一些中小软件企业的产品却远远无法和MicrosoftOffice相比；于是可能缺乏足够的用户反馈信息，或没有足够的时间或人力处理用户反馈信息。
5）开发及测试人员工作习惯，编程习惯，测试习惯等也影响测试的效果；由于测试人员短期的学习与培训，一般能提高的只是方法和技巧；而其自身能力与习惯可能的负面影响却一时难以消除。
4、测试管理问题的解决
4.1建立软件测试管理体系
建立软件测试管理体系的主要目的是确保软件测试在软件质量保证中发挥应有的关键作用，包括以下工作：
软件产品的监视和测量：
对软件产品的特性进行监视和测量，主要依据软件需求规格说明书，验证产品是否满足要求。
所开发的软件产品是否可以交付，要预先设定质量指标，并进行测试，只有符合预先设定的指标，才可以交付。
对不符合要求的产品的识别和控制：
对于软件测试中发现的软件缺陷，要认真记录它们的属性和处理措施，并进行跟踪，直至最终解决。
在排除软件缺陷之后，要再次进行验证。
产品设计和开发的验证：
通过设计测试用例对需求分析、软件设计、程序代码进行验证，确保程序代码与软件设计说明书的一致，以及软件设计说明书与需求规格说明书的一致。
对于验证中发现的不合格现象，同样要认真记录和处理，并跟踪解决。
解决之后，也要再次进行验证。
软件过程的监视和测量：
从软件测试中可以获取大量关于软件过程及其结果的数据和信息，它们可用于判断这些过程的有效性，为软件过程的正常运行和持续改进提供决策依据。
一般应用过程方法和系统方法来建立软件测试管理体系，也就是把测试管理作为一个系统，对组成这个系统的各个过程加以识别和管理，以实现设定的系统目标。
同时要使这些过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。
其主要目标是在设定的条件限制下，尽可能发现和排除软件缺陷。
测试系统主要由下面6个相互关联、相互作用的过程组成：
测试规划、测试设计、测试实施、配置管理、资源管理和测试管理；确定这些过程的顺序和相互作用，前一过程的输出是后一过程的输入。
其中，配置管理和资源管理是这些过程的支持性过程，测试管理则对其他测试过程进行监视、测试和管理；确定这些过程所需的准则和方法，一般应制订这些过程形成文件的程序，以及监视、测量和控制的准则和方法；确保可以获得必要的资源和信息，以支持这些过程的运行和对它们的监测；监视、测量和分析这些过程；实施必要的改进措施。
4.2建立配置管理系统，规范项目管理流程
建立配置管理系统CVS，CVS的全称是CurrentVersionControl。
在软件质量体系的诸多支持活动中，配置管理系统处在支持活动的中心位置，它有机地把其它支持活动结合起来，形成一个整体，相互促进，相互影响，有力地保证了质量体系的实施。
建立公司配置管理系统很容易得到公司领导层的支持，几乎没人反对。
更重要的是建立配置管理系统后测试人员的工作有了系统保证，测试工作的“矿藏资源”有了明确的位置，可以主动积极开展测试工作。
4.3测试过程分阶段执行
将测试过程分成几个阶段执行，即：
代码审查、单元测试、集成测试、确认测试和系统测试。
单元测试是针对软件设计的最小单位-模块进行正确性检验的测试工作，其目的在于发现各模块内部可能存在的各种差错。
在单元测试之后，需要按照设计时做出的结构图，将它们联结起来，进行集成测试。
是检验所开发的软件是否按用户要求运行。
确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
软件开发完成后，还要与系统中其他部分配套运行，进行系统测试，包括恢复测试、安全测试、强度测试和性能测试等。
4.4做好过程管理
过程管理须做好以下工作：
分阶段设立里程碑，按里程碑计划工作和总结工作；加强审核，测试过程的中间结果要进行充分的审核；注重风险管理和规避风险，任何决定和过程都存在风险，尤其是质量好坏的风险，通过审核管理风险。
4.5制定成功的测试管理计划及测试计划
一个成功的测试开始于一个全面的测试管理计划。
因此在每次测试之前应做好详细的测试管理计划：
首先，应该了解被测对象的基本信息，选择测试的标准级别，明确测试管理计划标识和测试管理项。
在定义了被测对象的测试管理目标、范围后必须确定测试管理所使用的方法，即提供技术性的Ali试管理策略和测试管理过程。
在测试管理计划中管理者应该全面了解被测试对象的系统方法、语言特征、结构特点、操作方法和特殊需求等，以便确定必要的侧试环境，包括测试硬件/软件及测试环境的建立等等。
而且.在测试管理计划中还应该制订一份详细的进度计划如：
侧试管理的开始段、中间段、结束段及测试管理过程每个部分的负责人等。
由于任何一个软件不可能没有缺陷、系统运行时不出现故障，所以在测试管理计划中还必须考虑到一些意外情况、也就是说，当问题发生时应如何处理。
因为测试管理具有一定难度，所以对测试管理者应进行必要的测试设计、工具、环境等的培训。
最后，还必须确定认可和审议测试管理计划的负责人员。
还需要一个成功的测试计划，专业的测试必须以一个好的测试计划作为基础。
尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。
测试的计划应该作为测试的起始步骤和重要环节。
一个测试计划应包括：
产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。
4.6测试人员及早介入
测试人员应从软件生命周期的需求阶段就开始介入，这样可以在这些需求基础上生成一份测试计划，并将测试用例对应于需求。
这样便于提高测试用例的有效性和可用性，并且方便测试用例的设计和管理。
4.7测试文件的使用
在软件的需求分析阶段，就开始测试文件的编制工作，各种测试文件的编写应按一定的格式进行。
测试文件的重要性表现在以下几个方面：
a、验证需求的正确性：
测试文件中规定了用以验证软件需求的测试条件，研究这些测试条件对弄清用户需求的意图是十分有益的。
b、检验测试资源：
测试计划不仅要用文件的形式把测试过程规定下来，还应说明测试工作必不可少的资源，进而检验这些资源是否可以得到，即它的可用性如何。
如果某个测试计划已经编写出来，但所需资源仍未落实，那就必须及早解决。
c、明确任务的风险：
有了测试计划，就可以弄清
升级会员 