软件测试计划的制定通常是在需求分析以及测试需求分析完成后开始，并且是整个软件研发生命周期中的重要环节

如果没有测试计划，会带来哪些问题呢?

1. 很难确切地知道具体的测试范围，以及应该采取的具体测试策略
2. 很难预估具体的工作量和所需要的测试工程师数量，同时还会造成各个测试工程师的分工不明确，引发某些测试工作被重复执行而有些测试则被遗漏的问题
3. 测试的整体进度完全不可控，甚至很难确切知道目前测试的完成情况，对于测试完成时间就更难预估准确的时间节点了
4. 整个项目对潜在风险的抵抗能力很弱，很难应对需求的变更以及其他突发事件

一份好的测试计划要包括:测试范围、测试策略、测试资源、测试进度和测试风险预估，这五大方面，并且每一部分都要给出应对可能出现问题的解决办法

Read More

测试工程师，最基本的一项技能就是，把发现的缺陷准确无歧义地表达清楚

好的缺陷报告绝对不是大量信息的堆叠，而是以高效的方式提供准确有用的信息

一份好的缺陷报告需要包括哪些具体内容呢

缺陷标题

标题是对缺陷的概括性描述.标题应该简洁清晰,足够具体,最好涵盖问题发生的上下文. 其次,标题应该尽可能描述问题本质

缺陷概述

概述中会提供更多的概括性的缺陷本质及现象的描述.是缺陷标题的细化.尽量不要使用具体描述,应该使用概括性语句. 概述的目的是简洁的描述缺陷,使阅读者能尽快聚焦缺陷本质.

缺陷影响

缺陷影响描述的是问题对业务的影响范围及严重程度. 决定了缺陷的优先级和严重程度.准确描述缺陷影响的前提是对软件的应用场景及需求有深入的理解.

环境配置

详细描述测试环境的配置细节,为缺陷复现提供必要的环境信息. 环境配置通常是按需描述,也就是仅列出必要的环境信息.

Read More

官方地址

Read More

总结框架

• 重点工作及业绩成果: 针对核心重点工作或项目的计划和推进结果进行要点阐述,说明进展的状态和取得的成果
• 重点工作思考及改进: 根据核心重点工作中出现的问题或可以改进的地方进行思考分析和总结,提出改进措施或行动计划
• 后续工作计划及方案: 结合大方向目标,及工作改进计划,提出后续的重点工作及具体实施方案

内容呈现和表达思路

内容的体现上突出说明关键工作/项目/事件/活动名称，该重点项中主要点做的是什么，个人的角色定位及取得的成果是什么，实现过程中有没有什么成功的方法或新方法新技术，整合了怎样的资源，带来的价值影响力是什么

内容呈现几点建议

• 数量体现: 理清重点工作,将它们分条阐述.重点工作不宜过多.重点工作应该跳出当前角色审视,不要太细节,数量不宜超过5个
• 价值体现: 阐述完重点工作后,需要说明这些工作带来的积极影响,有什么创造性成果,带来了怎样的经济消息/组织能力的提升
• 思考体现: 有主人翁意识,有主观能动性的体现.有思考说明在工作中有用心的投入和角色的担当.负责任的复盘总结分析，加上对团队发展的建设性改进建议，正是你区别于他人的价值所在
• 形式体现: 尽可能直观,能用图的不用文字,能用数字的不用形容词

Read More

测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，另一类是更偏向技术的代码覆盖率

需求覆盖率

需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量

采用ALM，Doors和TestLink 等需求管理工具来建立需求和测试的对应关系，并以此计算测试覆盖率

代码覆盖率

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

常用的三种代码覆盖率指标

