这是我写的一个测试流程，希望大家给点意见
我们公司的测试部门是刚开始组建，现阶段只能单个模块的黑盒测试，我结合我们公司的情况写了一个流程，希望大家能多多指教，如果有好的建议，希望大家能跟我联系。EMAIL:hecunwen@tom.com
QQ:30109514
测试流程
测试流程主要分七个步骤：
一、 程序员提交测试任务书。任务书主要包括以下内容：
1、 编写该模块的目的以及模块应该实现的功能。
2、 模块包括哪几部分，每部分的安装路径以及一些特别的要求。
3、 模块各个功能的用法。
4、 给出测试要求，给出模块的重点功能以便确定测试重点。
5、 测试应该注意的事项。
二、 测试员通过任务书或者程序员等方式，熟悉模块的具体功能。
1、 认真阅读任务书，对模块的开发目的和相关的技术有一定的了 解。
2、 按照任务书的要求，安装模块，让程序运行起来并使用。
3、 对测试点进行归纳和组合。
三、 编写测试用例，用例要求以下几点：
1、 写明测试的目的和功能特性。
2、 用例要求覆盖范围要广，各种可能性都要考虑到。
3、 用例的描述和操作说明要简单清晰。
4、 测试数据要详细给出。
5、 如果测试有特别的信息应该说明。
四、 在不同的平台执行用例，填写BUG报告表。
1、 严格按照测试用例的要求执行。
2、 测试的时候要细心认真。
3、 BUG的描述要简单清晰，如果有必要可以附图。
五、 程序员收到BUG报告表后确认是否BUG，修改后写明原因，把BUG报告表提交测试部。
六、 复检测试，阅读BUG报告表，测试修改是否成功。
七、 把用例和BUG文档归类存入数据库。 ding 个人感觉缺少了测试计划环节，对照任务书熟悉模块、对测试点有大致的想法后应该考虑如何测试，进行计划测试，然后再进行用例的设计。另外在用例设计过程中以及测试执行过程中都可以对测试计划进行更新。 缺少的环节太多了。在项目做需求的时候测试人员就要开始参与，有能力的话功能设计也要参与进去，在编码阶段就要开始做测试计划和测试方案。
上面的流程只是在编码之后测试人员才开始介入，为时已晚。 楼上的兄弟说得都很对，不过这是我们公司的实际情况所决定的，由于我们公司的模块都是开发部完成了以后，我们测试部才知道的（所谓测试部只是挂名的，都没正式成立过），最要命的是这些模块都是在一周或者几天就要出货了，所以我把我的写的流程拿出来，希望跟大家交流一下。 那时间也太紧了吧，估计按照这个流程也很难完成
测试只是一个样子而已
这种情况下就更考验测试的水平了，特别是测试计划的水平。1.首先需要告知管理层，由于时间太紧，完备的测试不可能进行。
2.由于时间短，就需要保证模块基本功能、主要功能测试的充分，尽量站在用户的角度来思考如何测试。
个人意见，欢迎讨论。 关键是“有效”！小可一直喜欢在各种场合强调“有效性”，是希望在工作的时候不要忘记了自己的真实目标，而被一些其他的事情吸引了过多的注意力！一定要紧紧盯住关键的最终目标不放，使用最有效、最直接的方法来实现它。一定要牢记自己的目标！ 好的环境不是完全靠别人给，也可以自己争取。
你们的测试从代码开发完成后才进入，的确差了很多东西，工作起来会很被动，而且也达不到好的效果。
建议与上层沟通，改善工作的环境，我想既然你们的上层已经开始组织人员测试了，只要你能拿出好的改进方案，他们一定会在某种程度上提供方便的。
希望斑竹给传个测试流程：）
测试用例其实并不是保证测试质量的根本吧.
一個dsp程序(mp3 player)要在2個星期裡面完成,包括閱讀spec,定測試方案,完成測試用列的制定,審核,大家認為可行嗎?在這種流程下面執行,而且必須保證質量!(包括MP3解碼軟件測試和WMA解碼軟件測試). 2、 用例要求覆盖范围要广，各种可能性都要考虑到。-- 这是不可能做到的
根据实际可将流程做合并或精简
按楼主所讲的，我认为在这种情况下可以将流程合并或做精简。对于要发出产品的主体流程，和这个版本的必要问题作为重点，其它的只要没有大的错误和数据的不可修复的损坏，就过吧（虽然这是我们不希望的，但是80%的情况都是这样的。）个人观点。 建议使用一下测试过程管理工具，如Test Director、QESuite等，对测试流程会有更深的认识。 个人认为:
熟悉业务流,在此基础上制定测试用例,一些简单的功能可以省略,有时间再补,分模块交叉测试,从需求说明要实现的功能尽快过一遍,从用户的角度进行系统测试,在功能上要尽量完善.
页:
[1]
