软件测试---基础篇

软件测试—基础篇

在此之前，关于软件测试的相关概念软件测试之概念篇了解一下

软件测试的生命周期

在不同的开发阶段，测试人员应该做什么：

• 需求阶段：分析需求，得到测试需求
• 计划阶段：根据需求编写测试计划
• 设计阶段：搭建测试用例的框架
• 编码阶段：完善、细化测试用例的同时也是对需求的测试
• 测试阶段：按照测试用例执行，执行率达100%，可按优先级分先后执行，但最终全都要执行。自由测试，探索测试。编写测试报告时要对缺陷进行分析。缺陷分析的目的：1. 定位问题 2.对类似缺陷有一定参考
• 运行维护：参与项目的实施，在试运行阶段收集bug并反馈

如何描述bug

团队精神
合格的bug描述应包括以下几部分：

• 发现问题的版本
• 问题出现的环境：浏览器版本，客户机操作系统等
• 错误出现的步骤：描述问题重现的最短步骤
• 预期行为的描述：描述期望结果，用户需求，最好写上需求来源。
• 错误行为的描述：描述错误现象，日志或截图
• 不要将多个bug混杂在一起：不同代码段产生的bug最好不要一块提交，难以定位
• 其他：故障分类，如功能故障，界面故障，兼容性故障；还有优先级分类等。

标准的bug描述如下图：

定义bug的级别

各个公司对bug的定义不太一样，
- Blocker（崩溃）：主要功能丧失，基本模块缺失等。如系统崩溃，数据库缺失等问题，这种较少见，一旦出现立即中止测试。
- Cirtical（严重）：功能与需求严重不符，一级功能菜单缺失但不影响其他功能测试，在不影响其他功能测试的情况下可以继续进行测试
- Major（一般）：功能未完全实现但不影响使用
- Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案。

bug的生命周期

从new到closed的所有状态
不同公司，不同工具对bug生命周期的定义不太相同
以下为bug状态转换图：

七种状态：
- new：新发现的bug，决定是否交给开发人员去修改
- open：确认是bug，并认定要修改，分配给特定的开发人员修改
- fixed：开发人员修改后标记成修改状态，等测试并进行人员进行回归测试
- rejected：若认为不是bug，则拒绝修改
- delay：无关紧要的bug延迟修改
- closed：修改状态的bug在测试人员回归测试验证通过之后，关闭该bug
- reopen：经验证bug未修复，要重新打开，开发人员重新修改

如何开始第一次测试

与测试组长确认工作内容：
测试计划？测试内容？测试案例多少？安排几天执行？

测试的执行和bug管理

测试执行过程：

• 打开待测系统
• 执行测试用例
• 发现bug（复现并记录复现步骤）
• 记录bug
• 沟通bug
• 验证以前提交的bug
• 完成测试
• 撰写测试报告

如何发现更多的bug：

• 软件测试存在二八原则，80%的故障存在20%的模块，对问题出现多的模块，加强测试深度和广度
• 开发人员也存在二八原则，80%的bug由20%的开发人员产出，加强容易出bug的开发人员开发模块的测试深度和广度
• 多进行逆向思维和开发性思维
• 不局限于测试用例和需求文档
• 早早介入项目，提前了解项目的开发流程和核心思想

处理人际关系

完成一个项目时，开发人员与测试人员难免产生冲突，具体产生冲突的原因可能有：对一个bug的判定、bug级别的确定、立即修改还是延迟修改等，这些问题都有可能使开发和测试人员之间发生争执。
遇到争执不要怕，记住批判性思维：清楚–准确、切题–深刻，有意义，有逻辑性–公正、全面。

当发生争执时，作为一个测试人员，首先要做好以下几点：

• 先检查自己是否将bug描述清楚
• 站在用户角度思考，这样的bug会不会对用户造成影响，有没有完全满足用户需求
• bug的定级要有根有据，最好站在用户角度上考虑定位级别
• 最关键的还是要提升自身技能和业务水平，在提出bug的同时，还要提出解决bug的思路
• 避免与开发人员争吵

接下来进一步学习软件测试之用例篇