7.5 测试理论（2）

测试理论（2）

软件测试的分类

按查看代码分类：

1、黑盒测试

把测试的对象看成是一个黑色的盒子的，看不到里面内部的结构，是对软件的一种功能性的测试。

2、白盒测试

就是把测试的对象看成是一个透明的盒子，能够看见被测软件的内部结构，是单元测试的一种形式，是针对程序的内部代码的一种测试形式。

3、灰黑测试

它是介于黑盒测试与白盒测试中间，具体的来说就是测试开发工程师（测试工程师）能够看开发的代码，进行代码的走查，和参与开发代码的评审。

测试编写代码的分类：

1、手工测试

2、自动化测试（UI自动化测试，接口自动化测试）：通过工具或者是代码的形式来模拟人的操作，来对被测试的产品进行自动化测试的操作。

软件的质量

六大特性：

功能性：软件需要满⾜⽤户显式或者稳式的功能。

易用性：软件易于学习和上手使⽤。

可靠性：指的就是软件必须实现需求当中指明的具体功能。

效率性：类似于软件的性能。

可维护性：要求软件具有将某个功能修复之后继续使⽤的能⼒。

可移植性：当前软件可以从⼀个平台移植到另⼀个平台上去使⽤的能⼒。

软件测试的人工检查

1、检查算法的逻辑正确性：确定所编写的代码算法、数据结构定义（如：队列、堆栈等）是否实现了模块或⽅法 所要求的功能。

     什么是算法：在程序里面，指的是做一件事需要的步骤。什么是程序，程序=数据结构+算法。

     数据结构：队列：先进先出；栈：先进后出

2、模块接⼝的正确性检查：确定形式参数个数、数据类型、顺序是否正确；确定返回值类型及返回值的正确性。

3、输⼊参数有没有作正确性检查：如果没有作正确性检查，确定该参数是否的确⽆需做参数正确性检查，否则请 添加上参数的正确性检查。

4、调⽤其他⽅法接⼝的正确性：检查实参类型正确与否、传⼊的参数值正确与否、个数正确与否，特别是具有多 态的⽅法。返回值正确与否，有没有误解返回值所表示的意思。最好对每个被调⽤的⽅法的返回值⽤显示代码作正 确性检查，如果被调⽤⽅法出现异常或错误程序应该给予反馈，并添加适当的出错处理代码。

5、出错处理：模块代码要求能预⻅出错的条件，并设置适当的出错处理，以便⼀旦程序出错时，能对出错程序重 做安排，保证其逻辑的正确性，这种出错处理应当是模块功能的⼀部分。若出现下列情况之⼀，则表明模块的错误 处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不⾜以对错误定位，不⾜以确定出错的原因；显示 的错误信息与实际的错误原因不符；对错误条件的处理不正确；在对错误进⾏处理之前，错误条件已经引起系统的 ⼲预等。

6、保证表达式、SQL语句的正确性：检查所编写的SQL语句的语法、逻辑的正确性。对表达式应该保证不含⼆义 性，对于容易产⽣歧义的表达式或运算符优先级（如：<、=、 >、 &&、||、++、 --等）可以采⽤扩号“（）”运算 符避免⼆义性，这样⼀⽅⾯能够保证代码的正确可靠，同时也能够提⾼代码的可读性。

      <：小于 ==：等于 >：大于 !=：不等于 &&：并且（至少两个条件的关系） ||：或者(至少两个条件满足一个就没可以了)

7、检查常量或全局变量使⽤的正确性：确定所使⽤的常量或全局变量的取值和数值、数据类型；保证常量每次引 ⽤同它的取值、数值和类型的⼀致性。

8、表示符定义的规范⼀致性：保证变量命名能够⻅名知意，并且简洁但不宜过⻓或过短、规范、容易记忆、最好 能够拼读。并尽量保证⽤相同的表示符代表相同功能，不要将不同的功能⽤相同的表示符表示；更不要⽤相同的表 示符代表不同的功能意义。

9、程序⻛格的⼀致性、规范性：代码必须能保证符合企业规范，保证所有成员的代码⻛格⼀致、规范、⼯整。例 如对数组做循环，不要⼀会⼉采⽤下标变量从下到上的⽅式（如:for(i=0;i++;i10)），⼀会⼉⼜采⽤从上到下的⽅式( 如:for(i=10;i--;i0))；应该尽量采⽤统⼀的⽅式，或则统⼀从下到上，或则统⼀从上到下。建议采⽤for循环和While 循环，不要采⽤do{}while循环等。

10、检查程序中使⽤到的神秘数字是否采⽤了表示符定义：神秘的数字包括各种常数、数组的⼤⼩、字符位置、 变换因⼦以及程序中出现的其他以⽂字形式写出的数值。在程序源代码⾥，⼀个具有原本形式的数对其本身的重要 性或作⽤没提供任何指示性信息，它们也导致程序难以理解和修改。对于这类神秘数字必须采⽤相应的标量来表 示；如果该数字在整个系统中都可能使⽤到务必将它定义为全局常量；如果该神秘数字在⼀个类中使⽤可将其定义 为类的属性（Attribute）,如果该神秘数字只在⼀个⽅法中出现务必将其定义为局部变量或常量。

