一个windows服务的信息：

1.注册的服务名称：也就是我们在任务管理器里面看到的进程名称

2.服务的显示名称：就是我们在服务管理器上面看到

3.服务的描述信息：这个就不用说了（可有可无）

4.服务调用的程序路径：这个服务运行那个程序

5.服务器的启动类型：是否自动，还是手动，或者是禁用

有了上面这些信息我们就可以开始着手写代码了

function OnFirstUIAfter()
STRING szServiceName, szServiceDisplayName, szServiceDescription, szServicePathFile,  szStartServiceArgs;
NUMBER ,bStartService,
begin

ShowObjWizardPages(NEXT);
szServiceName=”hiadmin”;

//注册的服务名称
szServiceDisplayName=”阳光网志”;

//服务显示名称
szServiceDescription=”阳光网志，个人博客而已”;

//服务描述
szServicePathFile=TARGETDIR^”\\Server\\test.exe”;

//程序文件的路径，安装路径下的Server目录下的test.exe文件
bStartService=0;

//启动类型为自动
szStartServiceArgs=”";
ServiceAddService ( szServiceName, szServiceDisplayName, szServiceDescription, szServicePathFile, bStartService, szStartServiceArgs );

ServiceStartService(szServiceName,”");

//在最后加了一行代码，当程序安装完成后启动这个服务

Advanced Installer

Advanced Installer 是一款功能强大、可生成符合 MS Windows 认证的 Windows Installer 的 MSI 安装包制作工具，具有友好的图形用户界面，直观而且非常简单的界面，创建 MSI 文件包非常方便，用户只需添加文件，修改名称，添加按钮就可以了，无需任何脚本方面的知识，并且生成的安装文件保证符合 Windows 最佳操作建议。

优点：

简单易学比InstallShield还简单好用。

控件很多，所有的控件可修改，控件自定义功能非常好用。还有注册服务之类的功能。非常适合新手朋友使用。

界面非常友好，比InstallShield和Wise Installation界面友好得多。

缺点：不能写代码，这是我放弃Advanced Installer选择用InstallShield 的主要原因，很多地方不是说用几个控件就可以解决的。

InstallShield

InstallShield 为软件发行方提供领先的安装程序解决方案，能够制作强大可靠的Windows Installer(MSI)、InstallScript以及跨平台的安装程序。

软件发行方在应用程序开发上投入了大量的时间和精力，他们同时也需要最新的安装程序，使用InstallShield，能够支持当今的最新技术。

在软件失败问题中，有28%是同安装和配置错误相关的。然而，许多软件发行方依然在使用着已经过时的安装程序制作工具。InstallShield一贯支持当今的最新技术和工业标准，支持MSI 3.1, IIS 6.0, Oracle, RPM以及试用和购买功能等，为您制作可靠的安装程序，适用于所有的操作系统、工作平台和设备。

特点：简单易学，可定制好，深一点的东西需要写代码。

缺点：系统自带的控件代码不可见，没办法修改自带的控件代码。注册系统服务需要通过代码实现。打包好的软件留有InstallShield的标志。

Wise Installation

Wise Installation非常著名的安装程序制作工具，它提供脚本编辑方式及众多应有尽有的安装选项，不愧为专业级的安装程序制作软件！

优点：简单易学。

缺点：界面不太友好，制作出来的安装包想2000年左右的安装光盘一样的安装界面。

企业级自动化测试工具WinRunner 软件测试

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

工业标准级负载测试工具Loadrunner

LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

功能测试工具Rational Robot
IBM Rational Robot 是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

单元测试工具xUnit系列

目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit，CppUnit(C++)，DUnit (Delphi )，NUnit(.net)，PhpUnit(Php )等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma (《设计模式》的作者)和Kent Beck(Extreme Programming)的创始人 )提供的开放源代码的JUnit.

功能测试工具SilkTest

Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。

性能测试工具WAS

Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

自动化白盒测试工具Jtest

Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具。

功能和性能测试的工具JMeter

JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现。

性能测试和分析工具WEBLODE

webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作，生成压力负载来测试web的性能

