◆ 基本要求：
　　1.熟悉软件质量、软件测试及软件质量保证的基础知识；
　　2.掌握代码检查、走查与评审的基本方法和技术；
　　3.掌握白盒测试和黑盒测试的测试用例的设计原则和方法；
　　4.掌握单元测试和集成测试的基本策略和方法；
　　5.了解系统测试、性能测试和可靠性测试的基本概念和方法；
　　6.了解面向对象软件和WEB应用软件测试的基本概念和方法；
　　7.掌握软件测试过程管理的基本知识和管理方法；
　　8.熟悉软件测试的标准和文档；
　　9.掌握QESuite软件测试过程管理平台和QESat/C++软件分析和工具的使用方法。
　　◆ 考试内容：
　　一、软件测试的基本概念
　　1.软件质量的概念。
　　2.软件测试的目标和原则。
　　3.软件测试的心理学。
　　4.软件测试的经济学。
　　5.软件质量保证。
　　二、软件测试的类型及其在软件开发过程中的地位
　　1.软件开发阶段。
　　2.规划阶段的测试。
　　3.设计阶段的测试。
　　4.编码阶段的测试。
　　5.验收和维护阶段的测试。
　　三、代码检查、走查与评审
　　1.桌面检查。
　　2.代码走查。
　　3.代码检查。
　　4.同行评审。
　　四、覆盖率（白盒）测试
　　1.覆盖率测试。
　　2.逻辑结构的覆盖率测试。
　　3.路径覆盖率测试。
　　4.数据流测试。
　　5.程序变异测试。
　　6.基于覆盖的测试用例选择。
　　五、功能（黑盒）测试
　　1.边界值测试。
　　2.等价类测试。
　　3.基于因果图的测试。
　　4.基于决策表的测试。
　　5.基于状态图的测试。
　　6.基于场景的测试。
　　7.比较测试。
　　六、单元测试和集成测试
　　1.单元测试的目标和模型。
　　2.单元测试策略。
　　3.单元测试分析。
　　4.单元测试的测试用例设计原则。
　　5.集成测试基本概念。
　　6.集成测试策略。
　　7.集成测试分析。
　　8.集成测试用例设计原则。
　　七、系统测试
　　1.系统测试概念。
　　2.系统测试方法。
　　3.系统测试的实施。
　　八、软件性能测试和可靠性测试
　　1.软件性能的概念。
　　2.性能测试的执行。
　　3.软件可靠性的概念。
　　4.可靠性预计。
　　5.可靠性分析方法。
　　6.软件可靠性测试的执行。
　　九、面向对象软件的测试
　　1.面向对象软件测试的问题。
　　2.面向对象软件测试模型。
　　3.面向对象软件的测试策略。
　　4.面向对象软件的单元测试。
　　5.面向对象软件的集成测试。
　　6.面向对象软件的系统测试。
　　十、Web应用测试
　　1.应用服务器的分类和特征。
　　2.Web应用系统的特点。
　　3.Web应用系统的测试策略。
　　4.Web应用系统测试技术。
　　5.Web应用系统安全测试。
　　十一、其他测试
　　1.兼容性测试。
　　2.易用性测试。
　　3.GUI测试。
　　4.构件测试。
　　5.极限测试。
　　6.文档测试。
　　十二、软件测试过程和管理
　　1.软件测试过程概念。
　　2.测试组织管理。
　　3.测试计划的制定。
　　4.测试步骤的确定。
　　5.测试环境管理。
　　6.软件测试风险分析和成本管理。
　　7.测试文档管理。
　　8.测试的复用与维护。
　　十三、软件测试自动化
　　1.测试自动化的原理、方法。
　　2.测试用例自动生成。
　　3.测试执行自动化。
　　4.测试结果比较自动化。
　　5.测试工具的分类和选择。
　　6.测试工具的主流产品介绍。
　　十四、软件测试的标准和文档
　　1.软件测试的标准。
　　2.软件测试的文档。
　　十五、软件测试实践
　　1.软件测试过程管理。
　　(1)软件测试过程管理概念。
　　(2)测试的设计。
　　(3)测试的准备。
　　(4)测试的执行。
　　(5)软件问题报告和软件问题生命周期。
　　(6)测试的总结。
　　(7)QESuite软件测试过程管理平台。
　　2.白盒测试实践。
　　(1)被测程序说明。
　　(2)静态分析。
　　(3)被测程序的插装和动态测试。
　　(4)QESAT/C++白盒测试工具。

软件功能测试用例的书写方式 软件测试

　　功能性测试用例

　　1. 测试的来源，即测试的需求

　　测试用例的主要来源有：

　　1) 需求说明”及相关文档

　　2)相关的设计说明(概要设计，详细设计等)

　　3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)

　　4)已经基本成型的UI(可以有针对性地补充一些用例)

　　简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。

　　2. 用例的组织方式

　　不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。

　　用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组 织在一起。

　　在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。

　　即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

　　至于用例文件格式，可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。

　　3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题 测试用例面临的比较大的风险有：

　　需求的变更、设计的修改、需求的错误和遗漏等等。

　　由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。

　　如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个(编号的)功 能点和测试用例间的关联关系。

　　这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增 加了新的功能点。

　　重要和困难的是，不手头的资料和信息一定要是最新的。

软件测试用例的设计-提高测试覆盖率 软件测试

　　说到测试用例的设计，我想每个有过测试经历的测试工程师都会认为很简单，不就是：按需求或概要设计，得到软件功能划分图，然后据此按每个功能，采用等价类划分、临界值、因果图等方法来设计用例就行了。

　　但事实上撇开测试数据的设计不谈，仅就测试项来说，我们发现，对同一个项目，有经验的测试人员，在写用例或测试时总会有更多的测试考虑点，从而发现更多的问题;而有些测试人员测试用例的撰写却只有那么三板斧，表面看好象已经把页面所有信息的测试都考虑到了，实际上却还是遗漏了大量测试覆盖点，导致其测试出来的程序总是比较脆弱。

　　究其原因，我觉得还是测试用例的撰写水平不到位，更确切地说是测试用例的覆盖度太低。说实话我认为系统测试用例真正做到100%覆盖是很难的。难道说按设计中的功能划分，每个功能都写到了这个用例就覆盖完整了?错，这还远远不够。因为我们知道还有大量的内部处理、转换、业务逻辑、相互影响的关系等都是需求或设计中所不会点明的。而这些一方面需要靠测试人员对项目本身的了解，另一方面要靠测试人员的经验，来一一找到这些隐藏点并予以测试，才能真正地保证我们的测试覆盖度。

　　所以本文抛开具体的测试数据设计方法，主要从测试覆盖度的角度来介绍用例设计时，如何才能考虑地更周全，如何才能将隐藏的测试项一一找出，从而使我们的测试更全面更完整。

　　想法虽然美好，可是毕竟每个测试的项目都是各不相同，针对不同项目我们的经验也会告诉给我们不同的想法，这些想法通常很感性，很难用严密的逻辑理论来把它升华。因此本文的内容仍是很简陋且不成熟，只是希望能以本文为砖，引起大家的思考，一起来补充完善，以使我们的测试用例设计水平不断提高。

测试用例的切面设计

　　所谓测试切面设计，其实就是测试用例大项的划分。测试用例划分的经典方法是瀑布模型，也就是从上到下，逐渐细分，大模块包括小模块，小模块包括更小的模块。但仅仅如此是不够的，我们还要从更多的角度切入系统，从不同的角度把系统切分成一块一块的，来进行测试，从而确保测试大项的完整性。

　　1、功能点切面

　　这是最常见的切面，通常我们认为页面上的一个按钮就是一个功能点。然后我们可以根据功能的复杂程度，按每个功能;或一个功能点分多页;或多个功能点合成一页来进行用例的撰写。

　　2、特定切面

　　除此以外，还有一种特定切面的划分方法，也是用例撰写时经常会用到的。所谓的特定切面，就是忽略掉表面上的功能点，而关注测试对象的某一个面。比如我们的内部管理系统提供了销售录入导入、注册录入导入等功能，从菜单划分上对应了七八个功能点。但这些功能处理后台有个共同的处理项就是授权记录的生成，这时我们就可以把“授权记录生成”单独拿出来做一个测试项，而在其它测试项中涉及这一部分的用例就不必再一一撰写。此外象一些界面共通的操作用例单独写成一页，也是一种特定切面。所以如果说将用例按功能点划分是一种纵向划分法，那么特定切面就是从横向的角度分析所得到的切面。在普通功能点划分上再根据实际情况设计特定切面，可以使我们的用例阅读性、理解性、操作性更强。

　　3、隐含切面

　　这类用例是最容易被忽略的。它往往不是明显的某个功能项，可能是功能项后台的隐含处理，也可能是多个功能项之间的关联处理，甚至可能是在某种特定情形下的处理。这都需要测试人员通过对软件的学习了解，来进行挖掘。

　　(1)、后台功能

