写给测试新人怎么找缺陷+怎么写用例（转）

写给测试新人

总结一下测试新人，怎样快速找出系统的不足或缺陷

      1、阅读需求文档，深入了解系统，磨刀不误砍柴工，不要还没弄清需求就开测了，（一个星期前，公司刚进一个新人，TD上查看了下他们发的BUG，发现好几个是需求不明确误发的）心想：原来是这个系统啊，项目实训的时候做过和这个类似的项目，于是就把实训的系统需求硬生生的搬到当前系统来，这样做的风险太大，因为每个系统的需求都不一样，不能生搬硬套，打个比方：假设要你制造一辆轿车，你以前制造过普桑，就把你制造普桑的技术拿去制造林肯，这样做显然不合适。熟悉系统（一般公司都会有系统熟悉情况考核）所以请一定要认真的阅读需求文档（有的公司叫产品定义）
       2、熟悉测试用例，这是测试执行的一个导向，要想快速高效率的执行用例，必须在熟悉系统的同时，熟悉用例，熟悉每条用例覆盖的需求，这样执行起来才能事半功倍
       3、记住自己在工作中扮演的角色是测试而不是开发 。珍惜时间，避免不必要的浪费。作为一个测试新人来讲，刚开始接触项目，有很多时候发现BUG，只是知道它的表象特征，却无法弄清这个缺陷是由什么引起的，这里就存在一个误区，花过多的时间去寻找原因，因为受个人所学习知识和经验上的限制，有的缺陷很难短时间内找到产生原因，与其这样浪费时间，不如将BUG重现给开发看一下，让开发找原因，那样即不耽误下面的测试也能在短时间内找出原因，从根本上解决BUG。
       4、一旦发现缺陷，应立刻提交。有几种情况：测试就像是一场优胜劣汰的战斗，你的动作慢了，成果就是别人的了。
        1）作为一个测试新人来讲，测试的第一步，可能是从执行用例开始，而成功的用例（项目刚开始时）可以发现很多系统中存在的问题，同一条case里的不同STEP就可能发现多个BUG，那么对于这样的情况，我们要做的是：发现就提交，不要等到所有STEP都执行完再提交。那样说不定已经被别人提交了。
        2）‘抛开’需求说明书（即不用看需求说明书，对需求也特别熟悉），以快取胜。假设你和同事同时发现了个BUG（双方都不知道对方在提交），而你对需求不熟悉，不太确信是个BUG，然后又去翻需求，翻完回来再提交，结果这时候同事已经提交了，那么不好意思，你的BUG只能作CLOSED_Nbug处理了，如果一定要加上一个批注，那么将是，重复提交（测试新人，备注里不建议加测试建议（即怎样修改可以避免此缺陷），因为有可能会对开发产生误导）特别说明：1）速度和效率同时考虑，尽量别发错BUG；2）公平竞争，还要考虑团队合作，在别人的测试模块发现BUG，建议告知对方提，与同事交流的时候，同事讲到的缺陷，而缺陷管理工具中没提，应该让对方提交上去
       5、新版本发布：
       1）验证FIXED缺陷，如果验证通过了，把状态改为CLOSED（关闭的时候一定要加个备注，（比如：某月某日某版本验证通过。）对于开发修改了，但是与需求有出入的，且与测试经理确认可以这样修改时，备注建议这样写：某月某日某版本验证通过，修改为……），如果没通过改为OPEN（同样加个备注：某月某日某版本验证未通过），这里存在一个误区，有的人会把状态改为REOPEN，如果是公司要求的，那无可厚非，如果没有要求，建议改为OPEN，因为REOPEN是已经确认修改并且该BUG已经改为CLOSED状态后，才需要修改为REOPEN状态的。（有很多公司是不允许出现REOPEN状态的（针对开发），一旦出现，开发此模块的程序员绩效可能会被大打折扣，我现在所在的公司就是这样的）
       2）冒下烟确保主流程畅通，然后再进行功能测试，着重测试有修改的或者与所修改模块有调用关系的模块和发现BUG比较多的模块（公司发布版本会邮件通知修改的模块与修复的BUG），未改动的模块建议做个流程测试。特别说明：主流程走不通，应立刻MSN给项目负责人（组长或经理，如果有本项目MSN群，直接在群里讲就可以了）
       6、如果版本未更新，
       1)建议着重进行业务逻辑方面测试，在电脑上以文档形式画出简单的业务逻辑图，重点说明：一定 要尽量考虑所有的情况，因为这样的BUG要么就没有，一旦有就是HIGH
       2)建议进行环境测试（当然要根据需求测试相应的环境）
       3)严格核对需求文档，防止需求遗漏
       7、严格按照缺陷提交说明提交BUG，因为这有可能涉及BUG的统计问题，（一般公司的缺陷描述：系统名称_功能模块，缺陷描述，要具体问题具体对待）
          优先级和严重程度不要夸大也不要降低，实事求是，因为这与开发和测试的绩效考评有挂钩，要是夸大缺陷，会影响开发的绩效考评，降低会影响自己的绩效考评，建议：系统级（影响流程）和跳黄页（报服务器错误的，这类缺陷有的是服务器配置错误导致，建议先检查配置后提交）建议为高，功能实现建议为中，界面易用，或者不影响系统使用的其他问题建议为低，具体级别公司会有规定，如果没有规定，可按照以上建议划分。

       8、测试没有空闲。项目在不同阶段，会有些时间很‘空闲’。

