一、为什么要做好开发自测（why）

二、开发自测方法论

• 开发阶段不仅是代码开发完成，编译通过，更重要的是自测通过；
• 自测工作必须覆盖全面的自测场景：正向、逆向、正常、异常、并发性能等等；
• 自测是开发阶段最重要的一环，如果不重视自测，测试阶段可能会产生大量的Bug、提测被打回、直接影响研发、测试进度；
• 自测直接决定了产品的质量。

•  迭代开发中允许有争论、有分歧、有权利发表自己的观点，沟通中要学会调整自己的心态，确保对话氛围安全，避免情绪失控；
•  有争议情况下的对话氛围尽量控制主观想法、臆断，主动回到客观事实；
•  学会征询对方的观点，切记独断专行，多站在对方的立场考虑问题，虚心接受和采纳正确的观点和建议；
• 不赌气，多沟通，以团队的利益和出发点考虑问题，少计较个人得失。

• 在规定的时间内尽量放慢开发的速度，做到慎之又慎，切记追求速度，需求上来就干 ；
• 合理地规划好时间，尽量避免多线程做事，多迭代并行开发；
• 对于复杂功能要梳理出开发顺序、先做什么后做什么，制定阶段性的开发目标和时间排期表，切记打乱仗。

• 对于不明确的需求、场景要主动、提前确认，确认后要告知相关的参与者；
• 需求问题确认最好当面或语音沟通、尽量做到产品、前后端开发、测试对需求的理解能达成一致；
• 不隐藏问题，尽早发现并提出问题，力所能及地加以解决。

• 做好全流程的自测，用户操作—前端页面—-后台接口—–数据库数据check
• 核心方法是否都通过了单元测试；
• 交叉Review已实现的功能，发现更多的Bug，完善到自测场景中。

三、具体如何做（do—执行）

•  需求评审前，我们应该先仔细阅读prd及交互文档，先形成自己对产品的思考，通过脑图的方式列出对产品设计的疑问点, 从用户或者从行业角度找出产品设计缺陷点；
•  需求评审不能流于形式，要把业务问题都理解吃透，确保产品设计的准确性以及合理性；带着自己的疑问点向产品、开发沟通自己对产品的疑惑和质疑点，多提几个为什么？如何实现？数据获取来源？超出预期的数据怎么处理？缓存处理机制如何？数据保存何处？逻辑由前端处理还是后端服务？后端服务逻辑是否跟第三方关联？
•  评审后要主动、反复确认跟进不明确的需求和待确认的问题，特别是一句话的需求。

•  开发前要做功能设计，特别是核心复杂的功能或流程，首先是确立最优的技术方案或架构设计；
•  对于不熟悉的新功能要想办法梳理出整体流程，再有针对性地钻研突破难点和瓶颈问题；对于熟悉的业务功能要梳理出这次改动的影响点和之前的遇到过的bug；
•  详细、完善的功能设计要包含正常场景和异常场景的覆盖；
• 考虑并发、性能相关问题的出现场景及相对应的技术解决方案；
• 开发阶段尽量考虑代码的公用性、拓展性及可维护性，多学习优秀的代码结构和设计思想。

• 一定要在测试环境自测流程， 确保基本的核心流程不出错，不出低级bug；
• 如时间充裕，组织组内用例评审也是非常必须的。特别是一些经验老道或者业务熟悉的老司机们，可以在用例评审上快速的帮忙指出用例的遗漏点，有助于测试人员打开思路，尽可能多的覆盖用户场景，值得注意的是用例评审上遇到不确定的，应立即记录下来，结束后及时找相关人员确认，避免猜测。开发人员对照达成一致的测试用例完成自测，特别留意异常场景和核心流程的测试；
• 多人协作开发的功能要注意提前界定好开发边界，确保整个功能的完整性，自测时要相互交叉测试；
• 和外部系统对接、联调要充分预计到对方系统、接口可能存在的问题，采取适当的补偿、降级和异常处理策略。