注意对一些元数据增删改后的测
试，尤其注意如有其
他地方引用了这些属性，则禁止相关操作，这是系统的关联性注意与数据库的关联查询在测试初期，要分清主次，轻重缓急，先对主流
功能进行测试。
不要在已经验证为错误的功能上延伸测试，错误的错误还是错误注意界面中一些默认值的设置，增添系统的人性化设计如果需要
进行下一个版本的测试，需要群发邮件。
测试执行分以下几个阶段：冒烟测试、功能测试、容错性测试、性能测试、
UI测试。冒烟测试是主要功能测试，是线的测试。功能测试是细分的功能点的测试，是点的测试。容错性测试、性能测试的测试点不一样，要看不同的项目涉及的
业务，以用户的关注点来定。
UI测试主要针对三点：正确、规范、美观协调。
经验：程序中所有可能有的错误和容易发生
错误的特殊情况。
测试人员最好能在开发开始之前，总结出一个列表，列表中列出需要开发人员统一处理的一些细节，比如表单中表头和表内容
用什么字体字号；是左对齐还是居中；翻页控件是放在表单左下角还是右下角还是居中；标点符号是用中文半角还是全角；选择框和下拉菜单中的内容按什么排序；
搜索结果是否需要排序；错误提示是弹出窗口还是显示在原界面；错误提示语也应尽量统一风格；查询后是否要保存查询条件；浏览器的前进后退是否需要限制等
等。项目经理最好统一给开发人员讲一下这些规矩，这样会在测试时省很多事。
尽可能考虑到测试过程中的风险，比如测试环境的问题、部署失
败的问题、开发延期的问题、人员变动的问题等。
1、测试用例要因人而异，如果自己已经很熟练了，测试用例可以只是简单的提示，不需写出
详细的执行步骤和测试数据，以免因为无谓的文档浪费太多时间。如果很可能别人还要复用你的测试用例而且有充足的时间，这时就可以把测试用例写详细点。
1）如果时间允许，测试一个页面时，要把这个页面的所有功能点的正常异常情况都测完之后再去测下一个页面，这样不容易遗漏。大多时候时间都不很充足，这
时要先测主要流程和主要的功能点，这些完成之后再去测细节和异常情况，因为并不是有bug就不能上线的。
2）至于测试数据需不需要在设
计测试用例时就写出需要根据实际项目情况来定，我一般认为最好把测试用例都写完之后，再准备测试数据，一条数据可以覆盖多个测试用例，这样很可能四五条数
据就可以覆盖十几个测试用例，这样可以提高效率。教科书通常认为一条测试数据最好对应一个测试用例，这样测试执行失败时就容易定位问题出在哪里。但实际情
况是只有极少数的测试会执行失败并因此发现bug，但如果因为这极少数的失败的情况来降低整个测试执行的效率就显得缺乏实践性了，况且并不是说一条测试数
据覆盖了多个用例时就不容易定位错误的根源。所以测试要根据实际情况灵活进行。
3）如果要写详细的测试用例，就一定要写的非常的清楚明
了，最好让一个不懂项目情况的人也能根据用例执行测试。而且测试用例和测试数据中的关键值一定要用颜色标出。最好还能写出每条用例的测试目的，这样方便日
后别人补充你的测试用例。
2、如果发现了很多界面性的小问题，不要连续提出，最好先提一两个功能性的问题，再提一两个界面性的问题，这
样间隔着提bug有利于开发人员接收，免得他把你提的连续的四五个界面性的bug都拒绝了。另外，一个bug
里最好不要既包括功能性问题又包括界面性问题，这样有可能开发人员只解决了功能性问题就把bug 关了。
3、可以一条测试数据覆盖多个测试用例，这样可以提高效率，前提是程序的质量还可以或者可以根据测试结果（结果数据和log）定位是哪个功能点
的问题。
4、如果时间充足的话，测试要在安静的环境中不慌不忙地进行，这样容易联想到更多的测试功能点，也可能因此发现更多的bug。如果测试太匆忙，
通常测试人员只是想尽快地执行完所有测试用例。
5、如果测试还要进行多个版本，则需要不断完善测试用例，并总结为什么一开始会遗漏这些测试点。
6、测试的目的是发现bug，不是执行完所有用例或者覆盖尽可能多的路径。所以如果全面的测试已无益于发现新的bug时，要让测试人员充分发挥
自己的主观能动性，随机地对可疑的地方进行测试。
7、发现bug时要确定自己操作和理解没有问题再向开发人员提出，而且要注意表达方式
8、平日最好能和开发人员保持不错的关系，这样有利于测试的进行。
9、不要迷信功能测试的自动化，我认为只有在版本稳定后还需要进行多个版本的测试时才需要测试自动化，而且要求测试人员都可以熟练使用测试自动
化工具。自动化测试的最大困难可能是需求和界面的频繁变化。
功能测试思路：
以客户需求（业务需求）为基础，数据为指导。
拿到一个成品，首先熟悉需求，要想更细的了解最好参照开发需求（功能说明书）以及测试需求。如果这些文档并不齐全，只能靠自己的嘴巴和脑袋了。
首先要用心分析需求文档，每个细节每个业务流程。对于不懂的或者与现有系统矛盾的地方，及时张开自己的金嘴去问熟悉这个系统的相关人员。
需求分析后，最好是能画出一个功能流程图。对于每个子功能，尽可能把各种可能的路径都显示在这张图上面。
对于如何画好这张图，这个时候最好的方式采用数据驱动的方式。每个模块之所以能关联在一起，追根揭底都是因为它们有数据传递。分析出数据流的流
向，一般都能把握住功能与子功能的各个分支，尽量做到无遗漏。
跟踪bug修改时，要注意验证bug的侧重点，如果又牵扯出其他问题，则关闭此bug，重新提新的bug，要快速，有重点，不要掉到坑里在没有
按照测试用例来测系统前，能测试一部分问题，为什么按照测试用例来执行测试后，就发现不了问题了呢？这是不正常的。说明我们在写测试用例的时候还不够专
业，我们要先把功能点想全了，按照一定的思路和逻辑写出测试用例，然后依次执行。当用户发现问题的时候，我们重复建立记录，看是否报错。
测试的思路问题：不同类型的项目、同一个项目的不同阶段，侧重点都是不同的，在进行测试前，首先要清楚自己测试的重点是什么，该从哪方面进行测
试。同一个功能点，由于测试角度不一样，测试用例也不同。
任何一件事情，都要整体规划，分布实施。着眼点要从全局到局部，不要太狭隘了。
目前几项工作的进度，有没有什么问题？
通过查看每个人在QC上的测试用例编写和执行情况，分析当前团队在测试工作中的问题：例如盲目，分不清侧重点、应用QC时不能显示自己的工作
量。
遇到建议的功能，先行提交，有时候不能考虑开发人员的想法。
测试服务器的维护很重要，不能让开发人员随便修改测试环境，如果必须修改，需要经过测试团队内部的认可，不能因为己方的行为给他人造成麻烦……