在我们的这个理发店中，我们事先做了如下的假设：
1. 理发店共有3名理发师；
2. 每位理发师剪一个发的时间都是1小时；
3. 我们顾客们都是很有时间观念的人而且非常挑剔，他们对于每次光顾理发店时所能容忍的等待时间+剪发时间是3小时，而且等待时间越长，顾客的满意度越低。如果3个小时还不能剪完头发，我们的顾客会立马生气的走人。
通过上面的假设我们不难想象出下面的场景：

1. 当理发店内只有1位顾客时，只需要有1名理发师为他提供服务，其他两名理发师可能继续等着，也可能会帮忙打打杂。1小时后，这位顾客剪完头发出门走了。那么在这1个小时里，整个理发店只服务了1位顾客，这位顾客花费在这次剪发的时间是1小时；

2. 当理发店内同时有两位顾客时，就会同时有两名理发师在为顾客服务，另外1位发呆或者打杂帮忙。仍然是1小时后，两位顾客剪完头发出门。在这1小时里，理发店服务了两位顾客，这两位顾客花费在剪发的时间均为1小时；

3. 很容易理解，当理发店内同时有三位顾客时，理发店可以在1小时内同时服务三位顾客，每位顾客花费在这次剪发的时间仍然是均为1小时；
从上面几个场景中我们可以发现，在理发店同时服务的顾客数量从1位增加到3位的过程中，随着顾客数量的增多，理发店的整体工作效率在提高，但是每位顾客在理发店内所呆的时间并未延长。

当然，我们可以假设当只有1位顾客和2位顾客时，空闲的理发师可以帮忙打杂，使得其他理发师的工作效率提高，并使每位顾客的剪发时间小于1小时。不过即使根据这个假设，虽然随着顾客数量的增多，每位顾客的服务时间有所延长，但是这个时间始终还被控制在顾客可接受的范围之内，并且顾客是不需要等待的。

不过随着理发店的生意越来越好，顾客也越来越多，新的场景出现了。假设有一次顾客A、B、C刚进理发店准备剪发，外面一推门又进来了顾客D、E、F。因为A、B、C三位顾客先到，所以D、E、F三位只好坐在长板凳上等着。1小时后，A、B、C三位剪完头发走了，他们每个人这次剪发所花费的时间均为1小时。可是D、E、F三位就没有这么好运，因为他们要先等A、B、C三位剪完才能剪，所以他们每个人这次剪发所花费的时间均为2小时——包括等待1小时图舴?小时。

通过上面这个场景我们可以发现，对于理发店来说，都是每小时服务三位顾客——第1个小时是A、B、C，第二个小时是D、E、F；但是对于顾客D、E、F来说，“响应时间”延长了。如果你可以理解上面的这些场景，就可以继续往下看了。
在新的场景中，我们假设这次理发店里一次来了9位顾客，根据我们上面的场景，相信你不难推断，这9位顾客中有3位的“响应时间”为1小时，有3位的“响应时间”为2小时（等待1小时+剪发1小时），还有3位的“响应时间”为3小时（等待2小时+剪发1小时）——已经到达用户所能忍受的极限。假如在把这个场景中的顾客数量改为10，那么我们已经可以断定，一定会有1位顾客因为“响应时间”过长而无法忍受，最终离开理发店走了。
我想并不需要特别说明，大家也一定可以把上面的这些场景跟性能测试挂上钩了。如果你还是觉得比较抽象，继续看下面的这张图 ^_^

这张是原图，下面这张我换成中文的了

这张图中展示的是1个标准的软件性能模型。在图中有三条曲线，分别表示资源的利用情况（Utilization，包括硬件资源和软件资源）、吞吐量（Throughput，这里是指每秒事务数）以及响应时间（Response Time）。图中坐标轴的横轴从左到右表现了并发用户数（Number of Concurrent Users）的不断增长。

