目录
1.软件测试流程
软件测试在公司内的全部工作流程如下：
需求分析：测试人员需要与产品经理、开发人员等沟通，确保对软件的需求和功能有清晰的认识。在需求分析过程中，测试人员需要了解用户需求，明确软件的预期效果和目标，以便更好地制定测试计划和用例。
编写基础版需求文档：产品经理或产品经理助理负责编写基础版需求文档，为后续的测试工作提供依据。
需求文档评审：产品经理、开发经理、测试经理和客户共同评审需求文档，确保文档的准确性和完整性。
修改需求文档：根据评审结果，产品经理和客户共同完成需求文档的修改。
下发需求文档：修改后的需求文档下发给开发经理和测试经理，作为开发的指导和测试的依据。
开发版需求文档和测试版需求文档：开发经理出具开发版需求文档，测试经理出具测试版需求文档。
制定开发任务：开发人员根据开发版需求文档进行编码工作，并制定开发任务。
代码自测：开发人员完成编码后进行本地环境下的代码自测，确保代码质量。
合并代码至公司源码库：自测完成后，开发人员将代码合并至公司源码库。
打包部署：开发人员将源代码打包部署至开发和测试环境。
测试准备：测试人员根据测试版需求文档制定测试计划，设计测试用例，并准备测试环境。
冒烟测试（预测试）：搭建测试环境后，测试人员进行冒烟测试，确保软件的基本功能正常。
正式测试：冒烟测试通过后，开始进行正式的测试工作，包括单元测试、集成测试、系统测试、验收测试等。
回归测试：在修复Bug后，进行回归测试以确保Bug已被修复且没有引入新的Bug。
测试评估与报告：测试完成后，测试人员评估软件的测试结果，并编写测试报告。测试报告应包括测试概述、测试环境、测试方法、测试结果、问题跟踪等内容。
版本发布：根据测试报告的结果，如果软件质量符合要求，则可以发布软件版本。
以上是软件测试在公司内的全部工作流程。在实际工作中，每个公司可能会有自己的工作流程和规范，但大体上都会遵循以上步骤。
2.测试报告内容
测试报告是测试过程中的重要输出文档，用于记录测试的执行情况、测试结果以及测试结论等。一个完整的测试报告通常包含以下内容：
引言：包括编写目的、背景、用户群、测试阶段、测试工具等。
测试环境：包括测试的硬件环境、软件环境、网络环境等。
测试方法：描述测试的方法和技术，包括黑盒测试、白盒测试、灰盒测试等。
测试范围：明确测试的范围和重点，包括功能测试、性能测试、安全测试等。
测试数据：提供测试过程中使用的数据和样本，包括输入数据、输出数据、预期结果等。
测试执行情况：详细记录测试的执行过程，包括测试用例的执行情况、缺陷跟踪记录等。
缺陷分析：对发现的问题和缺陷进行分析，包括缺陷类型、严重程度、影响范围等。
测试结论：根据测试结果和缺陷分析，得出测试结论，包括是否通过测试、是否需要进一步测试等。
建议和改进措施：针对测试过程中发现的问题，提出改进措施和建议，以便于产品的进一步优化和改进。
除了以上内容，一个完整的测试报告还应当包含附录、索引等辅助信息，以便于读者更好地理解和使用报告。同时，在编写测试报告时，需要注意语言准确、条理清晰、内容完整，以便于报告的可读性和可用性。
3.如何保证测试用例的覆盖率
要保证测试用例的覆盖率，可以从以下几个方面进行考虑：
全面分析需求：在编写测试用例之前，需要对需求进行全面分析，确保理解了所有功能点和业务逻辑。可以采用会议讨论、原型评审等方式，让相关人员参与到需求分析中，以降低理解偏差。
制定测试计划：在测试计划中，需要明确测试的范围、目标、资源、时间安排等，以确保测试工作有序进行。同时，测试计划中还需要包含测试用例的编写、评审、执行等环节，以确保测试用例的覆盖率。
设计有效的测试用例：在设计测试用例时，需要采用合适的测试方法和技术，例如等价类、边界值、场景法等，以确保测试用例能够覆盖各种情况。同时，需要结合业务逻辑和功能点，设计有针对性的测试用例，以提高覆盖率。
评审和修正测试用例：在完成初步的测试用例设计后，需要进行评审和修正，以确保测试用例的准确性和完整性。可以采用同行评审、专家评审等方式，对测试用例进行审查和改进。
执行测试和缺陷跟踪：在执行测试过程中，需要及时发现和记录问题，并根据实际情况调整测试用例。同时，需要对缺陷进行跟踪和验证，以确保问题得到解决。
不断迭代和优化测试用例：在测试过程中，随着业务需求的变化和缺陷的修复，需要不断迭代和优化测试用例。可以定期对测试用例进行审查和更新，以确保测试用例始终能够反映当前业务需求和系统状态。
总之，要保证测试用例的覆盖率，需要从需求分析、测试计划、设计用例、评审修正、执行测试、缺陷跟踪和迭代优化等方面进行全面考虑和实施。同时，需要注重团队协作和沟通，以确保测试工作的质量和效率。
4.什么是测试用例，什么是测试脚本，两者的关系
测试用例和测试脚本都是软件测试中的概念，但它们是两个不同的概念，具有不同的用途和特点。
测试用例（Test Case）是为了测试某个功能或特性而编写的输入、操作步骤、预期结果和实际结果等信息的集合。测试用例是软件测试的基础，它提供了一种结构化的、规范化的方法来进行软件测试。测试用例通常用于覆盖软件的各种可能情况，包括正常情况和异常情况，以确保软件的质量和稳定性。测试用例通常包括以下内容：
测试编号：唯一标识一个测试用例的编号。
测试标题：简短描述测试用例的测试目标和功能。
输入：提供测试所需要的数据，如用户输入、系统数据等。
操作步骤：描述如何进行测试，包括具体的操作步骤和流程。
预期结果：描述在正常情况下的期望结果，用于判断软件是否符合要求。
实际结果：记录实际测试的结果，用于与预期结果进行比较。
测试脚本（Test Script）则是一种程序代码，用于自动化执行测试用例。测试脚本通常用于模拟用户操作和验证软件的各种功能和性能。测试脚本可以是手动编写的脚本，也可以是自动化的脚本，如Python、JavaScript等脚本语言编写的脚本。测试脚本通常包括以下内容：
脚本编号：唯一标识一个测试脚本的编号。
脚本描述：简短描述测试脚本的功能和用途。
输入：提供测试所需要的数据，如用户输入、系统数据等。
操作步骤：描述如何进行自动化测试，包括具体的操作步骤和流程。
验证点：描述如何验证软件的各项功能和性能是否正常工作。
脚本代码：实现自动化测试的程序代码。
总的来说，测试用例是软件测试的规范和文档，而测试脚本则是实现自动化测试的工具和手段。测试用例提供了详细的测试要求和步骤，而测试脚本则实现了自动化执行这些要求和步骤，提高了测试效率和准确性。在实际的软件测试中，通常需要编写相应的测试脚本以实现自动化测试，同时还需要编写完善的测试用例来指导整个测试过程。
5.bug的级别，按照什么划分
Bug级别通常按照严重程度来划分，常见的Bug级别有：
Blocker（崩溃）：阻碍开发或测试工作的问题；造成系统崩溃、死机、非法退出、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
Major（一般）：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
Normal（普通）：数值计算错误、JavaScript错误等。
Minor（次要）：界面、菜单布局错误或不合理、焦点控制不合理、性能缺陷，光标,滚动条定位错误等。
Trivial（轻微）：辅助说明描述不清楚、显示格式不规范，数字，日期等格式等。
除了按严重程度划分外，Bug级别还可以按照影响范围、是否为缺陷、是否为性能问题等方式来划分。在实际开发过程中，根据项目需求和实际情况来划分Bug级别，有助于更好地管理和解决Bug，提高软件的质量和稳定性。
6.你认为是bug，但是开发认为不是bug，该怎么办
当测试人员认为存在Bug，但开发人员认为这不是Bug时，可以采取以下步骤来解决争议：
详细描述问题：确保测试人员提供了详细的Bug描述，包括问题表现、重现步骤、预期结果和实际结果等信息。这将有助于开发人员更好地理解问题的本质和影响范围。
确认Bug定义和判断标准：开发人员和测试人员应该共同明确Bug的定义和判断标准，确保双方对Bug的理解是一致的。这可以避免因对Bug定义和判断标准的不同而产生争议。
提供证据和截图：测试人员可以提供截图、日志、性能数据等相关证据，以支持Bug的判断。这将帮助开发人员更好地理解问题并做出判断。
寻求第三方意见：如果开发人员和测试人员无法达成共识，可以考虑寻求第三方意见，例如项目经理、产品经理或其他技术专家。他们可以从不同的角度来评估问题，并给出更客观的意见。
协商解决：在争议解决过程中，测试人员和开发人员应该保持沟通，尊重对方的意见，并寻求双方都能接受的解决方案。如果开发人员认为这不是Bug，但测试人员认为这是Bug，可以考虑在开发人员同意的情况下，将问题记录为建议或优化项，以便后续进一步评估和改进。
最重要的是，双方应该保持开放和合作的态度，共同为提高软件质量而努力。
8.你印象中最深刻的bug
测试过程中印象深刻的Bug包括但不限于：
界面显示问题：例如字体颜色、大小、对齐方式等不一致，导致用户使用时感到困惑。
逻辑错误：涉及到业务逻辑的问题，如数据计算错误、业务流程中断等，这些问题可能会对用户造成较大的困扰。
性能问题：如页面加载缓慢、系统崩溃等，这些问题会影响用户体验和系统稳定性。
安全漏洞：如未授权访问、数据泄露等，这些问题可能对用户数据和企业信息安全造成威胁。
兼容性问题：如在不同浏览器、不同操作系统下的显示和功能问题，这些问题可能导致用户无法正常使用软件或网站。
除了以上Bug，还有一些其他问题也可能给测试人员留下深刻印象，如测试过程中的意外情况、复杂问题的解决方案等。无论遇到什么问题，测试人员需要认真记录、分析和跟踪，以确保软件的质量和稳定性。
银行卡校验，一般我们认为的银行卡19位左右，但是有位合作客户的银行卡号是11位的，这个确实比较少见，校验得重新判断
9.如果没有需求文档怎么办
在测试过程中，如果没有需求文档，可以采用以下几种方法来处理：
参加内部讨论会议：尽可能多地参加内部讨论会议，进一步理解项目的需求和业务逻辑。通过与开发人员、产品经理等交流，了解项目的核心功能和目标，以及一些细节要求。
参考同行或竞争对手的类似产品：可以参考同行或竞争对手的类似产品，从中理解项目的需求和业务逻辑。通过对比分析，可以更好地理解产品的功能点、用户体验等方面的要求。
梳理需求点：根据测试过程中对项目的了解，梳理出需求点。可以整理出一些关键的场景和业务流程，并基于这些场景和业务流程设计测试用例。
制定测试计划和测试用例：根据梳理出的需求点和关键场景，制定相应的测试计划和测试用例。在制定测试用例时，可以采用等价类、边界值等测试方法和技术，以确保测试的覆盖率。
评审和修正测试用例：在完成初步的测试用例设计后，需要进行评审和修正。可以邀请同行或专家进行评审，以确保测试用例的准确性和完整性。同时，在执行测试过程中，需要根据实际情况调整测试用例。
交叉模块测试：对于一些复杂的模块，可以采用交叉模块测试的方法，即让不同的测试人员分别负责不同的模块，然后进行集成测试。这种方法可以更好地模拟实际使用场景，提高测试的质量和效率。
咨询客户部分需求疑问：如果有必要，可以与客户进行沟通，咨询部分需求疑问。通过与客户的交流，可以更好地理解项目的需求和用户反馈，进一步提高测试的针对性和有效性。
总之，在测试过程中，如果没有需求文档，可以采用多种方法来处理。最重要的是通过不断沟通和梳理，理解项目的需求和业务逻辑，并采用合适的测试方法和技术来确保软件的质量和稳定性。
10.Android兼容性测试选取手机的准则
Android兼容性测试选取手机的准则主要包括以下几个方面：
分辨率和屏幕尺寸：不同的手机屏幕分辨率和尺寸各不相同，需要考虑测试覆盖各种分辨率和尺寸的手机屏幕。
处理器和芯片组：不同的手机搭载的处理器和芯片组不同，性能也会有所差异。需要考虑测试覆盖各种处理器和芯片组的手机。
操作系统版本：Android操作系统的版本多样，需要考虑测试覆盖各种主流版本，包括旧版本和最新版本。
品牌和型号：不同品牌的手机在硬件配置、软件优化等方面存在差异，需要考虑测试覆盖不同品牌的手机。
内存和存储空间：手机的内存和存储空间会影响软件的运行速度和存储能力，需要考虑测试覆盖各种内存和存储空间的手机。
网络环境：不同的网络环境会对软件的联网功能产生影响，需要考虑测试覆盖各种网络环境，包括Wi-Fi、4G/5G等。
用户反馈：根据用户反馈的问题，选取相应的手机进行兼容性测试，以解决用户遇到的问题。
综上所述，Android兼容性测试选取手机的准则包括分辨率和屏幕尺寸、处理器和芯片组、操作系统版本、品牌和型号、内存和存储空间、网络环境和用户反馈等方面。
788
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