　　常见的如一些定时自动启动的服务;以及某种特定情况下自动执行的操作等。它们在界面上往往是不体现的，但许多在需求设计中还是会提到，也有一些比较细小的功能可能会被忽略，就需要测试人员根据对项目的了解程度来进行挖掘。所以说一个熟悉项目的和一个不熟悉的测试人员，写出来的用例就完全是两个层次的。

　　(2)、完整业务流程的测试

　　我们都知道测试用例的设计是从点、线、面三个层次去考虑的。完整的一个功能项是线，其中的某个按钮是点，多个相关功能结合成完整业务流就是面。从实际来看这类用例往往被我们忽略。

　　事实上目前公司的软件本来都是业务型应用软件，将各种功能从业务流中切割出来单独写用例，肯定也会有涉及到整体流程的情况。若不加以区分，将细节与全局搅在一起，不仅思路混乱，也容易考虑不周。因此在系统测试阶段，建议用例设计要有分有合，针对具体功能的就只围着这个功能转：而在业务流程测试项中，再完全从整体的业务流角度出发去考虑用例，这样不仅不容易产生疏漏，用例阅读与执行也更清楚。

(3)、某种特定情况下的系统运行

　　这类用例的设计往往与系统实际业务情况密不可分。比如财务软件，通常需要在月尾一天、月头一天、年尾一天、年头一天，对所有相关功能中的日期处理进行测试;又比如WIN 2000环境开发测试的系统，要测试在98、XP、2003等操作系统下是否能运行自如;再有如存在大量动态图片视频等的网页，在普通网速下的展现速度等等。总之就是要尽可能从实际应用的角度出发考虑，来进行测试补充。

　　(4)、其它相关系统

　　即指在当前项目中直接使用的其它成果，包括公司自有的系统模块、组件、函数;以及购买或免费得到的一些功能组件。对这些内容需要预先与开发组长等讨论清楚，是否需要测试。若时间紧张或其它原因决定不测的，应在测试计划中说明。若需要测试的，则具体可根据实际情况来设计，可以是通过系统某个功能的测试来涉及，此时就不需要单独划分测试项;若相对比较独立的，也可以通过单独的测试项来对其专门进行测试。

　　(5)、除功能测试外的其它测试类型

　　包括可靠性、安全性、恢复性、配置安装测试等等，这些测试类型都是一个单独的测试项。

　　所谓好的开始是成功的一半，保证测试项划分的完整、合理、正确，会直接影响到本次测试的成效。通常建议该阶段工作要花1-2天的时间来考虑，并要在测试过程中随着对软件的深入了解，不断进行调整补充。可千万不要认为把分析设计中的功能模型图搬搬过来就可以了。

做好测试计划和测试用例的工作的关键是什么? 软件测试

　　软件测试每周一问：测试的流程中，测试计划是对整个测试活动的安排，而测试用例则是测试执行的指导，但是，现在仍然有很多的测试人员没有认识到测试计划和测试用例的重要性，在项目时间比较紧张的情况下，计划和用例往往成了形式上的东西，甚至有些测试人员脱离用例，完全凭借自己的经验在执行测试活动，对此，你有什么样的看法?

　　会员godn_1981的精彩回答：

　　这个问题问的非常好，也确实是很多人有过切肤之痛的问题，对我来说，我也一直在苦苦追寻这个问题的答案，现在我不能说完全找到了，只能说把自己的心得分享一下，希望大家的测试计划和测试用例不再是一个摆设。

　　(一) 先说测试计划吧

　　诚如magic_zhu所言，现在很多测试人员没意识到测试计划的重要性，很多时候测试计划成为一纸空文，其根本原因在于测试计划缺乏可执行性，也正是因为测试计划缺乏可执行性，导致下一次写计划的时候非常草率，甚至不写，就算写了也是一个花架子应付领导，这样形成了一个恶性循环，久而久之，测试计划纯属一个摆设，我们很多从业者不写测试计划，其理由是反正写了也不能按照计划执行，这种理由真的很荒唐可笑，这是典型的因噎废食，因为你的计划执行性差就不写?这样只能使测试更加失去控制，使你的测试过程彻底无计划，无目标，变成一个放任主流的状态，完全没有受控性。这样的产品质量保证显然是空谈。

　　我觉得这个问题的解决方案不是不写，而是想办法写得更好，更有实效性，执行性。这个是问题的关键。

　　一个好的测试计划是用来计划测试的，指导整个测试过程。所以一个好的测试计划一定是可以指导测试的，就是对整个测试过程中的人力，时间，资源，策略，范围的一个说明。

　　作为一个测试计划来讲，核心的三个要素是时间，资源，范围。(这句话摘自微软的软件测试培训材料)，时间就是什么时候做以及要花多久做，资源就是你要调用的人力、机器等资源，范围是你要测试的东西以及测试重点。

　　除以上提到的3项之外，还有比较重要的项目有策略(具体就是怎么测)、风险控制(一旦有问题采取什么应急措施)等项目

要把一个计划做得很有实用性，按照笔者的经验，要注意以下几个方面：

　　a. 上面提到的三要素不能少

　　b. 测试策略一定要交待清楚，就是大概怎么测试

　　c. 需要其他人员(部门)协调的，要交待清楚

　　d. 在估计测试所需的时间、人力及其它资源时，尽量做到客观、准确、留有余地，特别是估计开发时间和debug时间，以及要对自己的执行用例速度，回归速度心里有数

　　e. 测试计划中每个阶段要明确表明，并且测试阶段的输入、输出文档要清楚

　　f. 测试计划中的时间段不宜太长(最好以day为单位)，太长就比较模糊，不好度量，不好check

　　g. 一定要有风险控制，要不然计划缺乏可执行性

　　h. 计划写完之后不是装在兜里，要组织PM和Dev进行评审

　　i. 要不断更新计划，记住：每个计划都是动态的，不是一成不变的

　　(二) 再说测试用例

　　和测试计划一样，测试用例很多时候也沦为形式，这是软件测试的可悲之处，软件测试的依据就是测试用例，如果用例弃之不用，你凭什么做好测试?这个很可笑。但是实际测试过程中很多时候测试用例并没用到实处，笔者认为还是用例实用性问题，有的时候用例洋洋洒洒数万字，到回归测试的时候根本用不上，至于如何选择回归测试用例，我曾经写过另一篇文章，欢迎查阅。

　　下面我就个人体会谈谈做好测试用例的关键。

　　首先，在做用例之前，要做两件事情。

　　第一， 透彻了解程序(需求和架构)。

　　第二， 做一个正式的测试设计(最好文档化)。然后再开始写用例。一般写用例的步骤和建房子一样，先搭框架，然后填材料，填材料的时候，主要根据需求做相关的设计，具体的设计方法就是那几种(郑老的书上写的很清楚)

　　一般来说，设计一个比较实用的测试用例，注意如下几个方面：

　　a. 选用好的用例管理工具(这个很重要，千万不要用word，excel)

　　b. 用例一定要及时更新(补充新的想法，删除过时的需求)

　　c. 做好用例分级

　　d. 做好用例评审，写用例之前可以征询相关人员的意见

　　e. 可以考虑结对编写，这个是不错的主意

　　f. 要全面，包括功能、性能、兼容性、安全性、易用性、容错性等等

　　g. 注意把握适当的颗粒度

软件测试流程之测试用例的设计与测试执行流程 软件测试

　　高效设计测试用例培训结束了，在上机练习的过程中，给他们穿插了sougo输入法的项目测试。之所以选择 sougo输入法，是因为大家对它比较熟悉，不用再熟悉其业务了。而且sougo输入法从1.0.14到现在的4.0有多个版本。每个版本更新前都会有当前版本更新的bug列表，和新增功能点列表。特别适合我们模拟实际的测试过程。这次我们测试使用TD从需求管理到缺陷管理的整个测试过程的管理。经过大家的努力和配合，我们采取边做测试边总结的方法，最后总结出测试工作中的工作流程，下面就是总结出的测试流程，大家看到后多多交流。

　　一、需求分析：

　　1、列出测试需求(根据需求规格说明书、帮助文档、软件的demo版，利用测试大纲法，以每个窗体为对象，每个窗体里面的控件为单位列出测试功能点。)

　　2、需求等级划分，依据需求内容的重要程度划分为：高、中、低等。

　　3、划分需求类型，(功能性、易用性、兼容性等)。

　　4、评审需求(软件不熟悉的情况下采取以集体的形式整体讨论的方法评审需求或设立专人负责评审)。

　　5、需求列入TestDirector(评审后的结果在TestDirector要有体现)。

　　二、用例设计：

　　1、根据功能点确定人员分工，具体的功能点分配给具体的组员。

　　2、测试用例的编写，借助功能演示demo、前一阶段所编写的测试功能点等编写测试用例。

　　3、要求组员对自己负责的功能点选择具体的设计测试用例的方法。

　　一般选择方法顺序：在考虑好被测试软件本身的特性后，一般首先边界值挑选最具有代表性的数据;然后使用等价类进一步补充;如果要考虑各功能的输入输出关系可以使用因果图、判定表法;但如果输入太多，可以使用正交排列法选择减少测试用例，并且是测试数据均匀分布。这些理性方法都使用完后，在测试执行阶段，可以使用随机测试法或者错误猜测方法进一步丰富你的测试用例。

