软件测试理论知识

一：设计测试用例方法

1、一个“好的”测试用例特征。
整体完备性：
“好的”测试用例一定是一个完备的整体，是有效测试用例组成的集合，能够完全覆盖测试需求。
等价类划分的准确性：
指的是对于每个等价类都能保证只要其中一个输入测试通过，其他输入也一定测试通过。
等价类集合的完备性：
需要保证所有可能的边界值和边界条件都已经正确识别。
2、测试用例设计方法有：
等价类划分法、边界值分析法、错误推测方法、因果图方法、判定表驱动分析法、正交实验设计方法、功能图分析方法、场景设计方法、形式化方法、扩展有限状态机方法
对大多数的软件测试而言，综合使用等价类划分、边界值分析和错误推测这三大类方法就足够了
3、等价类划分方法
等价类中任意一个输入数据对于揭露程序中潜在错误都具有同等效果。后续我们只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果
案例：学生信息系统中有一个“考试成绩”的输入项，成绩的取值范围是 0~100 之间的整数，考试成绩及格的分数线是 60。
为了测试这个输入项，显然不可能用 0~100 的每一个数去测试。通过需求描述可以知道，输入 0~59 之间的任意整数，以及输入 60~100 之间的任意整数，去验证和揭露输入框的潜在缺陷可以看做是等价的。
那么这就可以在 0~59 和 60~100 之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的“有效等价类”
等价类划分方法的另一个关键点是要找出所有“无效等价类”。显然，如果输入的成绩是负数，或者是大于 100 的数等都构成了“无效等价类”
在考虑了无效等价类后，最终设计的测试用例为：
有效等价类 1：0~59 之间的任意整数；
有效等价类 2：59~100 之间的任意整数；
无效等价类 1：小于 0 的负数；
无效等价类 2：大于 100 的整数；
无效等价类 3：0~100 之间的任何浮点数；
无效等价类 4：其他任意非数字字符
4、边界值分析方法
边界值分析是对等价类划分的补充，你从工程实践经验中可以发现，大量的错误发生在输入输出的边界值上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。
我们继续看学生信息系统中“考试成绩”的例子，选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101
5、错误推测方法
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
错误推测法和目前非常流行的“探索式测试方法”的基本思想和理念是不谋而合的，这类方法在目前的敏捷开发模式下的投入产出比很高，因此被广泛应用。但是，这个方法的缺点也显而易见，那就是难以系统化，并且过度依赖个人能力。
在软件企业的具体实践中，为了降低对个人能力的依赖，通常会建立常见缺陷知识库，在测试设计的过程中，会使用缺陷知识库作为检查点列表（checklist），去帮助优化补充测试用例的设计。
对于中小企业，可能最初的方法就是建立一个简单的 wiki 页面，让测试工程师完成测试用例的最初设计后对应这个 wiki 页面先做一轮自检，如果在后续测试中发现了新的点，就会继续完善这个 wiki 页面。
6、如何设计测试用例：
面向终端用户的 GUI 测试，最核心的测试点就是验证软件对需求的满足程度，这就要求测试工程师对被测软件的需求有深入的理解。在我看来，深入理解被测软件需求的最好方法是，测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端（End-2-End）的测试用例集。这个阶段的测试用例设计，主要目的是验证各个业务需求是否被满足，主要采用基于黑盒的测试设计方法。

在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。

二：单元测试

单元测试：是用来对一个模块，一个函数或者一个类来进行正确性检验的测试工作
单元测试通常由开发工程师完成，一般会伴随开发代码一起递交至代码库。单元测试属于最严格的软件测试手段，是最接近代码底层实现的验证手段，可以在软件开发的早期以最小的成本保证局部代码的质量。
在具体的工程实践中，开发工程师为了设计并实现逻辑功能正确的代码，通常会有如下的考虑过程：
如果要实现正确的功能逻辑，会有哪几种正常的输入；
是否有需要特殊处理的多种边界输入；
各种潜在非法输入的可能性以及如何处理。
单元测试的用例是一个“输入数据”和“预计输出”的集合
常见的单元测试“输入数据”：
被测试函数的输入参数；
被测试函数内部需要读取的全局静态变量；
被测试函数内部需要读取的成员变量；
函数内部调用子函数获得的数据；
函数内部调用子函数改写的数据；
嵌入式系统中，在中断调用时改写的数据；
再来看看“预计输出”，如果没有明确的预计输出，那么测试本身就失去了意义。同样地，“预计输出” 绝对不是只有函数返回值这么简单，还应该包括函数执行完成后所改写的所有数据。 具体来看有以下几大类：
被测试函数的返回值；
被测试函数的输出参数；
被测试函数所改写的成员变量；
被测试函数所改写的全局变量；
被测试函数中进行的文件更新；
被测试函数中进行的数据库更新；
被测试函数中进行的消息队列更新；
驱动代码，桩代码和 Mock 代码
驱动代码，桩代码和 Mock 代码，是单元测试中最常出现的三个名词。驱动代码是用来调用被测函数的，而桩代码和 Mock 代码是用来代替被测函数调用的真实代码的。

