标签：黑盒 覆盖 信息系统 综合测试 等价 测试用例 23.2 测试 输入
软件测试技术
软件测试技术
主要包括白盒测试和黑盒测试技术
黑盒测试主要检查程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试注重于测试软件的功能需求，主要试图发现以下几类错误：
(1)是否有不正确或遗漏了的功能。
(2)在接口上，能否正确地接受输入数据，能否产生正确的输出信息。
(3)访问外部信息是否有错。
(4)性能上是否满足要求。
(5)界面是否错误，是否不美观。
(6)初始化或终止错误。
黑盒测试有两种基本方法，即通过测试和失败测试（通过测试时，实际上是确认软件能做什么，而不会去考验其能力如何）；纯粹为了破坏软件而设计和执行的测试案例被称为失败测试或迫使出错测试。
黑盒
黑盒测试的优点：
(1)比较简单，不需要了解程序内部的代码及实现。
(2)与软件的内部实现无关。
(3)从用户角度出发，能很容易地知道用户会用到哪些功能，会遇到哪些问题。
(4)基于软件开发文档，所以也能知道软件实现了文档中的哪些功能。
(5)在做软件自动化测试时较为方便。
黑盒测试的缺点：
(1)不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%。
(2)自动化测试的复用性较低。
测试用例的设计方法：
1.等价类划分法
等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分(子集)，然后从每一个子集中选取少数具有代表性的数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值。等价类划分法是一种重要的、常用的黑盒测试用例设计方法。划分等价类的方法有以下6种：
(1)在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
例如：学生成绩是0-100分，那么“0<x<100”就是有效等价类，“x>100”和“x<0”就是两个无效等价类。
(2)在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况，可确立一个有效等价类和一个无效等价。
例如：查询日期要小于当前系统日期，“小于”是有效等价类，“大于、等于”就是无效等价类了。
(3)在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。例如：当输入错误的B、C时，系统会报错，所以输入“正确的B、C”就是有效等价类，错误的B、C”就是无效等价类。
(4)在规定了输入数据的一组值(假定n个)，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。例如：面试条件说明学历可为本科、硕士、博士三种之一，则分别取这三值作为三个有效等价类，三种学历之外的任何学历就是无效等价类。
(5)在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。例如：规定必须输入正整数，那么“正整数”就是有效等价类，而“0、负数、小数、分数、字母、汉字等”都是无效等价类。
(6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类。例如：输入日期>初步的有效等价类是“1<M<12，1<D<31；但有的月份只有28、29、30天，所以还需要细分。
在确立了等价类后，可建立等价类表，列出所有划分出的等价类，然后从划分出的等价类中按以下三个原则设计测试用例。
(1)为每一个等价类规定一个唯一的编号。
(2)设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
(3)设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
2.边界值分析法
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
一般边界值包括：略小于最小值、最小值、略大于最小值、中间值、略小于最大值、最大值、略大于最大值。
例如，如果程序的规格说明中规定：“重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……”。
作为测试用例，我们应取10及50还应取10.01、49.99、9.99及50.01等。
再如：选修人数在[20,60]之间，其边界值为19、20、21、59、60和61。
3.组合覆盖法
是设计尽可能少的测试用例，使各个被测元素的中的各类测试数据组合都被至少执行一次。组合覆盖是覆盖率很高的覆盖法。
1)全组合覆盖法
全组合覆盖法是将所有因素组合起来，每个因素的值都至少遍历一次。全组合法覆盖率比较高，但是测试用例量比较大/且会产生冗余。
2)成对组合覆盖法
成对组合(Pair-Wise) ， 又称西两组合或对对组合， 它是将所有因素的水平按照两两组合的原则而产生的。成对组合覆盖要求任意两个因素(输入条件)的所有水平组合至少要被覆盖1次
3)正交实验设计法
正交试验设计法，就是使用已经造好了的表格(正交表)来安排试验并进行数据分析的一种方法。它简单易行，计算表格化，使用者能够迅速掌握。正交实验设计法可以用最少的测试用例达到最高的测试覆盖率。
4)数据覆盖法
设计尽可能少的测试用例，使每个被测元素在设计中的各类数据都被至少执行一次。该方法是比较弱的测试覆盖法
4.逻辑推断法
1)因果分析图
是一种适合于描述对于种输入条件合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法。因果图法着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。因果分析法最终生成的就是判定表，它适用于检查程序输入条件的各种组合情况。
【如：工资为A1级别的员工，犯普通错误(中等错误、严重错误)，预期扣多少钱；A2级别……】
2)判定表法
在所有的黑盒测试方法中，基于判定表的测试是最为严格、最具有逻辑性的测试方法。判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
【如：功率大于50W吗、维修记录全不全?然后相应的动作，是进行优先处理，还是做其他处理等等。】
3)大纲法
大纲法是一种着眼于需求的方法，为了列出各种测试条件，我们将需求转换为大纲的形式。大纲表示为树状结构，在根和每个叶节点之间存在唯一的路径。大纲中的每条路径定义了一个特定的输入条件集合，用于定义测试用例。树中叶子的数目或大纲中的路径给出了测试所有功能所需测试用例的大概数量。
【像决策树，比如售货机有零钱，然后投入多少钱怎么处理；如果没零钱，投入多少钱买东西怎么处理。】
5.业务路径覆盖法
1)场景分析法
场景分析法是通过运用场景来对系统的功能点或业务流程的描述，丛而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始，然后再着手其他的场景分析。场景主要包括4种主要的类型：正常的用例场景，备选的用例场景，异常的用例场景，假定推测的场景。
2)功能图法
功能图法是用功能图形象地表示程序的功能说明，并机械地生成功能图的测试用例，功能图法是一种黑盒白盒混合用例设计方法。功能图法是为了解决动态说明问题的一种测试用例的设计方法。
测试方法选择的综合策略※※※
(1)首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的最有效的方法。
(2)在任何情况下都必须使用边界值分析方法。经验表明这种方法设计出的测试用例发现程序错误的能力最强。
(3)可以用错误推测法追加一些测试用例，这需要依靠测试工程师的智慧和经验。
(4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。/如果没有达到要求的覆盖标准，应当补充足够的测试用例。
(5)如果程序的功能说明中含有输人条件的组合情况，则一开始就可以选用因果图法和判定表驱动法。
(6)对于参数配置类的软件或对多条件查询功能进行测试时，要用正交试验法选择较少的组合方式达到最佳效果。
(7)对于业务清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
在确定测试方法时，应该遵循以下原则：
- 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。
- 认真选择测试策略，以便能尽可能少地使用测试用例，发现尽可能多的程序错误。
白盒
白盒测试将测试对象看作一个透明的盒子，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定要求正确工作，而不顾它的功能。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。采用白盒测试方法必须遵循以下几条原则，才能达到测试的目的：
(1)保证一个模块中的所有独立路径至少被测试一次。
(2)所有逻辑值均需测试真(true) 和假(false) 两种情况。
(3)检查程序的内部数据结构，保证其结构的有效性。
(4)在上下边界及可操作范围内运行所有循环。
用于白盒测试的测试工具可以分为内存泄漏检查工具、代码覆盖率检查工具和性能测试工具。
1)静态白盒测试
静态白盒测试是在不执行的条件下，有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程。
静态测试技术主要包括三种：
(1)代码检查法。代码检查主要检查代码与设计的一致性，代码对标准的遵循，可读性，代码逻辑表达的正确性，及代码结构的合理性等方面。
(2)静态结构分析法。/程序的结构形式是白盒测试的主要依据。
(3)静态质量度量法。根据ISO/IEC 9126国际标准的定义， 软件质量包括以下6个方面：功能性、可靠性、易用性、有效性、可维护性、可移植性。
2)动态由盒测试
动态白盒测试又称结构测试，因为软件测试员可以查看并使用代码的内部结构，从而设计和执行测试。
包括：覆盖测试、控制结构测试
信息系统测试管理
测试管理不仅需要对测试项目的过程、测试人员的工作内容进行管理，还需要对其他外部管理体系间的相互关联、相互影响作用进行关注和问题的跟踪解决。测试管理是为了实现测试工作预期目标，以测试人员为中心，对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动。
测试管理的内容按照管理范围和对象，一般可分为测试部门管理和测试项目管理两种。测试部门管理包含部门日常事务、部门人员、部门下属项目、部门资产等的跟踪及管理工作。测试项目管理包含测试人员管理、测试计划及测试策略的编写、测试评审的组织、测试过程的跟进、测试内部和外部的沟通协调、缺陷跟踪等。
测试监控管理
内容如下：
(1)测试用例执行的进度。
计算公式为：测试用例执行的进度=已执行的数目/总数目。
(2)缺陷的存活时间。
计算公式为：缺陷的存活时间=缺陷从open到closed的时间。
(3)缺陷的趋势分析。
(4)缺陷分布密度。
计算公式为：缺陷分布密度=对应于一项需求的总缺陷数/对应于该项需求的测试用例总数。
(5)缺陷修改质量。
计算公式为：缺陷修改质量=每次修改后发现的缺陷数量(包括重现的缺陷和由修改所引起的新缺陷)。
测试工作中主要的风险：
(1)需求风险。对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式；另外需求变更导致测试用例变更，同步时存在误差。
(2)测试用例风险。测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求；测试用例没有得到全部执行，有些用例被有意或者无意的遗漏。
(3)缺陷风险。某些缺陷偶发，难以重现，容易被遗漏。
(4)代码质量风险。软件代码质量差，导致缺陷较多，容易出现测试的遗漏。
(5)测试环境风险。有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差。
(6)测试技术风险。某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期。
(7)回归测试风险。回归测试一般不运行全部测试用例，可能存在测试不完全。
(8)沟通协调风险。测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期。
(9)其他不可预计风险。一些突发状况、不可抗力等也构成风险因素，且难以预估和避免。
测试人员绩效考核
1.工作内容考核：
(1)参与软件开发过程的工作内容考核
(2)参与测试文档的准备工作
(3)执行测试的工作
(4)测试结果缺陷残留
(5)测试人员的沟通能力考核。
2.工作效率与工作质量考核：
1)测试设计中工作效率相关指标
2)测试设计中工作质量相关指标
3)测试执行中工作效率相关指标
4)测试执行中工作质量相关指标
考核注意事项：要想考核得到满意的效果，上述方法的重要的前提条件是必须要在项目中充分收集相关的数据，包括采集缺陷数，记录工时、提交详细工作日志和进行文档配置管理，没有这些数据，定量分析就无从谈起，测试人员考核也无从谈起。
标签：黑盒,覆盖,信息系统,综合测试,等价,测试用例,23.2,测试,输入 来源： https://blog.csdn.net/vavid317/article/details/115621122
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。