CS结构软件测试小结

第一篇：CS结构软件测试小结

安装卸载类：

1、在已经安装软件的情况下，再次进行安装，表现是否正常（比如提示是否升级、检测到已安装），需要考虑已安装和现安装版本差异问题

2、各种杀毒软件（卡巴、瑞星、360）对安装程序的影响

3、是否能在控制面板里面卸载

4、安装后快速启动、桌面、开始程序里面的快捷方式情况

5、卸载时是否退出客户端（退出和不退出都要考虑），卸载后的表现

6、安装的程序是否带有插件

带有微软的framewor，而影响用户的安装和使用

7、安装目录的考虑（中英字符、长度、空目录、根目录、修改目录、默认目录）

8、是否需要考虑在虚拟机中的安装使用？

9、各个版本的安装包大小，客户端产品是需要下载的，所以包的大小对用户来说比较重要 字符（串）类（可输入编辑框或者文本框等也会涉及到）

1、需要考虑字符串长度、字符类型（中文、英文、数字等）、编码类型、如果是英文，还会涉及到大小写的区别。

2、全空格的考虑情况，字符中间含有空格，最导和最后包含空格情况考虑

3、涉及到编码的，要看各个编码下的显示是否正确，以及各个编码之间

4、当有限制长度类的输入时，需要考虑长度刚好达到限制和超过限制后仍然进行输入的情况，也就是需要考虑边界值。

5、对于只能输入字符的地方，尝试输入其他字符比如 汉字，看看操作表现是什么样子。界面类

1、应用程序所有可点击地方是否可以进行操作，菜单、按钮、超链接（文字颜色以及是否能正常超链）、文字等。

2、各种操作对应的正确、错误类提示信息是否正确

3、窗口的缩放（双击的最大最小，点击按钮的最大最小，关闭）、拖动（开多个窗口拖动）、任务栏（左键单击和右键单击的操作）、托盘区、任务管理器操作

一般客户端软件，开着窗口在桌面上移动的时候，cpu占用都比较高，这个性能需要控制在某个合适的范围内。

4、需要考虑窗口的模态性问题，比如有模态窗口的时候，进行其他的操作，以及模态窗口的重绘等。

5、需要考虑软件对键盘上各个键的响应情况，最多用的是enter、shift、crtl、上下左右箭头，home，vendors，pgup，pgdn，del，对tab键的支持等。还要考虑各种热键（全局热键和软件自身的热键）是否能正确响应。

6、各种控件的表现和操作是否正常，下拉列表、日历控件等

7、如果有托盘图标，需要考虑托盘图标的显示状态，是否能显示，操作是否正常等

8、软件的tooltip是否正确合理齐全

9、如果有排序类功能，排序是否正确，如果不正确，和windows系统本身的排序进行比对，看是否一致（例如中文在英文之后，英文是否区分大小写）

10、操作界面的即使动态刷新

11、如果设计到焦点切换的，需要看鼠标的焦点切换是否正常，适合用户使用习惯。

12、涉及到列表类显示的，要看是否显示翻页，翻页是否正常

13、涉及到编辑框的，要看输入内容过多之后，是否有滚轮

14、窗口在屏幕上的位置是否需要具有记忆能力，比如某个窗口操作一次后，下次打开的位置定位在哪里？

15、有的客户端软件要求有飘窗类的提示，需要测试再不同情况下是否能出来，比如最小化到托盘、任务栏以及用ctrl+D显示桌面，是否能正常出来飘窗

16、需要考虑再不同显示器上的显示，各种比例和分辨率下的现实情况。

17、对换行符的处理，有的显示、输入区，如果有换行符的话可能会出现问题

测试遇到过含有换行符的话，后面的内容无法显示出来。

18、一些操作状态的延续变化，很难发现啊。

邮件列表中，在某个分组上点击右键，不放鼠标，将鼠标拖动到分组下的列表上，出现右键菜单不一致的bug。

19、对任务栏的考虑，要考虑任务栏在下方以及在屏幕上下左右侧的情况 兼容性

1、在中英文系统上使用的区别，在控制面板的区域和语言选项里面进行设置，管理选项卡里更改系统区域设置。

2、在不同操作系统上使用的区别（XP,VISTA,WIN 7,2000,2003）

