软件测试问题
用黑盒技术设计测试用例的方法包括等价类划分、边界值分析、错误推测、因果图和综合策略。
黑盒测试侧重于测试软件的功能需求，即黑盒测试使软件工程师能够推导出执行程序所有功能需求的输入条件。黑盒测试不是白盒测试的替代品，而是用来帮助白盒测试发现其他类型的错误。
黑盒测试试图发现以下类型的错误:
1)功能错误或遗漏；
2)接口错误；
3)数据结构或外部数据库访问错误；
4)性能误差；
5)初始化和终止错误。
一、黑盒测试的测试用例设计方法
划分等价类的方法
边界值分析法
错误的推测方法
因果图方法
决策表驱动的分析方法
正交实验设计方法
功能图分析法
等价类划分:
就是把所有可能的输入数据，也就是一个程序的输入域分成几个部分(子集)，然后从每个子集里选取几个有代表性的数据作为测试用例。该方法是设计黑盒测试用例的一种重要且常用的方法。
1)划分等价类:等价类是指一个输入字段的子集。在这个子集中，所有的输入数据都相当于暴露程序中的错误。可以合理地假设，测试一个等价类的代表值等同于测试该类的其他值。因此，可以将所有输入数据合理地划分为若干个等价类，如果将每个等价类中的一个数据作为检验的输入条件，则可以使用少量的代表性。
有效等价类:指一组对程序的规格说明合理且有意义的输入数据。使用有效的等价类，我们可以检查程序是否实现了规范中指定的功能和性能。
无效等价类:与有效等价类的定义正好相反。
在设计测试用例时，我们应该同时考虑这两个等价类，因为软件不仅要能够接收合理的数据，还要能够经受住意想不到的测试。这样的测试可以保证软件具有更高的可靠性。
2)划分等价类的方法:下面是确定等价类的六个原则。
①在输入条件指定取值范围或取值个数的情况下，可以建立一个有效等价类和两个无效等价类。
②在输入条件指定输入值的集合或“必须做什么”的条件下，可以建立有效等价类和无效等价类。
③如果输入条件是布尔量，可以确定有效等价类和无效等价类。
(4)在指定了一组输入数据的值(假设n)，并且程序必须分别处理每个输入值的情况下，可以建立n个有效等价类和一个无效等价类。
⑤在输入数据必须遵守规则的条件下，可以建立一个有效等价类(符合规则)和几个无效等价类(从不同角度违反规则)。
⑥如果已知划分后的等价类中的每个元素在程序处理中有不同的方式，那么等价类应该进一步划分为更小的等价类。
3)设计测试用例:建立等价类后，可以建立等价类表，列出所有划分的等价类:
输入条件有效等价类无效等价类
.........
.........
然后根据以下三个原则从划分的等价类中设计测试用例:
①为每个等价类分配一个唯一的编号。
②设计一个新的测试用例，覆盖尽可能多的有效等价类，重复此步骤，直到覆盖所有有效等价类。
(3)设计一个新的测试用例，只覆盖一个未被覆盖的无效等价类，重复此步骤，直到所有无效等价类都被覆盖。
边界值分析
边界值分析法是等价类划分法的补充。
(1)边值分析法的思考:
长期的测试经验告诉我们，大量的误差发生在输入或输出范围的边界，而不是在输入和输出范围内部。因此，通过为各种边界条件设计测试用例，可以发现更多的错误。
用边界值分析法设计测试用例时，首先要确定边界条件。通常情况下，输入输出等价类的边界是应该重点测试的边界条件。应选择恰好等于、略大于或略小于边界的值作为测试数据，而不是典型值或等价类中的任意值。
(2)基于边界值分析法的测试用例选择原则:
1)如果输入条件指定了取值的范围，那么刚好达到这个范围的边界的值和刚好超出这个范围的边界的值都应该作为测试输入数据。
2)如果输入条件指定了值的数量，则将最大数量、最小数量、小于最小数量的数量和大于最大数量的数量用作测试数据。
3)根据规范中规定的每个输出条件，使用前面的原则1)。
4)根据规范中规定的每个输出条件，应用前面的原则2)。
5)如果程序规范中给出的输入字段或输出字段是一个有序集合，则应选择该集合的第一个元素和最后一个元素作为测试用例。
6)如果程序中使用了内部数据结构，则应选择该内部数据结构边界上的值作为测试用例。
7)分析规范，找出其他可能的边界条件。
虚假推测法
错误推断法:根据经验和直觉设计测试用例，推断程序中所有可能的错误的方法。
错误推理方法的基本思想:列出程序中所有可能出现的错误和容易出错的特殊情况，并据此选择测试用例。比如单元测试中列出的模块的很多常见错误，之前产品测试中发现的错误等等。这些是经验总结。此外，当输入数据和输出数据为0时，输入表为空白或输入表只有一行。这些都是容易出错的情况。可以选择这些情况的例子作为测试用例。
因果图方法
上面介绍的等价类划分方法和边界值分析法都是着眼于输入条件，而没有考虑输入条件之间的关系、相互组合等。考虑到输入条件的相互组合，可能会出现一些新的情况。但是，检查输入条件的组合并不容易。即使将所有输入条件划分为等价类，它们之间的组合也相当多。因此，我们必须考虑采用一种适合于描述多个条件的组合并相应地生成多个动作的形式。
因果图法的最终结果是决策表，适用于检查程序输入条件的各种组合。
利用因果图生成测试用例的基本步骤:
(1)分析软件规范的描述，它们是原因(即输入条件或输入条件的等价类)和结果(即输出条件)，并为每个原因和结果分配一个标识符。
(2)分析软件规格说明描述中的语义，找出原因与结果的对应关系，根据这些关系画出因果图。
(3)由于语法或环境的限制，原因和结果之间的一些组合不是不可能的。为了表示这些特殊情况，在因果图上用一些符号来表示约束或限制条件。
(4)将因果图转换成决策表。
(5)取出判断表的每一列作为设计测试用例的基础。
由因果图(在部分和组合关系下)生成的测试用例包含了所有真假输入数据的情况，测试用例的数量最少，随着输入数据的增加，测试用例的数量线性增加。
因果图方法中使用了决策表。决策表是分析和表达多逻辑条件下不同操作的工具。在程序设计发展的早期，决策表一直被用作编写程序的辅助工具，因为它可以既具体又清晰地表达复杂的逻辑关系和各种条件的组合。
决策表通常由四部分组成。
条件存根:列出问题的所有条件。一般认为所列条件的顺序并不重要。
动作存根:列出问题指定的可能动作。这些动作的顺序不受限制。
条件条目:在其左栏中列出条件的值，以及所有可能情况下的真值和假值。
动作条目:列出在各种条件下应该采取的动作。
规则:任何条件组合的特定值以及要执行的相应操作。决策表中贯穿条件项和动作项的一列是规则。显然，决策表中列出了多少组条件值，就有多少条规则，也就是说，有多少列条件项和操作项。
建立决策表的步骤:(根据软件规范)
①确定规则的数量。如果有n个条件，每个条件有两个值(0，1)，所以有规则。
②列出所有条件桩和动作桩。
③填写条件项。
④填写行动项目。等到初步判断表。
⑤简化合并相似规则(同一个动作)。
B.贝泽尔指出了适合使用决策表设计测试用例的条件:
规范以决策表的形式给出，也可以很容易地转换成决策表。
条件的顺序不会也不会影响执行哪些操作。
③规则的顺序不会也不会影响执行哪些操作。
④每次已经满足了一个规则的条件，确定了要执行的操作，就不需要再检查其他规则了。
⑤如果满足一个规则，将执行多个操作，这些操作的执行顺序无关紧要。
黑盒测试的优势
1.基本上没人管。如果程序停止运行，一般是被测程序崩溃。
2.设计完测试用例，接下来的工作就是爽了，当然更郁闷的是确定死机原因。
黑盒测试的缺点
1.结果取决于测试用例的设计。测试案例的设计部分来自经验，OUSPG值得借鉴。
2.没有状态转换的概念。目前对于PDU基本上做了一些成功的例子，但是对于被测试的程序是不可能做状态转移的。
3.对于没有状态概念的测试来说，寻找和确定导致程序崩溃的测试用例比较麻烦，周围可能出现的测试用例必须单独确认。就状态测试而言，它甚至更麻烦，尤其是如果它不是由单个测试用例引起的。这些在堆的问题上比较突出。
黑盒测试(功能测试)工具的选择
那么，如何高效地完成功能测试呢？选择一个合适的功能测试工具，培养一支高素质的工具用户团队，无疑是非常重要的。虽然现阶段有少数软件服务企业在不使用任何功能测试工具的情况下从事功能测试外包项目。短期来看，这类企业盈利能力尚可，但长期来看，很可能被自动化程度更高的软件服务企业所取代。
目前功能测试的软件工具很多，针对不同架构的工具也在不断推出。本文重点介绍了一种典型的自动化测试工具，即Mercury公司的WinRunner。
WinRunner是一个企业级的软件功能测试工具，用来测试应用程序是否能如期运行。通过自动捕获、检测和模拟用户交互，WinRunner可以识别大多数软件功能缺陷，从而确保那些跨越多个功能点和数据库的应用程序在发布时不会出现功能故障。
WinRunner的特点是:与传统的手工测试相比，可以快速、批量地完成功能点测试；可以对同一个测试脚本执行相同的动作，消除了手工测试带来的理解错误；除此之外，它还可以重复执行同一个动作，测试工作中最枯燥的部分都可以由机器来完成；它支持程序风格的测试脚本，一个高素质的测试工程师可以用它来完成极其复杂的测试，通过使用通配符、宏、条件语句、循环语句等来复用测试脚本。它为大多数编程语言和Windows技术提供了良好的集成和支持环境，为基于Windows平台的应用程序的功能测试带来了极大的便利。
WinRunner的工作流程大致可以分为以下六个步骤:
1.识别应用程序的GUI
在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象。识别后，WinRunner会将它们存储在GUI映射文件中。它提供了两种GUI映射文件模式:全局GUI映射文件和每次测试的GUI映射文件。最大的区别是后者为每个测试脚本生成一个GUI文件，可以自动创建、存储和加载。建议初学者使用这种模式。但是这种模式不容易描述对象的变化，效率也比较低，所以前者对于有经验的测试人员来说是更好的选择，而且它只产生一个GUI文件，测试脚本更容易维护，效率也更高。
2.建立一个测试脚本
在建立测试脚本时，通常是先录制，然后将需要的TSL(类似于C语言的测试脚本语言)手工添加到录制的脚本中。记录脚本有两种模式:上下文相关和模拟。选择主要依据鼠标轨迹是否模拟，需要回放时一般选择模拟。在录制过程中，这两种模式可以通过F2键切换。
只要看看现代软件的规模和功能点就能明白，功能测试早已跨越了用手敲键盘点鼠标就能完成的阶段。性能测试是控制系统性能的有效手段，在软件能力验证、能力规划、性能调优、缺陷修复等方面发挥着重要作用。
3.调试测试脚本。
在WinRunner中，有一个专门的调试工具栏用于调试测试脚本。可以使用单步、暂停、断点等。控制和跟踪测试脚本，并查看各种变量值。
4.在新应用程序中执行测试脚本。
当应用程序的新版本发布时，我们将测试应用程序的各种功能，包括新功能。这个时候，当然不可能重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本，测试旧的功能点是否正常工作。您可以使用call命令来加载每个测试脚本。您还可以将各种TSL脚本添加到call命令中，以增加批处理能力。
5.分析测试结果
在整个测试过程中，对测试结果的分析是最重要的，通过分析可以发现应用程序的各种功能缺陷。在运行一个测试脚本之后，将会产生一个测试报告。从这份测试报告中，我们可以发现应用程序的功能缺陷，实际结果与预期结果的差异，以及测试过程中产生的各种对话框。
6.返回缺陷
对测试报告进行分析后，按照测试流程报告应用的各种缺陷，然后将这些缺陷发送给指定人员进行修改和维护。
常见的功能测试方法
功能测试是对产品的功能进行验证，根据功能测试用例逐项进行测试，检查产品是否满足用户要求的功能。常见的测试方法如下:
1.页面链接检查:每个链接是否有对应的页面，页面之间的切换是否正确。
2.相关性检查:删除/添加一个项目会影响其他项目吗？如果有，这些影响是否正确？
3.检查按钮的功能是否正确:如更新、取消、删除、保存等功能是否正确。
4.字符串长度检查:输入超过需求中指定字符串长度的内容，看系统是否检查字符串长度出错。
5.字符类型检查:在应输入指定内容类型的位置输入其他类型的内容(例如，在应输入整数类型的位置输入其他字符类型)，以查看系统是否检查字符类型并将报告错误。
6.标点符号检查:输入内容包括各种标点符号，尤其是空格、引号和回车键。看系统处理是否正确。
7.汉字处理:在可以输入中文的系统中输入中文，看是否有乱码或错误。
8.检查带出信息的完整性:在核对信息和更新信息时，检查填写的信息是否全部带出，带出的信息是否与添加的信息一致。
9.重复信息:在一些需要命名且名称要唯一的信息中输入重复的名称或id，看系统是否处理过，是否会报错。重名包括是否区分大小写，输入前后是否输入空格，系统是否处理正确。
10.检查删除功能:在一些可以一次删除多条消息的地方，不选择任何一条消息就按“删除”，看看系统如何处理，会不会出错；然后选择一个或多个消息并删除它们，以查看它们是否被正确处理。
11.检查添加和修改是否一致:检查添加和修改信息的要求是否一致，如添加必录项，修改也要必录；添加指定为整数的项，修改也必须是整数。
12.检查并修改重名:修改时，将不能重复的项目修改到已有内容中，看是否会被处理报错。同时注意是否会用自己的重复项报错。
13.重复提交表单:一条已经提交成功的记录，回来后再提交，看系统有没有处理。
14.检查回退键的重复使用:有回退的地方，回原页面，再回退，重复几次，看看有没有错。
15.搜索检查:在有搜索功能的地方输入系统存在和不存在的内容，查看搜索结果是否正确。如果可以输入多个搜索条件，可以同时添加合理和不合理条件，看看系统处理是否正确。
16.输入信息位置:在光标停留的地方输入信息，注意光标和输入的信息是否会跳转到其他地方。
17.上传下载文件检查:是否实现了上传下载文件的功能，上传的文件是否可以打开。上传文件的格式有什么规定，系统有没有说明信息，检查系统能不能做到。
18.必填项检查:系统是否处理了所有应填项未填的情况，是否有必填项的提示，如必填项前加*。
19.快捷键检查:是否支持常用快捷键，如Ctrl+C Ctrl+V退格等。，以及对于某些不允许输入信息的字段，如人员选择和日期选择，是否也限制快捷方式。
20.回车键检查:输入后直接按回车键，看系统如何处理，是否报错。