软件测试外包管理之我见(转)

第一篇：软件测试外包管理之我见(转)

我们应该如何面队国外抛送过来的包呢？难道就就是长期以“包工制”形式一直做下去？

印度一家公司软件工程师为软件企业产品开发人员讲授如何管理软件测试外包项目。

我们应该如何面队国外抛送过来的包呢？难道就是长期以“包工制”形式一直做下去？

答案是否定的。很显然，我们的“包工制”外包项目就是靠实现服务赚钱，如果长此以往，那么我们做的只是低层次的IT企业或软件企业，这种发展趋势，决不是中国企业、中国政府所希望发展趋势。

那么我们应该如何逐步演变“包工制”，如何借“外包”把中国的软件企业带到一个更高的境界？

项目外包的核心理念就是“做你最拿手的，其余的让别人去做”。因此，我们要做好外包项目，也需要从这个理念开始。我们不是没包接，而是没有实力和规模接大包。所以我们要能做好外包项目，做大外包项目，首先我们要有自己最拿手最擅长的招。印度的规模编码设计、爱尔兰的本地化都是在IT市场竞争中获胜了的接包的招。可是我们国内企业，还需要磨练，还需要更强更深的技术能力和项目管理能力等招术。

软件外包测试的兴起对国内软件本地化企业意味着什么？笔者认为，意味着更多的机会，争取更多软件外包国际市场份额的机会。笔者试图通过多年来从事中高端软件外包工作管理的经历，以一个外包测试项目为例，总结了一些外包测试项目的经验，与读者共飨，以期达到抛砖引玉，共同提高外包行业管理能力的目的。限于篇幅，本文仅对测试外包中的风险管理和沟通管理做一个简单的整理。软件测试外包特性

与国内一直以来比较轻视软件测试工作不同，在很多欧美软件企业中，测试（质量控制）是一件非常重要的工程工作。国内企业一般在从事软件项目开发的时候，更多的是由开发人员或者客户人员在开发完成之后才进行一些简单的功能测试工作，很少采用专业的测试团队，开发与测试的比例在4:1以上，甚至高于10:1。因此，多数中国软件的质量水准相对要低。

与此相反的，在欧美企业中，质量管理人员（包括事后的质量控制和事前的质量保证）的地位却高的多。测试也作为一个非常独立的职业。在IBM、Microsoft等开发大型系统软件公司，很多重要项目的开发测试人员的比例能够达到 1:2，甚至1:4。测试活动贯穿于整个开发生命周期，甚至会比普通开发人员更早介入项目。测试也是一门更讲究科学方法的工程活动，测试的种类也包括单元测试、集成测试、功能测试、性能测试、β测试、验收测试等等。

本文所介绍项目的客户是美国一家知名的金融业软件及服务供应商。由于金融业的特点，对于软件的可靠性、稳定性等质量要求尤其的高。该公司从2005年开始将部门开发和测试工作外包到中国地区，由笔者所在公司在北京和上海分别成立了两个团队，采用一种类似ODC（Offshore Development Center，离岸外包中心）的模式。笔者在过去一年半的时间内负责北京团队的建设和管理，从最初的一个测试人员和两个开发人员发展到现在的十几人的团队（笔者由于公司内部工作安排已经于去年下半年离开该项目）。从最初的从事简单的软件产品的安装和数据移植测试，到现在从事其核心产品的全面功能测试和自动化测试，团队的工作越来越受到客户的认可，在客户的软件开发过程中的重要性也越来越高。按照人员数量来计算，该项目的测试与开发人员的比例略高于1:1。

软件测试外包的风险管理

软件外包工作由于天然存在的地理、语言文化差别，其失败的风险几率就大的多了。所以从事外包的管理人员在项目启动之前尤其要对项目中可能存在的风险因素有一个比较全面地识别和分析。比较好的一种风险识别方法是结构化的头脑风暴法，通过集思广益找出所有可能影响到项目进度、成本、质量的因素。一个非常重要的风险因素的来源是项目计划的假设和约束，一旦项目成功所作的假设不能达到，这些就会成为未来影响项目正常进展的问题。

