一、软件测试的生命周期（重要）

我们在上篇博客中讲到的是，软件开发的生命周期：
需求分析——计划——设计——开发——测试——运行维护

而软件测试的生命周期：
需求分析——测试计划——测试设计/测试开发——测试执行——测试评估

各个阶段的作用：
需求分析：验证需求的正确性、合理性。细化需求，找出测试项、写测试用例。

测试计划：规定好 测试人数、测试环境、测试时间、测试设备。

测试设计/测试开发：根据需求，写测试用例。

测试执行：此时开发已经完成了，就需要执行测试用例，验证它的功能。之后有BUG就把BUG告诉开发人员，并且等到开发人员修好BUG之后就再测试BUG 。

测试评估：写了多少测试用例，执行了多少测试用例。剩余的测试用例数、BUG 的数量、解决BUG 的数量、遗留的BUG以及解决方案、测试范围和测试了什么功能。

二、如何描述一个BUG？（重要）

实际上有BUG 管理工具，它能够以文字的形式帮我们去描述一个BUG 。但是去描述BUG 的什么信息的基础也是要掌握的。

(1)测试版本号(代码版本信息)
测试人员AB 在DEA 上发现一个BUG ，不能实现拼音匹配。
在一条分支上，master是一个线上的分支，而每个小的功能是master其中的一条分支。如：DevA的功能“修改查询功能”是A开发的，A、B进行测试的那么就由它们来负责。该功能没有bug后再合并master。

对于版本号，比如说此时有个修改BUG 的人是G，如果不描述问题的版本号，G就会一个个地去找BUG 的问题所在。因此版本号的作用是方便开发人员去复现BUG问题。

(2)测试环境
web系统：硬件设备信息、电脑品牌、型号、软件设备、操作系统，包括浏览器，浏览器的什么型号和版本号等。

APP：
软件设备：什么系统，如Andriod、IOS
硬件设备：手机品牌、电脑品牌

网络条件：对于弱网、不同的路由器来说，软件功能能否正常地使用。

(3) 测试数据和测试用例，它能更加快速地复现问题。
(4) 测试步骤
(5) 测试实际结果
(6) 测试预期结果
(7) 附件、错误日志、错误截图等

三、BUG级别

不同的公司的BUG 级别不同，此处只做了解。
(1)崩溃：
系统无法正常运行，出现崩溃，操作死锁，死循环，黑屏，阻碍测试人员的工作
(2)严重：
系统运行，但是不稳定，继续运行下去会造成严重的损失，重要的功能没有实现，或者功能和需求不符合，数据库中用户数据存储错误，威胁到用户的安全（信息、财产）。
(3)一般：
次要的功能没有实现，或者有错误，系统可以稳定地运行。
(4)建议：
会影响用户的体验，排版局促、颜色不符合大众审美、信息没有换行、或者提前换行。

四、BUG的生命周期

BUG的各种生存状态：

五、如果因为BUG和开发人员产生冲突？（重要）

(1) 检查：看BUG描述是否清楚
(2) 从用户的角度去说服开发人员去修改。
(3) BUG定级要有理有据(根据公司的规范)
(4) 不断提升自己的业务水平和技术水平(权威)，不但能够发现BUG，并且能够定位，还能够提出解决方案。
(5) 不要争吵，找产品经理讨论，一般都会有三方的会议，测试人员，开发人员，产品经理。就会讨论这个BUG 的最终解决方案。

六、黑盒测试的测试用例的设计方法

1.基于需求的设计方法

需求是测试人员进行测试的依据，测试人员分析需求，验证需求的合理性和正确性、无二义性。从需求当中提取出测试项，根据测试项进行进一步的细分，提取出测试点，编写测试用例。

根据需求设计测试用例分为哪两个方面？功能性和非功能性。
功能性：
(1) 从界面开始进行测试(符合UI设计稿)
(2) 验证软件的功能，把业务相关的功能串起来进行测试。不能光关注某一个孤立的功能
(3) 一个功能的不同的输入，和相应的不同的输出
(4) 功能之间的交互性。如：同一个系统不同角色之间的交互。淘宝中有卖家和买家。
(5) 异常功能的测试
(6) 功能用到的算法的验证
(7) 从易用性，兼容性性能等几个方面去考虑

