测试用例三范式
1. 输入
2. 输出（预想）
3. 执行顺序

执行的顺序
1. 测试用例流执行
创建记录
读记录
更新记录
读记录
删除记录
读记录
2. 独立测试用例执行

测试的类型
1. 黑盒测试
2. 白盒测试
3. 灰盒测试

测试的级别
1. 单元测试
2. 集成测试
3. 系统测试
4. 接收测试

WEB测试的关注点
1. 代码质量
2. 功能性
3. 易用性
4. 性能
5. 安全

黑盒测试
1. 等价类
分类，取代表值进行测试

2. 边界值测试
越界值-边界值-界内值

总结：
等价类，代表值 （等价类取代表值进行测试）
边界值，大小1  （边界值最大最小多一少一）
超范围、非法值，要入力，不允许 （超范围和非法字符要做输入检查）
边界值一定是代表值，但代表值不一定是边界值
  
3. 决策表
条件-业务规则-Action
适用于业务规则较多，条件和Action较规则少的场合。

4. 状态机分析法
将程序的各个处理部分视为状态机的一个状态
找出从源点到结束（可能有多个结束状态）的所有有向图的可能路径（N-1）

5. PairWise分析
解决组合爆炸的途径，采用欧拉算术进行分析
PairWise矩阵
N个条件时，PairWise矩阵的任意N列均可以生成完整的条件值组合

例如，两位二进制的PairWise矩阵为
0 0 0
0 1 1
1 0 0
1 1 0

只需测试其中2组就可以认为其他组没有问题

6. 域分析（3O1I分析）
On/In/Out/Off
ON：在边界上
OFF：不在边界上
IN：在边界内
OUT：不满足任何一个边界条件
1. (≥, >, ≤, or <) 场合，选择ON和OFF
2. =场合，选择1个ON点和两个OFF点

7. 基于用例（useCase）测试

白盒测试
1.控制路径测试（Control Flow Testing）
保证所有可能的执行路径都能被测试到
2. 数据流测试
保证程序中每一个数据的生命周期得以执行（从创生或串行化到消亡或被存储）

何时停止测试（考虑因素）
1. 覆盖率
2. 缺陷发现率
3. 边际成本
4. 项目组认可度

一、单元测试环境配置测试
1. 网络连接是否正常
2. 网络流量负担是否过重
3. 软件测试平台是否可选
4. 如果（3），是否在不同的软件测试平台进行软件测试
5. 所选软件测试平台的版本（包括Service Pack）是否正确
6. 所选软件测试平台的参数设置是否正确
7. 所选软件测试平台上正在运行的其它程序是否会影响测试结果
8. 画面的分辨率和色彩设定是否正确
9. 对硬件测试平台的要求和支持程度

二、代码测试
A 静态测试
1. 同一程序内的代码书写是否为同一风格
2. 代码布局是否合理、美观
3. 程序中函数、子程序块分界是否明显
4. 注释是否符合既定格式
5. 注释是否正确反映代码的功能
6. 变量定义是否正确（长度、类型、存储类型）
7. 子程序（函数和方法）接受的参数类型、大小、次序是否和调用模块相匹配合
8. 函数的返回值类型是否正确
9. 程序中是否引用了未初始化变量
10. 数组和字符串的下标是否为整数
11. 数组和字符串的下标是否在范围内（不“越界”）
12. 进行数组的检索及其它操作中，是否会出现“漏掉一个这种情况”
13. 是否在应该使用常量的地方使用了变量（例：数组范围检查）
14. 是否为变量赋予不同类型的值
15. （14）的情况下，赋值是否符合数据类型的转换规则
16. 变量的命名是否相似
17. 是否存在声明过，但从未引用或者只引用过一次的变量
18. 在特定模块中所有的变量是否都显式声明过
19. 非（18）的情况下，是否可以理解为该变量具有更高的共享级别
20. 是否为引用的指针分配内存
21. 数据结构在函数和子程序中的引用是否明确定义了其结构
22. 计算中是否使用了不同数据类型的变量
23. 计算中是否使用了不同的数据类型相同但长度不同的变量
24. 赋值的目的变量是否小于赋值表达式的值
25. 数值计算是否会出现溢出（向上）的情况
26. 数值计算是否会出现溢出（向下）的情况
27. 除数是否可能为零
28. 某些计算是否会丢失计算精度
29. 变量的值是否超过有意义的值
30. 计算式的求值的顺序是否容易让人感到混乱
31. 比较是否正确
32. 是否存在分数和浮点数的比较
33. 如果（32），精度问题是否会影响比较
34. 每一个逻辑表达式是否都得到了正确表达
35. 逻辑表达式的操作数是否均为逻辑值
36. 程序中的Begin…End和Do…While等语句中，End是否对应
37. 程序、模块、子程序和循环是否能够终止
38. 是否存在永不执行的循环
39. 是否存在多循环一次或少循环一次的情况
40. 循环变量是否在循环内被错误地修改
41. 多分支选择中，索引变量是否能超过可能的分支数
42. 如果（41）,该情况是否能够得到正确处理
43. 全局变量定义和用法在各个模块中是否一致
44. 是否修改了只作为输入用的参数
45. 常量是否被作为形式参数进行传递