　　4、针对所设计的用例对软件的功能点(以及其他类型的需求)进行需求覆盖。

　　我们列测试需求的最主要目的，就是为了完成对需求的覆盖，所以这个是对每一个设计测试用例的人员的基本要求。

　　5、用例评审，优化用例的数量确保用例的质量(设定专人评审)。

　　6、评审后写入TestDirector中。

　　7、挑选冒烟测试用例(抽取用例总数的10%~20%左右进行冒烟测试来反映基本功能)。

三、测试执行：

　　测试执行工作应尽量做到详细，依据测试计划里面的测试的整体安排，但是因为根据实际工作进度要做适当调整。一般情况是当天晚上前安排好明天的具体工作，具体任务可以以测试用例的数量来衡量。测试组长的几个重要工作步骤：

　　1、确认人力以及硬件资源是否到位，测试开启时间是否和测试整体计划相一致。

　　2、按照测试计划着手准备具体的测试工作。

　　3、在TD中，Test Lab里面设置以天为单位安排组员当天的应完成的用例，以及利用TD分析功能总结当天执行用例的情况。

　　4、指导组员工作，解决组员工作遇到的疑难问题

　　5、做好审查工作，监督组员工作

　　6、做好全组当天执行情况的总结

　　用例执行通过情况、发现bug数量、以及在各个模块中的分布情况等

　　7、将当天任务的执行情况书面化呈报上级领导

　　阶段任务完成后书写整个阶段的测试总结报告衡量当前版本软件的质量以及相关的发布问题。

　　四、下一版本的工作安排：

　　根据软件更新功能的多少分为两种情况：

　　1、一种是软件更新功能较少(新增加功能点是前一版本总功能的%5以内)，执行回归测试，根据新的功能点增加相关的需求和测试用例，确定新的功能点安排相关人员执行新加的测试用例;

　　2、另外一种情况是软件的新增更能点较多，则按照新的系统测试执行，首先进行冒烟测试，通过后进行详细的系统测试，测试过程中重点测试上一版本出现的缺陷(返测)、新增功能以及修改缺陷新增功能所影响到的模块。

　　新本版出现，总体按照测试执行阶段的测试工作流程进行测试同时注意特殊问题特殊处理。

　　五、提交缺陷(bug)

　　提交的缺陷需要测试部门专门人审查，通过审查后的缺陷，提交的TD中。主要审查下面几个方面：

　　1、发现的问题是否是缺陷(bug)

　　2、是否是重复的缺陷(bug)

　　3、缺陷(bug)程度的优先级是否合理

　　4、缺陷(bug)修复情况

　　看到很多有关测试流程以及测试用例设计的书籍，只是零散的测试知识，但是没有可操作性。希望上面列出的测试用例设计以及测试执行每个阶段的工作的步骤，有利于你更快更有效的进行软件测试工作。

从软件测试用例看测试的问题及变化 软件测试

　　对于一个测试人员来说测试用例的设计与编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从业务还是功能上都有一个明晰的把握。如何系统、结构的对用例加以规范将直接影响到其后的测试效率和效果，同时测试用例也将用来控制软件的整体执行覆盖，对最后的测试结果给出一种量化的评估标准。

　　一、问题：

　　许多测试类的书籍都有大幅篇章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法真正有效的提高测试效率，并且我们也没有足够的时间和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验(或习惯)，希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”，在用例设计上以前存在的问题现在依旧。

　　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

　　* 从此几乎很少被执行

　　* 已经与程序的实现发生了冲突(界面变动，功能变动)

　　* 执行用例发现的bug很少

　　* 根本没有时间为新的功能需求增补用例

　　* 有时间补充，但用例结构越来越乱

　　* 特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化)

　　知道怎样执行这个用例，但它要说明什么呢?(多数用例给我们的感觉是只见树木，不见森林，只说明某一功能的实现，无法串起)

　　通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

　　但没有用例或简略用例的编写我们又会舒服很多么?不言自明，谁也不想倒退发展。

　二、原因：

　　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

　　1、没有适合的规范

　　“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么?

　　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好?

　　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。我们有太多经验，但却没有形成适合的规范。

　　2、功能与业务的分离

　　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

　　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的bug是最多的，但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)，只能自己添加note向开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

　　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

　　3、测试未能跟上变化

　　变化!想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢?当地区特性，软件版本越来越多的时候，测试是否在积极响应呢?变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

　　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

　　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”，可能还会出现相互违背的情况，但这我们却无法及时发现。

　　永远是变化决定我们的下一步工作，这也是混乱的开始

三、可能的解决办法：

　　上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的解决办法，不拘泥形式，以结果来确定，最适合的就是最好的。

　　1、测试驱动开发，用例指导结果，数据记录变化

　　“测试驱动开发”(TDD)是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean)，“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

　　首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

　　如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起，以业务用例指导实现的结果。

　　开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很全面的指出应该实现怎样的结果，这就使得从业务到功能出现一个“阅读上的障碍”，如果最后发现程序错了还需返工，这样耗费的人力物力就非常大了。测试人员和最终用户不用过分关心软件实现的细节，所以以业务用例驱动开发，就是一个比较好的方法。给出一个明确的预期结果，指导开发人员如何界定是否达成目标，同样这也需要运用测试中的各种方法，列举出业务流程里数据的等价类和边界值。

　　业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会出错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

　　我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的)，使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个“数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

　　再进一步的话“数据库”就开始涉及到程序内部的接口，属于单元和集成测试，这需要开发人员的配合。

　　2、为用例标明时间(版本)和优先级

　　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

　　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

　　3、功能用例与业务用例分开组织

　　为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug，也许与业务无关，但用户往往很容易这样操作(例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无关，但程序将会怎样处理?)。

　　4、审核用例，结对编写

　　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例(前提是你有两个以上的测试人员)，内部审核。

　　测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理负担，提高组员的参与积极性。

　　四、发展

　　上面的这些解决方法只是一种建议，具体如何实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新问题和新苦恼，也许会比以前更为众多，这是我们必须付出的。

　　可以看到测试的发展方向很多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思考。

使用NModel自动生成测试用例 软件测试

　　在前面的网站自动化系统里面，大概聊了下如何结合Selenium生成的代码和VSTT创建一个简单的自动化系统。虽然在文章网站测试自动化系统—基于Selenium和VSTT、数据驱动测试、在测试代码中硬编码测试数据里，我讲了一些封装代码以及测试数据的技巧，规避后续开发过程中，程序员修改代码时，对测试程序带来的影响。但是每次程序员做出大的改动的时候，测试人员还是要修改大量的测试代码，更糟糕的是，每次大的改动，又涉及到测试覆盖是否足够的问题。为了规避类似的风险，以及帮助测试人员创建尽量多的测试用例，有些人提出了模型驱动测试的概念。

　　模型驱动测试的想法和飞机的风洞测试差不多，即根据功能需求说明书，对要测试的程序先建立一个模型，然后有另外一个程序分析这个模型，产生测试用例。就好比为了验证新飞机的气动布局，不可能建一个全比例的飞机，去测试它的布局是否合理;而是建立一个小的飞机模型，模型的气动布局和整机的布局是一致的。飞机模型建好以后，才放到风洞里面测试一下。

　　市面上已经有几个做模型驱动测试的工具了，这里我用的是NModel，本来想拿SpecExplorer尝一下鲜的，但最后发现这个想法太贵了—需要安装了Visual Studio 2010才能使用“免费”的SpecExplorer。你可以在这个网页里下载 NModel：

　　http://nmodel.codeplex.com/

　　在NModel中，测试人员使用C#创建程序的模型，模型创建的原理是：

　　1.程序是用来处理数据的，数据也可以称作状态(State);

　　2.用户通过程序提供的操作界面来处理数据，操作界面也可以称作动作(Action);

　　3.数据的更动 又反过来影响一些动作是否可以执行。

　　比如说，使用Word的时候，刚启动程序时是没有任何数据的，这个时候有些动作，例如“保存”是禁用的。当用户通过“新建”这个动作创建了一个新文件(数据)，这个新文件反过来激活“保存”动作。

　　因此当测试人员建模时，他要做的工作就是将程序的动作和状态抽象出来，并且描述动作和状态相互影响的过程。

　　来看一个例子，假如现在要测试一个用户登录程序，登录界面就是一个输入用户名和密码的文本框，而程序支持的用户有两种：管理员和授权用户。

先来做第一步，将动作和状态抽象出来，程序的状态应该包括：

　　1.程序状态：运行状态和未运行状态。

　　2.用户类型：管理员和授权用户。

　　3.密码：正确的密码和错误的密码。

　　4.登录状态：成功登录和登录失败。

　　动作应该包括：

　　1.登录：即用户在界面上输入用户名和密码。

　　2.注销。

　　第二步，编写C#?程序建模。

　　状态已经抽象出来了，在NModel里面，抽象出来的状态一般是用枚举值表示的。

　　MILY: 'Courier New'">public enum ModeState { Initializing, Running }