测试案例：一个日历，此时要测试日历中待办事项的功能。
步骤：

非功能性测试：
非功能性测试就是测试在软件本身有的功能之上做的一些限制。
易用性，兼容性，性能，安全性，可移植性，可靠性，可维护性。

不同应用的软件对于以上非功能的要求不太一样。
(1) 面向客户端的软件，画图板，office，word，xmind，它们对性能、安全性要求不高，但是对于兼容性(必须在不同的系统都可以安装和使用)，可移植性，稳定性(频繁日常的使用)要求较高。
(2) 面向企业内部的软件，如飞Q、飞书，对兼容性，性能要求不高，但是对于功能要求高，可靠性要求高。
(3) 大型商用软件，微信、QQ，对性能，兼容性，可靠性，可移植性，安全性都有要求。

2.等价类

概念：根据输入(特殊情况下才考虑输出)，把输入划分成若干个等价类，从每一个等价类当中选择测试用例进行测试，如果这个测试通过，我们就说这个测试用例代表的等价类测试通过。

案例：对于一个邮箱地址，规定是6~18个字符，可使用字母，数字，下划线，需要以字母开头。
那么测试用例的等价类有：
1.字母开头，数字+字母 (字母区分大小写)
2.字母开头，数字
3.字母开头，数字+下划线
4.字母开头，字母+下划线
5.字母开头，数字+字母+下划线

但是，只测试上面的还不够，上面的称为“有效等价类”，相对地，有“无效等价类”。

有效等价类：符合需求规格说明的数据集合。
无效等价类：不符合需求规格说明的数据集合。

练习：

有效等价类：6~15个大写字符，6到15个小写字符，6到15个大小写字符混合。
无效等价类：小于6个字符，大于15个字符，6到15个数字，6到15个特殊字符(汉字，各种符号)，数字+字母混合，数字+特殊字符混合，特殊字符+字母。

3.边界值

针对输入和输出的边界进行测试用例的设计。如6~15位的用户名，就需要测试5，6，7和14，15，16长度的用户名。即边界值要去边界上的值，和边界左右两边的值。

等价类是和边界值结合在一起进行测试用例的设计。如：无效等价类。

4.错误猜测法

根据测试人员的经验，知识积累，猜测某一块功能有问题，有针对性地进行测试用例的编写。
探索性测试，针对性比较强，比较依赖测试人员的个人水平。适合于测试用例都设计完了，作为一种补充的设计用例的方法。

1.如：搜索查询边框——空格。假设在查询词中的前后两边有空格时，实现不了关键词的搜索。因此要用trim方法去实现前后两边空格的去除，再进行搜索，而查询词中包含空格就不用去除。

2.搜索查询出的信息500条。
则有个小问题，每一页展示100条，展示5页。但是发现不同的页面上有相同的数据，数据ID 也一样，这是什么原因？
答：可能是没有对查询到的数据进行排序，导致每一页的数据都是随机展示的。

5.场景法

很多软件不同的场景，是基于不同事件的触发，不同事件的触发，导致场景走向不同的事件流。
不同的功能串起来形成一个场景，不同的功能又有不同的输出，不同的输出导致有不同的测试场景。

如ATM取款机：

因此可以根据不同的场景，写出不同的测试用例。

6.因果图法

因果图是一种逻辑图，恒等，与，或，非，用因果图来设计测试用例，叫做因果图法。
使用场景：当我们有很多输入，不同的输入或者不同输入组合针对有不同的输出，这个时候可以用因果图法来进行测试用例的设计。

因果图：

因果图法设计测试用例的步骤：
1.分析出所有的输入和输出
2.找出输入和输出之间的关系
3.根据关系画出因果图
4.根据因果图画出判定表
5.根据判定表写出测试用例

练习：618活动，订单已提交的前提下，金额大于300或有红包，就有优惠。
1.分析所有的输入和输出
输入：
订单已提交、订单未提交、金额大于300、金额小于等于300、有红包、无红包。
输出：
有优惠、无优惠。

2.输入和输出之间的组合关系：

3.根据关系画出因果图

4.根据因果图画出判定表 和 5.根据判定表写出测试用例。

7.正交法(了解)

根据正交法来设计测试用例，从大量的试验数据(测试)中根据正交原则取出最优的数据组合，根据最优的数据组合试验的结果，来分析整个测试的结果。