软件缺陷的正式定义
符合下列5个规则才能叫软件缺陷：
1. 软件未达到产品说明书标明的功能
2. 软件出现了产品说明书指明不会出现的错误
3. 软件功能超出产品说明书指明范围
4. 软件未达到产品说明书虽未指出但应达到的目标
5. 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
软件测试员的目标
尽可能早地找出软件缺陷，并确保其得以修复。
软件测试员应具备的素质
－ 探索精神（喜欢拿到新软件）
－ 故障排除能手（善于发现问题的症结）
－ 不懈努力（不停尝试）
－ 创造性（想出富有创意甚至超常的手段来寻找缺陷）
－ 追求完美（但对知道无法企及的东西也不强求）
－ 判断准确（决定测试内容、测试时间、是否真正的缺陷）
－ 老练稳重（知道如何将坏消息告诉程序员，知道如何跟不够冷静的程序员合作）
－ 说服力（善于表达观点，通过实际演示标明缺陷为何必须修复）
软件开发模式
从最初构思到公开发行软件产品的过程称为软件开发模式。
－ 大棒式（要么成功，要么失败）
－ 边写边改式（没有时间做好，总有时间返工）
－ 流水式（创意、分析、设计、开发、测试、产品一步步进行，不能后退。前一步完成才能进入下一阶段）
－ 螺旋式（主要思想是：开始不必详细定义所有细节。从小开始，定义重要功能，努力实现，接受客户反馈，然后进入下一阶段。一个螺旋包括6个步骤：1.确定目标、可选方案和限制条件；2.指出并解决风险；3.评估方案；4.本阶段开发和测试；5.计划下一阶段；6.确定进入下一阶段的方法）
术语－准确 vs 精确
－ 准确：参照物是目标。与目标越接近，就越准确
－ 精确：参照物是每次实施的结果。几次结果相互之间越接近，表示越精确。但与目标可能相去甚远
术语－验证 vs 合法性检查
－ 验证：保证软件符合产品说明书的过程
－ 合法性检查：保证软件满足用户要求的过程。
很多时候产品说明书并没有完全反映出用户的要求！
术语－测试 vs 质量评判(QA)
－ 测试：软件测试员的目标是找出软件缺陷，尽可能造一些，确保得以修复。
－ 质量评判：软件质量评判人员的主要指责是创建和加强促进软件开发并防止软件缺陷的标准和方法
黑盒测试 vs 白盒测试
－ 黑盒测试：软件测试员只需知道软件要做什么，无需知道是如何运作的。只关心输入和输出
－ 白盒测试：软件测试员可以访问程序员的代码，并通过检查代码来协助测试。
静态测试 vs 动态测试
－ 静态测试：只测试不运行的部分——只是检查和审阅。
－ 黑盒测试：指通常意义上的测试——运行和使用软件。
对产品说明书进行审查
－ 熟悉软件应用领域的相关知识
这一点极有好处，设身处地的为客户着想
－ 研究现有的标准和规范。
软件测试员要做的，不是定义、而是“检验”是否套用了正确的标准，有无遗漏。
如：公司惯用语和约定；行业要求；国家标准；图形用户界面；硬件和网络标准
－ 审查和测试同类软件
同类软件有助于制订测试条件和测试方法，还可能暴露没想到的潜在问题。
** 低级测试－ 属性检查清单（8个）
~ 完整。 完全？单独使用是否包含全部内容？
~ 准确。 方案正确？目标明确？
~ 精确、不含糊、清晰。 容易看懂和理解？
~ 一致。 功能描述是否自相矛盾？有无冲突？
~ 贴切。 功能陈述是否必要？信息冗余？是否客户要求？
~ 合理。 以现有人力、物力和资源能否实现？
~ 代码无关。 定义产品，而不是设计、架构或代码！
~ 可测试。 是否提供足够的测试信息？
－ 用语检查清单
~ 总是、每一种、所有、没有、从不。
对此类绝对或肯定的切实认定的叙述，应设计针锋相对的案例。
~ 当然、因此、明显、显然、必然。
这些话意图诱使接受假定情况。小心中了圈套哦。
~ 某些、有时、常常、通常、经常、大多、几乎、
太过模糊。“有时”发生的功能无法测试。
~ 等等、诸如此类、依此类推、
以这样的词结束的功能清单无法测试。功能清单必须绝对、解释明确。不能推论。
~ 良好、迅速、廉价、高效、稳定、
这些是不确定的说法，不可测试。必须要求进一步指明含义。
~ 已处理、已拒绝、已忽略、已消除、
这些说法可能会隐藏大量需要说明的功能
~ 如果……那么……（没有否则）。
想想，“如果”没有发生会怎样呢？** 高级审查
动态黑盒测试
不深入代码细节的软件测试方法。常被称为行为测试，因为测试的是软件在使用过程中的实际行为。
首先，从产品说明书获知测试对象的软件的输入和应该得到的输出。
接下来，开始定义测试案例。 测试案例：指进行实验用的输入，以及测试软件用的程序。
选择测试案例是软件测试员最重要的任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。准确评估风险，把不可穷近的可能性减少到可以控制的范围是成功的诀窍。
测试基本方法：通过测试 vs 失败测试
通过测试：确认软件至少能做什么，而不考验其能力。
失败测试：纯粹为了破坏软件而设计和执行的测试案例，也称为迫使出错测试。蓄意攻击软件的薄弱环节。
在设计和执行测试案例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多的软件缺陷。
常见的测试案例就是设法迫使软件出现错误提示信息。产品说明书可能会给出这样的功能要求，针对这个问题的测试可能是通过测试也可能是失败测试。可能两者都是。不用去刻意区分，重要的是找到软件缺陷！
选择测试案例：等价分配
等价分配：是指分步骤地把过多（无限）的测试案例减小到同样有效的小范围的过程。也称等价划分。
等价分配技术提供了一个选择哪些数值、舍弃哪些数值的系统方法。
等价类别或者等价区间是指测试相同目标或者暴露相同软件缺陷的一组测试案例。在寻找等价区间时，想办法把软件的相似输入、输出、操作分成组。这些组就是等价区间。
等价分配的目的是把可能的测试案例组合缩减到仍然足以测试软件的控制范围。因为选择了不完全测试，就要冒一定的风险。如果为了减少测试案例的数量过度进行等价分配，测试的风险就会增加。另外，等价区间的划分没有一定的标准，只要足以覆盖测试对象就行了。
数据测试
软件由数据（包括键盘输入、鼠标单击、磁盘文件、打印输出等等）和程序（可执行的流程、转换、逻辑和运算）两个最基本的要素组成。
对数据进行软件测试，就是在检查用户输入的信息、返回结果以及中间计算结果是否正确。主要根据下列原则来进行等价分配，以合理减少测试案例：边界条件、次边界条件和无效数据。
1. 边界条件测试
程序在处理大量中间数值时都是对的，但是可能在边界处出现错误。比如数组的[0]元素的处理。想要在Basic中定义一个10个元素的数组，如果使用 Dim data(10) As Integer ，则定义的是一个11个元素的数组，在赋初值时再使用 For i =1 to 10 ...来赋值，就会产生权限，因为程序忘记了处理i＝0的0号元素。
边界条件是指软件计划的操作界限所在的边缘条件。
数据类型：数值、字符、位置、数量、速度、地址、尺寸等，都会包含确定的边界。
应考虑的特征：第一个/最后一个、开始/完成、空/满、最慢/最快、相邻/最远、最小值/最大值、超过/在内、最短/最长、最早/最迟、最高/最低。这些都是可能出现的边界条件。
根据边界来选择等价分配中包含的数据。然而，仅仅测试边界线上的数据点往往不够充分。提出边界条件时，一定要测试临近边界的合法数据，即测试最后一个可能合法的数据，以及刚超过边界的非法数据。以下例子说明一下如何考虑所有可能的边界：
如果文本输入域允许输入1－255个字符。
尝试：输入1个字符和255个字符（合法区间），也可以加入254个字符作为合法测试。
输入0个字符和256个字符作为非法区间。
如果程序读写软盘
尝试：保存一个尺寸极小，甚至只有一项的文件。
然后保存一个很大的——刚好在软盘容量限制之内的文件。
保存空文件。
保存尺寸大于软盘容量的文件。
如果程序允许在一张纸上打印多个页面
尝试：只打印一页
打印允许的最多页面
打印0页
多于所允许的页面（如果可能的话）
2. 次边界条件测试
上面所讲的是普通的边界条件，在产品说明书中有定义，或者在软件的过程中确定。但有些边界在软件内部，最终用户几乎看不到，但是软件测试仍有必要检查，这样的边界条件成为次边界条件或者内部边界条件。寻找这样的边界条件，不要求软件测试员成为程序员或者具有阅读源代码的能力，但是确实要求大体了解软件的工作方式。2的乘方和ASCII表是这样的两个例子： 2的乘方
术语 | 范围或值 |
位bit | 0或1 |
双位doublebit | 0～15 |
字节Byte | 0~255 |
字word | 0~65,535或者0～4,294,967,295 |
千K | 1,024 |
兆M | 1,048,576 |
亿 | 1,073,741,824 |
万亿 | 1,099,511,627,776 |
计算机和软件的基础是二进制数。因此二的乘方是作为边界条件的重要数据。如：在通讯软件中，带宽或者传输信息的能力总是受限制，因此软件工程师会尽一切努力在通讯字符串中压缩更多数据。其中一个方法就是把信息压缩到尽可能小的单元中，发送这些小单元中最常用的信息，在必要时再扩展为大一些的单元。假设某种通讯协议支持256条命令。软件将发送编码为一个双位数据的最常用的15条命令；如果用到第16到256之间的命令，软件就转而发送编码为更长字节的命令。这样，软件就会根据双位/字节边界执行专门的计算和不同的操作。
在建立等价区间的时候，要考虑是否需要包含2的乘方边界条件。例如：软件接受1～1000范围内的数字，那么合法区间除了1和1000，也许还有2和999之外，还应该有临近2的乘方次边界：14，15，16以及254，255和256。
ASCII表
ASCII码表并不是结构良好的连续表。数字0～9对应48～57；斜杠字符(/)在0的前面，冒号(:)在9的后面；大写字母A～Z对应65～90；小写字母对应97～122。这些情况都代表次边界条件。
如果测试进行文本输入或文本转换的软件，在定义数据区间包含哪些值时，参考一下ASCII表是相当明智的。例如：测试的文本框只接受用户输入字符A～Z和a～z，就应该在非法区间中包含ASCII表中这些字符前后的值——@，'，[，{。 3. 默认值测试（默认、空白、空值、零值和无）
好的软件会处理这种情况，常用的方法：一是将输入内容默认为合法边界内的最小值，或者合法区间内某个合理值；二是返回错误提示信息。
这些值在软件中通常需要进行特殊处理。因此应当建立单独的等价区间。在这种默认下，如果用户输入0或－1作为非法值，就可以执行不同的软件处理过程。
4. 破坏测试（非法、错误、不正确和垃圾数据）
数据测试的这一类型是失败测试的对象。这类测试没有实际规则，只是设法破坏软件。不按软件的要求行事，发挥创造力吧！
状态测试
状态测试是通过不同的状态验证程序的逻辑流程。软件测试员必须测试软件的状态及其转换。软件状态是指软件当前所处的情况或者模式。软件通过代码进入某一个流程分支，触发一些数据位，设置某些变量，读取某些变量，从而转入一个新的状态。
同数据测试一样，状态测试运用等价分配技术选择状态和分支。因为选择不完全测试，所以要承担一定的风险，但是通过合理选择减少危险。
1. 建立状态转移图
使用：方框和箭头；圆圈（泡泡）和箭头。
应包含的项目：
－ 软件可能进入的每一种独立状态。
如果不能断定是否独立，先认为是；以后一旦发现不是，随时剔除。
－ 从一种状态转入另一种状态所需的输入和条件。
状态变化和存在的原因，就是我们要寻找的对象。
－ 进入或退出某种状态时的设置条件及输出结果。
包括显示的菜单和按钮、设置的标志位、产生的打印输出、执行的运算等等。
由于是黑盒测试，因而只需从用户的角度建立状态图即可。
2. 减少要测试的状态及转换的数量
测试每一种路线的组合，走遍所有分支是不可能的事情。大量的可能性也需要减少到可以操作的测试案例集合。方法有以下5种：
－ 每种状态至少访问一次。
无论用什么方法，每种状态都必须测试。
－ 测试看起来最常见最普遍的状态转换
－ 测试状态之间最不常用的分支。
这些分支是最容易被产品设计者和程序员忽视的。
－ 测试所有错误状态机器返回值。
错误是否得到正确的处理、错误提示信息是否正确、修复错误时是否正确恢复软件等
－ 测试随机状态转换。
3. 进行具体的测试——定义测试案例
测试状态及其转换包括检查所有的状态变量——与进入和退出状态相关的静态条件、信息、值、功能等等。如：窗口外观、窗口尺寸定义（固定/上次使用时的尺寸）、显示的菜单、默认设定值、文档的名称等。状态无论是否可见，都必须进行状态确定。 状态变量也许不可见，但是很重要，一个常见的例子时文档涂改标志（以此判断退出时是否询问保存）。
失败状态测试
状态测试的失败测试的案例，主要是竞争条件、重复、压迫和重负。
1. 竞争条件和时序错乱
设计多任务操作系统不是很难，设计充分利用多任务能力的软件才是艰巨的任务。在真正的多任务环境中软件设计绝对不能想当然，必须处理随时被中断的情况，能够与其他任何软件在系统中同时运行，并且共享内存、磁盘、通信设备以及其他硬件资源。
这样的结果，就是导致竞争条件问题；软件未预料到的中断发生，时序就会发生错乱。
竞争条件测试难以设计，最好是首先仔细查看状态转换图中的每一个状态，以找出哪些外部影响会中断该状态。考虑要使用数据如果没有准备好，或者在用到时发生了变化，状态会怎样。数条弧线或者直线同时相连的情形如何。
一下是要面临竞争条件的典型情形：
－ 两个不同的程序同时保存或打开同一个文档。
－ 共享同一台打印机、通信端口或者其他外围设备。
－ 当软件处于读取或者修改状态时按键或者单击鼠标。
－ 同时关闭或者启动软件的多个实例。
－ 同时使用不同的程序方位一个共同数据库。
2. 重复、压迫和重负
这三个测试的目标是处理那些连程序员都没有想到的恶劣条件下产生的问题的能力。
－ 重复测试
重复测试是不断执行同样的操作。最简单的是不停地启动和关闭程序，或者反复读写数据或者选择同一个操作。这种测试的主要目的是看内存是否不足。如果内存被分配进行某项操作，但操作完成时没有完全释放，就会产生一个常见的软件问题。
－ 压迫测试
压迫测试是使软件在不够理想的条件下运行——内存小、磁盘空间少、CPU速度慢、调制解调器速率低等等。观察软件对外部资源的要求和依赖程度。压迫测试就是将支持降到最低限度，目的在于尽可能的限制软件的必要条件。
－ 重负测试
重负测试和压迫测试相反。压迫测试是尽量限制软件，而重负测试是尽量提供条件任其发挥。让软件处理尽可能大的数据文件。最大限度的发掘软件的能力，让它不堪重负。比如：软件对打印机或通信端口进行操作，就把能连的都连上；服务器可以处理几千个模拟连接，就按他说的做。
不要忘了，时间也是一种重负测试。
重复、压迫和重负测试应联合使用，同时进行。
需要注意的是：
一，项目管理员和小组程序员可能不完全接受软件测试员这样打破软件的做法。但是软件测试员的任务就是确保软件在这样恶劣的条件下正常工作，否则就报告软件缺陷。如何以最佳方式报告软件缺陷，使其得到严肃对待和修复，也是一门学问。
二，无数次重复和上千次的连接对于手工操作是不可能的。因而需要借助自动化测试工具来实现。
其他黑盒测试方法
1. 像无经验的用户那样做
输入意想不到的数据；中途变卦而退回去执行其他操作；单击不应该单击的东西……
2. 在已经找到软件缺陷的地方再找找
原因有二：一是软件缺陷的集中性。如果发现在不同的特性中找出了大量上边界条件软件缺陷，那么就应该对所有特性着重上边界条件。对某个存在的缺陷，应当投入一些案例来保证这个问题不是普遍存在的。二是程序员往往倾向于只修改报告出来的软件缺陷，不多也不少。比如报告启动－终止－再启动255次导致冲突，程序员可能只修复了这个问题。重新测试时，一定要重新执行同样的测试256次以上。
3. 凭借经验、直觉和预感
记录哪些技术有效，哪些不行。尝试不同的途径。如果认为有可疑之处，就要仔细探究。按照预感行事，直至证实这是错误为止。
经验是人们对错误行为的称谓。
《软件测试》读书笔记（四）
静态测试是指测试非运行部分——检查和审查。白盒测试是指访问代码，能够查看和审查。
静态白盒测试实在不执行的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。有时也成为结构分析。
静态白盒测试的原因，首先是尽早发现软件缺陷；另外可为接受该软件测试的黑盒测试员提供应用测试案例的思路，他们不必了解代码细节，根据审查备注就可以确定可能存在问题的特性范围。
正式审查——进行白盒测试的过程
正式审查含义广泛，从程序员之间的交谈，到代码的严格检查均属于此过程。主要有4个基本要素：
－ 确定问题。
审查的目的，不仅是出错的，还包括遗漏的项目。全部的批评应直指代码，而不是其创建者。
－ 遵守规则
审查要遵守一套固定的规则，可能设定审查的代码量、花费时间、备注内容对象，以帮助合作者确定 自己的目标，了解自己的作用。
－ 准备
每个合作者需要了解自己的责任和义务，并积极参与审查。
－ 编写报告
审查小组必须做出总结审查结果的书面报告，并使报告便于开发小组使用。
正式审查的类型
1. 同事审查
召集小组成员进行初次正式审查是最简单的方法。大体类似于“各抒己见”类型的讨论。常常仅在编写代码的程序员和充当审查者的其他一两个程序员和测试员之间进行。
2. 公开陈述
公开陈述是使同事审查正规化的下一步。编写代码的程序员像5人小组或其它类似的程序员或测试员正式表述，逐行或逐个通读代码，解释代码如何工作的以及为什么。审查人员应该在审查之前接到软件拷贝，以便检查并编写备注和问题，在审查过程中提问。参与人数要多于同事审查。因此，做好准备和遵守规则是十分重要的。
3. 检验
检验是最正式的审查类型，具有高度组织化，要求每一个参与者都接受训练。检验与同事审查不同之处在于表述代码的人（表述者或宣读者），不再是原来的程序员。这就迫使他学习和了解要表述的材料，从而有可能提出不同的看法和解释。
检验员在检验中的职责是从不同的角度（如用户、测试员或产品支持人员）的角度审查代码，指出软件缺陷。检验会议后，检验员可能再次碰头讨论他们发现的不足之处，并与会议主席共同准备一份书面报告，明确解决问题所必须重做的工作。
编码标准和规范
坚持标准或规范的原因：
－ 可靠性。事实证明，代码缺陷将更少
－ 可读性、维护性。
－ 移植性。如果代码符合设备标准，迁移到另一个平台就会轻而易举。
标准由4个主要部分组成：
－ 标题。描述主题。
－ 标准（或规范）。描述内容，解释哪些允许，哪些不允许。
－ 解释说明。给出指定该标准的原因。说服程序员。
－ 实例。这不是必需的。
注意：标准/规范和风格不是一回事。后者不是缺陷。
通过代码审查清单
1. 数据引用错误
是指使用未经正确初始化用法和引用方式的变量、常量、数组、字符串或记录而导致的软件缺陷。如：变量未初始化、数组和字符串下标越界、对数组的下标操作遗漏[0]、变量与赋值类型不一致、引用的指针未分配内存……
2. 数据声明错误
数据声明软件缺陷产生的原因是不正确的声明或使用变量和常量。
3. 计算错误
计算或者运算错误是基本的数学逻辑问题。计算无法得到预期结果。如：不同数据类型 或 数据类型相同但长度不同的变量计算、计算过程中或计算结果溢出、赋值的目的变量上界小于赋值表达式的值、除数/模为0、变量的值超过有意义的范围（如概率的计算结果不在0－1范围内）……
4. 比较错误
小于、大于、等于、不等于、真、假。比较和判断错误很可能是边界条件问题。如：混淆小于和小于等于、逻辑表达式中的操作数不是逻辑值……
5. 控制流程错误
控制流程错误的原因是编程语言中循环等控制结构未按预期方式工作。通常由计算或者比较错误直接或间接造成。如：模块或循环无法终止、存在从未执行的代码、由于变量赋值错误而意外进入循环……
6. 子程序参数错误
子程序参数错误的来源是软件子程序不正确的传递数据。如：实际传送的参数类型或次序与定义不一致、更改了仅作为输入值的参数……
7. 输入/输出错误
包括文件读取、接受键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。如：软件没有严格遵守外部设备读写数据的专用格式、文件或外设不存在或者为准备好的错误情况发生时没有相应处理、未以预期的方式处理预计错误、错误提示信息不正确/不准确……
8. 其他检查
软件是否使用其他外语？处理字符集的范围（ASCII或Unicode）？是否需要移植？是否考虑兼容性？编译时是否产生警告或提示信息？
动态白盒测试
动态白盒测试是指利用查看代码功能和实现方式得到的信息来确定哪些要测试，哪些不要测试，如何开展测试。动态白盒测试的另一个常用名称是结构测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。
动态白盒测试不仅仅是查看代码，还包括直接参数和控制软件。动态白盒测试包括以下4个部分：
－ 直接测试底层功能、过程、子程序和库。即应用程序接口（API）
－ 以完整程序的方式从顶层测试软件，但是要根据对软件运行的了解调整测试案例。
－ 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以
正常测试难以实现的方式运行。
－ 估算执行测试时“命中”的代码量和具体代码，然后调整测试，去掉多余的，补充遗漏的。
动态白盒测试 vs 调试
白盒测试的目标是寻找软件缺陷，调试的目的是修复它们。但是二者又有交叉的现象。测试员应该把问题缩减为能够演示软件缺陷的最简化测试案例。在白盒测试中，甚至要包含那些值得怀疑的代码行信息，以方便程序员有针对性的分析、判断进而修复。
一定要分清软件测试员和程序员的工作。程序员编写代码，测试员寻找软件缺陷，可能还要编写一些代码来驱
动测试，然后程序员修复软件缺陷。
要进行这样的底层测试，就要使用与程序员相同的工具。如果程序已经编译过，就要使用同样的编辑器，但是
采用不同的设置，以加强错误检测功能。
分段测试
从测试的角度看，产生高额费用有两个原因：
－ 难以甚至不可能找出导致问题的原因
－ 某些软件缺陷掩盖了其他软件缺陷。造成核心错误很难弄清。
单元测试和集成测试
在底层进行的测试称为单元测试或者模块测试。等到单元测试后，底层软件缺陷被找出并修复之后，就集成在一起，对模块组进行集成测试。最后直到整个产品（至少是主要部分）集成到一起进行系统测试。
这种测试策略很容易隔离软件缺陷。主要有两条途径：
－ 自底向上
需要编写测试驱动模块来测试对象模块。测试驱动模块以将来真正模块同样的方式挂接，向处于测试底案例发送测试案例数据，接受返回结果，验证结果是否正确。
－ 自顶向下
这种情况下，可以使用测试存根代码的编写，充当下层接口模块，从文件中直接将参数提供给上层模块。这样，就可以从头到尾试验各种测试值，验证上层模块的操作。
示例：C语言中，将ASCII字符转换为整数值的函数atoi()。
－ 首先，确定该模块在程序中的位置——底层模块，可以由高层模块调用，但是自己不能调用其他模块。通过查看内部代码可以确认这一点。
－ 由上一步判定，确定应编写一个测试驱动以独立于程序其他不分的形式测验该模块。该测试驱动提
供测试字符串，读取返回值，与预期结果相比较。编写测试驱动的语言可以与函数的语言相同也可以不同；形式上，可以是简单的对话框（交互性和灵活性强），也可以是独立的程序（可快速的从文件读写测试用例）。
－ 分析说明书，确定应该采用的黑盒测试案例，然后运用等价分配技术参少测试案例集合。
－ 研究代码看函数是如何实现的，利用模块的白盒知识增减测试用例。
注意：在进行白盒测试之前，一定么根据说明书建立黑盒测试案例。这样才能够保证真正测试模块的用意，完成测试预期的操作，而避免白盒测试中受代码的影响而偏向模块工作方式建立测试案例。
白盒测试时，合理的做法也是把软件分成数据和状态（或者程序流程）。从同样的角度看待软件，可以很轻松的把白盒信息映射到已经写完的黑盒测试案例上。
数据范围
数据包括所有的变量、常量、数组、数据结构、键盘和鼠标输入、文件、屏幕输入/输出，以及调制解调器、网络等其他设备的输入/输出。
1. 数据流
数据流范围主要是指在整个软件中跟踪一批数据。在单元测试级，数据仅仅通过了一个模块或者函数。如果在底层测试，就会使用调试器和观察变量在程序运行时查看代码，检查中间值，从而保证质量。
2. 次边界
白盒测试要仔细检查代码，找到次边界条件，并建立测试他们的案例。除了ASCII码表和2的乘方之外，常见的例子比如：运算时可能由使用数据表转向使用公式；数据可能由RAM转向硬盘；数值分析程序可能根据数字大小采用不同的方程式……
3. 公式和等式
公式和等式通常深藏于代码中，从外部看，表现和影响不是很明显。但是，在某些公式中，比如：
A=P(1+r/n)，白盒测试员在看到这个公式之后，就知道选择n=0作为测试案例将导致除零错，这样不需运行测试用例即可预知缺陷。
然而，如果n是计算的结果（即可能会有很多种可能值），那么测试员就应该考虑有没有n为零值的情形，并指出什么样的程序输入会导致它出现。
4. 错误强制
在执行测试用例时，不能或不方便使某一变量达到设定值，可通过强制赋值的方式达到目的。
在使用错误强制时，小心不要设立现实世界中不可能出现的情况。比如，上例中，如果函数开头有判断n值必须大于0，而且n只存在于该公式中，那么将n值强制设为零的测试案例就是不合理的。使用错误强制是迫使软件中所有错误提示信息显示出来的好方法。因为许多错误情况是难以建立的，比如挂接2049台打印机。如果只是想测试错误提示信息是否正确，那么使用错误强制是最有效的。
代码范围
测试程序的状态以及其中的程序流程，必须设法进入和退出每一个模块，执行每一行代码，追踪每一条逻辑和决策分支。按级别详细检查软件称为代码范围分析。代码范围分析要求通过完全访问代码查看运行测试案例时经过哪些部分。其最简单的形式是利用编译环境的调试器通过单步执行程序查看代码。对于大程序，需要用到称为代码范围分析器的专用工具。从的得到的数据中可以很容易的获知：测试案例没有覆盖软件的哪些部分、哪些测试案例是多余的（增加该案例却未增加代码覆盖比例）等，从而判定还需要建立哪些新的测试案例。
程序语句和代码行范围
代码范围最直接的形式称为语句范围或者代码行范围。如果在测试软件的同时监视语句范围，目标就是保证程序中每一条语句最少执行一次。但是，从某种程度上说，语句范围是一种误导，因为即使全部语句被执行了，并不代表走遍了软件的所有路径。
分支范围
试图覆盖软件中的所有路径称为路径测试。路径测试最简单的形式称为分支范围测试。注意每一个判断条件（组合）都会产生分支，即每个判断条件（条件组合）的结果取真或假，都应该执行一次。
条件范围
条件范围测试将分支语句的附加条件考虑在内。与分支范围不同的地方主要体现在多重条件的组合上。分支范围把条件组合看作一个整体，而条件范围把这种组合拆开，而对每个具体条件进行分析。保证每个具体条件的真假取值都做一遍。
在前面几篇博客中简单的写了一下在工作中使用loadrunner 的情况，这一篇是前面工作完成以后才进行的步骤，当然这一步也差不多就是最后一步了。
Analysis 会话的目的是查找系统的性能问题，然后找出这些问题的根源，例如：
1.是否达到了预期的测试目标？在负载下，对用户终端的事务响应时间是多少？
2.是符合SLA 还是偏离了目标？事务的平均响应时间是多少？
3.系统的哪些部分导致了性能下降？网络和服务器的响应时间是多少？
首先是如何启动Analysis
1.打开HP Loadrunner11
选择开始 > 程序 > HP LoadRunner > LoadRunner。这时将打开HP LoadRunner11.00 窗口。
2.打开LoadRunner11 Analysis
在loadrunner11 launcher选项卡中单击分析负载测试---analysis Test Result ，这时将打开loadrunner11的 loadrunner analysis窗口。
3.打开analysis会话文件
为了配合本教程中的这一部分，得到更多不同的结果，我们运行了一个与您在前面课程中所运行的场景相类似的测试场景。但是这次测试使用了70 个Vuser，而不是10 个。现在您可以打开使用此场景的结果所创建的Analysis 会话。在Analysis 窗口中，选择文件 > 打开。这时将打开“打开现有Analysis 会话文件”对话框。
在<LoadRunner 安装位置>\tutorial 文件夹中，选择analysis_session 并单击打开。
Analysis 将在 Analysis 窗口中打开该会话文件。
10.3Analysis窗口一览
Analysis主要包含以下窗口：
会话浏览器
属性窗口
图查看区域
图例
备注：被页面上的链接，点击链接得到的就是图例和报告，图表说明。
“会话浏览器”窗格。位于左上方的窗格， Analysis 在其中显示已经打开可供查看的 报告和图。您可以在此处显示打开 Analysis 时未显示的新报告或图，或者删除自己不想再查看的报告或图。
“属性”窗格。位于左下方的窗格，属性窗口在其中显示您在会话浏览器中选择的图或 报告的详细信息。黑色字段是可编辑字段。
“图查看区域”。位于右上方的窗格， Analysis 在其中显示图。默认情况下，打开会话时，概要报告将显示在此区域。
“图例”。位于右下方的窗格，在此窗格内，您可以查看所选图中的数据。
备注：有几个可以从工具栏访问的其他窗口，它们提供附加信息。这些窗口可以在屏幕上随意拖放。
通过Analysis分析得到的值具有很大的参考性，一个系统的性能通过Analysis的分析就清楚的展现在眼前，当然这里面涉及到服务器的内存之类的指标，如果loadrunner在测试过程中断掉这些指标就不准确了（这一点在上一篇博客也提到过）所以还需要一些其他的工具进行辅助记录。
在青岛进行压力测试工作学到的内容到这里也就结束了。在这20天左右的时间我学会了如何使用loadrunner，包括录制脚本，修改参数和跑场景。当然也有一些东西我没有遇到比如修改录制的脚本。在测试过程中也多少接触了一点优化系统的方面 虽然只是很小的一部分也增加了我的一些知识。 这些东西还需要继续积累。将来才能更好的应用。
1.测试项目：电梯
需求测试：查看电梯使用说明书、安全说明书等
界面测试：查看电梯外观
功能测试：测试电梯能否实现正常的上升和下降功能.电梯的按钮是否都可以用；
电梯门的打开，关闭是否正常；报警装置是否可用，报警电话是否可用；
通风状况如何.突然停电时的情况；是否有手机信号；
比如说上升途中的响应。电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按了10楼，这时候是否会在10楼先停下来；
电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停；
可靠性：门关上的一刹那出现障碍物，同时按关门和开门按钮，点击当前楼层号码，多次点击同一楼层的号码等等；同时按上键和下键会怎样；
易用性：电梯的按钮的设计符合一般人使用的习惯吗.
用户文档：使用手册是否对电梯的用法、限制、使用条件等有详细描述
压力测试：看电梯的最大限度的承受重量.在负载过重时报警装置是否有提醒.在一定时间内不断的让电梯上升，下降.最大负载下平稳运行的最长时间。
2.测试项目：杯子
需求测试： 查看杯子使用说明书
界面测试： 查看杯子外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：杯子有没有毒或细菌
可靠性：杯子从不同高度落下的损坏程度
可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用
兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等
易用性：杯子是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述
疲劳测试：将杯子盛上水(案例一)放24 小时检查泄漏时间和情况；盛上汽油(案例二)放24 小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试： 杯子加包装( 有填充物)， 在多高的情况摔下不破损
震动测试： 杯子加包装( 有填充物)， 六面震动， 检查产品是否能应对恶劣的铁路\ 公路\ 航空运输
测试数据：测试数据具体编写此处略(最讨厌写测试数据了)。其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法
期望输出：该期望输出需查阅国标、行标以及使用用户的需求
3.测试题目：桌子
需求测试：查看国家相关标准。
功能：桌子是办公，或者放置用的，首先考虑桌子的面积大小是否适度.
界面：桌子的版面是否平滑，桌子有没有凹凸不平的地方
安全：桌子肯定有它的支撑点，若支撑点不稳，容易摔坏物品，使用起来也不方便.
易用：桌子的移动性好不.它的重量是否合适
可靠性：将桌子推倒后，再检查桌子是否很容易被损坏.
性能：将很重的物品放在桌子上，看它最大承受的重量是多少…
4.测试题目：洗衣机
功能测试：该洗衣机是否能正常的洗衣服
需求测试：查看洗衣机的使用说明书和安全说明书等
性能测试：使用时用电量如何，是否满足用户需求
界面测试：洗衣机的外观是否满足客户的需求
易用测试： 该洗衣机是否容易操作
兼用性测试：该洗衣机除了能洗衣服以外还能洗别的吗
安全性测试：该洗衣机通电以后人接触以后是否有电
负载测试：通过逐步增加系统负载，最终确定在什么负载条件下系统性能将处于崩溃状态，以此获得系统能提供的最大服务
压力测试：通过逐步增加系统负载，最终确定在什么负载条件下系统性能将处于崩溃状态，以此获得系统能提供的最大服务级别的测试。
稳定性测试：加到一定的衣服然后过一段时间看洗衣机是否正常洗
性能测试模拟真实负载是比较困难的。性能测试与真实环境的对比，通常有这样一些点：
1.客户端展现。如果是Web应用，客户端使用浏览器展现的，则一些的压力测试工具都不具备展现的功能，也就是说，只是模拟发送http请求到接收请求，而浏览器对html内容进行渲染的时间，是无法模拟的，这很可能是真实环境体验现测试结果不相同的地方。客户端展现要与真实环境相同，必须单独进行前端性能的分析。
2.网络速率。性能测试时通常在局域网环境中，而真实的网络用户来自于全国甚至世界各地，其网络情况不一致，而且有很大的偶然性。除了对压测工具所在的机器进行一些网络限速之外，很难完全模拟到真实的网络负载情况。
3.软硬件配置。软件配置比较容易做到与真实环境一致，但硬件配置通常比较难做到。像线上使用的一些负载均衡机器或者路由设备比较昂贵，不可能在测试环境采用完全一样的拓扑和集群，当然这些对测试结果影响通常可以分析到，不会有很大偏差，但这是一个无法完全与线上保持相同的点。
4.数据分布。数据分布要做到与线上一致有3个难点，1是对新应用而言，根本没有线上数据，因此无从模拟，只能手动造数据，所以无法跟线上一致；2是即使是老的功能，线上数据因为商业机密等原因也未必能直接拿来作为测试数据；3是用户的访问路径，这点很难与线上做到一致。功能测试尚不能覆盖掉所有的用户操作路径，何况性能测试？
以上四点，都是问题。因此性能测试很多情况下只能作为参考，用来发现明显的性能问题。如果要做到100的准确，还是要做线上的即时监控才行。
一般性能测试我会考虑4个方面，1、系统本身性能，2、网络条件，3、软件环境 4、硬件条件。
设计性能测试方案时，首先确认，你这个方案主要的目标是什么，然后就会有根据的进行测试设计了。
例如， 有个性能需求是：测试系统某个功能的大数据量(数据量级别）的查询速度<3s，或者多用户（100用户）同时查询时的查询速度<3s。 其实这个需求的条件是不明确的。 这个只有条件1， 对于2、3、4条件都没有明确的规定。 那么这个就需要你去补齐这些条件数据。
条件4：服务器硬件条件，这个在购买服务器时，对于硬件指标能达到什么级别，都会有一个比较明确的范围的。如：硬件内存可以满足多少事务处理，处理事务的速度等等
条件3：服务器软件环境，如中间件，数据库等，是否有连接限制，数据库本身性能能否满足足够的大数据量存储等。
条件2：服务器的网络上下行速率如何，客户端的网络上下行速率又如何，网络条件是很能影响测试结果的一个条件。
那么，对于上面的性能需求，因为你需要验证的是系统本身的性能是否达到要求。那么条件2、3、4是可变的。
简单的一个方案就是：
条件2 条件3 条件4
1 A C E
2 B D F
3 A D F
4 B C E
5 A D E
6 B C F
满足上面的一行条件，然后去验证 上面的性能需求是否达到要求，并且还要延伸做的是，在该条件下，能该性能指标能最大能达到什么数值。
然后对结果进行对比分析， 其实性能测试的方案设计及过程并不难，难的是结果的对比分析，这个需要靠经验和对性能指标的敏感度才能很好的体现。
以此类推，对于其他单个条件的，多个条件的性能测试，同样可以按照这个尝试。
当然，性能本身就是一个受很多因素影响的，简单的分类肯定不能满足实际的复杂程度，
但是个人觉得，我们把实际复杂的场景合理的简单化，其实对系统的发展是有帮助的