软件测试人员发现更多程序bug

软件测试人员发现更多程序bug

1. 理解需求和业务，需求评审时候发现bug

熟悉了产品的业务流程、才能迅速找出软件中存在的一些重要的缺陷，发现的软件缺陷才是有价值的。否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。阅读需求文档的时候，在需求评审阶段，识别和处理潜在的bug。常见的问题包括：
需求不明确或模糊：
需求文档中的描述不够清晰，导致理解上的歧义。需求缺少必要的细节，使得开发无法准确实现功能。
用户体验问题：
需求没有考虑到用户的易用性，可能导致用户体验不佳。需求与业务目标或用户期望不一致。需求的交互设计不符合用户习惯，需要调整。
安全性问题：
数据泄露风险：需求没有考虑数据保护措施，可能导致用户数据泄露，数据库存放明文密码，导出用户信息。
权限控制不当：需求的权限控制不合理，可能导致未授权访问。
性能问题：
需求没有考虑性能优化，可能导致系统响应缓慢，用户、设备数量超过10万，授权和登录功能、同步到其他设备。导入和导出没有限制数量。
可维护性问题：
需求的实现方式不利于未来的扩展和维护，每一个功能需要有日志记录，限制单个日志空间占用大小，增加新组件注册。云平台系统需要支持磁盘扩容。
一旦发现这些问题，应立即记录并向测试经理反馈，团队成员共同分析bug的原因和影响，确定是否需要修改需求。及时提出问题，可以有效减少后期开发中的返工和修改成本。

2. 写测试用例多思考发现更多bug

测试用例的全面性和有效性，写出能够发现更多bug的测试用例。

理解需求和设计
详细阅读需求文档：理解软件的功能需求、业务逻辑和非功能需求（如性能、安全等）。输入内容限制格式长度，新增和修改功能没有限制名字不能重复。查询功能精确查询和模糊查询，多条件查询。
参与需求讨论：参与需求讨论，确保对需求的理解没有偏差。明确哪些功能是本次测试的重点，用户最常用的业务流程，确保这些路径被充分测试。
设计测试用例
正常流程：设计覆盖所有正常业务流程的测试用例。
异常流程：考虑各种可能的错误情况和异常输入，设计相应的测试用例。模拟真实的使用场景，包括用户可能遇到的意外情况。
边界条件：针对每个输入，设计边界值测试用例，包括最小值、最大值、刚超过最小值、刚低于最大值等。
等价类划分：将输入数据划分为有效和无效的等价类，从每个类中选取代表性的值进行测试。验证系统如何处理非法或无效的输入。
边界值分析：专注于输入域的边界，因为这些地方最容易出错。
安全性测试：考虑潜在的安全漏洞，设计测试用例来检查输入验证、权限控制、数据加密等方面，导入功能需要限制文本格式和大小。
性能测试：设计测试用例来评估系统在高负载下的表现。
查看历史bug：参考以前发现的bug，提供更多参考思路。

用例评审和优化
用例评审：让同事审查你的测试用例，他们可能会发现你遗漏的测试点。
持续改进：根据发现的bug和新的需求，参考维护的文档，不断更新和优化测试用例。

3. 测试时候发现bug

测试每一个功能都需要考虑：外观、功能、性能、安全、易用性和兼容性。每天花一点时间查看其他人提交的bug，拓展自己的测试思路，多问一下维护组的同事，重点测试用户反馈的一些问题。集中测试的时候要使用二八原则。
外观
布局问题：元素错位、间距不一致、格式不统一、对齐问题、翻页功能和浏览器滚动条等。颜色搭配不合理、字体不统一或不清晰、中英文切换查看显示字体。
图片和图标问题：图片格式不同加载失败、不同显示屏图标分辨率低或显示错误。

功能
预期的功能未实现或部分实现。功能实现与需求不符，导致操作结果错误。业务正向和逆向流程，不同入口使用业务流程，导致业务流程错误。
新增功能：名称重复、所有字段填写后保存后丢失或错误，页面内容显示错误，字母大小写没有校验，多次点击保存按钮保存了多次，关键信息没有tooltips。
修改功能：没有限制输入字符类型和长度、没有区分大小写字母、时间先后没有校验、修改操作完后记录结果错误，修改名称和已存在资源相同名称保存成功，修改操作日志记录错误，修改内容没有同步到已注册的其他组件。
删除功能：删除失败、删除自定义内容失败、删除前没有提示信息、批量删除失败、物理删除用户数据、删除操作日志记录错误，删除内容没有同步到已注册的其他组件。
查询功能：无查询功能、没有限制输入字符长度、查询结果不准确、内置数据无查询结果、100万条数据查询加载慢、不支持关键词查询。
导入功能：导入数据失败、没有限制输入字符类型和长度、导入数据后位置乱序、导出默认数据后再导入失败、没有限制导入文件格式、没有限制导入文件大小和数据量（建议excel单个sheet限制10000行）、导入提示信息错误、导入数据后没有记录到日志或记录错误。
接口功能：缺少接口、接口没有限制每个字段长度和字符类型、缺少字段、接口文档错误（符号不正确、错别字、缺少字段）、接口返回结果错误与接口文档描述不一致。
网络功能：ipv4（回环127.0.0.1、回环域名localhost）、ipv6(回环::1、回环域名localhost)、纯ipv6环境功能正常、纯域名环境功能正常、使用已经被占用的IP、网口聚合、dchp自动获取地址能正常访问、DNS解析失败、nat地址、各组件配置nat、配置多网卡多个ip地址（一个地址通、一个地址网络不通）、各组件配置多个IP、禁用组件网卡功能继续使用，提示信息准确、高可用配置主备、主备切换、浮动IP地址注册组件切换主备、多个IP地址日志外发使用的IP地址、设备网络带宽瓶颈

