“工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。

　　 产品基本情况调研：

　　这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。

　　具体的要点有：

　　目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。

　　变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。

　　技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。

　　产品规格：就是制造商和产品版本号的说明。

　　测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。

　　项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。

　　测试需求说明：

　　这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有：

　　功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。

　　设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。

　　整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。

　　测试的策略和记录：

　　这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下：

　　公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。

　　测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。

　　特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。

　　经验判断：对以往的测试中，经常出现的问题加以考虑。

　　设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。

　　测试资源配置：

　　项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。

　　计划表：

　　测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。

　　问题跟踪报告：

　　在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。

　　问题描述尽可能是定量的，分门别类的列举，问题有几种：

　　1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。

　　2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。

　　3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。

　　测试计划的评审：

　　又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。

　　结果：

　　计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。

 API(Application Programming Interface,应用程序编程接口)是一套用来控制Windows的各个部件(从桌面的外观到位一个新进程分配的内存)的外观和行为的一套预先定义的Windows函数.用户的每个动作都会引发一个或几个函数的运行以Windows告诉发生了什么.

这在某种程度上很象Windows的天然代码.其他的语言只是提供一种能自动而且更容易的访问API的方法.VB在这方面作了很多工作.它完全隐藏了API并且提供了在Windows环境下编程的一种完全不同的方法.

这也就是说,你用VB写出的每行代码都会被VB转换为API函数传递给Windows.例如,Form1.Print...VB 将会以一定的参数(你的代码中提供的,或是默认参数)调用TextOut 这个API函数.

同样,当你点击窗体上的一个按钮时,Windows会发送一个消息给窗体(这对于你来说是隐藏的),VB获取这个调用并经过分析后生成一个特定事件(Button_Click).

API函数包含在Windows系统目录下的动态连接库文件中(如User32.dll,GDI32.dll,Shell32.dll...).

API 声明

正如在"什么是API"中所说,API函数包含在位于系统目录下的DLL文件中.你可以自己输入API函数的声明,但VB提供了一种更简单的方法,即使用API Text Viewer.

要想在你的工程中声明API函数,只需运行API Text Viewer,打开Win32api.txt(或.MDB如果你已经把它转换成了数据库的话,这样可以加快速度.注:微软的这个文件有很多的不足,你可以试一下本站提供下载的api32.txt),选择"声明",找到所需函数,点击"添加(Add)"并"复制(Copy)",然后粘贴(Paste)到你的工程里.使用预定义的常量和类型也是同样的方法.

你将会遇到一些问题:

假设你想在你的窗体模块中声明一个函数.粘贴然后运行,VB会告诉你:编译错误...Declare 语句不允许作为类或对象模块中的 Public 成员...看起来很糟糕,其实你需要做的只是在声明前面添加一个Private(如 Private Declare Function...).--不要忘了,可是这将使该函数只在该窗体模块可用.

在有些情况下,你会得到"不明确的名称"这样的提示,这是因为函数.常量或其他的什么东西共用了一个名称.由于绝大多数的函数(也可能是全部,我没有验证过)都进行了别名化,亦即意味着你可以通过Alias子句使用其它的而不是他们原有的名称,你只需简单地改变一下函数名称而它仍然可以正常运行.

你可以通过查看VB的Declare语句帮助主题来获取有关Alias的详细说明.

消息(Messages)

好了,现在你已经知道什么是API函数了,但你也一定听说过消息(如果你还没有,你很快就会)并且想知道它是什么.消息是Windows告诉你的程序发生了哪些事件或要求执行特定操作的基本方法.例如,当用户点击一个按钮,移动鼠标,或是向文本框中键入文字时,一条消息就会被发送给你的窗体.

所有发送的消息都有四个参数--一个窗口句柄(hwnd),一个消息编号(msg)还有两个32位长度(Long)的参数.

hwnd即要接受消息的一个窗口的句柄,msg即消息的标识符(编号).该标识符是指引发消息的动作类型(如移动鼠标),另外两个参数是该消息的附加参数(例如当鼠标移动时光标的当前位置)

但是,当消息发送给你时你为什么看不到呢--就象有人在偷你的信一样?请先别恼火,让我告诉你.

小偷其实是Visual Basic.但它并没有偷走你的信,而是在阅读了之后挑出重要的以一种好的方式告诉你.这种方式就是你代码中的事件(Event).

