测试整个工作流程围绕着禅道项目管理工具运行： 1.产品给出需求文档->2.评审后拆分开发任务和测试任务->3.测试用例编写和评审->4.开发人员完成开发提测将测试任务指给测试人员->5.测试人员测试提bug->release环境做发布前验证->版本上线 可以参考禅道官方的项目管理流程图 下面就以上面的工作流程为顺序提出对每个环节的工作规范。 1. 需求评审 由产品经理主持需求评审，相关开发、测试同学参加。 要求待评审的需求至少提前3天提交到禅道中。 对测试的要求: 1. 至少提前一天浏览需求，对需求有初步理解。 2. 必须参加负责项目的需求评审，如因故不能参加，考虑延期评审或找人代替 3. 思考可能的业务逻辑疏漏或与现有逻辑的冲突 4. 需求评审后要评估测试工作量（小时或人天） 5. 拆分任务，将需求在禅道中拆分为测试任务。 2. 测试用例编写 1. 测试用例编写要符合规范https://ryan255.ltd/testcasestandard/ 2. 新功能要求一定要编写测试用例 3. 项目时间紧急，也要列出测试点，以便日后将用例补充完整

1. 编写测试用例的目的 1. 统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。 2. 测试用例，不仅仅用于QA阅读和执行。它们也可能会被开发、PD、PM等阅读审查或执行；也更可能被其他测试人员或者新员工作为业务学习、测试执行的参照。 3. 编写测试用例的最终目标是：一个对于产品毫无所知的人员，也能够快速的熟悉用例并执行用例。 2. 模块划分规范 要求： 1. 产品、功能点同一层级的结构按同一个纬度来划分。如应用、同等级产品、同等级功能点等； 产品是指大的业务模块。如门店管理、交易下单； 2. 功能点指业务模块下的子功能点，是最小功能点叶子节点。如: 订单-订单详情-分页; 3. 产品、功能点划分不允许包含冒烟、回归、自动化这类以测试阶段或测试方法的命名的名称； 4. 用例库中产品、功能点已废弃的需要及时删除； 5. 用例库命名格式需要统一标准格式； 3. 用例颗粒度划分规范 1.

> 文章写于2018年8月 昨天"被"换了部门，虽然有点突然，但也算意料之内，情理之中。并且仔细想过之后，发觉这也未必是一件坏事。 捋一捋进入手司以来的经历，也算做一个记录和总结: 2016年夏天参加了两个月的培训，培训结束后返回学校完成大四为期一个月的专业实践课程。国庆过后，返回公司跟着老史参加优衣库官网后台项目组。这样一直干到了春节，节后又上了一个月班便返回学校完成毕业设计。2016年7月-2017年6月这一年处于实习和试用期，断断续续在公司和学校之间来回折腾。 一直到2017年6月中旬弄完毕业相关事宜开始真正全职在公司上班。这算是初步稳定了下来，2017年7月转正考评，结果还算满意。可惜好景不长，转正不到一个月，直接领导老史离职了，这对我们刚刚转正加入老史组里的成员来说算是一个不小的打击。不过当时我并没有多想，也只是按部就班完成手里的工作。对于新员工来说，刚转正就失去了直系的领导，这件事的影响可能并不是当初刚走出校园的我所能想象的。 8月份，风波说来就来，部门的领导计划让研发中心的成员逐步从优衣库项目中撤出。而我和同是原老史手下的另一位同事，就被通知去深圳出差了。当时

> 十个月的时间，辗转六七个项目，虽以普通开发人员的视角管中窥豹，但项目中的问题弊病依然可见一斑.从几个方面写写自己的见闻和浅析吧 问题 1. 人天问题 软件开发项目最大的成本就是人。人天预估的高了不容易中标，人天预估的低了又难以保证质量，其中的权衡拿捏不是我一个小技术能涉及的。 但是真正落地实际情况并不理想，在许多项目的承包上，项目预估的人天与实际所需严重不符，甚至有项目刚开始做需求分析的时候，工期已经过去了一半多。所以即使已经疯狂压榨开发人员(个别项目整月整月的加班到12点)，很多项目还是不得不延期，仓促赶工导致项目质量不行与延期之后带来的成本提升都在降低甲方的满意度，同时也降低了乙方的利润 2. 业务能力不足 多数项目中缺少能从整体角度辅助客户完成业务功能设计的出色业务顾问.很多项目中，甲方业务需求自己想方案完成方案设计，乙方业务能起到的作用小. 3. 盲目推行新模式 从项目中期开始赶鸭子上架推行DDD，领域驱动设计的确要求与业务加强沟通，双方共同设计出领域模型.但是在双方对领域驱动设计都缺乏了解的情况下强行推进DDD很容易弄巧成拙. 一方面业务人员容易落入原本瀑布式开