发表于： 2019-03-18 10:07:11
1 480
今天完成的事情：
一、今天对照之前的pm学员提交的测试用例，对比了自己写的测试，有些地方的表述还是不够规范，有些功能点的测试测试不到位。
二、了解了敏捷开发的概念，关于敏捷开发在国内的推行状况及效果在网上还是存在很大的这争议的。
三、学习了bug管理方面的知识。可以看这篇文章，文章作者曾在微软工作过，自己组织过Bug管理工具的软件研发。
https://blog.csdn.net/wishfly/article/details/1871701
1.什么是敏捷开发?
通过不断地快速试错来做正确的事情。 。精益创业里提出的最小化可行产品（MVP，minimum viable product）就是这一点的充分体现——通过开发最小化可行产品，以最低的成本来达到快速试错的目的，找到一条正确的道路，最终做出符合用户期望的产品。
敏捷开发在国内难以实行， 《Scrum在亚洲难以实行》主要列举了四个原因：
亚洲文化中等级观念根深蒂固，人们习惯于遵循体制，与敏捷思想中的“自我组织”、“自我管理”背道而驰。亚洲人好面子，讲究和谐第一，很难像西方人一样坦率直白地交流，造成了沟通障碍。亚洲的教育思想排斥犯错，教育出来的人都怕犯错，很难理解敏捷思想里的“快速试错”理念。亚洲的软件开发是从外包起步的，习惯于节约成本，而想要学会敏捷开发往往需要投入额外的时间与金钱
这四点刚好切中了要害，精确地概括了敏捷在亚洲难以落地的主要原因。今天，我想就个人一点不成熟的观察和体验，分析一下除了上面这四点，还有哪些具体因素导致敏捷开发在中国接不上“地气”。
什么是敏捷开发
敏捷绝非某一种特定的开发方法，它只是一种应对快速变化的需求的一种软件开发能力。敏捷本身只包含了《敏捷软件开发宣言》和《敏捷软件的十二条原则》两份文档。敏捷相信，只要符合这两份文档的开发方法，就能让开发团队拥有应对快速变化需求的能力，这样的开发方法都叫做敏捷开发方法。
最流行的敏捷开发方式是什么
敏捷开发的方法有很多：ASD、AUP、DSDM、XP、FDD、Kanban、RAD、Scrum。目前国内最流行的应属Scrum。
Scrum本意是指橄榄球运动中的“带球过人”，它可以解决非常复杂的项目，并且能高效并创造性地交付高价值的产品。Scrum包含3个角色、3个工件、5个价值观、5个事件（详情https://www.scrum.org/）。
相比其他敏捷方法，Scrum既不简单又不复杂。它有完善的指南，你可以按照指南，轻易在团队内推广尝试。但想要实践好Scrum，又需要很好的技巧。这种易上手难精通的方法，特别适合培训机构。所以近几年，关于
Scrum的培训机构遍地都是。可以说，在Scrum流行这件事上，这些培训机构做了很大的贡献。
敏捷开发> 分小步 快速开发 快速响应 快速原型 持续完善 不断更新 结束
开发步骤：
需求指定——>需求分析——>设计编码——>测试、功能验证——>发布版本——>下一个周期
1、需求制定：需求话方根据上一个版本，提出的新开发需求或调整等
2、需求分析： 开发及测试人员，与需求方讨论并分析新需求，并验证需求的可行性。
3、涉及编码：根据确认后的需求，设计实现方式并进行编码。
4、测试、功能验证：对软件稳定性进行各种测试，并由配合需求方进行功能验证。
5、发布版本：将这个版本发布给需求方。
一个完整的软件版本划分为多个迭代，每个迭代实现不同的特性。重大的、优先级高的特性优先实现，风险高的特性优先实现。
在项目的早期就将软件的原型开发出来，并基于这个原型在后续的迭代不断完善。
迭代开发的好处是：尽早编码，尽早暴露项目的技术风险。
尽早使客户见到可运行的软件，并提出优化意见。
可以分阶段提早向不同的客户交付可用的版本。
在每个迭代中，架构师负责将所有的特性分解成多个Story Card。每个Story可以视为一个独立的特性。
每个Story（用户故事卡片）应该可以在最多1个星期内完成开发，交付提前测试（Pre-Test）。
当一个迭代中的所有Story开发完毕以后，测试组进行完整的测试。
Scrum具体指整个系统开发的流程，而这个大流程又由多次迭代完成，一次迭代的过程称之为一个sprint.
2.如何做需求分析？
分析需求：
a）根据业务逻辑和业务流程画出流程图，分析需求以及业务走向
b）挖掘每个需求点的产生原因（知道为什么，）
c）挖掘每个需求点的隐含需求
d）挖掘每个需求的必要性
需求优先级划分：
1.KANO模型
该模型将需求可以分为三种，包括基本型需求，期望型需求和兴奋型需求。
基本型需求就是必须满足的基础功能，比如吃碗面，食材餐具卫生、煮熟可食用就是基本需求；期望型需求就是用户能够明确提出的希望有的需求，还是吃面，比如环境好，价格合理，分量足等等；兴奋型需求就是用户也不知道，但有了用户很惊喜的需求，依旧是吃面，比如味道超好，第二碗半价等等；2.四象限法则
分析需求记得哲学唯心三个问题：
1.我是谁？ ——受众群体是怎么样的一群人
2.我从哪里来？ ——需求的背景是怎么样，为什么会产生这样的需求
3.我要到那里去？ ——客户想要怎么样的功能，他们想要实现的目的是什么
感觉在确认需求的时候一定要多问几个为什么，自我推导....
3.怎么理解程序员会写出Bug这种事情，可不可以要求他们做到无Bug交付？怎么衡量Bug的修复时间和项目的上线时间冲突问题？ 点击查看相关小课堂
开发应用程序是一项压力很大的工作，人无完人，工作中遇到bug是很正常的事程序员写出bug 是难以避免的 这是程序猿积累经验的过程 规律
做不到没有bug 交付 世界上没有不存在bug的软件 bug 是需要预防机制和三方人员严谨的工作态度来减少的 不是只靠程序员
凭着bug 优先级不同大致修复时间 来决定 上线时间 三级到一级 没有上线必要
衡量Bug的修复时间和项目的上线时间冲突问题。
- 这个bug是否致命.出现就会crash,或者影响核心业务流程.
- 这个bug是否很显眼,用户一启动App就会遇见.
- 这个bug是否必现.
- fix这个bug的时间是否会严重影响项目上线.
if (1) 修复完再上线
else {
if(2&3) 修复完再上线
else if( !4 ) 修复完再上线
}
4.边界测试，功能测试，冒烟测试，黑盒测试，自动化测试，回归测试，性能测试的含义分别是什么，应该谁来主导，原因是什么？ 点击查看相关小课堂
边界测试;
边界值分析是一种常用的黑盒测试方法，是对等价类划分方法的补充；所谓边界值，是指相对于输入等价类和输出等价类而言，稍高于其最高值或稍低于最低值的一些特定情况。边界值分析的步骤包括确定边界，选择测试用例两个步骤.
边界测试是用来探测和验证代码在处理极端的或偏门的情况时会发生什么。
功能测试： 对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
冒烟测试： 冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
黑盒测试： 黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
自动化测试： 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。
回归测试： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
性能测试： 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
5.Bug如果长时间未得到解决，应该怎么处理？做为PM，是否应该推动Bug的解决，如果PM成为Bug的推动者，会不会导致开发人员越来越不主动？
bug 长时间未解决 应该考虑处理bug时间机制 bug流转 移交 问题 以及负责人未解决bug 而应有的惩罚机制
pm 不会成为解决bug 推动者 机制才是 。微软的bug管理工具： Raid
把研发管理真正搞起来，做出规模效应，从而有效的保证质量、控制进度、把对某个人的依赖尽量降低，并使产品可持续发展。
Bug管理制度其实就是定义Bug处理流程，有了好用的工具之后，我们需要这样的流程去明确指导如何对Bug进行管理。但是一个软件开发团队应当制定严格的Bug管理制度吗？坦率的讲，不需要。严格的制度在软件行业就意味着教条、负担和不切实际，让一帮聪明的大脑陷入无边无际的条条框框不能自拔，明知道是包袱还要去背、是火坑还要去跳，直到有一天终于受不了，最终结果不外乎三个：过劳累到、对付一天是一天或者干脆辞职换个工作。因此我觉得应该用“Bug管理指导原则（guidance）”来替换“Bug管理规章制度（rules & regulations）”这个词。
所以我认为Bug管理就是去制定适合自己团队实际情况的Bug处理流程和指导原则，制定者（管理层）应该起到真正指导的作用，他们要非常清楚下面这些问题的答案：
l 我们需要测试什么：哪些软件（网站）、哪些模块
l 测试人员的分工：什么人负责什么模块
l 测试工具和环境：巧妇难为无米之炊。你不能安排一个测试人员去测某个模块，而没有给他提供必要的软硬件环境
l 测试的进度安排：干这一行加班是不可避免的，但是需要有度，人不是机器，长期的劳累谁都扛不住。如果时间很紧，那只能去抓重点，要有所不为
l 发现一个问题时，如何用Bug管理工具去创建一个Bug：标题如何写、严重程度、详细重现步骤、错误状况、期望结果、现场附件、这个Bug去分配给谁
l 当一个Bug被处理掉时，测试人员应该如何验证并关闭
l 当一个Bug的解决方法有争议时，谁来仲裁
l 定期的Bug提醒，比如当前每个人的Bug情况
l Bug状态报告：Bug数目的变化趋势及我们应该采取的行动
l 阶段性的总结反馈：哪些地方我们做的好，哪些做的不好，为什么、如何改进
通常一个Bug的处理过程是这样的：
1. Tester发现一个问题，到Raid中创建一个Bug，描述这个Bug的详细信息，比如重现步骤（Repro Step）、错误结果（Result）、期望的改动（Expect）、运行版本等；然后把这个Bug指派给负责该模块的Dev Lead
2. Dev Lead判断后把这个Bug指派给某个特定的Dev
3. Dev处理掉这个Bug并返还给原Tester，或者请求PM给出一个澄清说明
6.怎么样判断Demo是否应该通过?
肉眼能发现的错误都不能通过 三方人员亲自操作使用 功能 核心无误 通过
7.常用的Bug管理工具有哪些，互相之间有什么差别，你更喜欢哪一种，为什么？ 管理商业产品应该有不少，比如，IBM提供的Rational ClearQuest、微软将在VS.NET 2005（Whidbey）中集成的Bug管理系统、上海微创提供的BMS、科泰世纪《和欣软件工程管理工具》套装软件中的Bug管理系统等等，都应该不错。开源社区中，你可以选择Bugzilla！、Mantis等Bug管理系统。
这篇文章对五款轻量型bug管理工具横向测评
Teamin是最能满足是我需求的一款在线的bug管理软件 唯一遗憾的一点是没有默认的任务优先级设置，不过这一点可以通过点赞关注任务或者添加标签和自定义字段来解决。
8.为什么要区分开发，测试，线上三个环境，三个环境之间的区别是什么？分别由谁来主导？ 点击查看相关小课堂
三个环境 开发 测试 上线 每个 改动次数 稳定程度 从高到低排列 线上最重要 所以 要区分开 用三台服务器物理分开最好
开发环境由开发人员指导，测试人员由测试人员指导，线上环境由用户主导
9.什么是版本回滚，在发布上线的过程中，如果发布不成功，多久之内应该要回滚，谁来决定，原因是什么？ 点击查看相关小课堂
回滚泛指程序更新失败, 返回上一次正确状态的行为。个人理解 如果 发布失败 一小时内进行回滚 因为发布时间 是凌晨五点到七点 还没到用户使用时间 过了 七点 大批用户无法使用 回滚由pm 和QA 决定 程序如果要回滚 那是程序 重大失误
10什么样的Bug是允许上线的，什么样的Bug是不允许上线的？
根据bug 优先级 三级到一级 全不能上线 分别是 系统奔溃核心功能操作被卡死 流程跑通了 预期结果不对
四级到五级可以上线 一个是 用户有耐心可以 但不超过三个 一个是设计问题 颜色 字体 错误等
11Bug的优先级是什么？一般会分成几个级别，分别对应什么含义？
bug优先级
critical 代表系统 奔溃 所有功能无法使用 例子 网页访问失败
block 核心功能操作步骤被卡住了 例子1206购票
marjor 业务流程可以跑通 但是和预期结果不符
norrnal 无关紧要的错误 用户可以等待 但不能超过三个
minor 无伤大雅的问题 例如错别字 样式错误等
12Bug的生命周期是怎么样的？什么情况下应该是Reopen？什么情况下去Close？
bug典型的生命周期应该是：BUGStart--> BUG初始状态 -->BUG分配状态-->BUG重新分配状态 --> BUG修复状态 -->BUG验证状态 --> BUG关闭状态
测试人员发现BUG并且将该BUG标记为Unconfirmed&New状态，下一步测试人员在排除BUG的登记错误后，将该BUG置为Assigned状态。
实现人员接到该BUG通告，进行BUG确认，确认成功后该BUG状态被置为Reassigned状态，当实现人员修复BUG后该BUG置为Resolved&Fixed状态。
测试人员对实现人员修复后的BUG进行确认测试，如果该BUG被正确修复了，那么其状态被置为Closed&Fixed状态，同时意味着该BUG的整个生命周期终结了。
如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”
如果测试人员经过再次测试之后确认bug 已经被解决之后，就将bug的状态设置为“Closed
13什么是测试用例，为什么要写测试用例，测试用例中的前置条件是什么？预期结果是什么？一个登录注册的小模块，正常来讲，应该有多少个测试用例？
根据产品需求 设计出不同场景 使用方法 来确认功能可以正常使用但是对不同功能的操作 方法太多 又不同 所以使用固定模板来记录 不测试 无法确保产品功能使用没有问题
前置条件:做一个操作, 前提是什么, 满足前提 ,才能进行操作得到结果
陆窗口主要就是用户名和密码的输入，然后点击登陆按钮进行登陆，编写测试用例过程中，将用户名分为合法、非法、为空、为空格四种情况，密码分为正确、错误、空、空格四种情况进行组合测试。
这里测试的前提条件是已经有一套注册系统来限制用户名和密码的字符类型等。在此基础上再进行的登陆测试。所以测试用例数据的选取可以根据具体情况来定。另外具体的错误提示信息需要相关的需求文档来给出。
14什么是产品经理?
产品经理（Product Manager）是企业中专门负责产品管理的职位，产品经理负责市场调查并根据用户的需求，确定开发何种产品，选择何种技术、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。
明天计划的事情：开始任务二
遇到的问题：
收获：了解了敏捷开发和bug
返回列表
评论