　　public enum User { Authenticated, Administrator }

　　public enum Password { Correct, Incorrect }

　　public enum LoginStatus { Success, Failure }

　　接下来模拟动作：

　　[Feature("Login")]

　　public static class Login

　　{

　　public static Map ActiveLoginRequests = Map.EmptyMap;

　　[Requirement("Send username and password to the server to log in.")]

　　[Action]

　　public static void Login_Start(User user, Password password)

　　{

　　if (password == Password.Correct)

　　ActiveLoginRequests = ActiveLoginRequests.Add(user, LoginStatus.Success);

　　else

　　ActiveLoginRequests = ActiveLoginRequests.Add(user, LoginStatus.Failure);

　　}

　　public static bool Login_StartEnabled()

　　{

　　return WebSiteModel.State == ModeState.Running;

　　}

　　public static bool Login_StartEnabled(User user)

　　{

　　return !ActiveLoginRequests.ContainsKey(user) &&

　　!WebSiteModel.UsersLoggedIn.Contains(user);

　　}

　　[Requirement("It should be possible to log out from any page")]

　　[Action]

　　public static void Logout(User user)

　　{

　　WebSiteModel.UsersLoggedIn = WebSiteModel.UsersLoggedIn.Remove(user);

　　}

　　public static bool LogoutEnabled()

　　{

　　return WebSiteModel.State == ModeState.Running;

　　}

　　public static bool LogoutEnabled(User user)

　　{

　　return WebSiteModel.UsersLoggedIn.Contains(user);

　　}

　　}

　　上面的代码稍微解释一下，标注了[Action]的函数，就是抽象出来的程序所支持的动作，例如Logout;而在动作函数名后面加上Enabled的函数，是NModel用来判定指定的动作是否可以执行，例如LogoutEnabled函数。

Feature属性，我们现在不讲，NModel用这个属性来标识一个大的功能。

　　另外要注意的是，在NModel里面，集合Set、Map是不可变的，即创建好了以后，就不能从里面删除和添加新元素了。每一次修改都会创建一个新的Set、Map实例。所以你会看到类似下面的用法：

　　ActiveLoginRequests = ActiveLoginRequests.Add(user, LoginStatus.Success);

　　最后，你需要采用一个工厂模式的方式，告诉NModel分析哪一个Feature，创建测试用例

　　public class WebSiteModel

　　{

　　public static ModeState State = ModeState.Initializing;

　　public static ModelProgram CreateLoginModel()

　　{

　　return new LibraryModelProgram(typeof(WebSiteModel).Assembly,

　　"TrainMode", new Set("Login"));

　　}

　　[Action]

　　public static void Initialize()

　　{

　　State = ModeState.Running;

　　}

　　public static bool InitializeEnabled() { return State == ModeState.Initializing; }

　　public static Set UsersLoggedIn = Set.EmptySet;

　　}

　　编译通过以后，先用NModel提供的图形化模型验证工具查看一下生成的模型是否正确。NModel自带的mpv.exe是用来验证模型的，但是 mpv.exe使用到一个图形布局程序GLEE需要单独下载，下载后，将Microsoft.GLEE.*.dll拷贝到NModel的bin文件夹里，就可以执行mpv.exe了。

　　使用下面的命令查看生成的模型：

　　"d:\Program Files\NModel\bin\mpv.exe" /r:TrainMode.dll TrainMode.WebSiteModel.CreateLoginModel

　　生成的模型应该如下图所示：

　　

　　下图是放大后的结果：

　

　　如果查看模型以后，觉得没有问题，就可以生成测试用例了，这里先生成手工的测试用例，下一篇再介绍如何生成自动化的测试用例。

"d:\Program Files\NModel\bin\otg.exe" /r:TrainMode.dll /f:scenario.txt TrainMode.WebSiteModel.CreateLoginModel

　　下面是生成的测试用例:

