软件集成技术总结

第一篇：软件集成技术总结

软件集成技术总结 软件集成系统

主要功能是实现各种应用软件在本系统中的集成及调用，由于需要集成软件的开发软件，运行环境各有不同，所以在系统集成时调用的相关技术也不尽相同。本系统软件的集成主要应用了一下三种技术：Java Applet技术，Exe软件的调用方法，Matlab软件的调用方法。相关技术 2.1 Java Applet技术

Applet可以翻译为小应用程序，Java Applet就是用Java语言编写的这样的一些小应用程序，它们可以直接嵌入到网页或者其他特定的容器中，并能够产生特殊的效果。

Applet必须运行于某个特定的“容器”，这个容器可以是浏览器本身，也可以是通过各种插件，或者包括支持Applet的移动设备在内的其他各种程序来运行。与一般的Java应用程序不同，Applet不是通过main方法来运行的。在运行时Applet通常会与用户进行互动，显示动态的画面，并且还会遵循严格的安全检查，阻止潜在的不安全因素（例如根据安全策略，限Applet对客户端文件系统的访问）。

在Java Applet中，可以实现图形绘制，字体和颜色控制，动画和声音的插入，人机交互及网络交流等功能。Applet还提供了名为抽象窗口工具箱（Abstract Window Toolkit，AWT）的窗口环境开发工具。AWT利用用户计算机的GUI元素，可以建立标准的图形用户界面，如窗口、按钮、滚动条等等。目前，在网络上有非常多的Applet范例来生动地展现这些功能，读者可以去调阅相应的网页以观看它们的效果。

在Java Applet的生命周期中，共有四种状态（初始态、运行态、停止态和消亡态）和四个方法：init()、start()、stop()和destroy()。a init()当创建Java Applet且第一次使用支持Java的浏览器载入时，就会执行init()方法。在Java Applet生命周期中，该方法只执行一次，因此可以利用这一点在init()方法中进行一些只需执行一次的初始化操作，例如对变量的初始化等。b start()调用完init()方法后，系统将自动调用start()方法。当用户离开包含Applet的主页后又再返回时，或者当浏览器从图标状态恢复为窗口时，系统都会自动再执行一遍start()方法。

和init()方法不同，start()方法在Applet的生命周期中被多次调用，该方法是Applet的主体。在start()方法中，可以执行一些任务，或者是启动相关的线程来执行任务，如循环播放歌曲等。c stop()和star()方法相对应，当用户离开Applet所在页面或者是浏览器变成图标时，系统都会调用stop()方法，因此该方法也是可以被多次调用的。

stop()方法起到这样的作用：当用户在当前时刻并不十分关注Applet时，停止一些耗用资源的工作，这样就可以提高系统的运行速度，而且系统会自动调用该方法，并不需要人为干预。倘若编写的Applet中不涉及动画等多媒体，一般不必重写该方法。51Testing软件测试网 d destroy()当用户关闭浏览器时，系统就会调用destroy()方法，应该注意stop()方法和destroy()方法的区别。

本系统中的Applet小程序调用流程：运行时，首先从服务器下载应用程序的ZIP压缩文件到本地，然后解压到本地，并在在本地运行，在Applet关闭时，停止exe运行，并删除已下载的ZIP文件和解压后的文件夹。

2.2 EXE软件的调用方法

使用Runtime.getRuntime().exec()方法可以在java程序里运行外部程序。

该方法有6个可访问版本：

1.exec(String

command)

2.exec(String

command，String

envp[]，File

dir)

3.exec(String

cmd，String

envp[])

4.exec(String

cmdarray[])

5.exec(String

cmdarray[]，String

envp[])

6.exec(String

cmdarray[]，String

envp[]，File

dir)

一般的应用程序可以直接使用第一版本,当有环境变量传递的时候使用后面的版本。

其中2和6版本可以传递一个目录,标识当前目录,因为有些程序是使用相对目录的,所以就要使用这个版本.当要执行批处理的时候,不能直接传递批处理的文件名,而要使用：

cmd.exe

/C

start

批处理文件名

使用dos命令(比如dir)时也要使用掉调用。

如果想与调用的程序进行交互,那么就要使用该方法的返回对象Process了,通过Process的getInputStream(),getOutputStream(),getErrorStream()方法可以得到输入输出流,然后通过InputStream可以得到程序对控制台的输出信息,通过OutputStream可以给程序输入指令,这样就达到了程序的交换功能。

使用Runtime类．

try {

Runtime rt = Runtime.getRuntime();

rt.exec(“C:WINDOWSNOTEPAD.exe”);

} catch(Throwable t){ System.out.print(t.getMessage());

} 2.3 Matlab软件的调用方法

