Transactions（用户事务分析）
　　用户事务分析是站在用户角度进行的基础性能分析。
　　1、Transation Sunmmary（事务综述）
　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
　　2、Average Transaciton Response Time（事务平均响应时间）
　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。
　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
　　3、Transactions per Second（每秒通过事务数/TPS）
　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。
　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。
　　4、Total Transactions per Second（每秒通过事务总数）
　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。
　　5、Transaction Performance Sunmmary（事务性能摘要）
　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
　　6、Transaction Response Time Under Load（事务响应时间与负载）
　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
　　7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
　　8、Transaction Response Time(Distribution)（事务响应时间(分布)）
　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。

Client/Server 测试
　　Roger S. Pressman
　　通常，客户 / 服务器软件的测试发生在三个不同的层次：
　　（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
　　（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
　　（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。
　　下面的测试方法是 C/S 应用中经常用到的：
　　应用功能测试 —— 客户端应用被独立地执行，以揭示在其运行中的错误。
　　服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
　　数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
　　事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
　　网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。
　　回归测试
　　Roger S. Pressman
　　每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。
　　在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。
　　回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。
　　回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
　　· 能够测试软件的所有功能的代表性测试用例。
　　· 专门针对可能会被修改影响的软件功能的附加测试。
　　· 针对修改过的软件成分的测试。
　　在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。
　　α 测试
　　α 测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，
　　α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。
　　α 测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。
　　β 测试
　　β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与 α 测试不同的是，开发者通常不在测试现场。因而， β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。
　　β 测试主要衡量产品的 FLURPS 。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时，才能开始 β 测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。 由于 β 测试的主要目标是测试可支持性，所以 β 测试应尽可能由主持产品发行的人员来管理。

单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
　　集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
　　集成测试的策略主要有自顶向下和自底向上两种。
　　系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，
　　其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
　　验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
　　回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：
　　一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
　　黑盒测试
　　黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
　　黑盒测试试图发现以下类型的错误：
　　1 ）功能错误或遗漏；
　　2 ）界面错误；
　　3 ）数据结构或外部数据库访问错误；
　　4 ）性能错误；
　　5 ）初始化和终止错误。
　　白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
　　1 ）如何测试功能的有效性？
　　2 ）何种类型的输入会产生好的测试用例？
　　3 ）系统是否对特定的输入值尤其敏感？
　　4 ）如何分隔数据类的边界？
　　5 ）系统能够承受何种数据率和数据量？
　　6 ）特定类型的数据组合会对系统产生何种影响？
　　运用黑盒测试方法，可以导出满足以下标准的测试用例集：
　　1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
　　2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。
　　白盒测试
　　Rex Black
　　白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
　　1 ）保证一个模块中的所有独立路径至少被使用一次；
　　2 ）对所有逻辑值均需测试 true 和 false ；
　　3 ）在上下边界及可操作范围内运行所有循环；
　　4 ）检查内部数据结构以确保其有效性。
　　“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？” 答案在于软件自身的缺陷：
　　1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、
　　条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ”
　　的处理则难于发现。
　　2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流
　　有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，
　　只有路径测试才能发现这些错误。
　　3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。
　　GUI 测试
　　Roger S. Pressman
　　图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。
　　下列问题可以作为常见 GUI 测试的指南：
　　窗口：
　　· 窗口是否基于相关的输入和菜单命令适当地打开？
　　· 窗口能否改变大小、移动和滚动？
　　· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
　　· 当被覆盖并重新调用后，窗口能否正确地再生？
　　· 需要时能否使用所有窗口相关的功能？
　　· 所有窗口相关的功能是可操作的吗？
　　· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，
　　并适当地显示？
　　· 显示多个窗口时，窗口的名称是否被适当地表示？
　　· 活动窗口是否被适当地加亮？
　　· 如果使用多任务，是否所有的窗口被实时更新？
　　· 多次或不正确按鼠标是否会导致无法预料的副作用？
　　· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
　　· 窗口是否正确地被关闭？
　　下拉式菜单和鼠标操作：
　　· 菜单条是否显示在合适的语境中？
　　· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
　　· 下拉式操作能正确工作吗？
　　· 菜单、调色板和工具条是否工作正确？
　　· 是否适当地列出了所有的菜单功能和下拉式子功能？
　　· 是否可以通过鼠标访问所有的菜单功能？
　　· 文本字体、大小和格式是否正确？
　　· 是否能够用其他的文本命令激活每个菜单功能？
　　· 菜单功能是否随当前的窗口操作加亮或变灰？
　　· 菜单功能是否正确执行？
　　· 菜单功能的名字是否具有自解释性？
　　· 菜单项是否有帮助，是否语境相关？
　　· 在整个交互式语境中，是否可以识别鼠标操作？
　　· 如果要求多次点击鼠标，是否能够在语境中正确识别？
　　· 光标、处理指示器和识别指针是否随操作恰当地改变？
　　数据项：
　　· 字母数字数据项是否能够正确回显，并输入到系统中？
　　· 图形模式的数据项（如滚动条）是否正常工作？
　　· 是否能够识别非法数据？
　　· 数据输入消息是否可理解？ 

