本文章转载于搜狗测试
介入测试，一般从执行用例开始，初始启航，面对执行任务，你是否会迷茫如何开始着手，如何反馈，如何沟通，下文是小编对用例执行进行的总结，抛砖引玉~
Ⅰ执行前需要了解的相关信息
㈠任务的基本信息
1.模块负责人：明确任务对应的功能负责人。
⑴执行任务过程中的沟通对象；
⑵任务执行情况和结果的反馈对象；
⑶除主负责人外，是否有第二负责人。
2.开始时间和结束时间：明确自己进入任务和完成任务的时间点
3.用例的条数和执行时间：了解用例的条数和执行时间，自我评估任务的时间是否合理，如果不合理需及时与负责人沟通解决。
㈡任务的职责
用例要求
用例路径：明确要执行的用例。
执行用例筛选条件：明确执行用例的范围，是全部执行，还是执行其中特定的部分
用例执行说明：用例执行时的特殊要求，需要遵循的基本原则，如：
⑴系统平台要求，如在win8下执行全部case等
⑵其他软件环境，如在Win7+IE10的环境中测试等
沟通要求
结果反馈：对于反馈结果和问题，有哪些特殊要求，如：
时间点要求：如每两个小时反馈一次、有问题及时沟通等。
随机测试要求
随机测试的时间：确认是否有随机测试的安排，以及随机测试的时间，掌握随机测试在任务中的比重，以便调控具体任务的时间。
随机测试的方向：是否有随机测试方向的说明，有没有需要特别关注的内容。
㈢执行相关信息
功能介绍
功能介绍：简单了解被测功能相关的需求和实现，有助于测试执行，关注的内容如下：
需求文档
流程图（需求流程或实现流程）
用例
工具说明
工具说明：了解测试执行过程中会用到的工具，及工具的使用方法。
测试数据
测试数据：获取测试过程中用到的测试数据，或制作测试数据的方法。一般直接向功能负责人索取。
是否需要安排讲解
确认讲解的需求：简单了解一下测试用例及其他相关信息，根据具体情况，确认是否需要安排专门的讲解。
如果功能比较复杂，无法通过单纯的看需求或实现文档了解功能，需要跟相关负责人协调，申请安排专门的讲解。
如果测试过程中涉及工具使用或服务器搭建，单纯的文档交接无法完全掌握方法的，需要跟相关负责人协调，申请安排专门的讲解。
Ⅱ执行过程中的方法和注意事项
㈠执行过程中涉及的内容
执行用例
标注执行结果
汇报执行进度
沟通问题及check执行结果
提交/验证bug
随机测试
㈡执行用例
执行用例的要求
执行用例没有遗漏。
用例执行正确，与用例执行的步骤一致，或充分满足用例的测试目的。
用例执行速度满足预期，达到功能负责人的标准。
用例执行的方法
标准用例和测试点型用例（word文档）的执行方法（建议）：
用不同的背景色或字体颜色标注已执行或未执行的用例，以提醒自己，避免执行遗漏。
用批注标注未执行的用例，后续通过审阅查找，重新执行后删除批注，避免执行遗漏。
对于看起来描述一样的用例，应该反复多看两遍，可能只存在个别字的差别，如“能够”和“不能”这样的差别。
对于步骤和描述不明确的用例，应该标记出来，与功能负责人确认，明确后方可执行，不能私自臆测。
㈢标注执行结果
标注执行结果的要求
标注完整、无遗漏
标注清晰、明确、无歧义。
标注执行结果的方法
标准用例和测试点用例：（建议）
用pass和fail标注执行结果。
需要跟进的问题和疑问用批注写明。
对于没有明确预期或实际效果与预期不符的，需要标注实际结果。
实际操作与用例步骤不一致时，需要记录实际操作的结果，并跟功能负责人确认实际操作的正确性。
用例中存在错误的地方，可用批注标明，并写明需要功能负责人后续跟进，及需要修改的内容。
发现用例中未覆盖的测试点，可用批注标明，并写明需要功能负责人后续跟进。
发现的问题按照是否已经提交bug区分，提交过bug的在标注中添加上对应的bug编号；未提交bug的可以根据实际情况用“待提交”或“待确认”等字样标明问题当前的状态，并写明对应的跟进人，以便对应人员后续跟进，如“待确认，需模块负责人跟产品确认——××”
㈣汇报进度
①定时汇报
汇报时机：根据功能负责人的要求汇报，如每两个小时汇报一次，或每天下午5点汇报。
汇报对象：对应任务的负责人。
汇报方式：口头沟通。如果功能负责人当时忙碌或不在，可以用其他方式汇报，如QQ留言，邮件等
汇报内容：
当前执行进度
预计完成时间点
任务是否会delay
执行过程中遇到哪些问题（包括确认测试结果、功能存在哪些问题、执行方法、阻塞问题等）
②主动汇报
汇报时机：随时，条件如下：
发现严重问题或阻塞问题。
预计执行进度不符合预期，会导致任务delay。
汇报对象：对应任务的负责人。
汇报方式：口头沟通。如果功能负责人当时忙碌或不在，可以用其他方式汇报，如QQ留言，邮件等
汇报内容：
发现的问题：发现的严重问题或阻塞问题现象。
影响范围：阻塞多少内容无法执行。
进度delay的原因以及时间。
㈤沟通执行结果
主动与功能负责人沟通。遇到问题时需要有积极的态度，作为发起方主动与功能负责人沟通。
注意事项：
沟通时注意思路清晰，描述问题简单详尽。跟功能负责人沟通前，需要先把问题想清楚，准备好充分的信息后再进行沟通，以免描述模糊不清导致沟通成本的增加。
沟通过的问题要备忘。已经沟通过的问题，需要自己进行备忘，不要在同一件事情上重复沟通，增加双方的沟通成本，影响任务的正常进行。
注意沟通的频率。在不影响整体执行进度的前提下，当问题（包括执行方法和待确认的bug）比较多的时候，可以跟功能负责人约定一个时间点，集中解决，不要频繁的打扰功能负责人，以免干扰功能负责人的正常工作。
㈥提交/验证bug
将发现的bug按照要求提交到bug管理系统，开发修改完毕后进行验证
㈦随机测试
按照功能负责人的要求对执行的功能进行随机测试
Ⅲ执行结果反馈
邮件公示执行结果（建议）
邮件标题：【测试执行】XX版本XXX功能（日期）——执行完毕
收件人：功能负责人
正文：
Case执行结果概述：
测试版本：（测试执行过程中使用的版本号，XXX版~XXX版）
提交bug数：（本次提交bug的总数）
阻塞性bug数及编号：（阻塞性bug的总数及编号）
执行结果统计表格：
case总数
pass数
fail数
阻塞case数
用例未覆盖的bug数
180
165
10
5
2
附件说明
测试执行结果文档：执行后的结果文档
测试执行数据：执行过程中用到的测试数据，没有填“无”
测试执行结果标注特殊说明：
例如：批注中标注XXX的内容，请功能负责人更新case；批注中标注XX的内容，请功能负责人与产品后续确认等。
上线风险（有则写，没有填“无”）
列举出没有提交bug的风险，如
产品确认没问题，但个人认为用户体验不好的。
随机出现无法重现，或者只在个例机器上稳定重现的。
未充分测试点（有则写，没有填“无”）
测试不充分的内容，如
测试用例中包含，但因为条件等因素无法执行的。
由开发人员自行保证的
开发回归范围较大，因时间或手段等回归不充分、无法覆盖的。
Bug反复出现，最终版本没有关注的。
注意事项
当部分（少量）case被阻塞，导致测试任务无法完成，如阻塞时间较长（任务预期结束时间无法完成），那么在其他case执行完毕后，仍然需要发出任务执行完毕的邮件，在邮件中说明剩余的case数，以及被阻塞的case后续执行完的预期时间点，并在全部执行完毕后回复说明。