Matlab软件的调用分为三个步骤：一是在java里面调用matlab，matlab2006b以后的版本中都提供了java 调用matlab的接口matlab build for java；二是将调用matlab程序的java程序转换为exe程序；三是按照2.1所述的方法调用Matlab的exe程序。

关键技术是java调用matlab程序的方法，下面是一个相关的例子：(一)在MATLAB中编辑operation.m, %定义一个函数operation(a,b),求a与b的加减乘除运算，并返回结果

%函数定义function 输出变量列表[s,m,...] 函数名（输入变量列表）sum,sub,mul,div中

function [sum,sub,mul,div] = operation(a,b);sum = a + b;sub = a-b;mul = a * b;div = a / b;end(二)生成Java调用文件

Matlab命令中输入deploytool,新建一个matlab builder ja文件，在operationclass中添加operation.m文件，点击bulid the project,生成一个供java调用的文件夹结构如下：

Operation-----|----distrib |

|-----operation.jar |

|-----readme.txt

|

-------src

|

|----operation

|

|----operationclass.java

|

|----operationMCRFactory.java

|----operationclassRemote.java

|

|----classes

|

|----operation

|

|----operation.ctf

|

|----operationclass$1.class

|----operationclass.class

|----operationclassRemote.class

|----operationMCRFactory.class |-------build.log |-------operation.ctf |-------operation.jar |-------mccExcludedFiles.log |-------readme.txt(三)Java中建立一个java project工程JavaTestMatlab，导入两个库文件javabuilder.jar（C:ProgramFilestoolboxjavabuilderjar）和operation.jar(D:My DocumentsMATLABoperationdistrib operation.jar)，编写java程序JavaTestMatlab.java程序如下： import operation.*;import java.util.Scanner;class JavaTestMatlab {

public static void main(String[] args)

{

Object result[] = null;

/* object是所有类的父类public Object[] operation(int nargout, Object...rhs)*/

operationclass myAdd = null;

/* Stores myadd class instance */

try

{

int a,b;

myAdd = new operationclass();

System.out.println(“从键盘输入两个操作数：”);

System.out.print(“

输入第一个操作数：”);

Scanner scan = new Scanner(System.in);

//从控制台读入输入的整数

a = scan.nextInt();

//从控制台输入第一个操作数

System.out.print(“

输入第二个操作数: ”);

b = scan.nextInt();

//从控制台输入第二个操作数

result = myAdd.operation(4,a,b);//operation(4,a,b)中第一个参数是返回值的个数，a是第一个输入参数,b是第二个输入参数

System.out.print(“The sum of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[0]);

System.out.print(“The sub of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[1]);

System.out.print(“The mul of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[2]);

System.out.print(“The div of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[3]);

}

catch(Exception e)

{

System.out.println(e);

}

} } 测试结果如下：

从键盘输入两个操作数：

输入第一个操作数：55

输入第二个操作数: 22 The sum of 55 and 22 is: 77 The sub of 55 and 22 is: 33 The mul of 55 and 22 is: 1210 The div of 55 and 22 is: 3(四)错误调试

1.安装matlab不完整，没有toolboxjavabuilder下的文件 2.环境变量中classpath中添加两个jar文件的路径 已经集成的软件

ORDEM2000 空间碎片评估系统（DAS2.0）增阻型离轨气动分析及优化软件 索型离轨技术模拟软件TetherSim 卫星寿命计算软件 再入安全评估软件

GEO卫星离轨燃料估算软件

第二篇：CADCAE软件集成心得

CAD/CAE软件集成心得

经过一个月的努力，现在已经熟练掌握了Proe、ABAQUS、ADAMS、ANSYS（APDL）和ANSYSWorkbench封装方法。从不熟悉ABAQUS和ADAMS的操作到基本熟悉它们的分析流程和软件的主要文件（哪些是输入文件，哪些是结果文件？），从不了解CAE软件的脚本语言到上网查资料知道了如何将GUI操作录制成脚本。经历了不知道自己的想法是否能行的通到知道自己的想法肯定能实现但是不知道怎么去做，再到实现自己的想法。而等我把它在电脑上运行成功后的那一刻，带给我的兴奋是不言而喻的，哈哈，买瓶啤酒庆祝庆祝。但是更多的时间在查资料，不断思考，不断修改参数，狂点鼠标，现在右手指还有些痛。当回过头来总结的时候，觉得这个过程是多么的值得。

