从零开始编写本身的C#框架（24）——测试

　　导航

---

　　一、前言

　　二、不堪回首的开发往事

　　三、测试推进开发的成长——将Bug消灭在自测中

　　四、关于软件测试

　　五、制定测试计划

　　六、编写测试用例

　　七、执行测试用例

　　八、发现并提交Bug

　　九、开发人员修复Bug

　　十、对已修复Bug进行返测

　　十一、将修复完成的Bug关闭，对未修复的Bug从新激活

　　十二、灵活使用压力测试工具

　　1三、测试与版本控制

　　1四、小结

　　1五、附件下载

---

 

　　一、前言

　　对于测试，不少公司并不看重，接触过很多朋友或客户，打开网站随便点击一下，就能够很容易发现爆黄页、40四、UI变型（浏览器兼容）、流程走不通、错别字......等各类各样的错误。固然也包括我之前工做过的公司，基本上都将测试交给了客户或网站来访者，发现有问题时常常是出了问题之后。

　　而我本身一直以来也一样对这一块不熟悉，虽然以为它很重要，但只存在概念上的东西，而不知道怎么去实施。经手的产品上线前也是本身简单的测试后以为没有问题就上线，而不是系统的测试。直到去年下半年，公司招了位在某互联网知名公司的测试工程师大牛晴哥哥过来后，我才真正明白什么叫测试，给我上了一堂宝贵的课程，在他的淫威之下，整个技术团队得以很是明显的进步，固然我也有了很明显的成长，在此对晴哥哥无私的付出与帮忙表示真诚的感谢，谢谢了。

 

　　二、不堪回首的开发往事

　　几乎每一个开发人员都会坚信本身的此次修改完成经过，没有Bug，而后一次次被击毁这种幻想回到现实。这种经历犯傻的事情我之前也常常发生，而结果可想而知。

　　0三、04年的时候，开发的网站基本上没测试就直接放上线，常常报黄页或出错后，才立马进行修改，弄得晕头转向的。

　　08年的时候在深圳一家软件公司上班，有一次帮东莞客户在供应链管理系统增长一些新的功能，在本地写完程序后自我检查后以为没有问题，而后更新代码并写SQL语句更新数据，其中有一条删除语句要删除某个条件的记录，动手以前想得好好，可写的时候忘了加条件，而后直接在生产环境上提交执行......将整个表记录全删除了，而当时又不懂数据恢复，公司也不给权限上百度那些网站，整我的一下就蒙了......还好老板那里有数据库备份，帮忙恢复了回去......

　　11年的时候在作KJava手机端应用开发，有一次要对应用进行一次很小的修改，改完后自我感受应该对其余地方没有影响，而后就提交给运营部门作群发，当时运营部门也没有测试直接放到网站上，并开足马力发送。过了十多分钟查数据发现没有扣费记录，而后从新测了软件才发现原来有个参数改的时候给注释掉了+_+ ......还好群发的数据量不算太大，损失很少......

　　......

　　还有不少经典的往事或发生在同事身上的囧事，如今都记不清楚了，而出现这些事情的主要缘由是，开发人员没有作好自测工做，太自觉得是。固然公司对这一块没有重视也是很重要的缘由，并无造成一套让开发人员自律的规范，缺乏测试部门。

 

　　三、测试推进开发的成长——将Bug消灭在自测中

 　　仍是说说一个小故事，4月份时有两位同事负责一个电子商务网站的注册、登陆、密码修改、忘记密码，弄了四五天才搞定（固然除了这个事情外还有其余事情在忙），老是提交测试打回来，而后修改再提交，再打回来......这个重复了N次，气得晴大哥吐血，聊天记录不方便所有发出来，而这种事情是否也曾发生在你、我、他......你们的身上呢？

　　

　　过后他们本身总结，主要仍是不够严谨，粗枝大叶引发的，且完成后总是自觉得这样改改就确定完事了，没有通过自测就扔到测试环境中。这些大都发生在经验不足的开发者身上，而对于其余老牛来讲就极少发生这种事情，由于老牛当初也可能被虐过千百遍后成长起来了。

　　固然通过这一次深入的教训后，他们两个都获得了很大的进步，对于要发布的程序自测都作得比较充足，相似的事情就比较少发生。而咱们其余程序员在晴哥近半年的鞭挞之下，也有不一样程度的长进，整个团队开发出来的质量已不一样往日而言了。

 

　　四、关于软件测试

　　软件测试，是用来促进鉴定软件的正确性、完整性、安全性和质量的过程。软件测试的经典定义是：在规定的条件下对程序进行操做，以发现程序错误，衡量软件质量，并对其是否能知足设计要求进行评估的过程。

　　对于软件测试，在软件开发周期中，它是很是重要的一项工做。一个软件最终发布后质量如何，这就要看测试专不专业了。

　　从软件开发的过程按阶段划分有
　　1）单元测试
　　2）集成测试
　　3）确认测试
　　4）系统测试
　　5）验收测试
　　6）回归测试
　　7）Alpha测试
　　8）Beta测试

