miniRe的博客

敏捷测试（杂）测试左移冒烟测试推至开发，保证提测需求的质量保证每个环节出来的质量《敏捷软件测试：测试人员与敏捷团队的实践指南》 by Lisa Crispin 和 Janet Gregory方法篇：以相对可靠的方法减小测试范围减少工作量，取舍影响范围工具篇：用自动化测试方法减少测试执行时间如何减少测试执行时间对测试的认知测试人员不应该是以发现bug越多越有成就感，而是要想着如何跟不同角色高效合作，使得交付的产品能够优化业务价值对技术的关注测试活动多样性不能只关心测试相关技术，

复现Bug方法总结1、探索性测试2、Bug复现技巧与方法确保所有的步骤都被登记：记录下所做的每一件事、每一个步骤、每一个停顿。无意间丢失一个步骤或者增加一个多余的步骤，可能导致无法再现软件缺陷。在尝试运行测试用例时，可以利用录制工具确切的记录执行步骤。所有的目标是确保导致软件缺陷所需的全部细节是可见的特定条件和时间：观察软件缺陷仅是不是在特定时刻出现、特定条件下产生。产生软件缺陷是网络忙吗？在较差和较好的硬件设备上运行测试用例会有不同的结果吗？压力和负荷、内存和数据溢出相关的边界条件：执行某个测

github使用积累

###评审准则：###测试案例要素测试环境：是充分必要的环境条件测试数据：步骤需要具备连贯性、可执行性测试目的：P0-P4，一般来说，P0、P1、P2、P3案例的占比分别为15%，35%，40%，10%，每一分级的案例占比偏差不能大于5%测试步骤：一般应该是3步左右，绝对不能超出5步测试结果 ：保证明确性、准确性，以及和需求一致性###设计框架####使用xmind提前定结构模块划分合理行：要包含所有要测试的对象，但不能重复逻辑链路流畅性：业务流程是流畅的，没有阻隔子属关系正确性

测试点编写（功能测试）为什么需要写测试点个人感觉测试和人某些成长其实有点类似。获取到需求文档、UI稿其实等同于这个功能获取到生命；我们开始编写测试点相当于这个功能开始学走路； 编写测试用例等同于学习奔跑；或许比喻不是特别恰当，但是能理解就好。既然如此，没理由我们在没学会走之前就去尝试奔跑，因为这样操作，后续会发现测试用例会有很多坑。也就是你会在奔跑的时候不断的摔倒。当然编写测试还有更重要的原因1、测试点是需求文档测试要点的提取文档，先编写测试点可以有效防止直接编写测试用例造成测试场景缺失、需求理

百搭模版：机型+版本号+操作步骤+附件辅助材料优先级：字不如图， 图不如视频首先判断是否为Bug非bug大多数情况1、部分协助判断依据网络问题是否被系统禁用权限系统设置禁用网络查看系统内其他的App是否能正常上网直接设置内查看POP的网络授权内容发送失败所有内容均发送失败当前网络环境不稳定切换网络环境看看:移动网（2G/3G/4G）/Wi-Fi/飞行模式部分内容发送失败，其余成功（转bug）权限问题微信、QQ分享/通知/地标授权摄像头/麦克风系统静音：看什么