51Testing软件测试网正在收集测试行业问卷结果,如果你也想为测试行业的前景助力,就点击下方的链接提交答案吧,还有精美礼品等你拿(测试课程五选二)。链接:http://vote.51testing.com/
项目背景
某项目是一个OA管理系统(外包给一家南方公司),以JAVA为开发语言、VUE为前端框架、MySQL为后端数据库管理系统。去年9月开始立项、开发,一直到今年6月中旬发布,减除项目暂停期间,共历经7个多月。
项目规模
该系统主要由六大模块组成。项目成员有1名项目经理、1名开发经理、10余位开发、2名测试。
项目测试情况
2021年11月份末,部门经理找到笔者,让笔者到该OA系统项目做测试。由于要兼顾其他项目,每天有50%左右时间来做该系统的功能测试,大概持续1个月测试随项目暂停。
2022年3月底,再度接到部门经理的通知,要进行该项目的验收测试。撸起袖子加油干,先制定了项目验收计划。
接着找出编写过的测试点、重新梳理,并在验收测试过程中逐步完善。测试点分为两份,其中第一份覆盖全面,每个模块功能粒度很细,而上线前时间有限不允许全面测试,覆盖了重点模块主要业务流程即可。
验收测试一共经历了3轮,第一轮1次迭代,第二轮6次迭代,第三轮20次迭代,进行更为严格的测试。
项目测试过程中遇到的问题及小结
1. 保证送测版本的质量
第一轮验收测试,执行了第一个模块的41条测试用例,用时1周,测试用例执行失败率高达21.95%,笔者当晚马上向项目经理反馈,并推测未来的bug数量将不少于80。后续的测试也证实了,bug数量确实是超了80,总数正好达100封顶。
项目经理在第二天即发出邮件通知外包方先进行内部测试,测试通过后再继续验收。随后外包方进行了内部测试,内部测试通过后笔者继续进行验收测试。项目经理的这个叫停决定很有效地保证了送测版本的质量,双方都减轻了压力,节约了时间。
小结一下:
(1)送测版本是需要制定一个标准的。在项目开始时要跟项目组约定,比如送测后已知bug数量超过N个,则打回版本停止测试。这里N可以根据项目或团队讨论决定。
(2)遇到了重要事情一定要向上级反应,直至推动事情的解决。
2. 重复的工作用selenium自动化测试替代
该OA系统中流程模块是重点,主要涉及10张表单及流程,其中假别又分为11种假别类型。新建流程类是重复工作之一,除了下拉选择流程类别,其他字段一样,自然想到用到selenium自动化测试来解决。
其次是发起11种请假类型,除了请假类别下拉选择,其他字段也一样,同样可用selenium自动化测试。第三,除了10张表单创建外,10张表单的审批功能也类似,可以用自动化脚本解决。笔者可以有更多的时间去做沟通、交互逻辑测试、测试数据分析、整理汇报等,效果还可以。
期间参加了一个前后端综合测试训练营,有效地改进了bug定位方法,给外包开发同学提供有用的bug接口参数响应信息,收获颇多。
小结:重复工作可以自动化。
3. 沟通以诚为本
外包公司派来一位前端同学,配合修改bug,并为外包内部开发人员和笔者中转沟通。笔者本着以诚为本的态度,所谓金诚所至金石为开,除了bug截图,对于不易再现或者双方有分歧的地方,提供传参和请求响应截图、录屏,能提供有助于定位bug解决bug的信息全力提供,所有能用上的方法都用上。
最后要相信团队的力量,项目组员终因测试的真诚而认真处理bug,最终一起保证项目的质量和交付。
4. 开发后期修复bug的成本永远比前期高出许多
去年9月份至今年1月份期间,该系统已暴露的功能类bug100多,UI类bug100多,其中UI类bug基本解决,功能类bug迟迟未完全修复。直到验收测试阶段,缓慢地推进新bug的解决,系统趋近于稳定。
截止笔者写稿时,尚有一个用户体验的问题在开发同学手中加班修复中,其余九十多个bug已全部解决。从时间跨度看,如果在去年项目前期解决了,不至于在今年验收阶段,花整整2个月时间测试、修复。希望小伙伴们项目团队可以引以为戒,在bug被暴露的时候就解决。这也很好地解释了测试的准则之一“尽早测试尽早发现bug”的真谛~
5. 持之以恒
由于项目周期长,开发团队新旧血液更换,时间长了业务容易遗忘、换了开发人员业务不熟悉不那么快速上手,导致测试过程中发现的bug,有的低级,有的反反复复激活。
很早笔者向项目经理透露,该项目功能多,逻辑复杂,上手需要一定的时间。后来从其他同事得知该团队的开发技术一般。个人觉得,相比需要有经验的测试,该项目更需要有经验的开发,开发质量在某种程度上决定了项目质量。
小结:这项马拉松式的验收测试,需要持之以恒的耐心、细心和责任心,也是我们测试同学的基本功~
作者:枫叶