文档介绍：浅谈项目测试实战
2011年3月24日
整理课件
内容简要
沟通
宏观计划
测试用例
问题定位
职责
总结
整理课件
沟通
举例
以下为项目组运行实际发生事情，非杜撰。
排测试的时间只有1天了。怎么办？
整理课件
宏观计划
开发完成时间
如果说上线时间是你计划的终结，那么一般开发结束时间是你实施测试的开始时间。一般上线时间是我们对客户的一种承诺，基本不变。开发时间一旦被延后，很可能压缩你的测试时间了。
避免因为开发时间延后而压缩测试时间，影响测试质量。当感觉无法满足测试要求，可能存在风险的时候。告诉项目负责人“你的担忧”，“您的项目in trouble ”了。
整理课件
宏观计划
开发质量
例如：我接受一个测试任务，从提交开发到测试结束，1周时间。但是测试进度已经5天了，我发现有很多的bug没有回归完毕。仍然有严重级别以上的bug发现。这时测试组长问我“是否可以上线”。我的回答是“上不了线，问题太多”。但是其实我丢给你的上司一个难题“保证质量还是按照客户约定发布产品”。“机会永远比结果强”
整理课件
宏观计划
开发质量
测试进行中要定期对bug进行统计，评估测试版本质量。
通过版本质量，计划测试后期投入。因为如果版本质量很差，那么你要为回归bug投入大量的时间，同时还要承担降级bug的产生风险。
当出现影响到测试进度的bug，要求相关人快速处理了。
正常随着测试进度的推进，bug应该处于收敛状态。如果迟迟不能完全收敛，那么就要通知项目负责人赶快想办法了。
整理课件
宏观计划
合作对象
测试进度很大程度依赖与你合作的开发人员。起码要知道你发现的bug谁改。
经常和开发人员沟通，缩短测试bug周期。因为一个bug被停滞的时间越长，风险越高。
确定优先级
测试的优先级应该依照测试用例。
整理课件
测试用例
举例
我最开始测试的时候，接到一个测试任务，直接开始测试，也没有过过需求，可能根本就不知道需要注意什么地方。
测试的时候凭感觉，东测试一下，西测试一下。测试快要结束的时候，把bug回归就算完成了。结果发现有很多东西没有测试到。
测试初期，感觉没有什么可以测试的东西。当投入进行后发现很多需要完成的。由于估计错误，导致测试任务过紧。
整理课件
测试用例
重要性
避免测试工作开展的盲目性；
于测试工作的跟踪管理，包括测试执行的时间进度的跟踪，测试质量的跟踪
在回归测试中，测试用例的存在可以大大的降低测试的工作量，从而提高测试的工作效率；
测试用例是测试执行的实体，是测试方法、测试质量、测试覆盖率的重要依据和表现形式；
测试用例是说服用户相信产品质量的最佳依据，同时也可以提供给客户作为项目验收的依据。
整理课件
测试用例
敏捷测试
敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即是从使用系统的用户的角度，来测试系统。
2、重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性
整理课件
测试用例
敏捷测试
目前项目组大部分维护工作，应该隶属于敏捷测试范畴。只是我们不规范而已。
目前关于敏捷测试是否需要写测试用例，论点不一。顺便说一下，敏捷开发和敏捷测试是适应当前客户需求的一种解决方式，但是对开发和测试有很高的要求。
我的理解就是“落笔则胸中丘壑尽在眼前”。测试之前，业务流程、需求要求、数据边界等都考虑一遍。
整理课件
测试用例
要点
需求设计第一位；
页面展现、逻辑是否满足需求要求。
是否会出现需求隐含缺陷。
“金钱至上、脸面重要、信誉第一”
因为保险属于金融领域，涉及到钱的问题，都是大问题。系统中的保单打印等是要给保险公司的客户的，属于脸面工程。保单是保险人与投保人之间签订的一种正式保险合同，是一种承诺。
“大局为重”
测试中不要仅限于单个功能，要布局与整个流程。
整理课件
测试用例
要点
“轻重 有别”
我们测试中主要测试什么要分清。测试保费计算是要先登录页面，但是没有必要把登录重点测试一遍
虚心请教
一般功能开发者对自己开发的逻辑有一定的了解。他们可以判断出可能存在的风险点。我们可以从他们那里获得灵感。
测试级别
一般测试任务都有一定的级别。例如保证流程畅通、数据正确。还有就是保证无任务轻微bug。当测试任务很紧的时候，次要的测试用例可能要被舍弃。
整理课件
问题定位
定位