工作中，怎么做好规范
日常工作中怎么做好规范？
——测试规范流程
规范的重要性不言而喻，从刚进入公司的第一天老大就在强调规范的重要性。记得当时，自己面试岗位是的网页设计，在编写页面代码时，自己定义了三个类名，分别为”a b c”3个类名，记得当时老大问我，“为什么要用这3个类名命名？”当时，我心中就感觉很奇怪，命名还要有什么要求吗？当时的自己对此非常的不解和困惑。
由于自己的工作性质主要是技术支持和软件测试，在该文档中，就围绕“测试规范流程”而展开本文的开篇。对于项目前期时，新增加的一个或者几个需求功能，测试人员只要检查软件的功能是否正常就可以了，因为系统不是很大，覆盖的功能点很少，同时需要考虑的问题也较少，所有测试也就显得不是那么规范化。但是随着项目后期的扩展，慢慢的测试人员会发现，越来越多的功能，自己一个人越来越显得力不从心，这时，就迫切需要一个规范的测试流程去引导测试工作有条不紊的进行。
一、日常工作中怎么做好规范呢？
规范的测试流程有助于需求条理化，将测试工作模块化，一切跟着计划走比通过脑袋记忆要更加的有条理。有的时候，工作任务比较繁琐，脑袋记忆力容易出现乱成一锅粥的情况，特别这个时候，测试计划就更加重要。下面结合实际情况对自己工作中测试流程进行简单的说明，纯属个人意见。
1．制定测试策略
首先测试策略，当用户提出新的需求时，测试人员应该和开发人员一起做测试需求分析，一般我们都会通过会议的形式去进行讨论分析，这样测试人员会对测试需要有个大概的了解，需要是干什么的，包括哪些功能等等，而不至于什么都不清楚不了解。
2．制定测试计划
大概了解需求内容之后，要对整个测试进行预期估算，包括计划要测试哪些方面的功能，要计划分配哪些人员参与到测试中，哪些人负责哪个模块，以及按照交叉测试的方法，同时还要计划要测试的开始和结束时间，便于掌控这个测试进展等等。
3．编写测试用例
测试计划规范之后，则是进行测试用例的编写。测试用例的编写，主要围绕界面模块而展开，如界面包括哪些按钮，按钮操作是否可以正常进行，其次围绕功能来设计，然后根据不同的场景来设计。对于测试过程中，出现的缺陷问题，要在将缺陷问题记录到测试用例“测试结果”一列，便于查看测试项测试任务情况。
4．形成测试报告
测试用例执行之后，对于测试过程中发现的缺陷问题，要汇报自己的测试情况并且测试中的缺陷反馈到测试工具中，便于开发人员解决。对于安排的不同模块的负责人在测试自己对应模块的任务时，也要及时的汇报自己的测试日工作进度，便于测试小组掌握测试的整个进度。
5．测试总结及文档编写
按照测试用例执行完所有的测试任务，且开发人员修复完了所有的bug问题（不包含一些难以修复但不紧急的问题，），测试人员需要编写针对本次项目的测试总结，要在总结中说明，测试计划是否按照如期进行。总测试缺陷数据多少，测试覆盖了多少等等。
同时文档人员要针对本次项目开发新增加的功能进行项目“升级日志”和“帮助手册”任务的编写。便于用户了解并能够快速上手使用新增加的功能。
二、不规定的行为有哪些？
随着后期慢慢的参与到项目中，才逐渐发现规范的重要。代码一个标点符号的缺少，页面样式一个花括号的缺少，action标签路径的写错等等这些都能导致后期产生大的影响。本文档列举自己的工作中一个不规范的事例来进行说明。希望能引发大家的反思。
事例：在Boss后台进行关于“澳洲经贸博览会”HTML页面的维护上传；
不规范行为：在编写文章对应分类编码时，分类编写书写的不规范，没有和链接code对应一致，同时在书写分类地址链接时，使用了绝地路径等问题；
影响：导致页面不能及时的随着数据更新，即第二次再次编辑HTML静态页面时，出现了数据不更新的情况。这个问题，花费了自己2个小时的时间去检查，排查。
虽然说，这些错误都是一些小错误，是很好解决的，但是一旦我们的项目上线，出现了bug，所有的代码问题都要重新检查一遍，带来的后期的维护检查成本是非常大的，这个时候，规范就显得由于重要。
三、怎么避免这些不规范的行为
1．明确开发需求任务，必要时需要和客户反复确认；
2．开发代码，增加注释以及开发结束之后，增加code review;
3．测试周期严格要求，制作有效的测试计划，并按照计划执行；
4．开发代码，增加注释以及开发结束之后，增加code review;
5．形成文档注释的习惯，可以方便后期代码重构和代码查阅等等；
四、总结
本次通过针对自己实际工作，阐述了工作中怎么做到规范以及规范的要点，同时举例说明有哪些不规范的行为存在，这些不规范带来的影响以及怎么尽量避免不规范的行为都做了大概的说明。其目的是提高大家对规范性的重视，并将规范应用到平时的工作中，这样在以后的工作或者代码维护中都起到很好的作用的，规范是需要每个人反思和重视的。
