第一次从项目开始做到终结，应该还是有很多想要留下来给自己沉淀的部分吧。那第一个部分应该是项目先前的整体规划，包括整个流程的规范，包括开发规范、测试规范，也还包括与客户在验收上要达成的一致，例如验收标准，要达到什么样的目标。这部分不在这里多谈，毕竟是老板们谈的事情大笑
　　简单说两句开发的部分，毕竟不是我的专业，只是说些看到的问题，有不对的地方请大家拍砖吧
　　首先，开发用的语言、框架自然不必说。其次，代码的规范，例如文件命名的定义。是不是需要写Unit Test，那是不是要达到什么样的覆盖度，当然对于贯彻持续集成的项目中，这一项会相对重要，如果不需要CI这一项可以根据项目情况来决定啦。CI的部分在流程规范的部分再谈吧。其实开发部分的规范还有很多，不多说了，只是想说明规范很重要。
　　好吧，说到测试的部分。
　　1. Test Case
　　首先，Test Case中要有什么栏位，例如Title、 Description(steps)、Input(test data)、Priority、Module、Functionality、Sub-functionality(maybe)、Case ID、Automation、Test type(blackbox， whitebox or others)、还可以通过栏位标记smoke/regression/E2E、Story ID(这里是来记录需求文档的number或其他的资讯，会比较好追溯)，标记Test type的讯息是为了让以后的Test Case比较好管理，可以在不同的测试时抓到正确的Test Case，例如我要做Head版本的测试可能要用的是smoke，那在做branch测试的时候会做Regression等等。
　　其次，Test Case的Description其实很难定义出来要写成什么样子，毕竟大家的工作习惯不全然相同。一直认为说，Test Case要像一个人写的，统一风格。在经历了这个项目之后觉得，那真的是个很好的预期，但确是很难达到的状况。理想很丰满现实很骨感。还是Case by case来说吧，进入Team的Tester时间不一样，那项目的松紧程度也不同，是否可以把标准统一贯彻到每个member，要考虑现实状况了；再者，规范定义出来之后在执行的时候是否严格，例如case review发现不符合标准的部分，如何让每个member都进行修改，直到达到标准之後。好了，我还是具体来说我的想法。再说明下，个人习惯(也有可能是客户要求)、项目情况都不同，还是case by case来看。对于Steps，描述清楚当然是首要标准，每一步都应该讲清楚是进入哪个页面(where)，进行什么样的操作(do what)，输入的数据是什么(input data)，输出应该是什么(output、expected result)。有些项目习惯用excel来管理Test Case，这样很难把每个步骤的output写清楚，只会有后一个期望结果，那这样好处是case粒度很细，坏处是case过度冗余，而且对于模块之间的关联性测试很难cover到，完全要依靠member对于模块的熟悉度去进行探索性测试，而这部分在测试过程当中往往是关键的，基本上大体的功能是不会漏测或者说开发不会做错的，像异常情况一样，这些模块之间串接的部分才是关键的测试点。对于一些有所共识的操作或者组件可以先期定义好，避免认知上的误差，例如复选框统一用checkbox，单选框用radiobutton；选择复选框用select，radiobutton用click
　　后Test Case的规划管理。个人见解，Test Case应该是项目中利用率高的部分，因为需求的变更带来的修改也是不可避免的，那需要很好的管理。在我接触过的项目中或者是潜意识中认为，按照Module来管理Test Case是比较合理的，业界也有很多方便的Test Case的管理工具，例如Testlink或者简单的Excel。不过我想说，在你有些不同测试需求的时候好像不那么方便。举例来说，按module测试，如果想进行smoke测试的时候需要重新找case出来，费时费力。那么如果我们可以有一种方式用Test Case中的一个键值将想进行测试的Test Case直接导出来或者生成一个文档很方便，只要分分钟可以搞定庞大的Test Case。当然，前提是Team member了解定义Test Case中定义每个栏位的意图在哪里，需要在新人正式进入工作前，给予系统的Training让大家清楚Test Case要写成什么样子的，什么样子的Test Case是smoke的、哪些又是Regression的，才会方便不同面向的测试
　　2. Bug
　　Bug上也有标准需要统一。Bug作为能体现问题的、与开发人员直接沟通的介质，要提供足够多正确的信息给开发人员重现问题、定位问题、解决问题。例如bug必须有截图、可能的话还要提供log日志、要有清晰的Title描述、详细的复现步骤，包括特定的帐号以及input data、screenshot要有文字描述、测试环境说明。像港剧里说的，死者是要借法医们传递死因给大家。我一直鼓励大家要尽可能挖掘到问题的本质，而不是单纯的表象。要了解到Bug到底是如何产生的，真正的原因是什么，要大家熟悉产品/项目的架构或技术体系，这也从一个角度说明测试其实并不一定比开发的要求低。另外一个颇具争议的部分是Priority和Severity。每个人的视角不同，无法有一个统一的标准定义优先级。我遇到过这类问题，其实是很简单的小问题，但会Block自动化测试的进度，那会是大问题。我也想这样是不是把问题搞复杂了，bug的定义还是应该简单化。
　　如果页面点不了、打不开、进入出错页那肯定是高优先级要处理的问题；
　　功能层面上也有可能有P1或者P2之分，那要Case by Case的来区别对待；
　　功能上还有部分属于异常情况的测试场景可以放到P3的范畴；
　　当然还有些是trivial或者tinny的问题，但请不要忽略这样的bugs，有时候在客户看来或者不同的软件产品上有些wording的问题会影响专业性。
　　其实，说到底无论是什么开发模式，敏捷也好、瀑布也罢，在项目kickoff之前确定好个部分的规范很重要，出现了什么问题应该找谁，产品经理应该做到什么、测试要做到什么、开发要如何开发。从项目管理的角度，才让每个部分的进程在可控的范围，PM应该在这几个面向上去管控项目流程进度的透明度以及正规化。这里面还有些没有谈到的，比如整个项目的流程上、持续集成都几个层面的问题，等我厘清之后再慢慢写吧。