在这张图中我们可以看到，最开始，随着并发用户数的增长，资源占用率和吞吐量会相应的增长，但是响应时间的变化不大；不过当并发用户数增长到一定程度后，资源占用达到饱和，吞吐量增长明显放缓甚至停止增长，而响应时间却进一步延长。如果并发用户数继续增长，你会发现软硬件资源占用继续维持在饱和状态，但是吞吐量开始下降，响应时间明显的超出了用户可接受的范围，并且最终导致用户放弃了这次请求甚至离开。
根据这种性能表现，图中划分了三个区域，分别是Light Load（较轻的压力）、Heavy Load（较重的压力）和Buckle Zone（用户无法忍受并放弃请求）。在Light Load和Heavy Load 两个区域交界处的并发用户数，我们称为“最佳并发用户数（The Optimum Number of Concurrent Users）”，而Heavy Load和Buckle Zone两个区域交界处的并发用户数则称为“最大并发用户数（The Maximum Number of Concurrent Users）”。

当系统的负载等于最佳并发用户数时，系统的整体效率最高，没有资源被浪费，用户也不需要等待；当系统负载处于最佳并发用户数和最大并发用户数之间时，系统可以继续工作，但是用户的等待时间延长，满意度开始降低，并且如果负载一直持续，将最终会导致有些用户无法忍受而放弃；而当系统负载大于最大并发用户数时，将注定会导致某些用户无法忍受超长的响应时间而放弃。
对应到我们上面理发店的例子，每小时3个顾客就是这个理发店的最佳并发用户数，而每小时9个顾客则是它的最大并发用户数。当每小时都有3个顾客到来时，理发店的整体工作效率最高；而当每小时都有9个顾客到来时，前几个小时来的顾客还可以忍受，但是随着等待的顾客人数越来越多，等待时间越来越长，最终还是会有顾客无法忍受而离开。同时，随着理发店里顾客人数的增多和理发师工作时间的延长，理发师会逐渐产生疲劳，还要多花一些时间来清理环境和维持秩序，这些因素将最终导致理发师的工作效率随着顾客人数的增多和工作的延长而逐渐的下降，到最后可能要1.5小时甚至2个小时才能剪完1个发了。
当然，如果一开始就有10个顾客到来，则注定有1位顾客剪不到头发了。
进一步理解“最佳并发用户数”和“最大并发用户数”
对于一个确定的被测系统来说，在某个具体的软硬件环境下，它的“最佳并发用户数”和“最大并发用户数”都是客观存在。以“最佳并发用户数”为例，假如一个系统的最佳并发用户数是50，那么一旦并发量超过这个值，系统的吞吐量和响应时间必然会 “此消彼长”；如果系统负载长期大于这个数，必然会导致用户的满意度降低并最终达到一种无法忍受的地步。所以我们应该 保证最佳并发用户数要大于系统的平均负载。
要补充的一点是，当我们需要对一个系统长时间施加压力——例如连续加压3-5天，来验证系统的可靠性或者说稳定性时，我们所使用的并发用户数应该等于或小于“最佳并发用户数”——大家也可以结合上面的讨论想想这是为什么 ^_^
而对于最大并发用户数的识别，需要考虑和鉴别一下以下两种情况：

1. 当系统的负载达到最大并发用户数后，响应时间超过了用户可以忍受的最大限度——这个限度应该来源于性能需求，例如：在某个级别的负载下，系统的响应时间应该小于5秒。这里容易疏忽的一点是，不要把顾客因为无法忍受而离开时店内的顾客数量作为理发店的“最大并发用户数”，因为这位顾客是在3小时前到达的，也就是说3小时前理发店内的顾客数量才是我们要找的“最大并发用户数”。而且，这位顾客的离开只是一个开始，可能有会更多的顾客随后也因为无法忍受超长的等待时间而离开；

2. 在响应时间还没有到达用户可忍受的最大限度前，有可能已经出现了用户请求的失败。以理发店模型为例，如果理发店只能容纳6位顾客，那么当7位顾客同时来到理发店时，虽然我们可以知道所有顾客都能在可容忍的时间内剪完头发，但是因为理发店容量有限，最终只好有一位顾客打道回府，改天再来。

对于一个系统来说，我们应该 确保系统的最大并发用户数要大于系统需要承受的峰值负载。
如果你已经理解了上面提到的全部的概念，我想你可以展开进一步的思考，回头看一下自己以往做过的性能测试，看看是否可以对以往的工作产生新的理解。也欢迎大家在这里提出自己的心得或疑惑，继续讨论下去。
理发店模型的进一步扩展