也许有人会问，关于这些CAD/CAE软件的封装在多学科优化软件中不是已经有相关实例了吗？没错，在ModelCenter中确实有这方面的实例，我也拿它的实例练习了，但是实例中提供的封装步骤并不能满足目前工程师的需要。随着现在大型商业软件的专业化，大多企业选择CAD软件（UG、Proe、Solidworks等）来建模，然后导入CAE软件（ANSYS、ABAQUS、NASTRAN等）来分析，最后利用优化软件（Isight、ModelCenter、Optimus等）将CAD和CAE软件集成，对现有设计方案进行优化。软件自带实例中提供的封装方法可优化的几何参数非常有限，而ModelCenter实例中所用的输入文件是一个有限元文件，包含了节点和单元的信息，许多几何参数无法从输入文件中提取，除非在CAE软件中参数化建模，当模型复杂时，在CAE中建模是非常的麻烦。我们知道实际工程结构的几何模型往往比较复杂，所以只能走CAD/CAE集成这条路。先集成CAD软件，把几何模型作为输出变量，然后利用编写的脚本语言作为输入文件集成CAE软件，当几何参数改变时，CAE软件会重新导入更新后的几何模型。采用这个办法就可以改变几何模型中的任意几何参数。以下就来介绍在CAD/CAE封装集成过程中我认为的关键中的关键：

1、克服对陌生事物的恐惧感。或许你跟我一样只是以前听说我这个软件，没关系，就算专业的CAE工程师也不可能熟悉所有的CAE软件。先找个相应软件的实例跟着操作一遍，大致熟悉分析的流程，如何导入几何模型，如何划分网格，如何添加边界条件以及保存文件。就像初次碰到陌生人一样，每个人都会紧张，但是见面次数多了，聊的多了不就成熟人了嘛。

2、编写脚本语言文件作为输入文件。CAE软件的操作有GUI（图形用户界面）和命令行两种方式，我们封装CAE软件一般采用命令流文件，但我们大多用户对GUI比较熟悉而对命令流比较陌生。没关系！我们每一步的GUI操作，软件都会帮我们记录相应的脚本，在此脚本文件的基础上做适当修改就可以当做输入文件了，例如，定义输入变量，将关心的输出变量值写入结果文件，具体过程参考所要集成软件的封装教程。

3、批处理命令。批处理命令即软件封装时需要输入的Run Command，起到调用软件、执行命令的目的。每个软件都有自己的脚本语言，所以每个软件的批处理命令都不尽相同，把它改成自己需要的。

4、多一次尝试，也许兴奋就在下一刻来临。每当软件封装测试失败时总会感到沮丧，没关系，把自己编写的脚本一行一行的在软件的Command Window中运行，检查自己的脚本文件是否有错误。还需要注意的细节，封装CAD软件时有重写入一项勾上或者将几何模型IGS格式作为CAD的输出变量，再把它当做CAE的读入文件，要不然几何参数再怎么变化，输出变量也是毫无变化。

第三篇：CAD技术集成

什么是CAD？

CAD即计算机辅助设计（Computer Aided Design），是一种技术，其中人与计算机结合为一个问题求解组，紧密配合，发挥各自所长，从而使其工作优于每一方，并为应用多学科方法的综合性协作提供了可能。CAD是工程技术人员以计算机为工具，对产品和工程进行设计、绘图、分析和编写技术文档等设计活动的总称。

根据模型的不同，CAD系统一般分为二维CAD和三维CAD系统。二维CAD系统一般将产品和工程设计图纸看成是“点、线、圆、弧、文本、…”等几何元素的集合，系统内表达的任何设计都变成了几何图形，所依赖的数学模型是几何模型，系统记录了这些图素的几何特征。二维CAD系统一般由图形的输入与编辑、硬件接口、数据接口和二次开发工具等几部分组成。

三维CAD系统的核心是产品的三维模型。三维模型是在计算机中将产品的实际形状表示成为三维的模型，模型中包括了产品几何结构的有关点、线、面、体的各种信息。计算机三维模型的描述经历了从线框模型、表面模型到实体模型的发展，所表达的几何体信息越来越完整和准确，能解决“设计”的范围越广。由于三维CAD系统的模型包含了更多的实际结构特征，使用户在采用三维CAD造型工具进行产品结构设计时，越能反映实际产品的构造或加工制造过程。

什么是CAPP？

CAPP（Computer Aided Process Planning）是利用计算机辅助工艺人员设计零件从毛坯到成品的制造方法，是将企业产品设计数据转换为产品制造数据的一种技术。

什么是CAE？

CAE（Computer Aided Engineering）是用计算机辅助求解复杂工程和产品结构强度、刚度、屈曲稳定性、动力响应、热传导、三维多体接触、弹塑性等力学性能的分析计算机以及结构性能的优化设计等问题的一种近似数值分析方法。

什么是CAM？

CAM(computer Aided Manufacturing)利用计算机来进行生产设备管理控制和操作的过程。它输入信息是零件的工艺路线和工序内容，输出信息是刀具加工时的运动轨迹(刀位文件)和数控程序。

CAD/CAE/CAPP/CAM集成的关键技术是什么？