一旦识别出尽可能多的风险因素之后，需要对这些因素进行评估，并不是所有的风险都需要去规避，所以必须分析哪些风险会对项目产生重大影响，哪些风险发生的可能性非常高。根据这些分析结果排出项目中优先级比较高的风险因素（比如Top 10列表），然后针对这些风险分别找出规避的措施以及风险发生时的应对举措。

针对本文中提到的项目，从风险识别的角度来说，自然灾害和战争等也是被识别的一些因素，由于属于不可抗力，所以一般并不列入项目风险管理计划，但不要因此在风险识别阶段就将其排除。而时差、测试人员的英语表达能力、中美的文化差异、网络的稳定性和速度（想想前段时间的海底光缆事故）、数据传输的安全性、节假日安排这些做国内项目的时候几乎不会考虑的因素可能会是对项目的致命威胁。

对于每个风险都能找到一定的规避和减少损失的措施，笔者在项目启动初期花费了较多时间准备金融领域的业务知识，通过夜间在家加班与客户建立了良好的信任关系，建立了定期的会议和汇报机制，很短时间之后就确保了团队正点上下班也不会存在时差所带来的障碍。

软件测试外包的沟通管理

学习过PMP/PMBOK的朋友可能都知道这么一个事实，一个项目经理85%的时间都用在各方面的沟通交流上。很多项目出现问题都不是在技术上碰到难题，而更多的是由于沟通不畅引发的后果。

以前做国内项目的时候一说沟通，很多人就想到要和客户一起去吃饭喝酒。相对这种非正式的个人之间的沟通，在外包项目管理中更需要建立流畅的正式沟通渠道。这种正式的沟通渠道包括但不限于定期的电视电话会议，正式邮件往来，通过IM的工作聊天，统一的错误报告机制（Bug跟踪系统及其他）等。一个非常重要但经常被忽视的沟通渠道就是文档，尤其是项目计划，不少项目经理都只是把项目计划当作前期不得不完成的一个文档，到项目执行过程中即使再去阅读也只是关注进度表部分。其实项目计划包含了众多内容，除了进度表外，还包括上面提到的风险管理计划，以及项目的范围界定和各种项目管理流程（包括需求变更管理流程等），它在一定意义上是合同的一部分，所以及时的更新、审核（Review）和批准（Approval）不仅仅对项目的监控非常重要，对于开发方来说也是很好的法律上的保护。

正式的沟通还有一点非常需要注意的就是要保证良好的反馈机制。我们都知道信息在传递的过程中会受到噪音的干扰，尤其是在多次传递的情况下更容易失真。所以在建立沟通渠道的时候要建立起方便有效的反馈途径。对于重要的文档，一定要有合适的审核和批准机制。更为有效的一种机制还是利用类似于Mercury的Quality Center这样的工具，由于其内置了工作流，所以任何的问题都必须按照一定的流程进行处理，避免了因为工作忙而忘记了一些重要工作的可能。

最后需要提醒的一点的是，要保留一切沟通过程的证据。美国的金融监管部门对金融业内部的所有电子邮件要求保留至少5年以上以备检查。在项目中证据的保留一方面是对自己权益的保护，另一方面也是保持完整的沟通记录有利于后期出现问题的顺利解决。

注：本文转自网络。

第二篇：软件测试外包公司面试题

1、试述软件的概念和特点?软件复用的含义?构件包括哪些? a)软件的概念：

软件是程序、数据结构和相关文档的集合，用于实现所需要的逻辑方法、过程或控制。软件是把知识与技术紧密结合的智力成果，是在研制、开发中被创造出来的一种信息产品。

b)软件的特点：

①抽象性软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。②不会磨损在软件的运行和使用期间，没有硬件那样的机械磨损、老化问题，但软件 维护比硬件维护要负责的多。

③软件开发工作最大、开发效率低、成本高，但复制容易、成本极低。④对计算机系统的依赖性

⑤软件具有无形性，可以多次使用，但商业寿命较短。c)软件复用(SoftWare Reuse)：

软件复用是将已有软件的各种有关知识用于建立新的软件,以缩减软件开发和维护的花费，提高软件生产力和质量的一种重要技术。

d)构件：

