3.4 测试案例

    软件测试常用白盒测试和黑盒测试，一般开发阶段做白盒测试，测试阶段做黑盒测试。这里的测试案例是为黑盒测试准备的，内容因各个项目而异，例如：

• 所有模块的可见页面是否齐全，是否《系统设计》、《需求说明书》（若有《产品规格说明书》一并参考）中列出的都有。 


• 可见页面的所有链接是否都工作正常。


• 可见页面的动态数据是否符合逻辑流程和商业要求。


• 表单提交页面是否能通过非常规测试。


• 可见页面是否满足美工UI页面，如果字体颜色不对、图标位置错误等等，都要予以纠正。


• ……

    项目组和客户各自写一份《测试测试》，彼此不能交换文档。一般项目组习惯侧重于功能、技术、逻辑等，客户侧重于界面、是否符合工作流程、是否满足需求等；如果互相交换文档，有时受先入为主的影响而局限测试案例的设计思想，有时项目时间过于紧张，文档编写人员会抄袭，这是不负责任的。

    文档格式例子见表5。

表 5

4. 开发阶段

4.1 版本号列表

    建议用版本控制器管理所有的文档和代码，这里假设组织使用SVN和有版本操作规范，规范定义了项目版本管理所需的角色、分支规定、版本号命名规定、使用者如何check in和check out文件、如何合并分支等等。

    开发阶段、测试阶段、发布阶段的版本号各不相同，项目经理编写《版本号列表》，提交版本服务器管理人员创建版本号、使用者帐号及其权限。然后发送文档给项目人员，成员据此操作。当一个阶段结束时，项目经理把所有检查过的、合格的文件并入主干中。

4.2 开发、测试、发布环境配置表

    配置表主要列有：

• 统一开发人员PC的开发工具，五花八门的开发工具有时会引发五花八门的错误，化时间去解决这些错误是无益的；


• 各阶段，版本服务器的访问地址和物理路径；


• 各阶段，软件的运行网址和服务器数据库的物理路径；


• 如果有外部设备，列出各阶段这些设备的访问地址和物理路径。

4.3 项目经理的代码检查结果表

    一般项目经理在开发中期和末期各进行一次代码检查，当然，如果时间充裕，检查次数越多越好。开展这项活动前，项目经理要肯定项目组的努力和现阶段成果，告诉成员尽早发现错误是好事，这能避免返工、绕开错误、提升软件的健壮性和稳定性。

    如果有特殊原因，项目经理可以委托他人执行这项活动，但必须对结果表进行复检和评估，对重要模块、重要SQL语句复查。代码检查所需的时间没有公式可循，一般开发时间越多代码越多，可以根据开发时间乘以某个百分率得到代码检查所需时间，这个百分比根据组织经验得出。

    完成公共类、公共设置、几个重要基础模块的开发后，要开展第一次代码检查，这能及时发现错误；检查范围是代码、SQL语句、服务器配置、外挂设备配置等等。如果开发人员多为新手，检查力度尽量细致到每个文件；如果开发人员经验丰富，检查力度可以粗一些，集中在业务逻辑、数据IPO等部分，对于不正确的格式问题，是要纠正，但不是代码检查的核心重点。开发人员根据项目经理的结果表修复错误，一般会轮循1-3次，如果超过3次以上，要引起注意和找原因。

    文档格式例子见表6，但内容不限于此：

表 6

4.4 开发人员的代码检查结果表

    这项活动在开发快结束时进行一次，当然，如果时间充裕，检查次数越多越好。开展活动前，依旧地，项目经理要肯定项目组的努力和现阶段成果云云。

    开发人员交叉检查模块，自己开发的模块不能自己检查，这是原则。检查的范围是代码和SQL语句。同样，这部分工时没有公式可循，建议宽松计算，每个开发人员的检查和修复时间约等于项目经理检查时间。开发人员根据代码结果表修复错误，一般会轮循1-3次，如果超过3次以上，要引起注意和找原因。

    文档格式例子见表7，但内容不限于此：

表 7

    开发人员除了找出代码缺陷外，还可以学习优秀的编码技巧。

4.5 架构客户硬件平台

    开发中期或末期，派人员到客户处架构运行软件所需的硬件平台，注意，只是硬件，开发中的软件不包括在内。一个很有趣的现象——架构硬件是很简单易见的事务，但常常被初级项目经理忽略，在这特别列出以示提醒。

【 发表评论 0条 】