常用的性能测试方法和测试要点.docx
《常用的性能测试方法和测试要点.docx》由会员分享，可在线阅读，更多相关《常用的性能测试方法和测试要点.docx（17页珍藏版）》请在冰点文库上搜索。
常用的性能测试方法和测试要点
常用的性能测试方法和测试要点
常用的性能测试方法和测试要点
2008-12-1613:
58:
04/个人分类：
转载好东西
常用的性能测试方法和测试要点
1、明确用户的性能需求（显示的和隐式的），性能测试点，找出瓶颈
1）用户直接需求的和使用过程中（行业经验）可能遇到的性能瓶颈点必须测试和分析到。
当然，客户不需要的，也没有必要去花时间和精力。
2）从中获取相应的性能测试参数，峰值和平均值。
3）客户的性能容忍度和系统所能承受的容忍度同样重要。
4）确认系统运行的最低硬件环境要求（虽然硬件便宜的多了，但客户能不能改造自己的环境还得客户说了算）
5）如果可以的话，将系统的容错性做为性能测试的一部分进行测试
2、测试对象和性能负载分布
1）基本的3个对对像：
C/S、B/S中的客户端和服务器，其中还有网络进行连接或中间件。
2）服务端可能分为数据端、业务端和服务容器。
3）跟据实际的测试结果合理的进行相应的性能负载分布。
3、负载、容量和压力测试逐一进行（如果需要）
1）更多的情况下，性能测试中出现的问题是最初的设计时应存在的问题。
如果可能，建议对相应的性能提前做测试和优化。
2）够用就好，不是所有的系统都要进行性能测试，一切以客户需求和实际需要为准。
4、测试点
1）CPU和内存使用（系统自身的原因）。
是否可以正常的使用和释放，是否存在内存溢出。
2）访问的速度（客户需求或是实际的应用要求说了算）
3）网络。
网络传输速度，网络传输丢包率。
（找些工具，有免费的）
4）服务器。
指令、服务应答响应时间，服务器对信息处理的时效性，服务器对峰值的处理（建议进行服务器优化或是进行服务负载均衡，有大量的文档对此进行描述）
5）中间件。
中间件在信息传递中的处理性能及信息处理的正确性。
5、测试和监控数据
1）均值下的持续运行（通过分析对整体的性能进行预测和评估）
2）短时间的峰值运行（分析系统的处理能力）
3）最低配置和最佳配置下的性能对比
4）多用户。
同时访问，同时提交。
5）对4中的数据进行记录和监控
6、选择测试工具
现有的测试工具太多了，不在一一列举。
适用就好，推荐开源的工具。
作为一名测试新人加入团队，大多数情况下，项目组成员都是一种热情欢迎的态度，并且主动提供力所能及的支持和帮助，如何快速熟悉项目业务和测试环境，尽快投入到实际工作中去，我谈谈个人的经验和一些看法，供同行参考：
1、寻找新公司的团队元老：
一般来说，一个新人进入新公司，都要指定一个师傅带一段时间，这也就是我们说的测试前辈。
很多时候，测试前辈都是经验非常丰富的测试高人，如何您和他相处融洽，关系不错，凭他个人丰富的业务经验，给您指点迷津，也许会比你自己摸索10倍的时间效果还好。
很多的测试新手，刚进入新公司时，自高自大，眼高收低，测试前辈都不愿意交，结果到了试用期转正答辩的时候，一问三不知，被迫离开公司，被炒鱿鱼。
这样的例子我看到的不下于10例，很可惜丢失了很多工作机会。
2、虚心的学习态度：
刚到一家新公司，保持谦虚的学习态度非常必要。
记得我刚毕业那年，公司招聘了一个测试主管，他有4到5年的工作经验，阅历算是不简单，也是我们心目中的牛人吧。
但是那个人，除了听总监的话以外，对于我们部门的其它人来说，他简直是自高自大，目中无人，根本不把部门里的其他人放到眼里，觉得部门的人都不如他。
他作为一个空降兵，老员工和新员工，对他都很冷漠，碰到什么问题，需要小组成员帮忙的时候，大家都不愿意帮助他，互相推诿，并且经理也找他谈了几次话，效果不明显，结果他呆了不到2个月，估计是自己觉得很不开心，被迫离开了公司。
其实，保持低姿态，谦虚的学习态度，必不可少。
3、阅读项目相关的文档：
一般来说，新人一到公司，就会安排到项目中去。
作为测试新手，快速阅读相关的“需求文档”、“详细设计文档”和“用户手册”特别关键。
我们能够通过需求规格说明书等文档，快速熟悉系统相关的知识，获取编写测试文档的相关信息。
如果项目已经编好了用户手册，您完全可以根据文档的步骤，一步一步傻瓜式的熟悉每项功能。
只有掌握的这些文档的精髓，测试才会变得异常轻松呀。
4、快速熟悉项目相关业务知识：
刚到新公司的测试人员，如果你是跳槽到以前做过的相近行业，有丰富的经验了，那么您熟悉业务没什么大的问题。
如果您换的新公司是您以前都没有接触到的行业，那你一定得努力一点，买些相关的业务知识看看非常必要。
我深有体会，以前从一家“通讯公司”跳槽到做“银行系统”的公司，业务完全两样，很多业务知识都是从零开始。
不过有一定的工作经验，学习起来也挺快，关键取决于个人是酷爱学习和坚强的学习毅力。
5、尽快介入了解被测试系统：
刚跨入一家新公司，如果被测试系统已经开发的差不多了，部分功能已经OK了。
你可以部署到测试环境下，尝试从直观测试的角度去尽快了解系统，尽快结合文档熟悉起来。
很多的时候，通过页面操作实际的系统比看文档效果好的多，并且印象更深刻，熟悉系统更快。
新加入公司的朋友不防试一试。
6、了解公司类似的相关产品：
大多数的公司，都不可能在每个行业都非常强，基本上都是在某一个较小的领域很强势，公司主要就是研发强势相关业务的产品。
所以说，相关的产品一般来说是很多的，如果要你测试的系统没有开发完毕，如果时间和条件允许，不妨先了解一下公司类似的产品，以便尽快熟悉起来。
大多数情况下，公司很多的产品都是相通的，大部分的产品是在不同的客户要求下，修改了部分功能和界面而已。
个人认为：
了解类似的产品，也是测试新手快速熟悉产品的一条捷径。
7、尽量多参加项目的各种会议：
每个项目，特别是在项目的启动阶段，大会小会不断，很多时候项目组成员抱怨居多，都认为很浪费时间，耽误开发进度。
如果作为测试新手的您这个时候加入，那太好了，多参加这样的讨论会。
大部分时间都是在讨论项目的重点和关键，如果大家意见不一致，必然要对不一致的东西展开细节讨论，您肯定是收益匪浅。
特别是对业务方面的讨论，您参加几次讨论，比您看10篇需求还强，并且理解也很透彻。
如果您对需求有所了解，但是部分功能模块还有问题，就可以在讨论会上随时提出来，大家一起讨论，共同解决。
如果有这样的机会，切勿放弃哟。
8、阅读类似项目已有的测试用例：
如果项目已经启动并进入了测试阶段，如果你在这个时候介入，通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。
这些测试用例也是您快速上手测试的重要参考资料。
如果还没有编写测试用例，你就介入了，那你就得重头开始，您可以阅读项目类似的测试用例，并结合以前项目的测试经验，根据公司相关的测试用例模板开始编写测试用例。
如果在编写测试用例中碰到您不了解和很难处理的问题，您可以记入测试需求疑问表格，等部门开会时，提出来大家讨论。
最好不要碰到一个问题就去问，经常打乱人家的思路，弄得别人嫌烦，那就不值了。
9、查看缺陷数据库中旧有的缺陷：
一般的测试缺陷跟踪系统，都是按模块来分类软件缺陷的。
如果老大给你分配了测试任务，你就可以有目的的去熟悉即将测试的模块缺陷。
登录系统后，对缺陷进行筛选，尝试按测试前辈的Bug描述步骤进行操作，看看是否能够重新缺陷这种方法能够借鉴测试同行的经验，尽快发现问题，避免测试的盲目性。
一来可以拓宽您的视野，避免递交类似问题的Bug或是重复的Bug，二来还可以为您快速熟悉被测试系统添砖加瓦。
10、必须明白自己领导是谁：
一般的员工进入公司，公司和部门领导很多，搞不清楚谁管我，碰到问题问谁谁可以帮忙解决问题如果真是这样那就麻烦了。
部门领导臃肿的情况实在是太多了，有的公司，既有2测试经理，又有几个测试主管，还有多个项目经理和研发总监，不知道工作向谁回报，对哪个领导负责。
弄得每个领导都回报，很累呀！
！
我的做法是：
测试项目中负责领导只有一个那就是测试主管，测试主管负责安排和分配每个测试人员的工作和任务，我直接Review测试主管。
如果项目中碰到有什么解决不了的问题，组内成员可以直接找我，同时我也定期加入项目参加部分测试，了解测试项目的一些进展情况，必要时还要找一些人谈心。
这样，工作汇报比较简单明了，很轻松。
11、熟悉与测试相关的管理软件的使用：
我说的这个测试相关的软件包括缺测试需求管理软件（如TestDirector或QC）、陷跟踪管理软件（如：
TestTrackPro、TestDirector等等）、版本配置管理工具软件（CVS、VSS，还是SVN等等），具体熟悉到什么程度，那就要看您的职位了。
如果您是一般的工程师，那你就只了解一般的使用就够了，如果您是测试经理，您不仅要了解一般的使用，还要更深层次的了解软件的权限和项目的配置，因为您要作为该软件的Admin，碰到问题大部分都由您搞定呀，高工资不是那么好拿的呀，哈哈！
！
！
如果作为新入职的您，连这些都不会，那你就得加把油了，不然到了测试启动阶段，你才开始熟悉管理软件，那么你觉的能够快速展开测试吗
12、注意沟通技巧，把握请教良机：
为了尽快熟悉项目，展开测试工作，沟通技巧必不可少。
您作为新入职的测试人员，尽量了解每个开发人员开发的模块和每个开发人员的性格特点，寻找一些共同语言，拉近与开发人员的距离，让他们对您产生好感。
只有这样，当您碰到问题的时候，他们才会鼎立的帮助您。
如果您与开发人员关系不好，看了就觉的很讨厌，那他们肯定不会帮助您的，更不原意和您配合，当您提错Bug的时候，他们就会抓住这些Bug不放，有时候还要说您什么都不懂，这样你就很郁闷，肯定呆不长久的，只有走人的份了，呵呵。
特别是开发人员很窝火的时候，您更要多一些理解和宽容，切勿火上浇油，您可以给他一些表扬，给他一些鼓励。
他一听准开心死了，总觉得还是您们最了解我，把您当成自己人。
这个时候，你再问开发人员问题，他也许态度就不一样了，他准会仔细的给你讲解，并且以后的什么事情，他也会百厌齐烦地帮助您的，因为他觉您最了解他们，无意识的把您当成了好朋友和哥们。
还有的时候，开发人员有空过来测试部门逛逛，准备和您交流时，一定要把握机会，和开发人员开开玩笑和一些必要赞赏，也能够调节和开发人员的关系。
总之，这一点做起来真的很难，如果做的好，那效果确实就不一样了。
欢迎各位同行继续补充指正！
！
项目背景：
此项目的客户是一个英国的软件公司，他们主要做设备管理系统、地产管理系统等，这一次是为Hertfordshire政府做一个软件用于各服务点（servicepoint）的数据收集、整理、评估，以前他们是用Excel来处理这些数据的，现在需要将其自动化。
后来客户决定将这个软件项目外包，我们公司就争取到了这个项目。
情况介绍：
这个项目主要包括两个部分：
前台的Web端，主要用于数据收集处理；后台管理端，用于管理用户、制定数据计算标准、导入数据等。
我们公司是将其作为一个加班项目来处理的，所谓加班项目也即也是说在每工作日规定的８小时内，不得做此项目，需要自己安排晚上或周末时间来完成任务。
若有问题需要与项目成员沟通，则一般采用邮件形式，或者是在中午以及临近下班的时间开小会。
在来这个公司前，对此我是闻所未闻的，后来了解到，大约这在外包公司比较常见，项目多任务紧时，为了压缩成本（大概也为了日后考虑），并不会立即招人，而是将部分小项目以加班项目的形式分配下来，当然，项目奖金也是很可观的。
然而加班项目无论在成员沟通、时间进度把握以及项目成员的心理认知都会存在一定的问题，所以，这也就为项目后来的进展埋藏了不少的隐患。
还值得一提的是，公司的很多项目都是以ODC报价，可是这个项目却采用的是固定报价形式，不管你花多久的时间做，最终成功交付了，才能得到所有钱。
这种形式本身没多少不对，可是，有时在一种心理的影响下，可能就会令项目进入一个恶性循环。
我是今年６月中旬应聘进入公司的，从另一个测试人员手上接手了这个项目的测试任务。
当时了解到，按照最初的计划，还有一个月的时间就该交付系统了，而此前交付某一部分时，因为延期，使得客户很不满意，而原因就是最初低估了工作难度而致实际使用时间大大超过预算。
我进入项目组时，成员是这样的，有一个项目经理，一个测试人员，五个开发人员，不过，几天后我明白了，实际只有三个。
当时之所以有五个，是因为其中两个才开始介入，为另两个的退出作准备。
后来，基本上就是一个负责WinForm，一个负责Web，另一个技术比较牛、负责的项目多，只有当Web有难题时，就会找他出山。
在我加入前，包括测试人员的所有项目成员都是把它当作加班项目做的，我因为没有其他项目，所有就当作正常项目来处理了。
在正式介入测试之前，我大概花了三天的时间理解需求，毕竟产品已基本成形，可以一边用一边读需求，直观容易多了。
但即使在这种情况下，我在后来的测试中还是渐渐发现当初对很多数据处理的细节方面是没有理解透彻的。
那时，摆在我面前的难题有三个：
一是所有项目文档都是英文，报告bug也要用英文，尽管我自诩英文读写能力不错，可还是花了好些时间才适应；二是尽管项目已进入中后期，除了mantis上的bug，没有任何测试方面的文档产出，包括测试计划、测试用例等；三，内部成员之间的沟通不及时，因为加班项目的特殊规定，有问题只能等到中午或下午下班后才能沟通，这种情况下，不可避免地会影响测试及至项目进度。
但是后来渐渐发现，问题远不止这三个。
由于是外包，我们的直接客户却并非最终客户，这就有两个问题，一是我们提交版本后，他们要测试，然后还要交给最终客户测试，这就使得每次反馈的时间拖长，由于没有新需求做，所以这边就只能处理等待状态；另一方面，最终客户反馈回来的bug，好些都是颠覆了原来的需求，更有甚者，有的还会改过来又改回去如此这般地往返几次，虽然客户不乏真诚地道歉，但是打击项目成员的积极性是不可避免的，同时，以后对于客户再提出的bug，不免报怀疑态度，大大降低了我们对客户的信任度。
而对于用户的需求，又只包括了功能方面，对性能等方面的需求，没有在前期沟通确定，导致项目待结束时，客户突然提出，这种性能是不可接受的，我们不得不对Web部分大刀阔斧地进行修改。
而后导致的一系列问题的处理，大大延迟了项目的进度。
上面都只说的是一些比较客观的原因，有些主观原因也是不可规避的。
首先检讨我自己，由于介入项目匆忙再加上自己测试能力有限，没有及早地发现某些bug；另外，自己在某些方面的认识上，也有待加强，以web的性能为例，一直以来，我都觉得速度不理想，尤其是数据大的情况下，但当时考虑到页面处理的特殊性（每个页面似一个excel的sheet，每个cell里都包含有控件，并且cell与cell之间还有大量的数据关联处理，而客户又要求不分页处理）以及客户没提这方面的需求，我也就没有这认为应该作为一个bug报告出来，而待项目接近尾声时，客户却要求我们改进性能。
在采用了诸多方法，均达不到用户理想的速度时，最终通过与客户沟通，采用了分页形式。
如果我能够不把眼光局限于浅显的bug，而多从整体或是用户角度去考虑，这个问题或许就可以早日提出解决，也不会引起那么多的后续问题。
最后，作为一句测试人员，我不应该放弃原则。
前面已经说过，这个项目是固定报价，项目拖得越久于我们而言是越不利的，可在这种因素的影响下，我们项目时间大大逾期，大家尤其是开发人员就不免急躁。
同时，由于客户多次报一些与起初需求不符的bug，也令开发人员莫名窝火。
在这种情况下，bug就分为两类对待了，客户报的都是高优先级，测试人员报的都是低优先级，并且总是认为只要不是太严重，且客户没报不修改也罢。
后果可想而知，一方面，bug总归是bug，始终还是要被客户发现的；另一方面，对于测试人员而言，这是一种比较尴尬的境遇，很容易产生消极心理。
对于整个项目而言，除去因是加班项目而引起的一些沟通不及时的问题而外，也还存在一些问题。
比如，需求方面不完整，这又得提到性能问题了，如果在最初沟通需求时，在此问题上能与客户达到一致，在设计过程中，必不会漏考虑这块儿。
还有，文档不完善，即至项目完成，除需求文档、bug报告而外，仍没有其他文档产品，这于一个项目而言是危险的。
另外，责任心问题，在项目中出现过多次这种情况，对于一个bug，开发人员始终认为无法处理，而在客户一直强调要解决的时候，最后还是想办法fix了，当然很多时候是那位比较牛的开发人员露面了。
如果遇上这种问题后，多沟通或者是有更强的责任心，也不会令客户光火。
最后，在项目管理上，或许还是有些疲软，尤其是后期阶段，在所有项目成员心思都比较涣散时，项目管理人员应该更坚持原则。
说了这么多，全是问题，其实闪光点也是不缺的。
比如，虽然沟通不便，大家也会抽出时间定期开小会，介绍自己的情况及问题；还如，当项目组遇上了难题时，大家能够齐心协力地想办法解决掉；另外于我而言，才进公司时，项目经理给了我很大的帮助和信心，而在最初阶段，有时报的bug不正确或是难以理解，开发人员也没有责难；等等。
作为我进入公司后的第一个合作团体，他们之中的每一个人我都是很感激的。
总结：
此项目终于在计划的deadline之后几月的11月中旬成功交付，在拖了如此之久后，大家心里已没多少成功的喜悦。
前事不忘，后事之师，于我而言，在忘掉这个项目之前，做做总结也许是很重要的。
当然，有了前面这一大篇幅的铺垫，总结将是十分简洁的：
1.需求沟通阶段，一定要尽可能地考虑全面，不只是功能、界面，还包括可接受的性能标准等方面。
2.在项目启动之初，就应该确定合理的内部沟通方式，确保不会因为沟通障碍影响项目成员及至整个项目组的进度。
3.无论时间多紧迫，必要的文档还是要有的，哪怕只是一个大纲也好。
4.无论是测试人员还是开发人员，遇上问题要尽早抛出，即使不一定得修改，拿出来讨论后大家有了这样一个意识，总错不了。
5.遇上解决有难度的问题，应该只有两种方法：
一是想尽一切办法（如请教高手）解决；二是让客户了解解决的成本，希望他能妥协放弃，而不应该有第三种：
拖延。
6.无论是对于bug，还是对于客户，任何时候，我们都不应该抱有侥幸心理。
作为项目成员，每一个都应该对质量负责，而不应该只是测试人员，更不应该是客户。
7.项目管理上，强硬也许比疲软更有效。
即使强硬会让项目成员一时难受，但最终会另整个项目组受益的。
大约因为自己是公司项目规范检查小组的成员之一，不禁就会考虑到这诸多方面。
而自己加入公司不久，所处的项目又有如此多的问题，所以当我检查其他人时，总会有些心虚。
不过，意识到了就是一个好现象，待等到机会加入一个新项目，我希望自己能做得更好。
明确测试目的，熟悉项目的测试进度。
设计测试案例的时候，需要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数。
测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。
测试用例设计一般包括以下几个步骤：
1、测试需求分析
从软件需求文档中，找出待测试软件/模块的需求，通过自己的分析、理解，整理成为测试需求，清楚被测试对象具有哪些功能。
测试需求的特点是：
包含软件需求，具有可测试性。
测试需求应该在软件需求基础上进行归纳、分类或细分，方便测试用例设计。
测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
2、业务流程分析
软件测试，不单纯是基于功能的黑盒测试，还需要对软件的内部处理逻辑进行测试。
为了不遗漏测试点，需要清楚的了解软件产品的业务流程。
建议在做复杂的测试用例设计前，先画出软件的业务流程。
如果设计文档中已经有业务流程设计，可以从测试角度对现有流程进行补充。
如果无法从设计中得到业务流程，测试工程师应通过阅读设计文档，与开发人员交流，最终画出业务流程图。
业务流程图可以帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。
从业务流程上，应得到以下信息：
A、主流程是什么
B、条件备选流程是什么
C、数据流向是什么
D、关键的判断条件是什么
3、测试用例设计
完成了测试需求分析和软件流程分析后，开始着手设计测试用例。
测试用例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等。
在用例设计中，除了功能测试用例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。
黑盒测试的测试用例设计方法有：
等价类划分、边界值划分、因果图分析和错误猜测，白盒测试的测试用例设计方法有：
语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖。
在这里主要讨论黑盒测试。
在设计测试用例的时候可以使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设计：
功能测试：
测试某个功能是否满足需求的定义，功能是否正确，完备。
适合的技术：
由业务需求和设计说明导出的功能测试、等价类划分
边界测试：
对某个功能的边界情况进行测试。
适合的技术：
边界值划分
异常测试：
对某些功能来说，其边界情况无法简单的了解或某些操作不完全是正确的但又是可能发生的，类似这样的情况需要书写相关的异常测试。
适合的技术：
由业务需求和设计说明导出的特殊业务流程、错误猜测法、边界值分析、内部边界值测试、
性能测试：
检查系统是否满足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。
内部性能因素包括测试环境的配置，系统资源使用状况；外部因素包括响应时间，吞吐量等。
适合的技术：
业务需求和设计说明导出的测试
压力测试：
压力测试又称强度测试，主要是检查系统运行环境在极限情况下软件运行的能力，比如说给一个相当大的负荷或网络流量给应用软件兼容测试：
测试软件产品在不同的平台，不同的工具，相同工具的不同版本下功能的兼容性。
4、测试用例评审
测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，需要进行测试用例的评审。
测试用例评审一般是由测试leader安排，参加的人员包括：
测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。
测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。
5、测试用例更新完善
测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。
软件的版本升级更新，测试用例一般也应随之编制升级更新版本。
测试用例是“活”的，在软件的生命周期中不断更新与完善。
不以物喜，不以己悲，心静自然凉
一般问题的产生，必定可以找到原因，只有找到问题的根本原因之后才能很好的解决。
个人认为产生上述问题可以从以下两方面思考。
第一，自身问题
也许你是个新人，也许你是刚毕业生，也许你刚进入某行业，也许是一个全新的项目等，，总之，在你手中的模块是全新的，你以前从没接触过的。
这种情况下也许你找不出很多BUG，是有点正常的，但你不能一直让它正常下去，首先，你应该先把心态调整下，心想，反正我现在可能是垫底的，不可能再差了，现在唯一的路就是进步了，心态好了后，进步就快了，下面是一些进步的方法：
1、尽快熟悉行业知识，比如游戏就应该熟悉游戏方面的，安全就应该熟悉病毒等
2、尽可能熟悉正在测试的项目
3、尽可能熟悉被测试的模块，包括和该模块开发人员打好关系，可以进一步熟悉该模块，进一步找出隐藏的问题
4、向公司测试高手学习方法，主要是他们的测试思想
5、业余时间多看看公司以前项目的测试文档，努力学习里面的测试思路，方法，努力提高
6、自身测试技能不足，导致测试不深入，就需要学习更深，更多的测试技能，尽可能熟悉再熟练
升级会员 