构件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。构件代表系统中的一部分物理实施，包括软件代码（源代码、二进制代码或可执行代码）或其等价物（如脚本或命令文件）。

2、瀑布模型和螺旋模型的主要区别是什么？

瀑布模型强调的保证软件的质量,忽略人力,时间,资源等成本因素,以质量为第一目标,每次需求发生变更都要从头再来，适合于一些大型稳定的项目。

螺旋模型是一种增量迭代开发的模型,每一次循环都是一次版本的升级，可提高软件的适应能力。比较适合于前期需求不稳定,后期需求新增变更较多的项目。

瀑布模型是基于质量的, 是由文档驱动的。螺旋模型是风险驱动的，更需要经验丰富的风险评估知识和水平。

3、软件生存周期及其模型是什么？

a)软件生命周期是：计划-需求分析-软件设计-程序编码-软件测试-运行维护

b)常用的模型有：瀑布模型，螺旋模型，IPD流程，RUP流程

4、什么是软件测试？软件测试的目的与原则？

a)软件测试是在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估

即软件测试是为了发现错误而执行程序的过程。

b)软件测试的目的是找出软件产品中的错误，是软件尽可能的符合用户的要求。当然 软件测试是不可能找出全部错误的。

软件测试的原则： 测试显示缺陷的存在（但不能证明系统不存在缺陷）穷尽测试是不可能的 测试尽早介入

缺陷集群性（80-20原则）杀虫剂悖论

测试活动依赖于测试背景 不存在缺陷的谬论

5、净室软件工程的策略是什么？

a)增量计划。开发一个采用增量策略的项目计划，建立每个增量的功能、它的项目大小、以及净室开发进度表。必须特别小心以保证通过认证的增量将被定时集成。

b)需求收集。使用类似于在第11 章引入的技术，为每个增量开发一个客户级需求的更详细的描述。

c)盒结构规约。使用一个运用盒结构的规约方法[HEV93]来描述功能规约。遵从操作分析原则，盒结构“在每一个精化级别上分离和分开行为、数据及过程的创造性定义”。

d)形式化设计。使用盒结构方法，净室设计是规约的自然的无缝的扩展。虽然，在两个活动间可进行清楚的区分，但是，规约(称为“黑盒”)是被递进地求精(在一个增量内)以成为类似于体系结构的和过程的设计(分别称为“状态盒”和“清晰盒”)。

e)正确性验证。净室小组对设计及代码进行一系列严格的正确性验证活动。验证从最高层次的盒结构(规约)开始，然后移向设计细节和代码。正确性验证的第一层次通过应用一组“正确性问题”[LIN88]来进行，如果这没有证明规约是正确的，则使用更形式化的(数过学的)验证方法。

f)代码生成、检查和验证。以某种专门语言表示的盒结构规约被转换为合适的程序设计语言。然后，使用标准的走查或检查技术来保证代码和盒结构的语义相符性，以及代码的语法正确性。然后，对源代码进行正确性验证。

g)统计性测试计划。分析软件的项目级使用情况，计划和设计一组执行用途的“概率分布”的测试用例。如图25-1 所示，这个净室活动是和规约、验证及代码生成并行进行的。

h)统计性使用测试。记住，对计算机软件进行彻底测试是不可能的，因此，总需要设计有限数量的测试用例。统计性使用技术[POO88]执行一系列由特定对象的所有用户的所有可能的程序执行的统计样本(上面提到的概率分布)所导出的测试。认证。一旦完成验证、检查和使用测试(并且所有错误被修正)，则开始进行增量集成前的认证工作。

6、软件配置管理的作用 软件配置包括什么？

a)软件配置管理作为软件开发过程的必要环节和软件开发管理的基础，贯穿整个软件生命周期，同时对软件开发过程的宏观管理即项目管理也有重要的支持作用。一个软件开发组织真正有效的实施软件配置管理，将会使软件开发过程有更好的可预测性，使系统具有可重复性，大大提高软件组织的竞争力。

b)软件配置包括如下内容：

配置项识别

工作空间管理 版本控制 变更控制 状态报告 配置审计

7、简述需求分析的过程和意义？

1、明确需求以及测试范围

了解该需求是为了解决用户的什么问题 功能性需求：产品必须有的功能