　　TestSuite(

　　TestCase(

　　Initialize(),

　　Login_Start(User("Authenticated"), Password("Correct")),

　　Login_Start(User("Administrator"), Password("Incorrect")),

　　Logout(User("Authenticated"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Administrator"), Password("Correct")),

　　Login_Start(User("Authenticated"), Password("Correct")),

　　Logout(User("Administrator")),

　　Logout(User("Authenticated"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Administrator"), Password("Incorrect")),

　　Login_Start(User("Authenticated"), Password("Incorrect"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Authenticated"), Password("Incorrect")),

　　Login_Start(User("Administrator"), Password("Correct")),

　　Logout(User("Administrator"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Administrator"), Password("Incorrect")),

　　Login_Start(User("Authenticated"), Password("Correct"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Administrator"), Password("Correct")),

　　Login_Start(User("Authenticated"), Password("Incorrect"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Administrator"), Password("Correct")),

　　Logout(User("Administrator")),

　　Login_Start(User("Authenticated"), Password("Correct"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Authenticated"), Password("Correct")),

　　Logout(User("Authenticated")),

　　Login_Start(User("Administrator"), Password("Correct"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Administrator"), Password("Correct")),

　　Logout(User("Administrator")),

　　Login_Start(User("Authenticated"), Password("Incorrect"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Authenticated"), Password("Correct")),

　　Login_Start(User("Administrator"), Password("Correct")),

　　Logout(User("Authenticated")),

　　Logout(User("Administrator"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Authenticated"), Password("Incorrect")),

　　Login_Start(User("Administrator"), Password("Incorrect"))

　　),

　　TestCase(

　　Initialize(),

　　Login_Start(User("Authenticated"), Password("Correct")),

　　Logout(User("Authenticated")),

　　Login_Start(User("Administrator"), Password("Incorrect"))

　　)

　　)

LoadRunner中参数化中参数迭代规则详解

　　Each Occurrence

　　每次遇到参数就进行更新。

　　多次使用同一参数，而且没有什么关联，例如随机数。

　　Each Iteration

　　每次迭代时发生更新。 如果参数出现几次，虚拟用户用同一个数值。

　　适用同一个关联的参数。

　　Once

　　所有的地方都用同一个数值，包括所以的迭代。

　　文件类型参数分派方法

　　Sequential

　　按照顺序访问。

MILY: StoneSerif; FONT-SIZE: 12pt" lang=EN-US>	更新方式	Sequential	例子
1.	Each Iteration	所有用户每次迭代同时取下一个数值。	All the Vusers use Kim in the first iteration, David in the second iteration, Michael inthe third iteration, etc.
2.	Each Occurrence	所有用户每次遇到同时取下一个数值，即使在同一个迭代。	All the Vusers use Kim in the first occurrence, David in the second occurrence,Michael in the third occurrence, etc.
3.	Once	所有用户第一次迭代时同时取第一个值，该用户所有的子迭代值不变。	If you specified Once, all Vusers take Kim for all iterations.

First Name

Kim

David

Michael

Jane

Ron

Alice

Ken

Julie

　　没有足够的值，从第一行开始重新取值。

Random：每个虚拟用户开始运行时安排随机的数值。

	更新方式	Random
1.	Each Iteration	每次迭代时，随机从数据表中取数。
2.	Each Occurrence	每次遇到随机取一个数值，即使在同一个迭代。
3.	Once	第一次迭代时随机取值，改用户所有的子迭代值不变。

　　Unique

　　The Unique method assigns a unique sequential value to the parameter for

　　each Vuser.

	更新方式	Unique	例子
1.	Each Iteration	每个用户每次迭代时，虚拟用户取下一个不同的数值。	If you specified Each Iteration, for a test run of 3 iterations, the first Vuser takes Kim in the first iteration,David in the second, and Michael in the third. The second Vuser takes Jane, Ron, and Alice. The third Vuser,Ken, Julie, and Fred.
2.	Each Occurrence	每个虚拟用户每次遇到取一个新的不同的数值，即使在同一个迭代。	lr自己决定。
3.	Once	每个第一次迭代时取不同值，该用户所有的子迭代值不变。	If you specified Once, the first Vuser takes Kim for all iterations the second Vuser takes David for all iterations, etc.

　　数据必须足够，例如20个虚拟用户，5次迭代，至少要有100个数据。

性能测试工具Loadrunner中日志参数的设置与使用

　　一、Run-Time Setting日志参数的设置

　　在loadrunner 的vuser菜单下的Run-Time Setting的General的LOG选项中可以对在执行脚本时Loadrunner对日志 的操作行为进行定义，下面我们在逐一介绍：

　　1、 Enable logging启用日志记录

　　如果选中该选项Loadrunner在执行脚本时，进行日志的记录，否则不记录日志

　　2、 Send messages only when an error occurs 仅在出错时发送消息

　　也称为 JIT (实时)消息传递，仅当错误发生时才写入日志，选择该选项后则可以设置高级选项，指明日志缓存的大小，loadrunner默认的日志到小为1k

　　3、 Always send messages

　　始终发送消息

　　4、 Standard log

　　标准日志：创建在脚本执行期间发送的函数和消息的标准日志，供调试时使用。

　　对于大型负载测试 场景、优化会话或配置文件禁用此选项。

　　如果日志记录级别设置为“标准”，当把脚本添加到场景、会话步骤或配置文件

　　中时，日志记录模式将被自动设置为“Send messages only when an error occurs”。但是，如果日志记录模式被禁用或者设置为“扩展”，则将脚本添加到场景、会话步骤或配置文件中将不会影响其日志记录设置。

　　5、 Extended log-----Parameter substitution

　　参数替换：选择此选项可以记录指定给脚本的所有参数及其相应的值

　　当脚本进行参数化、插入事务、关联等优化后，在执行脚本过程中，参数化的值、事务所耗时间、关联函数取出的变量值均会在日志中输出，这个选项对调试脚本查看参数化取值、关联取值是否正确有着重要的作用

　　6、 Extended log-----Data returned by server

　　选择此选项可以记录服务器返回的所有数据。

　　Loadrunner会将所有对服务器发出请求后的response情况记录在日志中，从这个日志中可以查看到服务器对请求的回应是否正确，在使用关联取值时往往需要到该日志中查看需要关联的值，从而确认所取数据左右边界。

7、 Extended log-----Advanced trace 高级跟踪

　　选择此选项可以记录 Vuser 在会话期间发送的所有函数和消息。

　　调试 Vuser 脚本时，该选项非常有用。

　　二、日志函数的使用

　　Loadrunner提供了一下几个message函数：

　　1、lr_message

　　int lr_message (const char * format, exp1, exp2,...expn.);

　　中文解释：lr_message函数将信息发送到日志文件和输入窗口。在VuGen中运行时，输入文件为output.txt。

　　例如：

　　char* abort="aborting";

　　lr_message ("login failed: %s", abort);

　　在日志中将会看到:login failed: aborting

　　2、lr_log_message

　　int lr_log_message (const char * format, exp1, exp2,...expn.);

　　中文解释：lr_log_message函数将消息发送到Vuser或代理日志文件(取决于应用程序)，而不是发送到输出窗口。通过向日志文件发送错误消息或其他 信息性消息，可以将该函数用于调试。

　　3、lr_error_message

　　int lr_error_message (const char *format, exp1, exp2,...expn. );

　　中文解释：lr_error_message函数将错误消息发送到输出窗口和Vuser日志文件。

　　如果Run-time settings > General > Miscellaneous >Continue on error未被选中，当脚本执行到此处时将终止执行，这个函数所输出的错误级别较高的信息，所以一般情况下如果使用该函数时选中Continue on error

　　4、lr_output_message

Loadrunner中若干message函数的使用方法详解

　　Loadrunner提供了若干message函数，以在脚本回放中和脚本运行中，对外输入信息，主要的函数有：

　　【lr_message】

　　int lr_message (const char *format, exp1, exp2,...expn.);

　　中文解释：lr_message函数将信息发送到日志文件和输入窗口。在VuGen中运行时，输入文件为output.txt。

　　【lr_log_message】

　　int lr_log_message (const char *format, exp1, exp2,...expn.);

　　中文解释：lr_log_message函数将消息发送到Vuser或代理日志文件(取决于应用程序)，而不是发送到输出窗口。通过向日志文件

　　发送错误消息或其他信息性消息，可以将该函数用于调试。

　　【lr_error_message】

　　int lr_error_message (const char *format, exp1, exp2,...expn. );

　　中文解释：lr_error_message函数将错误消息发送到输出窗口和Vuser日志文件。要发送不是特定错误消息的特殊通知，请使用lr_output_message。

　　【lr_output_message】

　　int lr_output_message (const char *format, exp1, exp2,...expn.);

　　中文解释：lr_output_message函数将带有脚本部分的行号的消息发送到输出窗口和日志文件。

　　【lr_vuser_status_message】

　　int lr_vuser_status_message (const char *format);

　　中文解释：lr_vuser_status_message函数向控制器或优化模块控制台的vuser窗口的“状态”区域发送字符串。它还将该字符串发送

　　到vuser日志。从VuGen运行时，消息被发送到output.txt。

如何在LoadRunner中监控oracle数据库

　　环境相关信息概述：

　　LoadRunner 9.0

　　Sitescope 9.0

　　Windows 2003

　　Oracle database 10g

　　1. 使用LR自带的监控引擎

　　1.1.在LR的controller上安装oracle客户端

　　这一步就不用说了，安装直接Setup，安装就OK了。

　　1，安装完后，先配置一下Net Configuration Assistant。记住配置的服务名。

　　配置成功会显示：正在连接...测试成功。

　　2，用sqlplus连接一下，看是否可以连接成功，打开sqlplus输入oracle用户名密码和主机字符串。

　　查看是否登录成功

1.2.添加oracle计数器

　　3，登录成功后，打开LR的controller.，在可用图中选择oracle，点击add measurements,再点击Advanced，如下所示：

　　

　　这里我们用LR native monitors。

　　4，在Monitored Server Machines区域，添加oracle服务器所在的IP。

　　5，再在Resource Measurements on:IP区域点击添加，弹出对话框如下：

　　

　　6，输入相应的信息，这里的orcl就是前面在Net Configuration Assistant配置的服务名。

　　7，点击OK，这里我们应该可以看到可以添加oracle的计数器了，如下所示：

　　

　　2. 使用Sitescope引擎

不需要配置Net Configuration Assistant。

　　1，在第一个图choose monitor engine中选择sitescope，然后在在Monitored Server Machines区域点击Add如下所示：

　　

　　在这里可以选择本地或者其他机器的sitescope，如果sitescope启用了account的验证，也要写上相应的用户名密码。

　　2，在Resource Measurements on:IP区域点击添加，弹出对话框如下：

　　

　　3，输入信息如图。点击OK，如下：　　

　　至此就可以监控oracle了。

软件测试工作量估算之功能点估算法

　　从上个世纪70年代开始，一些软件企业就开始引入“功能点分析算法”，来评估软件功能的规模，然后便可以对软件开发的成本和工期，进行精确的度量，也可以对开发团队的生产率进行考核评估。半个世纪以来，很多种不同的功能点算法模型被建立起来，Mk II功能点算法是其中一种比较常用的模型。

　　随着淘宝网站的高速发展，淘宝开发团队规模也不断增大，于是必然要面对管理问题。人数的增多必然带来管理层级的增多，这样很容易出现管理结构的臃肿，管理成本增高。如果我们引入一种简单而且科学的工作度量模型，让每个人每个团队的工作质量和效率用数字来说话，便可以促进管理结构的扁平，简化管理过程，每个管理者可以管理更多的人，并且对下属的工作了如指掌。

　　功能点算法就是为了解决如何度量工作效率的问题，而工作质量主要是依靠分析各种Bug数据，我们在别的文章里讨论。

　　首先我们讲一下MVC模型，这是目前WEB开发的一种非常流行的软件架构模式。它把WEB应用程序定义为3个部分，每个部分负责完成特定的任务：

　　Model 模型

　　View 视图

　　Controller 控制器

　　Model主要与数据库交互，把数据表转换成对象，并且实现基本的数据读写逻辑，比如在淘宝网，商品就是一个Model。View负责实现界面的设计，我们浏览网页看到的WEB界面控件，比如按钮、文本框、GRID都是在View中定义的，设计View主要是用Html和JS。用户在View层进行的各种操作(比如点击按钮)，就会启动Controller里的函数，主要的业务逻辑代码，都写在Controller里了，其实也就是对各种Model进行增删改查，比如购买一个商品。

　　关于MVC的更多详细说明请参考维基百科。

　　接下来我们介绍MkII功能点算法，淘宝测试选择MkII的主要原因是，它的算法和MVC模式非常的吻合，可以说是黄金搭档。

　　MkII功能点算法是这样：先要给各个功能模块划分逻辑事务，然后针对每个逻辑事务，分析输入DET(Data Element Type)和输出DET的数量，以及关联的实体类型数量，再根据一个算法公式，计算出功能点指数：

　　功能点=输入DET×0.58+实体类型×1.66+输出DET×0.26

　　逻辑事务指用户在WEB应用程序中的原子操作。很多开发团队都会设计UseCase，一般来说一个UC对应一个逻辑事务。注意：逻辑事务一定是记录用户行为的，而不是程序内部的处理逻辑。不过在实际的分析中，我们发现逻辑事务的个数，往往要大于UC的个数，这是正常的，主要因为很多UC包含的信息很多。

　我们用淘宝的“购买商品”来举例说明怎么划分逻辑事务，先来看购买商品的页面：

　　

　　在这个页面中，左边一块是显示商品的简要信息，这是一个逻辑事务：“查看商品信息”，右边最上面一个收货地址的radio button，也是一个：“展示我所有的收货地址”，右边下面一组文本输入框加一个按钮，是一个：“为当前商品创建一个订单”。

　　在MVC中，逻辑事务对应Controller，每个逻辑事务都可以在Controller里面找到一个public函数。

　　再讲一下输入DET和输出DET。比如刚才的“为当前商品创建一个订单”这个事务，页面上输入信息的控件，都是输入DET，比如文本框、按钮，都是输入DET。这个事务大约有10个输入DET：“收货地址”、“购买数量”、“运送方式”等等。输出DET指应用程序给用户提供的所有的提示信息，以文字提示的方式知会用户。比如“购买成功”、“您没有绑定支付宝，不能购买”、“商品库存不足，无法购买”、“购买数量必须输入整数”等等。这个事务的输出DET数量大约是20个。

　　在MVC中，输入DET和输出DET对应View。每个输入DET和输出DET都能在View中找到对应控件。

　　最后讲引用实体，在创建订单事务里，引用的实体有很多。订单成功后要扣减商品库存，因此商品算1个;订单本身是1个;订单需要同步生成支付宝交易，支付宝算1个;还有物流记录算1个，等等，大约是5个实体以上。

　　在MVC中，引用实体对应Model。

　　到此为止这个逻辑事务的数据收集完整，代入公式计算得出结果：

　　10×0.58+5×1.66+20×0.26=19.3

　　当然这只是一个DEMO，数字都是估算的，实际情况肯定比这个要复杂，算出的功能点指数就会多一些。需要注意的是，使用MkII算法计算出的功能点指数，只是一个数值，代表应用程序的功能规模，和我们平时听到开发说的“我修改了一个功能点”，概念上是不同的。所以我们用“功能点指数”这个概念，不过为了沟通起来方便，还是简化成“功能点”了。

　　MkII功能点算法是非常适合于淘宝这样的互联网公司的。不过由于WEB应用程序的交互日趋复杂，JS被大量使用，因此在实践中，如何划分逻辑事务，如何统计输入输出，还需要进一步的研究。

软件功能测试用例的书写方式 软件测试

　　功能性测试用例

　　1. 测试的来源，即测试的需求

　　测试用例的主要来源有：

　　1) 需求说明”及相关文档

　　2)相关的设计说明(概要设计，详细设计等)

　　3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)

　　4)已经基本成型的UI(可以有针对性地补充一些用例)

　　简而言之，所有你能得到的项目文档，都尽量拿到。 从所得到的资料中，分解出若干小的“功能点”，理解“功能点”，编写相应的测试用例。

　　2. 用例的组织方式

　　不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。

　　用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例，可以另外组 织在一起。

　　在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失败”——这样加上“未 执行”的用例的状态，共3种状态。

　　即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。

　　至于用例文件格式，可以是.DOC或.XLS(如果有专门的测试用例管理工具另当别论)。

　　3. 用例与其他材料的关联方式，即如何解决用例跟踪的问题 测试用例面临的比较大的风险有：

　　需求的变更、设计的修改、需求的错误和遗漏等等。

　　由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需求和设计的 变更势必引起测试用例的变更。

　　如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各个(编号的)功 能点和测试用例间的关联关系。

　　这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增 加了新的功能点。

　　重要和困难的是，不手头的资料和信息一定要是最新的。

　　4. 一个好的用例的表述要点，即用例中应当包含的信息

软件测试流程之测试用例的设计与测试执行流程 软件测试

　　高效设计测试用例培训结束了，在上机练习的过程中，给他们穿插了sougo输入法的项目测试。之所以选择 sougo输入法，是因为大家对它比较熟悉，不用再熟悉其业务了。而且sougo输入法从1.0.14到现在的4.0有多个版本。每个版本更新前都会有当前版本更新的bug列表，和新增功能点列表。特别适合我们模拟实际的测试过程。这次我们测试使用TD从需求管理到缺陷管理的整个测试过程的管理。经过大家的努力和配合，我们采取边做测试边总结的方法，最后总结出测试工作中的工作流程，下面就是总结出的测试流程，大家看到后多多交流。

　　一、需求分析：

　　1、列出测试需求(根据需求规格说明书、帮助文档、软件的demo版，利用测试大纲法，以每个窗体为对象，每个窗体里面的控件为单位列出测试功能点。)

　　2、需求等级划分，依据需求内容的重要程度划分为：高、中、低等。

　　3、划分需求类型，(功能性、易用性、兼容性等)。

　　4、评审需求(软件不熟悉的情况下采取以集体的形式整体讨论的方法评审需求或设立专人负责评审)。

　　5、需求列入TestDirector(评审后的结果在TestDirector要有体现)。

　　二、用例设计：

　　1、根据功能点确定人员分工，具体的功能点分配给具体的组员。

　　2、测试用例的编写，借助功能演示demo、前一阶段所编写的测试功能点等编写测试用例。

　　3、要求组员对自己负责的功能点选择具体的设计测试用例的方法。

　　一般选择方法顺序：在考虑好被测试软件本身的特性后，一般首先边界值挑选最具有代表性的数据;然后使用等价类进一步补充;如果要考虑各功能的输入输出关系可以使用因果图、判定表法;但如果输入太多，可以使用正交排列法选择减少测试用例，并且是测试数据均匀分布。这些理性方法都使用完后，在测试执行阶段，可以使用随机测试法或者错误猜测方法进一步丰富你的测试用例。

　　4、针对所设计的用例对软件的功能点(以及其他类型的需求)进行需求覆盖。

　　我们列测试需求的最主要目的，就是为了完成对需求的覆盖，所以这个是对每一个设计测试用例的人员的基本要求。

　　5、用例评审，优化用例的数量确保用例的质量(设定专人评审)。

　　6、评审后写入TestDirector中。

　　7、挑选冒烟测试用例(抽取用例总数的10%~20%左右进行冒烟测试来反映基本功能)。

三、测试执行：

　　测试执行工作应尽量做到详细，依据测试计划里面的测试的整体安排，但是因为根据实际工作进度要做适当调整。一般情况是当天晚上前安排好明天的具体工作，具体任务可以以测试用例的数量来衡量。测试组长的几个重要工作步骤：

　　1、确认人力以及硬件资源是否到位，测试开启时间是否和测试整体计划相一致。

　　2、按照测试计划着手准备具体的测试工作。

　　3、在TD中，Test Lab里面设置以天为单位安排组员当天的应完成的用例，以及利用TD分析功能总结当天执行用例的情况。

　　4、指导组员工作，解决组员工作遇到的疑难问题

　　5、做好审查工作，监督组员工作

　　6、做好全组当天执行情况的总结

　　用例执行通过情况、发现bug数量、以及在各个模块中的分布情况等

　　7、将当天任务的执行情况书面化呈报上级领导

　　阶段任务完成后书写整个阶段的测试总结报告衡量当前版本软件的质量以及相关的发布问题。

　　四、下一版本的工作安排：

　　根据软件更新功能的多少分为两种情况：

　　1、一种是软件更新功能较少(新增加功能点是前一版本总功能的%5以内)，执行回归测试，根据新的功能点增加相关的需求和测试用例，确定新的功能点安排相关人员执行新加的测试用例;

　　2、另外一种情况是软件的新增更能点较多，则按照新的系统测试执行，首先进行冒烟测试，通过后进行详细的系统测试，测试过程中重点测试上一版本出现的缺陷(返测)、新增功能以及修改缺陷新增功能所影响到的模块。

　　新本版出现，总体按照测试执行阶段的测试工作流程进行测试同时注意特殊问题特殊处理。

　　五、提交缺陷(bug)

　　提交的缺陷需要测试部门专门人审查，通过审查后的缺陷，提交的TD中。主要审查下面几个方面：

　　1、发现的问题是否是缺陷(bug)

　　2、是否是重复的缺陷(bug)

　　3、缺陷(bug)程度的优先级是否合理

　　4、缺陷(bug)修复情况

　　看到很多有关测试流程以及测试用例设计的书籍，只是零散的测试知识，但是没有可操作性。希望上面列出的测试用例设计以及测试执行每个阶段的工作的步骤，有利于你更快更有效的进行软件测试工作。

2010年软考软件评测师考试时间为11月13日举行。离考试还有将近16天的时间，为了让广大考生顺利的通过考试，考试吧特整理了软考软件评测师冲刺资料，帮助考生做最后的冲刺。预祝各位考生顺利通过考生。

考前须知

知识点突破

历年真题

学习方法与答题技巧

　第一步：考前须知

　　2010年下半年全国计算机软考软件评测师考试时间：11月13日

　　1、 考试用具早早准备：考试前当晚准备好两支2B的铅笔，检查准考证、身份证等是否全部备齐，避免第二天早上慌慌张张。

　　2、 晚上早入睡：考场上的正常发挥，与考试前晚上的休息有关。晚上早点睡觉、不要熬夜看书，以免第2天考试的时候无精打采。

　　3、 白天早起提前到考场：掌握好考试时间。第2天早点起来，打的去考场，以免路上颠簸，一年也就两次考试，打的吧，图个愉快轻松的心情，同时，早点出发避免塞车。早到后，在考场附近解决早餐问题。少喝水，早餐后上厕所，考试时想上厕所是一件非常痛苦的事情。

　第二步：知识点突破

　　在考试之前，考生可以通过通读资料，并且梳理记忆考点全面突破。

2010软件水平考试软件评测师考前复习资料汇总
序号	资料	查看
1	2010年软件水平考试软件测评师自动化测试汇总	查看
2	2010年软考软件测评师软件测试文档及图表汇总	查看
3	2010年软考软件评测师测试术语及名词解释汇总	查看
4	2010年软考软件评测师测试工作管理与规范汇总	查看
5	2010软考软件评测师软件测试流程及步骤汇总	查看
6	2010软考软件评测师软件测试的分类及方法汇总	查看
7	2010软考软件测试中面临的问题及解决办法汇总	查看

　第三步：历年真题

　　历年真题往往是出题的蓝本，历年真题能直接的体现出题人的思路和重点，所以考生要把历年真题吃透。为了方便考生查找资料，考试吧特整理了以下历年真题，考生还可以到考试吧模拟考场用真题自我检验：

软考嵌入式系统设计历年真题汇总(2007年-2010年)
年份	上午题	上午题
2010(上半年)	上午试题　　答案	下午试题　　答案
2009(下半年)	上午试题　　答案	下午试题　　答案
2009(上半年)	上午试题　　答案	下午试题　　答案
2008(下半年)	上午试题	下午试题
2008(上半年)	上午试题	下午试题
2007(上半年)	上午试题	下午试题

　第四步：学习方法与答题技巧

　　软件评测师考试有什么特点？如何备考才能拿到高分？往年考生有哪些成功经验？为了帮助考生提高复习效率，考试吧特别整理汇总了以下学习方法：

　　　这次考试通过了软件评测师考试，为了给后来人帮助，特说说我的复习方法。

　　教新手怎么入手软件测试

　　当你刚踏入测试团队的时候，你可能无从下手。拿来软件就是一顿乱点。其实要做一个好的测试人员。一定要有一份好的计划。所以测试计划就是测试的开始......详情

　　　拿到试题，仔细看题，不要匆忙做答，尤其是有论文的，先要酝酿好，但是时间也要把握好。答题卡一定要边答边填涂，不要等到最后一起涂!万一没时间了，上午题就没分了!不会的问题不要总是在想，只需要在卷上做个记号，如果有时间的话再回头看!不要因为捡芝麻而丢西瓜!........详情

　　考试吧预祝各位考试顺利通过2010年软考软件评测师考试。

测试用例设计方法

　　白盒测试基本技术：控制流图、代码覆盖率分析(Code Coverage Analysis)。

　　白盒测试方法：从总体上可划分为静态测试和动态测试;按测试操作的实施方式划分为手工测试和借助于工具的自动化测试等。

　　白盒测试的静态测试方法：代码检查法、静态结构分析法、代码质量度量法等。

　　白盒测试的动态测试方法：功能确认与接口测试、逻辑覆盖分析法、基本路径测试法、性能分析、内存分析等。

　　动态测试通常在静态测试之后进行。

　　其他白盒测试方法：域测试(Domain Testing)、程序变异测试、符号测试、数据流测试、Z路径测试。

　　常用的黑盒测试用例设计方法有：等价类划分法、边值分析法、错误猜测法、因果图方法等，其他的一些测试方法还有判定表驱动法、正交试验法、功能图法，以及场景法等。

　　面向对象测试关注于设计合适的操作序列以测试类的状态。

　　测试用例设计方法的主要原则包括：

　　(1)对每个测试用例应当给予特殊的标识，并且还应当与测试的类有明确的联系。

　　(2)测试目的应当明确。

　　应当为每个测试用例开发一个测试步骤列表。这个列表应包括以下一些内容：

　　(1)列出所要测试的对象的专门说明;

　　(2)列出将要作为测试结果运行的消息和操作;

　　(3)列出测试对象可能发生的例外情况;

　　(4)列出外部条件;

　　(5)列出为了帮助理解和实现测试所需要的附加信息。

软件自动化测试

　　自动化测试可以帮助测试人员做到：(1)提高测试执行的速度;(2)提高运行效率;(3)保证测试结果的准确性;(4)连续运行测试脚本;(5)模拟现实环境下受约束的情况。

　　自动化测试不能做到的是：(1)所有测试活动都可以自动完成;(2)减少人力成本;(3)毫无成本的得到;(4)降低测试的工作量。

面向对象软件的测试

　　面向对象技术主要包括6个核心概念：对象、消息、接口、类、继承、多态。

　　面向对象的开发模型实质是将软件测试过程分成3个阶段，即面向对象分析(OOA)、面向对象设计(OOD)和面向对象编程(OOP)。

　　面向对象测试的类型分为：面向对象分析的测试(OOA Test)、面向对象设计的测试(OOD Test)、面向对象编程的测试(OOP Test)、面向对象单元测试(OO Unit Test)、面向对象集成测试(OO Integration Test)、面向对象系统测试(OO System Test)。

　　面向对象测试类型的另一种划分：模型测试、类测试(用于代替单元测试)、交互测试(用于代替集成测试)、系统(包括子系统)测试、接收测试、部署测试。

　　传统测试模式与面向对象的测试模式的最主要的区别在于，面向对象的测试更关注对象而不是完成输入/输出的单一功能，这样的话测试可以在分析与设计阶段就先行介入，便得测试更好的配合软件生产过程并为之服务。与传统测试模式相比，面向对象测试的优点在于：更早地定义出测试用例;早期介入可以降低成本;尽早的编写系统测试用例以便于开发人员与测试人员对系统需求的理解保持一致;面向对象的测试模式更注重于软件的实质。

　　面向对象测试的过程：(1)指定范围;(2)指定深度;(3)指定已创建的被测试模块的基本要求(上一个阶段需要提供的接口);(4)以基本模型的内容为输入来设计测试用例作为评估标准;(5)生成测试覆盖度量标准;(6)试用测试清单执行静态分析，确保被测模块与基本模型的一致性;(7)执行测试用例;(8)如果覆盖不足以检测所有的活动，就需要分解测试工作，并且使用传统测试用例的方式来警醒，或者中断测试，重新测试传统测试用例。

Web应用测试

　　Web应用测试类型：功能测试、性能测试、可用性测试、兼容性测试和安全测试。

　　根据测试对象的不同，Web功能测试又分为链接测试、表单测试、Cookies测试、设计语言测试、数据库测试。

　　Web性能测试是要是确保Web应用系统达到要求的性能，一般用最大运行时间、吞吐率、响应时间描述。Web应用在极端条件下的性能测试又分为负载测试和压力测试。负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统的在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数据，也可以是在线数据处理的数量。压力测试是指实际破坏一个Web应用系统时测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。压力测试侧重于确定系统崩溃时的用户负载量。压力测试的区域包括表单、登录和其它信息传输页面等。

　　Web性能测试：(1)连接速度测试;(2)负载测试;(3)压力测试。

　　Web可用性测试：(1)导航测试;(2)图形测试;(3)内容测试;(4)整体界面测试。

　　Web兼容性测试：(1)平台测试;(2)浏览器测试。

　　Web安装性测试，就是测试Web应用防止未授权用户访问或故意破坏等情况下的能力，其重点是测试SSL(安全套接字)配置、登录模块、事务完整性等方面。

网络测试

　　网络性能测试的主要依据是：(1)双方在规划设计阶段共同认可的网络性能指标;(2)有关的国家标准或行业标准。

　　网络性能测试的具体内容应以网络设计方案为准，但一般包括以下内容：

　　(1)网络容量测试：最大容量和有效容量;

　　(2)网络响应时间测试：检测网络系统完成一系列任务所需的时间;

　　(3)网络可靠性测试;

　　(4)网络吞吐量测试;

　　(5)网络配置规模测试;

　　(6)网络瓶颈测试;

　　(7)衰减测试。

　　网络性能测试分类：(1)网络可接受性测试;(2)网络升级测试;(3)网络设备评估测试。

　　网络性能测试的对象：(1)路由器、集线器、交换机和网桥;(2)网段;(3)全局网;(4)网络操作系统;(5)文件服务器;(6)工作站。

　　网络应用测试的主要内容：(1)性能测试;(2)功能测试;(3)网络应用负载测试;(4)应用系统响应时间测试;(5)应用系统升级测试。

安全测试

　　软件安全性是与防止对程序和数据的非授权的故意或意外访问的能力相关的软件产品属性。软件安全性的测试包括程序和数据安全性的测试。

　　安全测试内容：用户认证机制、加密机制、安全防护策略、数据备份与恢复、防病毒系统。

　　安全测试策略：

　　(1)安全防护体系：实体安全、平台安全、数据安全、应用安全、通信安全、运行安全、组织安全、管理安全。

　　(2)安全保护国家标准：用户自主保护级、系统审计保护级、安全标记保护级、结构化保护级、安全域级保护级。

　　为保证实体、数据、平台、应用、运行等的安全，主要采用以下几种安全防护技术：防火墙、入侵检测系统、漏洞扫描、安全审计、病毒防治、Web信息防篡改。

　　安全测试方法：

　　主动发现方法：功能验证、漏洞扫描、模拟功能、侦听技术。

兼容性测试

　　硬件兼容性测试：主机兼容性测试;板卡、配件及外设的兼容性测试。

　　配置指标主要包括对CPU、内存和硬盘的要求。

　　推荐配置就保证软硬件构成的系统在正常业务的压力负载下，CPU资源占用率平均值不超过75%。

　　软件兼容性测试：操作系统兼容性测试、数据库兼容性测试、中间件兼容性测试、与其他软件的兼容性测试。

　　数据兼容性测试：编码体系测试、数据标准符合性测试。

　　新旧系统数据迁移测试：迁移准备、迁移实施、迁移验证。

　　平台软件兼容性测试：平台软件硬件、软件、数据库、文种兼容性测试。

易用性测试

　　在2003年颁布的GB/T16260-2003(ISO 9126-2001)《软件工程 产品质量》质量模型中，提出易用性包含易理解性、易学习性和易操作性;即易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。

　　(1)易理解性;(2)易学习性;(3)易操作性;(4)吸引性;(5)依从性。

　　易用性测试包括针对应用程序的测试，同时还包括对用户手册系统文档的测试。通常采用质量外部模型来评价易用性。包括如下方面的测试：(1)易理解性测试;(2)易学性测试;(3)易操作性测试;(4)吸引性测试;(5)易用的依从性测试。

　　易用性测试方法有：静态测试;动态测试;动态和静态结合测试。

　　软件质量模型将质量属性划分为6种特性：功能性、可靠性、易用性、效率、维护性和可移植性。

　　易用性与可靠性是正相关的;易用性与安全性(功能性的子特性)的某些方面是负相关的。

　　安装测试的主要工作(安装的易用性)：(1)安装手册的评估;(2)安装的自动化程度测试;(3)安装选项和设置的测试;(4)安装过程的中断测试;(5)安装顺序测试;(6)多环境安装测试;(7)安装的正确性测试;(8)修复安装测试和卸载测试。

　　功能易用性测试：(1)业务符合性;(2)功能定制性;(3)业务模块的集成度;(4)约束性;(5)交互性;(6)系统信息与错误提示。

　　界面整体测试指对界面的规范性、一致性、合理性等进行测试和评估。

文档测试

　　国家有关计算机软件产品开发文件编制指南()****有14种文件，可分为3大类。

　　1. 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

　　2. 用户文件：用户手册、操作手册。

　　3. 管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

　　用户文档分类：联机帮助;样例、示例和模板;包装;宣传与广告;其他。

　　用户文档的作用：改善易安装性;改善软件的易学性与易用性;改善软件可靠性;降低技术支持成本。

　　用户文档测试方法：技术校对;功能测试;其他辅助方式。

　　用户文档测试要点：文档的读者群;文档的术语;文档的正确性;文档的完整性;文档的一致性;文档的易用性;样例与示例;文档的语言;印刷与包装质量。

　　用户手册、操作手册的测试：“严格”地使用系统;“随心所欲”地使用系统;尝试文档中的每个建议和注意事项;描述的准确性;从用户角度看手册。

　　联机帮助的测试：准确性、用户的查询;帮助主题的完整性;帮助的风格。

测试项目管理

　　软件配置管理的作用：

　　通过软件配置管理，严格执行软件开发过程控制，使软件开发的各个过程阶段()置于软件配置管理控制之下，真实地记录软件生命周期内的全部过程活动，使软件开发从无形变成有形，从无法管理变成有章可循。

　　通过软件配置管理，严格执行软件版本控制()，做到完整保存各种历史软件，有利于验证和比较测试、联试中出现的问题;严格执行软件更改控制，严格审批更动过程。

　　配置管理内容：确立基线;建立3库(开发库、受控库、产品库);出入库管理和审计;状态报告和查询。

　　测试管理组包括评审小组、测试小组和支持小组。

　　软件测试过程分成4个阶段：单元测试、集成测试、系统测试和验收测试。

　　软件测试文档描述要执行的软件测试及测试的结果。

　　测试文件的类型：测试计划和测试分析报告。

　　测试文件的重要性表现在：(1)验证需求的正确性;(2)检验测试资源;(3)明确任务的风险;(4)生成测试用例;(5)评价测试结果;(6)再测试;(7)决定测试的有效性。

　　软件工程领域要考虑的风险类型：(1)项目风险;(2)技术风险;(3)商业风险。

　　风险条目检查表：(1)产品规模风险;(2)商业影响风险;(3)客户相关风险;(4)过程风险;(5)技术风险;(6)开发环境风险;(7)与人员数目及经验相关的风险。

软件评测基础知识

　　软件测试基本概念

　　软件质量与软件测试：软件测试是软件质量保证工作的一个重要环节。软件测试和软件质量保证是软件质量工程的两个不同层面的工作。软件测试只是软件质量保证工作中的一个重要环节。质量保证(QA)的工作是通过预防、检查与改进来保证软件的质量，它所关注的是软件质量的检查和测量。软件测试所关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。

　　软件测试定义：软件测试就是在软件投入运行前对软件需求分析、软件设计规格说明和软件编码进行的查错(包括代码执行活动与人工活动)。软件测试是为了发现错误而执行程序的过程。软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序的错误。是在软件投入运行前，对软件需求分析、软件设计规格说明和软件编码的最终复审，是软件质量保证的关键步骤。

　　软件测试目的：(1)测试是一个为了寻找错误而运行程序的过程;(2)一个好的测试用例是指很可能找到迄今为止未发现的错误的用例;(3)一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

　　软件测试的目标是能够以耗费最少时间与最小工作量找出软件系统中潜在的各种错误与缺陷。

　　测试只能证明程序中错误的存在，但不能证明程序中没有错误。

　　软件测试原则：(1)尽早地并不断地进行软件测试;(2)程序员或程序设计机构应避免测试自己设计的程序;(3)测试前应当设定合理的测试用例;(4)测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据;(5)在对程序修改之后要进行回归测试;(6)充分注意测试中的群集现象;(7)妥善保留测试计划、全部测试用例、出错统计和最终分析报告，并把它们作为软件的组成部分之一，为软件的维护提供方便;(8)应当对每一个测试结果做全面检查;(9)严格执行测试计划，排除测试的随意性。

　　软件测试对象：软件的测试不仅仅是程序的测试，软件的测试应贯穿于整个软件生命同期中。在软件定义阶段产生的可行性报告、项目实施计划、软件需求说明书或系统功能说明书，在软件开发阶段产生的概要测试说明书、详细设计说明书，以及源程序等都是软件测试的对象。

　　软件测试过程模型：V模型、W模型、H模型。

　　软件测试模型的使用：在实际软件测试的实施过程中，应灵活地运用各种模型的优点，通常可以在W模型的框架下，运用H模型的思想进行独立的测试。当有变更发生时，按X模型和前置模型的思想进行处理。同时，将测试和开发紧密结合，寻找恰当的就绪点开始测试，并反复进行迭代测试，以达到按期完成预定的目标。

　　软件问题分类：软件错误、软件缺陷、软件故障、软件失效。

　　软件测试类型：

　　按开发阶段分：单元测试、集成测试、确认测试(有效性测试)、系统测试

　　确认测试、验收测试

　　按测试实施组织分：开发方测试(验证测试或alpha测试)、用户测试(beta)、第三方测试(独立测试)

　　按测试方式分：动态测试、静态测试

　　按测试技术分：白盒测试、黑盒测试、灰盒测试

软件测试过程：用黑盒法设计基本的测试方案，再利用白盒法补充一些必要的测试方案。可以用以下策略结合各种方法：

　　(1)在任何情况下都应该使用边界值分析的方法;

　　(2)必要时用等价划分法补充测试方案;

　　(3)必要时用错误推测法补充测试方案;

　　(4)如果在程序的功能说明中含有输入条件的组合，最好在一开始就用因果图法，然后再按以上(1)、(2)、(3)步进行。

　　(5)对照程序逻辑，检查已设计出的设计方案。可以根据对程序可靠性的要求采用不同的逻辑覆盖标准，如果现有测试方案的逻辑覆盖程度没有达到要求的覆盖标准，则应再补充一些测试方案。

　　单元测试主要是对模块的5个基本特性进行测试和评价：(1)模块接口;(2)局部数据结构;(3)重要的执行路径;(4)错误处理;(5)边界测试。

　　在集成测试时，要考虑的问题有：数据经过接口是否会丢失;一个模块对另一模块是否造成不应有的影响;几个子功能组合起来能否实现主功能;误差不断积累是否达到不可接受的程度;全局数据结构是否有问题。

　　确认测试又称为有效性测试、合格测试或验收测试。确认测试主要由使用用户参加测试，检验软件规格说明的技术标准的符合程度，是保证软件质量的最后关键环节。

　　系统测试是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对计算机系统进行一系列的组装测试和确认测试。系统测试实质上是由一系列不同测试组成的，其主要目的是充分运行系统，验证系统各个部件是否都能正常工作并完成所分配的功能。

　　系统测试包括：恢复测试、安全性测试、强度测试、性能测试等。

　　验收测试是以用户为主，软件开发人员和质量保证人员也应参加的测试。由用户参加设计测试用例。使用用户界面输入测试数据，并分析测试的输出结果。验收测试往往知系统测试完成后，项目最终交付前进行。