摘要: 测试一段:能根据测试用例的描述步骤来执行测试用例,能对照用例的逾期结果发现产品的问题,能够清晰准确地将问题记录下来后反馈给开发,开发能够读懂问题描述的含义; 测试二段:对产品需求有一定的了解,能够根据产品需求分析、设计产品的测试用例,发现问题后能够进行初步定位; 测试三段:对产品的需求和实现都有较为 阅读全文
posted @ 2021-02-19 10:37 崔海辉 阅读(73) 评论(0) 推荐(0)
摘要: 1、软件未实现产品说明书要求的功能。 2、软件出现了产品说明书指明不应该出现的错误。 3、软件实现了产品说明书未提到的功能。 4、软件未实现产品说明书虽未明确提及但应该实现的目标。 5、软件难以理解、不易使用、运行速度慢、或者软件测试员认为最终用户会认为不好。 阅读全文
posted @ 2021-02-10 10:28 崔海辉 阅读(221) 评论(0) 推荐(0)
摘要: 1、总是、每一种、所有、没有、从不。如果看到此类绝对或肯定的描述,需要确认是这样的。软件测试员要考虑违反这些情况的用例。 2、当然、因此、明显、显然、必然。这些话意图说服你接收假定情况,不要中了圈套。 3、某些、有时、常常、通常、惯常、经常、大多、几乎。这些话太过模糊。‘有时’发生作用的功能无法测试 阅读全文
posted @ 2021-02-09 10:02 崔海辉 阅读(59) 评论(0) 推荐(0)
摘要: 测试团队将推动功能性风险分析,以达成如下目标。 1、保证产品的质量风险被周知 2、保证测试团队始终仅关注最高投资回报率的任务 3、保证存在一个质量和数据评估框架,能够随着产品的演进和新数据的引入,对新的质量和风险数据进行评估。 风险分析过程是将所有已知产品特性和能力简单罗列,然后测试团队根据每个方面 阅读全文
posted @ 2021-02-07 15:33 崔海辉 阅读(399) 评论(0) 推荐(0)
摘要: 1、需求评审 前:提前了解需求业务逻辑、业务场景 中:解决疑问 后:设计业务场景 2、技术概设 了解代码层的逻辑怎么实现需求 3、交互评审 业务的操作 4、UI评审 前端展示 5、用例设计 尽可能早的熟悉需求,澄清需求,设计用例。 业务逻辑复杂的要多动脑子想涉及到哪些场景 不管功能多小,都要写用例, 阅读全文
posted @ 2021-01-08 17:01 崔海辉 阅读(386) 评论(0) 推荐(0)
摘要: 1.1 测试经理(组长) 通过熟悉需求,输出测试计划、测试方案 1.2 软件测试工程师 第一步:熟悉需求,需求澄清 针对一个业务场景,搞清楚如下三个方面: 交易前:满足哪些条件 交易中:业务处理细节和步骤 交易后:业务处理结果 第二步:根据测试经理安排的任务(确定测试范围),做需求拆分,进行测试需求 阅读全文
posted @ 2020-11-07 18:14 崔海辉 阅读(161) 评论(0) 推荐(0)
点击右上角即可分享
微信分享提示