测试总结1

测试工作中经常会遇到的坑

经验就是在一个又一个的坑中拿出来的,自己做出一些总结,对于测试质量和效率是由很大的提示，下面我说说最近遇到的一些问题。

需求评审

在需求评审中，因为产品和UI对于需求范围描述不是很清晰，评审人员只关注了功能，对于范围没有太关注

1，平时在需求评审会议中，大家主要对于功能上的做出太多的关注，忽略了范围，对范围只是随口一个交代，说这次需求在哪些模块，具体每个模块中没有明确的提及，就导致在测试过程中，会不断的去询问产品或UI，这就导致了测试会浪费不必要的时间
2，例如最近一次，UI界面修改，在需求评审会议时，大家只针对了改变后的界面做了讨论。对于改变范围，只说了一下大模块，未拆分细的模块，在测试过程中，针对大模块中的一些很多细小范围同样存在了需要改变的内容，因为界面总是要保持一致。结果开发未修改，需求上未写，然后再测试过程中，不断的和UI、开发沟通，到最后协商的结果却是有的必须改，有的可以不改，浪费了时间，还使得范围变得更乱
3，最后虽然完成了工作，但是这中间浪费的时间还是浪费了，对于测试效率有很大的影响

需求分析

相信每个人或多或少都遇到过需求有歧义，不明确或者是不完善的情况，毕竟产品也有疏忽的时候，评审的时候，大家都是针对框架去分析，不会对于PRD每一句每一行去做，这就导致了细节的理解有异议， 最近做一项任务时，遇到了这些问题，在此做一个记录。

1，产品在PRD上的描述，让人看到就觉得是某个意思，开发理解后，然后去做，我编写用例的时候，也理解了，然后编写用例，最后测试时，我和开发理解一致，测试通过。结果测试负责人说，产品想要表达的不是这个意思，负责人和产品沟通一致，导致测试和开发工作浪费。讨论时，说我们理解错误，幸亏是一个小功能，如果是一个大功能，当时估计就崩溃了。。所以有歧义的语句一定要寻找产品，而且要带上负责人，（虽然我当时和开发觉得那句话就是要表达这个意思，不是有歧义。。）
2，测试工作通过后，是要给客户使用，所以一定要站在客户的角度去思考问题，在需求范围内怎么便于客户使用，怎么测。例如一些很明确的，新建的数据在页面要展示在第一行等等。最近在工作中遇到一些需求上没有，自己测试也没有考虑到问题。

• 新增数据和导入记录，操作完成后，需要刷新页面才会展示出来，测试过程中没有考虑到，应该是新增数据后页面自动刷新一次，将数据展示出来，让客户知道自己操作是有效的
• 导入文件，数据，邮件，等等一些类似功能，应该有模板供客户参考，这里的模板是指模板中的数据类型、格式等等，在模板中有一份样例供客户参考
• 需求中没有提及的，前后端却都支持的功能，测表达式函数时，需求上没有说明可以使用!()代表非函数，但是前后端都支持，我测前端时顺便就测了，因为我觉得!()本来就是非，所以测完了。最后负责人说我没有沟通，这不是需求，想想确实是自己问题。最后闹得前端和负责人吵起来，贼尴尬。

需求文档的重要性

大家在工作中应该有遇到过一些很老的功能要因为某些修改要重测的问题，这些老功能可能是好几年前的，已经没有需求文档，对测试工作造成很大的影响

1，当时接到这个任务，拿到的只有测试点，问产品和负责人要需求，都说没有，没有怎么测，找开发。。。是不是很皮。没办法，最后寻找开发，开发给出造测试数据所需要的一些字段，测了一周，准备交任务时，问了一个问题，结果引发出负责人的一连串问题，最后给出结论，你测的不对。。。。
2， 最后自己在公司wiki上搜索关于测试内容的所有记录，希望找出一份相关记录文档。真让我找出了一份，是以前的测试留下来的，真是谢天谢地。耗费一段时间重新测试，最后交付任务
3，当遇到这样的情况，一定要先自己进行寻找相关文档，没有需求，可能有相关参考文件，对测试工作有很大的作用

这些都是自己最近工作遇到的一些问题，在此总结。共勉之。