我们从 V 模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统（验收）测试计划和设计，除了能指导最终的系统测试和验收测试执行外，其本身也是对需求的一个验证过程。
    通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。
    设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题，为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测试人员可能会设计出不同于需求的测试用例，而这最终可能会有两个解释：
1 、需求不完整或者需求有错；
2 、遗漏了测试用例或者测试用例本身有错误；
   不管是哪种解释，最终肯定会提高整个系统的质量。但这个质量的获得是通过冗余的人员来完成的，即：开发人员在对系统需求进行进一步分析的时候，有一组独立的测试人员也在对系统需求进行独立的思维，并从中获取测试用例。尽管这两种思维可能会出现重复，但由于思维的方式不同，最终肯定会使得需求变得更清晰和更完善。

难得在温暖的下午有时间坐电脑前，所以写点东西吧。
肯定是关于考试，从来学校看教程看辅导书已经有11天多了，应该学得很用心，这才越来越了解这个考试，有难度，根本不是别人说的“100米的宽度1米的深度”，绝对不止。
接触最多的是新名词，新概念，一堆一堆，定义，核心，思想，相似点，区别，优点，缺点，应用，，，，
书的序言说会把你引入技术的殿堂，我觉得现在混沌的我象进了迷宫。
还有按理分析和论文的实践经验。。。
都是对我的挑战。
3月17号，今天离考试应该还有67天，如果没记错的话。

继续努力吧，相信自己。

提取测试需求是测试活动中的基础工作，是测试活动展开的前提条件。

在项目实施前在做整个系统的测试方案中工作量评估时，如果是基于系统功能点的方法，则已经对系统中的功能点、性能点等进行分析统计，可以直接在该分析结果的基础上进行细化和完善。

在项目测试活动中确定用户需求范围是最重要也最困难的工作之一。往往在项目实施前无法准确界定测试范围，原因很多，主要有以下几个方面：

1、系统用户需求不详细，从而无法确定测试范围；

2、用户需求中简单的描述，可能包括很多研发工作，也需要测试，容易别忽略；

3、行业经验不足，对其中的业务不熟悉，造成对业务功能不能确定；

在测试过程中，带来测试范围变化的原因，主要包括：

1、在开发过程中客户较大的改变原来的需求，扩展原来的需求；

2、开发改变客户的需求，带来测试范围的变化；

综合以上的原因，主要来自于三个方面：

1、客户的需求前期描述不清，后期的增加、修改变化；

2、开发对需求的变更；

3、测试团队对行业或系统业务、项目经验的不足；

对于第1点，可以约定测试用户需求的基线版本，对于研发过程中需求变更超过一定范围，重新评估增加的工作量。

对于第2点，可以同第1点一样，同客户在前期约定好。

对于第3点，则是需要一个过程，业务和项目经验积累需要一个过程。

要确定测试需求，相当于确定了测试范围，则能比较准确的确定工作量。如何分析测试需求呢？

首先、分析用户提供的所有文档，在业务分析师的帮助下，根据业务分解系统功能，由粗到细，逐渐细化需求，这其中需要客户、研发团队的协助，把不清晰、不明确、不具有可测试性的需求转化明确的、具有可测性的需求。根据测试需求对应的集成测试、系统功能测试和性能测试活动不同，其测试需求也不同，例如，对于产品集成测试，则测试需求细化到测试集成的每个模块接口、子系统接口即可。对于功能测试则时一个具体的功能实现，该功能可能时一个典型业务中的一个操作，也可能是整个典型业务。如果是一个典型业务的一个操作功能，则最好把整个典型业务的测试需求串接在一起，形成一个典型业务的测试需求链（具有相关的测试需求形成的一个序列）。

其次、把测试需求尽量使用测试管理工具进行管理，便于测试需求的统计、变更，以及与测试用例形成关联。

测试需求在客户评审通过后，要形成基线，以后用户需求变更后，要进行测试需求的变更，且保持测试需求与用户需求的版本一致。

任务：

1、在Weblogic发布WEB应用程序

