浅谈项目测试实战.ppt

《浅谈项目测试实战.ppt》由会员分享，可在线阅读，更多相关《浅谈项目测试实战.ppt（27页珍藏版）》请在三一办公上搜索。

1、浅谈项目测试实战 2011年3月24日,内容简要,沟通宏观计划测试用例问题定位职责总结,沟通,举例 以下为项目组运行实际发生事情，非杜撰。项目经理接到客户电话，要求一个问题“紧急处理”。项目经理告诉小组长“处理一下这个问题”。小组长告诉开发人员“有时间处理一下”。结果，问题被无限押后。交强险即时生效。开发人员很负责的完成设计文档，代码提交、自测。测试人员很负责的完成测试，但是当最后要更新生产的时候，发现了一个问题：开发完成的是商业险。,沟通,沟通成本 软件项目的整个过程，始终都贯穿着频繁地沟通，但其中的沟通成本往往被我们大家所忽视。比如这个成本表现在：沟通无法实现100%的信息传递，由于信息传

2、递失真导致的成本。沟通本身存在的时间和空间成本。由于沟通不充分，导致发生后续的多次沟通。,沟通,沟通效率选择正确的沟通途径。选择正确的沟通途径，对于完成沟通目标起到非常重要的作用。在软件项目管理中，存在各种各样的沟通。根据沟通的对象、内容的不同，我们需要选择不同的沟通途径。当然，最有效的还是面对面的沟通，特别是在获取需求阶段。我发现有时候很多人习惯使用QQ或飞秋沟通需求。其实，有些比较复杂的意见用文字表述非常容易出现歧义，导致沟通不畅，而且效率较低。,沟通,沟通效率表述的内容易于理解、思路清晰。沟通困难的原因，大多是自己想要讲述的内容，对方却无法理解。因此作为测试人员，对bug的描述一定要清晰

3、，主题要简明扼要，场景步骤要描述清楚。比如测试工号，保单号，以及重现的步骤等等。多次沟通，主要是因为对沟通理解不够透彻。没有对沟通内容进行全面深层次的分析而直接进行沟通。为了提高沟通效率、避免多次重复沟通，建议在沟通前将所要沟通的内容进行完整了解、分析。同时对可能遇到的不清晰、争议、模糊的地方进行例举出来。,沟通,沟通效率沟通过程中要做到先礼后“兵”。测试人员在明确自己职责的同时，要注意和开发沟通的方式。出现BUG先要很友好地进行沟通，必要的时候可以从他们的立场出发去寻求突破，不要轻易破坏和开发之间的友好关系。但是在问题得不到解决，或者会直接影响到项目的进度及质量的时候，也要果断的向上一级寻求

4、帮助，让更有发言权的人来进行沟通和确定。,沟通,沟通小窍门大家进入一个项目组，建议大家要在一周之内，认识项目组中的所有的人。其中包括他们的名字、基本性格。因人下菜碟。工作中有时候会遇到孩子气、驴脾气、打太极拳的的，要学会对不同的人采用不同的处理方式。急躁容易触发矛盾，保持清醒。生活如此美妙，不要过于急躁、不好、不好。海不扬波。工作不应该掺杂个人情感，但是请相信：同一件事，朋友永远比陌生人好办事。,宏观计划,举例我们进入一个项目组，接到测试任务A、B、C。A是先提交的，而且A的开发人员老是催我快点测试。我是先做A、还是B或者C呢？我正在测试一个任务A，突然项目经理告诉我，A需要明天上线。我抱怨A

5、测试时间不够，经过 查证，A开发完成提交测试的时间晚了一周。最后结果就是，你被牺牲了。当我辛辛苦苦测试一大堆bug，兴奋的找开发人员解决的时候。他喝着茶水，翘着二郎腿，告诉你“事情得一件一件的做”。或者很欠揍的说“要不你来改”。更离谱 的是，我完成测试，提交完bug，发现开发人员集体阵地转移了。,宏观计划,要点上线时间开发完成时间开发质量测试进度最需要做什么,宏观计划,上线时间上线时间一般为项目组按照客户或政策要求的最后版本更新时间。一般情况上线时间点之前的时间都是可以安排测试。当接到多个测试任务的时候，上线时间应该是你安排工作顺序的一个重要依据。上线时间来源一般是工作计划、项目组长、经理等资

6、深人员。,宏观计划,上线时间 例如、我们进入一个项目组，接到测试任务A、B、C。A是先提交的，而且A的开发人员老是催我快点测试。我是先做A、还是B或者C呢？我询问项目经理上线时间，A是1到2个月之后，时间未定。B是1周后，C是两周后，那么你测试安排计划心中应该有答案了吧。我首先要对B安排测试，但是我发现B的开发人员没有完成开发任务，我需要等待。我计划需要3天完成测试，但是B的开发人员在4天后提交我测试。除去周末，我安排测试的时间只有1天了。怎么办？,宏观计划,开发完成时间如果说上线时间是你计划的终结，那么一般开发结束时间是你实施测试的开始时间。一般上线时间是我们对客户的一种承诺，基本不变。开发