三：自动化测试

为什么开展自动化测试
1、可以替代重复的工作
2、提高回归测试效率
3、可以无人值守，减少人工成本
4、可以完成手工无法完成的工作

什么样的项目适合做自动化
1、需求稳定，不会频繁变更
2、研发和维护周期长，需要频繁执行回归测试。
3、需要在多种平台上重复运行相同测试的场景。
4、某些测试项目通过手工测试无法实现，或者手工成本太高。
5、被测软件的开发较为规范，能够保证系统的可测试性
6、某些用例的自动化必须要求开发人员在产品中预留可测试性接口，否则后续的自动化会很难开展
7、测试人员已经具备一定的编程能力。

四：测试覆盖率

测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。
1、需求覆盖率
需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。
2、代码覆盖率
简单来说，代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。
3、代码覆盖率的价值
现在很多项目都在单元测试以及集成测试阶段统计代码覆盖率，但是我想说的是，统计代码覆盖率仅仅是手段，你必须透过现象看到事物的本质，才能从根本上保证软件整体的质量。
统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。
代码覆盖率工具
JaCoCo 是一款 Java 代码的主流开源覆盖率工具，可以很方便地嵌入到 Ant、Maven 中，并且和很多主流的持续集成工具以及代码静态检查工具，比如 Jekins 和 Sonar 等，都有很好的集成。

五：软件缺陷报告

缺陷报告的组成
1、缺陷标题 ：
首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。
其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面。
比如，“商品金额输入框，可以输入英文字母和其他字符”这个描述就只描述了问题的表面现象，而采用诸如“商品金额输入框，没有对输入内容做校验”的方式，就可以透过标题看到缺陷的本质，这样可以帮助开发人员快速掌握问题的本质。
2、缺陷概述：
缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。这部分内容通常是开发工程师打开缺陷报告后最先关注的内容，所以用清晰简短的语句将问题的本质描述清楚是关键
3、缺陷影响
缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。
缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才能发布产品。
4、环境配置
环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。 比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。
5、前置条件
前置条件是指测试步骤开始前系统应该处在的状态，其目的是减少缺陷重现步骤的描述。合理地使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性。
6、缺陷重现步骤
缺陷重现步骤是整个缺陷报告中最核心的内容，其目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤。
7、期望结果和实际结果
期望结果和实际结果通常和缺陷重现步骤绑定在一起，在描述重现步骤的过程中，需要明确说明期待结果和实际结果。期待结果来自于对需求的理解，而实际结果来自于测试执行的结果。
8、优先级（Priority）和严重程度（Severity）
我之所以将优先级和严重程度放在一起，是因为这两个概念看起来有点类似，而本质却完全不同。而且，很多入行不久的测试工程师，也很难搞清楚这两者的差异到底在哪里。
根据百度百科的解释，缺陷优先级是指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
可见，严重程度是缺陷本身的属性，通常确定后就不再变化，而优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动。那么，缺陷的优先级和严重程度又有什么关系呢？
缺陷越严重，优先级就越高；
缺陷影响的范围越大，优先级也会越高；
有些缺陷虽然从用户影响角度来说不算严重，但是会妨碍测试或者是自动化测试的执行，这类缺陷属于典型的严重程度低，但是优先级高；
有些缺陷虽然严重程度比较高，但是考虑到修复成本以及技术难度，也会出现优先级较低的情况。
9、附件
附件通常是为缺陷的存在提供必要的证据支持，常见的附件有界面截图、测试用例日志、服务器端日志、GUI 测试的执行视频等

六：测试计划