3、在远程操作电脑的时候使用情况，测试的时候遇到过远程操作的时候会可能崩溃的错误。

4、浏览器：不同IE浏览器、带标签页和没有标签页，同一个IE浏览器不同版本的

5、同一个系统的不同系统用户操作（管理员和非管理员）

6、需要考虑不同分辨率，屏幕大小下是否能合适的显示。

7、需要考虑各种浏览器的缓存情况，会不会因为缓存而对测试产生影响

8、对于需要输入文字的地方需要考虑多种输入法切换是否能正常输入。输入达到限制后，再继续输入，是否有问题

9、在32位和64位系统上都需要进行测试。特别是对新的64位系统的支持度。

10、需要操作系统，比如sp1 sp2 sp3等，其他很多操作，可能会有影响的地方都需要考虑一下。

11、需要考虑计算机休眠、待机后再启动软件的表现情况，（还有待机）

各种杀毒软件对软件的影响。瑞星、卡巴、360等

杀毒软件对一些文件类型、端口等有监控，需要考虑。可能由于软件使用某些端口而被杀毒软件阻止而导致不能正常使用

12、jpeg格式图片有灰度图和RGB格式图片，都需要测试到。

13、考虑文件系统格式fat32 /ntfs下区别，比如fat32下有单个文件4G大小的限制等 5 用户体验类

1、界面文字提示是否友好、易懂、简练（因为用户都是懒惰的，不愿意看复杂的东西）

2、操作流程是否清晰，用户知道自己每步都是在做什么

3、有错误类信息，不要使用代码类文字，考虑到用户群体的情况，还要区分中英文（用哪个更好）上传下载传输类

1、上传是否超过最大容量、流量限制

2、上传格式

3、需要考虑不传输文件、传输文件内容为空（大小为0KB，边界值考虑）、文件内容包含特殊字符、文件名字符

4、涉及到网络传输，和端口有关系的，要考虑模拟一下端口错误，封端口的操作（需要补充具体如何封端口）

5、和网络有关系的要考虑使用代理的情况下，软件的运行状况，在传输中设置错误的代理，本地传输并没有受影响（自动收信过程中，设置了代理，但是自动收信还能继续），不受影响应该是正确的。

6、上传下载文件，考虑本地文件，还要考虑ftp，http上的文件。I/O读取类

1、需要考虑磁盘空间不足的情况

2、考虑同不同目录下相同文件的操作情况（比如邮件附件，两次添加同目录下的一个文件和分别添加不同目录下的相同文件的表现）和同目录下同名文件的重复操作

3、正在使用的文件是否是独占状态

4、涉及到文件操作时要考虑文件的类型（例如：txt、doc、gif、png、jpg。。。）、大小（0KB，正常、极大，其实也就是临界值考虑）

5、涉及到导入导出类操作的，需要查看导入导出过程中各种表现是否需要同步变化

6、涉及到文件保存时，需要考虑文件保存的类型、名称的默认给出。

7、文件拖动类的考虑

有的应用程序可以上传、下载、保存文件，那么拖动这些文件试试，看是否会有问题。

例如:对于foxmail邮箱这个软件，可以携带附件，那么试图拖动文件到附件区，或者从附件区拖动附件到文件夹，任务栏，或者拖动到程序中其他地方。另外，发现附件可以直接拖动到正文区进行显示的（新发现的功能，应该是编辑区的控件本身就支持吧，呵呵，惊讶了一把，居然还有这个功能，似乎很方便）。

8、系统对单个文件夹大小做限制，ntfs和fat格式的系统对单个文件大小有限制

9、图片文件原本为jpg格式的，但是修改后缀为gif后添加到表情 或者插入到其他地方。出现不能识别的问题。因为其他控件按照后缀先判断为gif格式，再走gif格式流程处理，但是实际上图片本身是jpg格式的

10、涉及到文件写入读取的，需要考虑移动设备，比如U盘、硬盘、ftp等 8 性能类

1、单核、双核的区别

2、内存大小的区别

3、同一个操作涉及不同的文件大小的时候，PC的反应（例如传输大文件和小文件）

4、涉及到网络操作时，超时是否及时、提示是否合理

5、是否有GDI泄漏（界面？）

6、使用过程中cpu、内存的占用情况 检索、过滤、搜索类