1.1配置工作区   用户名：weblogic     密码：weblogic

1.2进入weblogic服务器的管理控制中心进行配置要启动服务器：7001 通过 http：//localhost：7001/console

1.3发布应用诚寻--web程序  完成符合J2EE标准的web目录  -WEB-INF

                                                -web.xml文件（jso2.0、servlet2.4版本）

诚寻的访问http：//localhost：7001/testbea 项目部署上去后服务器必须选择启动项目。

2.在Weblogic 使用数据源连接池 依然使用oracle数据库在Weblogic之中包含了主流数据库的驱动程序

1.软件需求是软件开发最重要的一个输入 ，好的开始是成功的一半！ 所以，需求的质量很大程度上决定了项目质量或产品质量。
2.需求风险常常是软件开发过程中最大的一个风险 ，要降低需求阶段带来的风险，就要把需求评审做好。
3.需求评审做不好的后果：
需求变更
需求不明确
需求不可测
需求不可实现
导致后续工作难于开展或经常出现变更。
4、产品经理：不识庐山真面目，只缘身在此山中，需求是自己写的，容易受到固定思维的限制，所以，需要一双没有看过这个需求的眼睛来检查一下，有什么问题。

先大概说一下需求的不同类型：
需求的不同层次：
目标性需求：定义了整个系统需要达到的目标；
  -高层关注
功能性需求：定义了整个系统必须完成的任务；
  -中层关注
操作性需求：定义了完成每个任务的具体的人机交互；
  -执行人员关注

在做需求评审的时候，应该根据不同的需求层次，进行不同的评审。

因为经常参加需求评审会议，所以对需求评审中常见的问题有所了解，现在举一些例子：
1、某产品经理在主持需求评审会，评审开始时间不长，就被一位主管打断，明确指出此方案与企业业务发展方向不符，不能实施。紧接着其他与会人员纷纷发言表示同意，结果评审会无法继续进行，需求最终被否决。
问题所在：
缺乏初步沟通，目标性需求尚未明确，功能性需求和操作性需求无从谈起。

2、某次需求评审会，主要是公司内部相关领域的专家参加，在评审会开始后不久，某专家就对需求中的某个具体问题提出了自己的不同意见，于是，与会人员纷纷就该问题发表自己的意见，大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。
问题所在：
前期沟通和准备不够，缺乏应对不同意见的准备，难以化解争执。
主持者不能有效把握会议目标，会议讨论过于关注细节，导致评审失控。
3、某产品经理主持需求评审会，在讲解需求说明书时，与会人员似懂非懂，没有提出任何有价值的问题，致使会议没有得到预期效果，不得不改日重新进行。
问题所在：
前期准备和沟通不够，评审变成了培训。
没有选择合适的评审人员，无法获得有价值的信息。

4、某需求评审会，与会人员各抒己见，气氛热烈，产品经理忙于收集意见，结果散会时发现对需求有价值的并不多，并且遗漏了许多要评审的问题，评审效果不佳。与会人员在离开会议室后，私下也认为评审没有多少实际效果，完全是在走过场。
问题所在：
评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。
产品经理没有把握好会议主题，评审变成了头脑风暴。

需求评审常见问题汇总
目标性需求没有沟通好，后面的需求变成空中楼阁。
缺乏评审的可操作依据，遗漏评审内容。
没有作好前期准备工作，导致评审时间长，效率低。
没有选择合适的评审人员，无法获得有价值的反馈。
参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。

针对以上问题，提出一些建议：
建议一、做好评审前的沟通和准备
需求编写人员应将评审所需的资料准备齐全，数据、图表、其他相关资料等，并仔细检查以保证文档质量。
需求文档在评审会议前应提前下发给参与评审会议的人员，并留出时间让参与评审的人员阅读需求文档。
参加评审的人，应该是带着问题而来，而不是来参加培训的。

建议二、先沟通好目标，再进行细节的落实。
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
分阶段评审保证了需求在形成的过程中不偏离方向，不出现大的错误，降低了需求返工的风险，提高了最终评审的质量

