第一
测试应尽早进行，最好是能够在需求阶段就开始介入。千里之堤毁于蚁穴，对于测试，如果越早介入，问题就能越早被发现，修改或者调整方向的成本就会越小。
测试在需求阶段就介入，最严重的错误，无外乎是系统不能满足用户的需求，但是如果按照传统的瀑布模型，等到软件开发完成之后再进行测试，那么，万一偏离了方向，纠正过来的成本将是巨大的。
第二
加粗样式负责软件开发的人员应避免检查自己的程序。当局者迷旁观者清，自己犯的错误，往往意识不到。
当我们还是学生年代的时候，自己写的作文，如果是自己检查，很难找到错误。主要是受到思维惯性的影响，觉得这样表达并没有错，甚至是错别字也无法辨别出来。而如果交给其他同学或者老师来帮你检查，效果就不一样了。
这时候，有人就有疑问了，单元测试不是由开发人员测试的吗？
对的，这就相当于自检。每一个模块的代码实现什么功能，具体是怎样的实现逻辑，开发者自身是最清楚的。由开发人员做单元测试，能够高效地修正一些低级错误。
另外，也是因为测试人员的编码能力不足，开展单元测试效率低。所以，需要开发人员进行自检，这样的代码才有质量保证，而测试人员的作用就是，在代码已有的质量上，提升一个质量级别。
第三
设计测试用例既要考虑到合法情况，也要考虑不合法情况。
开发界有一句话：永远不要相信用户的输入。
测试界有一句话：永远不要相信开发的一句话： 这个功能我测试过
关于微信红包的金额，虽然已经指定了输入范围是0.01-200元，但是，有时候，用户会有意无意就会输入不合法的内容。更何况，黑客会专门找转件的漏洞进行攻击。所以，合法与不合法的输入，都要兼顾考虑，做好限制管控。
第四
在测试程序时，不仅要检验程序是否做了该做的事情，还要检验程序是否做了不该做的事情，多余的工作中会带来副作用，影响程序的效率，甚至带来潜在的危害和错误。
这一项检验工作，主要是按照需求文档进行检测的，包括程序代码考虑是否周全，逻辑是否严密等。
第五，
应长期保留所有测试用例，有助于以后修改程序后进行回归测试。
软件会长期进行迭代更新、升级，但是无法保证更新、升级的内容不会对原有的功能造成负面影响，因此，需要进行回归测试。
如果重新设计开发测试用例，将会耗费巨大的人力成本。
微信在开始阶段，是没有红包功能的，而增加这一项功能后，会不会对原有的聊天功能造成影响呢？这就需要进行回归测试了。
因为以前已经编写过聊天功能的测试用例，如果保留下来，就可以直接拿过来开始测试，否则，就需要重新编写。
以上就是本篇文章所要分享的内容，欢迎各位大牛指正。你的指正，能让我在测试之路上快速成长。
如果想学习交流，就快加入：893694563，群内学软件测试，分享技术和学习资料，陪你一起成长和学习。那就：码上开始