非功能性需求：是否美观，用户体验，稳定性，易用性等

最容易忽略的一点：明确的需求背后所隐藏的需求（例如登录，明确的需求是，正确输入用户名，密码，才能登录。隐性需求：用户名字符类型，长度，是否可为空；密码字符类型，长度等）将问题在需求阶段暴露的成本最小

2、画业务流程图（流程图）根据需求中规定的业务流程 各业务流程分支的确定

由于业务原因规定不可使用的业务流程

3、功能点整理（思维导图）

业务功能：需求中所定义的实际业务直接相关的功能

数据约束：主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

易用性需求：便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。

编辑约束：在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

权限需求：不同的权限所能操作的功能点的不同

4、提取测试点（测试需求文档）

根据整理的思维导图，去提取每一个功能点中的细节需求，例如新增员工，在思维导图中，最小的颗粒度就到新增员工了，但是新增员工这个功能仍然有很多的需求点，员工姓名唯一性判定，手机号码是否必填等，这些更细的需求点组合起来就形成了测试需求文档

5、确定测试范围

需求的确定，并不代表测试范围就是该需求的范围，很有可能一个需求分多个软件版本来实现，最后确定哪些需求是需要测试的。明确哪些测试目标优先级高，哪些目标优先级低 要完成哪些相应的测试任务才能确保目标的实现

总结： 需求分析的越详细，对业务的理解程度就越高，对设计测试用例的帮助就越大。测试的过程中就更有目的性。“磨刀不误砍柴工”，需求分析花的时间越多，之后测试的时间就越少。因为测试其实已经从需求阶段开始了。

8、什么是数据的对立性？有几个层次？

数据独立性是指：应用程序和数据库的数据结构之间相互独立，不受影响。分为物理独立性和逻辑独立性两个层次。

物理数据独立性：如果数据库的内模式要进行修改，即数据库的存储设备和存储方法有所变化，那么模式/内模式映象也要进行相应的修改，使概念模式尽可能保持不变。也就是对内模式的修改尽量不影响概念模式。

逻辑数据独立性：如果数据库的概念模式要进行修改，如增加记录类型或增加数据项，那么外模式/模式映象也要进行相应的修改，使外模式尽可能保持不变。也就是概念模式的修改尽量不影响外模式和应用程序。

9、网状、层次数据模型与关系数据模型的最大的区别是什么？

网状、层次数据模型与关系数据模型的最大区别在于表示和实现实体之间的联系的方法：网状、层次数据模型是通过指针链，而关系数据模型是使用二维表。

10、dbms读取一条记录时发生哪些事件？

用户程序A向DBMS发出读一条记录的指令，这时用户程序要给出外部文件名和记录的关键字值

DBCS分析所接到的指令，访问对应的外部模式

DBCS完成外部模式到概念模式的转换，决定访问哪个（些）概念文件 接着由DBSS完成概念模式到存储模式的转换，并决定访问哪个（些）存储文件

DBSS调用存取方法，通过操作系统将读取的记录送到系统缓冲区 用户程序从系统缓冲区得到所需记录和DBMS返回的状态信息 用户程序在工作区中使用所得到的记录

11、什么是软件质量 软件包是什么？

a)概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。

b)软件包(SoftWare Package)是指具有特定的功能，用来完成特定任务的一个程序或一组程序。软件包由一个基本配置和若干可选部件构成，既可以是源代码形式，也可以是目标码形式。用户手册和指南等文档是软件包的重要组成部分。

12、软件产品质量特性是什么？ 确保软件质量优良程度的内部因素称为软件质量特性。比较权威的软件质量特性划分应推Boehm提出的十二个基本质量特性。分别为：设备无关性、完整性、精度、一致性、设备效率、可访问性、可通讯性、结构性、自说明性、简明性、易读性、可扩充性。

13、什么是软件质量保证 其主要任务是什么？

软件质量保证：为确保软件开发过程和结果符合预期要求而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。

主要任务：

(1)用户要求定义(2)力争不重复劳动

(3)掌握开发新软件的方法(4)组织外部力量协作(5)排除无效劳动

(6)发挥每个开发者的能力(7)提高软件开发的工程能力(8)提高计划和管理质量