建议三、正式评审与非正式评审相结合
正式评审
是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。
非正式的评审
通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。 两种形式各有利弊，因此在评审时，根据项目复杂程度，紧急程度不同，应该灵活地利用这两种方式。

建议四、精心挑选评审员
为了保证评审的质量和效率，需要精心挑选评审员。
首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。(测试经常被遗忘哦！)
在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，选择有经验的，而不是有时间的人。（teamleader选择参加，主要执行人员必须参加！针对评审目标选择参与者，避免高、中、低层一起评审。）

建议五、充分利用需求检查单
使评审有可操作依据，提高评审有效性，避免遗漏。
便于收集评审数据，记录评审结果

建议六、做好评审后的跟踪工作
切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流
发送项目状态通知，让相关人员周知需求评审已完成。
说明需求经评审后改动的部分，如实现优先级、加入和裁减了哪些。
针对评审结果对需求进行完善，并保证相关人员获得最新版的需求文档


另外，关于开会说几点：

为什么会议时间过长？
前期沟通不够，把应该花在前期沟通上的时间，用在了会议上。
自己准备不足，比如资料不全，不准，数据准备不充分等，不能说服与会人员，陷入争执。
不能把握会议主题，偏离目标。

说了这么多，希望能对遇到过相似问题的朋友有所帮助。

1.项目数据库建立(一般名称为项目简称)

2.相关用户组建立 (根据项目已知信息确定用户组及相关权限，在TD中设定并实现)

3.BUG管理规范在TD中的实现(分析缺陷规范或流程，得到用户组信息。确定缺陷状态。确定每类用户在缺陷处理过程和整个测试过程中的权限。在TD中实施设置。实施检查。)

4.TD过程功能使用(建立测试需求树(将已经识别的测试对象管理起来requirement)，计划测试(Test Plan测试用例管理)，创建测试集(Test lab测试执行策略管理)，执行测试，缺陷管理(defect))

5.报表生成(生成缺陷分析报告(包含缺陷状态分布图、趋势图、龄期图)。生成测试需求覆盖报告(包含报告和执行结果覆盖饼图))

测试经理服务于两种完全不同的客户：测试工程师和高层管理者。对于测试工程师，测试经理帮助他们开发产品测试策略，积累产品测试经验并在测试组内充分共享。对于高层管理者，测试经理搜集尽可能全面的产品信息，供其就产品是否可以发布进行决策。但是有一点是相同的：无论是对于测试工程师还是高层管理者，测试经理将帮助其定义和校验产品发布标准。

产品发布标准的定义和校验：作为一个测试经理，应该找机会与市场、开发人员商讨产品发布标准，并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望，要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义，就可以通过测试去验证产品在多大程度上满足了客户需求。

对于测试工程师而言有一点非常重要：将测试任务按优先级划分，使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情，所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。

高层管理者需要充分理解产品发布标准，以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布，该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后，项目组也可以更清楚地了解和认识产品质量。

测试需求的概念比较简单。例如，比方说一个计算平方根的程序，如果输入一个大于或等于零的数，程序可以给出一个结果；如果输入一个小于零的数，程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试；对零非常接近的负数进行测试，这就是两个具体的测试需求。

在一个更加复杂的程序中，你可以将打算测试的项目做成一个列表。但是，这些测试需求都不会确定具体的测试数据。例如，一个银行交易程序，一个测试需求是试图支付客户的金额为负数，另一个测试需求是交易中的客户并不存在，等等。你有一系列这样的测试需求，它们并没有指出具体的数值或数据，如客户的姓名。

测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求，当然是最理想的情况，但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例，就可以不必考虑那些复杂的测试用例，但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

这里有一个测试需求的实例：对一个哈希表的插入操作进行测试，有以下这些测试需求：
1 ）插入一个新的条目
2 ）插入失败－条目已经存在
3 ）插入失败－表已满
4 ）哈希表在插入前为空
这些就是测试需求，而非测试用例，因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例，就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审，确保正确和没有需求遗漏。