CAD/CAE/CAPP/CAM集成的关键是CAD、CAE、CAPP和CAM之间的数据交换与共享。CAE/CAPP/CAM系统是制造业信息化的核心技术，主要支持和实现产品设计、分析、工艺规划、数控加工及质量检验等工程活动的自动化处理。CAD/CAE/CAPP/CAM的集成，要求产品设计与制造紧密结合，其目的是保证产品设计、工艺分析、加工模拟，直至产品制造过程中的数据具有一致性，能够直接在计算机间传递，从而克服由图纸、语言、编码造成的信息传递的局限性，减少信息传递误差和编辑出错的可能性。

由于CAD、CAE、CAPP和CAM系统是独立发展起来的，并且各自处理的着重点不同，所以它们的数据模型彼此不相容。CAD系统采用面向拓扑学和几何学的数学模型，主要用于完整地描述零件几何信息，但对于非几何信息，如精度、公差、表面粗糙度和热处理等，则没有在计算机内部逻辑结构中得到充分表达。而CAD/CAE/CAPP/CAM的集成，除了要求几何信息外，更重要的是需要面向加工过程的非几何信息，从而在CAD、CAE、CAPP和CAM之间出现了信息中断。建立CAPP和CAM子系统时，既需要从CAD子系统中提取几何信息，还需要补充输入上述非几何信息，其中包括输入大量加工特征信息，因此，人为干预量大，数据大量重复，无法实现CAD/CAE/CAPP/CAM的完全集成。

目前，采用的关键技术主要有以下几方面：

（1）特征技术。建立CAD/CAE/CAPP/CAM范围内相对统一的、基于特征的产品定义模型，并以此模型为基础，运用产品数据交换技术，实现CAD、CAE、CAPP和CAM间的数据交换与共享。该模型不仅要求能支持设计与制造各阶段所需的产品定义信息（几何信息、拓扑信息、工艺和加工信息），而且还应该提供符合人们思维方式的高层次工程描述语义特征，并能表达工程师的设计与制造意图。

（2）集成数据管理。已有的CAD/CAM系统集成，主要通过文件来实现CAD与CAM之间的数据交换，不同子系统文件之间要通过数据接口转换，传输效率不高。为了提高数据传输效率和系统的集成化程度，保证各系统之间数据的一致性、可靠性和数据共享，需要采用工程数据库管理系统来管理集成数据，使各系统之间直接进行信息交换，真正实现CAD/CAM之间信息交换与共享。

（3）产品数据交换标准。为了提高数据交换的速度，保证数据传输完整、可靠和有效，必须采用通用的标准化数据交换标准。产品数据交换标准是CAD/CAE/CAPP/CAM集成的重要基础。

（4）集成框架（或集成平台）。数据的共享和传送通过网络和数据库实现，需要解决异构网络和不同格式数据的数据交换问题，以使多用户并行工作共享数据。集成框架对实现并行工程协同工作是至关重要的

第四篇：软件测试技术面试总结

软件测试就是为了发现程序中的错误而分析和执行程序的过程。——概念

+基本知识+软件开发过程-定义-计划-实现-稳定化-部署

+软件开发模型(四种典型的模型)

+瀑布模型

-概述：包括计划，需求分析，设计，编码，测试，运行维护六个阶段。六个阶段自上而下、相互衔接，以固定的次序进行。

-特点：1.阶段的顺序性和依赖性；2.文档驱动； 3.推迟实现的观点；4.质量保证。-缺点：不适合需求模糊的系统

+原型模型-概述：先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。

-特点：1.快速开发工具；2.循环； 3.低成本。

-分类：按照对原型的处理方式，可以分为渐进型和抛弃型。

+增量模型

-概述：在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。

-同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。+螺旋模型

-概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。

-特点：1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；

2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。

-软件测试从需求开始：现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：了解软件需求，编写测试计划，搭建测试环境。

-测试用例

-三要素：前提条件和操作步骤、预期结果、实际结果。

-必须以需求为依据。

-软件测试分类

-是否关注软件结构和算法

-黑盒测试：基于软件需求的测试方法。

-白盒测试：基于软件内部设计和程序实现的测试方法。

-是否执行被测试软件

-动态测试：在测试过程中执行被测试软件的测试方法。

-静态测试：------------不----------------------。

-基于不同的测试阶段：

-单元测试：主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由 开发人员完成。

-集成测试：将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是

客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由 开发人员承担。

-系统测试：测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。一般由

独立的测试

人员完成，通常采用黑盒测试方法。

-验收测试：(α、β)与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。

-回归测试：指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。

-软件测试的三个步骤：

-测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。

-测试设计和开发：软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动 程序的开发。

-执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。

-测试工程师的能力要求：

+5C

-Controlled /kEn'trEuld/ 接受管理，有条理的-Competent /'kCmpitEnt/了解正确的测试技术

-Critical /'kritikEl/专注于发现问题

-Comprehensive /.kCmpri'hensiv/ 注意细节

-Considerate /kEn'sidErit/能够和开发人员很好的交谈

