数字多媒体测试组WEB测试流程.docVIP

版本测试流程： 参与产品的需求评审 ( 了解开发的进度时间安排 ( 进行需求分析 ( 用例设计 ( 用例评审 ( 测试执行（bug提交，需求变更） ( 生成测试报告 ( 版本发布 ( 发布后外网验证 ( 测试总结 参与需求评审会 需求评审会一般在周五，会有QA，测试，产品，开发，重构，客服的所有相关负责人参与会议。熟悉与会人员角色，在测试或其他工作中有问题可以直接找到相关负责人协商解决问题。 需求评审会议目的： 需求产生的背景，实现需求后要达到什么样的效果 需求设计是否合理，是否考虑周全，如果发现有不合理和不完善的地方要提出来。 是否有灰度部署需求 预计上线时间 了解测试工作量 了解项目的进度时间安排 在每周一小组leader会将每个组员本周的测试任务进行分配，以邮件形式发出。对于新进员工的工作由其导师进行分配。同时开发leader（一般是各个项目的开发PM）也会将开发一周的项目任务以邮件形式知会相关测试人员。 我们需要了解和思考的点： 各个迭代版本需完成的内容是哪些 各个迭代版本的完成时间 第一个版本的提测时间 完成所有需求的版本提测时间 版本上线时间点 了解自己的本周任务，任务分配是否合理，测试任务工作量和优先级。是否有跨周版本测试任务，合理分配测试时间 了解本次测试是否涉及到测试服务器端口和权限的开通，如果有的话请找8000开通端口，找5000开通相关权限。 进行需求分析 需求分析： 在开发提测前可以找产品要需求文档，仔细阅读并熟悉需求，可以让测试人员在测试开始的时候就了解需要测试的功能点。对各需求功能点的逻辑流程进行分析，是否存在需求中未覆盖或未明确的点，对于需求不明确的地方须和产品及开发及时够沟通 分析对各周边接口逻辑是否有影响。 判断是否要进行安全测试， 通常CS模式的客户端测试，一般不涉及安全测试。但如果是BS模式，必须要进行安全测试。安全测试checklist见文档后附录。注意：如果发现存在安全问题，要上报到开发组pm和测试leader处，如果是还未发布，则只罚开发人员，如果是已发布，则罚所有相关人员。 如果有新增和修改cgi，必须在cgi发布到外网前进行cgi安全扫描。在att首页的常用链接里可打开cgi扫描系统。说明：如果构建测试不发布，不用做上线前测试环境CGI漏洞扫描；如果构建测试要发布，必须做上线前测试环境CGI漏洞扫描。即安全扫描（内网）。内存泄漏检查，如果是第二天发布时，可以不必手动执行，关注每天早晨的CGI和内存扫描邮件 判断是否要进行兼容性测试。比如：操作系统（xp，win7），vista一般很少测试；浏览器（Ie6/7/8/9，FF，CHROME,SAFAR,QQ浏览器），TT浏览器已不是必测浏览器；Flash版本；运营环境（电信，网通，教育网）等等。 是否需要对原有功能进行覆盖检查。一般如果没有对原有功能进行修改，则只需要检查checklist即可，如果有原有模块被影响到，则需将原有模块的主要功能用例也过一遍。 是否对号码状态和级别有要求，比如会员，绿钻1-7级等。如果有，在测试前进行准备，可在att平台—测试管理—号码 里进行测试号码特权类别和等级的设置。如果有无法设置的级别状态，跟开发pm沟通看是否可提供一个平台进行更改，如果还有困难，可跟测试leader进行沟通协商解决。 如果是客户端版本，需要对界面进行测试，比如边框的拉伸缩放，位置记忆，用alt+f4或任务管理器直接杀进程等。 针对需求分析后可预估一下所需的测试时间，如果项目总计划中留给测试的时间不够。一定要及早跟pm沟通和协调。 进行用例设计 在ATT平台→→测试管理→→功能用例→→多媒体下选择对应项目和功能模块进行用例的新增和修改。目前本周版本测试用例可以放在本周版本目录中，测试版本发布完成后需要把本周版本中的测试用例移动到对应的项目目录去，同时进行测试用例的归类整理。 用例设计规范 将需求按照功能模块或场景拆分成不同模块目录。同一类用例尽量放在同一目录下 目录命名应简洁易懂，易于分辨用例类别 同一个目录下，目录、用例不能并存 用例目录下分基本功能用例，异常用例，checklist，外部接口关联（如果有）等。 用例名称要简单明了的把用例场景概括出来。 用例描述即用例名称的一个扩展，写清楚此用例所属的功能模块/需求是什么。如何构造场景。 前提条件中写清楚用例所需准备的测试资源/条件（如QQ号、QQ号权限/状态，所属的功能模块/需求联网还是断网等） 步骤和期待结果需一步步详细清晰的写明。期待结果应该是可验证的。如果步骤分1234，则对应的结果也要1234写清楚。要考虑到是否其他人拿到这个用例能根据此描述知道该如何操作。 每个用例的粒度大小尽量保持一致。基本上可根据功能点的大小来拆分。考虑一下各个功能用例执行的复杂度和执行时间