软件测试 V 模型要求我们在需求阶段就开始制定系统测试的计划，开始考虑系统测试的方法。但这还不是足够的。全面的质量管理要求我们在每个阶段都要进行验证和确认的过程。因此在需求阶段我们还需要对需求本身进行测试。这个测试是必要的，因为在许多失败的项目中， 7 0 % ～ 8 5 % 的返工是由于需求方面的错误所导致的。并且因为需求的缘故而导致大量的返工，造成进度延迟、缺陷的发散，这是一件及其痛苦的事情。因此我们要求在项目的源头（需求）就开始测试。这类测试更多的还只是静态手工方面的测试，当然也有一些自动化的工具，但这些工具会要求我们按照某个固定的格式进行需求的表述（例如形式化的方法），因此在适用性上会受到限制。通过静态手工方法进行需求测试中最常使用的手段是同行评审。

功能覆盖率（ Function Coverage ）是属于黑盒测试范畴内的，在实际测试中，涉及到的覆盖率一般都是结构化覆盖率，与黑盒相关的覆盖率比较少。
功能覆盖中最常见的是需求覆盖，其含义是通过设计一定的测试用例，要求每个需求点都被测试到。其公式是

    需求覆盖 ＝ （被验证到的需求数量） / （总的需求数量）

    在黑盒测试中还有一个覆盖叫接口覆盖（或者称为入口点覆盖），要求通过设计一定的用例使得系统的每个接口被测试到。
    由于黑盒测试把被测系统理解为一个黑盒，测试时，输入测试数据，然后判定输出结果是否与期望结果一致。根据这个可以得到输入数据的覆盖情况，即通过设计一定的用例，要求每种数据情况都被测试到。

我们都知道，「测试」是产品的真正试炼场；即使对一项软件开发工程投注了庞大的心血，如果测试不合格还是枉然，因为客户要的是「合格产品」，而不是你的「努力过程」。所以测试的重要性应该不必赘述。只不过，「知道」跟「做得到」是两回事，就如同我们都知道应该多吃青菜水果，然而还是有许多人每餐都是大鱼大肉。

许多人谈到测试，总是有满腹牢骚，因为它似乎是一件「知易行难」的麻烦工作。为何测试总是做不好？大致可归类成下述三大原因。

测试排最后

目前一般的软件开发工作，大多采用传统的「瀑布式（ Waterfall ）」流程法，也就是把开发过程分为「需求」、「分析」、「设计与撰写」、「整合」、「测试」等阶段，一个接一个依序进行。

这种方法很单纯，但导致「测试总是排在最后才进行」的状况。这种设计会产生两个状况：一是测试人员直到案子接近尾声才上工，所以往往在尚未了解整个系统架构的情况下，就一头栽进工作。二是这个时间点距离完工期实在太近，如果有什么突发状况，往往导致整个开发项目大乱或失败。

时间不够

测试做不好的第二个原因是「时间不够」，这是开发团队最常面临的问题。它其实也是上述「瀑布式」流程法把测试排在最后所导致的另一个致命伤。由于许多开发团队把大部分时间分配给前面阶段（特别是程序设计与撰写部分），只留少数时间给测试工作。然而突发状况永远无法预期，如果前面阶段因故导致工作拖延，在出货时间不能延后的情况下，后面阶段的时间就会不断地被牺牲。

所以我们常常看到，在一个预定进行八个月的软件项目里，因为前面阶段的状况百出（计算机当机、同仁生病请假、客户需求更改、开发不顺等），结果前面阶段不断占用后面阶段的时间，最后导致原本排定一个月的测试时间只剩下一周，甚至二、三天而已，根本无法测试。所以常常出现有些产品根本是在未经完整测试的情形下就贸然出货上市，把测试工作留给客户或消费者的情况。

另外还有一个与「时间不够」刚好相反的现象，就是「时间太长」。有时产品经初步测试之后发现问题丛生，实在无法交差（或是被客户退件），所以开发团队只好回头继续进行大量又重复的「测试 → 修改 → 验证」工作。如此折腾了好一阵子，最后产品终于可以验收。把这段额外时间加总起来，重新计算整体开发时间，这时才突然惊觉：「天啊，测试竟然占了将近一半的时间！」