+职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累 +制定测试计划的五个步骤：-分析和测试软件需求-定义测试策略

-定义测试环境

-定义测试管理

-编写和审核测试计划

如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。——越早测试越好-在需求分析过程中测试人员需要进行如下工作：

1)理解需求，参与审核需求文档；

2)理解项目的目标、限制，了解用户的应用背景；

3)编写测试计划；

4)准备测试资源。

+需求测试

-需求测试测试的对象是主意而不是代码，针对文档进行测试。

+好的需求文档的特征-具有清晰的格式和文档结构-需求的内容正确-需求的内容完整-需求具有可行性需求的必要性

-对不同的需求优先等级进行定义-描述明确-可证性和可测试性-可修改性-可追踪-需求文档被及时更新

+需求测试内容

-需求文档是否符合公司的格式要求

-是否正确

-要保证需求文档中所描述的内容是真实可靠的-这是“真正的”需求吗？描述的产品是否是要开发的产品？

-需求是否完备？第一个发布的版本是否需要更多的功能？列出的需求可以减少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可实现？如：需求设想的设备是否比实际运行的要快？需求要求的内存、I/0设备是否太多？

需求的输入或输出设备要求的分辨率是否要求过高？

-需求是否合理？在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。

-需求是否可测？对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。+需求测试方法-复查review-走查walkthrough-审查inspection

+测试策略的内容

-确定测试范围 软件是无法被完全测试的-确定测试方法 不同的系统需要不同的测试方法

-定义测试标准 入口标准，暂停和继续的标准，出口标准等

+软件测试结束的标准

-基于测试用例的使用规则

1)构造测试用例（由相关人员进行评审）

2)执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。

3)当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。

-基于“测试期缺陷密度”规则

--------------含义：对软件测试一个CPU小时发现的缺陷数，比较适用于系统测试-基于“运行期缺陷密度”规则

--------------含义：把软件运行一个CPU小时发现的缺陷数，比较适用于验收测试注：一个阶段的出口标准!=下一个阶段的入口标准

系统测试结束的标准!=软件的发布标准

发布标准!=软件0缺陷

-选择测试工具 是否需要，需要什么工具，怎么获取

-降低软件测试代价是企业普遍关注的问题，可通过

a.减少冗余和无价值的测试；

b.减少测试阶段(万般无奈下)

+测试环境

-基本内容：设备环境、软件环境、数据环境

-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备

-搭建测试环境时的配置原则：-使用的频度或范围-实效的可能性-最大限度的模拟真实环境 +测试管理 由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理

-选择缺陷管理工具和测试管理工具

-定义工作进度

-建立风险管理计划

+可能遇到的风险

·由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加

·开始测试时所需的硬件、软件没有准备好

·未能完成对测试人员的技术培训

·测试时的人力资源安排不足

·测试过程中，发生了大量的需求变更

·测试过程中，项目的开发计划被大幅度调整

·不能及时准备好测试所需的环境

·不能及时准备好测试数据

+风险管理的过程

·识别风险

·评估风险

·制定对策

·跟踪风险

+测试设计与开发

+总体设计

-投入产出：测试设计的输入是测试计划，输出是评审过的测试用例集合-定义设计目标遵循的原则

-清楚地说明没项测试的目标

-使每项测试的目标单一，可以对应到规格说明书中的一项需求

-只说明测试应该完成什么工作，而不说明如何完成-流程：总体设计-开发测试用例-评审测试用例

I.定义设计目标

II.定义输入说明

III.定义测试环境和配置

IV.测试设计文档

V.开发测试用例

+测试用例

-概念：为特定目标开发的测试输入、执行条件和预期结果的集合。

+好的测试用例：

-容易发现软件的错误

-精确的重复某测试失败的情景，可重复性

-清晰的定义一个或多个期望的结果

-没有冗余

+测试用例的作用

-指导测试的实施

-作为编写测试脚本的“设计规格说明书”

-评估测试标准的度量基准

-分析缺陷的标准

+白盒测试用例设计

+设计方法

+逻辑覆盖法

-语句覆盖

-判定覆盖

-条件覆盖

-判定-条件覆盖

-条件组合覆盖

-路经覆盖

-基本路经法

+辅助模块设计

-驱动模块：相当于被测程序的主程序。接受测试数据，把这些数据传给被测模块然后输出实际测试结果。

-桩模块：用于调用被测模块调用的子模块。可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。

+黑盒测试用例设计

-等价类划分法

-边界值法——“缺陷遗漏在角落里，聚集在边界上。”

-因果图法弥补等价类和边界值法的不足

-错误推测法

-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现，以保证测试是可重复的。+常见错误分析

-用户界面问题

·输入无合法性检查和值域检查。

·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。

·表达不清或过于模糊的信息提示。