（1）、性能优化工具EcoScope
EcoScope是一套定位于应用（即服务提供者本身）及其所依赖的所有网络计算资源的解决方案。EcoScope可以提供应用视图，并标出应用是如何与基础架构相关联的。这种视图是其他网络管理工具所不能提供的。EcoScope能解决在大型企业复杂环境下分析与测量应用性能的难题。通过提供应用的性能级别及其支撑架构的信息，EcoScope能帮助IT部门就如何提高应用性能提出多方面的决策方案。
EcoScope的应用主要表现在以下几个方面：
确保成功部署新应用
维护性能的服务水平
加速问题检测与纠正的高级功能
定制视图有助于高效地分析数据
（2）、数据库测试数据自动生成工具——TestBytes
在数据库开发的过程中，为了测试应用程序对数据库的访问，应当在数据库中生成测试用例数据，我们可能会发现当数据库中只有少量数据时，程序可能没有问题，但是当真正投入到运用中产生了大量数据时就出现问题了，这往往是因为程序的编写没有达到，所以一定及早地通过在数据库中生成大量数据来帮助开发人员完善这部分功能和性能。
TestBytes是一个用于自动生成测试数据的强大易用的工具，通过简单的点击式操作，就可以确定需要生成的数据类型（包括特殊字符的定制），并通过与数据库的连接来自动生成数百万行正确的测试数据，可以极大地提高数据库开发人员、QA测试人员、数据仓库开发人员、应用开发人员的工作效率。
（3）、PC—LINT
PC—LINT 主要进行更严格的语法检查功能，还完成相当程度的语义检查功能。可以这样认为：PC—LINT是一个更加智能、更加严格的编译器。PC—LINT在实现语法和某些语义规则检查时，是通过参数配置完成的，它的选项就有数百个之多，因此，在使用PC—LINT过程中，了解选项的含义也很重要。
（4）、TCL
TCL是Tool Command Language的缩写，它是一种很流行的脚本解释器，尤其在测试领域，它的最大特点是可移植性好，接口简单，方便，可以很容易地嵌入到软件中，作为自己的解释器使用。
TCL提供两种接口：编程接口和用户接口。编程接口是通过LIB或DLL形式提供的，提供了一些函数（命令）供调用，包括：分配一个解释器指针（对象）；初始化解释器（指针）；注册扩展函数等。用户接口很简单，即编写的脚本，脚本里面包含对扩展命令的调用。
（5）VB测试工具：VB Watch
（6）Java 程序的测试工具
1）Bean—Test
2）EJBQuickTest
3）JStyle
4）JTest
5）HttpUnit
6）JUnit
（7）、覆盖测试
C—Cover
C—Cover是一个测试工具软件，用来找出没有被测到的代码，并报告测试的覆盖率。C—Cover
只支持C/C++的代码覆盖率分析，其它语言不支持。但不受OS的限制。

单元测试方面：（对开发人员比较有用） J-Unit工具。
功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。
如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。
另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序， 如SMTP Server等。 这两个工具都是使用Post URL的方法测试Web Application的。对大量使用Javascrīpt的页面不太适合。 当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。
另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。
另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。 至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。
测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试 白盒测试工具主要有：
内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等
代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等 代码性能检查：Numega中的truetime,Rational的Quantify等
代码静态度量分析质量检查工具：logiscope和Macabe等
黑盒测试工具主要有： 客户端功能测试：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
服务器端压力性能测试： MI公司的winload,compuware的qaload,Rational的SQA load等等
Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等
测试管理工具：rational的test manager,compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。
数据库测试工具:TestBytes
黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。
回归测试工具：Rational TeamTest，WinRunner（MI公司）
WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）
白盒测试工具：Numega 、PuRe、软件纠错工具（Rational Purity）。
嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。
系统负荷测试工具：RationalPerformance
涵盖测试工具范围评估工具
软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify
测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理）
　　　　　　　 IBM-testmanage ；　compureware-trackrecord
　　　　　　　 微创的TCM
嵌入软件测试工具：codetest 

