1.测试执行的原则
(1).先安排新功能的测试，后安排完整的功能测试(包括可能会受影响的原有的正常功能)；
(2).先进行某一两个平台的测试，后进行广泛的环境、平台组合上的测试；
(3).先安排功能的逻辑和行为方面的测试，后安排界面测试；
(4).在代码冻结前，要为功能测试留下一个特定的时间段、用于最后的缺陷验证及其回归测试
2.测试任务安排
(1).针对个人的特定和特长来安排适合工程师的特定任务；
(2).结伴测试，几轮过后可以交叉互换测试；
(3).将关联性很强的若干子任务安排给一个人；
(4).评估任务量时，要留有余地，一般可在正常估算值上+15%
2.1 测试任务安排的一般步骤：
(1).评估每个模块的测试时间；
(2).分析软件模块之间的关系、关联性和相应工作量组合成可测试模块
(3).根据人员特点，将组合的模块分配给各测试人员
(4).哎若干轮测试结束后，交叉互换测试的模块组合。
3.测试环境的准备：
3.1.测试环境的可靠性
(1).性能测试环境与功能测试环境独立；
(2).功能测试环境应该有2套，作为当前版本和前一版本，这样每次部署都不影响当前正在使用的环境；
3.1测试环境的多样性和复杂性
4.创建测试套件：
4.1 功能测试要经过的测试执行的子阶段：
(1).新功能的快速测试；
(2).完整的功能性测试，并集中在逻辑性、行为方面的测试；
(3).界面、使用性测试；
(4).Ad-hoc测试和回归测试；
4.2 功能测试套件的创建：
4.2.1 依据功能点的测试用例组合
(1).新增的、最新修改的、改动大的模块的测试用例优先全部选择
(2).改动小的、受影响大的模块，大部分测试用例被选择
(3).收影响小的模块，少量的测试用例被选择
(4).不受影响的模块，不选择测试用例
4.2.2 测试用例的环境组合
(1).系统、网络、浏览器、手机等各种环境
5.功能自动化
5.1 功能自动化平台
待续......
5.2功能测试自动化的执行
(1).执行自动化测试之前，需要有配置清单准备测试环境，初始化数据等，该处的配置清单最好是可配置的，且不同的环境有一套完整的环境配置，便于快速集成；
(2).测试执行过程，要有相应的容错处理逻辑，且各模块之间尽量无关联关系，这样即使有模块失败了，也不影响其他模块的正常执行；
(3).结果的分析，自动化结果完整后，最关心的应该是哪些失败了，为什么失败了。所以测试结果应该包含完整的操作日志(文件记录)、测试数据操作结果、异常日志等，如果涉及浏览器操作的，可以使用录像软件配合查问题。
6.用户界面与适用性测试
(1).符合标准和规范，可参考业界标准
(2).直观性、灵活性、舒适性、实用性
7. 回归测试
7.1 回归测试方法
(1).基于风险选择测试，首先执行关键的、风险系数大的和可疑的测试；
(2).基于操作剖面选择测试，优先针对那些最重要或最频繁使用功能的测试用例；
(3).再测试修改的部分，回归测试局限于被修改的模块和它的接口，在条件允许时，回归测试尽可能覆盖受到影响的部分。
综合运用多种技术，采用多种策略组合。
8.软件缺陷的报告
8.1 缺陷的属性
比较重要而容易被忽略的几点：
(1).环境(web端强调浏览器+操作系统，app端抢到手机型号+操作系统)
(2).产生原因，强调需要开发规范填写
8.2 软件缺陷的有效描述规则
(1).单一准确，每个报告只针对一个软件缺陷
(2).完整统一。提供完整、前后统一的产生缺陷的步骤和信息
