软件缺陷是软件开发过程中的副产品，通常缺陷会导致软件产品在某种程度上不能满足客户需求。因此，妥善处理软件中的缺陷是关系到软件产品质量的根本。可遗憾的是，并非所有的软件团队都知道如何有效地管理在测试中发现的缺陷。

　　对于软件测试人员而言，在测试中不能正确表示缺陷的严重程度和优先级，这将会影响到软件缺陷管理的质量，不仅不利于有效的处理软件缺陷，还可能影响到软件缺陷的处理时机。特别在软件测试的后期，将影响软件是否能够按期发布与否。近期我在一个测试项目中，由于对缺陷严重程度和优先级缺乏有效处理，最终导致软件验收发布被迫延后。

　　什么是缺陷严重程度和优先级？

　　（1）什么是缺陷的严重程度和优先级

　　软件缺陷是指在软件系统中会导致系统不能实现其功能的缺陷（包括Defect或Bug）。一般来说，软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷原因等。

　　其中缺陷严重程度是指软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将会对软件的功能和性能产生怎样的影响。优先级是指表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

　　（2）正确评估严重程度和优先级的作用

　　缺陷管理的目标在于：当在软件测试过程中发现缺陷后，能正确评估缺陷并执行及修正系统质量，以创造一个合乎需求的软件产品。因此，软件产品质量很大程度上取决于在测试中发现的缺陷的管理能力。其中软件缺陷严重程度和优先级的正确评估和描述是软件缺陷管理的基础部分，也是测试人员与开发小组交流的基础。一个好的严重程度和优先级评估会用简单的、准确的、专业的语言来反映缺陷的本质。否则，如果评估和描述信息含糊不清，就可能会误导开发人员。因为清晰准确的软件缺陷评估可以提高软件缺陷修复的速度，也可以加强开发人员、测试人员和管理人员的协同工作。

　　因此，正确评估缺陷的严重程度和优先级，是项目组全体人员交流的基础。为了保证正确评估缺陷的严重程度和优先级，质量保证人员需要经常检查测试人员和开发人员对于这两个指标的评估和处理情况，一发现有问题及时反馈给项目负责人解决。

　　（3）缺陷的严重程度和优先级的级别划分

　　缺陷的严重程度和优先级通常可按级别划分，各个公司对不同项目的具体表示方式有所不同，具体的级别划分需要软件测试前达成一致。常用的缺陷严重程度可分为：致命、严重、一般、较小。致命是指系统任何一个主要功能完全丧失，或用户数据受到破坏，造成系统崩溃、悬挂、死机或者危机人身安全；严重是指系统的主要功能部分丧失，或数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；一般是指系统的次要功能没有完全实现，但不影响用户的正常使用；较小是指使操作者不方便或遇到麻烦，但它不影响功能的操作和执行的一些小问题。

　　常用的缺陷的优先级表示方法可分为：立即解决、高优先级、正常排队、低优先级。立即解决是指缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；高优先级是指缺陷严重影响测试，需要优先考虑；正常排队是指缺陷需要正常排队等待修复；而低优先级是指缺陷可以在开发人员有时间的时候再被纠正。

　　（4）缺陷严重程度和优先级的关系

　　严重程度高说明缺陷对软件造成的质量危害性大，是需要优先处理，而严重程度低的缺陷可能只是软件不太尽善尽美，可以稍后处理。因此，缺陷的严重程度和优先级是含义不同但相互联系密切的两个概念，它们是从不同的侧面描述了软件缺陷对软件质量的影响程度和处理方式。

　　一般地，严重程度高的软件缺陷具有较高的优先级，但是严重程度和优先级并不总是一一对应。有时候严重程度高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重程度低的缺陷却需要及时处理，反而具有较高的优先级。例如，公司名字和软件产品徽标是重要的，一旦它们误用了，这种缺陷是用户界面的产品缺陷，并不影响用户使用。但是它影响公司形象和产品形象，因此这也是优先级高的软件缺陷。

　　如何评估缺陷严重程度和优先级？

　　（1）明确用户需求，设定软件质量标准

　　我们常常听到许多自称测试专家的人在大谈特谈缺陷严重程度和优先级的标准，例如什么系统死机就一定是高级别，界面错误则是低级别之类。但事情上，对于不同的软件因为应用场合的不一样，即使是同一类型的缺陷但也可能其严重程度和优先级是不一样的。

　　一般来说，软件程序并不需要十全十美，因为尽善尽美意味着成本巨大，但软件产品必须迎合和满足目标用户的需求和期望。因此，对于一个软件产品,应该从客户角度来建立缺陷严重程度和解决优先级。了解对用户来说什么是最重要的，而不只是根据经验和常识来制定缺陷的严重程度和优先级。