1、说明：创建数据库
　　CREATE DATABASE database-name
　　2、说明：删除数据库
　　drop database dbname
　　3、说明：备份sql server
　　--- 创建 备份数据的 device
　　USE master
　　EXEC sp_addumpdevice 'disk', 'testBack', 'c:mssql7backupMyNwind_1.dat'
　　--- 开始 备份
　　BACKUP DATABASE pubs TO testBack
　　4、说明：创建新表
　　create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)
　　根据已有的表创建新表：
　　A：create table tab_new like tab_old (使用旧表创建新表)
　　B：create table tab_new as select col1,col2… from tab_old definition only
　　5、说明：删除新表
　　drop table tabname
　　6、说明：增加一个列
　　Alter table tabname add column col type
　　注：列增加后将不能删除。DB2中列加上后数据类型也不能改变，唯一能改变的是增加varchar类型的长度。
　　7、说明：添加主键： Alter table tabname add primary key(col)
　　说明：删除主键： Alter table tabname drop primary key(col)
　　8、说明：创建索引：create [unique] index idxname on tabname(col….)
　　删除索引：drop index idxname
　　注：索引是不可更改的，想更改必须删除重新建。
　　9、说明：创建视图：create view viewname as select statement
　　删除视图：drop view viewname
　　10、说明：几个简单的基本的sql语句
　　选择：select * from table1 where 范围
　　插入：insert into table1(field1,field2) values(value1,value2)
　　删除：delete from table1 where 范围
　　更新：update table1 set field1=value1 where 范围
　　查找：select * from table1 where field1 like ’%value1%’ ---like的语法很精妙，查资料!
　　排序：select * from table1 order by field1,field2 [desc]
　　总数：select count as totalcount from table1
　　求和：select sum(field1) as sumvalue from table1
　　平均：select avg(field1) as avgvalue from table1
　　最大：select max(field1) as maxvalue from table1
　　最小：select min(field1) as minvalue from table1
　　11、说明：几个高级查询运算词
　　A： UNION 运算符
　　UNION  运算符通过组合其他两个结果表（例如 TABLE1 和 TABLE2）并消去表中任何重复行而派生出一个结果表。当 ALL 随 UNION 一起使用时（即 UNION ALL），不消除重复行。两种情况下，派生表的每一行不是来自 TABLE1 就是来自 TABLE2。
　　B： EXCEPT 运算符
　　EXCEPT 运算符通过包括所有在 TABLE1 中但不在 TABLE2 中的行并消除所有重复行而派生出一个结果表。当 ALL 随 EXCEPT 一起使用时 (EXCEPT ALL)，不消除重复行。
　　C： INTERSECT 运算符
　　INTERSECT 运算符通过只包括 TABLE1 和 TABLE2 中都有的行并消除所有重复行而派生出一个结果表。当 ALL 随 INTERSECT 一起使用时 (INTERSECT ALL)，不消除重复行。
　　注：使用运算词的几个查询结果行必须是一致的。
　　12、说明：使用外连接
　　A、left outer join：
　　左外连接（左连接）：结果集几包括连接表的匹配行，也包括左连接表的所有行。
　　SQL: select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
　　B：right outer join:
　　右外连接(右连接)：结果集既包括连接表的匹配连接行，也包括右连接表的所有行。
　　C：full outer join：
　　全外连接：不仅包括符号连接表的匹配行，还包括两个连接表中的所有记录。