测试计划要包括：测试范围、测试策略、测试资源、测试进度和测试风险预估，这五大方面，并且每一部分都要给出应对可能出现问题的解决办法。
1、测试范围
测试范围描述的是被测对象以及主要的测试内容
比如，对于用户登录模块，功能测试既需要测试浏览器端又需要测试移动端，同时还考虑登录的安全和并发性能相关的非功能性需求的测试等。
测试范围的确定通常是在测试需求分析完成后进行，所以确定测试范围的过程在一定程度上也是对测试需求分析的进一步检验，这将有助于在早期阶段就发现潜在的测试遗漏。
同时，由于不可能进行穷尽测试，而且测试的时间和资源都是有限的，所以必须有所取舍，进行有针对性的测试。因此，测试范围中需要明确“测什么”和“不测什么”。
2、测试策略
测试策略简单来讲就是需要明确“先测什么后测什么”和“如何来测”这两个问题
测试策略会要求我们明确测试的重点，以及各项测试的先后顺序
比如，对用户登录模块来讲，“用户无法正常登录”和“用户无法重置密码”这两个潜在问题，对业务的影响孰轻孰重一目了然，所以，你应该按照优先级来先测“用户正常登录”，再测“用户重置密码”。
测试策略还需要说明，采用什么样的测试类型和测试方法。 这里需要注意的是，不仅要给出为什么要选用这个测试类型，还要详细说明具体的实施方法。
第一，功能测试
对于功能测试，你应该根据测试需求分析的思维导图来设计测试用例。
主线业务的功能测试由于经常需要执行回归测试，所以你需要考虑实施自动化测试，并且根据项目技术栈和测试团队成员的习惯与能力来选择合适的自动化测试框架。
这里需要注意的是，你通常应该先实现主干业务流程的测试自动化。
第二，兼容性测试
对于兼容性测试来说，Web 测试需要确定覆盖的浏览器类型和版本，移动设备测试需要确定覆盖的设备类型和具体 iOS/Android 的版本等。
第三，性能测试
对于性能测试，需要在明确了性能需求（并发用户数、响应时间、事务吞吐量等）的前提下，结合被测系统的特点，设计性能测试场景并确定性能测试框架。
测试资源
测试资源通常包括测试人员和测试环境，这两类资源都是有限的。测试计划的目的就是，保证在有限资源下的产出最大化。所以，测试资源就是需要明确“谁来测”和“在哪里测”这两个问题。
测试进度
在明确了测试范围、测试策略和测试资源之后，你就要考虑具体的测试进度了。测试进度主要描述各类测试的开始时间，所需工作量，预计完成时间，并以此为依据来建议最终产品的上线发布时间。
测试风险预估
俗话说，计划赶不上变化，对于测试也是一样的道理，很少有整个测试过程是完全按照原本测试计划执行的。通常需求变更、开发延期、发现重大缺陷和人员变动是引入项目测试风险的主要原因。
对于需求变更，比如增加需求、删减需求、修改需求等，一定要重新进行测试需求分析，确定变更后的测试范围和资源评估，并与项目经理和产品经理及时沟通因此引起的测试进度变化。测试经理 / 测试负责人切忌不能有自己咬牙扛过去的想法，否则无论是对测试团队还是对产品本身都不会有任何好处。
另外，随着测试的开展，你可能会发现前期对于测试工作量的预估不够准确，也可能发现需要增加更多的测试类型，也可能发现因为要修改测试架构的严重缺陷而导致很多的测试需要全回归，还有可能出现开发递交测试版本延期，或者人员变动等各种情况。
所以，在制定测试计划时，你就要预估整个测试过程中可能存在的潜在风险，以及当这些风险发生时的应对策略。 那么，在真的遇到类似问题时，你才可以做到心中不慌，有条不紊地应对这些挑战。

七：测试人员的核心竞争力

1、测试策略设计能力
测试策略设计能力是指，对于各种不同的被测软件，能够快速准确地理解需求，并在有限的时间和资源下，明确测试重点以及最适合的测试方法的能力。
2、测试用例设计能力
测试用例设计能力是指，无论对于什么类型的测试，都能设计出高效地发现缺陷，保证产品质量的优秀测试用例。
3、快速学习能力
对不同业务需求和功能的快速学习与理解能力；
对于测试新技术和新方法的学习与应用能力。
4、探索性测试思维
探索性测试是指，测试工程师在执行测试的过程中不断学习被测系统，同时结合基于自己经验的错误猜测和逻辑推理，整理和分析出更多的有针对性的测试关注点
5、缺陷分析能力
对于已经发现的缺陷，结合发生错误的上下文以及后台日志，可以预测或者定位缺陷的发生原因，甚至可以明确指出具体出错的代码行，由此可以大幅缩短缺陷的修复周期，并提高开发工程师对于测试工程师的认可以及信任度；
根据已经发现的缺陷，结合探索性测试思维，推断同类缺陷存在的可能性，并由此找出所有相关的潜在缺陷；
可以对一段时间内所发生的缺陷类型和趋势进行合理分析，由点到面预估整体质量的健康状态，并能够对高频缺陷类型提供系统性的发现和预防措施，并以此来调整后续的测试策略。
6、自动化测试技术
比如：接口自动化、ui自动化
掌握自动化测试技术，可以把你从大量的重复性手工劳动中解放出来，这样你可以把更多的时间花在更多类型的测试上。
7、良好的沟通能力