导航
1、前言
2、不堪回首的开发往事
3、测试推动开发的成长——将Bug消灭在自测中
4、关于软件测试
5、制定测试计划
6、编写测试用例
7、执行测试用例
8、发现并提交Bug
9、开发人员修复Bug
10、对已修复Bug进行返测
11、将修复完成的Bug关闭，对未修复的Bug重新激活
12、灵活使用压力测试工具
13、测试与版本控制
14、小结
15、附件下载
1、前言
对于测试，很多公司并不看重，接触过不少朋友或客户，打开网站随便点击一下，就可以很容易发现爆黄页、404、UI变型（浏览器兼容）、流程走不通、错别字......等各种各样的错误。当然也包括我以前工作过的公司，基本上都将测试交给了客户或网站来访者，发现有问题时经常是出了问题以后。
而我自己一直以来也同样对这一块不熟悉，虽然觉得它很重要，但只存在概念上的东西，而不知道怎么去实施。经手的产品上线前也是自己简单的测试后觉得没有问题就上线，而不是系统的测试。直到去年下半年，公司招了位在某互联网知名公司的测试工程师大牛晴哥哥过来后，我才真正明白什么叫测试，给我上了一堂宝贵的课程，在他的淫威之下，整个技术团队得以非常明显的进步，当然我也有了很明显的成长，在此对晴哥哥无私的付出与帮忙表示真诚的感谢，谢谢了。
2、不堪回首的开发往事
几乎每个开发人员都会坚信自己的这次修改完成通过，没有Bug，然后一次次被击毁这种幻想回到现实。这种经历犯傻的事情我以前也经常发生，而结果可想而知。
03、04年的时候，开发的网站基本上没测试就直接放上线，经常报黄页或出错后，才立马进行修改，弄得晕头转向的。
08年的时候在深圳一家软件公司上班，有一次帮东莞客户在供应链管理系统增加一些新的功能，在本地写完程序后自我检查后觉得没有问题，然后更新代码并写SQL语句更新数据，其中有一条删除语句要删除某个条件的记录，动手之前想得好好，可写的时候忘了加条件，然后直接在生产环境上提交执行......将整个表记录全删除了，而当时又不懂数据恢复，公司也不给权限上百度那些网站，整个人一下就蒙了......还好老板那里有数据库备份，帮忙恢复了回去......
11年的时候在做KJava手机端应用开发，有一次要对应用进行一次很小的修改，改完后自我感觉应该对其他地方没有影响，然后就提交给运营部门做群发，当时运营部门也没有测试直接放到网站上，并开足马力发送。过了十多分钟查数据发现没有扣费记录，然后重新测了软件才发现原来有个参数改的时候给注释掉了+_+ ......还好群发的数据量不算太大，损失不多......
......
还有很多经典的往事或发生在同事身上的囧事，现在都记不清楚了，而出现这些事情的主要原因是，开发人员没有做好自测工作，太自以为是。当然公司对这一块没有重视也是很重要的原因，并没有形成一套让开发人员自律的规范，缺少测试部门。
3、测试推动开发的成长——将Bug消灭在自测中
还是说说一个小故事，4月份时有两位同事负责一个电子商务网站的注册、登录、密码修改、忘记密码，弄了四五天才搞定（当然除了这个事情外还有其他事情在忙），总是提交测试打回来，然后修改再提交，再打回来......这个重复了N次，气得晴大哥吐血，聊天记录不方便全部发出来，而这种事情是否也曾发生在你、我、他......大家的身上呢？
事后他们自己总结，主要还是不够严谨，粗心大意引起的，且完成后老是自以为这样改改就肯定完事了，没有经过自测就扔到测试环境中。这些大都发生在经验不足的开发者身上，而对于其他老牛来说就极少发生这种事情，因为老牛当初也可能被虐过千百遍后成长起来了。
当然经过这一次深刻的教训后，他们两个都得到了很大的进步，对于要发布的程序自测都做得比较充足，类似的事情就比较少发生。而我们其他程序员在晴哥近半年的鞭挞之下，也有不同程度的长进，整个团队开发出来的质量已不同往日而言了。
4、关于软件测试
软件测试，是用来促进鉴定软件的正确性、完整性、安全性和质量的过程。软件测试的经典定义是：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
对于软件测试，在软件开发周期中，它是非常重要的一项工作。一个软件最终发布后质量如何，这就要看测试专不专业了。
从软件开发的过程按阶段划分有
1）单元测试
2）集成测试
3）确认测试
4）系统测试
5）验收测试
6）回归测试
7）Alpha测试
8）Beta测试
以上是专业测试的分类，而对于我们开发人员经常接触的则是下面这些内容。
Web测试阶段划分主要包括下面内容：
功能测试、界面测试、兼容性测试、安全测试、性能测试（包括负载/压力测试）、预发布测试（如果严格点来说还会分不同环境做多好几种测试）等。
当然也有别外一种说法：功能测试、界面测试、可靠性测试、易用性测试、可维护性测试、性能测试、可移植性测试、安全性测试等。
正常的测试流程包括下面几点（每个阶段大多都会按下面流程来进行）：
1）制定测试计划
2）编写测试用例
3）执行测试用例
4）发现并提交Bug
5）开发人员修复Bug
6）对已修复Bug进行返测
7）将修复完成的Bug关闭，对未修复的Bug重新激活
测试过程中需要编写的文档有很多，但总的来说每个阶段要编写的文档主要有测试计划、测试方案、测试用例和测试报告。
5、关于测试计划
顾名思义，制定测试计划，就是安排好将要进行的测试工作计划。
俗话说没规矩不成方圆，制定出测试计划后才能安排好具体的工作步骤，协调相关人员配合做好相应工作，做好接下来的测试工作。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等（摘自网上，具体内容请有兴趣的朋友自行查找相关文章）。其实也可以简单的理解为，要编写测试计划，首先要查看项目有关的各种文档，了解需求、功能与系统结构，然后再根据功能模块与各个测试阶段来安排工作计划。
做为一个开发人员，我们不需要知道测试计划具体怎么去编写，整个测试计划如何实施，但我们必须了解测试的工作内容是什么，这有利于提高我们开发效率，减少Bug的出现。根据测试计划，我们很容易安排接下来的开发任务，以便配合测试人员做好相应的开发工作。当然我们只有了解了测试的方法方式，我们才能更好的做好自测工作。
简单的测试计划例子：
6、关于测试用例
在将要完成代码工作，进入测试阶段前，通常测试人员会和技术共同开个小会讨论测试的相关工作，而这时测试人员会将他们编写好的测试用例转发一份给到我们。一份详细的测试用例，会带给我们非常多的惊奇喜，使我们发现原来测试还可以这样玩的，程序是这样操作爆出Bug的。就好像突然之前在我们的前面打开了一扇大门，让我们的思路与视野突然开阔了起来。
看到测试师给的测试用例后，才知道自己写的代码对于一些输入判断还是有不少地方没有考虑到的，才知道原来测试是这么做的。多看看测试用例，可以减少我们程序出现的Bug，特别是写购物车、订单之类的功能，稍微一个疏忽就可以产生漏洞，给别人攻击。
会员登陆测试用例：
7、执行测试用例
我们不是大公司，测试师只有晴哥哥一个人，所以提交给他测试前，我们需要进行全面的自测一次，而自测时会按他给我们的测试用例，逐个输入测试一遍。而每一次Bug修改后，也必须做一次全面的测试。对于需要不厌其烦的一遍又一遍的按测试用例操作，对于我这样脾气非常好耐心也不错的人有时都会感到心烦，有时想偷一下懒没有完全按测试用例做好自测工作，就被晴哥哥抓个现行，当然被抓现行的不单是我，还有其他同事，哈哈......看到大家都给虐了一遍，心情自然也不错了......对晴哥哥已经不能说是佩服了，应该是到了五体投地的膜拜这个层次了。
8、发现并提交Bug
通过专业与非专业测试提交的Bug对比后，才知道什么才是专业精神。
在测试时公司会叫上几位客服和运营人员帮忙测试，而他们提交的某些Bug有时会一头雾水，只知道出错了，但不知道是怎么回事。只有简单的几句或截了半个图，认真看了半天也不知道是那个页面做了什么操作后发生了......还得找到当事人慢慢沟通几次让他再演示后才明白，有时他自己也不知道为什么会发生这种情况，在那里截的图，那是真心的无语。
而专业的测试，会详细的写明测试的步骤，提交的内容，正常情况下期望出现的内容，而出现的Bug是如何产生的，再配上几幅详细的截图。一看就清晰明了，重现Bug也相对容易很多，自然修复起来也很容易。
当然做为开发人员，测试师与我们是相辅相成的，从他们的工作态度中就可以看出他们也很不容易，要互相体谅，必竟他们需要反反复复的重复同样的工作，有时心情烦燥也是很正常的，呵呵...
9、开发人员修复Bug
对于本项工作相信大家都经常在做，所以就不再罗嗦了。想提醒的一点时，Bug修改时千万不要粗心大意，很多问题就是这样产生的。而修改完成后一定要按测试用例自测一遍，宁愿花多一点时间，而不是过于自信立马提交，那样做的话很容易出现前面故事所说的那种现象。
10、对已修复Bug进行返测
对于我们提交的Bug修复，测试人员会对这个Bug进行重新测试，责任心强的测试师会从头来过，按测试用例一条条的重新创建记录，进行验证。从中可以看出能当测试的人脾气和耐心是真心的不错，如果大家有妹子未嫁的话，不防可以介绍给测试师哦，哈哈哈......
11、将修复完成的Bug关闭，对未修复的Bug重新激活
测试师返测完毕后，如果没发现有问题就会将Bug关闭，而继续出现Bug，则会重新激活这个Bug......再然后这个程序员就悲哀了......继续他的Bug修复之路......
12、灵活使用压力测试工具
对于开发人员，除了自测外使用测试工具的机会并不多，而在项目进行优化阶段或上线后版本迭代时，使用一些压力测试工具（比如Jmeter）对自己的代码进行压力测试还是很有必要的。如果不懂得压力测试工具的话，那么写出的代码就有可能经受不住上线后的压力，而导致网站访问缓慢、客户流失。同时自己很难分析出代码的瓶颈做好优化工作。
举几个例子给大家看看：
曾经试过对一些客户的网站做过压力测试（中小型电商网），10个并发运行一会后网站就挂掉了。
以前曾参与开发过一个电商网，300个并发运行过后，CPU与内存正常，但服务器出口带宽一会就爆掉了，查明原因是网站图片过多过大，需要将图片与网站服务器分开处理。
也曾试过服务器性能一下降得很利害，检查发现是由于某些数据表记录量过大，导致数据库查询运算占用过长时间，导致CPU飚升。
以前做过的一个电商网，在压力测试时1K并发没有问题，然后对一些关键的数据表添加记录，当记录增加到一定量时就发现了一些异常，检查过后发现是由于使用NOSQL缓存，程序一次性加载的记录量过大时，加载时间过长导致数据加载超时出现异常。
......
从上面例子可以看出，很多问题都可以在上线前通过一些测试工具提前查找出来，而不是上线后出现问题再进行优化处理。有的问题可能可以通过优化手段解决，而有的则可能需要对某些代码，甚至需要对框架架构进行修改才能搞定，提早发现问题可以帮我们减少很多不必要的损失。
当然如果有专业的测试师帮你做好这些工作的话，那开发人员就可以轻松很多。
13、测试与版本控制
我们开发的代码不可避免的需要更新换代，而代码的迭代过程中，测试师是一个非常重要的角色。
虽然绝大多数软件公司都有使用Git、WTF、CVS、Subversion等版本控制工具来管理源代码，而现实中在很多软件公司可以发现这种现象，领导、运营部门或客户提出一个需求进行修改后，则急忙更新到服务器中，根本就没有进行专业的测试，控制好上线版本工作，而由此产生了很多不可预知的各种问题。
在有测试师参与的项目中，这种现象则比较少发生，原因在于专业的测试会对版本控制得比较严格，凡是需要更新到服务器上的程序，都会经过测试师严格的测试且没有问题后，才会更新到服务器上。而每次更新到服务器端的版本，都会经过一系列的测试，而这些版本的源码也会创建一个分支备份，做为一个稳定版本单独保存，其他程序员则在主干继续进行开发，万一更新不成功则可以马上使用上一个版本进行替换。
14、小结
我不是专业的测试，所以很多关于测试的细节就不详细描述了，只从开发的角度来讲讲测试的相关常识，了解一下关于测试的基础知识，如有什么不正确或遗漏之处敬请谅解。
由于时间有限，所以就不对本框架进行全面的测试与编写对应的测试文档（水平有限），希望大家在使用的过程中发现Bug后告诉我一下，我会尽快修复后将补丁发布出来的。
15、附件下载
一些比较专业的内部测试文档不能共享出来，所以找测试拿了一些删减版的测试文档与模板，大家如果有兴趣的话可以下载看看。
由于框架不是非常成熟，很多朋友不是用来学习而是直接用到项目中，但不熟悉框架引起不少小问题，所以停止提供下载，有需要学习的可以到群共享里下，不便之处敬请谅解。
修改模板函数GetFieldValue执行更新时，条件字段为null的异常，更新后请重新生成逻辑层代码
本文转自 AllEmpty 博客园博客，原文链接http://www.cnblogs.com/EmptyFS/p/3838718.html：，如需转载请自行联系原作者