　　一、定义基本表
　　SQL语言使用CREATE TABLE语句定义基本表，其一般格式如下：
　　CREATE TABLE <表名>(<列名><数据类型>[列级完整性约束条件]
　　[,<列名><数据类型>[列级完整性约束条件]]……
　　[，<表级完整性约束条件>])；
　　例1 建立一个“学生”表student,它由学号Sno、姓名Sname、性别Ssex、年龄Sage、所在系Sdept五个属性组成。其中学号不能为空，值是唯一的，并且姓名取值也唯一。
　　CREATE TABLE Student
　　(Sno CHAR(5) NOT NULL UNIQUE, /*列级完整性约束条件，Sno取值唯一，不许取空值*/
　　Sname CHAR(20) UNIQUE,
　　Ssex CHAR(1),
　　Sage INT,
　　Sdept CHAR(15));
　　定义表的各个属性时需要指明其数据类型及长度。
　　SMALLINT 半字长二进制整数。
　　INTEGER或INT 全字长二进制整数。
　　DECIMAL(p[,q]) 压缩十进制数，共P位，其中小数后有q
　　或DEC(p[,q]) 位。0<=q<=p<=15,q=0时可以省略不写。
　　FLOAT 双字长浮点数。
　　CHARTER(n)或CHAR(n) 长度为n的定长字符串。
　　VARCHAR(n) 最大长度为n的变长字符串。
　　GRAPHIC(n) 长度为n的定长图形字符串。
　　VARGRAPHIC(n) 最大长度为n的变长图形字符串。
　　DATE 日期型，格式为YYYY-MM-DD。
　　TIME 时间型，格式为HH.MM.SS。
　　TIMESTAMP 日期加时间。
　　二、修改基本表
　　SQL语言使用ALTER TABLE 语句修改基本表，其一般格式如下：
　　ALTER TABLE <表名>
　　[ADD<新列名><数据类型>[完整性约束]]
　　[DROP<完整性约束名>]
　　[MODIFY<列名><数据类型>]；
　　例2 向Student表增加“入学时间”列，其数据类型为日期型。
　　ALTER TABLE Student ADD Scome DATE；
　　例3 将年龄的数据类型改为半字长整数。
　　ALTER TABLE Student MODIFY Sage SMALLINT;
　　三、删除基本表
　　当某个基本表不再使用时，可以使用DROP TABLE语句删除它。其一般格式为：
　　DROP TABLE <表名>;
　　例4 删除Student表。
　　DROP TABLE Student;
　　一、建立索引
　　SQL语言中，建立索引使用CREATE INDEX语句，其一般格式为：
　　CREATE[UNIOUE][CLUSTER]INDEX<索引名>
　　ON <表名>(<列名>[<次序>][，<列名>[<次序>]]……)；
　　UNIQUE 表明此索引的每一个索引值只对应唯一的数据记录。
　　CLUSTER 表示要建立的索引是聚簇索引，所谓聚簇索引是指索引项的顺序与表中记录的物理顺序一致的索引组织。
　　二、删除索引
　　SQL语言中，删除索引使用DROP INDEX语句，其一般格式为：
　　DROP INDEX <索引名>
　　3.3 查询
　　查询的一般格式为：
　　SELECT[ALL|DISTINCT] <目标列表达式>[，<目标列表达式>]……
　　FROM<表名或视图名>[,<表名或视图名>]……
　　[WHERE <条件表达式>]
　　[GROUP BY<列名1>[HAVING<条件表达式>]]
　　[ORDER BY<列名2>[ASC|DESC]]；
　　3.3.1 单表查询
　　一、选择表中若干列
　　1.查询指定列
　　例7：查询全体学生的学号与姓名。
　　SELECT Sno，Sname
　　FROM Student；
　　2.查询全部列
　　例8 查询全体学生的详细记录。
　　SELECT *
　　FROM Student； 等价于： SELECT Sno，Sname，Ssex,Sage,Sdept
　　FROM Student;
　　3.查询经过计算的值
　　例9 查全体学生的姓名及其出生年份
　　SELECT Sname，1996-Sage
　　FROM Student；
　　3.3 查询
　　查询的一般格式为：
　　SELECT[ALL|DISTINCT] <目标列表达式>[，<目标列表达式>]……
　　FROM<表名或视图名>[,<表名或视图名>]……
　　[WHERE <条件表达式>]
　　[GROUP BY<列名1>[HAVING<条件表达式>]]
　　[ORDER BY<列名2>[ASC|DESC]]；
　　二、选择表中的若干元组
　　1.消除取值重复的行
　　两个本来并不完全相同的元组，投影到指定的某些列上后，可能变成相同的行了。
　　例 10 查询选修了课程的学生学号。
　　SELECT Sno
　　FROM SC;
　　该查询结果里包含了许多重复的行。如果想去掉结果表中的重复项，必须指定DISTINCT短语：
　　SELECT DISTINCT Sno
　　FROM SC；
　　如果没有指定DISTINCT短语，则缺省为ALL，即保留结果表中的重复的行。
　　3.3 查询
　　查询的一般格式为：
　　SELECT[ALL|DISTINCT] <目标列表达式>[，<目标列表达式>]……
　　FROM<表名或视图名>[,<表名或视图名>]……
　　[WHERE <条件表达式>]
　　[GROUP BY<列名1>[HAVING<条件表达式>]]
　　[ORDER BY<列名2>[ASC|DESC]]；
　　二、选择表中的若干元组
　　2.查询满足条件的元组。
　　(1)比较大小
　　查询满足条件的元组可以通过WHERE子句实现。
　　用与进行比较的运算符一般包括：
　　=(等于)，>(大于),<(小于),>=(大于等于),<=(小于等于),!=或<>(不等于)。
　　还包括：!>(不大于),!<(不小于)。
　　例11 查询所有年龄在20岁以下的学生姓名及年龄。
　　SELECT Sname,Sage
　　FROM Student
　　WHERE Sage<20;
　　或 SELECT Sname,Sage
　　FROM Student
　　WHERE NOT Sage>=20;
　　(2)确定范围
　　谓词BETWEEN……AND……和NOT BETWEEN……AND……可以用来查询属性值在（或不在）指定范围内的元组，其中BETWEEN后是范围的下限（即低值），AND后是范围的上限（即高值）。
　　例12 查询年龄不在20 ~23岁之间的学生姓名、系别和年龄。
　　SELECT Sname,Sdept,Sage
　　FROM Student
　　WHERE Sage NOT BETWEEN 20 AND 23;
　　(3)确定集合
　　谓词IN可以用来查找属性值属于指定集合的元组。
　　例13 查询信息系（IS）、数学系（MA）和计算机科学系（CS）学生的姓名和性别。
　　SELECT Sname,Ssex
　　FROM Student
　　WHERE Sdept IN('IS'，'MA'，'CS')
　　(4)字符匹配
　　谓词LIKE可以进行字符串的匹配。其一般格式如下：
　　[NOT]LIKE奇<匹配串>‘[ESCAPE奇<换码字符>']
　　.%(百分号) 代表任意长度（长度可以为0）的字符串。例如a%b表示以a开头，以b结尾的任意长度的字符串。
　　._(下横线) 代表任意单个字符。
　　例14 查询学号为95001的学生的详细情况。
　　SELECT *
　　FROM Student
　　WHERE Sno LIKE'95001';
　　等价于：SELECT *
　　FROM Student
　　WHERE Sno ='95001';
　　例15 查询名字第二个字为“阳”字的学生的姓名和学号。
　　SELECT Sname,Sno
　　FROM Student
　　WHERE Sname LIKE'_ _阳%';
　　如果用户查询的字符串的字符串本身就含有%或_ _,这时就要使用ESCAPE '<换码字符>'短语对通配符进行转义了。
　　例16 查询以“DB_”开头，且倒数第3个字符为i的课程的详细情况。
　　SELECT *
　　FROM Course
　　WHERE Cname LIKE 'DB\_%i_ _'ESCAPE'\';
　　(5)涉及空值的查询
　　例17 查询所有有成绩的学生学号和课程号。
　　SELECT Sno,Cno
　　FROM SC
　　WHERE Grade IS NOT NULL;
　　(6)多重条件查询
　　逻辑运算符AND和OR可用来联结多个查询条件。AND的优先级高于OR，但用户可以用括号改变优先级。
　　例18 查询计算机系年龄在20岁以下的学生姓名。
　　SELECT Sname
　　FROM Student
　　WHERE Sdept='cs'AND Sage<20;
　　四、使用集函数
　　SQL提供的集函数主要有：
　　COUNT([DISTINCT|ALL]*) 统计元组个数
　　COUNT([DISTINCT|ALL]<列名>) 统计一列中值的个数（空值不计）
　　SUM ([DISTINCT|ALL]<列名>) 计算一列值的总和（此列必须是数值型）
　　AVG([DISTINCT|ALL]<列名>) 计算一列值的平均值（此列必须是数值型）
　　MAX([DISTINCT|ALL]<列名>) 求一列值中的最大值
　　MIN([DISTINCT|ALL]<列名>) 求一列值中的最小值
　　五、对查询结果分组
　　GROUP BY子句将查询结果表按某一列或多列值分组，值相等的为一组。如果
　　分组后还要求按一定的条件对这些组进行筛选，最终只输出满足指定条件的
　　组，则可以使用HAVING短语指定筛选条件。
　　连接查询
　　若一个查询同时涉及两个以上的表，则称之为连接查询。
　　一、等值与非等值连接
　　当连接运算符为＝时，称为等值连接。
　　若在等值连接中把目标列中重复的属性列去掉则为自然连接。
　　例：查询每个学生及其选修课程的情况
　　SELECT Student.*,SC.*
　　FROM Student,SC
　　WHERE Student.Sno=SC.Sno;
　　二、外连接
　　例：SELECT Student.Sno,SNAME,Cno,Grade
　　FROM Student LEFT JOIN SC
　　WHERE Student.Sno=SC.Sno;
　　三、复合条件连接
　　WHERE子句中可以有多个连接条件，称为复合条件连接。
　　例：查询选修2号课程且成绩在90分以上的所有学生
　　SELECT Student.Sno,SNAME
　　FROM Student,SC
　　WHERE Student.Sno=SC.Sno AND SC.Cno=奇2奇 AND SC.Grade>90;
　　3.4 数 据 更 新
　　SQL中数据更新包括插入数据、修改数据和删除数据三条语句。  
　　3.4.1 插入数据
　　SQL的数据插入语句INSERT通常有两种形式。
　　一、插入单个元组
　　插入单个元组的INSERT语句的格式为：
　　INSERT
　　INTO<表名>[<属性列1>[,<属性列2>...)]
　　VALUES(<常量1>[,<常量2>]...)
　　例1 插入一条选课记录('95020','1')
　　INSERT
　　INTO SC(Sno,Cno)
　　VALUES('95020','1')
　　新插入的记录在Grade列上取空值。
　　二、插入子查询结果
　　插入子查询结果的INSERT语句的格式为：
　　INSERT
　　INTO<表名>[<属性列1>[,<属性列2>...)]
　　子查询；
　　例3 对每一个系，求学生的平均年龄，并把结果存入数据库。
　　CREATE TABLE Deptage
　　(Sdept CHAR(15)
　　Avgage SMALLNT);
　　然后对表按系分组求平均年龄,再把系名和平均年龄存入新表中。
　　INTERT
　　INTO Deptage(Sedpt,Avgage)
　　SELECT Sdept,AVG(Sage)
　　FROM Student
　　GROUP BY Sdept;
　　修改数据
　　修改操作语句的一般格式为:
　　UPDATE <表名>
　　SET<列名>=<表达式>[,<列名>=<表达式>]...
　　[WHERE<条件>];
　　一、 修改某一个元组的值
　　例4 将学生95001的年龄改为22岁。
　　UPDATE Student
　　SET Sage=22；
　　WHERE Sno='95001'；
　　二、修改多个元组的值
　　例5 将所有学生的年龄增加1岁。
　　UPDATE Student
　　SET Sage=Sage+1；
　　三、带子查询的修改语句
　　子查询也可以嵌套在UPDATE语句中。
　　例6 将计算机科学系全体学生的成绩置零。
　　UPDATE SC
　　SET Grade=0
　　WHERE 'CS'=
　　(SELECT Sdept
　　FROM Student
　　GROUP Student.Sno=SC.Sno);
　　删除数据
　　删除语句的一般格式为:
　　DELETE
　　FROM<表名>
　　[WHERE<条件>];
　　一、删除某一个元组的值
　　例7 删除学号为95019的学生记录。
　　DELETE
　　FROM Student
　　WHERE Sno='95019';
　　二、删除多个元组的值
　　例8 删除所有的学生的选课记录
　　DELETE
　　FROM SC；
　　三、带子查询的删除语句
　　例9 删除计算机科学所有学生的选课记录。
　　DELETE
　　FROM SC
　　WHERE 'CS'=
　　(SELECT Sdept
　　FROM Student
　　GROUP Student.Sno=SC.Sno);
　　建立视图
　　SQL语言用CREATE VIEW命令建立视图，其一般格式为：
　　CREATE VIEW[<列名>[,<列名>]...)]
　　AS <子查询>
　　[WITH CHECK OPTION];
　　子查询不允许含有ORDER BY 子句和DISTINCT短语。
　　例1 建立信息系学生的视图。
　　CREATE VIEW IS_Student
　　AS
　　SELECT Sno,Sname,Sage
　　FROM Student
　　WHERE Sdept='IS';
　　本例中省略了视图IS_Student的列名,隐含了由子查询中SELECT子句中的三个列名组成。
　　二、删除视图
　　该语句的格式为：
　　DROP VIEW <视图名>;
　　例8 删除视图IS_S1
　　DROP VIEW IS_S1;
　　执行此语句后, IS_S1视图的定义将从数据字典中删除。
　　视图的作用
　　视图最终是定义再基本表之上的，对视图的一切操作最终也要转换为对基本表的操作。而
　　且对于非行列子集视图进行查询和更新时还有可能出现问题。既然如此，为什么还要定义视图
　　呢？这是因为合理使用视图能够带来许多好处。
　　1.视图能够简化用户的操作
　　2.视图使用户能以多种角度看待同一数据
　　3.视图对重构数据库提供了一定程度的逻辑独立性
　　4.视图能够对机密数据提供安全保护

