数字多媒体测试组WEB测试流程.docx
《数字多媒体测试组WEB测试流程.docx》由会员分享，可在线阅读，更多相关《数字多媒体测试组WEB测试流程.docx（24页珍藏版）》请在冰豆网上搜索。
数字多媒体测试组WEB测试流程
1.版本测试流程：
参与产品的需求评审→了解开发的进度时间安排→进行需求分析→用例设计→用例评审→测试执行（bug提交，需求变更）→生成测试报告→版本发布→发布后外网验证→测试总结
1.1.参与需求评审会
需求评审会一般在周五，会有QA，测试，产品，开发，重构，客服的所有相关负责人参与会议。
熟悉与会人员角色，在测试或其他工作中有问题可以直接找到相关负责人协商解决问题。
1.1.1.需求评审会议目的：
Ø需求产生的背景，实现需求后要达到什么样的效果
Ø需求设计是否合理，是否考虑周全，如果发现有不合理和不完善的地方要提出来。
Ø是否有灰度部署需求
Ø预计上线时间
Ø了解测试工作量
Ø了解项目的进度时间安排
在每周一小组leader会将每个组员本周的测试任务进行分配，以邮件形式发出。
对于新进员工的工作由其导师进行分配。
同时开发leader（一般是各个项目的开发PM）也会将开发一周的项目任务以邮件形式知会相关测试人员。
1.1.2.我们需要了解和思考的点：
Ø各个迭代版本需完成的内容是哪些
Ø各个迭代版本的完成时间
Ø第一个版本的提测时间
Ø完成所有需求的版本提测时间
Ø版本上线时间点
Ø了解自己的本周任务，任务分配是否合理，测试任务工作量和优先级。
是否有跨周版本测试任务，合理分配测试时间
Ø了解本次测试是否涉及到测试服务器端口和权限的开通，如果有的话请找8000开通端口，找5000开通相关权限。
1.2.进行需求分析
1.2.1.需求分析：
Ø在开发提测前可以找产品要需求文档，仔细阅读并熟悉需求，可以让测试人员在测试开始的时候就了解需要测试的功能点。
对各需求功能点的逻辑流程进行分析，是否存在需求中未覆盖或未明确的点，对于需求不明确的地方须和产品及开发及时够沟通
Ø分析对各周边接口逻辑是否有影响。
Ø判断是否要进行安全测试，通常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沟通和协调。
1.3.进行用例设计
在ATT平台→→测试管理→→功能用例→→多媒体下选择对应项目和功能模块进行用例的新增和修改。
目前本周版本测试用例可以放在本周版本目录中，测试版本发布完成后需要把本周版本中的测试用例移动到对应的项目目录去，同时进行测试用例的归类整理。
1.3.1.用例设计规范
Ø将需求按照功能模块或场景拆分成不同模块目录。
同一类用例尽量放在同一目录下
Ø目录命名应简洁易懂，易于分辨用例类别
Ø同一个目录下，目录、用例不能并存
Ø用例目录下分基本功能用例，异常用例，checklist，外部接口关联（如果有）等。
Ø用例名称要简单明了的把用例场景概括出来。
Ø用例描述即用例名称的一个扩展，写清楚此用例所属的功能模块/需求是什么。
如何构造场景。
Ø前提条件中写清楚用例所需准备的测试资源/条件（如QQ号、QQ号权限/状态，所属的功能模块/需求联网还是断网等）
Ø步骤和期待结果需一步步详细清晰的写明。
期待结果应该是可验证的。
如果步骤分1234，则对应的结果也要1234写清楚。
要考虑到是否其他人拿到这个用例能根据此描述知道该如何操作。
Ø每个用例的粒度大小尽量保持一致。
基本上可根据功能点的大小来拆分。
考虑一下各个功能用例执行的复杂度和执行时间。
较复杂的逻辑尽量拆分成多个小用例。
一个测试用例面向一个测试点，不要将许多测试点揉在一起
Ø描述清晰、包括特定的场合、对象和术语，没有含糊的概念和一般性的描述。
描述对象的名称尽量和产品需求书上保持一致。
不要用个人习惯来命名。
Ø避免重复，冗余的测试用例
Ø有充分的异常情况测试，增加异常测试用例
ØUI上的文字引用用<>符号标注起来
Ø使用各种测试方法，比如边界值法，流程图法等，尽可能的覆盖所有逻辑分支，最大可能的避免造成测试遗漏。
Ø各功能模块的checklist需在功能有变化时随时进行更新。
1.4.测试用例评审
Ø测试人员需在测试开始前完成测试用例的编写，并在ATT上对新增的用例发起评审流程。
步骤：
ATT→测试管理→用例评审
Ø评审必选人员：
开发，关注人员：
产品，组内交叉测试同学，eddieliu，开发PM，meryzhou
Ø标题开头先用【用例评审】版本号：
标明。
Ø请提醒相关人员及时进行评审。
每个必选人员必须进行反馈，即使是没有意见。
对于不在座位上或者有事情不能参与评审的人员需在统计时说明原因
Ø根据评审意见及时修改和更新测试用例。
1.5.测试执行
1.5.1.测试前
1.5.1.1.转测条件检查
Ø由产品提出需求的项目都必须先由产品体验通过后测试才能开始测试。
所以开发在发提测邮件前，测试应该能够收到开发提给产品经理的产品体验邮件。
产品体验邮件的标题通常以【产品体验申请】开头，且产品体验完后应回复邮件指出开发是否正确的实现了产品的需求，有问题的地方产品经理必须在回复体验邮件时明确写明在体验邮件的体验结果一栏中，方便测试人员在测试时重点关注。
Ø提测邮件标题检查。
体验通过后，开发会发提测邮件，测试人员收到提测邮件后需要检查提测邮件是否符合规定，符合后才能转入测试流程，否则要求开发修改提测邮件后重新提测。
这里邮件标题一般都以【特性提测申请】、【日常测试申请】、【版本提交测试】、【紧急版本提交测试】等开头。
Ø提测邮件内容检查
1）测试前确认开发提测邮件模版是否正确。
2）里面对应的host是否齐全，对应的提测内容和给出的tapd需求单是否一致。
3）是否有cgi的新增修改，对于新增的cgi测试人员需要手动修改web服务器配置文件（config.xml）,添加新cgi的路径和配置参数到配置文件。
1.5.2.测试中
发布到测试环境的ars单是否提供，是否缺少ars单。
在同步ars单时要注意同步的文件路径是否在web服务器根目录下（/htdocs），是否与/htdocs目录下其他文件冲突，会不会覆盖其它业务的配置同名文件。
如果需要直接发布到/htdocs目录下，必须拉开发，eddie确认影响访问，参见问题实例：
E:
\08音乐测试小组文档\2011新人指引\WEB测试流程及规范\【重要】请关注ARS单中生产同步目标地址字段的值，以评估影响范围.msg
1）注意查看开发写的版本或日常是否影响自动化用例，如果是，要修改自动化用例并多次执行（一般是跑通20次）。
新增cgi修改webserver如下：
172.25.32.105（）>/usr/local/services/qzhttp-6.0/conf/>viconfig.xml,在该文件中找到
将新增cgi添加到该配置中，如
如果需要修改其中参数可以找自己业务对应的开发人员协助。
保存退出后，重启qz。
usr/local/services/qzhttp-6.0/admin/,执行命令qz_restart。
重启完成后访问该cgi查看配置是否生效。
如果cgi需要配置l5进行负载均衡的话，需要确认服务器能否正常分发客户端的请求到后端的几台server。
修改L5配置具体操作请参考邮件（如果没有可以找导师或其他同事询问）,在svn上路径为音乐测试小组文档/2011新人指引/WEB测试流程及规范/转发【小节】105测试机修改L5配置以连接mqzone测试环境的步骤.msg
Ø同步ars单到测试环境，确认页面那边的单没有漏提。
如果在测试环境发现页面出现异常，首先看是不是ars单漏掉了css样式文件。
另外，因8000的安全策略，如果在测试过程中出现异常问题，首先检查一下浏览器—工具—Internet选项—连接---局域网设置—使用自动配置脚本是否被勾上，如果勾上了请去掉后清除cache再重新测试。
Ø测试需求要求开发写得清楚详细。
如果有不清楚的需求，一定要主动和开发进行沟通确认。
需求的情况可在每周周报的需求质量评分中体现出来。
Ø需求变更不可避免，要确认需求变更是否及时周知所有相关人员，是否及时更新需求文档到tapd上，要会判断变更的需求的原因是因为之前的需求考虑不充分还是因为第三方的要求。
如果是前者，要在周报需求变更评分中体现出来。
原则上，发布前最后一个版本不能再接受需求变更，如果要进行需求变更，需要各环节负责人确认同意进行变更后才允许进行修改。
Ø测试过程中有进度延迟或其它困难要及时反馈给团队，让产品、开发和测试leader及时了解进度。
长线版本最好能每周单独发一封测试小结的邮件对本周测试进度，问题进行总结。
Ø测试中出现的问题要及时与开发产品进行反馈，确定问题的原因。
测试BUG在bugtrace中提交，提交bug需清晰描述操作步骤。
尽量带上截图辅助说明，较复杂的操作还可以带上录像。
Bug的描述不能有二义性，要清楚明了。
（bug严重级别见附录1）
Ø开发会对测试人员在bug单中的描述进行评分，测试也要对开发的bug处理意见评分
Ø处理完的bug单会通过rtx消息进行提醒。
测试人员要及时回归和处理这些单。
回归通过的要及时关单。
Ø注意安全检查，敏感字和脏话过滤等
Ø测试完当前版本的需求后要在测试环境跑一遍相关可能影响到的功能的cgi和cgi自动化用例，以保证不会有未检查到的相关功能受到影响，同时也能保证新修改的cgi不会影响到已经上监控的cig。
Ø测试通过标准：
致命、严重bug必须全部解决；一般、提示的问题解决率要达到85%以上，未解决的bug需要leader检查并同意挂起后才能发布
Ø对于有输入的地方比如发表评论，要进行安全检查如XSS漏洞检查。
对于上传的操作比如上传文件需要到后台进行验证，能否对上传的视频进行安全检查好过滤。
涉及到cgi的，要进行cgi内存扫描
Ø涉及到cgi发布的，必须在发布前多次运行自动化用例，确保用例运行成功；同时还要对cgi进行内存泄漏扫描。
扫描具体操作请参考邮件（如果没有可以找导师或其他同事询问），svn上存放路径为音乐测试小组文档/2011新人指引/WEB测试流程及规范/【请关注】CGI内存泄漏扫描工具已支持实时扫描.msg
Ø测试前可以通过ars系统发出的js和css文件对比邮件（目前ars系统还无法比对cgi文件），先了解下这次改动的代码，然后评估测试范围。
1.6.测试报告
Ø测试完成后由测试人员通过ATT平台功能子计划出具测试报告
Ø测试报告邮件标题中版本号后面最好加上主要特性描述
Ø测试报告中对测试了的浏览器、操作系统需要正确填写，必测的需要写上，没有测的不能列在上面，保证信息的真实性
Ø因客观原因未能覆盖测试的内容可能引起的问题要在测试结论中写清楚
Ø测试不通过的要写清楚不通过的原因
Ø测试报告邮件需要抄送的人，可参考提测邮件的收件人。
具体规定如下：
1）收件人：
该版本下所有特性涉及的设计、产品、开发，测试同学----具体名单需你根据实际情况手工输入，否则对方收不到邮件，转体验也是如此。
抄送人：
g_DMPC_Testgroup（多媒体转测邮件组）---à这里系统配置，不用改
2）客户端开发组如还有习惯用手工写邮件转测的开发同学，请务必按上面的格式配置邮件接收人再发送。
Ø测试中遇到的困难和问题也可在测试报告总反馈
Ø对于暂时无法进行外网验证的（比如页面是有自动同步程序在次天凌晨进行同步的），在出测试报告时，需要选择“外网验证通过但仍须关注”。
1.7.发布评审
Ø在测试报告发去后，由开发同事拉群评审，在评审群中都需要拉上开发PM、DE、产品、OQA（余建波）、客服（宋佳琪）、运维（视频：
林娟娟，音乐：
肖世广），必须拉上eddieliu和meryzhou；必须参加且需要同意的人员有：
OQA（余建波），客服（宋佳琪），运维（林娟娟或肖世广）。
Ø发布群包括：
PM，DE，产品，OQA（余建波）,客服（jackysong），运维（视频/P2P：
林娟娟，音乐/P2P：
肖世广）,测试：
刘海锋，研发QA：
周春喜。
Ø若是在测试过程遗留了bug未解决，在发布群里贴出该版本未关闭的Bug单列表，评审同学如对挂起的单有异议需在发布群里提出来，否则默认pass。
Ø如果有遗留Bug，在发布前单独拉开发，pm，开发leader,产品确认是否Bug单可以挂起（这个推荐在测试群里做）；原则是版本发布时，所有的单应该是关闭或是延期解决状态，不允许有其它状态。
Ø如果有“严重”或“致命”的bug单，则不允许发布。
Ø在RTX里再与客服人员确定一次文档有没有知会到他们。
1.8.执行发布
Ø预发布
当发布评审通过后，就可以进入到预发布阶段；把ARS单发布到预发布环境，首先在ARS平台内提交预发布，再预发布部署，这样预发布就执行完了，然后配预发布的host验证相应的功能。
若是CGI发布则没有预发布环境，因此直接灰度到外网某台服务器进行验证则可。
Ø发布
当预发布验证通过后，就可以执行发布了；在ARS平台内同步ARS单，然后再执行发布。
一般外网生效要10—15分钟左右，发布到外网等10分钟左右就可以进行验证。
外网验证通过后，再发外网报告中。
若是CGI发布则需要确定是否进行灰度发布，灰度发布则要先灰度到一台机器上（灰度到哪一台开发会告诉），等待验证通过后，再全量发布到外网；灰度时，可以提醒开发去观察服务器的日志是否有异常。
Ø发布段注意事项
1）执行发布过程中若是出现文件冲突的情况，则需要问相冲突单的测试人员，他的单是否有发布，如果发布了，请他结单；若是没有发布则需要拉开发人员确定两个单会不会互相影响，若是不会互相影响，则可以继续发布。
2）在执行发布过程中若是遇到发布失败或是某几台机器发布失败，把失败的服务器ip帖给开发看，如果能迅速确定问题并解决问题，则重新发布；若是时间太长解决不了问题，则回滚ARS单。
在做这些操作前请跟开发和pm先进行确认。
3）在发布过程中要注意配置文件发到外网的服务器的路径映射是否正常，看影响路径是不是你所在业务的外网正确路径，若不是则要慎重发布，同时要开发及运维同事确认外网的部署路径是否正确，避免发到外网后影响其它相关的业务。
4）另外还要注意，若是新增的CGI发布，则需要制作CGI自动化用例，并且在CGI自动化用例上线前进行安全扫描；如果是js，html,css，则要提醒开发要进行混淆，而文件压缩是由运营统一配置webserver来自动实现的；你要关注图片是否过大，flash是否过大，图片的格式是否要进行优化为png。
4.发布的时间限制
正常版本测试周一至周四可以正常发布
日常测试周一至周五可以正常发布
周五09：
00-12：
00
周五或是其它节假日发布版本要走总监审批流程，日常版本周五下午两点也需要走总监审批流程。
紧急测试、内测、运营测试及日常同步在任意时间点都可以进行发布；若是下班后发布版本则需要给出原因。
发布时间规定
版本类型
周一至周四
（9：
00—19：
00）
周一至周四
（19：
00—次日9：
00）
周五（9：
00—12：
00）
周五（12：
00后）
周末及法定节假日
普通版本发布
√
√
×
×
×
配置文件
√
√
√
×
×
日常版本发布
√
√
√
×
×
紧急发布
√
√
√
√
√
包发布
√
×
×
×
×
其他
√
√
√
×
×
（1）非允许时段的普通版本发布，紧急版本发布，日常版本发布，需要开发总监审批（zhangqing，vincentlan），如果版本功能很大，则需要需要升级至运营部GM（nofeeling）和业务GM来审批
（2）非允许时段的包发布需要升级至dowsontong，nofeeling审批，只要其中一位评审人员审批通过即可。
1.9.外网验证
Ø测试项目发布到外网后及时验证外网；在外网验证时遇到问题需及时反馈便于相关人员定位解决问题
Ø验证通过后需回复邮件，验证不通过请赶紧联系开发查看并及时处理；在邮件中需要说明发布时所遇到问题比如发布耗时等其他问题
Ø任何版本，任何时段发布后，PM和开发责任人必须留守1小时，如涉及产品体验变化，对应产品经理也必须留守1小时。
待留守1小时后仍无异常，方可离开；主要观察外网CGI是否有告警，服务器压力是否过正常，是否有漏测。
Ø如果在外网出现问题需要回滚ars单，则在执行回滚执行后需查看回滚日志查看回滚操作是否成功，同是需要在外网下载该文件查看外网回滚是否成功
1.10.测试总结
Ø大项目测试完成后主动进行总结
Ø总结的点可以有：
需求阶段、开发质量、开发效率、测试质量、测试效率、遇到的困难、如何解决、发布后的效果、性能、用户反馈、投诉等等方面
Ø在测试完成后需要整理该项目相关文档，js、css文件，cgi文档主要包括cgi名称、参数定义、返回码定义、使用场景
1.11.监控
ØATT自动化用例（CGI）上监控
1）新项目上线前最好能做好自动化监控用例,如果时间来不及，也可上线后来做。
编写自动化用例指导手册地址：
E:
\08音乐测试小组文档\2011新人指引\部门常用系统\平台ATT3.1使用指南【自动化】.doc。
上线监控的自动化用例在用例前会以绿色小勾显示，如下图。
与开发leader沟通cgi自动化用例上监控的时间点，但是控用例上线最晚不能超过CGI上线后一周的时间。
2）任何CGI上线监控之前必须确定运行通过20次以上，上线监控要走上线电子流，在ATT平台内，具体操作如下：
att平台→自动化管理→上线电子流→（如果没有看到可以联系klzhao帮忙加上）→编辑并配置计划，运行完成并提交即可，若是CGI用例下线则需要发出邮件通知，邮件发给klZhao（赵昆仑）及相关的开发。
具体的上线和下线流程，请参考：
3）在CGI用例上线监控后，第二天需要到OZ平台（）查看监控数据确定用例确实已监控起来并确定没有问题。
4）在CGI用例监控后，在外网出现告警的时候，如果是自己负责业务的cgi告警，在收到告警时第一时间要拉开发、运维同事，定位问题查明告警原因，在查明原因后须在告警邮件中回复告警原因和处理措施。
如果告警不是由于CGI用例自身导致的，则不允许下线CGI自动化用例。
5）修改CGI用例时，若是时间间隔太长，可以RTX通知klZhao暂时屏蔽掉告警用例的监控，以免影响到CGI用例正常的监控，用例修改后一定要通知klZhao更新监控用例。
6）在cgi上监控后，需要在运维平台上订阅告警信息，地址为oz.isd.Com，更多>统一告警系统>告警订阅，选择自己负责的业务选择订阅，告警通知方式中手机、rtx和邮件建议全部选择综这样在出现告警时及时处理。
Ø在收到告告警后，分析步骤如下
1）在0Z上查看CGI告警的错误信息，判断是否是自动化用例导致
2）如果不是用例自身的问题，尝试手工运行自动化用例，看能否成功
3）如果不是用例自身的问题，在OZ上查看cgi所在server的机器负载情况，关注cpu，网络，mem
4）如果上面的都比较正常，开发会检查cgi的日志（也会结合模掉的数据来定位），确认和后台server的连接是否正常。
（比如后端一个s++机器的负载太大，cpu在凌晨4点时接近100%，导致请求无法相应，报错）
2.紧急测试
1）在“哀悼日”等特殊时期，需要停止网站功能时，需要提前联系KL停止掉CGI的监控，否则会引发大量的CGI告警
3.日常测试：
Ø日常测试完成后直接回复日常测试提测邮件即可，在邮件中写明测试内容，测试结果。
邮件标题格式为：
【测试结果反馈--日常测试+日常版本号】
Ø日常测试通过后，发布同样需要拉评审，评审通过后执行发布，其他与版本测试一样。
日常版本不强制要求拉评审，目前视频业务是会拉评审，音乐没有拉，保持现状即可。
Ø原则上有cgi修改的都不能走日常。
涉及重要流程特别是支付流程更改不能走日常。
涉及逻辑较复杂的东西可跟开发沟通改走版本。
4.号段扩容测试：
Ø提前收到即通号段扩容放出通知
Ø跟各项目负责人确定多媒体组各模块是否都支持即将放出的号段
Ø接到即通提供的测试号码
Ø根据各项目功能模块由各项目测试负责人进行测试
Ø汇总并反馈测试结果，测试结果反馈需注明所测业务功能点，说明测试不通过的原因最好有截图
Ø注意多媒体组有新功能、新模块、号段扩容测试推出的时候，需要用最新的号段进行测试检查，同时需要在ATT上运行CGI自动化用例调用扩容测试号码来进行测试
5.其它
5.1.测试工具负责人
1）在使用ars系统发现问题，可以找kikochen；att平台有问题可以找fayewang；上报安全漏洞联系tedli协助
附录1—Bug严重级别定义
附录2--安全测试CheckList说明
安全规范编号
检查点
说明
4.1.3
MT代码必须正确，必须符合公司要求。
该项由专人测试（曹艳负责）。
检查点和标准参见：
VSS\测试用例库\checklist\手机业务CheckList.xls
4.1.4
单条扣费的信息必须记录完整，能够完全重现用户操作，至少包含如下关键信息：
时间、支付流水号、用户编号（QQ号码、手机号码等）、支付方式、支付金额、支付号码（支付的Vnet帐号、QQ号码、手机号码等）、用户操作IP、前端服务器IP、购买物品信息。
详细要求参见《互联网计费系统设计要求》。
进行单条扣费操作后，要求开发人员提供日志中的相应记录，检查是否包含了所有关键信息，信息是否正确。
4.2.1
不允许没有校验用户登录状态就能执行用户请求的操作，暴露用户信息。
对于用户隐私数据显示，如手机号码、身份证号码，应该采取部分信息用*替代等方式，建议方式为后4位采用*。
用户自愿显示手机号码的地方除外，如群社区个人名片页面。
4.2.5
对
升级会员 