软件测试基本准侧与方法的摘录（应用实例待补充）

写在最开始：“测试是为发现错误而执行程序的过程”。————《软件测试的艺术》

🤩 本文中很多概念描述摘抄自还有很多概念没有列举。已写的部分概念缺少相应的实例，尚且留待补充。 ——2022.6.18

一、测试职责

• 发现软件缺陷

• 验证产品特性是否符合用户需求

• 解释产品风险，评估产品质量

二、测试的部分重要原则

1、测试心理

从客户需求出发

• 这个新功能对客户的价值是什么？
• 客户会如何使用这个新功能？
• 客户在使用这个功能时，会进行什么样的操作？
• 按目前设计，用户觉得方便、舒服吗？

可测试性

• 输入输出结果，可控制、可观察、可度量
• 需求明晰明确可验证
• 接口与UI定义清晰，设计可验证

计划测试工作时不应默许假定不会发现错误

• 测试显示缺陷的存在，但不能证明系统不存在缺陷。
• 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
• 测试可以减少软件中存在未被发现缺陷的可能性，但即使测试没有发现任何缺陷，也不能证明软件或系统是完全正确的。

2、测试方法&策略

贯穿SDLC（System Development Life Cycle）

• 持续地测试、持续地反馈。
• 软件测试贯穿着整个软件开发生命周期，随时发现需求、设计或代码中问题，及时将发现的问题反馈给用户、产品设计人员、开发人员等，主动、积极地交流，持续提高软件产品质量，这在敏捷测试中更为重要。

测试尽早介入

• 项目一启动，软件测试就应开始，测试人员就应参与项目的各种活动和开展对应的测试活动。
• 测试工作进行得越早，软件开发的劣质成本就越低，并能更好地保证软件质量。

系统质量（缺陷）发现越早越好

• 缺陷与问题越早暴露，其纠错成本越低
• 考虑沉没成本，缺陷问题应提尽提，

缺陷集群

• 在测试中发现缺陷多的地方，会有更多的缺陷没被发现。对发现错误较多的程序段，应进行更深入的测试

• 80/20 原则，即帕累托法则（Pareto Principle）

  用户80％的时间在使用软件产品中20％的功能。“重点测试”就是测试这20％的功能，而其他80％的功能属于优先级低的测试范围，占测试20%的资源

依赖上下文调整测试方法与测试策略

• 针对不同的测试背景，进行的测试活动也是不同的。

3、测试用例

测试用例设计

• 测试用例中一个必需部分是对预期输出或结果进行定义
• 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预
  料到的输入情况
• 不可能的穷尽测试

测试用例规划

• 应避免测试用例用后即弃，除非软件本身就是一个一次性的软件

• 杀虫剂悖论

  采用同样的测试用例多次重复进行测试，最后将不再能发现新的缺陷。为了克服这种“杀虫剂悖论”，测试用例需要进行定期评审和修改，同时需要不断地增加新的不同的测试用例来测试软件或系统的不同部分，从而发现潜在的更多的缺陷。

• 不可能的穷尽测试

  由于有太多的输入组合、有太多的路径，而且时间是有限的，无法做到完全的测试（100%测试覆盖率）。通过运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试

三、黑盒与白盒测试

1、黑盒测试

​ 黑盒测试又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。（其更加关注的是输入所对应输出结果的正确性。）

2、白盒测试

​ 白盒测试又称逻辑驱动的测试，其允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查，从中获取测试数据。其更加关注于程序的内部运行机理。

四、集成测试

1、单元测试

待补充

2、功能测试

待补充

3、系统测试

待补充

五、测试用例的设计

一个好的测试用例应当具有相当高的可能性发现某个错误

对程序的穷举输入测试是无法实现的

1.白盒测试用例编写

• 逻辑覆盖测试。

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说，完全的路径测试并不切合实际。

• 实现准则。

（1）将每个判断的所有结果都至少执行一次；

