1.手工测试：
整体流程框架：
提测 - 测试策略 - 手工测试 - 提交反馈
需求评审：
（1）明确功能测试验收点，在最初的测试优先保证验收点。
（2）流程上保证对应的用例明确正确。
提测：
（1）提交测试后，测试人员需要整体了解提测内容的最核心风险点，需要首先确保提测后的内容无重大错误，及需要与开发共同明确可能风险点。
（2）需要明确验收点，即提交测试后到测试完成时，哪些点是我要明确验证的（明确后，可以和开发确认下），在时间有限资源有限的情况下，哪些点的优先级最高及最终的发布版本是必须要验证通过才敢上线的，为之后的测试能够指明方向，再合理安排。
测试策略：
（1）在明确了验收点之后才进行测试策略的安排，即最后我要得到什么-如何得到的问题，如果不明确验收点和一定要通过的点是什么，那么策略的安排，是缺乏针对性的。
（2）测试用例需要是可靠的，不明确的用例是需要被避免的，主流程往往通过高等级的测试用例来保证基本可用性，如果不明确测试用例在一轮版本测试后，没有及时修改订正(需要通过具体流程保障我要测的用例正确明确，如互审)，避免用例量越来越多，不靠谱不明确的用例越来越多，足够清晰明了正确的测试用例将对缩短测试时间有帮助，对于项目我觉得是良性循环（当前用例有误是某个时间节点统一修改，修改的准确性和及时性很差，同时没有互审了，造成此问题的根因是新用例的产生没有流程保证用例准确性 - 用例的修改没有流程保证修改准确性）。
（3）测试用例尽可能将有关联的统一分配测试，在合适的阶段需要输出关联模块的测试数据报告。（在实际项目中，往往都是一个人负责一整个大模块的测试，因此默认就是关联模块了）
（4）手工测试存在重复性，重复性操作往往产生思维惯性，有可能导致漏测，测试策略的安排就需要考虑到人性，即需要有合适的方式方法通过策略本身的整体性来保证验收点的正确性，尽量避免一个人的测试失误导致验收点不通过(个人觉得这个是测试过程中的一个难点，不同场景和流程，应该有针对性的一套保证措施，前提还是明确验收测试点)，在策略合理的情况下，能达到不因个体的问题导致验收点失败而未被发现，但通过策略发现验收点不通过而个体未发现该问题是需要承担一定责任(这个点是自己脑子里的一个念头，暂不清楚怎么做。如果验收点是明确的，能保证验收点，无法完全覆盖所有测试点，但尽量做到整体可控)。
（5）bug的提交和跟踪，bug描述简单明了，不废话。附件材料需要明确添加清楚，换位思考就是bug解决者能明确他这个bug的问题点，并获取他想要的辅助信息。bug解决过程中，可能更需要关注的点是是否引入新bug，及需要跟开发明确，验证该bug，我还需要进行哪些测试点的测试，这些主观补充的测试，也是需要明确的，即有迹可循可追溯的。遗留bug上，需要明确遗留原因，同时修改了该遗留bug后，相关联的测试点测试需要被明确和可追溯。
（6）设计测试长时间挂机等相关场景，个人认为仅凭感觉的挂机时间和操作纯粹是靠运气，这个还是需要和开发进行确认，明确责任划分后针对性的挂机，同时有迹可循。
（7）验收测试，进行验收点的测试，原有旧功能验收点确保正确，其他边缘模块依据模块测试数据报告针对性安排，避免验收测试的时候，测试人员属于一顿瞎测的状态（必须避免在验收最后阶段，无明确测试方向和测试内容，诸如将某模块过一遍，看看是否没有问题这种不明确的安排，基本就是随意操作）。
提交反馈：
（1）版本提交之后的问题，因为已经明确验收点，对照验收点追溯，安排解决或者遗留，解决依照bug修改流程，遗留依照遗留流程。同时确认是否是用例遗漏，遗漏走用例修改流程。
自动化测试：
应用基本场景：
执行自动化用例 - 输出自动化测试报告 - 分析及问题上报 - 策略安排
自动化用例执行：
（1）明确自动化用例，明确用例库中哪些用例应该被转换为自动化用例，存在一条用例中部分可转，该用例对于手工测试人员来说，应该是未转换成自动化用例，对于自动化用例编写人员来说，仅进行可转部分的转换。新需求用例，基于用例是否明确进行转换，不明确不可靠，不进入自动化用例转换流程。用例转换完毕后，应该要可以直观查看哪些用例已被自动化完全覆盖。
（2）在明确要转的用例之后，用例本身转换外，是否要补充主观测试脚本问题，存在的矛盾是补充主观脚本能增加覆盖范围，但是后期对于脚本的维护会存在时间成本的增加。所以我认为如果自动化脚本要补充主观测试点，那么在这条用例中，应该也是写清楚的，即脚本和用例描述一一对应（如果条件允许，自动化小组单独维护一套测试用例，在用例变更之后，也一定要同步进行脚本维护），如果做不到用例转换内容清晰明了的话，就不进行主观测试点脚本覆盖。
（3）用例兼容性和健壮性问题，当前这方面无明确的流程和技术保证，对于完成的脚本无互审之类的保证措施，个人觉得，在精简性的基础上再保证兼容性和健壮性，减少无本质意义的用例维护时间，不能一味做加法。
报告输出：
（1）通过输出的报告，对手工测试的策略安排有辅助作用，基本相当于模块测试数据报告的输出。如果用例发现bug，自动化测试人员和手工测试人员，应该是均需要对该模块相关联用例的测试数据进行分析，针对性的安排测试补充到测试策略中（如该模块用例在bug修改后重跑，手工人员走bug修改流程）。
（2）验收阶段，进行验收用例自动化脚本执行(个人认为最好是在手工验收之后进行，或者同步进行)，不是明确的验收点，不再进行脚本执行，手工和自动化此阶段需明确分工下，时间充裕的话，优先执行主流程脚本及验收点(执行完毕后，反馈手工人员)，边缘模块放后执行。
策略安排：
（1）自动化脚本执行人员，和手动测试人员不应该是完全区隔开，自动化人员往往对项目当前情况比较不了解，需要手动人员对于自动化测试人员当下要执行的有反馈，如果在时间有限的情况下自动化全覆盖，其实也是没有明确测试点的一种表现（就当前情况而言，我认为自动化测试的职责主要是保障，而非挖掘，只有在保障的基础上，挖掘才有意义，手动人员利用节省的时间进行探索性测试）。