一、 测试人员应该注重业务知识的学习
测试的时候应该能够从用户的角度出发， 能够分权限， 分角色按照业务流程来进行测试。现在的软件开发大多都是面向对像基于W E B 结构的开发， 所以在测试的时候就是要分角色、分权限， 根据业务知识和业务流程按
照不同的用户、不同的岗位进行测试。只有这样才能够测试出来系统在权限和角色的划分中的问题。

二、 与开发人员的沟通
测试人员的工作不只是要找出B U G ,而且是更大程度上要提出更多的解决B U G 的方法和建议。在不能提出方法和建议的时候要尽量详细和清楚的描述B U G 产生的前后所做的操作。能够重现B U G ,也是测试人员的基本职责。开发人员经常由于工作比较紧， 所以更希望测试人员能够简洁、明了的来描述B U G。如果能够给出他们合理的改B U G 的建议和方法， 他们也会对测试人员刮目相看， 从而建立更好的合作关系。
三、 应该注重数据库知识和简单代码的学习
如果能够了解到更多的数据在数据库中的存储情况， 将有利于查找测试原因更有利于和开发人员的沟通。例如， 在一次的测试过程中发现数据字典， 增加功能无效， 就是增加过的记录在页面上看不到， 通过对数据库的查询发现， 记录已经正确存储在数据库中，只是页面上没有表现出来。当把这一情况告诉开发人员时， 开发人员很快就分析出了错误的原因， 并能够在最短的时间内对程序进行修改。代码的学习， 最基本的是可以看懂一些简单的代码。进行软件的性能测试时， 需要从代码的合理性、是否造成内存的浪费、是否存在不合理的竟争等多个方面来考虑软件的性能问题。如果以后想要往白盒测试方向发展的话， 那么代码的学习就是必须的了， 而且还要学习大量的复杂的代码。
四、 需要学会区分B U G 的严重程度和可修复程度
有时由于缺少对开发知识的了解， 测试出一个B U G 之后， 不知道修复的难易程度和产生错误的原因。开发人员会说出这个不是一个B U G ,就会对这个B U G 进行关闭， 而以后用户会认为它确实是存在的 一个B U G .盲目的听从开发人员我想也是初学测试者的一个误区。做为一名测试人员其实有时需要从经济学的角度考虑B U G 的严重程度和可修复程度对整个项目所带来的影响。
五、 测试方法和测试流程的规范
我所在的公司项目比较多， 项目比较紧。很多项目都是项目初期的时候还写测试用例进行测试方法的讨论， 后来由于一些实际情况把这些用例和方法都丢弃了。这样导致在测试的过程中都是随意进行测试。程序的有些地方都测试过很多遍， 而有一些地方却没有测试到， 造成了大量的重复劳动和低效率的劳动。
六、 测试工具的学习
一般的功能方面的测试， 还是通过简单的编写测试用例来进行测试。只有在性能测试时偶尔会用到L O U N D E R R U N E R。但是测试的发展方向还是用工具来代替人工测试，减少人力，成本、节约时间。况且性能测试、压力测试也需借助工具来测试。所以掌握用工具测试时，对测试人员来说是必须的。