14、软件质量保证体系是什么？ 国家标准中与质量保证管理相关的几个标准是什么 他们的编号和全称是什么？

为满足质量要求和实施质量管理，进行全部有计划和有系统的活动所需的组织结构、程序、过程和资源的总称。

GB／T 19001质量体系设计／开发、生产、安装和服务的质量保证模式（idtISO 9001）

GB／T 19002质量体系生产和安装的质量保证模式（idtISO 9002）

GB／T 19003质量体系最终检验和试验的质量保证模式（idtISO 9003）

GB／T 19004质量管理和质量体系要素指南（idt ISO9004）

15、软件测试的原则与策略是什么？

软件测试原则：

1、尽早和不断的测试。

2、程序员应该避免检查自己的程序，软件测试应该由第三方构造。

3、设计测试用例时应该考虑到合法的输入和不合法的输入以 及各种边界条件。

4、注意测试中的错误集中发生现象。

5、对测试错误结果有确认过程。

6、制定严格的测试计划，并把测试时间安排的尽量宽松。

7、回归测试的关联性，原有功能过滤

8、进行版本控制，制定变更测试文档的流程。

测试策略，在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合，需在测试计划文档中体现。

16、什么是测试用例 什么是测试脚本 两者的关系是什么？ 测试用例是为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

测试用例（TESt CASe）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试脚本就是用户对业务操作的记录，将测试用例用测试脚本表述出来，那我们就不用手工执行测试了，就可以通过执行测试脚本来执行测试

测试脚本是进行自动化测试时编写的脚本程序 测试脚本中要包含测试用例中的数据

17、简述什么是静态测试、动态测试、黑盒测试、白盒测试、a测试 b测试？

静态测试是指测试不运行的部分——只是检查和审核 动态测试是指通常意义上的测试——使用和运行软件

黑盒测试：不关心软件内部结构，只关心输入输出，主要测试依据是需求文档 白盒测试：关注软件的内部结构和程序的设计实现，主要测试依据是设计文档

α测试是软件开发公司组织内部人员，模拟各类用户，对即将上市的软件产品进行测试，试图发现错误并修复的过程。

β测试是由软件的多个用户在实际使用环境中进行的测试，这些用户返回有关错误信息给开发者。

18、测试问题的严重性分为几级 ？如何区分？

为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。

具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。例如，使用数字1，2，3，4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1，2，3，4可以分标表示低优先级、一般、较高优先级和最高优先级。

微小的（Minor）一些小问题如有个别错别字、文字排版不整齐等，对功能几乎没有影响，软件产品仍可使用。

一般的（Major）不太严重的错误，如次要功能模块丧失、提示信息不够准确、用户界面差和操作时间长等。

严重的（Critical）严重错误，指功能模块或特性没有实现，主要功能部分丧失，次要功能全部丧失，或致命的错误声明

致命的（Fatal）致命的错误，造成系统崩溃、死机，或造成数据丢失、主要功能完全丧失等。

19、测试用例设计的原则是什么 目前主要的测试用例设计方法是什么？ 测试用例设计的原则是：

代表性：能够代表并覆盖各种合理的和不合理、合法的和非法的、边界的和越界的、以及极限的输入数据、操作和环境设置等.可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果.可再现性：即对同样的测试用例，系统的执行结果应当是相同的。方法有等价类、边界值、因果图、状态图、正交法、大纲法

20、结构化系统测试和功能性系统测试分别采用了哪些方法和技术？

a)结构化系统测试技术：

用于验证所开发的系统及程序的运行情况。目标是要确保产品设计在结构上合理，功能上正确。为确定实现的配置及其各功能共同作用以完成特定任务提供了一种机制。

结构化测试技术由以下几种：

压力测试：确定系统以期望的容量执行。

执行测试：系统能达到期望的熟练性。

恢复测试：系统失效之后可以恢复到可操作状态。操作测试：系统以正常操作状态执行。

一致性测试：系统的开发与标准和规程相一致。安全性测试：根据组织的重要性对系统进行保护。

b)功能性系统测试用于确保系统需求与定义都得到了满足。该过程通常包含创建用于评价应用程序正确性的测试条件。

