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

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

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

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

要根据需求写测试用例

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

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

2: 如何描述一个 BUG p>

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

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

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

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

向被测试系统发起的一组集合,包含

• 为什么软件测试人员要写测试用例li>
• 基于需求设计测试用例
• 具体的设计测试用例的方法
• • 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: 正交法(了解)

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

查看需要测试的需求是否都测了,写下来之后就不会频繁的测试最后可能就会把自己搞晕,对照着测试还是很方便的

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

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

基于需求设计测试用例

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

这是我们拿到软件的第一眼,看看是否好坏,是否满足需求

比如一个淘宝大概的流程:搜索,加入购物车,结算,付钱…看看是否满足需求,要求我们不能针对一个点进行测试,要把他们串起来

就像我们登录QQ一样,用户名密码正确成功登入是一种情况,用户名或密码错误是一种情况,有一个没写又是一种情况

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

就像QQ登录一样,输错了有没有提示信息,都分别提示的什么p>

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

软件用起来简单还是不好上手,软件安在各种的系统上有没有不兼容的情况,这些都要进行测试

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

2: 边界值

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

4: 场景设计法

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

ATM取款机场景流程:

针对每一个点都存在一些事件:

1. 插错了卡(公交卡,饭卡,会员卡…非银行卡)
2. 银行卡的磁条无法识别
3. 卡损坏
4. 卡 冻结,账户锁死
5. 络不好,无法识别卡
6. 停电吞卡
   …

1. 输入正确的密码
2. 输入错误的密码
3. 不输入密码,直接点击确认
4. 密码输入错误超过三次,账户锁定
5. 密码第一次输入错误,第二次或第三次输入正确
6. 测试密码是否加密
7. 是否支持不同字符的输入
   …

1. 输入小于卡余额的钱数
2. 输入等于卡余额的钱数
3. 输入大于卡余额的钱数
4. 输入非整百的钱数
5. 不输入直接点击取钱按钮(这时取钱按钮是灰色的)
   …

1. 输入小于等于卡余额的钱数时,取款成功
2. 输入大于银行卡余额的钱数,取款失败,并提示”余额不足”
3. 超过每日取款余额的上限
4. 超过每日取款次数的上限
   …

1. 取钱后正常退卡
2. 操作超时,吞卡
   …

1. ATM 一切正常
2. ATM 余额不足
3. ATM 断 ,断电,硬件故障 软件系统崩溃
4. 发生异常情况 ATM 是否支持事务回滚
   …

虽然我们能够写出这么多的事件,但是他不算一个测试用例的,这里我们只是把每个场景可能设计到的情况写了下来.测试用例他是应该带有测试效果的:

1: 插错银行卡,系统提示”无法识别”
2: 卡消磁后,并将其插入 ATM 中,ATM 提示”无效卡,请检测你的银行卡是否有效!”

场景设计法就是根据场景中会可能发生的事件进行设计测试用例…

5: 因果图法

是一种逻辑图,用因果图来设计测试用例,叫做因果图法.

当我们有很多输入,不同的输入或者不同的输入组合针对有不同的输出,这个时候我们可以用因果图法来进行测试用例的设计.

5.1 恒等

输入为真,输出也为真

5.3 或

多个输入中其中一个为真,输出为真.

5.5 因果图法设计测试用例的步骤

分析出所有的输入和输出

找出输入和输出之间的组合关系

根据关系画出因果图

根据因果图画出判定表

根据判定表写出测试用例

我们根据 618 的活动,订单已提交且金额大于 300 ,有优惠,或者 有红包也有优惠:

5.5.1 分析出所有的输入和输出

订单已提交,金额大于 300,有红包 ; 订单未提交,金额小于等于 300,没有红包

有优惠,无优惠

5.5.2 找出输入和输出之间的组合关系

订单已提交,金额大于 300,有红包 有优惠

订单未提交,金额小于等于 300,有红包 有优惠

订单已提交,金额大于 300,没有红包 有优惠

订单已提交,金额小于等于 300,没有红包 没有优惠

订单未提交,金额大于 300,有红包 没有优惠

订单未提交,金额小于等于 300,有红包 没有优惠

订单未提交,金额大于 300,没有红包 没有优惠

订单未提交,金额小于等于 300,没有红包 没有优惠

5.5.3 根据关系画出因果图

5.5.5 根据判定表写出测试用例

根据判定表的每一列都是一个测试用例:

订单已提交,金额大于300,有红包 有优惠

订单已提交,金额大于300,没有红包 有优惠

订单已提交,金额小于等于300,有红包 有优惠

订单已提交,金额小于等于300,没有红包 没有优惠

订单未提交,金额大于300,有红包 没有优惠

订单未提交,金额大于300,没有红包 没有优惠

订单未提交,金额小于等于300,有红包 没有优惠

订单未提交,金额小于等于300,没有红包 没有优惠

6: 正交法(了解)

知道有这个方法就行.

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

正交法的目的就是为了减少用例数目,用尽量少的用例覆盖输入的两两组合.