这样,当用户在你的窗体上移动鼠标时,Windows会发送一条WM_MOUSEMOVE消息给你的窗口,VB得到这条消息以及它的参数并运行你在事件MouseMove中的代码,同时VB会把这条消息的第二个32位数(它包含了x,y坐标,单位为像素(Pixel),每个位16位)转换为两个单精度数,单位为缇(Twip).

现在,如果你需要光标坐标的像素表示,然而VB已经把它转换成了缇,因此你需要重新把它转换为以像素为单位.在这里,Windows给了你所需要的,但VB"好意地"进行了转换而使你不得不重新转换.你可能会问--我难道不能自己接收消息吗?答案是肯定的,你可以使用一种叫做子类处理(Subclass)的方法.但你除非必须否则最好不要使用,因为这与VB的安全程序设计有一点点的违背.(注:子类处理确实有很大的风险,但如果使用得当,是很有用处的.不过有一点一定要注意,即千万不要使用VB的断点调试功能,这可能会导致VB崩溃!)

需要补充说明的是:你可以发送消息给你自己的窗口或其他的窗口,只需调用SendMessage或PostMessage(SendMessage会使接受到消息的窗口立刻处理消息,而PostMessage是把消息发送到一个称为消息队列的队列中去,等候处理(它将会在该消息处理完后返回,例如有些延迟)).你必须制定接受消息的窗口的句柄,欲发送消息的编号(所有的消息的编号均为常量,你可以通过API Text Viewer查得)以及两个32位的参数。

另一种含义：

1：美国石油协会(API:American Petrolenm Institute)：制定机油标准的组织。汽车用发动机机油必须符合API提出的标准。

2：API还有一种含意：空气污染指数。【英文 air pollution index 的缩写】

3：在JAVA中，API除了有应用“程序程序接口”的意思外，还特指JAVA API的说明文档，也称为JAVA帮助文档。

4.API Q1质量体系认证是您向用户证明您有一套API认可的完善的质量管理体系, 有些石油、天然气设备制造商所生产的产品目前没有所适用API会标产品的规范对应， 但他们又想向用户证明他们的产品或服务符合API标准的要求，所以API Q1质量体系认证可以帮您办到。API Q1质量体系认证特别适用于那些所生产的产品没有相应的API会标产品规范所对应的石油、天然气设备生产厂家， 或向石油、天然气行业提供服务的公司。

另一种含义：

   使用API（应用编程接口，英文全称：Application Programming Interface）构建业务是实现开放式业务结构的关键技术，也是下一代网络区别于传统电信网的主要特点之一。目前，关于下一代网络的开放式业务API标准主要包括：由Parlay组织、3GPP和ETSI SPAN共同制定的Parlay/OSA API以及由SUN公司在Java平台上推出的JAIN API。
   Parlay API是由Parlay组织定义的便于业务开发者快速创建电信业务的应用编程接口，自1999年成立以来，Parlay组织已制定了4个版本的Parlay协议。开放式业务结构(OSA)是3GPP制定的多媒体业务框架，选定Parlay作为其开放式业务接口API。两者结合的Parlay/OSA API独立于具体的实现技术，可以应用于固定网络、移动网络以及下一代网络的业务提供；独立于具体的实现语言，可以用C、C++、Java等各种语言实现；定义了完善的认证和授权机制，以支持对第3方应用的支持。
   Parlay/OSA API位于由网络运营商管理的Parlay网关和由业务提供商管理的应用服务器之间。Parlay网关对应用服务器屏蔽了下层网络的技术实现细节，使得应用服务器可以使用统一的方式对网络能力进行访问。
   Parlay/OSA API包括两类接口：业务接口和框架接口。业务接口提供应用访问网络能力和信息的接口，框架接口提供业务接口安全、管理所必需的支持能力。业务接口保证用户能够接入传统网络，如呼叫控制、呼叫管理、发送消息、用户交互等；框架接口提供的功能有：业务登记、业务预订、业务发现、认证、授权和综合管理。
   JAIN API和Parlay/OSA API设计思想相近，功能上具有互补性。它采用专一的Java语言实现，并且定义了比较完备的访问各种网络的网络协议API。目前Parlay/JAIN联合工作组正在进行两者的融合工作。