（2）实事求是的确定缺陷严重程度和优先级

　　通常功能性的缺陷较为严重，具有较高的优先级，而软件界面类缺陷的严重性一般较低，优先级也较低。但实际上，优先级和严重程度是有联系也有区别。严重程度高的，必然优先级也要高，但优先级高的，严重程度却并非也一定高。

　　那么，怎么样才能使得一个包含缺陷的软件产品却看起来性能优良呢?具体说很大程度上是根据公司和客户需求来决定的。简单说，就是缺陷对客户影响严重程度（主要、次要、不严重），就是对软件产品的影响严重程度；缺陷客户的优先级（紧急、普通、不急）就是项目的优先级。所以，并非所有的缺陷都是一样的重要，也并非根据以往的项目经验就能确定软件缺陷的严重程度和优先级。判断的依据应该是从软件最终用户的观点来做出判断，即判断缺陷的严重程度是先考虑用户的利益，例如此类缺陷是否会对用户使用造成恶劣后果的严重程度。因此，根据用户需求和期望，是分析和评估缺陷严重程度至关重要的一步。

　　但缺陷优先级却不只是依据客户需求来判断的，缺陷优先级还必须要根据开发角度和资源投入来进行划分和评估优先次序。一般来说，测试比较规范的团队，会由测试经理、项目经理等部门根据技术角度和公司资源来制订一份优先级的标准文档。因为缺陷的修正顺序是个复杂的过程，不单是纯粹技术问题，除了要站在开发的角度去考虑问题外，更多的还要考虑抢占市场先机和公司资源分配的情况。

　　另外，为了确保软件缺陷的有效管理，在一定环境和条件下缺陷应该可以改变优先次序，如升级和降级。就是说随着项目进度，可能会重新划分严重程度和优先级别。因此，确定和评估缺陷严重程度和优先级要全面了解和深刻体会缺陷的特征，要从用户需求、开发角度以及市场的因素综合考虑。

　　（3）避免两种常见的误区

　　正确评估缺陷的严重程度和优先级不是件容易的事情，对于经验不是很丰富的测试人员而言，经常犯的错误有两种情形：一是将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，不但影响到对软件质量的正确评估，而且也耗费了开发人员辨别和处理缺陷的时间。二是将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。结果到项目后期才发现还有很多由于不正确评估优先级造成的严重缺陷，将会需要投入更多人力和时间进行修正，影响软件的正常发布；或者这些严重的缺陷成了漏网之鱼，随软件一起发布出去可能会造成软件质量事故。

　　巧用评估技术工具，分清轻重缓急

　　因此，正确评估和区分缺陷的严重性和优先级，是测试人员和开发人员以及全体项目组人员的一件大事。这既是确保测试顺利进行的要求，也是保证软件质量的重要环节，应该要引起足够的重视。这里介绍三种常用的技术工具供大家参考。

　　（1）20/80原则

　　管理学大师彼得杜拉克说过：做事情必须分清轻重缓急。最糟糕的是什么事都做，这必将一事无成。而意大利经济学家柏拉图则更明确提出：重要的少数与琐碎的多数或称20/80的定律。就是80%的有效工作往往是在20%的时间内完成的，而20%的工作是在80%的时间内完成的。因此，为了提高测试质量，必须清晰的认识到哪些缺陷是最重要的，哪些缺陷是最关键的。不要拣了芝麻，却丢了西瓜。所以，只有抓住了重要的关键缺陷，测试效果才能产生最大的效益，这也是第一个原则---分清轻重缓急，把测试活动用在最有生产力的事情上。

　　（2）ABC法则

　　古人云：事有先后，用有缓急。测试工作其实也是如此，分清缺陷的轻重缓急，不但做处理缺陷来井井有条，完成后的效果也是不同凡响。因此，我们在测试工作中要时时记住一点，手边的缺陷并不一定就具有第一优先处理的重要性。只有正确的判断，才可将测试活动效率增加数倍。

　　ABC法则是设定缺陷优先顺序重要工具之一。这ABC工具的关键点在于根据缺陷的重要程度决定优先顺序，按需求目标进行量化规划。把A类缺陷作为测试最重要的最有价值的最关键的缺陷，并保证首先把A类缺陷先处理。其次是B类，然后是C类，然后是其它的，还有一些不紧急不重要的缺陷根本没有必要去做。因此，应用ABC方法可更明确地确定各项测试目标，当然也能更明确把要处理的缺陷和它们的优先次序确定。

　　（3）四象限原则，把缺陷进行分类