用于执行功能测试的几种测试技术包括： 需求测试：系统按制定方式执行。

回归测试：验证系统中没有改变的部分仍能正确运行。错误处理测试：错误可以得到防止或检测，并被修复。

21、软件测试分为几个阶段 各阶段的测试策略和要求是什么？

软件测试分为单元测试、集成测试、系统测试、验收测试四个主要阶段：

单元测试：单元测试是针对软件设计的最小单位––程序模块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。

集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。

系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。

验收测试：验收测试以需求阶段的《需求规格说明书》为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。

单元测试测试策略：

自顶向下的单元测试策略：比孤立单元测试的成本高很多，不是单元测试的一个好的选择。

自底向上的单元测试策略：比较合理的单元测试策略，但测试周期较长。

孤立单元测试策略：最好的单元测试策略。

集成测试的测试策略：

大爆炸集成：适应于一个维护型项目或被测试系统较小

自顶向下集成：适应于产品控制结构比较清晰和稳定；高层接口变化较小；底层接口未定义或经常可能被修改；产口控制组件具有较大的技术风险，需要尽早被验证；希望尽早能看到产品的系统功能行为。

自底向上集成：适应于底层接口比较稳定；高层接口变化比较频繁；底层组件较早被完成。

基于进度的集成

优点：具有较高的并行度；能够有效缩短项目的开发进度。

缺点：桩和驱动工作量较大；有些接口测试不充分；有些测试重复和浪费。

系统测试的测试策略：

数据和数据库完整性测试；功能测试；用户界面测试；性能评测；负载测试；强度测试；容量测试；安全性和访问控制测试；故障转移和恢复测试；配置测试；安装测试；加密测试；可用性测试；版本验证测试；文档测试

22、面向对象的测试用例设计有几种方法 如何实现？

给类中的每个构造函数设计一组测试用例 组合类中的类变量、实例变量 组合类中的各种方法

根据前置条件和后置条件设计测试用例 根据代码设计测试用例

23、在软件测试各个阶段通常完成什么工作 各个阶段的结果文件是什么 包括什么内容？

单元测试阶段：各独立单元模块在与系统地其他部分相隔离的情况下进行测试，单元测试针对每一个程序模块进行正确性校验，检查各个程序模块是否正确地实现了规定的功能。生成单元测试报告，提交缺陷报告。

集成测试阶段：集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。该阶段生成集成测试报告，提交缺陷报告。

系统测试阶段：将通过确认测试的软件，作为整个给予计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行全面的功能覆盖。该阶段需要提交测试总结和缺陷报告。

24、软件的安全性应从哪几个方面去测试？

用户认证机制：如数据证书、智能卡、双重认证、安全电子交易协议 加密机制

安全防护策略：如安全日志、入侵检测、隔离防护、漏洞扫描

数据备份与恢复手段：存储设备、存储优化、存储保护、存储管理 防病毒系统

25、LoadRunner分为哪三个模块？请简述各模块的主要功能。

Virtual User Generator：用于录制脚步

Mercury LoadRunner Controller：用于创建、运行和监控场景 Mercury LoadRunner Analysis：用于分析测试结果

第三篇：软件测试管理总结

软件测试管理总结

软件测试工程师管理系统是我接触的测试管理项目，通过近两个星期对软件测试管理的学习和实践，遇到了很多问题，觉得还是有很多经验需要总结。

随着软件开发规模的增加、复杂程度的增加，以寻找软件中的故障为目的的测试工作就

显得更加重要。因此，为了尽可能多的找出程序中的故障，开发出高质量的软件产品，必须

对测试工作进行组织策划和有效管理，采取系统的办法建立起来软件测试管理系统。在进行

测试工作识别管理的过程中，我主要做了测试计划，测试实施，测试总结这几部分工作。

一、测试计划的编写要足够清晰合理。

测试计划阶段的整体目标是为了确定测试范围、测试策略和方法，以及对可能出现的问

题和风险，所需要的各种资源和投入等进行分析和估计，以指导测试的执行。在计划中要明

确测试的目的，完善对测试人员的资源分配，设置测试的标准，责任及时间都有明确的进度

安排，指出所用工具。测试计划编写时要对照产品需求说明书，系统全面的对测试工作作出