C/S与B/S架构的区别是什么？ C/S又称Client/Server或客户/服务器模式。服务器通常采用高性能的PC、工作站或小型机，并采用大型数据库系统，如Oracle、Sybase、Informix或   SQL   Server。客户端需要安装专用的客户端软件。         B/Ｓ是Brower/Server的缩写，客户机上只要安装一个浏览器（Browser），如Netscape   Navigator或Internet   Explorer，服务器安装Oracle、Sybase、Informix或   SQL   Server等数据库。浏览器通过Ｗeb   Server   同数据库进行数据交互。         C/S的优点是能充分发挥客户端ＰＣ的处理能力，很多工作可以在客户端处理后再提交给服务器。对应的优点就是客户端响应速度快。缺点主要有以下几个：         只适用于局域网。而随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。         客户端需要安装专用的客户端软件。首先涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。特别是有很多分部或专卖店的情况，不是工作量的问题，而是路程的问题。还有，系统软件升级时，每一台客户机需要重新安装，其维护和升级成本非常高。         对客户端的操作系统一般也会有限制。可能适应于Win98,   但不能用于win2000或Windows   XP。或者不适用于微软新的操作系统等等，更不用说Linux、Ｕnix等。         B/S最大的优点就是可以在任何地方进行操作而不用安装任何专门的软件。只要有一台能上网的电脑就能使用，客户端零维护。系统的扩展非常容易，只要能上网，再由系统管理员分配一个用户名和密码，就可以使用了。甚至可以在线申请，通过公司内部的安全认证（如ＣＡ证书）后，不需要人的参与，系统可以自动分配给用户一个账号进入系统  两者的比较:  1、执行效率:如果实时性的要求不是很高，差别可以忽略不记。     2、维护的难度：B/S要容易维护的多！     3、在lan内与在internet上跑有何影响：两个都要受到网络传输速度的影响， 而B/S更适合在internet上运行。     4、安全性：C/S稍好。     5、所用技术的难易程度：B/S相对更简单一些。     6、对硬件和网络的要求：B/S的要求低。     7、开发周期：相当。

首次开通我的测试空间,很想在这条路上走出多彩的人生

来容知已经快三个月了,三个月的时间我一直停滞在原来的测试基础上一点也没有进步

今天开通我的空间,让她见证我今后的测试历程

希望能在这里有更好的收获

*黑盒测试(功能测试)

黑盒测试是指测试条件主要根据程序或系统的功能实现来制定.这一类的测试包括决策表\等价类划分、范围测试、边界值测试、数据库集成测试、因果图、正交阵列测试、阵列和表测试、异常测试、极限测试、随机测试

黑盒测试优点：测试活动本身的行为要与程序或系统的设计行为想吻合

黑盒测试的不足:测试全部的\无遗漏的输入流是不太肯呢感的,因为这要求每一个可能的输入条件或其组合都要被测试到.另外,因为测试人员不知道内部的结构或处理逻辑,在黑盒测试中没有被测到的部分很可能会有致命的错误或程序员故意放置一段代码而搞的恶作剧

*白盒测试(结构测试)

白盒测试是指测试情境主要是针对逻辑路径来设计的.测试人员检查程序或系统的内部结构.测试数据根据对程序或系统的逻辑检查来确定,而不关系程序或系统的需求.这一类别中的测试包括基本路径分析、语句覆盖、分支覆盖、条件覆盖、分支/条件覆盖

白盒测试优点：测试比较彻底，并且侧重于已经开发出来的代码。

百盒测试的不足：1）不能验证规约的正确性；2）无法检验代码中遗漏的路径和数据敏感性错误

*灰盒测试（功能与结构测试）

灰盒测试是黑盒测试和白盒测试的有机结合。测试人员研究需求规约，然后与开发人员沟通并理解系统的内部结构。目的是整理一些不明确的需求规格，掌握程序的逻辑以设计引申的测试

*手工测试与自动测试

手工测试类别的分类根据是该类测试不是有人在计算机上执行的。这一类别的例子包括结果化走查、检查、JAD和桌面检查

自动测试类别的分类根据是该类测试是在计算机上执行的。例如边界值测试、分支覆盖测试、原型法和语法测试。

*静态测试与动态测试

静态测试方法是与时间无关的，不需要被测软件产品的手工执行或自动执行。例子包括结构化走查、语法检查和代码检查。使用计算机的静态检查的例子是静态流分析工作。

动态测试技术具有时间依赖性，包含了纸面上或计算机上对一些指令的执行。例子包括结构化走查、边界值测试等。

来容知已经半年多了 什么收获也没有

