项目背景
某项目是一个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)遇到了重要事情一定要向上级反应，直至推动事情的解决。
该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，有的低级，有的反反复复激活。
很早笔者向项目经理透露，该项目功能多，逻辑复杂，上手需要一定的时间。后来从其他同事得知该团队的开发技术一般。个人觉得，相比需要有经验的测试，该项目更需要有经验的开发，开发质量在某种程度上决定了项目质量。
小结：这项马拉松式的验收测试，需要持之以恒的耐心、细心和责任心，也是我们测试同学的基本功~
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