·要求用户输入多余的本来系统可以自己得到的数据。

·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。·不经用户确认就对系统或数据进行了重大修改。

-形象类问题

·不符合用户的操作习惯。如，快捷键定义不科学不实用，甚至无快捷键。

·不够专业，缺乏基本知识。

·界面中英文混杂，甚至拼写错误。

·说明书或帮助的排版格式不专业：中英文不对应，标点的半全角问题，没有排版准则。·界面元素参差不齐，文字不能完全显示。

－稳定性问题

·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。

·主系统和子系统使用了相同的临界资源而相互不知道。如：使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。

·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况(网络中断、内存申请

不成功、长时间无响应等)有关。

-其他问题

·运行时不检查内存、硬盘空间、数据库等。

·无根据的假设用户环境：硬件/网络情况；有些动态库；假设网络随时都是联通的。·提供的版本带病毒。

·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。

·用户现场开放和修改，又没有记录和保留。

·版本中部分内容或接口倒退，或出现版本管理混乱。

·有些选项永远都是灰的，或有些在该变灰时没变灰。

+测试用例的评审

-测试或测试组件完全针对的是需求中列出的功能吗？

-测试组件是否覆盖了所有的需求？

-有冗余的吗？

-每个测试步骤都有清楚描述的预期结果吗？

+优先级

+3级

优先级1：此测试用例必须执行-2：有时间就执行-3：可以不执行

+5级

1：此测试必须通过，否则产品发布存在危险2：在发布前必须执行3：时间允许就执行4：此测试可以在下一次发布或发布后短期内执行5：可以不测试

第五篇：软件测试技术总结

IT公司面试手册提供最全的IT类面试题, 包括

Java：Java面试题 J2EE面试题 Hibernate面试题 Spring面试题Struts面试题EJB面试题.NET:.net面试题 ASP.NET面试题 C#面试题

数据库：数据库面试题Oracle面试题 SQL Server面试题 MySql面试题

网络：网络技术面试题 网络安全面试题

Web开发：PHP面试题 Web开发面试题

Linux Unix：Unix面试题Linux面试题

软件测试： 软件测试面试题

其他类： 英语面试 外企面试 Python面试题 程序员面试

更多面试题请访问： http://

软件测试技术总结

软件测试就是为了发现程序中的错误而分析和执行程序的过程。——概念

+基本知识+软件开发过程-定义-计划-实现-稳定化-部署

一、软件开发模型(四种典型的模型)

1、瀑布模型

概述：包括计划，需求分析，设计，编码，测试，运行维护六个阶段。六个阶段自上而下、相互衔接，以固定的次序进行。

特点：1.阶段的顺序性和依赖性；2.文档驱动；3.推迟实现的观点； 4.质量保证。

缺点：不适合需求模糊的系统

2、原型模型

概述：先建立一个能够反映用户需求的原型系统，使得用户和开发者可以对目标系统的概貌进行评价和判断，然后对原型系统进行反复的扩充、改进、求精，最终建立符合用户需求的目标系统。

特点：1.快速开发工具；2.循环； 3.低成本。

分类：按照对原型的处理方式，可以分为渐进型和抛弃型。

3、增量模型

概述：在增量模型中每个阶段都生成软件的一个可发布版本，阶段交错进行，版本逐渐完善。同原型模型的最大区别在于，在原型模型中每个阶段发布一个原型而在增量模型中则完成一个正式版本。

4、螺旋模型

概述：适用于大型软件的开发，它将瀑布模型和快速原型模型结合起来，并加入了风险分析。特点：1.每个阶段都包括制定计划，风险分析，实施工程，评审四个阶段；2.开发过程迭代进行，每迭代一次螺旋线增一周，工程前进一个层次，系统生成一个新版本，投入新的时间成本，最终得到客户满意的版本。-软件测试从需求开始：现代的软件测试将测试渗入到软件开发的各个阶段，即使瀑布模型，表面看测试工作是在测试阶段开始的，事实上，在计划、需求、设计阶段，测试人员便已经开始了他们的工作，如：了解软件需求，编写测试计划，搭建测试环境。

二、测试用例

1、三要素：前提条件和操作步骤、预期结果、实际结果。

2、必须以需求为依据。

三、软件测试分类

1、是否关注软件结构和算法

-黑盒测试：基于软件需求的测试方法。-白盒测试：基于软件内部设计和程序实现的测试方法。

2、是否执行被测试软件

-动态测试：在测试过程中执行被测试软件的测试方法。-静态测试：------------不----------------------。

3、基于不同的测试阶段：

1、单元测试：主要测试软件的单元模块，需要编写额外的测试驱动程序，采用白盒测试的方法，一般由 开发人员完成。

2、集成测试：将一些“构件”集成在一起时测试他们是否能正常运行，构件可以是程序模块，也可以是客户机-服务器程序等，需要编写测试仿真程序，采用白盒和黑盒相结合的方式，通常由 开发人员承担。

