我敢打赌你一定不知道的软件测试基础知识整理

目录

1、什么是测试覆盖率吗？

2、提交的缺陷包含什么内容？

3、你们的测试流程是怎样的？

4、你写过测试计划么，包含什么内容

5、如何设计登录模块的测试用例？

6、总结

7、重点：配套学习资料和视频教学

---

1、什么是测试覆盖率吗？

测试覆盖率通常被用来衡量测试的充分性和完整性，从广义的角度来讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率。

• 需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量。需求覆盖率统计方法属于传统瀑布模型下的软件工程实践。互联网测试项目中很少直接基于需求来衡量测试覆盖率，而是将软件需求转换成测试需求，然后基于测试需求再来设计测试点。

• 代码覆盖率是指，至少被执行了一次的条目数占整个条目数的百分比。

代码覆盖率常用的指标

• 行覆盖率又称为语句覆盖率，指已经被执行到的语句占总可执行语句（不包含类似 C++ 的头文件声明、代码注释、空行等等）的百分比。这是最常用也是要求最低的覆盖率指标。实际项目中通常会结合判定覆盖率或者条件覆盖率一起使用。

• 判定覆盖又称分支覆盖，用以度量程序中每一个判定的分支是否都被测试到了，即代码中每个判断的取真分支和取假分支是否各被覆盖至少各一次。比如，对于 if(a>0 && b>0)，就要求覆盖“a>0 && b>0”为 TURE 和 FALSE 各一次。

• 条件覆盖是指，判定中的每个条件的可能取值至少满足一次，度量判定中的每个条件的结果 TRUE 和 FALSE 是否都被测试到了。比如，对于 if(a>0 && b>0)，就要求“a>0”取 TRUE 和 FALSE 各一次，同时要求“b>0”取 TRUE 和 FALSE 各一次。

代码覆盖率的价值

统计代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些由于需求变更等原因造成的不可达的废弃代码。

代码覆盖率的局限

即使你所设计的测试用例已经达到 100% 的代码覆盖率，软件产品的质量也做不到万无一失。其根本原因在于代码覆盖率的计算是基于现有代码的，并不能发现那些“未考虑某些输入”以及“未处理某些情况”形成的缺陷。

总结来讲，高的代码覆盖率不一定能保证软件的质量，但是低的代码覆盖率一定不能能保证软件的质量。

                     

 

2、提交的缺陷包含什么内容？

相同问题：如何提一个高质量的 bug 单？

• 缺陷标题

首先，对“什么问题”的描述不仅要做到清晰简洁，最关键是要足够具体，切忌不能采用过于笼统的描述。描述“什么问题”的同时还必须清楚地表述发生问题时的上下文，也就是问题出现的场景。

其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面。

最后，缺陷标题不易过长，对缺陷更详细的描述应该放在“缺陷概述”里。

• 缺陷概述

缺陷概述通常会提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化。这部分内容通常是开发工程师打开缺陷报告后最先关注的内容，所以用清晰简短的语句将问题的本质描述清楚是关键。

• 缺陷影响

缺陷影响描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度。

缺陷影响决定了缺陷的优先级（Priority）和严重程度（Severity），开发经理会以此为依据来决定修复该缺陷的优先级；而产品经理会以此为依据来衡量缺陷的严重程度，并决定是否要等该缺陷被修复后才能发布产品。测试工程师准确描述缺陷影响的前提是，必须对软件的应用场景以及需求有深入的理解，这也是对测试工程师业务基本功的考验。

• 环境配置

环境配置用以详细描述测试环境的配置细节，为缺陷的重现提供必要的环境信息。比如，操作系统的类型与版本、被测软件版本、浏览器的种类和版本、被测软件的配置信息、集群的配置参数、中间件的版本信息等等。

需要注意的是，环境配置的内容通常是按需描述，也就是说通常只描述那些重现缺陷的环境敏感信息。

• 前置条件

前置条件是指测试步骤开始前系统应该处在的状态