风险太高

第三个问题是「风险太高」，也是流程设计不当所致。如文章开头所言：「测试才是产品的真正试炼场」，也就是一个项目的各种隐藏性风险，往往是透过「测试」才被完整发掘出来。但是「单向瀑布式」流程法却把测试集中在最后进行，所以它的风险容易随着开发流程的推进而越来越高；是一种相当危险的风险控管方式。

事实上，这也是许多项目在后期才突然出现成本失控或失败的重要原因。因为等到风险爆发之时，往往已经无力回天，或必须付出相当大的代价以为因应。

 
我经常考虑作为测试人员职责到底多宽，经过看一些资料，还有我自己的体会对软件测试的职责作了下总结：

¶ 在项目的前景、需求文档确立基线前对文档进行测试，从用户体验和测试的角度提出自己的看法。

¶ 编写合理的测试计划，并与项目整体计划有机地整合在一起。

¶ 编写覆盖率高的测试用例。

¶ 针对测试需求进行相关测试技术的研究。

¶ 认真仔细地实施测试工作。

¶ 进行缺陷跟踪与分析。

¶ 提交测试分析报告。

当然具体到某个角色的职责又有所不同，一般测试组内有测试经理、测试员两个角色。

Y 测试经理:组建测试组;协调测试组内部的沟通；代表测试组与其他角色组进行沟通（其他角色是指项目经理、开发人员）；编写测试计划；测试报告分析。
Y 测试员：编写测试用例（有很多情况测试用例是由测试经理来编写的）；实施测试用例；执行测试。

测试的目的是显示存在错误，而调试的目的是发现错误或导致程序失效的错误原因，并修改程序以修正错误。调试是测试之后的活动。 [Beizer, 1984] 认为，测试和调试在目标、方法和思路上都有所不同，如下：

1 、测试从一个已知的条件开始，使用预先定义的过程，有预知的结果。调试从一个未知的条件开始，结束的过程不可预计。

2 、测试过程可以实现设计，进度可实现确定。调试不能描述过程或持续时间。

3 、测试是显示错误的行为。调试是推理的过程。

4 、测试显示开发人员的错误。调试是开发人员为自己辩护。

5 、测试能预期和可控。调试需要想象，经验和思考。

6 、测试能在没有详细设计的情况下完成。没有详细设计的信息调试不可能进行。

7 、测试能由非开发人员进行。调试必须由开发人员进行。

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则：
1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。
2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。
3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。
4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。
5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。
6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

很多实时系统的时间依赖性和异步性给测试带来新的困难－－时间！测试用例的设计者考虑的不仅是白盒和黑盒测试用例，而且包括事件处理（如中断处理）、数据的时间序列以及处理数据的任务（进程）的并发性。很多情况下，提供的测试数据有时使得实时系统在某状态下可以正常运行，而同样的数据在系统处于不同状态时有时又会导致错误。

另外，实时系统的软件和硬件之间的密切关系也会导致测试问题，软件测试必须考虑硬件故障对软件处理的影响，这种故障很难实时仿真。由于实时系统的特殊性和复杂性，还没有一个完善的综合性的测试用例设计方法，但是，大致可以分为以下四个步骤：

1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例，并在测试时执行每个任务。任务测试能够发现逻辑和功能错误，但是不能发现时间和行为错误。

2 、行为测试。利用 CASE 工具创建软件模型，就可能仿真实时系统，并按照外部事件的序列检查其行为，这些分析活动可作为创建实时系统时设计测试用例的基础。

3 、任务间测试。在隔离了任务内部和系统行为错误以后，测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务，看任务间的同步是否会产生错误。另外，测试通过消息队列和数据存储进行通讯的任务，以发现这些数据存储区区域大小方面的错误。

4 、系统测试。集成软件和硬件，并进行大范围的系统测试，以发现软件 / 硬件接口间的错误。

