总结
- 自测要占开发整体投入的30%,自测决定了产品质量
- 需要计划,填写自测表,功能覆盖度尽可能全
- 单元测试:保证核心方法、接口、场景都能覆盖到,必须有完整的断言。主要包含:
- 测试数据准备、准备Mock方法
- 主流程正向测试
- 主流程逆向测试
- 详细功能-正常场景测试
- 详细功能-异常场景测试
- 并发性能测试
- 测试数据清理
- 接口测试
- Review
** 但是往往开发写了测试代码,准备了测试数据,只保证在测这个方法的时候,测试代码是可运行的,而一旦测试数据被改动了,或者程序有改动,测试方法便无法执行了,而对于那些需要依赖外部环境或者第三方接口的方法,开发几乎是不会去写测试代码的
软件缺陷
- 软件未实现产品说明书要求的功能;
- 软件出现了产品说明书指明不应该出现的错误;
- 软件实现了产品说明书未提到的功能;
- 软件未实现产品说明书虽未明确提及但应该实现的目标;
- 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。
测试用例
- 需要细节和真实,但不需要太详细(容易阻滞测试工作);
- 编写测试计划:测试设计说明、测试用例说明、测试过程说明;
- 设定优先级
并非所有软件缺陷都需要修复
黑盒测试
测试软件基本方法:
- 通过性测试:确认软件至少能做什么
- 失效性测试:蓄意攻击软件薄弱环节
黑盒测试用例设计方法
等价类划分:筛选测试用例
选择有关数值,舍弃无关数值(划分类别)
等价类划分法是把程序的输入域划分成若干部分(子集),然后从每个部分中选取少数代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值
有效等价类: 是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
无效等价类: 与有效等价类的定义恰巧相反。
设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性。
测试用例设计-等价类划分
数据测试:进行边界条件分析
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,通常作为对等价类划分法的补充,其测试用例来自等价类的边界。
边界值分析法
状态测试
状态转换测试
软件状态: 软件当前所处的条件或者模式。
通过不同的状态验证程序的逻辑流程,建立状态转换图。
列出所有状态转换用例:0状态切换,1个状态切换…
错误推断法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法
因果图法
因果图法是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件的各种组合情况
判定表驱动法
根据因果图建立判定表。
判定表分条件桩和动作桩,条件项和动作项:
- 条件桩(Condition Stub):列出了问题得所有条件。通常认为列出的条件的次序无关紧要。
- 动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
- 条件项(Condition Entry):列出针对它左列条件的取值。在所有可能情况下的真假值。
- 动作项(Action Entry):列出在条件项的各种取值情况下应该采取的动作。
正交试验法
正交试验设计方法
异常分析法
异常分析法是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析,以此设计test case,验证系统的容错能力,以及当系统出现异常时故障恢复的能力。
黑盒测试用例设计总结
综合策略:
1. 在任何情况下都必须使用边界值分析方法,经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2. 必要时用等价类划分方法补充一些测试用例。
3. 用错误推测法再追加一些测试用例。
4. 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的测试用例。
5. 如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。
**测试用例设计步骤: **
- 构造根据设计规格得出的基本功能测试用例;
- 边界值测试用例;
- 状态转换测试用例;
- 错误猜测测试用例;
- 异常测试用例;
- 性能测试用例;
- 压力测试用例。
静态白盒测试(结构化分析):检查设计和代码
不执行软件,有条理地审查软件设计、体系结构和代码。
1.数据流测试
数据流分析测试
数据流分析测试是指变量 定义(赋值)与使用位置的 一种基于程序结构性的测试方法。该分析方法重点关注变量的定义与使用.
2.控制流图
控制流测试
控制流图是一个过程或程序的抽象表现,常以数据结构链的形式表示。简称流图,是对程序流程图进行简化后得到的,它可以更加突出的表示程序控制流的结构。
3.计算环路复杂度
- V(G) = m – n + 2,其中 m 是边数,n 是顶点数,这是最常用的一种计算方法;
- 除此之外,V(G) = P + 1,其中 P 是程序流图中判定节点数;
- 如果A是程序流程图的封闭区域数目,区域的个数定义为边和节点圈定的封闭区间域数加上图形外的区域数1,那么V(G) = A + 1。
4.逻辑覆盖
利用逻辑覆盖导出测试用例
逻辑覆盖
逻辑覆盖实例
语句覆盖
选择足够多的测试用例,使程序中每一可执行语句至少执行一次
判定(分支)覆盖
选择足够多的测试用例,使程序中每个判定的”真”和”假”至少执行一次
条件覆盖
选择足够多的测试用例,使程序中每个判定的每个条件取得各种可能的结果
判定/条件覆盖
选择足够多的测试用例,使程序中每个判定的”真”和”假”至少执行一次,并且每个判定的每个条件取得各种可能的结果。
条件组合覆盖
选择足够多的测试用例,使程序中所有判定的条件组合至少执行一次
路径覆盖
选择足够多的测试用例,使程序中每条路径至少执行一次
动态白盒测试(结构化测试)
单元测试
单元测试由开发人员进行,并测试他或她开发的代码单元(即模块,组件)。 这是一种测试方法,通过该方法测试源代码的各个单元以确定它们是否准备就绪。 由于可以在开发生命周期的早期阶段识别出错误,因此有助于减少错误修复的成本。
集成测试
集成测试由测试人员执行,并测试软件模块之间的集成。 它是一种软件测试技术,其中将程序的各个单元组合在一起并作为一组进行测试。 测试存根和测试驱动程序用于协助集成测试。 集成测试以两种方式执行,它们是自下而上的方法和自上而下的方法。
系统测试
回归测试
冒烟测试
作为开发人员,主要做的就是单元测试,测试每个模块和组件,注意测试基本错误,同时需要测试各功能模块直接的状态转换。
注意事项
- 每次更改版本或组件前,做好备份
- 真机测试前,先运行机器,确定机器没问题再进行版本测试,以节省时间
- 记住出问题时间点,方便日志查看
- 测试用例详细,但不能太细,影响工作效率
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!