Bug篇和用例篇

软件测试的生命周期

需求阶段、计划阶段、设计阶段、编码阶段、测试阶段、运行维护

Bug篇

如何创建一个Bug

创建Bug的要素：发现问题的版本、问题出现的环境、错误重现的步骤、预期结果、实际结果

bug的级别：崩溃、严重、一般、次要

Bug的生命周期

测试人员在执行测试的过程中，如有发现Bug，需要在对应的Bug管理平台来创建Bug

New:测试人员创建了一个Bug

Open：开发人员要去确认是否是Bug，是Bug状态就改为Open，不是Bug就拒绝（Rejected）

Fixed：开发人员在修复完成之后将Bug改为Fixed

Rejected：如果认为不是Bug，则拒绝修改

Delay：确认是Bug之后，如果Bug优先级比较低且开发人员不能立即修复Bug，状态改为Delay

Closed：Bug确认修复完成，测试人员将Bug改为Closed

Reopen：Bug确认修复未完成，测试人员将Bug状态改为Reopen

用例篇

测试用例的原则

用例的设计不仅要考虑其实现了其应该实现的，还要考虑其未实现其不应该实现的

测试用例的要素

为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素

测试用例的设计方法

基于需求进行测试用例的设计

万能公式：功能测试+性能测试+界面测试+兼容性测试+易用性测试+安全测试

功能测试

可能来自于需求文档，也有可能来自生活经验

性能测试

功能没有问题不一定代表性能是好的，性能往往代表极端情况下

界面测试

颜色、形状、大小、材质、文字、输入框、图片、下拉框......所有可以看到的元素

兼容性测试

浏览器的兼容性、系统兼容性、版本兼容性、数据兼容性

易用性测试

软件是否具备简单易上手的属性

安全测试

密码是否加密、数据库是否对隐私数据加密、SQL注入

测试用例的具体设计方法

等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽可能多的功能覆盖，解决了不能穷举测试的问题

划分

步骤

1. 确认有效等价类和无效等价类

2. 编写测试用例

边界值

边界值分析法就是对输入和输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界

边界值指的是有效边界和无效边界

判定表

使用场景

输入条件的组合对应不同的结果

步骤

1. 确认输入条件和输出条件

2. 找出输入条件和输出条件之间的关系

3. 画判定表

4. 根据判定表编写测试用例

场景设计法

目前几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一件事情不同的触发顺序和处理结果就形成了事件流

正交法

正交试验设计法是指从大量的实验中挑选出适量的、有代表性的点，依据“正交表”从而合理的设计出测试用例

步骤

1. 找出因素和水平

2. 生成正交表

3. 根据正交表来编写测试用例

4. 补充可能存在遗漏但是非常重要的测试用例

方法

使用allparis生成正交表下载链接

特性

1. 每一列中，不同的数字出现的次数相等

2. 任意两列中数字的排列方式齐全而且均衡

案例

1. 将水平和因素写入Excel

2. allparis同级目录创建一个新的txt文件（a.txt），复制Excel中的因素和水平，粘贴到a.txt文中，直接保存，不做任何的操作

3. 使用allparis工具生成正交表

4. 生成的正交表

错误猜测法

是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对性的设计测试用例的方法

缺点

难以系统化，并且过度依赖个人能力

测试分类

可靠性测试

可靠性即可用性，是指系统正常运行的能力或者程度，一般用正常向用户提供软件服务的时间占总时间的百分比表示

可靠性=正常运行时间/（正常运行时间+非正常运行时间）*100%

容错性测试

容错性测试是指系统能够处理异常，用户的错误操作而不至于系统崩溃，从而能够提高系统的可用性

安装卸载测试

工作中很容易遗漏安装和卸载的测试

内存泄漏测试

检测方法

人工静态法：人工检查

自动工具法：借助工具进行代码静态扫描

弱网测试

安卓手机如果一直刷不到内容，可能会出现anr弹窗，如果有时间网不太好可能会造成客户端频繁的去发送请求

黑盒测试

主要在系统测试阶段，是纯功能测试，是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当地接收输入数据而输出正确的结果，满足规范需求

优点

不需要了解程序内部的代码以及实现；从用户角度出发设计测试用例，很容易知道用户用到哪些功能；测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能

缺点

不可能覆盖所有代码

白盒测试

主要在单元测试阶段，主要关注程序的内部实现，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致

灰盒测试

主要在集成测试阶段，介于黑盒和白盒之间

为什么不能让灰盒测试取代黑盒测试和白盒测试？
灰盒测试没有白盒测试那么详尽，灰盒测试没有黑盒测试覆盖产品的广度大。

冒烟测试

开发人员完成开发任务之后，交给测试人员进行测试的第一步，评估软件/系统是否具备可测试的条件

回归测试