1、对分词的检索是否准确，比如如果检索ab，那么a b是否 会被检索出来？要视要求而定。

2、搜索的时候，对不同格式的文件内容，是否能够正常搜索，比如HTML格式和txt格式之间的区别，因为HTML格式本身含有标签以及其他一些内容，但是这些内容并不显示出来，所以搜索的时候是否需要搜索这些内容，需要进行考虑

3、搜索匹配时，对中英文的支持度（比如输入英文能否匹配中文，输入中文，能否匹配英文等。）

其他

1、客户端类软件，需要注意到开启的各个窗口之间数据同步一致性问题，各个窗口之

间事件触发是否会马上在其他窗口或者界面响应。

2、考虑界面上文字、各个窗口之间需要保持一致的文字说明。（诸如相同属性名称 文字提示信息等）

3、同一个操作涉及到的不同状态变化是否正常。（例如，点击某个链接，文字颜色是 否变化，点击某个按钮，按钮颜色或者属性是否变化等）

4、使用软件的过程中，多关注cpu、内存、句柄占用等方面的情况。

5、要能多考虑各种异常情况（磁盘空间不足、文件占用、网络断掉、断电、手动切进程模拟异常退出）

6、涉及到对文件目录的操作，需要考虑是否能记住/清除原来使用过的文件目录。如果是新建，要考虑是否可以新建成功（windows对新建文件的字符限制）

7、同一类的界面表现、操作应该尽量保持保持一致。（？没有描述好）

8、要多考虑进行了一个操作/设置后，可能会影响的其他方面，同步表现是否正常，设置是否有效等。

9、和服务器有相关的一些操作，都要考虑一些操作是在客户端处理，还是在服务器端处理的。服务器和客户端之间的一些交互返回信息，比如错误码等。

11、个人想法总结类

1、写总结、bug类语言描述一定要慎重，多读几遍，以便让其他人更能看明白，避免 求快而写错别字，用错术语。总结类需要写的更专业一些，避免通俗的、麽凌两可的的语言描述。宁可多花时间少写内容，少报bug，也不要报上去的bug，给别人看的总结出现过多纰漏，没有发现的bug可能是工作失误，但是发现了，但是却有不描述好，或者自己描述的不确定后事后自己都解释不清楚的话，那就更糟糕了，更上级看的总结也是如此，及时发现的bug再多，总结却是评价你这次测试的一个方面，如果总结写的很差，必然给领导留下很差的印象，或者总是在受到领导的批评。总之，三思而后行，是没错的，也许某些时候会降低工作效率，但是有时候，出现错误带来的负面影响比工作效率低下带来的负面影响更大。

2、开发对于一个软件安装和使用中生成的各种文件，最好有一份比较好的说明文档，当然开发可能没有时间去写，而且公司里面如果没有强行要求的话，他们也是不会写的，所以测试人员就只能自己多去钻研了，对于这些文件的了解对于测试也是很有必要的。遇到不懂的要及时跟开发沟通询问。有时候可能需要花费比较多的时间来了解开发的一些处理流程和文件具体含义（比如一些XML文件具体保存的是什么内容），这就需要协调和测试时间的冲突，因为要花时间了解，所以测试必然会耽误时间，但是了解之后却有利于进行某些功能的测试。慢慢改进吧。

3、不属于自己的任务，还是不要多去做的好

4、有时候自己提出来的产品问题，不一定会被领导、策划或者其他相关开发人员接受，除非等到产品发展部提出来。

5、测试中，只要有一点问题，就应该及时提出来，如果自己用的不顺手，或者觉得不合理的，自己多记录和总结，虽然不一定会被公司采纳，但是可以作为自己的总结类内容，整理出来。

12、可用性用户体验

1、跟网络有关系的，对网络错误的提示，有的需要及时，有的不需要频繁提示网络错误，应该多提供几次重连，比如三次，如果重连三次都发现网络错误连接失败，就提示用户，否则太频繁会有骚扰和降低用户对产品的信赖

2、给用户提供的操作，用户可以用，也可以选择不用，所以界面上需要提供取消类的入口，否则强制性的使用体验上不是很好，比如提供上一步类的入口也类似。

3、需要判断重复性的操作（已经安装、已经导入、已经。。）是否能提示用户

