说说软件开发-测试

[guanhui07]

测试的职责：

规划测试范围

识别软件的边界条件，包括最大最小值、最长最短输入等。如一个文本输入框，要测试其能够接受的最长字符数，以及输入超过这个限制时软件的反应

制定测试策略

确定采用何种测试方法，如黑盒测试、白盒测试、灰盒测试。黑盒测试主要关注软件的功能是否符合需求，不考虑内部实现细节。例如，通过输入各种商品购买数量，检查购物车总价计算是否正确。白盒测试则侧重于检查软件内部的逻辑结构，像检查代码中某个计算折扣的函数是否正确实现。灰盒测试介于两者之间，结合了部分功能测试和内部结构检查。
安排测试的阶段和顺序，例如先进行单元测试（对软件中最小可测试单元进行检查，如一个函数），然后是集成测试（将多个单元组合起来测试它们之间的接口是否正确），接着是系统测试（对整个软件系统进行测试），最后是验收测试（由用户或客户参与，确认软件是否满足业务需求）。

设计测试用例

根据软件需求文档，详细地设计测试用例。每个测试用例应包括测试场景、输入数据、预期结果等内容。以用户登录功能为例，一个测试用例可以是 “测试场景：用户使用正确的用户名和密码登录；输入数据：用户名‘testuser’，密码‘123456’；预期结果：成功登录，跳转到用户主界面”。
考虑各种可能的情况，包括正常情况和异常情况。除了正确的登录情况，还要设计如用户名或密码错误、输入为空、用户名包含特殊字符等异常情况的测试用例。
运用各种测试用例设计技术，如等价类划分（将输入域划分为若干个等价类，从每个等价类中选取代表性的数据进行测试）、边界值分析（重点测试边界值，因为边界值往往是容易出错的地方）、因果图法（分析输入条件和输出结果之间的因果关系来设计测试用例）等。

缺陷管理与跟踪

缺陷发现与记录：
在测试过程中，仔细观察软件的行为，发现软件的缺陷。这些缺陷可能包括功能缺陷（如某个按钮点击无反应）、性能缺陷（软件运行缓慢）、兼容性缺陷（在某些设备上界面显示异常）等。
使用专业的缺陷管理工具（如 JIRA、Bugzilla 等）记录发现的缺陷，详细描述缺陷的症状、重现步骤、严重程度（如致命、严重、一般、轻微）和优先级（如高、中、低）。例如，对于一个导致软件崩溃的致命缺陷，要详细记录重现崩溃的操作步骤，方便开发人员定位和修复。
缺陷跟踪与验证：
跟踪缺陷的处理进度，与开发人员保持沟通，了解缺陷的修复情况。确保开发人员对缺陷进行了正确的理解，并及时推动缺陷的修复。
当开发人员声称已经修复了缺陷后，进行回归测试，验证缺陷是否真正被修复，并且检查修复过程是否引入了新的问题。回归测试可能需要重新执行部分或全部相关的测试用例。

质量评估与报告

质量评估：
根据测试结果，对软件的质量进行评估。评估内容包括功能完整性、性能是否达标、稳定性、兼容性等方面。例如，通过性能测试工具测试软件的响应时间、资源占用情况等指标，判断软件是否满足性能要求。
与项目相关人员（如项目经理、开发团队）沟通软件质量状况，提供专业的质量意见。如果软件质量存在较大风险，要及时提出并建议采取相应的措施，如延长测试周期、增加测试资源等。
测试报告编写：
定期编写测试报告，总结测试活动的情况。测试报告应包括测试范围、测试方法、测试用例执行情况（如执行的用例总数、通过的用例数、失败的用例数）、发现的缺陷情况（缺陷数量、严重程度分布等）、软件质量评估结论等内容。
将测试报告提交给相关的利益者，如项目管理层、客户等，为他们提供决策依据，如是否可以发布软件产品。

测试的问题

图2

图3

图 4

图5

产品 开发 测试

首先,不埋怨 团队中任何一员,都配合干活,谁的责任 谁担, 全部都要非常了解业务设计

比如 产品负责需求 对齐 , 评审,产品写的 产品需求是否严谨,测试条件,而不是只画原型图,设计图
不给 逻辑 ,同时逻辑修改 需要对齐所有人,比如 和服务端说 的逻辑 要发到
在线文档,需求迭代规划& 跟踪、任务

测试需要完整了解业务设计,需求对齐产品, 测试用例, 测试复现 ,定位 , 缺陷跟踪管理、测试计划 & 用例会议 对齐

开发 完整了解产品设计,实现 , 良好编码,架构,扩展性,性能 ,完整的交付 产品逻辑

大多问题

产品需求不严谨,逻辑不对齐 甚至开局一张图 ,逻辑全靠问 ,部分人问了产品,产品不和测试 开发 对齐,产品文档逻辑定义是否完善,产品链路是否完善,

测试埋怨开发写出这么多bug ,首先是否产品定义 逻辑清晰,需求有无明确定义
把需求发bug单, 复现视频, 复现步骤, 抓包, 分析返回json 字段问题,
有无 了解 api设计文档,判定是服务端问题 还是客户端 问题,是否熟悉整个产品业务逻辑

开发 是否 熟悉整个产品业务逻辑 ,按 产品定义实现
程序是否良好的扩展性, 逻辑是否健壮
开发文档是否完善,设计文档是否完善,
Api文档 字段是否完善,链路是否完善,产品流程链路 流程文档

随便说说

测试人员的素质因人而异，有些人确实总能一阵见血的找到一些关键性 bug ，但是对一些常规 bug 、小 bug 容忍度就较高，有些人就是循规蹈矩照着测试用例一步一步执行，也能发现一些常规 bug 、小 bug ；所以测试是一个团队

1. 测试提的问题不全面： 例如项目经理每天看已完成的功能，总是能提出关键的问题，测试没测出来或没提出来，提到 Jira 中的
   -- 为啥产品没提出来，为啥研发没提出来，为什么要测试提？都是一个 team 的，这个测试不背锅

2. 生产环境：上线后，客户给提出来问题，测试没有测出来的这种情况
   -- 也要看实际 case ，定责问题而已，漏测很正常，一般主流程没问题的，都问题不大的

3. 测试提的问题：开发不能理解，导致出现反复修改的问题
   -- 面试的时候把测试当开发面咯，熟悉业务的测试可以教研发修改代码的，

4. 测试提的问题：总是有遗漏
   -- 看人咯，遗漏的话，那组织用例评审了，测试按照用例执行，还是有问题，大家一起背锅,通常都开发在救火

5. 测试：感觉态度不那么严谨，感觉负责人不是自己，无所谓，意识不到问题的严重性。
   -- 换更好的人