‘内部系统’怎么测试？两年测试的总结与反思

前言

    也许身处项目组，作为测试的你在孤军奋战，陌生的环境，同事全是开发，领导是技术/业务经理，这时有一个系统需要你测试，没有参与需求评审没有需求文档更没有测试流程，有的只是一个粗糙的原型。

    这样的背景下，会有一种绝望感吗？我不知道，但我确实经历了这一切，并改善了这个局面。前后共经历两年时间，我将会在此书写与内部系统的恩怨情仇。

    我记得大四实习时最早接触的，是个报表系统，在完全不知道测试要干什么的情况下，boss给了我一个原型以及10.10.*.*的地址，哦...还有admin帐号以及登录密码。后来陆陆续续地接触了许多测试同事、测试领导，来来往往，从一个人的测试组最终还是回到了初始化状态。

    这篇博客我认为也可以称之为：“一个人的测试应该怎么玩？”，但以此命名似乎不严谨，因为在我后来的了解，很多互联网相关的初创公司也会出现测试独苗的尴尬情况，对于用户体验以及其他非功能性测试非我所长。又或者命名为：“传统的web系统”，思前想后还是觉得“内部系统”更加贴切。

    书写我的测试经历，分享我看到的、我想到的，给我的两年工作做个总结，从总结中发现该反思的点。

    如果此刻点开此篇博客的你，将要对传统web系统进行测试工作，希望可以提供一些帮助；如果您对此不屑一顾，就请您到此为止，能被当成茶余饭后的谈资，不胜荣幸。

 

现状

    首先送给你的第一句话，作为测试，不必行螳臂挡车之举，讲究顺势而为，以万变应不变，至于为什么这么说，我先讲一讲内部系统的现状吧。

    所谓的内部系统，通俗来讲，就是自己开发的软件，自己使用。

    我所能了解到最早的测试，是一篇关于2006年左右发表的分析国内软件测试现状，即使现在Baidu当年的软件测试，也能找到很多相关的讨论。

    花开两朵，各表一枝，先说说早些年的软件测试行业。

    我对早些年的论坛讨论加以分析和整合，甚至充入一些我的想象得出结论：在国内软件发展起步较晚的情况下，软件测试这个行业还处于懵懂无知的状态，所谓的专业软件公司，开发出软件后bug一大堆，并不加以测试就直接交付给客户，至于bug肯定是不会修复，反正客户已经付过钱了。

    再过几年，有了软件测试工程师这个职位，但测试的流程和制度并未出现，项目组内除测试之外达成了一条共识，开发把软件写好以后部署到测试服务器，让测试去点点页面看看有没有什么bug，由此整个IT行业内出现了一句话“软件测试只是点点点”。这句话影响了未来多年时间，直到17、18年软件测试的招聘要求不断提高，点点点这个名词开始消声灭迹，但仍然存在于各个角落，甚至已经被外行人给这个职业刻上了印子。

    大批软件测试从业者在思考这个行业到底有没有前途？（为什么我会搜这些内容，因为我也深陷在这个难题中很久，最可怕的永远是自我怀疑。）答案是什么？打开招聘网看看，现在测试的薪资并不比开发低。

    再说回现在的内部系统，整个测试流程形同虚设，很像点点点。最大的诟病就是“求快”，一个系统还未确定复杂度的情况下，就要先评估或制定完成时间。就好比马拉松比赛不告诉你多少公里数，就问你一天能不能跑完，或者连问的机会都不给你。

    因为快，引发的一系列问题，产品经理要快，原型和需求文档必须马上写完；技术经理要快，架构和数据结构以及所有开发人员的工作计划要列好；测试要快，尽早地完成测试提交测试报告，这样系统可以准时交付。

    结果有俩，一是延期上线，理由千变万化，不会影响测试；二是准时上线，会不会出现bug，看运气，运气好则平安无事，运气不好，即便是不追究责任，作为测试的你怎么面对项目组成员“仇恨”的目光？

    至于在项目筹划期间，对系统的要求是什么？能用。可是能用这个词太笼统，每个人对能用的理解都不同，有的人认为打开浏览器输入网址能登录就行，有的人认为界面要美观，帐号输入框要好看。

    能用的下一步是什么，功能实现。比如要给系统添加帐号，能正常添加帐号完毕后，就算功能实现吗？万一哪天这个帐号的使用者不在这干了，有删除/禁用帐号的功能吗？就算有，能确保这个帐号不能登录系统吗？

    以此类推，可以不停的举例，不停的延伸扩展，以上就是内部系统的现状。

    一句话总结，流程和标准不完善。

 

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

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

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

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

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

    表单，

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

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

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

    列表，

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

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

    筛选框，

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

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

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

    新建/编辑，

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

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

    删除/禁用，

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

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

    导出，

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

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

 

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

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

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

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

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

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

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

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

 

测试之路如何开展

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

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

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

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

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

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

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

    提测，

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

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

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

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

    发版，

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

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

    报告，

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

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

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

    再往后可以怎么做？

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

 

我遇到的那些暗坑

    列表筛选后分页；

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

    不区分大小写的密码；

    数据库的字段有空格；

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

    

我的期望  & 尾声

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

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

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

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

    系统功能新增更新公告

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

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

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

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

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

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

 

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

    博客园ID：祝新新zxy