（2）将所有的程序入口都至少调用一次，以确保全部的语句都至少执行一次。而对于包含多重条件判断的程序，最简单的测试准则是设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次（加入“可能”二字，是因为有些组合情况难以生成）

• 辅助工具

[Jacoco](EclEmma - JaCoCo Java Code Coverage Library)，jacoco是一个开源的代码覆盖率工具，针对java语言，其使用方法很灵活，可以嵌入到Ant、Maven中；可以作为Eclipse插件，可以使用其JavaAgent技术监控Java程序等等。代码覆盖率一般又分为单元测试覆盖率和功能测试覆盖率，对于开发人员，一般比较关注单元测试覆盖率，而对于测试人员，一般更关注的是功能测试覆盖率。

其他类型辅助工具待补充

2. 黑盒测试用例编写

黑盒测试的目标是基于规格与需求，找出程序不符合规格/需求的地方。

1）. 等价划分

• 等价划分原则

1. 严格控制测试用例的增加，减少为达到“合理测试”的某些既定目标而必须设计的其他测试用例的数量。

   每个测试用例都必须体现尽可能多的不同的输入情况，以使最大限度地减少测试所需的全部用例的数量

2. 它覆盖了大部分其他可能的测试用例。也就是说，它会告诉我们，使用或不使用这个特定的输入集合，哪些错误会被发现，哪些会被遗漏掉。

   尽量将程序输入范围进行划分，将其划分为有限数量的等价类，这样就可以合理地假设（但是，显然不能绝对肯定）测试每个等价类的代表性数据等同于测试该类的其他任何数据。

• 等价类用例的生成

确定等价类是选取每一个输入条件并将其划分为两个或更多的组。注意，我们确定了两类等价类：有效等价类代表对程序的有效输入，而无效等价类代表的则是其他任何可能的输入条件（即不正确的输入值）。可以使用表3-1来进行划分

无效等价类	有效等价类	外部条件

​ 表3-1

1.为每个等价类设置一个不同的编号。

2.编写新的测试用例，尽可能多地覆盖那些尚未被涵盖的有效等价类，直到所有的有效等价类都被测试用例所覆盖（包含进去）。

3.编写新的用例，覆盖一个且仅一个尚未被涵盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖。

2）. 边界值分析

• 边界条件

所谓边界条件，是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态

• 边界值用例的生成

• 与从等价类中挑选出任意一个元素作为代表不同，边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。
• 与仅仅关注输入条件（输入空间）不同，还需要考虑从结果空间（输出等价类）设计测试用例。

3）. 因果图

• 因果图

因果图是一种形式语言，用自然语言描述的规格说明可以转换为因果图。因果图实际上是一种数字逻辑电路（一个组合的逻辑网络）。

• 边界条件

• 将规格说明分解为可执行的片段。这是必须的步骤，因为因果图不善于处理较大的规格说明。举例来说，当测试一个电子商务系统时，“可执行的片段”可能是指对挑选和确认购物车中的单件商品的规格说明。在测试一个Web页面设计时，我们可能会测试一个单独的菜单树，甚至是一个不太复杂的导航序列。
• 确定规格说明中的因果关系。所谓“因”，是指一个明确的输入条件或输入条件的等价类。所谓“果”，是指一个输出条件或系统转换（输入对程序或系统状态的延续影响）。举例来说，如果某个事务引起文件或数据库记录被修改，那么这种改变就是一个系统转换，而系统反馈的确认信息就是一个输出条件。通过逐字逐句地阅读规格说明，同时标识出描述“因”和“果”的文字或句子，就可以将“因”和“果”确定出来。因果关系一旦确定下来，每个“因”和“果”都被赋予一个惟一的编号。
• 分析规格说明的语义内容，并将其转换为连接因果关系的布尔图。这就是所谓的因果图。
• 给图加上注解符号，说明由于语法或环境的限制而不能联系起来的“因”和“果”。
• 通过仔细地跟踪图中的状态变化情况，将因果图转换成一个有限项的判定表。表中的每一列代表一个测试用例。
• 将判定表中的列转换成测试用例