测试工作内容

1、需求评审

对需求内容提前先了解，评审过程中仔细的听开发的发言，有一些发言可能是后续实现时的逻辑，搞清楚开发的实现在写测试用例的时候防止有遗漏。

关于需求评审这个环节，说一说自己的一些工作经历，很幸运自己刚毕业遇到一位很赞的领导，学到了很多，周边的同事们也都是认真的态度去做每一件事情，从他们的工作态度中可以看出不只是为了完成需求而做需求，是为了对自己所要生产的这个应用是否有价值而评审。在需求评审的时，对评审的内容问这样做的目的是什么是要解决什么问题，这样做是否能够达到目的，是否能够解决用户的问题。上述一些问题也是最困扰我自己的一些问题，仅供参考。

2、编写测试用例

测试用例不能只根据产品的需求去写，也要结合开发的实现逻辑，保证开发的实现满足产品需求的同时，也要对开发的实现是否有漏洞给出一些测试用例，用最少的用例覆盖所有的场景也是需要一定的技巧的。如果存在老数据，也是要考虑到老数据的兼容测试用例的。

最初写的测试用例都是根据产品的需求文档写的，写完之后看一遍还不如看着产品的需求文档测试方便呢。再后来就不写这样的用例了，实际存在的意义不大。看完需求文档，自己先在脑子里过一遍流程，然后找开发去聊一聊他们的实现流程，看一看开发的技术文档，根据开发的实现流程图和技术方案设计测试用例（前提是负责人的开发不会随便改产品的需求，只有无法满足需求时才会找产品临时更改需求，这种情况会周知到相关的人员的），保证开发实现的每一个流程没有问题，在完整流程测试上也会顺利很多的。个人理解，产品的需求是结果，开发的实现是过程，过程不出问题，结果也会是完美的。

3、工具的使用

工具是辅助提升工作效率的，完全取代人暂时应该是不可以的吧，在合适的时机使用合适的工具能够提高工作效率，还能提高自己的工作技能。常用的测试辅助工具还是需要很好的掌握的，比如弱网测试，不使用工具怎么测试，可以拿着手机去电梯或者地铁等信号弱的地方去测试，这种方式大多数的领导应该都是不能接受的吧。

4、保持好奇心

新开发的功能，可以先自己随便用用，用户小白上线使用，这儿点点那儿戳戳，这看看那儿瞅瞅，指定就会有惊喜出现呢。

5、是否符合需求

几轮使用之后，产品的需求基本都已经不用看文档都能够清楚的说出是什么内容，是不是符合产品的需求，差不多该产品上线了。面向广大用户的产品，要求比较高，功能要正确，还要经过产品的查看，实现是否能够满足产品曾经在脑子中构思的效果，除此之外卖相也是高要求，像素和外观交互等也是影响用户的一个原因，交互设计师上线，审核产品的交互实现和像素是否满足要求。

6、上线前的再次确认

涉及到服务端的上线，需要考虑到上线有问题之后如何在短时间内恢复用户的正常使用，要有回滚方案，方案是开发定的，测试最好还是要了解一下。确认各种配置是否已经添加，前后端谁先上线，是否已经做好了充足的兼容。

7、上线大吉

上线之后需要做线上的回归，预发布环境和线上用的数据是一样的，但是配置有可能不是同一套，还是要谨慎的，线上的回归是必须要有的。