1、最好是能得到一个好的测试需求，这样就可以省去你自己做需求的过程，而通过这个好的需求你还可以更好地把握系统本身，为将来的测试提供一个好的帮助；
2、比较明白和细致的开发人员，这个有助于你在遇到问题的时候寻求帮助，减少开发人员和测试人员之间不必要的冲突，因为就像测试与开发之间的关系说的不好听点有些类似于警察与小偷之间的关系，有冲突是必然的，你净找人家的麻烦任何人都不会舒服的，大家说呢？！
3、提供比较完善的用户帮助手册，这样即使是你没有使用过该软件也可通过流程来熟练自己的操作，但是也只是了解和熟练而已。
4、我要说的比较关键的一点就是：必须了解相关的业务。是的，就是相关的业务。
有很多的业务不是简单地用一个流程就可以看明白和操作明白的，他背后有强大的理论支撑，作为一个测试人员，如果单单去根据手册跑完流程是简单的，但是我相信，这样的测试肯定是不完全的，其中可能隐含的原则性问题你肯定也将发现不了，因为你不了解业务，你只能从别人给你的一点点东西中来寻找错误，那么如果所给你的东西本身就是个错误哪，你又会怎么办呢？
举个例子，这个也是我曾经遇到的事情，建设银行的U盾，大家都知道银行的U盾有密码，并且只能在使用的时候一次实验10次，然后就会锁定，大家肯定说这有什么稀奇，但是大家不知道的是，以前建行的U盾在实验10次以后就报废掉，因为它的密码是不能被重置的，这个估计曾经对建行U盾做过测试的人员没有想到的吧，但是这个却是事实，因为这是硬件本身的问题，同时也是软件的问题。
5、所以说要想快速掌握被测试软件业务流程，不能仅仅从上面几个方面来把握，入手可以，但是把握还是不够，我们还必须在长期的工作过程中了解业务流程背后的东西，有了足够的理论作指导，将来在把握起被测试软件的流程上才能更快速，更准确，更全面。
2、比较明白和细致的开发人员，这个有助于你在遇到问题的时候寻求帮助，减少开发人员和测试人员之间不必要的冲突，因为就像测试与开发之间的关系说的不好听点有些类似于警察与小偷之间的关系，有冲突是必然的，你净找人家的麻烦任何人都不会舒服的，大家说呢？！
3、提供比较完善的用户帮助手册，这样即使是你没有使用过该软件也可通过流程来熟练自己的操作，但是也只是了解和熟练而已。
4、我要说的比较关键的一点就是：必须了解相关的业务。是的，就是相关的业务。
有很多的业务不是简单地用一个流程就可以看明白和操作明白的，他背后有强大的理论支撑，作为一个测试人员，如果单单去根据手册跑完流程是简单的，但是我相信，这样的测试肯定是不完全的，其中可能隐含的原则性问题你肯定也将发现不了，因为你不了解业务，你只能从别人给你的一点点东西中来寻找错误，那么如果所给你的东西本身就是个错误哪，你又会怎么办呢？
举个例子，这个也是我曾经遇到的事情，建设银行的U盾，大家都知道银行的U盾有密码，并且只能在使用的时候一次实验10次，然后就会锁定，大家肯定说这有什么稀奇，但是大家不知道的是，以前建行的U盾在实验10次以后就报废掉，因为它的密码是不能被重置的，这个估计曾经对建行U盾做过测试的人员没有想到的吧，但是这个却是事实，因为这是硬件本身的问题，同时也是软件的问题。
5、所以说要想快速掌握被测试软件业务流程，不能仅仅从上面几个方面来把握，入手可以，但是把握还是不够，我们还必须在长期的工作过程中了解业务流程背后的东西，有了足够的理论作指导，将来在把握起被测试软件的流程上才能更快速，更准确，更全面。
