软件测试其他方法
4.黑盒测试
黑盒测试，英文是Black Box Testing。又称功能测试或者数据驱动测试。
黑盒测试是根据软件的规格对软件进行的测试，这类测试不考虑软件内部的运作原理，因此软件对用户来说就像一个黑盒子。
软件测试人员以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。
黑盒测试常用工具有：AutoRunner、winrunner
作用
黑盒测试法注重于测试软件的功能需求，主要试图发现下列几类错误。
1.功能不正确或遗漏；
2.界面错误；
3.输入和输出错误；
4.数据库访问错误；
5.性能错误；
6.初始化和终止错误等。
黑盒测试方法概述
从理论上讲，黑盒测试只有采用穷举输入测试，把所有可能的输入都作为测试情况考虑，才能查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但可能的输入进行测试。这样看来，完全测试是不可能的，所以我们要进行有针对性的测试，通过制定测试案例指导测试的实施，保证软件测试有组织、按步骤，以及有计划地进行。黑盒测试行为必须能够加以量化，才能真正保证软件质量，而测试用例就是将测试行为具体量化的方法之一。具体的黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法、场景法等。
等价类划分的办法是把程序的输入域划分成若干部分（子集），然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。该方法是一种重要的，常用的黑盒测试用例设计方法。
划分等价类
1) 划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。
有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类：与有效等价类的定义恰巧相反。
设计测试用例时，要同时考虑这两种等价类.因为，软件不仅要能接收合理的数据，也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。
边界值分析法
边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。
（1）边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
（2）基于边界值分析方法选择测试用例的原则：
1）如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2）如果输入条件规定了值的个数，则用最大个数,最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
3）根据规格说明的每个输出条件，使用前面的原则1）。
4）根据规格说明的每个输出条件，应用前面的原则2）。
5）如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
7）分析规格说明，找出其它可能的边界条件。
错误推测法
错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法.
错误推测方法的基本思想： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。 例如，在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
优点
1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了
2. 设计完测试用例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因
缺点
1. 结果取决于测试用例的设计，测试用例的设计部分优势来源于经验，OUSPG的东西很值得借鉴
2. 没有状态转换的概念，一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来实现
3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。
常用方法
功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下
1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确：如update,cancel,delete,save等功能是否正确。
4. 字符串长度检查： 输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度，会不会出错.
5. 字符类型检查： 在应该输入指定类型的内容的地方输入其他类型的内容（如在应该输入整型的地方输入其他字符类型），看系统是否检查字符类型，会否报错.
6. 标点符号检查： 输入内容包括各种标点符号，特别是空格，各种引号，回车键.看系统处理是否正确.
7. 中文字符处理： 在可以输入中文的系统输入中文，看会否出现乱码或出错.
8. 检查带出信息的完整性： 在查看信息和update信息时，查看所填写的信息是不是全部带出.，带出信息和添加的是否一致
9. 信息重复： 在一些需要命名，且名字应该唯一的信息输入重复的名字或ID，看系统有没有处理，会否报错，重名包括是否区分大小写，以及在输入内容的前后输入空格，系统是否作出正确处理.
10. 检查删除功能：在一些可以一次删除多个信息的地方，不选择任何信息，按”delete”，看系统如何处理，会否出错；然后选择一个和多个信息，进行删除，看是否正确处理.
11. 检查添加和修改是否一致： 检查添加和修改信息的要求是否一致，例如添加要求必填的项，修改也应该必填；添加规定为整型的项，修改也必须为整型.
12. 检查修改重名：修改时把不能重名的项改为已存在的内容，看会否处理，报错.同时，也要注意，会不会报和自己重名的错.
13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14. 检查多次使用back键的情况： 在有back的地方，back，回到原来页面,再back，重复多次，看会否出错.
15. search检查： 在有search功能的地方输入系统存在和不存在的内容，看search结果是否正确.如果可以输入多个search条件，可以同时添加合理和不合理的条件，看系统处理是否正确.
16. 输入信息位置： 注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方.
17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20. 回车键检查： 在输入结束后直接按回车键，看系统处理如何，会否报错。
5.静态测试
静态测试，英文是Static Testing。
静态测试指测试不运行的部分，例如测试产品说明书，对此进行检查和审阅.。静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
6.动态测试
动态测试，英文是Moment Testing。
动态测试是指通过运行软件来检验软件的动态行为和运行结果的正确性。
根据动态测试在软件开发过程中所处的阶段和作用，动态测试可分为如下几个步骤：
1、单元测试
2、集成测试
3、系统测试
4、验收测试
5、回归测试
7.单元测试
单元测试，英文是Unit Testing。
单元测试是最微小规模的测试;以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易做好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。
8.集成测试
集成测试，英文是Integration Testing。
集成测试是指一个应用系统的各个部件的联合测试，以决定它们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。
集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别
9.系统测试
系统测试，英文是System Testing。
系统测试是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。
系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试。
