自动化测试学习Day5-测试执行理论

测试执行

根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致。
执行测试用例主要涉及以下几点：
测试执行的顺序：
先执行功能测试，再执行性能测试(模拟一堆的用户)
一般情况下，按模块执行用例
项目紧急下，按照用例的优先级来执行，优先测试优先级高的
除了执行测试用例，还要进行探索性测试，即发散思维测试

注意事项：
搭建测试环境事项
注意前提条件和特殊说明
测试用例要全部执行（不要偷懒！！！！）
不要忽视如何偶然现象（提交BUG）
加强测试过程记录
详细预期与实际的不一致
提交缺陷时与开发的关系处理
提交一份优秀的问题报告单（定位问题的能力）
及时更新测试用例

搭建环境事项：
测试用例执行过程前，成功搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书。
如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。
注意用例的前提条件和特殊说明
有些测试软件是有顺序性的，那么它的测试用例就会有一些执行前提或特殊说明。
用例要全部执行
因为编写测试用例时，它考虑了测试覆盖率的问题，每条测试用例都对应一个功能点，如果少执行一条，就会有一个功能点没有测试到。

== 不要忽视如何偶然现象==
我们在执行某条用例时，软件会出错，但是当再次执行时这个错误就不再重现。这种情况，一般大家就会认为是偶然现象，就会忽略过去。其实，这种错误才是隐藏最深的，最难发现的错误。

遇到这种情况时，要仔细分析，不要忽视任何小的细节，多测试几次，尽可能准确的找出问题的原因。
加强测试过程记录
执行过的用例做好对应标记，发现了缺陷应及时提交确认。
一般软件产品提供了日志功能，比如有软件运行日志、用户操作日志。如果发现比较复杂难以重现的问题，一定要在测试用例执行后记录相关的日志文件，作为测试过程记录，这样开发人员可以通过这 些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
详细记录预期与实际的不一致
要从多个角度多测试几次，尽量详细的（定位软件出错的原因），最后把详细的输入和实际的输出，以及对问题的描述写到测试报告中。
提交缺陷时与开发的关系处理
测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力
及时更新测试用例
往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；
有些测试用例在具体 的执行过程中根本无法操作，这时候应该删除这部分用例；
若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。
　总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。

软件缺陷

缺陷的定义

软件为实现需求和规格要求的功能
软件出现了需求和规格指明不应该出现的错误
软件实现了需求和规格未提及的功能
软件未实现需求和规格未明确提及但应该实现的内容
软件难以理解，不易使用，运行缓慢，或者最终用户认为不好
总结
BUG的界定标准
1.与需求不符
2.不符合用户习惯

缺陷的原因：

修复缺陷的费用（例）：

缺陷的抗药性

测试进行得越多，新缺陷就越难被发现
因为之前一直使用同样的测试思路，同样的一套测试用例，没有新的突破。
某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发
一般公司会定期交叉测试，轮询一下

BUG的生命周期

当一个缺陷被发现了之后：
1. 测试人员发现bug后，将bug提交到bug管理系统，并指派给对应的研发人员
2. 研发人员会确认bug，如果确定是bug，则修复bug,如果不是bug，则打回给测试
3. 开发人员修复bug后转给测试人员确认
4. 测试人员对修复后的bug进行验证，确认是否正确修复
5. bug验证通过则关闭bug,若验证不通过，则重新激活，指派给研发修改
new（新建）-open（确认）-fixed(修复)-close（关闭）
new（新建）-rejected（拒绝）–close（关闭）
new（新建）-rejected（拒绝）–reopen—fixed（修复）–close
new（新建）-open（确认）-fixed(修复)-reopen（重新打开）-close（关闭）
new（新建）-open（确认）-block（延期遗留）

缺陷的流程

缺失生命周期

缺陷的等级

提交缺陷

一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间已经被完美地修复，转回到你手上进行验证测试这样的一个单子。
要做到这样，你应该提供足够的信息，使得开发人员既能够明确如何重现故障现象，又有足够的信息定位到问题的根源
除了书写良好的重现步骤，你还可以考虑附上打印日志，抓图，网络抓包，等等。

缺陷提报的标准

标题、测试环境、重现步骤、期望结果、实际结果、指派人、严重等级、优先级、相关附件（BUG较复杂时需要附上）

并非所有缺陷都需要修复

有一些原因，使得有些缺陷我们不修复：
1.没有足够的时间
2.不算真正的软件缺陷
3.修复的风险太大

回归测试

1.测试已经修复的内容，即回归BUG
2.再次测试本次版本的需求内容
3.再次测试其它功能的主流程

测试结束的标准

测试是无穷无止的，那么测试结束的标准是什么呢？
1. 所有可执行的用例都要执行完
2. 不能遗留致命和严重BUG
3. 其他遗留的问题经过三方评估，不会影响线上使用（可以遗留到后续的迭代版本再修改）

测试报告

测试报告的主要内容
项目需求
需求变更情况
数据统计
遗留BUG情况
测试风险
测试对象评估
测试结论
主页有免费模板文件
https://download.csdn.net/download/m0_59325089/88578196?spm=1001.2014.3001.5501