11、检查代码是否可以优化、算法效率是否最⾼：如：SQL语句是否可以优化，是否可以⽤1条SQL语句代替程序 中的多条SQL语句的功能，循环是否必要，循环中的语句是否可以抽出到循环之外等。

12、检查您的程序是否清晰简洁容易理解：注意：冗⻓的程序并不⼀定不是清晰的。

13、检查⽅法内部注释是否完整：是否清晰简洁；是否正确的反映了代码的功能，错误的注释⽐没有注释更糟； 是否做了多余的注释；对于简单的⼀看就懂的代码没有必要注释。

14、检查注释⽂档是否完整：对包、类、属性、⽅法功能、参数、返回值的注释是否正确且容易理解；是否会落 了或多了某个参数的注释，参数类型是否正确，参数的限定值是否正确。特别是对于形式参数与返回值中关于神秘 数值的注释，如：类型参数 应该指出 1.代表什么，2.代表什么，3.代表什么等。对于返回结果集(Result Set)的注 释，应该注释结果集中包含那些字段及字段类型、字段顺序等。

软件分类：

B/S（WEB）的产品测试经验。app的测试经验 小程序的产品（依赖于微信&支付宝）

WEB/APP/小程序

测试术语

冒烟测试：开发把编写好的程序转给测试的时候，程序首先需要做的是针对转测的程序进行正常流程的测试，这个过程叫冒烟测试。

针对被测程序的正常流程的测试，目的是验证程序正常流程可以执行通的情况下继续测试被测程序的其他功能

探索性测试：探索性强调测试⼈员的主观能动性，抛弃繁杂的测试计划和测试⽤例设计过程，强调在碰到问题时及时改变测试策略。

安全测试：主要是针对被测软件进行安全的考虑，目前主要使用的技术是渗透测试。

回归测试：产品都已经测试完成了，在准备上线的情况下，针对产品进行第N次的测试。回归测试目前主要是大量的自动测试来承担这部分的任务。

                  测试环境：1、系统已有功能的测试（回归）

                  线上环境：1、系统已有功能的测试    2、这对本次上线新功能的回归测试

如何做软件测试数据分析

为什么要需求分析

软件测试需求是设计测试⽤例的依据。

有助于保证测试的质量和进度

软件测试需求是衡量测试覆盖率的重要指标

软件测试需求分析步骤

列出需求⽂档中的具有可测性的原始需求

对每⼀条需求进⾏细化分解，形成可测试的分层描述的测试点

对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执⾏时需要实施的测试类型。

建⽴测试需求跟踪矩阵，对测试需求进⾏管理

测试点分析

通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）

各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验 证内容（功能业务测试） 考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况 （界⾯、易⽤性、兼容性、安全性、性能）

测试用例七大设计方法

测试用例概述

测试⽤例是为特定的⽬的⽽设计的⼀组测试输⼊、执⾏条件和预期的结果。测试⽤例是执⾏的最⼩实体。简单地说，测试⽤例就是设计⼀个场景，使软件程序在这种场景下，必须能够正常运⾏并且达到程序所设计的执⾏结果。

测试用例步骤

拿到测试需求 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分⽤例优先级（思维导图网站：https://www.processon.com/）

测试用例编写特征

⼀致性：主要包括⽤例模板⼀致；各同事的编写⼿法⼀致；以及⽤例的细腻度⼀致。

覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产⽣影响的覆盖；对各种场景的覆盖等 。

可执⾏性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。

执⾏准确性：是指⽤例执⾏的准确度，本身没什么技术含量。但这⾥需要注意的是执⾏⼈对待执⾏⽤例的态度。不要因为⽤例简单或者⼀些外界的因素，导致部分⽤例未实际执⾏标为通过的情况。

持续更新：要及时不断的更新，要尽量减少⽤例库中失效的⽤例 。 复⽤性：主要⽤例可以被不断的复⽤，从⽽减少维护成本

编写测试用例的三种方式：

1、思维导图 结构化看起来非常的好，但是不够细

2、使用excel，特点是写起来非常浪费时间，但是非常细

3、checklist 只考虑被测对象的大概的点测试⽤例组成元素

测试用例的要素（加黑的为必须部分）

⽤例ID；

用例名称；

测试⽬的；

测试级别；

参考信息；

测试环境；

环境：

1、测试环境：给测试使用的环境，指的是一个产品还没上线前测试的环境

2、预发布环境：介于测试环境与线上环境中间，但是它也是可以给客户使用的环境，一般不开放，只供研发内部人员使用

3、线上环境：给真实的用户使用的环境

前提条件；

测试步骤；

预期结果；

设计⼈员。