这一节中我会提到一些对理发店模型的扩展，当然，我依然是只讲述现实中的理发店的故事，至于如何将这些扩展同性能测试以及性能解决方案等方面关联起来，就留给大家继续思考了 ^_^
扩展场景1：有些顾客已经是理发店的老顾客，他们和理发师已经非常熟悉，理发师可以不用花费太多时间沟通就知道这位顾客的想法。并且理发师对这位顾客的脑袋的形状也很熟悉，所以可以更快的完成一次理发的工作。
扩展场景2：理发店并不是只有剪发一种业务，还提供了烫发染发之类的业务，那么当顾客提出新的要求时，理发师服务一位顾客的时间可能会超过标准的1小时。而且这时如果要计算每位顾客的等待时间就变得复杂了很多，有些顾客的排队时间会比原来预计的延长，并最终导致他们因为无法忍受而离开。

扩展场景3：随着烫发和染发业务的增加，理发师们决定分工，两位专门剪发，一位专门负责烫发和染发。

扩展场景4：理发店的生意越来越好，理发师的数量和理发店的门面已经无法满足顾客的要求，于是理发店的老板决定在旁边再开一家店，并招聘一些工作能力更强的理发师。

扩展场景5：理发店的生意变得极为火爆了，两家店都无法满足顾客数量增长的需求，并且有些顾客开始反映到理发店的路途太远，到了以后又因为烫发和染发的人太多而等太久。可是理发店的老板也明白烫发和染发的收入要远远高于剪发阿，于是他脑筋一转，决定继续改变策略，在附近的几个大型小区租用小的铺面开设分店，专职剪发业务；再在市区的繁华路段开设旗舰店，专门为烫发、染发的顾客，以及VIP顾客服务。并增设800电话，当顾客想要剪发时，可以拨打这个电话，并由服务人员根据顾客的居住地点，将其指引到距离最近的一家分店去。
这篇文章就先写到这里了，希望大家在看完之后可以继续思考一下，也写出自己的心得体会或者新的想法，记下自己的不解和疑惑，让我们在不断的交流和讨论中走的更远 ^_^
转自:http://jackei.cnblogs.com

在性能测试的整个流程当中，监控起着至关重要的作用。因为在性能测试开始执行之后，需要实时的去观察性能测试的各个指标是否正常，包括应用服务器、数据库、中间件等方面。一旦发现异常情况，及时修正，保证性能测试的顺利进行。而且在监控当中，也可以发现系统的瓶颈，适当制止性能测试的继续运行，保证避免重复的工作。

首先，广泛意义的性能测试监控，应该分阶段去做，其中包括执行前、执行中和执行后的监控。

执行前：

环境搭建的时候，监控确定性能测试环境的纯净性，没有其他资源在使用。CPU、MEM、LOA、I/O的初始值是否正常。

执行中：

监控内容包括虚拟用户执行情况、场景状态、事务响应时间、服务器资源使用、操作系统和硬件的监控，此外最重要的还有测试机的运行情况，包括CPU、MEM等。是否满足当前性能测试种类的要求，比如性能测试、压力测试、负载测试等。

除了LoadRunner等监控工具外，也可以借助于辅助工具，用来监控一些定时服务、夜间监控情况，写一些shell脚本。

监控中可以分几大类去监控：工具的监控、测试用例的监控、测试方法的监控、进度、以及测试环境的监控。

建议：创建监控点列表，确定监控目标。开启监控服务，监控同时要采集信息，以便之后的分析。确定监控信息，同时确定监控工具。

执行后：

监控资源释放是否正常、合理。

监控指标：

性能测试的监控指标主要包括以下几个部分：

1、服务器：Linux应用服务器

具体包括CPU、Memory、Load、I/O、Disk等。

2、数据库：1.Mysql 2.Oracle

具体包括缓存命中、索引、单条SQL性能、数据库线程数、数据池连接数等。

3、中间件：1.Jboss 2. Apache

具体包括线程数、连接数、日志输出等。

4、网络

具体包括防火墙、网卡、网线、吞吐量、吞吐率等。

5、应用服务