1、测试准备工作
　　在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处下手呢？
　　2、向有经验的测试人员学习
　　如果你进入的是一家运作规范的软件公司，有独立的软件测试部门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方式固化到流程中。
　　如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。
　　3、阅读软件测试的相关书籍
　　现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。
　　4、 走读缺陷跟踪库中的问题报告单
　　如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。
　　5、 走读相关产品的历史测试用例
　　如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。
　　通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用例的输出结果等。
　　总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。

6、学习产品相关的业务知识
　　软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。
　　因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折扣。
　　7、 识别测试需求
　　识别测试需求是软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法：
　　8、 主动获取需求
　　开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。
　　当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析：
　　软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部分内容作为测试用例输入的依据。
　　处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。
　　软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测试用例设计中，这部分内容作为测试用例的预期输出。
　　性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制，就是对需求的基本性能要求。
　　运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。
　　9、 确认需求的优先级
　　确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完成了。
　　10、加入开发小组的邮件群组
　　测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。
　　11、 与开发人员为邻
　　建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。
　　A 测试用例设计
　　测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题：
　　测试用例的基本格式
　　软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。
　　用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
　　测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。
　　重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，
　　测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
　　操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
　　预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
　　软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。
　　B　 重用同类型项目的测试用例
　　一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。
　　利用已有的软件 Checklist
　　在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。
　　加强测试用例的评审
　　测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起。
　　定义测试用例的执行顺序
　　在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。
　　测试用例执行
　　测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题：
　　搭建软件测试环境，执行测试用例
　　测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。
　　如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。
　　测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：
　　全方位的观察测试用例执行结果：测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源，后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察点单一，这个严重消耗资源的问题就无从发现了。
　　加强测试过程记录：测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
　　及时确认发现的问题：测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
　　与开发人员良好的沟通：测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。
　　及时更新测试用例
　　测试执行过程中，应该注意及时更新测试用例。往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
　　总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。
　　提交一份优秀的问题报告单
　　软件测试提交的问题报告单和测试日报一样，都是软件测试人员的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ，这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。
　　软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本等。
　　硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件配置情况。
　　测试用例输入 \ 操作步骤 \ 输出： 这部分内容可以根据测试用例的描述和测试用例的实际执行情况如实填写。
　　输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图，其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提供描述。
　　日志信息： 规范的软件产品都会提供软件的运行日志和用户、管理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志和操作日志作为附件，提交到问题报告单中。
　　根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相应的描述内容，这需要具体问题具体分析。
　　测试结果分析
　　软件测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中，建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中，每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区，必定会在下一轮测试用避免盲区。

 

