今天完成的事情：
1.回温如何做需求分析
2.继续完成深度思考内容
3.参加评审
明天计划的事情：
1.回顾今天学习的内容，默写出来
2. 完成任务一余下的七个深度思考，总结任务一内容
3.开始任务二深度思考
遇到的问题：
1.测试的种类、方法
收获：
二、如何做需求分析？
获取需求--处理需求--解决方案--排序需求--撰写报告--执行、复盘
三、怎么衡量Bug的修复时间和项目的上线时间冲突问题
1.要看BUG的严重程度：系统直接崩溃、瘫痪和逻辑出现严重问题，流程卡住，无法进行下一步时，需要修复后上线
2.部分功能出现闪退，功能没有实现，产品可以满足业务要求，部分小限制不符合验收标准，界面等UI问题显示错误等可以先上线后解决。
3.影响信息安全（信息或数据安全；帐户安全；财产安全等，必须延迟发布，假设上线了，不仅影响公司的声誉，还可能直接造成公司或者用户的经济损失。
四、边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试的含义分别是什么，应该谁来主导，原因是什么？
边界测试：探测和验证代码在处理极端的或偏门情况时会发生什么
不仅包含输入、输出的边界，还包含数据结构的边界，状态转换的边界，功能界限的边界或端点。
功能测试：对产品的各项功能进行测试，根据功能测试用例，逐项测试，检查产品是否达到用户邀请的功能（最高级别测试
功能测试就是黑盒测试，数据驱动测试，只需考测试的各个功能。
冒烟测试：在对一个新版进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测试性。（基本功能和流程能走通）（在功能测试完成之后，在新安装和更新的输入值之后，将在起始点执行一个简单的测试。
对程序主要功能的验证，而不会对具体功能进行更深入的测试.冒烟测试的最佳实践还是最好被自动化，在CI中每一个Build都自动的去执行主流程的测试，确保其是一个基本可用的版本。
黑盒测试:也称为功能测试.已知产品所具有的功能,通过测试来检测每个功能是否能正常使用。在测试时把程序看成一个不能打开的黑盒子，在不完全考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能能否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
自动化测试：是指软件测试的自动化。软件测试就是在预估条件下运行系统或应用程序，评估运行结果，预先条件包括正常条件和异常条件。自动化测试就是将以人为驱动的测试行为转化成机器执行的一种过程。
回归测试：检验软件原有功能修改后是否保持完整。（当系统中出现复杂的bug时，通常会影响系统的核心区域，所以使用回归测试来重新测试系统的所有模块。
性能测试：通过自动化的测试工具模拟多种正常、峰值和异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
应该由最高级别测试--功能测试主导。因为其实对产品的各项功能进行测试，检测每个功能是否能正常使用，如测试出每个功能均可正常使用，可保证产品在正常运行时没有问题。
五、Bug如果长时间未得到解决，应该怎么处理？做为PM，是否应该推动Bug的解决，如果PM成Bug的推动者，会不会导致开发人员越来越不主动？
1.邮件与开发沟通后仍长时间未解决，找开发组leader
2.肯定要推动，影响上线时间
3.PM不会是BUG的推动者，有测试和开发人员处理BUG，PM推动的是重要且长时间未得到解决的BUG，项目组为了同一个目标奋斗，开发人员怎么会变得不主动呢
六、怎么样判断Demo是否应该通过?
Demo过程中，有一个Demo通过的基本原则， 就是但凡是肉眼能够发现的错误，都应该记为不通过， 而不是说，有几个Minor级别的小问题，可以通过
以下是资料：
第一，Demo是开发团队向产品团队交付，所以Demo的主角是研发团队。 第二，Demo应该依照Story去演示功能，防止有遗漏。 第三，Demo之后就会打Tag（固定代码版本）， 所以Demo应该是非常严谨的，从来都没存在所谓的主流程跑通， 而是应该一行代码都不需要改动，直接发布到测试环境。 第四，Demo过程中，有一个Demo通过的基本原则， 就是但凡是肉眼能够发现的错误，都应该记为不通过， 而不是说，有几个Minor级别的小问题，可以通过。 第五，下次Demo的时候，可以只演示Demo中出现的问题，以节省时间。 第六，产品人员和测试人员应该参加Demo， Demo的时候不仅是要看一下研发团队的操作， 还应该自己亲自在PC或者是手机上操作。 第七，Demo的数据应该使用仿真数据 （而不是随意填写的测试一，测试王八蛋之类的）。 第八，在Demo之间，应该先进行性能测试，UI自检规范和CodeReview， 三者通过之后才允许Demo。 第九，如果有Bug的修复，也应该在开发环境先向测试人员演示通过， 才允许发布到测试环境，以减少反复发布测试的次数。 第十，Demo过程中发现的问题，应该记录下来责任人和预计修复时间。
以上通过查阅资料结合自己理解得出的结论。
返回列表
评论