具体包括JVM内存使用和回收、JAVA内存使用、Full GC频率、JAVA类装入和卸载、日志、线程运行状态(阻塞、等待、正常运行)等。

6、监控工具(LoadRunner)

具体包括用户执行情况、场景状态、事务响应时间、TPS、Load、CPU分析图表等。

7、测试机资源 具体包括CPU、Memory、网络、日志输出、磁盘空间、负载生成器评估等

监控原则：

1、确定监控目标

2、确定监控和分析信息

3、确定监控工具

4、收集数据

5、分析数据

6、调优

7、循环

监控方法：

包括Checklist法等。

监控工具

包括Profiler、Jstat、Jconsole、Jmap、Jprofiler、Nmon等。

1. 性能测试

2. 负载测试

3. 压力测试

4. 配置测试

5. 并发测试

6. 可靠性测试

7. 失效性测试

一：性能测试

性能测试试通过模拟生产环境运行的业务压力量和使用场景组合。测试系统试否满足要求的一种常见的测试方法。

性能测试有以下特点：

1. 这种方法的组要目的试验证系统是否有系统宣称的能力

2. 这种方法需要试险了解被测试系统的典型场景，并有确定的性能目标

3. 这种方法在已确定的环境下运行

二：负载测试

负载测试通过在被测系统上不断的增加压力，直到性能指标，超过预定指标或者某种资源使用已经达到饱和状态。

负载测试有如下特点
1. 负载测试的主要目的试找到系统处理能力的极限

2. 负载测试需要在给定的环境下运行，也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。

3. 负载测试一般用来了解系统的性能容量，或者是配合性能调优来使用。

三：压力测试

压力测试方法测试系统在一定饱和状态下，（cpu，内存使用率）系统能够处理的会话能力，以及系统试否会出现错误。

压力测试具有如下特点

1. 压力测试的组要目的试检查系统处于压力情况时，应用的表现。

2. 压力测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。

3. 压力测试一般用于测试系统的稳定性

四：配置测试

配置测试通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资源的最优分配原则

配置测试具有如下特点：

1. 配置测试的组要目的试了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。

2. 配置测试一般对系统性能有初步了解后进行

3. 配置测试一般用于性能调优

五：并发测试

并发测试通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在试锁或者其他性能问题

并发测试具有如下特点

1. 并发测试的组要目的试发现系统中可能隐藏的并发访问时的问题。

2. 并发测试主要关注系统可能存在的并发问题，例如系统的内存泄漏，线程试锁和资源争用方面的问题。

3. 并发测试可以在开发的各个阶段进行，需要相关的工具配置和支持。

六：可靠性测试

可靠性测试通过给系统加载一定的业务压力的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能够稳定运行

可靠性测试具有如下特点

1. 可靠性测试的组要目的试验证系统是否支持长期稳定的运行

2. 可靠性测试需要在压力状态下运行一段时间

3. 可靠性测试需要关注系统的运行状况

七：失效性测试

失效性测试是针对冗余备份和负载均衡的系统设计的，失效性测试用来检验系统局部发生故障，用户是否能够继续使用系统，以及这种情况发生后用户将受到什么影响

失效性测试具有如下特点

1. 失效性测试主要是验证局部故障时系统是否可以继续使用

2. 失效性测试需要指出这样的情况发生后，能支持多少用户访问和该采取什么样的措施

3. 失效性测试一般试在对系统持续运行指标有明确要求后才需要进行的测试

时光如梭，2009年很快就过去了，回首过去的一年，内心不禁感概万千，从09年4月在IT部门从内部IT转职到IDC值班工程师专门从事IDC上端的维护工作，8月转岗到现质量保证部门从事配置管理工程师一职，主要负责部门的内部维护，测试环境的配置，预发布的管理。10月中旬开始参与无盘二期的测试工作至今。

一：未完成的配置管理

8月份转到部门后由于原来没有配置管理工程师这个岗位所以只能靠自己摸索并在凯峰，老高，陈玲，马笑丽，李圣以及各位亲爱的部门同事们的帮助下，开始并逐步完成了对QC,SVN熟悉的过程，完成了将上端首页，28平台首页等网站程序，VC端程序移植到公司的内网的测试环境中，完成了预发布环境的配置以及预发布升级的工作，以及将测试环境整合到VMware的虚拟管理服务器中。