3、系统测试：测试软件系统是否符合所有的需求，包括功能性测试和非功能性测试。一般由独立的测试人员完成，通常采用黑盒测试方法。

4、验收测试：(α、β)与系统测试类似，但由客户或最终用户执行，测试软件是否符合需求规格说明书。

5、回归测试：指在软件开发过程中，每次错误被修正后或软件的功能、环境发生变化后进行的测试。

四、软件测试的三个步骤：

1、测试计划：测试人员首先对需求进行分析，最终定义一个测试集合，通过刻画和定义测试发现需求中的问题，然后根据软件需求同测试主管制定并确认“测试计划”。

2、测试设计和开发：软件测试人员根据软件需求和软件设计说明书完成测试用例的设计和必要的测试驱动程序的开发。

3、执行测试：需要做的工作包括搭建测试环境、运行测试、记录测试结果、报告软件缺陷、跟踪软件缺陷、分析测试结果，必要时进行回归测试。

五、测试工程师的能力要求：

1、5C

-Controlled /kEn'trEuld/ 接受管理，有条理的-Competent /'kCmpitEnt/了解正确的测试技术

-Critical /'kritikEl/专注于发现问题

-Comprehensive /.kCmpri'hensiv/ 注意细节

-Considerate /kEn'sidErit/能够和开发人员很好的交谈

2、职业素质-责任心-学习能力-怀疑精神-沟通能力-专注力-洞察力-团队精神-注重积累

六、制定测试计划的五个步骤：

1、分析和测试软件需求

2、定义测试策略

3、定义测试环境

4、定义测试管理

5、编写和审核测试计划

如果在需求分析阶段发现并结果问题需要花费$1，则在设计阶段解决同样的问题需花费$5，在编码阶段需$10，交付后解决同样的问题需花费$200。——越早测试越好

七、在需求分析过程中测试人员需要进行如下工作：

1)理解需求，参与审核需求文档；2)理解项目的目标、限制，了解用户的应用背景；

3)编写测试计划；4)准备测试资源。

八、需求测试

-需求测试测试的对象是主意而不是代码，针对文档进行测试。

九、好的需求文档的特征

1、具有清晰的格式和文档结构

2、需求的内容正确

3、需求的内容完整

4、需求具有可行性需求的必要性

5、对不同的需求优先等级进行定义

6、描述明确

7、可证性和可测试性

8、可修改性-可追踪

9、需求文档被及时更新

十、需求测试内容

1、需求文档是否符合公司的格式要求

2、是否正确

3、要保证需求文档中所描述的内容是真实可靠的4、这是“真正的”需求吗？描述的产品是否是要开发的产品？

5、需求是否完备？第一个发布的版本是否需要更多的功能？列出的需求可以减少一部分？

6、需求是否兼容？需求有可能是矛盾的。

7、需求是否可实现？如：需求设想的设备是否比实际运行的要快？需求要求的内存、I/0设备是否太多？需求的输入或输出设备要求的分辨率是否要求过高？

8、需求是否合理？在开发进度、开发费用、产品性能、可靠性和内存使用之间存在着平衡关系。

9、需求是否可测？对于软件测试人员来说判断需求是否可测是这个过程中最重要的工作。

十一、需求测试方法

1、复查review2、走查walkthrough3、审查inspection

十二、测试策略的内容

1、确定测试范围 软件是无法被完全测试的2、确定测试方法 不同的系统需要不同的测试方法

3、定义测试标准 入口标准，暂停和继续的标准，出口标准等

十三、软件测试结束的标准

-基于测试用例的使用规则

1)构造测试用例（由相关人员进行评审）

2)执行测试用例中，当测试用例的不通过率达到20%则拒绝继续测试，待开发人员修正软件后再继续。

3)当功能性测试用例通过率达到100%，非功能性测试用例通过率达到90%时，允许正常结束。

-基于“测试期缺陷密度”规则---------含义：对软件测试一个CPU小时发现的缺陷数，比较适用于系统测试-基于“运行期缺陷密度”规则---------含义：把软件运行一个CPU小时发现的缺陷数，比较适用于验收测试注：一个阶段的出口标准!=下一个阶段的入口标准

系统测试结束的标准!=软件的发布标准发布标准!=软件0缺陷

-选择测试工具 是否需要，需要什么工具，怎么获取

-降低软件测试代价是企业普遍关注的问题，可通过

a.减少冗余和无价值的测试；b.减少测试阶段(万般无奈下)

十四、测试环境

-基本内容：设备环境、软件环境、数据环境

-需考虑的因素-计算机平台-操作系统-浏览器-软件支持平台-外围设备-网络环境-其他专用设备-搭建测试环境时的配置原则：-使用的频度或范围-实效的可能性-最大限度的模拟真实环境

