通过昨天晚上的分享，自己感触很大。这是我第一次在简书上写文章。首先我先说一下自己所在公司的情况：我们公司测试团队5个人，由于现在做的这个项目刚刚起步，而且所做的产品也比较多，所以我们一直在忙着测试几乎没有时间写用例和深入的熟悉需求，我大致说下我们的流程。
1.产品先发需求文档给开发和测试相关人员
2.开需求评审会议
3.编写用例（就是我们自己写，然后自己看）
4.一边更改测试用例，一边进行测试
5.回归测试
一、先说一下上面流程的问题，首先开需求评审会议的时候，多半是开发和产品在沟通能不能在有限的时间内实现，所以需求多半会再次修改。这时候写的测试用例后来也都要改，一般这个需求会改动好几次才会确认，确认后也只是邮件通知或者口头通知。所以改进建议：在最后确认需求时，一定还要再开需求评审会议。
二、关于测试用例，现在我们用Excel写用例，因为需求变动较大所以每次都做了很多无用功，而且我们测试的时间本来就不充分。改进建议：利用xmind先粗略的列出主要的功能测试点，等到需求真正的确定后，再补充详细测试用例。而且在版本迭代的时候，新增的业务需求用这种方法更方便。还有比较重要的一点就是分享中所说的‘用例评审’，我们目前没有这一流程，所以觉得所写的用例意义并不大，因为开发与产品并不知道我们写的测试用例涉及的范围、场景以及业务逻辑到底覆盖全面与否。所以改进方案：要进行用例评审。
三、关于UI评审，目前项目中没有这一流程。在实际工作中，一般是我们测试在进行功能测试，而UI设计在进行ui页面的相关测试，这样就加大了开发的工作量。而这些本可以在开发开始之前就进行评审的。改进建议：项目前期要进行UI评审
四、关于测试，先说一下我们具体测试的流程，就是按照自己所写的用例一遍一遍的测试，例如：我们测试的后台，昨天测试一天还没有把流程完全走完，因为开发改了部分内容，我们今天还要重头来测（包括昨天已经测试过的部分），所以反反复复一直在测试效率低下。改进建议：开发提测后，我们开始测试，直到完整测试完一轮之后，开发修改完所提bug后再提交，我们再进行回归测试。
五、测试报告的输出，目前公司项目中没有该流程。我们公司开发的产品主要是自己用，所以像一些测试报告之类的文档几乎都没有输出。这样就造成了，每个版本测试了几轮、有多少bug、主要集中在那些地方，等等都不清楚。改进建议：每个版本测试完成产品上线之后，要有相应的测试报告输出。
六、关于开发自测，为了提高开发 的效率，也避免测试时出现流程走不通或者阻碍性的bug，开发提测前应该进行自测，必要时要让开发负责人进行监督。
网友评论