在这未完成的配置管理工作中学会了QC,SVN的基本使用及一些管理操作，学会了公司上端程序的基本配置以及常见的故障排除能力，学会了如何维护tomcat，apache常见的故障。

二：初涉的软件测试

10月中旬开始的软件测试，在老大的提携和凯峰不遗余力的指导以及部门内这么多测试前辈的帮助下，从一个连case都不知道是什么的小小白开始并深入到无盘的测试工作中，并深深喜欢上了测试这个工作，这无疑为我的职业发展重新找到新的方向。

从近3个月的无盘测试工作中，以前做IT时候学到硬件知识和系统方面知识以及对网络知识的了解在无盘的测试工作发挥了作用，测试过程中发现很多不足之处。

1. 测试基础匮乏，仔细阅读完《软件测试》一书，补充了大部分测试的基础知识，但是还需要在实践中来验证和提高。

2. case写得杂乱无章，这在我无盘二期case的时候还没有发现，但是当吕鑫和我评审无盘三期的用例时我才发现原来case应该这样写。

3. BUG提交的描述不清导致研发不能复现，当我看完潘江峰提交的BUG描述时，我才发现为什么我提交的BUG研发都要过来问我是怎么出现，并让我复现给他们看。现在提交的BUG描述信息，简单明了，复现步骤罗列清晰。

4. 行业知识缺乏，开始接手无盘测试之后我开始使用市场上比较成熟的无盘产品，锐起，网众，创世纪来提高对无盘行业的了解。

现在还欠缺的并需要恶补的知识。

1. SQL脚本完全不会，现在还停留在通过鼠标点击来完成对数据库的操作。

2. 阅读代码能力为零，现在还只能进行黑盒测试。

三：今年计划

新的一年意味着新的起点新的机遇新的挑战，向吕鑫同学学习，决心再接再厉，更上一层楼。完成测试基础知识的沉淀，补充SQL脚本的书写能力，达到初级测试工程师的水平并努力向中级测试工程师靠拢。

1）准确 vs 精确
－ 准确：参照物是目标。与目标越接近，就越准确
－ 精确：参照物是每次实施的结果。几次结果相互之间越接近，表示越精确。但与目标可能相去甚远

2）验证 vs确认

－ 确认：保证软件符合产品说明书的过程
－ 验证：保证软件满足用户要求的过程。

3）测试 vs 质量保证(QA)
－ 测试：软件测试员的目标是尽可能早一些找出软件缺陷，并确保其得以关闭。
－ 质量保证：软件质量保证人员的主要指责是创建和执行改进软件开发并防止软件缺陷的标准和方法

4）黑盒测试 vs 白盒测试
－ 黑盒测试：软件测试员只需知道软件要做什么，无需知道是如何运作的。只关心输入和输出
－ 白盒测试：软件测试员可以访问程序员的代码，并通过检查代码来协助测试。

5）静态测试 vs 动态测试
－ 静态测试：只测试不运行的部分——只是检查和审阅。
－ 动态测试：指通常意义上的测试——运行和使用软件
八：测试产品说明书就属于静态黑盒测试

一：对产品说明书进行审查
1） 熟悉软件应用领域的相关知识

2）.假设自己是用户（为用户设身处地的想）
3）.研究产品说明书了解软件该做什么，为什么和该怎么做。
4） 研究现有的标准和规范。
软件测试员的任务不是定义软件要符合何种标准和规范、而是“检验”是否套用了正确的标准，有无遗漏。如：公司惯用语和约定；行业要求；国家标准；图形用户界面；硬件和网络标准

二 审查和测试同类软件
了解同类软件有助于制订测试条件和测试方法，还可能暴露没想到的潜在问题

测试同类软件时应注意的问题

1） 规模（软件功能十分强大）

2） 复杂性（软件是否很复杂，是否会影响测试）

3） 测试性（是否有足够的时间来测试）

4） 质量和可靠性（软件是否满足用户需求）

5） 安全性（同类软件的安全性）

