速成测试接口达人测试流程.ppt

速成测试接口达人_测试流程的讲座,研发部讲师介绍： 姓名：方杰 部门：研发_业务保障部 2010年11月9日,通过此次培训我能知道什么,与测试负责人沟通时，那些测试术语是什么含义？,测试开始前我需要做什么？,如何申请测试资源？如何在jira中提交测试任务单？,测试过程中哪些工作是我们测试接口人需要关注的事宜？,什么叫测试结束？测试结束后我们会从测试人员那里得到哪些数据？,测试结束后，还需要测试接口人做什么事情？,目录,测试术语的定义,提交测试的相关流程,测试过程中测试接口人的相关管理之15大职能,不同分工的人员如何处理缺陷,缺陷产生原因定义及处理,重开缺陷的定义,缺陷等级的定义,线上遗漏缺陷表的填写方法,测试项目管理案例分析,培训总结,测试术语的定义,测试项目类型的定义 什么是冒烟测试 什么是回归测试 什么是主功能测试 什么是兼容性测试 什么是安全性测试 什么是线上跟踪测试 什么是常规测试、非常规测试,测试术语的定义,测试项目类型的定义,B/S（Web）功能测试,B/S（Browser/Server）结构即浏览器和服务器结构，B/S结构功能测试特指用黑盒的方法对Browser访问的页面实现的功能及兼容性进行的测试,C/S（Client）功能测试,C/S（Client/Server）结构即客户机和服务器结构，C/S结构功能测试特指用黑盒的方法对客户端实现的功能及兼容性进行的测试,测试术语的定义,测试项目类型的定义,接口功能测试 特指脱离页面呈现，脱离页面调用是否正确，直接测试接口功能的一种测试类型，测试的重点是要检查数据的交换，传递的正确性。通常包括测试接口的参数检查、接口的参数传入及接口返回值是否正确，各接口间逻辑调用是否可以实现应用层功能 提交接口测试的重要意义：实现开发期并行测试，减少页面层测试的深度，缩短整个项目的测试周期。目前的接口测试除API类均已使用自动化测试的方式执行 4. 服务器功能测试 特指为前端客户端或页面提供后台服务的服务器功能的测试，测试重点是要检查服务器与前端或后端DB数据交换及传递是否正确，服务器异常处理，主、从服务器间切换，丢包率等,测试术语的定义,测试项目类型的定义,验收测试 a、 B/S结构验收测试 同B/S功能测试类似，只是测试范围只是针对验收规格说明书进行主功能测试，不涉及功能详细测试及兼容性测试范畴 b、 C/S结构验收测试 同C/S功能测试类似，只是测试范围只是针对验收规格说明书进行主功能测试，不涉及功能详细测试及兼容性测试范畴 c、手机客户端验收测试 同C/S功能测试类似，只是测试范围只是针对验收规格说明书进行手机客户端主功能测试，不涉及功能详细测试及兼容性测试范畴，通常只在Symbian的一个主流操作系统上进行主功能测试,测试术语的定义,测试项目类型的定义,性能测试 分为负载测试、压力测试、并发测试、疲劳强度测试4种测试类型 负载测试 定义：指通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量 目标：确定系统处理能力的极限 压力测试 定义：指通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么压力条件下系统性能处于失效状态，由此获得系统能够提供的最大服务级别 目标：发现在什么条件下应用系统的性能会变得不可接受,测试术语的定义,性能测试的相关定义,并发测试 定义：并发测试指测试多个用户同时访问同一个应用、同一个模块或者操作数据记录时的性能 目标：考察系统在多用户访问时的性能状况 疲劳强度测试 定义：疲劳强度测试是指在保证总业务量的情况下长时间运行系统的测试。属可靠性测试范畴 目标：通过综合分析交易执行指标和监控资源指标来测试系统长时间无故障稳定运行的能力,测试术语的定义,什么是主功能测试,什么是冒烟测试,什么是回归测试,使用较短的时间，对提交测试的产品进行测试，确认产品的基本功能正常，可以进行后续的正式测试工作。这种测试强调功能的覆盖率，而不对功能处理细节的正确性进行验证,在软件测试周期中，如果代码改变就需要进行回归测试，回归测试分为两类，一个是对已修正缺陷的回归测试，一个是主功能的回归测试，是一种再确认的重复测试工作,特指针对产品需求说明书上描述的所有新增、变更功能和产品未变更功能的基本验证，不做深入测试,测试术语的定义,什么是线上跟踪测试,什么是兼容性测试,什么是安全性测试,B/S兼容性测试 验证多浏览器下的页面功能是否正常，通常页面的CSS、JS、flash版本会影响到页面的兼容性 C/S兼容性测试 验证多操作系统下客户端软件功能是否正常,特指为产品进行安全方面的测试，例如是否暴露用户个人私密信息、是否有被盗号的可能、是否会被黑客利用破坏用户利益，是否有损坏DB及服务的不安全漏洞,特指产品经过测试并上线后，在线上环境进行的主功能测试,测试术语的定义,什么是常规测试,什么是非常规测试,进行3轮测试，第1轮、第2轮进行全部测试用例的遍历和已修正缺陷的回归，并在第2轮测试完成时进行兼容性测试，第3轮进行所有已修正缺陷的回归测试及主功能测试 此测试方案对于项目质量来讲最有保障，是测试团队建议使用的一种测试方案,进行少于3轮或多于3轮的测试 此测试方案适用于上线时间紧迫、线上测试类项目、测试过程版本出现重大问题需要增加测试轮次提高产品质量的项目,测试的相关流程,项目立项阶段 项目测试开始阶段 项目测试准备阶段 测试执行阶段 测试完成阶段,测试的相关流程,项目立项阶段,测试的相关流程,项目测试开始阶段,测试的相关流程,项目测试准备阶段,测试的相关流程,测试执行阶段,测试的相关流程,测试完成阶段,测试过程中测试接口人的 相关管理之15大职能,提前申请测试资源，发送项目立项邮件 在jira中提交测试任务单 参与需求评审会，并按照会议内容补充需求 参与测试计划及用例评审 得到冒烟测试用例后，督促产品部涉及测试职能的员工及时完成冒烟测试工作（目前此职能为产品部特有职能） 测试过程中需求变更后及时更新需求并上传到SVN，邮件通知开发、测试负责人需求变更 测试接口人及时分配缺陷给相应的开发处理缺陷，对于延迟及放弃处理的缺陷及时注释延迟和放弃的原因并修改缺陷处理的状态,测试过程中测试接口人的 相关管理之15大职能,督促并检查开发工程师在解决缺陷时，是否在jira中正确标注了缺陷产生原因（如果选择其他原因，请在其他原因下方的注释框中添加缺陷造成的具体原因，如果有可选原因，应尽量避免选择其他） 测试过程中，关注每日的测试日报及风险预警，测试阶段启动邮件，确认开发修改缺陷完成点，及时与测试负责人沟通测试进度，协助测试负责人把控项目测试进度 测试过程中督促产品部涉及测试职能的工程师按期完成非测试部门完成的测试任务 测试各阶段完成时，与测试负责人一起参与Bug评审会议，严格控制延迟和放弃缺陷的比例，共同提高被测产品质量,测试过程中测试接口人的 相关管理之15大职能,根据测试报告，分析项目风险，提出规避风险的解决方案，并确认产品是否上线 如果项目进行了安全测试，请将安全测试报告及时反馈给开发负责人，确认是否修改 如果项目进行上线跟踪测试，请在上线前将欲上线时间点邮件发给测试负责人，并在上线完成时立刻电话通知测试负责人及时进行线上跟踪测试 项目完成后请收集测试遗漏缺陷，并统计到遗漏缺陷记录表中,测试过程中测试接口人的 相关管理之15大职能,如何在jira中建立测试任务单 提交方式：请在jira中如下地址提交测试项目申请 类别 : 研发-质量保证 项目 : 研发-质保-提交测试任务库 (TOTEST) /browse/TOTEST 实际操作演练 如何提交B/S测试 如何提交C/S测试,不同分工人员如何处理缺陷,不同分工的测试接口人如何处理缺陷,开发人员 a、将分配给自己的缺陷进行修正，处理缺陷为已修正状态 b、将建议延迟或放弃处理的缺陷分配给项目负责人确认是否同意延迟或放弃处理，本人不能更改Bug为延迟或放弃 c、将全部分配给自己的缺陷在jira中选择缺陷产生原因 产品人员、项目负责人、项目经理 a、将测试人员提交的欲修改的缺陷分配给对应的开发人员并注释修改的方案 b、将确认延迟或放弃的缺陷及时解决为延期或放弃，并注释延迟或放弃处理的原因。解决延迟处理的缺陷时请务必选择本项目直接延迟处理或本项目间接延迟处理 c、检查项目中所有的缺陷是否均已经选择了缺陷产生的原因，如果没有选择请分配给开发重新选择 备注：除测试人员外，其他不能自行关闭缺陷,缺陷产生原因定义及处理,缺陷产生原因的一级分类 缺陷产生原因的二级分类 在jira中进行缺陷产生原因的选择方法,缺陷产生原因定义及处理,缺陷产生原因的一级分类,环境：如测试环境不稳定：特指上传新版本时没有更新修改过的文件或者测试过程中有人动了测试环境的代码；需要提交测试的文件未更新完整 需求：如需求变更未及时通知开发及测试 代码错误：如代码循环错误 兼容性类错误：如对IE8浏览器未做处理 程序实现间接类错误：如外部门提供的接口或其它服务不稳定 其他原因（选择此项时，请在其他原因下方的注释框中填写具体原因，如果可以选择到对应的原因，应避免选择其他原因）,缺陷产生原因的二级分类 详见项目名称缺陷造成的原因分析表.xlsx,缺陷产生原因定义及处理,在jira中进行缺陷产生原因的选择方法 进入本项目缺陷库 选择本项目缺陷库中未解决缺陷 修改缺陷状态为延迟、放弃或已修正状态时，选择缺陷产生原因（not a bug的无需选择，其他状态均需选择缺陷产生原因） 选择缺陷产生的原因时，请务必选择一级分类和二级分类，切不可只选择一级分类、不选择二级分类,缺陷产生原因定义及处理,在jira中进行缺陷产生原因实践,重开缺陷的定义,重开缺陷的定义 重开缺陷的原因 Jira中重开缺陷的标识 重开率的计算公式 重开缺陷关注点,重开缺陷的定义,什么是重开缺陷? 重开缺陷：指开发修正并在jira中置为已修正的缺陷经过测试人员验证，发现仍有问题则将该缺陷重开,什么状态的缺陷可能会被重开？ 已解决-已修正缺陷：指经过开发修正并在jira中将相应状态置为已修正的缺陷 已关闭-已修正缺陷：指开发修正并在jira中置为已修正的缺陷经过测试人员验证，确认无误后将该缺陷关闭,重开缺陷的定义,重开缺陷的原因 A：缺陷未修改，问题仍然存在 该类重开缺陷产生可能原因：缺陷未修改，开发将缺陷置成已修正，经过验证，此问题被重开 B：缺陷描述未理解，修改不全面 该类重开缺陷产生可能原因：1）开发人员对于测试人员的缺陷描述未理解；2）对于描述的缺陷，只修正部分；3）一个功能有多个入口，开发只修改其中一个入口 C：缺陷已修改，但未按照原始需求实现 该类重开缺陷产生可能原因：1）开发未按照原始需求进行修改缺陷；2）需求已经变更但是测试人员不知，导致缺陷重开；3）需求已经变更但是开发人员不知，导致缺陷重开,重开缺陷的定义,重开缺陷的原因 D：缺陷状态标识错误 该类重开缺陷产生可能原因：缺陷本应置为放弃或延迟处理，但是开发人员误操作将其置为已修正，导致缺陷重开 说明：目前对于该类缺陷未计入重开缺陷中。 E：环境更新错误 该类重开缺陷产生可能原因：部署版本错误或新版本未部署上,重开缺陷的定义,Jira中重开缺陷的标识 重开缺陷标识 测试人员在回归测试中，对于要重开的缺陷，会增加如下注释：$reopenN-开发工程师邮箱前缀-tM(N为该bug在该轮回归测试中被重开的次数，M代表第几轮测试，如t2:代表第二轮) 例如：$reopen1-fangjie-t3 含义：方杰修正的缺陷在第3轮中被重开了一次 关闭缺陷标识 测试人员在回归测试中，对于验证无误的缺陷，会增加如下注释： $reviewN-开发工程师邮箱前缀-tM(N为该bug在该轮回归测试中被验证的次数，M代表第几轮测试，如t1:代表第一轮) 例如：$review3-fangjie-t1 含义：方杰修正的缺陷在第1轮中被验证了3次 请回答： $reopen2-fangjie-t2是什么含义？,重开缺陷的定义,重开率的计算公式 开发工程师重开率 个人被重开Bug总数/个人被验证Bug总数 每轮重开率 本轮重开缺陷/本轮验证的总缺陷数 项目重开率 所有测试轮次中总的重开缺陷/总验证缺陷数 产品线重开率 所有项目中总的重开缺陷数/所有项目总验证缺陷数,重开缺陷的定义,重开缺陷的关注点 以下缺陷，不会计入重开缺陷内 执行了重开操作但是未加注释$reopenN-开发工程师邮箱前缀-tN的缺陷，不计入重开缺陷内 在验证缺陷A时，发现存在由于修改该缺陷引发的新缺陷，此时会关闭A缺陷，新增缺陷B，不会出现重开缺陷A的情况 关注： 对于出现争议的重开记录，需开发提交给测试主管审核，确认后再加重开标识，这一点要求开发工程师及项目负责人及时关注项目中加有$reopenN-开发工程师邮箱前缀-tN的缺陷 兼容性缺陷，必须在缺陷中标注浏览器版本，开发需按照标注的浏览器版本有针对性的修改，如果测试工程师又在其他浏览器中出现相同问题，会新建提案，不会在原已经修改正确的提案中重开,缺陷等级的定义,按照测试类型分类 B/S结构(Web)测试的缺陷等级定义 C/S结构(Client)测试的缺陷等级定义 服务器及接口测试的缺陷等级定义 缺陷等级分类 A、致命 B、严重 C、较严重 D、一般性问题主要为：界面类、容错类缺陷 E、易用性和建议类缺陷 备注：具体内容详见所有类型测试的缺陷等级定义.docx,线上遗漏缺陷表的填写方法,线上遗漏缺陷表： 遗漏缺陷记录表.xlsx 填写完整后请发送给给产品线责任测试主管,测试项目管理案例分析,一个产品人员的困惑： 10月初期领导安排了一个项目，周期一个月的时间，从11月1日开始到12月1日上线。接到任务后，终于完成了需求文档的编写，提交到开发那里，被告知需求编写不详细，经过了多次会议的沟通，开发工程师们终于明白了要做成什么样子，询问什么时候可以开发完成，被告知11月26日。我的工作终于可以告一段落了，开始等待开发完成的时间点26日 26日，开发提交了可测试的版本，我给测试主管打电话，被告知没有测试资源安排，需要等到12月1日，郁闷与领导沟通后，终于项目可以拖延一周的时间，于是找到测试主管，告知这个好消息，产品可以12月8日上线，测试主管却反馈说一周的时间无法完成测试，测试用例的编写时间需要3个工作日，测试执行一轮需要2个工作日，如果按照常规的项目来执行，则需要3+2+0.5+3+0.5+1=10个工作日延期开始,测试项目管理案例分析,12月1日，测试人员通知我参与需求评审会议，会议上发现确实有些地方设计的不够全面，于是虚心接受，更改了需求，并提交给了测试部门，测试部门得到需求后开始编写用例，终于用了3个工作日编写完成，但完成时间点却是12月6日下班前，而不是12月3日下班前，困惑中，为什么会拖延了1个工作日？ 因为上线时间紧迫，测试部门发给我和开发编写完成的测试用例后，通知我们用邮件的方式反馈用例评审结果。为了节约时间，测试部门直接进入了测试执行阶段，问题出现了，冒烟测试没有通过真是雪上加霜，测试刚刚开始就收到了风险预警邮件测试被迫暂停 为了争取测试快速启动，开发说需要1.5个工作日完成缺陷修复，我苦口婆心的与开发沟通，压缩成0.5个工作日完成影响测试执行的缺陷修复，并及时通知了测试方。测试方在0.5个工作日后反馈给我，告知缺陷未被修改完成，无法进入测试为什么受伤的总是我,测试项目管理案例分析,开发又花费了1个工作日的时间修改缺陷，这次冒烟测试终于通过了，但是在执行过程中，太多缺陷被开发建议放弃处理，问询原因：你的需求变更了，为什么测试还按照原始需求进行测试？报告了很多缺陷？无奈下，我一一过缺陷，把因为需求变更的缺陷均修改为放弃处理，并通知测试，这部分有需求变更，测试人员反馈，需要把最新需求发给他们，以便他们更正测试用例，更正测试用例的时间需要0.5个工作日可是我根本没有时间给你们啊，老板也不给我时间啊持续郁闷。测试过程中发现了需求评审中补充的那部分需求均没有实现？困惑中这到底是个什么局面？ 延期再延期测试进度一拖再拖，风险预警一封接着一封没有按计划完成缺陷的修改、测试环境错误造成测试无法继续完成、没有达到进入第二轮测试的标准等等，太多原因造成项目延期，居然在测试过程中，测试主管说因为项目进度失控，提交可测试版本时间不确定，测试资源要调离到其他已经排期的项目中这样我的项目不就是遥遥无期了 肺腑之言：“老板，请再给我一点时间、一点空间”,通过此次培训我能知道什么 总结篇,与测试负责人沟通时，那些测试术语是什么含义？ 测试项目类型分类定义、常规非常规方案定义,测试开始前我需要做什么？ 发送立项邮件、发送Q提交测试项目计划、发送月提交测试项目计划、准备需求文档、