测试学习的路上

熟悉软件测试的理论。

软件测试是什么?

软件测试（英语：software testing），描述一种用来促进鉴定软件的正确性、完整性、安全性和质量的过程。据此，您可能会想，软件测试永远不可能完整的确立任意电脑软件的正确性。然而，在可计算理论（计算机科学的一个支派）一个简单的数学证明推断出下列结果：不可能完全解决所谓“死机”，指任意计算机程序是否会进入死循环，或者罢工并产生输出问题。换句话说，软件测试是一种实际输出与预期输出间的审核或者比较过程。

软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

软件测试有许多方法，但对复杂的产品运行有效测试不仅仅是研究过程，更是创造并严格遵守某些呆板步骤的大事。测试的其中一个定义：为了评估而质疑产品的过程；这里的“质疑”是测试员试着对产品做的事，而产品以测试者脚本行为反应作为回答。虽然大部分测试的智力过程不外乎回顾、检查，然而“测试”这个词意味着产品动态分析──让产品流畅运行。程序质量可能，而且通常会，随系统不同而有差异；不过某些公认特性是共通的：可靠性、稳定性、轻便性、易于维护、以及实用性。请引用至ISO标准ISO 9126有更详尽的说明。

我在学习的路上

学习了一段时间的软件测试，学习的路上一直在填坑，很多东西只是片面上的了解。
特别是在公司上，我刚进来先学习的是公司项目的业务。看需求、看设计文档、系统架构、接口文档。
差不多熟悉了，就开始对着公司的项目进行测试方案的编写，当然不是一口气把整个项目的测试方案写完（是按一个小功能一个小功能的来），结合学习的业务逻辑和需求文档，加深多接口的了解，测试方案中重要的是测试方法的分析，如何描述你的测试点。

第一次按着测试的方案的模板去写，很多东西觉得自己会了，埋头苦干。最终把整个测试方案给写烂了，给我师傅一看，看着那一大堆的批注，比我写的内容还多。

我犯了个严重的错误，在理解业务逻辑上，都是靠着自己的逻辑在走，忽略了很多深层次的东西，比如：一条业务的数据流转，通过什么形式去发送和操作。也只有这样才能知道测试点在哪里，我师傅经常反问我给你一个功能，你怎么测，怎么测。我噼里啪啦的说了一些无关紧要的东西，反思了每一次的错误，原来。

第一，还是我不了解业务需求的原因占的比重大，业务数据流转不清晰。
第二，个人对测试点的分析不到位。
第三，测试步骤描述不清晰。
这都是我写不好第一次测试方案的原因。

我也觉得软件测试没有那么难（对功能测试来说），就像google测试艺术书上说的一样，软件里面的缺陷就是开发人员所犯下的错误。严谨的开发人员根本不需要功能测试这部分的测试人员。

我觉得软件测试难就难在测试 点的分析，bug的定位上，好的测试人员不是说你帮我点点界面出现了这个功能不能实现了，就是bug，然后登记等待项目经理指派开发人员去修复。。。第二轮测试。

出现了bug，我们应该去定位bug。找到出现的位置，把前后端的测试分开来，避免前端出现bug赖到后端，后端出现bug赖到前端去。
这样也能大大简洁的帮助我们定位bug。

测试人员也应该会编程，我觉得也是，而且要技术牛逼，凭什么说软件测试的是一个没有门槛的工作岗位，纯属的劳动活。在这方面偏见，我只能说你只要去做好自己的工作，没事别瞎bb。

你知道什么叫性能测试吗？你知道什么叫压力测试、接口测试？我倒不觉得这些事很难的事，因为这都是冲着问题去的，其实我们所做的工作都是冲着解决某一件事情去的。有问题就一定有解决的办法，搜索引擎可以解决百分之99%的技术问题，剩下1%的只需要更强大的搜索引擎。

软件测试其实超乎我们的想象，越来规范化的测试流程。让软件质量得到了很好的保障。

有一个晚上，我其实在想，软件测试可以是无处不在的东西，可以用辩证思维去分析一件事情，分析场景。软件测试做得好了，可以变相思考自己的做事的处理方式。

结论先行。。很重要。软件测试是一种实际输出与预期输出间的审核或者比较过程。
细细品读这句话。全部的软件技术精髓都在上面呢。