测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因，应当为软件工程过程定义一个软件测试的模板－我们可以把特定的测试用例方法放置进去的一系列步骤。

人们已经提出了许多软件测试策略，所有这些策略都为如开发人员提供了一个供测试用的模板，而且它们都包含下列的类属特征：
· 测试开始于模块层，然后 “ 延伸 ” 到整个基于计算机的系统集合中。
· 不同的测试技术适用于不同的时间点。
· 测试是由软件的开发人员和（对于大型系统而言）独立的测试组来管理的。
· 测试和调试是不同的活动，但是调试必须能够适应任何的测试策略。

软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试，同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南，并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的，所以测试的进度必须是可测量的，而且问题要尽可能早的暴露出来。

中层经理人不论是作为一名执行者、还是一名领导者，都必须通过别人来完成任务。要做个“服众”的经理人，应该有意识地提高以下八项能力：

1. 领悟能力
    做任何一件事以前，一定要先弄清楚上司希望你怎么做，然后以此为目标来把握做事的方向，这一点很重要，千万不要一知半解就开始埋头苦干，到头来力没少出、活没少干，但结果是事倍功半，甚至前功尽弃。要清楚悟透一件事，胜过草率做十件事，并且会事半功倍。

2. 计划能力
    执行任何任务都要制定计划，把各项任务按照轻、重、缓、急列出计划表，一一分配部属来承担，自己看头看尾即可。把眼光放在部门未来的发展上，不断理清明天、后天、下周、下月，甚至明年的计划上。在计划的实施及检讨时，要预先掌握关键性问题，不能因琐碎的工作，而影响了应该做的重要工作。要清楚做好20%的重要工作，等于创造80%的业绩。

3. 指挥能力
    无论计划如何周到，如果不能有效地加以执行，仍然无法产生预期的效果，为了使部属有共同的方向可以执行制定的计划，适当的指挥是有必要的。
    指挥部属，首先要考量工作分配，要检测部属与工作的对应关系，也要考虑指挥的方式，语气不好或是目标不明确，都是不好的指挥。而好的指挥可以激发部属的意愿，而且能够提升其责任感与使命感。要清楚指挥的最高艺术，是部属能够自我指挥。

4. 控制能力
    控制就是追踪考核，确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉，然而企业的经营有其十分现实的一面，有些事情不及时加以控制，就会给企业造成直接与间接的损失。但是，控制若是操之过急或是控制力度不足，同样会产生反作用：控制过严使部属口服心不服，控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制，就是让部属通过目标管理方式实现自我控制。

5. 协调能力
    任何工作，如能照上述所说的要求，制定完善的计划、再下达适当的命令、采取必要的控制，工作理应顺利完成，但事实上，主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调，也包括与外部客户、关系单位、竞争对手之间的利益协调，任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。

6. 授权能力
    任何人的能力都是有限的，作为高级经理人不能象业务员那样事事亲历亲为，而要明确自己的职责就是培养下属共同成长，给自己机会，更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子，也是延伸自己智力和能力的载体，要赋予下属责、权、利，下属才会有做事的责任感和成就感，要清楚一个部门的人琢磨事，肯定胜过自己一个脑袋琢磨事，这样下属得到了激励，你自己又可以放开手脚做重要的事，何乐而不为。切记成就下属，就是成就自己。

7. 判断能力
    判断对于一个经理人来说非常重要，企业经营错综复杂，常常需要主管去了解事情的来龙去脉因果关系，从而找到问题的真正症结所在，并提出解决方案。这就要求洞察先机，未雨绸缪。要清楚这样才能化危机为转机，最后变成良机。

8. 创新能力
    创新是衡量一个人、一个企业是否有核心竞争能力的重要标志，要提高执行力，除了要具备以上这些能力外，更重要的还要时时、事事都有强烈的创新意识，这就需要不断地学习，而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的，它要求大家把工作的过程本身当作一个系统的学习过程，不断地从工作中发现问题、研究问题、解决问题。解决问题的过程，也就是向创新迈进的过程。因此，我们做任何一件事都可以认真想一想，有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限，唯有创新，才能生存。