4、涉及到告诉用户文件类型的操作，应该尽可能明确的给予显示类型，因为不是很多用户对文件类型有概念。比如如果某个功能需要导入txt格式文件，尽量做到能自动检测显示出来，而不是让用户自己去找

5、像日历这种控件，不仅仅需要提供月更改入口，还要提供便利的年更改的入口

6、对于一些快捷键，能给予tip或者附带在文字后面的，尽量让用户可见，否则让用户揣测，那太不人性化了点吧。

7、发现***和其他圆角的窗口有同样的情况，最大化时鼠标移到屏幕的最右上角点击，如果没点中按钮而是正好点在圆角的地方，则关掉的不是闪电邮而是它后面的窗口，比如浏览器……因为我经常把鼠标往右上角一推就按，不会去找按钮，所以好几次了。不过这倒也不太算是毛病..

第二篇：软件测试小结

第二阶段学习小结

1.白盒测试需要了解其内部结构和运行机制。白盒测试，也称之为结构测试和逻辑驱动测试。黑盒测试不需了解程序内部结构和内部特征。主要着眼于程序外部的用户界面，关注软件的输入和输出，关注用户的需求，从用户的角度来验证软件的功能。黑盒测试也称之为功能测试和数据驱动测试。

2.黑盒测试技术主要有：等价类划分法、边界值分析法、判定表方法、因果图法、错误推测法。

3.白盒测试主要技术有：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖。

4.测试用例的定义：测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。

软件测试的基本格式：软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。{系统测试用例的编号这样定义规则： PROJECT1-ST-001，命名规则是项目名称+测试阶段类型（系统测试阶段）+编号。定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。测试用例设计方法：（1）逐级细分法（2）输入域测试法（3）输出域分析法（4）正交试验设计法（5）业务流程分析法（6）状态迁移法（7）因果图法（8）判定表法（9）错误猜测法(10)等价类划分法（11）边界值分析法}。

5.Bug的描述：

① 和 bug 产生对应的软件版本。

② 开发的接口人员。

③ bug 的优先级。

④ bug 的严重程度。

⑤ bug 可能属于的模块，如果不能确认，可以用开发人员来判断。

⑥ bug 标题，需要清晰的描述现象。

⑦ bug 描述，需要尽量给出重新 bug 的步骤。

⑧ bug 附件中能给出相关的日志和截图。

6.软件测试环境的主要要素：配置测试环境是测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的重要性和真实性。一般来说，配置测试环境要满足五个基本元素：硬件、软件、网络环境、数据准备、测试工具。

7.测试环境的搭建:单机版测试环境搭建，b/s架构测试环境的搭建，c/s架构测试环境的搭建。

8.测试环境的管理：设置专门的测试环境管理员角色、明确测试环境管理所需的各种文档、测试环境访问权限的管理、测试环境的变更管理、测试环境的备份和恢复。

9.自动化测试工具介绍：性能测试—Loadrunner、Robot、Silk performer，功能测试—QTP、Winrunner、Robot、Silk test，其他测试—Xenu、AiRoboForm。

第三篇：软件测试小结

1.什么是白盒黑盒测试

白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。

黑盒测试：又被称为功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，2.测试方法：等价类划分、边界值分析方法、因果图、判定表

等价类划分法就是解决如何选择适当的数据子集来代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能数据，以发现更多的软件缺陷。

等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。利用这一方法设计测试用例可以不考虑程序的内部结构，以需求规格说明书为依据，选择适当的典型子集，认真分析和推敲说明书的各项需求，特别是功能需求，尽可能多地发现错误。等价类划分法是一种系统性的确定要输入的测试条件的方法。

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

因果图法即因果分析图，又叫特性要因图、石川图或鱼翅图，它是由日本东京大学教授石川馨提出的一种通过带箭头的线，将质量问题与原因之间的关系表示出来，是分析影响产品质量的诸因素之间关系的一种工具。从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变),可以通过因果图转换为判定表。

因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。采用因果图法能帮助我们按照一定的步骤选择一组高效的测试用例，同时，还能指出程序规范中存在什么问题，鉴别和制作因果图。

因果图法着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。3.软件测试的二八原则

80%的缺陷出现在20%的代码中。也即80%的bug多发生在软件的20%的模块。

4.判定覆盖比条件覆盖有更强的逻辑性