　　以上是专业测试的分类，而对于咱们开发人员常常接触的则是下面这些内容。

　　Web测试阶段划分主要包括下面内容：

　　功能测试、界面测试、兼容性测试、安全测试、性能测试（包括负载/压力测试）、预发布测试（若是严格点来讲还会分不一样环境作多好几种测试）等。

　　固然也有别外一种说法：功能测试、界面测试、可靠性测试、易用性测试、可维护性测试、性能测试、可移植性测试、安全性测试等。

　　正常的测试流程包括下面几点（每一个阶段大多都会按下面流程来进行）：
　　1）制定测试计划
　　2）编写测试用例
　　3）执行测试用例
　　4）发现并提交Bug
　　5）开发人员修复Bug
　　6）对已修复Bug进行返测
　　7）将修复完成的Bug关闭，对未修复的Bug从新激活

　　测试过程当中须要编写的文档有不少，但总的来讲每一个阶段要编写的文档主要有测试计划、测试方案、测试用例和测试报告。

 

　　五、关于测试计划

　　顾名思义，制定测试计划，就是安排好将要进行的测试工做计划。

　　俗话说没规矩不成方圆，制定出测试计划后才能安排好具体的工做步骤，协调相关人员配合作好相应工做，作好接下来的测试工做。一个测试计划应包括：产品基本状况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等（摘自网上，具体内容请有兴趣的朋友自行查找相关文章）。其实也能够简单的理解为，要编写测试计划，首先要查看项目有关的各类文档，了解需求、功能与系统结构，而后再根据功能模块与各个测试阶段来安排工做计划。

　　作为一个开发人员，咱们不须要知道测试计划具体怎么去编写，整个测试计划如何实施，但咱们必须了解测试的工做内容是什么，这有利于提升咱们开发效率，减小Bug的出现。根据测试计划，咱们很容易安排接下来的开发任务，以便配合测试人员作好相应的开发工做。固然咱们只有了解了测试的方法方式，咱们才能更好的作好自测工做。

　　简单的测试计划例子：

　　

　　

 

　　六、关于测试用例

　　在将要完成代码工做，进入测试阶段前，一般测试人员会和技术共同开个小会讨论测试的相关工做，而这时测试人员会将他们编写好的测试用例转发一份给到咱们。一份详细的测试用例，会带给咱们很是多的惊奇喜，使咱们发现原来测试还能够这样玩的，程序是这样操做爆出Bug的。就好像忽然以前在咱们的前面打开了一扇大门，让咱们的思路与视野忽然开阔了起来。

　　看到测试师给的测试用例后，才知道本身写的代码对于一些输入判断仍是有很多地方没有考虑到的，才知道原来测试是这么作的。多看看测试用例，能够减小咱们程序出现的Bug，特别是写购物车、订单之类的功能，稍微一个疏忽就能够产生漏洞，给别人攻击。

　　会员登录测试用例：

　　

 

　　七、执行测试用例

　　咱们不是大公司，测试师只有晴哥哥一我的，因此提交给他测试前，咱们须要进行全面的自测一次，而自测时会按他给咱们的测试用例，逐个输入测试一遍。而每一次Bug修改后，也必须作一次全面的测试。对于须要不厌其烦的一遍又一遍的按测试用例操做，对于我这样脾气很是好耐心也不错的人有时都会感到心烦，有时想偷一下懒没有彻底按测试用例作好自测工做，就被晴哥哥抓个现行，固然被抓现行的不单是我，还有其余同事，哈哈......看到你们都给虐了一遍，心情天然也不错了......对晴哥哥已经不能说是佩服了，应该是到了五体投地的膜拜这个层次了。

 

　　八、发现并提交Bug

　　经过专业与非专业测试提交的Bug对比后，才知道什么才是专业精神。

　　在测试时公司会叫上几位客服和运营人员帮忙测试，而他们提交的某些Bug有时会一头雾水，只知道出错了，但不知道是怎么回事。只有简单的几句或截了半个图，认真看了半天也不知道是那个页面作了什么操做后发生了......还得找到当事人慢慢沟通几回让他再演示后才明白，有时他本身也不知道为何会发生这种状况，在那里截的图，那是真心的无语。

　　而专业的测试，会详细的写明测试的步骤，提交的内容，正常状况下指望出现的内容，而出现的Bug是如何产生的，再配上几幅详细的截图。一看就清晰明了，重现Bug也相对容易不少，天然修复起来也很容易。

　　固然作为开发人员，测试师与咱们是相辅相成的，从他们的工做态度中就能够看出他们也很不容易，要互相体谅，必竟他们须要反反复复的重复一样的工做，有时心情烦燥也是很正常的，呵呵...

 

　　九、开发人员修复Bug

　　对于本项工做相信你们都常常在作，因此就再也不罗嗦了。想提醒的一点时，Bug修改时千万不要粗枝大叶，不少问题就是这样产生的。而修改完成后必定要按测试用例自测一遍，宁愿花多一点时间，而不是过于自信立马提交，那样作的话很容易出现前面故事所说的那种现象。

 

