《浅谈项目测试实战》PPT课件.ppt

浅谈项目测试实战 2011年3月24日,内容简要,沟通 宏观计划 测试用例 问题定位 职责 总结,沟通,举例 以下为项目组运行实际发生事情，非杜撰。 项目经理接到客户电话，要求一个问题“紧急处理”。项目经理告诉小组长“处理一下这个问题”。小组长告诉开发人员“有时间处理一下”。结果，问题被无限押后。 交强险即时生效。开发人员很负责的完成设计文档，代码提交、自测。测试人员很负责的完成测试，但是当最后要更新生产的时候，发现了一个问题：开发完成的是商业险。,沟通,沟通成本 软件项目的整个过程，始终都贯穿着频繁地沟通，但其中的沟通成本往往被我们大家所忽视。比如这个成本表现在： 沟通无法实现100%的信息传递，由于信息传递失真导致的成本。 沟通本身存在的时间和空间成本。 由于沟通不充分，导致发生后续的多次沟通。,沟通,沟通效率 选择正确的沟通途径 。 选择正确的沟通途径，对于完成沟通目标起到非常重要的作用。在软件项目管理中，存在各种各样的沟通。根据沟通的对象、内容的不同，我们需要选择不同的沟通途径。当然，最有效的还是面对面的沟通，特别是在获取需求阶段。我发现有时候很多人习惯使用QQ或飞秋沟通需求。其实，有些比较复杂的意见用文字表述非常容易出现歧义，导致沟通不畅，而且效率较低。,沟通,沟通效率 表述的内容易于理解 、思路清晰。 沟通困难的原因，大多是自己想要讲述的内容，对方却无法理解。因此作为测试人员，对bug的描述一定要清晰，主题要简明扼要，场景步骤要描述清楚。比如测试工号，保单号，以及重现的步骤等等。 多次沟通，主要是因为对沟通理解不够透彻。没有对沟通内容进行全面深层次的分析而直接进行沟通。为了提高沟通效率、避免多次重复沟通，建议在沟通前将所要沟通的内容进行完整了解、分析。同时对可能遇到的不清晰、争议、模糊的地方进行例举出来。,沟通,沟通效率 沟通过程中要做到先礼后“兵”。 测试人员在明确自己职责的同时，要注意和开发沟通的方式。出现BUG先要很友好地进行沟通，必要的时候可以从他们的立场出发去寻求突破，不要轻易破坏和开发之间的友好关系。 但是在问题得不到解决，或者会直接影响到项目的进度及质量的时候，也要果断的向上一级寻求帮助，让更有发言权的人来进行沟通和确定。,沟通,沟通小窍门 大家进入一个项目组，建议大家要在一周之内，认识项目组中的所有的人。其中包括他们的名字、基本性格。 因人下菜碟。工作中有时候会遇到孩子气、驴脾气、打太极拳的的，要学会对不同的人采用不同的处理方式。 急躁容易触发矛盾，保持清醒。生活如此美妙，不要过于急躁、不好、不好。 海不扬波。 工作不应该掺杂个人情感，但是请相信：同一件事，朋友永远比陌生人好办事。,宏观计划,举例 我们进入一个项目组，接到测试任务A、B、C。A是先提交的，而且A的开发人员老是催我快点测试。我是先做A、还是B或者C呢？ 我正在测试一个任务A，突然项目经理告诉我，A需要明天上线。我抱怨A测试时间不够，经过 查证，A开发完成提交测试的时间晚了一周。最后结果就是，你被牺牲了。 当我辛辛苦苦测试一大堆bug，兴奋的找开发人员解决的时候。他喝着茶水，翘着二郎腿，告诉你“事情得一件一件的做”。或者很欠揍的说“要不你来改”。更离谱 的是，我完成测试，提交完bug，发现开发人员集体阵地转移了。,宏观计划,要点 上线时间 开发完成时间 开发质量 测试进度 最需要做什么,宏观计划,上线时间 上线时间一般为项目组按照客户或政策要求的最后版本更新时间。一般情况上线时间点之前的时间都是可以安排测试。 当接到多个测试任务的时候，上线时间应该是你安排工作顺序的一个重要依据。 上线时间来源一般是工作计划、项目组长、经理等资深人员。,宏观计划,上线时间 例如、我们进入一个项目组，接到测试任务A、B、C。A是先提交的，而且A的开发人员老是催我快点测试。我是先做A、还是B或者C呢？ 我询问项目经理上线时间，A是1到2个月之后，时间未定。B是1周后，C是两周后，那么你测试安排计划心中应该有答案了吧。 我首先要对B安排测试，但是我发现B的开发人员没有完成开发任务，我需要等待。我计划需要3天完成测试，但是B的开发人员在4天后提交我测试。除去周末，我安排测试的时间只有1天了。怎么办？,宏观计划,开发完成时间 如果说上线时间是你计划的终结，那么一般开发结束时间是你实施测试的开始时间。一般上线时间是我们对客户的一种承诺，基本不变。开发时间一旦被延后，很可能压缩你的测试时间了。 避免因为开发时间延后而压缩测试时间，影响测试质量。当感觉无法满足测试要求，可能存在风险的时候。告诉项目负责人“你的担忧”，“您的项目in trouble ”了。,宏观计划,开发质量 例如：我接受一个测试任务，从提交开发到测试结束，1周时间。但是测试进度已经5天了，我发现有很多的bug没有回归完毕。仍然有严重级别以上的bug发现。这时测试组长问我“是否可以上线”。我的回答是“上不了线，问题太多”。但是其实我丢给你的上司一个难题“保证质量还是按照客户约定发布产品”。“机会永远比结果强”,宏观计划,开发质量 测试进行中要定期对bug进行统计，评估测试版本质量。 通过版本质量，计划测试后期投入。因为如果版本质量很差，那么你要为回归bug投入大量的时间，同时还要承担降级bug的产生风险。 当出现影响到测试进度的bug，要求相关人快速处理了。 正常随着测试进度的推进，bug应该处于收敛状态。如果迟迟不能完全收敛，那么就要通知项目负责人赶快想办法了。,宏观计划,合作对象 测试进度很大程度依赖与你合作的开发人员。起码要知道你发现的bug谁改。 经常和开发人员沟通，缩短测试bug周期。因为一个bug被停滞的时间越长，风险越高。 确定优先级 测试的优先级应该依照测试用例。,测试用例,举例 我最开始测试的时候，接到一个测试任务，直接开始测试，也没有过过需求，可能根本就不知道需要注意什么地方。 测试的时候凭感觉，东测试一下，西测试一下。测试快要结束的时候，把bug回归就算完成了。结果发现有很多东西没有测试到。 测试初期，感觉没有什么可以测试的东西。当投入进行后发现很多需要完成的。由于估计错误，导致测试任务过紧。,测试用例,重要性 避免测试工作开展的盲目性； 于测试工作的跟踪管理，包括测试执行的时间进度的跟踪，测试质量的跟踪 在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率； 测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式； 测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。,测试用例,敏捷测试 敏捷测试是遵循敏捷宣言的一种测试实践： 1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。 2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。 3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性,测试用例,敏捷测试 目前项目组大部分维护工作，应该隶属于敏捷测试范畴。只是我们不规范而已。 目前关于敏捷测试是否需要写测试用例，论点不一。顺便说一下，敏捷开发和敏捷测试是适应当前客户需求的一种解决方式，但是对开发和测试有很高的要求。 我的理解就是“落笔则胸中丘壑尽在眼前”。测试之前，业务流程、需求要求、数据边界等都考虑一遍。,测试用例,要点 需求设计第一位； 页面展现、逻辑是否满足需求要求。 是否会出现需求隐含缺陷。 “金钱至上、脸面重要、信誉第一” 因为保险属于金融领域，涉及到钱的问题，都是大问题。系统中的保单打印等是要给保险公司的客户的，属于脸面工程。保单是保险人与投保人之间签订的一种正式保险合同，是一种承诺。 “大局为重” 测试中不要仅限于单个功能，要布局与整个流程。,测试用例,要点 “轻重 有别” 我们测试中主要测试什么要分清。测试保费计算是要先登录页面，但是没有必要把登录重点测试一遍 虚心请教 一般功能开发者对自己开发的逻辑有一定的了解。他们可以判断出可能存在的风险点。我们可以从他们那里获得灵感。 测试级别 一般测试任务都有一定的级别。例如保证流程畅通、数据正确。还有就是保证无任务轻微bug。当测试任务很紧的时候，次要的测试用例可能要被舍弃。,问题定位,定位 我在测试初期，总是怀疑很多地方有问题，但是也不知道哪里有问题。当然，现在也有这种情况。遇到这种情况，尽量想一想这种方式对客户有什么影响，是否会对他的金钱、利益、风险有什么影响；对于系统操作人员有什么影响，是否操作不便、容易误操作等等。 可以将自己怀疑的点，一一记录下来。自己在心中说服自己，你的怀疑是正确的。然后找测试组内部人或者开发人员，去说服他接受你的观点。能说服别人，其乐无穷，而且很锻炼人。,职责,简述 当我们执行完测试用例，发现大量的bug后，那么恭喜你，你已经完成一半职责了。那么另一半呢？让你发现的bug“寿终正寝”。保证被你发现的bug被解决，并成功上线。 包括很多开发人员、测试人员都不了解，我们工作的终极目标，保证我们的工作成果成功上线并