　测试用例编写规范
　　一、测试用例编写准备
　　从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
　　二、测试用例制定的原则
　　测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
　　1、    正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
　　2、    容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
　　3、    完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
　　4、    接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
　　5、    数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
　　6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
　　7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。
　　8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
　　9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
　　11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
　　12、可移植性：在不同操作系统及硬件配置情况下的运行性。
　　13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。
　　14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。
　　说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。
　　1、  其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。
　　2、  单元（模块）测试（组件、控件）测试：重点测试第5项。
　　3、  组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。
　　4、  系统测试：重点测试第3、7、10、11、12、14项。
　　5、  其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。
　　6、  GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。
　　7、  对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
　　三、测试用例的填写
　　一个软件系统或项目共用一套完整的测试用例，整个系统测试过程测试完毕，将实际测试结果填写到测试用例中，操作步骤应尽可能的详细，测试结论是指最终的测试结果（结论为：通过或不通过）。

四、测试用例在软件测试中的作用
　　1、指导测试的实施
　　测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。
　　根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。
　　2、规划测试数据的准备
　　在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
　　除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。
　　3、编写测试脚本的"设计规格说明书"
　　为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。
　　4、评估测试结果的度量基准
　　完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。
　　5、分析缺陷的标准
　　通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。
　　五、相关问题
　　1、测试用例的评审
　　测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。
　　2、测试用例的修改更新
　　测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
　　一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。
　　3、测试用例的管理软件
　　运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。
　　有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

　测试工作也从简单测试演变为包括：编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。测试方式则由单纯手工测试发展为手工、自动兼之，并有向第三方专业测试公司发展的趋势。
　　一、测试用例是软件测试的核心
　　软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。
　　影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人员）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。
　　因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。
　　二、什么叫测试用例
　　测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
　　不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。
　　三、编制测试用例
　　着重介绍一些编制测试用例的具体做法。
　　1、测试用例文档
　　编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。
　　软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。
　　测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。
　　2、测试用例的设置
　　我们早期的测试用例是按功能设置用例。后来引进了路径分析法，按路径设置用例。目前演变为按功能、路径混合模式设置用例。
　　按功能测试是最简捷的，按用例规约遍历测试每一功能。
　　对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。
　　但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要靠传统方法来解决。这是按功能、路径混合模式设置用例的由来。
　　3、设计测试用例
　　测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。
　　设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。
　　可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。 