7、时间一旦被延后，很可能压缩你的测试时间了。避免因为开发时间延后而压缩测试时间，影响测试质量。当感觉无法满足测试要求，可能存在风险的时候。告诉项目负责人“你的担忧”，“您的项目in trouble”了。,宏观计划,开发质量例如：我接受一个测试任务，从提交开发到测试结束，1周时间。但是测试进度已经5天了，我发现有很多的bug没有回归完毕。仍然有严重级别以上的bug发现。这时测试组长问我“是否可以上线”。我的回答是“上不了线，问题太多”。但是其实我丢给你的上司一个难题“保证质量还是按照客户约定发布产品”。“机会永远比结果强”,宏观计划,开发质量测试进行中要定期对bug进行统计，评估测试版本质量。通过

8、版本质量，计划测试后期投入。因为如果版本质量很差，那么你要为回归bug投入大量的时间，同时还要承担降级bug的产生风险。当出现影响到测试进度的bug，要求相关人快速处理了。正常随着测试进度的推进，bug应该处于收敛状态。如果迟迟不能完全收敛，那么就要通知项目负责人赶快想办法了。,宏观计划,合作对象测试进度很大程度依赖与你合作的开发人员。起码要知道你发现的bug谁改。经常和开发人员沟通，缩短测试bug周期。因为一个bug被停滞的时间越长，风险越高。确定优先级 测试的优先级应该依照测试用例。,测试用例,举例我最开始测试的时候，接到一个测试任务，直接开始测试，也没有过过需求，可能根本就不知道需要注意

9、什么地方。测试的时候凭感觉，东测试一下，西测试一下。测试快要结束的时候，把bug回归就算完成了。结果发现有很多东西没有测试到。测试初期，感觉没有什么可以测试的东西。当投入进行后发现很多需要完成的。由于估计错误，导致测试任务过紧。,测试用例,重要性避免测试工作开展的盲目性；于测试工作的跟踪管理，包括测试执行的时间进度的跟踪，测试质量的跟踪在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。,测试用例,敏捷测试

10、 敏捷测试是遵循敏捷宣言的一种测试实践：1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性,测试用例,敏捷测试 目前项目组大部分维护工作，应该隶属于敏捷测试范畴。只是我们不规范而已。目前关于敏捷测试是否需要写测试用例，论点不一。顺便说一下，敏捷开发和敏捷测试是适应当前客户需求的一种解决方式，但是对开发和测试有很高的要求。我的理解就是“落笔则胸中丘壑尽在眼

11、前”。测试之前，业务流程、需求要求、数据边界等都考虑一遍。,测试用例,要点需求设计第一位；页面展现、逻辑是否满足需求要求。是否会出现需求隐含缺陷。“金钱至上、脸面重要、信誉第一”因为保险属于金融领域，涉及到钱的问题，都是大问题。系统中的保单打印等是要给保险公司的客户的，属于脸面工程。保单是保险人与投保人之间签订的一种正式保险合同，是一种承诺。“大局为重”测试中不要仅限于单个功能，要布局与整个流程。,测试用例,要点“轻重 有别”我们测试中主要测试什么要分清。测试保费计算是要先登录页面，但是没有必要把登录重点测试一遍虚心请教一般功能开发者对自己开发的逻辑有一定的了解。他们可以判断出可能存在的风险点

12、。我们可以从他们那里获得灵感。测试级别一般测试任务都有一定的级别。例如保证流程畅通、数据正确。还有就是保证无任务轻微bug。当测试任务很紧的时候，次要的测试用例可能要被舍弃。,问题定位,定位 我在测试初期，总是怀疑很多地方有问题，但是也不知道哪里有问题。当然，现在也有这种情况。遇到这种情况，尽量想一想这种方式对客户有什么影响，是否会对他的金钱、利益、风险有什么影响；对于系统操作人员有什么影响，是否操作不便、容易误操作等等。可以将自己怀疑的点，一一记录下来。自己在心中说服自己，你的怀疑是正确的。然后找测试组内部人或者开发人员，去说服他接受你的观点。能说服别人，其乐无穷，而且很锻炼人。,职责,简述

13、 当我们执行完测试用例，发现大量的bug后，那么恭喜你，你已经完成一半职责了。那么另一半呢？让你发现的bug“寿终正寝”。保证被你发现的bug被解决，并成功上线。包括很多开发人员、测试人员都不了解，我们工作的终极目标，保证我们的工作成果成功上线并得到用户的认可。发现的bug再多，如果没有人解决或者无法上线，这样我们的工作得不到体现，没有什么价值。,总结,简述 当我们测试完成，提交客户验收后，我们应当关注上线后问题反馈。对我们工作进行信息收集，积极分析我们工作中的不足，为下次测试吸取教训。测试不是万能的，谁都会出现测试疏漏。当发现疏漏的时候，不是推卸责任，而是多多总结。“路遥知马力”，高手来源“日积月累”。,寄语,愿我们飞的更高！,谢谢,