筹划。

二、准确的填写bug记录单需进行充分的步骤记录。

在测试过程中，bug记录单不清晰，产品错误便不会容易再现。作为测试管理人员对于

问题记录单中必须包括的要素要了解。我曾经有过造成填写的问题记录单过于简练，只有结

果，没有清晰的操作步骤，没有描述产生错误的数据信息等，这些都会在测试实施过程中造

成不必要的麻烦，给开发人带来模糊理解。认识问题才能解决问题，我在以后的工作中正尽

可能避免这些问题。

三、测试结果的分析要全面公正。

测试结束后，对测试结果进行分析，以确定软件产品的质量，为产品的改进或发布提供

数据和支持。在管理上，应做好测试结果的审查和分析，做好测试报告的撰写和审查工作。

对软件测试工程师管理系统的管理工作中，我觉得还可以努力地还有，明确测试流程，注意测试流程中各阶段的注意事项，及正确填写问题记录单。及时发现测试实施工作中的各

种问题，加强与开发人员的沟通，以便及时解决问题，保证产品测试进度。

第四篇：软件外包合同

游戏应用外包合同

甲方：**公司

乙方：

甲方将软件的部分外包给乙方开发，为明确双方责任，本着相互合作、互惠互利的原则，共同协商后达成如下协议：

第一条：合同标的1、软件项目名称：

2、内容及要求：

根据甲方设计要求，乙方在规定时间内完成“”软件部分的开发。

3、开发时间：以合同签定之日起一周为限。

第二条、双方的权利义务

1、甲方的权利义务：

（1）、甲方应当提供专人与乙方联络并对乙方的开发进度及质量进行监督；

（2）、甲方应当提供软件开发所需要的所有数据交给乙方，并保证数据的正确性；

（3）、甲方应当及时支付软件开发费用，保证软件开发费用及时到位；

（4）、甲方应当依合同约定，及时检验、测试所开发的软件；

（5）、甲方享有本合同相关作品、程序、文件源码的版权及所有权；

（6）、甲方在软件符合约定时，依合同约定接受软件。

2、乙方的权利义务：

（1）、乙方有责任按甲方的要求在规定时间内完成项目开发，完成需要开发的内容；

（2）、乙方应当与甲方讨论制定软件开发计划，并按照约定，及时、正确的完成软件的开发；

（3）、乙方在其开发的范围内有为甲方提供咨询及维修的义务；

（4）、乙方不得将本软件委托或外包给他人完成；

（5）、乙方对本软件的开发及在开发过程中所获得的所有数据负有保密的义务；

（6）、乙方不得在程序中加插和软件功能无关的程序或预留一些危害软件安全的漏洞；

（7）、乙方在开发出符合合同约定的产品后有权要求甲方依合同约定支付报酬。

第三条、外包软件的交付

1、乙方应当在双方约定期限内将软件产品交付甲方；

2、乙方交付产品时需要向甲方提交如下材料：

（1）、完成甲方功能要求的可执行软件；

（2）、软件的源代码；

（3）、软件开发过程中产生的其他文档。

3、开发完毕，乙方应将软件相关的文件、源代码移交给甲方，不得将其应用在其它用途。

第四条、验收

1、开发阶段的验收：

甲方应当依开发计划在每一个开发阶段对乙方所开发的产品进行检测和验收，在不符合开发计划时，甲方有权要求乙方修改；

2、产品交付的验收标准：

a、程序正常运行；b、方案中提到的功能全部实现；c、项目按时完成；

d、文档和源代码齐全；e、软件通过审核上线。

第五条、付款

本协议采用转帐方式付款。

软件开发总费用人民币元。甲方按开发进度分两个阶段向乙方支付：

1、合同签定后，个工作日内首付合同总额的30%，金额元；

2、验收通过后，支付其余款项

3、在实施过程中，因甲方需求变更所引起的费用变更，由甲乙双方协商解决。

第六条、保密协定

1、乙方对本协议内容、项目开发成果及开发过程中涉及的文件、资料材料负有保密义务，未经甲方书面许可，不得向任何第三方泄漏；

