【软件测试】（测试的执行和BUG管理 发现BUG 产生争执 测试用例设计方法 等价类 边界值 模拟弱网 接口测试 水杯测试 发朋友圈测试 冒泡排序 zip命令测试 测试用例设计公式 黑盒 白盒 灰盒）

---

如何开始第一次测试

1. 充分理解需求
   文档（产品文档+技术文档）
   项目功能问题问产品经理，模块底层如何实现问开发

2. 确定测试计划

3. 执行测试
   BUG开发修复了之后一定要验收

4. 项目上线+维护

测试的执行和BUG管理

开始进行测试：

1. 打开待测试的系统
2. 打开测试管理工具用例模块，开始执行用例
3. 发现bug！进行复现并确认bug的复现步骤
4. 记录bug
5. 沟通bug
6. 验证以前提交的bug
7. 确认本次测试完成
8. 编写测试报告

如何发现更多BUG

1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度
和深度！
2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强
他开发模块的测试广度和深度！
3、多进行逆向思维和发散性的思维
4、不要局限于用例和需求文档
5、尽早介入项目, 不要等到开发的差不多了再介入项目

产生争执怎么办

1、先检查自身，是否bug描述不清楚

2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。

3、BUG定级要有理有据，BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。

4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。

测试用例的设计方法

基于需求设计测试用例是测试设计和开发测试用例的基础，第一步就要分析测试需求，验证需求是否正确、完整、无二义性，并且逻辑自洽。在需求正确的基础上细化测试需求，从测试需求提炼出一个个测试点或者测试项，然后根据每一个测试点进行测试用例的设计；在分析测试需求时，一般分为功能测试需求和非功能测试需求。

功能测试：按照功能模块划分。

非功能测试需求主要涉及性能，安全性，可靠性，兼容性，易维护性和可移植性等。

等价类

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

• 有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能
• 无效等价类：根据需求说明书，不满足需求的集合。

边界值

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

边界值：

1. 上点：边界上的点
2. 内点：边界内的点
3. 离点：边界值附近的一个点（闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点）
   
   

如何模拟弱网

接口如何测试

1. postman工具

2. http方法进行测试
   针对接口的参数进行测试（传参数，不传参数，传入非法参数）参数通过parameter，json传递。

水杯测试用例

微信发朋友圈测试用例

写一个冒泡排序

//冒泡排序
public class Test {
    private static void bubbleSort(int[] arr) {
        for (int i = 0; i < arr.length; i++) {
            for (int j = 1; j < arr.length-i; j++) {
                if (arr[j-1] > arr[j]){
                    int tmp = arr[j - 1];
                    arr[j - 1] = arr[j];
                    arr[j] = tmp;
                }
            }
        }
    }
}

针对这个代码如何测试：

方法参数（参数类型、被给参数、参数传递为空）

异常处理
代码规范
语句覆盖
条件覆盖
语句条件覆盖
判定覆盖

对Linux里zip命令测试

测试用例设计万能公式

功能
物体：这个物体是用来干什么的
软件：软件实现功能

界面

物体：外表，材质，大小，容量
软件：界面，字体颜色，页面布局

易用

操作简单，使用流畅

兼容

物体：物体除了本质的功能，还有没有别的功能
软件：操作系统，设备，浏览器版本

性能

物体：使用寿命
软件：响应时间，吞吐量，并发数

安全

物体：物体材质是否有毒，物体会不会对人体健康造成威胁
软件：sql注入，xss漏洞，输入有毒的脚本

网络

2G~5G，弱网，WiFi

中断

黑盒测试

黑盒测试(Black-box Testing)
黑盒测试就是在完全不考虑程序逻辑和内部结构的情况下，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当的接收输入数据而输出正确的结果，满足规范需求。所以，黑盒测试又称之为数据驱动测试，只注重软件的功能。

黑盒测试的优点：

• 不需要了解程序内部的代码以及实现，不关注软件内部的实现。
• 从用户角度出发设计测试用例，很容易的知道用户会用到哪些功能，会遇到哪些问题，锻炼测试人员的产品思维
• 测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

黑盒测试的缺点是不可能覆盖所有代码。

黑盒测试用到的测试方法有，等价类，边界值，因果图，场景法，错误猜测法等。

白盒测试

白盒测试又称为结构测试或逻辑测试，它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。
白盒测试的测试目的是，通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设立检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。
主要包含六种测试方法：语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖。

灰盒测试

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。

测试金字塔