测试过程常用思维技巧分享-2016

1、测试过程常用思维技巧分享测试过程常用思维技巧分享测试过程常用思维技巧分享提纲提纲收到收到版本版本后主要要做哪些后主要要做哪些2多人版本测试，相互多人版本测试，相互配合配合的的原则原则3布署版本时，最容易布署版本时，最容易出现出现的问题的问题4高效准备测试数据高效准备测试数据5迭加需求版本，测试策略迭加需求版本，测试策略6有效利用等版本时间有效利用等版本时间1等待版本中可做的事情等待版本中可做的事情一般，版本与版本之间时间回归时间较长，会安排其它的工作开展；在版本临时推迟时（比如晚一个小时、两个小时）这样的情况下，可以提前进行如下一些碎片化的工作；1、BUG单的查阅统计已经FIXED的BUG个数

2、；查看reject或CancelBUG单，避免错误处理遗留到下一轮2、补充必要的用例可仅针对逻辑性较强的功能；减少用例统计/用例总体补充时的工作量。3、提前进行回归测试所需要的数据制作。4、备份上一轮版本；收到收到版本版本后主要要做哪些后主要要做哪些事情检查打包文件检查打包文件检查打包的文件是否齐全（文档、执行文件、源码-源码正确性）检查版本号是否正确检查升级说明、修改说明是否正确（是否与本次需求一致）。测试环境确认（常用于新项目或版本运行环境变更）部署版本进行测试。两个方面两个方面版本测试版本测试冒烟测试1.新增功能浏览（确认是否有功能遗漏）；2.主流程简单测试（确认本次提交的功能及相关功能

3、是否能正常使用）正常版本测试回归版本，确认本轮需回归的BUG总数、是否存在有争议被异常处理掉的BUG单（接口人）多人版本测试，相互配合的原则多人版本测试，相互配合的原则功能之间的联系紧密程度（联系紧密的功能通常安排同1个人测试）测试数据互相不受影响功能交织在一起的复杂测试，可按逻辑前后顺序来安排测试工作，但要明确测试开始点及结束点（数据值、页面流程等）明确自身的测试范围（需求、功能、测试开始点及结束点）有功能、数据影响时，应及时通知相关测试人员发现日志、控制台异常，应及时通知相关测试人员因功能缺陷可能影响到其他人测试的模块功能时，应及时通知相关测试人员，并说明可能影响到的原因有功能、数据交互影

4、响的测试时，应与对方配合进行测试。2文档问题部署人员应详细查看文档（升级、配置、版本号），在动手实际部署前应思考这么部署是否正确再进行部署，且应严格按照升级说明和配置说明进行部署。另外应注意升级文档的措词，比如替换和覆盖。有歧义，不清楚的地方应及时询问开发再进行部署。4部署环境部署版本不要用ROOT文件夹；部署版本后应清理tomcat的work文件夹及临时文件夹。布署版本时，最容易出现的问题布署版本时，最容易出现的问题1版本备份无论是补丁版本还是完整版本部署前都应做原版本备份，补丁版本升级比较容易忽视这个问题。3迭加功能对于在测试过程中有迭加功能的补丁版本，部署时应在原版本（主版本）的基础上进

5、行升级，不要在前一个轮测试版本上升级。5项目部署对于新项目，版本提交前就应准备好部署环境（web容器、数据库等）布署完成之后，不能一看启动无问题就认为布署OK了，或出现一些错误日志忽略掉；正确的做法：是要观察好日志是否有异常，且首次访问数据库是否正常、模块之间互联是否正确后，再开始正式的测试。对比对比找文档找文档重新设计重新设计结果无对比结果无对比已有文档已有文档稍作修改稍作修改可对比结果可对比结果测试数据的记录测试数据的记录养成记录测试数据的习惯，尤其是一些常用的、重用性比较高的测试数据，比如接口类测试报文、安全性测试规范数据、数据生成脚本、常用测试数据（用户名、手机号码）等。高效准备测试数

