第一次从项目开始做到终结,应该还是有很多想要留下来给自己沉淀的部分吧。那第一个部分应该是项目先前的整体规划,包括整个流程的规范,包括开发规范、测试规范,也还包括与客户在验收上要达成的一致,例如验收标准,要达到什么样的目标。这部分不在这里多谈,毕竟是老板们谈的事情大笑
  简单说两句开发的部分,毕竟不是我的专业,只是说些看到的问题,有不对的地方请大家拍砖吧
  首先,开发用的语言、框架自然不必说。其次,代码的规范,例如文件命名的定义。是不是需要写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应该在这几个面向上去管控项目流程进度的透明度以及正规化。这里面还有些没有谈到的,比如整个项目的流程上、持续集成都几个层面的问题,等我厘清之后再慢慢写吧。