软件测试，谈谈对软件测试的看法，从来没有想过对这么大一个话题来说出自己的一个想法或者说对软件测试的理解，我就觉得自己能不能把自己对软件测试的了解说说，或者说汇总汇总下这三四年来自己从事的行业，也算是自己的一种总结吧。
首先谈谈什么是软件测试，简单来说软件测试就是通过一个过程或一系列的过程，用来确认代码完成了它应该有的功能，不执行它不该有的功能，我们如何确定哪些功能是应该有的哪些功能是不应该有的，不是软件开发或是软件测试人员说了算的，这些确定的需求都来自于客户的需求文档。(软件测试人员是需要参与需求文档的评审的，一个比较完善测试流程，测试工程师从需求文档开始就参与进项目)。
知道软件测试的定义知道后，我们需要了解的就是软件测试的分类，软件测试从不同的角度可以分为不同的种类，接下来我们就来了解下这些分类。
第一种分类：
- 功能测试： 主要关注点是所测系统的功能是否实现，是否满足需求文档中所提到的功能（既不能多也不能少）；
- 界面（UI）测试： 主要关注点是所测系统的界面，是否会出现一些截断的现象，界面的排版是否正常；
- 性能测试： 这块主要分为性能测试（这块主要关注的是需求文档里面定义好了具体的需求，比如这个系统最多能容纳多少用户登录使用，或者系统能同时能承受多少用户登录，然后根据性能测试工具能进行测试，按照需求文档中所指的明确值来进行测试，如果不能达到，就得寻求优化系统的方法，看是哪部分出现了错误），压力测试（），负载测试，并发测试等测试。
- 国际化本地化测试： 这部分主要是主要测试的是软件在不同的国家能否满足当地市场的风俗习惯和语言习惯等，国际化测试指的是该软件本身是哪个国家开发的，然后将这个软件安装在不同语言的操作系统上，看被测系统是不是符合需求文档的，举个例子（针对英文或日语的软件的国际化测试就是把英文的或日文的软件安装在各国不同语言的操作系统上来进行验证）。而本地化测试指的却是将不同语言的软件或系统翻译成当地的语言然后将翻译后的软件或系统装在本地语言的操作系统进行测试，看被测软件系统是否满足需求文档中所提到得需求，在举个例子（还是英文的或日本的软件系统需要本地化成韩语或汉语，这个时候就需要将英文的或日文的软件系统翻译成韩语或简中的语言然后在韩语的系统或中文的系统上进行测试，然后确定被测试系统是否满足需求文档）。
第二种分类：
- 黑盒测试 ： 从测试方法的名字上我们可以看出，这种测试的方式就是我们把被测的软件系统当成一个黑盒子来对待，我们只能看到盒子的表面功能而看不到盒子的内部结构和构成。这种测试的特点是不关注被测软件系统内部是怎么实现的，不用管被测系统到底是调用了什么方法，到底采用什么样的架构实现的，单纯的关注软件测试我们看到的部分，主要从软件的功能和界面方面进行测试。
- 白盒测试： 就是把被测软件系统当成一个白盒子来对待，是能够看到盒子的内部的结构的，能知道产品内部的工作流程，知道设计该系统语言逻辑是否正常，是通过检查软件系统的内部构造来验证该软件系统是否满足需求文档的。
- 灰盒测试： 介于白盒测试和黑盒测试之间的一种测试方法，可以理解为灰盒测试即关心软件输入对输出结果的正确表现，也关心软件内部结构的测试。
第三种分类：
一个系统的编码开始到客户使用，这个过程有一个测试流程的分类：
单元测试;（一般这个阶段是由开发人员自己测试自己的代码，比如java有JUnit和TestNG等单元测试框架），何为单元测试呢，就是开发人员编写完一个模块或一个功能以后的自测行为；
集成测试：两个或两个以上的模块或功能集成以后进行的测试，验证的是各个模块之间的借口之间是否存在问题，有些时候虽然单个模块是OK的，但是几个模块集成以后就会出现一些问题，这个测试过程测试人员就可以进行测试；
系统测试： 基本的系统已经成型以后的测试
验收测试： 系统要上线之前进行的测试，在验收测试阶段我们需要做的事情很多，这些都需要测试人员出具体的文档来进行验收：
- 功能确认测试
- 安全可靠性测试
- 易用性测试
- 可扩充性测试
- 兼容性测试
- 资源占用率测试
- 用户文档资料验收
第四种分类：
- 手工测试： 手工测试就是由人一个测试用例一个测试用例执行来验证系统是否满足用户的需求，这里提到了测试用例，下面会对测试用例进行具体的分析和讲解。手工测试主要从事的就是根据测试用例通过键盘鼠标对系统进行输入然后参看输出结果是否是预期的结果，预期结果也来自于需求文档。
- 自动化测试： 何为自动化测试呢？就是通过测试工具或代码来实现的测试。自动化测试分为功能自动化测试和性能自动化测试，
功能自动化测试：就是把手工测试转换成机器来运行（就是将手工执行的测试用例转换成代码来实现相应的功能），以此来提高工作的效率和加强测试的覆盖率，
性能自动化测试： 因为进行性能测试，我们需要模拟更多的用户或者对系统进行瓶颈方面的测试，所以这个阶段我们需要借助工具来对系统来进行对应的测试，现在市面上比较火的的性能测试工具有LoadRunner（收费的，但是万能的我国人民永远能找到秘钥，哈哈）还有Apache开源的性能测试工具JMeter+Badboy，通过这些工具我们能模拟成千上万的用户对系统进行测试。
第五种分类：
对于下面的几种分类也是在做项目的过程中，不同的公司会根据不同的项目所进行的相关进行的测试阶段，这几种可以不认为是测试的分类，就是在系统测试不同的阶段所进行的测试过程，所以也由必要说说相关的术语，求别误导广大人民字第，完全是个人的想法。
- 冒烟测试： 何为冒烟测试，从字面上可是看不出到底是指的哪方面的测试类型，但是项目测试阶段是非常有必要进行的，具体指的就是一个大型项目开始测试之前，需要对软件基本是实现的功能进行一个流程化的测试，看这个系统把最基本的功能实现没有，如果基本功能没有实现，那就是这个系统不具备可测试性，测试人员可不是什么垃圾都收的，这个时候就需要把该项目打回去重新指给开发部门。这样有利于节省项目成本。
- 回归测试： 是指已经对系统进行了一遍完整的测试，发现了许多问题反馈给开发以后进行的下一轮测试，这轮测试我们需要验证之前的问题是否还会重现，还要确认被修改的部分没有引起其它地方出现问题，回归测试其实也是一个循环测试的过程，重复性比较大，所以在自动化测试中我就提到了，功能自动化测试一般是在回归测试阶段进行的。
- 随机测试或探索性测试： 随着敏捷开发的盛行也随之诞生了敏捷测试，这样就产生了随机测试或探索性测试的概念，简单一句话，就是根据测试人员的经验随机性的测试测试用例没有覆盖到的地方（测试用例是不可能完全覆盖所有的功能的，只能做到尽量覆盖到，采用不同的测试用例编写方法，后面慢慢说这块）。
测试方法的分类不单单只有这几种，还有更多的分类，作为测试人员需要知道自己所处的阶段，进行的是哪方面的测试，这样利用不同的技术才能更高效的进行测试。
测试用例
对于测试用例，怎么说这块呢，测试用例这块在测试团队应该占一定的比例，上家公司就会有专门的测试用例团队，专门研究和进行测试用例的编写，而且不同的公司采用的测试用例模板也完全不同，有的公司采用word来进行保存，有的采用Excel或思维导图，还有Visor画的流程图，测试用例的粗细程度也不尽相同，有的公司会把测试用例写到面面俱到，输入的字符都定义好了，有的公司则完全相反，测试用例写的相对比较粗。其实这两种也是各有利弊的，测试用例细的团队方便新进入的成员快速了解系统的测试流程，但是不利于测试人员的发散，限制了测试工程师的思维，颗粒度粗的测试用例则方便了测试工程师利用自己的经验来进行测试，能覆盖更多的地方，发现更多的问题，但是却也存在一定的弊端，对一些NewComer可能就是一个挑战了。
说了这么多，那么到底什么是测试用例呢？一条测试用例应该包含哪些具体的内容呢？
简单一句话来描述测试用例就是：就是测试人员把测试系统的操作步骤（来自于需求文档）按照一定的格式用文字描述出来，
功能自动化测试的测试用例，就是把手工测试的测试用例转换成代码脚本的过程。
但是一条基本的测试用例应该包含：
- 测试用例名字：就是对该测试用例所验证的功能进行一个简短的描述
- 前置条件： 就是为了验证这条测试用例先前所做的动作，也是一句话简短的描述（解释下这块啊，比如说我们要测试一个登录系统的操作，前提条件就是我们需要拥有这个系统的用户名，首先得注册一个账户在这个系统上，但是我们不可能说再次将注册的这个动作在进行一次（因为已经有其它测试用例已经覆盖到这个功能点了，在写的话只能是画蛇添足多此一举了），所以在这里我们仅仅只需要一句话"已存在注册该系统的用户"来作为前置条件一句带过）
- 输入动作： 就是为了验证一个结果之前，我们肯定会有动作（这里还是以验证登录为例子，我们为了验证登录是否成功，所以这里的动作就是，输入用户名，输入密码，有的系统还需要输入验证码，然后点击登录按钮等输入动作）
- 输出结果： 有了前提条件和输入动作，最后就应该有个输出结果，系统返回的输出结果，（成功或失败，比如说登录这个验证，成功的标示就是成功跳转到主页，并且显示该用户登录成功，失败的标示就是多种多样的了，可能没有反应，可能报错，可能页面不能跳转，或者显示不是该用户登录等等），根据输出结果来进行判断测试是通过还是失败。
知道了什么是测试用例，也知道了测试用例的基本构成元素，接下来我们就来看看测试用例的编写方法，下面的一些方法也是我在项目中常用的一些基本的方法。根据这些方法能让你的测试用例编写起来更有调理，思路更清晰，也具有更高的覆盖率，
对于这些测试用例的编写方法，我也说不出一个具体的概念，所有的方法我都以举例子的方式来讲解，或许更容易理解。
- 等价类划分
这里举个用户注册的例子，比如用户名的输入框是有限制的，它的限制条件是用户名的长度是8~16位的字符串（这些字符串只能是数字、字母以及下划线）组成
我们根据等价类划分，就可以分为有效等价类和无效等价类。
有效等价类： 输入字符的长度在 8~16位之间， 输入的字符串是由数字或字母或下划线或它们之间的组合这些组合
无效等价类：
- 输入的字符长度小于8位字符
- 输入的字符长度大于16位字符
- 输入了非法的字符比如"@#￥%……！"等不满足要求的字符串
然后根据这些字符来编排测试用例。
- 边界值分析：
在以往编写测试用例的经验中，边界值分析和等价类划分永远是放在一起来使用的，根据经验系统出问题的地方很多时候都是在边界值的地方。
还是举上面的那个注册用户名长度8~16位的例子来进行说明，
我们根据边界值分析的方法，我们就需要在测试用例中插入刚好是6位字符和7位字符8位字符9位字符，14位15位16位17位18位等字符长度来进行验证
- 错误推测法：
也就是反向思维来思考这件事，比如说一个输入框只能输入"a、b、c、d、e"这五个字符，你可以设计输入"q""A"等字符预期结果应该是报错的，如果没有报错那就是问题。
还有一些其它的方法，比如正交分解法、因果图、流程分析法等这些方法，这些我在实际项目中我也很少用到，也就不在这说了，上面的三种方法应该就足够能应付测试用例的编写方法，而且也是我在项目中长用到的。
根据实际的项目，也总结了一些一个Web页面的基本检查点，在编写测试用例的过程中，根据这些基本检查点然后结合具体项目的需求扩展设计的测试用例，然后结合上面测试用例的编写方法。
基本检查点：
- 页面元素的检查（页面的完整性、页面元素的排版、字体的排版等）
- 页面必输项功能检查（页面上存在一些必输项和可选项，检查相对应的提示信息）
- 页面上输入文本框的功能检查（文本长度、文本字符类型、文本框特殊字符的输入、特殊格式【比如邮箱等带@】的输入等）
- 页面上日期控件的功能检查（日期的选择、日期的保存、日期的选择范围等）
- 页面上单选框的检查
- 页面上多选框的检查
- 页面上下拉框的检查
- 页面上按钮的检查
- 页面上快捷键的使用（主要是Tab建、Space键、Esc键等等）
BUG的生命周期
测试的过程中肯定会伴随着BUG的产生，遇到BUG了，该如何写出一个相对完善的BUG呢？在这块每个公司针对不同的项目肯定会有不同的要求，但是最基本的内容也就如下，我觉得下面的这个BUG模板还是包含了一个BUG所需要的所有信息了，开发也能轻易的明白。
BUG Template:
Bug Title："简单一句话描述下这个问题"
Bug 描述： "描述下问题的原因，以及产生BUG中的一些问题和依赖关系"
测试环境： "描述测试环境的具体信息，包括操作系统、应用系统平台版本、数据库系统版本、浏览器类型"等等，把你发现问题的系统平台的信息描述出来，为什么需要这块呢？有可能是兼容性的问题，不描述清楚，开发人员可能在他本地上无法重现。
重现步骤(尽量描述清楚，不要让人感觉有歧义)：
步骤1….
步骤2…
步骤n…
实际结果：描述下通过上面的操作后实际产生的效果和输出结果
预期结果：根据需求文档，进行上述步骤操作后应该得到的效果和输出结果。
注意事项：描述下产生这个BUG的过程中要注意的事情，比如说只有IE上重现，Chrome上不重现等
客户影响：这个问题会对客户产生什么样的影响。