1、鱼鱼是一个需要爱情来滋润的星座，有一句话鱼鱼很认同：如果没有温暖的爱情，那么越聪明也就越悲哀。鱼鱼常常认为爱情是不需要理由的，鱼鱼的爱是有很多盲点的，她基本是属于爱屋及乌的类型，她爱你，就会尽量包容你的缺点。但是前提是：你们彼此相爱、彼此真诚，如果你让鱼鱼感觉到你对她不真诚，那会让她很没有安全感，不值得再那么包容地爱下去，时间长了，鱼鱼就会游走的。

2、鱼在感情方面是奉行“三不政策”的（不拒绝、不负责、不主动），这是星座上总结的，但我感觉真的很贴切！所以如果你喜欢鱼鱼，就一定要主动积极地去追求，只要鱼鱼看你还顺眼，性格也可以相处，通常不会拒绝你的。鱼鱼在感情是需要你去引导的，你要温柔地带着她走下去，慢慢让她依赖你。

3、鱼鱼讨厌对什么事都很消极、漠然的人，所以在生活中、工作中你要尽量表现出你积极上进的一面，鱼鱼会非常欣赏，你的事业心可以很强，鱼鱼可以理解你，但是你也要记住：在工作间隙或结束后，给鱼鱼打个电话或发个信息，哪怕只是三言两语，也已足够。千万不要表现出不愿和鱼鱼沟通的样子，恋爱的过程是需要不断磨合、不断沟通的，这样才会让爱情更加坚固、持久。

4、你什么都可以忘记，比如什么纪念日等等，因为鱼鱼平时是挺迷糊，也挺随性的，对这些日子恐怕也不见得会特别去记住。就算她记住了，你没记，鱼鱼也不会怪你，但鱼鱼的生日不要忘记。

5、鱼鱼是个很讨厌压力的星座，遇到困难、碰到压力，她会本能的想逃跑，所以你要给她适当的自由空间，她会更喜欢你的。

6、鱼鱼的生活就是很随性的那种，没有太多的规律可言，一切都是自自然然，随心情而定。你可以在早晨或是夜晚打电话给她，或是发信息给她，只要你想她了，随时都可以告诉她，她不会烦，会很享受，因为这表明你在乎她。

7、在鱼鱼面前，你不用表现得特别优秀，没有缺点，表现出你最自然、最本真的一面就好了，太优秀反而缺乏真实感，会让鱼鱼萌生小小的自卑，使你们有距离。
适当暴露出一点小缺点，鱼鱼会想要去拯救你，hoho 这会让鱼鱼觉得很有成就感的。嘿嘿～～别笑话鱼鱼啊～

8、鱼鱼最喜欢的是一种很温情舒服的感觉  是一种简单没有负担的爱  那种强悍的温柔用鱼鱼也很管用。

9、鱼鱼很情绪化，所以你就不要太情绪化了，适当的忧郁一下，鱼鱼会心疼你，温柔地安慰你，但是如果你的情绪比鱼鱼还要来得猛烈，那么鱼鱼会怕你的，会逃跑的。

 

10、鱼鱼喜欢比自己成熟一些的人，但是成熟而又不乏纯真的你，会让鱼鱼更着迷。

 

作者：李瑛

我骄傲，我是一棵树
我骄傲，我是一棵树，
我是长在黄河岸边的一棵树；
我是长在长城脚下的一棵树；
我能讲许许多多的故事，
我能唱许多许多支歌。

山教育我昂首屹立，
我便矢志坚强不仆；
海教育我坦荡磅礴，
我便永远正直地生活；
条条光线，颗颗露珠，
赋予我美的心灵；
熊熊炎阳，茫茫风雪，
铸就了我斗争的品格；
我拥抱着——
自由的大气和自由的风，
在我身上，意志、力量和理想，
紧紧的，紧紧的融合。

我是广阔田野的一部分，大自然的一部分，
我和美是一个整体，不可分割；
我属于人民，属于历史，
我渴盼整个世界
都作为我们共同的祖国。

无论是红色的、黄色的、黑色的土壤，
我都将顽强地、热情地生活。

哪里有孩子的哭声，我便走去，
用柔嫩的枝条拥抱他们，
给他们一只只红艳艳的苹果；
哪里有老人在呻吟，我便走去，
拉着他们黄色的、黑色的、白色的多茧的手，
给他们温暖，使他们欢乐。

我愿摘下耀眼的星星，
给新婚的嫁娘，
作她们闪光的耳环；
我要挽住轻轻的云霞，
给辛勤的母亲，
作她们擦汗的手帕。

雨雪纷飞——
我伸展开手臂覆盖他们的小屋，
作他们的伞，
使每个人都有宁静的梦；
月光如水——
我便弹响无弦琴，
抚慰他们劳动回来的疲倦的身子，
为他们唱歌。
我为他们抗击风沙，
我为他们抵御雷火。
我欢迎那样多的小虫——
小蜜蜂、小螳螂，小蝴蝶，
和我一起玩耍；
我拥抱那样多的小鸟——
长嘴的，长尾巴的，花羽毛的小鸟，
在我的肩头作窠。

