以下感言仅仅是最近测试后心中的一些感言，记录一下在一些测试之后的心情和感悟。作为一个入行还不到一年的测试，言论还十分的粗浅，经验也十分的浅薄。只能说总结了一下自己在软件功能测试这个最最最基本的测试必备技能上，自己有待改进并且仍未达标的一些标准，还有一些以后慢慢培养的良好习惯和思维逻辑。
1.简单的事情重复做，重复的事情创新做
这句话是今天测试经理告诉我，也是我觉得我在平时的测试工作中一直忽略或者是不重视的点。
问题描述和反思：
在每天对同一个系统进行重复、机械单调的测试中，我很容易就会产生一种麻木感，前一周或许兴致勃勃，每一个文本框每一个复选项都会乐此不疲的使用测试设计方法进行功能测试。但是在日复一日，或许不到一个月就觉得我对系统很熟了，这个地方之前是对的，这个小细节不需要关注。这个关联之前对的这次没改所以肯定也是对的，然后就懒得去打开关联页面进行验证了。
这是一个很懒很不负责任的行为，因为我无法做到在每一个版本完后才能后理直气壮地说这个模块我测过的地方肯定没问题了，因为我自己都知道很多小细节被我极快的略过了。
这个是我的惰性造成的，我的理性也并未对其纠正甚至任其发展。在一些本就不完美，投入时间更少的系统上，这个缺点尤其明显。为了追求效率，小细节忽略大问题才能看到，最后无法拍着胸脯保证我这个模块是完全没有问题的，甚至有个系统我断断续续测试了一月有余但并不知道那个模块使用哪张数据表，逻辑是如何？
如何改进？
- 平时的测试中，如果时间充裕的情况下，尽量放慢速度，把关联的页面都点开联系起来看一下。
- 了解这个模块的代码逻辑，相关联的数据库。
- 时常静下心来思考一下自己的测试方法，测试路线是否正确，是否真正运用完了自己所学
2. 生成自己的文档
作为一个测试，文档有很大一部分代表了你的所作所为和你的态度。
我最近负责了一个逻辑稍微有点复杂的系统，是一个基于网络的协诊系统，所以说有两个服务器端和两个客户端。在最开始很长的一段时间里我都不是很能够搞清其状态并且分辨出自己下一步该干啥。这暴露了我的逻辑之薄弱和注意力的不集中。
如何改进
生成自己的文档，哪怕只是记录自己在部署过程中一些你觉得无关紧要的操作，建议你也使用一个文档记下来。因为在工作的过程中一件事情有很大几率是会被打断的，如果你记录下来之前的操作，你能够在很快的时间内找到之前的状态并回魂，明确之际下一步应该干啥，而不是脑中一盘散沙。
3. 独立思考，发散思维
问题描述和反思：
当发现一个bug，我首先想的是上报给研发让其修改。只做到仔细描述bug的复现步骤和相关截图，但是并没有想到自己来定位一下这个问题是前端还是后端？后端是因为逻辑还是因为数据？
这个问题我自身有一个很好的例子：
在之前我已经提到过有我负责了一个网络协诊系统，在测试环境上经过我粗略的测试基本流程是能够通过的。然后我使用了现场的数据和测试的结构，相当于除了现场环境、数据其他的变量都一样，但是出现了错误。此时的我急忙叫来了开发来定位其问题。但是这一下就暴露了我没有自己沉下心去思考为何出错，对研发有依赖，对自己没要求。
如何改进
-
首先相信自己的能力，如果不是很紧急的事件，尝试着静下心来，使用F12或者fiddler定位是前端还是后端的问题，
如果是前端的问题尝试着思考其逻辑，是否是过滤未做还是没控制到什么的。
如果是后端的问题思考是数据的问题还是逻辑上的错误，根据数据库进行比对来定位问题所在。
最后可以在禅道中或者问题描述中记录下自己的看法，待开发修改正确之后询问其解决方法。 -
尝试多种方法，例如在上面我提到的那个问题，我是用了控制变量法，那么测试环境和实际环境中就只有2个变量是不相同的。
（1）测试环境和现场环境的数据，如果将此变量控制后错误仍然存在，可以初步判断数据这个变量的影响不大。
（2）现场硬件环境，这个变量是处于视情况而定可不可控的状态。
按照我目前这个系统的状态来看，排除数据问题之后基本肯定程序有缺陷，但是具体问题出在哪里？就又回到了第一个的思考方式，就是尝试自己定位。
开发的时间是很宝贵的，同时为了更加深入的了解自己所负责的系统，尽量将bug在自己这里过了再过。
2019.6.20 暂时就先写在这里，后面如果还有经验和教训会继续记录。
