“内部系统”怎么测试?两年测试的总结与反思

发表于:2019-12-04 11:43

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:祝新新zxy    来源:博客园

  前言
  也许身处项目组,作为测试的你在孤军奋战,陌生的环境,同事全是开发,领导是技术/业务经理,这时有一个系统需要你测试,没有参与需求评审没有需求文档更没有测试流程,有的只是一个粗糙的原型。
  这样的背景下,会有一种绝望感吗?我不知道,但我确实经历了这一切,并改善了这个局面。前后共经历两年时间,我将会在此书写与内部系统的恩怨情仇。
  我记得大四实习时最早接触的,是个报表系统,在完全不知道测试要干什么的情况下,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跟踪反馈以及最后的测试报告。
  所以希望在未来,上线时间可以交给测试。
  以上,就是我关于“内部系统”的一些见解。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号