这几天刚刚刚接触了软件测试，感觉内容挺简单的，无非就是该怎么测试一个软件能否正确运行。其中主要讲述了测试的方法与原则。实际上测试都是要依据各种测试方法协调完成测试工作，而这个过程不是在很大程度上决定了一个软件的成功与否。所以，软件测试很重要！
下面就让我们来接触它吧：
上面这幅图是我对与软件测试的初步认识总结的思维导图（仅供参考）。
软件测试主要讲述了软件测试的目标和原则、软件测试的用例设计、软件测试的策略、软件测试的种类和程序的调试五个大方面。
一、软件测试的目的和原则
目的：
1.测试时程序的执行过程，目的在于发现错误
2.一个好的测试用例在于能发现至今未发现的错误
3.一个成功的测试时发现了至今未发现的错误
原则：
1.应当把“尽早地和不断地进行软件测试”做为软件开发者的座右铭
2.测试用例应由测试输入数据和对应的预期输出结果这两部分组成
3.程序员应避免检查自己的程序（开发和测试人员两套）
4.在设计测试用例时，应当包括合理的输入条件和不合理的输入条件
二、测试信息流
(输入：)
软件配置：
测试配置：
测试工具：
(输出：)
测试结果分析：
排错（调试）：
修正后的文档再测试：
三、测试与软件开发各阶段的关系
开发过程是自顶向下，逐步细化的过程
测试过程相反顺序安排的自底向上，逐步集成的过程
四、测试用例设计
两种方法：
黑盒测试（功能测试或数据驱动测试）
把测试对象看做一个黑盒测试，检查程序的功能是否符合他的功能说明
白盒测试（结构测试或逻辑驱动测试）
测试对象看做一个透明的盒子，对程序所有逻辑路径进行测试
重点：独立路径至少要测试一遍；被测的所有逻辑（成立和不成立两个方向）都要测试
大的程序都不可能测试完全（所以需要测试员一般高于开发人员）
逻辑覆盖：
以程序内部的逻辑结构为基础的设计测试用例的技术（属白盒测试）
语句判定、判定覆盖、条件覆盖（存在缺陷）
判定—条件覆盖、条件组合覆盖、路径覆盖（比较严格）
语句覆盖：设计若干个测试用例，运行被测程序，使得每一条执行语句至少执行一次
判断覆盖：设计若干个测试用例，运行被测程序，使得每个判断的取真分支和取假分支至少精力一次
条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次
判断—条件覆盖：设计足够测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断中的每个条件的可能取值至少执行一次
例：
路径测试:设计足够的测试用例,覆盖程序中所有可能的路径
条件测试路径选择
当程序中判定多于一个时,形成的分支结构可以分为两类:嵌套型分支结构和连锁型分支结构
循环测试路径选择
循环分为:简单循环、嵌套循环、连锁循环、非结构循环
黑盒测试的测试用例设计
等价类划分
把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例
划分情况：有效等价类、无效等价类
划分原则：
1. 如果输入条件规定了取值范围，或值得个数，则可以确立一个有效等价类和无效等价类
2. 如果输入条件规定了输入值得集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类
3. 如果输入条件是一个布尔型，则可以确定一个有效等价类和一个无效等价类
4. 如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理
5. 如果规定了输入数据必需遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）
确定测试用例：列出所有划分出的等价类
边界值分析
测试用例时，主要考虑边界处。
使用时，首先要确定边界情况。应当选取正好等于，刚刚大于或刚刚小于边界值做测试数据
遵循原则：
1. 如果输入条件规定了取值范围，则应对该范围的边界内附近，恰好在边界和在边界外附近（无效等价类中）设计测试用例
2. 如果输入条件规定了数据的个数，则应对最小个数，最大个数，比最少个数少1，比最大个数大1等情况设计测试用例
3. 针对规格说明中的每个输出条件使用前面的1和2原则
4. 如果程序规格说明中提到的输入或输出域是个有效的集合（如顺序文件，线性表等）。应选有序续集的第一个和最后一个元素做为测试用例
错误推测法
基本想法：列举出程序中所有可能有的错误和容易发生错误的特殊情况
一般作补充的测试用例
因果法
如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，形影产生多个动作的形式来设计测试用例，这就需要利用因果图。最终生成的是判定表。
生成测试用例的基本步骤：
1. 分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符
2. 分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间的对应关系，根据这些关系画出因果图
3. 由于语法或环境限制，右斜原因与原因之间，原因与结果之间的组合情况不可能出现，为表明这些特殊情况，在因果图上用一些几号表明约束或限制条件
4. 把因果图转换成判定表
5. 判定表的每一列拿出来做为依据，设计测试用例
图中的基本符号：Ci表示原因，Ei表示结果，结点表示状态（0表示状态不出现，1表示状态出现）
主要原因和结果之间的关系有（恒等、非、或、与）
表示约束条件的符号：
五、软件测试的策略
步骤：单元测试、组装测试、确认测试和系统测试
单元测试（Unit Testion）
又称模块测试，针对软件设计的最小单位——程序模块，进行正确性检验的测试工作
内容：模块接口、局部数据结构、边界条件、独立路径、出错处理
步骤：同时考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其他模块（驱动模块driver、桩模块stub）
常见错误清单：
（一）模块接口检查表
1. 模块接受的输入参数个数与模块的变元个数是否一致
2. 参数与变元的属性是否匹配
3. 参数与变元所用的单位是否一致
4. 传递给被调用模块的变元的数目是否等于那个模块的参数的数目
5. 传递给被调用模块的变元属性和参数的属性是否一致
6. 传递给被调用模块的变元的单位和该模块参数的单位是否一致
7. 传递给内部函数的变元属性、数目和次序时否正确
8. 是否修改了只是做为输入用的变元
9. 全程变量的定义在各个模块中是否一致
10. 有没有把常数当做变量来传递
（二）完成外部输入/输出时的检查表
1. 文件属性是否正确
2. OPEN语句是否正确
3. 格式说明与输入/输出语句给出的信息是否一致
4. 缓冲区容量与记录长度是否匹配
5. 在进行读写操作之前是否打开了文件
6. 对结束文件条件的判断和处理是否正确
7. 对输入/输出错误的处理是否正确
8. 有没有输出信息中有正文错误
（三）模块局部数据结构检查表
1. 不正确或不一致说明
2. 错误的初始值或错误的缺省值
3. 变量名拼写错或缩写错
4. 不相容的数据类型
5. 下溢、上溢或是地址错误
组装测试（Integrated Testing）
把模块组装成为系统的方式有：一次性组装方式和增殖式组装方式（常用）
一次性组装方式（big bang）
增殖式组装方式
自顶向下的增殖方式
自底向下的增殖方式
混合增殖测试
确认测试（Validation Testing）
又称有效性测试。
任务：验证软件的功能和性能及其它特性是否与用户的要求一致
进行有效性测试
是在模拟的环境（可能就是开发的环境）下，运行黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求
软件配置复查
目的：
1.保证软件配置的所有成分都齐全
2.保证各方面的质量 都符合要求
3.保证具有维护阶段所必需的细节
4.保证已经编排好分类的目录
验收测试（Acceptance Testing）
是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加
由用户参加设计测试用例，使用生产中的实际数据进行测试
系统测试（System Testing）
将通过确认测试的软件做为整个基于计算机胸膛的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试
α测试和β测试
α测试是由一个用户在开发环境下进行测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者
测试种类
功能测试、可靠性测试、强度测试、性能测试、恢复测试、启动/停止测试、配置测试、安全性测试、可使用性测试、可支持性测试、过程测试、互连测试、兼容性测试、容量测试、文档测试
六、调试（Debug）
在成功测试后开始工作，进一步诊断和改正程序中潜在的错误
步骤：
i. 从错误的外部表现形式入手，确定程序中错误位置
ii. 研究有关部分的程序，找出错误的内在原因
iii. 修改设计和代码，以排除这个错误
iv. 重复进行暴露了这个错误的原始测试或某些有关测试
方法：强行排错（使用多，效率低）、回溯法调试（适用小程序）、归纳法调试（基本思想：从一些线索即错误征兆着手）、演绎法调试（从一般原理或前提触发)
原则：
许多原则本质是心理学方面的问题，分为：
确定错误的性质和位置的原则：
1.用头脑去分析思考与错误征兆有关的信息
2.避开死胡同
3.只把调试工具当做辅助手段来使用
4.避免用试探法，最多只能把它当做最后手段
修改错误的原则：
1.在出现错误的地方，很可能还有别的错误
2.当心修正一个错误的同时有可能会引入新的错误
七、测试分析报告
- 测试时程序的执行过程，目的在于发现错误
- 一个好的测试用例在于能发现至今未发现的错误
- 一个成功的测试时发现了至今未发现的错误
649
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