• 行覆盖率又称为语句覆盖率，指已经被执行到的语句占总可执行语句(不包含类似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各一次。

  Read More

自动化测试: 把人工对软件的测试转化为由机器执行测试行为的一种实践，可以把测试工程师从机械重复的测试工作中解脱出来，将更多的精力放在新功能的测试和更全面的测试用例设计上

发现自动化测试用例的维护成本高于其节省的测试成本时，自动化测试就失去了价值与意义

自动化测试的优势:

1. 自动化测试可以替代大量的手工机械重复性操作，测试工程师可以把更多的时间花在更全面的用例设计和新功能的测试上;
2. 自动化测试可以大幅提升回归测试的效率，非常适合敏捷开发过程;
3. 自动化测试可以更好地利用无人值守时间，去更频繁地执行测试，特别适合现在非工作时间执行测试，工作时间分析失败用例的工作模式;
4. 自动化测试可以高效实现某些手工测试无法完成或者代价巨大的测试类型，比如关键业务7×24小时持续运行的系统稳定性测试和高并发场景的压力测试等;
5. 自动化测试还可以保证每次测试执行的操作以及验证的一致性和可重复性，避免人为的遗漏或疏忽。

   Read More

单元测试（英语：Unit Testing）又称为模块测试，是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。

单元测试的好处

• 提升软件质量 优质的单元测试可以保障开发质量和程序的鲁棒性。越早发现的缺陷，其修复的成本越低
• 促进代码优化 会不断去审视自己的代码，从而（潜意识）去优化自己的代码
• 提升研发效率 表面上是占用了项目研发时间，但是在后续的联调、集成、回归测试阶段，单测覆盖率高的代码缺陷少、问题已修复，有助于提升整体的研发效率
• 增加重构自信 代码的重构一般会涉及较为底层的改动，比如修改底层的数据结构等，上层服务经常会受到影响；在有单元测试的保障下，我们对重构出来的代码会多一份底气

单元测试基本原则

宏观上，单元测试要符合 AIR 原则

• A: Automatic（自动化）
• I: Independent（独立性）
• R: Repeatable（可重复）

微观上，单元测试代码层面要符合 BCDE 原则：

• B: Border 边界性测试，包括循环边界、特殊取值、特殊时间点、数据顺序等
• C: Correct 正确的输入，并且得到预期的结果
• D: Design 与设计文档相符合，来编写单元测试
• E: Error 单元测试的目的是为了证明程序有错，而不是证明程序无错 为了发现代码中潜藏的错误，我们需要在编写测试用例时有一些强制的错误输入（如非法数据、异常流程、非业务允许输入等）来得到预期的错误结果

如何验证单元测试的有效性

1. 是否符合基本测试方法(边界值,条件组合)
2. 故障注入是否能被断言有效检出

应用场景

• 开发前写单元测试，通过测试描述需求，由测试驱动开发。（如果不熟悉TDD的同学可以去google一下）
• 在开发过程中及时得到反馈，提前发现问题
• 应用于自动化构建或持续集成流程，对每次代码修改做回归测试。（CI/CD 质量保障）
• 作为重构的基础，验证重构是否可靠

常见痛点

• 测试上下文依赖外部服务（如数据库服务）
• 测试上下文存在代码依赖（如框架等）
• 单元测试难以维护和理解（语义不清）
• 对于多场景不同输入输出的函数，单元测试代码量会很多

写单元测试的难易程度跟代码的质量关系最大，并且是决定性的。项目里无论用了哪个测试框架都不能解决代码本身难以测试的问题

《重构-改善既有代码的设计》《修改代码的艺术》 《敏捷软件开发：原则、模式与实践》

代码执行过程

代码执行过程可以看做一个数据分类,处理的过程.代码异常通常也都能归类到数据分类错误和数据处理错误两种错误原因上.

为实现正确的业务逻辑代码,考虑过程:

• 实现正确的功能逻辑的正常输入
• 特殊处理的多种边界输入
• 潜在的非法输入

单元测试详解

单元测试用例是一个”输入数据”,”输出数据”的集合. 针对确定的数据,根据逻辑功能预先推算出正确的输出,并以执行被测代码的方式来进行验证.

在明确代码需要实现的逻辑功能基础上,设计输入数据,并推算出输入数据应该对应的输出

输入数据不仅仅是函数入参:

• 输入参数
• 内部需要读取的全局静态变量
• 内部需要读取的成员变量
• 函数调用内部子函数获取的数据
• 函数内部调用子函数改写的数据

输出数据,主要包含数据改写和动作执行

• 被测函数的返回值
• 被测函数的输出参数
• 被测函数改写的成员变量
• 被测函数改写的成员变量
• 被测函数进行的文件更新
• 被测函数进行的数据更新
• 被测函数进行的消息队列更新

设计单元测试应该首先定义操作行为,而不是根据代码实现填充行为判定.要脱离代码从行为需要编写断言

Read More

Activity 是在业务流程中执行的工作. 可以是原子的,也可以是非原子(复合)的. 作为 Process 一部分的活动类型有: Task ,Sub-Process 和 Call Activity,它们允许在图中包含可复用的任务和流程. 然而,Process 不是一个特定的图形对象. 它是一组图形对象,下面将重点介绍 Sub-Process 和 Task 两种图形对象

Activities 表示 Process 中执行工作的点. 它们是BPMN流程的可执行元素.

Activity类是一个抽象元素,是FlowElement的子类. Activity具体子类声明了除通用 Activity 语义外的其他语义

Read More

BPMN流程类型

业务流程建模用于向各种各样的受众传达各种各样的信息. BPMN旨在涵盖多种类型的模型,并允许创建端到端的业务流程. 下面是三种基本的BPMN流程类型:

• Private Non-executable (internal) Business Processes
• Private Executable (internal) Business Processes
• Public Processes

Private (Internal) Business Processes

Private Business Process 是特定的组织内部的流程. 这些流程通常被叫做工作流或BPM流程. 在web服务中通常叫做服务编排. 两种典型的私有流程: executable 和 non-executable.可执行流程是指根据指定语义定义执行了建模的流程. 当然,在流程开发周期中,会有某些阶段,流程没有足够的细节可以执行. 不可执行流程是已建模的专用流程，目的是在建模者定义的详细级别上记录流程行为.因此,执行所需的信息（例如形式条件表达式）通常不包括在不可执行的流程中

Read More

Process 相关内容是 BPMN 流程建模标准和 BPMN 完整性标准所必须的. 但是,对于BPMN编排标准,BPMN执行标准,或 BPMN BPEL流程执行标准等不是必须的.

Process 描述了一个组织中的一系列以开展工作为目的的活动或流程. 在BPMN中,一个 Process 被描述为一个由流程元素构成的图,它们是一系列的 Activities, Events, Gateways, 和那些定义了有限执行语义的 Sequence Flows. Process 可以在任何级别定义,从企业范围的 Process 到由单个人员执行的 Process. 低级的 Process 可以组合在一起,以实现共同的业务目标.

注意,BPMN 术语 Process 专指一组流程元素. 它使用协作和编排对流程间交互建模.

Process 包包含用于流程建模的 Activities,Events 和 Gateways 等类, 以及它们如何在一个 Process 中排序的. 定义一个 Process 时,这些内容都包含在定义中.

一个 Process 是一个 CallableElement,使得其它 Process 可以通过 Call Activity 结构引用/重用它. 通过这种能力,一个 Process 可以引用一系列定义在外部的行为接口.

Read More