项目系统介绍
地质系统——主要作用进行地质数据建模、数据收集、数据计算及数据传递。
执行系统——主要根据地质系统传过来的数据，如平面地质图、巷道现状图等进行车辆调度并统计相关生产数据。
Mes系统——主要用于从相关系统获得的数据进行日报展示、大屏重点数据展示及相关数据业务数据展示。
各系统间逻辑关系：数据获取-计算-执行-展示。
项目背景：没有详细的需求文档，测试人力少 （2人）。
用例编写
用例的重要性
有时候因为时间紧张，没有编写测试用例，虽然可能会在一定程度上节省时间，但是这也可能导致关键的测试点被遗漏，从而影响测试的全面性和准确性。编写测试用例能够确保系统的各个方面都得到验证，避免了因为遗忘而导致潜在问题的出现，为产品质量提供了有力保障。
编写测试用例在软件开发和测试过程中具有重要作用，以下是几个我认为编写用例优势：
省时间
测试用例可以准确地描述测试步骤和预期结果，从而帮助测试人员高效地执行测试。这有助于减少测试过程中的时间浪费，提高测试效率。
逻辑清晰
用例的逻辑结构使测试人员在执行测试时能够轻松理解测试的目的和流程。即使在测试过程中被打断，测试人员也可以轻松恢复并继续测试。如果没有用例作为参考，很有可能发生测试跑偏现象。
记录存档
编写的测试用例可以作为文档存档，记录了测试过程中执行的步骤和结果。这对于追踪测试进度、检查测试历史以及与团队成员共享信息非常有用。
避免遗忘
通过编写测试用例，您可以确保测试所有关键功能和场景，避免以后再次提测时相关业务原理遗忘。
业务点再梳理
编写用例需要深入理解软件功能，并将业务需求转化为具体的测试步骤。这有助于发现业务需求中的不一致性和遗漏，从而进一步完善产品。
编写用例注意点
关注主要逻辑和数据走向
确保用例覆盖系统的主要功能逻辑和数据交互路径，以保证各个关键部分都经过测试。
如采矿主要业务流程：
设计系统间的关键数据包括：
地质系统进行采准、采矿、排线、中深孔设计、装药设计、爆破状态修改；
调度系统进行的 中深孔调度、装药调度；
生产管理系统进行的 查看各种排线设计图、统计日报、生产大屏查看数据。
按照这种业务的数据流关注主要数据走向。上面只是举了一个案例，任何系统都可以按照这个思路进行。
测试验证结果
用例应当明确定义预期结果，确保测试验证的结果不会遗漏任何重要点，从而保证系统的功能和性能达到预期。
换句话说，也就是关键步骤执行完成后验证的结果不要缺失，举个例子：
中深孔设提交成功后，在测量管理下会生成最新的中深孔设计图，在采矿计划下也会生成最新的中深孔设计图，所以这些相关文件的数据需要进行确认。
评审流程
在编写用例后，进行团队评审是很重要的一步，通过多人的审查可以发现潜在的问题，提高用例的质量和覆盖度，确保测试的全面性。
当组织中没有这个流程时，建议自己也提出申请，当别人提出意见和不足时，我们才能够成长。
测试执行
开发自测
开发自测是指开发人员在完成代码编写后，自行对其进行测试以验证其功能的正确性和稳定性。
这一阶段开发人员往往存在的问题：
1、不知道业务关键流程，上游和下游业务不通；
2、自测过程随意、没有标准化 ，也就是没有按照业务的实际步骤进行测试，比如需要终端执行的业务，在服务端手动添加数据代替。
综上，自测环节能规避一些问题，但是效果不太理想。
现场联调测试
测试模式
本次测试采用开发+测试联调进行 ，测试发现问题，开发及时进行修改。
为什么要进行这种模式呢？
根据之前经验，这种系统间的联调，尤其是不同系统之间的接口即使已经在测试环境调通，在生产环境很有可能数据不通，测试+回归完成至少2个月时间，迫于时间成本我们采用了这种敏捷的方式。
用例合并
测试过程中，根据之前编写的用例开始测试。主要注意两点：
1 做好结果记录；
2做好bug记录。
测试完场后要对不同人执行的测试用例进行合并，保证测试结果的完整性。
Bug记录
BUG记录模板：
描述步骤清晰，尤其是预期结果实际结果描述清楚，尽量要保存截图。
模板：
中深孔计划查看排线设计图，未显示排线设计刚刚上传的文件【中深孔计划一段时间有最新图，回采计划一直没有】。
步骤：
1、排线设计-中深孔设计-保存排线设计图-提交；
2、计划账号登录-中深孔计划-查看排线设计图。
备注：排线设计执行撤销操作后，排线设计图也显示6条排线。
定时反馈问题
影响流程业务：影响后续测试bug，即使沟通处理，尽快解决。
不影响流程业务：找一个时间段如每天下班前1小时，集中分别反馈问题，确保相关责任人理解问题，排除环境、数据等因素，保证测试的有效性。
测试结果跟踪
Bug状态跟踪
确认 Bug 跟踪是软件开发和测试过程中的一个重要环节，用于确认在软件中发现的问题（Bug）是否已经得到修复和验证。
可以说BUG跟踪是一个比较大的工程，和项目组工作氛围，开发人员任务量有很大关系，也是比较难的一个环节。
本次采用在线文档统计，没有bug提交系统，想要快速推进bug修改进度可采用以下方式：
群里沟通：总体监控bug状态，群里统一表达工作内容，50%开发人员能够即使对应；
单独推进：针对总体推进没有效果的bug，如待讨论问题、没有注释问题原因，单独私聊确定问题原因，对于暂时无法对应的问题确定好可对应时间；
PM 推进：通过PM进行推进，可以有效降低沟通成本，在任何环节都可。
Bug根因分析
有很多测试人员止步于此，回归完Bug就算测试完成。
建议花2个小时对问题原因进行分析，针对测试人员可以加深业务理解、理解功能开发逻辑。
Bug根因分析是在发现和解决Bug时进行的一种深入分析方法，旨在找出问题的根本原因，以便采取适当的措施来防止类似的问题再次发生。
Bug根因分析优点如下：
问题解决：根因分析帮助确定问题的真正原因，而不仅仅是修复表面症状。这有助于确保问题得到全面解决，而不是仅仅在特定情况下修复；
防止再次发生：通过找出问题的根本原因，可以采取措施来防止类似的问题再次出现，从而提高软件的稳定性和可靠性；
提高质量：根因分析有助于改进开发和测试过程，减少类似问题的发生。这有助于提高产品质量和用户满意度；
节省时间和资源：通过减少类似问题的发生，可以减少开发和测试人员处理Bug的时间，从而节省时间和资源；
优化流程：根因分析可能揭示了流程中的缺陷，可以通过改进流程来减少问题的发生；
增强团队合作：根因分析通常需要多个团队成员的合作，这有助于促进团队之间的合作和沟通；
提高技能：进行根因分析需要深入的技术和问题解决能力，团队成员可以通过这个过程提高自己的技能水平。
注意事项&总结
抓大放小
一般系统到这个阶段，切忌测试过程中过多关注细节，因小失大。
一直保持一根弦，我们的目标主流程数据的流程能够形成闭环，系统内部细节问题可不关注。
关注数据
从整个项目的全局性出发，数据的收集-流转-展示形成闭环，每一条业务流都可以按照这个思路进行测试，才是联调测试的最基本核心逻辑。
当然，许多基础数据的改变，随之在整个业务流的变化也是很重要测试点，本次有很多问题就是变更导致，也算是经验积累的一部分。
以上就测试开始前、执行测试到Bug跟踪结合自己的亲身经验做了一些总结，目的希望通过这种总结不断提升自己的测试经验，再有很多理论知识大家都知道，但是实际工作中的注意事项资料少之又少，算是为测试行业提供的一点价值。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
