发布时间：2022-04-28 04:23:38
开篇：写作不仅是一种记录，更是一种创造，它让我们能够捕捉那些稍纵即逝的灵感，将它们永久地定格在纸上。下面是小编精心整理的1篇软件测试论文，希望这些内容能成为您创作过程中的良师益友，陪伴您不断探索和进步。
软件测试是一项需具有较强专业技术、学习和创新能力的工作,软件测试人员必须要具有缜密的逻辑思维能力、全面的技术能力、敢想敢干的创新能力,要有较强的责任心和团队合作精神以及出色的沟通能力等专业素质。
国家示范性软件学院的一个重要职责就是要在教学研究、教学实践以及教学改革方面进行大胆的探索和实践。因此,在完善已有课程体系及授课的同时,应该充分利用优秀的教学资源,总结教学经验和科研成果,编写专业教材,力争探索出一条为国家快速培养高素质软件工程人才之路。
北京工业大学软件学院蔡建平教授长期从事软件工程、软件测试及软件质量保证的研究,在多年讲授软件测试课程经验和体会的基础上,对软件测试课程教学内的知识点进行调整、补充和完善等方面的改革,针对软件质量评价和软件高可靠性的要求,针对国内软件研发和测试外包的本地化要求,以及针对软件测试用于各种应用领域的要求选择授课的知识点,并取得了较好的效果。
目前国内关于软件测试的书籍较多,其中很多书籍是翻译的、为培训用的或介绍软件测试技术和方法,作为教材满足各类测试人员的学习还有一定的距离。本书是在作者长达二十几年软件工程、软件测试和软件质量保证实践经验和教学经验的基础上,借鉴前人成果,参考当前软件测试方法和技术应用实践案例进行编写的。蔡建平教授编写的《软件测试大学教程》一书,以现代软件测试需求为背景,以现代软件测试技术和方法为基础,以当前软件测试通常应用为典型实例,从软件危机及软件缺陷开始,全面介绍软件测试的基本概念,软件测试的技术、方法和工具应用,以及软件测试在当前主流应用中的具体开展和实施。
其特点如下:
(1) 内容全面。突出全生命周期软件测试概念、软件质量分析手段、现代软件测试技术、主流测试工具应用以及典型应用测试方法等,帮助学生了解和掌握现代软件测试的各种原理、方法和技术,并能够选择合适的软件测试工具进行相关测试。为培养学生今后成为高素质、专业化的软件测试人才打下基础。
(2) 针对性强。针对软件开发方法和技术的发展变化,针对我国软件外包服务的蓬勃兴起,针对我国国防工业如航空、航天、船舶、电子、通讯等大量重要软件或关键软件的实际应用情况和测试需求,特别是对软件高可靠性的要求,选择教材的知识点。
(3) 重实践性。该书对支撑现代软件测试技术应用的测试工具进行了全面地介绍,特别是对开源软件测试工具的介绍,这对高校开设软件测试实验课程是非常有意义的。在教材中给出了软件测试在几个典型应用领域具体实施的要点和注意事项,这对缺乏实践经验的培养对象而言具有极好的引领作用,对开阔软件测试人员的眼界、思路和具体实践有很大帮助。
(4) 具前瞻性。书中不少内容取材于互联网,在一定程度上体现了软件测试技术的最新发展,具有较强的新颖性和现代性。
该书取材新颖、内容翔实、通俗易懂、技术实用、覆盖面广、指导性强,对重点、难点阐述透彻,使其既可以符合现代软件测试技术发展的潮流,又具有相对的稳定性,还易于剪裁,以满足各类符合软件测试课程的教学需要和各类软件测试人员的学习需要,同时能够较好的满足国内企业,特别是国内各种测评机构或组织对现代软件测试人才培养的要求。
该书在现代软件测试技术的教学、普及、推广和软件测试人才培养以及软件测试教学知识体系的建立等方面进行了很好的探索。它的出版有助于国内软件测试人员和计算机相关专业的本科生及研究生的培养,有益于推动现代软件测试技术和方法的研究、教学和实践的进一步发展,同时对我国软件测试的发展起到积极的促进作用。
摘要：针对软件行业人才供需矛盾和传统教学模式局限性，分析问题原因，介绍项目驱动教学法的内涵和实施办法，探讨基于项目驱动的软件测试人才培养模式，从理论教学体系的改革、实践教学体系的建设和3+1教学模式的实施进行深入探索。
关键词：项目驱动教学法；软件测试人才；培养模式；实践教学
随着软件业的迅猛发展，软件产品的质量控制与质量管理正逐渐成为企业生存与发展的优秀。作为软件产品质量控制与质量管理者，软件测试工程师成为软件开发企业必不可少的技术人才。近年来，软件人才市场存在一种普遍现象：高校培养的软件人才大多找不到合适的岗位，而软件企业又招不到合适的人才。其根本原因在于学校的教育培养模式不能很好地适应人才市场的需求[1]。软件测试人才的教育应该以培养多层次、应用型、复合型软件测试人才为目标，全面加强素质教育，重点培养学生的敬业精神、创新能力和实践能力，真正实现人才培养与市场需求的一致。传统的教学模式在一定程度上已经不能适应新时期人才培养的需要，本文提出了基于项目驱动的软件测试人才培养模式。
1项目驱动教学法的内涵
传统的教学模式按照课程的知识结构组织教学，按章节讲述，学生由浅入深逐步掌握知识和技能，然后将知识和技能应用于实践。其优点是注重知识的内部体系结构，逻辑性较强，学生循序渐进地学习知识。但这种教学模式不利于培养学生的实践技能和综合素质，导致学生实践基础薄弱、适应性差，严重制约学生创新能力的发挥，学生难以适应工程技术快速发展的要求。
项目驱动教学法来源于建构主义学习理论，与其相适应的项目驱动教学模式是以学生为中心、教师为主导，利用项目创建的情境、协作、会话、操作等学习环境要素充分发挥学生的主动性、积极性和创新精神，使学生有效地建构所学知识，增强实践能力[2]。项目驱动教学法在教学过程中以项目为主线展开，把相关知识点融入到项目的各个环节中去，层层推进项目。通过对问题的深化或功能扩充，来拓宽知识的广度和深度，直至得到一个完整的项目的解决方案，从而达到学习知识、培养能力的目的。在这种模式中，教师根据学生已有的经验、知识、水平和兴趣来选取适合的项目，使学生置身于探索知识的情境之中，综合运用知识和技能解决实际问题，并在真实的项目流程中体验项目管理的思想和团队协作精神，提升创新和实践能力。
2项目驱动教学法的实施
实施项目教学法，首先需要设计项目。项目的设计与选取直接影响到该教学模式的教学效果及学生的学习兴趣，因此在设计项目时应遵循以下几条原则：
1) 项目涉及的知识面广。项目应涵盖课程的主要知识要点和基本技能。
2) 项目大小和难易适中。每个项目组的人数控制在3～5个人，设计的项目能使学生通过努力在一定的时间内完成。
3) 项目中任务顺序合理。项目各个任务的顺序，一方面要体现实际工作中解决问题的工作流程；另一方面要体现知识技能由浅入深的循序递进。
4) 项目具有典型性。项目教学法中选择的项目就是学生将来走向工作岗位可能要完成的实际工作任务，学校的学习就是将来实战的摸拟演练，使学生的知识技能轻易就可以迁移到实际工作中去。
5) 项目规范性。项目开展过程中，每个阶段的工作都应在文档中体现出来，文档撰写有严格的标准和规范[3]。
项目驱动教学法在理论课程和实践课程的实施过程中所不同。
2.1项目驱动在理论课程中的实施
在理论课程中实施项目教学法需注重知识的串联。教学过程中，教师不必在课程的基础知识和基本技能讲解清楚后，再进行项目教学，而是可以直接面对具体任务，在教师带领学生分析解决每个具体任务的方法时，将相关联的知识技能要点串联起来，讲解清楚，并让学生理解透彻。由于完成一个具体任务的方法有多种，教师可只讲解一种最实用的方法，其他方法可作为知识技能拓展，以讨论、课内课外作业的方式由学生自行完成。因为新知识新技能的学习是在解决具体的工作任务过程中进行的，这样做，学生学习兴趣浓厚，知识技能掌握牢固，而且容易迁移。在串联知识技能要点时，教师要按照“实用”的原则，与完成具体工作任务无关的知识技能只作简单提示，同时，引导学生自主地查阅文献和资料的方式来学习，此外，教师在进行项目教学时还要引导学生对知识和技能进行举一反三、触类旁通的迁移。
2.2项目驱动在实践课程中的实施
在实践教学中，教师给学生的项目就是一个大任务，教师将项目分解成一个个小任务，学生则主动去求解每一个小任务，探究性地学习相关的知识和技能，在知识的运用中掌握实践技能。通过任务的实施和完成，学生可以体验到一种强烈的成就感。这种成就感会进一步增强学生的学习兴趣，促使学生更加积极主动地去探究性地学习。
项目驱动教学法的实施必须注重学生开展项目的全过程，必须严格按照项目的具体实施流程进行，比如软件测试项目必须按照测试计划、测试设计、测试执行和测试结果分析等来进行，每个阶段的工作必须有撰写规范的技术报告。
实施项目教学法时，教师应高度重视对学生作品的评价。从表面上看，项目教学的结果只是学生完成项目后产生的作品，而实际上，它体现的是学生对相关知识技能的掌握水平。教师在评价学生作品时既要看学生的作品完成的质量，又要看学生的操作过程是否规范实用，对任务完成优秀的个人或团队应给予特别鼓励。
3项目驱动的软件测试人才培养模式
项目驱动教学法非常重视学生的主体活动，强调理论联系实际，培养学生综合解决问题的能力，增强团队协作精神，提高项目管理能力，这与软件测试人才培养目标相一致。使用项目驱动法进行软件测试人才培养，需要从各个教学环节进行改革和创新。
3.1理论教学体系的改革
在软件测试课程体系构建时，我们将软件测试人才培养定位于造就熟悉软硬件基础理论和测试相关知识、掌握软件测试基本技能、具有良好发展潜质和行业特色的高级专门人才。
3.1.1课程群的建设
以课程群的方式构建理论教学体系。课程群是指以现代教育思想和理论为指导，围绕同一专业或不同专业的人才培养目标要求，为完善相应专业学生的知识、能力、素质结构，将相应专业培养方案中的知识、方法、问题等方面具有逻辑联系的若干课程重新规划、整合构建而成的有机的课程系统[4]。课程群建设具有建设集约化、系统开放性、成员团队化等特点，它是以学生的培养为主线、以课程的逻辑联系为纽带、以教师团队合作为支撑、以质量效益为目标的新型课程建设模式。软件测试人才培养课程可分为六个课程群：公共基础、计算机软硬件基础、算法分析与设计、软件工程、程序设计与开发、软件测试技术，不同教师团队分别承担相应课程群的教学和课程建设。
3.1.2在课程群中推广测试思想
将软件测试的思想深入广泛地渗透到所有的专业课程中。在各类程序设计语言基础课程中引入单元测试的思想，并在实验教学中对程序进行单元测试。在软件工程和软件项目管理等课程中，强调软件质量保障和软件测试的重要性，增强软件质量管理意识。在面向对象分析与设计和UML建模等课程中，引入测试驱动开发的思想，强调测试与设计并重。在软件工程专业综合实验中，按照软件测试模型开展实验，进行软件项目管理和软件测试。在毕业设计中，学生开发的软件系统必须进行全面、系统的测试。
3.2实践教学体系的建设
使用项目驱动教学法分层次构建各类实践教学，分步骤分阶段实施各类实践教学活动。
1) 基础实验。
在基础实验教学中，根据课程知识结构设计实验内容，然后按照软件工程 “分而治之”的思想，将一个大的项目按实验内容的要求分解为多个实验，在每个实验中设计任务和目标，使学生可以由浅入深循序渐进地掌握基础知识和技能，为下一步综合实验打下基础。
2) 综合实验。
将软件测试的V模型或W模型引入到综合实验教学中，按照软件工程的流程开展软件设计、开发、测试、管理的全过程训练。根据V模型或W模型的各阶段划分和分配训练任务，使软件开发、测试和管理的综合训练融为一体。通过模型的实施，分阶段、分步骤地训练学生需求分析、概要设计、详细设计、编码、单元测试、集成测试和系统测试各阶段的计划、设计、实施、评估、报告等内容，培养学生全方位的软件开发、测试和管理的全过程能力。在实验实施过程中，将学生分组，采用软件项目组的模式开展项目。根据项目划分不同小组，在小组中为每位成员分配任务，分别完成设计、开发、测试等各个阶段的任务，以提高学生对软件开发全过程的认识，培养学生软件开发综合应用能力，增强软件项目管理能力和团队协作精神，进一步培养工程素养。
3) 学生科技活动。
以培养学生实践能力和创新能力为目标，建设与课内教学和生产实际相融合的创新实践基地，搭建完善的软件开发和测试平台，将学生置于一个更真实的、富有实践机遇和挑战的实践环境中。以学生为主体、教师为主导、课内与课外结合、建设学生团队和指导教师团队。学生通过申报实验室开放基金和软件开发项目，以软件项目为载体，任务为驱动，参与学生科技活动。通过软件项目的实施，提高学生交流沟通水平和团队协作精神；通过做事培养学生科学精神和敬业精神；通过做事培养学生专业技能和工程素养，增强创新能力和实践能力。
4) 毕业设计。
毕业设计是培养学生科学研究能力、工程实践能力、创新能力，提高综合素质和获取工作经验的重要手段。毕业设计选题要尽可能结合生产、科研和实验室建设的实际任务，减少虚拟题目的数量。题目可根据各专业的特点，结合教师的横向与纵向课题进行课题的选择、细化，使之成为符合学生毕业设计的课题。毕业设计完成的软件作品必须进行全面系统的软件测试，提高毕业设计作品的质量。
3.3 “3+1”教学模式的实施
为更深入开展和实施基于项目的软件测试人才培养模式，引入“3+1”教学模式。“3＋1”的教学模式就是学生在大学的前三年在学校学习，最后一年在企业实训。“3＋1”的教学模式是由学校和企业联合办学，培养专门化的技术人才[5]。该模式计划大学前三年在高校学习基础理论知识，最后一年在企业进行实践教学的培养，利用企业的高级工程技术人员和设备进行实地教学。“3＋1”教学模式从工程技术发展和终身教育的需要出发，通过深化课程教学体系改革，强化学生的实践能力，增强学生综合素质，大大开拓了学生视野[6]。为了培养具有创新精神与创业意识、基础扎实、知识全面，适应IT产业和经济信息全球化竞争的高层次、复合型、应用型优秀人才，学院从2009年开始对软件工程专业部分学生实施“3+1”培养方案。与以前的人才培养方案相比，大幅度增加了基础教学时间，减少了专业教学时间，明显拓宽了专业口径，淡化了专业界限，增强了社会适应性。
4结语
通过项目驱动的软件测试人才培养模式改革与实践，学院教学改革已取得了实质性进展和初步积累，学生创新和实践能力明显提高，创新成果明显增加。如果要广泛深入采用项目驱动教学模式，我们还需要不断探索创新。为使社会需求和高校的人才培养无缝对接，我们还需要不断寻求更好的人才培养模式。
摘要：针对软件测试课程教学中缺乏系统实例、重技术实现轻文档工作、测试工具使用流于产品说明等问题，文章就探索实验教学进度和内容进行了论述。依据实际软件开发过程中软件测试实施的方式方法，提出设计一套系统的软件测试实验内容。文章还阐述了在教学过程中采用案例教学法，提供给学生完整的案例系统及充分的设计文档，让学生学会根据设计文档书写测试文档、掌握测试工具的使用及自动化测试工具的开发。
关键词：案例教学法；软件测试过程；测试文档
目前我国软件测试人才严重匮乏，人才缺口达到30万，造成这一结果的主要原因是国内软件测试人才教育相对滞后[1]。但实际上，很多学习了软件测试课程的学生却找不到工作，业内专家称之为人才的“结构性过剩”[2]，而滞后的原因不仅仅是教育机构开设软件测试课程时间的滞后，主要是教学内容和教学效果与实际需要的差距产生的滞后。外包开发行业快速发展，对人才在代码和文档方面的规范性、技能和工具的熟练程度要求越来越高[2]，而这些要求正是软件测试人才教育的薄弱环节。因此，如何顺应市场需求，培养出企业所需的软件测试人员，成为软件测试课程改革创新的目标。
1教学现状
随着软件测试人员市场需求的不断增加，各大高校、职业技术学校及IT培训机构纷纷开设了“软件测试”课程。然而，在师资方面，讲授软件测试课程的教师多数是由软件工程的教师承担，这些主讲教师能很好地讲解软件测试理论和介绍软件测试方法，但缺乏软件测试的系统案例和软件测试经验[3]。在理论教材方面，虽然各种软件测试的教材相继出版发行，但教材中技术实现的内容较多，对常用的软件测试文档书写介绍很少，且缺乏文档模板；对自动化测试工具，基本也是简略介绍其功能。在实验教材方面，目前还没有配套的软件测试实验教材问世，在教学过程中基本是任课教师自行设计实验教学内容。对于实践性较强的课程，主讲教师如果没有大量的实际项目开发经验作为支撑，就难于用恰当的实例来解释相关理论，更难设计出实用有效的实验内容，导致在校学习的知识与实际工作脱节的现象。要顺应软件测试人才市场的需求，软件测试课程的教学必须面向企业的实际需要，使学生能学到实际工作中常用的技能，以“经验者”的身份进入人才市场参与竞争。
2改革和创新
笔者以日企工程经验为依据，针对软件测试课程教学中缺乏系统案例、重技术实现轻文档工作、测试工具流于产品说明等问题[4]，设计了一套软件测试实验，帮助学生利用软件测试技术搭建测试环境；根据测试规格说明书进行测试；练习测试用例的设计、执行与跟踪并高效地进行回归测试；熟悉常用测试文档的书写方法；掌握如何保存测试用例和有效的测试结果；准确地书写缺陷报告；通过思考题的方式启发学生利用计算机技术开发自动化测试工具。
2.1教学进度的调整
计算机课程的实验教学，通常和理论课同步或延迟几周进行。对于软件测试这门课程的实验教学，如果与理论课同步进行，前期的实验内容安排就缺乏理论支持，如果比理论课迟后几次，即在讲述白盒测试和黑盒测试后开始实验教学，就可以将各种测试方法融入实验中进行，但由于软件测试过程及技术、测试文档书写相关内容还未讲述，实验内容的安排显得孤立，没有整体感。为了让学生体验软件测试在实际工作环境中的实施过程，将理论课讲述的知识有机地融入到完整的案例中进行实验，就需要系统地学习完理论知识后，再结合实际案例系统地进行实验。
我们打破传统的周四学时，即“理论2+实验2”的排课模式，将一个学期分为理论上半学期，实验下半学期，上半学期周四学时用于结合案例进行理论教学，下半学期周四学时针对理论课讲述的案例进行实验教学，以便学生能够模拟实际工作环境进行系统的软件测试实验。
2.2实验教学的创新
2.2.1实验素材的创新
现有的软件测试教材，通常会在最后章节给出一个案例，针对该案例利用教材上介绍的各种测试方法有针对性地进行测试用例设计。但是教材对案例的描述基本只限于项目背景介绍、子系统介绍、子系统功能分析、子系统性能及可用性要求方面的资料，基本没有提供可运行案例系统的代码，同时也缺乏必要的供测试使用的文档。实际工作中，软件测试过程与软件设计周期有相互对应的关系，软件测试过程中的单元测试、集成测试、系统测试、验收测试分别对应软件设计中的详细设计、概要设计、系统设计和需求分析[5]。因此，要完成一个系统的较完整测试过程，不仅要提供被测系统的完整代码及数据，还必须提供全套的设计文档。
我们以一个开发完整的以C/S模式实现的“小区物业管理系统”和B/S模式实现的“图书馆管理系统”作为测试案例，在理论课教学中主要以“小区物业管理系统”作为案例进行理论知识的讲解，与网站测试和面向对象测试相关的内容以“图书馆管理系统”作为案例进行讲解。这样，进行完理论教学，学生对案例系统的功能基本了解。在实验教学中，我们提供给学生在测试中需要的代码、开发规范、需求分析、系统设计书、概要设计书、详细设计书，具备了以上资料，便可模拟实际工作模式，将理论教学中讲述的测试策略和方法、测试文档的书写方法运用到该案例的测试实验中。
2.2.2实验内容的创新
由于实验教学学时和学生能力的限制，在本实验的设计中，我们主要针对初、中级测试工程师级别设计实验内容，这些实验内容就是同学们踏上测试岗位要动手干的实际工作。而针对高级测试工程师和测试管理者担当的工作，比如测试计划的制作、各种设计的验证、测试评估和总结，需要经历初中级测试工程师的实战，积累大量经验才能承担，这一部分内容，我们只在理论教学中简单讲述，不在实验教学中安排实验内容。
我们设计了表1所示的实验内容，本设计旨在让学生经过实验的训练，以“经验者”的角色参与求职应聘，因此，我们以项目管理者培养“新人”的方式来安排实验内容和进度。虽然软件测试贯穿于软件生命周期的全过程，但对于刚毕业的大学生来说，从人才培养角度出发，项目管理者通常是按照以下流程在工作过程中培养人才：单纯性测试的实施、测试设计(书写测试规格说明书)、测试环境搭建等，按照单元测试、集成测试、系统测试的顺序循序渐进地深入测试工作，因此我们按如下进度设计了以下实验内容，并在提供的素材中人为地制造缺陷，以便学生发现缺陷、分析缺陷、修改缺陷。
通过上述8个实验，让学生牢固掌握单元测试和集成测试的设计和实现方法，了解常用测试工具的使用方法，同时对系统测试实施有基本了解。严格经过这8个实验的训练，学生基本能以初级测试工程师的身份投入到测试工作中。
2.2.3实验过程的创新
为提高实验教学效果，有的放矢地做好每一次实验，我们将每次实验分为四个阶段。第一阶段是以学生为主体的实验预习，要求学生进入实验室之前明确实验目的、内容，并以书面形式完成实验步骤设计及实验时间分配；第二阶段是以教师为主体的实验概述，用10分钟的时间结合理论内容讲解实验涉及的知识点、实验素材的作用及注意事项；第三阶段是以学生为主体的实验实施，实施过程中教师随堂抽检学生进行状况，对个别问题个别提示，普遍问题全体提示，并解答实验中学生遇到的问题；第四阶段是以教师为主体的实验总结，教师对实验过程中遇到的问题进行分析总结，选择较好的实验成果进行点评，最后结合本次实验，引出思考题，提示学生灵活应用计算机专业知识，进行自动化测试的探索和创新。
摘要:从目前国内研究生“软件测试理论与技术”课程教学实际出发,在分析目前国内研究生学习基础、学习需求及学习能力的基础上,提出一种紧密结合测试案例、测试理论与实践交叉进行的教学新方法。
关键词:研究生教学;软件测试;测试案例;交叉教学;测试实践
随着国家信息化建设步伐的不断加快,软件日益成为信息系统中极为重要的组成部分。软件的可信性已倍受关注,目前软件测试仍然是保障和提高软件质量的一种有效方法。同时随着国内软件产业的标准化与国际化,越来越需要专门的软件测试高级人才。当前高校仍然是培养软件测试专业人才的重要机构。
目前我国高校开设软件测试课程按学历分主要有三个层次:大专、本科与研究生阶段。大专和本科阶段的软件测试课程在我国已经开设有较长时间了,主要是教授基本的软件测试理论与技术,侧重以基础知识为优秀。一些高校已经摸索出一些好的教学经验和方法,发表了一些教学体会[1-3]。但是,研究生(本文特指硕士研究生,下同)阶段的软件测试课程教学却面临很多新的问题。特别是随着近几年高校研究生招生规模的扩大及招生形式的多样化,各高校研究生生源相差较大,学习目的与培养形式也有所差异,使得研究生的软件测试课程教学很难采取统一标准,给各校任课老师提出了新的挑战。从我校研究生软件测试课程教学实际出发,笔者分析了近年来研究生在学习基础、学习能力及学习目的上的诸多变化,提出了一种“紧密结合测试案例、测试理论与实践交叉进行”的软件测试教学新方法。该方法连续实施在两级研究生的教学实践中,从课堂反应、课程考核、案例测试实践指标来看,该方法较大程度地激发学生的学习兴趣,提高了研究生测试理论知识及实践测试动手能力。
1传统教学及面临的新问题
1.1传统的研究生软件测试教学形式
2010年5月我们参加了第四届全国软件工程领域硕士培养工作研讨会,与会期间我们和软件测试同行进行了广泛的交流。大部分院校认为软件测试教学大纲仍然沿用研究生招生改革之前的大纲,即教学对象为传统的学术型研究生,课程教学仍然以理论教学为主,教学内容也以书本为主,按章节进行教学。课程结束考试仍以论文报告的形式完成。总结大部分高校共同的教学内容有:
1) 软件测试概述;
2) 测试人员的离散数学;
3) 测试人员的图论;
4) 功能性测试;
5) 结构式性测试;
6) 集成测试;
7) 系统测试;
8) 面向对象测试等。
传统教学以教授学生理论知识为主,旨在培养懂理论的学术型研究生。未考虑学生的水平、学习需求、学习目的及学习能力等因素的差异,导致相当一部分同学失去学习兴趣。此外教学过程没有测试案例及其他实践测试环节,导致总体教学效果不理想,课程结束后大部分同学均没有掌握基本的软件测试理论与技术。
1.2研究生教学的新特点
随着近年来国家研究生招生及培养方式的改革,研究生的招生规模、招生形式及培养方案等均变化较大。以前是以工学硕士为主,重点培养懂理论、会创新的高级学术型研究人才。近年来,国家硕士研究生招生已细分为工学硕士及工程硕士,工学硕士又分为学术型与应用型。工程硕士和应用型硕士侧重于培养工程开发、工程应用、工程管理等应用创新型高级人才。研究生招生及培养制度的改革促使培养方案不一样,相应的课程大纲及教学方式也应不一样。故研究生软件测试课程教学面临的主要特点有:
1) 理论与实践并重;
2) 加强工程案例的测试教学;
3) 激发学生兴趣,互动教学;
4) 侧重于培养学生的实际测试动手能力。
现阶段研究生软件测试课程应考虑所有选修学生的学习基础、学习需求、学习目的及学习能力的多
样化,重点学习以下内容:常用软件功能性测试方法;面向对象程序测试技术;WEB软件测试;错误注入测试技术;安全性测试、主流软件自动化测试工具及大公司常用测试方法等。通过课程的学习,使学生较好地掌握软件测试理论、先进的软件测试技术和主流测试工具,并能较好地应用于实际软件工程项目中。
2案例交叉教学法大纲及其教学过程
基于研究生培养方案的诸多变化,我们提出了一种紧密结合测试案例、测试理论与实践交叉进行的教学新方法。该方法以学生为中心,旨在激发学生的学习兴趣,提高学生的理论知识和实际案例测试能力。
2.1江苏大学研究生软件测试教学大纲
表1是我校现行的研究生软件测试教学大纲,全校理工科研究生也可选修。
2.2案例交叉教学法教学过程
案例交叉教学法总体分成两个阶段:课前案例程序编写和课堂理论与案例交叉教学。
第一阶段:课前案例程序编写。上课前一周布置实现两个测试案例,每学期难度类型与之类似。
案例1:使用C、C++或C#语言编写一个程序,计算任意两个正整数a,b的最大公因数,其中0≤a,b≤1060。并撰写程序设计说明书。
案例2:使用ASP或JSP技术,数据库SQL Server实现具有用户注册、登陆验证的简单B/S结构系统。
当然,可以根据不同学生的水平布置不同的案例程序,要求所布置程序难度、功能和工作量与案例1和2相当,即案例1满足后期单元测试、功能测试、类测试、错误注入测试、安全测试及编写测试驱动等测试需求,案例2满足后期GUI测试、WEB测试、错误注入测试、安全测试及测试工具的教学等测试需求。
第二阶段:课堂理论与案例交叉教学。结合前面两个案例,自第二章开始结合测试案例、测试理论与实践交叉进行教学。具体教学流程如图1所示。
图1案例交叉教学流程图
图1中,S1代表第1章,其它类似。案例1重点是让学生掌握基于程序结构的测试方法,如边界值测试、等价类测试、类测试、数据流与控制流测试方法等。案例2重点让学生掌握基于程序规格说明的测试方法,如GUI测试、错误注入测试及基于状态的测试等方法。此外,结合案例1和2,不但教授学生重要的功能性测试方法,而且教授学生一些关于软件安全
性、可靠性及稳定性的测试思路,全面提高学生的综合测试能力。
此外,我们的教学过程中将联系国内外大型软件企业的实际测试方法及测试工具。如我们选用的教材之一便是微软软件测试工程师们撰写的教程,所讲授是主流自动化测试工具系列:Parasoft公司AEP方案系列、Mercury Interactive公司系列及IBM Rational系
列。重点讲授的自动化测试工具主要有:Parasoft C++Test;Mercury公司主要产品LoadRunner、WinRunner、TestDirector、QuickTestPro、IBM Rational Purify等。同时将结合程序案例1、2及其他大型测试案例进行工具的演示教学。
3教学效果分析
我们连续对两级研究生运用了案例交叉教学法,在课程结束后对50名学生进行了问卷调查,同时结合学生考试成绩及课程测试报告情况,结果表明案例交叉教学法教学效果明显好于传统的按章节教学方法。表2从学生兴趣、理论掌握度、测试用例设计、测试驱动编写、测试方案设计、测试思想及自动化测试工具的掌握等方面进行了教学效果对比分析。
学生问卷调查中的学生兴趣度以调查结果为主,其他调查项均以课程考核结果为主,调查结果为参
照。在课程期末考核中除了考查常规的测试基本理论与技术之外,同时还要求学生交叉测试其他同学的程序案例,最后撰写测试用例设计报告及程序测试报告。
由表2数据对比分析可知,案例交叉教学法在各方面都明显优于传统的按章节教学法,特别是学生在掌握测试思想及测试自动化工具方面近96%以上的学生掌握较好。
4结语
随着近年来软件企业规模化、正规化及国际化步伐的加快,社会越来越需要大量的专业化高级软件测试人才,这给高等院校及高级软件人才培训机构带来了新的挑战。本文提出了一种紧密结合测试案例、测试理论与实践交叉进行的教学新方法。该方法综合考虑学生的学习要求、学习基础及学习目的等诸多因素,以培养学生的测试兴趣为出发点,以学生自己编写的程序为测试案例,将测试理论、测试技术、测试案例及测试工具结合起来进行教学。课程最后介绍了微软公司常用的一些测试方法。
通过测试能力考核及课后调查表明,绝大部分学生认为新方法教学更有利于他们掌握软件测试基本理论,提高测试案例实践编写能力,特别是学会了主流自动化测试工具的应用。教师们也普遍反映软件测试课程的教学质量和教学效果有明显的提高。
摘要:分析软件测试课程的教学背景,从教学内容、教学资源、教学方法、实践方法、师资建设等方面对软件测试课程的教学改革进行探讨,提出课程建设的具体措施,以期对高校软件测试课程建设具有参考意义。
关键词:软件测试;教学方法;教学改革;课程建设
随着软件产业迅速发展,软件测试的作用越来越重要,地位得到前所未有的提高。软件测试人才需求量剧增,职业价值日益提升。然而在作为软件人才的主要培养渠道――传统的大学计算机教育中,软件测试教育存在很多问题。
首先,在很多高校软件工程相关专业中,没有开设专门的软件测试技术课程,软件测试技术只是作为软件工程的一部分被提及,还有一些学校只是把软件测试技术作为选修课,课时较少,则侧重理论讲解和测试方法介绍,忽视了极为重要的实践环节[1]。而软件测试课程的实践性很强,如果没有实验实训环节支持,只是枯燥地讲解测试理论和方法,会使学生产生抵触和厌学情绪,影响教学效果。同时,测试工具和测试对象都是看不见、摸不着的软件产品,实践课程的组织和实施有较大的难度。由于缺少基础理论知识和系统训练,很多高校毕业生虽然想从事测试工作,却离软件公司对测试人才的要求差距较大,从而被拒之门外。
其次,缺乏讲授软件测试课程的教师。高校软件工程的主讲教师能很好的讲解软件测试理论和测试方法,但缺乏较好的软件测试案例和软件测试经验,而这正是讲授好软件测试课程的关键所在,也是很多老师不愿意上该课程的原因。
第三,学生对软件测试的认识也直接影响他们对软件测试技术的掌握。一些不规范的软件公司往往让新进人员和编程能力较差的人员从事软件测试,这让很多学生片面地认为不会编程序的人才从事软件测试,从而不重视软件测试技术的学习和训练[2]。
在这种情况下,为培养应用型、技能型软件测试人才,我校计算机与信息学院自2005年就在软件工程本科专业中开设了软件测试技术以及相关实践课程,并将其作为该专业的主干课程来建设,在课程的建设方面做了一定的探索,积累了一些经验。
1突出培养目标,完善课程内容新体系
作为一般本科院校,我们的培养目标是为社会输送应用型高级人才。针对软件测试技术课程,教学目标是通过对软件测试技术的理论学习和系统训练,使学生了解软件测试在软件开发过程中的重要作用和地位,理解软件测试的基本概念和基本理论,掌握软件测试技术和方法,能运用软件测试技术解决实际问题,并了解软件测试职业特点及软件测试人员素质要求。按照这一培养目标,我们结合实际,在教学内容和教学资源建设等方面进行了探索。
1.1合理安排教学内容,适应应用型人才培养目标
软件测试技术课程内容应体现传授知识与发展能力相统一,重视能力发展,其结构要与学生认知结构相统一,应以软件测试基本理论为基础,引入案例教学,辅以讨论、报告会等方式,突出实践教学环节。
我们把教学内容分为课堂教学、实验教学和课程设计三大部分,在教学过程中采用案例教学,并增加配套实验和课程设计学时。其中课堂教学在软件工程概论课程结束之后开始,安排在第5学期进行,包括软件测试基本概念、各种测试技术和方法、测试用例的设计、软件测试项目的组织和管理等,共32学时;实验教学同步安排,主要是一些基础实验,包括白盒测试、黑盒测试等,通过学习实践,让学生掌握软件测试最基本的一些方法,共16学时;课程设计安排在第6学期后半学期集中进行,学生自由组合为小组,分角色进行,课程设计强调学生的综合设计和运用能力,主要是让学生掌握各种测试方法在大型项目中的应用,熟悉测试项目中的管理,感受大型测试项目的工作流程,共32学时。
这样安排的课程内容体系,理论与实践教学的比例达到1∶1.5,加强了实用性,使教学内容以应用为重点,循序渐进,深入浅出,课程结构更加合理。
1.2编写多种教学辅助资料,完善配套教学资源
软件测试技术不断发展,课程讲授的内容应该与时俱进,我们不能只局限于教材内容,应在讲解基本原理、基本概念和基本方法的同时,注意增加一些前沿技术的介绍。同时,为配合课堂教学,加强课后指导和实践环节,我们编写了《软件测试技术实验指导》和《软件测试技术课程设计指导书》等内部资料。通过这些资料,巩固、深化课堂教学,启发学生积极思考,提高动手能力,达到举一反三的目的。
此外,为了增大课堂信息量、提高教学水平和效果,我们精心制作了全新的多媒体课件,在授课时充分结合现代教育手段和传统板书,做到重点突出,直观易懂,使课时利用率大大提高;同时还向学生提供大量相关电子文档资料、参考文献和参考网站地址等,使学生可以进行主动性学习。另外,为了便于教师和学生检验学习效果,我们还建立考核系统和题库,搜集了丰富的各种类型题目,并进行了汇总和整理。
2强化实践教学环节,提高学生的动手能力
软件测试技术是一门实践性很强的课程,有效的实践教学是促进知识理解,培养创造力极为重要的一个环节。在实践教学中,我们重点做到“两有、两严、一宽”。“两有”即:有指导,在教师的指导下,学生首先对上机内容进行分析,然后做出合理设计;有目标,对每一部分内容,都有培养学习能力的具体目标。“两严”即:严格要求学生自己动手设计方案并调试,杜绝个别同学拷贝的现象;严格验收和检查,要求学生编写规范化文档,并结合演示,随机抽取提问等手段,使学生在思考―实现―再思考中真正得到提高。“一宽”即为学生提供宽松的学习气氛,鼓励学生发表自己的见解,充分调动学生的主观能动性。
2.1以提高应用能力为出发点,由浅入深、循序渐进地设计实验内容
软件测试作为一门实践性很强的课程,内容众多,包括多种软件测试方法和测试工具的使用。为了保证教学效果,我们按照由浅入深、循序渐进的原则安排了基础性、综合性和设计性3级实验的方案。
其中,基础性实验是较简单操作性实验,主要包括白盒测试和黑盒测试,共8学时,通过学习,让学生掌握软件测试的一些基本方法,加深对理论的理解。综合性实验是对各知识点的综合应用,使学生理解和掌握软件测试技术和各种具体的测试方法在项目中的应用,感受软件测试项目的工作流程和实施细节,共8学时。基础性实验和综合性实验穿插与理论课同步进行,与课堂教学相辅相成,启发学生深入思考,勇于创新,达到理论联系实际的教学效果。最后32学时的设计性实验是本课程最高层次的应用性设计实验,需要学生自主设计、自主管理,分组进行,安排在暑假前的两周集中进行,目的是使学生体会软件测试的规律,熟悉软件测试项目中人员、产品、测试用例及缺陷的管理,锻炼学生的综合能力。
通过3级实验的安排,让学生感受到理论与实践相结合以培养实践能力的重要性,彻底改变重理论、轻实践的传统教学模式。教学实践表明,学生通过3级实验,更牢固地掌握了理论和技术,有效提高了工程设计能力。
2.2建设实践教学案例库,扎实执行实践训练
为了保障软件测试课程的教学水平,提高教学效果,我们采用了案例教学法。以可操作的软件测试案例为中心,让学生能在教学和实践的过程中体会实际的测试过程。为了保证案例的有效性和可操作性,以便在课堂教学中取得应有效果,我们收集建设了实践教学案例库。这些案例有的是从软件企业中收集,有的是从学生毕业设计和上机作业中收集,还有的是从教材及网上收集[3],另外也有教师自己设计开发的。有了这些教学案例,大大方便了学生的实践训练。
2.3搭建实验平台,实施开放式实验教学
为了引导学生重视所学知识与行业发展、市场需求的结合,以便在今后的就业中更具有竞争力,通过比较和论证,我们最后选择了大多数企业测试部门最常用的一些测试工具,包括WinRunner、LoadRunner、JUnit、Rational工具、Bugzilla等,对于大多数被测软件来说,这些测试工具完全能够支撑整个软件测试过程。
在搭建实验平台的同时,全面实施开放式实验教学,通过软件工程实验室,学生能全天候进行实践,老师能随时指导学生做设计,以及回答学生的提问,使学生的实验时间更加充分和自由。
3提高教学效果,加强师资建设和培养
要培养合格的应用型学生,首先应培养合格的教师。为了提高教学效果,我院经常选送任课老师到正规软件公司的软件测试部门实习,学习企业的软件测试管理和开发过程,并在企业许可的情况下,收集测试案例,丰富实践教学。另外还派遣任课教师到优秀的软件测试培训机构进行培训,以及攻读博士学位等,在教学中结合项目实践,将第一线的技术、信息带进课堂,通过培训和项目实践,进一步丰富了实践经验,促进了教学手段、方法的改进。此外,我院还经常不定期地邀请企业的业务骨干和行业专家为师生开设专题讲座,传授最新业务知识,开展技能培训等。
4引导学生正确认识软件测试技术和软件测试职业
软件测试人员不仅要掌握软件测试技术,还要具备软件系统分析、软件系统设计和软件编程等方面的能力。由于软件测试人员的工作是找出软件中错误,并经常同系统设计者和编程人员交流,因此严谨的工作习惯、良好的沟通能力和团队合作精神也是软件测试人员所必需的。而学生对软件测试技术的重要性和就业前景的了解,是激发和促使他们主动学习的重要推动力。为此,在教学过程中要予以适时介绍,同时邀请经验丰富的工程师来校报告,使学生清楚地了解职业要求和广阔的发展空间,正确认识软件测试技术和软件测试职业。
5结语
软件测试技术是软件工程专业的重要课程,通过对课程教学改革的实施,使学生对课本知识的理解更加深入,主动思考问题能力和实践应用能力也得到提高,为培养高技能应用型人才打下良好的基础。同时,教师们也普遍反映软件测试技术的教学质量和教学效果得到极大的提高。在这个过程中,我们摸索和积累了一些经验,以期对其他专业的教学也具有一定的参考价值。
摘要：该文深入分析了DSP汇编语言软件的测试难点，给出DSP汇编语言软件的测试策略，对DSP汇编语言软件测试具有重要的应用意义。
关键词：DSP；汇编语言；测试
1 引言
目前，DSP硬件系统已具有了很高的可靠性，但其软件系统，特别是用汇编语言设计编写的较为复杂的软件系统，可靠性总是难以得到保证，更是缺少完整的质量保证和评估体系，这已经成为DSP应用方面亟待解决的一个问题。对DSP汇编语言软件的测试与一般的软件测试不同，其自身的特点决定了测试面临的困难。本文首先对其测试难点进行分析，然后给出了DSP汇编语言软件的测试方法。
2 DSP汇编语言软件环境的复杂性分析
2.1 与硬件结合紧密，测试环境难以搭建和选择
汇编语言的程序是烧制到DSP芯片中运行的，DSP芯片种类繁多。这些芯片的外部管脚、内部存储器分配都各不相同 。在搭建宿主机测试环境时必须选择各种不同的相对应的芯片，然后配合仿真器与宿主机连接。这些硬件的配置本身就增加了测试难度，然而这些仿真环境总是和目标环境之间有着不小的差异,比如目标环境的中断难于模拟等。基于目标的测试消耗较多的经费和时间，而基于宿主的测试代价较小，但毕竟是在模拟环境中进行的。目前的趋势是把更多的测试转移到宿主环境中进行，但是，目标环境的复杂性和独特性不可能完全模拟。
2.2 I/O通道少，测试数据获取比较困难
在DSP汇编语言软件的测试中给主机上载测试数据是很困难的。目前主要是基于以下3 种方式：1）实际的物理通道；2）开发工具IDE的虚拟IO功能；3）直接读取内存区数据。第一种方式就是目标机和主机之间具备物理的通信方式，比如以太网、串口、并口、USB等。这种方式要求系统必须具备这种通信方式和通信软件，一般只适用于系统级的测试。第二种方式是借助开发工具，比如TI CCS，这种方式调试较为复杂也容易出错。第三种方式则是需要占用较多的内存资源。
2.3 实时性要求较强
DSP软件一般都用作控制系统的内核，所以有很高的实时性要求，而实时性的测试是一般的测试方法和测试工具都难以实现的。
2.4缺少相应测试工具
汇编语言结构和语法都比较繁琐和冗长，这首先使测试人员理解程序变得困难，又因为DSP芯片的多样性，使得开发针对DSP汇编语言软件的通用测试工具几乎是不可能的。因此，在测试时，只能够使用一些外围测试工具（比如覆盖率分析工具等），而把测试的重点放在人工的代码审查上面，这就要求测试人员要很熟悉相应芯片的用法并且还要与开发人员充分的沟通。
3 DSP汇编语言软件的测试策略
DSP汇编语言软件是最难测试的软件之一，必须制定有效的测试策略。在搭建测试环境时，要寻求宿主机与目标机之间的平衡，即要对目标环境和宿主环境的测试内容有所选择，在宿主环境中，可以进行逻辑或界面的测试、以及与硬件无关的测试。在模拟或宿主环境中的测试消耗时间通常相对较少，用调试工具可以更快地完成调试和测试任务。而中断测试、硬件接口测试、系统集成测试等必须要在目标环境中进行。而在测试环境搭建完成之后，考虑到重要性以及测试执行先后顺序，把整个测试依次分为以下几个不同阶段。
1）代码审查阶段。对于DSP汇编语言软件，代码审查是整个测试的重点，要占到整个测试周期的60%。同时，代码审查又是功能测试编写测试用例之前的必要步骤。代码审查最好是在开发环境中通过硬件仿真进行。
2）功能测试阶段。在功能测试阶段，采用功能分解法、等价类划分和猜错法等方法，根据软件需求规格说明中所规定的软件正式合格项设计并执行测试用例，以验证其功能是否满足需求规格说明的要求，并对其功能的适合性和准确性进行验证。对于DSP汇编语言软件系统，功能测试必须首先进行模块化处理，分离出每个模块的输入输出。
在设计功能测试用例时，也包括对边界值的测试，即对输入域(或输出域)的临界状态、数据结构、状态转换、功能界限等的边界或端点情况下的运行状态的测试。此外，设计功能测试用例时运用覆盖测试工具辅助测试用例的设计，以达到功能测试的充分性。
3）性能测试阶段。在DSP软件系统中，程序的性能是非常重要的，要严格根据需求中对负载、定时、性能的要求，判断软件是否满足这些需求规范。在使用环境中，软件的失效过程要平稳（电机运动惯性问题），所以，不仅要检查软件工作过程，也要检查软件失效过程。
可以使用测试工具CODETEST主要对DSP下行的伺服驱动器控制软件中有时间要求和数据处理精度要求的软件合格性项进行测试，并把重点放在测试其实际时间特性与实际数据处理精度上。时间特性主要包括以下几个：中断延迟时间、任务上下文切换时间、任务响应时间、任务创建/删除时间、交替信号量时间、取得/释放信号量时间、交替消息队列传输时间。
4）接口测试阶段。为了保证正确地测试，还须要检验软硬件之间的接口。对接口的测试主要利用各种不同类型接口的监视工具。比如对TMS320LF2407板汇编软件串口测试，可以使用串口监控器EtherPeek.NX，人工设置各软件从RS232串口接收的输入/输出，验证各软件对输入/输出的反应，并监控其输入/输出内容的格式与数据位是否与接口规范一致，验证各接口的正确性和一致性。
5）结构覆盖测试阶段。使用测试工具LDRA TestBed对被测软件程序进行插装。插装可以是在测试环境中嵌入硬件，也可以是在可执行代码中加入软件，也可以是二者相结合。基于测试用例，执行插装后的程序，提取语句/跳转覆盖信息，将程序的执行表现与编码意图进行比较，衡量软件测试工作的充分性。代码覆盖分析工具可能侵入代码的执行，影响实时代码的运行过程。基于硬件的代码覆盖分析工具的侵入程度要小一些，但是价格一般比较昂贵，而且限制被测代码的数量。
6）强度测试阶段。在模拟环境下，打开被测软件全部数据采集与数据通信通道，运行全部模拟外设，长时间运行功能测试和接口测试等相关测试用例，检测交流伺服驱动器控制软件在设计能力下的运行情况。
7 ）安全性测试阶段。采用人工测试的方法对被测软件进行安全性测试。检测用户是否能对被测软件进行灾难性操作，被测软件是否具有关键操作的安全性保护等功能。对于电机控制系统的DSP软件，主要检查过压、过流、低压、低流、断电、异常复位等灾难性操作。
8）可恢复性测试阶段。采用人工测试的方法对被测软件进行可恢复性测试。用人工干预的手段模拟硬件故障、链路故障、电源故障等，故意造成系统出现异常，并由此检查被测软件是否具有错误探测功能，在故障发生时能否保护正在运行的作业和系统状态。并检测被测软件在重启之后能否正常地继续进行工作，并不对系统造成损害。
9）回归测试阶段。对于在测试过程中发现的问题，开发方应及时对其进行修正。修正后由测试方通过回归测试进行确认。回归测试必须将所有功能测试、接口测试等测试用例重新执行一遍，以验证所有问题已经全部解决，并且没有引入新的问题。
4 结论
此方法研究在一定程度上减轻了DSP汇编语言软件的测试难点，对以后的测试实践有重要的参考意义。此策略的充分性和自动化程度是今后工作和研究的方向。
摘要：在软件测试过程中，因为多方面的因素，常常会导致一些错误和失效，为了改善测试过程、使测试过程变得更为有效，需要对软件测试过程进行一个补充，那就是对软件测试的有效性进行评价。本文介绍了评价软件测试有效性工作的一般流程，并提出了一系列用于精确度量测试有效性的度量指标。
关键词：软件测试；测试的有效性
1 引言
如同任何产品离不开质量检验一样，软件测试是在软件投入运行前，对软件需求分析、设计规格说明和编码实现的最终审定，在软件生存期中占据着非常突出的重要位置。在软件测试过程中，测试人员非常关心之前的测试过程有没有得到改善，因为如果没有，那么在下一次又将犯一样的错误，继续执行无效的测试。同时由于测试在整个项目研发过程中占用了相当一部分信息服务资源，因此，管理人员也常常在思考测试是否有效，是否值得投入那么多资金。因此，要改善测试过程、使测试过程变得更为有效，必须不断地评价测试结果。
2 评价软件测试有效性的工作流程
评价软件测试有效性的主要目的是评价测试人员的工作和使用评价后的结果改进测试过程。在软件测试中，往往会存在一些无效的方面，评价的目标就是识别这些无效和问题以便可以采取修复措施。
在测试的有效性评价工作中，存在两个关键的因素：一是评估的目标，目标是对度量过程的恰当指导，无效的目标会使整个评价过程无效；二是实现度量目标所需的信息类别，信息的收集需要建立专门的小组，整个评价过程也应指派专门的人员负责，因为如果没有专人负责评价过程，那么就无法确保进行正确的数据收集和评估过程。
图1给出了评价测试有效性的工作流程。本文主要围绕这个工作流程来进行详细的阐述。
3 有效性评价的输入
当所有的软件测试过程结束后，软件测试有效性评价工作就可以开始了，测试阶段的最终执行结果是它的入口条件，表1列出了输入所需的一部分信息类型，根据具体项目的不同，也会产生其它的输入。
4 有效性评价的执行过程
软件测试的有效性评价的执行过程包含七个方面的内容：确定评估目标、确定度量内容、制定度量责任、选择评估方法、确定所需事实、收集评估数据和评估测试有效性。
4.1 确定评估目标
定义目标，是为了使度量过程得到指导。前面提到，评价的目标就是为了识别测试无效的方面，以便采取修复措施。因此应该明确地确定评估执行的目标。在测试有效性评价中需要识别的内容包括以下六个方面：识别测试弱项、识别新测试工具的需要、评估项目测试、识别良好的测试实践、识别不好的测试实践和识别经济的测试实践。
4.2 确定度量内容
明确了评价目标之后，接下来的工作就是确定度量的内容，即确定达到度量目标所需信息的类别。应用系统的测试中，有五个方面是可度量的：涉及方、测试的程度、资源、有效性和评估。
4.3 制定度量责任
在测试评价过程中，应该指定负责收集和评估测试性能信息的小组和专门的负责人员，这时为了确保数据收集和评估过程发生的推动力。
4.4 选择评估方法
在执行测试评估的过程中有一些方法可供选择，在实际操作过程中，我们推荐采用度量指标方法，因为它一旦建立就很容易使用，并且可以证明它与有效和无效实践有密切关系。
因素间的某种关联或关系称为度量指标。度量指标的一个主要优势在于可以清晰地定义评估过程，并且对被评估人员来说也是透明的，同时它具有良好的针对性，可以容易地确定哪些测试变量需要调整以提高有效性、效率和/或测试过程的经济性。测试度量指标方法是指识别那些和好的或不好的测试有密切关系的标准。
4.5 确定所需事实
确定所需事实是指识别支持所选方法的必要证据。度量指标方法明确地识别了评估过程所需的数据类型。要使用本文后面描述的度量指标，所需确定的信息包括：变更的特征、被测试过程的费用、测试的费用、测试所发现的缺陷、阶段发现的缺陷、测试后发现的缺陷、按功能的测试费用、对系统的抱怨、缺陷的量化和恢复缺陷的量化。
4.6 收集评估数据
收集评估数据主要是指通过收集机制、存储机制以及选择和总结信息的方法，来建立用于存储所需评估数据的系统。
4.7 评估测试有效性
执行过程的最后一步是分析信息以得到关于系统测试有效性的结论。通过分析度量指标方法，相应的人员可以有针对性地采取措施，并将总结后的结果记录到测试评估表格中。度量指标方法通常会以量化的，表示测试过程好坏的形式给出评估。
下面（见表2）给出30个推荐使用的用于评价应用系统测试的度量指标。
5 有效性评价的检查过程
在检查过程中，需要建立一个质量控制检查单（见表3），其中的“是”回答表示好的测试实践；“否”回答表示需要额外的调查。注释列用于解释“否’回答并记录调查结果。当检查单的项不适用于测试情形时适用“N/A”列。
6 有效性评价的输出
测试有效性评价的最后输出是改进后的测试过程。在这个步骤中，主要是对测试结果进行仔细地分析，然后采取相应措施来修复所确认的薄弱环节，使用度量/行动的方法来改善测试过程，最后使得应用系统测试更加有效。（度量/行动的方法是指通过改变某种度量指标中的变量来度量另一种度量指标中变量的改变。如果能够说明通过增加执行的指令数目确实减少了操作的系统中的缺陷数目，那么可以认为该措施是预期的，并且应该推广。而如果执行指令的增加并没有减少产品投入运行之前的缺陷的数目，那么说明那些资源还没有得到有效的使用，应该停止该行动并且尝试其他措施。）
7 结束语
本文提出了评测软件测试有效性的一般工作流程，描述了度量测试的普遍目标，并为执行这些度量给出了推荐的标准，是软件测试的有效充，对实际软件测试的评价工作具有一定的指导意义。在项目软件测试过程结束后，IT组织应该结合各自的特点，通过在软件过程中积累的经验，运用本文提出的工作流程，逐步对软件测试过程进行改进，使软件测试更为有效的发挥它的积极作用。
摘要：构件技术成为当前软件工程中的发展方向，构件的软件测试成为软件测试中的一个新的研究领域。本文对构件技术做了简单的介绍后，对构件测试中遇到的困难和问题做了比较详细的描述，并介绍了目前过内外在构件测试方面的一些成果现状。
关键字：软件测试；构件技术；构件测试
1 软件构件技术
自上个80年代以来，面向对象技术的发展与应用，在提高软件可重用性方面起了积极的推动作用，软件重用已经成软件工程技术的一个重要目标，成为开发出高效、低成本、可重用软件系统的重要的现实途径。当今软件开发技术的主流已是基于软件构件技术。只要遵循软件构件模型规范，各个软件开发商就可以用自己方便的程序语言去实现可重用的软件构件，应用程序开发人员就有可能实现在计算机硬件领域早已实现的梦想：挑选构件，组合成新的应用软件系统。oscarNierstrasz提出[1]：Applieations=Components + seripts即应用软件就是构件和构件描述组成。
2 传统的软件测试
2.1 软件测试的重要性、目的和原则
为了能够保证交付的软件使客户满意，需要在软件开发、集成和形成系统之后进行充分、全面、有效的测试，软件测试是保证软件质量的重要手段。
测试过程贯穿在软件开发的整个生命周期过程，覆盖范围是很广泛的，包括需求分析，设计文档、程序代码等。目前比较侠义的理解是软件测试就是对程序代码的测试。
Grenford.J.Myers[2] 就软件的测试目的提出了如下的观点：(1)软件测试是程序的执行过程，目的在于发现缺陷；(2)一个好的测试用例在于能发现至今未发现的缺陷；(3)一个成功的测试是发现了至今未发现的多个缺陷的测试。因而，测试的目的是在资源消耗合理的情况下，发现尽可能多的缺陷和错误。
软件测试中应该遵循主要原则包括：(1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭；(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成；(3)序员应避免检查自己的程序；(4)在设计测试用例时，应当包括合理的输入条件和不合理的输入条件；(5)充分重视测试中的群集现象；(6)严格执行测试计划，排除测试的随意性；(7)应当对每一个测试结果做全面的检查；(8)妥善的保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便[3]。
2.2 传统的软件测试主要方法和技术
通常依照如下方法对软件测试进行分类：
(1) 软件开发过程中的测试：包括单元测试；集成测试；系统测试； 验收测试。
(2) 软件产品测试。测试对象是已经或即将产品化的软件。包括：功能测试；性能测试；β测试；Benchmark测试。
(3) 专门的软件测试：包括可靠性测试；标准符合性测试；互操作性测试；安全性测试；强度测试。
3 构件测试方法概述
3.1 构件测试技术发展现状
构件测试技术发展历史并不长，构件继承了传统软件的特点，与传统软件相比又具有一定的特殊性，所以构件软件的测试技术也相应的继承了传统软件测试技术中适用的部分，同时又具有传统软件测试所不具备的特性。
正是这些特殊性决定了构件软件的测试方式、方法在某些方面具有自己的特点。为此，在传统软件测试技术的基础上，对构件软件测试技术进行挖掘和开拓成为构件软件测试领域的一项主要研究内容，并有了一定的发展。
构件软件作为软件的一种，是软件技术发展的新阶段，面临着更加复杂的开发模式，为此需要对构件软件进行一系列的测试，从而保证构件软件的质量要求。
3.2 构件测试面临的主要问题
基于构件的软件开发所面对的测试单元是构件产品，作为构件开发方来说可以针对构件的源码进行测试，而对于构件的使用方来说往往构件的源码是不可知的也很难与构件的开发者进行交流。这一差异导致构件的测试与传统的软件测试相比具有了新的问题，包括：
3.2.1 构件生产者所面临的测试问题
(1) 构件的应用环境复杂多变，作为构件开发者难以考虑所有的构件可能运行的环境，因而也就不能对构件进行充分的测试；(2)构件软件测试集的组合爆炸问题导致测试工作量非常大，却难以覆盖所有的测试点[4]；(3)构件的测试环境配置困难重重，构件生产者不可能搭建构件使用的确切环境；(4)构件测试的可重复性；(5)构件测试工具缺乏。
3.2.2 构件使用者面临的测试问题
(1)很难获得软件的源程序，因而不能对构件的内部细节有详细的了解，从而对构件的测试带有一定的盲目性；(2)测试数据的产生：由于同样的原因，难以产生合适的测试输入，使得对底层元素难以达到较高的覆盖率；(3)组合爆炸问题依然存在，导致测试困难；(4)集成测试中有可能对构件单元测试中的测试点造成重复测试，从而造成测试冗余性；(5)构件测试的可重用性：对构件的测试应该是可重用的；(6)构件测试工具的缺乏。
3.3 构件测试与传统的软件测试的主要区别
构件与传统软件从系统设计开始就是不同的，传统软件开发从需求分析、软件设计到编写代码一直到测试都是软件公司独立完成的，所以具有比较清晰的脉络，也能得到软件的内部细节信息。
基于构件的软件开发采用的模式也是从需求分析开始的，但是组成软件的基本单元不再是传统的软件模块（比如类），而是来自于第三方的软件构件。从而面向构件的软件开发技术面对的主要问题是如何选择以及组装软件构件[5]，经过充分的测试，最终形成软件产品。
因此，传统软件测试的软件设计详细信息和软件的源代码都是可以得到的，脉络十分清晰。软件构件的测试以及软件构件产品集成测试和系统测试需要寻找合适的构件产品并组装，而构件设计以及内部代码对于构件使用者来说是不可见的。
传统软件测试理论和方法技术都比较成熟，构件测试的测试方法和测试技术部分可以采用传统的软件测试。但是构件测试具有自己的特点，需要区别对待，根据构件的新特性研究构件的测试方法。
3.4 国内外构件测试的研究现状
国外及国内在构件测试方面的研究已经取得一定的成果，例如：Freedman提出了构件的可测性理论[6]；Jerry[7]提出了构件可跟踪性以及构件可理解性；浙江大学提出界面构件关联图的测试方法，等等
从国内外构件测试技术研究的现状来看，具体的软件构件测试方法主要有以下几种：
(1) 基于元数据的构件测试
这种测试方法由构件开发者提供包含构件信息的元数据，这些元数据覆盖了构件各个方面的信息。构件测试者提取元数据中的信息并根据这些信息来制定合理的测试用例，然后对构件进行测试。由于这些元数据具有明确的构件使用上下文信息，所以通过元数据提供的数据对构件进行测试具有明确的目标和清晰的测试切入点。不过元数据的制定比较困难。
(2) 软件构件流程图
使用数据流和控制流的方法，利用从构件中获取的信息将构件数据和信息的交互做成交互图，然后根据此交互图来制定测试用例。
(3) 错误注入的构件测试
通过对程序进行错误注入来观察构件失效或产生错误的状态下对整个系统的影响。通过对构件功能的限制来发现系统入侵情况下构件的运行状态以及由此而产生的对整个软件系统的危害。
(4) 测试序列技术
该方法对构件间的交互进行测试，通过应用需求分离出构件交互的序列并不断集成直到生成整个应用系统，因而可以看作是一个渐进的测试过程。但是随着系统中构件数目和规模的增加，这种测试的难度也逐渐的增加。
4 总结
随着构件技术成为当前软件工程中的热点发展方向，构件的软件测试成为软件测试中的一个新的研究领域。本文对构件技术做了简单的介绍后，对构件测试中遇到的困难和问题做了比较详细的描述，并介绍了目前过内外在构件测试方面的一些成果现状。所做的工作属于项目组系统实现的前期熟悉工作的组成部分。
摘要：以软件工程中面向对象软件开发模式为参考，具体阐述了面向对象分析、面向对象设计、面向对象编程的测试注意点和测试过程，并依照传统的单元测试、集成测试、系统测试三个测试步骤，借鉴传统测试方法以及面向对象软件测试层次结构，详细探讨了面向对象单元测试、面向对象集成测试和面向对象系统测试的测试策略，并对相关问题进行了探讨。
关键词：面向对象；软件测试；面向对象测试模型；测试过程
1 引言
从1982年在美国北卡罗来纳大学召开首次软件测试的正式技术会议至今，软件测试理论迅速发展，并相应出现了各种软件测试方法，使软件测试技术得到极大的提高，软件测试成为软件工程方法中保证软件质量的最重要手段。
传统软件测试技术是面向过程的测试，是从输入/处理/输出的角度检验一个函数或过程能否正确工作，而面向对象软件测试是针对相互协作而又彼此独立的对象的测试。面向对象软件开发的测试目标与传统的软件开发方法相同，都是为了确保软件能正确地和一致地解决待解决的问题，但由于过程性测试方法没有考虑到面向对象软件测试所要涉及的类、继承和多态性，因此这两者是有很大的不同，因而有必要对其进行深入的研究。
2 面向对象测试模型
面向对象的开发模型突破了传统的瀑布模型，将开发分为面向对象分析（OOA），面向对象设计（OOD）和面向对象编程（OOP）三个阶段。分析阶段产生整个问题空间的抽象描述，在此基础上，进一步归纳出适用于面向对象编程语言的类和类结构，最后形成代码。
针对这种开发模型，结合传统的软件测试步骤的划分，文献[1]提出一种整个软件开发过程中不断进行测试的面向对象软件测试模型，使开发阶段的测试与编码完成后的单元测试、集成测试、系统测试成为一个整体。该测试模型给出了面向对象测试OOT 与OOA、OOD 和OOP 三者的对应关系，如图1 所示。
OOA Test 和OOD Test 是对分析结果和设计结果的测试，主要是对分析设计产生的文本进行测试，是软件开发前期的关键性测试。OOP Test主要针对编程风格和程序代码实现进行测试，其主要测试内容在面向对象单元测试和面向对象集成测试中体现。面向对象单元测试是进行面向对象集成测试的基础。面向对象集成测试主要对系统内部的相互服务进行测试，如成员函数间的相互作用，类间的消息传递等。面向对象集成测试不但要基于面向对象单元测试，更要参见OOD 或OOD Test 结果[2]。面向对象系统测试是基于面向对象集成测试的最后阶段的测试，主要以用户需求为测试标准，需要借鉴OOA 或OOA Test 结果。
2.1 面向对象分析的测试（OOA Test）
传统的面向过程分析是一个功能分解的过程，是把一个系统看成可以分解的功能的集合。这种传统的功能分解分析法的着眼点在于一个系统需要什么样的信息处理方法和过程，以过程的抽象来对待系统的需要。而面向对象分析(OOA)是把E-R 图和语义网络模型，即信息造型中的概念，与面向对象程序设计语言中的重要概念结合在一起而形成的分析方法，最后通常是得到问题空间的图表的形式描述[3，4]。
OOA 阶段将问题空间中的实例抽象为对象，用对象的结构反映问题空间的复杂实例和复杂关系，用属性和服务表示实例的特性和行为。OOA 的结果是为后面阶段类的选定和实现，类层次结构的组织和实现提供平台。因此，OOA 对问题空间分析抽象的不完整，最终会影响软件的功能实现，导致软件开发后期大量不可避免的修补工作；而一些冗余的对象或结构会影响类的选定、程序的整体结构或增加程序员不必要的工作量。因此，对OOA 的测试重点应该放在完整性和冗余性方面。 OOA阶段的测试划分为以下五个方面：1) 对认定的对象的测试；2) 对认定的结构的测试；3) 对认定的主题的测试；4) 对定义的属性和实例关联的测试；5) 对定义的服务和消息关联的测试。
2.2 面向对象设计的测试（OOD Test）
通常结构化的设计方法是用面向作业的设计方法，它把系统分解以后，提出一组作业，这些作业是以过程实现系统的基础构造，把问题域的分析转化为求解域的设计，分析的结果是设计阶段的输入。
而面向对象设计(OOD)采用“造型的观点”，以OOA为基础归纳出类，并建立类结构或进一步构造成类库，实现分析结果对问题空间的抽象。OOD 确定类和类结构不仅能满足当前需求分析的要求，更重要的是通过重新组合或加以适当的补充，能方便实现功能的重用和扩充，以不断适应用户的要求。因此，对OOD 的测试，建议针对功能的实现和重用以及对OOA 结果的拓展，从如下三方面考虑[5]：
1) 对认定的类的测试；
2) 对构造的类层次结构的测试；
3) 对类库的支持的测试。
2.3面向对象编程的测试（OOP Test）
由于面向对象程序具有继承、封装和多态等新特征，使得传统的结构化程序测试策略不能完全适应面向对象程序的测试需要。主要表现在三个方面，即面向对象的封装不能实现传统测试方法中对数据非法操作的测试；面向对象的继承，使错误的传播概率提高，增加了测试的复杂度；面向对象的多态特征使程序内“同一”函数的行为复杂化，增加测试的工作量。
面向对象程序将功能实现分布在类中，类间通过消息传递来协同实现系统的功能。面向对象的这种程序风格将出现的错误精确地确定在一个具体的类中，因此，面向对象编程的测试OOP Test忽略类功能的实现细则，将测试集中在类功能的实现和相应的面向对象程序风格，主要体现为两方面（假设使用C++语言）：
1) 数据成员是否满足数据封装的要求；
2) 类是否实现了要求的功能。
3 面向对象的软件测试内容及层次
面向对象软件测试即在测试过程中继续运用面向对象技术，进行以对象概念为中心的软件测试。Binder 在研究了面向对象的特征，如封装性、继承性、多态和动态绑定性等，认为这些特征的引入增加了测试的复杂性。对软件测试层次一种较为普遍的划分方法是根据测试层次结构，面向对象软件测试总体上呈现从单元级、集成级、到系统级的分层测试，测试集成的过程是基于可靠部件组装系统的过程。测试可用不同的方法执行，通常的方法是按设计和实现的反向次序测试，首先验证不同层，然后使用事件集成不同的程序单元，最终验证系统级。根据测试层次结构确定相应的测试活动，并生成相应的层次[6]。由于面向对象软件从宏观上来看是各个类之间的相互作用，因此，将对类层的测试作为单元测试，而对于由类集成的模块测试作为集成测试，系统测试与传统测试层相同。测试流程如图2所示。
3.1 面向对象的单元测试（OO Unit Test）
传统的单元测试是针对程序的函数、过程或完成某一定功能的程序块，面向对象单元测试OO Unit Test 在OOP Test 时进行，是对程序内部具体单一的功能模块的测试。一些传统的测试方法在面向对象的单元测试中都可以使用，如等价类划分法，因果图法，边值分析法，逻辑覆盖法，路径分析法，程序插装法等等。
当考虑面向对象的软件时，模块单元的概念改变了，封装规定了类和对象的定义。这意味在面向对象单元测试中，最小的可测试单元是封装的类或对象，而不是模块。
类包含一组不同的操作，并且某特殊操作可能作为一组不同类的一部分存在。同时，一个对象有它自己的状态和依赖于状态的行为，对象操作既与对象的状态有关，也可能改变对象的状态。所以，类操作时不仅要将操作作为类的一部分，同时要把对象与其状态结合起来，进行对象状态行为的测试。类测试可以分为以下三个部分：[7]
1) 基于服务的测试：测试类中的每一个服务（即方法）；
G是一个有向图，叫做块体。它是按照控制流图的思想修改f的程序流程图而来的，表示f的控制结构中的符合条件判断被分解，每个判断框只有单个条件。
3.2 面向对象的集成测试
传统的集成测试是由底向上通过集成完成的功能模块进行测试，一般可以在部分程序编译完成的情况下进行。而对于面向对象程序，相互调用的功能是散布在程序不同的类中，类通过消息相互作用申请和提供服务，类相互依赖极其紧密，根本无法在编译时对类进行测试，所以，面向对象的集成测试通常需要在整个程序编译完成后进行。
在面向对象系统中，集成测试属于应用生命周期的一个阶段，可在两个层次上进行。第一层对一个新类进行测试，以及测试在定义中所涉及的那些类的集成。设计者通常用关系is a，is part和refers to来描述类与类之间的依赖，并隐含了类测试的顺序。首先测试基础类，然后使用这些类的类接着测试，再按层次继续测试，每一层次都使用了以前已定义和测试过的类作为部件块。
对于面向对象领域中集成测试的特别要求是：应当不需要特别地编写代码就可把在当前的软件开发中使用的元素集合起来，因此其测试重点是各模块之间的协调性，尤其是那些从没有在一起的类之间的协调性。
集成测试的第二层是将各部分集合在一起组成整个系统进行测试。以C++语言编写的应用系统为例，通常应在其主程序中创建一些高层类和全局类的实例，通过这些实例的相互通讯从而实现系统的功能。对于这种测试所选择的测试用例应当瞄准待开发软件的目标而设计，并且应当给出预期的结果，以确定软件的开发是否与目标相吻合。
3.3 面向对象的系统测试
系统测试是对所有类和主程序构成的整个系统进行整体测试，以验证软件系统的正确性和性能指标等是否满足需求规格说明书和任务书所指定的要求。它与传统的系统测试一样，包括功能测试、性能测试、余量测试等，可套用传统的系统测试方法。通过单元测试和集成测试，仅能保证软件开发的功能得以实现，不能确认在实际运行时，它是否满足用户的需要，是否大量存在实际使用条件下会被诱发产生错误的隐患。为此，对完成开发的软件必须经过规范的系统测试，即开发完成的软件仅仅是实际投入使用系统的一个组成部分，需要测试它与系统其他部分配套运行的表现，以保证在系统各部分协调工作的环境下也能正常工作[8]。
在系统测试中，不关心类的联系细节。同于传统的系统测试，面向对象软件的系统测试集中在用户可见的活动与用户可识别的来自系统的输出。为了导出测试案例，测试者应该使用分析模型中的使用案例，使用案例能够用于导出测试案例以发现不能满足用户交互需求的错误。系统测试应该尽量搭建与用户实际使用环境相同的测试平台，应该保证被测系统的完整性，对临时没有的系统设备部件也应有相应的模拟手段。系统测试不仅是检测软件的整体行为表现，也是对软件开发设计的再确认。
4 结束语
面向对象测试的目标与传统测试相同，但面向对象方法与传统顺序结构式方法在开发思想上有着根本的不同，尤其是面向对象所具有的类、封装、继承、动态连接等特性，使得面向对象软件测试在测试模型、测试方法、测试层次等方面都有别于传统的测试思想。从面向对象的测试模型可知，测试的视角扩大到包括复审分析和设计模型，此外，测试的焦点从过程构件(模块) 转向了对象类。
目前，面向对象软件系统的开发在不断的实践中已逐步形成了自己的方法学，但对于面向对象软件测试，目前尚无普遍接受的充分性准则。本文根据传统软件测试模型将面向对象软件开发过程和软件测试相结合，形成一种面向对象测试模型，并对模型的相关步骤和具体实施提出了一些方法和技术，虽已在实践中得到了一定的验证，但也只是初步的，有必要在今后的研究中得到进一步的完善。
摘要：国内软件项目过程不规范，导致重视编码和轻视测试的现象，对于软件测试的重要性、测试方法和流程等还存在很多认识误区，软件测试所起的作用还没有人们期望那样显著，因此，就需要继续加大投入对软件测试的关注程度，对软件测试过程进行持续的改进。
关键词：软件测试；软件工程；认识误区；持续改进
1 引言
随着市场对软件质量的不断提高和国内软件测试行业的逐渐发展，软件测试不断受到重视，有越来越多的软件企业更加重视软件测试，并已经形成了一套基本的软件测试流程。然而，认识误区的存在需要我们进一步改进软件测试过程。
2 软件测试概述
软件测试就是在软件投入运行前,对软件需求分析、设计规格说明书和编码的最终复审，是软件质量保证的关键步骤。一般按四个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。随着软件危机的频频出现，人们已经开始认识到测试开始的时间越早，测试执行的越频繁，所带来的整个软件开发成本的下降就会越多。所以，软件测试在软件项目实施过程中的重要性日益突出。
3 软件测试过程中的认识误区
3.1 软件开发完成后进行软件测试
人们一般认为，软件项目要经过以下几个阶段：需求分析，概要设计，详细设计，软件编码，软件测试，软件。据此，认为软件测试只是软件编码后的一个过程，这是不了解软件测试周期的错误认识。软件测试是一个系列过程活动，包括软件测试需求分析，测试计划设计，测试用例设计，执行测试。因此，软件测试贯穿于软件项目的整个生命过程。在软件项目的每一个阶段都要进行不同目的和内容的测试活动，以保证各个阶段的正确性。软件开发与软件测试应该是交互进行的，否则，测试的时间将会很短，测试的覆盖面将很不全面，测试的效果也将大打折扣。
3.2 测试过程不够完善
在软件开发领域，确实存在一些东西看起来要比另外一些东西难测试一些，但是远非无法测试。只不过这种不可测试性不是由于被测试的软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试的软件本身很难测试。这些很难测试的部分比较常见的有：图形界面、硬件、数据库等。
3.3 强调测试用例设计得越详细越好
在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。
3.4 追求测试用例设计“一步到位”
现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。
4 软件测试过程的持续改进
4.1 计划与风险
项目计划对项目过程的实施有着直接的指导作用，它的重要性是不言而喻的。对于软件测试来说，测试计划也是指导后续测试工作的基础，只有对过程中各任务进行更详细的计划，才有利于在测试过程中对项目进度的把握有一个明确的目标；同时，风险策略的制定，也有利于对及早对测试过程中可能遇到的问题做出分析，以便在问题出现时能够尽可能的减少规避风险的成本。
4.2 评审
在测试过程中的每个阶段结束前，都会输出一些资源，文档、用例等等，这些资源往往是下一个测试阶段或软件开发的下一个环节执行的依据。评和审是结合在一起的，每个角色根据自己对项目的了解，从各自角度来审核测试报告的充分性，对质量风险发表各种见解。最终，对报告的规范性也要进行考察。另外，也最好根据实际情况组织会议评审来对一定规模的问题统一评审。
4.3 文档
文档的编写对于测试人员来说是一个十分重要的任务，深入的、充分的投入测试的测试人员能写出高质量的测试文档。所以，测试文档的质量，往往反映了测试人员执行测试的广度和深度。而在文档的编写方面，首先必须形成统一规范；另外，针对不同项目的测试，可以适当对文档标题、内容进行简化。总之，文档模板一旦形成，必须严格遵守。
4.4 方法与策略
测试方法和测试策略，测试的重中之重。测试的策略一般要求从全局方面对测试的阶段、每个阶段的测试类型进行考虑、定义。而测试的方法更多是体现在一个具体的测试中，采取怎样的测试思路。另外，在测试过程中，对资源的协调也非常关键，需要能保证测试资源充分利用，每个测试人员都有适度并且相当的工作量。
4.5 总结测试经验
在测试的过程中，测试人员应该及时总结发现的错误并归类，标明经常容易出错的地方，将意见提交项目经理，审核后，制定出一份统一标准并提供给开发人员，这样就可以提前避免错误、避免重复错误和重复测试，提高测试效率。不仅如此，项目结束后的各项总结报告将是项目的后期维护或二次开发的宝贵参考资料。
4.6 缺陷分析、度量
对测试活动过程中发现的缺陷进行分析、度量，寻找软件开发过程中存在的问题，并持续改进开发过程，提高质量。缺陷的分析、度量从时间上分为两个方面，首先是在软件开发过程中发现的缺陷进行分析、度量；然后就是，对软件产品后，对用户提出缺陷进行统计、分析。
5 结论
测试是用来保证软件开发过程的高效性，以及保证开发出来的软件产品的高质量和可用性的。软件开发本身就是一件非常困难的事情，这也决定了有效的测试是非常重要的环节，我们要加强对软件测试的关注，使大家对于测试首先有一个正确的认识，避免误区的存在，并积极探索测试方法的持续改进问题，真正使软件测试真正起到它应有的作用。
摘要：主要介绍了面向对象软件的类测试技术。从基于对象状态方面分析UML状态图的组成、并发的优点，描述继承的对象动态行为、并发的动态行为，给出利用UML状态图构造复合状态测试树算法并产生测试用例的面向对象软件测试方法。
关键词：UML；测试用例；类测试；面向对象；状态图
1 引言
面向对象软件测试的主要目标与传统软件测试目标相同，既是用最小的工作量发现最多的错误。由于面向对象所独有的多态、继承、封装等新的特点，使面向对象测试的策略和技术与传统测试有所不同，测试的视角扩大到包括复审分析和设计模型，测试焦点从模块转向类。类是构成面向对象程序的基本成分，类的测试无疑成为面向对象 测试的重要环节。基于对象状态的测试是根据被测试的类的对象所处的状态以及状态之间的转移来构造测试用例，它侧重于对象的动态行为，这种动态行为依赖于对象状态。测试对象动态行为能检测出对象成员函数之间通过对象状态进行交互式产生的错误。
2 基于对象状态的测试方法的发展
现在面向对象测试中基于对象状态的测试方法一般是采用扁平状态机和状态迁移图。扁平状态机能很好的提示出一些类中的错误，但是随着类的状态属性的增加，对象状态的数目会迅速膨胀，大大增加测试的复杂度。状态转移图用于刻画对象响应各种事件时状态发生转移的情况，容易借助于自动机理论来选择测试时所用的时间序列和预测对象的状态变化结果序列，但是，它难于描述继承的对象动态行为、并发的动态行为以及由数据成员和成员函数构成的对象状态和对象状态转移。基于UML的状态图可以很好的描述对象动态行为、并发的动态行为，可以把状态的复杂度控制在和状态属性相关的线性级别，下面我们主要介绍利用UML状态图如何描述对象动态行为、并发的动态行为，以及如何产生测试用例。
3 UML状态图
UML状态图（State Diagram）是UML中对系统的动态行为进行建模的表示方法，它包括对反应型对象的行为建模。它展现了对象生命周期内可能处于的状态以及在这些状态间转换的激发条件。UML状态图中引起状态迁移的原因通常有两种，一种是在状态图中相应的迁移上未指明事件，这表示当位于迁移箭头源头的状态中的内部动作全部执行完后，该状态迁移被自动触发；另一种是，当出现某一事件时会引起状态的迁移，在状态图中把这种一起状态迁移的事件标在改前一的箭头上，如图1。
图1 状态装换
状态迁移的形式化语法为：
event_signsture[guard_condition]/action_expression^send_clause
其中事件特征event_signsture是由事件名后括号括起来的参数表组成，它指出触发迁移的事件以及与该事件相连接的附加数据。guard_condition警戒条件是一个布尔表达式，如果状态迁移中既有事件又有警戒条件，则表示仅当这个事件发生并且警戒条件为真时，触发状态迁移。动作表达式action_expression是一个触发状态迁移时可执行的过程表达式，表达式中可引用该状态所拥有的对象中的属性、操作或事件特征中的参数。发送子句send_clause是动作的一种特殊情况，用来说明在两个状态的迁移期间发送的消息。
UML状态图的优点在于它支持嵌套和并发。UML状态图中包含基本状态（basic state）和复合状态（composite state），复合状态分为或状态（or-state）和与状态（and-state）。或状态的子状态之间是相互排斥的或关系，表示在任一时刻这些子状态中只有一个子状态为真；与状态的子状态之间是并发的非相互排斥关系，与状态表示一个状态可以有多个并发的子状态，并发子状态之间用虚线分隔，用虚线分隔的每个区域表示一个并发的子状态。把状态属性看成并发的子状态，从而可以把状态图的复杂度控制在线性级别上。并发状态图中一个事件可能引起多个子状态的状态迁移。如图2中的CVM就是一个或状态，它的子状态OFF和ON之间是相互排斥的关系，ON状态就是一个与状态，当处于ON状态时，就意味着同时处于COFFEE和MONEY两个子状态。
由于UML状态图支持嵌套和并发，这就使得它比以往的状态转移图能更好的描述继承的对象动态行为、并发的动态行为以及由数据成员和成员函数构成的对象状态和对象状态转移。UML状态图中可以包含复合状态这就使得它可以把状态的复杂度控制在和状态属性相关的线性级别。下面我们讨论如何从UML状态图构造一棵复合状态测试树。
4 构造复合状态测试树
与以往的测试树不同的是复合状态测试树的每个节点代表对象的复合状态既对象的各个属性的集合，边表示状态间的迁移，根节点代表对象的初始属性集合。
构造一个队列queue来存放复合状态测试树的各个节点。
1)把UML状态图的起点读入队列queue。
2) 以UML状态图的起点定义根节点TestTree root，同时把节点标识treeNode置为对象的初始状态，nodelevel置为0，t和childTree置为NULL，把root放入队列中。
3) 取队列头部的节点设为head，搜索从head节点所对应的状态（head.treeNode）发出的状态前移以及前移置的目标状态，分别填充head.t和head.childTree，即把迁移至的状态作为head的子节点；同时置好各个子节点的属性值，nodeLevel=head.nodeLevel+1，从root节点开始层次遍历测试树（从第0层至head.nodeLevel层），如果在head的子节点中存在某个节点n，其所对应的状态已经在第0层至head.nodeLevel层中出现过，则该节点n不再扩展，即为叶子节点。把其他没有出现过的子节点加入到队列的尾部。
4) head指向队列中的下一个节点，重复第二步，直至队列为空。
在3)中，如果 某个迁移对应的目标状态已经在测试树中出现过，就不再考虑这个状态，不加入到队列尾部。这样有效地避免了重复构造节点，同时又不降低测试的覆盖率。通过上述步骤就可以构造出UML状态图对应的测试树。
复合状态树构造算法能很好的支持多个并发的子状态的情况，只是节点表示为并发子状态的合集；如果某个事件触发其他事件从而引起一系列的状态迁移时，只要把最终的状态作为节点加入到测试树中。比以往的插入桩模块更容易实现。
通过测试树可以很容易的构造出测试用例。从根节点开始沿着各个分支往下知道叶子节点，每条这样从根节点开始到某个叶子节点结束的路径上的事件按顺序组合在一起，就成为基于对象状态测试的一个测试用例。如果增加对象属性可以很容易的在复合状态测试树中增加，增加属性后可以把状态的复杂度控制在和状态属性相关的线性级别，测试时不仅可以单独的对对象的每一个属性和所有属行进行测试，也可以对对象的所有属性任意选择组合进行测试。大大增加了测试的灵活性。
5 结束语
UML的状态图支持潜逃和并发，把状态的复杂度控制在和状态属性相关的线性级别；其次UML状态参数图是在面向对象软件开发的生命周期中的早期设计阶段确定的，是对对象状态的完整的描述，并不依赖于源代码，既保证了状态描述的完整性，又可以在开发早期进行测试，尽早发现与状态相关的错误，避免将错误带入到后面的开发阶段。因此可以用UML的状态图来产生有效的测试用例，这大大提高了测试的灵活性和有效性。
摘要:该文对软件质量保证的重要手段――软件测试进行了论述,给出一些软件测试的基本理论。随着软件测试研究的发展,软件测试提出了一些比较前沿的理论,如面向对象的软件测试,测试驱动开发理论,探索性测试等。为了克服手工测试的一些困难,提高软件质量和测试效率,自动化测试被广泛地引入进来。它以其自动化程度高、实用性强等特点,引起了人们的广泛重视,成为软件测试的发展方向。自动化测试框架产品的出现表明软件测试自动化技术正在趋于成熟。早期使用录制回放和脚本工具的不足正在被克服,使得自动化测试更加经济、有效,更加有利于实现和维护。随着在开发和维护脚本上的时间越来越少,更多的时间可用于提高测试的覆盖范围和产品质量,从而在自动化上的投资能够更快地得到证明。该文分析讨论了自动化测试框架方法以及实现,并将其应用到软件测试中。
关键词:软件测试;自动化测试;数据驱动;关键字驱动
1 自动化测试框架
自动化测试在过去的20年中已经有了很大的发展。最初的测试工具只提供了简单的捕捉/回放功能:记录并播放键盘按键,然后捕捉和比较屏幕。这些测试方法虽然最容易应用,但是几乎不可能维护。捕捉/回放工具最终被功能和灵活性更强的测试脚本工具代替。后来,一种新的自动化测试产品出现了。它可以减少实现和维护的成本,使测试人员可以把精力集中在应用程序的测试用例设计上,而不是开发我们的测试。这些工具提供预先写好的测试框架,可以极大的减少,甚至消除学习和使用脚本语言的需要。这个测试产品就是自动化测试框架。
自动化测试框架定义了由假设、概念和制定工作平台或为自动化测试提供支持的实践组成的集合[1]。它能有效地弥补单一依靠测试工具所带来地一些缺陷。自动化测试小组可以考虑吸收几种测试框架的优点,设计适合自己团队的混合型测试框架。不是依赖某一种捕获――回放的自动化测试工具。
基于GUI的捕获回放工具都有维护性差的缺陷。因为GUI经常根据功能变更或者其他需求而改变,当GUI有重大变化时,会导致自动化测试中断,结果需要手工的干预或全部重新返工。因此更好的方案是引入自动化框架。
自动化测试框架为支持自动化软件测试设计了平台架构和最佳的实践经验。主要有4种基本框架结构类型[2]:脚本模块化架构,测试库架构,关键词或表格驱动架构,数据驱动架构。
1) 脚本模块化框架创建代表AUT基本模块和功能的底层脚本。然后以一种层次关系组合这些小脚本,实现一个特定的测试用例。
2) 测试库框架和测试脚本模块化框架非常相似,但是底层由过程和函数组成,而不是脚本。这种框架要求创建库文件(如SQABasic libraries, APIs, DLLs等等)代表AUT的模块和功能。这些库文件被测试用例脚本直接调用。每步的指令操作都在表格中维护。
3) 关键词驱动或表格驱动测试框架是一种独立于应用程序的自动化框架,这种框架要求开发数据表和关键字,不依赖于运行的自动化工具和脚本。关键词驱动测试看上去与手工测试用例非常相似。在关键词测试里,应用程序的功能特性和每步的指令操作都在表格中维护。
4) 数据驱动测试框架是从数据文件中读取输入和输出数值并载入到捕获的或手工编码的脚本变量里的框架。这种框架和表格驱动测试有些相似,脚本只是一种“驱动器”(driver )或传送数据的机制,不同的是导航的数据不包含在数据文件中,而只包含有测试数据。
测试框架是用来执行测试的总体环境,其中的优秀是一种自动化工具。本文主要介绍一种数据驱动的自动化测试框架WAF,对自动化测试的实施做出尝试,并对该框架模型做出一些改进。
自动化测试框架WAF是作为一个模块来设计和实现的,属于即插即用的构架,是一种数据驱动的软件自动化测试框架。当测试系统,测试数据和测试次序改变时不需要修改代码[3]。数据驱动引擎被设计并实现来支持现有模块的复用。只需要改变配置文件,测试用例表以及数据文件就可以实现当测试系统,数据和测试的次序改变时,不再需要改变其他的程序和函数等;通过实现新增模块的功能就可以引入新的测试或者新的验证行为。新的模块一旦创建就可以被应用,只需要对数据驱动引擎的头文件做些许的修改即可使用这些功能。
如同图1描述的那样,框架本身由WAF主程序,配置文件,WAF GUI映射,数据驱动引擎,测试用例或者测试组合(XML file),以及功能函数所定义。
2 WAF结构组成
2.1 主程序
当运行一个用WAF来开发的测试件(testware)时,主程序首先被调用执行。它根据对配置文件的解析结果来确定运行什么测试组合或测试用例,同时触发数据驱动引擎来解析测试用例文件,并根据解析结果来调用相应的数据文件同时触发相应的功能函数来执行测试。
2.2 数据驱动脚本
数据驱动脚本就是那些和应用程序相关联的脚本。这些脚本通过录制或手工编写成自动化工具私有的语言,然后对其中的变量赋予合适的数值,作为测试数据的输入[4]。这些变量作为一些关键应用程序输入的媒介,使脚本能通过外部的数据来驱动应用程序。
1) 可变数据,硬编码组件标志
这些数据驱动的脚本经常包含硬编码的数据,有时是一些窗口组件中非常脆弱的识别字符串。出现这种情况时,脚本很容易由于程序的更改而失去作用,而且这种情况并不是个别现象。
2) 高度技术化的、重复的测试设计
数据驱动脚本的另一个共同特点就是,所有在测试设计上所作的努力最终都体现在自动化工具的脚本语言中,或者复制到手工和自动化测试脚本中。
2.3 模块
WAF中的模块包括框架以及公共模块,专业模块,产品特定的模块。框架和公共模块包含一些框架和公共函数,例如数据驱动引擎。而产品特定的模块包括测试待测产品或应用所需要调用的功能函数。专业模块则包括处理特定的功能或者协议所需要的支持函数这些功能模块都放在函数库lib中[5]。
2.4WAF GUI映射
自动化测试工具录制应用程序中的每一个对象,并给每个对象命名来识别各对象,这个逻辑名能被修改,将其用在测试表中,测试工具使用他们来识别对象, GUI映射可由自动化测试工具自动产生。
2.5 测试数据
数据驱动测试是一种数据被包含在输入测试数据文件中,并且数据控制自动化测试脚本执行的流程和动作的测试。测试数据记录以文档的形式包含在输入文件中,输入文件包含测试数据和控制数据。测试数据进行必要的各种类型的测试,而控制数据引导测试脚本到达合适的位置并指示要执行的动作。测试数据是特定测试产品和测试组合的测试数据[6]。对于不同产品测试数据是不一样的。譬如对于文件传送功能的测试数据则表现为各种类型的文件。
2.6 测试用例
测试数据定义测试状态的初始化,测试步骤,应用在每一步中的测试数据以及其预期结果,是一个基本的测试单元[7]。测试组合是一个测试用例的集合,被指定来完成一个特定的测试目标。它可以被设计来测试一个函数,一个模块,或者是执行一个类型的测试,例如验收测试(Release Acceptance Test )。
在WAF框架模型中,测试数据是以标签的形式存放在XML文件中,每个标签对应一个测试数据,这样在一个独立的XML文件中可以对应多个测试用例,可以将XML文件看成是多个测试用例的集合。
2.7 测试件配置文件
TESTWARE配置文件记录执行测试件(testware)的一些基本配置项。包括文件目录,数据目录,测试组合目录,log目录以及一些服务的配置等。
2.8 测试结果
WAF在执行完一个测试后产生三种类型的测试结果,日志文件,报告和相应的测试过程数据。
2.9 利用WAF进行自动化测试开发流程
运行一个使用WAF开发的TESTWARE时,主程序被执行。它初始化测试环境,解析配置文件,启动数据驱动引擎(Data-driven engine)。
进行测试时数据驱动引擎调用XML文件,解析文件中的标签,通过资源定位符定位到XML文件中的设计好的测试用例(或者测试组合),根据解析的结果调用函数库中相应的功能函数(lib),并通过测试数据来对相应的应用程序执行测试。最后将测试结果返回给主程序输出。
3WAF在软件测试应用中的实现
当决定把数据驱动的自动化测试框架应用于一个具体的项目,首先要确定所有的testWare的一个目录结构。编写main程序来初始化环境,解析配置文件,启动测试引擎。抽象具体项目需要的Action,编制功能函数,放到lib函数库中。组织测试用例,准备测试数据。当所有的准备工作做完后,设置配置文件,运行测试,最后到result目录查看测试结果。
这就是把WAF应用到一个具体的项目测试的过程。
3.1 TestWare目录结构
TestWare的目录结构对于框架来说是很关键的。每一个目录都有自己的意义而且必须被遵从来向其中加入新的功能。目录结构包括以下部分。
BIN:包括主程序(main),启动(launch)脚本和测试配置文件。这是WAF的主要接口。TestConfig.ini文件用来定制和建立测试件(testWare)。启动脚本用来启动测试件(TestWare)。
Testdata:这个目录包括所有的在测试表中使用的测试数据。针对不同的测试软件存放各自的测试数据,比如各种文件等。
Lib:这个目录包括testWare的模块。不仅包括WAF框架的模块还包被测软件的特定模块。
Default config:产品的内部架构和设计被定一语这个目录文件中。被测试软件的配置文件被存放在这个目录下。
Testsuites:这个目录包括所有的测试表。这些测试表以树形结构来组织。
3.2 编写功能函数和组织测试组合/测试用例
lib函数库目录下不仅包括WAF公用的函数还包括产品特定的功能函数。数据驱动引擎的代码也保存在lib中。实现数据驱动引擎的代码包括解析测试表,运行测试用例,访问测试数据,返回测试结果等[8]。
3.3 组织测试数据
图2详细的显示了测试数据的组织。在被测软件的testware中,所有的测试数据都存放在一个特定的目录testdata下。在testdata目录下,测试数据分别存放在相对应的目录下,然后在testware配置文件的相应配置项中置上测试数据所在的目录即可。
3.4 检查测试结果
TestWare会把测试的全部结果结束按照测试执行的时间输出到testWare/results目录中。图3是一个测试结果的索引,它列出了所执行的所有测试。
点击相应的测试用例,就会打开具体的测试用例的执行情况,是成功还是失败(success/fail),以及每个测试步的执行结果是成功还是失败,如下图4所示。一旦测试执行失败,可以定位到具体的测试步骤。
3.5 WAF的优点
跟当前主流的测试工具相比,WAF具有以下优点[9]:
1) 实现了数据与脚本的分离。使得脚本的维护变得简单而方便。框架的重用性得到提高,能减少测试成本;
2) 使测试自动化而无需额外技术支持,减少测试人员学习自动化测试的时间;
3) 可以根据需要指定测试计划,测试表容易创建且维护简单,且简单的表结构重用性高;
4) 不必等到产品稳定以后才开始自动化测试。可以尽早的进行自动化测试,节约大量的手工测试的时间;
5) 测试人员不需要知道测试工具实现的细节,只需要和表打交道和执行自动化脚本;
6) 配置项从脚本中分离使得易于实现平台的转换,测试的移植。
4 工作总结
本文中主要介绍了自动化软件测试技术,优秀部分在于提出应用软件自动化测试框架实现软件自动化测试。以某软件作为应用背景提出一个适合该软件自动化测试的基于关键字和数据驱动的自动化测试框架。并将该框架模型应用于软件开发过程中的软件自动化测试。
这是一个最新的也是比较热门的发展方向。自动化测试中的自动化测试框架的研究也称为一个新的发展趋势。
现在,己经有一些商业化的自动化测试框架。在大多数情况下,他们和已有的商业化测试工具捆绑在一起。他们的主要不同点在于他们的底层的执行引擎或脚本库,是被映射到关键字,窗口还是对象或类,这也是将来自动化测试框架发展的几个趋势。关键字驱动的测试引擎已经实现,接下来,窗口引擎,对象引擎和类引擎等底层引擎的实现将会是商业化自动化测试框架的主要研究方向。
摘要: 软件测试是保证软件质量的重要手段,本文介绍目前常用的软件测试技术,给出不同测试技术的基本思想,讨论目前的研究内容和存在的不足。
关键词: 软件测试;软件质量;Web测试
0引言
软件测试是保证软件质量和可靠性的重要手段。软件测试是软件生命周期的一个重要组成部分,贯穿整个开发过程。软件测试是保证软件达到高质量和高可靠性的关键元素。现有的软件测试技术通常分为静态测试和动态测试。根据测试对象和研究侧重点的不同,目前软件测试技术的研究大多在以下方面:
1白盒测试
白盒测试是对软件的过程性细节做细致的检查,把测试对象看做一个打开的盒子,允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,因此又被称为结构测试或逻辑驱动测试。对白盒测试的研究主要在提高软件的各种覆盖率上,如文献[1、2]。目前一般认为,基于同一测试覆盖准则,测试覆盖率越高,软件的可靠性或可信性就越高。
2黑盒测试
黑盒测试[2]将被测对象看作一个打不开的黑盒,测试人员在不考虑程序内部结构和内部特性的情况下,只依据需求规格说明书,设计测试用例,检查程序的功能是否按照规范说明的规定正确地执行。它着重于验证软件功能和性能的正确性,典型测试项目包括功能测试、性能测试、边界侧试、余量测试、强度测试等。黑盒测试主要缺点是:测试结果取决于测试例的设计,而测试例的设计部分来源于经验,没有状态转换的概念,给寻找和确定程序缺陷带来困难。
3性能测试
性能测试主要测试软件处理事务的速度,一是检验软件性能是否符合要求,二是得到某些客户感兴趣的数据以供软件产品宣传。目前性能测试工具偏向于多用户的并发操作,侧重于负载压力的产生和服务器的监控,忽略负载压力情况下的功能不稳定问题。文献[3]指出性能测试时中间件的license、数据库的用户数有时影响系统的性能,测试时需综合分析,以得到准确结果。
4Web测试
基于Web的系统测试与传统的软件测试不同,它需要检查和验证是否按照设计的要求运行,而且还测试系统在不同用户的浏览器端的显示是否合适,并从最终用户的角度进行安全性和可用性测试。研究人员针对Web应用的交互、动态等特性进行深入分析,探讨Web应用的相关测试方法和技术。
4.1 Web应用模型的研究文献[4]提出一种基于非确定Petri网的链接模型;文献[5]将Web测试模型分为对象内部模型、交互关系模型和体系结构模型3个层次,分别对应测试内容的不同范围和阶段,即单元测试、交互测试和集成测试。
4.2 Web可用性测试方法文献[6]针对目前各Web服务间采用统一的SOAP协议进行通讯,提出基于协议对Web服务程序进行测试的方法;文献通过分析Web站点服务器端的日志文件得到的统计数据,从独特的角度探讨如何进行有效的Web站点测试,提出切实可行的测试方法。
4.3 Web测试自动化的研究目前Web测试的自动化多采用捕捉―回放工具(Capture-Replay)的工作过程和相关技术,但Web应用中有很多动态生成的页面且变动非常频繁,捕捉―回放技术不能完全胜任。因而文献提出通过使用具备一定智能的Agent建立起高效的Web应用测试执行方案。
4.4 其他方面的研究文献利用语义标注和XML描述技术实现Web页面中数据与显示信息的分离,并引入反馈控制机制,把测试结果反馈给Web应用本身。文献提出一种Web服务测试数据自动生成方法;它基于Web服务的功能说明随机地生成初始测试数据,然后使用合约变异技术进行测试数据选择,以生成一组达到一定合约变异充分度的有效测试数据。
5面向对象软件测试
面向对象技术具有多态、继承、封装等特点,使传统测试技术无法对面向对象软件进行有效的测试。宏观上面向对象软件是各个类之间的相互作用,系统的基本构造模块是封装的数据和方法的类和对象。对象中的数据和方法是一个有机的整体,测试过程不仅检查输入数据产生的输出结果是否与预期的吻合,还考虑对象的状态。
为使设计的软件测试工具具有良好的语言无关性,文献设计一种程序划分机制,它针对基于状态的面向对象软件的类测试过程中存在的不可预测、不可达状态、状态组合“爆炸”和测试用例“爆炸”等问题,提出基于EDPN(Event-driven petri network)模型的类测试、类的交互测试和类的层次测试框架,设计相应的测试模型。此外,研究人员对面向对象的测试策略和面向对象的回归测试等方面,根据其特点提出相应的新的思想和方法,如将多Agent系统引入面向对象的测试中等。
6总结
人类发展是一个发现问题,解决问题的改善过程。软件业的发展带来的问题,需要通过软件测试来解决,因此软件测试受到越来越多的关注和推广。同时面向对象、Agent 等新技术的应用为软件测试发展带来新的机遇。
摘 要
互联网信息高速发展的大背景下，无论硬件软件的复杂程度，还是技术含量都在日益提高，人们对软件的需求也越来越高。与此同时，软件中存在的漏洞和缺陷也迅速成为黑客攻击的对象，因此，建立一套高保障性的技术体系以保护软件的研制和可靠性成为当下社会研究的当务之急。
【关键词】软件应用 软件开发 软件测试
1 工程实例
1.1 测试过程
软件开发是一个常规的过程，在当今时代环境下，一般分为4个阶段，每个阶段中都需要对软件进行内部测试，一般分为：静态分析、代码审查、单元测试、部件测试、配置项测试。
1.1.1 静态分析
使用专业静态分析工具，对软件应用的程序，数据等参数进行剖析，并进行深入的数据分析，将软件应用内部的静态信息和代码信息提取出来，为未来的动态测试提供参考数据，并根据现在的软件模型，对软件的质量做出正确评价。
1.1.2 代码审查
主要是对代码进行一系列专业的检查过程，对代码的容错绿，代码运转结果的一致性，代码的可读性等进行检查分析。重点对代码的逻辑性，完整性进行检查，保证正确率。
1.1.3 单元测试
按照软件设计的说明图，模拟软件运行环境和运行部件，针对软件的环境进行接口模拟，并创造出软件的真实运行环境，进行测试，监测软件的运行结果。
1.1.4 部件测试
按照被测软件的说明图，在单元测试的基础上，将各个测试成功的单元模块按需求和设计组装成一个符合设计需求的整体功能模块，并进行测试，其目的是监测软件各个单元和接口之间的兼容性和容错率，保证软件的设计成功。
1.1.5 配置项测试
所谓配置项是软件中为满足不同用户的不通需求而设计的，能体现用户个性化功能的配置功能项，测试的目的是监测配置项在软件中的一致性。
1.2 问题现象
某产品软件到了后期阶段仍在进行频繁更改，通过对其分析，得出软件复杂度高是其存在的主要问题：
（1）模块在结构上应使用单出入口的结构，降低复杂性。
（2）在模块的逻辑设计上进行改进，采用分层次的结构，并在不同层次上设计不同的扇入扇出数，保证模块的扇出数较低，一般不超过7，并且尽可能的增加模块的扇入数，以保证代码的简洁性。另外，高层模块的设计应该采取不同策略，比如高层模块扇出较高，低层模块扇入较高等。
（3）软件单元的圈复杂度（即McCabe 指数）应小于10。
（4）简化软件单元的源代码数量，高级语言实现的单元，不应超过60行。
1.3 问题分析
测试的目的是为了更正软件的错误，降低风险率，一般来说经过几个阶段的测试后，软件中的缺陷基本都能被修复，但是没有重视静态分析中的软件圈复杂度，基本复杂度超标的现象，软件在后期的高复杂性往往会带来潜在的风险。
2 测试指导设计
2.1 软件质量的pareto原理
pareto原理[2] 指出，20%的软件模块包含了软件中80%的缺陷，20%的软件改进，需花费80%的适应性维护费用。从这里可以得出结论，高复杂的模块会导致软件中可能出现的绝大部分错误，而且不容易修复。因此，在软件设计早起杜绝复杂度过高的风险十分必要。
2.2 降低软件圈复杂度
2.2.1 圈复杂度定义
圈复杂度作为一个衡量软件结构复杂性的标准，数量上表现为独立线性路径条数，即合理的预防错误所需测试的最少路径条数。1976年ThomasMcCabe提出了圈复杂度（Cyclomatic Complexity）的概念，依据圈复杂度定义了软件的复杂性。1977年Halstead提出了软件科学复杂度度量。文献[3]，在这个理念中重点分析了嵌入式软件的位置的重要性，并通过模型的方式展示了软件复杂度的度量对识别代码错位的重要性。可以看出，软件的错误和缺陷并非随机分布的，而是有迹可循，和软件的个性化，复杂度息息相关。
2.2.2 复杂度计算方法
C语言常用的软件模块逻辑结构（结构流图）有如下几种，如图3所示。
2.2.3 降低圈复杂度
如果圈复杂度高于标准值的时候，可以提前做出判断，降低代码的复杂度和重复性。在判断语句中采取单一的判断条件，或者将重复代码用一个函数来替代。都是降低代码复杂度和重复性的有力措施。
2.3 降低软件基本复杂度
运转正常的语句或代码应带保证单入口和单出口结构，保证程序的简洁性，不应过多使用异常跳转语句增加程序的运转复杂度，如果非结构化语句过多，出入口增大，只会导致结构的复杂度增高，增加软件后期运行的风险。
因此，只要控制程序语句的结构单一化，简单化，避免各种非正常跳转语句的使用，复杂度就会在可控制的范围内，有利于程序的运行稳定。
2.4 降低软件扇出数
扇出的意思是函数调用其他函数的个数，如果扇出过小，则会导致程序代码过长，如果扇出过大，则会增加程序内函数的调用次数，影响速度，一般来说扇出最好为3或4个，最高不超过7个。
扇入的意思是一个函数被其他程序调用的次数，扇入较多会增加模块的使用频率，但是过高的扇入会影响程序的聚合性，如果扇出扇入次数过高，可以考虑重新调整该函数或过程。
3 结语
本文通过以测试结果来倒向改进软件设计的思路，提高了软件的设计质量和可靠性，可以看出，在软件代码内部进行早期分析，在软件设计早期对软件代码，复杂度等指标进行优化限制，对软件后期的稳定运行，错误率降低有非常大的影响和帮助，成为软件改进的新思路。
作者单位
天津滨海职业学院 天津市 300451
