Q1：对软件测试人员来说，技术评审需要做什么
一、评审准备阶段
-
熟悉相关文档和材料
- 仔细阅读需求规格说明书，明确软件系统的功能需求、性能需求、用户界面要求等。例如，如果是一个电商软件，要清楚商品展示、购物车功能、支付流程等各功能模块的详细需求。
- 了解软件的设计文档，包括总体架构设计、数据库设计、接口设计等。这样可以对软件的内部结构和数据流向有清晰的认识，为后续发现潜在问题提供基础。
- 对于有变更的部分，重点关注变更请求文档，理解变更的原因、范围和影响。比如，当电商软件增加了新的促销活动功能时，要关注该功能对原有购物流程和数据存储的影响。
-
收集和整理测试相关信息
- 汇总之前类似项目或模块的测试问题，分析其可能在本次评审的软件中出现的风险点。例如，以往项目中曾出现过数据库连接超时的问题，在本次评审时就要关注数据库相关设计是否进行了优化。
- 准备好测试计划和测试策略相关的初步思路，以便在评审过程中讨论其可行性。比如，针对新的软件功能，初步规划采用黑盒测试结合部分白盒测试的策略，在评审中与开发人员等沟通是否合适。
-
确定评审范围和重点关注问题
-
根据软件的特性和项目要求，确定需要重点评审的功能模块。例如，对于金融软件，重点可能是交易处理模块、安全认证模块等。
-
识别可能存在高风险的技术点，如复杂的算法实现、多系统集成的接口等。以一个物流管理软件为例，其与外部地图服务接口的准确性和稳定性就是重点关注的高风险技术点。
-
二、评审会议阶段
-
功能需求评审
- 检查软件功能是否完整地覆盖了需求规格说明书中的要求。例如，在评审一个办公自动化软件时，检查文档编辑、文件共享、审批流程等功能是否与需求一致。
- 对功能的正确性进行评估，提出可能导致功能错误的潜在问题。比如，在一个图像处理软件中，检查滤镜效果是否正确应用，图像裁剪是否符合预期的尺寸和比例。
- 关注功能的可操作性和用户体验。测试人员要站在用户的角度，考虑软件操作是否便捷、界面是否友好。例如，软件的菜单选项是否易于理解，操作流程是否符合用户习惯。
-
技术设计评审
- 对软件的架构设计进行评估，检查架构是否具有可扩展性、灵活性和可靠性。例如，对于一个大型企业级应用，其架构应该能够方便地添加新的业务模块，并且在高负载情况下保持稳定运行。
- 审查数据库设计，包括数据表结构、数据完整性约束、数据存储和查询性能等。以一个客户关系管理软件为例，要检查客户信息表的字段设计是否合理，数据查询是否能够快速响应。
- 检查接口设计，确保接口的参数定义准确、调用方式正确，并且能够满足不同系统之间的交互需求。例如，在一个软件系统集成项目中，检查支付接口与银行系统接口的数据传输格式和协议是否兼容。
-
代码规范和质量评审
- 检查代码是否遵循既定的编码规范，包括代码格式、命名规则、注释等。例如，代码中的变量命名应该具有清晰的含义，函数应该有适当的注释说明其功能。
- 关注代码的可读性和可维护性，提出改进建议。比如，复杂的逻辑代码是否进行了合理的拆分和封装，以便后续维护人员能够容易地理解和修改。
- 协助开发人员识别可能的代码缺陷，如潜在的内存泄漏、空指针引用等。在一些性能敏感的软件中，还要检查代码是否存在性能瓶颈，如循环嵌套过多、频繁的数据库查询等。
-
风险评估和问题记录
-
识别软件在技术实现过程中可能存在的风险，如技术选型的适用性、新技术的引入可能带来的不确定性等。例如，采用一种新的加密算法可能存在与现有系统兼容性的风险。
-
对评审过程中发现的问题进行详细记录，包括问题的位置（如具体的功能模块、代码行）、问题的描述、问题的严重程度等。例如，记录一个功能模块中存在计算结果错误的问题，详细描述错误的计算场景和预期结果。
-
三、评审后续阶段
-
跟踪问题解决情况
- 根据记录的问题清单，与开发人员一起确定问题的优先级和解决计划。例如，严重影响软件核心功能的问题应该优先解决，而一些界面显示的小瑕疵可以安排在后续阶段处理。
- 定期检查问题的解决进度，确保问题得到及时有效的处理。可以通过项目管理工具或者定期的沟通会议来跟踪进度。
- 对问题解决后的部分进行重新评审或者回归测试，验证问题是否真正得到解决并且没有引入新的问题。例如，对于修复后的功能模块，重新运行相关的测试用例，检查功能是否恢复正常。
-
总结和反馈
- 对整个技术评审过程进行总结，包括评审的范围、发现的主要问题、问题的解决情况等。将总结报告提供给项目团队成员，让大家了解评审的结果。
- 向项目团队反馈技术评审中的经验教训，为后续的软件开发和评审工作提供参考。例如，如果在本次评审中发现代码规范执行不严格的问题，建议加强代码规范的培训和检查。
Q2：怎样提高软件测试人员的技术评审能力？
一、知识学习与积累
-
深入学习软件开发生命周期
- 理解从需求分析、设计、编码、测试到维护的各个阶段的工作内容和目标。例如，学习软件需求工程，了解如何准确地获取、定义和管理软件需求，这样在评审需求文档时，能够更好地判断需求的完整性和合理性。
- 熟悉不同开发模型（如瀑布模型、敏捷开发模型等）下技术评审的重点和流程。在敏捷开发中，技术评审可能更加频繁和灵活，需要快速评估用户故事的可实现性和软件增量的质量。
-
掌握软件设计和开发技术
- 学习软件架构知识，包括常见的架构模式（如 MVC、微服务架构等）。了解这些架构的优缺点，在评审架构设计时，能够评估其是否适合项目的需求和规模。例如，对于一个小型的 Web 应用，MVC 架构可能比较合适，而大型的分布式系统可能更适合微服务架构。
- 熟悉编程语言和代码规范。学习至少一种编程语言（如 Java、Python 等），掌握基本的语法、数据结构和编程范式。同时，要熟悉代码风格指南（如 Google 的 Java 代码风格指南），这样在评审代码时可以检查代码是否符合规范。
- 了解数据库设计和管理知识，包括关系数据库（如 MySQL）和非关系数据库（如 MongoDB）的设计原则。在评审数据库设计时，可以检查数据表的关系是否正确、索引是否合理等。
-
提升测试专业知识
-
深入研究各种测试方法和技术，如黑盒测试、白盒测试、自动化测试等。例如，在黑盒测试中，熟练掌握等价类划分、边界值分析等方法，在评审功能需求时，可以用这些方法来发现潜在的功能缺陷。
-
学习测试工具的使用，如测试管理工具（JIRA）、自动化测试工具（Selenium）等。在评审过程中，可以建议使用合适的工具来提高测试效率和质量。
-
了解软件质量标准和模型，如 ISO 9001、CMMI 等。这些标准可以为技术评审提供参考，帮助测试人员判断软件是否符合一定的质量要求。
-
二、实践经验积累
-
积极参与技术评审项目
- 主动要求参与公司内部的各种软件项目的技术评审，从简单的小型项目开始，逐步积累经验。在参与过程中，观察和学习其他资深人员的评审方法和技巧。例如，注意他们是如何提问、如何发现深层次的技术问题的。
- 参与不同类型的软件项目评审，如桌面应用、Web 应用、移动应用等。不同类型的软件有不同的特点和技术要求，通过参与多种项目，可以拓宽视野，提高综合评审能力。
-
模拟评审和案例分析
-
组织内部的模拟评审活动，选取一些有代表性的软件文档或代码片段进行评审。在模拟评审后，进行小组讨论，分享各自的发现和观点，互相学习。例如，可以选择一个开源软件的部分代码进行模拟评审，分析代码的质量和可能存在的问题。
-
收集软件项目中的失败案例和缺陷案例，进行深入分析。了解这些问题是如何在技术评审中被遗漏的，以及如何在今后的评审中避免类似情况。例如，分析一个因数据库并发访问控制不当导致的数据不一致的案例，总结在评审数据库设计和代码时应该关注的要点。
-
三、沟通协作能力提升
-
与开发团队建立良好关系
- 加强与开发人员的日常沟通，了解他们的工作思路和技术难点。这样在技术评审时，可以更好地理解他们的设计和实现，提出更有建设性的意见。例如，定期参加开发团队的技术分享会，增进彼此的了解。
- 以合作的心态参与评审，避免与开发人员产生对抗情绪。强调评审的目的是提高软件质量，而不是指责开发人员的工作。例如，在提出问题时，采用温和、客观的语气，重点放在问题本身和解决方案上。
-
跨部门协作沟通
-
如果软件项目涉及多个部门（如业务部门、运维部门等），积极与这些部门沟通。了解业务部门的需求和期望，以及运维部门对软件部署和维护的要求。在技术评审时，可以综合考虑这些因素。例如，与业务部门沟通后，在评审功能需求时，可以更好地判断功能是否符合实际业务场景。
-
参加跨部门会议，提高在不同利益相关者面前表达自己观点的能力。学会用通俗易懂的语言解释技术问题，使非技术人员也能理解评审的重要性和发现的问题。
-
四、持续自我反思与改进
-
记录和总结评审过程
- 每次技术评审后，详细记录评审的内容、发现的问题、提出的建议以及问题的解决情况。通过对这些记录的总结和分析，可以发现自己在评审过程中的优点和不足。例如，发现自己在评审架构设计时经常忽略可扩展性方面的问题，就可以有针对性地学习和改进。
- 定期回顾自己的评审记录，与其他测试人员的评审记录进行对比，学习他人的长处。可以通过内部的知识分享会或者在线文档共享的方式，互相学习评审经验。
-
寻求反馈和改进建议
- 主动向其他参与评审的人员（如资深测试人员、开发人员、项目经理等）寻求反馈。询问他们对自己评审表现的看法，包括评审的深度、准确性、沟通能力等方面。例如，向项目经理询问自己在评审会议中的贡献是否足够，是否有效地推动了问题的解决。
- 根据反馈意见，制定个人的改进计划。例如，如果反馈意见是自己在评审代码时对某些复杂算法的理解不够深入，导致无法发现潜在问题，就可以安排时间学习相关的算法知识，并通过实际案例来加深理解。
Q3：分享一些软件测试人员在技术评审中遇到的常见问题及解决方法
一、需求相关问题
（一）问题
-
需求不明确
- 需求文档中存在模糊的表述，例如 “系统应该具有良好的用户体验”，但没有具体说明怎样才算良好的用户体验。
- 功能边界不清楚，比如对于一个文件管理系统，没有明确说明文件格式支持的范围，导致测试人员无法确定测试的边界。
-
需求变更频繁
-
在评审过程中，业务部门不断提出新的需求或者修改已有的需求，使得评审工作难以聚焦，并且增加了测试的工作量和不确定性。
-
（二）解决方法
-
需求不明确
- 要求产品经理或相关负责人对模糊的需求进行澄清。例如，可以在评审会议上提出，对于 “良好的用户体验” 这一需求，具体可从界面操作的便捷性、响应时间、错误提示的友好性等方面进行详细说明。
- 针对功能边界问题，与开发人员和业务人员一起梳理边界情况。对于文件管理系统的文件格式支持范围，可以通过列出系统需要支持的常见文件格式列表（如.docx、.pdf 等）来明确。
-
需求变更频繁
-
建立有效的需求变更管理流程。当业务部门提出需求变更时，要求他们填写需求变更申请表，说明变更的原因、内容和影响范围。
-
在评审会议上，与所有相关人员（包括开发团队、业务团队等）一起评估需求变更对项目进度、成本和质量的影响。如果变更影响较大，需要重新规划测试计划和时间表。
-
二、设计相关问题
（一）问题
-
架构设计不合理
- 架构缺乏可扩展性，例如在设计一个电商系统时，没有考虑到未来可能增加新的促销活动类型或支付方式，导致后续功能扩展困难。
- 架构的性能存在隐患，如多层架构之间的数据传输过于复杂，可能导致响应时间过长。
-
数据库设计缺陷
-
数据表结构设计不佳，例如存在过多的冗余字段，增加了数据存储成本和数据不一致的风险。
-
数据库索引设计不合理，导致查询效率低下。比如在一个订单管理系统中，没有对订单日期字段建立索引，当按日期查询订单时速度很慢。
-
（二）解决方法
-
架构设计不合理
- 对于可扩展性问题，建议采用插件式或模块化的架构设计。在电商系统中，可以将促销活动模块和支付模块设计成独立的插件，方便后续添加新的功能。
- 针对性能隐患，与架构师一起重新审视架构设计，优化数据传输路径。可以通过引入缓存机制（如 Redis 缓存）来减少数据传输和提高响应速度。
-
数据库设计缺陷
-
对于数据表结构冗余问题，与数据库设计师协商，对数据表进行规范化处理。例如，通过建立关联表来消除冗余字段，确保数据的一致性。
-
对于索引设计不合理的情况，使用数据库性能分析工具（如 MySQL 的 Explain 命令）来确定需要优化的查询语句和索引。根据分析结果，添加或调整索引来提高查询效率。
-
三、代码相关问题
（一）问题
-
代码不符合规范
- 代码的命名不规范，变量和函数名难以理解其含义，例如使用单个字母作为变量名（如 int a;）而没有任何注释说明。
- 代码格式混乱，缩进不一致，增加了代码的阅读难度。
-
潜在代码缺陷
-
存在空指针引用的风险，例如在没有对对象进行非空判断的情况下直接调用对象的方法。
-
资源未正确释放，如打开的文件、数据库连接等没有及时关闭，可能导致资源泄漏。
-
（二）解决方法
-
代码不符合规范
- 参考公司或项目的代码风格指南，要求开发人员修改代码。在评审会议上，可以展示一些规范的代码示例，让开发人员清楚了解正确的命名和格式要求。
- 引入代码格式化工具（如 Prettier 对于 JavaScript 代码），自动对代码进行格式化，提高代码的可读性。
-
潜在代码缺陷
-
对于空指针引用问题，建议开发人员在代码中添加必要的非空判断。可以通过代码审查工具（如 FindBugs）来自动发现这类潜在问题。
-
针对资源未正确释放的情况，要求开发人员在合适的代码位置添加资源释放的代码。同时，使用性能测试工具（如 JProfiler）来监控资源的使用情况，及时发现资源泄漏问题。
-
四、沟通协作相关问题
（一）问题
-
与开发人员产生冲突
- 在评审过程中，测试人员提出的问题可能被开发人员认为是过于挑剔或者不合理，导致双方产生冲突，影响评审的顺利进行。
- 双方对于问题的严重程度和优先级判断不一致，例如测试人员认为某个功能缺陷很严重，而开发人员认为这是一个小问题，可以在后续阶段解决。
-
跨部门沟通不畅
-
与业务部门沟通时，测试人员可能无法准确理解业务需求，或者业务部门无法理解测试人员提出的技术问题和风险。
-
（二）解决方法
-
与开发人员产生冲突
- 强调评审的目的是为了提高软件质量，而不是指责开发人员。在提出问题时，采用客观、具体的表述方式。例如，说 “这个代码片段可能会导致空指针异常，因为没有进行非空判断，我们可以考虑添加一个判断来避免这个问题”，而不是直接批评开发人员的代码质量。
- 对于问题的严重程度和优先级，建立统一的评估标准。可以参考缺陷管理工具（如 JIRA）中的缺陷等级划分标准，在评审会议上，根据这个标准来共同确定问题的严重程度和优先级。
-
跨部门沟通不畅
- 测试人员要主动学习业务知识，了解业务流程和需求。可以参加业务部门组织的培训或者阅读相关的业务文档。
- 在沟通技术问题时，尽量使用通俗易懂的语言。例如，将复杂的软件架构问题类比为建筑结构，用简单的例子来解释给业务部门听，帮助他们理解技术风险。
