内部cms系统测试

转载至51testing：http://www.51testing.com/html/34/n-4463534.html

内部系统的功能以及如何测试

　　前文有提到，我定义的内部系统，是一个由目前主流语言java开发的web项目(我：和后端语言无关)，每个系统都有对应不同的业务，但后台管理永远都是通用的，也许不同的产品经理对系统的设计会有所不同，我还是可以从中提取出相似的地方。

　　如果恰巧你所在的测试组没有所谓的流程规范，如果恰巧你测试的系统也是我描述的一样，那么不妨看看我为你提供的测试点。

　　再次声明，如果你的系统面对互联网的其他用户或用户量庞大的情况，我提供的这些测试点肯定是不够的，甚至可以拿来当反面教材。

　　内部系统的三大元素，表单、列表、筛选框。

　　表单，

　　功能描述：分为标题、表单域和按钮，表单域，但表单域有个可怕的地方就是，输入框或下拉框会无限的多。

　　测试重点：冒烟、必填项、唯一约束。

　　测试说明：表单测试是一件很麻烦的事，通常每个输入框的必填、唯一、正则都是需要测试的内容，但如果测试时间有限，可以提取出高优先级的几项安排测试。

　　列表，

　　功能描述：从数据库抓取的一大串数组，通过某种排序方式展示出来。

　　测试重点：数据准确性、用户权限对应的数据展示、排序方式合理性、分页的按钮功能。

　　筛选框，

　　功能描述：通常伴随列表使用。

　　测试重点：筛选结果正确性、筛选后对应用户权限、列表筛选后导出。

　　内部系统的三大功能，新建/编辑、删除/禁用，导出。

　　新建/编辑，

　　功能描述：通常都带有表单的功能。

　　测试重点：冒烟、数据关联约束、修改后数据正确、核对数据库。

　　删除/禁用，

　　功能描述：通常是逻辑删除，对应的会有个delete或id_show字段。

　　测试重点：冒烟、数据关联约束、删除后新建、修改后数据正确、核对数据库。

　　导出，

　　测试重点除了筛选导出之外，还要考虑对应数据权限关系。

　　内部系统的两个扩展模块，流程、报表

　　测试工程师的地位以及角色

　　感谢在实习初期当了几天透明人，有幸以测试工程师的职业观察到一个没有测试的项目组测试流程。

　　项目组没有测试这个岗位之前，他们是怎么测试的？测试这个工作大部分分担给产品经理和开发人员，开发人员在按照需求完成一个功能后，会进行一遍自测，觉得没问题后，把代码发布到测试环境并告知产品经理。产品经理到测试环境查看功能是否符合预期效果，提一点使用的建议，之后没问题就可以正式发布版本，如果后续出现bug联系开发人员改一下就好了。

　　通过以上的描述，有没有觉得遗漏了什么环节，对外行人来说，没问题啊，功能开发好了，测试也过了，不就可以正式发布了吗？

　　是的，如果确实是个内部系统，复杂度不高且开发人员<=2时，这么干也不会有什么影响。

　　但是，如果系统因代码出现大的问题，会影响到项目管理人员怎么办？如果系统复杂度和开发人员数量增加，系统还能正常使用吗？

　　在没有出现这些问题之前，很少有人会考虑到。

　　甚至某天出现了致命的系统bug，紧急修复后是否会考虑到测试是否完善或穷尽？

　　测试之路如何开展

　　如果你是实习生，测试组内有位中高级的测试带领，只需要多向你的“师傅”请教问题即可，多学习可别懒散，否则实习考核的时候，“师傅”也救不了你。

　　如果你是实习生，测试组内只有你一个人，我会推荐你赶紧跑，什么话都别听，当然要先找好工作。如果找不到的话...

　　如果你是中高经验的工程师或是测试负责人，以我现在的眼光和心态去思考我会这么做？

　　到一家测试经验为零的公司，首先先跟上级领导交流，言语中不光要了解当前测试环境，还要抓到一点，用户容忍度。

　　比较幸运的是一个新系统从零开始，正好你加入了，这样可以减少很多的时间和精力去了解过去的内容。

　　我个人认为，直接去弄一整套测试流程规范是没有意义的，没法落地，实行难度太大，不如从最小化开始。

　　有三个最容易实行的点，提测、发版、报告。

　　提测，

　　一个功能开发完成到提交测试需要一个什么样的步骤？

　　以往就是直接丢一堆功能给你，具体怎么做，看着办就好，

　　但这次可以先要求开发，提交测试需要正式发邮件，邮件内容包括：功能、代码分支、数据库执行sql等信息。

　　测试根据开发提供的内容，先开始一轮冒烟测试，如果因sql或其他信息没有提供，导致测试进行不下去，打回测试。

　　发版，

　　把系统的发版权限交给测试，但是要做到这一步，你需要对Git、Jenkins和linux怎么使用得心应手。

　　一个系统是否达到上线标准，整个项目组只有测试才是最了解的。

　　报告，

　　测试报告是一个向项目组表示“存在感”很重要的工作，因此在每次生产环境更新的时候，都要对本次测试的内容和过程做一份详细的报告，

　　至于要如何写一份漂亮的测试报告，就不做太多阐述。

　　以上三点做到后，基本上测试流程已经有了一个规范，测试的“存在感”也变得越来越明显。

　　再往后可以怎么做？

　　参与需求评审、完善bug生命周期、开发回应bug的效率等等。

　　我遇到的那些暗坑

　　列表筛选后分页；

　　导入的时候，数据超过一千条；

　　不区分大小写的密码；

　　数据库的字段有空格；

　　增加筛选项，测筛选以及筛选+导出；

　　我的期望&尾声

　　说了这么多，算是吐槽也算是经验总结，再一次感谢能有耐心看到这里。

　　其实很多的意外（系统的bug）都可以避免，毕竟测试的工作就是为用户“蹚雷”，

　　如果还有机会规整这些测试流程，我的期望不光是测试流程和制度的规范，甚至还可以扩展到整个项目周期。

　　说一说我对未来系统的期望吧。

　　系统功能新增更新公告

　　内部系统在上线的时候，总是会存在一堆的功能不足和影响面不大的bug，比如某个列表筛选框功能没有实现，用户在第一次使用的时候发现这个问题，肯定在以后很长一段时间都不会再次使用这个筛选。

　　在登录页面或首页上，加上一个更新公告，对每次迭代开发的新功能以及bug修复，无论会不会有人开，起码都代表着项目组的诚意，个别情况下还能间接展示了工作了内容。

　　系统上线的时间能由测试来统筹

　　系统何时上线，真的不应该是一两句话就能说准的事，开发要评估开发时间，测试要评估测试时间，还要加上产品经理对接梳理需求以及服务器准备的一些操作，这些事情都是很占用时间。

　　对测试而言，测试的工作包括前期信息收集、测试分析、测试用例、测试施行、bug跟踪反馈以及最后的测试报告。

　　所以希望在未来，上线时间可以交给测试。

　　以上，就是我关于“内部系统”的一些见解，