3、可以一条测试数据覆盖多个测试用例，这样可以提高效率，前提是程序的质量还可以或者可以根据测试结果（结果数据和log）定位是哪个功能点的问题。

　　4、如果时间充足的话，测试要在安静的环境中不慌不忙地进行，这样容易联想到更多的测试功能点，也可能因此发现更多的bug。如果测试太匆忙，通常测试人员只是想尽快地执行完所有测试用例。

　　5、如果测试还要进行多个版本，则需要不断完善测试用例，并总结为什么一开始会遗漏这些测试点。

　　6、测试的目的是发现bug，不是执行完所有用例或者覆盖尽可能多的路径。所以如果全面的测试已无益于发现新的bug时，要让测试人员充分发挥自己的主观能动性，随机地对可疑的地方进行测试。

　　7、发现bug时要确定自己操作和理解没有问题再向开发人员提出，而且要注意表达方式

　　8、平日最好能和开发人员保持不错的关系，这样有利于测试的进行。

　　9、不要迷信功能测试的自动化，我认为只有在版本稳定后还需要进行多个版本的测试时才需要测试自动化，而且要求测试人员都可以熟练使用测试自动化工具。自动化测试的最大困难可能是需求和界面的频繁变化。

　　功能测试思路：

　　以客户需求（业务需求）为基础，数据为指导。

　　拿到一个成品，首先熟悉需求，要想更细的了解最好参照开发需求（功能说明书）以及测试需求。如果这些文档并不齐全，只能靠自己的嘴巴和脑袋了。首先要用心分析需求文档，每个细节每个业务流程。对于不懂的或者与现有系统矛盾的地方，及时张开自己的金嘴去问熟悉这个系统的相关人员。

　　需求分析后，最好是能画出一个功能流程图。对于每个子功能，尽可能把各种可能的路径都显示在这张图上面。

　　对于如何画好这张图，这个时候最好的方式采用数据驱动的方式。每个模块之所以能关联在一起，追根揭底都是因为它们有数据传递。分析出数据流的流向，一般都能把握住功能与子功能的各个分支，尽量做到无遗漏。

　　跟踪bug修改时，要注意验证bug的侧重点，如果又牵扯出其他问题，则关闭此bug，重新提新的bug，要快速，有重点，不要掉到坑里在没有按照测试用例来测系统前，能测试一部分问题，为什么按照测试用例来执行测试后，就发现不了问题了呢？这是不正常的。说明我们在写测试用例的时候还不够专业，我们要先把功能点想全了，按照一定的思路和逻辑写出测试用例，然后依次执行。当用户发现问题的时候，我们重复建立记录，看是否报错。

　　测试的思路问题：不同类型的项目、同一个项目的不同阶段，侧重点都是不同的，在进行测试前，首先要清楚自己测试的重点是什么，该从哪方面进行测试。同一个功能点，由于测试角度不一样，测试用例也不同。

　　任何一件事情，都要整体规划，分布实施。着眼点要从全局到局部，不要太狭隘了。

　　目前几项工作的进度，有没有什么问题？

　　通过查看每个人在QC上的测试用例编写和执行情况，分析当前团队在测试工作中的问题：例如盲目，分不清侧重点、应用QC时不能显示自己的工作量。

　　遇到建议的功能，先行提交，有时候不能考虑开发人员的想法。

　　测试服务器的维护很重要，不能让开发人员随便修改测试环境，如果必须修改，需要经过测试团队内部的认可，不能因为己方的行为给他人造成麻烦……（以上言论仅代表作者的个人观点，不代表51Testing观点）