编写TC、提交bug、测试执行总结.docxVIP

体现测试专业性的方面较多，个人认为最直接、最本质的体现还是在编写测试用例、提交bug和执行测试方面。下面就这三方面来谈一下我的感受。

编写TC

上次黑灯舞会辩论的问题就是测试用例的粒度大一些还是小一些比较好，记得大家辩论

很激烈，我比较倾向于测试粒度大一些比较好，大前提是：该校验的测试点已经在测试用例中有体现，宏观把握，微观协调。

下面说下自己对编写测试TC方面的拙见：

首先，明确测试点。要非常清楚自己要校验的点是什么；

其次，编写测试用例的时候遵循一个用例一个校验点的原则，这样不仅方便统计测试点是否被遗漏，而且方面后续做页面自动化测试和接口测试的时候统计用例及编写校验脚本；

再次，编写TC的时候言简意赅，步骤按照执行顺序清晰明确，使用规范的符号和描述。

最后，测试用例要写得全面。涉及到的应用校验点也要加入到用例中，这是一种能力，对业务、应用间的关系、代码的调用、涉及到的接口的熟悉程度要求比较高，尤其在做项目的时候，这种要求就转化为一个潜在的风险，只有不断的提升自己才能在人的角度上降低风险，只有踏踏实实积累、不断的追求卓越才会看见更美的风景。

提交bug

这个季度中心里对bug的认识明显深于上一个季度。上个季度有时候出于一种对开发

工作的肯定，对于类似于文案校验的小问题有时候会放水，其实这是一种不负责任的表现，也是一种对测试人员工作的不尊重。没有从宏观出发来保证产品的质量，我们的工作指责是在各自的岗位上尽最大努力做好本职工作，和开发等其他同事一道把握好质量这关。

提交bug的方法很简单，很重要的一点是在写摘要、前置条件、步骤、预期结果和显示结果的时候一定要阐述清楚，最起码能够让别人能够看懂你在描述什么样的问题。个人建议在写bug摘要的时候”[里]”面要用最少的字写明测试场景，便于阅读、理解和猜测。

测试执行

个人的一点想法：

首先执行测试用例，如果测试用例写得好的话，覆盖率会比较高，但是不要拘泥与测试

用例，发散、灵活、探索性测试也是一种艺术，在尝试的过程中也许会有意外收获，也许这个意外收获是一种潜在问题，也许这个收获会给开发人员一个微妙的启发和提示。

现在大环境对测试人员的要求不断提高，测试人员的专业性不仅体现在业务和应用之间联系的掌握程度上，更重要的是要不断的探索创新，珠联璧合明确了测试方向，要从功能测试中提升自己，追求高效、覆盖率高的测试方法和流程。测试人员在日常和项目前期就介入充分体现了测试的重要性，只有在各个阶段做好各个阶段应该做的事情才能把质量这关把握好，人人都是产品经理，人人质量，让我们和其他线上的兄弟姐妹们携起手来做得更好，更专业！