领导力更需提升
    一个部门经理提高完成任务执行力的过程，其实也就是提高自身对部门员工领导力的过程。因为要提高执行部门的执行力，不是光靠经理一人所能完成的，而是要靠带领部门所有员工的共同努力才能完成的。
   说到底，对上提高执行力、对下就要提升领导力。
    那么，怎样才能提升领导力呢？除了提高以上八项能力之外，还有最重要的两点：
1. 学会用老板眼光看企业。
    在老板看来，管理很简单，就是两件事：一是扩大业务范围，增加业务收人；另一件事就是降低管理成本，控制运作费用。其实这两件事，最终是一件事，收入减去成本，减去费用，就是利润。所以归根到底老板是看利润的，利润要从管理中来。
2. 从被领导中学习领导。
    在领导人看来，领导也很简单，就是两件事：一是用人，内圈用德、外圈用才，用人所长、容人所短；二是激励，解人之难、记人之功，通过正面激励，引导下属往前跑，通过负面激励，推着下属往前走。要知道，任何领导都是从做下属开始的，谁都不可能一步登天当领导。在每个人的成长过程中，你会经历大大小小许多领导，只要你用心学习，不管是好领导、还是坏领导，你都可以从正反两方面学到经验和教训，这对你将来当好领导是十分珍贵的。

除了以上各种能力外，测试技能不能丢，通过技术服众可以保证管理的有效执行。

一、测试计划：
对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。
二、测试方案：
描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计和选择、测试用例的设计方法、测试代码的设计方案。
三、测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。
四、测试方案是技术层面的文档，从技术的角度度一次测试活动进行规划。
五、测试计划要明确的内容：
1、明确测试组织的组织形式
1测试组织和其他部门关系，责任划分。
2测试组织内的机构和责任安排。
2、明确测试的测试对象（明确测试项，用于后面划分任务,估计工作量等）
3、完成测试的需求跟踪
4、明确测试中需要遵守的原则
1测试通过/失败标准
2测试挂起和回复的必要条件
5、明确测试工作任务分配是测试计划的核心
1、进行测试任务划分
2、进行测试工作量估计
3、人员资源和物资源分配
4、明确任务的时间和进度安排
5、风险的估计和规避措施
6、明确测试结束后应交付的测试工作产品
六、测试方案的具体内容：
1、明确策略
2、细化测试特性（形成测试子项）
3、测试用例的规划
4、测试环境的规划
5、自动化测试框架的设计
6、测试工具的设计和选择
七、测试方案需要在测试计划的指导下进行，测试计划提出“做啥”，而测试方案明确“咋做”。
八、详见测试计划模板和测试方案模板。

1、安装SQL, 登录用户名一定要SA
2、设置MS-SQL的数据库连接：对数据库的“客户端网络实用工具”进行配置。选择协议Named Pipes与TCP/IP，别名设置最好选择本机计算机名。对数据库的安全性设置--身份验证，设置为SQL Server和WINDOWS。
3、在服务器上安装TD，安装过程选择SQL数据库
4、设置与SQL连接在Site Administrator--DB Servers中，先新建一个数据库，Server Alias为你的计算机名，DB user 为SA ,DB Passwoed为SQL的SA密码一样建立成功以后，Ping一下，通过则认为数据库与TD建立连接成功
5、项目移植将ACCESS中的项目在TD中建立，数据库选择SQL；之后进入SQL数据库，在相应数据库项目单击右键选择“所有任务—导入数据”，进入导入数据向导，数据源选择“ODBC数据源”，用户、系统DNS新建一个“文件数据源”，按照向导提示一步一步做下去，这样就将ACCESS中的数据移植到SQL中
6、移植完成登录到TD，就可以看到移植后的项目数据，移植成功

注：从ACCESS移植到SQL，中间也许会出现问题，造成数据丢失（是不可避免的）

在SqlServer数据库中插入10万条数据:

declare @i int
set @i=0

while  (@i<100000)
begin

   insert into table values(字段1,字段2……)
   set @i=@i+1
end