三：优秀的产品说明书应具有8个重要的属性

1） 完整。 完全？单独使用是否包含全部内容？

2）准确。 方案正确？目标明确？
3）精确、不含糊、清晰。 容易看懂和理解？
4）一致。 功能描述是否自相矛盾？有无冲突？
5）贴切。 功能陈述是否必要？信息冗余？是否客户要求？
6）合理。 以现有人力、物力和资源能否实现？
7）代码无关。 定义产品，而不是设计、架构或代码！
8）可测试。 是否提供足够的测试信息？

四：检查产品说明书的用语清单

1）总是、每一种、所有、没有、从不。
对此类绝对或肯定的切实认定的叙述，应该考虑并设计违反这些情况的用例。
2）当然、因此、明显、显然、必然。
这些话意图诱使接受假定情况。小心中了圈套。
3）某些、有时、常常、通常、经常、大多、几乎、
太过模糊。“有时”发生的功能无法测试。
4）等等、诸如此类、依此类推、例如
以这样的词结束的功能清单无法测试。功能清单必须绝对、解释明确。不能推论。
5）良好、迅速、廉价、高效、稳定、
这些无法量化的术语，不可测试。如果说明书中出现这类的术语必须要求进一步指明含义。
6）处理、拒绝、忽略、跳过、排除
这些说法可能会隐藏大量需要说明的功能
7）如果……那么……（没有否则）。
想想，“如果”没有发生会怎样呢？

一：软件测试员的目标
软件测试员的目标是尽可能早一些找出软件缺陷，并确保其得以关闭。我认为这句话有3个含义，而且是先后有关联

1） 软件测试员的基本目标是发现软件缺陷

软件测试员的基本目标就是发现软件缺陷，这是做好测试的前提条件。

2） 软件测试员应该是尽可能早的找出软件缺陷

当软件的缺陷越早发现修改成本越低，反之亦然，所以软件测试员应尽可能早的找出软件缺陷。这个问题上次老大在培训如何写测试大纲的时候也提到过。

3） 软件测试人员必需确保找出的软件缺陷得以关闭

缺陷是否需要修复的最终决定权在软件的最终负责人，检查缺陷得以关闭的责任在测试人员。而关闭软件缺陷的前提是缺陷得以修复或决定不作修复。

二：软件缺陷的正式定义
1)软件未实现产品说明书要求的功能

2)软件出现了产品说明书指明不应该出现的错误

3)软件实现了产品说明书未提到的功能

4)软件未实现产品说明书虽未明确提及但应该实现的目标

5)软件难以理解，不易使用，运算速度慢，或者软件测试人员认为最终用户会认为不好。

这几条定义很容易理解，第五条由于每个人都对软件的工作方式有自己的意见和想法，要软件都满足所有用户的意见是不可能的，所以作为软件测试人员要全面的客观的评价。

三：软件测试员应具备的素质
1）探索精神（喜欢拿到新软件，并进行测试）
2）故障排除人员（善于发现问题的症结）
3）不放过任何蛛丝马迹（总是不停的尝试，想尽一切办法去发现转瞬即逝和难以复现的软件缺陷）
4）创造性（想出富有创意甚至超常的手段来寻找缺陷）
5）追求完美（力求完美，但对知道无法企及的东西也不强求，而是尽力接近目标）
6）判断准确（决定测试内容、测试时间、是否是真正的缺陷）
7）老练稳重（知道如何将坏消息告诉程序员，知道如何跟不够冷静的程序员合作）
8）说服力（善于表达观点，通过实际演示标明缺陷为何必须修复）

9）表达能力（用简短的文字描述缺陷，使程序员能一目了然的知道缺陷所在）

10）专业知识（测试财务软件，必须要知道财务知识）

四：软件产品的组成

1） 软件本身

2） 帮助文件

3） 用户手册

4） 样本和示例

5） 产品支持信息

6） 图标和标志

7） 说明文件

8） 广告和宣传材料

9） 错误信息

在测试的时候不仅仅是测试软件本身还包括了如上的软件组成部分

五：软件开发模式
从最初构思到公开发行软件产品的过程称为软件开发模式。
1）大爆炸模式