判定覆盖, 也称为分支覆盖, 它的基本思想是: 设计若干测试用例, 使被测程序中每个判定的取真分支和取假分支至少执行一次, 即判断真假值均曾被满足。而条件覆盖的基本思想是: 要编写足够的测试用例以确保将一个判断中的每个条件的可能结果至少执行一次。

（1）判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

往往大部分的判定语句是由多个逻辑条件组合而成。

（2）条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。

要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

5.在代码测试覆盖中，覆盖了条件的测试用例不一定会覆盖代码里的判定分支

要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

条件覆盖：设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。

判断M表达式:设条件 a>0 取真 记为 T1 ；假F1

条件 b>0 取真 记为 T2 ；假F2

判断Q表达式:设条件 a>1 取真 记为 T3 ；假F3

条件 c>1 取真 记为 T4 ；假F4

我们用条件覆盖设计的思想就是让测试用例能覆盖T1、T2、T3、T4、F1、F2、F3、F4

【优点】：增加了对条件判定情况的测试，增加了测试路径。

【缺点】：条件覆盖不一定包含判定覆盖。例如，我们刚才设计的用例就没有覆盖判断M的Y分支和判断Q的N分支。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

6.因果图方法会根据输入输出的依赖关系来设计测试用例

因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。

7.质量模型包括：使用质量、内部质量、外部质量

软件质量模型可以分为：内部质量和外部质量模型、使用质量模型，而质量模型中又将内部和外部质量分成六个质量特性，将使用质量分成四个质量属性，8.软件测试的核心理念及核心技术（救命题）

9.程序规格规定：输入三个整数作为三边的边长构成三角形，当此三角形为一般三角形、等腰三角形和等边三角形的时候，分别计算。

用等价类划分的方法进行用例设计 输入条件要求：

整数、三个数、非零数、整数 输出条件要求：

两边之和大于第三边，等腰，等边 列出所有等价类:

1.使用质量模型包括：有效性、生产力、满意度、安全性；

2.基本软件的测试方法：单元测试、集成测试、系统测试；

3.系统测试：功能测试、恢复测试、安全测试、性能测试、协议测试；

4.软件测试越早，发现的问题越容易修改，投入的代价就越小。

第四篇：软件测试人员结构组成分析

软件测试人员结构组成分析

软件测试工程师是软件行业中一种即年轻又古老的职业，进入二十一世纪以来，随着中国加入WTO以后，从事这项职业的人也越来越多。一个公司在组建一个测试队伍的时候如何分配人员结构，从而使公司软件测试工作水平得到提高，是大家比较关注的问题。本人依照自己的经验提出自己的观点：

我们首先来看一下测试人员的纵向结构

1，测试经理

测试经理主要负责测试队伍的内部管理以及与其他外部人员，客户的交流，详细说来主要包括进度管理，风险管理，资金管理，人力资源管理，交流管理等等，测试经理需要具有项目经理的知识和技能。同时测试工作开始前项目经理需要书写《测试计划书》，测试结束需要书写《测试总结报告》

2，测试文档审核师

测试文档审核师主要负责前置测试，包括在需求期与设计期间产生的文档进行审核，比如《业务建模书》，《需求规格说明书》，《概要设计书》，《详细设计书》等等。审核需要进行书写审核报告。当文档确定后，需要整理文档报告，并且反映介绍给测试设计师。3，测试设计师

测试设计师主要根据需求期与设计期间产生的文档设计各个测试阶段的测试用例。（往往测试文档审核师，测试设计师可以有相同的一组人来完成）

4，测试工程师

测试工程师按照测试用例，来完成测试工作。

但是测试人员应该有哪些人来组成呢？也就是测试人员的横向组成，让我们再来讨论讨论：

1，需要具有一定开发经验的计算机专业人员

由于具有一定开发经验的计算机专业人员即懂得计算机的基本理论，又有一定的开发经验。所以对于软件中哪里容易出错，哪里不容易出错他们了如指掌；他们可以分析程序的性能，软件性能差是否是占有内存空间太多，或者是占有CPU时间太多引起的，还是其他原因，他们往往是专家。尤其是进行非功能测试的时候，他们可以更好的搭建系统测试平台。这种人员应该占测试队伍中一半以上。

2，需要具有本软件业务经验的人员

