
如果是标题,则该列详细.
1. 辅助过程的简化,细致化和项目规范的澄清. 面对最终用户时,要清除产品形式,以及有关计划计划中不清楚或逻辑上的冲突的问题(产品要求). 在实际开发中,程序员受到工作重点的限制,因此QA / QC人员必须更加了解产品将达到的形式. 在此期间,质量检查/质量控制人员的想法应保留为最终用户的身份,而不是作为开发参与者.
要求:
仔细阅读计划案例(产品要求)
请求因产品要求本身的解释不明确或逻辑冲突而引起的疑问
根据开发目标,弄清产品在开发阶段的目标形式,以及与最终形式的差距

2. 参照相应的产品计划书制定“质量保证书”,仔细考虑产品需求的合理性和在即时需求下可能产生的大胆假设,然后制定产品的质量保证书(测试过程)必须严格遵守产品要求,并及时向开发团队提供产品要求本身的合理性和要求中忽略的重要缺点的见解
要求:
确保“质量保证计划”严格遵循产品的需求
提供对需求合理性和需求缺乏的成熟见解
制定完整的质量保证计划,不仅要确保测试过程中每个功能的实现,还要使可能出现的假设最大化
3. 产品检验. 确保产品严格按照计划计划(产品要求)实现有效的功能,同时确保真实地反馈实际开发人员意外收到的错误. 根据已建立的“质量保证”,“计划”严格执行测试项目,并如实测量工作的基本程序,详细地写回(BUGZILLA)反馈.

要求:
根据现有测试计划完成测试
参考现有产品的需求,从用户的角度考虑它是否合理和完美,并如实地将成熟的建议反馈给开发团队
在确保测试过程已完全实施并报告了所有已知的错误之后,进行了大量的重复测试. (就公司的产品而言,它是重复播放的. 在实际工作中,只有大约30%的错误可以反映在预先建立的测试过程中. 大多数其他错误在无序测试中更容易检测到. )
出现意外的BUG,然后总结该BUG的类型,然后将非偶然的BUG添加到``质量保证计划''中. 在意外的BUG权衡之后记录. 见注①
4. 流程审核统计反馈BUG的下属很明显,谁来处理BUG,并且BUG将根据项目进度确定优先级

要求:
澄清BUG的处理程序,并在BUGZILLA中指定正确的对象(不排除A的代码中的B代码将由B处理的情况,具体的实际对象应参考项目进度或服从安排
确定当前进度下要处理的错误
告知相应的开发人员反馈错误的ID
5. 跟踪问题处理. 根据项目的实际开发进度,跟踪已知产品的BUG加工情况. 经过反复测试,处理后的BUG会及时反馈.
要求:

重复产品检查过程
验证BUG已完全处理,并在最大程度上确保没有扩展BUG
及时在bugzilla中报告错误的当前状态
6. 测量和报告. 在资源有限的情况下,面对需要测试的多个项目或单元测量工作的基本程序,质量保证/质量控制人员需要评估并如实反映.
要求:
在项目过程中,需要对核心部分进行更大的保证以确保其稳定性. 在人力和时间资源有限的情况下,在此方向上会花费更多的精力. 对于整个项目,这是更好的选择
7. 积累经验除了积累自己的工作经验之外,还要对日益成熟的工作方法和流程进行书面保留,以实现公司无形财富的积累.
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/shumachanpin/article-284233-1.html
能有什么麻烦
就更有利于国民战斗力提升了ps
刚好点而已