关键词：黑盒测试；等价类划分；用例
中图分类号：TP311文献标识码：A文章编号：1009-3044(2012)02-0322-02
Design and Implementation of Testing Case of Black Box Based on Equivalence Partitioning
CHU Shu-lai,LI Wei-li
(Zhoukou Vocational and Technical College,Zhoukou 466000,China)
Abstract: Equivalence partitioning is one of the Black Box Testing approaches adopted frequently.It can be used to design testing case from different angles, for discovering the maximum errors and defects with the minimum testing case.
Key words: black box testing; equivalence partitioning; testing case
软件测试是根据软件开发规格说明和程序的内部结构而精心设计一组测试用例，并利用这些测试用例去运行程序，以发现程序中错误的过程.通过软件测试可以暴露软件中存在的错误和缺陷，从而提高软件的可靠性。特别地，随着软件规模和复杂性的不断提高,软件测试成本也不断增加，软件测试技术也越来越得到重视。如何实现用少量测试用例来实现高覆盖率的软件测试呢，基于等价类划分的黑盒测试技术能很好解决这个问题。
1基于等价类划分的黑盒测试概述
1.1黑盒测试概述
黑盒测试是使用规格说明，不要求考察程序代码，以用户的视角进行的测试，对于测试者而言，只要求有关被测试产品的功能认识，不一定了解系统内部逻辑，也不一定了解构建该产品所使用的程序设计语言，一般黑盒测试进行的是保证功能与兼容性测试。
1.2等价类划分概述
等价类划分是一种基于黑盒测试的软件测试技术，用于确定少量能够产生尽可能多的不同输出条件的有代表性的输入值，这种方法可以减少用于测试的输入、输出值的排列组合，从而提高覆盖率，降低测试工作量。
等价类划分试图定义一个测试用例以期发现一类错误，由此减少所需设计测试用例的总数。在等价类的划分集合中，一般要确保两个特性，一是完整性，也就是说划分出来的子集合的并集是整个集合；二是不相交性，也就是说划分出来的子集合是互不相交的一组子集。还需要说明的一点就是，这些等价类中的测试用例会以与同样的方式进行“相同处理”。当我们考虑结构性测试时，将会看到“相同处理”映射到“遍历相同的执行路径”。
2设计测试用例的步骤
2.1等价类划分表的设计步骤
首先选择等价类划分的判断准则，根据次准则确定有效等价类，从划分中选择一个样本数据；根据给定需求（或规约）编写出预期结果，确定可能有德特殊值，添加到到用例表中；检查是否所有测试用例均给出了预期结果，如果对任何具体的测试不能给出明确的预期结果，可将其标注出来，并进行及时更正。
2.2用例设计步骤
在测试用例的设计中，首先要按等价类划分表中的每个等价类确定一个唯一编号，其次是用例要尽可能多的覆盖尚未被覆盖的有效等价类，然后逐一设计仅覆盖一个还未覆盖的无效等价类的测试用例。
3基于等价类划分的软件测试用例设计
3.1规约：工资支付系统规约
工资支付系统允许员工以无纸化的方式来登记时间卡信息，并自动根据员工的工作时间和销售总额（对于有提成的员工）来生
成用于支付工资的支票。员工可以通过该系统输入时间卡信息和交易订单信息，更改员工首选项（例如支付方式），并生成多种报告。该系统可以在每个员工的个人台式电脑或便携式电脑上运行。出于安全和审计的需要，员工只能访问和编辑自己的时间卡信息和销售订单信息。本文中仅对桌面系统登录验证模块进行测试，其余部分规约略去。
3.2桌面系统登录事件分析
主事件流：当系统提示员工输入员工编号(ID)和口令(PW)时，用例开始。员工可以扫描卡片再按回车提交员工编号(ID)，然后通过键盘输入口令(PW)，并回车或点击确认按钮。系统就检查员工的号码和口令(PW)输入是否合法。如果是合法的，系统就显示员工的基本信息和可选操作，然后结束这个用例。
可选事件流：如果员工输入了一个不合法的编号(ID)或口令(PW)，系统就显示错误消息，用户可以选择重新输入或取消，重新输入则回到主事件流，若取消则该用例结束。
可选事件流：如果员工输入的编号(ID)已过期或被禁用了，系统就显示提示消息，并记录该次登录事件，该用例结束。
可选事件流：如果员工连续3次输入不合法，则显示警告并锁定屏幕，进入等待管理员解锁用例。
3.3工资支付系统等价类测试用例设计
3.3.1工资支付系统员工基本信息表
对编号(ID)和口令(PW)的判断是基于数据库中员工信息的，假定员工基本信息表1如下（此表中只列出编号(ID)、口令(PW)、是否过期三项，其余项信息与本文关系不大，暂且略去）
表1员工基本信息表
3.3.2桌面登录系统问题的等价类划分 在等价类划分中，一般是将程序的输入划分为若干个数据类，从中生成测试用例来实现软件测试。基于输入的等价类划分如表2所示。
表2桌面系统登录问题的等价类
3.2.3桌面系统登录问题的等价类测试用例设计
表3桌面系统登录问题的等价类测试用例
3.3.4基于输出域的等价类划分
从被测试程序的输出情况划分等价类（如表4所示），也可以作为等价类划分的标准，在这里就仅作一例证，不在详细说明。通常情况下，基于输出的等价类划分与基于输入的等价类划分结合起来使用，能更好地提高测试的覆盖率。（下转第350页）
（上接第323页）
表4桌面系统登录问题的四个等价类测试用例
4结束语
等价类划分测试是黑盒测试的重要技术之一，对软件功能测试、可靠性测试起关键作用。通过不重复同一个划分中的相同测试，可以最大限度地降低测试的冗余，结合一些专门的测试工具软件，能够实现对软件的进行合理、高效的测试。
参考文献：
[1]韩丽媛.黑盒测试及测试工具Rational Robot的应用[J].计算机工程与设计,2006(2).
[2]浦云明,陈黎震.基于划分的等价类测试[J].计算机工程与设计,2009(19).
[关键词]卓越工程师教育培养计划 岩土工程测试技术 教学改革 创新能力 实践能力
引言
“卓越工程师教育培养计划”（以下简称“卓越计划”）是为贯彻落实党的十七大提出的走中国特色新型工业化道路、建设创新型国家、建设人力资源强国等战略部署，贯彻落实《国家中长期教育改革和发展规划纲要（2010-2020年）》实施的高等教育重大计划，2010年6月教育部启动了“卓越计划”[1]。2011年10月，重庆交通大学入选教育部第二批卓越工程师教育培养计划，为适应人才培养从传统的教育模式向“卓越计划”培养模式的转变，重庆交通大学土木工程专业中实践性较强的课程均在积极探索全新的教育改革模式。
“岩土工程测试技术”主要介绍了边坡、软土地基、桩基、城市地铁区间隧道盾构、基坑、地下隧洞矿山巷道等岩土工程现场监测和检测技术以及无损检测与声发射技术。该课程的主要目的和任务是：通过对本课程的学习，掌握岩土工程测试的基本理论和方法、常用测试仪器工作原理、不同岩土工程的测试项目、测试方法、数据采集和整理等。该课程是土木工程（岩土工程方向）理论与实践结合的至关重要课程，也是培养学生工程实践能力、锻炼学生综合能力和执行“卓越计划”的最佳课程之一。
本文以重庆交通大学岩土工程专业课程 “岩土工程测试技术”为例，进行了适应“卓越计划”人才培养的教学改革探讨。首先，分析现有“岩土工程测试技术”课程教学现状和存在问题；其次，探讨该教学模式与“卓越计划”要求之间的差距；第三，针对现阶段教学模式的问题进行改革，探索一套与“卓越计划”人才培养相适应的教学模式。
一、教学模式现状及存在问题
在土木工程（岩土工程方向）课程设置体系中，“岩土工程测试技术”课程具有毋庸置疑的重要地位，是从基本理论过渡到工程实际的重要桥梁。本校开设了“岩土工程测试技术”课程和“岩土工程测试技术”实验课程。
传统教学模式主要包括多媒体教学、工程现场教学、换位教学法、以施工图为中心的教学法及情境教学法等，这些教学措施悉数被应用于普通本科及高职院校的“岩土工程测试技术”课程教学[2]。多媒体教学在播放岩土工程勘察测试技术动画、视频与现场录像或现场参观等方面起到了至关重要的作用，加深了学生对测试技术的感性认识，激发了学生一定的创造欲和兴趣。但是由于课时的限制、课程内容安排以及教学条件的限制，不能运用多元化的教学手段，最终还是落入以教师为主体，满堂灌、注入式的教学方法和多媒体配合板书的教学手段，取得的教学效果也相应不如人意。
因此，针对以上传统教学模式和理念，结合课程内容未能体现前沿科技、重理论轻实践、实验项目与课程不符、考核方式死板等问题，对“岩土工程测试技术”这门实践性、综合性较强的课程而言，不能满足其教学目标和要求。
（一）课程内容未能体现前沿科技
本校采用任建喜主编、武汉理工大学出版社出版的《岩土工程测试技术》为主要教材，内容共分9章，介绍了岩土工程测试技术中常用的传感器的原理和使用方法后，重点介绍岩土工程现场监测和检测技术，包括边坡工程、软土地基和路基、桩基工程、城市地铁区间隧道、基坑工程、隧道工程和地下洞室等，以及地下工程无损检测技术和声发射技术等内容。
现行使用教材为第1版，书中难免有逻辑和编写上的错误；现行课程教学虽然在前期教学中有所积累和改进，但很大程度上都是传统课程内容的沿袭。现有教学内容体系虽然在知识的系统性和完整性上尚可，但对知识的进一步拓展、新材料、新技术、新工艺等方面知识点和前沿科技尚有待完善。
新技术历来都是岩土工程领域发展水平的一个重要标志，也是岩土工程建设的重要支撑。随着近年来岩土工程技术取得了突飞猛进的发展，很多新型测试装备、创新性的技术被应用到岩土工程监测与检测工程中，如岩土体的室内测试技术、CT技术、离心模拟技术、遥感影像技术、多功能触探装置、多功能钻机以及各种新型智能化岩土工程测试仪器和技术等[3， 4]。
（二）重理论轻实践
本校为“岩土工程测试技术”安排56学时的理论教学和16学时的实验教学，一共4学分，教学内容和课时安排较合理。但是，一方面，由于教学主要以教师为主体，强调教材作用，很难将工程实践内容贯穿于课堂教学始终[5]；另一方面，施工单位鉴于安全和工期方面的压力，不愿接收大量学生到工程现场参观学习课堂；第三，教学中的实践环节主要靠任课教师根据所参与的工程科技服务项目及经验积累，在课堂教学之外未曾安排施工现场观摩学习。因此，以上种种条件的制约，学生看到的只是某一阶段的状态，很难看到全过程，这就直接导致课堂理论教学和工程实践之间脱节现象。学生的工程实践能力、动手能力以及协同创新能力无法得到充分锻炼。
（三） 实验项目与课程不符
本校为“岩土工程测试技术”安排的16学时的实验教学，对应的实验教学大纲如表1所示。鉴于实验场地和实验设备的不足，实验项目存在拼凑的嫌疑。一方面，实验教学内容一共有8个，其中5个演示实验，学生的动手能力和实践能力得不到发挥和体现；另一方面；“岩土工程测试技术”课程安排内容主要涉及前4个实验项目，其他4个实验项目没有涉及；第三，实验项目存在和其他课程重复的现场，如材料疲劳强度测试实验应该是力学实验、岩石三轴实验为岩石力学实验、土体三轴实验为土力学实验等。
表1：“岩土工程测试技术”实验教学内容
（四） 考核方式死板
科学、合理的考核方式既是对学生知识掌握情况的检验也是教师教学质量的体现，因此具有重要意义[2]。不同的考核方式，对学生的学习方式及知识的掌握有很大关系。
本课程教学大纲规定课程考核方式主要采取笔试形式，兼顾学生实验成绩和平时考勤成绩，即课程成绩=平时成绩×10%+实验成绩×20%+期末成绩×70%。试卷题目类型主要包括填空题、简答题与论述题。对于这种题型较单一和死板的卷面考核，学生主要还是根据考试范围死记硬背，印象不深刻，而最后落入应试教育，埋没了学生的个性和兴趣。因此，对于“岩土工程测试技术”这种实践性很强的课程而言，无法考核学生的实践能力、创新能力和解决实际问题的综合能力。
二、与“卓越计划”要求的差距
现行教学模式主要以教师为主、强调学生对基础知识的理解与掌握，对实践能力的培养尚有欠缺，对创新能力、团队协作能力与综合解决问题能力的培养基本为零。因此，为满足卓越土木工程师培养需求，在“岩土工程测试技术”教学改革方面应具有符合“卓越计划”要求的全新模式。
三、课程教学模式改革
（一） 完善教学目标与任务
针对“卓越计划”的三大培养特点，在“岩土工程测试技术”教学过程中应更加侧重工程实践能力、创新能力的培养。通过教学内容的调整、教学模式的改革、考核机制的完善，掌握岩土工程测试的基本理论和方法、常用测试仪器工作原理和使用方法，达到岩土工程行业对检测员的基本要求。
本课程以新教学大纲安排的教学内容为主线，重视基础理论和应用技术的掌握，嵌入对应的岩土工程监测工程实例、室内演示实验和综合实验、工程监测布置的实地观摩，培养学生的动手能力、团队合作能力、交流能力、创新能力等。
（二） 课程教学内容调整
根据“卓越计划”的目标与任务，结合“卓越计划”的三个培养特点，对现行的教学内容进行调整及优化。
优化教学内容。存在以下三方面优化项目：教学内容缺少常规以及新型检测仪器的使用和原理介绍，监测方法比较陈旧，某些工程实例针对性不强等问题；扩充教学内容，增加滑坡工程的监测内容，第三章边坡工程监测合并；近年来，随着国内外岩土工程测试技术的发展，更经济合理的新监测方法出现，机械化、信息化和智能化程度更高的新测试仪器设备研发，因此，教学课程中应加入新型监测方法和仪器的使用方法介绍。
调整教学重点。重点讲解边坡与滑坡工程、软土地基和路基、桩基工程、隧道工程、基坑工程等现场监测和检测技术，其中监测仪器的使用和监测方案的制定（监测项目、监测布置、监测方法）是重点。
精简教授内容。首先，如果前期相关课程如岩石力学、土力学、工程测量涉及的内容只做简要提及，并不详细介绍。其次，将和隧道工程有关的两章合成一章内容，避免重复讲述。
增加岩土工程测试技术方案制定。结合全院教师参与的各种岩土工程监测项目，让学生以实际工程为背景，根据所学基础知识和工程实例制作岩土工程检测技术方案，这不但培养了学生工程实践能力、创新能力，还培养了学生的组织能力。
（三） 教学实验内容调整
以“卓越计划”要求的各种“能力”培养为主线，完成教学实验内容调整。新实验教学内容保留了原实验教学大纲的四个项目，将另外四个项目替换为：常用传感器原理、使用与标定、桩基工程低应变动测法实验、隧道周边位移收敛量测和隧道围岩内部位移量测，具体见表2所示。由于本校的岩土工程侧重于隧道与地下工程，因此实验教学内容有较多项目涉及。调整后的新教学实验大纲，侧重于学生的实践能力、团队合作能力的培养，鼓励创新性项目的开展。
表2：“岩土工程测试技术”新实验教学内容
（四）考核方式调整与完善
考评是引导师生的指挥棒，大多数学生和教师总是在现行的评价体系引导下寻求“佳绩”[2]。以考核学生各项综合能力为目的，重点考评学生对书本知识的掌握以及应用、分析和解决实际问题的能力。“岩土工程测试技术”课程考评改革包括以下四方面内容。第一，基础理论卷面考核。保留通过闭卷考试形式进行基础知识掌握情况考核的传统方式。考试题型增加单选题、判断题、多项选择题以及案例分析题，结合原有的填空题、简答题与论述题，一共有七道大题，实现了题型的多样化。题目的设计注意不要落入死记硬背的套路，着重考核的是学生对基本理论的理解和运用，注意平时积累，参与课堂讨论与案例分析之中，达到综合分析能力和实践技能的提高。第二，增加“岩土工程测试技术”课程设计，考核学生的综合分析能力、实践能力、创新能力和团队协作能力。根据本学院教师参与项目，变换各种设计参数、环境条件和目的要求，设计具有实际背景的岩土工程监测项目，鼓励学生充分发挥个人优势和团队协作能力，设计出具有创新性的方案。第三，实验成绩。依照实验大纲安排的实验教学内容，根据学生实验报告考察学生的动手能力、实践能力和实验结果分析处理能力综合评定成绩。第四，平时成绩。根据学生的考勤、课堂上的积极性和主动性以及急性思维的活跃度计分。根据以上四部分所占本课程的比重，考评计分采用以下算法：课程成绩=平时成绩×10%+实验成绩×25%+课程设计成绩×15%+期末成绩×50%。
四、结语
根据“卓越计划”的目的和任务，结合“卓越计划”的三个培养特点，针对现行课程教学中存在未能体现前沿科技、重理论轻实践、实验项目与课程不符、考核方式死板等问题，对“岩土工程测试技术”课程开展以下四方面的教学改革：完善教学目标与任务；课程教学内容调整、教学实验内容调整、考核方式调整与完善等。
此项教改以培养学生综合分析能力、实践能力、创新能力与团队协作能力为目标，培养出复合型、高素质、满足“卓越计划”要求的优秀工程型人才。
[参考文献]
[1]中华人民共和国教育部.教育部关于实施卓越工程师教育培养计划的若干意见[Z].2011，1，18.
[2]朱劲松.面向卓越工程师培养的桥梁施工课程教学改革与实践[J].高等建筑教育，2012，21（3）：71-75.
[3]伍法权.我国岩土与工程研究的现状与展望――第三届全国岩土与工程大会学术总结[J].工程地质学报，2009，17（4）：463-468.
[4]包承纲.岩土工程试验研究中的若干新进展[J].岩土力学，2011，32（增2）：1-9.
[5]董倩，刘东燕，黄林青.卓越土木工程师实践教学体系构建[J].高等建筑教育，2012，21（4）：74-77.
【关键词】软件生命周期；质量管理；软件测试
1.引言
软件质量是指与软件产品满足明确或隐含需求的能力有关的特性，由于软件产品是逻辑体，不具有实体的可见性，因而其质量也就更加难以把握。软件产品的质量是通过软件开发活动和软件开发过程构造入软件的，所以软件开发管理者和软件开发者必须了解每一个开发活动对软件产品质量可能产生的影响，及时掌握每一个开发活动对软件质量所产生的影响，并且对在开发过程中可能产生的或已经产生的质量问题，能够及时发现并加以控制。要做到这些必须实现软件开发的工程化。软件全生命周期质量管理实际上就是工程化管理。它的主要任务就是使软件开发活动规范化、程序化、标准化。软件质量管理的基本方法就是根据软件开发活动的各阶段，将质量管理目标分解为若干可实现并可管理的部分，并采用相应的技术和方法进行管理，并对其阶段性产品的质量进行验证，确保最终软件产品质量满足用户的要求。下图是一个软件开发过程的主要阶段分解图。
2.需求分析阶段
2.1 任务及目标
软件需求分析阶段的任务是确定所开发软件的运行环境、功能和性能要求，编写开发计划。软件需求分析是由软件开发方根据委托方提出的软件任务书以及其它文件，详细确定软件需求并编制出一个需求完整、详细的软件需求规格说明。
2.2 实施步骤
1）分析和确定软件开发和运行的环境；2）明确操作者的要求，经分析后将任务书中的技术指标条文拟定成相应的软件需求规格说明的条文；3）确定人机界面；4）编制项目开发计划，确定项目质量要求，并将它分解为对软件开发各阶段的质量要求，给出检查准则；5）确定本项目的质量保证、配置管理工作，并写入项目开发计划；6）编写软件需求规格说明；7）初步编写软件测试工作计划，明确计划安排。软件测试工作计划一般由软件项目组编写。如要求独立测试，则测试计划应由独立测试单位在本阶段评审通过后根据需求规格说明另行编写；8）开始编写软件使用说明；9）评审；10）安排测试工作。若需要开发专门的测试软件或研制专门的软件测试设备，则应在本阶段评审通过后与软件开发并行地进行此项工作，以保证软件测试工作按时顺利进行。软件测试的测试软件开发和测试设备的研制工作按计划由软件项目组或独立测试单位承担。
2.3 阶段产品
1）项目开发计划；2）软件需求规格说明；3）软件测试工作计划；4）软件项目计划数据表。
2.4 技术要求
1）软件需求规格说明应对软件的主要功能、性能、技术指标进行定义，其内容应全面、可检查；2）项目开发计划中应给出阶段评审及配置管理计划，并明确人员。
2.5 配置管理要求
软件任务书、开发计划、软件需求规格说明、软件项目计划数据表、软件需求分析阶段评审表、软件测试工作计划进入受控库。
2.6 评审要求
在软件需求分析阶段，必须进行软件需求评审，以保证软件需求的完整性、一致性和准确性。提交软件任务书、项目开发计划、软件需求规格说明、软件项目计划数据等，针对项目开发计划及软件需求规格说明，对任务和需求分析、可行性分析、质量保证、标准化、配置管理等进行评审，以决定是否开展下阶段工作。
3.软件设计阶段
3.1 任务
软件设计阶段的任务是根据软件需求规格说明进行软件的总体结构和功能模块间的设计，初步编制软件集成测试计划。定义各功能模块的接口并设计数据结构，对功能模块进行过程描述设计，设计功能模块的内部细节，包括算法和数据结构，为编写源代码提供必要的说明。
3.2 实施步骤
1）总体结构设计；2）设计该软件系统的数据结构，给出所需的模型及所采用的算法原理；3）设计高层模块的数据流和控制关系；4）给出各个功能模块的功能描述、数据接口描述及全局数据定义；5）根据软件可靠性要求，对各功能模块进行可靠性指标的分配和相应的可靠性设计；6）进行安全性分析，使安全性关键的软件设计符合安全性要求；7）初步编制软件集成测试计划；8）确定所有模块的功能及详细的接口信息；9）对构成软件系统的各功能模块逐步细化，形成若干个可编码的程序模块或程序单元。
3.3 阶段产品
1）软件设计说明；2）软件集成测试计划（初步）。
3.4 技术要求
1）各功能模块间应具有低耦合度及高内聚度，功能模块的作用范围应在其控制范围之内；2）各模块功能单一，模块接口的复杂度低；3）软件设计说明和软件需求规格说明要保持一致，并具有良好的可追踪性；4）各子项目、模块的功能和接口要求必须完整、正确。
3.5 配置管理要求
集成测试计划（初步）、软件设计说明进入受控库。
3.6 评审要求
评审软件设计是否实现了软件需求规格说明的要求；评审设计方案与主要算法的可行性和先进性；并针对集成的单元之间的信息流和控制流的可追溯性、数据加工处理与数据结构的一致性、并发性信息处理的正确性、可靠性和安全性技术应用的程度及正确性等进行评审，并最终做出本阶段工作是否完成、是否转入下阶段工作的评审结论。
4.代码开发阶段
4.1 任务
根据软件设计说明对各程序单元进行编码、调试、静态分析和单元测试，验证程序单元与设计说明的一致性，并将经过单元测试的模块逐步集成和调试，完成软件系统集成，
4.2 实施步骤
1）对每个程序单元用指定的程序设计语言进行编码和测试；2）对完成编码的源程序进行静态分析；3）补充和完善单元测试用例并依此产生测试输入数据，开发单元测试程序；4）进行程序单元测试；5）将经过单元测试和调试的程序逐步集成和调试，直至集成为相对独立的软件功能模块；6）及时清除程序中用于调试等项工作的多余语句和程序“垃圾”；7）在集成调试后，对经过修改的模块应进行单元回归测试；8）编写软件使用说明初稿；9）评审。
4.3 阶段产品
1）修改了的软件设计文档及相应的修改报告单；2）程序单元的编码；3）程序单元的测试结果、测试用数据及测试辅助程序；4）软件使用说明初稿。
4.4 技术要求
1）用指定的编程语言进行编码；2）编码符合规定语言的编码格式约定；3）每个程序单元实现的功能、性能和接口应该满足设计说明的要求；4）必须进行程序静态分析；5）按要求应分别采用自检、互检、专检等方式检测软件，以提高软件质量和可靠性；6）被测试单元中的每项软件特性和功能都必须被至少一个测试用例所覆盖；7）采用必要的安全性设计措施，保证安全性设计需求的实现；8）对在单元测试中发现错误的程序应进行修改，修改后的程序单元必须进行回归测试；9）不仅要考虑对合法的输入产生测试用例，而且要对非法的、非预期的输入产生测试用例，既要对正常的处理路径进行测试，也要考虑对出错的处理路径进行测试； 10）程序单元的测试用例需加明确的注释，并和测试辅助程序一起纳入测试集，存档保留。
4.5 配置管理要求
修改的文档和相应的修改报告单、软件使用说明、程序单元的代码、单元测试数据和测试程序、软件实现阶段评审表进入受控库。
4.6 评审要求
评审编码、单元测试的正确性和完整性，在完成文档、程序编码、程序单元调试及单元测试的前提下，提供程序单元的编码、程序单元测试的结果和测试用例、程序开发卷宗等，对程序代码与详细设计的一致性、代码格式与规定要求的一致性、程序代码调试结果的正确性、静态分析过程的正确性和合理性、单元测试用例的充分性和合理性、单元测试数据的产生和测试过程的正确性、合理性和完整性、软件实现过程中若修改了软件详细设计或概要设计，则应多途径审查从被修改阶段开始到软件实现阶段为止所有改动部分的正确性等进行审查，做出软件实现阶段是否完成、是否将程序和文档提交，以便进行软件集成测试的结论。
5.集成测试阶段
5.1 任务
根据集成测试计划，在将底层程序单元逐步集成到子项目、直至整个开发项目的过程中对软件进行测试。在进入集成测试前，各程序单元必须完成代码静态分析和逐步审查、无错误地通过编译或汇编、完成单元测试、满足软件质量要求、程序单元已置于软件配置管理之下等。
5.2 实施步骤
1）补充、修改和完善软件集成测试计划；2）校订集成顺序，编制软件集成测试程序并核对其正确性；3）建立软件集成测试环境；4）对集成软件功能模块进行测试；5）对集成软件子项目进行测试；6）对集成软件产品总体进行测试；7）分析测试结果，找出产生错误的原因；8）提交软件集成测试分析报告，以便尽快修改错误；9）完成软件使用说明的编写工作；10）评审。
5.3 阶段产品
1）修改后的软件集成测试计划；2）修改后的软件设计文档及相应的修改报告单；3）软件集成测试分析报告；4）通过集成测试的代码；5）集成测试用例集和集成测试辅助程序；6）软件使用说明。
5.4 技术要求
1）软件集成测试应保证模块间无错误地连接；2）应测试软件系统或子系统对数据的正确处理能力和经受错误的能力；3）在软件集成测试中，在找出错误后，程序应送回编码者进行修改、调试和单元测试，然后再重新进行软件集成测试；4）通过软件集成测试的软件应满足各模块无错误地连接、满足各项设计要求、对错误输入有正确的处理能力、人机界面正确无误、满足全部操作要求等。
5.5 配置管理要求
软件集成测试计划、修改的软件设计文档及相应的修改报告单、软件集成测试分析报告、最后集成完成的程序代码、集成测试用例集和集成测试辅助程序、软件使用说明、软件集成测试的评审报告进入受控库。
5.6 评审要求
评审集成测试结果的有效性、软件的结构和接口间的协调性；评审在软件集成测试中对所发现的问题进行软件设计修改、程序代码修改的正确性。在完成测试、测试分析和文档提供软件集成测试计划、软件集成测试分析报告、软件问题报告单的前提下，对软件集成测试的恰当性、测试用例集的完整性和恰当性、测试结果和测试用例集的一致性、测试环境和正式运行环境的相容性、测试分析过程和结论的正确性等进行评审。
6.确认测试阶段
确认测试主要是针对软件的全部功能和性能要求的黑盒测试。软件项目开发单位的质量管理部门的测试人员负责测试过程的实施和测试结果的确认，技术管理部门的有关人员与业务部门及项目组成员共同组成确认测试小组，完成确认测试任务。
6.1 任务
1）根据软件需求规格说明中定义的全部功能和性能要求及确认测试计划，测试整个软件，确认其是否符合软件需求规格说明的要求；2）软件确认的依据是软件需求规格说明、概要设计说明及详细设计说明等，测试对象为通过了软件集成测试的源程序代码；3）软件确认测试工作包括测试环境的建立和测试计划的编制两项，此两项工作在软件需求分析阶段就应开始。
6.2 实施步骤
1）组织和确定软件确认测试组成员；2）修订确认测试计划，对确认测试计划进行评审，经批准后实施；3）建立和确认软件测试环境；4）接口测试；5）根据软件需求规格说明中规定的功能对软件逐项进行测试；6）根据软件需求规格说明中规定的性能要求，如精度、速度、适应性等，对软件逐项进行测试；7）逐条运用软件使用说明进行测试，以进一步证实该说明的适应性和有效性，并改正其中的错误；8）分析测试结果，找出产生错误的原因；9）编写确认测试报告；10）评审。
6.3 阶段产品
1）确认测试计划；2）确认测试分析报告；3）确认测试用例集及有关测试辅助程序；4）通过确认测试的程序代码。
6.4 技术要求
1）关键软件部件或测试项目的确认测试应由与该软件项目组无关的技术人员进行，以保证测试的客观性；2）应在正常输入数据和合理的异常输入数据的条件下，考查被测软件功能和性能的完备性；3）确认测试的测试环境必须与软件真实运行环境一致或相容；4）全部测试结果、预期结果及测试数据应当存档保留；5）个别功能和接口要求只能在系统联试后才能确认的，必须在确认测试分析报告中写明；6）软件项目组应积极配合确认测试组的测试工作。
6.5 配置管理要求
确认测试计划、确认测试分析报告、确认测试用例集及有关测试辅助程序、通过确认测试的程序代码、确认测试计划评审表和确认测试阶段评审表进入受控库。
6.6 评审要求
在本阶段应进行两次评审，软件确认测试计划评审和软件确认测试阶段评审。
1）确认测试计划评审
评审确认测试计划的合理性、完备性以及与软件需求规格说明的一致性。提供软件确认测试计划，确认测试计划安排的合理性；确认测试环境选择的合适性；确认测试计划中功能测试的合理性、齐全性；确认测试计划中性能测试的合理性、齐全性；确认测试用例、测试数据、测试方案的合理性、正确性和全面性；确认测试结果分析的合适性；确认测试组人员组成和安排的恰当性。该评审应得出的结论是该确认测试计划是否可行，是否批准实施。
2）确认测试阶段评审
评审确认测试结果的有效性；评审软件功能、性能与软件需求规格说明的相容性；评审确认测试分析结果的正确性。完成确认测试后提供软件确认测试分析报告、确认测试用例集，对确认测试用例集的完备性和恰当性、确认测试用例集和确认测试结果的一致性、确认测试环境和运行环境的相容性、确认测试分析过程和结论的正确性进行评审，最终确认该软件是否实现了软件需求规格说明所要求的技术指标，对确认测试过程不正确或不完整，需改进测试过程后重做或另外组织确认测试组重做。
7.系统联试阶段
7.1 任务
系统联试是大系统开发的一个重要阶段。系统联试应由大系统的开发部门主持，软件项目组参加，以保证软件与大系统的对接。
7.2 技术要求
1）软件与所属大系统的接口应重点测试，不允许有不协调之处；2）对软件向所属大系统输出的信息以及从所属大系统向软件输入的信息，都应仔细归类进行测试，并注意边缘测试；3）测试应在软件和大系统的正式工作环境下进行；4）对存在的问题应分析其产生的原因并给出修改意见；5）全部预期结果、测试结果及测试数据应存档保留。
8.总结
软件生命周期质量管理就是使软件开发过程规范化、程序化和标准化。它通过将复杂的问题分解为若干可实现并可管理的部分，对软件生命周期的各阶段采取相应有效的方法，对其阶段性产品的质量进行验证，以保证软件的质量。
参考文献
[1]周艳会，王静.软件质量管理的几点做法[J].电脑与电信，2012（4）：70-71.
测试项目启动与规划
一般地，项目启动过程组包括两个过程:即制定项目章程和制定项目初步范围说明书;而项目规划过程组则会综合项目的成本、范围、时间、质量、风险、人力、沟通、采购等因素制定项目计划，该项目计划将用于指导项目的实际执行。
对任一项目而言，有三个文件是非常重要的。即:项目章程、项目范围说明书，项目管理计划。这三个文件均产生于项目启动阶段和项目规划阶段。其中项目章程被认为是三大文件之首（项目章程、项目范围说明书，项目管理计划）。一个项目，不论大小，都应该有项目章程。
项目章程由项目发起人(Sponsor)签发，自签发之日起，项目经理即获得法定权力。
项目经理在获得法定权力之后的第一动作是制定项目初步范围说明书。为了制定这份文档，他/她将广泛地收集来自项目发起人的需求，以便在项目计划正式编制之前，与项目发起人在项目范围的理解上达成一致。项目初步范围说明书还将在后续项目范围规划过程中进一步细化，并融入项目客户、执行组织、项目干系人等各方面需求，进而形成完整的项目范围说明书。
项目初步范围说明书编制完成以后，项目经理将进入项目计划编制阶段。这个阶段将会涉及项目管理方方面面的规划、计划。有经验的项目经理在此过程中总是会认真听取和吸收团队骨干成员和同行们的经验意见，从而形成广为认可和接受的规划、计划。
经过权衡和必要的调整，这些文档最终将被集成到一个完整的项目管理计划中。项目管理计划经由项目发起人、高级管理层审批以后，即可生效。
此后，项目经理将召开项目开工会议，宣布项目正式开始进入执行阶段。
项目启动阶段的项目章程和项目初步范围说明书，也可以体现在分包或采购合同中。这在软件外包服务型企业中最为常见。
通常，伴随合同到达项目经理手中的还有项目建议书，项目建议书由项目发起人制定，内容和项目章程中有关产品、可交付成果的描述大致类似，此外，还应包括对项目经理成功完成此项目的一些指导性建议。项目经理进行综合考虑，与相关干系人磋商，在项目团队相关专家的帮助下，制定出合适的项目管理计划。
上面讨论的是一般项目启动过程组与规划过程组。具体到测试项目的启动与规划，工作内容也是类似的。读者朋友请根据所在测试项目的特点做适当调整。需要交待清楚的是测试项目启动与规划过程组有可能与其他六个过程组（测试需求分析、测试设计、测试执行、测试项目收尾、测试交付、测试项目监控与调整）在项目实施过程中有频繁的迭代关系（参见图1）。
比如，规划过程组有可能在整个项目生命期内都有更新和完善。
对于整周期软件开发项目的测试而言，上述过程组的内容会有较大的差异。
比如:项目章程将重点关注开发，而不会过多讨论测试相关的工作。对于这一类型的软件测试，笔者建议在任命开发项目经理的同时，由项目经理[适用于项目型或强矩阵组织]或高层经理[适用于弱矩阵或职能型组织]指定项目测试经理。测试经理应根据项目章程、项目初步范围说明书和项目建议书尽早开始软件测试相关规划和设计，并和项目经理沟通、协调，以将一些重要的信息及时反映给项目经理，从而使项目计划能较好地支持测试工作的开展。
软件测试需求分析
理论上，软件测试需求是源于软件需求的，而软件需求又是源于用户需求的。然而，有些时候在分析软件测试需求时并不存在已经文档化的软件需求规格说明。
在这种情况下，要分析软件测试需求可能仍然需要追溯到用户需求。由于后者涉及需求工程的专门知识，本文略过不做细述;这里重点讨论前者。在一个规范化的软件需求规格说明中，用户需求是由更高层次的业务需求（体现在项目章程、SOW、项目建议书等文档中）细化而成，它通常描述了用户使用该软件系统会涉及到的不同的执行路径、工作逻辑以及所预期的处理结果。在UML表示方法中，用户需求通常通过Use Case来进行刻画。
接下来，用户需求将进一步转化为三类需求项，即功能需求项、性能需求项以及约束性需求项。这三类需求项就是通常意义上的软件需求项。管理这三类需求项的矩阵被称为需求矩阵。
理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。（注意:为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。）
然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。
软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试（这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求和设计的确认），测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求（由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求）。
又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。
再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。
最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。
读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢？是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。测试需求的开发总是有赖于相应层次的软件规格说明书
只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。
除了对软件需求项、测试需求项做优先关系排序、对不具备可测试性或不确定的需求进一步细化、明确化之外，测试需求开发阶段的工作还包括分析各测试需求项之间可能的时间关系排序。哪些测试需求项应该先测，哪些可以延后，那些是可以并行等等，都需要在测试需求开发阶段一并分析清楚。
关键词：计算机；软件测试；质量监督；
中图分类号：TP311.52 文献标识码：A文章编号：1007-9599 (2011) 08-0000-01
To Enhance the Quality Supervision of Computer Software Test
Zhang Haixin
(Fuzhou University,Yangguang College,Fuzhou305515,China)
Abstract:Computer Software testing is an important computer performance evaluation method is also an important part of software engineering,computer-carrier in the work,the computer software is crucial.How to test the quality of computer monitoring software,computer workers is an important research subject.Software quality goals from the start this on a variety of different software to explore the supervision of the test.
Keywords:Computer;Software test;Quality supervision
一、计算机软件测试质量的目标
计算机的软件工程对从事软件开发的人中来讲，一个很大的冲击就是软件工程针对计算机软件的开发每一个方面都要进行量化。同时，计算机软件的测试也是这样，得有一个明确具体的目标，才能去衡量计算机软件测试和开始的真实水平。无目标的软件测量就好像瞎子摸象，没办法对软件的质量进行评价，也就没法确定测量是不是有效。其质量目标的确定要根据不同的计算机语言来设定，一般来讲，软件测试的质量是用千行缺陷率为单位衡量的。假如测试时出现的错误率比质量目标低，那么就说明测试的效率低，就需要重新对软件测试的用例进行审视，看测试的过程是不是合理的。假如测试时出现的错误率比质量目标高，那么就说明其软件的开发水平低，这就说明以后软件和测试会出现其它的错误。所以，在软件测量时发现的错误多则说明其质量也不高。
二、计算机软件测试的说明和测试的计划监督
研制计算机软件的过程中，就要对承制单位是不是按照相应要求进行监督。在计算机软件的需求分析时期就得制定相应的测试计划，在计算机软件总体概要的设计时期就得制定相应的集成测试的计划，在计算机软件具体设计时候制定出相应的测试计划。需要监督起承制的单位针对软件测试的计划评审，并通过评审以后按照测试的计划严格展开测试。一般来讲，软件测试的计划有以下几项内容：一是目的，要提出每一个测试的阶段进行明确的目的。二是标准，对每一个测试的阶段给出一个具体的标准。三是步骤，详细具体的安排每一个测试的时期，列出具体的时间安排，具体到执行、设计软件测试的时间。四是规定责任人，对每一个测试时期，要指定具体的责任人，由谁设计执行和对测试的结果进行分析等等，都要责任到人。五是测试的用例标准化，这主要是要求对测试的具体用例要存储、标识出来。六是测试环境及工具，元宝出测试时的环境和提供的工作，也要制定出相应计划，由谁来得到环境和工具，怎么使用等等。
三、不同软件测试的具体监督
对承制单位从事研究的过程中的各种不同软件测试进行监督，这主要包括软件的系统测试、集成测试和单元测试。
（一）对软件的系统测试监督
测试目的：对软件的系统测试环境是其真实的运行中的模拟，系统测试的时候，各个不同的部分实现研究成功的设备渐渐把模拟器把取代，这样的条件下，容易全面暴露相关的设备的接口、输入或输出以及处理器和设备间接口是否相容、系统的时序是否匹配等等细节。其适用的对象是在目标的计算机上所有运行的软件。测试的内容包括以下几个方面：一是系统的安全性；二是系统的可靠性；三是系统的余量；四是系统的强度；五是系统和软件的接口；六是系统的性能；七是系统的功能；八是系统的边界和敏感性；九是系统的边界，即用来测试的软件在系统的输出或输入域和性能及功能界限，以及状态的转换等端点和边限的情况下计算机的运作状态。只有满足以下要求，才算是通过了测试：一是在真实或高度仿真的环境里，计算机软件能够满足软件的需求里的性能和功能要求及对接口的需求说明里的规定要求；二是对发现出来的各种缺陷都被排除，并能顺利通过了软件的二次测试；三是对出现的问题做了详细的描述和记录；四是编写完计算机软件的测试报告并且顺利的通过了评审。
（二）对软件的集成测试监督
软件的集成测试指的是将不同的单元软件装配成高一层次的软件的部件来测试，最终形成整个的软件整体。其目的是为了对单元软件和部件间接口的关系进行检验，并最终把通过测试的部件建造成为符合具体设计的要求。适用对象包括计算机软件的配置项和软件的部件。测试的内容有计算机软件配置项的测试以及软件的部件测试，先对部件测试，然后把通过测试的部件装配成软件的配置项，再进行测试。软件的部件测试内容有部件和单元之间的接口、软件的部件功能、软件的部件性能、全局数据的结构等等；软件的配置项主要测试内容有接口的测试、性能的测试、输出和输入的通道、处理的时间和通信的能力、人机的界面、强度及安全性、软件的可恢复性、功能测试等等。只有满足了以下要求，才能通过测试：一是要达到软件地要求说明里规定的接口、功能和性能等软件的配置项的要求；二是针对已经发现的问题和缺陷都被排除，并能顺利通过了软件的二次测试；三是编写完计算机软件集成测试的报告并且顺利的通过了评审。
（三）对软件的单元测试监督
计算机软件的单元测试目的是为了对软件单元能不能满足性能、功能以及接口等等要求的验证，用于任何一个计算机的软件单元。测试的主要内容包括：一是语句的覆盖；二是边界；三是错误的处理；四是局部的数据结构；五是重要路径；六是单元功能的测试。测试的步骤：一是要做好测试的计划；二是建立测试的环境和编制说明；三是执行测试，记录相关信息；四是根据测试的结果判断能不能通过；五是针对不通过的情况，要分析出原因，并且经修正后再进行测试至通过为止；六是测试完成后续的工作，包括编写测试报告、将测试用例归档。只有顺利通过以下要求，才被认定为通过：一是被测软件的单元要和设计时的需求相一致；二是软件的单元接口要一致；三是可以正确的处理运行和输入时的错误；四是针对已经发现的问题和缺陷都被排除，并能顺利通过了软件的二次测试；五是要达到事先所定的测试结果覆盖率；六是编写完测试的报告。
参考文献：
[1]郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1992
[2]张江河.软件测试用例复用研究[D].西北大学,2005
关键词：城市轨道交通；动车调试；计划管理系统
1关键业务分析
1.1通用业务分析
动车调试和综合调试是一项极其繁琐的业务，主要工作包括系统保障、动车调试及综合联调。（1）系统保障需完成动车调试前所需的冷热滑试验，综合调试所需的供电、配电调试，动车及综合调试所需的传输、无线通信及其他系统保障。（2）动车调试主要完成线路部分的车辆型式试验，信号系统ATP/ATO功能测试，信号系统与屏蔽门、PIS、广播、无线、综合监控、TCC等系统动车测试，ATO模式下的定点停车调试、列车动态CI、ATS功能测试、CBTC按图多车追踪功能测试及其他调试内容。（3）综合调试主要实现，BAS与风水电、电扶梯、导向标识之间，FAS与风水电、门禁、ATS及气体灭火系统之间，ISCS与SCADA、PSD、AFC、ACS及通信等专业之间，ISCS与路网ACC/TCC之间的点对点、端对端调试和模式调试，以及中心级综合调试。由于城市轨道交通调试施工复杂、涉及单位多、专业广、交叉作业繁琐、技术接口复杂、作业标准高，且按车辆段、区间、车站、中心等分步进行，在整个过程需要相关专业、各施工单位及供货制造厂商的联合保障。为确保动车调试和综合调试工作安全有序进行，管理者需对各环节进行有效监督，遵循以调试量大的车辆和信号专业为主线并协调搭车试验的原则编制计划，合理安排分段试验和统筹安排各类施工调试计划，组织协调各单位交叉影响区域，通过数据综合分析整体把控施工、集成、动调服务商等各单位不同考核指标。
1.2计划管理基本流程
根据调试总体要求、管理办法、规章制度、调试大纲及应急预案，合理安排动车调试和综合调试作业计划，利用流程化控制节点对作业申请、作业审核、作业执行三大阶段进行把控管理。（1）作业申请阶段。动调计划编制应参照设计、监理、集成供货商及施工各单位调试前准备工作的完成情况进行。首先，由施工单位按照各专业作业模板发起计划申请，基本信息包括计划作业开始及完成时间、作业类型和内容，申请部门、联系人、受理部门、配合部门、相关的系统设备，以及风险分析、人员、物资、特殊工器具需求、工作许可和作业计划优先级别等。其次，系统按照时间顺序自动生成作业计划编号，供施工各专业负责人利用总体方案、指标计划及经验协作等对本专业的所有申请作业进行内容校核，并标识“已通过/未通过校核”状态。通过初步校核可列入作业计划，按照紧急程度、作业时间等，初步划分并发送至相关工作部门审核。（2）作业审核阶段。不同施工单位、系统专业的作业计划审核涉及以下几方面：①计划时间、作业区域、行车线路、其他专业配合条件、所需备件工具和消耗品及用电区域等资源情况；②需办理的各项许可（如动火、辐射防护、消火栓临时使用）等必要条件及关键要素；③动车调试技术方案及施工配合方案。由审核部门审查并检测这些作业计划的现场符合性，系统记录审核部门、人员、时间和审核意见并标识状态，审核通过即可按优先级排入作业计划列表并以甘特图直观展示进展状态，未通过的作业计划依据审核意见重新准备填报。（3）作业执行阶段。作业计划在现场条件满足的情况下，施工单位可持工作单到现场开始工作。为了确保现场施工作业计划的有效实施，系统根据计划进展程度区分“已进行”、“已完成”标识，并将计划执行进展情况、问题汇总、所采取措施、资源使用情况及后续建议等总结为工作报告并进行归档，作为后续工作的参考。
1.3冲突检测规则
整个调试过程中因作业申请部门的众多性、调试内容的相关性、各作业的衔接性等，难免会产生作业计划冲突而无法同时进行的情况，主要包括作业计划的先后顺序、共享资源占用、优先级排序等方面的冲突。在计划管理业务流程中通过利用冲突库规则配置增加冲突检测环节，提高作业计划编制的可靠性、安全性和高效性（图1）。计划管理系统在作业计划初始提交时，会自动通过作业时间的同一性进行重合性的初步判断，然后使用包含作业计划的先后顺序、内在衔接关系及资源占用情况等要素在内的冲突检测规则库，进行动车调试和综合调试各方面的冲突检测，设定作业计划的冲突判断条件和指标。当发现作业计划中各要素间的矛盾时，通过对不同检测冲突简单分类、优化和反复修正消除，以达到统筹合理的目标。冲突检测规则根据调试业务进行要素抽取，并逐步随计划复杂度及衔接关系的挖掘不断扩充，实现规则库的可维护配置。
2系统设计构建
2.1软件架构
城市轨道交通动车联调计划管理平台构建于模型视图控制器MVC3层之上，将软件架构分层设计为数据资源层、应用逻辑层、界面逻辑层、用户安全认证、业务功能层及用户展示层等6层（图2）。运用具有操作便捷、数据共享、扩展灵活等优点的基于B/S（浏览器/服务器）模式的Web技术，采用J2EE+Oracle的研发方式，设计JAVA表示层、业务逻辑层和数据持久层等3层，其中表示层用于接收用户请求、返回和展现用户请求的数据结果，而具体的数据处理由业务逻辑层和数据访问层处理；业务逻辑层用来逻辑处理实现业务目标的上下交互数据；数据持久层主要实现与数据库的交互功能。同时，整个系统将组件式设计的通用组件、技术组件和业务组件进行分层部署，以保持用户界面、业务处理和数据操作的分离和逻辑独立。（1）通用组件。通过应用逻辑提供基本功能服务，包括数据库事务、消息引擎、报表引擎、系统日志、文件上传下载及共享信息接入、、管理等服务组件。（2）技术组件。系统构建的技术支撑组件包括J2EEWeb应用框架、Netframework、ArcGIS服务等。（3）业务组件。提供各种业务功能组件，包括计划管理、进度监测、日常安全管理、调试进展分析、报表文件管理、事故管理、通讯录与系统角色管理等组件。
2.2功能模块
基于关键业务分析和方案设计的系统可为整个调试过程中的组织部门、管理部门、作业部门、审核部门，分别实现调试工作任务的派发与调度、冲突检测与计划调配、作业跟踪监控、统计分析、查询处理及配置管理等功能，总体功能模块主要包括办公桌面、计划管理、进度管理、事故管理、统计分析、系统管理等模块。（1）办公桌面。实现城市轨道交通动车调试及综合调试的新闻动态、计划方案、进展状态、工单概要、信息统计、即时通知等功能，能够快速地掌握当前调试进度及重要事件。通过引入通信接口将有关重要信息及时转发给相关施工和管理单位，以提高作业进展的及时性与电子系统办公的效率。（2）计划管理。完成对不同施工单位、系统、专业、类型的施工作业计划管理，实现计划编制、计划审核、冲突检测、计划查询、计划甘特图展示等。主要包括总体计划和分项计划，以及按不同周期制定的年度计划、季度计划、月度计划、周计划、日计划。系统提供关键节点计划版本管理的操作。（3）进度管理。根据基础及真实采集数据，分别生成动调设计和实际进度，通过比对形成相应的进度管理分析结构（提前、正常、滞后），进行计划与实际的甘特图进度展示，并基于线路走向示意图进行多线路进度监测及安全事故预警。（4）事故管理。调试管理单位需掌握作业过程中所发生的事故情况，实现事故基本情况上报、事故关联单位指标考核、事故报告分析等。（5）统计分析。按照不同统计维度，提供不同施工单位、不同专业、不同事件类型的数据统计分析图标，以便进行相关指标的比对，为考核系统厂商提供数据辅助支撑。（6）系统管理。提供用户登录、用户管理、角色管理、系统设置、字典管理、日志查询、系统帮助等操作功能。
2.3物理架构
为了保证业务实现的完整性、可用性和安全性，按系统运行的互联网或局域网的方式提供物理架构设计（图3），设计考虑2种不同的方案。（1）方案1。通过配置服务器、工作站、交换机等，将动车调试计划管理系统以独立生产系统的方式部署在互联网上，便于多个单位快捷操作和信息交互。（2）方案2。计划管理系统部署在局域生产网内，施工单位利用VPDN专用通信通道及无线网络专用通信方式，将电子申报业务上传至局域网内，以共享和传输业务信息。
3系统应用实现
3.1GIS进度总揽
在城市轨道交通线网建设状态监视的应用中，基于城市地理信息（电子地图数据），通过叠加线路动车调试进度可以总揽和动态监视作业进度，在地图上以不同颜色（红、黄、绿）区分不同阶段进度（未调试、调试中、调试完毕）。点击地图上在建线路，可查看当前区段动调各个专业（车辆\信号、供电、机电、通信等）最新的动调进度详情（图4）。
3.2线路动调计划
对应城市轨道交通联合调试的各个区段，能在线路走向的示意图上直观了解动车调试的进展状态和形象化的动车调试各阶段详情。系统以不同的颜色进行标识（红、黄、绿、黑、灰分别代表未调试、调试中、已调完、不具备调试条件、未计划调试线路，已开通区段用线路标准色标识），点击相应的颜色区段可查看详细的计划安排、工作内容、已完成情况等具体的属性信息（图5）。3.3计划编制按照动车调试及综合联调作业内容的不同复杂度，制定不同专业动调计划模板，可实现动调计划录入、管理、查询、生成、审核、导出、模板编辑等功能。这些功能通过提供数据符合性的冲突检测检验，来完成多功能计划管理职责（图6）。3.4进度对比为保证多线路多任务动车调试及综合联调的同步有效进行，需依据实际作业的施工内容及完成情况提取实际工作量，并用甘特图动态展示实际工作量与设计工作量的对比情况。系统对偏差情况按分级分类标准进行报警提示与情况分析，便于后续工作的总体协调与展开，从而为建设管理单位审核和监督施工单位进展情况提供数据分析依据（图7）。
4结束语
关键词：软件测试；黑盒测试；优化；策略；方法改进
中图分类号：TP3115文献标识码：A文章编号：2095-1302(2011)08-0069-03
0 引 言
黑盒测试是目前软件业界采用的主流测试方法，这种方法以业务应用为驱动，通过控制输入及其对业务的预期影响来判断代码实现是否正确。 实践证明，这是一种行之有效的测试方法。
1 黑盒测试常用技术及方法
黑盒测试方法主要运用于单元功能和性能方面的测试。其常用的技术方法有三种。
1.1 边界值分析法
边界值分析的基本思想是使用最小值(min)、略高于最小值(min+)、正常值(nom)、略低于最大值(max-)和最大值(max)处取输入变量值。如果要进一步测试被测对象的健壮性，除了变量的五个边界值外，还要通过采用一个略超过最大值(max+)和一个略小于最小值(min-)的取值来看看超过极值时系统会有什么表现。如果被测对象是多个独立变量的函数，这些变量受物理量的限制，则很适合边界值分析。
1.2 等价类划分法
等价类划分法是依据软件的任务书、需求规格说明或设计文档，把输入数据范围划分为多个区间(即等价类)，在每个等价类中选取有代表性的数据设计测试用例。划分等价类是应用等价类划分的关键，既要划分出所有等价类，也要确保没有划分重复的等价类。等价类划分少了会导致测试不充分，等价类划分重复了会导致设计多余的测试用例。例如，对于if(int_DataA>=100 &&int_DataA
1.3 基于决策表测试法
决策表指以表格方式给出的可能输入条件和程序所的对应输出结果之间的严格的逻辑关系.基于决策表设计出相应的测试用例的测试方法即为基于决策表的测试法。该测试方法在所有功能性测试方法中是最严格的。
2 黑盒测试方法的优化
2.1 数值更改黑盒测试的思路
首先描述一下数值更改的几种设计思路和模式。一般设计员进行数值更改往往使用直接查找工程文件的方法。如查找到需要更改的数值,就直接使用新数值进行更改。多数设计员认为只要没有漏改数值,就不会有问题。但不幸的是,还是会被测试人员发现一些程序中的错误。本文将按照软件工程开发测试流程的八个模块进行分析，提供一些数值更改的思路。针对数值更改的设计思路和模式,相应的测试思路如下:
(1) 首先确定设计更改的需求是否达到目的；
(2) 确认设计更改点所处的功能模块的功能是否满足要求；
(3) 找出该更改点涉及的相关功能和接口；找相关接口要注意查阅相关的设计文档,如接口定义、通信协议、程序结构、芯片资料、设计标准等，设计人员的笔误往往集中在更改点涉及的相关接口；
(4) 确认更改点涉及部分的功能是否能够满足要求；
(5) 按测试要求做好测试记录并最后出具报告。
2.2 随机模拟法在黑盒测试中的应用
该方法的基本思想是为了求解数学、物理、工程技术或生产管理等方面的问题。首先建立一个与求解有关的概率模型或随机过程，使它的参数等于所求问题的解，然后通过对模型或过程的观察或抽样试验来计算所求参数的统计特征，最后给出所求解的近似值。概率统计是随机模拟法的理论基础，其基本手段是随机抽样。对于那些难以进行或条件不满足的试验而言，这无疑是一种极好的替代方法。在应用时，要先产生一种均匀分布的随机数序列，然后再设法转换成特定要求的概率分布的随机数序列，并以此作为数字模拟试验的输入变量序列进行模拟求解。其基本步骤：一是建立概率模型，即对所研究的问题构造一个符合其特点的概率模型；二是产生随机数序列作为系统的抽样输入，进行大量的数字模拟试验，从而得到大量的模拟试验值。产生随机数的数学方法，最常用的有同余法、平方取中法以及易位指令加法等；常用的随机数检验方法有参数检验、均匀性检验、独立性检验、组合规律检验和游程检验等；三是对模拟试验结果进行统计处理(计算频率、均值等特征值)，给出所求问题的解和解的精度估计。设计测试用例要经历划分等价类和选取测试用例两步，首先要进行等价类划分，之后在此基础上通过随机模拟方法随机选取测试用例，这样可以使选取的测试用例组合覆盖程序的全部输入域，因而更具有一般性和代表性。
2.3 基于需求的测试优先化方法
优先化方法一般基于以下四个优先化因子:
(1) 用户指派优先权(CP)是一个需求对于用户的重要性的度量,由用户为每项需求指派范围从1~10的值,值越高，优先权越高；
(2) 需求易变率(RV)表示基于一项需求在开发周期中被修改的次数,是对需求变更的估计；
(3) 执行复杂性(IC)是从开发团队的角度对需求实现难易程度的主观度量。一般按每项需求可接受的实现难易度给出一个1~10之间的值,值越大，所可能包含的缺陷数越多；
(4) 需求缺陷倾向(FP)可帮助开发团队从软件以前多个版本收集的数据发现易出错的需求,并找出实现这些需求的代码。缺陷倾向越大的模块,造成域失效的可能性越大。
优先化因子的收集与更新过程是:先由用户指定系统各项需求的优先权以及开发阶段需求的增加和修改;需求分析者记录需求和相关优先权,并记下需求的任何变动;接着由软件维护工程师修复缺陷,并将故障映射回受其影响的需求;开发者再对各项需求执行的复杂程度给出客观评价;测试者为每项需求编写测试用例,同时将需求映射到其测试用例并运行。最后记录用例失效,并将其映射到引起该失效的测试用例。
2.4 测试用例的分布策略
一般而言,针对一个软件的测试用例集是不可能穷尽的,只能根据各种原则选择部分典型的用例进行测试。特别是对于一些大型软件,最终可能需要数以万计的测试用例来对其进行测试,在测试用例设计之前大量的测试用例该如何进行分布才能达到相对更好的测试效果呢?
(1) 基于矩阵的首次分布策略
理论上，程序规模与测试用例的数量并非线性关系,因为程序规模越大,复杂度就越高,关联因素也越多,所以，对软件来说，这并不是单纯行数的增长。但是在工程中,为了便于实际操作,大多会简单将它们假设为线性关系。
为了把握好测试用例数目的合理分布,可采用矩阵式首次分布预测法进行分布。表1所示是以软件子功能作为矩阵的行,以功能测试的基础测试观点作为矩阵的列给出的矩阵法示意表。表1中的行列元素仅仅是举例说明。
(2) 基于分析结果的再次分布策略
如果是按照上述基于矩阵的首次分布策略单纯地实施完最初设计的测试用例就认为测试结束,那么测试就不能称之为完整的测试。而必须依据第一轮测试发现的bug的分布特征、bug的收敛趋势等分析结果来判断是否需要继续测试。在需要继续增加测试的情况下,可以采用基于分析结果的再次分布策略来确定增加部分测试用例的分布。具体实施方法是:根据功能点和基础测试观点进行bug的分布规律分析,将测试发现的bug数都正确地填写在表1的矩阵中,然后根据数字明确哪些子功能是薄弱点,哪些基础测试观点是bug最多的观点,根据软件测试中的80-20规则(80%的bug集中在20%的程序代码内),对于这些交叉点提高测试用例密度,并进行增加部分的测试用例再次分布。
2.5 基于输入输出关系的综合黑盒测试方法
这是针对黑盒测试存在的问题提出的一种测试用例设计方法。根据系统规格说明和系统输入输出之间的关系等附加信息，来确定输入参数之间的覆盖和约束关系，并对参数输入域进行约减;接着对各组进行处理，对各个组合中的输入变量进行两两组合覆盖，再对各相关组的结果进行水平拼接组合。实践结果表明，该方法在不影响测试检错能力的情况下，可以有效地提高测试用例的选择效果。
利用输入输出关系对测试用例集进行约简和优化时,首先对输入输出关系自身进行约简,然后进行关联性分析,并将其划分成若干个彼此独立的相关组;接着对各相关组分别进行，可仅对每个输出涉及到的输入变量进行组合覆盖,进而利用组内元素的关联性通过公共元素进行水平拼接，最后再把各个相关组的结果进行水平拼接。结果表明，改进后的方法可以产生数量最少的用例集。
利用测试用例集的约简技术和优化,可以大大地缩减测试计划,降低测试成本。利用已知的输入输出关系,通过对输入输出关系自身的特点(包含和关联)进行分析来对输入输出关系进行约简和分组,然后把每个相关组视为独立的输入输出关系分别进行处理，再对每个输出所涉及的输入变量进行组合覆盖,进而利用关联性把这些组合覆盖的测试数据进行水平拼接，最后再把各个相关组的结果进行水平拼接所样产生的结果不仅最接近最优解,而且时间复杂度也指数级下降,从而得到了较大的优化。
3 结 语
为了提高软件测试的质量和效率，本文针对黑盒测试中的软件测试方法进行了分析，并根据实际操作总结出了针对黑盒测试的改进方法。实践证明，通过测试方法的优化，可使软件测试更加系统化、灵活化，其测试效率和质量都会得到明显提升。
参 考 文 献
［1］董晓霞.相邻因素组合测试用例集的最优生成方法\[J\].计算机学报,2007,30(2):200-210.
［2］COOPER Alan,REIMANN Rober.软件观念革命\[M\].北京:电子工业出版社,2005.
［3］周伟明.软件测试实践\[M\].北京:电子工业出版社,2008.
［4］徐异婕.基于模型的有效测试用例设计—工作流系统测试实战\[J\].程序员,2007(4):76-79.
［5］李都.测试顺序选择策略研究\[J\].计算机工程与设计,2008,29(4):781-783.
关键字：软件；测试过程；管理
软件开发过程的质量决定软件的质量，软件测试过程的质量直接影响测试结果的准确性和有效性。
1 软件测试过程常用的模型
1、V模型
V模型反映出测试活动与分析设计活动的关系，指出单元测试和集成测试应检测程序的执行是否满足软件设计的要求。系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标。验收测试确定软件的实现是否满足用户需求或合同的要求。
2、W模型
W模型指出软件各开发阶段中应同步进行的验证和确认活动，即测试与开发也应是同步进行的。W模型有利于尽早和全面的发现问题。
3、H模型
V模型与W模型有不妥，即它们都把软件的开发视为需求、设计和编码等一系列串行的活动，而事实上，这些活动可以交叉进行的。H模型揭示这一点：软件测试是一个独立的流程，贯穿于产品的整个生命周期中，与其他流程并发进行。
除了上面的几种常见模型外，还有X模型、前置测试模型等。在实践中，建议以W模型作为框架，及早全面地开展测试，同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。
2 测试阶段中的测试活动
软件测试过程主要包括以下四项基本活动：
1、测试策划
在测试策划中的活动有：制定测试计划，以确定测试范围、测试策略和测试方法，规划测试任务日程表，对测试资源进行安排，并提前评估测试风险，制定风险控制策略。
2、测试设计与实现
在测试设计与实现中的活动有：制定测试的技术方案，选择测试工具，并根据测试技术方案设计测试用例。
3、测试执行
在测试执行中的活动有：建立相关测试环境、配置测试数据、按日程安排执行测试用例并记录测试执行结果，对发现的软件缺陷进行报告，并配合开发人员进行软件缺陷的分析、处理和追踪。
4、测试总结
在测试总结中的活动有：对测试结果进行综合分析，以确定软件产品质量的当前状态，为产品的改进和提供数据和依据，同时编制测试报告，提交相关的测试文档。
3 软件测试过程管理的特点
软件测试过程管理的基本内容包括计划、组织和监控；测试过程中存在的问题有：
1.软件质量标准定义不准确、任务边界模糊。
2.软件测试项目的变化控制和预警分析要求高。
3.软件测试项目具有智力密集，劳动密集的特点，受人力资源的影响最大。
4.测试任务的分配比较困难。
5.测试要求的人力资源十分稳定。
6.软件测试人员在待遇、地位上可能会受到一些不公平的待遇。
软件测试项目的过程管理能否成功，通常受到三方面的影响：项目组内的环境，项目所处的组织环境，整个开发流程所控制的全局环境。
4 软件测试过程管理的原则
1、有关测试需求，应当有一个经各方同意的、完整的、清楚的、详细的、整体的、可实现的和可测试性的需求并文档化，尽可能坚持最初的需求。
2、测试计划先行。软件项目管理过程从项目的计划活动开始，软件测试项目也不例外，也是从测试计划开始。
3、建立任务优先级。在测试任务较多的情况下，应该为各项任务建立测试优先级，这样也可以根据优先级来先后处理各项任务。
4、建立客观的评估标准。这样使得整个项目过程具有良好的可测性和可跟踪性，强调以数据说话。
5、尽早测试。这是从W模型中抽象出来的理念。一方面指测试人员尽早参与测试项目，另一方面指尽早开展测试执行任务。
6、全面测试。这也是W模型的重要思想，其含义一方面只要对软件所有产品进行全面的测试；另一方面指软件开发人员与测试人员全面参与到测试工作中。
7、全过程测试。这是从W模型中抽象出来的另一理念。其含义一方面指测试人员要充分关注开发过程；另一方面指测试人员要对测试的全过程进行全程的跟踪。
8、独立的、迭代的测试。这是H模型的重要思想，强调只要达到测试就绪点，即测试条件成熟，测试准备活动完成，测试执行活动就可以开展。
5 软件测试过程的人员组织
测试团队的组织直接关系到测试团队的工作效率和生产力，其组织方式由测试团队的规模、具体任务和技术来决定。
一个测试团队的基本角色有：测试经理、实验室管理人员、内审员、测试组长、测试设计人员、资深测试工程师、一般测试工程师。
若测试团队规模较大，则测试工程师分为三个层次：初级测试工程师、测试工程师和资深测试工程师，同时设置自动化测试工程师、系统测试工程师和架构工程师。
测试过程人员组织的一个方面是考虑测试团队的规模，测试团队的规模可以考虑在整个开发部门所占的比重，或相对开发人员所占的比例。从经验看，不同的应用，软件测试和软件开发人员的比例也是不同的，大致可分为三类。
1、操作系统类型的产品，对测试要求最高，测试人员和开发人员的比例为2：1。
2、应用平台、支持系统类型的产品，对测试要求比较高，通常测试人员和开发人员的比例为1：1。
3、对于特定应用系统一类产品，由于以后对象清楚、范围小，甚至可对应用平台或应用环境加以限制，所以测试人员可以再减少，但测试人员和开发人员的比例至少保证在1：2的水平以上。
6 结束语
相比之下，目前中国软件企业在软件测试方面与国际水准仍存在较大差距。首先，在认识上重开发、轻测试，没有认识到软件项目的如期完成不仅取决于开发人员，更取决于测试人员；其次，在管理上随意、简单，没有建立有效、规范的软件测试管理体系；另外，缺少自动化工具的支持，大多数企业在软件测试时并没有采用软件测试管理系统。所以对国内软件企业来说，不仅要提高对软件测试过程管理的认识，同时要建立起完善的软件测试过程管理体系，确保软件测试管理在软件质量保证中发挥应有的关键作用。
参考文献
[1]朱少民. 软件测试方法和技术 [M].北京：清华大学出版社， 2005年
[2]郑文强，马均长. 软件测试管理[M].北京：电子工业出版社， 2010年
[3]布莱克（美）.软件测试过车管理[M].北京：机械工业出版社，2003年
