请问，如果每天都有86400元进人你的银行户头，而你必须当天用光，你会如何运用这笔钱？

　　天下真有这样的好事吗？

　　是的，你真的有这样一个户头，那就是“时间”。每天每一个人都会有新的86400秒进账。那么，面对这样一笔财富，你打算怎样利用它们呢？

　　首先，让我们来做一个关于时间管理总体水平的测试

　　下面的每个问题，请你根据自己的实际情况，如实地给自己评分。计分方式为：选择“从不”记0分，选择“有时”记1分，选择“经常”记2分，选择“总是”记3分。

1．我在每个工作日之前．都能为计划中的工作做些准备。
2．凡是可交派下属（别人）去做的，我都交派下去。
3．我利用工作进度来书面规定工作任务与目标。
4．我尽量一次性处理完毕每份文件。
5．我每天列出一个应办事项清单，按重要顺序排列，依次办理这些事情。
6．我尽量回避干扰性电话、不速之客的来访，以及突然的约会。
7．我试着按照生理节奏变动规律曲张图来安排我的工作。
8．我的日程表留有回旋余地，以便应对突发事件。
9．当其他人想占用我的时间，而我又必须处理更重要事情时，我会说“不”。

结论：
0-12分：你自己没有时间规划，总是让别人牵着鼻子走。
13-17分：你试图掌握自己的时间，却不能持之以恒。
18-22分：你的时间管理状况良好。
23-27分：你是值得学习的时间管理的典范。

　　知道了你自己的时间管理方面的总体水平，接下来，让我们来分析一下时间是如何被浪费掉的。

　　浪费时间的原因有主观和客观两大方面。这里，我们来分析一下浪费时间的主观原因，因为，这是一切的根源。

1. 做事目标不明确。
2. 作风拖拉。
3. 缺乏优先顺序，抓不住重点。
4. 过于注重细节。
5. 做事有头无尾。
6. 没有条理，不简洁，简单事情复杂化。
7. 事必躬亲，不懂得授权。
8. 不会拒绝别人的请求。
9. 消极思考。

　　一项国际调查表明：一个效率糟糕的人与一个高效的人工作效率相差可达10倍以上。

　　看来，人人都需要掌握时间管理的方法和理念。

　　那么，什么是时间管理？

　　所谓时间管理，是指用最短的时间或在预定的时间内，把事情做好。

　　接下来，我们来看一组数据，虽然这些数据来自美国，但对我们还是有一定参考价值的。

1、人们一般每8分钟就会受到1次打扰，每小时大约7次，每天50次~60次。平均每次打忧用时大约是5分钟，总共大约4小时。大约50%-80%的打扰是没有意义或者极少有价值的。

2、每天自学1小时，7小时一周，365小时一年，一个人可以像全日制学生一样学习，3-5年就可以成为专家。

3、一个人如果办公桌上乱七八糟，?他平均每天会为找东西花半小时，每周要花7个半小时。

4、善于利用时间的人不会把时间花在需要的事情上，而会花在值得的事情上。

5、时间管理中最有用的词是“不”。

6、做一件事情实际花费的时间往往会比预期的时间多一倍。

7、如果你让自己一天做一件事情，你会花一整天去做；如果你让自己一天做两件事，你也会完成它们；如果你让自己一天去做12件事情，则会完成7~8件......

　　数字往往会揭示一些人们意想不到的真相。这些数据是否令你感到吃惊？我们不妨留意一下，找出一些和自己有关的时间数字，使自己始终保持危机感，警惕时间的流逝，抓紧利用好每一分、每一秒。

　　时间管理的方法

　　时间管理的方法有很多，这里我们来分享集各种方法之大成的5个：

　　6点优先工作制

　　该方法是效率大师艾维利在向美国一家钢铁公司提供咨询时提出的，它使这家公司用了5年的时间，从濒临破产一跃成为当时全美最大的私营钢铁企业，艾维利因此获得了2.5万美元咨询费，故管理界将该方法喻为“价值2.5万美元的时间管理方法”。

　　这一方法要求把每天所要做的事情按重要性排序，分别从，“1”到“6”标出6件最重要的事情。每天一开始，先全力以赴做好标号为“1”的事情，直到它被完成或被完全准备好，然后再全力以赴地做标号为“2”的事，依此类推……

　　艾维利认为，一般情况下，如果一个人每天都能全力以赴地完成6件最重要的事，那么，他一定是一位高效率人士.

　　帕累托原则

　　这是由19世纪意大利经济学家帕累托提出的。其核心内容是生活中80％的结果几乎源于20%的活动。比如，总是那些20％的客户给你带来了80％的业绩，可能创造了80％的利润；世界上80％的财富是被20%的人掌握着，世界上80％的人只分享了20％的财富。因此，要把注意力放在20％的关键事情上。

