回顾上一篇博客主要内容:软件测试 - 基础篇
1: 软件测试的流程是什么?

需求分析,测试计划,测试设计/测试开发,测试执行,测试报告

需求分析
分析需求,验证需求的正确性和合理性,从需求中提取出测试项

测试计划
要考虑测试人数,测试环境,测试时间,测试设备等

测试设计/测试开发
要根据需求写测试用例

测试执行
到这里开发已经完成;我们要执行测试用例,验证功能是否完善,有BUG就提交BUG,验证BUG

测试评估
写了多少测试用例,执行了多少,剩余的测试用例数有多少,有多少BUG数量,解决的BUG数量,遗留的BUG以及解决方案,测试范围以及测试功能等

2: 如何描述一个 BUG ?

1:发现问题版本
2:测试环境
3:测试数据
4:测试步骤
5:测试实际结果与预期结果
6:附件,错误日志,错误截图等等
7:不要把多个BUG放到一起

3: 因为一个 BUG 和开发人员产生了冲突怎么做?

1: 先检查自身,看 BUG 描述是否清楚
2: 从用户的角度去说服开发人员
3: BUG 定级要依据公司的标准
4: 要不断的提高自己的技术和业务水平,提高自己在团队的影响力
5: 找产品经理一起商量解决办法

4: 在回忆什么是测试用例?

向被测试系统发起的一组集合,包含测试环境,测试步骤,测试数据,预期结果

为什么软件测试人员要写测试用例?
基于需求设计测试用例
具体的设计测试用例的方法
- 1: 等价类
- 2: 边界值
- 3: 错误猜测法
- 4: 场景设计法
- 5: 因果图法
- - 5.1 恒等
  - 5.2 与
  - 5.3 或
  - 5.4 非
  - 5.5 因果图法设计测试用例的步骤
  - - 5.5.1 分析出所有的输入和输出
    - 5.5.2 找出输入和输出之间的组合关系
    - 5.5.3 根据关系画出因果图
    - 5.5.4 根据因果图画出判定表
    - 5.5.5 根据判定表写出测试用例
- 6: 正交法(了解)

为什么软件测试人员要写测试用例?

1: 测试用例是测试执行的依据

2: 测试用例可以复用,在进行回归测试的时候不用重新编写

3: 测试用例可以衡量需求的覆盖率
查看需要测试的需求是否都测了,写下来之后就不会频繁的测试最后可能就会把自己搞晕,对照着测试还是很方便的

4: 后人可以借鉴
我们写的测试用例都是在公司会有备份的,即使你后来不干了,后面来的新人就可以借鉴你写的测试用例

5: 手工测试用例是自动化测试的依据
自动化测试就是把手工测试用例给转换成代码脚本,让其自己测,从而提高效率

基于需求设计测试用例

需求是测试人员进行测试的依据,测试人员分析需求,验证需求的合理性和正确性,无二义性,并且逻辑自洽.从需求当中提取出测试项,根据测试项进行进一步的细分,提取出测试点,编写测试用例…

1: 从界面开始进行测试(符合UI设计稿)(功能性)
这是我们拿到软件的第一眼,看看是否好坏,是否满足需求

2: 验证软件的功能,把业务相关的功能串起来进行测试(功能性)
比如一个淘宝大概的流程:搜索,加入购物车,结算,付钱…看看是否满足需求,要求我们不能针对一个点进行测试,要把他们串起来

3: 一个功能的不同的输入,和相应不同的输出(功能性)
就像我们登录QQ一样,用户名密码正确成功登入是一种情况,用户名或密码错误是一种情况,有一个没写又是一种情况

4: 功能之间的交互性(功能性)
就像注册和登录是两回事,购物车跟收藏夹也是(购物车满了,可以放在收藏夹里),联系客服(买家跟卖家的联系)等等

5: 异常功能的测试(功能性)
就像QQ登录一样,输错了有没有提示信息,都分别提示的什么?

6: 功能用到的算法的验证(功能性)
有一些功能是需要用到算法的,要结合代码,所以需要和开发人员沟通怎样测,然后设计一些数据来进行测试

7: 从易用性,兼容性性能等几个方面去考虑(非功能性)
软件用起来简单还是不好上手,软件安在各种的系统上有没有不兼容的情况,这些都要进行测试

浅浅看一下日历的一些功能

我们在对不同应用的软件对于非功能性的要求是不一样的:
1: 面向客户端的软件,像画图板,office,Word等对性能,安全性要求不高的,但是对于兼容性(必须在不同的系统上都能够使用),可移植性,稳定性要求(频繁使用)较高
2: 面向企业内部的软件,像飞Q,飞书,钉钉等对兼容性要求不高,但是对于功能性要求高,可靠性要求高
3: 大型商用软件,像微信,QQ等对性能,兼容性,可靠性,可移植性,安全性等要求较高(毕竟用户多,而且腾讯也是用他们来赚钱的,懂得都懂,虽然他是免费的,但是我们发现他上面是有很多广告的,只要我们点击了,腾讯就会向广告商收钱,想一想这其中有多少用户…)

具体的设计测试用例的方法

1: 等价类

根据需求输入(特殊情况会考虑输出)划分为若干个等价类,从等价类中选出一个测试用例,如果这个测试用例测试通过,则认为所代表的等价类测试通过,这样就可以用较少的测试用例达到尽量多的功能覆盖,解决了不能穷举的问题
就像我们春夏秋冬的衣服都是分类好的放在一块区域(勤快的人哈…),就可以把它们理解为等价类
在这里插入图片描述

2: 边界值

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

3: 错误猜测法

根据测试人员的经验,知识积累,猜测某一块功能有问题,有针对性的进行测试用例的编写(就像探索性测试,针对性比较强,比较依赖测试人员的个人水平)

例如:

1: 搜索框查询(空格)
在某个搜索框里搜一个名字(王二狗),但是用户在输入的时候前面多输了空格或者后面多输了空格导致并没有查到王二狗,但是数据库确确实实有王二狗,就是因为这个空格导致了数据不匹配所以查不到,我们学Java的都知道,在 String 中有一个方法叫 trim(),他就可以去除字符串前后的空格(当然中间的是不能去掉的,中间的用户是能够发现的,是有意义的)