《软件测试执行全流程.ppt》由会员分享，可在线阅读，更多相关《软件测试执行全流程.ppt（43页珍藏版）》请在三一文库上搜索。
1、测试执行,深 圳 市 门 道 信 息 咨 询 有 限 公 司Shenzhen MT Information Consulting Co . , LTD版权所有.侵权必究,目录,Chapter 1 测试执行,Chapter 2 软件缺陷,Chapter 3 测试报告,Chapter 1 测试执行,1.1 什么是执行测试用例1.2 测试执行过程注意事项,什么是执行测试用例,根据已有的测试用例，按照里面的步骤一步一步的执行，查看预期结果与实际结果是否一致。,测试执行过程注意事项,搭建测试环境事项注意前提条件和特殊说明测试用例要全部执行不要忽视任何偶然现象加强测试过程记录详细预期与实际的不一致提交缺陷
2、时与开发的关系处理提交一份优秀的问题报告单及时更新测试用例,测试执行,搭建测试环境事项 测试用例执行过程前，成功搭建测试环境是第一步。一般来说，软件产品提交测试后，开发人员应该提交一份被测试软件产品的详细安装指导书。 如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招致开发人员的反感，也降低了开发人员对测试人员的认可程度。,测试执行,注意用例的前提条件和特殊说明 有些测试软件是有顺序性的，那么它的测试用例就会有一些执行前提或特殊说明。 比如要测试某个软件的登陆功能
3、，那么测试前必须创建用户，并为用户分配一定的权限等。如果前提条件和特殊说明没有注意，会导致测试用例的无法执行。,测试执行,测试用例要执行全部执行 因为编写测试用例时，它考虑了测试覆盖率的问题，每条测试用例都对应一个功能点，如果少执行一条，就会有一个功能点没有测试到。 我们执行测试前要认为待测试软件的每条功能点都是未实现的，每个功能点我们都要测试一遍，才能保证待测试软件能正确满足用户需求。,测试执行,不要忽视任何偶然现象 我们在执行某条用例时，软件会出错，但是当再次执行时这个错误就不再重现。这种情况，一般大家就会认为是偶然现象，就会忽略过去。其实，这种错误才是隐藏最深的，最难发现的错误。 遇到这
4、种情况时，要仔细分析这种情况，不要忽视任何小的细节，多测试几次，尽可能准确的找出问题的原因。,测试执行,加强测试过程记录 测试执行过程中，一定要加强测试过程记录。执行过的用例做好对应标记，发现了缺陷应及时提交确认。 一般软件产品提供 了日志功能，比如有软件运行日志、用户操作日志。如果发现比较复杂难定位的问题，一定要在测试用例执行后记录相关的日志文件，作为测试过程记录，这样开发人员可以通过这 些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。,测试执行,详细记录预期与实际的不一致 如果不一致，要从多个角度多测试几次，尽量详细的定位软件出错的位置和原因，并测试出因为这个
5、错误会不会导致更严重的错误出现，最后把详细的输入和实际的输出，以及对问题的描述写到测试报告中。 因为在一个项目组中，项目的开发时间是有限的，如果我们测试时能把问题描述的详细一些，那么开发人员就会很容易的重现这个问题，也就能更快的解决问题，节省项目时间。,测试执行,提交缺陷时与开发的关系处理 测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。,测试执行,提交一份优秀的问题报告单 测试提交的问题报告单和测试日报一样，都是测试人员的工作输出，及绩效的集中体现。因此，提交一份优秀的问题报告单是很重 要的。,测试执行,及时更
6、新测试用例 测试执行过程中，应该注意及时更新测试用例： 往往在测试执行过程中，才发现遗漏了一些测试用例，这时候应该及时的补充；有些测试用例在具体 的执行过程中根本无法操作，这时候应该删除这部分用例；若干个冗余的测试用例完全可以由某一个测试用例替代，那么删除冗余的测试用例。 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多本应该更新的测试用例。,Chapter 2 软件缺陷,2.1 缺陷的理论基础2.2 缺陷的生命周期2.3 缺陷的流程2.4 缺陷的状态2.5 缺陷的等级2.6 缺陷实例与练习,缺陷理论基础,2.1.1 缺
7、陷的定义2.1.2 缺陷的原因2.1.3 缺陷的修复成本2.1.4 缺陷的分布特征2.1.5 缺陷的抗药性2.1.6 并非所有缺陷都要修改,缺陷的定义,软件未实现需求和规格要求的功能软件出现了需求和规格指明不该出现的错误软件实现了需求和规格未提及的功能软件未实现需求和规格未明确提及但应该实现的内容软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好。测试用例执行中发现的与预期结果不符的现象 缺陷又名为BUG（臭虫）,缺陷的原因,缺陷的修复成本,缺陷的分布特征,集结（二八定理） 缺陷往往喜欢扎堆，一个模块已经发现的缺陷比别的模块多，通常不是代表这个模块已经把缺陷暴露完了，而是意味着这
8、个模块还存在有同样多的缺陷尚未被发现。这就是著名的二八定理：80%的缺陷出现在 20%的模块。,缺陷的抗药性,测试进行得越多，新缺陷就越难被发现 因为之前一直使用同样的测试思路，同样的一套测试用例，没有新的突破。 某些缺陷天然地只有在很特殊或者很极端的情况下才会被触发,并非所有的缺陷都需要修复,有一些原因，使得有些缺陷我们不修复：没有足够的时间不算真正的软件缺陷修复的风险太大不值得修复,缺陷的生命周期,当一个缺陷被发现了之后： 1. 测试工程师填写缺陷跟踪单，提交测试经理审核 2. 测试经理作出初步判断，将问题单转项目经理审核 3. 项目经理确认问题单,转给开发人员定位问题 4. 开发人员定位
9、错误后修复缺陷转给 项目经理确认 5. 项目经理确认完转给转给测试经理确认并组织测试 6. 测试人员对该修复进行验证，确认是否正确修复，确认是否有引 发 新问题，是否影响了原有正常的功能,缺陷的流程,缺陷生命周期状态,缺陷的等级,附带上所有你认为有价值的信息,一个好的缺陷单，是你提交之后就再也没人联系你，然后过了一段时间已经被完美地修复，转回到你手上进行验证测试这样的一个单子要做到这样，你应该提供足够的信息，使得开发人员既能够明确如何重现故障现象，又有足够的信息定位到问题的根源除了书写良好的重现步骤，你还可以考虑附上打印日志，抓图，网络抓包，等等。,合理地利用各种手段强调关键信息,假如你的缺陷
10、跟踪单支持字体颜色关键词强调特殊标记,例子-excel,例子-bugfree,缺陷的写作练习,1.当运行WORD程序时，如果输入字符SHUTDOWN，会导致程序自动关闭2.QQ运行24小时左右，会占用大量内存，并有一定概率出现程序崩溃3.某网络购物网站的密码修改功能的入口设计不合理，本应该在用户账户管理界面下，但是却跑到系统设置界面下4.某型号手机的方向键设计不合理，想要按“下”方向键时，经常误触到“2”键。5.HH08型号的无线Modem，在每天23:59分到0:00之间，无线网络会断开一分钟无法响应,Chapter 3 测试报告,3.1 测试报告的主要内容3.2 测试结果分析3.3 测试总
11、结,测试报告的主要内容（掌上书院）,3.1.1 数据统计3.1.2 遗留bug情况3.1.3 测试风险3.1.4 测试对象评估3.1.5 测试结论3.2 测试总结,数据统计-人力投入,数据统计-用例覆盖率,数据统计-问题单分类统计,遗留bug情况,测试风险,测试对象评估,测试结论,测试结果分析,测试执行结束后，测试活动还没有结束。测试结果分析是必不可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。 因为通过对问题单的分析、总结不仅能发现不同人提交问题的类别与差异，还能发现自身思维的局限性，避免下轮测试进入自我盲区。,测试总结,回顾整个项目的测试过程，总结个人成长经验，取得了什么成绩、有哪些不足、有什么好的经验或者方法可以和大家分享呢？对工作进行一个理性的分析和思考。,43,多动脑 勤动手 定成功,Thanks&Best wishes for you!,？FAQ？,