我是回家来吐苦水的。

illlh

我是19期的北京学员，到公司上班有一些日子了，也算了解了公司开发流程以及测试流程，对公司有一些看法，从中也能看出现今国内中小软件企业的一个发展现状。


首先先介绍以下我们公司哈。
我们公司是一个高新技术民营企业，通过了ISO9001-2000认证。公司规模不算很大，主要产品经营了十多年的硬件平台和相关配套软件。有独立的测试部门，而且测试部门在公司的地位相对其他小公司要好一些，有内审员，有评审团。下面给大家慢慢讲故事。
规范篇：
1。评审
   我们公司的评审很简单，项目经理写了一堆自己都没设计好的文档拿到评审去的时候，还有些段落是空白的。然后几个评审团成员开始对文档的设计进行分析，把设计的工作挪到了评审环节来执行，评审前，参与评审人员无人见过此文档。
   评审团成员万年不变的是开发总工程师、内审员、项目负责人、测试人员，其中只有测试人员是变动的，但是测试人员在评审之前没机会看到设计文档。
   我就纳闷了，那评审的时候干吗非得搞设计啊，不能在评审之前给我看看嘛。我都懒得去评审了，去了也没什么可说的，连文档都没看完呢就让我发表意见，我当然是没意见了。这样的评审虽然不能说找不出缺陷来，但是更多的时间是用在了设计分析上。完全体现不出评审的价值。
2。单元测试
    每个项目的测试接近尾声，没有新bug产生的时候，项目经理就开始催促开发人员写单元测试文档，这可难坏了一群java和C的程序员。他们根本就没做过单元测试，这文档让他们写什么呢，好办，开发经理拿出一份由内审员制订的单元测试报告模板，众开发人员大喜。
    我粗略得看了一下测试报告的模板，没有用例设计，没写测试工具，没有代码分析的描述，更不用说什么覆盖率检查了，开发人员绞尽脑汁得编写了一堆个模块的调用关系，并且在调用成功后指出，测试通过……
3。测试用例
   这部分是我们测试经理正在完善的部分，不过看他最近也是有心无力，每个测试之前都要写大量的用例，可是执行的时候没见用过。
4。需求规格说明书
   严谨点来说，我们公司从来都没有什么需求规格说明书，只有需求分析说明书。这个情况可能开发人员对需求及需求规格没有严格区分导致，当然，我们的内审员大人也不是很清楚。
   需求分析说明书中，未曾见过对任何一个需求的完整描述，上面大多使用不规范、甚至错误的流程图标明了需求实现的流程分析，也许我这么说有点不太明确，举个例子吧。
   客户的需求如果是给他一个苹果的话，
   设计人员会在分析说明中这样描述：1 出门去市场
                                   2 看兜里是否带了足够的钱
                                   3 寻找卖苹果的人
                                   4 买苹果
                                   5 送给客户
   这样的测试叫我怎么做呢？
   我得进行以下确认工作：
                           1 做车去还是步行？
                           2 用美员还是人民币
                           3 买多少苹果
                           4 是红色的苹果or任何颜色都可以？
                           5 买来的苹果都送给客户吗？
    说白了，只有需求，没有规格。
这样的需求分析在分发到其他开发人员手中以后，会买来各种各样的苹果，还有买来梨的就离谱了。我不关心你苹果是怎么来的，我就关心你送来的是不是苹果而已。
其实我只是想要在需求中看到要做什么，做成什么样子而已，大可不必写那么多实现方式嘛，这些实现方式难道不应该写在概要设计和详细设计中嘛，当然，我们公司是有写概要设计和详细设计的规定的，ISO企业，当然要文档齐全。
今天太晚了，先写到这，明天周末继续来吐苦水。周日去沙龙，没准被哪个大老板看中把我带走吧~~~

illlh

一周了也没闲出时间回来补帖,今天被房东屏蔽了路由,好不容易找了个无线,速度太慢,就不讲故事了,改天网络好点再讲故事
下期故事预告:ISO评审