测试过程常用思维分享-2016分析.pptVIP

测试过程常用思维技巧分享 测试过程常用思维技巧分享 提纲 收到版本后主要要做哪些 2 多人版本测试，相互配合的原则 3 布署版本时，最容易出现的问题 4 高效准备测试数据 5 迭加需求版本，测试策略 6 有效利用等版本时间 1 等待版本中可做的事情 一般，版本与版本之间时间回归时间较长，会安排其它的工作开展；在版本临时推迟时（比如晚一个小时、两个小时）这样的情况下，可以提前进行如下一些碎片化的工作； 1、BUG单的查阅—统计已经FIXED的BUG个数；查看reject或CancelBUG单，避免错误处理遗留到下一轮 2、补充必要的用例—可仅针对逻辑性较强的功能；减少用例统计/用例总体补充时的工作量。 3、提前进行回归测试所需要的数据制作。 4、备份上一轮版本； 收到版本后主要要做哪些事情 检查打包文件 检查打包的文件是否齐全（文档、执行文件、源码-源码正确性） 检查版本号是否正确 检查升级说明、修改说明是否正确（是否与本次需求一致）。 测试环境确认（常用于新项目或版本运行环境变更） 部署版本进行测试。 两个方面 版本测试 冒烟测试 1.新增功能浏览（确认是否有功能遗漏）； 2.主流程简单测试（确认本次提交的功能及相关功能是否能正常使用） 正常版本测试 回归版本，确认本轮需回归的BUG总数、是否存在有争议被异常处理掉的BUG单（接口人） 多人版本测试，相互配合的原则 版本功 能分工 功能之间的联系紧密程度（联系紧密的功能通常安排同1个人测试） 测试数据互相不受影响 功能交织在一起的复杂测试，可按逻辑前后顺序来安排测试工作，但要明确测试开始点及结束点（数据值、页面流程等） 版本测 试过程 明确自身的测试范围（需求、功能、测试开始点及结束点） 有功能、数据影响时，应及时通知相关测试人员 发现日志、控制台异常，应及时通知相关测试人员 因功能缺陷可能影响到其他人测试的模块功能时，应及时通知相关测试人员，并说明可能影响到的原因 有功能、数据交互影响的测试时，应与对方配合进行测试。 2 文档问题 部署人员应详细查看文档（升级、配置、版本号），在动手实际部署前应思考这么部署是否正确再进行部署，且应严格按照升级说明和配置说明进行部署。 另外应注意升级文档的措词，比如替换和覆盖。有歧义，不清楚的地方应及时询问开发再进行部署。 4 部署环境 部署版本不要用ROOT文件夹；部署版本后应清理tomcat的work文件夹及临时文件夹。 布署版本时，最容易出现的问题 1 版本备份 无论是补丁版本还是完整版本部署前都应做原版本备份，补丁版本升级比较容易忽视这个问题。 3 迭加功能 对于在测试过程中有迭加功能的补丁版本，部署时应在原版本（主版本）的基础上进行升级，不要在前一个轮测试版本上升级。 5 项目部署 对于新项目，版本提交前就应准备好部署环境（web容器、数据库等） 布署完成之后，不能一看启动无问题就认为布署OK了，或出现一些错误日志忽略掉；正确的做法：是要观察好日志是否有异常，且首次访问数据库是否正常、模块之间互联是否正确后，再开始正式的测试。 对比 找文档 重新设计 结果无对比 已有文档 稍作修改 可对比结果 测试数据的记录 养成记录测试数据的习惯，尤其是一些常用的、重用性比较高的测试数据，比如接口类测试报文、安全性测试规范数据、数据生成脚本、常用测试数据（用户名、手机号码）等。 高效准备测试数据 旧 新 对比 匆忙设计 容易遗漏 效率低 时间充足 逐步完善 效率高 测试数据的记录 在提交版本前，针对本次版本功能提前准备测试数据，比如电商高级会员自动续订功能如有修改（表结构并未修改），那么可在提交版本前准备测试数据，但要注意备份原表。 对比 匆忙设计 容易漏测 效率低 时间充足 覆盖完善 效率高 用例设计阶段 版本提交前，在用例设计阶段就详细的写出用到的测试数据，比如一个复杂的流程测试需要填写那些数据、复杂的统计需要那些脚本等 涉及到流程性测试时，尽可能同时至少走2条数据来进行测试；以更好的复现和确定问题。 迭加需求版本，测试策略 对迭加的新需求要有充分的了解，包括其设计方法，因为只有你了解了这些，才可能想到其对旧功能的影响范围。 了解新 功能 测试过程 测试部署 建议先测试新功能，再回归bug；对于耦合性很高的新功能，还要全面测试功能相关的旧功能。对于开发来说，新功能更容易出bug，及早发现新bug，开发也会有更多的时间去改正。。 刚前面已经说到过，要用依赖的主版本（最初的版本）来部署。 bug内容编写 新BUG编写时，测试人员需保证此BUG单的唯一性、独立性以及完整性。以达到BUG单的效率最大化，减少无效BUG单的出现，以及减少开发人员对BUG单的误解。 bug内容填写规范 1. Summary中，填写BUG的概要信息，包括： 1)