初次怎么写用例？
有很多朋友初次写用例，不知道从何下手，虽然有的公司给出了相关说明文档，但是写起来还是不能得心应手，编写用例方法有很多种：功能导向用例（边界值、等价类等等），用户导向用例（场景法），用户、功能相结合导向用例……那么对于初次编写用例，应该怎样高效率的编写用例？应该注意点什么？
一、功能导向用例是按照系统需要达到的每一个功能，进行编写用例，这样的用例着重点在功能实现上，而没有考虑到每个功能之间的关联，因而虽然用例已经达到功能覆盖，却不一定达到逻辑覆盖，因而这种方法通常会和其他方法结合使用。功能导向用例是每个用例编写者前期最常用的方法，网络上可以搜索到很多相关文章，这里因为时间关系就不写了。（还有一个原因就是可能写的很烂，所以就不拿出来丢人现眼了，呵呵）
二、用户导向用例是按照用户的习惯，将用户使用系统的每个目的作为一个目标，以每个目标实现为基点设计测试用例，这样的方法在B/S结构中使用比较广泛（我一直从事B/S测试所以适不适用C/S我不清楚，但因为我喜欢玩网游，所以对C/S软件也不陌生，个人觉得也可以应用，现在的网络游戏（非竞技类）以多任务为主导，比如魔兽世界、梦幻西游、大话西游、完美国际、QQ三国等等，那么可以将完成每个任务作为目标设计测试用例）但是设计这一类用例，初写者，可能会产生很多困惑（下面写一下我第一次写的时候有哪些困惑，并针对这些困惑，后来采取了怎样的解决方案）
1、编写用例的第一步我该做什么？
理解系统，首先站在测试的角度深入理解系统的每个功能与系统业务逻辑，画出业务逻辑图（即：系统能做什么）。
其次站在用户的角度，列出用户使用系统的目的（即：用户使用这个系统，想干什么？）
2、怎样确定用户目标？
   不能确定用户目标，可能由2方面原因造成： a>对系统不够熟悉，b>不了解用户背景。对于第一点原因，那是你自己的原因，只有回过去头看文档了，对于第二点原因，可以从‘系统能做什么’推算出‘用户可以做什么’然后再总结出‘用户可能想做什么’，当然这样做的前提是你对系统已非常熟悉。

这个月我将做什么？

刚进入测试 行业 是怎样总结的（利用测试管理 工具 进行总结）：
1）把测试 管理工具 中的缺陷全部分类导出，总结一下哪些模块容易产生哪些缺陷，重点看一下自己没发现或没有考虑到的缺陷，关注CLOSED_NBUG、ByDesign、Rejected、Deferred状态的缺陷：
a)CLOSED_NBUG状态的缺陷一般都是需求不明确，需求变更而产生的，看一下这类缺陷，可以总结一下哪些需求容易产生误解，和出现了哪些新需求。
b) ByDesign 状态的缺陷一般都是设计上的问题，可以以此总结一下设计上存在哪些不足，有什么好的建议，还可以给项目 经理 提（这样的建议一旦采纳，那你的身价会提高很多）
c) Rejected状态的缺陷有几种情况：一、重复提交（有的人会改为CLOSED_Nbug）二、开发人员认为不需要修改，三、不是问题（对需求不够理解造成）对于Rejected状态的BUG一定要看Comments（备注：通常是说明Rejected理由的），如果没加备注，那要确认下为什么要打回？（我们 公司 要是Rejected不加备注，要直接打开，然后备注写上：未说明Rejected原因，重新打开，个人觉得这样不太好，应该先和开发确认一下Rejected原因，合理的话要让他加上备注，如果不合理，要和他交涉并和测试组长或经理确认一下是否需要重新打开）
d)Deferred 状态的缺陷一般是项目时间比较紧 而且 这类缺陷的存在又不会影响系统的正常使用，所以延期处理，对于这样的缺陷，可以暂时不用关注，但是要确认一下大约在哪个阶段修改，确认后 记录 下来，到了相应阶段，继续关注这些缺陷，可以通过这类BUG总结一下哪些缺陷可以延后处理（重点说明：优先级虽低，但是一定要提，只是为了让自己对缺陷主次有个认识）
    2）如果说测试新人工作的第一层次是从执行用例开始，那么第二层次就是编写测试用例了
把测试管理工具中的用例详细看几遍，学习别人的用例编写方法和思想，空闲时间可以自己试着编写，看自己编写的与别人编写的用例差距在哪，从而不断完善。重要说明；着重用例编写方法和思想的学习，而不要死搬硬套
    3）进入一些测试论坛，把自己的困惑和经验和大家一起分享，在学习中，不断进步。