　　根据这一原则，我们应当对要做的事情分清轻重缓急，进行如下的排序：

A．重要且紧急〔比如救火、抢险等）—一必须立刻做。

B．重要但不紧急〔比如学习、做计划、与人谈心、体检等）－一只要没有前一类事的压力，应该当成紧急的事去做，而不是拖延。

C．紧急但不重要（比如有人因为打麻将“三缺一”，而紧急约你、有人突然打电话请你吃饭等）－—只有在优先考虑重要的事情后，再来考虑这类事。人们常犯的毛病是把“紧急”当成优先原则，而不是把“重要”当成优先原则。其实，许多看似很紧急的事，拖一拖，甚至不办，也无关大局。

D．既不紧急也不重要〔比如娱乐、消遣等事情）一一有闲工夫再说。

　　麦肯锡30秒电梯理论

　　麦肯锡公司曾经得到过一次沉痛的教训：该公司曾经为一家重要的大客户做咨询。咨询结束的时候，麦肯锡的项目负责人在电梯间里遇见了对方的董事长，该董事长问麦肯锡的项目负责人：“你能不能说一下现在的结果呢？”由于该项目负责人没有准备，而且即使有准备．也无法在电梯从30层到l层运行的300秒钟内把结果说清楚。最终，麦肯锡失去了这一重要客户。从此，麦肯锡要求公司员工凡事要在最短的时间内把结果表达清楚，凡事要直奔主题、直奔结果。麦肯锡认为，一般情况下人们最多记得住一二三，记不住四五六，所以凡事要归纳在3条以内。这就是如今在商界流传甚广的“30秒电梯理论”或称“电梯演讲”。

　　办公室美学

　　秩序是一种美。均匀、对称、平衡和整齐的事物能给人一种美感。简洁就是速度，条理就是效率。简洁和条理也是一种美，是一种办公室的美学、工作的美学。

　　我们应当养成如下良好习惯：

1、物以类聚，东西用毕物归原处；
2、不乱放东西；
3、把整理好的东西编上号，贴上标签，做好登记‘
4、好记性不如烂笔头，要勤于记录；
5、处理文件的3个环节：第一，迅速回复。第二，迅速归档，以免文件弄乱或弄丢。第三，及时销毁。没用的文件要及时处理掉，以免继续浪费空间和时间。

　　莫法特休息法

　　《圣经新约》的翻译者詹姆斯?莫法特的书房里有3张桌子：第一张摆着他正在翻译的《圣经》译稿；第二张摆的是他的一篇论文的原稿；第三张摆的是他正在写的一篇侦探小说。

　　莫法特的休息方法就是从一张书桌搬到另一张书桌，继续工作。

　　“间作套种”是农业上常用的一种科学种田的方法。人们在实践中发现，连续几季都种相同的作物，土壤的肥力就会下降很多，因为同一种作物吸收的是同一类养分，长此以往，地力就会枯竭。人的脑力和体力也是这样，如果长时间持续同一项工作内容，就会产生疲劳，使活动能力下降。如果这时改变工作内容，就会产生新的优势兴奋灶，而原来的兴奋灶则得到抑制，这样人的脑力和体力就可以得到有效的调剂和放松。

 负面测试（Negative testing）是相对于正面测试（Positive testing）而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作；而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。
        正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，而负面测试则主要根据错误猜测，逆向思维来测试系统，一定程序上的的依赖测试人员的经验积累。
        执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。
        简言之负面测试的三部曲就是：
1． 检查程序中的屏幕或页面是否给出了清晰且充分的提示或约束；
2． 测试系统是否处理了用户的异常操作；
3． 检查系统的错误提示是否清晰且充分。
 
        以下是Steve Miller的《Top 10 Negative Test Cases》，概括性的提到了一些做负面测试时经常需要注意的测试。
 
        负面测试用例被设计于用软件未意欲被使用的方式测试软件，它也应该是测试工作的一部分。以下就是在设计测试工作量时你应该考虑的10大负面测试用例。
        1.植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。
        【Kiki补充】其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，<，>（对于web的应用程序）都是很容易引发错误的。在开发早期测试组就可以建议开发组写一个通用的函数来处理这些特殊字符，然后在处理用户的输入时套用这个函数就可以避免此类错误了。
 
        2.必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。
        【Kiki补充】对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段是否真的必须输入。
 
        3.字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）
        【Kiki补充】其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正确的处理。
 
        4.字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错误信息更加的文雅些。
        【Kiki补充】一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。
 
        5.数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一个得体的信息表示失败。
 
        6.数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从-2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。
        【Kiki补充】小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。
        不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。
 
        7.日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。
        【Kiki补充】一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。
 
        8。日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。
 
        9。web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。
 
        10.性能的改变。当发布产品的最新版本时，应该有一套运行于识别屏幕（列出信息的屏幕，add/update/delete数据的屏幕等等）速度的性能测试。测试包里应该包括比较先前版本和现有版本性能统计值的测试用例。这个可以帮助识别那些可以证明是随着对现有版本的代码变更而引起的潜在的性能问题。
 
        【Kiki补充】从第一条到第八条是我们在测试字段时常常需要做的测试，一般的测试人员都不陌生。第九条在测试web应用程序中会作为检查应用程序的安全性而做的一项测试。而第十条估计很多公司都不会将它考虑到测试的范畴中，一般最多也就是在测试用例中添加校验某一个操作是否在系统允许的响应时间里，很少去做这样的比较，除了一些有针对性的性能测试。