　　在处理测试缺陷中，常会遇到千头万绪、问题繁多的情况，有些测试人员会被测试出来众多的缺陷所压垮，有些人则是悠然自得、高效完成。到底是什么原因造成这种区别呢？原因在于对缺陷分类是否合理。

　　那么，我们该如何对缺陷进行合理的分类呢？其实很简单，在一张坐标纸上，先划分好四个象限，然后只需记住四个字就行，那就是"轻重缓急"。"轻"，指的是相对重要但不紧急的缺陷；"重"，是指最重要也是最紧急的缺陷；"缓"，指的是不重要也不紧急的缺陷；"急"，则是指不是最重要但却最为紧急的缺陷。理清这种关系之后，就算同时测试许多不同类型的缺陷，也会很快清楚哪些缺陷是必须马上完成，哪些缺陷是可以暂时缓一缓，这样也就不会被堆积如山的缺陷所压垮，测试效率自然也会得到很大的提高。

作者: 潘少红    来源: IT168

1、严格按用例执行；

　　2、如果是作随机测试时，把测试步骤的点进行速记;

　　3、偶发BUG一般都是严重的，保留现场，让开发人员一起分析留下的现场(如数据的变化，界面窗口的变化等，找出问题的引子，那怕是千丝万缕，只要有一线希望，都要与开发人员一起分析，千万别关机(关机后再重启很多现场已破坏，不少数据是保存在闪存中的)。

　　4、最好的做法：要求开发打开trace，测试版本在执行时能自动把测试的路径，或触发的消息等输出到文件，相当于软件的执行log，这个log对解决偶发问题将大有裨益。

　　5、即使一时没有重现，一定也要录入故障库，并标明发生的概率。在日后不同的迭代版本中进行跟踪验证，并把验证的路径写上。

　　6、事上没有那么侥幸的事，在公司内部出现过的BUG，在用户端一定也会发生，只是时间与频率的问题，所以要视其影响度，是否需考虑由专人处理这类问题。

本文出自aux0的51Testing软件测试博客：http://www.51testing.com/?26026

列表页面显示：

某网站提供会员模板下载、上传、购买、支付等功能，目前进入性能测试阶段，通过性能需求可以了解到主要有以下几个性能指标需要进行测试：

　　● 产品页面刷新性能

　　● 产品上传性能

　　● 产品下载性能

　　目前给出的指标为：

　　延迟：

　　测试项         响应时间  抖动   备注

　　产品页面刷新     <5秒    <2秒

　　产品下载相应时间  <4秒    <2秒

　　吞吐量：

　　编号                项                 吞吐量

　　Perf.T.1 所有登录用户在线状态更改频率  每10分钟1次

　　Perf.T.2 每日页面平均访问量           60000次

　　Perf.T.3 每日下载量                  50000

　　Perf.T.4 平均每日新增会员数量          500

　　Perf.T.5 高峰同一模板下载量           100用户并发下载

　　Perf.T.6 高峰不同模板下载量           150用户并发下载

　　容量：

　　编号       项            容量

　　Perf.C.1 用户数          <=100万

　　Perf.C.2 活动用户数       10000

　　Perf.C.3 模板中心总用户数  <=25万

　　根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？（可以说给出的性能需求很垃圾，没有丝毫价值，但没办法还是点做啊）

　　首先，我不去在乎它要求的性能是什么，我只需要去做在一定的测试环境下对系统进行压力测试，找到各个性能指标的临界点就好了，至于是否达到性能指标，在和性能需求对照编写测试报告即可。

　　所以，针对这几个需要进行性能测试的页面，我们做一下分析，如何设计场景才能尽可能准确地体现出系统的性能：

　　先说一下搜索页面

　　搜索页面根据对项目的了解，搜索后，将所有符合条件的结果遍历出来，显示在前台，每页的显示数量是一定的，超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面，对于页面显示对性能的消耗我们可以忽略不计，主要的压力来自数据的传输、sql的执行及应用服务器的处理过程，所以我可以从两个方面设计场景：

　　a、虚拟用户一定，不同数据库数量级的情况下，搜索的性能

　　如何确定虚拟用户的数量成为一个关键，我们可以让客户提供一个常规情况下每天访问用户数（如果没有实际数据可参考，可以根据产品方案中期望的用户数来代替），我们就用这个用户数来进行测试；再来分析一下不同的数据库数量级，如果系统运营1年的产品数据量是5万条，那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试（具体的分法可以根据实际情况而定），所以对于这个测试目标，我们可以设计5个场景进行：

　　虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间

　　100 10000  搜索页面 随机产生 30分钟 加入思考时间

　　100 30000  搜索页面 随机产生 30分钟 加入思考时间

　　100 50000  搜索页面 随机产生 30分钟 加入思考时间

　　100 100000 搜索页面 随机产生 30分钟 加入思考时间

　　100 200000 搜索页面 随机产生 30分钟 加入思考时间

　　b、一定数据库数量级，不同量虚拟用户的情况下，搜索的性能

　　我们定下来一个常规的数据库数据量，在数据量不变的情况下逐步增加虚拟用户数，测试一下不同虚拟用户压力下系统的性能

　　虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间

　　50  50000 搜索页面 随机产生 30分钟 加入思考时间

　　80  50000 搜索页面 随机产生 30分钟 加入思考时间

　　100 50000 搜索页面 随机产生 30分钟 加入思考时间

　　120 50000 搜索页面 随机产生 30分钟 加入思考时间

　　150 50000 搜索页面 随机产生 30分钟 加入思考时间

　　产品上传

　　影响上传性能的主要因素有上传文件的大小和上传的请求数，所以我们就从这两个方面设计用例。

　　a、虚拟用户数一定，上传不同大小的文件

　　虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间

　　50 100k 上传页面 随机产生 30分钟 取消思考时间

　　50 300k 上传页面 随机产生 30分钟 取消思考时间

　　50 500k 上传页面 随机产生 30分钟 取消思考时间

　　50 800k 上传页面 随机产生 30分钟 取消思考时间

　　50 1M   上传页面 随机产生 30分钟 取消思考时间

　　b、上传文件大小一定，不同量的虚拟用户

　　虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间

　　20  300k 上传页面 随机产生 30分钟 取消思考时间

　　50  300k 上传页面 随机产生 30分钟 取消思考时间

　　80  300k 上传页面 随机产生 30分钟 取消思考时间

　　100 300k 上传页面 随机产生 30分钟 取消思考时间

　　产品下载

　　影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例

　　a、虚拟用户数一定，下载不同大小的文件

　　虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间

　　50 100k 下载页面 随机产生 30分钟 取消思考时间

　　50 300k 下载页面 随机产生 30分钟 取消思考时间

　　50 500k 下载页面 随机产生 30分钟 取消思考时间

　　50 800k 下载页面 随机产生 30分钟 取消思考时间

　　50 1M   下载页面 随机产生 30分钟 取消思考时间

　　b、下载文件大小一定，不同量的虚拟用户

　　虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间

　　20 300k 下载页面 随机产生 30分钟 取消思考时间

　　50 300k 下载页面 随机产生 30分钟 取消思考时间

　　80 300k 下载页面 随机产生 30分钟 取消思考时间

　　100 300k 下载页面 随机产生 30分钟 取消思考时间

1、能发现到目前为止没有发现的缺陷的用例是好的用例：

　　首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

　　* 程序做了它应该做的事情

　　* 程序没有做它不该做的事情

　　因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

　　2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试;

　　不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护(别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化)上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。

　　在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。

　　除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。

　　在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30 - 40左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

　　3、测试用例设计是一劳永逸的事情;

　　这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。

　　这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

　　4、测试用例不应该包含实际的数据;

　　测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

　　5、测试用例中不需要明显的验证手段;

　　我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢?是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢?显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

对于刚进入软件测试工作岗位的新人，如何快速、健康的在职业道路上成长，作者谈了几点自己看法：

1、兴趣是最好的老师
　　对于软件测试工作，通常是比较枯燥的，如果没有兴趣很难做到持久。我最近参与了一个软件测试项目，在测试团队中，有三位是在校学生，他们以兼职的身份到公司上班，他们都是软件相关专业的本科生和研究生，基础都不错。但是，只有其中一位表现最突出，因为他很珍惜这份社会实践的工作机会，做事认真，找出了很多高优先级的Bug。
　　另两位同学，在参加项目不到1个月后就以各种理由退出了。在我与他们的交流中，其中一位说测试工作太枯燥了，没有挑战性，他更希望做软件开发的工作。这位同学由于不喜欢做软件测试，实际上他对软件测试技术缺乏基本的了解。所以他在7天的测试工作中，只找到了3个Bug（正常情况下，其他测试人员每天能找到5个缺陷）。因此，从绩效评比中他的成效最低。
　　另一位同学虽然愿意做软件测试，但是他觉得现在的黑盒测试太简单，学习不到测试技术的高级技巧，他更愿意学习白盒测试，能够自己测试软件源代码。而现在的项目没有这部分的内容，所以尽管他工作成绩也不错，但是积极性不高。
　　因此，建议同学们在寻找工作中，首先需要了解，你是否愿意做软件测试，愿意做白盒测试还是功能的黑盒测试，不要盲目的参与到工作中，否则对于用人单位，对于个人的成长都是浪费。

2、测试人员要学会思考
　　测试是个技术工作，需要学会主动思考。如果你遇到一个好的测试主管（组长），他会主动的解决你的测试实际技术难点，这是你的幸运。但是测试问题错综复杂，测试主管工作很忙，他没有时间解决你遇到的任何技术问题，需要你自己分析问题的性质，尝试各种解决方法，搜索网络上的文章，最好如果仍然解决不了才向主管求助。
　　我们反对遇到问题表现得很茫然失措，不要问一些很“弱智”的问题，否则主管认为你解决问题的能力不做，学习能力欠缺，这样对于今后的发展不利。
　　测试人员如何思考？根据问题的现象思考。问题是属于测试专业知识不足引起的，还是测试用例等测试文档模糊、错误引起的，是个别现象还是测试项目的其他内容都存在的普遍现象。测试要从模拟用户使用的角度展看，因此要用最终用的角度，分析问题的严重程度。
　　在询问最终的解决方法前，确保你根据自己的经验尝试了各种解决方法，并且尽量把你发现的问题和猜测，告诉测试主管，证明你已经主动思考了，但是没有找到好的解决方法，或者不能确定是否方法可行。

3、选择适合的测试学习材料
　　软件测试的技术博大精深，对于初学者该从何入手呢？可以从以下几个方面学习：
　　第一是公司提供的培训材料。测试新员工到公司后一般都要经过短暂的培训，这是学习的最好的第一手材料。针对性特别强，都是公司今后用到的测试知识的总结，针对性和实用性都很强。如果有不懂得问题，可以随时提出来，因为你是测试新人，不懂要问，任何人都不会对你的能力表示怀疑。
　　第二是借助测试项目的测试文档学习，包括测试计划、测试用例，测试缺陷数据库，可以先看看以前发现了哪些bug，这些bug是怎么发现的，有什么规律和特征，学习别人怎么写测试缺陷报告。
　　第三是阅读测试书籍和测试网站和论坛。这些内容很多，建议利用工作之后的时间，根据自己的知识有选择的选择测试书籍，先从基础知识阅读。正式出版的书的内容质量都比较高，而测试网站和论坛的文章良莠不齐，有些只是只言片语，很多还存在错误。因此，需要有一定的鉴别能力，否则会误导，浪费时间。

4、巩固测试知识基础
　　练武术需要先练“蹲马步”，否则直接学习刀枪棍棒等十八般武器，只能学到几招皮毛，甚至伤及自己，武林高手都是基础很牢固的，内功很深厚的。
　　做软件测试也是这个道理。很多出入测试行业的新人，希望走捷径，往往听信各种测试培训机构的宣传，认为参加几天的能力提高班，就可以步入测试高手的殿堂，这是错误的，也是要吃大亏的。
　　另一个错误就是还没有学会测试的基本概念，就盲目地学习各种大型商业自动化测试软件，结果花了很多时间和金钱，只是学会了工具的具体操作。到了实际测试项目中，无法有效利用工具解决实际测试问题。
　　实际上，作为测试新手，大部分都是从手工功能测试开始起步的，大型自动化测试只有成为测试高手，才有机会使用。另外测试工具的操作是很简单的技术问题，关键是如何发挥测试工具的作用，这需要测试策略。
　　所以，初学者要老老实实的学习测试基础知识，学习各种测试术语、测试概念、测试分类、测试的流程、测试项目的执行过程等。如果这些都不懂，今后的职业发展会成为限制。
　　学习是痛苦的过程，但是学习是增强技能的必然之路。学习测试知识没有捷径，需要日积月累，需要勤奋，需要思考，需要总结，从一点一滴学起。

5、不断学习行业知识
　　测试人员除了学习和掌握测试技术外，还需要不断学习行业知识，这是区别普通测试技术人员和测试行业专家的最好方法。
　　学习什么行业知识呢？根据你测试的软件的应用领域决定。例如，你正在测试的是电信行业的应用软件，那么你需要学习电信行业知识，包括术语、业务和行业技术。怎么学习呢？可以与客户交流，与开发人员交流，看专业书和文章。
　　学习行业知识是个不断进步的过程，每个行业都有很系统的知识架构，首先学习工作中最需要的理论和技术。然后有机会和兴趣的时候，不断细化和深入。
　　高级的测试人员需要精通测试技术，掌握行业知识，可以提供行业软件的测试和质量保证方案。对于初学者，要认识到经过不断努力，可以成为测试行业专家。千里之行，始于足下，目前最重要的是从测试入门知识开始。