在刚成为测试人员时，不断地提系统的缺陷，发现产品的问题。认为做好测试工作，写好用例，发现缺陷，提好缺陷报告就好了，但是，每当缺陷越提越多，产品质量不因你提的缺陷增多而改善，所以去发现过程当中的问题，让自己和研发测试团队不断改进，让整个过程不断完善，才能让产品质量有更大的提升。

结合身为团队负责人浅谈一下我们日常工作以及测试工作中可以改进的方面和空间。

从流程抓起，梳理明确的流程规范研发流程，从研发流程整个流程去思考我们当前的产品研发过程有没有问题以及有没有可以改进的空间。

1、需求设计评审重点关注：

a)有没有做：先看我们的产品研发流程有没有做需求评审，如果一开始就错了，那么我们返工的周期将会拉的非常大，所以需求设计评审是必须要做的环节。

b)有没有及地做：在日常大量的需求处理过程中，产品组的需求设计评审有没有及时做，如果不及时，严重影响产品研发进度，不仅开发时间被压缩，测试时间更是被挤压。

c)有没有高效地做：在大量的需求需要处理、设计、测试，能形成一个高效快速的需求设计评审的机制，那就能快速地发现需求设计的问题及时纠偏。形成需求设计评审的套路。建议列一个清单，每个需求评审都按照这个清单去提问。结合新发现的问题，考虑是否适用于清单，并及时总结提炼到清单中，后续不断维护这一个需求设计评审清单即可。需求设计评审能力其实取决于你对需求评审的套路是否养成。评审如此，设计方案亦是如此，方案要怎么设计也是一个套路化的过程。

d)发现的问题是否跟踪执行：发现的问题后续有没有及时调整方案和设计内容是需求评审最关键的内容，调整了处理了才能算需求评审完成的标志。

2、递交测试需要关注：

a)修改内容是否和需求保持一致：修改内容和之前的需求回复处理结果以及和任务设计的内容范围和逻辑上是否一致，如果不一致需要建议直接打回。

b)测试建议编写是否符合准入条件：好的测试建议不仅能方便测试人员高效测试，还能补充测试人员在用例设计过程中无法考虑到的场景。对于测试建议的打回也是要跟提交缺陷一样的标准，打回原因不能仅仅选一下类型，还要把需要优化和改进内容写到备注告诉开发，不让要打回的修改单出现开发再找测试沟通的情况。

c)产品组有没有做代码审核。代码审核能从代码层面发现一些基本逻辑问题，甚至能发现一些测试过程并不一定易现的问题。如单行查询返回多行的问题。如sql里面变量列明不明确的问题。

d)有没有使用代码审核工具。人工的代码审核效率毕竟低下，可以通过一些代码审核工具自动审核，扫除一些连接池释放问题，内存溢出问题的代码缺陷。

3、测试环节关注：

a)有没有用例：的确看到蛮多不写用例的情况。但是用例如果不写，产品的质量奖处于完全无法控制的状态，没有用例可以认为和没有测试是一样的。

b)用例有没有评审：一个人的考虑范围一定没有整个团队考虑的全面。要把好质量的关，就把好用例质量的这一关

c)有没有用例模板：为了能快速高效的写用例，一个有效的用例模板将能起到事半功倍的效果。更是让新人能快速成长学习的有效途径。当然模板可以有多个类型。如接口类的用例模板，功能类的用例模板，通用测试点的模板等等。又是一个套路化的过程。

d)有没有自动化测试：自动化测试不只是一个口号，UI自动化、接口自动化、存储过程自动化，比对自动化、性能自动化、分析自动化，用自动化的思路解决执行效率的问题。

4、测试执行跟踪情况关注

a)有没有指定重点里程碑计划：重点跟踪里程碑节点的执行情况，把控是否存在延期情况。没有计划，一定延期，也一定乱了章法。

b)有没有通过日报周报反馈机制，突出整体进度，反馈当前风险。

5、通过分析再发现问题细节和根本所在，不断循序渐进

a)分析为什么缺陷会逃逸：通过缺陷逃逸分析能直面了解问题为什么会逃逸到客户环节发现，而不能在上游环节去考虑。对于分析的结果一样可以形成对应的套路和清单，分别使用于不同的环节和流程中。

b)是否通过PDCA让质量止于至善：发现问题、分析问题、制定改进措施、检查执行效果。让这样过程形成习惯，让自己和团队坚持做一个坚持不懈的改进者。

以上是在对应产品的测试过程中结合自身遇到和看到的一些问题做的一些分享，希望和大家一起共勉。

最后引用一下公司过程改进的一些话语：

持续改进是一种文化

持续改进是一种意识

持续改进是一种创新