测试用例
-
概念： 测试用例就是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来
-
特征
- 有效性：能够使用 且不同人员使用测试结果一致
- 可重复性：良好的测试用例具有重复使用的功能能（回归测试）
- 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用(功能，性能，易用分类编号)
- 清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的针对性，不应出现一些无用的操作步骤。
- 可维护性：软件开过程中，需求变更等原因，要对测试用例修改，添加，删除，以便符合相应测试要求
-
作用
- 避免盲目测试并提高测试效率，
- 实施重点突出，目的明确
-
组成元素
用例编号，所属模块，优先级，前置条件，测试描述，执行操作，输入数据，预期结果，实际结果
-
编写测试用例的方法
-
1.等价类划分 多用于输入框
-
边界值法
每个等价类的边界都进行测试
-
因果图
-
适用于输入条件比较多的情况，测试所有的输入条件的排列组合
所谓的原因就是输入，所谓的结果就是输出
-
-
场景法
- 事件触发时出现了场景，同一事件不同的触发顺序和处理结果就形成了事件流
- 基本流 最主要的一个业务流程
- 备选流 以基本流位基础，在经过的每个判定节点出满足不同的出发条件而导致的其他事件流
- 银行ATM案例 个人识别号pin personal identification number
-
错误推测法
-
正交表法
- 正交表查询地址：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm
- 应用场景：在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法
n代表测试用例的行数 试验次数 k代表因素的个数 m是每个因素的水平数 n = k *(m -1) +1;
-
-
测试用例的评审
包含:参与评审人员(需求人员，对应的开发人员，对应的测试人员，项目经理)
评审内容,评审的时间
测试计划
确定测试范围
制定测试策略
测试资源安排
-------测试时间、工作量、人员
-------由于每个人的思维存在局限性，每项测试最后安排不少于2个人测试，以便交叉测试
进度安排
-------最好能预留一段缓冲时间，用于应对计划的变更，以及让测试员有时间完善和补充测试用例
风险及对策
-------可考虑建立后备机制
软件缺陷
常常又被叫做BUG
软件缺陷的种类划分
-
功能不正常
-
软件在使用上感觉不方便
只要是不知如何使用或难以使用的软件，在产品设计上一定是出了问题
-
软件的结构未做良好规划
这里主要指软件是以自顶向下方式开发，还是以自底向上方式开发。如果是以自顶向下的结构或方法开发的软件，在功能的规划及组织上比较完整，相反以自底向上的组合式方法开发处的软件则功能较为分散，容易出现缺陷。
-
提供的功能不充分
-
与软件操作者的互动不良
-
使用性能不佳
此类缺陷通常是由于开发人员采用了错误的解决方案，或使用了不恰当的算法导致的
-
未做好错误处理
-
边界错误
bug的处理流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i9YKd6nu-1606139325890)(F:\resource\TESTING\LittlePTranning\homework\pic\bug的处理.png)]
-
计算错误
-
使用一段时间所产生的错误
-
控制流程的错误
-
在大数据量压力下所产生的错误
-
在不同硬件环境下产生的错误
-
版本控制不良导致的错误
-
软件文档的错误
bug的处理