测试队伍中需要有这样的人员的目的在于，这些人员由于对业务非常熟悉，软件质量的前提又是满足用户的需求。专业业务知识是计算机专业人员达不到的，所以这方面人才可以利用它们的业务知识和专业水平，参与系统需求期间的文当审核，可以发现软件中存在的业务性错误。比如专业用语不准确，业务流程不规范等等，这种人才对于专业性比较强的软件测试工作尤为重要，比如税务，法律，艺术，CAD,CAM…

3，只需要会操作计算机的人员

由于软件一旦卖出去之后，使用软件的人各种各样，各种各样的人带来各种各样的操作情况，请一大部分人员在软件测试工作后期进行测试工作是十分重要的，他们往往会发现专业测试人员测试不出的东西和一些希奇古怪的错误。这就是软件测试学中所谓的猴子测试法。对于一个软件公司来说，并不是说所有的测试队伍都需要这三种人员，实际中可以一组人代替多个角色，但是要遵循以下原则：

1，对于业务不是很专业的软件，具有一定开发经验的计算机专业人员与具有本软件业务经验的人员可以合并；

2，只需要会操作计算机的人员，可以由公司行政人员来充当。

第五篇：文档加密软件测试小结

加密软件测试小结

1、山丽防水墙

a)厂家技术人员上门安装，简单培训使用方法以及功能 b)加密服务器使用加密KEY方式 c)客户端需登录到服务器

d)可以实现对U盘等移动设备的加密及管理

e)可以实现对网络传输文件的加密管理，即可以选择网络传输的不进行加密

2、亿赛通

a)代理商上门进行安装，简单培训使用方法及功能 b)加密服务器采用授权码方式 c)客户端需登录到服务器

d)可以实现对U盘等移动设备的加密及管理

e)可以针对所使用软件的进程进行加密，可以针对所使用的文件扩展名进行加密 f)可以针对特定文件夹进行落地加密，即只要放到这个文件夹中的文件自动进行加密 g)

3、IP-Guard a)厂家发送软件安装包，我们自行进行安装，附有使用说明文件 b)加密服务器采用授权码方式

c)客户端安装后无需登录到服务器，自动与服务器联系 d)可以实现对U盘等移动设备的加密及管理 e)对文件的加密是采用的监视软件进程方式，只要是该软件进程产生的文件即进行加密，软件进程采用特殊的控制方式，厂家可以提供工具生成授权软件的进程库。f)加密可以按保密级别以及使用部门进行区分，不同密级以及不同部门的加密文件不能互相打开

g)通过管理程序可以对客户端进行非常详细的控制和管理

山丽防水墙和亿赛通的授权使用日期都只有不到一个礼拜，所以测试的内容较少，主要测试了与PDM系统的兼容性，后期再向厂家申请试用时间。

通过测试发现，PDM系统中的零部件图纸如果进行加密的话，山丽防水墙是不能直接通过设计软件直接打开的，其他两款可以直接打开；文档文件也是，如果进行加密的话，山丽防水墙不能直接通过点击打开，需要先下载到本地硬盘才能打开。如果PDM服务器上的图纸文件进行加密的话，文档文件没什么影响，零部件图纸就会出现缩略图不能查看的问题，即使装了加密客户端也不能查看缩略图，用Product View也不能打开查看，把相应的进程加到加密软件的进程里面也不行，IP-Guard因为没有进程工具所以没能进行ProductView进程的添加测试。

鉴于缩略图的影响以及为了图纸的安全，我们建议服务器上的文件不能加密，明文保存，这就需要对PDM系统的访问进行限制，比如不装加密客户端的不能访问PDM系统。山丽防水墙目前还不能实现该功能，亿赛通厂家说有专用网关设备来实现认证访问，准备下周带来进行测试，IP-Guard目前就能实现不装客户端不能访问PDM服务器的功能。对于服务器端不加密的问题，山丽可以通过设置网络不加密来进行控制，但这样就能不能控制通过网络把图纸传送到其他电脑，亿赛通厂家人员说通过其专用网关可以进行控制，等待下周其设备到后进行测试；IP-Guard目前不具备该功能，厂家技术人员说可以实现，但需要进行二次开发。

另外还有其他几款加密软件，厂家说可以实现我们需要的功能，已经约好下面几周进行安装测试。