B 动态测试
1. 测试数据是否具有一定的代表性
2. 测试数据是否包含测试所用的各个等价类（边界条件、次边界条件、空白、无效）
3. 是否可能从客户那边得到测试数据
4. 非（3）的情况下，所用的测试数据是否具有实际的意义（客户业务上的）
5. 是否每一组测试数据都得到了执行
6. 每一组测试数据的测试结果是否与预期结果一致
7. 文件的属性是否正确
8. 打开文件语句是否正确
9. 输入/输出语句是否与格式说明书所记述的一致
10. 缓冲区大小与记录长度是否匹配
11. 使用文件前是否已打开了文件
12. 文件结束条件是否存在
13. 产生输入/输出错误时，系统是否进行检测并处理
14. 输出信息中是否存在文字书写错误和语法错误
15. 数字输入框是否接受数字输入
16. （15）的情况下、数字是否按既定格式显示
17. 数字输入框是否拒绝字符串和“非法”数字的输入
18. 组合框是否的能够进行下拉选择
19. 组合框是否能够进行下拉多项选择
20. 对于可添加数据组合框，添加数据后数据是否能够得到正确显示和进行选择
21. 列表框是否能够进行选择
22. 多项列表框是否能够进行多数据项选择
23. 日期输入框是否接受正确的日期输入
24. 日期输入框是否拒绝错误的日期输入
25. 日期输入框在日期输入后是否按既定的日期格式显示日期
26. 单选组内是否有且只有一个单选钮可选
27. 如果单选组内无单选钮可选，这种情况是否允许存在
28. 复选框组内是否允许多个复选框（包括全部可选）可选
29. 如果复选框组内无复选框可选，这种情况是否允许存在
30. 文本框及某些控件拒绝输入和选择时显示区域是否变灰或按既定规约处理
31. 文本框中数据格式（大小、对齐方向、颜色、背景）是否符合规范
32. 密码输入框是否按掩码的方式显示
33. 控件是否存在默认输入值，若存在，默认值是否得到显示和提交
34. Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理
35. Submit之类的按钮按下后，数据是否得到提交或按既定规约处理
36. 异常信息表述是否正确
37. 软件是否按预期方式处理错误
38. 文件或外设不存在的情况下是否存在相应的错误处理
39. 软件是否严格的遵循外设的读写格式
40. 产生的文件和数据表的格式是否正确
41. 产生的文件和数据表的计算结果是否正确
42. 打印的报表是否符合既定的格式
43. 错误日志的表述是否正确
44. 错误日志的格式是否正确

C GUI测试
1. 窗体是否能够基于相关的输入或菜单命令适当的打开
2. 窗体是否能够改变大小、移动和滚动
3. 窗体的数据是否能够利用鼠标、功能键、方向箭头和键盘操作
4. 当窗体被覆盖并重新调用后，窗体是否能够正确再生
5. 窗体相关的功能是否可以操作
6. 是否显示相关的下拉菜单、工具条、滚动条、对话框、按钮、图标和其他控制，既能正确显示又能调用
7. 显示多窗体时，窗体名称是否能够正确表示
8. 活动窗体是否能够被反显加亮
9. 多用户联机时所有窗体是否能够实时更新
10. 鼠标无规则点击时是否会产生无法预料的结果
11. 窗体声音及提示是否符合既定编程规则
12. 窗体是否能够被关闭
13. 窗体控件的大小、对齐方向、颜色、背景等属性的设置值是否和程序设计规约相一致
14. 窗体控件布局是否合理、美观
15. 窗体控件TAB顺序是否从左到右，从上到下
16. 窗体焦点是否按照编程规范落在既定的控件上
17. 窗体画面文字（全、半角、格式、拼写）是否正确
18. 鼠标有多个形状时是否能够被窗体识别（如漏斗状时窗体不接受输入）

软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

    生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素：

      1、软件未达到客户需求的功能和性能；

      2、软件超出客户需求的范围；

      3、软件出现客户需求不能容忍的错误；

      4、软件的使用未能符合客户的习惯和工作环境。

    考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。

    在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。

    下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

测试是不完全的（测试不完全）

    很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

测试具有免疫性（软件缺陷免疫性）

    软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

测试是 “ 泛型概念 ” （全程测试）

    我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

    另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

80-20 原则

    80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

    80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

    80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

为效益而测试

    为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。

缺陷的必然性

    软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

软件测试必须有预期结果

    没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。

软件测试的意义 - 事后分析

    软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。