1. 软件测试
在一般的项目中，一开始均为手动测试，由于自动化测试前期投入较大，一般要软件项目达到一定的规模，更新频次和质量均有一定要求时才会上自动化测试或软件测试。
1.1. 项目中每个成员的测试职责
软件测试从来不是某一个职业，某一个环节，某一个人应该做的，应该是整个项目团队都要参与的，只是每个人承担的责任付出的时间精力的多少决定的。一个项目中的每个岗位，每个成员都应该有自己的需要测试的内容，重点和方向。
那么也就包括，项目经理、需求人员、设计人员、软件架构师、开发人员(分为各个层面和方向的开发人员)、数据人员、测试人员以及运维人员，在整个项目中每个岗位职责的不同，就要将其工作一定程度的体现在软件上，通过各个人员不同角度的测试实现对软件全方面，尽可能多的测试，不应该是寄希望于某一个人或某一个环节上。因为如果寄希望于一个人则会导致：
整个项目的所有内容，测试环节的负责人均要知悉，这种可能只能是专业团队下的理想情况，但是随着软件开发模型的不同，这种理想情况的可能性是非常小的。
· 软件因为一些主观、客观的因素总会发生修改，而这些修改在软件过程中很难详细的记录下来。
· 整个软件项目的背景、技术瓶颈、设计或架构人员的设计习惯、实现方法等均有一定程度的差异，在项目的开发完成过程中发生了一定程度的化学反应。寄希望于一个人完全的了解是不太可能的。
在前一条的基础上，则不可避免的导致测试覆盖面小，不完善，甚至理解错误，得出错误的结论。
如果要解决前一条，则避不可免的需要询问相关的人员，则会产生不可见的隐形开销。
工作量剧增，在规定的工作时间内全面的``保质保量的完成，在用人成本和人员素质上是不切实际的。
所以需要在项目中的每个岗位基于自己所处项目的职责，去关注每个角度所体现在软件上的模块和功能，需要根据岗位去决定测试覆盖的广度和深度。
| 序号 | 责任岗位 | 深度和广度 | 测试任务描述 |
| 1 | 项目经理 | 注重广度可以适当忽略深度 | 确认软件的项目边界内容是否实现、基于项目经理的角度分析软件的弹性是否能够支撑后续各类变化，如：数据的变化（包括频次、数据格式等等）、业务的变化、与其他项目的关联方式 |
| 2 | 需求设计人员 | 注重广度，一定程度需要关注深度 | 确认软件的实现是否实现了需求设计、需要从整体的角度去关注业务在系统的体现是否是一个相较完整的闭环 |
| 3 | 软件架构师 | 关注广度也需要关注深度 | 1. 协助测试人员设计测试友好的测试框架 2. 从安全性、可用性和可伸缩性的方向制作测试用例 3. 确认每类数据流转在架构中是否存在问题，包括并发并行等情况、适当考虑软件运行效率 |
| 4 | 开发人员 | 关注深度也需要关注广度 | 1. 完成自我的功能后是否编写一定的测试代码进行了测试 2. 对自己实现的代码成果一方面需要完成设计的内容，另一方面要考虑和测试软件在实际运行中的可能，在不同的输入中，最终是否都能够得到正确的结果 3. 需要对功能完成所选择的实现方式对不同数据量数据内容进行考虑甚至是测试 4. 需要考虑和其他模块之间的关系，是否只是单纯的完成而没有交互 |
| 5 | 测试人员 | 关注广度 | 基于上述各类人员在项目中的完成和成果，制作不同的数据、不同的测试样例对软件进行系统化的整体测试 |
1.1.1 举例说明
1. 开发人员需要使用不同数据进行测试？
数据是软件的生命，不同的数据由于算法的实现可能得出的结果可能不是完全正确的，如下案例：
地理信息中矢量图形的表达有点、多点、线、多线、面、多面。其在OGC标准WKT或GeoJson的表达上均有一定的表达，算法实现中（比如读取显示）是否兼顾了各类数据格式；面状数据存在天井图斑（内外环）的图斑，是否存在问题
在数据为王的软件中，比如采集软件、数据质检软件、数据库管理软件中需要对不同的数据依据数据特性进行测试（当然也要结合实际情况进行测试，比如软件面向的是全国则需要测试全国的情况，如果软件面对的这个地方没有则可以适当的测试延后甚至可以考虑不做测试），比如：
·三调质检软件中存在一个规则，相邻图斑属性不相同(此用例结合下一个举例再次说明)，软件算法是否考虑节点图斑、天井图斑等等数据的不同得到结果不一样。
· 全国不同的坡度数据采集方式不一样，有的是小图斑、有的是等级图斑（全区域只有10条）则会导致一个图斑的内存大小非常的大，是否会出现内存溢出的情况。
· 数据读取时不同的数据存放是否标准，如在房屋安全数据中，默认约定是数据全量提供，但是由于一些情况，可能只提供警告数据的，在算法实现中，是否能够兼容不同的数据体量得到一直的结果。
2. 开发人员需要对不同体量的数据进行考虑甚至是测试？
结合相邻图斑属性不相同的案例，数据的节点个数大小不同，在算法中是否会出现内存放大的问题，相邻图斑的层数量多，算法实现方式结合时间复杂度和空间复杂度是否会出现时间长度内无法得到结果
数据入库的方式，是否存在数据条数较多时会出现效率慢的情况(会导致在项目在比较紧张的情况下应对效果较差)
3. 开发人员和需求人员的系统化和结构化思维
软件要想一步就位是可遇不可求的理想状态，基本上是不可能的，总会有需求变更和产品迭代，每次变更都要考虑变更对整体的系统性的影响。
1.2. 如何开始一个软件的测试
开始进行软件测试是一个重要的步骤，它有助于确保您的软件在交付给用户之前具备良好的质量和稳定性。以下是一些步骤，可以帮助您开始一个软件项目的测试过程：
1. 理解项目需求：
首先，深入理解软件项目的需求，包括功能需求、性能需求、安全性需求等。这将有助于确定需要测试哪些方面。
2. 制定测试计划：
制定详细的测试计划，包括测试范围、测试目标、测试策略、测试资源、时间表和风险评估。测试计划是测试活动的路线图，有助于确保测试进程有条不紊。
3. 确定测试环境：
确定测试所需的硬件、软件和网络环境。测试环境应该与生产环境相似，以确保测试结果的准确性。
4. 选择测试方法和技术：
根据项目需求和测试目标，选择适当的测试方法和技术。常见的测试方法包括功能测试、性能测试、安全测试等。
5. 创建测试用例：
基于需求和设计文档，编写详细的测试用例，包括输入数据、预期结果和执行步骤。测试用例是用于执行测试的指南。
6. 设置测试环境：
配置测试环境，包括安装和设置必要的测试工具和测试数据。确保测试环境准备就绪。
7. 执行测试：
根据测试计划和测试用例，执行测试。记录测试结果、问题和缺陷，并跟踪测试进度。
8. 自动化测试（如果适用）：
对于重复性高的测试用例，考虑自动化测试。编写自动化测试脚本并集成到测试流程中，以提高效率。
9. 问题管理：
使用问题跟踪工具（如JIRA、Bugzilla等）来记录和管理测试中发现的问题和缺陷。确保问题被及时修复和验证。
10. 性能测试和安全测试（如果适用）：
如果项目需要，执行性能测试和安全性测试，以确保软件在负载和安全方面表现良好。
11. 测试报告：
生成详细的测试报告，包括测试结果、问题汇报、测试覆盖率等信息。测试报告应该清晰、易于理解，以便团队做出决策。
1.2.1. 测试用例
1. 公用测试用例
2. 软件性能测试用例
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