假如有一天，我死去，我便平静的倒在大地上，
我的年轮里有我的记忆，我的懊悔，
我经受的隆隆的暴风雪的声音，
我脚下的小溪淙淙流响的歌；
甚至可以发现熄灭的光、熄灭的灯火，
和我引为骄傲的幸福和欢乐……

那是我对泥土的礼赞，
那是我对大地的感谢；
如果你俯下身去，会听见，
我的每一个细胞都在轻轻地说：
让我尽快地变成煤炭
——沉积在地下的乌黑的煤炭，
为的是将来献给人间
纯洁的光，
炽烈的热！

人生最痛苦的事情不是口喝没水渴，而是有钱，水也在面前就是不卖给你。

人倒霉的时候连喝水都塞牙，这不昨天连水都没的渴！神啊！

最近几天总是不顺，郁闷到了极点。

前天，台风来袭，因是周末，去了一位朋友家玩，星期天晚上回家，我简直蒙了。屋子全部是水，而且还有垃圾。

房东说请人帮我清理，清理？最好的办法尽快搬离此地！有一次就有第二次。

早上上班，发现桌上两本笔记本不见了，还用几张报纸。我想应该是打扫的人拿走了，因为她已经拿过几次了，

这次尽连笔记本也拿走了。（她不故意拿笔记本的，可能拿报纸的时没看见。或者觉得差不多写完，没什么用

）她说报纸已经买了。几张报纸可以卖到美元吗？我是心痛我笔记本，近一年半的工作记录，哎。。。

天气太沉闷了，想出去溜达一下，下楼没走十步，发现开始下雨了。无耐上去拿伞。

再次出来是十几分钟后，没走几步，隐约看见个较熟悉的身影，是公司领导。

这也太巧了，他倒是干脆，问了我句“出去啊？”我“嗯”了一声。

上班时间出去，真的不好！

回来时，发现电梯环了。“电梯维修”，请勿使用！发狂！

在上楼时我想，可能公司大小领导会一同出现。

我的心好脆弱啊！

 今天是周三，感觉像过了半个月那样久，上周六去笔试了两家公司，笔试都通过了，其中一家当天就面试了技术主管，感觉不错，技术主管感觉为人挺低调的，我喜欢这样的上司。

  昨天收到另外一家的E－mail复试通知，心情比较激动，因为在做题时，我有一部分题目（分三部分）没有点击“提交”按钮，觉得不会有成绩。过后那个悔啊，真想撞墙。

  到面试地点后，填了份信息表，来的人明显比周六的人少的多。也看见了笔试时的一位女生，她是那天我唯一有点印象的人，因为她穿着比较正式（不过我觉得太正式了，好像没那个必要），其他的人都没有去注意。

 填完表后一位HR领我上楼，在上楼时，我往上看了一下，从一扇门的玻璃处看见几个人一排坐在那，当时心里就有点怕怕，可能有心里的阴影，我比较怕这种面试方式（不是紧张）。（我毕业时参加公务员面试，当时一个圆桌上坐满了考官，主考官更像是位法官，流汗）。

 打开门HR就让我进去了，坐下后，让我自我介绍下。三分钟后，中间那位开始询问了，问我会不会什么业界主流测试主具，我说不会，在××用的都是公司自己开发的工具。

问“你为什么离开公司？”答：经常要加班，一周要加四天班。。。

问“我们公司一周要加五天班，不加班那是完不成任务的”。

听完后，我就想笑，其他二位可能也觉得很好玩，也笑了笑，其实我明白他的意思，我说在那加班是一种习惯，要不能会被头们看成是不好学，不求上进。（个人观点），我不想为了加班而加班，如果是为了项目，则无可厚非。

  我在举例时举错了，中间那位指出来了，当时真想找个洞往下钻，不过我觉得自己在当时做事了，有点试图掩饰的言语，作为资深人士(不过比他牛的人我也见过，这个人感觉不低调)，这点东东他怎么看不出来.不知道自己怎么说错了。

  问“如果开发人员不认同你的BUG，你怎样处理？

答：首先自己再重新定位一遍，再和组内其他人员讨论一下，听听其他人的观点，对应需求说明书看看与否有出入，确定后再与开发人员讨论。

问“你有没有和开发人员一起定位过问题”？对这个问题我当时心里空白，不知怎样答，多半是答非所问。

中间这位应该还问了二个问题，但是现在我忘记了，我觉得他提的问题都很好，除了他说公司要加五天班。

  右边的女士很友好，问我怎样学习测试理论知识和测试工具的，我答，主要通过自学。

问：“什么方式”

答：上测试论坛、下载学习资料。

问：“什么论坛？”

答：51testing   测试时代。

问“你最近下了些什么资料学习？”当时听了我心想，你真狠啊， 我说下了WR的操作手册。 

最后HR问了我要多少钱，我回答后，他再问你现在多少钱，我也回答了，不知道他为什么要问这个。

     面试就这样结束了，结果不知道。

     希望对面视的人有所帮助！大家也可以帮我分析一下，我有什么问题。