测试管理中可能存在的问题及分析(3)

　　软件测试件管理通俗地讲就是指努力建设好测试团队的财富库并对测试团队成员进行技能培训以帮助他们能使用好这个财富库。这里，财富库是指软件测试件。测试件(Testware，指测试工作形成的产品)是一个不常见到的词汇，它包括是测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广至通用的测试脚本程序。测试件管理工作做得越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递就越充分，测试脚本或规格文档的重复开发工作也就能被有效地避免。软件测试件管理工作包括两部分，一是建设，另一个是培训。建设工作大抵是收集各类测试外文档、测试工具、测试脚本，也包括收集整理测试人员的会议发言、总结报告、技术心得等等。培训工作大抵是通过技术讲座、正式或非正式团队会议、印发学习资料等形式进行。

　　2.3 软件测试管理内容

　　具体的测试管理内容有：

　　1)测试方案管理：单元测试、集成测试和产品测试的测试计划的录入、修改、删除、查询和打印。

　　2)测试案例管理

　　测试案例的增、删、改、拷贝和查询;

　　测试案例测试情况的管理，如测试状态包括：未测试、测试中、已测试;

　　测试结果分为：通过、未实现、存在问题等;

　　测试案例输人、编号和归档。

　　3)测试流程管理：测试进度管理;测试流程标识;测试日志及状态报告。

　　4)问题报告管理：问题报告处理流程(问题报告、整改报告)、实现问题报告与测试案例的关联。

　　5)测试报告管理：生成单元测试、集成测试和产品测试的测试报告。

　　除了以上这些，在侧试管理过程中还应对人员和环境资源进行管理。

　　3、测试及测试管理中的问题及分析

　　通过以上的简单总结与分析，可以看到软件测试及测试管理的重要性，及其复杂、广泛的组织管理工作，所以在实施起来，难免与理论有些出入。另外，国内的软件企业大多起步晚，技术基础薄弱，应用与管理经验缺乏，在测试上更是如此。于是国内的一些中小型的软件企业，在软件测试方面存在诸多问题，不仅与理论要求相差甚远，与实际的应用需求也相差很多。下面将简要介绍与分析当前国内中小型软件企业在测试及测试管理中存在的问题和问题原因，并在之后提出一些解决办法。

　　3.1 软件本身的复杂性与企业自身的不足

　　这里复杂性包括软件用户需求的复杂与难确定性，软件开发过程的组织管理的难控制性等，使得软件开发过程必然会存在诸多问题，开发出的产品也必然存在一些缺陷与不足。而由于生产与管理经验的不足，缺乏高效的开发与测试团队，往往是开发人员又是测试人员，或测试人员质量管理;缺乏有效的测试技术，代码走查室最常用的方法;测试开始较晚，往往在开发完成之后;对用户反馈信息缺乏整理总结等;使得不仅难以控制产品的缺陷数量，而且对于缺陷的定位与修补也很难到位。

　　3.2 测试的特性

　　3.2.1 测试是不完全的(测试不完全)

　　由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。

　　3.2.2 测试具有免疫性(软件缺陷免疫性)

　　软件缺陷与病毒一样具有可怕的“免疫性”，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试必须采用不同的测试方式和测试数据，应该尽可能的多采用多种途径进行测试。

　　3.2.3 测试是“泛型概念”(全程测试)

　　如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住“软件缺陷具有生育能力”。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为：需求测试和设计测试)的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理)，即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。

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