1.辅助过程裁减、细致化、明确项目规范.清晰产品在面向最终用户时的形态，对策划案（产品需求）中阐述不清晰或者有逻辑冲突的地方提出质疑.实际开发中，程序员受限于工作的焦点，所以QA/QC人员一定做到更懂产品将要达到一个什么样的形态，期间QA/QC人员的思路应保持在最终用户的身份上，而非开发参与者。

  2. 制定〈质量保证计划〉参考相应的产品策划案，严谨斟酌产品需求的合理性以及大胆假设在即定需求下有可能产生的BUG，以此制定出质量保证计划（测试流程）产品将要实现的功能必须严格遵守产品需求，对于产品需求本身的合理性以及需求中所忽略的重要缺憾及时的对开发团队提出见解

  制定出完善的质量保证计划，测试流程中不仅要保证每项功能的实现还必须最大限度的假设可能出现的情况

  3.产品检查.确定保证产品在严格依照策划案（产品需求）实现了有效功能的同时，最大力度的保证实际研发人员所未预料到的BUG得到如实的反馈.依照制定的《质量保证计划》严谨的落实测试项，并且如实详尽的以书面形式（BUGZILLA）反馈。

  参考现有产品需求，以用户的角度斟酌是不是合理和完善，并且如实向开发团队反馈成熟建议

  在确保测试流程完全落实，并且所有已知BUG已经反馈的情况下，进行大量重复性的测试。（就公司产品而言，就是反复玩，实际工作中，仅仅有30%左右的BUG是在预先制定的测试流程中能体现的，其他大部分BUG在无序测试中反而更容易被侦测到）

  未预料到的BUG出现，则总结该BUG的类型，并且将非偶然性的BUG添加入《质量保证计划》中。偶然性BUG权衡后记录。见注①

  4.过程审计 统计反馈BUG的隶属对象 明确BUG会将由谁来处理，并且依照项目进度对BUG划分优先级

  明确BUG的处理方，并且在BUGZILLA中指定正确的对象（不排除A的代码出现的BUG将由B处理的情况，具体实际对象应参考项目进度或服从安排）

  5.跟踪问题处理.根据项目的实际开发进度，跟踪已知的产品BUG处理情况.已处理的BUG经过反复测试后，及时反馈。

  6.度量及报告.资源有限的情况下，面对多个项目或者单元需要测试，QA/QC人需要评估并且如实反馈。

  在项目进行中，有核心部分需要有较大的把握保证其稳定性，在人力和时间资源有限的情况下，将精力更多的花费在此方向上，对于整个项目来说，是更优选择

  7.经验积累 自身的工作经验的累积以外，对日渐成熟的工作方式及流程做书面保留，以实现公司非物质财富的累积

  注①：偶然性BUG的处理在权衡后，明确其产生环境并加以记录。如：使用不相同引擎开发的产品 开发环境的不同其偶然性BUG总有着必然联系，对此加以记录方便后续工作者的快速任职。

  特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

  政协委员周小平建议：福建省公安厅对“厦金撞船事件”立案侦查，公安部督办

  科技部部长：鼓励有条件的单位把一半以上的基础科研费用投向35岁以下的年轻人

  受全国人大常委会委托 全国人大常委会副委员长李鸿忠作关于国务院组织法修订草案的说明

  妈妈分享镜头下的女儿，完美诠释了什么叫“梨花带雨 我见犹怜”，花朵朵有什么伤心的事跟，泥巴巴说说