2）边写边改模式（写代码，修改，写代码，修改，知道产品发布，没有时间做好，总有时间返工）

3)瀑布模式（创意、分析、设计、开发、测试、产品一步步进行，不能后退。前一步完成才能进入下一阶段）

4）螺旋模式（总体思想是：开始不必详细定义所有的细节。从小开始，定义重要的功能，努力实现这些功能，接受用户反馈，然后进入下一阶段。重复上面的过程，直到得到最终产品；螺旋模式每一次的循环包括6个步骤：1.确定目标、可选方案和限制条件；2.指出并解决风险；3.评估方案；4.本阶段开发和测试；5.计划下一阶段；6.确定进入下一阶段的方法）

六：测试的原则

1） 完全测试是不可能的

.输入量太多

.输出结果太多

.软件执行路径太多

.软件说明书是主观的，从旁观者来看就是缺陷

2） 软件测试是有风险的行为

接着上面的如果选择了不去测试所有的情况，那就选择了冒险。不完全测试又会漏掉软件缺陷。所以软件测试员要会学一个关键思想：如何把数量巨大的可能测试减少到可以控制的范围，以及如何针对风险作出明智的选择，那些需要测试，那些不需要测试。

3） 测试无法显示潜伏的软件缺陷

软件测试员可以报告缺陷存在，但是不能报告软件缺陷不存在。我们可以报告已经发现的缺陷，但是如何时候下都不保证软件缺陷没有了。

4） 找到的软件缺陷越多，就说明软件缺陷越多。

.程序员也有心情不好的时候

.程序员往往犯同样的错误

.某些软件缺陷实在是冰山的一角（软件测试过程中发现很多的缺陷到最后才发现是由一个缺陷造成的）

5） 杀虫剂事件（软件缺陷免疫）

当一个测试员对同一个缺陷进行多次的回归测试很难在发现新的软件缺陷了，这个时候可以换一个方式或者换一个测试员来测试可能会发现不同的软件缺陷。

6） 并非所有的软件缺陷都需要修复

在前面已经说过了，只要确定软件缺陷得以关闭，不修复的原因有几个

.没有足够的时间来修复软件

.修复的风险太大（修复一个软件缺陷会导致其他的软件缺陷）

.不值得修复（不常出现的缺陷是可以放过的，可以躲过和用户有办法预防或避免的软件缺陷通常不用修复，当然这些都要归结为商业风险决策）

7） 产品说明书还没有最终版本

软件测试员必须想到产品说明书可能改变，没有测试计划的功能可能会增加，经过测试报告的软件缺陷的功能可能发生变化设置功能被删除。

8） 软件测试员在产品项目中不受欢迎

软件测试员的工作就是检查和批评同事的工作，挑毛病，公布发现的问题。当你下班的时候兴冲冲的跑去告诉程序员你今天发现了20个BUG，你可能会很有成就感，可程序员可不这样想。所以需要控制好情绪。

从Google论坛上面看见很多朋友在求助，差不多的解决办法如下：

第一种：（可以访问电子表格但是提示访问出错）

http://docs.google.com登录后，点击表格文件，出现链接http://spreadsheets.google.com/ccc?key=0AgW4ARBICLomdDgxX3U5dGJVc2ZXWVpwU1QweV9MWGc&hl=zh_CN，将spreadsheets去掉最后的s，即http://spreadsheet.google.com/ccc?key=0AgW4ARBICLomdDgxX3U5dGJVc2ZXWVpwU1QweV9MWGc&hl=zh_CN

刷新下就可以访问了，此方法经常是不可行

第二种：（也不可行）

http://spreadsheets.google.com/改成https://spreadsheets.google.com/

第三种：用翻墙软件Hotspot Shield这个可以用的，就是Hotspot Shield的广告有点多。

最后说下怎么下载下来。对Google电子表格无望后，阳光一直想把电子表格下载到电脑里面，可是一直无法打开，连下载也出现错误。

第一种：http://docs.google.com登录后点击导出电子表格，出现错误。将地址栏里面链接地址的spreadsheets的S去掉变成spreadsheet就可以下载文档了。

第二种：用翻墙软件Hotspot Shield登录后导出也可以的。