公司对测试的态度 让我沉迷了整整半年之多

今天 就是今天 我要跟自己说 崛起 

1.1 什么是质量

质量可以定义为以下两种

一种定义为满足需求;另一种定义为产品或服务满足了客户的需求,换一种说法就是"适用"

1.2预防与检测

质量是不能通过评估已经生产出来的产品来达到的,因此,目标有该是首先去预防产品缺陷的产生,并且使产品可以通过质量保证量度进行评估

1.3验证与确认

验证贯穿在整个开发生命周期中,用来评价产品是否满足了在前面一些已经正确完成的活动中定义的需求,而确认发生在生命周期的末尾,用来检查系统是否满足了客户的需求.

1.4软件质量保证

是指为整个软件产品的使用性提供证据的系统化活动

质量控制 是把产品质量与可应用的标准相比较的过程,以及当检测出不一致是要采取的措施.

审计 是指严整产品是否符合计划\政策\和过程的检查/评估过程

软件质量糟糕的表现:

1)已经交付的软件频繁的出现故障;

2)系统运行失败所带来的后果令人无法接受,诸如经济损失甚至威胁生命安全;

3)系统经常不能实现预期的目的

4)系统升级的成本经常很高

5)发现逼供内排除缺陷的成本很高

大部分质量风险都与缺陷有关,但还不仅仅如此.缺陷的产生是由于不能满足某一项需求.如果需求本身是不 恰当的,甚至是不正确的,那么缺陷的风险就会更大,结果就会产生很多内置缺陷,而这些缺陷是根本无法验证的.在有些风险管理策略和技术中就包括软件测试\技术评审\同行评审及兼容验证等

1.5质量保证的组成

大部分软件质量 保证活动可划分为软件测试(即验证与确认)\软件配置管理和质量控制

1.6软件测试

在软件设计和实现的过程中,验证可以用来帮助确定软件开发生命周期中某个阶段的产品是否满足前一阶段确立的需求.

1.7质量控制

质量控制可以定义为用来监督工作进展和观测需求是否被满足的过程和方法,它主要侧重与在产品发布以前评审和排除缺陷.

就软件产品而言,典型的质量控制一般包括规约评审\代码和文档检查以及用户交付物检查

狭义的性能测试主要用于描述常规的性能测试，是指通过模拟产生运行的业务压力或者用户使用场景来测试系统的性能是否满足生产性能的要求。

    广义的性能测试则是压力测试、负载测试、强度测试、并发（用户）测试、大数据量测试、配置测试、可靠性测试等和性能相关的测试统称。

 

预期性能测试用例

    在系统需求设计阶段预先提出的、期望系统达到的，或者向用户保证的性能指标。针对每个指标都要编写一个或多个测试用例来验证系统是否达到要求，如果达不到目标，则需根据测试结果来改进系统的性能。

 

用户并发性能测试用例

    用户并发性能测试要求选择具有代表性的、关键的业务来设计测试用例，以便更有效的评测系统性能。

 

疲劳强度与大数据量测试

    大数据量测试主要是针对那些对数据库有特殊要求的系统而进行的测试。（实时大数据量测试、极限状态下的测试、前面两种的结合）

 

网络性呢功能测试

    基于硬件的测试：主要通过各种专用软件工具、仪器等来测试整个系统的网络运行环境，一般由专门的系统集成人员来负责。

    基于应用系统得测试：在实际的软件项目中，主要测试用户数目与网络带宽的关系。通过测试工具准确展示带宽、延迟、负载和端口的变化是如何影响用户响应时间。

 

服务器性能测试

    高级服务器性能测试：主要指在特定的硬件条件下，由数据库、WEB服务器、操作系统相应领域的专家进行性能测试。

    初级服务器性能测试：主要指在业务系统工作或进行前面其他种类性能测试的时候，监控服务器的一些些计数器信息。通过这些计数器对服务器进行综合性能分析，找出系统瓶颈，为调优或提高性能提供依据。

1.压力测试（Stress Testing）的概念

 压力测试（Stress Testing）是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。扩展开来说，其一压力测试应该是较短时间的，其次是模拟巨大的工作负荷的，再次压力测试是要使应用程序的使用达到峰值

2.如何进行压力测试

测试前提:需要了解AUT（被测应用程序）一般能够承受的压力，同时能够承受的用户访问量（容量），最多支持有多少用户同时访问某个功能。