没想到，第一次写博客是写测试。

实习测试，也算预料之外中的惊喜吧，我的一开始看法是后端来着，后来认为测试也OK，总之也算我的方向吧。所以也投了测试相关职位，没想到一次成功，还是比较不错的公司，谢谢我转的好运微博，O(∩_∩)O哈哈~其实前天下午也恶补了相关知识。

屁话不多，以下，是近来一个月接触到的测试相关知识，像这些知识性的网上一大把，我也不细说了，这个都要实际去接触就会有感悟：

测试流程：

1.需求评审：相关人员对软件需求文档进行评审，内容是否健全，是否有描述不清楚或矛盾的地方

2.需求剖析：需求剖析这一过程是主要确定系统必须完成什么工作，对目标系统提出完整、准确、清晰具体的要求。

3.测试计划：依照需求计算测试所需资源（人力，设备等）、所需时间、功能点界定、如何合理分配安排资源

4.用例设计：测试用例是指导你执行测试，帮助证明软件功能或发觉软件缺陷的一种说明。用例设计好以后，会进行评审。

5.测试环境：软件+硬件+网路+数据打算+测试工具

6.执行测试：开发人员递交第一个版本，假如存在未完成的功能，开发需跟测试人员说明，之后测试人员依照测试用例的详尽步骤，执行测试用例，发觉BUG递交缺陷库。

7.BUG跟踪：开发人员递交第二个版本，包括更改的BUG以及降低的部份功能，测试人员进行第二轮测试和回归测试，跟踪BUG直至关掉。重复前面的工作，通常情况下3-4个版本后BUG数目减小。

8.测试报告：测试报告是指把测试的过程和结果写成文档，对发觉的问题和缺陷进行剖析，为纠正软件的存在的质量问题提供根据，同时为软件初验和交付打下基础。

测试方式：从不同角度，有不同的分类

1.从是否关心软件内部结构和具体实现的角度界定

白盒测试、黑盒测试、灰盒测试

2.从是否执行代码角度

静态测试、动态测试

3.从软件开发的过程按阶段界定有

单元测试、集成测试、确认测试、系统测试、验收测试、回归测试

ＢＵＧ的递交：

虽然怎样判定是否是一个优秀的bug，最重要的一个标准：开发不用寻问测试就晓得如何再现这个bug，或则才能理解这个bug，而不是看不懂这个bug。对于我来说，目前做的不够好，应当再细致一点，万无一失。

一个bug单包含什么要素：

1、所属的系统

2、发现的版本

3、发现bug所属的模块

4、bug递交人

5、bug的错误类型：代码错误、界面优化、设计缺陷、配置相关、安装布署、安全相关、性能问题等

6、bug的再现机率：必现大几率再现小几率再现极小几率再现

7、bug的严重级别：致命严重通常提示

8、bug的优先级：高中低

9、bug的标题言简意赅说明是哪些bug，而不是把测试用例名子复制一遍

10、bug单号通常系统手动生成

11、bug内容：发觉的环境、预制条件、重现步骤、预期结果、实际结果，截图证明，bug错误说明，

12：附件：测试用的数据或则出错的日志，假如须要添加上日志

递交bug的时侯尽量把截图附上，并对截图进行标明，操作过程说明清楚，虽然字不如图，描述半天不如一张图。

数据标明：

近来做得最多的是数据标明，判定情感分类；听上去挺简单的，虽然平常瞧瞧评论也能反映出这是好评，中评还是差评。而且对于此次大量的数据标明，显著有点“复杂”，由于在判定早期我们有个理念，所以会秉持界定掉其他平常中我们认为是一类的数据，逐渐团队也会总结各类情况，就类似阅读理解了，挺有意思的。。。

一个月以来的心得：

*对于目前我们测试，都是功能测试，点点点，虽然挺有趣的，有些bug靠自己的看法找到也不失为优美的艺术。

*对于写测试用例，明白需求是十分重要的，这样才能写出比较健全有效的用例。并且实际操作中也会发觉好多须要测试的点，所以要不断改善，就能发觉更多的bug。并且有时侯需求是在不断变化的，一定要更上进度。

*近来主要递交bug软件测试学校，对于找bug，一定要把自己当作用户，一定要存疑，一定要有要把项目做到最完美的信念。早期，我对于需求也只是通过用例，相关图资料有个大致了解。并且在找bug中也会有好多细小的不同。例如有些功能有，然而不够好；例如有些地方没有提及的功能，加上是否更好？还有一些bug，更改了，而且疗效不大或则目前情况看不出疗效等等，这种作为初入测试的我，我晓得不能冲动行事，虽然对于业务我了解的不深，或则对于个别功能的实现以及项目的完成度不了解，造成有些bug是目前没必要的，反倒还可能浪费开发人员的宝贵时间，所以交流就很重要，跟项目总监确定需求，跟开发人员确定数据，页面相关问题，做到心里有数，才能做事不盲目。在了解情况之下，提bug看着不对就提（一个开死党爷爷对我说的）。其实提bug也可以提一些建议，虽然本意都是为了项目更好。还有提bug你可以简单剖析一下诱因，为何你认为这儿会有问题软件测试学校，是自己理解错误，误认成bug，还是开发错误，想清楚了，提bug的时侯就顺便交待清楚，可以给开发人员提供思路。

虽然越了解测试，越发觉是个宝库，由于测试涉及的知识太广了，你须要向一个宝库一样，能够走得更远。