2、乙方对甲方提供的、对本次开发有关的资料负有保密义务，未经甲方书面许可，不得

向第三方泄漏；

3、乙方有责任对甲方所开发的软件进行保密，在未经甲方书面许可的情况下，不得向第三方泄露；

4、本合同履行过程中乙方获知的另一方的商业秘密或其他技术及经营信息均负有保密义

务，不得向任何其他第三方透露或泄露；

第七条、知识产权归属

1、因本协议产生的开发成果（含源代码、系统技术文文件、软件、数据等）由甲方享有

知识产权，未经甲方书面许可，乙方不得擅自许可任何第三方阅读、使用或复制；

2、乙方保证其开发过程、开发完成的软件及相关产品不侵犯任何第三方的知识产权。

第八条、违约责任

1、如果因为甲方原因使开发无法完成，乙方有权终止开发并不退回首付款。

2、如果因为乙方原因使开发无法完成，甲方有权终止开发并要求乙方退回首付款。

3、如因不可抗力或意外事帮导致本外包合同所指向软件开发无法继续时，该合同自动

终止，违约责任由双方协商解决。

第九条、其他条款

1、本合同经双方授权代表签字，自签订日起生效；

2、本合同一式两份，双方当事人各执一份，具有同等法律效力。

甲方：乙方：

授权人：身份证号：

年月日年月日

第五篇：软件外包合同

甲方在此委托乙方进行xx软件的开发，为明确双方责任，经友好协商，双方达成以下协议：

第一条：项目的功能、平台架构、开发进度、交付方式等内容由载明。

第二条：甲方的权利和义务

1.提供专人与乙方联络。

2.提供项目所需要的所有资料交给乙方，并保证资料的正确性。

3.及时支付费用，保证项目的开发费用及时到位。

4.本合同的相关作品、程序、文件源码的版权属甲方所有。

第三条：乙方的权利和义务

1.提供专人与甲方联络。

2.按照项目进度要求及时完成系统的开发，同时保证项目质量。

3.协助甲方完成所开发系统的实施、培训以及维护。

4.开发完毕，乙方应将系统的文档、源代码移交给甲方，不得将其应用在其他企业。

5.不得将甲方开发内容泄露给第三方。

第四条：验收

1.验收标准为： a.程序正常运行；b.方案中提到的功能全部实现；c.项目按时完成；d.文档和源代码齐全

2.验收期限为2天时间。

第六条：付款方式

1.合同签订后1个工作日内，甲方向乙方支付合同总价30％的预付款。

2.试运行完毕，甲方向乙方支付合同总价70％的合同款；

第七条：维护

1.乙方应通过电话、email、现场服务等方式协助甲方的系统维护，乙方有义务及时响应和认真服务，努力确保甲方所委托开发系统的正常使用；

2.甲方需要改动或需要委托乙方进行二次开发，甲方应同乙方另订协议，作为合同的附件，另收开发费用。

第八条 违约责任

1.任何一方有证据表明对方已经、正在或将要违约，可以中止履行本合同，但应及时通知对方。若对方继续不履行、履行不当或者违反本合同，该方可以解除本合同并要求对方赔偿损失。

2.因不可抗力而无法承担责任的一方，应在不可抗力发生的3 天内，及时通知另一方。

3.一方因不可抗力确实无法承担责任，而造成损失的，不付赔偿责任。本合同所称不可抗力是指不能预见、不能克服并且不能避免的客观事件，包括但不限于自然灾害如洪水、地震、火灾和风暴等以及社会事件如战争、**、政府行为等。

第九条 其它

1.如果本合同任何条款根据现行法律被确定为无效或无法实施，本合同的其他所有条款将继续有效。此种情况下，双方将以有效的约定替换该约定，且该有效约定应尽可能接近原约定和本合同相应的精神和宗旨。

2.本合同经双方授权代表签字并盖章，自签订日起生效。

3.本合同一式两份，双方当事人各执一份，具有同等法律效力。

乙 方： 甲方

法人代表： 法人代表：

代 理 人： 代 理 人：

日 期： 年 月 日 日 期： 年 月 日

地 址： 地 址：

电 话： 电 话：

传 真： 传 真：

开户银行： 开户银行

帐 号： 帐 号：...