软件测试

软件测试的艺术

软件测试的基本思想：等价类的划分，边界值，因果图和判定表，代码覆盖

软件测试：试图发现程序中错误的破坏性过程。即使规模很小的程序，软件测试也不能够发现“所有”的错误，因为使用者是在一个潜在的无限大的集合中选取输入或者操作流程，而软件测试则不能把无限的集合一一实践出来（穷举测试不可能）。这个基本的问题暗示出软件测试的经济学问题（无论在什么领域，我觉得思考问题时从资本和经济收益上出发绝对不会错；即使是一些公益性的领域），测试人员对被测试软件的期望，以及测试用例的设计方式。

黑盒测试：又称为数据驱动测试或输入/输出驱动测试。测试目标与程序的内部机制无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。测试数据来源于软件规范（需求分析）。测试投入的目标在于通过有限的测试用例，最大限度地提高发现问题的数量。具体方法有 等价类划分，边界值分析，因果图分析，错误猜测

白盒测试：逻辑驱动测试，允许我们检查程序的内部结构，这种测试策略对程序的逻辑结构进行检查，获取测试数据，但忽略了软件规范。穷举路径测试：如果使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全测试。白盒测试不能检测出的错误：功能错误，功能缺失，数据敏感错误。具体方法有语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，多重条件覆盖

编号	原则
1	测试用例中包括对预期结果定义
2	避免测试自己编写的程序 思维定势
3	彻底检查每个测试的执行结果？？
4	测试用例的输入应包括无效的输入
5	检测功能完整性，和功能多余性
6	保存测试用例
7	假定程序存在很多错误
8	潜在错误量与已发现错误量成正比

代码检查与走查：人工阅读检查特定的程序，测试错误，不需要调试错误。这些方法通常会查找出30%~70%的逻辑设计和编码错误，但不能发现高级的错误。代码检查需要一份错误列表：数据引用错误（初始化？下标界限？指针？），数据声明错误，运算错误，比较错误，控制流程错误，接口错误，输入输出错误，其他检查。代码走查：其他人员像程序员提问，发现错误，类似于头脑风暴。

测试用例的设计：

白盒测试：

逻辑覆盖测试的确很弱，只是在给定的条条框框下验证正确性，却没办法验证条条框框是否正确，判定覆盖是测试的必要条件。判定覆盖是从判定结果上来看把每个判定结果都执行一编（判定对，判定错的条件各一个就行了），但是对产生判定结果的输出不需要完全性遍历，没有把结果的入口点执行完全；而条件覆盖则是把每个输入元素进行完全取值k*n种（不是输入组合完全取值，输入组合是（k^n)）），但是输入后的结果可能会漏掉某种结果。所以判定/条件覆盖准则就是指：将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口都至少条用一次。多重条件覆盖准则能部分解决逻辑表达式中屏蔽的问题，将每个判定中的所有可能的条件结果的组合，以及所有的入口点都至少执行一次。具体区别见新浪博客

等价划分：测试程序时，被限制从所有可能的输入中努力找出某个小的子集，子集必须正确，且能尽可能发现最多错误的子集。确定子集需要满足以下两个特性：严格控制测试用例的增加，子集的势确定保证有效 无效输入；确定一个用户覆盖的输入集合，用来设计一个测试用例。一般是选取每个输入条件，并将其划分为两个或更多的组来确定等价类。边界值：通用指南：规定范围（无效输入，有效输入，边界输入），输入值的数量。边界值分析和等价划分主要是通过确定边界值来切割输入域，但是未对输入条件组合进行分析，即使对输入条件进行等价划分，组合的数量也较大。因果图试图选出高效的测试用例集，也可以指出规格说明的不完整性和不明确之处。因果图是一种形式语言，但不善于处理较大的规格说明。

模块（单元）测试是对程序中的单个子程序进行测试的过程，将模块的功能和定义模块的功能规格说明或接口规格说明进行比较。模块测试总体上是蛮像白盒测试的，后续的测试过程着眼于发现其他类型的错误。模块测试的测试用例设计过程如下：使用几种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。增量测试和非增量测试。非增量测试需要编写驱动模块和桩模块来模拟数据输入和调用的其他模块，增量测试则是把下一个要测试的模块组装到前面已经测试过的模块集合中，需要一个驱动模块，不需要桩模块。前者可以减少机器运行时间，速度快，后者可以尽早发现接口问题。

更高层次的软件测试

功能测试：试图发现程序与其外部规格说明之间存在不一致的过程。通常是黑盒测试；

系统测试：最困难的测试过程，并非是测试整个系统或程序功能的过程，在寻找程序与其目标之间不一致的过程。外部规格说明不能作为获得系统测试用例的基础，也不能利用目标文档本身表示测试用例，而是利用程序的用户文档或书面材料，通过分析目标文档来设计系统测试。具体包括能力测试，容量测试（能够处理的数据容量），强度测试（单位时间内能够处理的数据量），易用性测试（人为因素或易用性问题），安全性测试（设计测试用例来突破程序安全监察的过程，避免内存保护机制等），性能测试，存储测试，配置测试，兼容性测试，安装测试，可靠性测试，可恢复性测试等。如何判断测试何时终止呢？测试时间结束，测试用例用完。

测试类型	编码和逻辑设计错误	设计错误
模块测试	65%	0%
功能测试	30%	60%
系统测试	3%	35%
总计	98%	95%

调试

所谓成功的测试是只可以证明程序没有实现预期的功能，调试有两步：确定程序可疑错误的准确性质和位置，修改错误。

这里有几个问题：

1测试和开发比起来，管理的成分占了很多，包括测试计划，错误统计，潜在错误预测，测试经济花销控制等。

2 自动化测试和调试工具有哪些？

http://blog.csdn.net/qyq24836910000/article/details/4073965

3 开发和测试对码工的要求差异还是很大的，开发更看重技术娴熟，宏观规划，手到擒来；测试貌似需要严谨，完备。

2013-06-01补充

典型的测试工具开发公司(一般软件开发和管理公司有会有相应产品)：

Mercury Interactive   LoadRunner software:

Parasoft

自动化测试工具

Selenium

 

如何给出测试用例

http://www.ltesting.net/ceshi/ceshijishu/csyl/2012/0705/205238.html

给出测试用例的第一步是要全面的思考一个测试对象需要验证的地方，上篇文章通过几个引导词 归类  使我们比较容易的联想出一些方面，不得不说还是很管用的，只是我通常所用的引导词或者说是分类维度不完全一样：功能测试（能否完成需求），界面测试（界面元素描述，界面感官如何，舒适度，易用性，接口），压力测试（实际上这个是和上篇博客里面的数据相关的，差不多和数据相关的都有个程度需要考虑，容量，重量，高度，使用次数，生产日期，耐温。。），安全测试（这个考虑测试对象从诞生到灭亡，会不会给人类带来危害，材料是否有毒，烫手，能否回收，污染环境等，甚至可以衍生到生产的附属品等），环境（小孩子不能用，太空中不能用等等）。把两个分类维度对比一下：发现文章里的更合理点。。。结构对应界面，功能对应功能，数据对应压力，平台对应运行环境，操作对应到功能里面了，时间对应到压力里面。

给出测试用例的第二步是制定测试报告表格；实际上各大公司已经有比较成熟的表格系统了。

给出测试用例的第三步是把分类维度细化，填入测试表格中；期间注意在单个维度上的边界值，等价类等；因果图 覆盖 最后还希望尽量减少测试用例数量；

第四步为测试评估 测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少 以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。 通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现