6、据高效准备测试数据旧新对比对比匆忙匆忙设计设计容易遗漏容易遗漏效率低效率低时间充足时间充足逐步完善逐步完善效率高效率高测试数据的记录测试数据的记录在提交版本前，针对本次版本功能提前准备测试数据，比如电商高级会员自动续订功能如有修改（表结构并未修改），那么可在提交版本前准备测试数据，但要注意备份原表。对比对比匆忙匆忙设计设计容易漏测容易漏测效率低效率低时间充足时间充足覆盖完善覆盖完善效率高效率高用例设计阶段用例设计阶段版本提交前，在用例设计阶段就详细的写出用到的测试数据，比如一个复杂的流程测试需要填写那些数据、复杂的统计需要那些脚本等涉及到流程性测试时，尽可能同时至少走2条数据来进行测试；以更好

7、的复现和确定问题。迭加需求版本，测试策略迭加需求版本，测试策略对迭加的新需求要有充分的了解，包括其设计方法，因为只有你了解了这些，才可能想到其对旧功能的影响范围。了解新功能测试过程测试部署建议先测试新功能，再回归bug；对于耦合性很高的新功能，还要全面测试功能相关的旧功能。对于开发来说，新功能更容易出bug，及早发现新bug，开发也会有更多的时间去改正。刚前面已经说到过，要用依赖的主版本（最初的版本）来部署。bug内容编写内容编写新新BUGBUG编写时，测试人员需保证此编写时，测试人员需保证此BUGBUG单的唯一性、独立性以及完整性。以达单的唯一性、独立性以及完整性。以达到到BUGBUG单的效

8、率最大化，减少无效单的效率最大化，减少无效BUGBUG单的出现，以及减少开发人员对单的出现，以及减少开发人员对BUGBUG单的误单的误解。解。bug内容填写规范1. SummarySummary中，填写BUG的概要信息，包括：1) 所属大模块所属大模块，如：前台/交易管理：2) 问题简要说明问题简要说明，如：交易密码修改出现异常。Summary完整内容则为：前台/交易管理：交易密码修改出现异常。2. Description中，需详细说明本BUG所属的操作步骤及重现条件，如涉及数据表值更新及日志、图片，都需要附上。新新BUGBUG编写时，测试人员需保证此编写时，测试人员需保证此BUGBUG单的唯

9、一性、独立性以及完整性。以达单的唯一性、独立性以及完整性。以达到到BUGBUG单的效率最大化，减少无效单的效率最大化，减少无效BUGBUG单的出现，以及减少开发人员对单的出现，以及减少开发人员对BUGBUG单的误单的误解。解。1) 例一（附图或日志型）：前台/交易管理：进入交易密码修改页面，系统出现脚本错误，错误图见附件所示。2) 例二（数据库型）：后台/撤牌审核：撤牌审核通过或不通过后，未及时更新T_PROJECT_RELEASE_BASE表中的撤牌状态，造成前台/我发布的项目中，项目操作栏一直显示为“撤牌审核中”。3) 例三（步骤型）：前台/挂牌申请：选择股权进行挂牌申请，按照界面操作引导

10、下一步至添加版权项目其他信息页面后，再点击上一步，系统转到文化产品添加页面了（正常是不应该转到此页面的）4）) 例四（解释补充型）：后台/商品管理：修改商品保存后，竞价模式修改为其它了；造成商品同步到竞价平台异常；（前台进行商品修改不存在本问题）bug内容编写内容编写有争议问题单共享有争议问题单共享语意不清孤芳自赏漫天过海原bug：mcp/我的莞惠，我的等级，页面显示位置不对，如图开发：死活找不到关键词：浏览器更改为：mcp/我的莞惠，我的等级，页面显示位置不对，如图（ie7） 12新手问答新手问答1态度2过程3期望1.测试人员是否需要用争吵来坚持自己的意见凡事只要开始吵，结果基本上就会输了；但在测试过程中，观点不一的争议必然存在；要想坚持自己的意见，改变别人的想法，更好的形式是摆观点，找论据，拉站队；同时一定要留下自己的BUG证据。这样的方式更OK点2.一个功能（版本）测试到啥程度算结束 按理说功能和版本应该测试到你认为用例已全面覆盖，基本已测试不出bug来为止，但实际上由于时间关系，部分版本达不到这种程度，这就需要你对版本功能做权衡，找出测试的优先级，通常大的流程、页面操作等方面功能是必须保证能正常使用的，异常则可做选择性测试。3.减少漏测和提高效率的问题 对于这个