性能
响应时间慢：登录系统响应时间长，数据量达到100万条加载慢，影响用户体验。
资源消耗大：系统资源（如内存、CPU）使用率高，可能导致系统崩溃。系统在高并发情况下性能下降，无法满足用户需求。

安全
1.SQL注入：攻击者通过在输入框中输入恶意SQL代码，尝试获取或修改数据库中的数据。
2.重放攻击漏洞：攻击者截获合法用户的请求，然后将该请求重复发送给服务器。
3.XSS（跨站脚本攻击）：攻击者通过在网页中插入恶意脚本，当其他用户浏览该网页时，这些脚本会被执行，从而窃取用户信息或进行其他恶意操作。

4.文件上传漏洞：攻击者通过上传恶意文件，尝试执行远程代码或获取服务器权限，上传功能没有校验文件格式和内容。
5.弱密码策略：默认或过于简单的密码可能导致攻击者轻易破解账户。
6.未加密的数据传输：在数据传输过程中未进行加密处理，可能导致数据泄露或被篡改。
7.未经授权的访问控制：未对敏感资源进行严格的访问控制，可能导致攻击者越权访问。登录系统后台使用命令或者脚本越权。
8.缺乏安全更新和补丁：未及时修复已知的安全漏洞，可能导致攻击者利用这些漏洞进行攻击。使用中间件版本低存在漏洞，百度一下中间件的漏洞然后提bug。

易用性
导航困难：菜单结构复杂，用户难以找到所需功能。交互设计不符合用户习惯，需要调整，比如有的功能需要进入后台才能配置，页面需要有配置的选项。
帮助信息不足：缺少必要的帮助文档或提示信息，使用户难以理解如何使用软件，增加tooltips功能。
兼容性
跨浏览器问题：在不同浏览器上表现不一致，某些功能无法正常使用。
跨平台问题：在不同操作系统（国产操作系统）或设备上表现不一致，某些功能无法正常使用。

拓展思路：
参考其他人提交的bug，可以从不同的角度拓展思路，发现更多潜在的bug。也可以参考其他项目中的bug报告，了解常见的bug类型和解决方案；也可以借鉴其他测试人员的经验，学习他们的测试方法和技巧。
自由测试是一种非正式的测试方法，测试人员可以根据直觉和经验进行测试，不受预定义测试用例的限制。这种方法可以帮助发现一些容易被忽视的bug，但也可能因为缺乏系统性而导致漏测。在进行自由测试时，建议结合正式的测试用例一起使用，以获得更全面的测试覆盖。
根据二八原则（帕累托原则），80%的问题往往集中在20%的模块中。统计bug分布时，可以重点关注那些出现bug较多的模块。通过对这些模块的深入测试，可以发现更多bug，有效提高系统的整体质量。

4. 回归bug的时候发现更多bug

在回归测试时发现更多bug是一个常见且重要的现象。在修复一个bug时，可能会对其他功能模块产生连锁反应，导致新的bug出现。一个模块的修复可能会影响到另一个模块的正常使用。
测试覆盖不全面：在初次测试中，可能由于测试用例设计不充分或者测试时间和环境的限制，未能覆盖所有可能的场景。在回归测试中，通过更全面的测试用例，可能会发现之前未检测到的bug。
需求变更：在软件开发过程中，需求可能会发生变化。这些变更如果没有及时反映到测试用例中，可能会导致新的bug在回归测试中被发现。
环境变化：测试环境和生产环境可能存在差异。在回归测试中，如果使用了更接近生产环境的配置，可能会暴露出之前未发现的环境相关bug。
人为因素：开发人员在修复bug时可能会因为疏忽或误解需求而引入新的bug。
确保之前发现的bug已经修复，并且修复没有引入新的问题。多思考类似的功能有没有同样的问题。

5. 软件发布后，用户使用中的bug

软件发布后，用户在实际使用过程中遇到的各种问题，用户在使用过程中发现的bug是一个不可避免的现象。以下是一些常见的用户使用中发现的bug类型及其描述：
功能问题：某些预期的功能与用户期望不符。
性能问题：应用响应缓慢，加载时间长，在高并发情况下，系统崩溃或服务不可用。
兼容性问题：在不同操作系统、浏览器或设备上表现不一致。
安全性问题：数据泄露或未授权访问，系统容易受到SQL注入、XSS攻击等。
稳定性问题：长期使用，应用崩溃或频繁出错，内存泄漏导致系统资源耗尽。
国际化和本地化问题：多语言支持不完整或翻译错误，日期、货币格式未根据地区正确显示，系统初始化后语言正确。
用户体验问题：界面不友好，操作复杂，缺乏必要的帮助信息或提示。

采取以下措施：
问题分析和定位：对用户报告的问题进行详细分析，重现问题场景，定位问题根源。
记录和跟踪：将用户反馈的bug记录在案，并跟踪其处理状态。这有助于后续的问题管理和质量改进。
测试和验证：在问题修复后，进行充分的测试以确保问题已经解决，并且没有引入新的问题。
持续改进：通过分析用户反馈的bug，不断改进软件测试用例和方法，减少未来类似问题的发生。