文章转载链接：www.51testing.com/html/62/n-7…
概述
从去年4月份开始，已经发现我们的提测版本质量存在问题，于是陆陆续续向上反馈希望通过自测环节来把控提测版本质量问题。
为此，经过前期的一些探索我们开展了如下工作成果，增加自测流程：
· 整体汇总单体测试测试点V1.0
· 通用测试checklist 清单
· 单体测试宣讲
问题分析
在经过上述实践后，我们发现了一些不足之处。从不同角度深入分析，我们意识到在某些方面仍需改进。
排除一些主观因素外，存在问题现象有2点:
1、不能匹配所有项目
部门大部分项目为web 项目，有些功能清单能覆盖到，有的项目非web型，并且调用第三方平台，针对这种类型的项目，清单就显现出了弊端。
下面为清单内容：
自测清单
2、无法做到全面自测
现状：目前项目中1名开发对应多个页面的开发，仅仅由PM或者组长提交一份清单结果，无法做到针对性，无法普及到所有页面是否完全进行自测，以至于仅仅是流程的走马观花，等我们进行测试的时候问题依然很多。
为此，为了规避上面以及未提及的一些问题，提出了一个新的方案，即自测用例模式。
开发自测用例模式
自测用例流程
按照功能点由测试人员提供自测用例，各自模块开发人员执行测试，最后由PM邮件发送测试结果，规避流程不通等影响流程性较大问题。
自测用例提取原则
功能性原则：确保每个功能点都有对应的自测用例，并且用例的设计要覆盖功能的主要方面，包括正常情况和异常情况。
优先级原则：根据功能的重要性和风险程度，对自测用例进行优先级排序，优先测试核心功能和重要场景。
标准化原则：遵循统一的测试用例编写规范和标准，保持格式一致，方便团队成员理解和使用。
实现原则：先编写功能测试用例，再从功能测试用例中抽取开发自测用例。
可改善点
每一次实践，都会有一定的成果，这是我们不断进步的动力。然而，正如每一次旅行都不能一帆风顺，我们也总会遇到一些困难和不足。
这些不足，正是我们需要正视和改进的地方。它们可能是流程上的瑕疵、技术上的瓶颈，或者是团队协作的摩擦。
下面有3点还需要改善：
1、缺少开发规范（UI）
开发规范（UI）在软件开发中起着至关重要的作用。
首先，它能够统一整个产品的视觉风格，确保用户界面的一致性和美观性，提升用户体验。
其次，UI规范可以明确各个界面元素的标准和交互方式，让开发人员遵循统一的标准进行开发，提高开发效率。
此外，明确的UI规范还有助于减少后期维护成本，降低因设计不规范而导致的返工和修改。
最重要的是，UI规范能够确保软件产品的品质和用户体验的稳定性，为用户提供更好的使用体验，从而提升软件产品的市场竞争力。
参照下图：
2、用例方面
· 自测测试用例 尽量按照功能点去编写，保证完整性，注意细节。
· 自测测试用例需要增加常见UI问题检查项。
3、复盘会议
以往对于不符合要求功能模块体现到测试报告中，有条件总测试报告编写完成后可针对每一个组存在的问题召开一次复盘会议。
总结
针对提测版本质量过低的问题，从测试的角度，我们已经采取了一系列措施，如自测清单、自测用例和测试宣讲等，这些措施的实施确实提高了测试的质量和效率。
但要想取得更大的成果，单靠这些措施是远远不够的，还需要得到更多方面的支持和配合:
首先，需要得到领导层的支持，他们可以提供更多资源和人员配备，使得测试工作能够更加顺利地进行。
此外，也需要开发人员的积极配合，他们可以更加深入地了解测试的需求和目的，从而更好地完成开发工作。
同时，还需要得到跨部门之间的协作和支持，例如与产品经理、运维团队等的沟通和合作，以确保产品的质量和稳定性。
总之，要想取得大的成果，离不开各种支持和配合，只有大家齐心协力，才能够更好地完成测试工作并提高产品的质量。