十五、测试管理

由于测试工程中设计的人员、活动、工具是很多的，在制定测试计划时需要对这些因素进行管理-选择缺陷管理工具和测试管理工具-定义工作进度

-建立风险管理计划

(1)可能遇到的风险

1.由于设计、编码阶段出现大量质量问题，导致测试工作量时间增加

2.开始测试时所需的硬件、软件没有准备好3.未能完成对测试人员的技术培训

4.测试时的人力资源安排不足5.测试过程中，发生了大量的需求变更

6.测试过程中，项目的开发计划被大幅度调整7.不能及时准备好测试所需的环境

8.不能及时准备好测试数据

(2)风险管理的过程

1.识别风险2.评估风险3.制定对策4.跟踪风险

+测试设计与开发

+总体设计

-投入产出：测试设计的输入是测试计划，输出是评审过的测试用例集合-定义设计目标遵循的原则

(-清楚地说明没项测试的目标-使每项测试的目标单一，可以对应到规格说明书中的一项需求-只说明测试应该完成什么工作，而不说明如何完成)

-流程：总体设计-开发测试用例-评审测试用例

I.定义设计目标II.定义输入说明III.定义测试环境和配置

IV.测试设计文档V.开发测试用例

+测试用例——概念：为特定目标开发的测试输入、执行条件和预期结果的集合。

+好的测试用例：

1.容易发现软件的错误2.精确的重复某测试失败的情景，可重复性

3.清晰的定义一个或多个期望的结果4.没有冗余

+测试用例的作用

-指导测试的实施-作为编写测试脚本的“设计规格说明书”-评估测试标准的度量基准-分析缺陷的标准 +白盒测试用例设计

+设计方法

+逻辑覆盖法

(-语句覆盖-判定覆盖-条件覆盖-判定-条件覆盖-条件组合覆盖-路经覆盖-基本路经法)

+辅助模块设计

(1.驱动模块：相当于被测程序的主程序。接受测试数据，把这些数据传给被测模块然后输出实际测试结果。

2.桩模块：用于调用被测模块调用的子模块。可以做少量的数据操作，不需要把子模块的所有功能都带进来，但不容许什么都不做。)

+黑盒测试用例设计

-等价类划分法

-边界值法——“缺陷遗漏在角落里，聚集在边界上。”

-因果图法弥补等价类和边界值法的不足

-错误推测法

-测试用例的管理可以通过配置管理工具cvs,vss,ClearCase等实现，以保证测试是可重复的。

+常见错误分析

-用户界面问题

·输入无合法性检查和值域检查。

·界面信息不能及时更新，不能正确反映数据状态，甚至对用户产生误导。

·表达不清或过于模糊的信息提示。

·要求用户输入多余的本来系统可以自己得到的数据。

·为了得到某个设置或对话框用户必须做许多冗余的操作，如对话框嵌套太多。

·不能记忆用户的设置或操作习惯，使每次进入系统用户都需重新操作一次初始环境。

·不经用户确认就对系统或数据进行了重大修改。

-形象类问题

·不符合用户的操作习惯。如，快捷键定义不科学不实用，甚至无快捷键。

·不够专业，缺乏基本知识。

·界面中英文混杂，甚至拼写错误。

·说明书或帮助的排版格式不专业：中英文不对应，标点的半全角问题，没有排版准则。

·界面元素参差不齐，文字不能完全显示。

－稳定性问题

·不可重现的死机，或不断申请但不能完全释放资源，使系统性能越来越低。

·主系统和子系统使用了相同的临界资源而相互不知道。如：使用相同的类名或临时文件名、使用同样的数据库字段名或登陆帐号。

·不能重现的错误，许多与代码中的未初始化变量有关，有些与系统不检查异常情况(网络中断、内存申请不成功、长时间无响应等)有关。

-其他问题

·运行时不检查内存、硬盘空间、数据库等。

·无根据的假设用户环境：硬件/网络情况；有些动态库；假设网络随时都是联通的。

·提供的版本带病毒。

·提供错误的版本给测试组或测试用户，或程序员与测试组使用不同版本。

·用户现场开放和修改，又没有记录和保留。

·版本中部分内容或接口倒退，或出现版本管理混乱。

·有些选项永远都是灰的，或有些在该变灰时没变灰。

+测试用例的评审

-测试或测试组件完全针对的是需求中列出的功能吗？

-测试组件是否覆盖了所有的需求？

-有冗余的吗？

-每个测试步骤都有清楚描述的预期结果吗？

+优先级

+3级

优先级1：此测试用例必须执行-2：有时间就执行-3：可以不执行

+5级

1：此测试必须通过，否则产品发布存在危险2：在发布前必须执行3：时间允许就执行4：此测试可以在下一次发布或发布后短期内执行5：可以不测试