　　十、对已修复Bug进行返测

　　对于咱们提交的Bug修复，测试人员会对这个Bug进行从新测试，责任心强的测试师会从头来过，按测试用例一条条的从新建立记录，进行验证。从中能够看出能当测试的人脾气和耐心是真心的不错，若是你们有妹子未嫁的话，不防能够介绍给测试师哦，哈哈哈......

 

　　十一、将修复完成的Bug关闭，对未修复的Bug从新激活

　　测试师返测完毕后，若是没发现有问题就会将Bug关闭，而继续出现Bug，则会从新激活这个Bug......再而后这个程序员就悲哀了......继续他的Bug修复之路......

 

　　十二、灵活使用压力测试工具

　　对于开发人员，除了自测外使用测试工具的机会并很少，而在项目进行优化阶段或上线后版本迭代时，使用一些压力测试工具（好比Jmeter）对本身的代码进行压力测试仍是颇有必要的。若是不懂得压力测试工具的话，那么写出的代码就有可能经受不住上线后的压力，而致使网站访问缓慢、客户流失。同时本身很难分析出代码的瓶颈作好优化工做。

　　举几个例子给你们看看：

　　曾经试过对一些客户的网站作过压力测试（中小型电商网），10个并发运行一会后网站就挂掉了。

　　之前曾参与开发过一个电商网，300个并发运行事后，CPU与内存正常，但服务器出口带宽一会就爆掉了，查明缘由是网站图片过多过大，须要将图片与网站服务器分开处理。

　　也曾试过服务器性能一降低得很利害，检查发现是因为某些数据表记录量过大，致使数据库查询运算占用过长时间，致使CPU飚升。

　　之前作过的一个电商网，在压力测试时1K并发没有问题，而后对一些关键的数据表添加记录，当记录增长到必定量时就发现了一些异常，检查事后发现是因为使用NOSQL缓存，程序一次性加载的记录量过大时，加载时间过长致使数据加载超时出现异常。

　　......

　　从上面例子能够看出，不少问题均可以在上线前经过一些测试工具提早查找出来，而不是上线后出现问题再进行优化处理。有的问题可能能够经过优化手段解决，而有的则可能须要对某些代码，甚至须要对框架架构进行修改才能搞定，提前发现问题能够帮咱们减小不少没必要要的损失。

　　固然若是有专业的测试师帮你作好这些工做的话，那开发人员就能够轻松不少。

 

　　1三、测试与版本控制

　　咱们开发的代码不可避免的须要更新换代，而代码的迭代过程当中，测试师是一个很是重要的角色。

　　虽然绝大多数软件公司都有使用Git、WTF、CVS、Subversion等版本控制工具来管理源代码，而现实中在不少软件公司能够发现这种现象，领导、运营部门或客户提出一个需求进行修改后，则急忙更新到服务器中，根本就没有进行专业的测试，控制好上线版本工做，而由此产生了不少不可预知的各类问题。

　　在有测试师参与的项目中，这种现象则比较少发生，缘由在于专业的测试会对版本控制得比较严格，凡是须要更新到服务器上的程序，都会通过测试师严格的测试且没有问题后，才会更新到服务器上。而每次更新到服务器端的版本，都会通过一系列的测试，而这些版本的源码也会建立一个分支备份，作为一个稳定版本单独保存，其余程序员则在主干继续进行开发，万一更新不成功则能够立刻使用上一个版本进行替换。

 

　　1四、小结

　　我不是专业的测试，因此不少关于测试的细节就不详细描述了，只从开发的角度来说讲测试的相关常识，了解一下关于测试的基础知识，若有什么不正确或遗漏之处敬请谅解。

　　因为时间有限，因此就不对本框架进行全面的测试与编写对应的测试文档（水平有限），但愿你们在使用的过程当中发现Bug后告诉我一下，我会尽快修复后将补丁发布出来的。

 

　　1五、附件下载

 　　一些比较专业的内部测试文档不能共享出来，因此找测试拿了一些删减版的测试文档与模板，你们若是有兴趣的话能够下载看看。

测试文档.rar

 

因为框架不是很是成熟，不少朋友不是用来学习而是直接用到项目中，但不熟悉框架引发很多小问题，因此中止提供下载，有须要学习的能够到群共享里下，不便之处敬请谅解。

 

修改模板函数GetFieldValue执行更新时，条件字段为null的异常，更新后请从新生成逻辑层代码

 

 

 版权声明：

　　本文由AllEmpty原创并发布于博客园，欢迎转载，未经本人赞成必须保留此段声明，且在文章页面明显位置给出原文连接，不然保留追究法律责任的权利。若有问题，能够经过1654937@qq.com 联系我，很是感谢。

 

　　发表本编内容，只要主为了和你们共同窗习共同进步，有兴趣的朋友能够加加Q群：327360708 ，你们一块儿探讨。

 

　　更多内容，敬请观注博客：http://www.cnblogs.com/EmptyFS/