1引言 1.1编写目的 编写本方案的目的是用于指导XXXX系统的性能测试,主要从测试环境、测试工具、测试策略、测试具体执行方法、任务与进度表等事先计划和设计。 1.2适用范围 XXXX系统性能测试组 XXXX系统开发组 XXXX系统性能优化组 1.3参考资料 系统性能测试指南 1.4术语和缩写词 缩写、术语 解 释 性能测试 （performance testing） 运行这些测试通常要确定程序运行有多快，以便确定是否需要优化 负载测试 (load testing) 通过在面临很多资源要求的系统上运行，攻击被测程序或系统 可靠性测试 (reliability testing) 持续进行的性能测试，目标是发现短序列程序测试遗漏的情况 ……           2系统介绍 3测试环境 3.1网络拓扑图 3.2硬件环境 3.3软件环境 4测试范围与主要内容 测试范围： 如：XXXX系统各项性能指标，反应时间的性能测试、CPU、Memory的性能测试、负载的性能测试（压力测试）、可靠性测试 主要检测内容： 如： 1. 典型应用的反应时间 2. 客户端、服务器的CPU、Memory使用情况 3. 服务器的响应速度 4. 系统支持的最优负载数量 5. 网络指标 6. 系统可靠性测试 5测试工具和测试方法 5.1测试工具 MI（Mercury Interactive）公司的LoadRunner7.5.1创建虚拟用户脚本工具Virtual User Generator MI（Mercury Interactive）公司的LoadRunner7.5.1创建、运行实际场景工具Controller MI（Mercury Interactive）公司的LoadRunner7.5.1分析测试结果工具Analysis 性能监视器（MicroSoft Win2000自带） 5.2测试方法 5.2.1反应时间的性能测试 处理点或事件 期望的反应时间 实际反映时间平均值（至少3次） 上次或上版本实际反映时间平均值（至少3次）                                         测试结果分析： 5.2.2CPU、Memory的性能测试 条件： 1.客户端情况 2. 应用服务器情况 3.数据库服务器情况 测试结果分析： 5.2.3负载的性能测试（压力测试 输入/动作 输出/响应 能否正常运行 10个用户操作     20个用户操作     30个用户操作     50个用户操作     100个用户操作     ……     测试结果分析： 5.2.4可靠性测试 任务描述   连续运行时间 建议72小时 故障发生的时刻 故障描述         ……   统计分析 任务A无故障运行的平均时间间隔 （CPU小时） 任务A无故障运行的最小时间间隔 （CPU小时） 任务A无故障运行的最大时间间隔 （CPU小时） 测试结果分析： 5.2.5网络性能测试 对网络性能的测试，如网络流量、每秒采样数、网络延迟等。 6测试完成准则 系统满足各项性能要求、能满足实际使用情况并提供测试报告 7任务与进度表 8提交的文档和报告 XXXX系统性能测试方案 XXXX系统性能测试报告 XXXX系统性能测试脚本   作者: 张红辉    来源: UML软件工程组织

因为测试项目规模和范围的原因，我们的测试项目常常都是制定测试计划以后直接开始测试设计。最近在资料和网文中看到测试方案的字样，心想应该是和测试计划不同的东西。于是上网查了一下，找到了比较两者不同的内容并且整理了一下。

其实我们的测试计划中已经包含了测试方案的内容，即测试环境规划、测试工具选择以及测试用例设计方法等。只不过因为测试项目规模较小，我们把测试计划和测试方案放到了一起。
概念总归是概念，不必拘泥于此。如果测试项目规模较大的时候，把测试计划和测试方案适当分开，应该有利于整个测试项目运作和项目组间交流。